Skip to main content

11. Server Implementation and Deployment Advice (服务器实施和部署建议)

本节是非规范性的.

11.1 Non-Conformant User Agent Considerations (非符合标准的用户代理考虑)​

非符合标准的UAs忽略Strict-Transport-Security头字段; 因此, 非符合标准的用户代理不解决第2.3.1节 ("Threats Addressed") 中描述的威胁. 有关进一步讨论, 请参阅第14.2节 ("Non-Conformant User Agent Implications").

11.2 HSTS Policy Expiration Time Considerations (HSTS策略过期时间考虑)​

服务器实现和部署网站需要考虑它们是将到期时间设置为未来的恒定值, 还是设置为固定的时间点.

"未来的恒定值"方法可以通过不断向UAs发送相同的max-age值来实现.

例如, max-age值7776000秒是90天:

Strict-Transport-Security: max-age=7776000

请注意, UA每次接收此头字段都将需要UA更新其必须删除其对此已知HSTS主机的知识的时间概念.

"固定时间点"方法可以通过发送表示到所需到期时间的剩余时间的max-age值来实现. 这将需要HSTS主机在每个HTTP响应中发送新计算的max-age值.

这里的一个考虑是部署者是否希望将发出信号的HSTS策略到期时间与网站域证书的到期时间相匹配.

此外, 服务器实现者应考虑在其部署配置系统中使用默认max-age值为零. 这将需要部署者有意地设置max-age以使UAs为其主机执行HSTS策略, 并将保护它们免于无意中启用具有某个任意非零持续时间的HSTS.

11.3 Using HSTS in Conjunction with Self-Signed Public-Key Certificates (结合自签名公钥证书使用HSTS)​

如果以下四个条件都为真...

  • 网站/组织/企业正在为网站生成自己的安全传输公钥证书, 并且

  • 该组织的根证书颁发机构 (CA) 证书通常不会默认嵌入浏览器和/或操作系统CA证书存储中, 并且

  • HSTS策略在使用由组织CA签名的证书 (即, "自签名证书") 标识自己的主机上启用, 并且

  • 此证书与可用的TLS证书关联不匹配 (如TLSA协议规范 [RFC6698] 第4节所定义),

...那么按照HSTS设计, 到该站点的安全连接将失败. 这是为了防止各种主动攻击, 如上所述.

但是, 如果该组织希望使用自己的CA和自签名证书与HSTS配合使用, 它可以通过将其根CA证书部署到其用户的浏览器或操作系统CA根证书存储中来实现. 它还可以另外或替代地向其用户的浏览器分发特定主机的终端实体证书. 有多种方法可以实现这一点 (详细信息超出本规范的范围). 一旦其根CA证书安装在浏览器中, 它就可以在其站点上使用HSTS策略.

或者, 该组织可以部署TLSA协议; 所有也使用TLSA的浏览器将能够信任通过TLSA表示的可用TLS证书关联标识的证书.

注意 (NOTE): 以交互方式向用户分发根CA证书, 例如通过电子邮件, 并让用户安装它们, 可以说是在训练用户容易受到一种可能的钓鱼攻击形式的影响. 参见第14.8节 ("Bogus Root CA Certificate Phish plus DNS Cache Poisoning Attack"). 因此, 应该小心地以在用户的系统和浏览器上分发和安装此类证书的方式.

11.4 Implications of includeSubDomains (includeSubDomains的含义)​

includeSubDomains指令具有值得仔细考虑的实际含义; 两个示例场景是:

  • HSTS主机在其HSTS主机域名的备用端口或各种子域上提供不安全的基于HTTP的服务.

  • 在HSTS主机的不同子域提供不同的Web应用程序, 这样UAs通常直接与这些子域Web应用程序交互, 而不一定与HSTS主机的域名上提供的Web应用程序 (如果有) 交互.

下面的小节依次讨论这些场景中的每一个.

11.4.1 Considerations for Offering Unsecured HTTP Services at Alternate Ports or Subdomains of an HSTS Host (在HSTS主机的备用端口或子域提供不安全HTTP服务的考虑)​

例如, 证书颁发机构通常通过纯HTTP提供其CRL分发和OCSP服务 [RFC2560], 有时在可能由TLS/SSL保护的公开可用Web应用程序的子域上. 例如, https://ca.example.com/是"示例CA" (一个证书颁发机构) 的公开可用Web应用程序. 客户使用此Web应用程序注册其公钥并获取证书. "示例CA"为客户生成证书, 包含http://crl-and-ocsp.ca.example.com/作为"CRL分发点 (CRL Distribution Points)"和"授权信息访问:OCSP (Authority Information Access:OCSP)"证书字段的值.

如果ca.example.com要发出带有includeSubDomains指令的HSTS策略, 那么实现HSTS的已与ca.example.com Web应用程序交互的基于HTTP的用户代理将无法检索CRLs并无法检查证书的OCSP, 因为这些服务是通过纯HTTP提供的.

在这种情况下, 示例CA可以:

  • 不使用includeSubDomains指令, 或

  • 确保在ca.example.com的子域上提供的基于HTTP的服务也统一通过TLS/SSL提供, 或

  • 在不同的域名上提供基于纯HTTP的服务, 例如, crl-and-ocsp.ca.example.NET, 或

  • 利用分发证书状态信息的替代方法, 避免需要通过纯HTTP提供CRL分发和OCSP服务 (例如, "证书状态请求 (Certificate Status Request)" TLS扩展 [RFC6066], 通常俗称为"OCSP装订 (OCSP Stapling)").

注意 (NOTE): 上述要点明确只是一个示例, 并不旨在解决所有涉及的复杂性. 例如, 在部署诸如"OCSP装订"之类的方法时, CAs、证书部署者和应用程序 (例如, 浏览器) 方面涉及许多考虑因素. 此类问题超出本规范的范围.

11.4.2 Considerations for Offering Web Applications at Subdomains of an HSTS Host (在HSTS主机的子域提供Web应用程序的考虑)​

在这种情况下, HSTS主机声明带有includeSubDomains指令的HSTS策略, 并且在HSTS主机的不同子域上也存在不同的Web应用程序, 这样UAs通常直接与这些子域Web应用程序交互, 而不一定与HSTS主机交互. 在这种情况下, UAs将不会接收或执行HSTS策略.

例如, HSTS主机是"example.com", 并且它被配置为发出带有includeSubDomains指令的STS头字段. 但是, example.com的实际Web应用程序地址是"www.example.com", 并且example.com只是将用户代理重定向到https://www.example.com/.

如果STS头字段仅由"example.com"发出, 但UAs通常会为"www.example.com"添加书签 -- 并且链接 (来自Web上的任何地方) 通常建立到"www.example.com" --, 并且在某些非零百分比的交互中并非所有用户代理都直接联系"example.com", 那么一些UAs将不会将"example.com"标注为HSTS主机, 并且一些"www.example.com"的用户将不受HSTS策略的保护.

为了解决这个问题, 应该配置HSTS主机, 使得STS头字段直接在构成其Web应用程序的众所周知"入口点"的每个HSTS主机域或子域名上发出, 无论是否采用includeSubDomains指令.

因此, 在我们的示例中, 如果STS头字段从"example.com"和"www.example.com"发出, 则将解决此问题. 此外, 如果"example.com"提供的Web应用程序还有其他众所周知的入口点, 例如"foo.example.com", 它们也应该配置为发出STS头字段.

Last updated on