握手階段如上圖所示，可分為5步（使用Diffie – Hellman演算法）：

第一步，瀏覽器給出協議版本號、一個客戶端生成的隨機數（Client random），以及客戶端支援的加密方法。

第二步，伺服器確認雙方使用的加密方法，使用的tls版本號和一個隨機數。

第三部，並給出數字證書、以及一個伺服器執行Diffie-Hellman演算法生成的引數，比如pubkey。

第四部，瀏覽器獲取伺服器發來的pubkey，計算出另一個pubkey，發給伺服器。

第五部，伺服器發給瀏覽器一個session ticket。

下面，我們使用wireshark抓包驗證上面的握手過程。

在瀏覽器中訪問https://baidu.com, 使用ip.addr==119.75.217.109&& ssl來過濾TLS包。結果如下圖所示。

圖一

我的Chrome瀏覽器一開始就連續給伺服器傳送三個相同的“Client Hello”包，這三個包除了源埠和隨機數不一樣外，其他的部分都相同。（圖三四五所示）為什麼？後面我們會看到，最總這個connection只用了第一個“ClientHello”所建立的連線，也就是埠號為4188。所以，之所以這樣做，很可能是為了避免超時重傳從而影響使用者體驗。如下圖所示：

圖二

圖三

圖四

圖五

瀏覽器傳送一個“ClientHello”訊息，內容包括：支援的協議版本，比如TLS1.0版，一個客戶端生成的隨機數（稍後用於生成“會話金鑰”），支援的加密演算法（如RSA公鑰加密）和支援的壓縮演算法。

2.Server Hello：伺服器將其SSL版本號、加密設定引數以及其它一些必要資訊傳送給客戶端，一個伺服器生成的隨機數（稍後用於生成“對話金鑰”），確認使用的加密方法（如RSA公鑰加密），如下圖所示：

3.Certificate：伺服器發一個證書給客戶端，該證書用於向客戶端確認伺服器的身份。如果配置伺服器的SSL需要驗證伺服器的身份，會發送該訊息（多數電子商務應用都需要伺服器端身份驗證。伺服器如果需要驗證客戶端的身份，那麼伺服器會發一個“Certificate Request

瀏覽器收到伺服器發來的Certificate包來之後，執行Diffie-Hellman演算法生成一個pubkey，然後傳送給伺服器。通過這一步和上面Certificate兩個步驟，伺服器和瀏覽器分別交換了pubkey，這樣他們就可以分別生成了一個一樣的sessionkey（具體的實現過程可以參考Diffie-Hellman演算法的實現），如果你還不是很理解這個演算法，那麼這裡你只需要知道伺服器和瀏覽器向對方傳送了pubkey之後，雙方就可以計算出相同的金鑰了，並且這個過程沒有安全問題。

完成上面的步驟，可以說TLS的握手階段已經完成了，但是，伺服器還會發送一個Session Ticket給瀏覽器。如下圖所示，這個sessionticket包含了這個ticket的生命週期是兩個小時（7200s）、它的id等等資訊。這個sessionticket包有什麼做用呢？握手階段用來建立TLS連線。如果出於某種原因，對話中斷，就需要重新握手。客戶端只需傳送一個伺服器在上一次對話中傳送過來的sessionticket。這個sessionticket是加密的，只有伺服器才能解密，其中包括本次對話的主要資訊，比如對話金鑰和加密方法。當伺服器收到sessionticket以後，解密後就不必重新生成對話金鑰了。就可以繼續使用上一次的連線了。

通過上面的步驟，伺服器和瀏覽器建立了安全的連線，下面便開始傳資料了。如下圖所示。我們可以看到，它使用的是http協議，資料被加密了。前面我們也提到，一開始瀏覽器直接傳送了三個“ClientHello”包給伺服器，而最終只使用了第一個成功建立起來的TLS（埠號為4188）傳輸資料。