摘要：公開密鑰加密的出現大大減輕了交換對稱密鑰的困難，公鑰可以公開透過不安全可被竊聽的渠道發送，用以加密明文。當與配合使用，稱之為，與配合則稱為，以此類推。這步沒有簽名，服務端收到數據后不會發現被篡改。對于認證機構，一旦私鑰外泄，將可能導致整

未濟，亨。小狐汔濟，濡其尾，無攸利。——《易》

六、密鑰管理

當不再擔心身份會被冒充、篡改之后，我們再來詳細談談網絡通信中對于加密算法的密鑰管理。

在密鑰被簽發后，密鑰管理一般有三個步驟：交換、存儲和使用。其中最重要也是最難的點在于密鑰交換。

密鑰交換

進行安全通信之前，各用戶間需要確立加密程序的細節，尤其是密鑰。在對稱密鑰加密系統，各用戶間需要確立共同使用的單一密鑰，此步驟即密鑰交換。

前面章節已經提過，交換對稱密鑰必須透過另一安全的通信管道進行；否則，如果以明文形式在網絡發送，將使竊聽者能夠立即得知密鑰以及據其加密的數據。以前，交換密稱密鑰是非常麻煩的，可能需要使外交郵袋等安全渠道。

公開密鑰加密的出現大大減輕了交換對稱密鑰的困難，公鑰可以公開（透過不安全、可被竊聽的渠道）發送，用以加密明文。不過，公鑰加密在在計算上相當復雜，性能欠佳、遠遠不比對稱加密。

因此，在一般實際情況下，往往通過公鑰加密來隨機創建臨時的對稱秘鑰，亦即對話鍵，然后才通過對稱加密來傳輸大量、主體的數據。（也叫混合加密算法）

密鑰交換/協商機制的幾種類型

1.依靠非對稱加密算法

• 原理：

拿到公鑰的一方先生成隨機的會話密鑰，然后利用公鑰加密它；再把加密結果發給對方，對方用私鑰解密；于是雙方都得到了會話密鑰。

• 舉例：

RSA

2. 依靠專門的密鑰交換算法

• 原理：

這個原理比較復雜，一兩句話說不清楚，待會兒聊到 DH 的那個章節會詳談。

• 舉例：

DH 算法及其變種（ECDH算法）

3. 依靠通訊雙方事先已經共享的“秘密”

• 原理：

既然雙方已經有共享的秘密（這個“秘密”可能已經是一個密鑰，也可能只是某個密碼/password），只需要根據某種生成算法，就可以讓雙方產生相同的密鑰（并且密鑰長度可以任意指定）

• 舉例：

PSK 和 SRP

基于 RSA 的密鑰協商

概述

這大概是 SSL 最古老的密鑰協商方式——早期的 SSLv2 只支持一種密鑰協商機制，就是它。（前一篇）介紹身份認證重要性的時候，也是拿 RSA 來演示。

RSA 是一種【非】對稱加密算法。特點是：加密和解密用使用【不同的】密鑰。

并且“非對稱加密算法”既可以用來做“加密/解密”，還可以用來做“數字簽名”。

密鑰協商的步驟

1. 客戶端連上服務端
2. 服務端發送 CA 證書給客戶端
3. 客戶端驗證該證書的可靠性
4. 客戶端從 CA 證書中取出公鑰
5. 客戶端生成一個隨機密鑰 k，并用這個公鑰加密得到 k
6. 客戶端把 k 發送給服務端
7. 服務端收到 k 后用自己的私鑰解密得到 k
8. 此時雙方都得到了密鑰 k，協商完成

如何防范偷窺（嗅探）

• 攻擊方式1

攻擊者雖然可以監視網絡流量并拿到公鑰，但是【無法】通過公鑰推算出私鑰（這點由 RSA 算法保證）

• 攻擊方式2

攻擊者雖然可以監視網絡流量并拿到 k，但是攻擊者沒有私鑰，【無法解密】 k，因此也就無法得到 k

如何防范篡改（假冒身份）

• 攻擊方式1

如果攻擊者在第2步篡改數據，偽造了證書，那么客戶端在第3步會發現（這點由證書體系保證）

• 攻擊方式2

如果攻擊者在第6步篡改數據，偽造了k，那么服務端收到假的k之后，解密會失敗（這點由 RSA 算法保證）。服務端就知道被攻擊了。

基于 DH 的密鑰協商

概述

DH 算法又稱“Diffie–Hellman 算法”。這是兩位數學牛人的名稱，他們創立了這個算法。該算法用來實現【安全的】“密鑰交換”。它可以做到——“通訊雙方在完全沒有對方任何預先信息的條件下通過不安全信道創建起一個密鑰”。這句話比較繞口，通俗地說，可以歸結為兩個優點：

1. 通訊雙方事先【不】需要有共享的秘密。
2. 用該算法協商密碼，即使協商過程中被別人全程偷窺（比如“網絡嗅探”），偷窺者也【無法】知道協商得出的密鑰是啥。

但是 DH 算法本身也有缺點——它不支持認證。

也就是說：它雖然可以對抗“偷窺”，卻無法對抗“篡改”，自然也就無法對抗“中間人攻擊/MITM”（前一篇已經強調過——缺乏身份認證，【必定會】遭到“中間人攻擊/MITM”）。

為了避免遭遇 MITM 攻擊，DH 需要與其它簽名算法（比如 RSA、DSA、ECDSA）配合——靠簽名算法幫忙來進行身份認證。當 DH 與 RSA 配合使用，稱之為“DH-RSA”，與 DSA 配合則稱為“DH-DSA”，以此類推。

反之，如果 DH 【沒有】配合某種簽名算法，則稱為“DH-ANON”（ANON 是“anonymous”（匿名）的簡寫）。此時會遭遇“中間人攻擊/MITM”。

關于該算法具體數學原理，可以參見迪菲-赫爾曼密鑰交換。

密鑰協商的步驟

1. 客戶端先連上服務端
2. 服務端生成一個隨機數 s 作為自己的私鑰，然后根據算法參數計算出公鑰 S（算法參數通常是固定的）
3. 服務端使用某種簽名算法把“算法參數（模數p，基數g）和服務端公鑰S”作為一個整體進行簽名
4. 服務端把“算法參數（模數p，基數g）、服務端公鑰S、簽名”發送給客戶端
5. 客戶端收到后驗證簽名是否有效
6. 客戶端生成一個隨機數 c 作為自己的私鑰，然后根據算法參數計算出公鑰 C
7. 客戶端把 C 發送給服務端
8. 客戶端和服務端（根據上述 DH 算法）各自計算出 k 作為會話密鑰

如何防范偷窺（嗅探）

嗅探者可以通過監視網絡傳輸，得到算法參數（模數p，基數g）以及雙方的公鑰，但是【無法】推算出雙方的私鑰，也【無法】推算出會話密鑰（這是由 DH 算法在數學上保證的）

如何防范篡改（假冒身份）

• 攻擊方式1

攻擊者可以第4步篡改數據（修改算法參數或服務端公鑰）。但因為這些信息已經進行過數字簽名。篡改之后會被客戶端發現。

• 攻擊方式2

攻擊者可以在第7步篡改客戶端公鑰。這步沒有簽名，服務端收到數據后不會發現被篡改。但是，攻擊者篡改之后會導致“服務端與客戶端生成的會話密鑰【不一致】”。在后續的通訊步驟中會發現這點，并導致通訊終止。
（協議初始化/握手階段的末尾，雙方都會向對方發送一段“驗證性的密文”，這段密文用各自的會話密鑰進行【對稱】加密，如果雙方的會話密鑰不一致，這一步就會失敗，進而導致握手失敗，連接終止）

基于 PSK 的密鑰協商

概述

PSK 是“Pre-Shared Key”的縮寫。顧名思義，就是【預先】讓通訊雙方共享一些密鑰（通常是【對稱加密】的密鑰）。所謂的【預先】，就是說，這些密鑰在 TLS 連接尚未建立之前，就已經部署在通訊雙方的系統內了。

這種算法用的不多，它的好處是：

1. 不需要依賴公鑰體系，不需要部屬 CA 證書。
2. 不需要涉及非對稱加密，TLS 協議握手（初始化）時的性能好于前述的 RSA 和 DH。 更多介紹可以參見維基百科，鏈接在“這里”。

密鑰協商的步驟

（由于 PSK 用的不多，下面只簡單介紹一下步驟，讓大伙兒明白其原理）

• 在通訊【之前】，通訊雙方已經預先部署了若干個共享的密鑰。
• 為了標識多個密鑰，給每一個密鑰定義一個唯一的 ID
• 協商的過程很簡單：客戶端把自己選好的密鑰的 ID 告訴服務端。
• 如果服務端在自己的密鑰池子中找到這個 ID，就用對應的密鑰與客戶端通訊；否則就報錯并中斷連接。

如何防范偷窺（嗅探）

使用這種算法，在協商密鑰的過程中交換的是密鑰的標識（ID）而【不是】密鑰本身。 就算攻擊者監視了全過程，也無法知曉密鑰是什么。

如何防范篡改（假冒身份）

PSK 可以多帶帶使用，也可以搭配簽名算法一起使用。

• 對于多帶帶使用：

如果攻擊者篡改了協商過程中傳送的密鑰 ID，要么服務端發現 ID 無效（協商失敗），要么服務端得到的 ID 與客戶端不一致，在后續的通訊步驟中也會發現，并導致通訊終止。
（協議初始化/握手階段的末尾，雙方都會向對方發送一段“驗證性的密文”，這段密文用各自的會話密鑰進行【對稱】加密，如果雙方的會話密鑰不一致，這一步就會失敗，進而導致握手失敗，連接終止）

• 對于搭配簽名算法

如果攻擊者篡改了協商過程中傳送的密鑰 ID，驗證簽名會失敗

補充說明

PSK 與 RSA 具有某種相似性——既可以用來搞“密鑰協商”，也可以用來搞“身份認證”。 所以，PSK 可以跟 DH（及其變種）進行組合。例如：DHE-PSK、ECDHE-PSK

基于 SRP 的密鑰協商

概述

SRP 是“Secure Remote Password”的縮寫。

這個算法有點類似于剛才提到的 PSK——只不過 client/server 雙方共享的是比較人性化的密碼（password）而不是密鑰（key）。該算法采用了一些機制（鹽/salt、隨機數）來防范“嗅探/sniffer”或“字典猜解攻擊”或“重放攻擊”。

這個算法應該用得很少——OpenSSL 直到2012年才開始支持該算法。所以這里就不展開了，有興趣的同學可以去看 RFC2945 的協議描述

密鑰存儲

對稱加密使用的單一密鑰會被收發雙方存儲，公開密鑰加密的私鑰由于還有數字簽名的功能，所以都必須安全存儲，以保障通信安全。業界已發展出各種各樣的技術來保障密鑰得到妥善存儲，包括定期或不定的系統檢測是否有入侵之虞、對存儲媒體或服務器提供高強度的物理防護及監控。

最常見的是加密應用程序負責管理用戶的密鑰，使用密鑰時則需要輸入認別用戶的訪問密碼。對于認證機構，一旦私鑰外泄，將可能導致整個信任鏈被摧毀，影響廣及眾多客戶，所以認證機構會使用硬件安全模塊，有些存儲私鑰的計算機甚至平時不會連線，只在固定的調度下，經過一系列嚴謹的行政程序重重把關，才會取出私鑰為客戶簽名證書。

在信任鏈設計中，絕大部分的根證書都不會直接為客戶簽名，而是先簽名一個（或多個）中繼證書，再由中繼證書為客戶簽名，這可以加強控管能力及控制一旦簽名私鑰被泄時的損失。

密鑰使用

密鑰的有效期限是一個重要問題，一個密鑰應該在產生后多久被汰換呢？

密鑰汰換之后，舊有的密鑰就無法再解密新產生的密文，喪失對竊聽者的價值，這會增加了攻擊者所需要投入的氣力，所以密鑰應該經常替換。

同時，這也可以減低信息一旦被破解（_一般是回溯性破解【注1】_）時的損失：因為竊聽者可能在破解密鑰之前一直存儲截取到的加密消息，等待成功破解密鑰的一刻。所以密鑰更換得越頻密，竊聽者可解讀的消息就越少。

在過去，如果可靠的密鑰交換程序非常困難或者僅僅間歇可行，對稱密鑰會被長期使用。

但在理想情況下，對稱密鑰應該在每次交換消息或會話時轉換（_完美正向加密【注2】_），使得如果某一密鑰被泄（例如，被盜竊，密碼分析或社會工程化）時，只有單一消息或會話被解讀。

基于公開密鑰加密的特性，一對公鑰和私鑰的有效期一般會長于對稱加密所使用的單一密鑰，尤其是需要認證機構簽核的電子證書，當中涉及行政及部署成本，所以可能是三個月至一、兩年不等，考慮的因素包括配合加密算法的密鑰長度、存儲私鑰的強度、一旦外泄可能引致的風險、更換程序對運行中的服務的影響、以及運行成本。

七、TSL握手

有了前面的基礎知識，這章我們就來討論下TSL完整的實現過程。

TSL建立連接要經過四次握手， 握手過程又分為：

1. 單向驗證：就是server端將證書發送給客戶端，客戶端驗證server端證書的合法性等。例如百度、新浪、google等普通的https網站。
2. 雙向驗證：不僅客戶端會驗證server端的合法性，同時server端也會驗證客戶端的合法性。例如銀行網銀登陸，支付寶登陸交易等。

下面只討論單向驗證的情況：

第一步：客戶端發出請求（ClientHello）

首先，客戶端（通常是瀏覽器）先向服務器發出加密通信的請求，這被叫做ClientHello請求。

在這一步，客戶端主要向服務器提供以下信息。

（1） 支持的協議版本，比如TLS 1.0版。
（2） 一個客戶端生成的隨機數，稍后用于生成"對話密鑰"。
（3） 支持的加密方法，比如RSA公鑰加密。
（4） 支持的壓縮方法。

這里需要注意的是，客戶端發送的信息之中不包括服務器的域名。也就是說，理論上服務器只能包含一個網站，否則會分不清應該向客戶端提供哪一個網站的數字證書。這就是為什么通常一臺服務器只能有一張數字證書的原因。

對于虛擬主機的用戶來說，這當然很不方便。2006年，TLS協議加入了一個Server Name Indication擴展，允許客戶端向服務器提供它所請求的域名。

第二步：服務器回應（SeverHello）

服務器收到客戶端請求后，向客戶端發出回應，這叫做SeverHello。服務器的回應包含以下內容。

（1） 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
（2） 一個服務器生成的隨機數，稍后用于生成"對話密鑰"。
（3） 確認使用的加密方法，比如RSA公鑰加密。
（4） 服務器證書。

除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供"客戶端證書"。比如，金融機構往往只允許認證客戶連入自己的網絡，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。

第三步：客戶端回應

客戶端收到服務器回應以后，首先驗證服務器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。

如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然后，向服務器發送下面三項信息。

（1） 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。
（2） 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
（3） 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。

上面第一項的隨機數，是整個握手階段出現的第三個隨機數，又稱"pre-master key"。有了它以后，客戶端和服務器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自生成本次會話所用的同一把"會話密鑰"。

至于為什么一定要用三個隨機數，來生成"會話密鑰"，dog250解釋得很好：

"不管是客戶端還是服務器，都需要隨機數，這樣生成的密鑰才不會每次都一樣。由于SSL協議中證書是靜態的，因此十分有必要引入一種隨機因素來保證協商出來的密鑰的隨機性。
對于RSA密鑰交換算法來說，pre-master-key本身就是一個隨機數，再加上hello消息中的隨機，三個隨機數通過一個密鑰導出器最終導出一個對稱密鑰。
pre master的存在在于SSL協議不信任每個主機都能產生完全隨機的隨機數，如果隨機數不隨機，那么pre master secret就有可能被猜出來，那么僅適用pre master secret作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶端和服務器加上pre master secret三個隨機數一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機，可是是三個偽隨機就十分接近隨機了，每增加一個自由度，隨機性增加的可不是一。"

此外，如果前一步，服務器要求客戶端證書，客戶端會在這一步發送證書及相關信息。

第四步： 服務器的最后回應

服務器收到客戶端的第三個隨機數pre-master key之后，計算生成本次會話所用的"會話密鑰"。然后，向客戶端最后發送下面信息。

（1）編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
（2）服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。

至此，整個握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協議，只不過用"會話密鑰"加密內容。

握手過程擬人化說明

A：我想和你安全的通話，我這里的對稱加密算法有DESRC5 密鑰交換算法有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的密鑰，這時雙方已經安全的協商出一套加密辦法了） 注意，我也要開始用加密的辦法給你發消息了！ [我說完了]

八、其他

HTTP與HTTPS區別小結：

1. HTTP 的URL 以http:// 開頭，而HTTPS 的URL 以https:// 開頭
2. HTTP 是不安全的，而 HTTPS 是安全的
3. HTTP 標準端口是80 ，而 HTTPS 的標準端口是443
4. 在OSI 網絡模型中，HTTP工作于應用層，而HTTPS 工作在傳輸層
5. HTTP 無加密，而HTTPS 對傳輸的數據進行加密
6. HTTP無需證書，而HTTPS 需要CA機構頒發的SSL證書

握手過程優化

對于HTTP，為了避免每次請求都要經過tcp三次握手，使用了長連接技術進行優化。

而對于HTTPS，如果每次重連都要重新TSL握手也是比較消耗性能和費時的，大致有幾個優化方向：

1. Session id及session ticket的復用，縮減證書交換時間，減少可能的計算以及RTT時間 。
2. 選取相對來說計算量較小且安全的算法 。
3. 將最消耗性能和費時的握手部分，交給加速卡承擔。

在此不再詳細展開，有興趣的可以參考TLS 握手優化詳解。

回顧前篇請點擊以下鏈接：

UCloud云計算：沒那么淺地談談HTTP與HTTPS【一】?zhuanlan.zhihu.comUCloud云計算：沒那么淺地談談HTTP與HTTPS【二】?zhuanlan.zhihu.com

參考鏈接：

1. 淺談HTTPS（SSL/TLS）原理
2. SSL/TLS協議運行機制的概述
3. HTTPS證書生成原理和部署細節
4. 掃盲 HTTPS 和 SSL/TLS 協議系列
5. 數字證書及 CA 的掃盲介紹
6. RFC:The Transport layer Security (TLS) Protocol Version 1.2
7. HTTPS協議詳解(三)：PKI 體系
8. 《HTTP權威指南》 人民郵電出版社 2012

本文作者：UCloud后臺研發工程師 Hughes.Chen

博客地址：https://ulyc.github.io/