SSL握手流程
- 客戶端向服務器發送ClientHello消息，說明它支持的最高TLS協議版本，隨機數、密碼算法列表及壓縮方法。
- 服務器回覆ServerHello消息，包含基於客戶端ClientHello消息所選擇的TLS協議版本，隨機數、密碼算法列表及壓縮方法。服務器選擇的協議版本爲客戶端和服務器都支持的最高版本。
- 當雙方知道了鏈接參數，服務器向客戶端發送證書。
- 客戶端驗證服務器證書的合法性，包括：服務器證書是否過時、發行服務器證書的CA是否可靠、發行CA的公鑰可否正確解開服務器證書的發行CA的數字簽名、服務器證書上的域名是否和服務器的實際域名相匹配。若是合法性驗證沒有經過，通信將斷開；若是合法性驗證經過，將繼續進行第5步。
- 客戶端隨機產生一個用於後面通信的「對稱密碼」，而後用服務器的公鑰（服務器的公鑰從步驟3中的服務器證書中得到）對其加密，而後將加密後的「預主密碼」傳給服務器。
- 若是服務器要求客戶端的身份認證（在握手過程當中爲可選），客戶端能夠創建一個隨機數而後對其進行數據簽名，將這個含有簽名的隨機數和客戶端本身的證書以及加密過的「預主密碼」一塊兒傳給服務器。
- 若是服務器要求客戶端的身份認證，服務器必須檢驗客戶端證書和簽名隨機數的合法性，具體的合法性驗證包括：客戶端證書是否過時，發行客戶端證書的CA是否可靠，發行CA的公鑰可否正確解開客戶端證書的發行CA的數字簽名，檢查客戶端證書是否在證書廢止列表（CRL）中。若是合法性驗證沒有經過，通信馬上中斷；若是合法性驗證經過，服務器將用本身的私鑰解開加密的「預主密碼」，而後執行一系列步驟來產生主通信密碼（客戶端也將經過一樣的方法產生相同的主通信密碼）。
- 服務器和客戶端用相同的主密碼即「通話密碼」，一個對稱密鑰用於SSL協議的安全數據通信的加解密通信。同時在SSL通信過程當中還要完成數據通信的完整性，防止數據通信中的任何變化。
- 客戶端向服務器發出信息，指明後面的數據通信將使用的步驟8中的主密碼爲對稱密鑰，同時通知服務器客戶端的握手過程結束。
- 服務器向客戶端發出信息，指明後面的數據通信將使用的步驟8中的主密碼爲對稱密鑰，同時通知客戶端服務器的握手過程結束。
- SSL的握手部分結束，SSL安全通道的數據通信開始，客戶端和服務器開始使用相同的對稱密鑰進行數據通信，同時進行通信完整性的檢驗。
單向認證vs雙向認證
上面所述的是雙向認證SSL協議的具體通信過程，這種狀況要求服務器和客戶端雙方都有證書。單向認證SSL協議不須要客戶端擁有CA證書，具體的流程相對於上面的步驟，只需將服務器驗證客戶端證書的步驟去掉，以及在協商對稱密碼方案，對稱通話密鑰時，服務器發送給客戶端的是沒有加過密的（這並不影響SSL過程的安全性）密碼方案。這樣，雙方具體的通信內容，就是加密過的數據。若是有第三方攻擊，得到的只是加密的數據，第三方要得到有用的信息，就須要對加密的數據進行解密，這時候的安全就依賴於密碼方案的安全。而幸運的是，目前所用的密碼方案，只要通信密鑰長度足夠的長，就足夠的安全。這也是咱們強調要求使用128位加密通信的緣由。算法
通常Web應用都是採用單向認證的，緣由很簡單，用戶數目普遍，且無需作在通信層作用戶身份驗證，通常都在應用邏輯層來保證用戶的合法登入。但若是是企業應用對接，狀況就不同，可能會要求對客戶端（相對而言）作身份驗證。這時就須要作雙向認證。安全