TLS通訊過程

時間 2019-11-08

標籤 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 |html

client_key_exchange |
--- |
Pre-master |windows

時序圖

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

client_hello

客戶端發起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數，擴展字段等信息，相關信息以下：
支持的最高TSL協議版本version，從低到高依次SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當前基本再也不使用低於TLSv1的版本；
客戶端支持的加密套件cipher suites列表，每一個加密套件對應前面TLS原理中的四個功能的組合：認證算法(身份驗證)、密鑰交換算法KeyExchange(密鑰協商)、對稱加密算法Enc(信息加密)和信息摘要Mac(完整性校驗)；
支持的壓縮算法compression methods列表，用於後續的信息壓縮傳輸；
隨機數random_C，用於後續的密鑰的生成；
擴展字段extensions,支持協議與算法相關參數以及其它輔助信息等，常見的SNI就屬於擴展字段。

server_hello+server_certificate+server_hello_done

server_hello,服務端返回墒的信息結果，包括選擇使用的協議版本version,選擇的加密套件cipher suite,選擇的壓縮算法compression method、隨機數random_S等，其中隨機數用於後續的密鑰協商；
server_certificates,服務器端配置對應的證書鏈，用於身份認證與密鑰交換；
server_hello_done,通知客戶端server_hello信息發送結束；

證書校驗
客戶端驗證證書的合法性，若是驗證經過纔會進行後續的通訊，不然根據錯誤狀況作出不一樣提示和操做，合法性驗證包括以下：

證書鏈的可信性trusted catificate path；
證書是否吊銷revocation,有兩類方式離線CRL與在線OCSP，不一樣的客戶端行爲會不一樣；
有效期expiry date,證書是否在有效時間範圍；
域名domain,覈查證書域名是否與當前的訪問域名匹配，匹配規則後續分析；

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與算法進行加密，而後發送給服務器用於數據與握手驗證；

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與算法加密併發送到客戶端；

握手結束
客戶端計算全部接收信息的hash值，並採用協商密鑰解密encrypted_handshake_message,驗證服務器發送的數據和密鑰，驗證經過則握手完成；
加密通訊
開始使用協商密鑰與算法進行加密通訊。緩存

會話緩存握手過程

爲了加快創建握手的速度，減小協議帶來的性能下降和資源消耗，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

會話標識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信息；
服務器驗證數據經過，則握手創建成功，開始進行正常的加密數據通訊；

會話記錄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信息；
服務器驗證數據經過，則握手創建成功，開始進行正常的加密數據通訊；cookie

重建鏈接

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

服務器重建鏈接

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，三個參數做爲密鑰協商的基礎。

計算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三個隨機數一同生成的密鑰就不容易被猜出了，一個僞隨機可能徹底不隨機，但是三個僞隨機數就十分接近隨機數了，每增長一個自由度，隨機性增長的不止一。