夢之痕bhl 2020-02-19 17:12:28
https://blog.csdn.net/laing92?t=1
簡介
最近在基於openssl1.0.2t源碼做開發，解密TLS1.2數據包，出現部分數據包解密失敗的問題，通過定位發現，不同的HTTPS服務器，在客戶端與服務端協商時部分擴展字段有差異，導致計算密鑰失敗或錯誤，其中關於“Extended Master Secret Extension”，如果協商時具有此擴展字段，計算主密鑰的方式會有所差異，具體對此字段的解釋，詳見RFC7627
TLS密鑰計算流程
無“Extended Master Secret”
在TLS中，每個會話都有一個“master_secret”，其計算方式如下：
master_secret = PRF（pre_master_secret，“主密碼”，
ClientHello.random + ServerHello.random）
[0..47];
1
2
3
其中“pre_master_secret”是某些密鑰交換的結果協議。例如，當握手使用RSA密碼套件時，該值是由客戶端均勻隨機生成的。
具有“Extended Master Secret”
全面協商擴展主密鑰后，握手時，“master_secret”的計算公式為：
master_secret = PRF（pre_master_secret，“擴展的主密鑰”，
session_hash）
[0..47];
1
2
3
其中的session_hash的定義如下：
session_hash = 哈希（handshake_messages）
1
其中“handshake_messages”是指所有已發送的握手消息，或者從ClientHello開始，直至並包ClientKeyExchange消息，包括以下內容的類型和長度字段握手消息。
三重握手
三重握手(Triple Handshake) (CVE-2014-1295)：攻擊者（A）分別與客戶端（C）和服務器（S）握手，協商出同一個主密鑰；之后令客戶端（C）和服務器（S）之間重新協商（renegotiation）或繼續（resumption）會話來握手。可攻破重新協商，TLS Exporter RFC5705和"tls-unique" RFC5929。
具體握手過程
C：客戶端。 A： 攻擊者 S：服務端
C向A發送“ ClientHello”，A將其轉發給S。
S向A發送“ ServerHello”，A將其轉發給C。
S將包含其證書鏈的“證書”發送給A。
A用自己的證書鏈替換它，並將其發送給C。
S向A發送“ ServerHelloDone”，A將其轉發給C。
C向A發送“ ClientKeyExchange”，其中包含
“ pre_master_secret”，已使用A的公鑰加密。解密
“ pre_master_secret”，使用S的公鑰對其重新加密，並且
將其發送給S。
C向A發送“完成”。A計算其“完成”
與S連接並將其發送給S。
S向A發送“完成”。A計算其“完成”
與C的連接，並將其發送給C。
通過以上方式，如果使用無“Extended Master Secret”擴展字段的計算方式將發現，從C->A和從A->S之間使用的會話密鑰是一樣的，這種叫做未知密鑰共享（unkown key-share（UKS））攻擊。當使用
master_secret = PRF（pre_master_secret，“擴展的主密鑰”，
session_hash）
[0..47];
1
2
3
的計算方式時，因為有session_hash，計算了所有協商消息的hash，如果中間攻擊者A對協商消息進行改動，則客戶端和服務端計算的hash值則不一樣，最后計算出的主密鑰也會不同。
參考資料
https://tools.ietf.org/html/rfc7627
https://forum.nginx.org/read.php?2,272703,272704
————————————————
版權聲明：本文為CSDN博主「夢之痕bhl」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/laing92/article/details/104396530