最近大家在使用百度、谷歌或淘寶的時候，是不是注意瀏覽器左上角已經全部出現了一把綠色鎖，這把鎖表明該網站已經使用了 HTTPS 進行保護。仔細觀察，會發現這些網站已經全站使用 HTTPS。同時，iOS 9 系統默認把所有的 http 請求都改為 HTTPS 請求。隨著互聯網的發展，現代互聯網正在逐漸進入全站 HTTPS 時代。

    因此有開發同學會問：

    全站 HTTPS 能夠帶來怎樣的優勢？HTTPS 的原理又是什么？同時，阻礙 HTTPS 普及的困難是什么？

    為了解答大家的困惑，騰訊TEG架構平臺部靜態加速組高級工程師劉強，為大家綜合參考多種資料并經過實踐驗證，探究 HTTPS 的基礎原理，分析基本的 HTTPS 通信過程，迎接全站 HTTPS 的來臨。

    1.HTTPS 基礎

    HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協議 它是一個安全通信通道，它基于HTTP開發，用于在客戶計算機和服務器之間交換信息。它使用安全套接字層（SSL）進行信息交換，簡單來說它是HTTP的安全版，是使用 TLS/SSL 加密的 HTTP 協議。

    HTTP 協議采用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風險，而協議 TLS/SSL 具有身份驗證、信息加密和完整性校驗的功能，可以避免此類問題。

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

    哈爾濱seo培訓

    2.TLS/SSL 原理

    HTTPS 協議的主要功能基本都依賴于 TLS/SSL 協議，本節分析安全協議的實現原理。

    TLS/SSL 的功能實現主要依賴于三類基本算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法采用協商的密鑰對數據加密，基于散列函數驗證信息的完整性。

    哈爾濱seo培訓

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

    在信息傳輸過程中，散列函數不能單獨實現信息防篡改，因為明文傳輸，中間人可以修改信息之后重新計算信息摘要，因此需要對傳輸的信息以及信息摘要進行加密；對稱加密的優勢是信息傳輸1對1，需要共享相同的密碼，密碼的安全是保證信息安全的基礎，服務器和 N 個客戶端通信，需要維持 N 個密碼記錄，且缺少修改密碼的機制；非對稱加密的特點是信息傳輸1對多，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但服務器發出的信息能夠被所有的客戶端解密，且該算法的計算復雜，加密速度慢。

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

    3.PKI 體系 3.1 RSA 身份驗證的隱患

    身份驗證和密鑰協商是 TLS 的基礎功能，要求的前提是合法的服務器掌握著對應的私鑰。但 RSA 算法無法確保服務器身份的合法性，因為公鑰并不包含服務器的信息，存在安全隱患：

    客戶端 C 和服務器 S 進行通信，中間節點 M 截獲了二者的通信；

    節點 M 自己計算產生一對公鑰 pub_M 和私鑰 pri_M;

    C 向 S 請求公鑰時，M 把自己的公鑰 pub_M 發給了 C;

    C 使用公鑰 pub_M 加密的數據能夠被 M 解密，因為 M 掌握對應的私鑰 pri_M，而 C 無法根據公鑰信息判斷服務器的身份，從而 C 和 M 之間建立了“可信”加密連接；

    中間節點 M 和服務器S之間再建立合法的連接，因此 C 和 S 之間通信被M完全掌握，M 可以進行信息的竊聽、篡改等操作。

    另外，服務器也可以對自己的發出的信息進行否認，不承認相關信息是自己發出。

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

    哈爾濱seo培訓

    3.2 身份驗證-CA 和證書

    解決上述身份驗證問題的關鍵是確保獲取的公鑰途徑是合法的，能夠驗證服務器的身份信息，為此需要引入權威的第三方機構 CA。CA 負責核實公鑰的擁有者的信息，并頒發認證“證書”，同時能夠為使用者提供證書驗證服務，即 PKI 體系。

    基本的原理為，CA 負責審核信息，然后對關鍵信息利用私鑰進行“簽名”，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。CA 也可以吊銷已經簽發的證書，基本的方式包括兩類 CRL 文件和 OCSP。CA 使用具體的流程如下：

    哈爾濱seo培訓

    a.服務方 S 向第三方機構CA提交公鑰、組織信息、個人信息（域名）等信息并申請認證；

    b.CA 通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等；

    c.如信息審核通過，CA 會向申請者簽發認證文件-證書。

    證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名；

    簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，然后，采用 CA 的私鑰對信息摘要進行加密，密文即簽名；

    d.客戶端 C 向服務器 S 發出請求時，S 返回證書文件；

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

    f.客戶端然后驗證證書相關的域名信息、有效時間等信息；

    g.客戶端會內置信任 CA 的證書信息（包含公鑰），如果CA不被信任，則找不到對應 CA 的證書，證書也會被判定非法。

    在這個過程注意幾點：

    a.申請證書不需要提供私鑰，確保私鑰永遠只能服務器掌握；

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

    c.內置 CA 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書；

    d.證書=公鑰+申請者與頒發者信息+簽名；

    3.3 證書鏈

    如 CA 根證書和服務器證書中間增加一級證書機構，即中間證書，證書的產生和驗證原理不變，只是增加一層驗證，只要最后能夠被任何信任的CA根證書驗證合法即可。

    a.服務器證書 server.pem 的簽發者為中間證書機構 inter，inter 根據證書 inter.pem 驗證 server.pem 確實為自己簽發的有效證書；

    b.中間證書 inter.pem 的簽發 CA 為 root，root 根據證書 root.pem 驗證 inter.pem 為自己簽發的合法證書；

    c.客戶端內置信任 CA 的 root.pem 證書，因此服務器證書 server.pem 的被信任。

    哈爾濱seo培訓

    服務器證書、中間證書與根證書在一起組合成一條合法的證書鏈，證書鏈的驗證是自下而上的信任傳遞的過程。

    二級證書結構存在的優勢：

    a.減少根證書結構的管理工作量，可以更高效的進行證書的審核與簽發；

    b.根證書一般內置在客戶端中，私鑰一般離線存儲，一旦私鑰泄露，則吊銷過程非常困難，無法及時補救；

    c.中間證書結構的私鑰泄露，則可以快速在線吊銷，并重新為用戶簽發新的證書；

    d.證書鏈四級以內一般不會對 HTTPS 的性能造成明顯影響。

    哈爾濱seo培訓

    證書鏈有以下特點：

    a.同一本服務器證書可能存在多條合法的證書鏈。

    因為證書的生成和驗證基礎是公鑰和私鑰對，如果采用相同的公鑰和私鑰生成不同的中間證書，針對被簽發者而言，該簽發機構都是合法的 CA，不同的是中間證書的簽發機構不同；

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

    中間證書的簽發機構可能是根證書機構也可能是另一個中間證書機構，所以證書鏈層級不一定相同。

    3.4 證書吊銷

    CA 機構能夠簽發證書，同樣也存在機制宣布以往簽發的證書無效。證書使用者不合法，CA 需要廢棄該證書；或者私鑰丟失，使用者申請讓證書無效。主要存在兩類機制：CRL 與 OCSP。

    （a） CRL

    Certificate Revocation List, 證書吊銷列表，一個單獨的文件。該文件包含了 CA 已經吊銷的證書序列號（唯一）與吊銷日期，同時該文件包含生效日期并通知下次更新該文件的時間，當然該文件必然包含 CA 私鑰的簽名以驗證文件的合法性。

    證書中一般會包含一個 URL 地址 CRL Distribution Point，通知使用者去哪里下載對應的 CRL 以校驗證書是否吊銷。該吊銷方式的優點是不需要頻繁更新，但是不能及時吊銷證書，因為 CRL 更新時間一般是幾天，這期間可能已經造成了極大損失。

    （b） OCSP

    Online Certificate Status Protocol, 證書狀態在線查詢協議，一個實時查詢證書是否吊銷的方式。請求者發送證書的信息并請求查詢，服務器返回正常、吊銷或未知中的任何一個狀態。證書中一般也會包含一個 OCSP 的 URL 地址，要求查詢服務器具有良好的性能。部分 CA 或大部分的自簽 CA （根證書）都是未提供 CRL 或 OCSP 地址的，對于吊銷證書會是一件非常麻煩的事情。

    4.TLS/SSL握手過程

    4.1握手與密鑰協商過程

    基于 RSA 握手和密鑰交換的客戶端驗證服務器為示例詳解握手過程。

    哈爾濱seo培訓

    1.client_hello

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

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

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

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

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

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

    2.server_hello+server_certificate+sever_hello_done

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

    （b）server_certificates, 服務器端配置對應的證書鏈，用于身份驗證與密鑰交換；

    （c） server_hello_done，通知客戶端 server_hello 信息發送結束；

    3.證書校驗

    客戶端驗證證書的合法性，如果驗證通過才會進行后續通信，否則根據錯誤情況不同做出提示和操作，合法性驗證包括如下：

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

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

    有效期 expiry date，證書是否在有效時間范圍；

    域名 domain，核查證書域名是否與當前的訪問域名匹配，匹配規則后續分析；

    4.client_key_exchange+change_cipher_spec+encrypted_handshake_message

    （a） client_key_exchange，合法性驗證通過之后，客戶端計算產生隨機數字 Pre-master，并用證書公鑰加密，發送給服務器；

    （b） 此時客戶端已經獲取全部的計算協商密鑰需要的信息：兩個明文隨機數 random_C 和 random_S 與自己計算產生的 Pre-master，計算得到協商密鑰；

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

    （c） change_cipher_spec，客戶端通知服務器后續的通信都采用協商的通信密鑰和加密算法進行加密通信；

    （d） encrypted_handshake_message，結合之前所有通信參數的 hash 值與其它相關信息生成一段數據，采用協商密鑰 session secret 與算法進行加密，然后發送給服務器用于數據與握手驗證；

    5.change_cipher_spec+encrypted_handshake_message

    （a） 服務器用私鑰解密加密的 Pre-master 數據，基于之前交換的兩個明文隨機數 random_C 和 random_S，計算得到協商密鑰：enc_key=Fuc（random_C, random_S, Pre-Master）；

    （b） 計算之前所有接收信息的 hash 值，然后解密客戶端發送的 encrypted_handshake_message，驗證數據和密鑰正確性；

    （c） change_cipher_spec, 驗證通過之后，服務器同樣發送 change_cipher_spec 以告知客戶端后續的通信都采用協商的密鑰與算法進行加密通信；

    （d） encrypted_handshake_message, 服務器也結合所有當前的通信參數信息生成一段數據并采用協商密鑰 session secret 與算法加密并發送到客戶端；

    6.握手結束

    客戶端計算所有接收信息的 hash 值，并采用協商密鑰解密 encrypted_handshake_message，驗證服務器發送的數據和密鑰，驗證通過則握手完成；

    7.加密通信

    開始使用協商密鑰與算法進行加密通信。

    注意：

    （a） 服務器也可以要求驗證客戶端，即雙向認證，可以在過程2要發送 client_certificate_request 信息，客戶端在過程4中先發送 client_certificate與certificate_verify_message 信息，證書的驗證方式基本相同，certificate_verify_message 是采用client的私鑰加密的一段基于已經協商的通信信息得到數據，服務器可以采用對應的公鑰解密并驗證；

    （b） 根據使用的密鑰交換算法的不同，如 ECC 等，協商細節略有不同，總體相似；

    （c） sever key exchange 的作用是 server certificate 沒有攜帶足夠的信息時，發送給客戶端以計算 pre-master，如基于 DH 的證書，公鑰不被證書中包含，需要單獨發送；

    （d） change cipher spec 實際可用于通知對端改版當前使用的加密通信方式，當前沒有深入解析；

    （e） alter message 用于指明在握手或通信過程中的狀態改變或錯誤信息，一般告警信息觸發條件是連接關閉，收到不合法的信息，信息解密失敗，用戶取消操作等，收到告警信息之后，通信會被斷開或者由接收方決定是否斷開連接。

    4.2會話緩存握手過程

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

    session ID 由服務器端支持，協議中的標準字段，因此基本所有服務器都支持，服務器端保存會話ID以及協商的通信信息，Nginx 中1M 內存約可以保存4000個 session ID 機器相關信息，占用服務器資源較多；

    session ticket 需要服務器和客戶端都支持，屬于一個擴展字段，支持范圍約60%（無可靠統計與來源），將協商的通信信息加密之后發送給客戶端保存，密鑰只有服務器知道，占用服務器資源很少。