SSL（“Secure Sockets Layer” 安全套接層）/TLS（“Transport Layer Security” 傳輸層安全協(xié)議）的基本思路采用的是公鑰加密算法，原理：
??????? 客戶端向服務(wù)器發(fā)送獲取公鑰的請求，服務(wù)端生成公鑰和私鑰，將公鑰返回給客戶端（這兒過程中請求和返回數(shù)據(jù)都是明文）；下次客戶端發(fā)送請求用公鑰加密，服務(wù)端用私鑰解密客戶端的請求數(shù)據(jù)
在這個過程中將存在兩個問題:
1、如何保證公鑰不會被篡改？
將公鑰放在數(shù)字證書中，只要數(shù)字證書沒有被篡改就公鑰就安全。
2、如何減少每次請求的時長（每一次請求都需要先獲取公鑰）？
每一次對話，客戶端與服務(wù)端約定好對話密鑰，對話密鑰是對稱加密的，運(yùn)算速度會非常的快，用它加密請求信息。
服務(wù)器的公鑰將只用于獲取對話密鑰本身，以減少加密算法所消耗的時長。
SSL/TLS協(xié)議的基本過程：（1、2兩步又稱為握手階段）
?????? 1. 客戶端向服務(wù)端索要公鑰、驗(yàn)證公鑰的合法性
? ? ?? 2. 雙方約定對話密鑰
? ? ?? 3. 雙方通過對話密鑰進(jìn)行信息加密
握手階段的詳細(xì)過程
?????? 一、客戶端首次請求（Client Hello）
? ? ? ? ? ? 第一步是客戶端向服務(wù)端發(fā)送Client Hello消息，消息內(nèi)容：
? ? ? 支持的協(xié)議版本號（SSL Version）
? ? ? 客戶端生成的隨機(jī)數(shù)（Client Random1）
? ? ? 客戶端支持的加密套件（Support Ciphers）比如：RSA加密算法、DH加密算法
????? 支持的壓縮算法
? ? ? 支持的一些SSL/TLS擴(kuò)展 （sever_name等） ?????
SSL Version，用于服務(wù)端驗(yàn)證支持的協(xié)議版本號。? Client Random1，隨機(jī)數(shù)用于后面對話密鑰的生成。? Support Ciphers，用于服務(wù)端選擇支持的加密算法。 壓縮算法，用于壓縮的算法。
客戶端請求中原本是不包括服務(wù)器域名的，也就是說，理論上只能包含一個服務(wù)器，對于支持多個虛擬機(jī)的服務(wù)器來說，這并不方便，不能知道向哪個服務(wù)器請求證書。為了解決這個問題，在Client Hello報文中了，擴(kuò)展信息中，增加了sever_name這個擴(kuò)展信息，通過域名進(jìn)行區(qū)分。
? ? ? 二、服務(wù)器回應(yīng)（Sever Hello、Certificate、Server Key Exchange、Server Hello Done）? ? ? ? ?
?????????? 服務(wù)端收到客戶端的請求之后向客戶端返回數(shù)據(jù)： ?????
???? 確定加密通信使用的通信版本 ??????????????
???? 服務(wù)端生成的隨機(jī)數(shù)（Sever Random）
???? 確定雙方使用的加密算法和壓縮算法
? ?? 支持的一些SSL/TLS擴(kuò)展
? ? ? ? ? 服務(wù)器發(fā)送Sever Hello后，向客戶端發(fā)送證書信息（Certificate）
? ? 服務(wù)器證書（Certificate）
? ? ? ? ? 服務(wù)器發(fā)送Certificate后，開始發(fā)送sever key exchange，向客戶端發(fā)送生成密鑰的信息。這個發(fā)送只限于使用DH算法（DH算法生成的密鑰是由客戶端參數(shù)和服務(wù)端參數(shù)根據(jù)規(guī)則計算得出），如果是RSA算法不需要發(fā)送此請求。
? ? 服務(wù)器DH參數(shù)（Sever Key Exchange）
????????? 當(dāng)服務(wù)器發(fā)送Sever Hello Done，表明所有的參數(shù)發(fā)送完成。
PS：此為單向驗(yàn)證，若是雙向驗(yàn)證，需要在Sever Hello Done之前發(fā)送Certificate Request，表示需要客戶端提供證書，內(nèi)容為：
???? 客戶端應(yīng)當(dāng)提供的證書類型
???? 服務(wù)端可以接受的證書列表
? ? ? 三、客戶端回應(yīng)（Client Key Exchange、 Change Chiper Spec、Encrypted Handshake Message）
????????? 客戶端接收到服務(wù)器的證書之后，將對接收到的證書進(jìn)行校驗(yàn)，若發(fā)現(xiàn)證書不是可信機(jī)構(gòu)頒發(fā)或者域名不正確、證書已過期，將由客戶端進(jìn)行選擇是否繼續(xù)。若證書沒有問題向服務(wù)端發(fā)送消息：
? ? 客戶端Client Key Exchange生成的一個隨機(jī)數(shù)（Pre Master Secret）
? ? 客戶端傳輸改變通知（Change Chiper Spec）
? ? 客戶端第一個加密報文（Encrypted Handshake Message）
Client Key Exchange生成一個隨機(jī)數(shù)，如果采用的是RSA加密方式則取出證書中的公鑰，生成隨機(jī)數(shù)。如果采用的是DH算法則使用雙發(fā)的DH加密參數(shù)和規(guī)則生成隨機(jī)數(shù)。Change Chiper Spec，通知服務(wù)端以后報文按照協(xié)商的加密方式傳輸。Encrypted Handshake Message，通過前兩次的隨機(jī)數(shù)以及最后一次的隨機(jī)數(shù)（Pre Master Secret）使用確定的加密算法生成對話密鑰? （Session Secret），使用對話密鑰加密報文。
PS：如果是雙向認(rèn)證，客戶端還會Certificate和Certificate Verify報文。Certificate是客戶端的證書，Certificate Verify是客戶端擁有的所有握手過程中的簽名信息。服務(wù)端對證書以及信息進(jìn)行確認(rèn)，如果發(fā)現(xiàn)證書和信息有誤則終止SSL/TLS連接。
? ? ? 四、服務(wù)端最后回應(yīng)（New Session Ticket, Change Chiper Spec, Encrypted Handshake Message）
? ? ? ? ? 服務(wù)端收到客戶端的加密報文之后進(jìn)行解密和校驗(yàn)，若成功生成一個session ticket（解釋見下文）。然后作出回應(yīng)：
? ? 服務(wù)端傳輸改變通知（Change Chiper Spec）
? ? 服務(wù)端第一個加密報文（Encrypted Handshake Message）
Change Chiper Spec與客戶端發(fā)送的含義一致，通知客戶端。 Encrypted Handshake Message與客戶端發(fā)送的第一報文含義一致，用于客戶端進(jìn)行報文驗(yàn)證。
客戶端確定密鑰以及驗(yàn)證成功之后，整個握手過程就基本完成，以后的報文都是通過協(xié)商好的密鑰進(jìn)行加密。
會話恢復(fù)（session ID 和 session ticket）
session ID
? ? ? ? Session Identifier（會話標(biāo)識符），是 TLS 握手中生成的 Session ID。服務(wù)端可以將 Session ID 協(xié)商后的信息存起來，瀏覽器也可以保存 Session ID，并在后續(xù)的 ClientHello 握手中帶上它，如果服務(wù)端能找到與之匹配的信息，就可以完成一次快速握手。
session ticket
??????? Session Identifier 機(jī)制有一些弊端，例如：1）負(fù)載均衡中，多機(jī)之間往往沒有同步 Session 信息，如果客戶端兩次請求沒有落在同一臺機(jī)器上就無法找到匹配的信息；2）服務(wù)端存儲 Session ID 對應(yīng)的信息不好控制失效時間，太短起不到作用，太長又占用服務(wù)端大量資源。
???????? 而 Session Ticket（會話記錄單）可以解決這些問題，Session Ticket 是用只有服務(wù)端知道的安全密鑰加密過的會話信息，最終保存在瀏覽器端。瀏覽器如果在 ClientHello 時帶上了 Session Ticket，只要服務(wù)器能成功解密就可以完成快速握手。
簡單的描述了下會話恢復(fù)，SSL/TLS優(yōu)化請參考這篇文章?
參考資料
