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協(xié)議的1.2版本。
下圖描述了在TCP/IP協(xié)議棧中TLS(各子協(xié)議）和HTTP的關(guān)系
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協(xié)議相比提供了
- 數(shù)據(jù)完整性：內(nèi)容傳輸經(jīng)過完整性校驗
- 數(shù)據(jù)隱私性：內(nèi)容經(jīng)過對稱加密，每個連接生成一個唯一的加密密鑰
- 身份認證：第三方無法偽造服務(wù)端（客戶端）身份
其中，數(shù)據(jù)完整性和隱私性由TLS Record Protocol保證，身份認證由TLS Handshaking Protocols實現(xiàn)。
總覽
使用RSA算法的SSL握手過程是這樣的：
Source: Keyless SSL: The Nitty Gritty Technical Details
- [明文] 客戶端發(fā)送隨機數(shù)client_random和支持的加密方式列表
- [明文] 服務(wù)器返回隨機數(shù)server_random，選擇的加密方式和服務(wù)器證書鏈
- [RSA] 客戶端驗證服務(wù)器證書，使用證書中的公鑰加密premaster secret發(fā)送給服務(wù)端
- 服務(wù)端使用私鑰解密premaster secret
- 兩端分別通過client_random，server_random和premaster secret生成master secret，用于對稱加密后續(xù)通信內(nèi)容
證書（Digital certificate）
那么什么是證書呢？
證書中包含什么信息：
- 證書信息：過期時間和序列號
- 所有者信息：姓名等
- 所有者公鑰
為什么服務(wù)端要發(fā)送證書給客戶端？
互聯(lián)網(wǎng)有太多的服務(wù)需要使用證書來驗證身份，以至于客戶端（操作系統(tǒng)或瀏覽器等）無法內(nèi)置所有證書，需要通過服務(wù)端將證書發(fā)送給客戶端。
客戶端為什么要驗證接收到的證書？
中間人攻擊
客戶端<------------攻擊者<------------服務(wù)端 偽造證書 攔截請求
客戶端如何驗證接收到的證書？
為了回答這個問題，需要引入數(shù)字簽名（Digital Signature）。
+---------------------+ | A digital signature | |(not to be confused | |with a digital | |certificate) | +---------+ +--------+ | is a mathematical |----哈希--->| 消息摘要 |---私鑰加密--->| 數(shù)字簽名 | |technique used | +---------+ +--------+ |to validate the | |authenticity and | |integrity of a | |message, software | |or digital document. | +---------------------+
將一段文本通過哈希（hash）和私鑰加密處理后生成數(shù)字簽名。
假設(shè)消息傳遞在Bob，Susan和Pat三人之間發(fā)生。Susan將消息連同數(shù)字簽名一起發(fā)送給Bob，Bob接收到消息后，可以這樣驗證接收到的消息就是Susan發(fā)送的
+---------------------+ | 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. | 比 +---------------------+ | | | +--------+ +---------+ | 數(shù)字簽名 |---公鑰解密--->| 消息摘要 | +--------+ +---------+
當然，這個前提是Bob知道Susan的公鑰。更重要的是，和消息本身一樣，公鑰不能在不安全的網(wǎng)絡(luò)中直接發(fā)送給Bob。
此時就引入了證書頒發(fā)機構(gòu)（Certificate Authority，CA），CA數(shù)量并不多，Bob客戶端內(nèi)置了所有受信任CA的證書。CA對Susan的公鑰（和其他信息）數(shù)字簽名后生成證書。
Susan將證書發(fā)送給Bob后，Bob通過CA證書的公鑰驗證證書簽名。
Bob信任CA，CA信任Susan 使得 Bob信任Susan，信任鏈（Chain Of Trust）就是這樣形成的。
事實上，Bob客戶端內(nèi)置的是CA的根證書（Root Certificate），HTTPS協(xié)議中服務(wù)器會發(fā)送證書鏈（Certificate Chain）給客戶端。
TLS協(xié)議
TLS協(xié)議包括TLS Record Protocol和TLS Handshake Protocol。總覽中的流程圖僅涉及到TLS Handshake Protocol。
TLS Record Protocol
在TLS協(xié)議中，有四種子協(xié)議運行于Record protocol之上
- Handshake protocol
- Alert protocol
- Change cipher spec protocol
- Application data protocol
Record protocol起到了這樣的作用
- 在發(fā)送端：將數(shù)據(jù)（Record）分段，壓縮，增加mac(Message Authentication Code)和加密
- 在接收端：將數(shù)據(jù)（Record）解密，驗證MAC，解壓并重組
值得一提的是，Record protocol提供了數(shù)據(jù)完整性和隱私性保證，但Record類型（type）和長度（length）是公開傳輸?shù)?/p>
Record Protocol有三個連接狀態(tài)（Connection State），連接狀態(tài)定義了壓縮，加密和MAC算法。所有的Record都是被當前狀態(tài)（Current State）確定的算法處理的。
TLS Handshake Protocol和Change Ciper Spec Protocol會導(dǎo)致Record Protocol狀態(tài)切換。
empty state -------------------> pending state ------------------> current state Handshake Protocol Change Cipher Spec
初始當前狀態(tài)（Current State）沒有指定加密，壓縮和MAC算法，因而在完成TLS Handshaking Protocols一系列動作之前，客戶端和服務(wù)端的數(shù)據(jù)都是明文傳輸?shù)模划擳LS完成握手過程后，客戶端和服務(wù)端確定了加密，壓縮和MAC算法及其參數(shù)，數(shù)據(jù)（Record）會通過指定算法處理。
其中，Record首先被加密，然后添加MAC（message authentication code）以保證數(shù)據(jù)完整性。
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
客戶端和服務(wù)端在握手hello消息中明文交換了client_random和server_random，使用RSA公鑰加密傳輸premaster secret，最后通過算法，客戶端和服務(wù)端分別計算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
小結(jié)
TLS Handshaking Protocols協(xié)商了TLS Record Protocol使用的算法和所需參數(shù)，并驗證了服務(wù)端身份；TLS Record Protocol在協(xié)商后保證應(yīng)用層數(shù)據(jù)的完整性和隱私性。
TLS Handshaking Protocol的核心是在公開信道上傳遞premaster secret。
Q&A
為什么傳輸內(nèi)容不直接使用非對稱加密？
性能
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.
攻擊者甚至可以直接丟棄雙方的數(shù)據(jù)包。
服務(wù)端如何驗證客戶端身份？
通過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算法參數(shù)是如何計算的
Handshaking Protocols使得客戶端和服務(wù)端交換了三個參數(shù)：client_random，server_random和master_secret，通過以下算法生成算法所需要的參數(shù)
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握手細節(jié)
