【HTTPS协议原理】数据加密、如何防止中间人攻击、证书和签名、HTTPS完整工作流程

目录数据加密常见的加密方式数据摘要方案一仅使用对称加密方案二仅使用非对称加密方案三双方都使用非对称加密方案四非对称加密 对称加密CA认证证书方案五非对称加密 对称加密 证书认证HTTPS完整流程数据加密HTTPS 也是一个应用层协议是在 HTTP 协议的基础上引入了一个加密层。因为 HTTP 的内容是明文传输的明文数据会经过路由器、wifi 热点、通信服务运营商、代理服务器等多个物理节点如果信息在传输过程中被劫持传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉这就是中间人攻击所以我们才需要对信息进行加密。加密就是把明文进行一系列变换生成密文解密就是把密文再进行一系列变换还原成明文。在加密和解密的过程中往往需要一个或多个中间数据辅助这个过程这样的数据称为密钥。常见的加密方式对称加密采用单钥密码系统的加密加密和解密所用的密钥是相同的计算量小因此加密速度快。非对称加密需要两个密钥来进行加密和解密公开密钥和私有密钥算法强度复杂因此加密速度较慢通过公钥对明文加密变成密文私钥对密文解密变成明文当然也可以反着用用公钥加密只有私钥能解密反着来同样的也只有持有私钥的人才能加密。数据摘要数据摘要的基本原理是利用单向散列函数对信息进行运算生成一串固定长度的数字摘要。和加密算法的区别是摘要严格意义不是加密因为没有解密只不过从摘要很难反推原信息通常用来进行数据对比因此可以用来判断数据有没有被篡改。方案一仅使用对称加密对数据进行对称加密可以让中间人不能得到真实数据保证信息安全。但服务器要给很多客户端提供服务这么多客户端每个人用的秘钥都必须是不同的因此服务器就需要维护每个客户端和密钥之间的关联关系比较麻烦。有个办法就是让客户端和服务器在建立连接的时候双方协商确定这次通信的密钥。但是如果直接把密钥明文传输那中间人也就能获得密钥了因此密钥的传输也必须加密传输。那么这就形成死循环了。方案二仅使用非对称加密如果服务器先把公钥以明文方式传输给浏览器之后浏览器向服务器传数据前都先用这个公钥加密好再传因为只有服务器有相应的私钥能解开公钥加密的数据所以从客户端到服务器信道暂时是安全的。但是如果服务器用它的私钥加密数据传给浏览器那么浏览器用公钥可以解密它而这个公钥是一开始通过明文传输给浏览器的若这个公钥被中间人劫持到了那他也能用该公钥解密服务器传来的信息了。方案三双方都使用非对称加密服务端拥有公钥 S 与对应的私钥 S’客户端拥有公钥 C 与对应的私钥 C’客户和服务端交换公钥客户端给服务端发信息前先用 S 对数据加密再发送只能由服务器解密因为只有服务器有私钥 S’服务端给客户端发信息前先用 C 对数据加密再发送只能由客户端解密因为只有客户端有私钥 C’ 这个方案好像可行但是有两个问题非对称加密效率太低依旧有安全问题如何提高效率呢方案四非对称加密 对称加密服务端拥有非对称公钥 S 和私钥 S’客户端发起 https 请求获取服务端公钥 S客户端在本地生成对称密钥 C用公钥 S 加密发送给服务器由于中间人没有服务端私钥即使截获了数据也无法还原出内部的原文服务端通过私钥 S’解密还原出客户端发送的对称密钥 C并且使用这个对称密钥加密给客户端返回的响应数据后续客户端和服务器的通信都只用对称加密即可。这样只在开始阶段协商密钥的时候使用非对称加密后续的传输都使用对称加密效率就提高了。但是这种方案只提高了效率还没有解决安全问题什么安全问题呢如果中间人在最开始握手协商的时候就开始攻击了可能会发生下面的问题服务器拥有非对称加密算法的公钥 S私钥 S’中间人拥有非对称加密算法的公钥 M私钥 M’客户端向服务端发起请求服务端明文传送公钥 S 给客户端中间人劫持数据报文提取公钥 S 并保存然后将被劫持报文中的公钥 S 替换成为自己的公钥 M并将伪造报文发给客户端客户端收到报文提取公钥 M自己形成对称秘钥 X用公钥 M 加密 X形成报文发送给服务器中间人劫持后直接用自己的私钥 M’进行解密得到通信秘钥 X再用曾经保存的服务端公钥 S 加密后将报文推送给服务器服务器拿到报文用自己的私钥 S’解密得到通信秘钥 X双方开始采用 X 进行对称加密通信但是他们不知道的是他们的通信信息中间人也能看到甚至修改。那么这个问题的痛点在哪里呢客户端无法确定收到的含有公钥的数据报文是不是真的由目标服务器发送过来的。CA认证证书服务端在使用 HTTPS 前需要向 CA 机构申领一份数字证书数字证书里含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器浏览器从证书里获取公钥证书就如身份证证明服务端公钥的权威性。当服务端申请 CA 证书的时候CA 机构会对该服务端进行审核并专门为该网站形成数字签名过程如下CA 机构拥有非对称加密的私钥 A 和公钥 A’CA 机构对服务端申请的证书明文数据进行 hash形成数据摘要然后对数据摘要用 CA 私钥 A’加密得到数字签名 S服务端申请的证书明文和数字签名 S 共同组成了数字证书这样一份数字证书就可以颁发给服务端了。方案五非对称加密 对称加密 证书认证客户端和服务端建立连接服务器给客户端返回一个证书证书中有服务端的公钥还有网站的身份信息。客户端系统中已内置了受信任的证书发布机构当客户端获取到这个证书之后会对证书进行校验判定证书是否过期、证书的发布机构是否受信任、证书是否被篡改等等。然后从系统中拿到该证书发布机构的公钥对签名解密得到一个 hash 值(数据摘要)设为 hash1然后计算整个证书的 hash 值设为 hash2对比 hash1 和 hash2 是否相等如果相等则说明证书是没有被篡改过的。| 如果中间人篡改了证书的明文由于他没有 CA 机构的私钥所以无法 hash 之后用私钥加密形成签名那么也就没法办法对篡改后的证书形成匹配的签名。| 如果强行篡改客户端收到该证书后会发现明文和签名解密后的值不一致则客户端就能知道证书已被篡改从而终止向服务器传输信息。| 中间人整个掉包证书因为中间人没有 CA 私钥所以无法制作假的证书除非他向 CA 申请真证书但估计没有会这么干然后用自己申请的证书进行掉包。中间人没有 CA 私钥所以对任何证书都无法进行合法修改包括自己的。| 为什么数据在网络传输的时候一定要加密形成签名?常见的摘要算法 MD5 有以下特点:定长无论多长的字符串计算出来的 MD5 值都是固定长度分散源字符串只要改变一点点最终得到的 MD5 值都会差别很大不可逆通过源字符串生成 MD5 很容易但是通过 MD5 还原成原串理论上不可能。因此我们可以认为如果两个字符串的 MD5 值相同则这两个字符串相同。假设我们的证书只是一个简单的字符串 happy对 happy 计算 hash 值结果为BC4B2A76B9719D91。如果 happy 中有任意的字符被篡改那么计算的 md5 值就会变化很大比如BDBD6F9CF51F2FD8。然后我们可以把这个字符串 happy 和哈希值 BC4B2A76B9719D91 从服务器返回给客户端此时客户端只需要计算 happy 的哈希值判断是不是 BC4B2A76B9719D91 即可。| 如果中间人把 happy 篡改同时也把哈希值重新计算下客户端该如何应对所以被传输的哈希值不能传输明文只能传输密文。所以对证书明文 hash 形成散列摘要然后 CA 使用自己的私钥加密形成签名将 happy 和加密的签名合起来形成CA 证书颁发给服务端即使中间人截获了因为没有 CA 私钥就无法更改或者整体掉包就能安全的证明证书的合法性。最后客户端通过操作系统里已经存好的证书发布机构的公钥进行解密还原出原始的哈希值再进行校验。HTTPS完整流程HTTPS 工作过程中涉及到的密钥有以下三组。第一组非对称加密用于校验证书是否被篡改。服务器持有私钥私钥在形成 CSR 文件与申请证书时获得客户端持有公钥操作系统包含了可信任的 CA 认证机构服务器在客户端请求时返回携带签名的证书客户端通过公钥进行证书验证保证证书的合法性进一步保证证书中携带的服务端公钥权威性第二组非对称加密用于协商生成对称加密的密钥。客户端用收到的 CA 证书中的服务端公钥给随机生成的对称加密的密钥加密传输给服务器服务器通过私钥解密获取到对称加密密钥第三组对称加密客户端和服务器后续传输的数据都通过这个对称密钥加密解密。一切的关键都是围绕这个对称加密的密钥其他的机制都是辅助这个密钥工作的。第二组非对称加密的密钥是为了让客户端把这个对称密钥传给服务器第一组非对称加密的密钥是为了让客户端拿到第二组非对称加密的公钥。本篇文章的分享就到这里了如果您觉得在本文有所收获还请留下您的三连支持哦~