我们都知道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握手流程基本一致