目录

一 HTTPS是什么

二 加密

三 加密方案

四 CA机构/证书

五 最终方案(对称密钥/非对称密钥/CA证书)和总体流程

---

一 HTTPS是什么

在应用层存在SSL，TLS(HTTP之下，传输层之上)加密/解密安全协议，如果HTTP经过这个协议，对端也走这个协议，那么就是HTTPS，HTTPS=HTTP+SSL/TLS。

上述如果采用HTTP协议走协议栈就不会走安全协议，因为HTTP都是按文本方式铭文传输，如果被中间人获取篡改可能就会有问题。

二 加密

1. 什么是加密

加密就是把明文数据加密成密文数据，通常加密过程中需要其他的数据辅助，这种数据称为密钥，比如"12345"(明文) => 密钥 => "xxxxx"(密文)。

2. 为什么要加密

下面来看一张图

如果不进行加密，传输的是明文数据被篡改，结果就不符合预期，中间客户端是感觉不到的，如果把明文进行加密密文，中间人就无法得知明文数据。

3. 对称加密 VS 非对称加密

1. 对称加密

只需要一个密钥进行加密或解密，比如A+密钥=B，B+密钥=A。

1. 常见对称加密算法 ： DES 、 3DES 、 AES 、 TDEA、 Blowfish 、RC2 等。

2. 特点：算法公开、计算量⼩、加密速度快、加密效率⾼。

2. 对称加密

需要2对密钥(公钥/私钥)，公钥公开，私钥不公开，公钥进行加密，私钥进行解密，或者私钥进行加密，公钥进行解密，比如A+公钥=B，B+私钥=A。

1. 需要两个密钥 来进行加密和解密，这两个密钥是公开密钥 （ public key ，简称公钥）和私有密钥（private key ，简称私钥)

2. 常见非对称加密算法 ( 了解 ) ： RSA ， DSA ， ECDSA等

3. 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，而使得加密解密速度没有对称加密解密的速度快

3. 数据摘要/数据指纹

数据摘要又称数据指纹，原理就是拿一组数据进行(hash函数)进行运算，得出来的结果是一组固定长度的字符串，这样的加密通常不可反向推出原数据(hash不可逆)，严格来说不算是一种加密方式，而是用来校验数据是否被篡改，比如 11111 + hash函数 = 101010110，如果原数据有一点的改动比如一字节一bit位，hash之后的结果和原来的结果差距极大。

1. 摘要常见算法：有 MD5 、 SHA1 、 SHA256 、 SHA512 等，算法把无限的映射成 有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率非常低）

2. 摘要特征：和加密算法 的区别是，摘要严格意义不是加密，因为没有解密，只不 过从摘要很难反推原信息，通常用来进行数据对比

三 加密方案

1. 第一种方案(对称加密)

采用一对对称密钥加密，客户端先把密钥传给服务器，服务器响应空的报头，客户端在拿密钥进行数据加密，服务器进行密钥解密，如果最开始中间人获取了密钥，客户端和服务器进行通信，加密后的数据被中间人拿到，中间人在拿之前获取的密钥进行解密就能进行篡改，监听等操作。如果对最开始的密钥进行加密，那么解密的密钥也要传给服务器进行解密，无限套娃，所以只采用对称加密不安全。

2. 第二种方案(非对称加密)

假设非对称密钥由服务器进行维护，客户端首先请求服务器，服务器响应给客户端S公钥，客户端在拿着公钥S进行加密发送给服务器，服务器拿着私钥S'进行解密。

问题1：公钥S是明文交换的，中间人拿到，当服务器对数据进行加密(私钥S)，客户端拿公钥S进行解密，中间人提取获取服务器加密后的数据，再拿着之前获取的公钥S进行解密，原数据被监听或篡改等。

问题2：每次数据交换采用非对称加密，效率低。

3. 第三种方案(2对非对称加密)

客户端和服务器各自持有自己的非对称密钥，客户端和服务器交换各自的公钥，客户端拿服务器的公钥加密，服务器拿自己的私钥解密，服务器拿客户但的公钥加密，客户端拿自己的私钥解密。

问题1：每次通信都采用非对称加密，效率低。

问题2：貌似双方只有自己持有私钥，保证了数据安全，但也有问题，下面来看看方案4。

4. 第四种方案(对称加密+非对称加密)

客户但维护对称密钥，服务器维护非对称密钥，服务器把公钥传给客户端，客户端拿公钥对自己的对称密钥进行加密，服务器拿自己的私钥进行解密，得到客户端对称密钥，后续采用客户端的对称密钥进行通信。

问题1：解决了方案2/3通信效率低的问题，只在密钥交换协商的适合进行非对称加密，后续通信采用客户端的对称密钥进行通信。

问题2：看似只有客户端和服务器持有对称密钥，实际呢？下面来看一张图

当服务器把自己的公钥传输给客户端的时候，中间人拿到，并用自己伪造的M公钥交给客户但，客户端拿中间人的公钥加密自己的对称密钥，传给服务器，中间人再次拿到客户端加密的数据，拿自己的私钥解密得到客户端的对称密钥，在用客户端的公钥和服务器的公钥加密，传给服务器，服务器解密，得到客户端的对称密钥，但客户端的对称密钥和服务器的公钥已被窃取，后续通信采用对称密钥，中间人已经有了对称密钥，所以也有问题。

上述最根本的问题是什么？当客户端第一次拿到服务器的公钥，由于中间人的篡改，无法甄别合法公钥的合法性，导致了后续的问题，要解决上述问题，引入CA证书。

四 CA机构/证书

服务器在使用HTTPS之前要去CA机构认领证书，提交的数据包括域名，服务器公钥等信息，CA机构给该数据进行hash加密形成摘要，在拿CA机构的私钥进行加密，形成签名，最终拿着原始数据和签名拼在一起，就形成了携带了签名的证书。

当客户端进行验证的时候，会拿着服务器发来的证书进行验证，通常客户端会内置CA机构的公钥，拿着公钥对签名解密形成摘要，在拿着原始数据进行hash加密形成的摘要，如果相同则该证书是合法的，否则不合法。

五 最终方案(对称密钥/非对称密钥/CA证书)和总体流程

首先服务器想使用HTTPS，得先去CA机构认领证书，提交材料(包括服务器的公钥)，认领完成，服务器把证书返回给客户端，客户端用CA公钥对签名进行解密形成摘要，在用数据进行hash(函数)形成摘要，进行比对，相同则证书合法，客户端在用合法的公钥和自己形成的对称密钥进行加密，服务器收到私钥进行解密得到客户端形成的对称密钥，自此只有客户端和服务器知道对称密钥，往后通信只用对称密钥即可。

如果证书局部被掉包？

签名不能掉包，签名只能由CA机构签名，中间人签的客户端不认。

数据掉包，客户端拿数据进行hash形成摘要，在拿签名和CA公钥进行解密比对不一样。

如果证书整个被掉包？

这种情况中间人只能自己也去CA机构申请真的证书，但申请证书需要提交材料信息等，中间人拿到真的证书，但域名不一样(域名具有唯一性)，客户端甄别前后域名不一样。

所以这种做法除了开始的密钥协商采用了非对称密钥，后续通信则用的是对称密钥，效率高，同时客户端也能验证服务器发来的证书是否合法。