1、為了弄清楚tls1.3的內部結構，覺得有必要將tls的整個結構從新整理一遍，方便後續在做握手協議的形式化分析的時候能夠不遺漏每個加密和認證的的環節。
tls1.3不**在協議內容上還是效能上都較之前的tls1.2版本有較大的改變，這裡首先概括性的表徵一下存在的差異：
更換了新的密碼套件，舊的密碼套件不在支援tls1.3，不提供鄉下相容的特性。新的密碼套件一共五個如下：
tls_aes_128_gcm_sha256
tls_aes_256_gcm_sha384
tls_chacha20_poly1305_sha256
tls_aes_128_ccm_sha256
tls_aes_128_ccm_8_sha256
同時新的密碼組定義不同，並未指定證書型別，秘鑰交換機制，客戶端在clienthello中提供了key_share，在主握手完成之後才能建立會話，在握手結束和會話建立之間存在間隙，在後續的會話恢復機制中可以產生影響。tls1.3連線中不能重新協商。秘鑰改變之後不再像對方傳送change_cipher_spec報文資訊。更多的握手資訊會被加密。更多型別的訊息可以實現擴充套件 ，
tls1.3徹底廢棄了rsa秘鑰交換演算法，之前的1.2的版本先計算mac再加密的方法存在很多安全隱患，不再允許對加密報文進行壓縮處理，tls1.3棄用的加密演算法如下：
sha-1 hash function 存在安全隱患
rc4 steam cipher ----在https中使用並不安全
des
3des
aes-cbc
md5 algorithm
various diffie-hellman groups
export-strength ciphers
rsa key transport --------不支援向前安全
lts1.3 僅採用aead類對稱加密演算法作為唯一的加密選項，同時引入了新的秘鑰協商機制 psk（presharedkey）
圖 tls在傳輸層保障資訊傳輸的安全示意圖
2、對tls1.3 握手協議的過程分析
從效率效能上講，tls1.2的版本 握手需要協商多個引數，握手過程需要往返兩個（rtt），相比較1.3的版本在引數，秘鑰，秘鑰套件和往返次數上都減少。所以tls1.3放棄了向後相容的方法，轉而向更加安全的措施。
3、恢復會話過程
tls1.3恢復會話可以直接傳送加密後的應用資料，不需要額外的tls握手，因此 「0-rtt」 握手就是指恢復加密傳輸層不需要二外的rtt，但是在第一次進行完全握手的時候，是需要 1-rtt的。但是存在的乙個缺點是，tls1.3 0-rtt現在無法保證向前安全（forwardsecrecy），如果當攻擊者通過某種手段可以獲取到 secession ticket key ,攻擊者就可以解密之前的加密資料。（注意：環節該問題的辦法： 可以通過設定 severconfiguration 和expiration date欄位，使得與session ticket key 相關的dh靜態引數在短時間內過期）
4、對tls1.2 協議形式化分析的改進
tls 1.2 握手示意圖
5、tls1.3 協議形式化描述
形式化描述之前對tls協議的握手過程要抽象出資訊互動過程
tls降級
tls1.3 握手協議過程
cn.bing.com tls1.3/quic 是怎樣做到 0-rtt 的
TLS 證書和秘鑰
建立 ca 配置檔案 mkdir root ssl cd root ssl cfssl print defaults config config.json cfssl print defaults csr csr.json 根據config.json檔案的格式建立如下的ca config.json檔...
TLS1 3 認證和秘鑰建立握手環節的分析
1 clienthello 中的引數 clienthello 在 extension中的擴充套件中包含 supported version supported groups signatureschemlist key shared 2 伺服器接收到之後需要選擇支援的最高版本協議，秘鑰分發演算法和選...
TLS協議握手過程分析
比如說bob有乙個 bob.cn，bob生成了一對公私鑰，其把個人身份及公鑰傳送給ca登記機構，ca登記機構驗證bob的身份，比如是個dv證書，就看證書所對應的網域名稱是不是你的，網域名稱是不是指向你的伺服器。登記機構驗證通過之後，就會把證書簽名申請傳送給ca機構，ca機構用其私鑰簽名之後，頒發證書...