不能不知道的https原理 --- RSA密钥协商算法

HTTP和HTTPS对比及解决方案

http是明文传输，所以数据容易暴露。
https是在http和TCP层之间加入了TLS协议
数据的传输过程中要保证不被别人截获查看、修改数据的内容、确保传输的对象是自己想要的对象
所以总结起来就是三点：

• 防止信息被窃听
• 防止信息被篡改
• 确定服务端（也就是信息传输的额接收端）的合法性

所以TLS协议在此应用

• 加密信息：避免了信息泄露
• 校验信息：比较校验结果，以此来检验信息有无篡改
• 身份验证：确保合法性

RSA密钥协商算法握手过程

客户端和服务器建立连接时先进行TCP会话连接（三次握手）
然后进行TLS的四次握手

TLS第一次握手

客户端首先给服务器发送client hello（中间要是加个冒号就是客户端在跟服务器说你好了）
在这个数据包中携带的信息都有：

1. TLS的版本
2. 支持的密码套件
3. 支持的压缩算法
4. 生成的随机数（生成对称加密的重要数据）client random

TLS第二次握手

服务端在收到客户端的数据包后，会在数据包提供的信息中查看TLS版本是否支持，然后选择出密码套件、压缩算法（一般不压缩）、生成返回客户端的随机数（server random）
密码套件的基本格式是：
密钥交换算法+签名算法+对称加密算法+摘要算法
服务端还得证明自己是真正的服务端
所以给客户端发送server certificate（服务器合格证书）来正身，在这个数据包中包含数字证书
然后发送server hello down，进行接下来的步骤

TLS第三次握手

客户端在验证完证书的合法性后，合法则继续接下来的步骤。
客户端生成一个随机数（per-master），使用服务端的RSA公钥加密传输给服务端，服务端收到以后私钥解密得到随机数。
至此，双方都收到协商中的三个随机数，根据三个随机数生成会话密钥，这个密钥时对称密钥

之后客户端发送Change Cipher Spec 数据包，在通信时使用密钥，并且将之前的绘画内容进行摘要，使用生成的密钥进行加密，验证密钥是否可用以及会话内容是否被篡改

TLS第四次握手

服务端进行相同的操作进行验证
双方验证完成后，确认功能正常，则服务就响应了

RSA算法缺陷及解决方案

RSA算法不支持向前保密，一旦服务端的私钥泄露，则使用服务端公钥加密的随机数就会暴露，所以过去具被截获的TLS加密会话都会被破解。
为了解决这一问题，于是就有了 DH 密钥协商算法
DH 密钥协商算法工作流程：
客户端和服务端各自会生成随机数，并以此作为私钥，然后根据公开的 DH 计算公示算出各自的公钥，通过 TLS 握手双方交换各自的公钥，这样双方都有自己的私钥和对方的公钥，然后双方根据自己的私钥和对方的公钥计算出一个随机数，这个随机数的值双方都是一样的，由于私钥未经过传递，所以计算出的随机数就可以作为后续对称加密时使用的密钥。

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

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