SSL握手流程

1、SSL是什麼？

   安全套接字（SSL）協議是Web瀏覽器和Web服務器之間安全交換信息的協議。

   SSL介於應用層和TCP層之間，應用層數據再也不直接傳遞給傳輸層，而是傳遞給SSL層，SSL層對從應用層收到的數據進行加密，並增長本身的SSL頭。

 

History:
1994年，NetScape公司設計了SSL協議（Secure Sockets Layer）的1.0版，可是未發佈。
1995年，NetScape公司發佈SSL 2.0版，很快發現有嚴重漏洞。
1996年，SSL 3.0版問世，獲得大規模應用。
1999年，互聯網標準化組織ISOC接替NetScape公司，發佈了SSL的升級版TLS 1.0版。
2006年和2008年，TLS進行了兩次升級，分別爲TLS 1.1版和TLS 1.2版。最新的變更是2011年TLS 1.2的修訂版。

 

0x1:SSL記錄協議：
1) 分組、組合
2) 壓縮、解壓縮
3) 以及消息認證  
4) 加密傳輸等

0x2:SSL握手協議：
1). 客戶機認證服務器 
2). 協商客戶機與服務器選擇雙方都支持的密碼算法  
3). 可選擇的服務器認證客戶 
4). 使用公鑰加密技術生成共享密鑰 
5). 創建加密SSL鏈接（過程都是明文的，握手完成以後纔開始加密數據。）

0x3:SSL告警協議：SSL告警協議報文由嚴重級別和警告代碼兩部分組成
  
1. 嚴重級別(AlertLevel )
    1) Fatal
    Fatal級報警即致命級報警，它要求通訊雙方都要採起緊急措施，並終止會話，同時消除本身緩衝區相應的會話記錄 
    2) Waming
    Warning級報警即警告級報警的處理，一般是通訊雙方都只進行日誌記錄，它對通訊過程不形成影響
2. 警告代碼 
    1) bad_record_mac：收到了不正確的MAC 
　 2) unexpected_message：接收了不合適的報文 
    3) decompression_failure：解壓縮函數收到不適當的輸入。
    4) illegal_parameter：握手報文中的一個字段超出範圍或與其餘字段不兼容。
    5) certificate_revoked：證書已經被廢棄。
    6) bad_certificate：收到的證書是錯誤的。
    7) certificate_expired：證書已通過期。
    8) handshake_failer：握手過程失敗。
    9) no_certificate: 未提供證書
    10) unsupported_certificate: 未支持的證書格式
    11) certificate_unknown: 未知證書

2、SSL有什麼用？

1. 祕密性: SSL客戶機和服務器之間傳送的數據都通過了加密處理,網絡中的非法竊聽者所獲取的信息都將是無心義的密文信息

2. 完整性: SSL利用密碼算法和散列(HASH)函數,經過對傳輸信息特徵值的提取來保證信息的完整性,確保要傳輸的信息所有到達目的地,能夠避免服務器和客戶機之間的信息受到破壞。

3. 認證性:利用證書技術和可信的第三方認證，可讓客戶機和服務器相互識別對方的身份。爲了驗證證書持有者是其合法用戶(而不是冒名用戶)，SSL要求證書持有者在握手時相互交換數字證
書，經過驗證來保證對方身份的合法性。

3、SSL和TLS的差別：

1. 版本號：TLS記錄格式與SSL記錄格式相同，但版本號的值不一樣，TLS的版本1.0使用的版本號爲SSLv3.1。
2. 報文鑑別碼：SSLv3.0和TLS的MAC算法及MAC計算的範圍不一樣。TLS使用了RFC-2104定義的HMAC算法。SSLv3.0使用了類似的算法，二者差異在於SSLv3.0中，填充字節與密鑰之間採用的是鏈接運算，而HMAC算法採用的是異或運算。可是二者的安全程度是相同的。
3. 僞隨機函數：TLS使用了稱爲PRF的僞隨機函數來將密鑰擴展成數據塊，是更安全的方式。
4. 報警代碼：TLS支持幾乎全部的SSLv3.0報警代碼，並且TLS還補充定義了不少報警代碼，如
    1) 解密失敗(decryption_failed)
    2) 記錄溢出(record_overflow)
    3) 未知CA(unknown_ca)
    4) 拒絕訪問(access_denied)等。
5. 密文族和客戶證書：SSLv3.0和TLS存在少許差異，即TLS"不支持":
    1) Fortezza密鑰交換
    2) 加密算法
    3) 客戶證書。
6. certificate_verify和finished消息：SSLv3.0和TLS在用certificate_verify和finished消息計算MD5和SHA-1散列碼時，計算的輸入有少量差異，但安全性至關。
7. 加密計算：TLS與SSLv3.0在計算主密值(master secret)時採用的方式不一樣。但都是以客戶端和服務端各自產生的隨機數Ramdom做爲輸入
8. 填充：用戶數據加密以前須要增長的填充字節。在SSL中，填充後的數據長度要達到密文塊長度的最小整數倍。而在TLS中，填充後的數據長度能夠是密文塊長度的任意整數倍(但填充的最大長度爲255字節)，這種方式能夠防止基於對報文長度進行分析的攻擊。

 

4、SSL過程

0x1: 流程  前兩部稱爲「握手階段」

1）客戶端向服務器端索要並驗證公鑰    
2）雙方協商生成「對話密鑰」（不用通訊方的公鑰進行加密<耗時>，只用對方的公鑰來加密本端生成的「密鑰」）
3）雙方採用「對話密鑰」進行加密通訊。

0x2:具體過程  只關注單向認證

1. Client Hello：首先，客戶端（瀏覽器）先向服務器發出加密通訊請求，這被叫作ClientHello請求。

1) 支持的協議版本，好比TLS 1.0版。
2) 一個客戶端生成的隨機數A，稍後用於生成"對話密鑰"。
3) 加密方法：支持的多種非對稱加密方法、多種對稱加密方法、多種MAC算法
4)  支持的壓縮方法。

2.Server Hello：

1) 確認使用的加密通訊協議版本，好比TLS 1.0版本。若是瀏覽器與服務器支持的版本不一致，服務器關閉加密通訊。
2) 一個服務器生成的隨機數B，稍後用於生成"對話密鑰"。
3) 確認使用的加密方法：從客戶端提供的選出一個集合出來：{對稱加密算法，非對稱加密算法，MAC校驗算法}

3. Certificate： server將「攜帶本身公鑰信息的數字證書」和到根CA整個鏈經過Certificate消息發送給SSL客戶端（整個公鑰文件都發送過去）

1）客戶端可使用該公鑰來驗證服務器的身份

  證書中的消息包括：

           

    通常狀況下客戶端收到的是一個證書鏈，第一個是服務器的證書，以後是服務器證書籤發者，最後是自簽名的根證書。以下圖，在實際解析中先要驗證根CA的證書，而後是直接證書籤發者證書，最後是服務器終端證書。

                   

證書合法性的判斷方法：

~頒佈者的合法性（hash值）
~有效期
~簽名值是否合法：首先對證書中除簽名值部分的內容按照證書中的簽名算法進行簽名，把獲得的簽名按照asn.1編碼方式進行編碼：OBJECT格式的簽名算法+ ASN_OCTET_STRING格式的簽名值A；把證書中的簽名值按照證書中的主體公鑰算法進行解密獲得B；當A和B徹底相同時認爲證書有效（證書製做過程當中的簽名值計算方法：計算獲得A，和客戶端計算方法相同，用服務器私鑰對A進行加密，獲得證書中的簽名值）

 

2）公鑰加密pre-naster secret （Client Key Exchange）

    假設上面的證書驗證經過了，這就意味着client相信server發過來的證書了，也就意味着client贊成用server發過來的public key開始通信了。注意，非對稱加密的過程在這裏開始了。client生成了一個pre-master secret（一般也是一個隨機數）P，使用server提供的public key加密P以後生成P'，將P'發給了server。

server收到P'後，用本身的private key解密還原出了P。注意這個P和以前A的最大不一樣是加密傳輸過來的哦。並且理論上在server沒有泄露本身private key的狀況下， 只有server可以從P'還原出P。So，此時，client和server雙方已經具有了生成雙方後面通信時對稱加密須要使用的master secret的條件：雙方都有的一個肯定的僞隨機函數、3個彼此都知道的隨機數A、B和P。因而，雙方在本身一方，經過共同的僞隨機數和共同的素材，生成出來了master secret。

--------------

爲何要使用三個隨機數?

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

 

4. Change cipher Spec：通訊雙方協商好了對稱加密的密鑰和對稱加密的算法以後，用這個消息進行測試

1)client用雙方贊成的MAC（message authentication code）算法，好比MD5加密一段明文Q，生成MAC，而後用雙方都贊成的對稱加密算法（好比AES）加密Q和MAC以後，
  生成一段Change Cipher Spec(content type:20).
2)Server收到這條TLS record以後，會先嚐試解密密文，再用約定的MAC算法驗證內容是否被篡改。這個若是這兩個任何一項工做失敗了，就前功盡棄了。這裏假設都成功了，
  因而server作了上一步client一樣的事情：生成一份content type爲20的Change cipher Spec發給client，至此，整個握手過程正式結束。

5. 下面的通信就是雙方直接使用對稱加密算法直接加解密message的過程了，每次交互過程當中，還會包括上面描述的MAC驗證的過程。

參考資料：大部分資料來自網絡，我只是稍加整理。風格是抄襲Little Hann大神的~勿噴

http://www.cnblogs.com/LittleHann/p/3733469.html
http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html
http://www.2cto.com/Article/201404/291859.html
http://blog.csdn.net/sealyao/article/details/5901510