三次握手
客戶端向服務(wù)器發(fā)送SYN請求
服務(wù)器發(fā)送ACK回應(yīng)請求，并同時發(fā)送一個SYN的請求給客戶端
客戶端回應(yīng)ACK應(yīng)答
四次揮手
客戶端主動關(guān)閉，發(fā)送FIN請求
服務(wù)器回應(yīng)ACK應(yīng)答
服務(wù)器被動關(guān)閉，發(fā)送FIN請求
客戶端回應(yīng)ACK應(yīng)答
看到上述流程，可能有一個疑問：為什么連接和關(guān)閉的握手次數(shù)不一樣？其實，不論是連接還是關(guān)閉，客戶端和服務(wù)器端都是發(fā)送了一次請求（SYN/FIN），回應(yīng)了一次應(yīng)答（ACK），它們是對稱的。但是，在連接的時候服務(wù)器端的請求和應(yīng)答是在一次握手中同時完成的，而關(guān)閉的時候卻是分兩次完成的，所以就造成了連接和關(guān)閉的握手次數(shù)不對稱。
現(xiàn)在，新問題又來了：為什么連接時復(fù)用一次握手，而關(guān)閉的時候不復(fù)用握手？這個則是因為連接和關(guān)閉的行為不是一樣所造成的。
在連接過程中，客戶端是主動連接，服務(wù)器端是被動連接，這個順序是確定了的，因此，可以復(fù)用第二次握手。
在關(guān)閉的過程中，客戶端和服務(wù)器端可能同時主動關(guān)閉，此時就不能復(fù)用第二次握手了，因此請求和應(yīng)答需要單獨的發(fā)送。
Client Hello
握手第一步是客戶端向服務(wù)端發(fā)送 Client Hello 消息，這個消息里包含了一個客戶端生成的隨機數(shù) Random1、客戶端支持的加密套件（Support Ciphers）和 SSL Version 等信息
Server Hello
第二步是服務(wù)端向客戶端發(fā)送 Server Hello 消息，這個消息會從 Client Hello 傳過來的 Support Ciphers 里確定一份加密套件，這個套件決定了后續(xù)加密和生成摘要時具體使用哪些算法，另外還會生成一份隨機數(shù) Random2。注意，至此客戶端和服務(wù)端都擁有了兩個隨機數(shù)（Random1+ Random2），這兩個隨機數(shù)會在后續(xù)生成對稱秘鑰時用到。
Certificate
這一步是服務(wù)端將自己的證書下發(fā)給客戶端，讓客戶端驗證自己的身份，客戶端驗證通過后取出證書中的公鑰。
Certificate Request
Certificate Request 是服務(wù)端要求客戶端上報證書，這一步是可選的，對于安全性要求高的場景會用到。
Server Hello Done
Server Hello Done 通知客戶端 Server Hello 過程結(jié)束。
Certificate Verify
客戶端收到服務(wù)端傳來的證書后，先從 CA 驗證該證書的合法性，驗證通過后取出證書中的服務(wù)端公鑰，再生成一個隨機數(shù) Random3，再用服務(wù)端公鑰非對稱加密 Random3 生成 PreMaster Key。
Client Key Exchange
上面客戶端根據(jù)服務(wù)器傳來的公鑰生成了 PreMaster Key，Client Key Exchange 就是將這個 key 傳給服務(wù)端，服務(wù)端再用自己的私鑰解出這個 PreMaster Key 得到客戶端生成的 Random3。至此，客戶端和服務(wù)端都擁有 Random1 + Random2 + Random3，兩邊再根據(jù)同樣的算法就可以生成一份秘鑰，握手結(jié)束后的應(yīng)用層數(shù)據(jù)都是使用這個秘鑰進行對稱加密。為什么要使用三個隨機數(shù)呢？這是因為 SSL/TLS 握手過程的數(shù)據(jù)都是明文傳輸?shù)模⑶叶鄠€隨機數(shù)種子來生成秘鑰不容易被暴力破解出來。
Change Cipher Spec(Client)
這一步是客戶端通知服務(wù)端后面再發(fā)送的消息都會使用前面協(xié)商出來的秘鑰加密了，是一條事件消息。
Encrypted Handshake Message(Client)
這一步對應(yīng)的是 Client Finish 消息，客戶端將前面的握手消息生成摘要再用協(xié)商好的秘鑰加密，這是客戶端發(fā)出的第一條加密消息。服務(wù)端接收后會用秘鑰解密，能解出來說明前面協(xié)商出來的秘鑰是一致的。
Change Cipher Spec(Server)
這一步是服務(wù)端通知客戶端后面再發(fā)送的消息都會使用加密，也是一條事件消息。
Encrypted Handshake Message(Server)
這一步對應(yīng)的是 Server Finish 消息，服務(wù)端也會將握手過程的消息生成摘要再用秘鑰加密，這是服務(wù)端發(fā)出的第一條加密消息?？蛻舳私邮蘸髸妹罔€解密，能解出來說明協(xié)商的秘鑰是一致的。
Application Data
到這里，雙方已安全地協(xié)商出了同一份秘鑰，所有的應(yīng)用層數(shù)據(jù)都會用這個秘鑰加密后再通過 TCP 進行可靠傳輸
中間人攻擊
服務(wù)器向客戶端發(fā)送公鑰。
攻擊者截獲公鑰，保留在自己手上。
然后攻擊者自己生成一個【偽造的】公鑰，發(fā)給客戶端。
客戶端收到偽造的公鑰后，生成加密hash值發(fā)給服務(wù)器。
攻擊者獲得加密hash值，用自己的私鑰解密獲得真秘鑰。
同時生成假的加密hash值，發(fā)給服務(wù)器。
服務(wù)器用私鑰解密獲得假秘鑰。
這里就需要一個強大的公證人，就是CA，操作系統(tǒng)會做CA證書的判斷。
http://www.itdecent.cn/p/7158568e4867
http://www.itdecent.cn/p/9c52693a09dc
