1.SSL/TLS握手 簡化版

注意:

過程有所簡化,比方說在正式使用會話金鑰通話前,瀏覽器和伺服器各自會發送一段用會話金鑰加密的 Finish 訊息,以檢驗之前通過握手建立起來的加解密通道是否成功, 詳細版請看下文

2.先行知識

SSL和TLS的概念與區別

• 什麼是SSL? SSL（Secure Socket Layer，安全套接字層），為Netscape所研發，用以保障在Internet上資料傳輸之安全，利用資料加密(Encryption)技術，可確保資料在網路上之傳輸過程中不會被擷取。當前版本為3.0。它已被廣泛地用於Web瀏覽器與伺服器之間的身份認證和加密資料傳輸。 SSL協議位於TCP/IP協議與各種應用層協議之間，為資料通訊提供安全支援。SSL協議可分為兩層： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供資料封裝、壓縮、加密等基本功能的支援。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的資料傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密金鑰等。
• 什麼是TLS? TLS(Transport Layer Security，傳輸層安全協議)，用於兩個應用程式之間提供保密性和資料完整性。 TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務組）制定的一種新的協議，它建立在SSL 3.0協議規範之上，是SSL 3.0的後續版本，可以理解為SSL 3.1(可簡單理解為同一事物不同階段的不同稱呼)，它是寫入了 RFC 的。該協議由兩層組成： TLS 記錄協議（TLS Record）和 TLS 握手協議（TLS Handshake）。較低的層為 TLS 記錄協議，位於某個可靠的傳輸協議（例如 TCP）上面。
• SSL和TLS的主要區別? TLS的主要目標是使SSL更安全，並使協議的規範更精確和完善。另外,TLS版本號也與SSL的不同(TLS的版本1.0使用的版本號為SSLv3.1).

“對稱加密”和“非對稱加密”的概念

• 什麼是“加密”和“解密”？ 通俗而言，你可以把“加密”和“解密”理解為某種【互逆的】數學運算。就好比“加法和減法”互為逆運算、“乘法和除法”互為逆運算。 “加密”的過程，就是把“明文”變成“密文”的過程；反之，“解密”的過程，就是把“密文”變為“明文”。在這兩個過程中，都需要一個關鍵的東東——叫做“金鑰”——來參與數學運算。

• 什麼是“對稱加密”？ 所謂的“對稱加密技術”，意思就是說：“加密”和“解密”使用【相同的】金鑰。這個比較好理解。就好比你用 7zip 或 WinRAR 建立一個帶密碼（口令）的加密壓縮包。當你下次要把這個壓縮檔案解開的時候，你需要輸入【同樣的】密碼。在這個例子中，密碼/口令就如同剛才說的“金鑰”。

• 什麼是“非對稱加密”？ 所謂的“非對稱加密技術”，意思就是說：“加密”和“解密”使用【不同的】金鑰。這玩意兒比較難理解，也比較難想到。當年“非對稱加密”的發明，還被譽為“密碼學”歷史上的一次革命。 一般來說指:加密時使用公鑰,解密時使用私鑰

• 各自有什麼優缺點？ “對稱加密”的好處是效能較好,但由於要讓客戶端掌握金鑰,需將金鑰在網路上傳輸,故不安全 “非對稱加密”的好處是限制了公鑰的能力,即用公鑰加密後只能在服務端用私鑰解密,這樣使得”解密的能力僅保留在服務端“,缺點也很明顯,這樣只能實現單向加密,客戶端沒有解密能力.另外由於”非對稱加密”涉及到“複雜數學問題”,所以效能相對而言較差.

• SSL對兩種加密的利用? 為了獲得較優的效能,對話的內容用”對稱加密”,而對於”對稱加密”帶來的金鑰傳輸問題,則由”非對稱加密”來解決,由於客戶端沒有”非對稱加密”的解密能力,所以金鑰由客戶端來產生並用公鑰加密傳輸給服務端,這樣就(在思路上)解決了金鑰傳輸的安全問題和對話資料解密的效能問題.

CA 證書的原理及用途

• 什麼是證書？

　　“證書”洋文也叫“digital certificate”或“public key certificate”（專業的解釋看“這裡”）。 　　它是用來證明某某東西確實是某某東西的東西（是不是像繞口令？）。通俗地說，證書就好比例子裡面的公章。通過公章，可以證明該介紹信確實是對應的公司發出的。 　　理論上，人人都可以找個證書工具，自己做一個證書。那如何防止壞人自己製作證書出來騙人捏？請看後續 CA 的介紹。

　　CA是Certificate Authority的縮寫，也叫“證書授權中心”。（專業的解釋看“這裡”） 　　它是負責管理和簽發證書的第三方機構，就好比例子裡面的中介——C 公司。一般來說，CA必須是所有行業和所有公眾都信任的、認可的。因此它必須具有足夠的權威性。就好比A、B兩公司都必須信任C公司，才會找 C 公司作為公章的中介。

　　CA 證書，顧名思義，就是CA頒發的證書。 　　前面已經說了，人人都可以找工具製作證書。但是你一個小破孩製作出來的證書是沒啥用處的。因為你不是權威的CA機關，你自己搞的證書不具有權威性。 　　這就好比上述的例子裡，某個壞人自己刻了一個公章，蓋到介紹信上。但是別人一看，不是受信任的中介公司的公章，就不予理睬。壞蛋的陰謀就不能得逞啦。 　　文字後續提及的證書，若無特殊說明，均指 CA 證書。

　　在俺的例子裡談到，引入中介後，業務員要同時帶兩個介紹信。第一個介紹信包含了兩個公章，並註明，公章C信任公章A。證書間的信任關係，就和這個類似。就是用一個證書來證明另一個證書是真實可信滴。

　　實際上，證書之間的信任關係，是可以巢狀的。比如，C 信任 A1，A1 信任 A2，A2 信任 A3……這個叫做證書的信任鏈。只要你信任鏈上的頭一個證書，那後續的證書，都是可以信任滴。

　　“根證書”的洋文叫“root certificate”，專業的解釋看“這裡”。為了說清楚根證書是咋回事，再來看個稍微複雜點的例子。 　　假設 C 證書信任 A 和 B；然後 A 信任 A1 和 A2；B 信任 B1 和 B2。則它們之間，構成如下的一個樹形關係（一個倒立的樹）。 　　處於最頂上的樹根位置的那個證書，就是“根證書”。除了根證書，其它證書都要依靠上一級的證書，來證明自己。那誰來證明“根證書”可靠捏？實際上，根證書自己證明自己是可靠滴（或者換句話說，根證書是不需要被證明滴）。

客戶端需要對服務端的證書進行檢查，如果證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。如果證書沒有問題，客戶端就會從伺服器證書中取出伺服器的公鑰(公鑰從證書中獲取,證書的正確性由CA保證)

3.金鑰協商過程——TLS握手 詳細版

SSL協議分為兩部分：Handshake Protocol和Record Protocol。其中Handshake Protocol用來協商金鑰，協議的大部分內容就是通訊雙方如何利用它來安全的協商出一份金鑰。 Record Protocol則定義了傳輸的格式。

由於非對稱加密的速度比較慢，所以它一般用於金鑰交換，雙方通過公鑰演算法協商出一份金鑰，然後通過對稱加密來通訊，當然，為了保證資料的完整性，在加密前要先經過HMAC的處理。

SSL預設只進行server端的認證，客戶端的認證是可選的。以下是其流程圖（摘自TLS協議）。

SSL客戶端（也是TCP的客戶端）在TCP連結建立之後，發出一個ClientHello來發起握手，這個訊息裡面包含了自己可實現的演算法列表和其它一些需要的訊息，SSL的伺服器端會迴應一個ServerHello，這裡面確定了這次通訊所需要的演算法，然後發過去自己的證書（裡面包含了身份和自己的公鑰）。Client在收到這個訊息後會生成一個祕密訊息，用SSL伺服器的公鑰加密後傳過去，SSL伺服器端用自己的私鑰解密後，會話金鑰協商成功，雙方可以用同一份會話金鑰來通訊了。

1 客戶端發出請求（ClientHello）

由於客戶端(如瀏覽器)對一些加解密演算法的支援程度不一樣，但是在TLS協議傳輸過程中必須使用同一套加解密演算法才能保證資料能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務端，自己支援哪些加密演算法，所以客戶端需要將本地支援的加密套件(Cipher Suite)的列表傳送給服務端。除此之外，客戶端還要產生一個隨機數，這個隨機數一方面需要在客戶端儲存，另一方面需要傳送給服務端，客戶端的隨機數需要跟服務端產生的隨機數結合起來產生後面要講到的 Master Secret 。

綜上，在這一步，客戶端主要向伺服器提供以下資訊：

• 支援的協議版本，比如TLS 1.0版
• 一個客戶端生成的隨機數，稍後用於生成”對話金鑰”
• 支援的加密方法，比如RSA公鑰加密
• 支援的壓縮方法

2 伺服器迴應（SeverHello)

上圖中，從Server Hello到Server Done，有些服務端的實現是每條單獨傳送，有服務端實現是合併到一起傳送。Sever Hello和Server Done都是隻有頭沒有內容的資料。

服務端在接收到客戶端的Client Hello之後，服務端需要將自己的證書傳送給客戶端。這個證書是對於服務端的一種認證。例如，客戶端收到了一個來自於稱自己是www.alipay.com的資料，但是如何證明對方是合法的alipay支付寶呢？這就是證書的作用，支付寶的證書可以證明它是alipay，而不是財付通。證書是需要申請，並由專門的數字證書認證機構(CA)通過非常嚴格的稽核之後頒發的電子證書。頒發證書的同時會產生一個私鑰和公鑰。私鑰由服務端自己儲存，不可洩漏。公鑰則是附帶在證書的資訊中，可以公開的。證書本身也附帶一個證書電子簽名，這個簽名用來驗證證書的完整性和真實性，可以防止證書被串改。另外，證書還有個有效期。

在服務端向客戶端傳送的證書中沒有提供足夠的資訊（證書公鑰）的時候，還可以向客戶端傳送一個 Server Key Exchange，

此外，對於非常重要的保密資料，服務端還需要對客戶端進行驗證，以保證資料傳送給了安全的合法的客戶端。服務端可以向客戶端發出 Cerficate Request 訊息，要求客戶端傳送證書對客戶端的合法性進行驗證。比如，金融機構往往只允許認證客戶連入自己的網路，就會向正式客戶提供USB金鑰，裡面就包含了一張客戶端證書。

跟客戶端一樣，服務端也需要產生一個隨機數傳送給客戶端。客戶端和服務端都需要使用這兩個隨機數來產生Master Secret。

最後服務端會發送一個Server Hello Done訊息給客戶端，表示Server Hello訊息結束了。

綜上，在這一步，伺服器的迴應包含以下內容：

• 確認使用的加密通訊協議版本，比如TLS 1.0版本。如果瀏覽器與伺服器支援的版本不一致，伺服器關閉加密通訊
• 一個伺服器生成的隨機數，稍後用於生成”對話金鑰”
• 確認使用的加密方法，比如RSA公鑰加密
• 伺服器證書

3 客戶端迴應（Certificate Verify）

Client Key Exchange

如果服務端需要對客戶端進行驗證，在客戶端收到服務端的 Server Hello 訊息之後，首先需要向服務端傳送客戶端的證書，讓服務端來驗證客戶端的合法性。

Certificate Verify 接著，客戶端需要對服務端的證書進行檢查，如果證書不是可信機構頒佈、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通訊。如果證書沒有問題，客戶端就會從伺服器證書中取出伺服器的公鑰。然後，向伺服器傳送下面三項資訊：

• 一個隨機數。該隨機數用伺服器公鑰加密，防止被竊聽
• 編碼改變通知，表示隨後的資訊都將用雙方商定的加密方法和金鑰傳送
• 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面傳送的所有內容的hash值，用來供伺服器校驗 上面第一項的隨機數，是整個握手階段出現的第三個隨機數，它是客戶端使用一些加密演算法(例如：RSA, Diffie-Hellman)產生一個48個位元組的Key，這個Key叫 PreMaster Secret，很多材料上也被稱作 PreMaster Key。

ChangeCipherSpec ChangeCipherSpec是一個獨立的協議，體現在資料包中就是一個位元組的資料，用於告知服務端，客戶端已經切換到之前協商好的加密套件（Cipher Suite）的狀態，準備使用之前協商好的加密套件加密資料並傳輸了。

在ChangecipherSpec傳輸完畢之後，客戶端會使用之前協商好的加密套件和Session Secret加密一段 Finish 的資料傳送給服務端，此資料是為了在正式傳輸應用資料之前對剛剛握手建立起來的加解密通道進行驗證。

4 伺服器的最後迴應（Server Finish）

服務端在接收到客戶端傳過來的 PreMaster 加密資料之後，使用私鑰對這段加密資料進行解密，並對資料進行驗證，也會使用跟客戶端同樣的方式生成 Session Secret，一切準備好之後，會給客戶端傳送一個 ChangeCipherSpec，告知客戶端已經切換到協商過的加密套件狀態，準備使用加密套件和 Session Secret加密資料了。之後，服務端也會使用 Session Secret 加密一段 Finish 訊息傳送給客戶端，以驗證之前通過握手建立起來的加解密通道是否成功。

根據之前的握手資訊，如果客戶端和服務端都能對Finish資訊進行正常加解密且訊息正確的被驗證，則說明握手通道已經建立成功，接下來，雙方可以使用上面產生的Session Secret對資料進行加密傳輸了。

4. 附：金鑰協商的形象化比喻

如果上面的說明不夠清晰，這裡我們用個形象的比喻，我們假設A與B通訊，A是SSL客戶端，B是SSL伺服器端，加密後的訊息放在方括號[]裡，以突出明文訊息的區別。雙方的處理動作的說明用圓括號（）括起。

A：我想和你安全的通話，我這裡的對稱加密演算法有DES,RC5,金鑰交換演算法有RSA和DH，摘要演算法有MD5和SHA。

B：我們用DES－RSA－SHA這對組合好了。 這是我的證書，裡面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發給A）。 目前沒有別的可說的了。

A：（檢視證書上B的名字是否無誤，並通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發出警告並斷開連線，這一步保證了B的公鑰的真實性） （產生一份祕密訊息，這份祕密訊息處理後將用作加密金鑰，加密初始化向量（IV）和hmac的金鑰。將這份祕密訊息-協議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的訊息。由於用了B的公鑰，保證了第三方無法竊聽） 我生成了一份祕密訊息，並用你的公鑰加密了，給你（把ClientKeyExchange發給B） 注意，下面我就要用加密的辦法給你發訊息了！ （將祕密訊息進行處理，生成加密金鑰，加密初始化向量和hmac的金鑰） [我說完了]

B：（用自己的私鑰將ClientKeyExchange中的祕密訊息解密出來，然後將祕密訊息進行處理，生成加密金鑰，加密初始化向量和hmac的金鑰，這時雙方已經安全的協商出一套加密辦法了） 注意，我也要開始用加密的辦法給你發訊息了！ [我說完了]

A: [我的祕密是…]

B: [其它人不會聽到的…]

5.參考