安全網站迴避HTTP公鑰固定？！

安全網站迴避HTTP公鑰固定？！

 HTTP公鑰固定 (HTTP Public Key Pinning），或稱HPKP，可以防止欺詐者頒發偽造的TLS證照。儘管它能夠有效抵禦欺詐性證照的侵襲，而且一些瀏覽器一年多前就已經支援這項技術，採用它的HTTPS站點少之又少。

Netcraft在SSL調研中發現，只有不到0.1%的證照用於HPKP響應頭。而在實際部署中，三分之一的運維者採用了錯誤的HPKP配置策略。HPKP部署門檻之高，顯而易見。

即使已入門，也需要對維護給予高度重視：無論是常規維護還是實施緊急措施都有可能給合法的訪問者帶來巨大風險，而且是長期的。但是，只要部署正確、維護妥當，HPKP絕對是一項強大的安全技術。

 HPKP防什麼？

一個網站可以透過部署HTTPS, HSTS和HSTS preloading預載入抵禦大部分中間人攻擊。將所有這些技術疊加在一起，可以保證網站通訊從發出請求到獲得響應都是被加密和授權的。

儘管有這些技術可以有效抵禦如pharming和sslstrip之類的攻擊，還是有許多攻擊正躍躍欲試。一個偏執的攻擊者甚至可以透過說服CA為他簽發一張偽造的證照，來攻擊一個防設“完美”的HTTPS網站。

HPKP可以防止顧客進入持有效假冒證照的釣魚網站。儘管兩個站點都持有可信CA簽發的證照，只有真實網站的證照鏈包含了客戶端所期望的證照。瀏覽器會對每個包涵雜湊函式的固定證照進行網站預訪問。

雖說讓攻擊者特地去為一個不由他控制的域名獲取一張證照挺難，但也不是不可能。事實上這樣的例子發生過很多次。多家證照授權機構被攻破，寬鬆的策略被發現，技術上的缺陷被攻擊者利用。

HPKP響應頭的引入就是基於生態系統的證照誤發歷史。為了使用HPKP，網站運營者必須挑選出一系列的公鑰並投入使用。一旦使用者訪問站點，它的HPKP策略就會被儲存在客戶端，用來攔截未來所有非白名單的伺服器連線。

當HPKP遇上使用者計算機的本地流氓根證照，靠一條策略就想要抵禦所有仿冒攻擊是遠遠不夠的。近日，Dell和Lenovo公司都被曝光在使用者計算機內植入根證照，甚至還包含了私鑰。攻擊者只要有心，就可以利用這點為任何站點生成任何證照，然後仿冒這個網站。而受害者的瀏覽器會無視站點的HPKP策略，直接把證照當做合法的。

HPKP怎麼用？

使用HPKP可以固定三種金鑰：

• 網站當前的證照公鑰
• 包含CA和中級證照的公鑰
• 備份金鑰

為了能夠使瀏覽器接受並儲存網站的HPKP策略，至少需要兩個特定的釘針用於固定。其中一個用於在校驗網站證照時固定瀏覽器信任鏈，另一個作為後備。

以下這個例子固定了三個不同的公鑰（標粗內容）。這條規則有效期為一年，涵蓋了所有現域名的子域名：

Public-Key-Pins:
  pin-sha256="Q0ig6URMeMsmXgWNXolEtNhPlmK9Jtslf4k0pEPHAWE=";
  pin-sha256="F5OSegYUVJeJrc4vjzT38LZtDzrjo7hNIewV27pPrcc=";
  pin-sha256="p1Uk2ryJ7QmI5/zIzFmdzme0X+2nvXG5bHwR88A5ZjA=";
  max-age=31536000; includeSubDomains

網站運維者必須在固定CA金鑰時格外小心。因為CA可能會不經提醒就更改他們的簽發機制，新證照可能用的不是之前那條信任鏈。如果新的證照鏈不再包含固定金鑰，整個網站將在HPKP規則過期之前都無法訪問。

為了避免使用CA金鑰可能導致的麻煩，可以選擇固定自己的金鑰。但考慮到備份金鑰可能不能用（金鑰丟失或者不符合證照的要求（比如，該備份金鑰被視作 Debian weak key，CA是不會接受並在新證照中採納的）），風險也很大。

 那誰還敢固定？

如果固定和證照都安排合理，HPKP實現起來可以稱得上是完全安全的。但一想到可能出現的問題，HPKP就沒那麼“安全”了：任何一個細小的問題都會讓客戶幾個月都無法訪問到網站，從而毀掉一家網路公司。在諸多最火的站點中，以下敢使用HPKP的都是勇士：

GitHub

GitHub是部署HPKP最頻繁的網站。 眾所周知，GitHub最注重安全，它配置了太多當今最優秀的安全響應頭。

當你訪問 ，其中的一個響應頭就是用HPKP佈置的：

Public-Key-Pins: max-age=300;
  pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=";
  pin-sha256="JbQbUG5JMJUoI6brnx0x3vZF6jilxsapbXGVfjhN8Fg=";
  includeSubDomains

這個HPKP策略帶有兩個固定，該指令適用於所有子域。

第一個固定的金鑰（使用了 WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18= SHA-256 hash）包含了DigiCert High Assurance EV Root CA。這是github.com現在使用的根信任鏈。

第二個雜湊函式（ JbQbUG5JMJUoI6brnx0x3vZF6jilxsapbXGVfjhN8Fg=)是Github的後備固定。它包含了 VeriSign Class 3 Public Primary Certification Authority – G5 root。鑑於這個金鑰並沒有出現在Github的現有證照鏈上，它被視作後備固定。

當Github希望替換它的TLS證照時，新證照必須是由DigiCert或者 簽發的——否則，任何新證照鏈的金鑰都無法與設定好的HPKP規則進行匹配，從而使用者會被拉入訪問黑名單。

相對於固定Github自己的備份金鑰，固定一組根證照金鑰風險要更小些，卻是一筆更大的“交易”。根據Github現有的HPKP規則，攻擊者依舊可以透過獲取一張由DigiCert或Symantac簽發的偽造證照來仿冒它。相反的，如果Github是依賴於它的備份金鑰，那攻擊者就只能靠攻破Github的私鑰了。

即便如此，Github仍保持警惕——它把HPKP響應頭的max-age設到了300。這意味著，瀏覽器只會在300秒內記住這條規則，由此一旦發生錯誤，使用者也至多隻會在五分鐘內被拒絕訪問。但這種做法也使得安全策略本身顯得雞肋。

在一場攻擊中，任何在五分鐘之內沒訪問到真實Github網站 的訪客都會是潛在的受害者。就算他在五分鐘之內訪問了Github，被拒絕訪問也可能只是個小差錯。而一個精明的攻擊者可以等個五分鐘再進入Github，以確保不被發現。

Mozilla

Mozilla正在更有效地採用HPKP並支援到自己的網站上。它設定了更高的max-age響應：

Public-Key-Pins: max-age=1296000;
  pin-sha256="r/mIkG3eEpVdm+u/ko/cwxzOMo1bk4TyHIlByibiA5E="
  pin-sha256="WoiWRyIOVNa9ihaBciRSC7XHjliYS9VwUGOIud4PB18=";

這個數字相當於15天，也就是說它每兩週可以為任何訪客提供有效的保護措施。

相較於使用包含不止一個CA的公鑰雜湊，Mozilla選擇了固定單個CA:所有金鑰都由DigiCert掌管。從某種角度說，只讓一家CA簽發新證照固然是安全的，但這導致Mozilla只能用DigiCert。萬一DigiCert被迫終止簽發，而Mozilla的證照又剛好需要替換，訪客將會在15天內被限制訪問Mozilla的站點。

Pixabay

pixabay.com的Pixabay相簿採用了更大膽的HPKP配置。它的Public-Key-Pins響應頭設定的max-age為一年。

Public-Key-Pins:
  pin-sha256="Kx1dtEVeqnPn0gfhzqIJfChEYFr5zMe+FjvcJ0AhVgE=";
  pin-sha256="zN9pxsvWtHm05/fKZ6zA1NJOq4j2NJJA3oIecCNc1eU=";
  max-age=31536000;

相較於固定CA掌管的金鑰，Pixabay固定了它自己的證照金鑰以及備份金鑰。這個做法完全防止了CA洩密帶來的問題，但也將風險轉嫁到另一方面：萬一備份金鑰不可用怎麼辦。

如果Pixabay丟失了所有證照的私鑰，那將是災難性的——訪客將在一整年裡被拒絕訪問。但Pixabay認為這項風險部署是值得的。

為什麼只有少量網站敢用HPKP?

在Netcraft SSL調研中顯示，只有0.09%的證照在使用HPKP——這個數字比只有4100張證照由公鑰固定響應頭傳遞還要小。

或許有人認為這個數字還低得不夠驚人。但事實上，其中超過四分之一的站點都在錯誤使用HPKP響應頭，甚至可以稱得上是禁用了HPKP。也就是說，真正在使用HPKP的證照數量低於3000。

依舊處於萌芽期

HPKP沒有被廣泛部署的一大原因是因為它還只是一項新標準，而且並沒有被所有主流瀏覽器支援。然而，這只是部分解釋了它在服務端上不得志的原因。

Firefox 35也支援了HPKP技術，大約四分之一的網民受益於使用HPKP的站點。但在今天，HPKP仍沒有被IE, Edge, Safari以及Opera Mini支援。另一方面，成千上萬的使用者正在使用支援HPKP的瀏覽器，而之所以他們沒能得益於這項技術，是因為只有少部分網站在部署它。

缺乏重視

或許缺乏HPKP部署的最大的原因在於，許多網站運維者缺乏安全意識，又或者並沒有意識到它能帶來的好處。然而許多網站最主要的問題是缺乏一些最基礎的網站設施，比如such as HSTS和“安全”的cookies。如果一個網站連HSTS都不支援，採用HPKP也是多餘的，因為中間人攻擊者還是可以劫持未加密的HTTP流量、阻止受害者的瀏覽器轉到HTTPS網站。

缺乏理解

Nercraft的SSL調研結果說明了，許多繁瑣的錯誤都是因為網站運營者在部署HPKP響應頭的時候缺乏理解能力。這導致了在許多網站上HPKP都不能用。

害怕“HPKP Footgun”

HPKP是保護網站免於欺詐性證照攻擊的最佳途徑。但在上文中我們已經討論到，HPKP的部署結果容易適得其反。一個小小的錯誤配置所能達到的破壞程度不可置否。

HPKP提供了針對中間人攻擊的強大防禦，糅合了HTTPS、HSTS以及HSTS預載入技術——雖然優點顯而易見，但沒什麼人去使用。目前只有0.09%的安全網站在使用HPKP響應頭。

在部署HPKP時很難發現哪裡出錯，而任何一個環節出錯都足以最終毀掉一個公司（長達數月的網站拒絕訪問）。目前只有幾千家安全站點接受這項風險。當然你也可以說只有那些備受矚目的大型網站才會有用HPKP的必要。對那些小型網站而言，HPKP出錯引發的災難要比普通的網站攻擊要嚴重得多：畢竟他們受欺詐性證照攻擊的可能性還是非常小的，這種事主要針對大的網站。

還有一個更新的技術叫做Expect CT可能提供更加安全和容易的方式來應對欺詐性證照。採納這項技術的網站能夠讓瀏覽器到Certificate Transparency的日誌裡檢視他們的安全證照。而這些日誌是完全透明的，所有域名擁有者、CA和域名使用者都可以去驗證錯誤簽發的證照；欺詐性證照不會出現在日誌列表中，自然在Expect CT這邊也就不可信。這些日誌的錄入主要由CA來完成，同時也減輕了不少網站運營者的負擔。

對於那些正確配置HPKP的網站而言，要去攻擊他們極難，但也不是不可能。如果瀏覽器從來沒有訪問過任何站點，那它仍有可能受到中間人攻擊。因為不像HSTS，HPKP沒有常規的預載入列表。

 

全球可信CA機構