最近大家在使用百度、谷歌或淘寶的時(shí)(T_T)候，是不是注意瀏覽器左上角已經(jīng)全部出現了一把綠色鎖，這(/ω＼)把鎖表明該網(wǎng)站已經(jīng)使用了 HTTPS 進(jìn)行保護。仔細觀(guān)察，會(huì )發(fā)現這些網(wǎng)站已經(jīng)全站使用 HTTPS。同時(shí)，iOS 9 系統默認把所有的 http 請求都改為 HTTPS 請求。隨著(zhù)互聯(lián)網(wǎng)的發(fā)展，現代互聯(lián)網(wǎng)正在逐漸進(jìn)入全站 HTTP(′_ゝ`)S?? 時(shí)代。

因此有開(kāi)發(fā)同學(xué)會(huì )問(wèn)：

全站 HTTPS?? 能夠帶來(lái)怎樣的??優(yōu)勢?HTTPS 的原理又是什么?同時(shí)，阻礙 HTTPS 普及的困難是什么???

為了(le)解答大家的困惑，騰訊TEG架構平臺部靜態(tài)加速組高級工程師劉強，為大家綜合參考多種資┐(′д｀)┌料并經(jīng)過(guò)實(shí)踐驗證，探究 HTTPS 的(de)基礎??原理，(???)分析基本的 HTTPS 通信過(guò)程，迎接全站 HTTPS 的來(lái)臨。

1.HTTPS 基礎

HTTPS(Secure Hypertext Transfer Protocol)安全ヽ(′▽?zhuān)?ノ超文本傳輸協(xié)議 它是一個(gè)安全通信通道，它基于HTTP開(kāi)發(fā)，用于在客戶(hù)計算機和服務(wù)器之間交換信息。它(′?ω?`)使用安??全套接字層(SSL)進(jìn)行信??息交換，簡(jiǎn)單來(lái)說(shuō)它是HTTP的安全版,是使用 TLS/SSL 加密的 HTTP 協(xié)議。

HTTP 協(xié)議采用明文傳輸信息，存在信息竊聽(tīng)、信息篡改和信息劫持的風(fēng)險，而協(xié)議(′?｀*) TLS/SSL 具有身份驗證、信息加密和完整性校驗的功能，可以避免此類(lèi)問(wèn)題。

TLS??/SSL 全稱(chēng)安全傳輸層協(xié)議 Transport Layer Secu??rit??y, 是介于 TCP 和 HTTP 之間的一層安全協(xié)議，不影響原有的 TCP 協(xié)議和 HTTP 協(xié)議，所以使用?? HTTPS 基本上不需要對 HTTP 頁(yè)面進(jìn)行太多的改造。

2.TLS/SSL 原理

HTTPS 協(xié)議的主要功能基本都依賴(lài)于 TLS/SSL 協(xié)議，本節分析安全協(xié)議的實(shí)現原理。

TLS??/SS(?⊿?)L 的功能實(shí)現主要依??賴(lài)于三類(lèi)基本算法：散列函數 Hash、對稱(chēng)加密和非對稱(chēng)加密，其利用非對稱(chēng)加密實(shí)(shi)現身份認證和密鑰協(xié)商，對稱(chēng)加密算法采用協(xié)商的密鑰對數據加密，基于散列函數驗證信息的完整性。

散列函數 Hash，常見(jiàn)的有 MD5、SHA1、SHA256，該類(lèi)函數特點(diǎn)是函數單向不可逆、對輸入非常敏感、輸出長(cháng)度固定，針對數據的任何修改都會(huì )改變散列函數的結果，用于防止信息篡改并(′▽?zhuān)?驗證數據的完整性;對稱(chēng)加密，常見(jiàn)的有 AES-CBC、DES、3DES、AES-GCM等，相同的密鑰可以用于信息的加密和解密，掌握密鑰才能獲取信息，能夠防止信息竊聽(tīng)，通信方式是1對1;非對稱(chēng)加密，即常見(jiàn)的 RS?A 算法，還包括 ECC、DH 等算法，算法特點(diǎn)是，密鑰成對出現，一般稱(chēng)為公鑰(公開(kāi))和私鑰(保密)，公鑰加密的(′?｀)信息只能私鑰解開(kāi)，私鑰加密的信息只能公鑰解開(kāi)。因此掌握公鑰的不同客戶(hù)端之間不能互相解密信息，只能和掌握私鑰的服務(wù)器進(jìn)行加密通信，服務(wù)器可以實(shí)現1對多的通信，客戶(hù)端也可以用來(lái)驗證掌握私鑰的服務(wù)器身份。

在信息傳輸過(guò)程中，散列函數不能單獨實(shí)現信息防篡改，因為明文傳輸，中間人可以修改??信息之后重新計算信息摘要???，因此需要對傳輸的信息以及信息摘要進(jìn)行加密;對稱(chēng)加密的優(yōu)勢是信息傳輸1對1，需要共享相同的密碼(╬ ò﹏ó)，密碼的安全是保證信息安全的基礎，服務(wù)器和 N 個(gè)客戶(hù)端通信，需要維??持 N 個(gè)密碼記錄，且缺少修改密碼的機制;非對稱(chēng)加密的特點(diǎn)是信息傳輸1對多，服務(wù)器只需要維持一個(gè)私鑰就能??夠和(T_T)多個(gè)客戶(hù)端進(jìn)行加密通信，但服務(wù)器發(fā)出的信息能夠被所有的客戶(hù)端??ヽ(′?｀)ノ解密，且該算ヽ(′ー｀)ノ法的計算復雜，加密速度慢。

結合三類(lèi)算法的特點(diǎn)，TLS 的基本工作方式是，客戶(hù)端使ヽ(′▽?zhuān)?ノ用非對稱(chēng)加密與服務(wù)器進(jìn)行通信，實(shí)現身份驗證并協(xié)商對稱(chēng)加密使用的(′?_?`)密鑰，然后對稱(chēng)加密算法采用協(xié)商密鑰對信息以及信息摘要進(jìn)行加密通信，不同的節點(diǎn)之間采??用的對稱(chēng)密鑰不同，從而可以保證信息只能通信雙方獲取。

3.PKI 體系 3.1(//ω//) RSA 身份驗證的隱患

身份驗證和密鑰協(xié)商是 TLS 的基礎功能，要求的前提是合法的服務(wù)器掌握著(zhù)對應的私鑰(′▽?zhuān)?)。但 RSA 算法無(wú)法確保服務(wù)器身份的合法性，因為公鑰并不包含服務(wù)器的信息，存在(zai)安全隱??患:

客戶(hù)端 C 和服務(wù)器 S 進(jìn)行通信，中間節點(diǎn) M 截獲了二者的???通信;ヾ(＾-＾)ノ

節點(diǎn) M 自己計算產(chǎn)(???)生一對公鑰 pub_M 和私鑰 pri_M;

C 向 S 請求公鑰時(shí)，M(′ω｀*) 把自己的公鑰 pub_M 發(fā)給了 C;

中間節點(diǎn) M 和服務(wù)器S之間再建立合法的連接，因此 C 和 S 之(zhi)間通信被M完全掌握，M 可以進(jìn)行信息的竊??聽(tīng)、篡改等操作。

另外，服務(wù)器也可以對自己的發(fā)出的信息進(jìn)行否認，不承認相關(guān)信息是自己發(fā)出。

因此該方案下至少存在兩類(lèi)問(wèn)題：中間人攻擊和(he)信息抵賴(lài)。

3.2 身份驗證-CA 和證書(shū)

解決上述身份驗證問(wèn)題的關(guān)鍵是確保獲取的公鑰途徑是合法的，能夠驗證服務(wù)器的身份信息，為此需要引入權威的第三方機構 CAヽ(′?｀)ノ。CA 負責核實(shí)公鑰的擁有者的信息，并頒發(fā)認證”證(′?ω?`)書(shū)”，同時(shí)能夠為使用者提供證書(shū)驗證服務(wù)，即 PKI 體系。

基本的原理為，CA 負責審核信息，然后對關(guān)鍵信息利用私鑰進(jìn)行”簽名”，公開(kāi)對應的公鑰，客戶(hù)端可以利用公鑰驗證簽名。CA 也可以吊銷(xiāo)已經(jīng)簽發(fā)的證書(shū)，基本的方式包括兩類(lèi) CRL 文件和 OCSP。CA 使用具體的流程如下：??

a.服務(wù)方 S 向第三方機構CA提交公鑰、組織信息、個(gè)人信息(域名)等信息并申請認證;

b.CA 通過(guò)線(xiàn)上、線(xiàn)下等多種手段驗證申請者提供信息的真實(shí)性，如組織??是否存在、企業(yè)是否合法，是否擁有域名的所有權等;

c.如信息審核通過(guò)，CA 會(huì )向申請者簽發(fā)認證文件-證書(shū)。

證書(shū)包含以下信息：申請者公鑰、申請者的組織信息和個(gè)人信息、簽發(fā)機構 CA 的信息、有效時(shí)間、證書(shū)序列號等信息的明文，同時(shí)包含一個(gè)簽名;

簽名的產(chǎn)生(???)算法：首先，使用散列函數計算公開(kāi)的明文信息的信息摘要，然后(hou)，采用 CA 的私鑰對信息摘要進(jìn)行加密，密文即簽名;

d.客戶(hù)端 C 向服務(wù)器 S 發(fā)出請求時(shí)，S 返回證書(shū)文件;???

e.客戶(hù)端 C 讀取證書(shū)中的相關(guān)的明文信息，采用相同的散列函數計算得到信息摘?要，然后，利用對應 CA 的公鑰解密簽名數據，對比證書(shū)的信息摘要，如果一致，則可以確認證書(shū)的合法性，即公鑰合法??;

f.客戶(hù)端然后驗證證??書(shū)相關(guān)的域名信息、有效時(shí)間等信息;

g.客戶(hù)端會(huì )內置(╯°□°)╯信任 CA 的證書(shū)信息(包含公鑰)，如果CA不被信任，則找不到對應 CA 的證書(shū)，證書(shū)也會(huì )被判定非法。

在這個(gè)過(guò)程注意幾點(diǎn)：

b.證(zheng)書(shū)的合法性仍然依賴(lài)于非對稱(chēng)加密算法，證書(shū)主要是增*務(wù)器信息以及簽名??;

c.內置 CA 對應的證書(shū)稱(chēng)為根證書(shū)，頒發(fā)者和使用者相同，自己為自己簽名，即自簽名證書(shū);

d.證書(shū)=公鑰+申請者與頒發(fā)者信息+簽名;

3.3 證書(shū)鏈

如 CA 根證書(shū)和服務(wù)器證書(shū)中間增加一級證書(shū)機構，即中間證書(shū)，證書(shū)(shu)的產(chǎn)生和驗證原理不變，只是增加一層驗證，??只要最后能夠被任何信任的CA根證書(shū)驗證合法即可。

a.服務(wù)器證書(shū) server.pem 的簽發(fā)(fa)者為中間證書(shū)機構 inter，inter 根據證書(shū) inter.pem(′?ω?`) 驗證 server.pem 確實(shí)為自己簽發(fā)的有效證書(shū);

服務(wù)器證書(shū)、中間證書(shū)與根證書(shū)在一起組合成一條合法的證書(shū)鏈，(???)證書(shū)鏈的驗證是自下而上的信任傳遞的過(guò)程。

a.減少根證書(shū)結構的??管理工作量，可以更高效的進(jìn)行證書(shū)的(???)審核與簽發(fā);

b.根證書(shū)一般內置在客戶(hù)端中，私鑰一般離線(xiàn)存儲，一旦私鑰泄露，則吊銷(xiāo)過(guò)程非常困難，無(wú)法及時(shí)補救;

c.中間證書(shū)結構的私鑰泄露，則可以快速在線(xiàn)吊銷(xiāo)，并重新為用戶(hù)簽發(fā)新的證書(shū);

d.證書(shū)鏈四級以?xún)纫话悴粫?huì )對( ???) HTTPS 的性能造成明顯影響。

證書(shū)鏈有以下特點(diǎn)：

a.同一本服務(wù)器證書(shū)可能存在多條合法的證書(shū)鏈。(╥_╥)

因為證書(shū)的生成和驗證基礎(???)是公鑰和私鑰對，如果采用相同的??公鑰和私鑰生成不同的中間證書(shū)，┐(′д｀)┌針對被簽發(fā)者而言，該簽發(fā)機構都是合法的 CA??，不同的是中間證書(shū)的簽發(fā)機構不同;

b.不同證書(shū)鏈的層級不一定相同，可能二級、三級或四級證書(shū)鏈。

3.4 證書(shū)吊銷(xiāo)

CA 機構能夠簽發(fā)證書(shū)，同樣也存在機制宣布以往簽發(fā)的證書(shū)無(wú)效。證書(shū)使用者不合法，CA 需要廢棄該證書(shū);或者私鑰丟失，使用者申請讓證書(shū)無(wú)效。主要存在兩類(lèi)機制：CRL 與 OCSP。

(a) CRL

Certificate Revocation List, 證書(shū)吊銷(xiāo)列表，一個(gè)單獨的文件。該文件包(?????)含了 CA 已經(jīng)吊銷(xiāo)的??證書(shū)序列號(唯一)與吊銷(xiāo)日期，同時(shí)該(╯°□°）╯文件包含生效日期并通知下(′；ω；`)次更新該(′?_?`)文件的時(shí)間，當然該文件必然包含 CA( ?ω?) 私鑰的簽名以驗證文件的合法性。

證書(shū)中一般會(huì )包含一個(gè) URL 地址 CRL(′?ω?`) Distribution Point，通知使用者去哪里下載對應的 CRL 以校驗證書(shū)是(shi)否吊銷(xiāo)。該吊銷(xiāo)方式的優(yōu)點(diǎn)是不需要頻繁更新，但是不能及時(shí)吊?銷(xiāo)證書(shū)，因為 CRL 更新時(shí)間(′?｀*)一般是幾天，這期間??可能已經(jīng)造成了極大損失。

(b??) OCS??P

Online Certificate Status Protocol, 證書(shū)狀態(tài)在線(xiàn)查詢(xún)協(xié)議，一個(gè)實(shí)時(shí)查詢(xún)證書(shū)是否吊銷(xiāo)的方式。請求者發(fā)送證書(shū)的信息并請求查詢(xún)，ヽ(′▽?zhuān)?ノ服務(wù)器返回正常、吊銷(xiāo)或未知中( ?ω?)的任何一個(gè)狀態(tài)。證書(shū)中一般也會(huì )包含一個(gè) OCSP 的 URL 地址，要求查詢(xún)服務(wù)器具有良好的性能。部分 CA 或大部分的自簽 CA (根(T_T)證書(shū))都是未提供 CRL 或 OCSP 地址的，對于吊(╯‵□′)╯銷(xiāo)證書(shū)會(huì )是一件非常麻煩的事情。

4.TLS/SSL握手過(guò)程

4.1握手與密鑰協(xié)商過(guò)程

基于 RSA 握手和密鑰交換的客戶(hù)端驗證服務(wù)器為示例詳解握(′▽?zhuān)?手過(guò)程。

客戶(hù)端發(fā)起請求，以明文傳輸請求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機數，擴展字段等信息，相關(guān)信息如下：

支持的最高TSL協(xié)議版本version，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2，當前基本不再使用低于 TLSv1 的版本;

支持的壓縮算法 compression method??s 列表，用于后續的信息壓縮傳輸;

隨機數 random_C，用于后續的密鑰的生成;

擴展字段 extensions，支持協(xié)議與算法的相關(guān)參數以及其它輔助信息等，常見(jiàn)的 SNI 就屬于擴展字段，后續單獨討論該字段作用。

(a) server_hello, 服務(wù)端返回協(xié)商的信息結果，包括選擇使用的協(xié)議版本 version，選擇的加密套件 cipher suite，選擇的壓縮算法 compression method、隨機數 random_S 等，其中隨機數用于后續的密鑰協(xié)商;

(b)server_certificates, 服務(wù)器端配置對應的證書(shū)鏈，用于身份驗證與密鑰交換;

(c) serv??er_hello_done，通知客戶(hù)端 server_hello 信息發(fā)送結束;

3.證書(shū)校驗

證書(shū)鏈的可信性 trusted certificate path，方法如前文所述;

證書(shū)是否吊銷(xiāo) revocation，有兩類(lèi)方式離線(xiàn) CRL 與在線(xiàn) OCSP，不同的客戶(hù)端行為會(huì )不同;

有效期 expiry date，證書(shū)是否在有效時(shí)間范圍;

域名 domain，核查證書(shū)域名是否與當前的訪(fǎng)問(wèn)域名匹配，匹配規則后續分析;

4.client_key_exchange+change_cipher??_spec+encrypted_handshake_message

(a) client_key_exchange，合法性驗證通過(guò)之后，客戶(hù)端計算產(chǎn)生隨機數字 Pre-master，并用證書(shū)公鑰加密，發(fā)送給服務(wù)器;

((′?｀*)b) 此時(shí)客戶(hù)端已經(jīng)獲取全部的計算協(xié)商密鑰需要(yao)的信息：兩個(gè)明文隨機數 random_C 和 random_S 與自己計算產(chǎn)生的 Pre-master，計算(suan)得到協(xié)商密鑰;

enc_key=Fuc(random_C, random_S, Pre-Master)

(c) change_cipher_spec，客ヾ(′ω｀)?戶(hù)端通知服務(wù)器后續的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信;

(d) encrypted_handsh(′?｀*)ake_message，結合之前所??有通信參數的 hash 值與其(qi)它相關(guān)信息生成一段??數據，采用協(xié)商密鑰 session secret 與算法進(jìn)行加密，然后發(fā)送給服務(wù)器用于數據與握手驗證;??

5.change_cipher_s??pec+encrypted_handshake_message

(a) 服務(wù)器用私鑰解密加密的 Pre-master 數據，基于之前交換的兩個(gè)明文隨機數 random_C?? 和 random_??S，計算得到協(xié)商密鑰??:enc_key=Fuc(random_C(╯°□°）╯, random??_S, Pr??e-Master);

(b) 計算之前所有接收信息的 hash 值，然后解密客戶(hù)端發(fā)送的 encrypted_handshake_message，驗證ヽ(′▽?zhuān)?ノ數據和密鑰正確性;

(c) change_cipher_spec, 驗證通過(guò)之后，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶(hù)端后續的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信;

(d) encrypted_handshake_message, 服務(wù)器也結合所有當前(qian)的通信參數信息生成一段數據并采用協(xié)商密鑰 session secret 與算法加密并發(fā)送到客戶(hù)端;

6.握手結束

客戶(hù)端計算所有接收信息的 hash 值，并采用協(xié)商密鑰解密 encrypted_hands??hake_message，驗證服務(wù)器發(fā)送的數據和密鑰，驗證通過(guò)則握手完成;

7.加密通信

開(kāi)始使用協(xié)商密鑰與算法進(jìn)行加密通信。

注意：

(a) 服務(wù)器也可以要求驗證客戶(hù)端，即雙向認證，可以在過(guò)程2要發(fā)送 client_certificate_request 信息，客戶(hù)端在過(guò)程4中先發(fā)送 client_certificate與certificate_verify_message 信息，證書(shū)的驗證方式基本相同，certificate_verify_me(╯‵□′)╯ssage 是采用client的私鑰加密的一段基??于已經(jīng)協(xié)商的通信信息得到數據，服務(wù)器可(ke)以采用對應的公鑰解密并驗證;

(b) 根據使用的密鑰交換算法的不同，如 ECC 等，協(xié)商細節略有不同，總體相似;

(c) sever key exchange 的作用是 server certificate 沒(méi)有攜帶足夠的信息時(shí)，發(fā)送給客戶(hù)端以計算 pre-master，如基于 DH 的證書(shū)，公鑰不被證書(shū)中包含，需要單獨發(fā)送;

(d) chang??e cip??her spec 實(shí)際可用于通知對端改版當前使用的加密通信方式，當前沒(méi)有深入解析;

(e) alter message 用于指明在握手或通信過(guò)程中的狀態(tài)改變或錯誤信息，一般告警信息觸發(fā)條(tiao)件是連接關(guān)閉，收到不合法??的信息，信息解密失敗，用戶(hù)取消操作等，收到告警信息之后，通信會(huì )被斷開(kāi)或者由接收方?jīng)Q定是否斷開(kāi)連??接。

4.2會(huì )話(huà)緩存握手過(guò)程

為了加快建立握手的速度，減少協(xié)議帶來(lái)的性能降低和資源消耗(具體分析在后文)，TLS 協(xié)議有兩類(lèi)會(huì )話(huà)緩存機制：會(huì )話(huà)標識 session ID 與會(huì )話(huà)記錄 session ticket。

se??ssion ID 由服務(wù)器端支持，協(xié)議中的標準字段，因此基本所有服務(wù)器都支持(chi)，服務(wù)器端保存會(huì )話(huà)ID以及協(xié)商的通(tong)信信息，Nginx 中1M 內存約可以保存4000個(gè) session ID 機器相關(guān)信息，占用服務(wù)器資源較多;

session ticket 需要服務(wù)器和客戶(hù)端都支持，屬于一個(gè)擴展字段，支持范圍約60%(無(wú)可靠統計與來(lái)源)，將協(xié)商的通信信息加密之后發(fā)送給客戶(hù)端保存，密鑰只有服務(wù)器知道，占ヽ(′▽?zhuān)?ノ用服務(wù)器資源很少。

二者都存在的情況下，(nginx 實(shí)現)優(yōu)先使用 session_ticket。

握手過(guò)程如下圖：

注意：雖然握手過(guò)程有1.5個(gè)來(lái)回，但是最后客戶(hù)端向服務(wù)(wu)器發(fā)送的第一條應用數據不需(xu)要等待服務(wù)器返回的信息，因此握手延時(shí)是1*RTT。

1.會(huì )話(huà)標識 session ID

(a???) 如果客戶(hù)端和服務(wù)器之間(jian)曾經(jīng)建立了連接，服務(wù)器會(huì )在握手成功后返回 session ID，并保存對應的通信參數在服??務(wù)器中;

(b) 如果客戶(hù)端再次需要和該服務(wù)器建立連接，則在 client_hello 中 session ID 中攜帶記錄的信息，發(fā)送給服務(wù)器;

(c) 服務(wù)器根據收到的 sess??ion ID 檢索緩存記錄，如果沒(méi)有檢索到貨緩存過(guò)期，則按照正常的握手過(guò)程進(jìn)行;

(d) 如果檢索到對應的緩存記錄，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個(gè)信息作用類(lèi)(lei)似，encrypted_handshake_message 是到當前的通信參數與 master_secret(╬?益?)的hash 值;

(f) 如果客(′?ω?`)戶(hù)端能夠驗證通過(guò)服務(wù)器加密數據，則客戶(hù)端同樣發(fā)送 change_cipher_spec 與 encrypted_handshake_message 信息;

(g) 服務(wù)器驗證數??據通過(guò)，則握手建立成功，開(kāi)始進(jìn)行正常的加密數據通信。

2.會(huì )話(huà)??(′?｀)記錄 session ticket

(b) 如果客戶(hù)端再次需ヾ(′?｀)?要和該服務(wù)器建立連接，則在 client_??hello 中擴展字段 session_ticket 中攜帶加密信息，一起發(fā)送給服務(wù)器;

(c) 服務(wù)器解密 sesssion_ticket 數據，如果能夠解密失敗，則按照正常的(de)握手過(guò)程進(jìn)(⊙_⊙)(jin)行;

(d) 如果解密??成功，則返回 change_cヽ(′▽?zhuān)?ノipher_spec 與 en(╯‵□′)╯crypted_handshake_message 信息，兩個(gè)信息作用與 session ID 中類(lèi)似;

(f) 如果客戶(hù)端能夠驗??證通過(guò)服務(wù)器加??密數據，則客戶(hù)端同樣??發(fā)送 change_cipher_s??pec與encrypted_handshake_message 信息;

(g) 服務(wù)器驗證數據通過(guò)，則握手建立成功，開(kāi)始進(jìn)行??正常的加密數據通信。

4.3 重建連接

重建連接 renegotiation 即放棄正在使用的 TLS 連接，從新進(jìn)行身份認證和密鑰協(xié)商的過(guò)程，特點(diǎn)是不需要斷開(kāi)當前的數據傳輸就可以重新身份認證、更新密鑰或算法，因此服務(wù)器端存儲和緩存的信息都可以保持?？蛻?hù)端和服務(wù)器都能夠發(fā)起重建連接的過(guò)程，當前 win??dows?? 2000 & XP 與 SSL 2.0不支持。

1.服務(wù)器重建連接

服務(wù)器端重建連接一般情況是客戶(hù)端訪(fǎng)問(wèn)受保護的數據時(shí)發(fā)生?；具^(guò)程如下：

(c) 服務(wù)器端返回 hello_request 信息;

(d) 客戶(hù)端收到 hello??_request 信息之后發(fā)送 client_hello 信息，開(kāi)始重新建立連接。

2.客戶(hù)端重建連接???

客戶(hù)端重建連接一般是為了更新通信密鑰。

(a) 客戶(hù)端和服務(wù)器之間建立了有效 TLS 連接并通信;

(c) 服務(wù)器端收到 client_he??llo 信息之后無(wú)法立即識別出該信息非應用數據，因此會(huì )提交給下一步處理，處理完之后會(huì )返回通知該信息為要求重建連接;

(d) 在確定重建連接之前，服務(wù)器不會(huì )立即停止向客戶(hù)端發(fā)送數據，可能恰好同時(shí)或有緩存數據需要發(fā)送給客戶(hù)端，但(′?｀)是客戶(hù)端不會(huì )再發(fā)送任何信息給服務(wù)器;

(f??) 客戶(hù)端也同樣無(wú)法立即判斷出該信息非應用數據，同樣提交給下一步處理，處理之后會(huì )返回通知該信息為要求重建連接;

(ヾ(′?｀)?g) 客戶(hù)端和服務(wù)器開(kāi)始新的重建連接的過(guò)程。

4.4 密鑰計算

上節提到了兩個(gè)明文傳輸的隨機??數 random_C 和(he) random_S 與通過(guò)加密在服務(wù)器和客戶(hù)端之間交換的 Pre-master，三個(gè)參數作為密鑰協(xié)商的基??礎。本節討論說(shuō)明密鑰協(xié)商的基本計算過(guò)程以及通信過(guò)程中的密鑰使用。

1.計算 Key

涉及參數 ra??ndom client 和 ra??ndom server, Pre-master, Master secret, key material, 計算密鑰時(shí)，服務(wù)器和客戶(hù)端都具有這些基本信息，交換方式在上節ヽ(′▽?zhuān)?ノ中有說(shuō)明，計算流程如下：

(a) 客戶(hù)端采用 RSA 或 Diffie-Hellman 等加密算法生(sheng)成 Pre-master;

(b) Pre-ma┐(′?｀)┌ster 結合 random client 和 random server 兩個(gè)隨機數通過(guò) Pseudo(′?ω?`)RandomFunction(PRF)計算得到 Master secret;

(c) Master secret 結合 random client 和 random server 兩個(gè)隨機數通過(guò)迭代計算得到 Key material;

(a) PreMaster secret 前兩個(gè)字節是 TLS 的版本號，這是一個(gè)比較重要(??-)?的用來(lái)核對握(??ヮ?)?*:???手數據的版本號，因為在 Client Hello 階段，客(′ω｀)戶(hù)端會(huì )發(fā)送一份加密套件列表和當前支持的 SSL/TLS 的版本號給服務(wù)端，而且是使用明文傳送的，如果握手的數據包被(bei)破解之后，攻擊者很有可能串改數據包，選擇一個(gè)安??全性較低的加密套?件和版本給服務(wù)端，從而對數據進(jìn)行破解。所以，服務(wù)(′?ω?`)端需要對密文中解密出來(lái)對的 PreMaster 版本號跟之前 Client Hello 階段的版本號進(jìn)行對比，如果版本號變低??，則說(shuō)明被串改，則立即停止發(fā)送任何消息。(copy)

(b) 不管是客戶(hù)端還是服務(wù)器，都??需要隨機數，這樣生成的密鑰才不會(huì )每次都一樣。由(you)于 SSL 協(xié)議中證書(shū)是靜態(tài)的，因此十分有必要引入一種隨機因(yin)素來(lái)??保證協(xié)商出來(lái)的密鑰的隨機性。

對于 RSA 密鑰交換算法來(lái)說(shuō)，pre-master-key 本身就是一個(gè)隨機數，再加上 hello 消息中的隨機，三??個(gè)隨機數通過(guò)一個(gè)密鑰導出器最終導出一個(gè)對稱(chēng)密鑰。

pre master 的存在在于 SSL 協(xié)議不信任每個(gè)主機都能產(chǎn)生完全隨機的隨機數，如果隨機數不隨機，那么 pre master sec??ret 就有可能被猜出來(lái)，那么僅適用 pre mast(╯‵□′)╯er secret 作為密鑰就不合適了，因此必須引入新的隨機因素，那么客戶(hù)端和服務(wù)器加上 pre master secret 三個(gè)隨機數一同生成的密(′?｀*)鑰就不容??易被猜出了，一個(gè)偽隨機可能完全不隨機，(╯°□°）╯︵ ┻━┻可( ?ヮ?)是三個(gè)偽隨機就十分接近隨機了，每增加一個(gè)自由度，隨機性增加的可不是一。

Key 經(jīng)過(guò)12輪迭代計算會(huì )獲取到12個(gè) hash 值，分組成為6個(gè)元素，列表如下：

(a) mac key、encryption key 和 IV 是一組加密元素，分別被客戶(hù)端和服務(wù)器使用，但是這兩組元素都被兩邊同時(shí)獲取;

(b) 客戶(hù)端使用 client?? 組元素加密數據，服務(wù)器使用 client 元素解密;服務(wù)器使用 ser??ver 元素加密，client 使用 server 元素解密;

(c) 雙向通信的不同方向使用的??密鑰不同，破解通信至少需要破解兩次;

(d) encryption key 用于對稱(chēng)加密數據;

(e) IV 作為很多(duo)加密算法的初始化向量使用，具(ju)體可以研究對稱(chēng)加密算法;

(f) Mac key 用于數據的完整性校驗;

4.4 數據加密通信過(guò)(guo)程

(a) 對應用層數據進(jìn)行分?片成合適的(′_｀) block;

(c) 使用協(xié)商的壓縮算法壓縮數據(ju);

(d) 計算 MAC 值和壓縮數據組成傳輸數據;

(e) 使用 client encryption key 加密數據，發(fā)送給服務(wù)器 server;

(f) server 收到數據之后使用 client enc( ?ヮ?)rytion key 解密，校驗數據，解壓縮數據，重新組裝。

注：M(╯°□°）╯AC值的計算包括兩個(gè) Hash 值：client Mac(°ロ°) ! key 和 Hash (編號、包類(lèi)型、長(cháng)度、壓縮數據)。

4.5(′?｀*) 抓包分析

關(guān)于抓包不再詳細分析，按照前面的分析，基本的情況都能夠匹配，根據平常定位問(wèn)??題的過(guò)程，個(gè)人提些認為需要??注意的地方：

2.抓包 HTTP??S 通信主要包??括三個(gè)過(guò)程：TCP 建立連接、TLS 握手、TLS 加密通信，主要??分析 HTTPS 通信的握手建立和狀態(tài)等信息。

根據ヾ(＾-＾)ノ extension 字段中的(?⊿?) server_name 字段判斷是否支持SNI，存在則支持，否則(°ロ°) !不支持，對于??定位握??手失敗或證書(shū)返回錯誤非常有用;

會(huì )話(huà)標識 session ID 是標??準協(xié)議部分，如果沒(méi)有建立過(guò)連接則對應值為空，不為空則說(shuō)明之前建立過(guò)對應的連接并緩存;

會(huì )話(huà)記錄 session ticke t是擴展協(xié)議部分，存在該字段說(shuō)明協(xié)議支持 sesssion ticket，否則不支持，存在且值為空，說(shuō)明之前未建立并緩存連接，存在且值不為空，說(shuō)明有緩存連接。

4.server_hello

根據 TLS version 字段能夠推測出服務(wù)器支持的協(xié)議的最高版本，版本不同可能造成握手失敗;

基于 cipher_suite 信息判斷出服務(wù)器優(yōu)先支持的加密協(xié)議;

5.ヽ(′▽?zhuān)?ノceritficate

6.alert

告警信息 aler?t 會(huì )說(shuō)明建立連接失敗的原因即告警類(lèi)型，對于定位問(wèn)題非常重要。

5.HTTPS 性能與優(yōu)化

5.1 HTTPS 性能損耗

前文討論了 HTTPS 原理與優(yōu)勢：身份驗證、信息加密與完整???性校驗等，且未對 TCP 和 HTTP 協(xié)議做任何修改。(?⊿?)但通過(guò)增加新協(xié)議以實(shí)(shi)現更安全的通信必然(???)需要付出代價(jià)，HTTPS 協(xié)議的性能損耗主要體現如下(?????)：

1.增加延時(shí)

分析前面的握手過(guò)程，一次完整的握手至少需要兩端依次來(lái)回兩次通信，至少增加延時(shí)2* RTT，利用會(huì )話(huà)緩存從而復用連接，延時(shí)??也至少1* RTT*。

2.消耗較多的 CPU 資源

除數據傳??輸之外，HTTPS 通信主要包括對對稱(chēng)加解密、非對稱(chēng)加解密(服(′-ι_-｀)務(wù)器主要采用私鑰解密數據ヽ(′?｀)ノ);壓測 TSˉ\_(ツ)_/ˉ8 機型的單核 CPU：對稱(chēng)加密算法AES-CBC-256 吞吐量 600Mbps，非對稱(chēng) RSA 私鑰解密200次/s。不考慮其它軟件層面的開(kāi)銷(xiāo)，1(′?｀)0G 網(wǎng)卡為對稱(chēng)加密需要消耗 CPU 約1ヽ(′ー｀)ノ7核，24核CPU最多接入 HTTPS 連接 4800;

5.2 HTTPS 接入優(yōu)化

1.CDN 接入

2(′ω｀*).會(huì )話(huà)緩存

雖然前文提到 HT?TPS 即使采用會(huì )話(huà)緩存也要至少1*RTT的延時(shí)，但是至少延時(shí)已經(jīng)減少為原來(lái)的一半，明顯的延時(shí)優(yōu)化;同時(shí)，基于會(huì )話(huà)緩存建立的 HTTPS 連接不需要服務(wù)器使用RSA私鑰解密獲取 Pre-mast(╯°□°）╯er 信息，可以省??去CPU 的消耗。如果業(yè)務(wù)訪(fǎng)問(wèn)連接集中，緩存命中率高，則HTTPS的接入能力講明顯提升。當前 TRP 平臺的緩存命中率高峰時(shí)期大于30%，10k/s的接入資源實(shí)際可以承載13k/的接入，收效非?？捎^(guān)。

3.硬件加速

為接入(/ω＼)服務(wù)器安裝專(zhuān)用的 SSL 硬件加速卡，作用類(lèi)似 GPU，釋放 CPU，??能夠具(ju)有更高的 HTTPS 接(jie)入能ヽ(′ー｀)ノ力且不影響業(yè)務(wù)程序的。測試某硬件加速卡單卡可以提供 35k 的解密能力，相當于175核 CPU，至少相當于7臺24核的服???務(wù)器，考慮到接入服務(wù)器其它程序的開(kāi)銷(xiāo)，一張硬件卡可以實(shí)現接近10(??-)?臺服務(wù)器??的接入能力。

4.遠程解密

本地接入消耗過(guò)多的 CPU 資源，浪費了網(wǎng)卡和硬盤(pán)等資源，考慮將最消耗 CPU 資源的RSA解密計算任務(wù)轉移到其它服務(wù)器，如此則可以充分(fen)發(fā)揮服務(wù)器的接入能力，充分利用帶寬與網(wǎng)卡資源。遠程解密服務(wù)器可以選擇 CPU 負載較低的機器充當，實(shí)現機器資源復用，也可以??是專(zhuān)門(mén)優(yōu)化的高計算性能的服務(wù)(wu)器(qi)。當前也是 CDN 用于大規模HT??TPS接入的解決方案之一。

5.SPDY/HTTP2

前面的方法分別從減少傳輸延時(shí)和單機負載的方法提高 HTTPS 接入性能，但是方法都基于不改變 HTTP 協(xié)議??的基礎上提出的優(yōu)化方法，SPDY/HTTヽ(′?｀)ノP2 利用 TLS/SSL 帶來(lái)的優(yōu)勢，通過(guò)修改協(xié)議的方法來(lái)提升 HTTPS 的性能，提高下載速度等。