网安—https原理--RSA密钥协商算法

一、TLS握手过程

HTTP是明文传输。

明文：客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。

所以安全上存在三个风险：

• 窃听风险        比如通信链路上可以获取通信内容，用户号容易没。
• 篡改风险        比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
• 冒充风险        比如冒充淘宝网站，用户钱容易没。

HTTPS是在HTTP与TCP之间加入了TLS协议，来解决上述的风险。

TLS协议是如何解决HTTP的风险呢？

• 信息加密：HTTP交互信息是被加密的，第三方就无法窃听；
• 校验机制：校验信息传输过程中是否呦被第三方篡改，如果被篡改过，则会有警告提示；
• 身份证书：比如说京东是真的京东网；

可见TLS协议保证了HTTP通信的安全，那么进行HTTP通信前，需要先进行TLS握手。

TLS握手（DHE密钥协商）：

上图简要概括了TLS的握手过程，通常经过「四个消息」就可以完成TLS握手，也就是需要2个RTT的时延。

所以我们可以发现HTTPS是应用层协议，需要先完成TCP连接建立，然后走TLS握手过程后，才能建立通信安全的连接。

不同的密钥交换算法，TLS的握手过程可能会有一些区别（主要区别是DHE/ECDHE协商有server key exchange握手过程，而RSA没有）。

密钥交换算法：因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，对称加密密钥是不能被泄露的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。

二、RSA密钥协商握手过程

 对应Wireshark的抓包，我们可以从下图很清晰地看出改过程：

看着上图，我相信大家云里雾里，接下来我带着大家一起学习TLS握手。

TLS第一次握手

客户端首先会发一个「Client Hello」消息，这里大家字面意思可以理解成这是跟服务器「打招呼」。

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

TLS第二次握手

当服务器收到客户端的「Client Hello」消息后，会确认TLS版本号是否支持，和密码套件列表中选择一个密码套件，还有选择压缩算法（当然由于安全性原因，一般不压缩），以及生成随机数（Server Random）。

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

可以从图上看到，服务器选择的的密码套件是"Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 "。

当然这个密码套件让很多人看起来头疼，其实它是有固定格式和规范的。基本形式为「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」，一般WITH单词前面有两个单词，第一个是约定密钥交换的算法，第二个是约定证书的验证算法。

如上的密码套件意思就是：

• 由于WITH单词前面只有一个RSA，则说明握手时密钥交换算法和签名算法都是使用RSA；
• 握手后的通信使用AES对称算法，密钥长度128位，分组模式是GCM；
• 摘要算法SHA256用于消息认证和产生随机数；

在前面两次客户端和服务端相互打招呼的过程中，双发确认了TLS版本和使用密码套件，并且还会将各自生成的随机传递给对方。

在这里细心的小伙伴可能就发现了这个随机数有啥用？其实呀这两个随机数是后续作为生成「会话密钥」的条件。

会话密钥：就是数据传输时所使用的对称加密密钥。

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

随后服务端发了「Server Hello Done」消息，目的就是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。

客户端验证证书

这里就要疑问了，要怎么校验该数字证书是真实有效的呢？

这就不得不提起数字证书和CA机构了

数字证书通常包括：

• 公钥
• 持有者信息；
• 证书认证机构（CA）的信息；
• CA对这份文件的数字签名及使用的算法；
• 证书有效期；
• 还有一些其他额外信息；

数字证书作用：是用来认证公钥持有者的身份，以防第三方进行冒充。通俗易懂的来说证书可以告诉客户端，该服务器是否是合法的，因为只有证书合法才能代表服务端身份是可信的。

CA（Certificate Authority，证书认证机构）：就是网络世界里的公安局、公证中心，具有极高的可信度。

为什么要签名？是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改。

数字证书签发和验证流程

CA签发证书的过程：

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

客户端校验服务端的数字证书的过程，上图右边部分：

• 首先客户端会使用同样的Hash值H1；
• 通常浏览器和操作系统中集成了CA的公钥信息，浏览器收到证书后可以使用CA的公钥解密Certificate Signature内容，得到一个Hash值H2；
• 最后比较H1和H2，如果相同，则为可信赖的证书，否则不可信。

TLS第三次握手

客户端验证完证书后，客户端就会生成一个新的随机数（pre-master），用服务的RSA公钥加密该随机数，通过「Change Cipher Key Exchange」消息传给服务端。

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

到这里，客户端和服务端双方都共享了三个随机数，分别是Client Random、Server Random、pre-master。

双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于后续HTTP请求/相应的数据加解密。

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

然后客户端再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否被中途篡改过。

可以发现，「Change Cipher Spec」之前传输的TLS握手数据都是明文，之后都是对称密钥加密的密文。

TLS第四次握手

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

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