HTTPS RSA握手过程 #

HTTP与HTTPS的区别

1. HTTP是超文本传输协议，信息是明文传输，存在安全风险的问题。HTTTPS则是解决HTTP不安全的问题。在TCP和HTTP之间加入了SSL/TLS安全协议，使得报文能加密传输。
2. HTTP连接建立相对简单，TCP三次握手之后便可以进行HTTP的报文传输，而HTTPS在TCP三次握手之后，还需要进行SSL/TLS的握手过程，才能进入加密报文传输。
3. HTTP的端口号是80，HTTPS的端口号是443
4. HTTPS需要向CA(证书权威机构)申请数字证书，来保证服务器的身份是可信的。

• HTTPS解决了哪些问题
  1. 信息加密：交互信息无法窃取
  2. 校验机制：无法篡改通信内容，篡改了就不能正常显示
  3. 身份证书：可以证明是真实的网站

加密技术 #

混合加密 #

通过混合加密的方式可以保证信息的机密性，解决了窃听的风险

对称加密和非对称加密 （1）对称加密加密与解密使用的是同样的密钥，所以速度快，但由于需要将密钥在网络传输，所以安全性不高。

（2）非对称加密使用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

（3） 解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

HTTPS采用的是 对称加密 和 非对称加密 结合的混合加密方式：

在通信建立前采用非对称加密的方式交换会话秘钥，服务器把公钥A发送给浏览器，浏览器随机生成一个用于对称加密的秘钥X，用公钥A对X进行加密传回服务器，服务器用私钥B进行解密，得到秘钥X，这样子两边都有秘钥X，而别人无法知道它，在之后的通信中，使用秘钥X对数据进行加密解密。

摘要算法 #

摘要算法用来实现完整性，能够为数据生成独一无二的「指纹」，用于校验数据的完整性，解决了篡改的⻛险。

客户端在发送明文之前会通过摘要算法算出明文的「指纹」，发送的时候把「指纹 + 明文」一同加密成密文后，发送给服务器，服务器解密后，用相同的摘要算法算出发送过来的明文的「指纹」，通过比较客户端携带的「指纹」和当前算出 的「指纹」，若「指纹」相同，说明数据是完整的。

数字证书 #

如何保证公钥不被篡改和信任度? #

借助第三方权威机构 CA (数字证书认证机构)，将服务器公钥放在数字证书(由数字证书认证机构颁发)中，只要证书是可信的，公钥就是可信的。

服务器把自己的公钥注册到CA，CA机构用自己的私钥将服务器的公钥进行数字签名，并颁发数字证书。建立通信之前，服务器先返回公钥和CA数字签名给客户端，客户端拿到数字签名后，使用CA的公钥（已经事先注入到浏览器或者系统中）进行确认数字证书的真实性，从数字证书获取到服务器的公钥后，使用它对报文加密后发送，服务器使用私钥进行解密。

数字证书和证书认证机构(CA) #

一个数字证书一般包括了：公钥、持有者信息、CA机构的信息、CA对这份文件的数字签名以及使用的算法、证书的有效期、还有一些额外的信息。

• CA签发证书的过程如下：对持有者的公钥、用途、颁发者、有效时间等信息打包，然后对这些信息进行Hash计算，得到一个Hash值；CA会使用自己的秘钥对hash值进行加密，生成数字签名Certificate Signature，后续将数字签名添加在文件证书上，形成数字证书；

• 客户端校验数字证书的过程：同样客户端会将同样的Hash算法获得该证书的hash值H1；通常浏览器或者操作系统已经集成了CA的公钥信息，浏览器收到证书后就可以使用CA的公钥解密数字签名，得到hash值H2，通过比对H1和H2是否相同来判断证书是否可信。

证书链 #

一般来说，我们向CA机构申请的证书都不是根证书颁发的，而是中间证书签发的。客户端收到网站的证书时，发现证书的签发者不是根证书，就会向CA请求中间证书；拿到中间证书后，回去判断它的签发者是不是根证书，如果是的话，检查此证书是否存在于预载入的根证书清单中，然后进行校验，如果通过则认为中间证书有效，再继续验证网站的证书。

一层层的验证形成了一条信任链，之所以有这么多中间证书，是为了保证根证书的绝对安全性，将根证书隔离地越严格越好，否则一旦根证书失守，那么整条信任链都会有问题。

SSL/TLS协议 #

基本流程：

• 客户端向服务器索要并验证服务器的公钥
• 双方协商产生「会话秘钥」
• 双方采用「会话秘钥」进行加密通信。

上图简述的就是TLS的握手 🤝 过程，其实每一个「实线框」就是一个记录，记录是TLS收发数据的基本单位，类似TCP里的segment。多个记录可以组合成一个TCP包发送

前两步就是『握手阶段』，共涉及4次通信，需要2个RTT时延：

RTT(Round-Trip Time)，往返时延。 在计算机网络中它是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认（接收端收到数据后便立即发送确认），总共经历的时延。 往返延时(RTT)由三个部分决定：即链路的传播时间、末端系统的处理时间以及路由器的缓存中的排队和处理时间。

1. 首先，客户端向服务器发起加密通信请求，也就是ClientHello

这一步，客户端主要向服务器发送一下内容

• 客户端支持的SSL/TLS协议版本
• 客户端生成的随机数（Client Random），用于后面产生「会话秘钥」
• 客户端支持的密码套件列表，如RSA加密算法

密码套件的命名也是有规则的，基本形式是：「密钥交换算法+签名算法+对称加密算法+摘要算法」 例如：TLS_RSA_WITH_AES_128_GCM_SHA256

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

2. 服务器收到客户端请求后，作出响应，也就是ServerHello

服务器回应的内容有：

• 确认SLL/TLS协议版本，如果浏览器不支持，则关闭加密通信
• 服务器生成的随机数（Server Random），用于后面生产「会话秘钥」
• 确认密码套件，如RSA加密算法
• 服务器的数字证书

3. 客户端收到回应后，首先通过浏览器（或者操作系统）中的CA公钥，确认服务器的数字证书的真实性，如果证书没有问题，客户端会从数字证书中取出服务器公钥，然后使用它加密第三个随机数。

向服务器发送一下信息：

• 一个随机数（pre-master），会被服务器公钥加密。
• 加密通信算法改变通知Change Cipher Spec，表示随后的信息都会将用「会话秘钥」加密通信。
• 客户端握手结束通知Encrypted Handshake Message(Finishd)，表示客户端握手阶段已经结束，同时会把之前所有发送的数据做个摘要，再用会话密钥(master secret)加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

此时服务端和客户端就同时有三个随机数，接着有双方协商的加密算法，各自生成本次通信的「会话秘钥Master Secret」。

4. 服务器收到客户端第三个随机数后，利用私钥解密出第三个随机数，然后通过协商的加密算法，计算出通信的「会话秘钥」。

然后向客户端发送最后的信息：

• 加密通信算法改变通知Change Cipher Spec，表示随后的信息都将用「会话秘钥」加密通信。
• 服务器握手结束通知Encrypted Handshake Message。表示服务器握手阶段已经结束。 如果双方都验证加密和解密没问题，那么握手正式完成。

至此，整个 SSL/TLS 的握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的 HTTP 协议，只不过用「会话秘钥」加密内容。

拓展 #

DH密钥交换 #

使用RSA密钥协商算法的最大问题是不支持前向保密，因为客户端传递随机数给服务端是使用服务端公钥加密，服务端收到之后，会用秘钥解密得到随机数。一旦服务端的私钥被第三方截取，那么所以的TLS通讯密文都会被破解。

为了解决这个问题，就出现了DH密钥协商算法。

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

但因为 DH 算法的计算效率问题，后面出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法。