HTTPS协议通信流程分析

1、TLS握手过程：

完整的 HTTPS 的通信TLS握手过程:

明文->非对称加密->对称加密

第一步：浏览器给出TLS协议版本号、一个客户端生成的随机数1(Cientrandom)，以及客户端支持的加密方法。(明文通讯)

第二步：服务器确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数2 (Server random)。

 

"Change Cipher Spec"（更改密码规范）是在密码学和网络安全协议中，特别是在 TLS（Transport Layer Security）和 SSL（Secure Sockets Layer）协议中使用的一个重要概念。以下是关于它的详细介绍：

• 定义：Change Cipher Spec 是 TLS/SSL 协议中的一个消息类型，用于通知通信双方即将切换到新的加密密钥和加密算法组合。
• 作用：在 TLS/SSL 握手过程中，客户端和服务器会协商加密算法和密钥。当双方就这些参数达成一致后，会通过发送 Change Cipher Spec 消息来表示接下来的数据将使用新协商好的加密配置进行保护，从而确保通信的保密性和完整性。
• 工作原理：
  • 首先，客户端和服务器通过握手消息交换来协商加密算法、密钥长度等参数。
  • 一旦协商完成，双方都会各自生成新的密钥材料，并向对方发送 Change Cipher Spec 消息。
  • 收到 Change Cipher Spec 消息的一方会确认并切换到新的加密状态，之后双方就使用新的加密配置来加密和解密通信数据。

例如，当用户访问一个使用 HTTPS 协议的安全网站时，浏览器和网站服务器之间会进行 TLS 握手，在握手过程中会包含 Change Cipher Spec 消息的交换，以确保后续传输的网页内容、用户登录信息等数据的安全性。

HTTP over TLS-也就是 HTTPS（Hypertext Transfer Protocol Secure），它是 HTTP 协议的安全版本，通过结合 HTTP 和 TLS（Transport Layer Security）协议来保障数据在传输过程中的安全性和完整性。下面为你详细介绍：

工作原理

• 握手阶段：客户端与服务器初次建立连接时，会开展 TLS 握手。此过程中，双方会协商 TLS 版本、加密算法，并验证服务器证书（部分情况下也会验证客户端证书），同时生成会话密钥。
• 加密通信阶段：握手完成后，双方使用协商好的加密算法和会话密钥对 HTTP 数据进行加密与解密操作，进而实现安全的数据传输。

优点

• 数据保密性：借助加密技术，防止数据在传输过程中被窃取或监听。即使数据被截取，攻击者由于没有正确的解密密钥，也无法获取其中的内容。
• 数据完整性：利用消息认证码（MAC）等技术，确保数据在传输过程中未被篡改。若数据被修改，接收方能够检测到这种变化。
• 身份验证：通过使用数字证书，客户端可以验证服务器的身份，确保其与合法的服务器进行通信，有效防止中间人攻击。

回复：

    TLSv1.3 Record Layer: Handshake Protocol: Server Hello 给出另一半的key_share
    TLSv1.3 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec 开启握手加密
    TLSv1.3 Record Layer: Application Data Protocol: Application Data     ---->EncryptedExtensions (加密握手过程)
    TLSv1.3 Record Layer: Application Data Protocol: Application Data    ---->Certificate 下发服务器证书 (加密握手过程)
    TLSv1.3 Record Layer: Application Data Protocol: Application Data    ---->CertificateVerify 验证证书 (加密握手过程)
    TLSv1.3 Record Layer: Application Data Protocol: Application Data    ---->Finished 结束服务端协商 (加密握手过程)

发送：

    TLSv1.3 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec 开启对称加密
    TLSv1.3 Record Layer: Application Data Protocol: Application Data    ---->Finished 结束客户端协商 (加密握手过程) 

发送

    TLSv1.3 Record Layer: Application Data Protocol: Application Data 对称秘钥
回复

    TLSv1.3 Record Layer: Application Data Protocol: Application Data 对称秘钥

第三步：浏览器确认数字证书有效，然后生成一个新的随机数3(Pre:master secret)，并使用数字证书中的公钥加率这个随机数，发给服务器。(使用非对称加密算法)

 浏览器确认数字证书有效:浏览器和操作系统内部内置了很多CA机构的证书，是否篡改、是否在有效期内、域名和访问的网站是否匹配。

第四步：服务端使用自己的私钥，获取客户端发来的随机数(即Premastersecret)。

双方就都有三个一模一样的随机数，前两个是明文发送的，最后客户端生成的这个是使用证书中的公钥密文发送的。

第五步：客户端和服务器根据约定的加密方法，使用前面的三个随机数经过特定的算法，生成"对话密钥"(session key)，用来加密接下来的整个对话过程。

对话密钥，又叫做会话密钥，其实就是讲之前通讯中的三个随机数生成一个密钥(对称加密)
三个随机数…-->第三个是使用非对称加密->相同的算法……>会话密钥。

第六步:客户端和服务器都会第一次使用会话密钥加密一个消息发送给对方。

备注:客户端收到服务端发送的Certificate 报文后首先会校验证书的合法性:

• 证书路径信任链逐级校验通过(证书确由可信 CA 认证签发)。
• 签名解密成功(确系证书持有者亲笔)。
• 从签名解析出的摘要和证书公开内容的摘要一致(证书内容完整，未被算改)。
• 主题子域与 URL 中的 HOST 一致，综上确保访问的网站是来白预期目标服务器且非劫持或钓鱼。

2、session的恢复

握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。

这时有两种方法可以恢复原来的session:一种叫做sessionID，另一种叫做session ticket。

session!D的思想很简单，就是每一次对话都有一个编号(sessionID)。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的“对话密钥"，而不必重新生成一把。

上图中，客户端给出session ID，服务器确认该编号存在，双方就不再进行握手阶段剩余的步骤，而直接用已有的对话密钥进行加密通信。sessionID是目前所有浏览器都支持的方法，但是它的缺点在于session |D往往只保留在一台服务器上。所以，如果客户端的请求发到另一台服务器，就无法恢复对话。session ticket就是为了解决这个问题而诞生的，目前只有Firefox和Chrome浏览器支持。

上图中，客户端不再发送session1D，而是发送一个服务器在上一次对话中发送过来的session ticket。这个sessionticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。