Author:張天陸

0x00 簡述

---

基於PKI體系的SSL/TLS協議近年來暴出很多安全問題，比如著名的HeartBleed、POODLE攻擊和Freak攻擊等，2014年關於SSL/TLS協議證書驗證問題的CVE有成千個。針對SSL協議在實現中暴露出的各種問題，這裡我們討論一下現有的加固和防範方案，主要包括四個方面：

a) Key pinning策略
b) HSTS策略
c) 多路徑證書檢查策略
d) DNS-based authentication

下面我們基於這四個策略做詳細介紹。

0x01 Key Pinning策略

---

1、 Key Pinning介紹

Pinning是把伺服器的主機名和證書、公鑰等密碼學要素聯絡起來的一種安全技術。例如，當知道某網站的正確證書，再次連結此網站時，可以透過對比已知的正確證書和從網站接收到的證書，判斷是否被中間人攻擊。當然，沒有必要在本地儲存某網站的完整證書資訊，可以對證書做hash（比如SHA-256），本地儲存對應的hash值，這樣比完整證書更便捷，並且節省空間。

相對證書pinning，更為實際的是public key pinning，因為很多時候證書在重新簽發時，並沒有更換其公鑰資訊，這也是為什麼很多證書擁有相同公鑰的原因。這樣如果在本地pin的是公鑰資訊，那麼收到不同的證書也沒關係，只要公鑰內容相同，就可以信任這些證書。

對於SSH此類不依賴於證書的協議，可以直接pin公鑰，但是對於SSL/TLS協議，最好的方式是pin X.509證書的SPKI（SubjectPublicKeyInfo）部分對應的hash值，SPKI部分包含了公鑰以及其他額外的用於安全驗證的資訊（包括所使用的公鑰加密演算法、公鑰位數）。

2、 pin的位置

伺服器基於安全考慮，會經常更換公私鑰對；並且如果私鑰洩露，也需要從CA重新簽發證書；並且同一個網站有可能部署了多個公私鑰對。而如果pin的是伺服器的公鑰，那麼在維護和使用上會相當複雜。

基於上述因素的考慮，可以將pin的位置放在證書鏈上。一般來說證書鏈開始於終端證書，有一箇中間CA證書，最後是根CA證書。如果pin的是後兩個證書資訊（中間CA或者根CA的證書資訊），那麼伺服器終端更換證書時，只要是同一個CA簽發的，那麼證書鏈沒變，pin的資訊也不用更換。

但是這裡會出現另一個問題，CA可能會有很多的上級中間CA，或者不同的根CA，伺服器在更換證書時，即使選擇的是相同CA，那麼上級中間CA有可能不同。

基於這些考慮，最佳的pin位置可以選擇在證書鏈的第二個證書上，就是給伺服器簽發證書的CA的證書，因為即使伺服器更換證書，也會選擇該CA進行證書籤發，pin的資訊不會變。

3、何時用pin

最有效的pinning方式，是在native application中。因為這時作為開發者可以控制通訊雙方，對於桌面應用和移動應用都可以，比如一些銀行軟體，支付軟體等。

對於這種情況，如果開發者可以控制通訊雙方（客戶端與伺服器），從而既可以使用自己的證書作為pinning資訊，也可以使用第三方CA簽發的證書。

4、使用key pinning的不足：

• 伺服器私鑰如果洩露，就需要更換金鑰對，另外伺服器會經常更改金鑰對，為了使相同金鑰加密的資訊不要太多。這時就需要經常的更換pin的資訊，操作複雜。
• 另外同一站點有可能有多個證書，pinning的內容如果不全面，有可能產生錯誤資訊。
• 對於一些應用在更換pin資訊時，需要透過軟體升級的方式，不太方便。

0x02 HSTS策略

---

1、 HSTS簡介

HSTS（HTTP Strict Transport Security）HTTP嚴格傳輸安全，最早於2009年提出，標準化於2012年11月的RFC 6797，是一套由網際網路工程任務組釋出的網際網路安全策略機制。網站可以選擇使用HSTS策略，強制瀏覽器使用TLS協議，並且中斷所有證書出現錯誤的連線，從而減輕瀏覽器在執行TLS協議時所面臨的一些危險。

HSTS策略的使用，主要解決了以下幾個問題：

• 面對一個主機名（沒有指明協議），瀏覽器不知道該網站是否使用TLS協議；
• 當遇到證書錯誤不是阻斷連線，而是給使用者告警（使用者多會選擇忽略）；
• HTTPS頁面從一個HTTP origin載入資源，被稱為mixed content，攻擊者可以透過控制從不安全頁面載入到https頁面的mix content實現攻擊效果；
• cookie遵守的同源策略和web content的同源策略不同，只根據host隔離，因此https和http會共用cookie。

HSTS透過兩種方式，解決以上問題：

• 在本地將所有的http轉換為https，保證使用了HSTS的網站，只能透過https訪問；
• 當遇到證書錯誤時，中斷連結。

2、HSTS安全意義

一些支援https的網站一般情況下也會監聽http的請求，之後再講這些請求重定向為https。例如：當收到http://www.facebook.com時，會將使用者訪問重定向為https://www.facebook.com。這種重定向是不安全的，因為第一個請求使用的是http，攻擊者可以從中獲取一些敏感資訊（比如之前安全會話中的coocie等），另外，攻擊者還可能將使用者重定向到一些釣魚網站。並且根據使用者的輸入習慣，不會在主機名前加上https，更容易帶來威脅。

HSTS策略防止了這種威脅的存在，它要求瀏覽器在本地將http協議強制轉換為https，之後再與伺服器透過https協議進行通訊。

3、HSTS執行

伺服器開啟HSTS的方法是，當客戶端透過HTTPS發出請求時，在伺服器返回的超文字傳輸協議響應頭中包含Strict-Transport-Security欄位（非加密傳輸時設定的HSTS欄位無效，Strict-Transport-Security 頭資訊當透過HTTP請求傳遞，會被瀏覽器忽略，因為攻擊者可能攔截或者篡改HTTP連線頭，直到第一次透過https進行安全連線，並且收到Strict-Transport-Security頭資訊，才會針對該網站配置HSTS策略，這裡可以透過瀏覽器對HSTS preload方式解決）。

Strict-Transport-Security欄位包括：

Strict-Transport-Security: max-age=expireTime [; includeSubdomains]

其中：max-age引數指明瞭過期時間，單位秒，瀏覽器需要記住這個網站只能透過HTTPS訪問的時間；includeSubdomains是可選引數，指明該網站的子域名也需要透過https訪問。

瀏覽器對Strict-Transport-Security欄位處理：

當瀏覽器使用https第一次訪問網站，收到伺服器響應的包含該欄位的頭，會記錄下這些資訊，之後在有效期內，把對該網站的請求都轉換為https。每次瀏覽器收到Strict-Transport-Security頭，都會更新max-age指定的有效期時間，這樣可以防止HSTS策略過期。

我們用圖形簡單介紹HSTS功能：

圖1

圖1標示了正常情況下，伺服器收到http請求時，重定向為https的過程，該過程是不安全的；

圖2

圖2標示了第一次安全連線時，收到HSTS的Strict-Transport-Security頭資訊，之後的訪問都會執行HSTS策略。

圖3

圖3標示HSTS策略執行時的過程。

4、HSTS部署

HSTS的部署要考慮到全面性。預設情況下，HSTS只針對返回Strict-Transport-Security響應頭的主機名部署，但是很多站點可以部署多個域名，因此要注意HSTS策略部署到所有的域名。

對於一些只有一個主機名的網站也需要考慮部署是否全面的問題。例如使用者想要訪問某網站時，沒有加WWW字首（輸入XXX.com訪問www.XXX.com），由於沒法控制使用者的輸入，因此在配置HSTS時要注意覆蓋到所有的主機名。

另外需要注意的是，HSTS部署的全面性要考慮到能夠到達網站的所有的路徑名，比如使用者可能首先透過輸入訪問根域名，之後再訪問其它子域名，此時根域名如果沒有部署HSTS策略，有可能會招到SSL剝離攻擊。

5、HSTS Preloading

當使用者第一次正確使用https連線某網站，並且收到Strict-Transport-Security頭時，才會根據頭資訊對該網站設定HSTS策略。為了提高HSTS的安全效率，解決“first visit”問題，Google安全團隊在Chrome瀏覽器中設定了“HSTS preload list”，列表中的域名都會自動的使用HSTS策略。Firefox，Safari以及最新版本的IE瀏覽器，都會合並使用Chrome的HSTS preload list。

使用HSTS preload可以滿足以下要求：

• 確保了根域名和子域名都被強制使用https；
• 對所有的子域名都標註了一個策略有效時間和preload標記，標示域名擁有者同意加入preload list中。

對於一些金融機構、政府網站或者社交網路等，HSTS策略可以緩解大量SSL/TLS協議遭受到的威脅。但是HSTS策略並不能低於證書偽造攻擊，需要key-pinning策略協同使用。

0x03 多路徑證書檢測

---

多路徑證書檢查策略，核心思想就是不僅僅依賴PKI體系，拋開CA的權威性，透過多個途徑和方法檢驗客戶端收到的證書的合法性。

多路徑證書檢查的方法基本有兩種：

• 公證人輔助證書檢查；
• Tor-Network洋蔥網路檢查；
• Social network藉助社交網路檢查。

這裡我們主要介紹前兩種方法。

1、公證人輔助證書檢查

1.1 Notary簡介

公證人協助驗證證書，是指透過第三方（Notaries）機構，協助驗證證書是否合法有效。最早的出現是Perspectives，Firefox的一個外掛，可以將收到的伺服器證書與大量的notaries進行對比，這些notaries來自於不同的網路節點，這樣即使其中某些節點出現問題，攻擊者仍然沒辦法將所有的notaries攻破。透過對比證書是否相同，判斷是否遭受中間人攻擊。

圖4

圖4展示了利用notaries進行證書比對的流程，當客戶端收到伺服器返回的證書後，向設定好的多個notaries發出請求，根據伺服器主機名查詢多個notaries中對應的證書，透過返回的證書進行比對，如果有不相同，則認為該證書無效。這些notaries部署在不同的網路環境中。

1.2 Notaries證書獲取

最初的Perspectives所對應的Notaries，會定期的主動的掃描全網的主機，從中獲取證書所對應的公鑰，儲存在本地資料庫中，當瀏覽器的Perspectives外掛需要進行證書比對時，從該資料庫中獲取對應主機的證書公鑰，返回給客戶端進行比對。2011年，Convergence notary提供了類似的功能，不同的是Convergence notary不會主動的進行全網掃描，僅僅當客戶端索求一個本地資料庫中沒有的證書時，才會向對應的主機進行證書索取。目前Perspectives和Convergence是兩個權威的notary維護機構，各自維護這多個可以被共用的notaries。

1.3 Notaries的評估

使用Notaries作為第三方，協助進行公鑰檢查，瀏覽器可以透過外掛完全的依賴所設定的可信Notaries，弱化了以X.509證書為基礎的PKI體系。同時，如果某個Notaries被攻破，使用者完全可以自行更改設定，選擇不同的Notaries。

使用Notaries進行證書驗證也有一些缺點：

• 降低了使用者體驗，多了一層證書驗證流程，會降低網路訪問速度；
• 對於一些Notaries，會獲取到使用者想要訪問哪些網站的隱私；
• 一些網站可能會有多個證書，導致Notaries誤報的情況出現。

2、Tor-Network 網路輔助證書檢查

洋蔥網路的特點是當使用者訪問某一個固定的目的端，每次經過的路徑是隨機的。具體來說，TOR客戶端維護一個瀏覽器一樣的代理，其他軟體可以使用該代理提供的藉口，進入Tor網路，TOR節點在不同次的連線時會選擇不同的路徑，不會輕易被中間人攻擊。利用洋蔥網路的這一特點，可以進行多路徑證書檢查。

洋蔥網路輔助證書檢查是建立在正常https協議出現證書警告的情況下，透過洋蔥網路再次獲取證書，比對兩次得到的證書是否相同來判斷是否遭受中間人攻擊。

圖5

圖5展示了使用Tor-Network進行多路徑證書檢查的流程：

• Alice收到https證書警告；
• 透過洋蔥網路代理，接入洋蔥網路；
• 獲取目標伺服器的證書；
• 比對兩次獲取的證書是否相同。

多路徑證書檢查的思想都是透過多一次的證書獲取，與收到的證書進行對比，從而判斷是否遭受中間人攻擊，提高通訊的安全性，但是這種方式勢必會增加TLS連線消耗的時間，降低使用者體驗。

0x04 DNS-based authentication策略

---

4.1 DANE簡介

DANE（DNS-Based Authentication of Named Entities）是一種將域名和密碼學要素聯合起來的安全標準，2012年8月在RFC 6698中標準化定義。域名擁有者可以控制DNS的配置，能夠利用DNS作為單獨的一條渠道來加強TLS的安全執行。DANE方便部署，但是僅靠DNS並不能提供任何安全性質，還需要依靠DNSSEC協議。

DNSSEC簡言之，就是利用數字簽名身份認證技術，在進行域名請求時，驗證整個請求鏈中的每個DNS的身份，確保最終收到的域名資訊是正確的沒有被篡改過。

目前的認證機制分為兩個階段：一是有一群我們信任的第三方機構為域名真正擁有者簽發證書，成為CA；二是客戶端（比如瀏覽器）能夠檢測某主機名對應的證書是正確的。基於這種分離式的架構是因為通訊雙方一般是遠距離沒法碰面的，驗證身份容易找到欺騙。而基於DNSSEC協議，DNS請求就可以確保安全性，就可以利用DNS提供身份驗證，這樣就有一個新的途徑同域名擁有者進行通訊，從而拋棄掉對CA的依賴性。

簡言之，DANE就是在客戶端pin主機名對應的的證書，之後透過DNS請求時，獲取主機名的證書，透過對比判斷證書的可信性。

4.2 DANE作用

• 安全的部署自簽名證書

  現在，自簽名證書被認為是不安全的，因為沒有一種辦法區分自簽名證書和中間人攻擊偽造的證書，也就是說自簽名證書都是一樣的。但是，我們可以用安全的DNS去pin一個自簽名的證書，這樣瀏覽器就可以知道正在使用的自簽名證書是安全的，也可以很容易的區分出中間人攻擊偽造的證書。

• 安全的部署私有根證書 如果可以安全的pin一個伺服器證書，那麼也可以pin這個伺服器證書所在的證書鏈中的任一證書，也就是說可以構造一個你所擁有的網站的根證書，並讓客戶端信任這個證書，這種方式對擁有很多網站的開發者來說，更為方便。

• 支援CA頒發的證書和Public key-pinning DANE無須改變現有的認證架構，同樣的可以在客戶端pin CA頒發的證書和根證書。

4.3 DANE執行

DANE擴充套件了一種新的DNS記錄型別，叫做TLSA Resource Record(TLSA RR或者叫做TLSA)，TLSA包含四個區域：(1) Certificate Usage;(2)Selector;(3)Matching Type;(4)Certificate Association Data。

其中Certificate Usage欄位有四種不同的值：

0-CA規範：pin一個CA，在證書鏈中必須有對應的CA簽發的證書；
1-指定TLS證書：TLSA 記錄指定應當用於某一域名的準確TLS證書；
2-信任點宣告：在客戶端pin一個某站點自己的CA，該CA可以不是公共信任的CA；
3-域名頒發證書：在客戶端pin一個具體的TLS證書，該證書可以是某主機自己簽發的證書

透過後兩種值可以看出，DANE可以完美的支援自簽名證書，同時也確保使用自簽名證書的安全性。

自此，我們講述了四種目前常見的SSL/TLS協議的加固策略，這四種策略固然各有優劣。其中key pinning可以和HSTS結合使用，確保強制使用https的同時也保證了證書安全性。另外，安全性和使用者體驗總是會存在一些衝突，在取和舍之間不同的人又有著不同的觀點。