TLS協議

TLS詳解

簡介

​ TLS是這樣一種協議，跟前面IPsec保護網絡層安全傳輸有所區別，TLS是基於TCP建立兩個應用進程之間的安全連接。

​ 在客戶/服務器應用模式中，為了實現雙向身份鑒別，僅僅在服務器端保留固定安全參數並進行單向驗證是不夠的。因此，有必要為每一次客戶機和服務器之間的數據傳輸過程動態產生上訴安全參數，而且這些安全參數在每一次數據傳輸過程結束后自動失效，這將大大增強客戶機和服務器之間數據傳輸的安全性。TLS就是這樣一種用於完成雙向身份鑒別和安全參數協商的協議。

​ TLS的前身是安全插口層SSL(Secure Socket Layer)。

TLS協議結構

​ 實際上，SSL是共同工作的兩層協議所組成的，分別是獨占一層的TLS記錄協議和可以看作TLS記錄協議封裝的上層應用層數據，但是其中有幾個TLS的控制報文，如TLS握手協議、TLS密碼規范協議和TLS報警協議。如下圖所示

​ TLS記錄協議傳輸的上層消息可以實現源端鑒別、保密性和完整性。

​ TLS握手協議是一種實現身份鑒別和安全參數協商的協議。客戶端和服務器端通過TLS記錄協議傳輸數據前，需要通過TLS握手協議完成雙向身份鑒別過程，並約定壓縮算法、加密算法、消息鑒別MAC算法、加密密鑰、MAC密鑰等安全參數

​ 通信雙方確定新的安全參數后，通過TLS改變密碼規范協議通知對方開始使用新約定的安全參數。

​ 報警協議用於傳輸出錯消息，如解密失敗、無法確認證書等

​ 通信雙方第一次啟動握手協議時，初始安全參數為不壓縮、不加密、不計算MAC

TLS記錄協議

​ TLS的記錄協議封裝過程如上訴左圖所示

​ TLS封裝后后續添加首部格式如上述右圖所示

​ 其不同字段的內容所表示含義不同

• 內容類型包含TLS握手協議、TLS報警協議、TLS密碼改變規范協議或是HTTP消息

• 主版本號對於TLS固定為3

• 次版本號對於TLS固定為1

• 壓縮數據長度為加密操作前上層消息長度

  TLS的數據完成性檢測就由報文摘要算法計算后的消息鑒別碼MAC實現，數據本身的安全性保證則由對壓縮后的數據和MAC一起加密實現。

  那么在TLS進行如上訴左圖所示的封裝前，必須通過TLS握手協議約定如下安全參數壓縮算法、加密算法、消息鑒別MAC算法、服務器端寫密鑰、客戶端寫密鑰、服務器端寫MAC密鑰、客戶端端寫密鑰和需要

TLS握手協議實現身份鑒別和安全參數協商過程

​ 很顯然如圖所示，TLS握手協議分為四個階段，每個階段都有其作用。

​ TLS握手協議報文格式如下圖所示

階段1 約定算法

​ 客戶C在客戶Hello消息中按優先順序列出客戶C支持的算法列表及TLS協議版本，服務器V從客戶C支持的算法中選擇一種自己也支持的算法作為雙方約定的算法，在雙方共同支持的TLS版本則選擇版本較低的那一個，然后服務器會通過Hello消息將自己的選擇會送給客戶C

階段2 驗證服務器證書

​ 這就是我們在搭建網站時，為網站配置證書后的作用了。

​ 如圖是一些比較著名的證書廠商

​ 客戶端對服務器身份鑒別的過程實際上就是確認客戶C訪問的服務器域名確實為IDv的過程。我們采用的一般就是證書+私鑰的鑒別機制。需要服務器提供如下證書鏈。

​ 有點像數據結構中的並查集算法，查證兩節點是否有同一個根節點，也就是雙方都具有信任點的認證中心。服務器V一般需要提供如下證書鏈A<\<C>>,C<\<G>>,G<\<服務器V>>。

​ 但是提供上訴證書的過程並不能證明我們此時訪問的這個服務器就是我們想要訪問的服務器V，因為其他人可以通過劫持證書的方式來獲取服務器V的證書。

階段3 生成主密鑰與驗證客戶證書

​ 這是TLS握手階段最重要也是最復雜的一個階段。首先，如果服務器在發送自己證書的同時，也要求客戶端發送證書。那客戶C也會向服務器V發送自己的證書鏈。

​ 那么前面提到並不能完全證明服務器V的身份，那么在此步中，客戶端為了證明服務器V是具有證書V的私鑰Kskv的，就會用其公鑰Kpkv加密客戶選擇的預主密鑰PMS(Pre-Master Secret)，並通過交換密鑰消息將密文發送給服務器，如果最后服務器V和客戶端C成功協商出各種安全參數，那么就證明服務器V是具有私鑰SKV的。

​ 同樣的，反過來服務器也需要證明客戶C是具有其證書C私鑰SKC，也就是客戶C是客戶C本人。客戶C發送的證實證書消息中包含客戶C用私鑰SKC對雙方交換的握手協議消息的報文摘要進行解密運算后得到的密文一並發送。在服務器端保留有雙方交換的握手協議消息的摘要信息，通過C的公鑰PKC加密運算后恢復到握手協議的摘要的明文階段，與本來保留的摘要信息進行比對后，即可證明用戶C是否具有這個私鑰SKC。過程如下圖所示。

​ 在服務器端V得到預主密鑰PMS后生成主密鑰MS的過程暫不詳細敘述，計算公式如下

​ MK=PRF(PMS,"master secret",NonceC||NonceV)

​ PRF計算公式如下

​ PRF(密鑰，標簽，種子)=P_MD5(S1,標簽||種子)⊕P_SHA-1(S2,標簽||種子)注:S1和S2是將密鑰平分為前后兩部分

​ P_hash如圖所示

階段4 雙方身份鑒別和安全參數切換

​ 實際上，我們的客戶端C在此時還未得知服務器V到底是不是服務器V。前面我們不是用它的公鑰加密了預主密鑰PMS對吧，那只要證明其擁有預主密鑰PMS即可證明服務器V身份。也就是服務器V也得到了計算所得得主密鑰MS。因此，服務器向V向客戶C發送得結束消息中包含加密過的MS等信息。只要客戶端通過計算后得到得內容跟這個歌消息相等，則服務器V的身份得到確認。改變密碼規范表明發送端已經准備開始使用協商所得的安全參數。

HTTPS

​ 所謂HTTPS也就是在完成上訴雙向身份鑒別和安全參數協商之后，傳輸HTTP報文。用來實現瀏覽器和服務器之間傳輸的HTTP消息的保密性、完整性和源端鑒別。

​ 過程如下

​ 約定完安全參數后，終端發送HTTP消息的過程如下所示

更進一步

​ 在這一篇博文中，還有對SSL/TLS更詳盡的敘述包括握手報文中的具體內容。是個阿里雲的大牛寫的。

​ SSL、TLS協議格式、HTTPS通信過程、RDP SSL通信過程 - 鄭瀚Andrew.Hann - 博客園 (cnblogs.com)