从零开始认识https协议
1 什么是https协议
之前的文章中我们详细的讲解了http协议，从代码底层的实现一步一步的理解了http协议。其中我们根据http协议中请求和应答的结构重点实现了http协议中的httpRequest和httpResponse。进行通信时，浏览器（客户端）会向服务端发送请求，请求中的所有信息（请求行 ，URL ，cookie ，正文…）都是明文。明文是没有进行过加密的信息，那么就会造成一些安全问题。
- 客户端与服务端进行通信不是直接进行通信的，而是通过第三方的运营商进行信息的中转。
- 作为中间人的运营商就能够看到客户端和服务端通信的信息是是什么，这样势必会造成用户隐私的泄漏！
为了避免这样的问题，最要紧的就是将信息进行加密，把明文转换为密文，这样运营商就不会轻易的获取到客户端与服务端之间的信息了！而由此诞生的就是https协议！https协议中会进行一些加密算法：
- 对称加密：采用单钥密码系统的加密方法， 同一个密钥可以同时用作信息的加密和解密， 这种加密方法称为对称加密， 也称为单密钥加密。
- 特征： 加密和解密所用的密钥是相同的
- 常见对称加密算法(了解)： DES、 3DES、 AES、 TDEA、 Blowfish、 RC2 等
- 特点： 算法公开、 计算量⼩、 加密速度快、 加密效率⾼
- 非对称加密：需要两个密钥来进行加密和解密， 这两个密钥是公开密钥（public key， 简称公钥） 和私有密钥（private key， 简称私钥） 。
- 特征：非对称加密要用到两个密钥, 一个叫做 “公钥”, 一个叫做 “私钥”。公钥和私钥是配对的。 最大的缺点就是运算速度非常慢， 比对称加密要慢很多。
- 常见非对称加密算法(了解)： RSA， DSA， ECDSA
- 特点： 算法强度复杂、 安全性依赖于算法与密钥但是由于其算法复杂， 而使得加密解密速度没有对称加密解密的速度快。
当然仅仅通过加密算法，还是不能保证安全，需要使用相应的策略！
2 https通信方案
2.1 只使用对称加密
如果通信双方都各自持有同一个密钥 X， 且没有别人知道， 双方就可以通过密钥加密与解密，而作为中间人由于不知道密钥，无法获取真正的信息，所以这两方的通信安全当然是可以被保证的（除非密钥被破解）。
但是，矛盾的一点是：如何让双方都持有同一个密钥？
- 如果每次通信，第一次进行时都由客户端（浏览器）将密钥交给服务端，注意这里的密钥在通信中也是进行了加密。服务端收到信息之后，根本就还没获得密钥，又如何将密钥从信息中解密出来呢？
- 如果不将密钥进行加密传输，直接把密钥明文传输, 那么中间人也就能获得密钥了，此时后续的加密操作就形同虚设了！
所以只使用对称加密是不可行的！
2.2 只使用非对称加密
鉴于非对称加密的机制：**需要客户端和服务端分别持有公钥和私钥。**那么想要进行通信的话就也需要将密钥进行通信！
- 如果服务器先把公钥以明文方式传输给浏览器， 之后浏览器向服务器传数据前都先用这个公钥加密好再传， 从客户端到服务器信道似乎是安全的(其实也是有安全问题的，后面讲解中间人攻击)， 因为只有服务端有相应的私钥能解开公钥加密的数据。但是服务器到浏览器的这条路怎么保障安全？
- 如果服务器用它的私钥加密数据传给浏览器， 那么浏览器用公钥可以解密它， 而这个公钥是一开始通过明文传输给浏览器的， 若这个公钥被中间人劫持到了， 那他也能用该公钥解密服务器传来的信息了！
所以只使用非对称加密是不可行的！
2.3 双方都使用非对称加密
- 服务端拥有公钥 S1 与对应的私钥 S2， 客户端拥有公钥 C1 与对应的私钥 C2
- 客户和服务端交换公钥
- 客户端给服务端发信息： 先用 S1 对数据加密， 再发送， 只能由服务器解密， 因为只有服务器有私钥 S2
- 服务端给客户端发信息： 先用 C1 对数据加密， 再发送， 只能由客户端解密， 因为只有客户端有私钥 C2
我们画图解释一下：
这样由于使用的是非对称加密，效率是比较低的！并且其实这种方案也怕中间人攻击，后面我们来讲！
2.4 非对称加密 + 对称加密
既然你说双方都使用非对称加密效率较低，那么我们使用对称加密+非对称加密的策略，效率是不是就更好了一些！
- 服务端具有非对称公钥 S1 和私钥 S2
- 客户端发起 https 请求， 获取服务端公钥 S1
- 客户端在本地生成对称密钥 C， 通过公钥 S1 加密, 发送给服务器.
- 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥(一样也怕中间人攻击！ )
- 服务器通过私钥 S2解密，还原出客户端发送的对称密钥 C。并且使用这个对称密钥加密给客户端返回的响应数据。后续客户端和服务器的通信都只用对称加密即可。
- 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义
我们来画图理解一下：
这样只需要在第一次通信时使用非对称加密，其余通信都是对称加密，所以效率可以保证了。
这样看似已经很安全了，但是也是有安全隐患的：中间人攻击。这个我们反复提了很多遍，这到底是什么东西，怎么就攻击性这么强，加密看似无懈可击，怎么还能被攻击？！
3 中间人攻击
中间人攻击：Man-in-the-MiddleAttack， 简称“MITM 攻击”。
我们所以的4中方案中，可以说最优的就是方案四。方案 4 中， 客户端获取到公钥 S1 之后， 对客户端形成的对称密钥 C，用服务端给客户端的公钥 S1进行加密， 中间人即使窃取到了数据， 此时中间人确实无法解出客户端形成的密钥 C， 因为只有服务器有私钥 S2，也就是说服务器才能解密出正确的对称密钥。
但是中间人的攻击， 如果在最开始握手协商的时候就进行了， 那就不一定了， 假设黑客已经成功成为中间人。那么事情就会变得十分有趣了：
- 首先，现在黑客已经作为了服务端和客户端的中间人，成为中间人的方式有很多（手机热点 ， 假wifi ，假网站，平时大家要注意保护自己的信息安全）
- 中间人首先会接受到服务端向客户端以“明文”形式发送的公钥S1 ， 这时他自身创建一对非对称密钥M1/M2，他将中间人公钥M1发送给客户端。
- 客户端收到中间人转发的信息，获得了中间人的公钥（客户端认为这就是服务端公钥）。然后客户端通过公钥M1将自身的对称密钥C加密后传输给中间人。
- 中间人通过私钥M2解密出来客户端的对称密钥，然后随便使用服务端密钥S1加密一些信息发送给服务端就行了。
- 至此，中间人的局已经做好，中间人拥有了进行通信的对称密钥！客户端发送的所有的信息都会被中间人劫持！并且服务端也会接收到使用公钥S1加密的数据！客户端和服务端都不会发出端倪！
这里最大的问题就是客户端无法知道获取的公钥是否可信，所以无论使用什么方案，都没有办法保证绝对的安全！因此就需要一些其他手段进行保护！
4 签名与CA证书
4.1 签名
签名的形成是基于非对称加密算法的， 注意， ⽬ 前暂时和 https 没有关系， 不要和https 中的公钥私钥搞混了：
进行发送数据时，无论是什么类型的数据，都可以通过散列函数（摘要算法）获取到一个散列值（数据摘要）。散列值通过签名者的私钥进行加密，这样的散列值具有唯一性！！！原始数据和散列值拼接到一起，获得到带有数字签名的数据。最终发送的数据就是带数字签名的数据！！！
接收到数据时，先将原始数据和签名分开，然后原始数据通过同样的散列算法再次获得到一个散列值。将签名通过签名者的公钥进行解密，新散列值和签名进行比较，最终就可以判断数据是否有被更改了！
这样就能保证数据不被更改了，因为这个世界上使用签名者有自己的私钥！也就意味着，只有签名者对数据具有签名的权利！其他人无法解开！
4.2 CA证书
CA 证书：即“证书授权中心”（Certificate Authority）证书 ，服务端在使用 HTTPS 前， 需要向 CA 机构申领一份数字证书， 数字证书里含有证书申请者信息、 公钥信息等。 服务器把证书传输给浏览器， 浏览器从证书里获取公钥就行了， 证书就如身份证， 证明服务端公钥的权威性！其主要功能是验证和证明公钥所有者的身份，确保公钥和特定实体（个人、组织、服务器等）之间的绑定关系是真实可靠的。
需要注意的是： 申请证书的时候， 需要在特定平台生成， 会同时生成一对密钥对， 即公钥和私钥。 这对密钥对就是用来在网络通信中进行明文加密以及数字签名的。
其中公钥会随着 CSR 文件， 一起发给 CA 进行权威认证， 私钥服务端自己保留， 用来后续进行通信（其实主要就是用来交换对称密钥）。
通过CA证书，客户端可以知道公钥是否合法，是否是目标网址！并且因为其带有签名，所以就算会是明文信息，中间人更改会造成签名不对等，从而被识破！
5 https通信最终方案
https最终的通信方案是：非对称加密 + 对称加密 + 证书认证！
服务端会先去CA认证机构申请证书，来保证其可以进行通信！
在客户端和服务器刚一建⽴连接的时候，服务器给客户端返回一个CA证书， 证书包含了之前服务端的公钥, 也包含了网站的身份信息。这样客户端就可以识别公钥是否合法：
客户端进行认证：当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的).
- 判定证书的有效期是否过期。
- 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)。
- 验证证书是否被篡改：从系统中拿到该证书发布机构的公钥，对签名解密，得到一个 散列值(称为数据摘要)，设为 hash1。然后计算整个证书的散列值，设为 hash2. 对比 hash1 和 hash2 是否相等。如果相等，则说明证书是没有被篡改过的
CA证书验证解决了中间人掉包公钥的问题，保证了客户端可以获取正确的公钥！并且通过数字签名，可以保证传输证书过程中中间人无法修改证书的明文信息，因为中间人没有证书的私钥，无法形成正确的签名！在客户端验证签名时就会出错！
这样我们就理解了https协议是如何保证网络安全通信的了！！！