關於HSTS安全協議的全面詳細解析

HTTP 嚴格傳輸安全（HSTS）是一種安全功能，web 服務器經過它來告訴瀏覽器僅用 HTTPS 來與之通信，而不是使用 HTTP。HSTS 是網站從 HTTP 到 HTTPS 中網站性能及安全優化很是重要的一個步驟，可以解決和兼容 HTTPS 中的一些不足之處。HSTS 在全站 HTTPS 下有一個較大的正向做用，推薦使用。

1、HSTS 是什麼？

國際互聯網工程組織 IETE 正在推行一種新的 Web安全協議HTTP Strict Transport Security（HSTS）。採用 HSTS 協議的網站將保證瀏覽器始終鏈接到該網站的 HTTPS 加密版本，不須要用戶手動在 URL 地址欄中輸入加密地址。該協議將幫助網站採用全局加密，用戶看到的就是該網站的安全版本。
.
HSTS 的做用是強制客戶端（如瀏覽器）使用 HTTPS 與服務器建立鏈接。服務器開啓 HSTS 的方法是，當客戶端經過 HTTPS 發出請求時，在服務器返回的超文本傳輸協議響應頭中包含 Strict-Transport-Security 字段。非加密傳輸時設置的 HSTS 字段無效。
.
HTTPS 最典型的用戶訪問過程
一般咱們訪問一個網站時，通常在瀏覽器中只輸入網站地址，而不輸入協議名。好比訪問子凡的淚雪博客，若是直接輸入網址 https://leoheng.com 或leoheng.com 時，這就給了中間人***的一個機會，重定向會可能會被破壞，從而定向到一個惡意站點而不是應該訪問的加密頁面。HTTP 嚴格傳輸安全（HSTS）功能使 Web 服務器告知瀏覽器毫不使用 HTTP 訪問，在瀏覽器端自動將全部到該站點的 HTTP 訪問替換爲 HTTPS 訪問。
即便你打開網站看到的是全站 HTTPS 狀態 ，你是由於咱們在服務器上作過301/302 跳轉到 https://leoheng.com/ 這個地址的， HTTPS 網站的作法是對用戶的 HTTP 訪問作 302 跳轉到 HTTPS，並從新建連。（訪問過程以下圖）

那麼問題也就來了，在這個跳轉的過程當中就有兩個不足之處：

• 整個通訊過程當中的前兩個 RT 是沒有意義的；
• 使用了不安全的 HTTP 通訊，若是是在提交敏感數據呢。
  .
  HSTS 的出現就是解決這些問題的。HSTS 的做用除了節省 HTTPS 通訊 RT 和強制使用 HTTPS ，還包括：
  阻止基於SSLStrip 的中間人***；
  萬一證書有錯誤，則顯示錯誤，用戶不能迴避警告。
  HSTS 的工做機制可描述以下：服務器端配置支持 HSTS 後，會在給瀏覽器返回的 HTTP 首部中攜帶 HSTS 字段。瀏覽器獲取到該信息後，會將全部 HTTP 訪問請求在內部作307跳轉到 HTTPS，而無需任何網絡過程，從而提升了兼容性，這個機制對於不支持 HTTPS 的搜索引擎來講也是很是友好的作法。
  .
  目前大部分瀏覽器對 HSTS 的支持已經至關完美，具體各瀏覽器和版本的支持狀況能夠在http://leoheng.com/#search=HSTS上查看。 可是 HSTS 是有缺陷的，第一次訪問網站的客戶端，HSTS 並不工做。 要解決這個問題，就要了解咱們下面要講解的 HSTS preload list。

HSTS preload list 是什麼？
HSTS preload list 是 Chrome 瀏覽器中的 HSTS 預載入列表，在該列表中的網站，使用 Chrome 瀏覽器訪問時，會自動轉換成 HTTPS。Firefox、Safari、Edge 瀏覽器也會採用這個列表。
.
加入 HSTS preload list 所需條件：

• 有效的證書；
• 將全部 HTTP 流量重定向到 HTTPS；
• 確保全部子域名啓用 HTTPS，特別是 www 子域名。
• 同時輸出的 HSTS 響應頭部須要知足如下條件：
• max-age 至少須要 18 周，10886400 秒
• 必須指定 includeSubdomains 參數
• 必須支持 preload 參數
  一個典型知足 HSTS preload list 的響應頭部爲：Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  從申請到審覈經過，時間在幾天到幾周不等。值得一提的是，從審覈經過到正式加入到 Chrome 的 stable release 版本中還須要一段時間，由於要通過 canary、dev、beta 以及 stable progression。
  .
  HSTS 的優點及必要性
  簡單說就是強制客戶端使用 HTTPS 訪問頁面。有效避免了中間人對 80 端口的劫持。可是這裏存在一個問題：若是用戶在劫持狀態，而且沒有訪問過源服務器，那麼源服務器是沒有辦法給客戶端種下 Strict-Transport-Security 響應頭的（都被中間人擋下來了）。
  啓用 HSTS 不只僅能夠有效防範中間人*，同時也爲瀏覽器節省來一次 302/301 的跳轉請求，收益仍是很高的。咱們的不少頁面，難以免地出現 http 的連接，好比 help 中的連接、運營填寫的連接等，這些連接的請求都會經歷一次 302，對於用戶也是同樣，收藏夾中的連接保存的可能也是 http 的。
  .
  307 狀態碼
  在 GET、HEAD 這些冪等的請求方式上，30二、30三、307 沒啥區別，而對於 POST 就不一樣了，大部分瀏覽器 都會 302 會將 POST 請求轉爲 GET，而 303 是規範強制規定將 POST 轉爲 GET 請求，請求地址爲 header 頭中的 Location，307 則不同，規範要求瀏覽器繼續向 Location 的地址 POST 內容。
  而在 HSTS 中，307 能夠被緩存，緩存時間根據 max-age 而定，通常建議緩存 1 年甚至更長。
  .
  HSTS 存在的坑**
  1. 純 IP 的請求，HSTS 無法處理，好比 http://3.3.3.1 ， 即使響應頭中設置了 STS，瀏覽器也不會理會（未測試）
  2. HSTS 只能在 80 和 443 端口之間切換，若是服務是 8080 端口，即使設置了 STS，也無效（未測試）
  3. 若是瀏覽器證書錯誤，通常狀況會提醒存在安全風險，然是依然給一個連接進入目標頁，而 HSTS 則沒有目標頁入口，因此一旦證書配置錯誤，就是很大的故障了
  4. 若是服務器的 HTTPS 沒有配置好就開啓了 STS 的響應頭，而且還設置了很長的過時時間，那麼在你服務器 HTTPS 配置好以前，用戶都是沒辦法鏈接到你的服務器的，除非 max-age 過時了。
  5. HSTS 能讓你的網站在 ssllab 上到 A+

寫在最後：HSTS 在全站 HTTPS 下有一個較大的正向做用，推薦使用。