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

理解 Mixed Content

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

早期的 IE

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

比較新的 IE

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

現(xiàn)代瀏覽器

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

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

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

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

移動(dòng)瀏覽器

前面所說都是桌面瀏覽器的行為，移動(dòng)端情況比較復(fù)雜，當(dāng)前大部分移動(dòng)瀏覽器默認(rèn)都允許加載 Mixed Content。也就是說，對(duì)于移動(dòng)瀏覽器來說，HTTPS 中的 HTTP 資源，無論是圖片還是 JavaScript、CSS，默認(rèn)都會(huì)加載。

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

合理使用 CSP

CSP，全稱是 Content Security Policy，它有非常多的指令，用來實(shí)現(xiàn)各種各樣與頁面內(nèi)容安全相關(guān)的功能。這里只介紹兩個(gè)與 HTTPS 相關(guān)的指令，更多內(nèi)容可以看我之前寫的《Content Security Policy Level 2 介紹》。

block-all-mixed-content

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

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

HTTP 響應(yīng)頭方式：

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

<meta> 標(biāo)簽方式：

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

upgrade-insecure-requests

歷史悠久的大站在往 HTTPS 遷移的過程中，工作量往往非常巨大，尤其是將所有資源都替換為 HTTPS 這一步，很容易產(chǎn)生疏漏。即使所有代碼都確認(rèn)沒有問題，很可能某些從數(shù)據(jù)庫讀取的字段中還存在 HTTP 鏈接。

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

• 頁面所有 HTTP 資源，會(huì)被替換為 HTTPS 地址再發(fā)起請(qǐng)求；
• 頁面所有站內(nèi)鏈接，點(diǎn)擊后會(huì)被替換為 HTTPS 地址再跳轉(zhuǎn)；

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

合理使用 HSTS

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

HSTS 基本使用

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

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

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

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

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

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

HSTS Preload List

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

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

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

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

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

CDN 安全

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

合理使用 SRI

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

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

有關(guān) SRI 的更多說明請(qǐng)看我之前寫的《Subresource Integrity 介紹》。SRI 并不是 HTTPS 專用，但如果主頁面被劫持，攻擊者可以輕松去掉資源摘要，從而失去瀏覽器的 SRI 校驗(yàn)機(jī)制。

了解 Keyless SSL

另外一個(gè)問題是，在使用第三方 CDN 的 HTTPS 服務(wù)時(shí)，如果要使用自己的域名，需要把對(duì)應(yīng)的證書私鑰給第三方，這也是一件風(fēng)險(xiǎn)很高的事情。

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

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

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

原文：https://imququ.com/post/sth-about-switch-to-https.html

最新評(píng)論