跳到主要内容

连接

2024年04月07日
柏拉文
越努力，越幸运

一、认识​

https 通过数字证书验证服务器是否为信任的服务器, 采用非对称加密的方式交换密钥，然后使用对称加密的方式对数据进行加密，并且对消息的内容采用摘要算法得到消息摘要，这样对端在解密数据后可以通过相同的消息摘要算法对计算后的消息摘要和传过来的消息摘要进行对比，从而判断数据是否经过篡改。

早期的 TLS密钥交换 用的是 RSA算法，目前主流都是用 ECDHE算法 来做密钥交换的。下面我们分别来介绍下。

二、基于 TLS1.2 的 HTTPS 连接过程-RSA 密钥交换算法​

Preview

  1. 客户端发起 HTTPS 请求, 端口为 443

  2. 经历 TCP 三次握手，握手成功之后，就可以开始通过TCP传输数据

  3. 开始 TLS 握手的流程

    1. Client Hello：客户端生成一个Client Random随机数，明文发送给服务器，同时提供自己的 TLS版本号，以及自己支持的加密套件

    2. Server Hello：服务器收到之后，也生成了一个Server Random随机数，明文发送给客户端，同时告知自己选择的TLS版本号，以及选择的加密套件

    3. Server Certificate：服务器将其公开的SSL证书返回给客户端。这个证书包含了公钥、证书的颁发机构，以及证书的所有者等信息。

    4. Server Hello Done：提示服务器信息发送完毕

    5. 客户端收到证书后会验证服务器的SSL证书。首先检查证书的颁发机构是否被客户端信任，然后检查证书是否已经过期，最后检查服务器的域名是否与证书中的域名一致。如果这些检查都通过，那么客户端就会信任这个证书。

    6. Client Key Exchange：客户端生成一个PreMaster随机数，通过服务器的公钥加密传输给服务器。这个时候客户端和服务器都有三个参数：Server Random、Client Random、PreMaster，其中PreMaster是无法被不怀好意的人截获的，通过这三个参数，生成对称密钥

    7. 客户端Change Cipher Spec：客户端通知服务器后续改用刚刚生成的密钥进行加密通信

    8. 客户端Encrypted Handshake Message：客户端准备用刚刚的参数加密传输，验证加密通信

    9. 服务器Change Cipher Spec：服务器也通知客户端后续改用刚刚生成的密钥进行加密通信

    10. 服务器Encrypted Handshake Message：服务器准备用刚刚的参数加密传输，验证加密通信

    11. 在双方都确认好了之后，最后是验证的消息。

    这里的核心是：通过非对称加密交换参数，生成对称通信加密的密钥，其中PreMaster是非对称加密传输的，保证了不会泄露通信加密的密钥。

  4. 然后开始通信, 并使用摘要算法对数据进行完整性验证。

三、基于 TLS1.2 的 HTTPS 连接过程-ECDHE 密钥交换算法​

把与基于RSA算法的连接过程的差异步骤都进行高亮显示了，如下图：

Preview

  1. 客户端发起 HTTPS 请求, 端口为 443

  2. 经历 TCP 三次握手

  3. 握手成功之后, 开始 TLS 握手的流程

    1. Client Hello：客户端生成一个Client Random随机数，明文发送给服务器，同时提供自己的 TLS版本号，以及自己支持的加密套件

    2. Server Hello：服务器收到之后，也生成了一个Server Random随机数，明文发送给客户端，同时告知自己选择的TLS版本号，以及选择的加密套件

    3. Server Certificate：服务器将其公开的SSL证书返回给客户端。这个证书包含了公钥、证书的颁发机构，以及证书的所有者等信息。

    4. Server Key Exchange：在服务端发送完证书之后，多了这一步，这个是椭圆曲线参数Server Params，为了保证认证性，这里同时生成了Server Params的签名，一起发给客户端

    5. Server Hello Done：提示服务器信息发送完毕

    6. 客户端收到证书后会验证服务器的SSL证书。首先检查证书的颁发机构是否被客户端信任，然后检查证书是否已经过期，最后检查服务器的域名是否与证书中的域名一致。如果这些检查都通过，那么客户端就会信任这个证书。

    7. Client Key Exchange：这里不再是直接发送客户端生成PreMaster，而是生成客户端的椭圆曲线参数Client Params，直接传送给服务端；接着，客户端和服务端双方通过ECDHE算法用Client Params和Server Params算出最终的PreMaster，这个PreMaster是保证不会被截获的。这样双方就有了：Client Random，Server Random，PreMaster参数了，通过这三个参数就可以生成通信密钥了

    8. 客户端Change Cipher Spec：客户端通知服务器后续改用刚刚生成的密钥进行加密通信

    9. 客户端Encrypted Handshake Message：客户端准备用刚刚的参数加密传输，验证加密通信

    10. 服务器Change Cipher Spec：服务器也通知客户端后续改用刚刚生成的密钥进行加密通信

    11. 服务器Encrypted Handshake Message：服务器准备用刚刚的参数加密传输，验证加密通信

    12. 在双方都确认好了之后，最后是验证的消息。

    这里的核心是：通过非对称加密交换参数，生成对称通信加密的密钥，其中PreMaster是非对称加密传输的，保证了不会泄露通信加密的密钥。

  4. 然后开始通信

四、基于 TLS1.3 对安全性和性能的提升​

1. 安全性提升

这个版本中砍掉了很多不够安全点加密套件中的算法，只提供了少而精的加密套件。密钥交换算法废弃了RSA，更好地保证了安全性，不会因为RSA私钥泄露导致历史报文被破解的问题出现。

2. RSA密钥交换算法不够安全的原因？

假设有人故意截获了会话中所有的加密报文，在RSA算法中，如果私钥泄露，那么就可以推算出PreMaster和对称密钥，那么保存了所有的历史报文都会被破解。

3. 性能提升

上图我们看到，TLS 握手经历了两个 RTT。**TLS1.3**简化了握手过程，主要就是把原来两个 RTT 中的信息，打包成一个发送了，减少传输次数，最终只需要1个 RTT 就完成了信息的交换和握手。

用了HTTPS肯定会变慢，有什么提升速度的措施呢？

4. SSL 连接断开后如何恢复

共有两种方法来恢复断开的 SSL 连接，一种是使用 session ID，一种是 session ticket。

  1. 通过session ID: 使用 session ID 的方式，每一次的会话都有一个编号，当对话中断后，下一次重新连接时，只要客户端给出这个编号，服务器如果有这个编号的记录，那么双方就可以继续使用以前的秘钥，而不用重新生成一把。目前所有的浏览器都支持这一种方法。但是这种方法有一个缺点是，session ID 只能够存在一台服务器上，如果我们的请求通过负载平衡被转移到了其他的服务器上，那么就无法恢复对话。

  2. 通过session ticket: 另一种方式是 session ticket 的方式，session ticket 是服务器在上一次对话中发送给客户的，这个 ticket 是加密的，只有服务器能够解密，里面包含了本次会话的信息，比如对话秘钥和加密方法等。这样不管我们的请求是否转移到其他的服务器上，当服务器将 ticket 解密以后，就能够获取上次对话的信息，就不用重新生成对话秘钥了。