HTTPS相比HTTP，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，加密传输。

HTTPS RSA握手过程

1、客户端浏览器去DNS服务器获取此url对应的ip，然后客户端连接上服务端的443端口，发送请求到服务端，请求包括：TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random）；

2、服务端收到后，确认TLS版本是否支持，确定密码套件，生成一个随机数（Sverver Random）。保存Client Random用来后面生成密钥，返回Sverver Random、确认的TLS版本号、使用的密码套件【密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法】。为证明自己的身份，会再给客户端发数字证书

数字证书的签发：首先 CA 会把持有者公钥、用途、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算得到一个 Hash 值，CA 用自己的私钥将该 Hash 值加密，对证书做了签名；最后将 签名添加在文件证书上，形成数字证书

数字证书的校验：客户端会用同样的 Hash 算法获取该证书的 Hash值H1；通常浏览器和操作系统中集成了CA公钥信息，浏览器收到证书后可使用CA公钥解密签名内容，得到一个 Hash 值H2 ；最后比较H1和H2，如果值相同可信赖否则不可信

3、客户端验证发来的证书。验证证书无误后又会生成一个随机数pre-master，用服务端RSA公钥加密（如此一来，此随机数只有服务端的私钥才能解开了），发送该随机数给服务端。服务端收到后，用RSA 私钥解密得到随机数 pre-master。至此，双方都共享了三个随机数，然后根据三个随机数生成会话密钥（对称，用于对后续的HTTP请求/响应数据加解密）。

然后客户端发一个请求告诉服务端开始使用加密方式发送消息，再发一个消息，把之前所有发送的数据做个摘要再用会话密钥加密一下，让服务器做个验证，验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。

4、服务器也是同样的操作，发两次消息，如果双方都验证加密和解密没问题，那么握手正式完成。

RSA 和 ECDHE 握手过程的区别：

1、RSA 「不支持」前向保密，ECDHE 「支持」前向保密；RSA在使用对称加密通信之前是不安全的，因为RSA中服务器的私钥是唯一的，而ECDHE是不是固定的，在第二次握手时会选择一个椭圆曲线公开给客户端，然后也根据基点 G 和私钥计算出服务端的椭圆曲线公钥公开给客户端。然后客户端会根据服务器发送的信息生成一个椭圆曲线公钥，共享给服务端。至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是双方都就计算出点（x，y），其中 x 坐标值双方都是一样的。最终的会话密钥，就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的。

2、使用了 RSA ，TLS 完成四次握手后，才能进行应用数据传输；而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间；

为什么抓包工具可以截取HTTPS数据？

工作原理与中间人一致。

使用抓包工具进行 HTTPS 抓包时，需要在客户端安装 Fiddler 的根证书，这里实际上起认证中心（CA）的作用。

抓包工具能抓包的关键是客户端会往系统受信任的根证书列表中导入抓包工具生成的证书，而这个证书会被浏览器信任。也就是抓包工具给自己创建了一个认证中心 CA，客户端拿着中间人签发的证书去中间人自己的 CA 去认证，当然认为这个证书是有效的。

HTTPS优化

1、尽量用ECDHE密钥交换算法，尽量选择x25519曲线（最快）

2、TLS升级（ TLS1.3 把 Hello 和公钥交换这两个消息合并成了一个，减少到只需1 RTT就能完成 TLS 握手）

3、证书优化：传输、验证

4、会话复用：缓存加密密钥，客户端和服务器首次 TLS 握手连接后，双方会在内存缓存会话密钥，并用唯一Session ID来标识。或者是用Session Ticket，服务器不再缓存每个客户端的会话密钥，而是把缓存工作交给客户端，类似于 HTTP 的 Cookie。