http轉https後資源加載不顯示

【點擊領取】阿里雲代金券 | 阿里雲優惠券 |阿里雲優惠碼|雲服務器|阿里雲|阿里雲代金券 – 限時領取1888元阿里雲代金券

【3折購買ECS服務器入口】：https://promotion.aliyun.com/ntms/act/qwbk.html?userCode=t9686fzw

關於啓用 HTTPS 的一些經驗分享

      隨着國內網絡環境的持續惡化，各類篡改和劫持層出不窮，愈來愈多的網站選擇了全站 HTTPS。HTTPS 經過 TLS 層和證書機制提供了內容加密、身份認證和數據完整性三大功能，能夠有效防止數據被查看或篡改，以及防止中間人冒充。本文分享一些啓用 HTTPS 過程當中的經驗，重點是如何與一些新出的安全規範配合使用。至於 HTTPS 的部署及優化，以前寫過不少，本文不重複了。

理解 Mixed Content

HTTPS 網頁中加載的 HTTP 資源被稱之爲 Mixed Content(混合內容)，不一樣瀏覽器對 Mixed Content 有不同的處理規則。

早期的 IE

早期的 IE 在發現 Mixed Content 請求時，會彈出「是否只查看安全傳送的網頁內容?」這樣一個模態對話框，一旦用戶選擇「是」，全部 Mixed Content 資源都不會加載;選擇「否」，全部資源都加載。

比較新的 IE

比較新的 IE 將模態對話框改成頁面底部的提示條，沒有以前那麼幹擾用戶。並且默認會加載圖片類 Mixed Content，其它如 JavaScript、CSS 等資源仍是會根據用戶選擇來決定是否加載。

現代瀏覽器

現代瀏覽器(Chrome、Firefox、Safari、Microsoft Edge)，基本上都遵照了 W3C 的 Mixed Content 規範，將 Mixed Content 分爲Optionally-blockable 和 Blockable 兩類：

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

• 經過 標籤加載的圖片(包括 SVG 圖片);

• 經過 <img> 標籤加載的圖片（包括 SVG 圖片）；

• 經過 <video> / <audio> 和 <source> 標籤加載的視頻或音頻；

• 預讀的（Prefetched）資源；

預讀的(Prefetched)資源;

除此以外全部的 Mixed Content 都是 Blockable，瀏覽器必須禁止加載這類資源。因此現代瀏覽器中，對於 HTTPS 頁面中的 JavaScript、CSS 等 HTTP 資源，一概不加載，直接在控制檯打印錯誤信息。

移動瀏覽器

前面所說都是桌面瀏覽器的行爲，移動端狀況比較複雜，當前大部分移動瀏覽器默認都容許加載 Mixed Content。也就是說，對於移動瀏覽器來講，HTTPS 中的 HTTP 資源，不管是圖片仍是 JavaScript、CSS，默認都會加載。

通常選擇了全站 HTTPS，就要避免出現 Mixed Content，頁面全部資源請求都走 HTTPS 協議才能保證全部平臺全部瀏覽器下都沒有問題。

合理使用 CSP

CSP，全稱是 Content Security Policy，它有很是多的指令，用來實現各類各樣與頁面內容安全相關的功能。

block-all-mixed-content

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

經過 CSP 的 block-all-mixed-content 指令，可讓頁面進入對混合內容的嚴格檢測(Strict Mixed Content Checking)模式。在這種模式下，全部非 HTTPS 資源都不容許加載。跟其它全部 CSP 規則同樣，能夠經過如下兩種方式啓用這個指令：

HTTP 響應頭方式：

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

<meta>標籤方式：
<!--若是換成https後圖片或者其餘資源加載不上來，能夠加上這個meta-->

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


upgrade-insecure-requests

歷史悠久的大站在往 HTTPS 遷移的過程當中，工做量每每很是巨大，尤爲是將全部資源都替換爲 HTTPS 這一步，很容易產生疏漏。即便全部代碼都確認沒有問題，極可能某些從數據庫讀取的字段中還存在 HTTP 連接。

而經過 upgrade-insecure-requests 這個 CSP 指令，可讓瀏覽器幫忙作這個轉換。啓用這個策略後，有兩個變化：

• 頁面全部 HTTP 資源，會被替換爲 HTTPS 地址再發起請求;

• 頁面全部站內連接，點擊後會被替換爲 HTTPS 地址再跳轉;

      

      跟其它全部 CSP 規則同樣，這個指令也有兩種方式來啓用，具體格式請參考上一節。須要注意的是 upgrade-insecure-requests 只替換協議部分，因此只適用於 HTTP/HTTPS 域名和路徑徹底一致的場景。

合理使用 HSTS

      在網站全站 HTTPS 後，若是用戶手動敲入網站的 HTTP 地址，或者從其它地方點擊了網站的 HTTP 連接，依賴於服務端 301/302 跳轉才能使用 HTTPS 服務。而第一次的 HTTP 請求就有可能被劫持，致使請求沒法到達服務器，從而構成 HTTPS 降級劫持。

HSTS 基本使用

這個問題能夠經過 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 Preload List

能夠看到 HSTS 能夠很好的解決 HTTPS 降級攻擊，可是對於 HSTS 生效前的首次 HTTP 請求，依然沒法避免被劫持。瀏覽器廠商們爲了解決這個問題，提出了 HSTS Preload List 方案：內置一份列表，對於列表中的域名，即便用戶以前沒有訪問過，也會使用 HTTPS 協議;列表能夠按期更新。

目前這個 Preload List 由 Google Chrome 維護，Chrome、Firefox、Safari、IE 11 和 Microsoft Edge 都在使用。若是要想把本身的域名加進這個列表，首先須要知足如下條件：

• 擁有合法的證書(若是使用 SHA-1 證書，過時時間必須早於 2016 年);

• 將全部 HTTP 流量重定向到 HTTPS;

• 確保全部子域名都啓用了 HTTPS;

• 輸出 HSTS 響應頭：

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

• 必須指定 includeSubdomains 參數;

• 必須指定 preload 參數;

      即使知足了上述全部條件，也不必定能進入 HSTS Preload Lis。經過 Chrome 的 chrome://net-internals/#hsts 工具，能夠查詢某個網站是否在 Preload List 之中，還能夠手動把某個域名加到本機 Preload List。

      對於 HSTS 以及 HSTS Preload List，個人建議是隻要你不能確保永遠提供 HTTPS 服務，就不要啓用。由於一旦 HSTS 生效，你再想把網站重定向爲 HTTP，以前的老用戶會被無限重定向，惟一的辦法是換新域名。

CDN 安全

對於大站來講，全站遷移到 HTTPS 後仍是得用 CDN，只是必須選擇支持 HTTPS 的 CDN 了。若是使用第三方 CDN，安全方面有一些須要考慮的地方。

合理使用 SRI

HTTPS 能夠防止數據在傳輸中被篡改，合法的證書也能夠起到驗證服務器身份的做用，可是若是 CDN 服務器被入侵，致使靜態文件在服務器上被篡改，HTTPS 也無能爲力。

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

SRI 並非 HTTPS 專用，但若是主頁面被劫持，攻擊者能夠輕鬆去掉資源摘要，從而失去瀏覽器的 SRI 校驗機制。

瞭解 Keyless SSL

另一個問題是，在使用第三方 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 纔是正道。

【點擊領取】阿里雲代金券 | 阿里雲優惠券 |阿里雲優惠碼|雲服務器|阿里雲|阿里雲代金券 – 限時領取1888元阿里雲代金券

【3折購買ECS服務器入口】：https://promotion.aliyun.com/ntms/act/qwbk.html?userCode=t9686fzw