流程比较长，需要点耐心读下去。^_^
HTTPS、TLS、SSL之间的关系
HTTP协议是明文传输，在网络传输过程中不能保证机密性（机密性——确保信息不被非法获取），于是HTTPS协议在HTTP的基础上加入了TLS（Transport Layer Security）;
HTTPS = HTTP + TLS
TLS是一种保障数据传输安全的一种技术（方案），它规定了如何为网络中传输的数据进行加密和解密。
TLS和SSL和OpenSSL的关系:
- 可以简单的理解为：TLS = SSL
想知道TLS和SSL的关系，先看看他们的历史：
-
过去人们遇到数据传输安全问题，网景公司设计SSL协议（Secure Sockets Layer安全套接字层），主要用于Web的安全传输，这种协议在Web上获得了广泛的应用；
-
网景公司后来将SSL贡献给 IETF 组织，并最终重命名为 TLS。所以SSL是TLS前身，是一种继承关系；
-
-
...
TLS/SSL方案的历史版本，都被发现了设计缺陷，于是被禁用，并升级了协议。现在要是还有人在使用历史版本的TLS/SSL，说明存在风险。
SSL和OpenSSL的关系？
- SSL是一套技术方案；
- OpenSSL是一个加解密的工具包。
冷知识：
除了HTTPS外，TLS可以被应用于任何基于TCP/IP协议的上层协议或应用程序，如SFTP协议、SMTP协议、数据库间通信加密等等。
TLS具体是怎么确保在网络中通信安全?
下文将描述客户端和服务端两个角色，他们对话的过程，以及其中怎么确保传输内容的机密性。从不安全的方案开始设计，逐渐演化成安全的方案。那么从第一个问题开始讲起，TLS怎么保证数据在传输中的机密性？
下面来看 TLS 1.3 的握手流程：
对称加密
TLS采用了AES这样的对称加密算法去加密数据，然后在网络中传输加密过的数据，即使被中间人拦截，中间人没有密钥，也无法解密。这样就解决了数据被中间人拦截问题。
什么是对称加密？
对称加密是指通讯双方根据协商好的算法，生成一个唯一的密钥，该密钥将同时运用于对数据进行加密、解密操作。
对称加密的关键，加密/解密的双方都需要有相同的密钥。问题是，Client和Server都没有见过面，怎么能有一把相同的密钥呢？
下面是双方协商出来一个会话密钥过程：
预主密钥：
通过生成的一串随机字符串，生成一个预主密钥，这个预主秘钥的作用是用来生成会话密钥。
会话密钥：
你和网站之间的每一次会话，都需要一把密钥，每次会话的都是有时间期限的，这样有期限的密钥称为会话密钥。
有了会话密钥，通讯双方就可以使用这个会话密钥对数据进行加密、解密了。
【这个预主秘钥和会话密钥的生成过程是 ECDHE 算法，ECDHE 算法不是本文的核心，先大致知道流程就行。】
虽然对称加密解决了数据加密的问题，但如何确保预主秘钥能够安全的传输给服务器端，则成了当前最大的难题。
因为在传输过程中，一旦被中间拦截，预主秘钥的泄露，中间人则可以创建出和客户端相同的会话密钥，最终导致后续的所有数据都被破解的风险。
为了将预主秘钥能安全的传输到对方，TLS引入了另一种加密技术非对称加密。通过非对称加密的方式来传输预主秘钥。
非对称加密
什么是非对称加密？
与对称加密不同的是，非对称加密包含两个不同的密钥，公钥和私钥；
公钥用于加密，
私钥用于解密，
公钥对外公开，任何都可以随意获取，
而私钥则必须保证其安全性，只有拥有者自己才能知道。
将非对称加密这一过程运用到TLS中，流程如下：
首先，Server生成一对公私密钥对，
与对称加密过程一样，客户端和服务器端首先协商好TLS版本，加密算法等，
Server还会把公钥发送给客户端，
客户端在生成预主秘钥之后，
使用公钥加密成密文，
再把密文传递回去给Server,
Server使用私钥解密，得到预主秘钥。
双方基于预主秘钥，得到一把相同的会话密钥。
以上看似很美好，但其实，还存在一个重大的安全隐患！
你以为的公钥，难道真的是Server发给你的？
如果在一开始，你的通话就被中间人拦截，公钥是黑客生成的，然后传递给你的，那么后续的一系列步骤都是不安全的。
为了解决这个公钥是谁的公钥的问题？
需要引入了证书机制。
那么对应的，Client不需要公钥，而是需要Server的证书。
【PKI 不是本篇的重点，先了解大致节点即可。】
数字证书
数字证书 - Digital Certification ， 下文简称证书。
什么是证书？
证书由证书颁发机构 Certificate Authority(简称 CA)所签发。
功能是：唯一标识一个站点的身份信息。
简而言之：
证书就是一个网站的身份证，用来帮助用户鉴别一个网站的真伪。
我们主要关注：
- 证书是如何唯一标识网站身份？
- 客户端收到证书后，又是如何验证身份的？
CA 签发证书的过程：
-
首先 CA 收到站点申请者的CSR（Certificate Secure Request）证书请求文件，文件包含申请者的公钥、颁发者、有效时间等信息打成一个包，然后对这些信息进行 Hash 计算，得到一个 Hash 值；
-
然后 CA 会使用自己的私钥对该 Hash 值加密，生成 Certificate Signature；
-
最后将 Certificate Signature 附在在文件证书的最后，形成数字证书；
客户端校验服务端的数字证书的过程：
-
客户端会使用同样的 Hash 算法获取该证书的 Hash 值 H1；
-
通常浏览器和操作系统中已经预置各大 CA 的根证书，根证书里面有根CA的公钥，浏览器收到证书后可以使用 CA 的公钥解密 Certificate Signature 内容，得到一个 Hash 值 H2 ；
-
最后比较 H1 和 H2，如果值相同，则为可信赖的证书，否则则认为证书不可信。
证书链验证：
- 如果是中间CA颁发的证书，需要验证整个证书链直到根CA；
- 确保链中的每个证书都是有效的；
证书的验证过程中，存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间CA机构的私钥签发的，比如百度的证书，从下图你可以看到，这个案例中的证书层级有三级：
使用上一层的CA证书的公钥对其进行解密，如果H1和H2完全一致，则说明验签成功，确保该证书是上一层CA所签发的。也说明证书在传输过程中，没有被人截获并篡改其内容。从而确保了证书的完整性，进而实现了证书身份的核实。
其实还有一个问题：
如果安全的获取根CA的公钥呢？
其实这个是个套娃式的追问问题，毕竟很有可能在获取根CA公钥的时候，就被篡改了。
但是，很显然，这个问题在这里就停止了，没有绝对的安全，现在只追求相对的安全，预安装就是这个问题的尽头。每台电脑出厂的时候，都会预安装各大CA根证书，维护根证书库。
我们必须信赖一个预安装的CA根证书，必须有个起点。当需要验证证书签名时，就去系统获取对应的CA根证书即可。
而且现在有很多HSM安全硬件方案了，预安装也是一个相对安全的过程。扯远了...
完整的TLS 1.3 通信流程：
Reference
【网络】浅析 HTTPS 的 TLS（ECDHE）握手流程（图解）
https://mp.weixin.qq.com/s/kKO9WlgJClHDS_kB9H6c4A
TLS 1.0 至 1.3 握手流程详解
https://www.cnblogs.com/enoc/p/tls-handshake.html
浏览器验证SSL数字证书的步骤
https://blog.yuantops.com/tech/how_do_web_broswer_validate_ssl_certificates/
手工验证一张数字证书的有效性
https://blog.yuantops.com/tech/validate_a_digital_certificate_step_by_step/
带你详细了解TLS、HTTPS以及证书的底层原理-上
https://www.bilibili.com/list/watchlater?oid=1555427198
