HTTPS建立基本流程

• 客戶端向服務(wù)器索要并驗證服務(wù)器的公鑰。
• 通過密鑰交換算法（如RSA或ECDHE）協(xié)商會話秘鑰，這個過程被稱為“握手”。
• 雙方采用會話秘鑰進(jìn)行加密通信。

RSA流程

RSA流程包括四次握手：

• 第一次握手：客戶端發(fā)送支持的TLS版本、生成的Client Random和支持的密碼套件列表。
• 第二次握手：服務(wù)器處理確認(rèn)TLS協(xié)議版本，然后發(fā)送生成的Server Random、密碼套件列表（包括密鑰交換算法、簽名算法、對稱加密算法、對稱加密算法分組方式和摘要算法）以及服務(wù)器的數(shù)字證書（包含公鑰）。
• 第三次握手：客戶端處理驗證證書真?zhèn)?#xff0c;生成會話密鑰（由Client Random + Server Random + pre-master key組成以保證隨機(jī)性），然后發(fā)送服務(wù)器公鑰加密過的剛生成的pre-master key（預(yù)主密鑰），告訴服務(wù)端之后使用加密方式發(fā)送消息，并發(fā)送之前所有發(fā)送的數(shù)據(jù)做個摘要，并使用會話密鑰加密，以驗證可用性。
• 第四次握手：服務(wù)器處理生成會話密鑰，然后發(fā)送告訴客戶端之后使用加密方式發(fā)送消息，并發(fā)送之前所有發(fā)送的數(shù)據(jù)做個摘要，并使用會話密鑰加密，以驗證可用性。

RSA缺陷

RSA的主要缺陷是沒有前向安全性。這意味著如果一個會話的秘鑰被泄露，那么所有以前的會話都可能被解密。

DHE算法

• DHE算法基于離散對數(shù)問題，即對于 aimodp=b，當(dāng) p 很大時，已知 a、b 無法快速獲得 i ，時間復(fù)雜度為 O(p?) ，但是如果正向計算（已知 a、i，求b ）是可以做到 O(logp) 的。
• DHE算法的流程如下：
  • 雙方確定模數(shù)P和底數(shù)A。
  • 各自隨機(jī)生成私鑰i，j作為指數(shù)。
  • 通過 Bi=Aimodp、Bj=Ajmodp 得到公鑰并交換。
  • 以 K=Bij=Bjimodp 為會話密鑰。
• 在static DH算法中，一方私鑰是固定的，無法保證前向安全，所以有了DHE，其中E就是 ephemeral 臨時的。
• DHE算法的缺點是雖然保證了前向安全性，但是需要大量乘法，性能不佳。

ECDHE算法

• ECDHE算法基于橢圓曲線上的加法，對于橢圓曲線上一點 A，過A的一條切線與圓錐曲線相交，交點關(guān)于x軸對稱的點記為2A。
• ECDHE算法的流程如下：
  • 雙方確定橢圓曲線和曲線是基點G。
  • 各自隨機(jī)生成私鑰d1、d2。
  • 計算公鑰 Q1=d1G、Q2=d2G并交換。
  • 計算得到 d1Q2=d2Q1 中的x相同的（預(yù)主密鑰）。
• ECDHE算法的優(yōu)勢是利用了ECC圓錐曲線特性，計算量更少，前向安全性，ECDHE 允許 TLS False Start 即在第三次揮手之后可以直接進(jìn)行數(shù)據(jù)傳輸。

ECDHE流程

ECDHE流程包括四次握手：

• 第一次握手：客戶端發(fā)送支持的TLS版本、生成的Client Random和支持的密碼套件列表。
• 第二次握手：服務(wù)器處理確認(rèn)TLS協(xié)議版本，生成私鑰、公鑰，然后發(fā)送生成的Server Random、密碼套件列表（類型同RSA）、服務(wù)器的數(shù)字證書、選定的圓錐曲線以及對應(yīng)公鑰。
• 第三次握手：客戶端處理生成私鑰、公鑰，會話密鑰 = Client Random + Server Random + ECDHE計算出的點的x坐標(biāo) 保證隨機(jī)性，然后發(fā)送圓錐曲線公鑰（客戶端公鑰加密）、告訴服務(wù)端之后使用加密方式發(fā)送消息、之前所有發(fā)送的數(shù)據(jù)做個摘要，并使用會話密鑰加密，驗證可用性。
• 第四次握手：服務(wù)器處理生成會話密鑰，然后發(fā)送告訴客戶端之后使用加密方式發(fā)送消息、之前所有發(fā)送的數(shù)據(jù)做個摘要，并使用會話密鑰加密，驗證可用性、Session Ticket 會話復(fù)用。

HTTPS優(yōu)化

• 硬件優(yōu)化

  • 升級CPU，加快密鑰計算。
  • 選用支持 AES-NI 特性的 CPU。

• 軟件優(yōu)化

  • openssl升級。
  • linux內(nèi)核升級。

• 協(xié)議優(yōu)化

  • 選用 ECDHE 密鑰交換，支持 TLS False Start。
  • 選擇 x25519 橢圓曲線，該曲線是目前計算最快的橢圓曲線。
  • 有CPU支持就選AES，如果沒有就選擇ChaCha20。
  • 安全性要求不是很高使用 AES128 代替 AES256。
  • 升級TLS1.3，將第一、三次握手合并，兩次握手之后即可加密傳輸。密鑰交換算法僅留下了支持前向安全性的ECDHE，僅留下了幾個安全性高的密碼套件，0RTT會話復(fù)用。

• 證書優(yōu)化

  • 選擇橢圓曲線（ECDSA）證書，而不是 RSA 證書，相同安全程度下ECDSA密鑰更短。

• 會話復(fù)用

  • Session ID：雙方會在內(nèi)存緩存會話密鑰，并用唯一的 Session ID 來標(biāo)識，Session ID 和會話密鑰相當(dāng)于 key-value 的關(guān)系，定時過期?？蛻舳嗽俅芜B接時，hello 消息里會帶上 Session ID，服務(wù)器收到后就會從內(nèi)存找，如果還有就繼續(xù)使用，省略后續(xù)揮手過程。占用服務(wù)器內(nèi)存。
  • Session Ticket：首次連接后的第四次揮手加密會話密鑰作為? Ticket 發(fā)給客戶端。服務(wù)器收到 Ticket 后判斷有效期，有效就恢復(fù)會話。在 TLS1.3 中把 Ticket 和 HTTP 請求一同發(fā)送給服務(wù)端即可，我們稱之為Pre-shared Key（PSK）。
  • 重放攻擊：如果中間人截獲了客戶端使用會話重用技術(shù)的 POST 請求，會導(dǎo)致服務(wù)器被惡意修改。應(yīng)對方法包括設(shè)定過期時間，只對GET請求等使用會話復(fù)用。