# Https
###### tags: `Secure` `Https`
## 流程
在建立完TCP連線後(Three-Way Handshake)，SSL handshake就開始了。
SSL 通訊過程中的步驟，被歸類成以下三個階段 ：
1. **Authentication (Handshake)** :
使用 Public/Asymmetric Key Encryption Algorithms.
2. **Key Exchange (Handshake)**:
使用 Public/Asymmetric Key Encryption Algorithms/Key Exchange protocol.
3. **Encrypted Data Transfer (Record)**:
使用 Private/Symmetric Key Encryption Algorithms

其中, 前兩階段又合稱為”SSL Handshake protocol”, 其目的是要認證 server 並且決定要用來進行實際的資料傳輸之對稱式金鑰, 第三步稱為”SSL Record protocol”, 用意在於傳輸加密資料。

**Authentication Phase**
**Step 1:**
Client 送出了一個 client hello 至server端. 這個 hello 訊息包含了一些細節, 如其所支持的 SSL 之最高版本 (這個版號可以是sslv3, tls1.0, tls1.1, tls1.2.). 再來, 也包含了在這個 SSL 版本之下其所支援的所有 cipher suites (密碼套件). 所謂的 cipher suit 就是一種協議與演算法的組合, 這個組合會被用在該 SSL session中.
以下是一個 cipher suite 的範例, 可以看成是一個由六個部分所組成的字串:

TLS_ECDHE_RSA_WITH_AES256_CBC_SHA

1. TLS : 所使用的傳輸層協議: 其它如 SSL (當然現在幾乎都是TLS了)
2. ECDHE : 會話金鑰(session key)的交換演算法: 其它如 RSA, DH, DHE, 用於決定 client / server 之間在 handshake時要如何進行身份驗證
3. RSA : 憑證的 PKI 類型: 其它如 DSS(Digital Signature Standard)
4. AES256 : 在對實際資料進行加密時所使用的對稱式密碼演算法(批次加密演算法): 其它如 RC4, 3DES, CAMELLIA, ARIA, DES40
5. CBC : 對稱式密碼演算法的操作模式: 其它如 CCM, GCM
6. SHA : 確保資料完整性的雜湊演算法(訊息鑑別碼演算法): 其它如MD5, SHA2

除了上述的部分, client hello 也包含了要使用哪種資料壓縮方法. 若之後的金鑰交換階段要採用RSA演算法, 則還會再生成一個隨機數, 用於金鑰交換階段生成對稱式金鑰用 (client’s random number).

**Step 2:**
當收到client hello之後, server 就會準備好一個 server hello 訊息並且將之送回去給 client. 這個訊息中包含了 SSL version, cipher suite, server 支援且同意的資料壓縮方法以及最重要的: Server 的 SSL certificate. 若之後的金鑰交換階段要採用RSA演算法, 則還會再生成一個隨機數, 用於金鑰交換階段生成對稱式金鑰用 (server’s random number).

Server hello 還有一個選填的欄位, 其作用是用來提醒 client 是否需要將 client 的憑證送回給 server. Client certificate 在公開網路中是很罕見的, 但在一些要求高安全性的環境中, 如國防通訊等, 這時候 server 就應該要認證 client.

在 server hello的尾聲, 會有一個 server hello done 的指令來表示這段資訊的結束.

**Step 3 :**
接下來, 就輪到 client 驗證 server 的 SSL 憑證了, 瀏覽器會去看是哪個 CA 簽了這個憑證的, 然後去把這個 CA 的 public key 從瀏覽器的 cert store 中讀出來並且用來驗證憑證中的數位簽章(之前的文章提過, 此處憑證中的數位簽章是 CA 的數位簽章, 就是將網站擁有者的 public key 透過 CA 的 private key 加密後的結果). 若從數位簽章中解出來的 public key 跟 server 同時送來的 public key 是不吻合的, 就表示簽章是不合法的, 瀏覽器就會產生警告. 通常一個不合法的憑證就代表了可能會有 MITM 攻擊的出現.

**Step 4 : **
若 server 有在 server hello 中要求 client 憑證的話, 就會有這一步的出現, 這時候 client 會將其憑證送給 server.

**Step 5 : **
接續前一步驟, server 會在這步驗證 client 的憑證.

到這裡為止, 就算是完成 SSL handshake 裡的 authentication 階段了.

**Key Exchange Phase**
這階段最重要的, 就是要產生一個用來在 client 以及 server 之間當作 shared secret 的對稱式金鑰. 要生出這個金鑰有很多方法, 其中, RSA 與 Deffie Hellman 以算法是最常見的金鑰交換演算法.

**RSA Key Exchange
**首先來看一下透過 RSA 演算法取得金鑰的方式 (這曾經是最常使用的方式之一):

一開始 client 會先生成一個 random number, 並使用 server 的公鑰(包含在 server 寄過來的 SSL 憑證中的一部分) 來加密此 random number (這樣這個 random number 才不會被竊聽), 以作為所謂的 pre-master secret (a.k.a. PMS), 然後把這個 PMS 寄給 sever 端. 在資料傳輸階段進行加密的對稱式金鑰( master secret )就是透過 pre-master secret 以及前面提過的由 client/server 各自提供的 random numbers 所計算出來的. 這個計算的動作不管是在 client 還是 server 都會執行, 以取得共同的 shared key, 因此, master secret 是不會透過網路來傳輸的(因為兩邊都可以擁有計算出金鑰所需的所有元素). 事實上, master secret 是一個由三部分所組成的函數:

1. Pre-master secret
2. Client’s random number
3. Server’s random number

那為什麼要三個數字呢? 因為這樣生成的 secret 亂度才會夠高, 由於 SSL 憑證是靜態的, 所以導入適當的隨機因素以確保協商出來的 secret 之隨機性是有必要的. 在以 RSA 實作金鑰交換的流程中, pre-master secret 本身就是一個隨機數, 再加上在之前的 hello 過程中, 由 client/server 各別生出的隨機數, 就導出了一個具有足夠隨機性的 secret 了.

使用 RSA 作為金鑰交換機制的實作演算法有一個缺點就是其本身是不具有 Perfect Forward Secrecy (PFS)的. PFS 是安全通訊協定中的一個特性, 其可以保護過往的 session 不會在未來的時間點被破解(不論是 secret key 還是 password). 在使用 RSA 的場合下, 一旦攻擊者查出了 shared secret 之後, 其就有辦法解密所有的 SSL 通訊. 這也是為什麼現在比較常見的金鑰交換機制會改用 Deffie hellman 演算法(DH)來實作的原因之一, 因為
DH 演算法不需要像 RSA 一樣進行 PMS key 的交換. Client 以及 server 可以各自獨立地計算出PMS, 這也意味了在 DH 演算法中, 不需要利用 server 的 public key 來進行金鑰交換.

**Diffie — Hellman Key Exchange
**有時也簡稱為DH演算法, 是一種安全協定. **其可以讓雙方在完全沒有對方任何預先資訊的條件下通過public channel (unsafe channel) 建立起一個金鑰.** 這個金鑰可以在後續的通訊中作為對稱金鑰來加密通訊內容. 雖然DH演算法本身是一個匿名(無認證)的金鑰交換協定, 它卻是很多認證協定的基礎, 並且被用來提供傳輸層安全協定的短暫模式中的完備的前向安全性 (forward secrecy) .

講白話一點, DH演算法就是在教你**如何”安全地”告訴對方密碼而不用擔心密碼被竊聽**. 通過在public channel交換一個資訊, 就可以建立一個可用於在public channel上安全通信的shared secret.

ps 詳細在wiki

## Encrypted Data Transfer (Record) Phase

加密資料傳輸階段, 通常又稱為 record protocol, 這個階段負責處理瀏覽器與網站之間的實際資料傳輸. 要傳輸的資料會透過前面提到的 master secret 以對稱式金鑰加密演算法進行加密. Record protocol 主要會確保兩個特性: 保密性 (confidentiality) 以及完整性 (integrity). 保密性是透過對稱式加密來確保, 完整性則是透過 MAC (Message Authentication Code) 來確保, MAC 值是透過雜湊演算法以及 secret key 計算得來的.


1. 要被傳輸的資料會被分成多個區塊, 稱為 fragments.
2. 每一個 fragment 都會經由壓縮演算法來進行壓縮.
3. MAC 值被計算出來, 並且被附加在已經壓縮的 fragment 之後.
4. 使用 secret key 對 fragment 進行加密.
5. 在加密過後的 fragment 之前加上 SSL Record Header.

以上就是 SSL Record Protocol 的詳細流程, 其中, 關於最後一步的 SSL Record Header, 大概有以下內容:

- Byte 0 = SSL record type
SSL3_RT_CHANGE_CIPHER_SPEC 20 (x’14')
SSL3_RT_ALERT 21 (x’15')
SSL3_RT_HANDSHAKE 22 (x’16')
SSL3_RT_APPLICATION_DATA 23 (x’17')
- Bytes 1–2 = SSL version (major/minor)
SSL3_VERSION x’0300'
TLS1_VERSION x’0301'
- Bytes 3–4 = Length of data in the record (excluding the header itself). Max is 16384 (16K).
- Byte 5 = Handshake type
SSL3_MT_HELLO_REQUEST 0 (x’00')
SSL3_MT_CLIENT_HELLO 1 (x’01')
SSL3_MT_SERVER_HELLO 2 (x’02')
SSL3_MT_CERTIFICATE 11 (x’0B’)
SSL3_MT_SERVER_KEY_EXCHANGE 12 (x’0C’)
SSL3_MT_CERTIFICATE_REQUEST 13 (x’0D’)
SSL3_MT_SERVER_DONE 14 (x’0E’)
SSL3_MT_CERTIFICATE_VERIFY 15 (x’0F’)
SSL3_MT_CLIENT_KEY_EXCHANGE 16 (x’10')
SSL3_MT_FINISHED 20 (x’14')
- Bytes 6–8 = Length of data to follow in this record
- Bytes 9-n = Command-specific data

## HTTPS的本質

這篇文章已經把 HTTPS 通訊的整個流程大概描述了一次, 所以 HTTPS 的本質到底是什麼呢? 我們可以這樣解讀: HTTPS 就是在 HTTPS connection 發起之前, 先透過 SSL/TLS 協議來協調 client/server, 使兩邊都可以產生出一個基於對稱式金鑰加密演算法的 secret. 有了這個 secret, 就可以在普通的 HTTP 協議中傳輸經過 secret 加密過後的資料內容. 因為這個 secret 是安全的, 所以被加密的內容也就是安全的了.

from https://reurl.cc/GVvQLv