HTTPS背后发生了什么？认识TLS与HTTP安全响应头

1. 理解证书在一次访问中的作用

浏览器通过HTTPS连接网站时，TLS会建立加密通信。浏览器会检查证书是否覆盖所请求的主机名，以及能否构建一条通往受信任证书颁发机构（CA）的证书链。证书中写明了它覆盖的域名、有效期以及构建信任链所需的信息。

把根域名、“www”和各个服务子域名等公开名称整理成清单，逐一检查，并记录每张证书由哪家服务商管理。CDN和源站可能使用各自独立的证书和续期安排。证书的有效期也在缩短：自2026年3月15日起，新签发的公开信任TLS证书最长有效期为200天；2027年3月15日起缩短为100天，2029年3月15日起缩短为47天。请把续期自动化，并另行监控到期时间。例如，Let’s Encrypt已于2025年6月4日停止发送到期提醒邮件。

OWASP TLS安全指南可以帮助团队选择要支持的协议版本，并持续维护配置。记录某次连接实际协商使用的TLS版本，能为这项检查提供具体的观察依据。

2. 看清各层如何相互补充

可以把这些控制看作相互补充的指令：证书支撑连接本身，响应头则说明某个具体响应应当如何处理。不同页面的用途也不同，公开文章、账户页面和有意允许嵌入的组件，各自适合与其作用相符的策略。

3. 根据实际使用的资源制定CSP

内容安全策略（CSP）规定页面可以从哪些来源加载资源，以及允许浏览器执行哪些行为。先盘点脚本、图片、字体、网络连接和框架（iframe）。把完整流程走一遍，这样清单里也会包括只有在用户操作之后才出现的支付、身份验证和客服资源。

使用Report-Only模式观察拟定的策略与实际使用是否吻合：这种模式不会拦截任何内容，只报告违规。Content-Security-Policy-Report-Only必须作为HTTP响应头发送，不能写在HTML的meta标签中。查看浏览器控制台或已配置的报告接收地址，把每条消息对应到相应的资源，再决定需要哪些规则。代表性流程都检查完毕后，再正式启用测试过的策略。借助nonce或哈希值，可以逐个允许特定的脚本。一份有文档记录的资源清单，能让今后新增资源时更容易评估，也说明了每项许可存在的理由。

4. 让浏览器始终使用HTTPS

HSTS告诉浏览器，在指定期限内只通过HTTPS访问某个主机。浏览器从有效的HTTPS响应中获取这项策略，并在之后的访问中执行；通过普通HTTP收到的HSTS响应头会被忽略。对启用了HSTS的主机，浏览器在遇到证书错误时不会给访客“仍然继续”的选项。因此证书一旦过期，曾经访问过网站的用户将完全无法打开它。证书续期和HSTS需要一起规划。先选择一个团队便于观察的较短期限，确认行为正常后再分阶段延长。

includeSubDomains会把策略扩展到所有子域名，因此应结合域名清单和各子域名的HTTPS状况来决定。预加载（preload）会把域名加入浏览器内置的列表，使首次访问也受到保护。不过，接收预加载申请的hstspreload.org目前推荐使用HSTS，但不推荐预加载，理由是Chrome、Safari等浏览器已经会自动把HTTP导航升级为HTTPS。此外，从列表中移除的变更需要数月才能到达用户。如果仍考虑预加载，请把它当作长期决定，并事先规划完整的域名覆盖范围。MDN的HSTS说明介绍了这些选项如何配合使用。

5. 让Cookie和响应头适配用户流程

会话Cookie让服务能够识别一次持续进行的访问。Secure表示浏览器只在HTTPS请求中发送该Cookie（localhost除外），但它并不能对JavaScript隐藏Cookie。HttpOnly禁止页面上的JavaScript（例如通过document.cookie）读取该Cookie，但浏览器仍会在匹配的请求中携带它；因此它能限制通过XSS窃取Cookie，却不能阻止XSS本身。SameSite决定跨站请求是否携带该Cookie。由于各浏览器的默认值不完全相同，建议显式设置，并根据登录流程和从外部网站返回的流程选择取值。使用SameSite=None时，必须同时设置Secure。

其他响应头进一步规定内容的处理方式。X-Content-Type-Options: nosniff会让浏览器拦截MIME类型不正确的脚本和样式表，并且不再猜测其他响应的类型，所以每个资源的Content-Type都必须正确。Referrer-Policy决定请求中的Referer头携带多少URL信息。页面可以被哪些网站嵌入，由CSP的frame-ancestors指令决定；X-Frame-Options: DENY或SAMEORIGIN则作为旧版浏览器的后备方案。两者都只能通过HTTP响应头生效，写在meta标签中无效；此外，frame-ancestors不会继承default-src的设置。选择这些设置时，可以参考OWASP HTTP安全响应头指南。请把每个响应头的用途记录下来，让应用、反向代理和CDN的配置体现同一套一致的策略。

6. 查看访客实际收到的结果

在浏览器开发者工具中打开一次普通的页面请求，沿着重定向一直查看到最终响应。检查实际下发的证书、响应头和Cookie。这样可以把配置与访客的真实体验对应起来，并看清每项设置来自哪个服务。

1. 通过HTTPS访问所有受支持的公开域名。
2. 记录证书信息和最终响应中的策略。
3. 完整走一遍登录、账户找回、嵌入式支付以及从外部网站返回的流程。
4. 查看控制台中的提示，以及所选报告地址收到的消息。

保存一份带日期的配置记录，并注明每一层由谁负责。托管服务或集成发生变化时，用同样的流程确认行为是否符合预期。有计划地发布变更，并保留上一版配置以便回退，能让团队更从容地协调更新。整理出的检查清单，也能帮助今后接手的维护人员快速了解这个网站。

如需立即检查某个网站的响应头，可以使用免费的HTTP 安全响应头检测工具。

7. 把这张保护地图放在手边

把公开域名、证书负责人、浏览器加载的资源和重要的用户流程集中记录在一处。

Sitelemetry的免费网站上线准备评分无需注册，会运行八项被动检查。就本文主题而言，它会与网站建立一次TLS连接，检查证书是否受信任、是否将在30天内到期，以及连接是否使用TLS 1.2或1.3；它还会查看经过重定向后的最终响应中发送了哪些安全响应头，对大多数响应头只检查是否存在。结果显示为一个分数、单独的加固等级，以及最多三条需要优先查看的信号。它不会列出服务器支持的所有TLS版本和加密套件，也不是渗透测试。

网站安全指南介绍了这些保护层与账户、权限和日常维护之间的关系。