文章目录
- [1. HTTPS是什么？](#1. HTTPS是什么？)
- [2. 加密是什么？](#2. 加密是什么？)
-
- [2.1 引入对称加密（效率高）](#2.1 引入对称加密（效率高）)
- [2.2 引入非对称加密（效率低）](#2.2 引入非对称加密（效率低）)
- [2.3 引入证书](#2.3 引入证书)
-
- [2.3.1 数据签名](#2.3.1 数据签名)
- [2.3.2 通过证书解决中间人攻击](#2.3.2 通过证书解决中间人攻击)
1. HTTPS是什么？
HTTP也是一个应用层协议，是在HTTP协议基础上引入了一个加密层。
HTTP协议内容大谱是按照文本的方式明文传输的，这就导致在传输的过程中会有被纂改的情况。
2. 加密是什么？
加密就是把明文(要传输的信息)进行一系列的变换，生成密文。
解密就是把密文再进行一系列的变换，还原成明文。
那么如何对数据进行加密呢？
2.1 引入对称加密（效率高）
对称加密就是加密和解密时使用的密钥时相同的。
使用对称加密，每个客户端都生成一个自己的密钥，这个密钥就是以后在HTTP通讯中使用的密钥，那么服务器就需要把客户端和密钥的关系维护起来。
客户端和服务器在第一次建立连接的时候就需要协商出来一个密钥，在协商密钥的过程肯定不能以明文传输，所以在协商密钥的时候也需要进行密文传输，所以就引入了非对称加密。
2.2 引入非对称加密（效率低）
非对称加密就是使用公钥加密用私钥解密；使用私钥加密用公钥解密。公钥加密的密文不能使用公钥加密；私钥加密的密文不能使用私钥解密。
私钥只保存在服务器，公钥保存在客户端。所有的客户端持有相同的公钥。
在客户端和服务端协商密钥时使用非对称加密进行加密，那么此时客户端和中间设备都持有公钥，服务器持有私钥。协商时，客户端使用公钥加密来传输协商的密文，此时即便中间设备截胡了信息但是中间设备没有私钥，并不能破解，也就拿不到协商的密钥了。之后被公钥加密的密钥传输到服务器，服务器使用私钥进行解密，获取到了协商的密文，服务器在给客户端返回响应的时候就会使用密钥加密要传输的数据。
在进行第一次协商正常通讯使用的密钥时，借助非对称加密，当正常密钥协商完成之后，所有的交互都使用对称加密进行通讯。
即便是这样，中间设备依旧可以使用一些特殊的手段获取到密钥：中间设备可以自己生成一对私钥和密钥，中间设备在客户端向服务器发送连接请求时拦截该请求，阻止其到达真实服务器，中间设备伪装成服务器把自己伪造的公钥发送给客户端。客户端将自己生成的此后进行通讯的密钥使用公钥加密发送给服务器时，中间设备再次进行拦截，此时就可以使用私钥进行解密，获取到客户端和服务器协商的密钥，然后再假装若无其事的把破解出来的密钥使用服务器真实发送的公钥进行加密发送给服务器，服务器接收到时就察觉不到，依旧使用自己持有的私钥进行正常解密。
那么此时仅仅引入一个非对称加密就解决不了被中间设备恶意破解的问题了，此时就又引入了一个验证公钥真伪的证书。
2.3 引入证书
服务器在使用HTTPS前，需要向CA机构申领一份数字证书，数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书中获取公钥就行了，证书就像身份证一样，证明服务器公钥的权威性。
这个把这个证书理解为一个结构化的字符串，里面包含了一下信息：证书发布机构、证书有效期、公钥、证书所有者、签名...
2.3.1 数据签名
签名的形成是基于非对称加密算法的，注意，目前暂时和https没有关系，不要和https中的公钥私钥搞混了。
当服务端申请CA证书的时候，CA机构会对该服务端进行审核，并专门为该网站形成数字签名，过程如下:
- CA机构拥有非对称加密的私钥A和公钥A'
- CA机构对服务端申请的证书明文数据进行hash（使用MD5算法等），形成数据摘要（是一个字符串）。
- 然后对数据摘要用CA私钥A'加密，得到数字签名S服务端申请的证书明文和数字签名S共同组成了数字证书，这样一份数字证书就可以颁发给服务端了。
为什么数据摘要在网络传输的时候一定要使用私钥加密形成数字签名呢？
常见的数据摘要算法有：MD5、SHA系列。
以MD5为例，我们不需要研究具体的计算签名的过程，只需要了解MD5的特点：
- 定长。无论多长的字符串，计算出来的MD5值都是固定的长度（16字节版本或32字节版本）。
- 分散。源字符串只要改变一点点，最终得到的MD5值都会差别很大。
- 不可逆。通过源字符串生成MD5 很容易，但是通过MD5 还原成源字符串理论上不可能的。
正因为MD5有这样的特性，我们可以认为：如果两个字符串的MD5 值相同，则认为这两个字符串相同。
此时，如果中间设备把内容进行修改并重新hash，客户端就分辨不出来了，所以被传输的哈希值不能传输明文，需要传输密文。所以CA使用自己的私钥加密形成数字签名，将证书内容和加密的数字签名合起来形成证书，办法给服务器，当客户端请求时就发给客户端，中间人没有CA私钥，就无法更改或者整体掉包，就能保证安全。最后，客户端通过操作系统中已经存了的证书发布机构的公钥进行解密，还原出原始的哈希值，再进行校验。
中间人有没有可能纂改该证书？即便中间人纂改了该证书，由于他没有CA机构的私钥，所以无法hash之后用私钥加密形成签名，那么也就没办法对纂改之后的证书形成匹配的签名。如果强行进行纂改的化，客户端收到该证书后会发现明文和签名解密后的值不一致，则说明证书已经被纂改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
有没有可能中间人直接掉包整个证书？因为中间人没有CA私钥，所以无法制作假的证书，所以中间人只能向CA申请真证书，然后用自己申请的证书进行掉包，这个确实能够做到证书的整体掉包，但是证书明文中包含了域名等服务端认证信息，如果整体掉包，客户端依旧能够识别出来。
为什么签名不直接进行加密，而是要先hash形成摘要？缩小签名密文的长度，加快数字签名的验证签名的运算速度。
2.3.2 通过证书解决中间人攻击
在客户端和服务端刚建立连接的时候，服务器就给服务端返回一个证书，这个证书包含了公钥，也包含了网站的身份信息。
当客户端获取到这个证书之后，会对证书进行校验（防止证书是伪造的）。
- 判定证书的有效期是否过期。
- 判断证书的发布机构是的受信任。
- 验证证书是否被纂改：从系统中拿到该证书发布机构的公钥，对签名进行解密
