CDN双向TLS认证实战：mTLS配置与源站安全加固
去年一个客户，源站IP被攻击者扫到了。CDN层配了WAF、防盗链、IP黑白名单，但攻击者绕过了CDN，直接对源站IP发起请求。源站没有任何防护，瞬间被打满。
安全负责人说：“CDN配了这么多东西，源站还是被打穿了。”
这是CDN安全架构里最容易被忽视的漏洞：CDN把攻击挡在了外面，但如果源站IP暴露了，攻击者可以直接绕过CDN。而mTLS双向认证，正是解决这个问题的方案。
01 为什么CDN前置防护不够？
标准CDN架构中，用户请求经过CDN节点，CDN再回源到源站。CDN层可以配置WAF、防盗链、IP黑白名单等防护策略，但这些防护只作用于经过CDN的流量。
核心问题：源站本身仍然暴露在公网上。攻击者可以通过DNS历史记录、证书透明度日志、全网端口扫描等方式发现源站IP，然后直接对源站发起攻击。
一种常见的直觉方案是在源站前再部署一层WAF，但存在根本性缺陷：源站同时接收两类请求——经CDN转发的请求（真实客户端IP通过X-Forwarded-For头传递）和来自互联网的直连请求（TCP源IP即为真实客户端IP，可能伪造头部）。两类请求混杂在一起，导致WAF的速率限制、地理封锁、anti-DDoS等规则误报和漏报概率显著增大。
正确的思路是：确保只有CDN的流量能到达源站，从传输层彻底阻断非法直连。
02 mTLS如何保护源站？
mTLS（双向TLS认证）在标准TLS握手的基础上，要求客户端和服务器互相验证对方身份。
回源mTLS的核心机制：
标准回源HTTPS中，仅CDN节点验证源站证书（单向认证）。开启回源mTLS后，源站也会验证CDN节点出示的客户端证书。验证流程如下：
效果：源站只接受携带有效客户端证书的CDN节点请求，任何没有合法证书的直连请求在TLS握手阶段即被拒绝。即使源站IP暴露，攻击者也无法直接连接。
03 配置步骤
以阿里云CDN客户端证书认证为例，以及AWS CloudFront源站mTLS配置参考。
第一步：准备证书
需要准备客户端CA证书（用于签发客户端证书的根证书或中间CA证书）。格式要求：以-----BEGIN CERTIFICATE-----开头，以-----END CERTIFICATE-----结尾。建议使用私有CA并开启自动化轮换，而不是长期静态证书。
第二步：在源站安装CA证书
将客户端CA证书安装在源站服务器上。Nginx配置参考：
text
ssl_client_certificate /path/to/ca.crt; # 客户端CA证书 ssl_verify_client on; # 启用客户端证书验证
第三步：在CDN平台启用mTLS
阿里云CDN：在域名管理的HTTPS配置中，开启“客户端证书认证”并输入客户端CA证书。
AWS CloudFront：通过ACM导入客户端证书，在Distribution源站配置中启用源站mTLS，指定客户端证书ARN。mTLS不收取额外费用，已包含在CloudFront Business与Premium套餐中。
写在最后
那家客户后来启用了回源mTLS，源站只接受来自CDN节点的加密请求。攻击者再次扫描到源站IP后，直接连接被拒绝。
安全负责人说：“以前源站是敞开的，现在多了一道锁。钥匙只在CDN手里。”
mTLS的价值不是替代WAF和防盗链，而是补齐源站防护的最后一块短板——让攻击者即使找到源站IP也进不来。
