隨著國內(nèi)網(wǎng)絡環(huán)境的持續(xù)惡化，各種篡改和劫持層出不窮，越來越多的網(wǎng)站選擇了全站 HTTPS。HTTPS 通過 TLS 層和證書機制提供了內(nèi)容加密、身份認證和數(shù)據(jù)完整性三大功能，可以有效防止數(shù)據(jù)被查看或篡改，以及防止中間人冒充。本文分享一些啟用 HTTPS 過程中的經(jīng)驗，重點是如何與一些新出的安全規(guī)范配合使用。至于 HTTPS 的部署及優(yōu)化，之前寫過很多，本文不重復了。

理解 Mixed Content

HTTPS 網(wǎng)頁中加載的 HTTP 資源被稱之為 Mixed Content(混合內(nèi)容)，不同瀏覽器對 Mixed Content 有不一樣的處理規(guī)則。

早期的 IE

早期的 IE 在發(fā)現(xiàn) Mixed Content 請求時，會彈出「是否只查看安全傳送的網(wǎng)頁內(nèi)容?」這樣一個模態(tài)對話框，一旦用戶選擇「是」，所有 Mixed Content 資源都不會加載;選擇「否」，所有資源都加載。

比較新的 IE

比較新的 IE 將模態(tài)對話框改為頁面底部的提示條，沒有之前那么干擾用戶。而且默認會加載圖片類 Mixed Content，其它如 JavaScript、CSS 等資源還是會根據(jù)用戶選擇來決定是否加載。

現(xiàn)代瀏覽器

現(xiàn)代瀏覽器(Chrome、Firefox、Safari、Microsoft Edge)，基本上都遵守了 W3C 的 Mixed Content 規(guī)范，將 Mixed Content 分為Optionally-blockable 和 Blockable 兩類：

Optionally-blockable 類 Mixed Content 包含那些危險較小，即使被中間人篡改也無大礙的資源?，F(xiàn)代瀏覽器默認會加載這類資源，同時會在控制臺打印警告信息。這類資源包括：

通過 標簽加載的圖片(包括 SVG 圖片);

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

預讀的(Prefetched)資源;

除此之外所有的 Mixed Content 都是 Blockable，瀏覽器必須禁止加載這類資源。所以現(xiàn)代瀏覽器中，對于 HTTPS 頁面中的 JavaScript、CSS 等 HTTP 資源，一律不加載，直接在控制臺打印錯誤信息。

移動瀏覽器

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

一般選擇了全站 HTTPS，就要避免出現(xiàn) Mixed Content，頁面所有資源請求都走 HTTPS 協(xié)議才能保證所有平臺所有瀏覽器下都沒有問題。

合理使用 CSP

CSP，全稱是 Content Security Policy，它有非常多的指令，用來實現(xiàn)各種各樣與頁面內(nèi)容安全相關的功能。

block-all-mixed-content

前面說過，對于 HTTPS 中的圖片等 Optionally-blockable 類 HTTP 資源，現(xiàn)代瀏覽器默認會加載。圖片類資源被劫持，通常不會有太大的問題，但也有一些風險，例如很多網(wǎng)頁按鈕是用圖片實現(xiàn)的，中間人把這些圖片改掉，也會干擾用戶使用。

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

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 這一步，很容易產(chǎn)生疏漏。即使所有代碼都確認沒有問題，很可能某些從數(shù)據(jù)庫讀取的字段中還存在 HTTP 鏈接。

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

頁面所有 HTTP 資源，會被替換為 HTTPS 地址再發(fā)起請求;

頁面所有站內(nèi)鏈接，點擊后會被替換為 HTTPS 地址再跳轉;

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

合理使用 HSTS

在網(wǎng)站全站 HTTPS 后，如果用戶手動敲入網(wǎng)站的 HTTP 地址，或者從其它地方點擊了網(wǎng)站的 HTTP 鏈接，依賴于服務端 301/302 跳轉才能使用 HTTPS 服務。而第一次的 HTTP 請求就有可能被劫持，導致請求無法到達服務器，從而構成 HTTPS 降級劫持。

HSTS 基本使用

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

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

max-age，單位是秒，用來告訴瀏覽器在指定時間內(nèi)，這個網(wǎng)站必須通過 HTTPS 協(xié)議來訪問。也就是對于這個網(wǎng)站的 HTTP 地址，瀏覽器需要先在本地替換為 HTTPS 之后再發(fā)送請求。

includeSubDomains，可選參數(shù)，如果指定這個參數(shù)，表明這個網(wǎng)站所有子域名也必須通過 HTTPS 協(xié)議來訪問。

preload，可選參數(shù)，后面再介紹它的作用。

HSTS 這個響應頭只能用于 HTTPS 響應;網(wǎng)站必須使用默認的 443 端口;必須使用域名，不能是 IP。而且啟用 HSTS 之后，一旦網(wǎng)站證書錯誤，用戶無法選擇忽略。

HSTS Preload List

可以看到 HSTS 可以很好的解決 HTTPS 降級攻擊，但是對于 HSTS 生效前的首次 HTTP 請求，依然無法避免被劫持。瀏覽器廠商們?yōu)榱私鉀Q這個問題，提出了 HSTS Preload List 方案：內(nèi)置一份列表，對于列表中的域名，即使用戶之前沒有訪問過，也會使用 HTTPS 協(xié)議;列表可以定期更新。

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

擁有合法的證書(如果使用 SHA-1 證書，過期時間必須早于 2016 年);

將所有 HTTP 流量重定向到 HTTPS;

確保所有子域名都啟用了 HTTPS;

輸出 HSTS 響應頭：

max-age 不能低于 18 周(10886400 秒);

必須指定 includeSubdomains 參數(shù);

必須指定 preload 參數(shù);

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

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

CDN 安全

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

合理使用 SRI

HTTPS 可以防止數(shù)據(jù)在傳輸中被篡改，合法的證書也可以起到驗證服務器身份的作用，但是如果 CDN 服務器被入侵，導致靜態(tài)文件在服務器上被篡改，HTTPS 也無能為力。

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

SRI 并不是 HTTPS 專用，但如果主頁面被劫持，攻擊者可以輕松去掉資源摘要，從而失去瀏覽器的 SRI 校驗機制。

了解 Keyless SSL

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

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

CloudFlare 的這套機制已經(jīng)開源，如需了解詳情，可以查看他們官方博客的這篇文章：Keyless SSL: The Nitty Gritty Technical Details。

好了，本文先就寫到這里，需要注意的是本文提到的 CSP、HSTS 以及 SRI 等策略都只有最新的瀏覽器才支持，詳細的支持度可以去 CanIUse 查。切換到 HTTPS 之后，在性能優(yōu)化上有很多新工作要做，這部分內(nèi)容我在之前的博客中寫過很多，這里不再重復，只說最重要的一點：既然都 HTTPS 了，趕緊上 HTTP/2 才是正道。