HTTPS 加密原理与 CA 数字证书：从对称加密到完整通信流程
-
- 一、HTTPS是什么
- 二、加密基础
-
- [1. 数字摘要](#1. 数字摘要)
- [2. 数字签名](#2. 数字签名)
- 三、HTTPS加密方案演进
-
- 方案一：对称加密
- 方案二：只使用非对称加密
- 方案三：双方都使用非对称加密
- [方案四：非对称加密 + 对称加密](#方案四：非对称加密 + 对称加密)
- 方案四仍存在的中间人攻击
- 四、CA数字证书
- 五、HTTPS完整通信流程
一、HTTPS是什么
HTTPS就是在HTTP的基础上加了一层加密层。加密是在传输层以下加密传输的，在应用层是明文的。
加密就是原始数据通过密钥加密后得到密文，然后密文再通过密钥就可以解密得到原始数据。
服务端（S）和用户端（C）进行HTTPS通信时，若通信内容涉及密码等需要加密的敏感数据，服务端会拥有自己的非对称密钥对（私钥由自身妥善留存，公钥用于对外传输），一个公钥一个密钥，公钥和密钥必须成对。
二、加密基础
1. 数字摘要
数字摘要也叫数字指纹，它的基本原理是利用单向散列Hash函数对信息运算，生成一串固定长度的数字摘要，可以实现把一大篇文章或者小文本（甚至一个字符）利用hash形成一个固定长度的字符串摘要，都是等长的。
这个数字签名和文章基本上是1:1的，就是你文章有一点改动都会使这个数字签名发生改变。所以可以用来对比两个文件是否是同一个文件，同一个文件经过hash就会得到相同的数列，不一样的文件非常大的概率会得到不同的序列。
它并不是加密机制，不存在解密过程，很难从摘要反推原始信息，主要用于判断数据是否被篡改。常见算法包括MD5、SHA1、SHA256、SHA512，由于是将无限的信息映射为有限长度输出，理论上会存在哈希碰撞，也就是不同信息算出相同摘要，MD5和SHA1已被证实可以人为构造碰撞，安全性较差，SHA256、SHA512更为安全。和加密算法最大区别就是摘要单向不可解密，只适合做数据对比校验，不能还原原始明文。
2. 数字签名
数字签名就是把你hash得到的序列再经过加密得到的就是数字签名。
在网络通信中我们要解决的主要就是：1. 内容被监听；2. 内容被篡改。
三、HTTPS加密方案演进
方案一：对称加密
通信双方客户端与服务器使用同一套密钥完成加解密，客户端利用密钥把明文加密为密文后在网络中传输，即便黑客截获密文，没有密钥就无法解析真实内容，以此保障数据安全。
但该方案存在明显短板：服务器要对接众多客户端就需要为每个客户端分配专属密钥，维护客户端与密钥的对应关系成本很高。同时最大难点是如何安全分发共享密钥，若明文传输密钥会被黑客截获，若加密传输密钥，又需要提前拥有另一密钥，陷入鸡生蛋、蛋生鸡的循环困境。
所以在进行正常的加密通信之前要解决的是对方怎么安全拿到密钥，所以单纯的对称加密行不通。
方案二：只使用非对称加密
服务器将公钥明文发送给客户端，客户端使用该公钥加密数据后发给服务器，该方向的数据只有服务器持有的私钥能够解密，客户端到服务器这条链路看似安全。
但公钥本身是明文传输，所有人都可以获取，服务器如果用私钥加密返回给客户端的数据，拦截到公钥的中间人就可以利用公钥解开服务器下发的报文，无法保障服务器到客户端方向的数据安全，同时单纯依靠这一组公私密钥也无法完整实现双向安全通信。
方案三：双方都使用非对称加密
服务端持有公钥S与私钥S'，客户端持有公钥C与私钥C'，通信时双方先明文互相交换公钥，客户端发送数据使用服务端公钥S加密，只能由服务端私钥S'解密，服务端返回数据使用客户端公钥C加密，只能由客户端私钥C'解密，看似实现双向加密通信。
但非对称加密运算开销大，整体执行效率很低，同时公钥为明文传输，依旧无法抵御中间人攻击，存在安全隐患。
方案三看似没有问题但是实际上仍然有安全问题，然后双方都要解密会导致效率低下。
方案四：非对称加密 + 对称加密
解决效率问题，结合非对称加密与对称加密。服务端持有非对称公钥S和私钥S'，客户端发起HTTPS请求拿到服务端明文传输的公钥S，客户端本地随机生成一份对称密钥C，使用公钥S对该对称密钥C进行加密后发送给服务器。
中间人即便截获这份密文，因为没有私钥S'，不能解密拿到对称密钥C。服务器收到密文后通过自身私钥S'解密，还原得到客户端生成的对称密钥C，之后客户端与服务器之间全部使用对称密钥C完成业务数据的加解密通信。
充分利用对称加密运算速度快的优势，仅密钥协商阶段使用开销更大的非对称加密，兼顾安全与传输效率。
方案四仍存在的中间人攻击
客户端向服务器发起连接请求之后，服务器会将自身的公钥S通过明文报文的方式传输给客户端，这份报文在网络传输途中会被中间人劫持，中间人提取并保存报文里真实的服务端公钥S，随后将报文中的公钥替换成中间人自己的公钥M，再把这份经过篡改的伪造报文转发给客户端。
客户端收到报文之后没有办法校验公钥的真实来源，便误以为接收到的公钥M就是目标服务器的公钥，于是客户端在本地随机生成本次会话所使用的对称密钥X，使用中间人公钥M对对称密钥X进行加密，生成密文报文向外发送，意图传递给服务器。
该报文会再次途经中间人并被截获，中间人调用自己的私钥M'完成解密，直接获取到明文状态的对称密钥X，至此中间人就掌握了后续双方全部通信所依赖的会话密钥。接着中间人取出此前保存的真实服务端公钥S，使用公钥S对对称密钥X重新加密，组装成全新的密文报文转发给真正的服务器。
服务器接收到报文后使用自身私钥S'解密，顺利得到对称密钥X，服务器全程无法感知密钥已经被第三方窃取。在这之后客户端和服务器双方都会使用对称密钥X开展加密通信，客户端发出的数据会被中间人截获，中间人可以使用密钥X解密读取全部报文内容，甚至能够修改报文数据，完成操作之后再使用X重新加密报文转发给服务器。
服务器返回的响应数据同样会经过中间人，遭受窃听与篡改，客户端与服务器始终认为双方正在进行安全的加密通信，但实际上所有传输的流量都完全处于中间人掌控之下。
产生该漏洞的根本原因在于公钥以明文形式在网络中传递，客户端缺少可靠的验证手段，无法确认收到的公钥确实来自目标服务器。
四、CA数字证书
为了解决公钥明文传输带来的中间人攻击漏洞，HTTPS引入了CA数字证书这套解决方案。
服务端在正式对外提供HTTPS服务之前，会先生成属于自己的公钥与私钥密钥对，将公钥、网站域名、申请者身份等信息封装在证书申请文件CSR当中，向权威的CA数字证书认证机构提交证书申请。
CA机构会先审核服务端的真实身份信息，审核通过之后就会生成一份完整数字证书，这份证书由两大部分组成：
- 一部分是证书明文信息，里面存放着服务端公钥、网站域名、证书发布机构、证书有效期、证书所有者等关键内容。
- 另一部分就是CA机构生成的数字签名。
数字签名的生成流程是：CA机构对证书全部明文信息执行哈希散列运算计算出数据摘要，再使用CA自身独有的私钥对这份哈希摘要做非对称加密，加密之后的结果就是数字签名。
当客户端向服务端发起网络连接请求的时候，服务端返回给客户端的不再是裸露的单独公钥，而是一整份经过CA签发的完整数字证书。
客户端拿到证书之后，会把证书拆分为证书明文信息和CA的数字签名两个部分。客户端操作系统或者浏览器内部已经预先内置了各个可信CA机构对应的公钥，客户端就使用这份预装可信CA公钥去解密证书携带的数字签名，解密之后可以得到CA当初计算出来的原始哈希摘要。
与此同时客户端会采用和CA签名时完全相同的哈希算法，重新对证书里面的明文信息做哈希运算，本地计算出新的一份哈希摘要，随后客户端将解密签名得到的哈希摘要与本地重新计算得到的哈希摘要进行对比。
如果两份哈希摘要完全相等，就能够证明证书传输途中没有被中间人篡改，证书内携带的服务端公钥是真实可信的。
这里的核心关键点在于：数字签名只能由CA机构的私钥加密生成，中间人即便劫持网络报文、篡改证书里的公钥或者其他明文内容，中间人没有CA机构的私钥，就无法伪造出合法有效的数字签名。篡改之后的明文经过哈希运算会得到完全不一样的摘要，伪造的签名也无法被浏览器内置的CA公钥正常解密。
一旦两份哈希摘要比对不一致，客户端就可以判定证书已经遭到篡改，当前存在中间人攻击风险，会立刻终止本次通信连接并抛出安全告警。
确认证书校验全部通过之后，客户端才会从合法证书当中取出服务端真实公钥，继续后续会话对称密钥的协商流程。
依靠非对称加密、对称加密加上CA证书认证三者相结合的这套机制，就可以从根源抵御中间人篡改公钥的攻击，以此保障HTTPS整个通信过程的身份可信与数据完整安全。
五、HTTPS完整通信流程
- 客户端向服务器发送建立连接请求，请求经过中间网络设备转发到达服务器。
- 服务器收到连接请求，返回携带证书的建立连接响应，响应经过中间网络设备转发给到客户端。
- 客户端拿到服务器返回的证书，依次执行校验：检查证书有效期；检查证书发布机构是否在系统可信列表；使用CA公钥解密证书签名得到hash1，本地计算证书内容得到hash2，对比hash1与hash2。
- 证书全部校验通过，客户端从证书中取出服务器公钥。
- 客户端本地随机生成对称会话密钥，使用服务器公钥加密该会话密钥，发送密文请求，报文经过中间网络转发至服务器。
- 服务器使用自身私钥解密报文，获取到客户端生成的对称会话密钥。
- 后续通信，客户端使用该对称密钥加密业务请求，将密文发出；服务器收到密文，用相同会话密钥解密，执行业务处理。
- 服务器处理完毕，使用这套对称密钥加密响应数据，回传密文响应。
- 客户端接收密文响应，使用会话密钥解密，获取服务器返回数据，往复完成业务交互。