一文读懂https中密钥交换协议的原理及流程

一、引言

http与https区别：HTTP 由于是明文传输，所以在安全性上存在以下三个风险：

• 窃听风险，因为明文传输，可以直接抓包获取传输的数据，就会导致信息的泄漏。
• 篡改风险，比如强制入垃圾广告。
• 冒充风险，如搭建一个某平台的仿真网站，通过DNS欺骗诱导用户访问。

HTTPS 在 HTTP 与 TCP 层之间加入了SSL/TLS 协议

HTTPS的通信过程:

1、 TCP的3次握手

2、 TLS的握手

3、 HTTP请求和响应

SSL/TLS 协议基本流程：

1、 客户端向服务器索要并验证服务器的公钥。

2、 双方协商生产「会话密钥」。

3、 双方采用「会话密钥」进行加密通信。

HTTPS 是如何解决上面的三个风险的呢？

• 混合加密的方式实现信息的机密性，解决了窃听的风险。
• 摘要算法的方式来实现完整性，它能够为数据生成独一无二的「指纹」，指纹用于校验数据的完整性，解决了篡改的风险。
• 将服务器公钥放入到数字证书中，解决了冒充的风险。

二、DH密钥交换协议

Diffie-Hellman(简称 DH)算法是WhitefieldDiffie和MartinHellman在1976年公布的一种密钥交换算法，它是一种建立密钥的方法，而不是加密方法，所以密钥必须和其他一种加密算法结合使用。这种密钥交换技术的目的在于使两个用户安全的协商一个会话密码。Diffie-Hellman密钥交换算法的有效性依赖于计算离散对数的难度。

基于此背景知识，可以定义Diffie-Hellman密钥交换算法。该算法描述如下图2.1：

图2.1 DH过程图

现在我们使用到的https通信协议，也就是用到这个协议去协商密钥，在传输前先把数据加密再进行传输，达到了会话安全的目的。

应用

应用非常广泛，在SSH、VPN、Https...都有应用，勘称现代密码基石。

拓展

ECC的密钥交换。https中的ECDHE算法协议。

缺点

图2.2 DH中间人攻击

三、RSA算法

RAS算法是由MIT的Ron Rivest,Adi Shamir和Len Adleman在1997年提出并于1978年首次发表的算法，可是说是最早提出的满足有要求的公钥算法之一。Rivest-Shamir-Adleman（RSA）算法自其诞生之日起就成为被广泛接受且被实现的通用公钥加密方法

四、解析密码协议在 https 中的应用

4.1https之RSA

RSA密钥交换算法协议的全过程如下图3.1.1所示。

3.1.1 RSA密钥交换协议过程

•RSA 算法来实现密钥交换，首先将TLS 证书部署服务端，证书文件中包含一对公私钥，其中公钥会在 TLS 握手阶段传递给客户端，私钥则一直留在服务端（一定要确保私钥不能被窃取）

•在 RSA 密钥协商算法中，客户端会生成随机密钥，并使用服务端的公钥加密后再传给服务端。根据非对称加密算法，公钥加密的消息仅能通过私钥解密，这样服务端解密后，双方就得到了相同的密钥，再用它加密应用消息

图3.1.2 RSA 握手过程包分析

第一次握手

客户端首先会发一个「Client Hello」消息

消息里面有客户端使用的TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random），这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。

第二次握手

1 SayHello

当服务端收到客户端的「ClientHello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数（Server Random）。

接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

2.2 Server Certificate

服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书。

1.3   Server Hello Done

服务端发了「ServerHello Done」消息，目的是告诉客户端，本次服务端侧打招呼完毕

第三次握手

1 Client Key Exchange

首先客户端验证证书，证书验证通过后，继续后面的操作。

客户端产生一个新的随机数 (pre-master)，并使用服务端的RSA公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。该随机数就是后面会话密钥的重要组成成分之一。

服务端得到客户端发来的随机数 (pre-master)后，可用 RSA 私钥解密。

3.2 ChangeCipher Spec

生成完会话密钥后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。

3.3  Finished

客户端再发一个「EncryptedHandshake Message（Finished）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用，以及验证之前握手信息是否有被中途篡改过。会话密钥（master secret）为randomClient+randomServer+ pre-master。

第四次握手

服务器也是同样的操作，发「ChangeCipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。

最后，就用「会话密钥」加解密 HTTP 请求和响应了。

RSA密钥交互的缺陷

使用 RSA 密钥协商算法的最大问题是不支持前向保密。因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。

为了解决这一问题，于是就有了 ECDHE 密钥协商算法

4.2 https之ECDHE

ECDHE密钥交换协议算法的全过程如下图3.2.1所示。与RSA（图3.1.1）密钥交换协议有一定的区别，服务端不会去初始话密码系统。

图3.2.1 ECDHE流程图

DH 密钥交换过程中，即使第三方截获了 TLS 握手阶段传递的公钥，在不知道的私钥的情况下，也是无法计算出密钥的，而且每一次对称加密密钥都是实时生成的，实现前向保密。

现在使用的交互协议是ECDHE， 即ECC + DH+E (即基于椭圆曲线的一次一密密钥交换协议, E:ephemeral)

图3.2.2 ECDHE会话网络包

第一次握手

客户端首先会发一个「ClientHello」消息，消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random）。

第二次握手

1 ServerHello

服务端收到客户端的「打招呼」，相应客服端，会返回「Server Hello」消息，消息面有服务器确认的 TLS 版本号，也给出了一个随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件。

2 Certificate

接着，服务端为了证明自己的身份，发送「Certificate」消息，会把证书也发给客户端。

3 ServerKey Exchange

这个过程服务器做了三件事：

•  选择了名为named_curve 的椭圆曲线，选好了椭圆曲线相当于椭圆曲线基点 G 也定好了，这些都会公开给客户端；
• 生成随机数作为服务端椭圆曲线的私钥，保留到本地；
• 根据基点 G 和私钥计算出服务端的椭圆曲线公钥，这个会公开给客户端。

为了保证这个椭圆曲线的公钥不被第三方篡改，服务端会用 RSA 签名算法给服务端的椭圆曲线公钥做个签名。

4 ServerHello Done

随后，就是「Server HelloDone」消息，服务端跟客户端表明：“这些就是我提供的信息，打招呼完毕”

至此，TLS 两次握手就已经完成了，目前客户端和服务端通过明文共享了这几个信息：Client Random、Server Random 、使用的椭圆曲线、椭圆曲线基点 G、服务端椭圆曲线的公钥，这几个信息很重要，是后续生成会话密钥的材料

第三次握手

1 KeyExchange

客户端收到了服务端的证书后，首先要校验证书是否合法，如果证书合法，那么服务端的身份就是没问题的。确认无误后，就可以继续往下走。

客户端会生成一个随机数作为客户端椭圆曲线的私钥，然后再根据服务端前面给的信息，生成客户端的椭圆曲线公钥，然后用「Client Key Exchange」消息发给服务端

至此，双方都有对方的椭圆曲线公钥、自己的椭圆曲线私钥、椭圆曲线基点 G。于是，双方都就计算出点（x，y），其中 x 坐标值双方都是一样的，前面说 ECDHE 算法时候，说 x 是会话密钥，但实际应用中，x 还不是最终的会话密钥。

TLS 握手阶段，客户端和服务端都会生成了一个随机数传递给对方

最终的会话密钥，就是用「客户端随机数 + 服务端随机数 + x（ECDHE 算法算出的共享密钥） 」三个材料生成的。

之所以需要3个，是因为客户端或服务器「伪随机数」的可靠性不可信，为了保证真正的完全随机，把三个不可靠的随机数混合起来，那么「随机」的程度就非常高了。

2 ChangeCipher Spec

算好会话密钥后，客户端会发一个「Change Cipher Spec」消息，告诉服务端后续改用对称算法加密通信。

3 EncryptedHandshake Message

接着，客户端会发「EncryptedHandshake Message」消息，把之前发送的数据做一个摘要，再用对称密钥加密一下，让服务端做个验证，验证下本次生成的对称密钥是否可以正常使用。

第四次握手

最后，服务端也会有一个同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。于是，就可以正常收发加密的 HTTP 请求和响应了。

五、RSA协议和ECDHE协议对比分析

5.1RSA 和 ECDHE 握手过程的区别

• RSA 密钥协商算法「不支持」前向保密，ECDHE 密钥协商算法「支持」前向保密；
• 使用了 RSA 密钥协商算法，TLS 完成四次握手后，才能进行应用数据传输，而对于 ECDHE 算法，客户端可以不用等服务端的最后一次 TLS 握手，就可以提前发出加密的 HTTP 数据，节省了一个消息的往返时间；
• 使用 ECDHE， 在 TLS 第 2 次握手中，会出现服务器端发出的「Server Key Exchange」消息，而 RSA 握手过程没有该消息；

5.2为什么RSA模式下知道证书私钥可以解密流量包？

由前面的流程可以看到，RSA密钥交换过程中，是客服端选择一个随机数作为会话密钥，然后用服务端证书的公钥加密，加密后的密文传输过去，然后服务端用私钥解密。

表面看是实现了密钥交换，但实际上，会话密钥还是在网络中进行了传输，因此每次数据表中都可以得到。得到后如果有服务端的证书和私钥，就可以解密了。

因此也称此为不具有前向安全性，只要服务端不换证书，那么所有证书范围内的会话都可以进行解密。对于旁路监听流量，拥有全量数据包的情况下，是可以全部解密的

5.3为什么ECDHE模式不可以解密流量包？

由前面的流程可以看到，与RSA密钥协商算法不同的是，ECDHE在进行会话密钥协商时，第2和第3次握手中，都是服务端与客服端生成自己的临时公私钥对，在网络中交换时，仅仅只是传输了公钥，会话密钥完全在本地计算，而且双方的私钥也未暴露在网络中，所以只是抓包和知道证书与私钥，也是不能恢复出会话密钥的。

参考文献

[1] William Stallings. 密码编码学与网络安全-原理与实践（第六版）[M].电子工业出版社, 2003.  

转载请注明来自网盾网络安全培训，本文标题：《一文读懂https中密钥交换协议的原理及流程》

标签：随机数https握手协议对称密钥tlstls协议rsa算法