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

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

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

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

    1.HTTPS 基礎(chǔ)

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

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

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

    哈爾濱seo培訓(xùn)

    2.TLS/SSL 原理

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

    TLS/SSL 的功能實(shí)現(xiàn)主要依賴于三類基本算法：散列函數(shù) Hash、對(duì)稱加密和非對(duì)稱加密，其利用非對(duì)稱加密實(shí)現(xiàn)身份認(rèn)證和密鑰協(xié)商，對(duì)稱加密算法采用協(xié)商的密鑰對(duì)數(shù)據(jù)加密，基于散列函數(shù)驗(yàn)證信息的完整性。

    哈爾濱seo培訓(xùn)

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

    在信息傳輸過(guò)程中，散列函數(shù)不能單獨(dú)實(shí)現(xiàn)信息防篡改，因?yàn)槊魑膫鬏敚虚g人可以修改信息之后重新計(jì)算信息摘要，因此需要對(duì)傳輸?shù)男畔⒁约靶畔⒄M(jìn)行加密；對(duì)稱加密的優(yōu)勢(shì)是信息傳輸1對(duì)1，需要共享相同的密碼，密碼的安全是保證信息安全的基礎(chǔ)，服務(wù)器和 N 個(gè)客戶端通信，需要維持 N 個(gè)密碼記錄，且缺少修改密碼的機(jī)制；非對(duì)稱加密的特點(diǎn)是信息傳輸1對(duì)多，服務(wù)器只需要維持一個(gè)私鑰就能夠和多個(gè)客戶端進(jìn)行加密通信，但服務(wù)器發(fā)出的信息能夠被所有的客戶端解密，且該算法的計(jì)算復(fù)雜，加密速度慢。

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

    3.PKI 體系 3.1 RSA 身份驗(yàn)證的隱患

    身份驗(yàn)證和密鑰協(xié)商是 TLS 的基礎(chǔ)功能，要求的前提是合法的服務(wù)器掌握著對(duì)應(yīng)的私鑰。但 RSA 算法無(wú)法確保服務(wù)器身份的合法性，因?yàn)楣€并不包含服務(wù)器的信息，存在安全隱患：

    客戶端 C 和服務(wù)器 S 進(jìn)行通信，中間節(jié)點(diǎn) M 截獲了二者的通信；

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

    C 向 S 請(qǐng)求公鑰時(shí)，M 把自己的公鑰 pub_M 發(fā)給了 C;

    C 使用公鑰 pub_M 加密的數(shù)據(jù)能夠被 M 解密，因?yàn)?M 掌握對(duì)應(yīng)的私鑰 pri_M，而 C 無(wú)法根據(jù)公鑰信息判斷服務(wù)器的身份，從而 C 和 M 之間建立了“可信”加密連接；

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

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

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

    哈爾濱seo培訓(xùn)

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

    解決上述身份驗(yàn)證問(wèn)題的關(guān)鍵是確保獲取的公鑰途徑是合法的，能夠驗(yàn)證服務(wù)器的身份信息，為此需要引入權(quán)威的第三方機(jī)構(gòu) CA。CA 負(fù)責(zé)核實(shí)公鑰的擁有者的信息，并頒發(fā)認(rèn)證“證書(shū)”，同時(shí)能夠?yàn)槭褂谜咛峁┳C書(shū)驗(yàn)證服務(wù)，即 PKI 體系。

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

    哈爾濱seo培訓(xùn)

    a.服務(wù)方 S 向第三方機(jī)構(gòu)CA提交公鑰、組織信息、個(gè)人信息（域名）等信息并申請(qǐng)認(rèn)證；

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

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

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

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

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

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

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

    g.客戶端會(huì)內(nèi)置信任 CA 的證書(shū)信息（包含公鑰），如果CA不被信任，則找不到對(duì)應(yīng) CA 的證書(shū)，證書(shū)也會(huì)被判定非法。

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

    a.申請(qǐng)證書(shū)不需要提供私鑰，確保私鑰永遠(yuǎn)只能服務(wù)器掌握；

    b.證書(shū)的合法性仍然依賴于非對(duì)稱加密算法，證書(shū)主要是增加了服務(wù)器信息以及簽名；

    c.內(nèi)置 CA 對(duì)應(yīng)的證書(shū)稱為根證書(shū)，頒發(fā)者和使用者相同，自己為自己簽名，即自簽名證書(shū)；

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

    3.3 證書(shū)鏈

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

    a.服務(wù)器證書(shū) server.pem 的簽發(fā)者為中間證書(shū)機(jī)構(gòu) inter，inter 根據(jù)證書(shū) inter.pem 驗(yàn)證 server.pem 確實(shí)為自己簽發(fā)的有效證書(shū)；

    b.中間證書(shū) inter.pem 的簽發(fā) CA 為 root，root 根據(jù)證書(shū) root.pem 驗(yàn)證 inter.pem 為自己簽發(fā)的合法證書(shū)；

    c.客戶端內(nèi)置信任 CA 的 root.pem 證書(shū)，因此服務(wù)器證書(shū) server.pem 的被信任。

    哈爾濱seo培訓(xùn)

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

    二級(jí)證書(shū)結(jié)構(gòu)存在的優(yōu)勢(shì)：

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

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

    c.中間證書(shū)結(jié)構(gòu)的私鑰泄露，則可以快速在線吊銷，并重新為用戶簽發(fā)新的證書(shū)；

    d.證書(shū)鏈四級(jí)以內(nèi)一般不會(huì)對(duì) HTTPS 的性能造成明顯影響。

    哈爾濱seo培訓(xùn)

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

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

    因?yàn)樽C書(shū)的生成和驗(yàn)證基礎(chǔ)是公鑰和私鑰對(duì)，如果采用相同的公鑰和私鑰生成不同的中間證書(shū)，針對(duì)被簽發(fā)者而言，該簽發(fā)機(jī)構(gòu)都是合法的 CA，不同的是中間證書(shū)的簽發(fā)機(jī)構(gòu)不同；

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

    中間證書(shū)的簽發(fā)機(jī)構(gòu)可能是根證書(shū)機(jī)構(gòu)也可能是另一個(gè)中間證書(shū)機(jī)構(gòu)，所以證書(shū)鏈層級(jí)不一定相同。

    3.4 證書(shū)吊銷

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

    （a） CRL

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

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

    （b） OCSP

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

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

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

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

    哈爾濱seo培訓(xùn)

    1.client_hello

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

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

    客戶端支持的加密套件 cipher suites 列表， 每個(gè)加密套件對(duì)應(yīng)前面 TLS 原理中的四個(gè)功能的組合：認(rèn)證算法 Au （身份驗(yàn)證）、密鑰交換算法 KeyExchange（密鑰協(xié)商）、對(duì)稱加密算法 Enc （信息加密）和信息摘要 Mac（完整性校驗(yàn)）；

    支持的壓縮算法 compression methods 列表，用于后續(xù)的信息壓縮傳輸；

    隨機(jī)數(shù) random_C，用于后續(xù)的密鑰的生成；

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

    2.server_hello+server_certificate+sever_hello_done

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

    （b）server_certificates, 服務(wù)器端配置對(duì)應(yīng)的證書(shū)鏈，用于身份驗(yàn)證與密鑰交換；

    （c） server_hello_done，通知客戶端 server_hello 信息發(fā)送結(jié)束；

    3.證書(shū)校驗(yàn)

    客戶端驗(yàn)證證書(shū)的合法性，如果驗(yàn)證通過(guò)才會(huì)進(jìn)行后續(xù)通信，否則根據(jù)錯(cuò)誤情況不同做出提示和操作，合法性驗(yàn)證包括如下：

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

    證書(shū)是否吊銷 revocation，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會(huì)不同；

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

    域名 domain，核查證書(shū)域名是否與當(dāng)前的訪問(wèn)域名匹配，匹配規(guī)則后續(xù)分析；

    4.client_key_exchange+change_cipher_spec+encrypted_handshake_message

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

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

    enc_key=Fuc（random_C, random_S, Pre-Master）

    （c） change_cipher_spec，客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信；

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

    5.change_cipher_spec+encrypted_handshake_message

    （a） 服務(wù)器用私鑰解密加密的 Pre-master 數(shù)據(jù)，基于之前交換的兩個(gè)明文隨機(jī)數(shù) random_C 和 random_S，計(jì)算得到協(xié)商密鑰：enc_key=Fuc（random_C, random_S, Pre-Master）；

    （b） 計(jì)算之前所有接收信息的 hash 值，然后解密客戶端發(fā)送的 encrypted_handshake_message，驗(yàn)證數(shù)據(jù)和密鑰正確性；

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

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

    6.握手結(jié)束

    客戶端計(jì)算所有接收信息的 hash 值，并采用協(xié)商密鑰解密 encrypted_handshake_message，驗(yàn)證服務(wù)器發(fā)送的數(shù)據(jù)和密鑰，驗(yàn)證通過(guò)則握手完成；

    7.加密通信

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

    注意：

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

    （b） 根據(jù)使用的密鑰交換算法的不同，如 ECC 等，協(xié)商細(xì)節(jié)略有不同，總體相似；

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

    （d） change cipher spec 實(shí)際可用于通知對(duì)端改版當(dāng)前使用的加密通信方式，當(dāng)前沒(méi)有深入解析；

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

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

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

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

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