SSL協議為不同的高層協議(http、FTP)提供安全服務
SSL握手協議、SSL修改密文協議和SSL告警協議的目的是為了管理和SSL相關的密文交換
連接：兩臺主機之間提供特定類型的數據傳輸，是點對點的關系；連接是短暫的，每一個連接都會和一個會話相互關聯
會話：是指客戶和服務器之間的關聯，會話是通過握手協議創建的；會話是加密安全參數的一個集合，包含加密算法、臨時的加密密鑰等信息；會話可以為多個連接所共享，就可以避免為每個連接建立都要進行安全參數的協商帶來的昂貴的時間代價。如果服務器和客戶端之間建立了多個安全的SSL連接，這些連接可以共享一個會話，也可以共享不同的會話。
SSL協議提供? 機密性和報文完整性兩種服務

SSL握手協議

握手協議是客戶機和服務器用SSL連接通信時使用的第一個子協議，握手協議包括客戶機與服務器之間的一系列消息。SSL中最復雜的協議就是握手協議。該協議允許服務器和客戶機相互驗證，協商加密和MAC算法以及保密密鑰，用來保護在SSL記錄中發送的數據。握手協議是在應用程序的數據傳輸之前使用的。
每個握手協議包含以下3個字段
- Type：表示10種消息類型之一
- Length：表示消息長度字節數
- Content：與消息相關的參數

SSL的流程(整體)

第一步，客戶端給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支持的加密方法。
第二步，服務器確認雙方使用的加密方法，并給出數字證書、以及一個服務器生成的隨機數（Server random）。
第三步，客戶端確認數字證書有效，然后生成一個新的隨機數（Premaster secret），并使用數字證書中的公鑰，加密這個隨機數，發給服務器。
第四步，服務器使用自己的私鑰，獲取客戶端發來的隨機數（即Premaster secret）。
第五步，客戶端和服務器根據約定的加密方法，使用前面的三個隨機數，生成"對話密鑰"（session key），用來會話密鑰對稱加密接下來通信過程中的對話。

SSL的流程(拆分)

1.1 建立安全能力

SSL握手的第一階段啟動邏輯連接，建立這個連接的安全能力。首先客戶機向服務器發出client hello消息并等待服務器響應，隨后服務器向客戶機返回server hello消息，對client hello消息中的信息進行確認。
Client hello消息包括Version，Random，Session id，Cipher suite，Compression method等信息。

ClientHello 客戶發送CilentHello信息，包含如下內容：

（1）客戶端可以支持的SSL最高版本號
（2）一個用于生成主秘密的32字節的隨機數。（等會介紹主秘密是什么）
（3）一個確定會話的會話ID。
（4）一個客戶端可以支持的密碼套件列表。
（5）一個客戶端可以支持的壓縮算法列表。

補充

?密碼套件格式：每個套件都以“SSL”開頭，緊跟著的是密鑰交換算法。用“With”這個詞把密鑰交換算法、加密算法、散列算法分開，例如SSL_DHE_RSA_WITH_DES_CBC_SHA,表示把DHE_RSA(帶有RSA數字簽名的暫時Diffie-HellMan)定義為密鑰交換算法；
把DES_CBC定義為加密算法；把SHA定義為散列算法。

?ServerHello 服務器用ServerHello信息應答客戶，包括下列內容

（1）一個SSL版本號。取客戶端支持的最高版本號和服務端支持的最高版本號中的較低者。
（2）一個用于生成主秘密的32字節的隨機數。（客戶端一個、服務端一個）
（3）會話ID
（4）從客戶端的密碼套件列表中選擇的一個密碼套件
（5）從客戶端的壓縮方法的列表中選擇的壓縮方法

這個階段之后，客戶端服務端知道了下列內容：

（1）SSL版本
（2）密鑰交換、信息驗證和加密算法
（3）壓縮方法
（4）有關密鑰生成的兩個隨機數。

1.2 服務器鑒別與密鑰交換

?服務器啟動SSL握手第2階段，是本階段所有消息的唯一發送方，客戶機是所有消息的唯一接收方。該階段分為4步：
（a）證書：服務器將數字證書和到根CA整個鏈發給客戶端，使客戶端能用服務器證書中的服務器公鑰認證服務器。
（b）服務器密鑰交換（可選）：這里視密鑰交換算法而定
（c）證書請求：服務端可能會要求客戶自身進行驗證。
（d）服務器握手完成：第二階段的結束，第三階段開始的信號

補充

這里重點介紹一下服務端的驗證和密鑰交換。這個階段的前面的（a）證書和（b）服務器密鑰交換是基于密鑰交換方法的。而在SSL中密鑰交換算法有6種：無效（沒有密鑰交換）、RSA、匿名Diffie-Hellman、暫時Diffie-Hellman、固定Diffie-Hellman、Fortezza。
在階段1過程客戶端與服務端協商的過程中已經確定使哪種密鑰交換算法。
如果協商過程中確定使用RSA交換密鑰，那么過程如下圖：

?這個方法中，服務器在它的第一個信息中，發送了RSA加密/解密公鑰證書。不過，因為預備主秘密是由客戶端在下一個階段生成并發送的，所以第二個信息是空的。注意，公鑰證書會進行從服務器到客戶端的驗證。當服務器收到預備主秘密時，它使用私鑰進行解密。服務端擁有私鑰是一個證據，可以證明服務器是一個它在第一個信息發送的公鑰證書中要求的實體。

1.3 客戶機鑒別與密鑰交換：

客戶機啟動SSL握手第3階段，是本階段所有消息的唯一發送方，服務器是所有消息的唯一接收方。該階段分為3步：

（a）證書（可選）：為了對服務器證明自身，客戶要發送一個證書信息，這是可選的，在IIS中可以配置強制客戶端證書認證。
（b）客戶機密鑰交換（Pre-master-secret）：這里客戶端將預備主密鑰發送給服務端，注意這里會使用服務端的公鑰進行加密。
（c）證書驗證（可選），對預備秘密和隨機數進行簽名，證明擁有（a）證書的公鑰。

?1.4 完成

客戶機啟動SSL握手第4階段，使服務器結束。該階段分為4步，前2個消息來自客戶機，后2個消息來自服務器。

密鑰生成的過程

這樣握手協議完成，下面看下什么是預備主密鑰，主密鑰是怎么生成的。為了保證信息的完整性和機密性，SSL需要有六個加密秘密：四個密鑰和兩個IV。為了信息的可信性，客戶端需要一個密鑰（HMAC），為了加密要有一個密鑰，為了分組加密要一個IV，服務也是如此。SSL需要的密鑰是單向的，不同于那些在其他方向的密鑰。如果在一個方向上有攻擊，這種攻擊在其他方向是沒影響的。生成過程如下：

記錄協議?

記錄協議在客戶機和服務器握手成功后使用，即客戶機和服務器鑒別對方和確定安全信息交換使用的算法后，進入SSL記錄協議，記錄協議向SSL連接提供兩個服務：
（1）保密性：使用握手協議定義的秘密密鑰實現
（2）完整性：握手協議定義了MAC，用于保證消息完整性

記錄協議的過程：

3、警報協議

客戶機和服務器發現錯誤時，向對方發送一個警報消息。如果是致命錯誤，則算法立即關閉SSL連接，雙方還會先刪除相關的會話號，秘密和密鑰。每個警報消息共2個字節，第1個字節表示錯誤類型，如果是警報，則值為1，如果是致命錯誤，則值為2；第2個字節制定實際錯誤類型。

總結

SSL中，使用握手協議協商加密和MAC算法以及保密密鑰?，使用握手協議對交換的數據進行加密和簽名，使用警報協議定義數據傳輸過程中，出現問題如何去解決。

SSL/TLS握手過程可以分成兩種類型：

SSL/TLS 雙向認證，就是雙方都會互相認證，也就是兩者之間將會交換證書。
SSL/TLS 單向認證，客戶端會認證服務器端身份，而服務器端不會去對客戶端身份進行驗證。

注意事項

生成對話密鑰一共需要三個隨機數。(客戶端生成隨機數、服務器生成隨機數、客戶端使用服務器公鑰加密的隨機數)；考慮到中間人攻擊，中間人可以獲得客戶端生成隨機數、服務器生成隨機數和對稱加密使用的算法，安全性完全依靠第三個加密的隨機數（客戶端使用服務器公鑰加密的隨機數）,盡管只要服務器的公鑰足夠長，破解的難度很大。因此部分算法使用?DH密鑰交換算法，參見參考鏈接；不需要使用第三個參數，僅僅根據先前傳遞的隨機數計算這個隨機數
握手之后的對話使用"對話密鑰"加密（對稱加密），服務器的公鑰和私鑰只用于加密和解密"對話密鑰"（非對稱加密），無其他作用。
服務器公鑰放在服務器的數字證書之中。

?第三步和第四步由傳遞Premaster secret變成了傳遞DH算法所需的參數，然后雙方各自算出Premaster secret。這樣就提高了安全性

Session恢復

如果出于某種原因，對話中斷，就需要重新握手。這時有兩種方法可以恢復原來的session：一種叫做session ID，另一種叫做session ticket。

session ID

session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且服務器有這個編號的記錄，雙方就可以重新使用已有的"對話密鑰"，而不必重新生成一把。
session ID是目前所有瀏覽器都支持的方法，但是它的缺點在于session ID往往只保留在一臺服務器上。所以，如果客戶端的請求發到另一臺服務器，就無法恢復對話。session ticket就是為了解決這個問題而誕生的，目前只有Firefox和Chrome瀏覽器支持。