TLS詳解

TLS加密通訊，

開始使用協商的祕鑰進行加密通訊

  一、服務器也能夠要求驗證客戶端，即實現雙向的驗證，

  二、會話緩存握手過程，爲了創建握手的速度，減小協議帶來的性能方面的下降和資源方面的消耗，TLS協議有兩類會話緩存機制，分別是會話session ID 和會話記錄session titcket 。

     Session ID有服務器端支持，協議中的標準字段，所以基本的全部服務都支持，服務區段保存會話 ID 以及協商的通訊信息， Nginx中的IM內存約保存4000個session ID機器相關的信息，佔服務器資源較多。 另外一種就是Session ticket須要服務器和客戶端都支持，術語一個擴展字段，將協商的通訊信息加密以後發送給客戶端保存，祕鑰只有服務器知道，佔用服務器的資源最少。這二者對比，主要是保存協商信息位置的不一樣，相似http中session與從cookie。兩者都存在的狀況下，（nginx實現）優先使用session_ticket

   握手過程以下：

  

（1）會話標識SessionID 

      若是客戶端和服務器之間以前創建了鏈接，服務器會在握手成功以後返回SessionID ,而且保存默認的參數在服務器中

    若是客戶端再次須要和該服務器創建鏈接，則在Client_hello中 session_id中攜帶記錄信息，發送給服務器。

    服務器根據收到的session Id 檢索緩存的記錄，若是沒有檢索到緩存過時，則按照正常的握手進程進行。

    若是檢索到對應點緩存激勵，則返回change_cipher_spec與 encrypted_handshake_message信息，兩個信息做用相似，encrypted_handshack_messag是到當前通訊參數與 master_sercet的hash值。可是若是客戶可以驗證經過服務器加密數據，則客戶端一樣發送change_spec和encrypted_handshake_message信息。服務器驗證數據經過，則握手創建鏈接成功，開始進行征程的數據加密通訊。

（2）會話記錄session_ticket

    若是客戶端和服務器支架以前創建可鏈接，服務器會在new_session_ticket數據中攜帶加密的session_ticket信息，客戶端保存。

    若是客戶端再次須要和服務器創建鏈接，則在client_hello 中擴展字段session_ticket中攜帶加密信息，一塊兒發送給服務器，服務器解密session_ticket數據，若是解密失敗按照正常的握手進行。

   若是解密成功，session-ticket則返回 change_cipher_spec和encrypted_handshake_message信息，兩個信息做用於session Id中相似。

    若是客戶端能工驗證經過服務器加密數據，則客戶端一樣發送change_cipher_spec和encrypted_handshake_message信息。

   服務器驗證數據經過，則我哦手創建成功，開始進行正常的數據加密通訊。

三、從新鏈接

從新創建鏈接，就是放棄以前創建的鏈接，（TLS鏈接） 重新進行身份認證和祕鑰寫上個的過程，特色是不須要斷開當前的數據傳輸就能夠從新身份認證，更新祕鑰和算法，所以服務端存儲和緩存的信息均可以保存，

服務器端從新創建通常狀況是客戶端訪問受保護的數據發生，基本過程以下：

    客戶端和服務端創建了有效TLS鏈接 ，並開始通訊。

   客戶端訪問受保護的信息

   服務器端返回helo-request信息

   客戶端收到hello_request 信息以後發送client-helo 信息，開始創建鏈接

（4）祕鑰計算

涉及的參數 random client   random_server  Pre_master  Master sercet  key material 計算祕鑰時，服務器和客戶端都具體有這些基本的信息 ，計算流程以下：

 

客戶端使用RSA或者Diffe-Hellman等加密算法生成Pre-Master

Pre-Master結合Random sercet 和Random-server 兩個隨機數進行迭代生成 ker material 下面是詳細的內容解釋：

   PreMaster sercet 前面兩個字節是TLS的版本號，這是一個比較重要的用來覈對握手數據的版本號，由於在 Client hello 階段，客戶端會發送一份加密套件列表和當前支持的TLS協議的版本號給服務端  ，並且使用的是明文傳輸，若是握手數據包被破解以後，攻擊者極可能篡改數據包，選擇一個安全性較低的加密套件和版本給服務端，從而對數據進行破解，因此服務端要對密文中解密出來的對 PerMaster 版本號跟以前的Client hello階段版本號進行對比， 若是版本號變低，則說明數據被篡改，則當即日內至發送任何消息。

 不論是客戶端仍是服務器端都要使用隨機數，這樣生成的隨機祕鑰每次都會不同，對於RAS祕鑰來講，pre-master-key 自己就是一個隨機數，再加上helo消息中的隨隨機數三個隨機數經過一個祕鑰導出器最終生成一個對稱祕鑰。一個僞隨機可能不徹底是僞隨機，可是三個僞隨機加起來可能十分接近僞隨機數，