TLS握手：回顧1.2、迎接1.3
*本文原創作者：novsec，本文屬於FreeBuf原創獎勵計劃，未經許可禁止轉載
前言
HTTPS或者說SSL or TLS現在都是老生常談的東西了，為什麼還要寫這篇文章？
TLS 1.3 2018年釋出了，在看1.3的變動前有必要盤點下1.2的主要原理。另外，在我查詢握手細節的過程中發現很多部落格沒有把一些細節解釋清楚，主要是關於RSA和DH兩種金鑰協商協議所產生的一些細節上的區別，所以就有了這篇文章。
背景
SSL/TLS的解決的威脅：
1.資料洩露問題（Data Leak）：資訊加密，明文傳輸->密文傳輸； 2.資料篡改（Data tampering）：保證資料完整性， MAC, AE(after TLS 1.2)； 3.身份認證問題（spoofing/pretending）: 身份鑑別，數字證書。
HTTPS是什麼？可簡單的理解為HTTP over SSL。
SSL在設計上擁有可擴充套件性，不僅可以和HTTP結合作HTTPS，還可應用到很多其他的應用成協議，如FTP，Telnet等等。
歷史
1994 NetScape SSL 1.0 未釋出
1995 NetScape SSL 2.0
1996 SSL 3.0
1999 ISOC TLS 1.0（SSL 3.1）
2006 TLS 1.1 (SSL 3.2)
2008 TLS 1.2 (SSL 3.3)
2018 TLS 1.3
基礎知識
非對稱加密與對稱加密
簡單的理解，非對稱加密加解密使用不同的金鑰，對稱加解密使用相同的金鑰。
非對稱加密效能不如對稱加密。
非對稱加密私鑰要保持隱祕性，公鑰是公開的。私鑰加密，公鑰解密，叫簽名，可用來驗證身份，公鑰加密，私鑰解密，就是常見的加密傳輸資訊。
證書和簽名
簡單的說，CA將申請者的公鑰和資訊進行單向hash，生成摘要，然後CA用自己的私鑰對摘要進行簽名，最好將申請資訊(公鑰)和簽名整合生成證書。
Client(電腦和瀏覽器)內建了CA的根證書，根證書中包含CA公鑰，用CA公鑰解密證書，驗證證書，拿到摘要，然後按照同樣的HASH演算法生成摘要，將兩個摘要進行比對。
比較詳細的通俗解釋參考：一篇文章讀懂HTTPS及其背後的加密原理
金鑰交換(金鑰協商)及身份認證
SSL設計的最重要關鍵點就是金鑰交換。
單純用對稱加密，如果雙方不預先內建(PSK)，直接明文傳輸，機密性無法保證；加密傳輸，產生先有雞還是先有蛋的問題。
非對稱加密，主要有兩種方式：基於RSA的金鑰協商和基於DH的金鑰協商。
基於RSA的金鑰協商，引入了CA證書，可以解決資料洩露問題，CA證書解決身份認證問題。
基於DH的金鑰協商
，通訊雙方在完全沒有對方任何預先資訊的條件下通過不安全通道建立起一個金鑰
, 可以解決資料洩露問題，但是不能解決身份認證問題，會存在MITM攻擊。所以DH金鑰協商需要配合某種簽名演算法，如果沒有配合任何簽名演算法，稱為“DH-ANON”。此外，DH有很多種，DH本身依賴的是求離散對數問題困難性，而變種ECDH依賴求解橢圓曲線離散對數問題困難性。
SSL/TLS handshake
Overview
ClientServer ClientHello--------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* <--------ServerHelloDone Certificate* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished--------> [ChangeCipherSpec] <--------Finished Application Data<------->Application Data
Client Hello
包含：
client支援的協議版本
client random value
支援的加密套件列表
……, 例如：壓縮方法
Server Hello
包含：
確認使用的協議版本
server random value
選擇的加密套件
…
加密套件命名
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS
協議
ECDHE
金鑰交換協議
ECDSA
身份認證演算法
AES_128_GCM
對稱加密演算法
SHA256
MAC
Server Certificate(可選)
伺服器證書，這一步緊隨在Server Hello 之後，用來供客戶端驗證伺服器的身份。
Server Key Exchange Message(可選)
This message will be sent immediately after the server Certificate message (or the ServerHello message, if this is an anonymous negotiation).
這個步驟在Server Certificate後，按照RFC的說法，如果沒有Server Certificate，則在Server Hello之後。
該環節也是可選的。如果祕鑰協商演算法選用的是諸如RSA這類，則不會發送這部分資訊。RFC中的原文是
The ServerKeyExchange message is sent by the server only when the server Certificate message (if sent) does not contain enough data to allow the client to exchange a premaster secret.
可簡單的理解，如果是採用的非對稱加密演算法來進行祕鑰協商，可以通過公鑰加密傳送預主祕鑰的演算法不需要傳送這部分資訊。如RSA，而像DH及其變種這種金鑰交換演算法則需要通過這個環節傳送演算法所需的引數資訊。RFC中給出的DH引數結構參考：
struct {
opaque dh_p<1..2^16-1>;
opaque dh_g<1..2^16-1>;
opaque dh_Ys<1..2^16-1>;
} ServerDHParams;/* Ephemeral DH parameters */
dh_p
The prime modulus used for the Diffie-Hellman operation.
dh_g
The generator used for the Diffie-Hellman operation.
dh_Ys
Certificate Request(可選)
SS分為單向SSL(One-way SSL)和雙向SSL(Two-way SSL)，兩者區別主要是server端是否需要對client端進行身份驗證，常見場景如銀行提供的USB證書。雙向SSL，這部分資訊會在Server Key Exchange Message之後，單向SSL中，不會發送這部分資訊。
Server Hello Done
最後，server傳送這部分資訊來結束Sever hello， 等待客戶端迴應。
Client Certificate(可選)
這部分資訊是Server Hello Done 之後可以傳送的第一部分資訊，對應Certificate Request，也是可選部分。
Client Key Exchange Message
這部分資訊在Client Certificate之後傳送，在單向SSL中，在Server Hello Done後傳送。這部分資訊包含的最重要的一部分資訊是premaster secret(預主金鑰)，permaster的說法對應的是RSA，而在DH中對應的是DH exponent。
如果金鑰協商演算法是RSA， client會生成一個48位元組長的預主金鑰，然後用server的公鑰加密後傳送。
如果是DH演算法，則傳送client端生成的DH public value(dh_Yc)(請參考DH的數學原理), 此外如果之前的client certificate已經加密傳送了這個值，那這裡也會發送一個空值過去。
Certificate Verify(可選)
這部分資訊如果需要傳送，會跟隨在Client Key Exchange Message部分後。
Finished
在最後，傳送完ChangeCipherSpec，驗證了金鑰交換協議和身份認證成功後，會發送finish資訊。至此握手完成。
Master Secret
無論用哪種金鑰協商演算法，最後的主金鑰計算方法是相同的——TLS採用了一個PRF來做主金鑰的計算，PRF的引數就是之前的兩個隨機數加上預主金鑰。
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
Q & A
1.RSA的時候直接設定祕鑰不行麼，為什麼需要引入random；
2.SSL不信任每個client都能產生安全的隨機數，所以client和server各引入了一個random value；
3.三個random怎麼生成最終的祕鑰；
這個問題，很多帖子都沒有說明，最開始看的時候這是我的一個疑惑，其實RFC中給出了很明確的回答，參考握手中的部分。
4.為什麼不直接用非對稱加密通訊？
效能問題。因為非對稱加密的效能不如對稱加密，所以TLS的核心任務就是怎麼產生一個雙方共同的、祕密的、可信金鑰。
TLS 1.3
TLS 1.3 廢除了RSA 金鑰協商機制，保證PFS，PFS主要是為了避免回溯性破解，回溯性破解簡單的說就是如果在將來拿到了雙防的私鑰，能推匯出會話金鑰，就能解密通訊內容。而RSA的私鑰是穩定長期不變的，所以無法保證PFS，而DH可以強制每次生成隨機私鑰，之後強制銷燬，可以保證PFS，這種DH變種叫做DHE。
TLS1.3廢除了HMAC(SHA1, MD5),只採用AEAD驗證完整性，AEAD是AE的變種，可以在解密的同時驗證完整性
TLS1.3中，對稱加密演算法只保留了AES。壓縮特性廢除。
TLS1.3由於廢除了RSA的金鑰協商機制，所以握手協議的過程變動較大，比如DH演算法的引數1.2前的版本由server生成，整個握手過程2-RTT，而1.3中，DH引數直接在第一步由client生成，整個握手過程1-RTT。
詳細的TLS1.3握手過程參考RFC 8446 ，有空再寫。
*本文原創作者：novsec，本文屬於FreeBuf原創獎勵計劃，未經許可禁止轉載