HTTPS 基本流程3

前文說到了6 組key material， 12個hash 值，很是迷惑， 今天才搞明白， 原來全部這些內容就是 對稱密鑰的內容。

上面的圖 雖然不是很清晰，可是， 其實也已經寫明白了， 就是 右邊的 CBC 模式的部分。對於 CBC模式的DES加密算法， 是須要這些內容的。

 

 

 

關於 身份認證， 其實不是 防止 篡改， 說的另外的一回事。 通常就是說，防止 middler man， 就是驗證 服務端就是 我想要的那個。 經過 證書 驗證， 能夠完成 身份的認證。

固然， 其實咱們也能夠 對客戶端 進行認證， 這也是 身份認證的一部分。

1. 身份認證：第三方沒法僞造服務端（客戶端）身份

 

 

DH 算法的通訊創建過程是這樣的：

 

 

 

 總之，若是協商過程使用 RSA 的話， 創建tls / ssl通道（正式傳輸 tls 上層數據以前）有7個 交互過程：

1 C->S：Client Hello
2 S->C：Server Hello
3 S->C：Certificate, Server Key Exchange, Server Hello Done
4 C->S：Client Key Change
5 C->S：Change Cipher Spec
6 C->S：Encryted Handshake Messagex`
7 S->C：Change Cipher Spec, Encryted Handshake Message
8 C->S/S->C：Application Data

 

簡單的SSL握手鍊接過程(僅Server端交換證書給client)：

1.C->S：client發送ClientHello，指定版本，隨機數(RN)，全部支持的密碼套件(CipherSuites)

2.S->C：server迴應ServerHello，指定版本，RN，選擇CipherSuites，會話ID(Session ID)

3.S->C：server發送Certificate

4.S->C：Server發送ServerHelloDone

5.C->S：Client發送ClientKeyExchange，用於與server交換session key

6.C->S：Client發送ChangeCipherSpec，指示Server從如今開始發送的消息都是加密過的

7.C->S：Client發送Finishd，包含了前面全部握手消息的hash，可讓server驗證握手過程是否被第三方篡改

8.S->C：Server發送ChangeCipherSpec，指示Client從如今開始發送的消息都是加密過的

9.S->C：Server發送Finishd，包含了前面全部握手消息的hash，可讓client驗證握手過程是否被第三方篡改，而且證實本身是Certificate密鑰的擁有者，即證實本身的身份

已經SSL握手完成，已經 創建tls / ssl通道了。

10 C->S/S->C：Application Data  開始正式數據交互

 

實際上呢， 2/3/4 幾個步驟是能夠合併的， 5/6/7 也是，8/9 也是。 因此抓包的時候能夠看到 4次通訊。

 

 

 參考：

https://blog.csdn.net/tterminator/article/details/50675540 很是很是詳細

https://blog.csdn.net/phunxm/article/details/72853376 很是很是詳細

https://blog.csdn.net/a_tu_/article/details/77119532

 http://www.cnblogs.com/svan/p/5090201.html