HTTPS 资源记录（HTTPS RR）与 HTTP 严格传输安全（STS）均可实现 HTTP 到 HTTPS 的自动升级，但二者在威胁模型与部署权衡上存在本质差异，彼此无法完全替代。
STS 的两种部署路径与局限：
STS 通过 HTTP 响应头或浏览器预置的 HSTS 预加载列表生效。响应头方式要求用户至少完成一次明文访问才能获取策略，首次访问仍暴露于 sslstrip 攻击。预加载列表虽能保护从未访问过的主机，但列表维护不可扩展，且撤销极其困难——一旦主机停止支持 HTTPS，需等待所有主流浏览器发布更新移除条目，期间该主机将在大多数浏览器中不可访问。原文未给出具体预加载列表条目数量或更新周期数据。
HTTPS RR 依赖安全 DNS 的前提：
HTTPS RR 在 DNS 查询阶段即声明域名支持 HTTPS，浏览器可在建立连接前直接发起 HTTPS 请求，理论上消除首次访问的降级窗口。但该机制强制要求 DNS 流量加密（如 DoH、DoT），若 DNS 查询与响应仍为明文，攻击者可篡改 HTTPS RR 响应，伪造域名不支持 HTTPS，导致保护失效。原文未给出具体加密 DNS 部署比例或 HTTPS RR 标准化进度时间表。
威胁模型的细微差异：
STS 的信任锚点在浏览器本地策略或预置列表，防护范围覆盖从首次重定向后的所有连接；HTTPS RR 的信任锚点在加密 DNS 通道，防护范围前移至域名解析阶段。前者在部署后对历史访问者立即生效，后者需配合全链路加密 DNS 才能生效。二者并非互斥关系：STS 可作为 HTTPS RR 部署不完备时的兜底，HTTPS RR 则在支持加密 DNS 的环境中缩短暴露窗口。
运维工程师需根据基础设施成熟度选择：已部署 DoH/DoT 的环境可尝试 HTTPS RR 减少首次访问风险；依赖浏览器预置列表的场景仍需维护 STS 预加载，二者可叠加而非互斥。
原文: APNIC Blog（2020-11-23）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog