客戶端與伺服器商議通訊金鑰的過程稱為tls握手,在握手階段,通訊內容雖然都是明文,但要保證最終商量的金鑰只有客戶端和伺服器知道,其他中間節點無從得知。
rsa握手過程說明:
// 生成master secret、以及從master secret中得到session key
mastersecret = generatemastersecret(r1, r2, premastersecret);
sessionkey = sessionkeyfrom(mastersecret);
第3步,premaster secret由客戶端使用公鑰加密後傳送,擁有私鑰的伺服器才能解密,所以最終只有客戶端與服務端能生成一致的master secret。圖中最後的session key是從master serect中派生出來用做對稱加密演算法的金鑰,握手階段結束後,通訊內容開始使用金鑰加密並簽名,確保有同樣知道金鑰的人才能解密內容,從而避免被竊聽和篡改的風險。
上述握手過程,在私鑰沒有洩漏且證書是可信的前提下,的確能避免通訊內容被竊聽或篡改。但可能存在一種情況:
通訊過程中,客戶端和伺服器之間的某個網路節點,將所有與伺服器相關通訊內容(tcp報文)在本地儲存乙份副本。在當時,由於不知道伺服器私鑰,無法破解被加密的premaster secret,從而不能解密通訊內容。很久以後的某天,伺服器的私鑰洩漏,導致加密的premaster secret被破解,通訊內容被解密,從而引發資訊洩漏。上述rsa握手過程,伺服器長期使用的私鑰洩漏會導致會話金鑰洩漏,從而導致使用會話金鑰加密的內容洩漏,即不具有前向安全性,下面介紹一種具有前向安全性的握手過程-dhe_rsa。
dhe_rsa握手過程依賴金鑰交換演算法-迪菲-赫爾曼金鑰交換(diffie–hellman key exchange,縮寫d-h),它是一種安全協議,可以讓雙方在完全沒有對方任何預先資訊的條件下通過不安全通道建立起乙個金鑰。
dh演算法簡要原理摘錄:dhe_rsa握手過程說明:
第4步後,雙方都能計算出premaster secret(gab),從而得到master secret以及session key。在這種方式下,伺服器私鑰只在第3步中簽名使用,哪怕洩漏,通訊雙方的秘密(a、b)也不會洩漏。
提到tls握手,大部分網上文章講的都是rsa方式,但現實中單純使用rsa握手過程的tls幾乎沒有,更多的應該是dhe_rsa或ecdhe_rsa,ecdhe_rsa原理與dhe_rsa區別不大,只是借助橢圓曲線(elliptic curve)減少計算量,提高效能。
tips: 通過chrome除錯視窗」security」標籤頁,可以看到握手過程的具體演算法,如:」a strong key exchange (ecdhe_rsa with p-256)」。
參考資源: - keyless ssl: the nitty gritty technical details部落格原
TLS協議握手過程分析
比如說bob有乙個 bob.cn,bob生成了一對公私鑰,其把個人身份及公鑰傳送給ca登記機構,ca登記機構驗證bob的身份,比如是個dv證書,就看證書所對應的網域名稱是不是你的,網域名稱是不是指向你的伺服器。登記機構驗證通過之後,就會把證書簽名申請傳送給ca機構,ca機構用其私鑰簽名之後,頒發證書...
TLS1 3 握手過程特性的整理
1 密碼協商 tls協議中,密碼協商的過程中client在clienthello中提供四種option 第一 client 支援的加密套件列表,密碼套件裡面中能出現client支援的aead演算法或者hkdf雜湊對,第二 supported group 的擴充套件和 key share的 擴充套件,...
TLS 握手優化詳解
隨著 http 2 的逐漸普及,以及國內網路環境越來越糟糕 運營商劫持和篡改 https 已經開始成為主流。https 在 tcp 和 http 之間增加了 tls transport layer security,傳輸層安全 提供了內容加密 身份認證和資料完整性三大功能,同時也給 web 效能優化...