我们都知道HTTP是明文传输，所以存在窃听、篡改和伪装等风险。为了解决这些问题，https出现了，https在http的应用层和传输层之间增加了一个SSL/TLS层，建立连接时增加了TLS层的四次握手，实现了信息加密、报文校验和身份证书等功能。

今天，我们就来探讨一下，TLS层的信息加密是如何实现的。

https的信息加密是混合加密，也就是对称加密与非对称加密。双方通通信开始前要协商密钥，密钥协商时采用的是非对称加密，进行通信时使用的对称加密。

在密钥协商阶段主要用到以下几种算法：

• RSA算法
• DH算法
• ECDHE算法

RSA算法

TLS第一次握手

clientHello阶段，客户端向服务器发送请求，发送SSL/TLS版本，发送客户端支持的密码套件列表，然后会产生一个随机数（Client Random），发送给服务器，这是生成对称密钥的材料。

第一次握手客户端做的事：

客户端clientHello，客户端发送请求

• 确定SSL/TLS版本

• 客户端生成的随机数，用于生成会话密钥（Client Random）

• 客户端支持的密码套件列表，如RSA算法

TLS第二次握手

服务器会确定自己所支持的SSL/TLS版本，如果不支持，则直接关闭此次连接。在客户端发送来的密码套件中选择一套。生成一个随机数（Server Random）

serverHello阶段，服务器响应客户端的请求，发送SSL/TLS版本，发送服务器选择的密码套件，发送随机数

密码套件：密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法

WITH单词前面只有一个单词RSA

• 密钥交换算法和签名算法都是RSA

• 加密对称算法采用的是AES算法，密钥长度为128位，分组模式为GCM

• 摘要算法为SHA256，用于消息认证和产生随机数

发送数字证书

最后会发一个Server Hello Done的信息

第二次握手服务器做的事：

服务器接收到客户端请求，进行响应

• 确定SSL/TLS版本，如果不支持，直接关闭

• 服务器生成的随机数，后面用于生成会话密钥（Server Random）

• 确定服务器支持的密码套件列表，如RSA加密算法

• 发送数字证书

客户端拿到服务器的响应后，会去验证证书的证实有效性

数字证书包含

• 公钥

• 持有者信息

• 有效时间

• 证书认证机构（CA）的信息

• 其他信息

数字证书的签发流程

• CA会把一些基本信息例如持有者、用途、有效信息等打包，然后运用Hash算法得到一个Hash值

• CA会使用自己的私钥将这个Hash值加密，生成一个Certificate Signature（证书签名），CA对证书进行了签名

• 最后将签名加到证书文件，形成数字证书

客户端验证证书的流程

• 客户端使用同样的Hash算法，得到该证书的Hash值H1

• 浏览器使用CA的公钥，解密Certificate Signature中的内容，得到Hash值H2

• 如果H1等于H2，则证明可信

TLS的第三次握手

证书有效，客户端生成一个随机数（pre-master），用服务器的RSA公钥加密，然后通过Change Cipher Key Exchange消息发给服务器

服务器收到后，用私钥解密收到pre-master

到此阶段，客户端和服务器共享了三个数，Client Random、Server Random、pre-master，双方根据这三个数生成密钥

生成密钥后客户端再发一个Change Cipher Spec告诉服务器开始使用加密通话

最后在发送一个Encrypted HandShare Message消息，向服务器发送握手摘要，再加密一下，让服务器验证

第三次握手客户端做的事：

向服务器进行响应

• 发送一个随机数（密钥），该随机数会被公钥加密（pre-master）

• 加密算法改变的通知，表示之后的会话都将用会话密钥进行加密（Change Cipher Key Exchange）

• 客户端响应结束通知，握手数据的摘要（Encrypted HandShare Message）

TLS的第四次握手

服务器也是相同操作，发送Change Ciper Spec和Encrypted HandShare Message

服务器进行响应

• 加密算法改变通知，表示之后的信息会用加密的密钥进行加密（Change Ciper Spec）

• 服务器响应结束通知，握手数据的摘要（Encrypted HandShare Message）

RSA算法的缺陷

RSA算法最大的问题就是不支持前向保密，服务器的私钥一旦泄露，被第三方截获的TLS密文都会被破解

所以才有了DH算法

DH算法

客户端和服务器都各自产生一个随机数，生成一个私钥，然后根据公开的DH算法，算出自己的公钥，再把这个公钥通过TLS互换，这要有了自己的私钥和对方的公钥，就可以解密报文。

即时公钥被截取了，在不知道私钥的情况下也无法计算出密钥。

但是DH算法存在计算效率的问题，所以出现了ECDHE密钥协商算法

ECDHE算法

根据私钥的生成算法，有两种模式

DH算法（服务器的私钥是不变的）缺点是时间长了服务器的私钥有被破解的可能

DHE算法（目前常用）E（ephemeral）的意思就是临时性的

双方的私钥在每次密钥交换通信时都是临时生成的。但是这种算法的性能不佳，所以出现了ECDHE算法

ECDHE算法

在DHE算法的基础上，利用了ECC椭圆曲线的特性，可以优化计算公钥和最终会话密钥的计算量

ECDHE算法流程（实质就是通过椭圆曲线特性计算公钥）

• 双方事先确定好使用什么椭圆曲线，和曲线上的基点G，两个参数都是公开的

• 双方各自随机生成私钥d，将G乘以私钥d得到公钥Q（Q=Gd），客户端的公私钥为d1和Q1，服务器的公私钥为d2和Q2

• 双方交换公钥，客户端计算d1Q2，服务器计算d2Q1，由乘法交换律和结合律得d2Q1 = d2d1G = d1d2G = d1Q2,双方的坐标都是一样的，实现了共享密钥

此过程双方的私钥都是随机、临时生成的，不公开的。

ECDHE握手

TLS第一次握手

与RSA的握手流程大致相同

TLS第二次握手

服务器生成自己的随机数，在客户端的密码套件列表中选择一个密码套件

密码套件的信息有所改变（密钥协商算法+签名算法+对称算法+摘要算法）

• 密码套件的密钥协商算法变为ECHDE

• 签名算法为RSA

• 对称算法为AES，密钥长度为256位

• 摘要算法采用SHA384

接着服务器会发送数字证书

然后就会发送Server Key Exchange的消息（RSA算法是在TLS第四次握手才发动）

这个过程服务器做了三件事

• 选择椭圆曲线，确定椭圆曲线的G点，公开给客户端

• 生成的随机数作为椭圆曲线的私钥，保留在本地

• 根据G点和私钥计算出服务端的椭圆曲线公钥Q2，公开给客户端

为保证公钥不被篡改，服务器会使用RSA算法加密公钥

最后发送Server Hello Done信息

TLS第三次握手

过程大致相同

此阶段多了客户端会生成随机数作为自己的私钥，然后根据服务器给的信息生成椭圆曲线公钥，然后发送Client Key Exchange消息给服务器。

至此对方的公钥，自己的私钥和椭圆曲线的G点都已经得到

最终密钥是通过客户端随机数+服务器随机数 * 共享密钥确定的

TLS第四次握手

与RSA握手流程基本一致