SSL/TLS通訊

時間 2019-11-26

標籤 ssl tls 通訊欄目 SSL 简体版

原文原文鏈接

本文同時發表在https://github.com/zhangyachen/zhangyachen.github.io/issues/31html

複習基本概念

對稱密碼：加密和解密使用同一密匙。
公鑰密碼：加密和解密使用不一樣密鑰的方式。
單向散列函數：計算散列值，保證的不是機密性，而是完整性。
消息認證碼：確認消息是否被篡改，並且可以確認消息是否來自所期待的通訊對象。
數字簽名：因爲消息認證碼使用公鑰進行加密的，會出現發送方否定的狀況，因此爲了防止這種狀況出現，發送方使用私鑰進行加密散列值。
證書：咱們必須保證驗證數字簽名的公鑰必須屬於發送方，不然數字簽名會失效。爲了確認本身獲得的公鑰是否合法，咱們須要使用證書。

密碼技術git

什麼是SSL/TLS

來看一下經過http發送請求的場景：github

可是此種狀況下，信用卡號就頗有可能被竊聽。因而，咱們可使用SSL或者TLS做爲對通訊進行加密的協議，而後在此之上承載http。經過對此兩種協議的疊加，咱們就對HTTP的通訊進行加密，防止竊聽。算法

以上面的例子爲例，若是咱們想要達到安全的通訊，必須達到如下幾點：瀏覽器

信用卡號不被竊聽
信用卡號不被篡改
確認通訊對方是真實的而不是假冒的

以上問題抽象出來就是：安全

機密性
完整性
認證問題

經過文章最開始提到的密碼技術，咱們能夠想到機密性能夠用對稱密碼解決（這裏的竊聽不是指發送內容不能被攻擊者獲得，而是攻擊者即便獲得發送內容也不能理解或者破譯）。因爲對稱密碼不能被攻擊者預測，所以咱們使用僞隨機數生成器來生成密鑰。若要將對稱密碼的密鑰發送給通訊方而不被攻擊者竊聽，可使用公鑰密碼或者Diffie-Hellman密鑰交換。
識別篡改可使用消息認證碼技術.
對通訊對象的認證，可使用對公鑰加上數字簽名所生成的證書。服務器

咱們須要一個「框架」將上述工具組合起來，SSL/TLS協議就扮演了這樣一個框架的角色。框架

上面的例子是SSL/TLS承載HTTP協議，其實SSL/TLS還能夠承載不少協議，例如：SMTP、POP3。函數

SSL與TLS的區別

SSL是1994年網景公司設計的一種協議，並在該公司的Web瀏覽器中進行了實現。隨後不少Web瀏覽器都採用了這一種協議，使其成爲了事實上的行業標準。SSL已經於1995年發佈了3.0版本。
TLS是IETF在SSL3.0的基礎上設計的協議。在1999年做爲RFC2246發佈的TLS1.0，實際上至關於SSL3.1。工具

爲何使用SSL/TLS

全部信息都是加密傳播，第三方沒法竊聽。
具備校驗機制，一旦被篡改，通訊雙方會馬上發現。
配備身份證書，防止身份被冒充。

SSL/TLS的層次化協議

TLS協議分爲TLS記錄協議和TLS握手協議。位於底層的TLS記錄協議負責進行加密，位於上層的TLS握手協議負責加密之外的其餘操做。而上層的TLS握手協議又分爲4個子協議。

記錄協議

負責消息的壓縮、加密以及數據的認證。

處理過程以下：

將消息分割成小片斷，而後對每一個片斷進行壓縮，壓縮算法須要與通訊對象進行協商。
將每一個壓縮的片斷加上消息認證碼，這是爲了保證完整性並進行數據的認證。經過附加消息的MAC值，能夠識別出篡改。與此同時，爲了防止重放攻擊，在計算消息認證碼時，還加上了片斷的編號，單向散列函數的算法。以及消息認證碼所使用的共享密鑰都須要與通訊對象協商決定。
通過壓縮的片斷加上消息認證碼會一塊兒經過對稱密碼進行加密。加密使用CBC模式，CBC的初始化向量（IV）經過主密碼（master secret）生成，而對稱密碼的算法以及共享密鑰須要協商。
上述的加密數據再加上數據類型、版本號、壓縮後的長度組成的報頭就是最終的報文數據。

握手協議

負責生產共享密鑰以及交換證書。
握手協議主要分爲4個子協議：握手協議、密碼規格變動協議、警告協議和應用數據協議。

握手協議

負責在客戶端和服務器之間協商決定密碼算法和共享密鑰。基於證書的認證也在這一步完成。這段協議至關於下面的會話：
客戶端：「你好，我能理解的密碼套件有RSA/3DES，或者DSS/AES，請問咱們使用哪種？」
服務器：「你好，咱們使用RSA/3DES吧，這是個人證書。」
協商以後，就會互相發出信號來切換密碼。負責發出信號的就是下面介紹的密碼規格變動協議。

密碼規格變動協議

負責向通訊對象傳達變動密碼方式的信號。
客戶端：「咱們按照剛纔的約定切換密碼吧。1,2,3」
中途發生錯誤時，就會經過下面的警告協議傳達給對方。

警告協議

服務器：「剛纔的消息沒法正確解析哦。」

應用數據協議

將TLS上面承載的應用數據傳達給通訊對象的協議。

使用SSL/TLS進行通訊

（圖片太長了，截了兩次，o(╯□╰)o）

一些重要握手過程：

ClientHello

客戶端向服務器發出加密通訊的請求。
在這一步，客戶端主要向服務器提供如下信息。

支持的協議版本，好比TLS 1.0版。
當前時間
一個客戶端生成的隨機數，稍後用於生成"對話密鑰"。
會話ID
支持的加密方法，好比RSA公鑰加密。
支持的壓縮方法。

「會話ID」是當客戶端和服務器但願從新使用以前創建的會話（通訊路徑）時所使用的信息。

ServerHello

服務器收到客戶端請求後，向客戶端發出迴應。服務器的迴應包含如下內容。

確認使用的加密通訊協議版本，好比TLS 1.0版本。若是瀏覽器與服務器支持的版本不一致，服務器關閉加密通訊。
一個服務器生成的隨機數，稍後用於生成"對話密鑰"。
當前時間
會話ID
確認使用的加密方法，好比RSA公鑰加密。
密碼套件。

Certificate

服務器發送Certificate消息。包含如下內容

證書清單
首先發送的是服務器的證書，而後會按順序發送對服務器證書籤名的認證機構的證書。
當以匿名方式通訊時，不發送Certificate消息。

ServerKeyExchange

當Certificate消息不足以知足需求時（例如匿名方式通訊），服務器會經過ServerKeyExchange消息向客戶端發送一些必要信息。
當使用RSA時，服務器發送N與E，也就是公鑰。
當使用DH算法時，服務器發送P、G、G的x次方modP（DH算法的公開參數）

ClientKeyExchange

客戶端從服務器的證書中取出服務器的公鑰，而後向服務器發送如下信息。

一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。該隨機數也叫做pre-master key。有了它之後，客戶端和服務器就同時有了三個隨機數，接着雙方就用事先商定的加密方法，各自生成本次會話所用的同一把主密碼。而主密碼用來加密客戶端和服務器的通訊內容。
當使用RSA時，會隨ClientKeyExchange一塊兒發送通過加密的預備主密碼。
當使用DH算法時，會隨ClientKeyExchange一塊兒發送DH的公開值，即Y(G的x次方模P)，以後雙方也能算出相同的pre-master key。

主密碼

很是重要的一個數值，TLS密碼通訊的機密性和數據的認證所有依靠這個數值。

主密碼的計算

主密碼依賴以下信息計算出來：

預備主密碼
客戶端隨機數
服務器隨機數

當使用RSA公鑰密碼時，客戶端在發送ClientKeyExchange消息時，將通過加密的預備主密碼一塊兒發送給服務器。
當使用DH密鑰交換時，客戶端在發送ClientKeyExchange消息時，將DH的公開值一塊兒發送給服務器。根據這個值，客戶端和服務器會各自生成預備主密碼。
當根據預備主密碼計算主密碼時，會使用兩個單向散列函數(MD5和SHA-1)組合而成的僞隨機數生成器。之因此用兩個單向散列函數，是爲了提升安全性。

爲何必定要三個隨機數

引用dog250的理解

不論是客戶端仍是服務器，都須要隨機數，這樣生成的密鑰纔不會每次都同樣。因爲SSL協議中證書是靜態的，所以十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對於RSA密鑰交換算法來講，pre-master-key自己就是一個隨機數，再加上hello消息中的隨機，三個隨機數經過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在於SSL協議不信任每一個主機都能產生徹底隨機的隨機數，若是隨機數不隨機，那麼pre master secret就有可能被猜出來，那麼僅適用pre master secret做爲密鑰就不合適了，所以必須引入新的隨機因素，那麼客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個僞隨機可能徹底不隨機，但是是三個僞隨機就十分接近隨機了，每增長一個自由度，隨機性增長的可不是一。