建站
咨詢
售后
建站咨詢
新聞中心
隨著國(guó)內(nèi)網(wǎng)絡(luò)環(huán)境的持續(xù)惡化，各種篡改和劫持層出不窮，越來(lái)越多的網(wǎng)站選擇了全站 HTTPS。HTTPS 通過(guò) TLS 層和證書(shū)機(jī)制提供了內(nèi)容加密、身份認(rèn)證和數(shù)據(jù)完整性三大功能，可以有效防止數(shù)據(jù)被查看或篡改，以及防止中間人冒充。本文分享一些啟用 HTTPS 過(guò)程中的經(jīng)驗(yàn)，重點(diǎn)是如何與一些新出的安全規(guī)范配合使用。至于 HTTPS 的部署及優(yōu)化，之前寫(xiě)過(guò)很多，本文不重復(fù)了。
理解 Mixed Content
HTTPS 網(wǎng)頁(yè)中加載的 HTTP 資源被稱之為 Mixed Content(混合內(nèi)容)，不同瀏覽器對(duì) Mixed Content 有不一樣的處理規(guī)則。
早期的 IE
早期的 IE 在發(fā)現(xiàn) Mixed Content 請(qǐng)求時(shí)，會(huì)彈出「是否只查看安全傳送的網(wǎng)頁(yè)內(nèi)容?」這樣一個(gè)模態(tài)對(duì)話框，一旦用戶選擇「是」，所有 Mixed Content 資源都不會(huì)加載;選擇「否」，所有資源都加載。
比較新的 IE
比較新的 IE 將模態(tài)對(duì)話框改為頁(yè)面底部的提示條，沒(méi)有之前那么干擾用戶。而且默認(rèn)會(huì)加載圖片類 Mixed Content，其它如 JavaScript、CSS 等資源還是會(huì)根據(jù)用戶選擇來(lái)決定是否加載。
現(xiàn)代瀏覽器
現(xiàn)代瀏覽器(Chrome、Firefox、Safari、Microsoft Edge)，基本上都遵守了 W3C 的 Mixed Content 規(guī)范，將 Mixed Content 分為Optionally-blockable 和 Blockable 兩類：
Optionally-blockable 類 Mixed Content 包含那些危險(xiǎn)較小，即使被中間人篡改也無(wú)大礙的資源?，F(xiàn)代瀏覽器默認(rèn)會(huì)加載這類資源，同時(shí)會(huì)在控制臺(tái)打印警告信息。這類資源包括：
通過(guò) 標(biāo)簽加載的圖片(包括 SVG 圖片);
通過(guò) 標(biāo)簽加載的圖片（包括 SVG 圖片）；
通過(guò)
預(yù)讀的（Prefetched）資源；
預(yù)讀的(Prefetched)資源;
除此之外所有的 Mixed Content 都是 Blockable，瀏覽器必須禁止加載這類資源。所以現(xiàn)代瀏覽器中，對(duì)于 HTTPS 頁(yè)面中的 JavaScript、CSS 等 HTTP 資源，一律不加載，直接在控制臺(tái)打印錯(cuò)誤信息。
移動(dòng)瀏覽器
前面所說(shuō)都是桌面瀏覽器的行為，移動(dòng)端情況比較復(fù)雜，當(dāng)前大部分移動(dòng)瀏覽器默認(rèn)都允許加載 Mixed Content。也就是說(shuō)，對(duì)于移動(dòng)瀏覽器來(lái)說(shuō)，HTTPS 中的 HTTP 資源，無(wú)論是圖片還是 JavaScript、CSS，默認(rèn)都會(huì)加載。
一般選擇了全站 HTTPS，就要避免出現(xiàn) Mixed Content，頁(yè)面所有資源請(qǐng)求都走 HTTPS 協(xié)議才能保證所有平臺(tái)所有瀏覽器下都沒(méi)有問(wèn)題。
合理使用 CSP
CSP，全稱是 Content Security Policy，它有非常多的指令，用來(lái)實(shí)現(xiàn)各種各樣與頁(yè)面內(nèi)容安全相關(guān)的功能。
block-all-mixed-content
前面說(shuō)過(guò)，對(duì)于 HTTPS 中的圖片等 Optionally-blockable 類 HTTP 資源，現(xiàn)代瀏覽器默認(rèn)會(huì)加載。圖片類資源被劫持，通常不會(huì)有太大的問(wèn)題，但也有一些風(fēng)險(xiǎn)，例如很多網(wǎng)頁(yè)按鈕是用圖片實(shí)現(xiàn)的，中間人把這些圖片改掉，也會(huì)干擾用戶使用。
通過(guò) CSP 的 block-all-mixed-content 指令，可以讓頁(yè)面進(jìn)入對(duì)混合內(nèi)容的嚴(yán)格檢測(cè)(Strict Mixed Content Checking)模式。在這種模式下，所有非 HTTPS 資源都不允許加載。跟其它所有 CSP 規(guī)則一樣，可以通過(guò)以下兩種方式啟用這個(gè)指令：
HTTP 響應(yīng)頭方式：
Content-Security-Policy: block-all-mixed-content
標(biāo)簽方式：
upgrade-insecure-requests
歷史悠久的大站在往 HTTPS 遷移的過(guò)程中，工作量往往非常巨大，尤其是將所有資源都替換為 HTTPS 這一步，很容易產(chǎn)生疏漏。即使所有代碼都確認(rèn)沒(méi)有問(wèn)題，很可能某些從數(shù)據(jù)庫(kù)讀取的字段中還存在 HTTP 鏈接。
而通過(guò) upgrade-insecure-requests 這個(gè) CSP 指令，可以讓瀏覽器幫忙做這個(gè)轉(zhuǎn)換。啟用這個(gè)策略后，有兩個(gè)變化：
頁(yè)面所有 HTTP 資源，會(huì)被替換為 HTTPS 地址再發(fā)起請(qǐng)求;
頁(yè)面所有站內(nèi)鏈接，點(diǎn)擊后會(huì)被替換為 HTTPS 地址再跳轉(zhuǎn);
跟其它所有 CSP 規(guī)則一樣，這個(gè)指令也有兩種方式來(lái)啟用，具體格式請(qǐng)參考上一節(jié)。需要注意的是 upgrade-insecure-requests 只替換協(xié)議部分，所以只適用于 HTTP/HTTPS 域名和路徑完全一致的場(chǎng)景。
合理使用 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)求無(wú)法到達(dá)服務(wù)器，從而構(gòu)成 HTTPS 降級(jí)劫持。
HSTS 基本使用
這個(gè)問(wèn)題可以通過(guò) HSTS(HTTP Strict Transport Security，RFC6797)來(lái)解決。HSTS 是一個(gè)響應(yīng)頭，格式如下：
Strict-Transport-Security: max-age=expireTime [; includeSubDomains] [; preload]
max-age，單位是秒，用來(lái)告訴瀏覽器在指定時(shí)間內(nèi)，這個(gè)網(wǎng)站必須通過(guò) HTTPS 協(xié)議來(lái)訪問(wèn)。也就是對(duì)于這個(gè)網(wǎng)站的 HTTP 地址，瀏覽器需要先在本地替換為 HTTPS 之后再發(fā)送請(qǐng)求。
includeSubDomains，可選參數(shù)，如果指定這個(gè)參數(shù)，表明這個(gè)網(wǎng)站所有子域名也必須通過(guò) HTTPS 協(xié)議來(lái)訪問(wèn)。
preload，可選參數(shù)，后面再介紹它的作用。
HSTS 這個(gè)響應(yīng)頭只能用于 HTTPS 響應(yīng);網(wǎng)站必須使用默認(rèn)的 443 端口;必須使用域名，不能是 IP。而且啟用 HSTS 之后，一旦網(wǎng)站證書(shū)錯(cuò)誤，用戶無(wú)法選擇忽略。
HSTS Preload List
可以看到 HSTS 可以很好的解決 HTTPS 降級(jí)攻擊，但是對(duì)于 HSTS 生效前的首次 HTTP 請(qǐng)求，依然無(wú)法避免被劫持。瀏覽器廠商們?yōu)榱私鉀Q這個(gè)問(wèn)題，提出了 HSTS Preload List 方案：內(nèi)置一份列表，對(duì)于列表中的域名，即使用戶之前沒(méi)有訪問(wèn)過(guò)，也會(huì)使用 HTTPS 協(xié)議;列表可以定期更新。
目前這個(gè) Preload List 由 Google Chrome 維護(hù)，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。如果要想把自己的域名加進(jìn)這個(gè)列表，首先需要滿足以下條件：
擁有合法的證書(shū)(如果使用 SHA-1 證書(shū)，過(guò)期時(shí)間必須早于 2016 年);
將所有 HTTP 流量重定向到 HTTPS;
確保所有子域名都啟用了 HTTPS;
輸出 HSTS 響應(yīng)頭：
max-age 不能低于 18 周(10886400 秒);
必須指定 includeSubdomains 參數(shù);
必須指定 preload 參數(shù);
即便滿足了上述所有條件，也不一定能進(jìn)入 HSTS Preload Lis。通過(guò) 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ì)被無(wú)限重定向，唯一的辦法是換新域名。
CDN 安全
對(duì)于大站來(lái)說(shuō)，全站遷移到 HTTPS 后還是得用 CDN，只是必須選擇支持 HTTPS 的 CDN 了。如果使用第三方 CDN，安全方面有一些需要考慮的地方。
合理使用 SRI
HTTPS 可以防止數(shù)據(jù)在傳輸中被篡改，合法的證書(shū)也可以起到驗(yàn)證服務(wù)器身份的作用，但是如果 CDN 服務(wù)器被入侵，導(dǎo)致靜態(tài)文件在服務(wù)器上被篡改，HTTPS 也無(wú)能為力。
W3C 的 SRI(Subresource Integrity)規(guī)范可以用來(lái)解決這個(gè)問(wèn)題。SRI 通過(guò)在頁(yè)面引用資源時(shí)指定資源的摘要簽名，來(lái)實(shí)現(xiàn)讓瀏覽器驗(yàn)證資源是否被篡改的目的。只要頁(yè)面不被篡改，SRI 策略就是可靠的。
SRI 并不是 HTTPS 專用，但如果主頁(yè)面被劫持，攻擊者可以輕松去掉資源摘要，從而失去瀏覽器的 SRI 校驗(yàn)機(jī)制。
了解 Keyless SSL
另外一個(gè)問(wèn)題是，在使用第三方 CDN 的 HTTPS 服務(wù)時(shí)，如果要使用自己的域名，需要把對(duì)應(yīng)的證書(shū)私鑰給第三方，這也是一件風(fēng)險(xiǎn)很高的事情。
CloudFlare 公司針對(duì)這種場(chǎng)景研發(fā)了 Keyless SSL 技術(shù)。你可以不把證書(shū)私鑰給第三方，改為提供一臺(tái)實(shí)時(shí)計(jì)算的 Key Server 即可。CDN 要用到私鑰時(shí)，通過(guò)加密通道將必要的參數(shù)傳給 Key Server，由 Key Server 算出結(jié)果并返回即可。整個(gè)過(guò)程中，私鑰都保管在自己的 Key Server 之中，不會(huì)暴露給第三方。
CloudFlare 的這套機(jī)制已經(jīng)開(kāi)源，如需了解詳情，可以查看他們官方博客的這篇文章：Keyless SSL: The Nitty Gritty Technical Details。
好了，本文先就寫(xiě)到這里，需要注意的是本文提到的 CSP、HSTS 以及 SRI 等策略都只有最新的瀏覽器才支持，詳細(xì)的支持度可以去 CanIUse 查。切換到 HTTPS 之后，在性能優(yōu)化上有很多新工作要做，這部分內(nèi)容我在之前的博客中寫(xiě)過(guò)很多，這里不再重復(fù)，只說(shuō)最重要的一點(diǎn)：既然都 HTTPS 了，趕緊上 HTTP/2 才是正道。
網(wǎng)站名稱：關(guān)于啟用HTTPS的一些經(jīng)驗(yàn)分享
轉(zhuǎn)載源于：http://fisionsoft.com.cn/article/chdocd.html
