在推動公司的全站 HTTPS + HSTS ，整理用到的知識，供以後查閱只用。
1. HTTP 背景知識
1.1 HTTP/0.9
單行協議，極其簡單。
請求：由單行指令構成，以唯一可用方法 GET 開頭，其後跟目標資源路徑
GET /mypage.html
響應：只包含響應文檔本身
<HTML>
這是一個非常簡單的HTML頁面
</HTML>
缺點：
- 只能傳輸 HTML 文件，無法傳輸其他類型的文件
- 無法判斷請求執行的結果
1.2 HTTP/1.0
構建可擴展性，HTTP/1.0 擴展了以下的內容，使之用途更廣泛：
- 發送信息中包含協議版本信息
- 增加狀態碼用於代表執行結果的成功或者失敗
- 引入 HTTP 頭的概念，對於請求和響應，允許傳輸元數據，使協議變得更靈活，擴展性更強
- 在 HTTP 頭中增加 Content-Type 類型，具備了傳輸其他類型文檔的能力
GET /mypage.html HTTP/1.0
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)
200 OK
Date: Tue, 15 Nov 1994 08:12:31 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: text/html
<HTML>
一個包含圖片的頁面
<IMG SRC="/myimage.gif">
</HTML>
缺點：
- 以上新擴展作爲一種嘗試出現，並未被引入到標準中
1.3 HTTP/1.1
標準化的協議，HTTP/1.0 多種不同的實現方式在實際運行中顯得十分混亂，HTTP/1.1 統一了標準並引入多項的改進內容：
- 默認長連接機制，節省多次 TCP 連接建立消耗的時間
- Pipelie 機制，允許第一個應答被完全發送之前就發送第二個請求
- Chunked 編碼傳輸
- Header 中引入 host
- 更詳細的 Cache 機制
一次完整的請求流程如下：
GET /en-US/docs/Glossary/Simple_header HTTP/1.1
Host: developer.mozilla.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://developer.mozilla.org/en-US/docs/Glossary/Simple_header
200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Wed, 20 Jul 2016 10:55:30 GMT
Etag: "547fa7e369ef56031dd3bff2ace9fc0832eb251a"
Keep-Alive: timeout=5, max=1000
Last-Modified: Tue, 19 Jul 2016 00:59:33 GMT
Server: Apache
Transfer-Encoding: chunked
Vary: Cookie, Accept-Encoding
(content)
注意
- HTTP 協議已經穩定使用超過 15 年，期間進行過兩次修訂RFC 2616 發佈於1999年6月，而另外兩個文檔 RFC 7230-RFC 7235 發佈於2014年6月
- 由於 HTTP 協議明文傳輸數據，基於安全的考慮，網景公司在 HTTP 的基礎上創建了一個額外的加密傳輸層：SSL。（SSL 1.0 沒有在公司以外發布過）
1.4 HTTP2
爲了更優異的表現，谷歌實踐了一個實驗性的協議 SPDY 協議旨在解決 HTTP/1.x 中存在的諸如連接複用、頭部冗餘等問題。SPDY 協議位於 HTTP 和 SSL 之間，屬於應用層協議，主要特性如下：
- 多路複用
- 請求優先級
- header 壓縮
- 服務端推送
SPDY 協議成爲了 HTTP/2 協議的基礎，可以看到 HTTP2 協議的很多特性跟 SPDY 協議提供的是有主體是重合的，但仍有少許差異點：
- HTTP/2 可以在 TCP 上直接使用，不像 SPDY 那樣必須在 TLS 上
- 添加了新的頭部壓縮算法 HPACK
- 添加了控制幀的種類
- 完善協議商討和 Server Push 的流程
2. HTTPS 出現的原因
2.1 原因
一種新技術的出現必然是因爲當前技術無法滿足當時社會的要求。從安全性的角度對比下 HTTP 和 HTTPS 協議：
| 安全性 | HTTP | HTTPS |
|---|---|---|
| 竊聽風險 | 信息明文傳遞，可被攔截竊聽 | 信息加密傳輸 |
| 篡改風險 | 被攔截下的信息可被篡改 | 信息校驗，接收方可通過校驗機制發現篡改行爲 |
| 僞裝風險 | 無法驗證對端的真實性 | 身份校驗 |
注意：
- 由於對數據進行加解密，決定了它天生比 HTTP 慢
2.2 HTTPS 協議組成
HTTPS 是在 HTTP 上建立 SSL/TLS 加密層，並對傳輸數據進行加密。
SSL/TLS 協議的基本過程是：
- 客戶端向服務端索要並驗證公鑰
- 雙方協商生產「對話密鑰」
- 雙方使用對話密鑰通信
步驟1、2 爲「握手階段」，完成的詳細過程見下圖：
注 「握手階段」所有的通信都是明文的
- （ClientHello）客戶端向服務端提供以下信息：
- 支持的協議版本
- 客戶端生成的隨機數，稍後用於生成「對話密鑰」
- 支持的加密方法
- 支持的壓縮方法
- （ServerHello）服務端迴應：
- 確認使用的加密通信協議版本
- 服務端生成的隨機數，稍後用於生成「對話密鑰」
- 確定使用的加密方法
- 服務器證書
- 客戶端迴應
- 一個隨機數。用於服務器公鑰加密，防止被竊聽
- 編碼改變通知，表示隨後的信息都將用雙方協商好的加密方法和密鑰發送
- 客戶端握手結束通知，表示客戶端的握手階段已經結束
- 服務器最後迴應
- 編碼改變通知，表示隨後的信息都將用雙方協商好的加密方法和密鑰發送
- 服務器握手結束通知，表示服務器的握手階段已經結束。
以上是從理論的層面上大致瞭解了下 SSL/TLS 做了什麼，後面文章會從實際使用中抓包分析真實過程。
3. HSTS 解決了什麼問題
3.1 概念
HSTS HTTP 嚴格傳輸安全，網站可以選擇使用 HSTS 策略，來讓瀏覽器強制使用 HTTPS 與網站進行通信，以減少回話被劫持的風險。
3.2 作用
抵禦 SSL 剝離攻擊， SSL剝離的實施方法是阻止瀏覽器與服務器創建HTTPS連接。它的前提是用戶很少直接在地址欄輸入https://，用戶總是通過點擊鏈接或3xx重定向，從HTTP頁面進入HTTPS頁面。所以攻擊者可以在用戶訪問HTTP頁面時替換所有https://開頭的鏈接爲http://，達到阻止HTTPS的目的。
HSTS 可以很大程度上解決 SSL 剝離攻擊，因爲只要瀏覽器與服務器創建過一次安全連接，之後瀏覽器會強制使用 HTTPS。
4. 待擴展知識點
- 長連接 & Pipelie 機制
- SPDY 協議
- SSL & TLS 協議實現
- HSTS demo