網站部署 HTTPS 中須要作的事情

時間 2019-11-29

原文原文鏈接

這篇文章首發於個人我的網站：據說 - https://tasaid.com/，建議在個人我的網站閱讀，擁有更好的閱讀體驗。javascript

這篇文章與博客園和 Segmentfault 共享。html

前端開發QQ羣：377786580前端

這篇文章是基於我在遷移 https://tasaid.com 的時候，和在公司跟進部署 HTTPS 的一些經驗所編寫。收錄在《Said - 從 HTTP 到 HTTPS 》系列：java

部署到 HTTPS 會發生什麼

HTTP 協議和 HTTPS 協議是不兼容的，即 HTTPS 和 HTTP 是不可互相訪問的 (混合資源)，當 HTTPS 頁面中包含 HTTP 內容的時候，瀏覽器會向用戶拋出警告，這個網頁是加密的，可是卻包含不安全的元素，即混合資源 (Mixed Content)。git

隨着 chrome 的安全計劃，從此如下的 API 只能在安全環境中使用：github

Geolocation - 獲取用戶地理位置
Devicemotion / orientation - 設備方向和運動信息
Encrypted Media Extensions/EME - 加密媒體擴展
getUserMedia - 採集攝像頭/音頻/屏幕信息

實測中，當前獲取用戶地理位置 API navigator.geolocation.getCurrentPosition 已經只能在安全環境 (能夠理解爲 HTTPS 環境)中使用，在chrome下，非安全環境使用該 API 會顯示警告：web

getCurrentPosition() and watchPosition() no longer work on insecure origins. To use this feature, you should consider switching your application to a secure origin, such as HTTPS. See https://goo.gl/rStTGz for more details.

作哪些事

自適應協議資源路徑

傳統的資源路徑會通常會寫成絕對路徑和相對路徑：ajax

<img src="/static/bar.jpg"/>
<img src="http://tasaid.com/static/bar.jpg" />

絕對路徑的資源建議使用 // 語法讓它兼容 HTTP/HTTPS，//語法表示這個資源的訪問協議和當前頁面保持一致，若是當前頁面是 HTTPS 的，則會採用 HTTPS 協議訪問，若是是 HTTP 的，則使用 HTTP 協議訪問。chrome

<img src="//tasaid.com/static/bar.jpg" /><!--https://tasaid.com 中會訪問 https://tasaid.com/static/bar.jpg-->

異步請求

相對路徑下的異步請求沒有問題，絕對路徑的請求會有問題：shell

$.ajax('http://tasaid.com/user/get')

若是請求的 url 是兼容 HTTPS 的話，則能夠在 HTTPS 環境下使用 https:// 訪問，不然須要服務器作一個 HTTPS包裝跳轉，將原 url 的請求在本身的服務器作一層轉發，表單提交同理。

$.ajax('/httpsRedirect?url=http%3A%2F%2Flinkflys.com%2Fuser%2Fget')

iframe

iframe 只能是被嵌入的 url 也一樣支持 HTTPS，目前本人並未找到合適的方案。固然若是大家服務端真心 NB 的話也能夠像某大型搜索引擎同樣把須要內嵌 iframe 的站點抓到本身的服務器上。

HTTP嚴格傳輸安全協議

HTTP 嚴格傳輸安全協議（ HTTP Strict Transport Security，簡稱 HSTS ）是互聯網工程任務小組 (Internet Engineering Task Force，簡稱IETF) 發佈的互聯網安全策略，後者負責互聯網標準的開發和推進。網站能夠選擇使用 HSTS 策略，讓瀏覽器強制使用 HTTPS 協議訪問。

爲何要強制訪問呢？由於傳統的 HTTP 跳到 HTTPS 都依賴服務端 301/302 跳轉，例如訪問 http://tasaid.com 跳轉到 https://tasaid.com，而此次強制跳轉的通訊，是基於 HTTP 的，因此是可能被劫持的。

設置 HSTS 以後，瀏覽器會在本地替換協議爲 HTTPS 而後訪問服務器，而不用再依賴服務器跳轉，能夠更多的減小會話劫持攻擊。

HSTS 是一個響應頭，只能用於 HTTPS 響應，HTTP 環境下會忽略掉這個響應頭：

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

參數	釋義
max-age	指定的時間內 (單位是秒)，網站必須使用 HTTPS 協議來訪問
includeSubDomains	子域名也必須經過 HTTPS 協議來訪問
preload	讓瀏覽器由安全域名列表 (Preload List) 決定是否本地替換爲 HTTPS 請求

最後這個 preload 可能有點抽象，就是各大瀏覽器廠商 (Chrome/Firefox/IE/Safari/Edge) 共同維護的一個域名列表 (Preload List)，你能夠在這裏查詢，chrome 瀏覽器能夠直接在本地訪問 chrome://net-internals/#hsts 查詢。

設定 preload 參數，瀏覽器會根據當前網站知足的條件嘗試把網站加入這個域名列表 (Preload List)，其餘用戶再訪問這個網站的時候，若是這個網站域名存在於這個域名列表中，則自動啓用 HTTPS 訪問。

當用戶第一次訪問一個歷來沒訪問過的網站時，本地是沒有 HSTS 信息的，因此這個第一次的會話仍然是可能被劫持的。preload 就是爲了解決這個第一次會話劫持的問題的。

值得注意的是：一旦 HSTS 生效，在 max-age 指定的時間內，你再想把網站重定向爲 HTTP，以前的老用戶會被無限重定向。並且一旦網站證書錯誤，用戶沒法選擇忽略。

HSTS 是個大招，不要隨便開，否則技能冷卻時間的時間內。

結語

至此，《Said - 從 HTTP 到 HTTPS 》系列已經完結。當今互聯網上多數站點都陸續部署上或者正在部署 HTTPS，主要是由於 HTTPS 的安全性，以及當前主流的瀏覽器支持的 HTTP/2.0 須要 HTTPS 爲基礎。同時，百度也正在積極推進 HTTPS的收錄，而 google 也聲明瞭 HTTPS 會提高一點點的網站排名，但變化不會很明顯。

最簡單直觀的一個狀況，常見的流量劫持 —— 好比你的手機訪問某個網站，網頁中被某些不良的運營商劫持，強行插入了一些廣告：

web 發展迅猛，技術突飛猛進層出不窮。web 的安全性一樣是一場持久的攻防戰。而 HTTPS 的普及，爲 web 通訊構建了更加良好和安全的根基。儘快給你的網站也部上 HTTPS 吧，迎接更好的 web 時代。

這篇文章首發於個人我的網站：據說 - https://tasaid.com/，建議在個人我的網站閱讀，擁有更好的閱讀體驗。

這篇文章與博客園和 Segmentfault 共享。