碼上快樂

相關內容    簡體    繁體

TLS通信過程

本文轉載自   查看原文   2019-01-13 19:54   1570    tls

TLS通信過程

握手與密鑰協商過程

基於RSA握手和密鑰交換的客戶端驗證服務器為示例詳解TLS/SSL握手過程

sequenceDiagram
client->>server: client_hello  
server->>client: server_hello
client->>client: 證書校驗
client->>server: client_key_exchange \n change_cipher_spec \n encrypted_handshake_message
server->>client: change_cipher_spec \n encrypted_handshake_message 
loop application data  
client->server: application data
end
client_hello
version
cipher suites
compression methods
random_C
extensions
server_hello
version
cipher suite
compression method
random_S
extensions
證書校驗
trusted CA
revocation
date
domain
client_key_exchange
Pre-master

時序圖

sequenceDiagram
client->>server: client hello(隨機數，支持的加密算法)
server->>client: server hello(隨機數，選擇一個client支持的算法)
server->>client: server 證書
client->>client: 驗證證書
client->>server: client key exchange(用server公鑰加密pre-master key)
client->>server: change cipher sped(通知server參數協商完成)  
client->>server: finsh hand shake(encrypt handshake message)
server->>client: cipher spec + finsh handshake
  1. client_hello
  • 客戶端發起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數，擴展字段等信息，相關信息如下：
  • 支持的最高TSL協議版本version，從低到高依次SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當前基本不再使用低於TLSv1的版本；
  • 客戶端支持的加密套件cipher suites列表，每個加密套件對應前面TLS原理中的四個功能的組合：認證算法(身份驗證)、密鑰交換算法KeyExchange(密鑰協商)、對稱加密算法Enc(信息加密)和信息摘要Mac(完整性校驗)；
  • 支持的壓縮算法compression methods列表，用於后續的信息壓縮傳輸；
  • 隨機數random_C， 用於后續的密鑰的生成；
  • 擴展字段extensions,支持協議與算法相關參數以及其它輔助信息等，常見的SNI就屬於擴展字段。
  1. server_hello+server_certificate+server_hello_done
  • server_hello,服務端返回墒的信息結果，包括選擇使用的協議版本version,選擇的加密套件cipher suite,選擇的壓縮算法compression method、隨機數random_S等，其中隨機數用於后續的密鑰協商；
  • server_certificates,服務器端配置對應的證書鏈，用於身份認證與密鑰交換；
  • server_hello_done,通知客戶端server_hello信息發送結束；
  1. 證書校驗
    客戶端驗證證書的合法性，如果驗證通過才會進行后續的通信，否則根據錯誤情況做出不同提示和操作，合法性驗證包括如下：
  • 證書鏈的可信性trusted catificate path；
  • 證書是否吊銷revocation,有兩類方式離線CRL與在線OCSP，不同的客戶端行為會不同；
  • 有效期expiry date,證書是否在有效時間范圍；
  • 域名domain,核查證書域名是否與當前的訪問域名匹配，匹配規則后續分析；
  1. client_key_exchange+change_cipher_spec+encrypted_handshake_message
  • client_key_exchange，合法性校驗通過之后，客戶端計算產生隨機數字Pre-master，並用證書公鑰加密，發送給服務器；
  • 此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數random_C和random_S與自己計算產生的Pre-master，計算得到協商密鑰；
  • enc_key=Fuc(random_C,random_S,Pre-Master)
  • change_cipher_spec,客戶端通知服務器后續的通信都采用協商的通信密鑰和加密算法進行加密通信；
  • encrypted_handshake_message,結合之前所有通信參數的hash值與其它相關信息生成一段數據，采用協商密鑰session secret與算法進行加密，然后發送給服務器用於數據與握手驗證；
  1. change_cipher_spec+encrypted_handshake_message
  • 服務器用私鑰解密加密的Pre-master數據，基於之前交換的兩個明文隨機數random_C和random_S，計算得到協商密鑰：enc_key=Fuc(random_C,random_S,Pre-Master)；
  • 計算之前所有接收信息的hash值，然后解密客戶端發送的encrypted_hadshake_message，驗證數據和密鑰的正確性；
  • change_cipher_spec，驗證通過之后，服務器同樣發送change_cipher_spec以告知客戶端后續的通信都采用協商的密鑰與算法進行通信；
  • encrypted_handshake_message,服務器也結合所有當前的通信參數信息生成一段數據並采用協商密鑰session secret與算法加密並發送到客戶端；
  1. 握手結束
    客戶端計算所有接收信息的hash值，並采用協商密鑰解密encrypted_handshake_message,驗證服務器發送的數據和密鑰，驗證通過則握手完成；
  2. 加密通信
    開始使用協商密鑰與算法進行加密通信。

會話緩存握手過程

為了加快建立握手的速度，減少協議帶來的性能降低和資源消耗，TLS協議有兩類會話緩存機制：會話標識session ID與會話記錄session ticket。
session ID由服務器端支持，協議中的標准字段，因此基本所有服務器都支持，服務器端保存會話ID以及協商的通信信息，Nginx中1M內存約可以保存4000個session ID機器相關信息，戰用服務器資源較多；
session ticket需要服務器和客戶端都支持，屬於一個擴展字段，將協商的通信信息加密之后發送給客戶端保存，密鑰只有服務器知道，戰勝服務資源很少。
二者對比，主要是保存協議信息的位置與方式不同，類似與http的sessin與cookie。
二者都存在的情況下,(nginx實現)優先使用session_ticket。
握手過程如下圖：

sequenceDiagram
client->server: full handshake
client->>server: client_hello
server->>client: server_hello \n change_cipher_spec \n encrypted_handshake_message
client->>server: change_cipher_spec \n encrypted_handshake_message
loop 應用程序數據
client->server: application data
end
client_hello
version
cipher suites
compression methods
random_C
extensions
Session ID
(session ticket)
  1. 會話標識session ID
  • 如果客戶端和服務器之間曾經建立了連接，服務器會在握手成功后返回session ID，並保存對應的通信參數在服務器中；
  • 如果客戶端再次需要和該服務器建立連接，則在client_hello中session ID中攜帶記錄的信息，發送給服務器；
  • 服務器根據收到的session ID檢索緩存記錄，如果沒有檢索到緩存過期，則按正常的握手過程進行；
  • 如果檢索到對應的緩存記錄，則返回change_cipher_spec與encrypted_handshake_message信息，兩個信息作用類似，encrypted_handshake_message是到當前的通信參數與master_secret的hash值；
  • 如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發送change_cipher_spec與encrypted_handshake_message信息；
  • 服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信；
  1. 會話記錄session ticket
  • 如果客戶端和服務器之間曾經建立了連接，服務器會在new_session_ticket數據中攜帶加密的session_ticket信息，客戶端保存；
  • 如果客戶端再次需要和該服務器建立連接，則在client_hello中擴展字段session_ticket中攜帶加密信息，一起發送給服務器；
  • 服務器解密session_ticket數據，如果能夠解密失敗，則按照正常的握手過程進行；
  • 如果解密成功，則返回change_cipher_spec與encrypted_handshake_message信息，兩個信息作用與session ID中類似；
  • 如果客戶端能夠驗證通過服務器加密數據，則客戶端同樣發送change_cipher_spec與encrypted_handshake_message信息；
  • 服務器驗證數據通過，則握手建立成功，開始進行正常的加密數據通信；

重建連接

重建連接renegotiation即放棄正在使用的TLS連接，重新進行身份認證和密鑰協商過程，特點是不需要斷開當前的數據傳輸就可以重新身份認證、更新密鑰或算法，因此服務器端存儲和緩存的信息都可以保持。客戶端和服務器都能夠發起重建連接的過程，當前windows 2000和XP與SSL 2.0不支持。

服務器重建連接

sequenceDiagram
client->server: full handshake
loop 應用程序數據
client->server: application data
end
client->>server: access protected data
server->>client: hello_request 
client->server: full handshake
loop 應用程序數據
client->server: application data
end

服務器端重建連接一般情況是客戶端訪問受保護的數據時發生。基本過程如下：

  • 客戶端和服務器之間建立了有效TLS連接並通信；
  • 客戶端訪問受保護的信息；
  • 服務器端返回hello_request信息；
  • 客戶端收到hello_request信息之后發送client_hello信息，開始重新建立連接。

客戶端重建連接

sequenceDiagram
client->server: full handshake
loop 應用程序數據
client->server: application data
end
client->>server: client_hello
server-->>client: application data
server->>client: server_hello
client->server: next handshake processes
client->server: application data

客戶端重建連接一般是為了更新通信密鑰。

  • 客戶端和服務器之間建立了有效TLS連接並通信；
  • 客戶端需要更新密鑰，主動發出client_hello信息；
  • 服務器端收到client_hello信息之后無法立即識別出該信息非應用數據，因此會提交給下一步處理，處理完之后會返回通知該信息為要求重建連接；
  • 在確定重建連接之前，服務器不會立即停止向客戶端發送數據，可能恰好同時有緩存數據需要發送給客戶端，但是客戶端不會再發送任何信息給服務器；
  • 服務器識別出重建連接請求之后，發送server_hello信息至客戶端；
  • 客戶端也同樣無法立即判斷出該信息非應用數據，同樣提交給下一步處理，處理之后會返回通知該信息為要求重建連接；
  • 客戶端和服務器開始新的重建連接的過程。

密鑰計算

上節提取兩個明文傳輸的隨機數random_C和random_S與通過加密在服務器和客戶端之間交換的Pre-master，三個參數作為密鑰協商的基礎。

  1. 計算key
    涉及參數random client和random server,Pre-master,Master secret ,key material,計算密鑰時，服務器和客戶端都具有這些基本信息，計算流程如下：
graph TB
RSA/Diffie-Hellman-->Pre-master
Pre-master-->MasterSecret
MasterSecret-->keyMaterial
RandomClient-->MasterSecret
RandomServer-->MasterSecret
  • 客戶端采用RS或Diffie-Hellman等加密算法生成Pre-master;
  • Pre-master結合random client和random server兩個隨機數通過PsedoRandomFunction(PRF)計算得到Master secret;
  • Master secret結合random client和random server兩個隨機數通過迭代計算得到key material;
  • PreMaster secret前兩個字節是TLS的版本號，這是一個比較重要的用來握手數據的版本號，因為在Client Hello階段客戶端會發送一份加密套件列表和當前支持的SSL/TLS的版本號給服務端，而且是使用明文傳送的，如果握手的數據包被破解之后，攻擊者可能篡改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解，所以服務端需要對密文中解密出來的PreMaster版本號跟之前 Client Hello階段的版本號進行對比，如果版本號變低，則說明被篡改，則立即停止發送任何消息。
  • 不管是客戶端還是服務器，都要隨機數，這樣生成的密鑰才不會每次都一樣。由於SSL協議中證書是靜態的，因此十人有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
    對於RS密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
    pre master的存在在於SSL協議不任何每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機數，那么客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是三個偽隨機數就十分接近隨機數了，每增加一個自由度，隨機性增加的不止一。
  1. 密鑰使用
    Key經過12輪迭代計算會獲取到12個hash值，分組成為6個元素，列表如下：
client Mac key
server Mac key
client encryption key
server encryption key
client IV
server IV
  • mac key、encryption key、和IV是一組加密元素，分別被客戶端和服務器使用，但是這兩組元素都被兩邊同時獲取；
  • 客戶端使用client組元素加密數據，服務器使用client元素解密，服務器使用server元素加密，client使用server元素解密；
  • 雙向通信的不同方向使用的密鑰不同，破解通信至少需要破解兩次；
  • encryption key用於對稱加密數據；
  • IV作為很多加密算法的初始化向量使用，具體可以研究對稱加密算法；
  • Mac key用於數據的完整性校驗；
  1. 數據加密通信過程
  • 對應用層數據進行分片成合適的block；
  • 為分片數據編號，防止重放攻擊；
  • 使用協商的壓縮算法壓縮數據；
  • 計算MAC值和壓縮數據組成傳輸數據；
  • 使用client encryption key加密數據，發送給服務器server；
  • server收到數據之后使用client encryption key密鑰，校驗數據，解壓縮數據，重新組裝。

參考鏈接：https://www.cnblogs.com/huanxiyun/articles/6554085.html


免責聲明！

本站轉載的文章為個人學習借鑒使用，本站對版權不負任何法律責任。如果侵犯了您的隱私權益，請聯系本站郵箱yoyou2525@163.com刪除。



猜您在找 SSL、TLS協議格式、HTTPS通信過程、RDP SSL通信過程 SSL、TLS協議格式、HTTPS通信過程、RDP SSL通信過程 SSL/TLS通信 SSL/TLS握手過程 docker的安全管理與TLS/LLS加密通信 HTTPS加密過程和TLS證書驗證 TLS協議握手過程簡介 SSL/TLS 握手過程詳解 ARP通信過程 SSL及其加密通信過程
 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM