隨著國內網絡環境的持續惡化，各種篡改和劫持層出不窮，越來越多的網站選擇了全站 HTTPS。就在今天，免費提供證書服務的Let's Encrypt 項目也正式開放，HTTPS 很快就會成為 WEB 必選項。HTTPS 通過 TLS 層和證書機制提供了內容加密、身份認證和數據完整性三大功能，可以有效防止數據被查看或篡改，以及防止中間人冒充。本文分享一些啟用 HTTPS 過程中的經驗，重點是如何與一些新出的安全規范配合使用。至于 HTTPS 的部署及優化，之前寫過很多，本文不重復了。
HTTPS 網頁中加載的 HTTP 資源被稱之為 Mixed Content（混合內容），不同瀏覽器對 Mixed Content 有不一樣的處理規則。
早期的 IE 在發現 Mixed Content 請求時，會彈出「是否只查看安全傳送的網頁內容？」這樣一個模態對話框，一旦用戶選擇「是」，所有 Mixed Content 資源都不會加載；選擇「否」，所有資源都加載。
比較新的 IE 將模態對話框改為頁面底部的提示條，沒有之前那么干擾用戶。而且默認會加載圖片類 Mixed Content，其它如 JavaScript、CSS 等資源還是會根據用戶選擇來決定是否加載。
現代瀏覽器（Chrome、Firefox、Safari、Microsoft Edge），基本上都遵守了 W3C 的 Mixed Content 規范，將 Mixed Content 分為 Optionally-blockable 和Blockable 兩類：
Optionally-blockable 類 Mixed Content 包含那些危險較小，即使被中間人篡改也無大礙的資源?，F代瀏覽器默認會加載這類資源，同時會在控制臺打印警告信息。這類資源包括：
除此之外所有的 Mixed Content 都是 Blockable，瀏覽器必須禁止加載這類資源。所以現代瀏覽器中，對于 HTTPS 頁面中的 JavaScript、CSS 等 HTTP 資源，一律不加載，直接在控制臺打印錯誤信息。
前面所說都是桌面瀏覽器的行為，移動端情況比較復雜，當前大部分移動瀏覽器默認都允許加載 Mixed Content。也就是說，對于移動瀏覽器來說，HTTPS 中的 HTTP 資源，無論是圖片還是 JavaScript、CSS，默認都會加載。
一般選擇了全站 HTTPS，就要避免出現 Mixed Content，頁面所有資源請求都走 HTTPS 協議才能保證所有平臺所有瀏覽器下都沒有問題。
CSP，全稱是 Content Security Policy，它有非常多的指令，用來實現各種各樣與頁面內容安全相關的功能。這里只介紹兩個與 HTTPS 相關的指令，更多內容可以看我之前寫的《Content Security Policy Level 2 介紹》。
前面說過，對于 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">
歷史悠久的大站在往 HTTPS 遷移的過程中，工作量往往非常巨大，尤其是將所有資源都替換為 HTTPS 這一步，很容易產生疏漏。即使所有代碼都確認沒有問題，很可能某些從數據庫讀取的字段中還存在 HTTP 鏈接。
而通過 upgrade-insecure-requests 這個 CSP 指令，可以讓瀏覽器幫忙做這個轉換。啟用這個策略后，有兩個變化：
跟其它所有 CSP 規則一樣，這個指令也有兩種方式來啟用，具體格式請參考上一節。需要注意的是 upgrade-insecure-requests 只替換協議部分，所以只適用于 HTTP/HTTPS 域名和路徑完全一致的場景。
在網站全站 HTTPS 后，如果用戶手動敲入網站的 HTTP 地址，或者從其它地方點擊了網站的 HTTP 鏈接，依賴于服務端 301/302 跳轉才能使用 HTTPS 服務。而第一次的 HTTP 請求就有可能被劫持，導致請求無法到達服務器，從而構成 HTTPS 降級劫持。
這個問題可以通過 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 可以很好的解決 HTTPS 降級攻擊，但是對于 HSTS 生效前的首次 HTTP 請求，依然無法避免被劫持。瀏覽器廠商們為了解決這個問題，提出了 HSTS Preload List 方案：內置一份列表，對于列表中的域名，即使用戶之前沒有訪問過，也會使用 HTTPS 協議；列表可以定期更新。
目前這個 Preload List 由 Google Chrome 維護，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。如果要想把自己的域名加進這個列表，首先需要滿足以下條件：
即便滿足了上述所有條件，也不一定能進入 HSTS Preload List，更多信息可以看這里。通過 Chrome 的 chrome://net-internals/#hsts 工具，可以查詢某個網站是否在 Preload List 之中，還可以手動把某個域名加到本機 Preload List。
對于 HSTS 以及 HSTS Preload List，我的建議是只要你不能確保永遠提供 HTTPS 服務，就不要啟用。因為一旦 HSTS 生效，你再想把網站重定向為 HTTP，之前的老用戶會被無限重定向，唯一的辦法是換新域名。
對于大站來說，全站遷移到 HTTPS 后還是得用 CDN，只是必須選擇支持 HTTPS 的 CDN 了。如果使用第三方 CDN，安全方面有一些需要考慮的地方。
HTTPS 可以防止數據在傳輸中被篡改，合法的證書也可以起到驗證服務器身份的作用，但是如果 CDN 服務器被入侵，導致靜態文件在服務器上被篡改，HTTPS 也無能為力。
W3C 的 SRI（Subresource Integrity）規范可以用來解決這個問題。SRI 通過在頁面引用資源時指定資源的摘要簽名，來實現讓瀏覽器驗證資源是否被篡改的目的。只要頁面不被篡改，SRI 策略就是可靠的。
有關 SRI 的更多說明請看我之前寫的《Subresource Integrity 介紹》。SRI 并不是 HTTPS 專用，但如果主頁面被劫持，攻擊者可以輕松去掉資源摘要，從而失去瀏覽器的 SRI 校驗機制。
另外一個問題是，在使用第三方 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 才是正道。
原文：https://imququ.com/post/sth-about-switch-to-https.html
新聞熱點
疑難解答
