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

未濟，亨。小狐汔濟，濡其尾，無攸利?！兑住?/strong>

六、密鑰管理

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

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

密鑰交換

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

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

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

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

密鑰交換/協(xié)商機制的幾種類型

1.依靠非對稱加密算法

• 原理：

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

• 舉例：

RSA

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

• 原理：

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

• 舉例：

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

3. 依靠通訊雙方事先已經(jīng)共享的“秘密”

• 原理：

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

• 舉例：

PSK 和 SRP

基于 RSA 的密鑰協(xié)商

概述

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

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

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

密鑰協(xié)商的步驟

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

如何防范偷窺（嗅探）

• 攻擊方式1

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

• 攻擊方式2

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

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

• 攻擊方式1

如果攻擊者在第2步篡改數(shù)據(jù)，偽造了證書，那么客戶端在第3步會發(fā)現(xiàn)（這點由證書體系保證）

• 攻擊方式2

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

基于 DH 的密鑰協(xié)商

概述

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

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

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

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

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

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

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

密鑰協(xié)商的步驟

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

如何防范偷窺（嗅探）

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

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

• 攻擊方式1

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

• 攻擊方式2

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

基于 PSK 的密鑰協(xié)商

概述

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

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

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

密鑰協(xié)商的步驟

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

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

如何防范偷窺（嗅探）

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

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

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

• 對于多帶帶使用：

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

• 對于搭配簽名算法

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

補充說明

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

基于 SRP 的密鑰協(xié)商

概述

SRP 是“Secure Remote Password”的縮寫。

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

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

密鑰存儲

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

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

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

密鑰使用

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

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

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

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

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

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

七、TSL握手

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

TSL建立連接要經(jīng)過四次握手， 握手過程又分為：

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

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

第一步：客戶端發(fā)出請求（ClientHello）

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

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

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

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

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

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

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

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

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

第三步：客戶端回應

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

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

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

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

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

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

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

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

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

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

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

握手過程擬人化說明

A：我想和你安全的通話，我這里的對稱加密算法有DESRC5 密鑰交換算法有RSA和DH， 摘要算法有MD5和SHA。
B：我們用DES－RSA－SHA這對組合好了。 這是我的證書，里面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發(fā)給A）。 目前沒有別的可說的了。
A：（查看證書上B的名字是否無誤，并通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發(fā)出警告并斷開連接，這一步保證了B的公鑰的真實性）
（產(chǎn)生一份秘密消息，這份秘密消息處理后將用作加密密鑰，加密初始化向量（IV）和hmac的密鑰。將這份秘密消息-協(xié)議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由于用了B的公鑰，保證了第三方無法竊聽）
我生成了一份秘密消息，并用你的公鑰加密了，給你（把ClientKeyExchange發(fā)給B） 注意，下面我就要用加密的辦法給你發(fā)消息了！
（將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰） [我說完了]
B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來，然后將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經(jīng)安全的協(xié)商出一套加密辦法了） 注意，我也要開始用加密的辦法給你發(fā)消息了！ [我說完了]

八、其他

HTTP與HTTPS區(qū)別小結：

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

握手過程優(yōu)化

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

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

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

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

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

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

參考鏈接：

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

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

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