【HTTPS】HTTPS RSA握手解析

TLS握手过程

HTTP由于是明文传输，所谓的明文，就是客户端与服务端通信的信息都是肉眼可见的，随时用一个抓包工具都可以接活通信的内容。

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

• 窃听风险，比如通信链路上可以获取通信内容。
• 篡改风险，比如强制植入垃圾广告。
• 冒充风险，比如钓鱼网站。

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

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

• 信息加密：HTTP交互信息是被加密的，第三方就无法窃取。
• 校验机制：校验信息UR书过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示；
• 身份证书：证明是真的网站。

可见，有了TLS协议，能保证HTTP通信是安全的了，那么在进行HTTP通信前，需要先进性TLS握手。如图1所示。

图1 TLS的握手过程

---

上图简要介绍了TLS的握手过程，其中每一个框都是一个记录，记录是TLS收发数据的基本单位，类似于TCP里的segment。多个记录可以组合成一个TCP包发送，所以通常经过四个消息局可以完成TLS握手，也就是需要2个RTT的时延，然后就可以在安全的通信环境里发送HTTP报文，实现HTTPS协议。

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

事实上，不同的秘钥交换算法，TLS的握手过程可能会有一些区别。

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

接下来，我们就以最简单的RSA秘钥交换算法，来看看它的TLS握手过程。

RSA握手过程

传统的TLS握手基本都是使用RSA算法来实现秘钥交换的，在将TLS证书部署服务端时，证书文件中包含一堆公私钥，其中公钥会在TLS握手阶段传递该客户端，私钥则一直留在服务端，一定要确保私钥不能被窃取。

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

TLS第一次握手

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

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

TLS第二次握手

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

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

该密码套件的基本形式是密钥交换算法+签名算法+对称加密算法+摘要算法。一般WITH单词前面有两个单词，第一个单词是约定秘钥交换的算法，第二个单词是约定证书的验证算法。比如刚才的密码套件的意思就是：

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

就前面这两个客户端和服务端相互【打招呼】的过程，客户端和服务端就已经确认了TLS版本和使用的密码套件，而且可以发现客户端和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。

那这个随机数有什么用呢？其实这两个随机数是后续作为生成会话秘钥的条件，所谓的会话秘钥就是数据传输是，所使用的的对称加密秘钥。

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

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

 客户端验证证书

客户端拿到了服务端的数字证书后，要如何校验该数字证书是真实有效的呢？

数字证书和CA机构

在说校验数字证书是否可信的过程前，我们先来看看数字证书是什么，一个数字证书通常包含了：

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

数字证书的作用，是用来认证公钥持有者的身份，以防止第三方进行冒充；简单来说，证书就是用来告诉客户端，高服务端是否合法。

我们用证书来认证公钥持有者的身份（服务端的身份），那证书又是怎么来的？又该怎么认证证书呢？

为了让服务端的公钥被信任，服务端的证书都是有CA签名的，CA就是网络世界里的公安局，公正中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。

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

数字证书签发和验证流程

CA签发证书的过程

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

客户端校验服务端的数字证书的过程：

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

证书链

但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向CA申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，有三级证书。

对于这种三级层级关系的证书的验证过程如下：

• 客户端收到baidu.com的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证baidu.com证书是否可信。于是，客户端根据badu.com证书中的签发者，找到该证书的颁发机构是“GlobalSign Organization Validation CA-SHA256-G2”,然后向CA请求该中间证书。
• 请求到证书后发现“GlobalSign Organization Validation CA-SHA256-G2”证书是由“GlobalSign Root CA”签发的，由于“GlobalSign Root CA”没有再上级签发机构，说明它是根证书，也就是自签证书。应用软件鬼检查此证书是否已预载于根证书清单上，如果有，则可以利用根证书中的公钥去验证“GlobalSign Organization Validation CA-SHA256-G2”证书，如果发现验证通过，就认为该中间证书是可信的。
• “GlobalSign Organization Validation CA-SHA256-G2”证书被信任后，可以使用“GlobalSign Organization Validation CA-SHA256-G2”证书中的公钥去验证baidu.com证书的可信性，如果验证通过，就可以信任baidu.com证书。

在这四个步骤中，最开始客户端只信任根证书GlobalSign Root CA证书的，然后“GlobalSign Root CA”证书信任“GlobalSign Organization Validation CA-SHA256-G2”证书，而“GlobalSign Organization Validation CA-SHA256-G2”又信任baidu.com证书，于是客户端也信任baidu.com证书。

总的来说，由于用户信任GlobalSign，所以由GlobalSign所担保的baidu.com可以被信任，另外由于用户信任操作系统或浏览器的软件商，所以软件商预载了根证书的GlobalSign都可以被信任。

为什么需要证书链这么麻烦？Root CA为什么不直接颁发证书，而是要搞那么多中间层级呢？

这是为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然证书如果失手了，那么整个信任链都会有问题。

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请求和响应了。

RSA算法的缺陷

使用RSA秘钥协商算法的最大问题时不支持前向保密。

因为客户端传递随机数（用于生成对称加密秘钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数，所以一旦服务端的私钥泄漏了，过去被第三方截获的所有TLS通讯密文都会被破解。

为了解决这个问题，后面就出现了ECDHE秘钥协商算法，我们现在大多数网站使用的正式ECDHE秘钥协商算法。