理解 HTTPS 的工作原理
HTTPS，也稱作HTTP over TLS。TLS的前身是SSL，TLS 1.0通常被標示為SSL 3.1，TLS 1.1為SSL 3.2，TLS 1.2為SSL 3.3。本文著重描述TLS協議的1.2版本。
下圖描述了在TCP/IP協議棧中TLS(各子協議)和HTTP的關系
Credit: Kaushal Kumar Panday From: SSL Handshake and HTTPS Bindings on IIS
其中Handshake protocol，Change Ciper Spec protocol和Alert protocol組成了SSL Handshaking Protocols。
HTTPS和HTTP協議相比提供了：
- 數據完整性：內容傳輸經過完整性校驗
- 數據隱私性：內容經過對稱加密，每個連接生成一個唯一的加密密鑰
- 身份認證：第三方無法偽造服務端(客戶端)身份
其中，數據完整性和隱私性由TLS Record Protocol保證，身份認證由TLS Handshaking Protocols實現。
總覽
使用RSA算法的SSL握手過程是這樣的：
Source: Keyless SSL: The Nitty Gritty Technical Details
- [明文] 客戶端發送隨機數client_random和支持的加密方式列表
- [明文] 服務器返回隨機數server_random，選擇的加密方式和服務器證書鏈
- [RSA] 客戶端驗證服務器證書，使用證書中的公鑰加密premaster secret發送給服務端
- 服務端使用私鑰解密premaster secret
- 兩端分別通過client_random，server_random和premaster secret生成master secret，用于對稱加密后續通信內容
證書(Digital certificate)
那么什么是證書呢?
證書中包含什么信息：
- 證書信息：過期時間和序列號
- 所有者信息：姓名等
- 所有者公鑰
為什么服務端要發送證書給客戶端?
互聯網有太多的服務需要使用證書來驗證身份，以至于客戶端(操作系統或瀏覽器等)無法內置所有證書，需要通過服務端將證書發送給客戶端。
客戶端為什么要驗證接收到的證書?
- 客戶端<------------攻擊者<------------服務端
- 偽造證書 攔截請求
客戶端如何驗證接收到的證書?
為了回答這個問題，需要引入數字簽名(Digital Signature)。
- +---------------------+
- | A digital signature |
- |(not to be confused |
- |with a digital |
- |certificate) | +---------+ +--------+
- | is a mathematical |----哈希--->| 消息摘要 |---私鑰加密--->| 數字簽名 |
- |technique used | +---------+ +--------+
- |to validate the |
- |authenticity and |
- |integrity of a |
- |message, software |
- |or digital document. |
- +---------------------+
將一段文本通過哈希(hash)和私鑰加密處理后生成數字簽名。
假設消息傳遞在Bob，Susan和Pat三人之間發生。Susan將消息連同數字簽名一起發送給Bob，Bob接收到消息后，可以這樣驗證接收到的消息就是Susan發送的
- +---------------------+
- | A digital signature |
- |(not to be confused |
- |with a digital |
- |certificate) | +---------+
- | is a mathematical |----哈希--->| 消息摘要 |
- |technique used | +---------+
- |to validate the | |
- |authenticity and | |
- |integrity of a | |
- |message, software | 對
- |or digital document. | 比
- +---------------------+ |
- |
- |
- +--------+ +---------+
- | 數字簽名 |---公鑰解密--->| 消息摘要 |
- +--------+ +---------+
當然，這個前提是Bob知道Susan的公鑰。更重要的是，和消息本身一樣，公鑰不能在不安全的網絡中直接發送給Bob。
此時就引入了證書頒發機構(Certificate Authority，CA)，CA數量并不多，Bob客戶端內置了所有受信任CA的證書。CA對Susan的公鑰(和其他信息)數字簽名后生成證書。
Susan將證書發送給Bob后，Bob通過CA證書的公鑰驗證證書簽名。
Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任鏈(Chain Of Trust)就是這樣形成的。
事實上，Bob客戶端內置的是CA的根證書(Root Certificate)，HTTPS協議中服務器會發送證書鏈(Certificate Chain)給客戶端。
TLS協議
TLS協議包括TLS Record Protocol和TLS Handshake Protocol?？傆[中的流程圖僅涉及到TLS Handshake Protocol。
TLS Record Protocol
在TLS協議中，有四種子協議運行于Record protocol之上
- Handshake protocol
- Alert protocol
- Change cipher spec protocol
- Application data protocol
Record protocol起到了這樣的作用
- 在發送端：將數據(Record)分段，壓縮，增加MAC(Message Authentication Code)和加密
- 在接收端：將數據(Record)解密，驗證MAC，解壓并重組
值得一提的是，Record protocol提供了數據完整性和隱私性保證，但Record類型(type)和長度(length)是公開傳輸的
Record Protocol有三個連接狀態(Connection State)，連接狀態定義了壓縮，加密和MAC算法。所有的Record都是被當前狀態(Current State)確定的算法處理的。
TLS Handshake Protocol和Change Ciper Spec Protocol會導致Record Protocol狀態切換。
- empty state -------------------> pending state ------------------> current state
- Handshake Protocol Change Cipher Spec
初始當前狀態(Current State)沒有指定加密，壓縮和MAC算法，因而在完成TLS Handshaking Protocols一系列動作之前，客戶端和服務端的數據都是明文傳輸的;當TLS完成握手過程后，客戶端和服務端確定了加密，壓縮和MAC算法及其參數，數據(Record)會通過指定算法處理。
其中，Record首先被加密，然后添加MAC(message authentication code)以保證數據完整性。
TLS Handshaking Protocols
Handshakeing protocols包括Alert Protocol，Change Ciper Spec Protocol和Handshake protocol。本文不會詳細介紹Alert Protocol和Change Ciper Spec Protocol。
使用RSA算法的握手過程是這樣的(已在總覽中提到)
Source: Keyless SSL: The Nitty Gritty Technical Details
客戶端和服務端在握手hello消息中明文交換了client_random和server_random，使用RSA公鑰加密傳輸premaster secret，最后通過算法，客戶端和服務端分別計算master secret。其中，不直接使用premaster secret的原因是：保證secret的隨機性不受任意一方的影響。
除了使用RSA算法在公共信道交換密鑰，還可以通過Diffie–Hellman算法。Diffie–Hellman算法的原理是這樣的：
- By Original schema: A.J. Han Vinck, University of Duisburg-Essen SVG version: Flugaal [Public domain], via Wikimedia Commons
使用Diffie–Hellman算法交換premaster secret的流程
Source: Keyless SSL: The Nitty Gritty Technical Details
小結
TLS Handshaking Protocols協商了TLS Record Protocol使用的算法和所需參數，并驗證了服務端身份;TLS Record Protocol在協商后保證應用層數據的完整性和隱私性。
TLS Handshaking Protocol的核心是在公開信道上傳遞premaster secret。
Q&A
為什么傳輸內容不直接使用非對稱加密?
性能
HTTPS能保證正常連接?
no
There are a number of ways in which a man-in-the-middle attacker can attempt to make two entities drop down to the least secure method they support.
攻擊者甚至可以直接丟棄雙方的數據包。
服務端如何驗證客戶端身份?
通過Client Certificate
This message conveys the client’s certificate chain to the server; the server will use it when verifying the CertificateVerify message (when the client authentication is based on signing) or calculating thepremaster secret (for non-ephemeral Diffie- Hellman). The certificate MUST be appropriate for the negotiated cipher suite’s key exchange algorithm, and any negotiated extensions.
Alert protocol有什么作用?
Closure Alerts：防止Truncation Attack
In a truncation attack, an attacker inserts into a message a TCP code indicating the message has finished, thus preventing the recipient picking up the rest of the message. To prevent this, SSL from version v3 onward has a closing handshake, so the recipient knows the message has not ended until this has been performed.
Error Alerts：錯誤處理
master secret是如何計算的
- master_secret = PRF(pre_master_secret, "master secret",
- ClientHello.random + ServerHello.random)
- [0..47];
加密，壓縮和MAC算法參數是如何計算的
Handshaking Protocols使得客戶端和服務端交換了三個參數：client_random，server_random和master_secret，通過以下算法生成算法所需要的參數
- To generate the key material, compute
- key_block = PRF(SecurityParameters.master_secret,
- "key expansion",
- SecurityParameters.`server_random ` +
- SecurityParameters.`client_random`);
- until enough output has been generated. Then, the key_block is
- partitioned as follows:
- client_write_MAC_key[SecurityParameters.mac_key_length]
- server_write_MAC_key[SecurityParameters.mac_key_length]
- client_write_key[SecurityParameters.enc_key_length]
- server_write_key[SecurityParameters.enc_key_length]
- client_write_IV[SecurityParameters.fixed_iv_length]
- server_write_IV[SecurityParameters.fixed_iv_length]
The master secret is expanded into a sequence of secure bytes, which is then split to a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key
使用Diffie-Hellman算法的TLS握手細節
