經過前兩章的學習，我們知道了通訊安全的定義以及TLS對其的實現~有了這些知識作為基礎，我們現在可以正式的開始研究HTTPS和TLS協議了。嗯……現在才真正開始。
我記得之前大概聊過，當你在瀏覽器的位址列輸入一個URL地址會發生什麼，大致是瀏覽器從URI中獲取協議名和域名，獲取預設埠號，再用DNS解析出IP地址，然後就可以三次握手與網站建立TCP連線了，然後就會立即進行報文的傳遞。
但是在HTTPS中，三次握手後，還不能立即傳送報文，它還需要再用另外一個握手過程，在TCP上建立安全連線，之後才是收發HTTP報文。
這個握手過程與TCP類似，是HTTPS和TLS協議裡最重要、最核心的部分，搞懂了TLS握手，你就掌握了HTTPS。
一、TLS協議的組成
在講TLS握手之前，我們先來了解下TLS協議的組成。
TLS 包含幾個子協議，你也可以理解為它是由幾個不同職責的模組組成，比較常用的有記錄協議、警報協議、握手協議、變更密碼規範協議等。
記錄協議（Record Protocol）規定了 TLS 收發資料的基本單位：記錄（record）。它有點像是 TCP 裡的 segment，所有的其他子協議都需要透過記錄協議發出。但多個記錄資料可以在一個 TCP 包裡一次性發出，也並不需要像 TCP 那樣返回 ACK。
警報協議（Alert Protocol）的職責是向對方發出警報資訊，有點像是 HTTP 協議裡的狀態碼。比如，protocol_version 就是不支援舊版本，bad_certificate 就是證書有問題，收到警報後另一方可以選擇繼續，也可以立即終止連線。
握手協議（Handshake Protocol）是 TLS 裡最複雜的子協議，要比 TCP 的 SYN/ACK 複雜的多，瀏覽器和伺服器會在握手過程中協商 TLS 版本號、隨機數、密碼套件等資訊，然後交換證書和金鑰引數，最終雙方協商得到會話金鑰，用於後續的混合加密系統。
最後一個是變更密碼規範協議（Change Cipher Spec Protocol），它非常簡單，就是一個“通知”，告訴對方，後續的資料都將使用加密保護。那麼反過來，在它之前，資料都是明文的。
其中握手協議是最最重要的，也是本章的重點。我們先來看張簡要圖：
我們來分析下上圖，我們可以粗略的看到三種顏色，嗯……沒錯，我們還可以看到兩次資料的往返。嗯……也沒錯。
首先，圖中的每一個圓角框，就是一個record，就是一個記錄。多個記錄可以組合成一個TCP包傳送。所以最多兩次往返，4個訊息，就可以完成握手，然後底下的紫色部分，就是加密後的資訊了。
其次，在TLS握手完成之前，也就是出現ChangeCipherSpec之前，所有的訊息都是明文傳輸的。欸？明文傳輸，那不會洩露交換的資料麼？這個問題我就不回答了，回憶一下我們前兩章講的東西。
最後，我們簡要的看詞說話一下，首先客戶端會發起一個訊息，攜帶了TLS的版本號，客戶端隨機數，還有一個Cipher Suites，Cipher Suites是啥呢？就是密碼套件。還記得我們之前說過，客戶端會把它支援的密碼套件傳送給伺服器，讓伺服器來選擇一個。然後呢，伺服器會把一大堆東西傳給客戶端，其中包括TLS版本、伺服器的隨機數、和Cipher Suite、然後還有其它的訊息，比如伺服器證書Certificate，比如PubKey，就是伺服器的公鑰，再有就是傳一個Server完事的資料。下一波呢，客戶端會傳一個PubKey給伺服器，還有ChangeCipherSpec以及結束標記傳送給伺服器。伺服器也返回結束。接下來就開始加密傳輸了。
當然，這是簡單的過程，大家先消化一下，接下來我們再看看詳細的流程：
嗯……這張圖確實有點大。不用怕啦，我們一點一點來分析，其實這張圖就是我們本章要講的重點了，都在這張圖裡了。
第一部分，很好理解，我相信大家都很熟悉了，就是TCP的三次握手嘛~不說了。
TCP握手完成之後，就是第二部分，也就是第一個來回。我就不截圖了，大家看上面的就好了。瀏覽器會首先發一個“Client Hello”訊息，也就是跟伺服器“打招呼”。裡面有客戶端的版本號、支援的密碼套件，還有一個隨機數（Client Random），用於後續生成會話金鑰。
Handshake Protocol: Client Hello Version: TLS 1.2 (0x0303) Random: 1cbf803321fd2623408dfe… Cipher Suites (17 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
伺服器在收到”Client Hello“後，會返回一個”Server Hello“訊息。把版本號對一下，也給出一個隨機數（Server Random），然後從客戶端的列表裡選一個作為本次通訊使用的密碼套件，比如下面的程式碼選擇了“TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384”。
Handshake Protocol: Server Hello Version: TLS 1.2 (0x0303) Random: 0e6320f21bae50842e96… Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
然後，伺服器為了證明自己的身份，就把證書也發給了客戶端（Server Certificate）。
接下來是一個關鍵的操作，因為伺服器選擇了 ECDHE 演算法，所以它會在證書後傳送“Server Key Exchange”訊息，裡面是橢圓曲線的公鑰（Server Params），用來實現金鑰交換演算法，再加上自己的私鑰簽名認證。
Handshake Protocol: Server Key Exchange EC Diffie-Hellman Server Params Curve Type: named_curve (0x03) Named Curve: x25519 (0x001d) Pubkey: 3b39deaf00217894e... Signature Algorithm: rsa_pkcs1_sha512 (0x0601) Signature: 37141adac38ea4...
然後就是”Server Hello Done“訊息，伺服器的資訊就傳遞完了。
這樣，第一部分訊息往返就結束了，消耗了兩個TCP包，結果是客戶端和伺服器透過明文共享了三個資訊：Client Random、Server Random、Server Params。
此刻，客戶端拿到了伺服器給的證書證明伺服器它是它，但是客戶端怎麼知道這個證書是真的呢？嗯，就是我們之前講的信任鏈的追溯了，確認證書的真實性後，再用證書公鑰驗證簽名，就確認了伺服器的身份。
然後，我們看第三部分，客戶端按照密碼套件的要求，也生產一個橢圓曲線的公鑰（Client Params），用“Client Key Exchange”訊息發給伺服器。
Handshake Protocol: Client Key Exchange EC Diffie-Hellman Client Params Pubkey: 8c674d0e08dc27b5eaa…
現在客戶端和伺服器手裡都拿到了金鑰交換演算法的兩個引數（Client Params、Server Params），就用 ECDHE 演算法一陣算，算出了一個新的東西，叫“Pre-Master”，其實也是一個隨機數。計算過程很複雜~~特別複雜，略。
現在客戶端和伺服器手裡有了三個隨機數：Client Random、Server Random 和 Pre-Master。用這三個作為原始材料，就可以生成用於加密會話的主金鑰，叫“Master Secret”。而駭客因為拿不到“Pre-Master”，所以也就得不到主金鑰。那，為啥要三個隨機數來生成Master Secret呢？其實就是為了提高破解的複雜度。
那~~再多說兩句，Master-Secret怎麼計算出來的呢？
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)
這是RFC中的計算公式。
這裡的“PRF”就是偽隨機數函式，它基於密碼套件裡的最後一個引數，比如這次的 SHA384，透過摘要演算法來再一次強化“Master Secret”的隨機性。主金鑰有 48 位元組，但它也不是最終用於通訊的會話金鑰，還會再用 PRF 擴充套件出更多的金鑰，比如客戶端傳送用的會話金鑰（client_write_key）、伺服器傳送用的會話金鑰（server_write_key）等等，避免只用一個金鑰帶來的安全隱患。
有了主金鑰和派生的會話金鑰，握手就快結束了。客戶端發一個“Change Cipher Spec”，然後再發一個“Finished”訊息，把之前所有傳送的資料做個摘要，再加密一下，讓伺服器做個驗證。
伺服器也是同樣的操作，發“Change Cipher Spec”和“Finished”訊息，雙方都驗證加密解密 OK，握手正式結束，後面就收發被加密的 HTTP 請求和響應了。
最後，我們來看最後一部分，怎麼有點奇怪呢？客戶端怎麼在伺服器返回握手結束的訊息之前就傳送HTTP加密資料了呢？
首先，我們上圖中的握手過程，其實是TLS主流握手過程，這與傳統的握手過程有兩點不同。
第一，是使用ECDHE實現金鑰交換，而不是RSA，所以會在伺服器端傳送”Server Key Exchange“訊息。
第二，因為使用了 ECDHE，客戶端可以不用等到伺服器發回“Finished”確認握手完畢，立即就發出 HTTP 報文，省去了一個訊息往返的時間浪費。這個叫“TLS False Start”，意思就是“搶跑”，和“TCP Fast Open”有點像，都是不等連線完全建立就提前發應用資料，提高傳輸的效率。
所以你看，關鍵就在於用了ECDHE來作為核心引數生成Master Secret。
二、雙向認證
其實到這裡TLS握手的核心就基本完事了。只不過大家發現一個問題沒有，上圖中，只有伺服器傳了Certificate，讓客戶端驗證伺服器的身份。而伺服器並沒有驗證客戶端的身份。這是因為通常單向認證透過後已經建立了安全通訊，用賬號、密碼等簡單的手段就能夠確認使用者的真實身份。
但為了防止賬號、密碼被盜，有的時候（比如網上銀行）還會使用 U 盾給使用者頒發客戶端證書，實現“雙向認證”，這樣會更加安全。
熟悉不？現在知道為啥你之前去銀行的時候，銀行會給你個U盾，在網站上操作轉賬啥的時候，都必須插上U盾才行，現在知道這個U盾是用來幹啥的了吧？就是給你本地的電腦安裝證書。當然，現在好像基本上不用U盾了，直接從可信的網站上下載證書就可以了。
雙向認證的流程也沒有太多變化，只是在“Server Hello Done”之後，“Client Key Exchange”之前，客戶端要傳送“Client Certificate”訊息，伺服器收到後也把證書鏈走一遍，驗證客戶端的身份。大家可以參照本章的圖，自己理解一下噢~
三、小結
本篇，很重要，還有點複雜。大家要熟悉一下本章的兩張握手圖，理解TLS的握手過程。這個總結好像有點糊弄~~哈哈哈
哦對，大家還可以在Chrome瀏覽器裡的Security中檢視HTTPS的相關資訊。