HTTPS建立基本流程

• 客户端向服务器索要并验证服务器的公钥。
• 通过密钥交换算法（如RSA或ECDHE）协商会话秘钥，这个过程被称为“握手”。
• 双方采用会话秘钥进行加密通信。

RSA流程

RSA流程包括四次握手：

• 第一次握手：客户端发送支持的TLS版本、生成的Client Random和支持的密码套件列表。
• 第二次握手：服务器处理确认TLS协议版本，然后发送生成的Server Random、密码套件列表（包括密钥交换算法、签名算法、对称加密算法、对称加密算法分组方式和摘要算法）以及服务器的数字证书（包含公钥）。
• 第三次握手：客户端处理验证证书真伪，生成会话密钥（由Client Random + Server Random + pre-master key组成以保证随机性），然后发送服务器公钥加密过的刚生成的pre-master key（预主密钥），告诉服务端之后使用加密方式发送消息，并发送之前所有发送的数据做个摘要，并使用会话密钥加密，以验证可用性。
• 第四次握手：服务器处理生成会话密钥，然后发送告诉客户端之后使用加密方式发送消息，并发送之前所有发送的数据做个摘要，并使用会话密钥加密，以验证可用性。

RSA缺陷

RSA的主要缺陷是没有前向安全性。这意味着如果一个会话的秘钥被泄露，那么所有以前的会话都可能被解密。

DHE算法

• DHE算法基于离散对数问题，即对于 aimodp=b，当 p 很大时，已知 a、b 无法快速获得 i ，时间复杂度为 O(p​) ，但是如果正向计算（已知 a、i，求b ）是可以做到 O(logp) 的。
• DHE算法的流程如下：
  • 双方确定模数P和底数A。
  • 各自随机生成私钥i，j作为指数。
  • 通过 Bi=Aimodp、Bj=Ajmodp 得到公钥并交换。
  • 以 K=Bij=Bjimodp 为会话密钥。
• 在static DH算法中，一方私钥是固定的，无法保证前向安全，所以有了DHE，其中E就是 ephemeral 临时的。
• DHE算法的缺点是虽然保证了前向安全性，但是需要大量乘法，性能不佳。

ECDHE算法

• ECDHE算法基于椭圆曲线上的加法，对于椭圆曲线上一点 A，过A的一条切线与圆锥曲线相交，交点关于x轴对称的点记为2A。
• ECDHE算法的流程如下：
  • 双方确定椭圆曲线和曲线是基点G。
  • 各自随机生成私钥d1、d2。
  • 计算公钥 Q1=d1G、Q2=d2G并交换。
  • 计算得到 d1Q2=d2Q1 中的x相同的（预主密钥）。
• ECDHE算法的优势是利用了ECC圆锥曲线特性，计算量更少，前向安全性，ECDHE 允许 TLS False Start 即在第三次挥手之后可以直接进行数据传输。

ECDHE流程

ECDHE流程包括四次握手：

• 第一次握手：客户端发送支持的TLS版本、生成的Client Random和支持的密码套件列表。
• 第二次握手：服务器处理确认TLS协议版本，生成私钥、公钥，然后发送生成的Server Random、密码套件列表（类型同RSA）、服务器的数字证书、选定的圆锥曲线以及对应公钥。
• 第三次握手：客户端处理生成私钥、公钥，会话密钥 = Client Random + Server Random + ECDHE计算出的点的x坐标 保证随机性，然后发送圆锥曲线公钥（客户端公钥加密）、告诉服务端之后使用加密方式发送消息、之前所有发送的数据做个摘要，并使用会话密钥加密，验证可用性。
• 第四次握手：服务器处理生成会话密钥，然后发送告诉客户端之后使用加密方式发送消息、之前所有发送的数据做个摘要，并使用会话密钥加密，验证可用性、Session Ticket 会话复用。

HTTPS优化

• 硬件优化

  • 升级CPU，加快密钥计算。
  • 选用支持 AES-NI 特性的 CPU。

• 软件优化

  • openssl升级。
  • linux内核升级。

• 协议优化

  • 选用 ECDHE 密钥交换，支持 TLS False Start。
  • 选择 x25519 椭圆曲线，该曲线是目前计算最快的椭圆曲线。
  • 有CPU支持就选AES，如果没有就选择ChaCha20。
  • 安全性要求不是很高使用 AES128 代替 AES256。
  • 升级TLS1.3，将第一、三次握手合并，两次握手之后即可加密传输。密钥交换算法仅留下了支持前向安全性的ECDHE，仅留下了几个安全性高的密码套件，0RTT会话复用。

• 证书优化

  • 选择椭圆曲线（ECDSA）证书，而不是 RSA 证书，相同安全程度下ECDSA密钥更短。

• 会话复用

  • Session ID：双方会在内存缓存会话密钥，并用唯一的 Session ID 来标识，Session ID 和会话密钥相当于 key-value 的关系，定时过期。客户端再次连接时，hello 消息里会带上 Session ID，服务器收到后就会从内存找，如果还有就继续使用，省略后续挥手过程。占用服务器内存。
  • Session Ticket：首次连接后的第四次挥手加密会话密钥作为  Ticket 发给客户端。服务器收到 Ticket 后判断有效期，有效就恢复会话。在 TLS1.3 中把 Ticket 和 HTTP 请求一同发送给服务端即可，我们称之为Pre-shared Key（PSK）。
  • 重放攻击：如果中间人截获了客户端使用会话重用技术的 POST 请求，会导致服务器被恶意修改。应对方法包括设定过期时间，只对GET请求等使用会话复用。