🚗🚗🚗今天给大家分享的是HTTPS加密的工作过程。
清风的CSDN博客
🛩️🛩️🛩️希望我的文章能对你有所帮助，有不足的地方还请各位看官多多指教，大家一起学习交流！
✈️✈️✈️动动你们发财的小手，点点关注点点赞！在此谢过啦！哈哈哈！😛😛😛
目录
一、引入对称加密
二、非对称加密
三、引入证书
四、总结
一、引入对称加密
一个简单的对称加密, 按位异或：假设明文 a = 1234, 密钥 key = 8888，则加密 a ^ key 得到的密文 b 为 9834。然后针对密文 9834 再次进行运算 b ^ key, 得到的就是原来的明文 1234。(对于字符串的对称加密也是同理, 每一个字符都可以表示成一个数字) 。当然, 按位异或只是最简单的对称加密，HTTPS 中并不是使用按位异或。
二、非对称加密
- 通过公钥对明文加密, 变成密文
- 通过私钥对密文解密, 变成明文
也可以反着用：
- 通过私钥对明文加密, 变成密文
- 通过公钥对密文解密, 变成明文
服务器生成一对公钥和私钥，私钥自己留着，公钥发送给客户端。客户端就可以拿着公钥进行对称密钥的加密，对于黑客来说，可以拿到加密后的对称密钥的密文，但是无法解密。即使黑客手里可能有公钥，但是并没有私钥。而要对公钥加密的密文进行解密，只能用私钥。这样就可以有效的保证数据的安全。(此处使用非对称加密，只是针对“对称密钥”进行加密)。因为非对称加密运算量很大，效率很低。
到此为止，还是不能保证数据的安全。可以试想一下，如果黑客入侵网络设备之后，生成一对公钥和密钥，然后对客户端：假装自己是服务器，而对服务器：假装自己是客户端，这样从中截获：
此时，也会导致数据不安全。那么，如何解决这一问题呢？继续往下看。
三、引入证书
解决中间人攻击的关键，是让客户端能够确认当前收到的公钥确实是服务器返回的，而不是黑客伪造的，因此引入证书机制，即第三方认证机构，通过第三方认证机构作保来确认当前的公钥是有效的。
- 首先，服务器要去第三方公正机构申请证书，此时机构会审核服务器的资质，审核通过就可以得到证书，证书包含很多属性和字段：证书发布机构 、证书有效期、公钥、证书所有者、数字签名等等。数字签名是针对上述数据进行的一个验证机制，公正机构在生成证书的时候，会先针对证书中的其他属性生成校验和。
- 其次，公正机构还会使用自己的私钥针对上述的校验和加密，别人无法重新生成。
- 在客户端向服务器发起申请建立连接时，服务器给客户端返回证书(证书里面包含公钥)。
- 当客户端收到证书之后，就会针对证书进行验证，检查证书是否合法。为什么客户端可以验证加密的证书呢？这是因为客户端持有公正机构的公钥，这个公钥不是通过网络传输的，而是系统内置的，黑客无法对次环节进行攻击。
验证步骤：
- 判定证书的有效期是否过期
- 判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构)
- 验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥, 对签名解密, 得到一个 hash 值(称为数据摘要), 设为 hash1，然后计算整个证书的 hash 值, 设为 hash2， 对比 hash1 和 hash2 是否相等。如果相等, 则说明证书是没有被篡改过的。
此时，无论黑客是直接替换公钥，还是把公钥和数字签名一起替换，都能被客户端发现。
四、总结
- 第一组(非对称加密): 用于校验证书是否被篡改，服务器持有私钥(私钥在注册证书时获得), 客户端持有公钥(操作系统包含了可信任的 CA 认证机构有哪些, 同时持有对应的公钥)。服务器使用这个私钥对证书的签名进行加密，客户端通过这个公钥解密获取到证书的签名, 从而校验证书内容是否是篡改过。
- 第二组(非对称加密): 用于协商生成对称加密的密钥，服务器生成这组 私钥-公钥 对, 然后通过证书把公钥传递给客户端，然后客户端用这个公钥给生成的对称加密的密钥加密, 传输给服务器, 服务器通过私钥解密获取到对称加密的密钥。
- 第三组(对称加密): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密。
其实一切的关键都是围绕这个对称加密的密钥，其他的机制都是辅助这个密钥工作的 ：
- 第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器
- 第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥
🚗🚗🚗好啦，今天的分享就到这里，别说还挺晕的，哈哈哈。多看几遍就行啦！也有可能是我没有给大家表述清楚，有什么问题欢迎大家指出。
🎉🎉🎉创作不易，还希望各位大佬支持一下！
✈️✈️✈️点赞，你的认可是我创作的动力！
⭐⭐⭐收藏，你的青睐是我努力的方向！
✏️✏️✏️评论：你的意见是我进步的财富！
