跑步進入全站 HTTPS ，這些經驗值得你看看

隨著國內網路環境的持續惡化，各種篡改和劫持層出不窮，越來越多的網站選擇了全站 HTTPS。就在前幾天，免費提供證照服務的 Let’s Encrypt 專案也正式開放測試，HTTPS 很快就會成為 WEB 必選項。HTTPS 通過 TLS 層和證照機制提供了內容加密、身份認證和資料完整性三大功能，可以有效防止資料被檢視或篡改，以及防止中間人冒充。本文分享一些啟用 HTTPS 過程中的經驗，重點是如何與一些新出的安全規範配合使用。至於 HTTPS 的部署及優化，之前寫過很多，本文不重複了。

理解 Mixed Content

HTTPS 網頁中載入的 HTTP 資源被稱之為混合內容（Mixed Content），不同瀏覽器對混合內容有不一樣的處理規則。

早期的 IE

早期的 IE 在發現混合內容請求時，會彈出「是否只檢視安全傳送的網頁內容？」這樣一個模態對話方塊，一旦使用者選擇「是」，所有混合內容資源都不會載入；選擇「否」，所有資源都載入。

比較新的 IE

比較新的 IE 將模態對話方塊改為頁面底部的提示條，沒有之前那麼干擾使用者。而且預設會載入圖片類混合內容，其它如 JavaScript、CSS 等資源還是會根據使用者選擇來決定是否載入。

現代瀏覽器

現代瀏覽器（Chrome、Firefox、Safari、Microsoft Edge），基本上都遵守了 W3C 的混合內容Mixed Content規範，將混合內容分為 Optionally-blockable 和 Blockable 兩類：

Optionally-blockable 類混合內容包含那些危險較小，即使被中間人篡改也無大礙的資源。現代瀏覽器預設會載入這類資源，同時會在控制檯列印警告資訊。這類資源包括：

• 通過 <img> 標籤載入的圖片（包括 SVG 圖片）；
• 通過 <video> / <audio> 和 <source> 標籤載入的視訊或音訊；
• 預讀的（Prefetched）資源；

除此之外所有的混合內容都是 Blockable，瀏覽器必須禁止載入這類資源。所以現代瀏覽器中，對於 HTTPS 頁面中的 JavaScript、CSS 等 HTTP 資源，一律不載入，直接在控制檯列印錯誤資訊。

移動瀏覽器

前面所說都是桌面瀏覽器的行為，移動端情況比較複雜，當前大部分移動瀏覽器預設允許載入所有混合內容。也就是說，對於移動瀏覽器來說，HTTPS 中的 HTTP 資源，無論是圖片還是 JavaScript、CSS，預設都會載入。

補充：上面這段結論源自於我大半年前的測試，本文評論中的 ayanamist 同學反饋現狀已經有所變化。我又做了一些測試，果然隨著作業系統的升級，移動瀏覽器都開始遵循混合內容規範了。最新測試表明，對於 Blockable 類混合內容：

• iOS 9 以下的 Safari，以及 Android 5 以下的 Webview，預設會載入；
• Android 各版本的 Chrome，iOS 9+ 的 Safari，Android 5+ 的 Webview，預設不會載入；

一般選擇了全站 HTTPS，就要避免出現混合內容，頁面所有資源請求都走 HTTPS 協議才能保證所有平臺所有瀏覽器下都沒有問題。

合理使用 CSP

CSP，全稱是 Content Security Policy，它有非常多的指令，用來實現各種各樣與頁面內容安全相關的功能。這裡只介紹兩個與 HTTPS 相關的指令，更多內容可以看我之前寫的《Content Security Policy Level 2 介紹》。

block-all-mixed-content

前面說過，對於 HTTPS 中的圖片等 Optionally-blockable 類 HTTP 資源，現代瀏覽器預設會載入。圖片類資源被劫持，通常不會有太大的問題，但也有一些風險，例如很多網頁按鈕是用圖片實現的，中間人把這些圖片改掉，也會干擾使用者使用。

通過 CSP 的 block-all-mixed-content 指令，可以讓頁面進入對混合內容的嚴格檢測（Strict Mixed Content Checking）模式。在這種模式下，所有非 HTTPS 資源都不允許載入。跟其它所有 CSP 規則一樣，可以通過以下兩種方式啟用這個指令：

HTTP 響應頭方式：

Content-Security-Policy: block-all-mixed-content

<meta> 標籤方式：

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">

upgrade-insecure-requests

歷史悠久的大站在往 HTTPS 遷移的過程中，工作量往往非常巨大，尤其是將所有資源都替換為 HTTPS 這一步，很容易產生疏漏。即使所有程式碼都確認沒有問題，很可能某些從資料庫讀取的欄位中還存在 HTTP 連結。

而通過 upgrade-insecure-requests 這個 CSP 指令，可以讓瀏覽器幫忙做這個轉換。啟用這個策略後，有兩個變化：

• 頁面所有 HTTP 資源，會被替換為 HTTPS 地址再發起請求；
• 頁面所有站內連結，點選後會被替換為 HTTPS 地址再跳轉；

跟其它所有 CSP 規則一樣，這個指令也有兩種方式來啟用，具體格式請參考上一節。需要注意的是 upgrade-insecure-requests 只替換協議部分，所以只適用於 HTTP/HTTPS 域名和路徑完全一致的場景。

合理使用 HSTS

在網站全站 HTTPS 後，如果使用者手動敲入網站的 HTTP 地址，或者從其它地方點選了網站的 HTTP 連結，依賴於服務端 301/302 跳轉才能使用 HTTPS 服務。而第一次的 HTTP 請求就有可能被劫持，導致請求無法到達伺服器，從而構成 HTTPS 降級劫持。

HSTS 基本使用

這個問題可以通過 HSTS（HTTP Strict Transport Security，RFC6797）來解決。HSTS 是一個響應頭，格式如下：

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

• max-age，單位是秒，用來告訴瀏覽器在指定時間內，這個網站必須通過 HTTPS 協議來訪問。也就是對於這個網站的 HTTP 地址，瀏覽器需要先在本地替換為 HTTPS 之後再傳送請求。
• includeSubDomains，可選引數，如果指定這個引數，表明這個網站所有子域名也必須通過 HTTPS 協議來訪問。
• preload，可選引數，後面再介紹它的作用。

HSTS 這個響應頭只能用於 HTTPS 響應；網站必須使用預設的 443 埠；必須使用域名，不能是 IP。而且啟用 HSTS 之後，一旦網站證照錯誤，使用者無法選擇忽略。

HSTS Preload List

可以看到 HSTS 可以很好的解決 HTTPS 降級攻擊，但是對於 HSTS 生效前的首次 HTTP 請求，依然無法避免被劫持。瀏覽器廠商們為了解決這個問題，提出了 HSTS Preload List 方案：內建一份列表，對於列表中的域名，即使使用者之前沒有訪問過，也會使用 HTTPS 協議；列表可以定期更新。

目前這個 Preload List 由 Google Chrome 維護，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。如果要想把自己的域名加進這個列表，首先需要滿足以下條件：

• 擁有合法的證照（如果使用 SHA-1 證照，過期時間必須早於 2016 年）；
• 將所有 HTTP 流量重定向到 HTTPS；
• 確保所有子域名都啟用了 HTTPS；
• 輸出 HSTS 響應頭：
  • max-age 不能低於 18 周（10886400 秒）；
  • 必須指定 includeSubdomains 引數；
  • 必須指定 preload 引數；

即便滿足了上述所有條件，也不一定能進入 HSTS Preload List，更多資訊可以看這裡。通過 Chrome 的 chrome://net-internals/#hsts 工具，可以查詢某個網站是否在 Preload List 之中，還可以手動把某個域名加到本機 Preload List。

對於 HSTS 以及 HSTS Preload List，我的建議是隻要你不能確保永遠提供 HTTPS 服務，就不要啟用。因為一旦 HSTS 生效，你再想把網站重定向為 HTTP，之前的老使用者會被無限重定向，唯一的辦法是換新域名。

CDN 安全

對於大站來說，全站遷移到 HTTPS 後還是得用 CDN，只是必須選擇支援 HTTPS 的 CDN 了。如果使用第三方 CDN，安全方面有一些需要考慮的地方。

合理使用 SRI

HTTPS 可以防止資料在傳輸中被篡改，合法的證照也可以起到驗證伺服器身份的作用，但是如果 CDN 伺服器被入侵，導致靜態檔案在伺服器上被篡改，HTTPS 也無能為力。

W3C 的 SRI（Subresource Integrity）規範可以用來解決這個問題。SRI 通過在頁面引用資源時指定資源的摘要簽名，來實現讓瀏覽器驗證資源是否被篡改的目的。只要頁面不被篡改，SRI 策略就是可靠的。

有關 SRI 的更多說明請看我之前寫的《Subresource Integrity 介紹》。SRI 並不是 HTTPS 專用，但如果主頁面被劫持，攻擊者可以輕鬆去掉資源摘要，從而失去瀏覽器的 SRI 校驗機制。

瞭解 Keyless SSL

另外一個問題是，在使用第三方 CDN 的 HTTPS 服務時，如果要使用自己的域名，需要把對應的證照私鑰給第三方，這也是一件風險很高的事情。

CloudFlare 公司針對這種場景研發了 Keyless SSL 技術。你可以不把證照私鑰給第三方，改為提供一臺實時計算的 Key Server 即可。CDN 要用到私鑰時，通過加密通道將必要的引數傳給 Key Server，由 Key Server 算出結果並返回即可。整個過程中，私鑰都保管在自己的 Key Server 之中，不會暴露給第三方。

CloudFlare 的這套機制已經開源，如需瞭解詳情，可以檢視他們官方部落格的這篇文章：Keyless SSL: The Nitty Gritty Technical Details。

好了，本文先就寫到這裡，需要注意的是本文提到的 CSP、HSTS 以及 SRI 等策略都只有最新的瀏覽器才支援，詳細的支援度可以去 CanIUse 查。切換到 HTTPS 之後，在效能優化上有很多新工作要做，這部分內容我在之前的部落格中寫過很多，這裡不再重複，只說最重要的一點：

既然都 HTTPS 了，趕緊上 HTTP/2 才是正道。