我们在上一篇博客中讲解了 HTTP 协议的工作原理但 HTTP 有一个致命的缺陷传输的数据都是明文在网络中裸奔安全风险极高。正如我们在网络基础中提到的在局域网环境下通过 ARP 欺骗等手段可以抓取到同网段内其他设备的传输数据也就是常说的 “抓包”。一旦 HTTP 传输的数据被截获账号密码、个人信息等所有内容都会直接暴露。在注重隐私安全的今天明文传输显然不可接受因此我们日常上网使用的应用层协议早已不是 HTTP而是 HTTPS。简单来说HTTPS 就是 “安全的 HTTP”它在 HTTP 和 TCP 传输层之间增加了一层 SSL/TLS 安全协议负责对 HTTP 传输的数据进行加密、身份认证和完整性校验核心目标是让数据以密文形式在网络中传输即使被截获也无法被解读或篡改。HTTPS 的安全体系建立在两种加密算法之上对称加密与非对称加密。下面我们先分别理解两者的特点再一步步推导 HTTPS 的完整安全方案。一、两种基础加密体制1. 对称加密对称加密的核心是加密和解密使用同一个密钥yue不是yao。它的特点是算法简单、加密解密速度极快、效率高适合对大量数据进行加密。举一个最简单的例子我们用异或运算模拟对称加密过程。int plain 10; // 要传输的明文数据 int key 20; // 对称密钥 // 加密明文与密钥异或得到密文 int cipher plain ^ key; // 解密密文与同一个密钥异或还原明文 int result cipher ^ key; // result 10与原明文一致在这个过程中密钥 key 同时参与加密和解密这就是 “对称” 的含义。常见的对称加密算法有 AES、DES、3DES 等。2. 非对称加密非对称加密需要一对密钥公钥公开密钥和私钥私有密钥。公钥可以公开给任何人私钥必须由持有者严格保密。它的核心规则是用公钥加密的数据只能用对应的私钥解密用私钥加密的数据只能用对应的公钥解密。非对称加密的特点是算法复杂、计算量大、加密解密速度慢但安全性远高于对称加密。这里要特别注意两种用法的区别公钥加密、私钥解密用于保密传输。比如你用某人的公钥加密信息只有持有对应私钥的本人才能解密确保信息只有目标接收方能看到。私钥加密、公钥解密不用于保密传输因为公钥人人都有谁都能解密而是用于数字签名证明信息的发布者是私钥持有者同时防止信息被篡改。常见的非对称加密算法有 RSA、ECC 等。二、为什么单一加密方案都不安全接下来我们基于 “存在中间人” 的前提进行讨论 —— 中间人可以拦截、篡改、伪造通信双方的数据包这是网络安全的默认威胁模型。1. 只用对称加密密钥分发就是死穴既然对称加密效率高那为什么不直接全用对称加密核心问题在于密钥怎么安全地交给对方。通信之初客户端没有服务器的密钥必须先向服务器请求密钥。这个过程中如果存在中间人客户端向服务器发送 “请求密钥” 的数据包被中间人拦截中间人冒充客户端也向服务器发送密钥请求服务器生成对称密钥返回给 “客户端”实际是中间人中间人拿到密钥后既可以原封不动转发给客户端也可以替换成自己生成的假密钥。无论哪种情况中间人都会持有合法的对称密钥。后续客户端和服务器的所有加密通信中间人都能解密读取也能篡改内容后重新加密发送。结论仅用对称加密无法解决安全问题因为密钥本身无法安全分发。2. 只用非对称加密逃不过中间人替换公钥有人会想非对称加密的公钥可以公开私钥自己保管是不是就能解决密钥分发问题我们先看单向通信的情况服务器把自己的公钥 S 公开客户端用公钥 S 加密数据发送给服务器只有服务器持有私钥 S可以解密数据。此时中间人截获密文没有私钥也解不开客户端→服务器方向的传输是安全的。但反过来服务器要给客户端回数据怎么办如果服务器用自己的私钥 S 加密响应那所有人都能用公钥 S 解密完全没有保密性如果要实现双向保密客户端也需要生成自己的公私钥对公钥 K、私钥 K服务器用客户端的公钥 K 加密响应数据。看起来双向都安全了但中间人攻击依然存在客户端向服务器请求公钥请求被中间人拦截中间人自己生成一对公私钥公钥 Z、私钥 Z把自己的公钥 Z 发给客户端冒充是服务器的公钥同时中间人冒充客户端向服务器请求公钥拿到服务器的真实公钥 S后续通信中客户端用公钥 Z 加密数据 → 中间人用私钥 Z 解密看到明文→ 篡改后用公钥 S 加密发给服务器服务器用公钥 Z 加密响应 → 中间人用私钥 Z 解密 → 篡改后用公钥 K 加密发给客户端。在客户端看来自己拿着 “服务器的公钥” 加密在服务器看来自己拿着 “客户端的公钥” 加密。但双方的公钥都已经被中间人替换所有通信对中间人都是透明的且可以被随意篡改。结论仅用非对称加密也无法解决安全问题核心漏洞是客户端无法确认自己拿到的公钥真的属于目标服务器而不是中间人。除此之外非对称加密计算效率极低如果全程用非对称加密传输所有数据通信速度会变得无法接受。三、混合加密解决了效率没解决安全既然对称加密效率高、非对称加密能解决密钥分发的 “最初一公里”那把两者结合起来不就行了这就是混合加密的思路客户端先拿到服务器的公钥 S客户端随机生成一个对称密钥 K用服务器的公钥 S 加密这个对称密钥发送给服务器服务器用私钥 S 解密拿到对称密钥 K后续所有通信都用对称密钥 K 进行加解密。这样一来只需要一次非对称加密传输对称密钥后续全部用高效的对称加密效率问题完美解决。但安全问题依然存在 —— 和纯非对称加密的漏洞一样中间人可以替换服务器的公钥。中间人把自己的公钥发给客户端客户端用假公钥加密对称密钥中间人解密拿到对称密钥再用服务器的真实公钥加密后转发给服务器。后续的对称加密通信中间人依然可以全程解密和篡改。所以混合加密只是解决了效率问题核心的身份认证问题依然没有解决客户端无法确认公钥的归属。四、从完整性到身份认证摘要与签名要解决 “公钥是谁的” 这个问题我们需要先引入两个重要概念数据摘要和数字签名。1. 数据摘要防篡改的指纹数据摘要也叫数据指纹是通过单向散列函数哈希函数对原始数据进行运算生成的一段固定长度的字符串。它有两个核心特点单向不可逆只能从原文算出摘要无法从摘要反推出原文输入敏感哪怕原文只修改一个字符最终生成的摘要都会发生巨大变化且不同原文生成相同摘要的概率极低哈希碰撞。常见的哈希算法有 MD5、SHA-1、SHA-256 等。摘要本身不是加密而是用来校验数据完整性的接收方收到数据和摘要后对数据重新做哈希运算和收到的摘要对比就能知道数据在传输中有没有被篡改。但只传原文 摘要依然不安全中间人可以篡改原文同时重新计算对应摘要接收方无法识别。2. 数字签名用私钥给摘要 “盖章”怎么防止中间人篡改摘要答案是用非对称加密给摘要做 “签名”。数字签名的生成过程发送方对原始数据做哈希运算得到数据摘要发送方用自己的私钥加密这个摘要得到的密文就是数字签名发送方把「原始数据 数字签名」一起发给接收方。验证过程接收方用发送方的公钥解密数字签名得到原始摘要接收方对收到的原始数据重新做哈希运算得到新摘要对比两个摘要如果一致说明数据没有被篡改且发送者确实是私钥持有者因为只有私钥能生成合法签名。这里的核心逻辑是签名只能由私钥持有者生成公钥只能验证签名无法伪造签名。这样就同时解决了「数据完整性」和「发送方身份认证」两个问题。但回到我们的问题就算服务器用私钥给公钥做签名客户端还是不知道这个公钥对应的私钥持有者是不是真的服务器 —— 中间人也可以给自己的假公钥做签名。问题的本质变成了谁来为公钥的归属做背书这就需要引入第三方权威机构CA。五、终极方案CA 数字证书体系1. 什么是数字证书CACertificate Authority数字证书认证机构是全球公认的权威第三方机构负责给合法的服务器颁发数字证书。操作系统和浏览器会内置所有受信任 CA 的根公钥。服务器申请证书的大致流程服务器生成自己的公私钥对把公钥、域名、主体信息等提交给 CA 机构CA 机构审核服务器身份确认域名归属、主体合法CA 机构用自己的根私钥对服务器提交的信息做哈希 签名生成数字证书。一份数字证书主要包含两部分明文信息签发机构、有效期、域名、申请者信息、服务器公钥等数字签名CA 对上述明文信息做哈希再用 CA 根私钥加密得到的签名。2. HTTPS 的完整安全流程有了证书之后HTTPS 的密钥交换与通信流程就完整了客户端发起 HTTPS 请求服务器返回自己的数字证书客户端读取证书中的签发机构从本地系统 / 浏览器内置的信任库中找到对应的 CA 根公钥客户端用 CA 根公钥解密证书中的签名得到明文信息的摘要客户端对证书中的明文信息重新做哈希对比解密得到的摘要一致说明证书没有被篡改确实是该 CA 签发的不一致证书无效浏览器直接告警。客户端额外校验证书中的域名确认和当前访问的域名一致同时校验有效期确认证书未过期。验证通过后客户端从证书中取出服务器的真实公钥客户端生成随机对称密钥用服务器公钥加密后发送给服务器服务器用私钥解密拿到对称密钥后续所有 HTTP 数据都通过该对称密钥加密传输。3. 为什么中间人无法伪造证书有人会问中间人能不能也申请一张证书替换掉服务器的证书 答案是无法实现有效攻击原因有二域名校验不通过证书中绑定了明确的域名。中间人就算申请到了合法证书证书上的域名也和用户访问的域名不一致客户端校验域名时会直接失败中断通信并告警。合法证书需要身份审核CA 机构颁发证书前会严格审核域名所有权和主体资质中间人无法在不暴露身份的情况下申请到目标域名的合法证书。而伪造的证书没有 CA 根私钥的签名客户端用内置的 CA 公钥一验就会失效。六、补充几个常见疑问1. 为什么不直接加密明文而要加密摘要做签名数字签名的核心目标是身份认证和防篡改因为私钥只有CA机构持有而非保密。明文信息比如证书中的服务器公钥、域名本身不需要保密需要的是 “确保内容没被改、确实是 CA 发的”。如果直接加密明文不仅会增加计算开销也偏离了目标签名只需要保证不可伪造不需要保证内容不可读。用摘要 私钥签名的方式既实现了身份认证和完整性校验又因为摘要长度很短大幅降低了非对称加密的计算量。七、总结HTTPS 的安全体系并不是单一技术实现的而是多层机制的组合对称加密负责后续通信的高效加解密保障数据机密性非对称加密负责安全交换对称密钥同时支撑数字签名机制数字摘要负责校验数据完整性识别篡改CA 数字证书负责身份认证解决公钥的信任问题从根源上防御中间人攻击。四者结合才构建了我们今天使用的 HTTPS 安全通信体系在效率和安全之间找到了平衡。