ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

HTTPS 协议详解:对称加密、非对称加密、中间人攻击与数字证书

2026/9/27 21:33:53 拓冰建站 浏览量
HTTPS 协议详解:对称加密、非对称加密、中间人攻击与数字证书 HTTPS HTTP SSSL/TLS专门用来加密的应用层协议由于在HTTP中数据都是 “ 明文 ” 传输的就很容易出现网络安全问题为了解决这个问题业界内推出了 HTTPS 协议一. HTTPS 的加密方式在对 HTTPS协议的加密方式进行讲解之前我们要先理解密钥的概念简单来说密钥就是一套加密算法所对应的密码钥匙只有拿到密钥才能够还原被加密的数据1.1 对称加密对称加密就是 加密和解密 用的是同一个密钥在 HTTP 时由于数据是直接明文传输的那么如果数据在传输的过程中经过了一个黑客黑掉的路由器时所传输的数据就会被黑客一览无余也就造成了网络安全问题大概的流程图如下所示但在我们引入了对称加密之后数据就会以密文的形式进行加密那么即使数据在传输的过程当中途径了黑客的路由器黑客也不能直接拿到我们传输的数据大概的流程图如下所示这样看来似乎黑客就拿不到我们传输的数据内容了但是事情真的有这么简单吗我们知道密钥是 客户端和服务器在最初的通信时由其中任意一方生成并通过网络传输给另一方而且有一个最大的问题是该密钥在网络传输时是明文传输的也就是说黑客也是能拿到这个密钥的所以黑客也能够拿着得到的密钥来对加密的数据进行解析从而拿到我们传输的数据那么如何解决 密钥 是明文传输所带来的网络安全问题呢我们就需要对密钥也进行加密那还是用对称加密的方式吗如果是这样的话我们又去生成一个对称密钥 key2 来对 key 进行加密key 确实是可以通过密文传输了但是 key2 也是要通过网络去明文传输的那么难道我们又要生成一个 key3 来对 key2 进行加密当我们仔细想想就可以发现无论这样套多少次都总是有一层是需要明文传输的也就是说仅仅依靠对称加密是不能解决这个问题的为了解决这个问题HTTPS 就引入了非对称加密1.2 非对称加密非对称加密有两个密钥一个公钥公开的密钥一个私钥自己私有的密钥用 公钥/私钥 进行加密的数据只有持有对应的 私钥/公钥 才能对其进行解密。公钥和私钥并不相同所以称作非对称加密非对称加密传输之后用来对通信数据进行加密的密钥的流程图大概如下图所示首先客户端先用服务器公开的公钥对 密钥key 进行加密传输像这样即使在 密钥key 在传输的过程当中经过了黑客的路由器黑客也只能拿到经过公钥加密后的数据而又由于黑客手中并没有该公钥对应的私钥所以并不能对这些加密后的数据进行解密也就拿不到 密钥key。在之后客户端和服务器之间就使用 密钥key 来加密通信黑客由于没有 密钥key 也不能对这些加密数据进行解密也就保障了网络安全我们要注意的是客户端和服务器之间并不能直接通过服务器提供的公钥和私钥进行加密通信因为非对称加密运算速度巨慢而且还有明文长度上限不能加密大文件所以HTTPS 采取了一个折中的方案只使用服务器的 公钥/私钥 非对称加密传输 密钥key之后客户端和服务器之间的数据传输都是用 密钥key 进行对称加密传输在 HTTPS 引入了非对称加密了之后那些狡猾的黑客难道就真的没办法去窃取我们的数据了吗其实不然那些狡猾的黑客又想出了一个办法来在非对称加密后获取到我们传输的 密钥key这个办法就是 中间人攻击二.HTTPS 典型安全隐患中间人攻击中间人攻击就是 黑客在客户端和服务器的网络通信之间安插了一个第三者偷偷地去截留、篡改双方传输的数据但客户端和服务器双方都意识不到中间有第三者在 非对称加密 的前提下黑客的网络设备也会生成一对 公钥和密钥 对服务器提供的公钥和私钥进行 调包从而获取到 客户端和服务器之间用来进行网络通信加密的 密钥key大概流程如下图所示由于客户端不能确定传输过来的公钥是真是假所以只能选择相信这份公钥是正确的并用这个公钥对密钥key进行加密传输这时如果这份公钥是黑客伪造的 公钥pub2那么在黑客拿到加密的数据后就可以用对应的 私钥pri2 进行解密从而拿到 密钥key。然后黑客再使用服务器的 公钥pub 对 密钥key 进行加密并传输给服务器服务器也使用对应的 私钥pri 对加密的数据进行解密也拿到了密钥key。那么在这之后客户端和服务器之间的通信数据都是以 密钥key 进行加密的而由于黑客手中已经掌握了 密钥key之后客户端和服务器之间的传输数据黑客都能解密偷看、篡改而客户端和服务器双方完全无感知这也就是中间人攻击为了解决中间人攻击HTTPS 又引入了校验机制 —— 数字证书三.抵御中间人攻击的方式数字证书中间人攻击的关键在于客户端无法区分收到的公钥是否是服务器真实传输过来的公钥还是被黑客篡改过的公钥想要解决中间人攻击的问题HTTPS 就要想办法去对公钥进行校验去判断这是否是服务器真实传输过来的公钥而这个校验机制就是数字证书数字证书就相当于网站的官方身份证由公认权威机构CA颁发这时服务器就要先向 公证权威机构CA去申请一个数字证书证书内包含有以下内容证书的颁布机构、证书的有效期、服务器的公钥、服务器的拥有者域名和 证书的数字签名本质上是一个被加密的校验和校验和就是用要校验的数据代入一个校验和的计算算法所算出的一个数字用来快速验证数据在传输的过程当中是否被修改或出错这时当客户端向服务器发起通信时就会先获取到服务器传输过来的证书并对该证书进行校验校验无误之后才使用证书里带有的 公钥 对 密钥key 进行加密并传输给服务器之后客户端和服务器之间的网络通信就都用 密钥key 进行加密传输证书的流程如下图所示客户端对证书的校验过程1.客户端针对证书中的其他字段除了数字签名使用 公证权威机构 同样的算法计算校验和得到校验和12.客户端再通过公正权威机构的 公钥pub 对数字签名进行解密得到校验和2公正权威机构的公钥不是通过网络进行传输的而是操作系统中内置的黑客并不能伪造这份公钥3.客户端对比 校验和1 和 校验和2 是否相同如果相同就说明证书是没有被修改过的也就说明整数中含有的服务器的公钥是正确的如果不相同那么这个证书就是中间被其他人篡改过的属于无效证书引入了证书之后黑客就对我们加密的 密钥key 无能为力了如果黑客想要直接修改证书中的公钥 为自己的公钥就会导致客户端计算出来的 校验和1 和 解密出来的 校验和2 对不上此时客户端就会直接报错就算黑客想要直接替换整份服务器的证书为自己申请的证书那也是不行的因为证书当中包含有服务器的域名黑客申请下来的证书中的域名和服务器的域名肯定是不同的客户端这里还会验证 输入的 URL 中的域名 和 得到的证书中的域名是否一致如果不一致那么也同样会认为该证书非法直接报错三. 小结HTTPS 并不是一种全新的协议而是 HTTP 加上 SSL/TLS 加密层后的产物。它的安全机制可以概括为一句话用非对称加密安全地传递对称密钥再用对称密钥加密实际传输的数据。但仅有加密还不够因为中间人攻击可以调包公钥。为了解决这个问题HTTPS 引入了数字证书由权威 CA 机构颁发证书中包含服务器公钥、域名和数字签名。客户端通过校验数字签名和域名就能确认公钥是否真的属于目标服务器从而抵御中间人攻击。至此HTTPS 通过“对称加密 非对称加密 数字证书”三件套实现了数据传输的机密性、完整性和身份认证。在下一篇博客我们将进入传输层看看 TCP 和 UDP 是如何工作的