★ FEATURED ARTICLE 一、开场面试官到底在问什么很多同学在面试时喜欢把“中间人攻击”挂在嘴边可一旦被追问“那 HTTPS 具体是怎么防住中间人的”就容易卡壳。面试官这句话不是故意刁难而是在提醒一个关键事实如果你不知道 HTTPS 的握手、证书校验、密钥交换和信任链那么你口中的“中间人攻击”只是一个名词不是一个理解。这篇文章会从 HTTP 的明文风险出发逐步拆解对称加密、非对称加密、数字摘要、数字签名、数字证书、CA 信任链、TLS 握手以及中间人攻击的真实边界。读完以后你不仅能在面试中把原理讲清楚还能理解为什么“我用了 HTTPS 就绝对安全”这句话本身也是错误的。二、先理解问题起点HTTP 为什么是裸奔的HTTP 是一个明文协议。浏览器发送的请求、服务器返回的响应在网络上都是以可直接阅读的文本形式传输的。比如你登录一个网站时如果使用 HTTP那么用户名和密码就可能出现在数据包中。这意味着任何位于通信路径上的设备都有可能看到甚至修改内容。这里的“路径上的设备”包括路由器、交换机、运营商设备、公共 WiFi 的接入点以及攻击者自己建立的恶意热点。HTTP 明文带来的主要风险有窃听攻击者可以读取传输内容包括账号、密码、Cookie、手机号等敏感信息。篡改攻击者可以修改服务器返回的页面比如把下载地址替换成木马程序。伪装攻击者可以冒充目标网站与用户建立连接诱导用户提交隐私。HTTPS 要解决的核心问题就是这三件事加密、完整性检验、身份认证。这三件事分别由不同的密码学机制完成很多人把它们混在一起所以才会讲不清。三、HTTPS 不只是“加了一层密”HTTPS 的准确表述是HTTP over TLS也就是在 HTTP 和 TCP 之间加入 TLS 层。TLS 的前身是 SSL现在常见的版本是 TLS 1.2 和 TLS 1.3。HTTPS 并没有改变 HTTP 的请求方法、状态码、Header 和 Body只是把 HTTP 报文放进加密通道里传输。因此理解 HTTPS 的本质就是理解 TLS。TLS 要完成四件事身份认证客户端确认自己连接的就是目标服务器而不是冒牌货。密钥协商双方在不安全的信道上安全地协商出一把只有双方知道的会话密钥。数据加密使用会话密钥对应用数据做对称加密。完整性校验防止传输内容被修改。很多人的误区是认为“HTTPS 就是用公钥加密数据”。这是错误的。真实过程中公钥加密只在握手阶段发挥作用真正传输网页内容时用的是对称加密因为对称加密速度更快。四、密码学基础之一对称加密为什么快对称加密顾名思义就是加密和解密使用同一把密钥。发送方用密钥把明文变成密文接收方用同一把密钥把密文恢复成明文。对称加密的特点是速度快、效率高适合大量数据加密。常见的算法有 AES、ChaCha20。它们的密钥长度、分组模式和认证方式会影响安全性但基本逻辑始终一样谁拥有密钥谁就能解密。对称加密最大的难题不是算法本身而是密钥分发。两个陌生人在互联网上通信怎么安全地把同一把密钥交给对方如果直接明文传输密钥攻击者也能拿到加密就失去意义。这个难题需要非对称加密来辅助解决。五、密码学基础之二非对称加密为什么安全非对称加密使用一对数学上相关但无法相互推出的密钥公钥和私钥。公钥可以公开给任何人私钥只能由持有者保管。用公钥加密的数据只有对应的私钥才能解密。用私钥加密的数据只有对应的公钥才能解密这通常用于数字签名场景。常见算法有 RSA 和 ECC。非对称加密的安全性建立在数学难题上比如大整数分解问题、椭圆曲线离散对数问题。优点是解决了密钥分发问题缺点是计算速度慢不适合加密大量数据。因此 TLS 采用混合加密先用非对称加密安全地协商对称密钥再用对称密钥加密应用数据。这也解释了为什么抓包时我们很难直接看到网页内容。六、哈希、摘要与数字签名哈希函数把任意长度的输入映射为固定长度的输出称为摘要。它有这些特性单向性从摘要几乎无法还原原文。抗碰撞很难找到两个不同输入拥有相同摘要。微小变化引起巨大差异原文改一个字节摘要会完全不同。哈希本身不是加密它无法还原数据但它可以用于验证数据是否被修改。比如服务器发送文件的同时给出 SHA-256 摘要用户计算本地文件摘要并比较就能判断文件是否完整。数字签名就是把“哈希”和“非对称加密”结合。签名的一方先对内容做哈希再用自己的私钥对摘要加密生成签名。验证方用公钥解密签名得到原始摘要再对收到的内容重新计算摘要并比较。如果一致说明内容未被篡改且确实来自持有私钥的一方。七、数字证书网络世界的身份证非对称加密有一个致命问题客户端怎么知道收到的公钥真的属于目标服务器攻击者可以把自己生成的公钥发给客户端并谎称这是服务器的公钥。如果客户端不验证就会用攻击者的公钥加密数据攻击者再用自己的私钥解密。为了解决“公钥归属”问题数字证书出现了。证书本质上是一份由可信第三方签署的声明主要内容包括网站的域名。网站的公钥。证书颁发机构 CA 的信息。证书有效期。CA 对上述内容的数字签名。浏览器拿到证书后会检查域名是否匹配、证书是否过期、是否被吊销并验证 CA 的签名是否合法。只有全部通过浏览器才信任这份证书。八、CA 与信任链信任是如何传递的CA即证书颁发机构负责验证网站身份并签发证书。浏览器不会信任世界上所有证书它只信任预先内置在操作系统或浏览器中的根证书。现实中的证书通常是三级链根证书由根 CA 自签名通常离线保存浏览器内置信任。中间证书由根 CA 签发用于实际签发终端证书。终端证书由中间 CA 签发给具体网站。浏览器验证时会沿着证书链逐级向上验证签名直到找到一个受信任的根证书。这条链就叫“信任链”。如果攻击者伪造了一张证书但没有得到任何受信任 CA 的签名浏览器就会提示证书错误。信任链的核心逻辑是如果你信任根 CA那么你就信任它签发的中间 CA如果你信任中间 CA那么你就信任它签发的终端证书。这种链条一旦某处被打断信任就不成立。九、TLS 1.2 完整握手过程详解TLS 握手的目标是确认身份、协商参数、生成会话密钥。以 TLS 1.2 中的 ECDHE 密钥交换为例完整流程大致如下。1. ClientHello客户端向服务器发送支持的 TLS 版本、密码套件列表、随机数和其他扩展信息。2. ServerHello服务器从客户端列表中选择双方都支持的 TLS 版本和密码套件并发送自己的随机数。3. Certificate服务器发送自己的证书链证明自己的身份。4. ServerKeyExchange服务器发送与密钥交换有关的临时公钥并用证书对应的私钥对关键参数签名防止临时公钥被篡改。5. ClientKeyExchange客户端也生成自己的临时公私钥并把临时公钥发送给服务器。6. 双方各自计算会话密钥客户端和服务器利用双方随机数、临时私钥和临时公钥通过密钥派生函数计算出相同的会话密钥。这个过程没有把会话密钥直接放在网络上传输。7. ChangeCipherSpec 和 Finished双方通知对方后续消息开始加密并发送校验消息确认握手数据没有被篡改。握手完成后双方使用协商出的对称密钥加密后续的 HTTP 数据。这里需要特别强调真正被公钥保护的并不是网页内容而是密钥交换参数。如果把“证书里的公钥加密了网页”当成答案面试官马上就会知道你没搞懂。十、为什么 ECDHE 比 RSA 密钥交换更值得讲密钥交换有两种经典思路维度RSA 密钥交换ECDHE 密钥交换会话密钥如何产生客户端生成预主密钥用服务器公钥加密后发送双方各生成临时密钥对通过算法协商出相同结果服务器私钥作用解密预主密钥仅为临时公钥签名不参与最终密钥计算前向保密不支持支持TLS 1.3已移除保留并简化前向保密指的是即使服务器证书的私钥将来泄露攻击者也无法解密历史流量。因为 ECDHE 每次握手都会使用一次性临时密钥服务器私钥不参与最终会话密钥的生成。而 RSA 密钥交换中攻击者一旦拿到服务器私钥就能解密历史会话。所以现在的生产环境通常推荐 ECDHE面试时如果能把前向保密说清楚会明显加分。十一、TLS 1.3 做了哪些关键简化TLS 1.3 在安全性和性能上都做了优化握手更快从两次往返减少到一次往返甚至在恢复会话时可以实现零往返。密钥交换固定为前向安全算法移除了静态 RSA 密钥交换等不安全机制。密码套件简化将密钥交换、加密、认证算法合并表达减少配置错误。部分握手消息提前加密即使握手尚未完成证书等敏感信息也受到更好保护。面试时可以说TLS 1.3 通过减少往返、移除不安全算法、引入前向保密和提前加密显著提升了握手效率和隐私性。但无论版本怎么变HTTPS 的基本目标仍然是身份认证、密钥协商、加密和完整性校验。十二、中间人攻击到底怎么发生中间人攻击Man-in-the-Middle简称 MITM是指攻击者悄悄插入客户端和服务器之间成为双方通信的中转站。客户端以为自己在和目标服务器通信服务器以为自己在和目标客户端通信实际上数据都要经过攻击者。攻击者的目标是读取加密前的明文。修改请求和响应。伪装成目标服务器。在 HTTPS 场景中单纯监听握手过程并不能直接解密数据因为会话密钥没有被传输攻击者无法从密文中直接推出对称密钥。于是攻击者通常采用伪造证书、DNS 劫持、ARP 欺骗等方式想办法让客户端误以为自己就是服务器。场景一伪造证书但客户端不做严格校验攻击者建立恶意 WiFi拦截客户端发往目标网站的请求并把自己的证书返回给客户端。如果客户端没有校验证书链就会接受攻击者的公钥。于是客户端与攻击者建立加密连接攻击者再以真实客户端身份与目标服务器建立另一条加密连接。两条连接中间攻击者可以看到明文。场景二诱导用户安装攻击者控制的根证书有些抓包工具、企业安全软件或恶意应用会要求用户安装自己的根证书。一旦安装浏览器就会信任由该根证书签发的任何证书攻击者就可以对 HTTPS 流量进行解密。场景三DNS 劫持配合钓鱼证书攻击者把域名解析到自己的服务器并准备一张看起来属于该域名的证书。如果证书不是由受信任 CA 签发浏览器通常会报错但如果用户忽略警告继续访问攻击仍然可能成功。这些场景说明一个关键点HTTPS 的安全依赖客户端严格执行证书校验。如果校验被绕过、根证书被污染或者用户主动忽略警告中间人攻击仍然可以成功。十三、浏览器如何识别一个证书不可信浏览器在建立 HTTPS 连接时会对证书做多项检查域名匹配证书中的域名必须与访问域名一致。有效期当前时间必须在证书有效期内。签名链从终端证书向上验证到受信任根证书。吊销状态查询证书是否被吊销可通过 CRL 或 OCSP。公钥用途证书必须允许用于服务器身份认证。任何一项失败浏览器都会显示“您的连接不是私密连接”而不是直接在后台自动降级为 HTTP。这个提示本身就是一种保护但很多用户看到提示后仍然选择继续访问这使得安全机制失效。十四、证书校验不是“比一下指纹就好”不少面试者会说“客户端拿到证书后会比对证书的指纹。”这个说法过于简化甚至不准确。证书指纹可以用于人工核对但浏览器并不会把全世界所有证书的指纹都预先保存下来。浏览器真正的判断依据是这条证书链是否最终锚定到一个内置受信任的根 CA并且每一级签名都有效。指纹只是证书内容的哈希如果攻击者可以控制用户信任的根指纹机制也无法阻止伪造。面试时建议这样回答浏览器不会只看某个固定指纹而是逐级验证签名、有效期、域名、吊销状态和密钥用途最终确认证书能回溯到受信任的根证书。十五、中间人攻击与 HTTPS 的三个常见误区误区一“HTTPS 只能防止窃听不能防止中间人攻击。”这句话有严重漏洞。正确理解是HTTPS 无法防住所有形式的中间人攻击比如用户主动安装恶意根证书但它在正常情况下确实能通过证书校验阻止未授权的中间人。准确说法是HTTPS 能否防住中间人取决于证书校验是否严格执行。误区二“我用 HTTPS所以密码在网络上肯定是安全的。”如果客户端信任了攻击者提供的证书加密对于攻击者就是透明的。浏览器与攻击者的连接是加密的攻击者与服务器的连接也是加密的但攻击者在中间能看到明文。误区三“中间人攻击就是破解了 HTTPS 的加密算法。”大多数真实攻击根本没有破解 AES 或 RSA而是利用证书校验缺失、用户误操作、系统被植入根证书等弱点。攻击者绕过了信任机制而不是从数学上破解了密码算法。十六、不只是钓鱼中间人攻击还能做哪些坏事如果攻击者成功建立中间人连接危害远不止看到账号密码篡改网页内容插入恶意脚本记录用户键盘输入。修改 API 响应例如把转账金额、收款账号悄悄替换。把用户重定向到钓鱼页面收集手机验证码。替换下载文件将正常软件换成木马。剥离 HTTPS 请求诱导客户端降级到 HTTP。这些攻击说明 HTTPS 保护的是传输过程而不是传输完之后发生的事情。如果服务器被攻破、客户端被植入恶意软件或者应用本身有逻辑漏洞再强的传输加密也无法解决问题。十七、中间人攻击如何防御从用户到网站对于普通用户不要随意连接来源不明的公共 WiFi。不要轻易安装不明来源的根证书更不要为了让抓包工具工作而长期信任来路不明的 CA。看到浏览器安全提示时不要习惯性点击“继续前往”尤其不要在警告页面输入账号密码。访问网银、邮箱等敏感网站时使用官方域名并确认地址栏出现正确的 HTTPS 标识。对于开发者或网站运营者全站启用 HTTPS把所有 HTTP 请求 301 跳转到 HTTPS避免用户继续停留在明文连接。配置 HSTS告诉浏览器以后只能通过 HTTPS 访问减少降级攻击和第一次访问时的劫持风险。保证证书链完整部署终端证书的同时下发中间证书避免客户端在校验链条时失败。及时续期和管理证书监控证书有效期和吊销状态避免因过期或误配置触发安全警告。只启用现代 TLS 协议和密码套件关闭 SSLv3、TLS 1.0、TLS 1.1 以及静态 RSA 交换等不安全配置。严格保护私钥私钥一旦泄露攻击者就可以签发或使用伪造证书进行中间人攻击。总的来说HTTPS 能防住大部分基于网络路径的中间人攻击但前提是证书校验没有被绕过。真正的通信安全需要用户提高警惕、网站正确配置、根证书体系可靠三方面共同配合。面试中能把“信任链校验为什么重要”讲清楚再加上具体防御措施就能把这道题从名词解释提升到完整闭环。
阅读完成 · 觉得有帮助？
