传输层安全协议（TLS）的早期版本已经服役超过二十年，TLS 1.0 最初基于 SSL 3.0 改进而来，随后 TLS 1.1 做了有限修补，但两者仍然共享许多今天看来已经过时的密码学设计。CloudFront 支持通过查看器证书配置来限制客户端与边缘节点之间协商的 TLS 版本，当最低版本设置为 TLS 1.2 或更高时，TLS 1.0 和 TLS 1.1 将被直接拒绝，无法建立 HTTPS 连接。本文将围绕如何在 AWS CloudFront 上完成这一安全加固展开。
需要说明的是，CloudFront 的查看器协议安全策略与源站协议策略是两套独立配置。本文讨论的是客户端到 CloudFront 边缘节点之间的 HTTPS 连接，也就是查看器请求部分。源站与 CloudFront 之间的 TLS 版本由源站策略单独控制，不应混淆。
为什么必须淘汰 TLS 1.0 和 TLS 1.1
TLS 1.0 和 TLS 1.1 在密码学设计上存在明显弱点。TLS 1.0 大量沿用 SSL 3.0 的分组密码使用方式，采用 CBC 模式时没有做好初始化向量的随机化处理，这直接催生了 BEAST 攻击。攻击者可以在浏览器中注入恶意脚本并结合网络嗅探，逐步解密 HTTPS 会话中的 Cookie 等敏感数据。TLS 1.1 虽然对初始化向量做了改进，但同样允许使用 RC4 等已经证明不安全的流密码算法，同时两个版本都支持 SHA-1 作为消息完整性校验算法，而 SHA-1 的抗碰撞能力早已不足以满足现代安全要求。
除了算法层面的缺陷，行业合规要求也在推动淘汰旧版本。PCI DSS 3.1 明确要求支付卡数据环境中不能使用 SSL 3.0 和早期版本的 TLS，后续版本进一步要求禁用 TLS 1.0 和 TLS 1.1。主流浏览器如 Chrome、Firefox、Safari 和 Edge 都在更新中逐步移除了对这两个协议的支持。如果 CloudFront 边缘节点仍然接受这些旧版本，不仅会增大被中间人攻击的风险，还可能因为合规审计不通过而影响业务。
从实际攻击面来看，即使服务端仍然支持 TLS 1.2，只要同时允许 TLS 1.0 或 TLS 1.1，攻击者就可以利用协议降级攻击迫使客户端使用较弱版本，再借助已知漏洞发起攻击。因此，仅仅“支持新版本”是不够的，必须主动移除旧版本的协商能力，才能从根本上切断降级路径。
CloudFront 中的 TLS 安全策略与配置入口
CloudFront 分布中与查看器 HTTPS 相关的配置位于“查看器证书”部分。你可以选择使用默认 CloudFront 证书，也可以关联自定义 SSL 证书。无论使用哪种证书，都可以通过设置最低 TLS 版本或安全策略来限制允许的协议。AWS 提供了多个预定义安全策略，例如 TLSv1.2_2018、TLSv1.2_2019 和 TLSv1.2_2021，这些策略不仅指定了最低 TLS 版本，还控制了可用的密码套件组合。其中 TLSv1.2_2021 是目前最严格的策略，只允许 TLS 1.2 和 TLS 1.3，并且密码套件经过精简，移除了较弱的 CBC 套件。
在 AWS 管理控制台中，进入 CloudFront 分配的“常规”选项卡，点击“编辑”，找到查看器证书区域，可以看到“安全策略”或“最低 TLS 版本”设置。推荐直接选择 TLSv1.2_2021。如果你使用 CLI，需要先获取当前分布配置，修改 ViewerCertificate 对象中的 SecurityPolicy 或 MinimumProtocolVersion 字段，然后调用更新接口。以下是一个 AWS CLI 操作示例：
aws cloudfront get-distribution-config --id E1234567890ABCD --output json > dist-config.json # 编辑 dist-config.json，找到 ViewerCertificate，设置 SecurityPolicy 为 TLSv1.2_2021 aws cloudfront update-distribution --id E1234567890ABCD --distribution-config file://dist-config.json --if-match ETAG
如果采用 CloudFormation 管理基础设施，可以在 AWS::CloudFront::Distribution 资源中的 ViewerCertificate 属性里指定最低协议版本。即使部分区域尚未完全支持 SecurityPolicy 字段，设置 MinimumProtocolVersion 为 TLSv1.2_2021 也能达到禁用 TLS 1.0 和 TLS 1.1 的效果。下面是一个 YAML 片段：
ViewerCertificate: CloudFrontDefaultCertificate: false AcmCertificateArn: arn:aws:acm:us-east-1:123456789012:certificate/abc SslSupportMethod: sni-only MinimumProtocolVersion: TLSv1.2_2021
需要注意的是，更新分布配置后 CloudFront 需要一定时间将新配置部署到所有边缘节点，通常几分钟内生效。部署完成后，旧版 TLS 连接请求会在 TLS 握手阶段被直接拒绝，客户端会收到握手失败或协议版本不支持的错误。
如何使用 openssl 验证配置是否生效
验证 TLS 策略是否已经生效，最直接的方法是使用 openssl s_client 模拟不同版本的 TLS 握手。假设你的 CloudFront 分配域名是 d123.cloudfront.net，执行以下命令可以测试 TLS 1.1 是否仍然被接受：
echo | openssl s_client -connect d123.cloudfront.net:443 -tls1_1 2>/dev/null | grep -E "Protocol|Cipher"
如果输出中没有显示协商成功的协议和密码套件，而是提示握手失败或直接返回非零退出码，说明 TLS 1.1 已经被禁用。同样可以用 -tls1_2 参数测试 TLS 1.2，应该能够正常输出类似 Protocol : TLSv1.2 和对应的密码套件信息。对于已经启用 TLS 1.3 的 CloudFront 安全策略，还可以使用 -tls1_3 验证新版本支持情况。
除了命令行验证，还可以使用 CloudFront 标准日志或实时日志中的 tls-protocol 字段来观察真实流量的协议分布。标准日志会记录每个请求所使用的 TLS 版本，通过 Amazon Athena 或日志分析工具统计 tls-protocol 取值，可以评估当前环境下还有多少客户端在使用旧版本。如果统计结果中已经几乎没有 TLS 1.0 或 TLS 1.1 的请求，就可以更放心地执行禁用操作。
兼容性影响与渐进迁移建议
禁用 TLS 1.0 和 TLS 1.1 并非完全没有代价。部分老旧客户端可能默认不支持 TLS 1.2，例如 Android 4.4 及更早版本的系统浏览器、部分 Windows 7 上的 IE 11 在未安装更新时、以及使用老版本 OpenSSL 的嵌入式设备。这些客户端在策略生效后将无法访问你的 HTTPS 站点。对于面向公众的 Web 应用，需要先通过日志或分析工具确认老客户端的占比，如果仍有一定比例，建议先推动客户端升级，或提供通过 HTTP 重定向到 HTTPS 的过渡方案。
迁移过程可以采用分阶段的方式。首先在测试分布或低流量环境开启 TLS 1.2 最低版本，观察错误率和用户反馈。接着在生产环境启用前，记录当前分布配置和 ETag，以便在出现兼容性事故时快速回滚。回滚只需将 SecurityPolicy 或 MinimumProtocolVersion 改回原来的值并再次更新分布即可，由于 CloudFront 配置是版本化的，操作较为简单。
从长远来看，将最低 TLS 版本固定在 1.2 以上，并优先使用 TLS 1.3，是当前 CDN 安全基线的基本要求。CloudFront 的安全策略在持续演进，后续可以关注 AWS 发布的新策略，及时升级到更严格的配置。通过结合日志监控、自动化测试和基础设施即代码管理，可以把这类安全加固从一次性操作变成可重复、可审计的日常运维动作。
AWS CloudFrontTLS版本HTTPS安全修改时间：2026-08-28 20:47:56