關於啟用 HTTPS 的一些經驗分享

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

　理解 Mixed Content

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

　　早期的 IE

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

　　比較新的 IE

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

　　現代瀏覽器

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

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

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

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

　　移動瀏覽器

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

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

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

　　一般選擇了全站 HTTPS，就要避免出現 Mixed Content，頁面所有資源請求都走 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 才是正道。