HTTPS RSA握手解析
TLS握手过程
HTTP由于是明文传输,所谓的明文,就是说客户端与服务端通信的信息都是肉眼可见的,随意使用一个抓包工具都可以截获通讯内容
HTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。
所以安全上存在以下三个风险：
- 窃听风险
- 篡改风险
- 冒充风险
TLS 协议是如何解决 HTTP 的风险的呢？
- 信息加密： HTTP 交互信息是被加密的，第三方就无法被窃取；
- 校验机制：校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示；
- 身份证书：证明淘宝是真的淘宝网；
可见，有了 TLS 协议，能保证 HTTP 通信是安全的了，那么在进行 HTTP 通信前，需要先进行 TLS 握手。TLS 的握手过程，如下图：
上图简要概述了TLS的握手过程,其中每一个框都是一个记录(record),记录是TLS收发数据的基本单位,类似与TCP里的segment.多个记录可以组合成一个TCP包发送,所以经常通过四个消息就可以完成TLS握手,也就是需要2个RTT时延,然后就可以在安全的通信环境里发送HTTP报文实现HTTPS协议
可以发现HTTPS是应用层协议,需要先完成TCP连接建立,然后走TLS握手过程后,才能建立通信安全连接
事实上,不同 秘钥交换算法,TLS的握手过程可能有一些区别
简单介绍下秘钥交换算法,因为考虑到性能的问题,所以双方在加密应用信息是使用的是对称加密秘钥,而对称加密秘钥是不能被泄露的,为了保证加密秘钥的安全性,所以使用非对称加密的方式来保护对称秘钥加密秘钥的协商,这个工作就是秘钥交换算法来负责的
接下来用最简单的RSA秘钥交算法,来看看TLS握手的过程
RSA握手过程
传统的TLS握手基本都是使用RSA算法来实现秘钥交换的,再将TLS证书部署服务端时,证书文件其实就是服务端的公钥,会在TLS握手阶段传递给客户端,而服务端的私钥则已知留在服务端,一定要确保私钥不能被窃取.
再RSA秘钥协商算法中,客户端会生成随机秘钥,并使用服务端的公钥加密后再传给服务端.根据非对称加密算法,公钥加密的消息仅能通过私钥解密,这样双方就得到了相同的秘钥,再用它加密应用信息
我用 Wireshark 工具抓了用 RSA 密钥交换的 TLS 握手过程，你可以从下面看到，一共经历了四次握手：
对应 Wireshark 的抓包，我也画了一幅图，你可以从下图很清晰地看到该过程：
那么,接下来针对每一个TLS握手做进一步介绍
https://www.bilibili.com/video/BV18N411X7ty
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 （Certificate Authority，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。
之所以要签名，是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改。
数字签发证书和验证流程
CA签发证书的过程,如上图左边部分
- 首先CA会吧持有者的公钥用途,颁发者,有效时间等信息打一个包,然后对这些信息进行hash计算,得到一个hash值
- 然后CA会降自己的私钥将该hash值加密,生成 Certificate Signature，也就是CA对证书做签名
- 最后将 Certificate Signature添加在文件证书上,形成数字证书
客户端校验数字证书的过程,如右边上图
- 首先客户端会使用同样的Hash算法获取该证书的Hash值H1
- 通常浏览器和操作系统中集成了CA公钥信息,浏览器收到证书后可以使用CA的公钥解密 Certificate Signature内容,得到一个Hash值H2
- 最后比较H1和H2如果值相同,则为可信赖的证书,否则则认为证书不可靠
但事实上，证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的，比如百度的证书，从下图你可以看到，证书的层级有三级：
对于这种三级层级关系的证书的验证过程如下：
- 客户端收到 baidu.com 的证书后，发现这个证书的签发者不是根证书，就无法根据本地已有的根证书中的公钥去验证 baidu.com 证书是否可信。于是，客户端根据 baidu.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公钥加密该随机数,通过[client Key Exchange]消息传递给服务端
服务端收到后,用RSA私钥解密,得到客户端发来的随机数
至此,客户端和服务端双方都共享了是哪个随机数分别是 client Random,ServerRandom,Pre-master
于是双方根据已经得到的三个随机数,生成会话秘钥(Master secret),它是对称秘钥,用于对后续的HTTP请求/相应的数据加解密
生成完「会话密钥」后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。
然后客户端再发一个Encrypted Handshake Message（Finishd）消息,把之前所有发送数据做个摘要,再用会话秘钥(master secret)加密一下,让服务器做个验证,验证加密通信是否可用和之前握手信息是否有被中途篡改过
可以发现，「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。
TLS 第四次握手
服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。
最后，就用「会话密钥」加解密 HTTP 请求和响应了。
缺陷
使用RSA秘钥协商算法的最大问题是不支持向前保密
因为客户端传递随机数()
因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。
为了解决这个问题，后面就出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法，关于 ECDHE 握手的过程，将在下一篇揭晓。