啟用HTTPS的原理

這篇文章主要講解了“啟用 HTTPS 的原理”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“啟用 HTTPS 的原理”吧！

理解 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)對話框改為頁面底部的提示條，沒有之前那么干擾用戶。而且默認(rèn)會加載圖片類 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 包含那些危險較小，即使被中間人篡改也無大礙的資源。現(xiàn)代瀏覽器默認(rèn)會加載這類資源，同時會在控制臺打印警告信息。這類資源包括：

• 通過 <img> 標(biāo)簽加載的圖片（包括 SVG 圖片）；

• 通過 <video> / <audio> 和 <source> 標(biāo)簽加載的視頻或音頻；

• 預(yù)讀的（Prefetched）資源；

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

移動瀏覽器

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

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

合理使用 CSP

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

block-all-mixed-content

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

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

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 這個 CSP 指令，可以讓瀏覽器幫忙做這個轉(zhuǎn)換。啟用這個策略后，有兩個變化：

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

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

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

合理使用 HSTS

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

HSTS 基本使用

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

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 這個響應(yīng)頭只能用于 HTTPS 響應(yīng)；網(wǎng)站必須使用默認(rèn)的 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 維護(hù)，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。如果要想把自己的域名加進(jìn)這個列表，首先需要滿足以下條件：

• 擁有合法的證書（如果使用 SHA-1 證書，過期時間必須早于 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 工具，可以查詢某個網(wǎng)站是否在 Preload List 之中，還可以手動把某個域名加到本機 Preload List。

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

CDN 安全

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

合理使用 SRI

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

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

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

了解 Keyless SSL

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

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

感謝各位的閱讀，以上就是“啟用 HTTPS 的原理”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對啟用 HTTPS 的原理這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！