HTTPS通信原理-证书交换

TLS握手过程

握手简述（以RSA为例）：

• client hello:客户端给出TLS协议版本号，支持的加密算法、随机数Client random、扩展字段
• server hello:服务端确认双方可支持的加密算法，并把数字证书下发给客户端。同时也会生成一个随机数Server random
• 客户端验证证书的有效性，并重新生成一个随机数Pre-main secret，使用证书中的公钥加密随机数，发送给服务端
• 服务端使用私钥获取随机数
• 客户端与服务端根据约定的加密算法，使用前面的三个随机数，生成对话密钥Session key，用来加密后续会话。

TLS需要知道的名词

1.会话密钥（Session key）

这是握手的最终结果。它是对称密码的密钥，并允许客户端和服务器相互加密消息。

2.客户端随机（Client random）

这是由客户端创建的32个字节的序列。它对于每个连接都是唯一的，并且应该包含四个字节的时间戳，后跟28个随机字节。最近，谷歌浏览器切换为使用32个字节的随机数，以防止客户端指纹。这些随机值通常称为随机数（nonce）。

3.服务器随机数(Server random)

服务器随机数与客户端随机数相同，只是服务器生成的随机数相同。

4.Pre-main密钥(Pre-main secret)

这是一个48字节的数据块。它可以与客户端随机变量和服务器随机变量结合使用，以使用“伪随机函数”（PRF）创建会话密钥(Session key）。

5.密码套件（Cipher suite）

CipherSpecs 用于认证加密算法和信息摘要算法的组合，通信双方必须同意这个密码规范才能进行通信。而 CipherSuites 则定义了 SSL / TLS 安全连接中所使用的加密算法的组合，该组合包含三种不同的算法：

• 握手期间所使用的的密钥交换和认证算法 (最常用的是 RSA 算法)
• 加密算法 (用于握手完成后的对称加密，常用的有 AES、3DES等)
• 信息摘要算法 (常用的有 SHA-256、SHA-1 和 MD5 等)

CipherSuites是用于组合构成TLS连接的算法的唯一标识符。它为以下列出的每个功能定义一种算法：

• 密钥建立（通常是Diffie-Hellman变体或RSA）
• 认证（证书类型）
• 机密性（对称密码）
• 完整性（哈希函数）

例如，密码套件是“ ECDHE-ECDSA-AES256-GCM-SHA384”，它定义了一个使用以下内容的会话：

• Elliptic Curve Diffie-Hellman Ephemeral（ECDHE）密钥交换以建立密钥
• Elliptic Curve Digital Signature Algorithms（ECDSA）进行身份验证
• 256-bit Advanced Encryption Standard in Galois/Counter mode (GCM) 用于确保机密性
• 384位的SHA(安全哈希算法)确保完整性

RSA握手

消息1：Client Hello

client hello包含客户端要使用的协议版本，以及一些开始握手的其他信息，包括客户端随机数（client random）和密码套件（cipher suites）列表。现行浏览器还包括他们要查找的主机名，称为服务器名称指示（SNI）。SNI使Web服务器可以在同一IP地址上托管多个域。

消息2：Server Hello

收到client hello后，服务器将选择进行握手的参数。密码套件的选择确定执行哪种类型的握手。服务器“ hello”消息包含服务器随机数，服务器选择的密码套件以及服务器的证书。证书包含服务器的公钥和域名。

消息3：Client Key Exchange

在验证证书是受信任的并且属于他们尝试访问的站点之后，客户端将创建一个随机的pre-main secret。此密钥使用证书中的公钥加密，然后发送到服务器。

收到此消息后，服务器将使用其私钥来解密此密钥。既然双方都有pre-main secret，并且客户端和服务器都具有随机性，那么他们都可以导出相同的会话密钥。然后，他们交换一条短消息以指示他们发送的下一条消息将被加密。

当客户端和服务器交换“完成”消息时，握手正式完成。正式的文本描述是：使用session key加密“client finished” or “server finished” 。双方之间的任何后续通信都使用session key加密。

这种握手优点是，在一个步骤中将密钥交换和身份验证结合在一起。理论上如果服务器可以正确导出会话密钥，则它们必须有权访问私钥，因此必须是证书的所有者。

这种握手的缺点是，它所保护的消息仅与私钥一样安全。假设第三方已记录了握手和随后的通信。如果该方将来可以访问私钥，则他们将能够解密主密码并导出会话密钥。这样他们就可以解密整个消息。即使证书已过期或吊销，也是如此。这将导致我们采用另一种形式的握手，即使私钥遭到破坏，该握手也可以提供机密性。

Ephemeral Diffie-Hellman 握手

它使用两种不同的机制：一种用于建立shared pre-main secret，另一种用于认证服务器。这依赖的关键功能是Diffie-Hellman密钥协商算法。

算法工作原理类似如下：

• a有密钥a，将g^a发送给b
• b有密钥b，将g^b发送给a
• a计算(gb)a
• b计算(ga)b
• a和b都以gab结尾，这是他们的共同密钥

消息1：Client Hello

就像在RSA中一样，client hello包含协议版本，客户端随机值，密码套件列表以及SNI扩展（可选）。

消息2：Server Hello

收到client hello后，服务器将选择进行握手的参数，包括ECDHE的曲线。服务器“ hello”消息包含服务器随机数，服务器选择的密码套件以及服务器的证书。

RSA和Diffie-Hellman握手在这一点上因新的消息类型而开始不同。

消息3：Server Key Exchange

为了启动Diffie-Hellman密钥交换，服务器需要选择一些启动参数并将其发送给客户端-这与我们上面描述的g^a相对应。服务器还需要一种方法来证明它具有对私钥的控制权，因此服务器会计算到目前为止所有消息的数字签名。Diffie-Hellman参数和签名都在此消息中发送。

消息4：Client Key Exchange

在验证证书是受信任的并且属于他们尝试访问的站点之后，客户端将验证从服务器发送的数字签名。他们还向客户端发送Diffie-Hellman握手的一半（对应于上面的g^b）。

此时，双方都可以根据Diffie-Hellman参数（对应于上面的gab）计算出pre-main secret。使用pre-main secret以及客户端和服务器的随机密钥，它们可以派生相同的会话密钥。然后，他们交换一条短消息以指示他们发送的下一条消息将被加密。

就像在RSA握手中一样，当客户端和服务器交换“Finished”消息时，此握手已正式完成。双方之间的任何后续通信都使用会话密钥加密。

Tips:与RSA相比采用DH算法后，Premaster secret不需要传递，双方只要交换各自的参数，就可以算出这个随机数。

Abbreviated handshake

TLS提供了一项好的机制，称为“会话恢复（session resumption）”。如果客户端先前已经与服务器建立了会话，并尝试再次连接，则可以使用Abbreviated handshake。有两种机制可以实现：会话ID和会话票证（session IDs and session tickets）。

会话ID要求服务器保持会话状态（即会话密钥）就绪，以防需要恢复先前的会话。对于会话票证，服务器在初始握手期间将会话票证（由用票证密钥加密的会话密钥组成）发送给客户端。在恢复会话时，客户端将加密的密钥发送回服务器，由服务器解密并恢复会话。无需使用私钥来恢复会话。

Firefox和Chrome是支持会话票证的主要浏览器。所有其他现行浏览器都通过会话ID支持恢复。大规模使用这些技术时面临的挑战之一是负载平衡。为了使服务器恢复连接，它需要具有先前建立的会话密钥。如果访问者尝试恢复与新服务器的连接，则该服务器需要以某种方式获取原始会话密钥（original session key ）。

会话恢复的主要问题在于，这并不意味着可以扩展到负载平衡的服务器。如果客户端在一个服务器上启动会话，则无法在另一台服务器上恢复该会话。这不是协议的失败，只是开源Web服务器中缺少的功能。

通过Keyless SSL，我们引入了高级会话恢复功能来解决此问题。这包括通过会话票证在全球范围内恢复会话，以及通过会话ID在数据中心内恢复会话。会话恢复使重复访问者的连接时间很快，因为无需返回到密钥服务器即可恢复连接。

补充知识

SNI：

在TLS握手阶段，客户端发送的信息之中不包括服务器的域名。也就是说，理论上服务器只能包含一个网站，否则会分不清应该向客户端提供哪一个网站的数字证书。这就是为什么通常一台服务器只能有一张数字证书的原因。

对于虚拟主机的用户来说，这当然很不方便。2006年，TLS协议加入了一个Server Name Indication扩展，允许客户端向服务器提供它所请求的域名。SNI使Web服务器可以在同一IP地址上托管多个域。

Keyless服务

放到CDN上的网站，可以不用提供自己的私钥，也能使用SSL加密链接。

如何做到：将密钥放到密钥服务器上

数字证书（digital certificate)

在非对称加密通信过程中，服务器需要将公钥发送给客户端，在这一过程中，公钥很可能会被第三方拦截并替换，然后这个第三方就可以冒充服务器与客户端进行通信，这就是传说中的“中间人攻击”(man in the middle attack)。解决此问题的方法是通过受信任的第三方交换公钥，具体做法就是服务器不直接向客户端发送公钥，而是要求受信任的第三方，也就是证书认证机构 (Certificate Authority, 简称 CA)将公钥合并到数字证书中，然后服务器会把公钥连同证书一起发送给客户端，私钥则由服务器自己保存以确保安全。

证书验证过程

• 服务端生成公钥和私钥
• 服务端发送公钥给CA
• CA生成证书给服务端
• 服务端再客户端请求时发送证书给客户端
• 客户端接收到证书之后发送给CA验证证书有效性
• 确认证书有效之后，才可以进行后续https通信

验证什么

• 检查数字签名
• 验证证书链
• 验证证书有效期
• 验证证书撤回状态
• 证书中有什么
• 证书所有者的公钥
• 证书所有者的专有名称
• 证书颁发机构的专有名称
• 证书的有效起始日期
• 证书的过期日期
• 证书数据格式的版本号
• 序列号，这是证书颁发机构为该证书分配的唯一标识符

流量解密

工具：wireshark

法一:使用私钥解密
条件：拥有私钥证书

缺点：无法解密 ECDHE 进行密钥交换的加密流量。

步骤

配置wireshark

编辑–>首选项–>protocols–>TLS

按照下图中填写IP地址、端口、协议、以及私钥文件。

 

保存配置，重新打开wireshark捕获流量，然后访问私钥对应的网站就可以解密流量了。

法二:SSLKEYLOGFILE
此方法对使用ECDHE 密钥交换方式的流量也可以，不需要私钥

步骤

添加环境变量：SSLKEYLOGFILE

Firefox 和 Chrome 会将每个 HTTPS 连接产生的 Premaster Secret 或 Master Secret 存储在环境变量SSLKEYLOGFILE对应的文件路径中。

Wireshark配置：

TLS debug file : 解密过程中的日志会记录到这里，可选配置

(Pre)-Master-Secret log filename 选项中选择环境变量SSLKEYLOGFILE配置的文件路径。

配置完成后，再访问 HTTPS 网站，sslkeylog.log 文件中将会有浏览器写入的数据。
确认之后就可以重新打开Wireshark进行抓包，可以看到解密流量了

参考资料
SSL/TLS协议运行机制的概述

图解SSL/TLS协议

session id & Session ticket参考

三种解密 HTTPS 流量的方法介绍
————————————————
版权声明：本文为CSDN博主「BlackFee」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/u013315560/article/details/108286278