三次握手
客戶端向服務(wù)器發(fā)送SYN請求
服務(wù)器發(fā)送ACK回應(yīng)請求排作，并同時(shí)發(fā)送一個(gè)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)答
看到上述流程妄痪，可能有一個(gè)疑問：為什么連接和關(guān)閉的握手次數(shù)不一樣？其實(shí)楞件，不論是連接還是關(guān)閉拌夏，客戶端和服務(wù)器端都是發(fā)送了一次請求（SYN/FIN）僧著，回應(yīng)了一次應(yīng)答（ACK），它們是對稱的障簿。但是，在連接的時(shí)候服務(wù)器端的請求和應(yīng)答是在一次握手中同時(shí)完成的栅迄，而關(guān)閉的時(shí)候卻是分兩次完成的站故，所以就造成了連接和關(guān)閉的握手次數(shù)不對稱。
現(xiàn)在毅舆，新問題又來了：為什么連接時(shí)復(fù)用一次握手西篓，而關(guān)閉的時(shí)候不復(fù)用握手？這個(gè)則是因?yàn)檫B接和關(guān)閉的行為不是一樣所造成的憋活。
在連接過程中岂津，客戶端是主動連接，服務(wù)器端是被動連接悦即，這個(gè)順序是確定了的吮成，因此，可以復(fù)用第二次握手辜梳。
在關(guān)閉的過程中粱甫，客戶端和服務(wù)器端可能同時(shí)主動關(guān)閉，此時(shí)就不能復(fù)用第二次握手了作瞄，因此請求和應(yīng)答需要單獨(dú)的發(fā)送茶宵。
Client Hello
握手第一步是客戶端向服務(wù)端發(fā)送 Client Hello 消息，這個(gè)消息里包含了一個(gè)客戶端生成的隨機(jī)數(shù) Random1宗挥、客戶端支持的加密套件（Support Ciphers）和 SSL Version 等信息
Server Hello
第二步是服務(wù)端向客戶端發(fā)送 Server Hello 消息乌庶，這個(gè)消息會從 Client Hello 傳過來的 Support Ciphers 里確定一份加密套件，這個(gè)套件決定了后續(xù)加密和生成摘要時(shí)具體使用哪些算法契耿，另外還會生成一份隨機(jī)數(shù) Random2瞒大。注意，至此客戶端和服務(wù)端都擁有了兩個(gè)隨機(jī)數(shù)（Random1+ Random2）宵喂，這兩個(gè)隨機(jī)數(shù)會在后續(xù)生成對稱秘鑰時(shí)用到糠赦。
Certificate
這一步是服務(wù)端將自己的證書下發(fā)給客戶端，讓客戶端驗(yàn)證自己的身份锅棕，客戶端驗(yàn)證通過后取出證書中的公鑰拙泽。
Certificate Request
Certificate Request 是服務(wù)端要求客戶端上報(bào)證書，這一步是可選的裸燎，對于安全性要求高的場景會用到顾瞻。
Server Hello Done
Server Hello Done 通知客戶端 Server Hello 過程結(jié)束。
Certificate Verify
客戶端收到服務(wù)端傳來的證書后德绿，先從 CA 驗(yàn)證該證書的合法性荷荤，驗(yàn)證通過后取出證書中的服務(wù)端公鑰退渗，再生成一個(gè)隨機(jī)數(shù) Random3，再用服務(wù)端公鑰非對稱加密 Random3 生成 PreMaster Key蕴纳。
Client Key Exchange
上面客戶端根據(jù)服務(wù)器傳來的公鑰生成了 PreMaster Key会油，Client Key Exchange 就是將這個(gè) key 傳給服務(wù)端，服務(wù)端再用自己的私鑰解出這個(gè) PreMaster Key 得到客戶端生成的 Random3古毛。至此翻翩，客戶端和服務(wù)端都擁有 Random1 + Random2 + Random3，兩邊再根據(jù)同樣的算法就可以生成一份秘鑰稻薇，握手結(jié)束后的應(yīng)用層數(shù)據(jù)都是使用這個(gè)秘鑰進(jìn)行對稱加密嫂冻。為什么要使用三個(gè)隨機(jī)數(shù)呢？這是因?yàn)?SSL/TLS 握手過程的數(shù)據(jù)都是明文傳輸?shù)娜担⑶叶鄠€(gè)隨機(jī)數(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ù)都會用這個(gè)秘鑰加密后再通過 TCP 進(jìn)行可靠傳輸
中間人攻擊
服務(wù)器向客戶端發(fā)送公鑰窃蹋。
攻擊者截獲公鑰，保留在自己手上静稻。
然后攻擊者自己生成一個(gè)【偽造的】公鑰警没，發(fā)給客戶端。
客戶端收到偽造的公鑰后振湾，生成加密hash值發(fā)給服務(wù)器杀迹。
攻擊者獲得加密hash值，用自己的私鑰解密獲得真秘鑰押搪。
同時(shí)生成假的加密hash值树酪，發(fā)給服務(wù)器浅碾。
服務(wù)器用私鑰解密獲得假秘鑰。
這里就需要一個(gè)強(qiáng)大的公證人续语，就是CA垂谢，操作系統(tǒng)會做CA證書的判斷。
http://www.reibang.com/p/7158568e4867
http://www.reibang.com/p/9c52693a09dc
