Skip to content

Transport Layer Security Cheat Sheet / 传输层安全性速查表

Introduction / 介绍

This cheat sheet provides guidance on implementing transport layer protection for applications using Transport Layer Security (TLS). It primarily focuses on how to use TLS to protect clients connecting to a web application over HTTPS, though much of this guidance is also applicable to other uses of TLS. When correctly implemented, TLS can provide several security benefits:

此速查表提供了使用传输层安全性（TLS）实现应用程序传输层保护指南。它主要关注如何使用TLS保护通过HTTPS连接到Web应用程序的客户端，尽管其中许多指南也适用于TLS的其他用途。当正确实施时，TLS可以提供以下安全优势：

  • Confidentiality: Provides protection against attackers reading the contents of the traffic.
    中文：机密性：提供保护，防止攻击者读取流量内容。
  • Integrity: Provides protection against traffic tampering, such as an attacker modifying or replaying intercepted requests against the server.
    中文：完整性：提供保护，防止流量篡改，例如攻击者修改或重放截获的请求到服务器。
  • Authentication: Enables the client to confirm they are connected to the legitimate server. Note that the identity of the client is not verified unless client certificates are employed.
    中文：身份验证：使客户端能够确认他们已连接到合法的服务器。请注意，除非使用客户端证书，否则不会验证客户端的身份。”

SSL vs TLS / SSL与TLS

Secure Socket Layer (SSL) was the original protocol that was used to provide encryption for HTTP traffic, in the form of HTTPS. There were two publicly released versions of SSL - versions 2 and 3. Both of these have serious cryptographic weaknesses and should no longer be used.

安全套接字层（SSL）是最初用于为HTTP流量提供加密的协议，形式为HTTPS。SSL有两个公开发布的版本 - 第2版和第3版。这两个版本都存在严重的加密弱点，不应再使用。

For various reasons the next version of the protocol (effectively SSL 3.1) was named Transport Layer Security (TLS) version 1.0. Subsequently TLS versions 1.1, 1.2 and 1.3 have been released.

由于各种原因，该协议的下一个版本（实际上是SSL 3.1）被命名为传输层安全性（TLS）1.0。随后发布了TLS 1.1、1.2和1.3版本。

The terms "SSL", "SSL/TLS" and "TLS" are frequently used interchangeably, and in many cases "SSL" is used when referring to the more modern TLS protocol. This cheat sheet will use the term "TLS" except where referring to the legacy protocols.

术语“SSL”、“SSL/TLS”和“TLS”经常被互换使用，在许多情况下，当提到更现代的TLS协议时，使用“SSL”。本速查表将使用“TLS”术语，除非提到旧协议。

Server Configuration / 服务器配置

Only Support Strong Protocols / 仅支持强协议

Web applications must default to TLS 1.3 and may support TLS 1.2 for compatibility. TLS 1.0 and TLS 1.1 are formally deprecated by RFC 8996 (March 2021) and must be disabled. They are also forbidden by PCI DSS, disallowed by NIST SP 800-52 Rev. 2, and removed from all mainstream browsers. SSLv2 and SSLv3 must always be disabled.

Web应用程序必须默认使用TLS 1.3，并可能为兼容性支持TLS 1.2。TLS 1.0和TLS 1.1已被RFC 8996（2021年3月）正式弃用，必须禁用。它们也被PCI DSS禁止，由NIST SP 800-52 Rev. 2不允许，并被所有主流浏览器移除。SSLv2和SSLv3必须始终禁用。

If interoperability with end-of-life clients is a hard business requirement, isolate them on a dedicated endpoint with no access to sensitive data — do not weaken the primary endpoint. The "TLS_FALLBACK_SCSV" extension should be enabled to prevent protocol downgrade attacks.

如果与已停用的客户端的互操作性是硬性业务需求，请在没有访问敏感数据的专用端点上隔离它们——不要削弱主端点。应启用"TLS_FALLBACK_SCSV"扩展以防止协议降级攻击。

Only Support Strong Ciphers / 仅支持强加密套件

There are a large number of different ciphers (or cipher suites) that are supported by TLS, that provide varying levels of security.

TLS支持大量不同的加密套件（或加密套件），提供不同级别的安全性。

For TLS 1.3, use the standard AEAD cipher suites (AES‑GCM or ChaCha20‑Poly1305).

对于TLS 1.3，使用标准的AEAD加密套件（AES-GCM或ChaCha20-Poly1305）。

If TLS 1.2 is still required, prefer AEAD‑based suites there as well and avoid CBC‑mode ciphers. At a minimum, the following types of ciphersuites should always be disabled:

如果仍然需要TLS 1.2，也优先使用基于AEAD的套件，并避免使用CBC模式的加密套件。至少，以下类型的ciphersuites应始终禁用：

  • Null ciphers;
    中文：空密码；
  • Anonymous ciphers (TLS_*_anon_*);
    中文：匿名密码（TLS_*_anon_*）；
  • EXPORT ciphers (TLS_*_EXPORT_*);
    中文：EXPORT 密码（TLS_*_EXPORT_*）；
  • RSA key transport (TLS_RSA_*) and static Diffie-Hellman key agreement (TLS_DH_*, TLS_ECDH_*), which do not provide forward secrecy.

For TLS 1.2, prefer ECDHE cipher suites with authenticated encryption. Ephemeral Diffie-Hellman provides forward secrecy; finite-field DHE suites (TLS_DHE_*) are nevertheless discouraged in TLS 1.2 because of construction and parameter-negotiation weaknesses, as explained in RFC 9325 Section 4.1.

对于 TLS 1.2，优先选择带有认证加密的 ECDHE 密码套件。临时 Diffie-Hellman 提供前向安全性；由于构造和参数协商的弱点，有限域 DHE 套件（TLS_DHE_*）在 TLS 1.2 中仍然不被推荐，如 RFC 9325 第 4.1 节 所解释。

The Mozilla Foundation provides an easy-to-use secure configuration generator for web, database and mail servers. This tool allows site administrators to select the software they are using and receive a configuration file that is optimized to balance security and compatibility for a wide variety of browser versions and server software.

Mozilla 基金会提供了一个易于使用的安全配置生成器，用于网页、数据库和邮件服务器。此工具允许站点管理员选择他们使用的软件，并接收一个针对广泛浏览器版本和服务器软件的安全性与兼容性平衡的配置文件。

Set the appropriate Diffie-Hellman groups / 设置适当的 Diffie-Hellman 组

The practice of earlier than TLS 1.3 protocol versions of Diffie-Hellman parameter generation for use by the ephemeral Diffie-Hellman key exchange (signified by the "DHE" or "EDH" strings in the cipher suite name) had practical issues. For example, the client had no say in the selection of server parameters, meaning it could only unconditionally accept or drop, and the random parameter generation often resulted to denial of service attacks (CVE-2022-40735, CVE-2002-20001).

在 TLS 1.3 之前的协议版本中，Diffie-Hellman 参数生成用于临时 Diffie-Hellman 密钥交换（在密码套件名称中的 "DHE" 或 "EDH" 字符串表示）的做法存在实际问题。例如，客户端在选择服务器参数方面没有发言权，这意味着它只能无条件接受或丢弃，而随机参数生成通常会导致拒绝服务攻击（CVE-2022-40735，CVE-2002-20001）。

The supported_groups extension is used to negotiate which Diffie-Hellman group are supported:

使用 supported_groups 扩展来协商支持哪个 Diffie-Hellman 组：

  • the available Finite Field Diffie-Hellman groups are ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192 as specified in RFC7919;
  • Elliptic Curve Diffie-Hellman groups include x25519, prime256v1, x448, secp384r1;
    中文：椭圆曲线迪菲-赫尔曼组包括 x25519、prime256v1、x448、secp384r1；
  • for post-quantum cryptography, X25519MLKEM768 it currently used (though it is not a group, proper).
    中文：对于后量子密码学，目前使用的是 X25519MLKEM768（尽管它不是一个真正的组）。

For OpenSSL, the list of enabled groups can be configured ins in openssl.cnf. For example

对于 OpenSSL，可以在 openssl.cnf 中配置启用的组列表。例如

openssl_conf = openssl_init
[openssl_init]
ssl_conf = ssl_module
[ssl_module]
system_default = tls_system_default
[tls_system_default]
Groups = X25519MLKEM768:x25519:prime256v1:x448:ffdhe2048:ffdhe3072

An Apache configuration would look like

Apache 的配置可能如下所示

SSLOpenSSLConfCmd Curves X25519MLKEM768:X25519:prime256v1:secp384r1

The same group on NGINX would look like the following

在 NGINX 上相同的配置可能如下所示

ssl_ecdh_curve X25519MLKEM768:X25519:prime256v1:secp384r1;

For TLS 1.2 or earlier versions it is recommended not to set Diffie-Hellman parameters.

对于 TLS 1.2 或更早版本，建议不要设置迪菲-赫尔曼参数。

Disable Compression / 禁用压缩

TLS compression should be disabled in order to protect against a vulnerability (nicknamed CRIME) which could potentially allow sensitive information such as session cookies to be recovered by an attacker.

为了防止一个名为 CRIME 的漏洞（通过压缩率作为 TLS 请求的侧信道进行攻击），建议禁用 TLS 压缩，该漏洞可能允许攻击者恢复敏感信息，如会话cookie。

TLS compression is not available in TLS v1.3 for this reason.

TLS v1.3 由于此原因不支持 TLS 压缩。

Patch Cryptographic Libraries / 修补加密库

As well as the vulnerabilities in the SSL and TLS protocols, there have also been a large number of historic vulnerability in SSL and TLS libraries, with Heartbleed being the most well known. As such, it is important to ensure that these libraries are kept up to date with the latest security patches.

除了 SSL 和 TLS 协议中的漏洞外，SSL 和 TLS 库也存在着大量历史漏洞，其中 Heartbleed 是最为人熟知的。因此，确保这些库保持最新安全补丁更新非常重要。

Test the Server Configuration / 测试服务器配置

Once the server has been hardened, the configuration should be tested. The OWASP Testing Guide chapter on SSL/TLS Testing contains further information on testing.

一旦服务器被加固，应测试其配置。OWASP 测试指南中关于 SSL/TLS 测试的章节](https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_Transport_Layer_Security)提供了更多测试信息。

There are a number of online tools that can be used to quickly validate the configuration of a server, including:

有许多在线工具可以快速验证服务器配置，包括：

Additionally, there are a number of offline tools that can be used:

此外，还有一些离线工具可供使用：

Certificates / 证书

Use Strong Keys and Protect Them / 使用强密钥并保护它们

The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits when using RSA keys. Additional information on key lifetimes and comparable key strengths can be found here and in NIST SP 800-57.

用于生成密钥的私钥必须足够强大，以适应私钥和相应证书的预期使用寿命。当前的最佳实践是在使用RSA密钥时选择至少2048位的密钥大小。有关密钥寿命和可比密钥强度的更多信息，请参阅这里和NIST SP 800-57。

The private key should also be protected from unauthorized access using filesystem permissions and other technical and administrative controls.

私钥还应通过文件系统权限和其他技术和行政控制来防止未经授权的访问。

Use Strong Cryptographic Hashing Algorithms / 使用强加密哈希算法

Certificates should use SHA-256 for the hashing algorithm, rather than the older MD5 and SHA-1 algorithms. These have a number of cryptographic weaknesses, and are not trusted by modern browsers.

证书应使用 SHA-256 作为哈希算法，而不是较旧的 MD5 和 SHA-1 算法。这些算法存在许多加密弱点，并且不被现代浏览器所信任。

Use Correct Domain Names / 使用正确的域名

The domain name (or subject) of the certificate must match the fully qualified name of the server that presents the certificate. Historically this was stored in the commonName (CN) attribute of the certificate. However, modern versions of Chrome ignore the CN attribute, and require that the FQDN is in the subjectAlternativeName (SAN) attribute. For compatibility reasons, certificates should have the primary FQDN in the CN, and the full list of FQDNs in the SAN.

证书的域名（或主题）必须与提供证书的服务器的完全限定名称匹配。历史上，这存储在证书的 commonName（CN）属性中。然而，现代版本的 Chrome 忽略 CN 属性，并要求 FQDN 存在于 subjectAlternativeName（SAN）属性中。出于兼容性原因，证书应在 CN 中包含主要 FQDN，并在 SAN 中包含完整的 FQDN 列表。

Additionally, when creating the certificate, the following should be taken into account:

此外，在创建证书时，还应考虑以下因素：

  • Consider whether the "www" subdomain should also be included.
    中文：考虑是否也应包含 "www" 子域名。
  • Do not include non-qualified hostnames.
    中文：不要包含非限定主机名。
  • Do not include IP addresses.
    中文：不要包含 IP 地址。
  • Do not include internal domain names on externally facing certificates.
    中文：不要在面向外部的证书中包含内部域名。
    • If a server is accessible using both internal and external FQDNs, configure it with multiple certificates.
      中文：如果服务器可以通过内部和外部FQDN访问，请使用多个证书进行配置。

Carefully Consider the use of Wildcard Certificates / 仔细考虑通配符证书的使用

Wildcard certificates can be convenient, however they violate the principle of least privilege, as a single certificate is valid for all subdomains of a domain (such as *.example.org). Where multiple systems are sharing a wildcard certificate, the likelihood that the private key for the certificate is compromised increases, as the key may be present on multiple systems. Additionally, the value of this key is significantly increased, making it a more attractive target for attackers.

通配符证书虽然方便，但违反了最小权限原则，因为单个证书对所有域名的子域名（如*.example.org）都有效。当多个系统共享通配符证书时，证书的私钥可能被泄露的可能性增加，因为密钥可能存在于多个系统上。此外，该密钥的价值显著增加，使其成为攻击者更具吸引力的目标。

The issues around the use of wildcard certificates are complicated, and there are various other discussions of them online.

关于通配符证书使用的问题很复杂，网上有各种其他讨论。

When risk assessing the use of wildcard certificates, the following areas should be considered:

在评估通配符证书使用风险时，应考虑以下方面：

  • Only use wildcard certificates where there is a genuine need, rather than for convenience.
    中文：仅在真正需要时使用通配符证书，而不是为了方便。
    • Consider the use of the ACME to allow systems to automatically request and update their own certificates instead.
  • Never use a wildcard certificates for systems at different trust levels.
    中文：切勿在不同信任级别的系统上使用通配符证书。
    • Two VPN gateways could use a shared wildcard certificate.
      中文：两个VPN网关可以使用一个共享的通配符证书。
    • Multiple instances of a web application could share a certificate.
      中文：多个Web应用的实例可以共享一个证书。
    • A VPN gateway and a public web server should not share a wildcard certificate.
      中文：VPN网关和公共Web服务器不应共享通配符证书。
    • A public web server and an internal server should not share a wildcard certificate.
      中文：公共Web服务器和内部服务器不应共享通配符证书。
  • Consider the use of a reverse proxy server which performs TLS termination, so that the wildcard private key is only present on one system.
    中文：考虑使用一个执行TLS终止的反向代理服务器，这样通配符私钥就只存在于一个系统上。
  • A list of all systems sharing a certificate should be maintained to allow them all to be updated if the certificate expires or is compromised.
    中文：应维护一个共享证书的所有系统的列表，以便在证书过期或被破坏时更新它们。
  • Limit the scope of a wildcard certificate by issuing it for a subdomain (such as *.foo.example.org), or a for a separate domain.
    中文：通过为子域（如*.foo.example.org）或单独的域颁发通配符证书来限制其范围。

Use an Appropriate Certification Authority for the Application's User Base / 为应用的用户基础选择合适的认证机构。

In order to be trusted by users, certificates must be signed by a trusted certificate authority (CA). For Internet facing applications, this should be one of the CAs which are well-known and automatically trusted by operating systems and browsers.

为了获得用户的信任，证书必须由受信任的证书颁发机构（CA）签名。对于面向互联网的应用程序，这应该是操作系统和浏览器自动信任的知名CA之一。

The LetsEncrypt CA provides free domain validated SSL certificates, which are trusted by all major browsers. As such, consider whether there are any benefits to purchasing a certificate from a CA.

Let's Encrypt CA 提供免费的域名验证SSL证书，所有主流浏览器都信任这些证书。因此，考虑是否购买CA的证书有任何好处。

For internal applications, an internal CA can be used. This means that the FQDN of the certificate will not be exposed (either to an external CA, or publicly in certificate transparency lists). However, the certificate will only be trusted by users who have imported and trusted the internal CA certificate that was used to sign them.

对于内部应用程序，可以使用内部CA。这意味着证书的FQDN不会被暴露（无论是给外部CA，还是公开在证书透明度列表中）。然而，只有导入并信任了用于签名的内部CA证书的用户才会信任该证书。

Use CAA Records to Restrict Which CAs can Issue Certificates / 使用CAA记录来限制哪些CA可以颁发证书

Certification Authority Authorization (CAA) DNS records can be used to define which CAs are permitted to issue certificates for a domain. The records contains a list of CAs, and any CA who is not included in that list should refuse to issue a certificate for the domain. This can help to prevent an attacker from obtaining unauthorized certificates for a domain through a less-reputable CA. Where it is applied to all subdomains, it can also be useful from an administrative perspective by limiting which CAs administrators or developers are able to use, and by preventing them from obtaining unauthorized wildcard certificates.

认证机构授权（CAA）DNS记录可以用来定义哪些CA被允许为域名颁发证书。记录包含一个CA列表，任何未包含在该列表中的CA应拒绝为该域名颁发证书。这可以帮助防止攻击者通过信誉较低的CA获取域名的未经授权的证书。如果应用于所有子域名，它还可以从管理角度有用，通过限制管理员或开发者能够使用的CA，并防止他们获取未经授权的通配符证书。

Consider the Certificate’s Validation Type / 考虑证书的验证类型

Certificates come in different types of validation. Validation is the process the Certificate Authority (CA) uses to make sure you are allowed to have the certificate. This is authorization. The CA/Browser Forum is an organization made of CA and browser vendors, as well as others with an interest in web security. They set the rules which CAs must follow based on the validation type. The base validation is called Domain Validated (DV). All publicly issued certificates must be domain validated. This process involves practical proof of control of the name or endpoint requested in the certificate. This usually involves a challenge and response in DNS, to an official email address, or to the endpoint that will get the certificate.

证书有不同的验证类型。验证是证书颁发机构（CA）用来确保您有权拥有证书的过程。这是授权。CA/浏览器论坛是一个由CA和浏览器供应商以及对网络安全感兴趣的其他人组成的组织。CA/Browser Forum。他们根据验证类型设定CA必须遵守的规则。基本验证称为域名验证（DV）。所有公开颁发的证书都必须进行域名验证。这个过程涉及对证书中请求的名称或端点的实际控制证明。这通常涉及DNS中的挑战和响应，到一个官方电子邮件地址，或到将获得证书的端点。

Organization Validated (OV) certificates include the requestor’s organization information in the certificates subject. E.g. C = GB, ST = Manchester, O = Sectigo Limited, CN = sectigo.com. The process to acquire an OV certificate requires official contact with the requesting company via a method that proves to the CA that they are truly talking to the right company.

组织验证（OV）证书在证书的主题中包含请求者的组织信息。例如，C = GB，ST = Manchester，O = Sectigo Limited，CN = sectigo.com。获取OV证书的过程需要通过一种证明CA确实在与正确的公司交谈的方法与请求公司进行官方联系。

Extended validation (EV) certificates provide an even higher level of verification as well as all the DV and OV verifications. This can effectively be viewed as the difference between "This site is really run by Example Company Inc." vs "This domain is really example.org". Latest Extended Validation Guidelines

扩展验证（EV）证书提供了比DV和OV验证更高的验证级别。这可以被视为“此网站确实由Example Company Inc.公司运营”与“此域名确实为example.org”之间的区别。最新扩展验证指南

Historically these displayed differently in the browser, often showing the company name or a green icon or background in the address bar. However, as of 2019 no major browser shows EV status like this as they do not believe that EV certificates provide any additional protection. (Chromium Covering Chrome, Edge, Brave, and Opera. Firefox Safari)

历史上，这些证书在浏览器中的显示方式不同，通常在地址栏中显示公司名称或绿色图标或背景。然而，截至2019年，没有主流浏览器以这种方式显示EV状态，因为它们认为EV证书不会提供任何额外的保护。（Chromium 涵盖Chrome、Edge、Brave和Opera。Firefox Safari)

As all browsers and TLS stacks are unaware of the difference between DV, OV, and EV certificates, they are effectively the same in terms of security. An attacker only needs to reach the level of practical control of the domain to get a rogue certificate. The extra work for an attacker to get an OV or EV certificate in no way increases the scope of an incident. In fact, those actions would likely mean detection. The additional pain in getting OV and EV certificates may create an availability risk and their use should be reviewed with this in mind.

由于所有浏览器和TLS堆栈都未意识到DV、OV和EV证书之间的区别，因此在安全性方面它们实际上是相同的。攻击者只需要达到对域名的实际控制水平，就可以获取一个恶意证书。攻击者获取OV或EV证书的额外工作量并不会增加事件的范围。实际上，这些行为可能会引起检测。获取OV和EV证书的额外困难可能会造成可用性风险，因此在使用时应考虑这一点。

Application / 应用

Use TLS For All Pages / 所有页面使用TLS

TLS should be used for all pages, not just those that are considered sensitive such as the login page. If there are any pages that do not enforce the use of TLS, these could give an attacker an opportunity to sniff sensitive information such as session tokens, or to inject malicious JavaScript into the responses to carry out other attacks against the user.

TLS应应用于所有页面，而不仅仅是被认为是敏感的页面，如登录页面。如果有任何页面没有强制使用TLS，这可能会给攻击者提供窃取敏感信息（如会话令牌）或向响应中注入恶意JavaScript以对用户进行其他攻击的机会。

For public facing applications, it may be appropriate to have the web server listening for unencrypted HTTP connections on port 80, and then immediately redirecting them with a permanent redirect (HTTP 301) in order to provide a better experience to users who manually type in the domain name. This should then be supported with the HTTP Strict Transport Security (HSTS) header to prevent them accessing the site over HTTP in the future.

对于面向公众的应用程序，可能有必要让Web服务器在端口80上监听未加密的HTTP连接，然后立即通过永久重定向（HTTP 301）将它们重定向，以向手动输入域名的用户提供更好的体验。然后应使用HTTP严格传输安全（HSTS）头文件来防止他们未来通过HTTP访问网站。

API-only endpoints should disable HTTP altogether and only support encrypted connections. When that is not possible, API endpoints should fail requests made over unencrypted HTTP connections instead of redirecting them.

仅API端点的应用应完全禁用HTTP，并仅支持加密连接。当不可能这样做时，API端点应拒绝未加密HTTP连接的请求，而不是将其重定向。

Do Not Mix TLS and Non-TLS Content / 不要混合TLS和非TLS内容

A page that is available over TLS should not include any resources (such as JavaScript or CSS) files which are loaded over unencrypted HTTP. These unencrypted resources could allow an attacker to sniff session cookies or inject malicious code into the page. Modern browsers will also block attempts to load active content over unencrypted HTTP into secure pages.

通过TLS可访问的页面不应包含任何通过未加密HTTP加载的资源（例如JavaScript或CSS文件）。这些未加密的资源可能允许攻击者嗅探会话cookie或将恶意代码注入页面。现代浏览器还会阻止尝试将活动内容通过未加密HTTP加载到安全页面中。

Use "Secure" Cookies / 使用“Secure”cookie

All cookies must be marked with the "Secure" attribute. This instructs the browser to only send them over encrypted HTTPS connections. This is important even if the website does not listen on HTTP, as an attacker performing an active man in the middle attack could redirect the user to a spoofed web server served over HTTP in order to steal their cookie.

所有cookie都必须标记为“Secure”属性。这指示浏览器仅在加密HTTPS连接中发送它们。即使网站没有监听HTTP，这也非常重要，因为执行主动中间人攻击的攻击者可能会将用户重定向到通过HTTP提供伪造Web服务器的服务器，以窃取他们的cookie。

In addition, you must use the __Secure- prefix for the cookie to ensure that a man in the middle cannot modify the cookie over plain HTTP. This type of attacks could for example be exploited in session fixation attacks.

此外，您必须使用__Secure-前缀来确保中间人无法在纯HTTP上修改cookie。此类攻击可能被用于会话固定攻击。

Prevent Caching of Sensitive Data / 防止敏感数据缓存

Although TLS provides protection of data while it is in transit, it does not provide any protection for data once it has reached the requesting system. As such, this information may be stored in the cache of the user's browser, or by any intercepting proxies which are configured to perform TLS decryption.

尽管TLS在数据传输过程中提供保护，但它不会在数据到达请求系统后提供任何保护。因此，此类信息可能存储在用户的浏览器缓存中，或由配置为执行TLS解密的任何拦截代理存储。

Where sensitive data is returned in responses, HTTP headers should be used to instruct the browser and any proxy server not to cache the information, in order to prevent it being stored or returned to other users. For modern HTTP/1.1+ clients and intermediaries, a single header is sufficient:

当敏感数据在响应中返回时，应使用HTTP头指令浏览器和任何代理服务器不要缓存信息，以防止其被存储或返回给其他用户。对于现代HTTP/1.1+客户端和中介，单个头信息就足够了：

Cache-Control: no-store

no-store is the strongest cache directive: it forbids both shared and private caches from storing any part of the response. The legacy combination Cache-Control: no-cache, no-store, must-revalidate plus Pragma: no-cache and Expires: 0 is only required if you must support pre-HTTP/1.1 caches (effectively obsolete in 2024+) and adds no protection beyond no-store on a modern stack. Note that Cache-Control governs the HTTP cache; it does not control whether the browser stores cookies in its cookie jar — that is controlled by the cookie attributes (Max-Age, Expires, Session).

no-store 是最强的缓存指令：它禁止共享和私有缓存存储响应的任何部分。传统的组合 Cache-Control: no-cache, no-store, must-revalidate 加上 Pragma: no-cache 和 Expires: 0 仅在您必须支持 HTTP/1.1 之前的缓存时才需要（实际上在 2024+ 之后已过时）并且在现代堆栈上不会提供比 no-store 更多的保护。请注意，Cache-Control 规范 HTTP 缓存；它不控制浏览器是否在 cookie jar 中存储 cookies — 这由 cookie 属性（Max-Age、Expires、Session）控制。

If you also need to clear data already cached on the client at sign-out, additionally send Clear-Site-Data (e.g. Clear-Site-Data: "cache", "cookies", "storage").

如果您还需要在注销时清除客户端已缓存的任何数据，请额外发送 Clear-Site-Data（例如 Clear-Site-Data: "cache", "cookies", "storage"）。

Use HTTP Strict Transport Security / 使用 HTTP 严格传输安全

HTTP Strict Transport Security (HSTS) instructs the user's browser to always request the site over HTTPS, and also prevents the user from bypassing certificate warnings. See the HTTP Strict Transport Security Cheat Sheet for further information on implementing HSTS.

HTTP 严格传输安全（HSTS）指示用户的浏览器始终通过 HTTPS 请求网站，并防止用户绕过证书警告。有关实施 HSTS 的更多信息，请参阅 HTTP 严格传输安全作弊表。

Client Certificates and Mutual TLS / 客户端证书和相互 TLS

A typical TLS connection authenticates the server, while mutual TLS (mTLS) also authenticates the client using a client certificate and proof of its private key. In TLS 1.3, this proof is bound to the handshake transcript by CertificateVerify. This channel binding prevents an intermediary from relaying the client's authentication onto a separate TLS connection to the legitimate server.

典型的 TLS 连接验证服务器，而相互 TLS（mTLS）还使用客户端证书和其私钥的证明来验证客户端。在 TLS 1.3 中，这个证明通过 CertificateVerify 与握手转文绑定。这种 通道绑定 防止中间人将客户端的认证转发到与合法服务器不同的 TLS 连接上。

TLS provides confidentiality between its endpoints; mTLS does not make data confidential from a TLS endpoint whose server certificate the client accepts. If the client accepts an attacker's certificate for the target domain, the attacker can read application data sent to that endpoint, even when the client uses a certificate. Validate the server's identity and trust configuration independently; see Public Key Pinning for applications that need to restrict server trust further.

TLS 提供其端点之间的 机密性；mTLS 不会使 TLS 端点上的数据对客户端接受的服务器证书不保密。如果客户端接受攻击者为目标域的证书，攻击者可以读取发送到该端点的应用程序数据，即使客户端使用证书。独立验证服务器的身份和信任配置；对于需要进一步限制服务器信任的应用程序，请参阅 公钥固定。

Challenges and Considerations

挑战和考虑因素

Client certificates are rarely used in public systems due to several challenges:

客户端证书在公共系统中很少使用，因为存在一些挑战：

  • Issuing and managing client certificates involves significant administrative overhead.
    中文：颁发和管理客户端证书涉及大量的管理开销。
  • Non-technical users may find installing client certificates difficult.
    中文：非技术用户可能会发现安装客户端证书很困难。
  • Organizations' TLS decryption practices can cause client certificate authentication, a key component of mTLS, to fail.
    中文：组织机构的TLS解密实践可能导致客户端证书身份验证失败，这是mTLS的关键组成部分。

Despite these challenges, client certificates and mTLS should be considered for high-value applications or APIs, particularly where users are technically sophisticated or part of the same organization.

尽管存在这些挑战，但客户端证书和mTLS应考虑用于高价值应用程序或API，尤其是在用户技术熟练或属于同一组织的情况下。

Public Key Pinning / 公钥固定

Public key pinning can be used to provides assurance that the server's certificate is not only valid and trusted, but also that it matches the certificate expected for the server. This provides protection against an attacker who is able to obtain a valid certificate, either by exploiting a weakness in the validation process, compromising a trusted certificate authority, or having administrative access to the client.

公钥固定可以用来确保服务器的证书不仅有效且受信任，而且与服务器预期的证书相匹配。这可以防止攻击者通过利用验证过程中的弱点、损害受信任的证书颁发机构或拥有对客户端的行政访问权限来获取有效的证书。

Public key pinning was added to browsers in the HTTP Public Key Pinning (HPKP) standard. However, due to a number of issues, it has subsequently been deprecated and is no longer recommended or supported by modern browsers.

公钥固定被添加到浏览器的HTTP公钥固定（HPKP）标准中。然而，由于一系列问题，它已经被弃用，不再推荐或由现代浏览器支持。

However, public key pinning can still provide security benefits for mobile applications, thick clients and server-to-server communication. This is discussed in further detail in the Pinning Cheat Sheet.

然而，公钥固定仍然可以为移动应用、厚客户端和服务器之间的通信提供安全优势。这将在Pinning 快速参考中进一步讨论。

References / 参考