1. HTTPS 基礎(chǔ)

https://<主機>:<443>/<路徑>

• HTTPS(Secure Hypertext Transfer Protocol)安全超文本傳輸協(xié)議 它是一個安全通信通道，它基于HTTP開發(fā)悉尾，用于在客戶計算機和服務(wù)器之間交換信息带到。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版,是使用 TLS/SSL 加密的 HTTP 協(xié)議。
• HTTP 協(xié)議采用明文傳輸信息辜腺，存在信息竊聽默勾、信息篡改和信息劫持的風(fēng)險碉渡，而協(xié)議 TLS/SSL 具有身份驗證、信息加密和完整性校驗的功能母剥，可以避免此類問題滞诺。
• TLS/SSL 全稱安全傳輸層協(xié)議 Transport Layer Security, 是介于 TCP 和 HTTP 之間的一層安全協(xié)議，不影響原有的 TCP 協(xié)議和 HTTP 協(xié)議环疼，所以使用 HTTPS 基本上不需要對 HTTP 頁面進行太多的改造习霹。

2. TLS/SSL 原理

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

2.1 加密算法

• 對稱加密采用對稱密碼編碼技術(shù)煞檩，相同的密鑰可以用于信息的加密和解密，掌握密鑰才能獲取信息栅贴，能夠防止信息竊聽斟湃，通信方式是1對1。對稱加密使用簡單檐薯，密鑰較短凝赛，加密和解密過程較快，耗時短坛缕，常見的對稱加密算法有DES墓猎，3DES，lDEA祷膳，AES陶衅，RC4等。
• 非對稱加密與對稱加密不同直晨，其加密算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（private）搀军，兩者是一對的膨俐。如果用公鑰加密，只能用私鑰才能解密罩句。非對稱加密保密性好焚刺，但加密和解密花費的時間較長，不適合對大文件加密而只適合對少量的數(shù)據(jù)加密门烂。常見的非對稱加密算法有RSA乳愉，ECC，DSA(數(shù)字簽名)等屯远。因此掌握公鑰的不同客戶端之間不能互相解密信息蔓姚，只能和掌握私鑰的服務(wù)器進行加密通信，服務(wù)器可以實現(xiàn)1對多的通信慨丐，客戶端也可以用來驗證掌握私鑰的服務(wù)器身份坡脐。
• Hash算法是函數(shù)單向不可逆、對輸入非常敏感房揭、輸出長度固定备闲，針對數(shù)據(jù)的任何修改都會改變散列函數(shù)的結(jié)果，用于防止信息篡改并驗證數(shù)據(jù)的完整性算法捅暴，通過Hash算法可以對目標(biāo)數(shù)據(jù)生成一段特定長度恬砂、唯一的hash值,但是不能通過這個hash值重新計算出原始的數(shù)據(jù)，因此也稱之為摘要算法蓬痒，經(jīng)常被用在不需要數(shù)據(jù)還原的密碼加密以及數(shù)據(jù)完整性校驗上泻骤，常用的算法有MD2，MD4乳幸，MD5瞪讼，SHA等。

2.2 加密內(nèi)容

• 在信息傳輸過程中粹断，散列函數(shù)不能單獨實現(xiàn)信息防篡改，因為明文傳輸嫡霞，中間人可以修改信息之后重新計算信息摘要瓶埋，因此需要對傳輸?shù)男畔⒁约靶畔⒄M行加密；

• 對稱加密的優(yōu)勢是信息傳輸1對1诊沪，需要共享相同的密碼养筒，密碼的安全是保證信息安全的基礎(chǔ)，服務(wù)器和 N 個客戶端通信端姚，需要維持 N 個密碼記錄晕粪，且缺少修改密碼的機制；

• 非對稱加密的特點是信息傳輸1對多渐裸，服務(wù)器只需要維持一個私鑰就能夠和多個客戶端進行加密通信巫湘，但服務(wù)器發(fā)出的信息能夠被所有的客戶端解密装悲，且該算法的計算復(fù)雜，加密速度慢尚氛。

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

3. PKI 體系

3.1 RSA 身份驗證的隱患

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

• 客戶端 C 和服務(wù)器 S 進行通信极祸，中間節(jié)點 M 截獲了二者的通信慈格；
• 節(jié)點 M 自己計算產(chǎn)生一對公鑰 pub_M 和私鑰 pri_M;
• C 向 S 請求公鑰時，M 把自己的公鑰 pub_M 發(fā)給了 C;
• C 使用公鑰 pub_M 加密的數(shù)據(jù)能夠被 M 解密遥金，因為 M 掌握對應(yīng)的私鑰 pri_M浴捆，而 C 無法根據(jù)公鑰信息判斷服務(wù)器的身份，從而 C 和 M 之間建立了"可信"加密連接;
• 中間節(jié)點 M 和服務(wù)器S之間再建立合法的連接稿械，因此 C 和 S 之間通信被M完全掌握选泻，M 可以進行信息的竊聽、篡改等操作美莫。
  另外页眯，服務(wù)器也可以對自己的發(fā)出的信息進行否認(rèn)，不承認(rèn)相關(guān)信息是自己發(fā)出厢呵。

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

3.2 身份驗證-CA 和證書

解決上述身份驗證問題的關(guān)鍵是確保獲取的公鑰途徑是合法的，能夠驗證服務(wù)器的身份信息襟铭，為此需要引入權(quán)威的第三方機構(gòu) CA碌奉。CA 負(fù)責(zé)核實公鑰的擁有者的信息，并頒發(fā)認(rèn)證"證書"寒砖，同時能夠為使用者提供證書驗證服務(wù)赐劣，即 PKI 體系。
基本的原理為哩都，CA 負(fù)責(zé)審核信息魁兼，然后對關(guān)鍵信息利用私鑰進行"簽名"，公開對應(yīng)的公鑰漠嵌，客戶端可以利用公鑰驗證簽名咐汞。
CA 也可以吊銷已經(jīng)簽發(fā)的證書盖呼，基本的方式包括兩類 CRL 文件和 OCSP。
CA 使用具體的流程如下：

• 服務(wù)方 S 向第三方機構(gòu)CA提交公鑰碉考、組織信息塌计、個人信息(域名)等信息并申請認(rèn)證；

• CA 通過線上侯谁、線下等多種手段驗證申請者提供信息的真實性锌仅，如組織是否存在、企業(yè)是否合法墙贱，是否擁有域名的所有權(quán)等热芹；

• 如信息審核通過，CA 會向申請者簽發(fā)認(rèn)證文件-證書惨撇。

  • 證書包含以下信息：申請者公鑰伊脓、申請者的組織信息和個人信息、簽發(fā)機構(gòu) CA 的信息魁衙、有效時間报腔、證書序列號等信息的明文，同時包含一個簽名剖淀；
  • 簽名的產(chǎn)生算法：首先纯蛾，使用散列函數(shù)計算公開的明文信息的信息摘要，然后纵隔，采用 CA 的私鑰對信息摘要進行加密翻诉，密文即簽名；

• 客戶端 C 向服務(wù)器 S 發(fā)出請求時捌刮，S 返回證書文件碰煌；

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

• 客戶端然后驗證證書相關(guān)的域名信息、有效時間等信息典尾；

• 客戶端會內(nèi)置信任 CA 的證書信息(包含公鑰)役拴，如果CA不被信任，則找不到對應(yīng) CA 的證書钾埂，證書也會被判定非法河闰。
  在這個過程注意幾點：

• 申請證書不需要提供私鑰科平，確保私鑰永遠(yuǎn)只能服務(wù)器掌握；

• 證書的合法性仍然依賴于非對稱加密算法姜性，證書主要是增加了服務(wù)器信息以及簽名瞪慧；

• 內(nèi)置 CA 對應(yīng)的證書稱為根證書，頒發(fā)者和使用者相同部念，自己為自己簽名弃酌，即自簽名證書

• 證書=公鑰+申請者與頒發(fā)者信息+簽名；

3.3 證書鏈

如 CA 根證書和服務(wù)器證書中間增加一級證書機構(gòu)儡炼，即中間證書妓湘，證書的產(chǎn)生和驗證原理不變，只是增加一層驗證乌询，只要最后能夠被任何信任的CA根證書驗證合法即可榜贴。

• 服務(wù)器證書 server.pem 的簽發(fā)者為中間證書機構(gòu) inter，inter 根據(jù)證書 inter.pem 驗證 server.pem 確實為自己簽發(fā)的有效證書妹田；
• 中間證書 inter.pem 的簽發(fā) CA 為 root唬党，root 根據(jù)證書 root.pem 驗證 inter.pem 為自己簽發(fā)的合法證書；
• 客戶端內(nèi)置信任 CA 的 root.pem 證書鬼佣，因此服務(wù)器證書 server.pem 的被信任驶拱。
  服務(wù)器證書、中間證書與根證書在一起組合成一條合法的證書鏈沮趣，證書鏈的驗證是自下而上的信任傳遞的過程屯烦。
  二級證書結(jié)構(gòu)存在的優(yōu)勢：
• 減少根證書結(jié)構(gòu)的管理工作量，可以更高效的進行證書的審核與簽發(fā)房铭；
• 根證書一般內(nèi)置在客戶端中驻龟，私鑰一般離線存儲，一旦私鑰泄露缸匪，則吊銷過程非常困難翁狐，無法及時補救；
• 中間證書結(jié)構(gòu)的私鑰泄露凌蔬，則可以快速在線吊銷露懒，并重新為用戶簽發(fā)新的證書；
• 證書鏈四級以內(nèi)一般不會對 HTTPS 的性能造成明顯影響砂心。

證書鏈有以下特點：

• 同一本服務(wù)器證書可能存在多條合法的證書鏈懈词。 因為證書的生成和驗證基礎(chǔ)是公鑰和私鑰對，如果采用相同的公鑰和私鑰生成不同的中間證書辩诞，針對被簽發(fā)者而言坎弯，該簽發(fā)機構(gòu)都是合法的 CA，不同的是中間證書的簽發(fā)機構(gòu)不同
• 不同證書鏈的層級不一定相同，可能二級抠忘、三級或四級證書鏈

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

3.4 證書吊銷

CA 機構(gòu)能夠簽發(fā)證書崎脉，同樣也存在機制宣布以往簽發(fā)的證書無效拧咳。
證書使用者不合法，CA 需要廢棄該證書囚灼；或者私鑰丟失骆膝，使用者申請讓證書無效。主要存在兩類機制：CRL 與 OCSP啦撮。

(a) CRL

Certificate Revocation List, 證書吊銷列表谭网，一個單獨的文件。該文件包含了 CA 已經(jīng)吊銷的證書序列號(唯一)與吊銷日期赃春，同時該文件包含生效日期并通知下次更新該文件的時間愉择，當(dāng)然該文件必然包含 CA 私鑰的簽名以驗證文件的合法性。

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

(b) OCSP

Online Certificate Status Protocol, 證書狀態(tài)在線查詢協(xié)議刁笙，一個實時查詢證書是否吊銷的方式破花。請求者發(fā)送證書的信息并請求查詢，服務(wù)器返回正常疲吸、吊銷或未知中的任何一個狀態(tài)座每。證書中一般也會包含一個 OCSP 的 URL 地址，要求查詢服務(wù)器具有良好的性能摘悴。部分 CA 或大部分的自簽 CA (根證書)都是未提供 CRL 或 OCSP 地址的峭梳，對于吊銷證書會是一件非常麻煩的事情。

4. TLS/SSL握手過程

4.0 HTTPS 的通信過程

1）蹂喻、「443 端口的 TCP 連接」葱椭。
2）、「SSL 安全參數(shù)握手」口四。
3）孵运、「客戶端發(fā)送數(shù)據(jù)」。
4）蔓彩、「服務(wù)端發(fā)送數(shù)據(jù)」掐松。

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

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

1. client_hello

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

• 支持的最高TSL協(xié)議版本version逞壁，從低到高依次 SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2流济，當(dāng)前基本不再使用低于 TLSv1 的版本；
• 客戶端支持的加密套件 cipher suites 列表腌闯， 每個加密套件對應(yīng)前面 TLS 原理中的四個功能的組合：認(rèn)證算法 Au (身份驗證)绳瘟、密鑰交換算法 KeyExchange(密鑰協(xié)商)、對稱加密算法 Enc (信息加密)和信息摘要 Mac(完整性校驗);
• 支持的壓縮算法 compression methods 列表姿骏，用于后續(xù)的信息壓縮傳輸糖声；
• 隨機數(shù) random_C，用于后續(xù)的密鑰的生成分瘦；
• 擴展字段 extensions蘸泻，支持協(xié)議與算法的相關(guān)參數(shù)以及其它輔助信息等，常見的 SNI 就屬于擴展字段嘲玫，后續(xù)單獨討論該字段作用悦施。

2. server_hello+server_certificate+sever_hello_done

• server_hello, 服務(wù)端返回協(xié)商的信息結(jié)果，包括選擇使用的協(xié)議版本 version去团，選擇的加密套件 cipher suite抡诞，選擇的壓縮算法 compression method、隨機數(shù) random_S 等土陪，其中隨機數(shù)用于后續(xù)的密鑰協(xié)商;
• server_certificates, 服務(wù)器端配置對應(yīng)的證書鏈昼汗，用于身份驗證與密鑰交換；
• server_hello_done旺坠，通知客戶端 server_hello 信息發(fā)送結(jié)束乔遮；

3.證書校驗

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

• 證書鏈的可信性 trusted certificate path，方法如前文所述璧疗；
• 證書是否吊銷 revocation坯辩，有兩類方式離線 CRL 與在線 OCSP，不同的客戶端行為會不同崩侠；
• 有效期 expiry date漆魔，證書是否在有效時間范圍；
• 域名 domain，核查證書域名是否與當(dāng)前的訪問域名匹配改抡，匹配規(guī)則后續(xù)分析矢炼；

client_key_exchange+change_cipher_spec+encrypted_handshake_message

• client_key_exchange，合法性驗證通過之后阿纤，客戶端計算產(chǎn)生隨機數(shù)字 Pre-master句灌，并用證書公鑰加密，發(fā)送給服務(wù)器欠拾；
• 此時客戶端已經(jīng)獲取全部的計算協(xié)商密鑰需要的信息：兩個明文隨機數(shù) random_C 和 random_S 與自己計算產(chǎn)生的 Pre-master胰锌，計算得到協(xié)商密鑰;

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

• change_cipher_spec，客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進行加密通信;
• encrypted_handshake_message藐窄，結(jié)合之前所有通信參數(shù)的 hash 值與其它相關(guān)信息生成一段數(shù)據(jù)资昧，采用協(xié)商密鑰 session secret 與算法進行加密，然后發(fā)送給服務(wù)器用于數(shù)據(jù)與握手驗證;

5. change_cipher_spec+encrypted_handshake_message

• 服務(wù)器用私鑰解密加密的 Pre-master 數(shù)據(jù)荆忍，基于之前交換的兩個明文隨機數(shù) random_C 和 random_S格带，計算得到協(xié)商密鑰:enc_key=Fuc(random_C, random_S, Pre-Master)；
• 計算之前所有接收信息的 hash 值东揣，然后解密客戶端發(fā)送的 encrypted_handshake_message践惑，驗證數(shù)據(jù)和密鑰正確性；
• change_cipher_spec, 驗證通過之后嘶卧，服務(wù)器同樣發(fā)送 change_cipher_spec 以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進行加密通信尔觉；
• encrypted_handshake_message, 服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù)并采用協(xié)商密鑰 session secret 與算法加密并發(fā)送到客戶端；

6. 握手結(jié)束

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

7. 加密通信

開始使用協(xié)商密鑰與算法進行加密通信钉稍。
注意：

• 服務(wù)器也可以要求驗證客戶端，即雙向認(rèn)證棺耍，可以在過程2要發(fā)送 client_certificate_request 信息贡未，客戶端在過程4中先發(fā)送 client_certificate與certificate_verify_message 信息，證書的驗證方式基本相同蒙袍，certificate_verify_message 是采用client的私鑰加密的一段基于已經(jīng)協(xié)商的通信信息得到數(shù)據(jù)俊卤，服務(wù)器可以采用對應(yīng)的公鑰解密并驗證；
• 根據(jù)使用的密鑰交換算法的不同害幅，如 ECC 等消恍，協(xié)商細(xì)節(jié)略有不同，總體相似以现；
• sever key exchange 的作用是 server certificate 沒有攜帶足夠的信息時狠怨，發(fā)送給客戶端以計算 pre-master约啊，如基于 DH 的證書，公鑰不被證書中包含佣赖，需要單獨發(fā)送恰矩；
• change cipher spec 實際可用于通知對端改版當(dāng)前使用的加密通信方式，當(dāng)前沒有深入解析茵汰；
• alter message 用于指明在握手或通信過程中的狀態(tài)改變或錯誤信息枢里，一般告警信息觸發(fā)條件是連接關(guān)閉，收到不合法的信息蹂午，信息解密失敗，用戶取消操作等彬碱，收到告警信息之后豆胸，通信會被斷開或者由接收方?jīng)Q定是否斷開連接。

4.2 會話緩存握手過程

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

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

session ticket 需要服務(wù)器和客戶端都支持攀细，屬于一個擴展字段箫踩，支持范圍約60%(無可靠統(tǒng)計與來源)，將協(xié)商的通信信息加密之后發(fā)送給客戶端保存谭贪，密鑰只有服務(wù)器知道境钟，占用服務(wù)器資源很少。

二者對比俭识，主要是保存協(xié)商信息的位置與方式不同慨削，類似與 http 中的 session 與 cookie。

二者都存在的情況下套媚，(nginx 實現(xiàn))優(yōu)先使用 session_ticket缚态。

注意：雖然握手過程有1.5個來回，但是最后客戶端向服務(wù)器發(fā)送的第一條應(yīng)用數(shù)據(jù)不需要等待服務(wù)器返回的信息凑阶，因此握手延時是1*RTT猿规。

1. 會話標(biāo)識 session ID

• 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接，服務(wù)器會在握手成功后返回 session ID宙橱，并保存對應(yīng)的通信參數(shù)在服務(wù)器中姨俩；
• 如果客戶端再次需要和該服務(wù)器建立連接蘸拔，則在 client_hello 中 session ID 中攜帶記錄的信息，發(fā)送給服務(wù)器环葵；
• 服務(wù)器根據(jù)收到的 session ID 檢索緩存記錄调窍，如果沒有檢索到貨緩存過期，則按照正常的握手過程進行张遭；
• 如果檢索到對應(yīng)的緩存記錄邓萨，則返回 change_cipher_spec 與 encrypted_handshake_message 信息，兩個信息作用類似菊卷，encrypted_handshake_message 是到當(dāng)前的通信參數(shù)與 master_secret的hash 值缔恳；
• 如果客戶端能夠驗證通過服務(wù)器加密數(shù)據(jù)，則客戶端同樣發(fā)送 change_cipher_spec 與 encrypted_handshake_message 信息洁闰；
• 服務(wù)器驗證數(shù)據(jù)通過歉甚，則握手建立成功，開始進行正常的加密數(shù)據(jù)通信

2. 會話記錄 session ticket

• 如果客戶端和服務(wù)器之間曾經(jīng)建立了連接扑眉，服務(wù)器會在 new_session_ticket 數(shù)據(jù)中攜帶加密的 session_ticket 信息纸泄，客戶端保存；
• 如果客戶端再次需要和該服務(wù)器建立連接腰素，則在 client_hello 中擴展字段 session_ticket 中攜帶加密信息聘裁，一起發(fā)送給服務(wù)器；
• 服務(wù)器解密 sesssion_ticket 數(shù)據(jù)弓千，如果能夠解密失敗衡便，則按照正常的握手過程進行；
• 如果解密成功计呈，則返回 change_cipher_spec 與 encrypted_handshake_message 信息砰诵，兩個信息作用與 session ID 中類似；
• 如果客戶端能夠驗證通過服務(wù)器加密數(shù)據(jù)捌显，則客戶端同樣發(fā)送 change_cipher_spec與encrypted_handshake_message 信息茁彭；
• 服務(wù)器驗證數(shù)據(jù)通過，則握手建立成功扶歪，開始進行正常的加密數(shù)據(jù)通信理肺。

4.3 重建連接

重建連接 renegotiation 即放棄正在使用的 TLS 連接，從新進行身份認(rèn)證和密鑰協(xié)商的過程善镰，特點是不需要斷開當(dāng)前的數(shù)據(jù)傳輸就可以重新身份認(rèn)證妹萨、更新密鑰或算法，因此服務(wù)器端存儲和緩存的信息都可以保持炫欺。
客戶端和服務(wù)器都能夠發(fā)起重建連接的過程乎完，當(dāng)前 windows 2000 & XP 與 SSL 2.0不支持。

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

服務(wù)器端重建連接一般情況是客戶端訪問受保護的數(shù)據(jù)時發(fā)生品洛∈饕蹋基本過程如下：
(a) 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信曙痘； (b) 客戶端訪問受保護的信息屉符； (c) 服務(wù)器端返回 hello_request 信息; (d) 客戶端收到 hello_request 信息之后發(fā)送 client_hello 信息，開始重新建立連接竟秫。

2. 客戶端重建連接

客戶端重建連接一般是為了更新通信密鑰弄企。

• 客戶端和服務(wù)器之間建立了有效 TLS 連接并通信一忱；
• 客戶端需要更新密鑰郭怪，主動發(fā)出 client_hello 信息桐磁；
• 服務(wù)器端收到 client_hello 信息之后無法立即識別出該信息非應(yīng)用數(shù)據(jù)，因此會提交給下一步處理查邢，處理完之后會返回通知該信息為要求重建連接蔗崎；
• 在確定重建連接之前，服務(wù)器不會立即停止向客戶端發(fā)送數(shù)據(jù)侠坎，可能恰好同時或有緩存數(shù)據(jù)需要發(fā)送給客戶端蚁趁，但是客戶端不會再發(fā)送任何信息給服務(wù)器；
• 服務(wù)器識別出重建連接請求之后实胸，發(fā)送 server_hello 信息至客戶端；
• 客戶端也同樣無法立即判斷出該信息非應(yīng)用數(shù)據(jù)番官，同樣提交給下一步處理庐完，處理之后會返回通知該信息為要求重建連接；
• 客戶端和服務(wù)器開始新的重建連接的過程徘熔。

4.4 密鑰計算

上節(jié)提到了兩個明文傳輸?shù)碾S機數(shù) random_C 和 random_S 與通過加密在服務(wù)器和客戶端之間交換的 Pre-master门躯，三個參數(shù)作為密鑰協(xié)商的基礎(chǔ)。本節(jié)討論說明密鑰協(xié)商的基本計算過程以及通信過程中的密鑰使用酷师。

1.計算 Key

涉及參數(shù) random client 和 random server, Pre-master, Master secret, key material, 計算密鑰時讶凉，服務(wù)器和客戶端都具有這些基本信息，交換方式在上節(jié)中有說明山孔，計算流程如下：

• 客戶端采用 RSA 或 Diffie-Hellman 等加密算法生成 Pre-master
• Pre-master 結(jié)合 random client 和 random server 兩個隨機數(shù)通過 PseudoRandomFunction(PRF)計算得到 Master secret;
• Master secret 結(jié)合 random client 和 random server 兩個隨機數(shù)通過迭代計算得到 Key material懂讯；
  以下為一些重要的記錄，可以解決部分愛深入研究朋友的疑惑台颠，copy的材料褐望，分享給大家：
  (a) PreMaster secret 前兩個字節(jié)是 TLS 的版本號，這是一個比較重要的用來核對握手?jǐn)?shù)據(jù)的版本號串前，因為在 Client Hello 階段瘫里，客戶端會發(fā)送一份加密套件列表和當(dāng)前支持的 SSL/TLS 的版本號給服務(wù)端，而且是使用明文傳送的荡碾，如果握手的數(shù)據(jù)包被破解之后谨读，攻擊者很有可能串改數(shù)據(jù)包，選擇一個安全性較低的加密套件和版本給服務(wù)端坛吁，從而對數(shù)據(jù)進行破解劳殖。所以铐尚，服務(wù)端需要對密文中解密出來對的 PreMaster 版本號跟之前 Client Hello 階段的版本號進行對比，如果版本號變低闷尿，則說明被串改塑径，則立即停止發(fā)送任何消息。(copy)

(b) 不管是客戶端還是服務(wù)器填具，都需要隨機數(shù)统舀，這樣生成的密鑰才不會每次都一樣。由于 SSL 協(xié)議中證書是靜態(tài)的劳景，因此十分有必要引入一種隨機因素來保證協(xié)商出來的密鑰的隨機性誉简。

對于 RSA 密鑰交換算法來說，pre-master-key 本身就是一個隨機數(shù)盟广，再加上 hello 消息中的隨機闷串，三個隨機數(shù)通過一個密鑰導(dǎo)出器最終導(dǎo)出一個對稱密鑰。
pre master 的存在在于 SSL 協(xié)議不信任每個主機都能產(chǎn)生完全隨機的隨機數(shù)筋量，如果隨機數(shù)不隨機烹吵，那么 pre master secret 就有可能被猜出來，那么僅適用 pre master secret 作為密鑰就不合適了桨武，因此必須引入新的隨機因素**肋拔，那么客戶端和服務(wù)器加上 pre master secret 三個隨機數(shù)一同生成的密鑰就不容易被猜出了，一個偽隨機可能完全不隨機呀酸，可是三個偽隨機就十分接近隨機了凉蜂，每增加一個自由度，隨機性增加的可不是一性誉。

2.密鑰使用

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

• mac key错览、encryption key 和 IV 是一組加密元素纫雁，分別被客戶端和服務(wù)器使用，但是這兩組元素都被兩邊同時獲然壤先较；
• 客戶端使用 client 組元素加密數(shù)據(jù)，服務(wù)器使用 client 元素解密悼粮；服務(wù)器使用 server 元素加密闲勺，client 使用 server 元素解密；
• 雙向通信的不同方向使用的密鑰不同扣猫，破解通信至少需要破解兩次菜循；
• encryption key 用于對稱加密數(shù)據(jù)
• IV 作為很多加密算法的初始化向量使用，具體可以研究對稱加密算法申尤；
• Mac key 用于數(shù)據(jù)的完整性校驗癌幕；

4.4 數(shù)據(jù)加密通信過程

• 對應(yīng)用層數(shù)據(jù)進行分片成合適的 block;
• 為分片數(shù)據(jù)編號衙耕，防止重放攻擊；
• 使用協(xié)商的壓縮算法壓縮數(shù)據(jù)勺远；
• 計算 MAC 值和壓縮數(shù)據(jù)組成傳輸數(shù)據(jù)橙喘；
• 使用 client encryption key 加密數(shù)據(jù)，發(fā)送給服務(wù)器 server胶逢；
• server 收到數(shù)據(jù)之后使用 client encrytion key 解密厅瞎，校驗數(shù)據(jù)，解壓縮數(shù)據(jù)初坠，重新組裝和簸。
  注：MAC值的計算包括兩個 Hash 值：client Mac key 和 Hash (編號、包類型碟刺、長度锁保、壓縮數(shù)據(jù))。

4.5 抓包分析

• 抓包 HTTP 通信半沽，能夠清晰的看到通信的頭部和信息的明文爽柒，但是 HTTPS 是加密通信，無法看到 HTTP 協(xié)議的相關(guān)頭部和數(shù)據(jù)的明文信息者填，

• 抓包 HTTPS 通信主要包括三個過程：TCP 建立連接霉赡、TLS 握手、TLS 加密通信幔托，主要分析 HTTPS 通信的握手建立和狀態(tài)等信息。

• 抓包 HTTPS 通信主要包括三個過程：TCP 建立連接蜂挪、TLS 握手重挑、TLS 加密通信，主要分析 HTTPS 通信的握手建立和狀態(tài)等信息棠涮。

• client_hello

  • 根據(jù) version 信息能夠知道客戶端支持的最高的協(xié)議版本號谬哀，如果是 SSL 3.0 或 TLS 1.0 等低版本協(xié)議，非常注意可能因為版本低引起一些握手失敗的情況严肪；
  • 根據(jù) extension 字段中的 server_name 字段判斷是否支持SNI史煎，存在則支持，否則不支持驳糯，對于定位握手失敗或證書返回錯誤非常有用篇梭；
  • 會話標(biāo)識 session ID 是標(biāo)準(zhǔn)協(xié)議部分，如果沒有建立過連接則對應(yīng)值為空酝枢，不為空則說明之前建立過對應(yīng)的連接并緩存恬偷；
  • 會話記錄 session ticke t是擴展協(xié)議部分，存在該字段說明協(xié)議支持 sesssion ticket帘睦，否則不支持袍患，存在且值為空坦康，說明之前未建立并緩存連接，存在且值不為空诡延，說明有緩存連接滞欠。

• server_hello

  • 根據(jù) TLS version 字段能夠推測出服務(wù)器支持的協(xié)議的最高版本，版本不同可能造成握手失斔亮肌筛璧；
  • 基于 cipher_suite 信息判斷出服務(wù)器優(yōu)先支持的加密協(xié)議；

• ceritficate：服務(wù)器配置并返回的證書鏈妖滔，根據(jù)證書信息并于服務(wù)器配置文件對比隧哮，判斷請求與期望是否一致，如果不一致座舍，是否返回的默認(rèn)證書沮翔。

• alert

告警信息 alert 會說明建立連接失敗的原因即告警類型，對于定位問題非常重要曲秉。

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

5.1 HTTPS 性能損耗

HTTPS 原理與優(yōu)勢：身份驗證采蚀、信息加密與完整性校驗等，且未對 TCP 和 HTTP 協(xié)議做任何修改承二。

HTTPS 協(xié)議的性能損耗主要體現(xiàn)如下：

1. 增加延時

分析前面的握手過程榆鼠，一次完整的握手至少需要兩端依次來回兩次通信，至少增加延時2 RTT亥鸠，利用會話緩存從而復(fù)用連接妆够，延時也至少1 RTT*。

2. 消耗較多的 CPU 資源

除數(shù)據(jù)傳輸之外负蚊，HTTPS 通信主要包括對對稱加解密神妹、非對稱加解密(服務(wù)器主要采用私鑰解密數(shù)據(jù))；

5.2 HTTPS 接入優(yōu)化

1. CDN 接入

HTTPS 增加的延時主要是傳輸延時 RTT家妆，RTT 的特點是節(jié)點越近延時越小鸵荠，CDN 天然離用戶最近，因此選擇使用 CDN 作為 HTTPS 接入的入口伤极，將能夠極大減少接入延時蛹找。CDN 節(jié)點通過和業(yè)務(wù)服務(wù)器維持長連接、會話復(fù)用和鏈路質(zhì)量優(yōu)化等可控方法哨坪，極大減少 HTTPS 帶來的延時庸疾。
全稱是Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)齿税。CDN是構(gòu)建在現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)之上的智能虛擬網(wǎng)絡(luò)

2. 會話緩存

雖然前文提到 HTTPS 即使采用會話緩存也要至少1*RTT的延時彼硫，但是至少延時已經(jīng)減少為原來的一半，明顯的延時優(yōu)化；同時拧篮，基于會話緩存建立的 HTTPS 連接不需要服務(wù)器使用RSA私鑰解密獲取 Pre-master 信息词渤，可以省去CPU 的消耗。
如果業(yè)務(wù)訪問連接集中串绩，緩存命中率高缺虐，則HTTPS的接入能力講明顯提升。

3. 硬件加速

為接入服務(wù)器安裝專用的 SSL 硬件加速卡礁凡，作用類似 GPU高氮，釋放 CPU，能夠具有更高的 HTTPS 接入能力且不影響業(yè)務(wù)程序的顷牌。

4. 遠(yuǎn)程解密

本地接入消耗過多的 CPU 資源剪芍，浪費了網(wǎng)卡和硬盤等資源，考慮將最消耗 CPU 資源的RSA解密計算任務(wù)轉(zhuǎn)移到其它服務(wù)器窟蓝，如此則可以充分發(fā)揮服務(wù)器的接入能力罪裹，充分利用帶寬與網(wǎng)卡資源。遠(yuǎn)程解密服務(wù)器可以選擇 CPU 負(fù)載較低的機器充當(dāng)运挫，實現(xiàn)機器資源復(fù)用状共，也可以是專門優(yōu)化的高計算性能的服務(wù)器。當(dāng)前也是 CDN 用于大規(guī)模HTTPS接入的解決方案之一谁帕。

5. SPDY/HTTP2

SPDY/HTTP2 利用 TLS/SSL 帶來的優(yōu)勢峡继，通過修改協(xié)議的方法來提升 HTTPS 的性能，提高下載速度等匈挖。

參考

全站 HTTPS 來了