■面试官求你了，别再问我HTTPS( 二 )

SSL(Secure Sockets Layer)安全套接层和 TLS(Transport Layer Security)传输层安全协议其实是一套东西。
网景公司在 1994 年提出 HTTPS 协议时，使用的是 SSL 进行加密。
后来 IETF(Internet Engineering Task Force)互联网工程任务组将 SSL 进一步标准化，于 1999 年公布第一版 TLS 协议文件 TLS 1.0 。目前最新版的 TLS 协议是 TLS 1.3 ，于 2018 年公布。
工作流程
我们先来看看 HTTPS 的加解密流程，如下图：

本文插图

HTTPS 加解密流程如下：

用户在浏览器发起 HTTPS 请求(如 https://www.mogu.com/) ，默认使用服务端的 443 端口进行连接。
HTTPS 需要使用一套 CA 数字证书，证书内会附带一个公钥 Pub ，而与之对应的私钥 Private 保留在服务端不公开。
服务端收到请求，返回配置好的包含公钥 Pub 的证书给客户端。
客户端收到证书，校验合法性，主要包括是否在有效期内、证书的域名与请求的域名是否匹配，上一级证书是否有效(递归判断，直到判断到系统内置或浏览器配置好的根证书) ，如果不通过，则显示 HTTPS 警告信息，如果通过则继续。
客户端生成一个用于对称加密的随机 Key ，并用证书内的公钥 Pub 进行加密，发送给服务端。
服务端收到随机 Key 的密文，使用与公钥 Pub 配对的私钥 Private 进行解密，得到客户端真正想发送的随机 Key 。
服务端使用客户端发送过来的随机 Key 对要传输的 HTTP 数据进行对称加密，将密文返回客户端。
客户端使用随机 Key 对称解密密文，得到 HTTP 数据明文。
后续 HTTPS 请求使用之前交换好的随机 Key 进行对称加解密。

本文插图

对称加密与非对称加密
又是对称加密又是非对称加密，一会公钥一会私钥一会随机 Key ，为什么要这么复杂呢，一套搞到底不好么?
对称加密是指有一个密钥，用它可以对一段明文加密，加密之后也只能用这个密钥来解密得到明文。
如果通信双方都持有密钥，且天知地知你知我知，绝对不会有别的人知道，那么通信安全自然是可以得到保证的(在密钥足够强的情况下) 。
然而，在 HTTPS 的传输场景下，服务端事先并不知道客户端是谁，你也不可能在事先不通过互联网和每一个网站的管理员都悄悄商量好一个通信密钥出来。
那么必然存在一个密钥在互联网上传输的过程，如果在传输过程中被别人监听到了，那么后续的所有加密都是无用功。
这时，我们就需要另一种神奇的加密类型，非对称加密。
非对称加密有两个密钥，一个是公钥，另一个是私钥。一般来说，公钥用来加密，这时密文只能用私钥才能解开。
那么，当客户端发起连接请求，服务端将公钥传输过去，客户端利用公钥加密好信息，再将密文发送给服务端，服务端里有私钥可以解密。
但是，当服务端要返回数据，如果用公钥加密，那么客户端并没有私钥用来解密，而如果用私钥加密，客户端虽然有公钥可以解密。
但这个公钥之前就在互联网上传输过，很有可能已经有人拿到，并不安全，所以这一过程只用非对称加密是不能满足的。
注意，严格来讲，私钥并不能用来加密，只能用作签名使用，这是由于密码学中生成公钥私钥时对不同变量的数学要求是不同的。
因此公钥私钥抵抗攻击的能力也不同，在实际使用中不可互换。签名的功能在 HTTPS 里也有用到，下文中会说明。