HTTP一般基于TCP協(xié)議，而HTTPS就是在這之間加了SSL/TLS協(xié)議，那么在TCP三次握手建立TCP連接后，就需要TLS握手建立SSL/TLS連接。

TLS握手-流程

基于RSA算法

（1）首先，客戶端向服務(wù)器發(fā)起加密通信請求-ClientHello請求，該請求包括 

    ① 生成隨機數(shù)（用于后續(xù)會話密鑰）；

    ② 客戶端支持的密碼套件列表，如RSA加密算法。

    ③ 客戶端支持的TLS協(xié)議版本；

（2）服務(wù)器收到后，作出響應-ServerHello，響應包括 

    ① 生成隨機數(shù)（用于后續(xù)會話密鑰）；

    ② 確認密碼套件列表；

     ③ 確認TLS協(xié)議版本；

同時發(fā)送Certificate信息，攜帶服務(wù)器的數(shù)字證書。

（3）客戶端收到響應后，先通過瀏覽器或OS中的CA公鑰確認數(shù)字證書真實合法，再取出數(shù)字證書中服務(wù)器的公鑰，使用其加密報文，發(fā)送往服務(wù)器：

    ① 一個隨機數(shù)；

    ② 傳遞后續(xù)通信都以【會話密鑰】加密通信的信息；

    ③ 客戶端握手結(jié)束通知；

    ④ 把之前所有發(fā)送數(shù)據(jù)做個摘要，并用【會話密鑰】加密，以保證可用和信息未被篡改過。

綜上的三個隨機數(shù)，通過前面雙方協(xié)商的加密算法，客戶端生成本次通信的【會話密鑰】

（4）服務(wù)器收到后，也會計算出本次通信的【會話密鑰】，然后向客戶端發(fā)送信息：

    ① 傳遞后續(xù)通信都以【會話密鑰】加密通信的信息；

    ② 服務(wù)器握手結(jié)束通知

    ③ 把之前所有發(fā)送數(shù)據(jù)做個摘要，并用【會話密鑰】加密，以保證可用和信息未被篡改過。

到這里TLS握手結(jié)束！

不，內(nèi)容還沒。

Extra Summary

RSA 和 ECDHE 算法區(qū)別

（1）ECDHE支持前向保密

（2）使用ECDHE可不需等最后一次TLS握手，就可以提前發(fā)送加密的HTTP數(shù)據(jù)，節(jié)省一個消息時間

（3）ECDHE在第2次握手，會出現(xiàn)服務(wù)器發(fā)出Server Key Exchange信息

以上RSA都達不到該效果。

Extra Question

第三次握手生成的【會話密鑰】是對稱的還是非對稱的？

考慮非對稱加密計算耗時量大，在HTTPS后續(xù)通信中使用的會話密鑰是對稱加密的。

前向保密是啥？

要求一個密鑰僅可訪問它所保護的數(shù)據(jù)；用來產(chǎn)生密鑰的元素一次一換，不能再產(chǎn)生其他密鑰；一個密鑰被破解，并不影響其他密鑰的安全性。

RSA為什么沒有前向保密性？

因為RSA每次對稱加密傳遞信息，都是基于公鑰加密，私鑰解密的，若干服務(wù)器私鑰被截取了，那么通信數(shù)據(jù)將輕而易舉地被解密。

ECDHE怎么做到前向保密？

關(guān)鍵在于客戶端服務(wù)端都生成一對公私鑰，且密鑰是實時生成的?？蛻舳朔?wù)器均為生成隨機數(shù)作為私鑰，據(jù)特殊公式算出各自的公鑰，然后雙方據(jù)持有的數(shù)據(jù)算出一個一樣隨機數(shù)用于后續(xù)對稱加密的密鑰。

到此這篇關(guān)于關(guān)于HTTPS的TSL握手的文章就介紹到這了,更多相關(guān)HTTPS的TSL握手內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論