HTTPS是在HTTP的基础上进行了一层加密,加密就是把 明文 (要传输的信息)进行一系列变换,生成 密文 。解密就是把 密文 再进行一系列变换, 还原成 明文 。在这个加密和解密的过程中, 往往需要一个或者多个中间的数据, 辅助进行这个过程, 这样的数据称为 密钥。
HTTPS 的工作过程
既然要保证数据安全, 就需要进行 "加密". 网络传输中不再直接传输明文了, 而是加密之后的 "密文". 加密的方式有很多, 但是整体可以分成两大类: 对称加密(密钥由客户端生成) 和 非对称加密(服务器生成)。
对称加密其实就是通过同一个 "密钥" , 把明文加密成密文, 并且也能把密文解密成明文。引入对称加密之后, 即使数据被截获, 由于黑客不知道密钥是啥, 因此就无法进行解密, 也就不知道请求的真实内容是啥了。但事情没这么简单. 服务器同一时刻其实是给很多客户端提供服务的. 这么多客户端, 每个人用的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了, 黑客就也能拿到了). 因此服务器就需要维护每个客户端和每个密钥之间的关联关系, 这也是个很麻烦的事情。比较理想的做法, 就是能在客户端和服务器建立连接的时候, 双方协商确定这次的密钥是啥,但是如果直接把密钥明文传输, 那么黑客也就能获得密钥了,此时后续的加密操作就形同虚设了。因此密钥的传输也必须加密传输! 但是要想对密钥进行对称加密, 就仍然需要先协商确定一个 "密钥的密钥". 这就成了 "先有鸡还是先有蛋"的问题了. 此时密钥的传输再用对称加密就行不通了,这时就需要引入非对称加密。
非对称加密要用到两个密钥, 一个叫做 "公钥", 一个叫做 "私钥". 公钥和私钥是配对的. 最大的缺点就是运算速度非常慢,比对称加密要慢很多.通过公钥对明文加密, 变成密文,通过私钥对密文解密, 变成明文 。也可以反着用,通过私钥对明文加密, 变成密文,通过公钥对密文解密, 变成明文。客户端在本地生成对称密钥, 通过公钥加密, 发送给服务器. 由于中间的网络设备没有私钥, 即使截获了数据, 也无法还原出内部的原文, 也就无法获取到对称密钥。服务器通过私钥解密, 还原出客户端发送的对称密钥. 并且使用这个对称密钥加密给客户端返回的响应数据。后续客户端和服务器的通信都只用对称加密即可. 由于该密钥只有客户端和服务器两个主机知道, 其他主机/设备不知道密钥即使截获数据也没有意义。由于对称加密的效率比非对称加密高很多, 因此只是在开始阶段协商密钥的时候使用非对称加密,后续的传输仍然使用对称加密。那么接下来问题又来了: 客户端如何获取到公钥? 客户端如何确定这个公钥不是黑客伪造的(也称中间人,服务器生成一对公钥私钥,然后将公钥发送给客户端,但这个信息被黑客截获,然后黑客也生成一对公钥私钥,并将自己的公钥替换掉服务器的公钥,然后发送给客户端,这时客户端并不知道与它进行连接的不是服务器,直接使用发来的公钥对对称密钥进行加密后在发送给黑客,然后黑客使用自己的私钥对其进行解密,这样黑客就得到了对称密钥,然后再使用从服务器得到的公钥对其进行加密,然后服务器对其进行解密,后续与客户端进行数据交互就使用这个对称密钥,但此时黑客已经得到对称密钥,因此后续的数据交互都能被黑客所知晓)?
引入证书
解决这个问题的关键在于客户端如何确定这个公钥不是黑客伪造的,因此需要引入一个证书来证明这个公钥是来自服务器的。在客户端和服务器刚一建立连接的时候, 服务器给客户端返回一个 证书。这个证书包含了刚才的公钥, 也包含了网站的身份信息。这个 证书 可以理解成是一个结构化的字符串, 里面包含了以下信息: 证书发布机构 证书有效期 公钥 证书所有者 签名 等,当客户端获取到这个证书之后, 会对证书进行校验(防止证书是伪造的)。判定证书的有效期是否过期,判定证书的发布机构是否受信任(操作系统中已内置的受信任的证书发布机构),验证证书是否被篡改: 从系统中拿到该证书发布机构的公钥(该公钥不是通过网络传输,而是直接系统内置,客户端安装好window系统后,系统就会内置各种知名公正机构的公钥,因此黑客无法进行中间人), 对签名解密(签名由公正机构的私钥所生成,如果被替换,客户端解密不了), 得到一个 hash 值(称为数据摘要), 设为 hash1. 然后计算整个证书的 hash 值, 设为 hash2. 对比 hash1 和 hash2 是否相等。如果相等, 则说明证书是没有被篡改过的。(数据摘要会被证书发布机构的私钥所加密,避免它被其他设备所生成)
总结 HTTPS 工作过程中涉及到的密钥有三组 . 第一组 ( 非对称加密 ) : 用于校验证书是否被篡改 . 服务器持有私钥 ( 私钥在注册证书时获得 ), 客户端持有公钥( 操作系统包含了可信任的 CA 认证机构有哪些 , 同时持有对应的公钥 ). 服务器使用这个私钥对证书的签名进行加密. 客户端通过这个公钥解密获取到证书的签名 , 从而校验证书内容是否是篡改过 . 第二组 ( 非对称加密 ): 用于协商生成对称加密的密钥 . 服务器生成这组 私钥 - 公钥 对 , 然后通过证书把公钥传递给客户端. 然后客户端用这个公钥给生成的对称加密的密钥加密 , 传输给服务器 , 服务器通过私钥解密获取到对称加密密钥. 第三组 ( 对称加密 ): 客户端和服务器后续传输的数据都通过这个对称密钥加密解密 .。 其实一切的关键都是围绕这个对称加密的密钥. 其他的机制都是辅助这个密钥工作的 . 第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器. 第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥.
标签:公钥,加密,证书,流程,密钥,HTTPS,服务器,客户端 From: https://blog.51cto.com/u_15319978/7976931