HTTPS 安全最佳实践（一）之SSLTLS部署

SSL/TLS 是一种简单易懂的技术，它很容易部署及运行。但想要部署的安全通常是不容易的。这也使系统管理员和开发者不得不去了解 SSL 和 TLS 相关的技术，掌握如何配置一个安全的 web 服务器或应用。无疑会耗费很大的精力去看相关的技术文档，乏味且宽泛。

受理SSL数字证书客户问题，包括产品咨询、技术支持、投诉受理、建议反馈，以及购买帮助等。

1 证书和私钥

在TLS中，所有的安全性都从服务器的密码标识开始；需要一个强大的私钥来防止攻击者进行模拟攻击。同样重要的是要有一个有效的和强大的证书，这将授予私有密匙作为一个特定主机名的权利。没有这两个基本的构建块，就没有其他东西可以安全了。

1.1 使用 2048 位私钥

对于大多数的 web 站点，提供一个 2048 的 RSA key 是足够安全的。RSA 的公钥算法是被普遍支持的，这使得这个类型的 key 作为默认是足够安全的。对于 2048 位，这些 key 提供了大约 112 位的安全性。如果您想要比这更多的安全性，请注意 RSA key 的伸缩性不太好。想要获得 128 位的安全性，你需要 3072 位 RSA key，这会很大的影响性能。ECDSA key 提供了一种提供更好安全性和更好性能的替代方法。对于 256 位，ECDSA key 提供 128 位安全性。少数古董客户端不支持 ECDSA，但现代客户端是支持的。如果您不介意管理这样一个设置的开销，那么您可以同时部署 RSA 和 ECDSA 密钥。

1.2 保护你的私钥

把你的私钥视为一项重要的资产，尽可能最大的使用你的私钥，限制最小的员工的访问。建议的政策包括以下内容:

• 在可信计算机上用足够的熵生成私有密钥。一些 CA 为您提供生成私钥的功能，请尽量不要这样做。
• 密码保护 key 最初就不要存储在备份系统中。私钥密码在生产环境中起不了什么作用，因为有知识的攻击者总是能够从进程内存中检索密钥。有硬件设备(被称为硬件安全模块，或 HSMs)，即使在服务器折衷的情况下，也可以保护私有密匙，但是它们是昂贵的，因此仅适用于具有严格安全性需求的组织。
• 妥协后，撤销旧证书并生成新密钥。
• 每年更新证书，如果您可以自动化过程，则更频繁。大多数网站都应该假定不可靠的妥协证书被撤销; 因此，具有较短使用寿命的证书在实践中更加安全。
• 除非保持相同的密钥对于公钥密钥很重要，否则每当获得新证书时，还应该生成新的私钥。

1.3 覆盖您的域名

确保您的证书涵盖您希望与网站一起使用的所有名称。您的目标是避免无效的证书警告，这会混淆用户，削弱他们的信心。

即使您期望只使用一个域名，请记住，您无法控制用户到达该网站的方式或其他人如何链接到该网站。在大多数情况下，您应该确保该证书与 www 前缀有关（例如，它适用于 example.com 和
www.example.com ）。经验法则是，安全的 Web 服务器应该具有对配置为指向它的每个 DNS 名称有效的证书。

通配符证书能满足更广泛的需求，但如果准备将密钥暴露给更多的人员，特别是跨团队或部门，则避免使用它们。换句话说，访问私钥的人越少越好。还要注意，证书共享会创建一个可以被滥用的将漏洞从一个网站或服务器传输到使用相同证书的所有其他站点和服务器（即使底层私钥不同，只要证书域名匹配）的绑定。

1.5 从可信 CA 获取证书

选择对其证书业务和安全性可靠和认真的认证中心（CA）。选择 CA 时，请考虑以下条件：

安全状态 所有CA都经过定期审核，但有些则比其他 CA 更为严重。弄清哪些在这方面做的更好并不容易，但一个选择是检查他们的安全历史，更重要的是，他们如何反应妥协，如果他们从错误中学到了经验，这将更有利。

业务重点 CA 的活动构成其业务的重要组成部分，如果事情发生严重错误，其所有事情都将丢失，并且在其他地方追逐潜在的更有利可图的机会可能不会忽视其证书部门。

提供的服务 至少，您选择的 CA 应提供对证书吊销列表（CRL）和在线证书状态协议（OCSP）撤销方法的支持，具有稳定的网络可用性和性能。许多网站对域验证的证书感到满意，但您也应该考虑是否需要扩展验证（EV）证书。在任一种情况下，您都应该选择公钥算法。大多数网站今天使用 RSA，但由于其性能优势，ECDSA 在未来可能会变得重要。

证书管理 选项如果您需要大量证书并在复杂环境中运行，请选择一个 CA，为您提供良好的管理工具。

支持选择一个 CA，如果需要的话可以给您很好的支持。

注意
为了获得最佳效果，请提前获得证书，并在部署到生产之前至少一周。这种做法（1）有助于避免在计算机上没有正确时间的一些用户的证书警告;（2）有助于避免与 CA 需要额外时间的 CA 失败的撤销检查，以向 OCSP 响应者传播有效的新证书。随着时间的推移，尝试将这个“热身”期延长至 1-3 个月。同样，不要等到你的证书即将到期以替换它们。留下额外的几个月也会帮助时钟不正确的人在另一个方向。

1.6 使用强签名算法

证书安全性取决于（1）用于签署证书的私钥的强度，（2）签名中使用的散列函数的强度。直到最近，大多数证书都依赖于 SHA1 散列函数，现在被认为是不安全的。因此，我们正在向 SHA256 转型。截至 2016
年 1 月，您无法从公共 CA 获取 SHA1 证书。现有的 SHA1 证书将继续工作（在某些浏览器中有警告），但只能到 2016 年底。

2 配置

使用正确的 TLS 服务器配置，您可以确保将凭据正确呈现给站点的访问者，仅使用安全的加密原语，并减轻所有已知的缺陷。

2.1 使用完整的证书链

在大多数部署中，仅服务器证书不够的; 需要两个或多个证书来建立完整的信任链。当部署具有有效证书但没有所有必要的中间证书的服务器时，会发生常见的配置问题。为避免这种情况，只需使用 CA 提供给您的所有证书。

无效的证书链有效地使服务器证书无效并导致浏览器警告。实际上，这个问题有时难以诊断，因为一些浏览器可以重构不完整的链，有些浏览器不能重建。所有浏览器都倾向于缓存和重用中间证书。

2.2 使用安全的协议

SSL／TLS 系列中有五种协议：SSL v2，SSL v3，TLS v1.0，TLS v1.1和TLS v1.2：

• SSL v2 是不安全的，不能使用。此协议版本非常糟糕，即使它们位于完全不同的服务器（DROWN 攻击）上也可以用来攻击具有相同名称的RSA 密钥和站点。
• 当与 HTTP（POODLE 攻击）一起使用时，SSL v3 是不安全的，当与其他协议一起使用时，SSL v3 是弱的。它也是过时的，不应该被使用。
• TLS v1.0 也是不应该使用的传统协议，但在实践中通常仍然是必需的。其主要弱点（BEAST）在现代浏览器中得到缓解，但其他问题仍然存在。
• TLS v1.1 和 v1.2 都没有已知的安全问题，只有 v1.2 提供了现代的加密算法。

TLS v1.2 应该是您的主要协议，因为它是唯一提供现代认证加密（也称为 AEAD）的版本。如果您今天不支持 TLS v1.2，则缺乏安全性。

为了支持较旧的客户端，您可能需要继续支持 TLS v1.0 和TLS v1.1。但是，您应该计划在不久的将来退出 TLS v1.0。例如，PCI DSS 标准将要求所有接受信用卡付款的网站在 2018 年 6 月之前移除对 TLS v1.0 的支持。

目前正在开展设计 TLS v1.3 的工作，其目的是消除所有过时和不安全的功能，并进行改进，以保持我们的通信在未来几十年内的安全。

2.3 使用安全的套件

为了安全通信，您必须首先确定您正在与所需方（而不是通过将窃听的其他人）直接沟通并安全地交换数据。在 SSL 和 TLS 中，密码套件定义了如何进行安全通信。它们由不同的建筑组成，通过多样性实现安全。如果发现其中一个构建块软弱或不安全，那么您应该可以切换到另一个。

您应该主要依靠提供强身份验证和密钥交换，前向保密和至少 128 位加密的 AEAD 套件。还有一些其他较弱的套房可能仍然得到支持，只要它们只能与不支持任何更好的老客户进行协商。

有几个过时的加密原语必须避免：

• 匿名 Diffie-Hellman（ADH）套件不提供身份验证。
• NULL 密码套件不提供加密。
• 导出密码套件在连接中协商时不安全，但也可以针对更喜欢更强大的套件（FREAK攻击）的服务器使用。
• 弱密码（通常为 40 和 56 位）的套件使用可以轻松破坏的加密。
• RC4 是不安全的。
• 3DES 缓慢而虚弱。

使用以RSA和ECDSA键为基础的以下套件配置，作为起点：

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

警告：
我们建议您始终首先在分段环境中测试TLS配置，仅在确定所有内容按预期工作时将更改应用到生产环境。请注意，以上是一个通用列表，并不是所有系统（特别是较旧的）支持所有套件。这就是为什么测试很重要，推荐您使用《SSL/TLS安全评估》进行检查。

上述示例配置使用标准 TLS 套件名称。一些平台使用非标准名称; 有关详细信息，请参阅您的平台的文档。例如，以下套件名称将与OpenSSL 一起使用：

ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

2.4 选择合适的协议

在SSL v3及更高版本的协议版本中，客户端提交他们支持的密码套件列表，服务器从列表中选择一个用于连接的套件。然而，并不是所有的服务器都做得很好，有些将从客户端列表中选择第一个支持的套件。使服务器主动选择最佳可用加密套件对于实现最佳安全性至关重要。

2.5 使用 FS

前向保密（有时也称为完全前向保密）是一种协议功能，可实现不依赖服务器私钥的安全对话。对于不提前向保密的密码套件，可以恢复服务器的私钥的人就可以解密所有较早记录的加密对话（也就是可以先大量记录密文，再解密，比如您的证书到期后没有正确销毁，它的私钥就能用来解密非PFS的密文）。您需要支持并喜欢 ECDHE 套件，以便通过现代网络浏览器实现前向保密。为了支持更广泛的客户，您还应该使用 DHE 套件作为 ECDHE 后备。避免 RSA 密钥交换，除非绝对必要。我在2.3节中提出的默认配置只包含提供前向保密的套件。

2.6 使用强的密钥交换算法

对于密钥交换，公共站点通常可以选择经典的短暂的 Diffie-Hellman密钥交换（DHE）和其椭圆曲线变体 ECDHE。还有其他的密钥交换算法，但是它们通常是以某种方式不安全的。RSA 密钥交换仍然很受欢迎，但不提供前向保密。

2015 年，一批研究人员发表了对 DHE 的新攻击; 他们的工作被称为Logjam 攻击。[2] 研究人员发现，较低强度的 DH 密钥交换（例如768 位）容易被破坏，一些知名的 1024 位 DH 组可被国家机构破坏。为了安全起见，如果部署 DHE，请至少配置 2048 位的安全性。一些较老的客户端（例如Java 6）可能不支持这种强度。出于性能原因，大多数服务器应该更喜欢 ECDHE，这是更强大和更快。在这种情况下，secp256r1命名曲线（也称为 P-256）是一个很好的选择。

3 减轻已知问题

近几年来已经发生了几次严重的 SSL 和 TLS 攻击，但是如果您正在运行最新的软件并遵循本指南的建议，那么它们通常不会关心您。（如果没有，我建议您使用 chinaz 测试您的系统，并从中进行测试）。但是，没有什么是完全安全的，所以为了保持对安全性的了解，这是一个很好的做法。如果供应商补丁可用，请及时提供; 否则，依靠解决方案进行缓解。

4 性能

安全是我们在本指南中的主要重点，但我们也要注意表现; 一个不符合性能标准的安全服务无疑将被丢弃。通过正确配置，TLS 可以相当快。使用现代协议（例如 HTTP/2），甚至可能比明文通信更快。

4.1 避免过度安全

用于建立安全连接的密码握手是一种操作，其费用受私钥大小的高度影响。使用太短的密钥是不安全的，但使用太长的密钥将导致“太多”的安全性和缓慢的操作。对于大多数网站，使用超过 2048 位的 RSA 密钥和强大于 256 位的 ECDSA 密钥会浪费 CPU 功耗，并可能会损害用户体验。类似地，增加短暂密钥交换的强度对于 DHE 为 2048 位以及 ECDHE 为 256 位几乎没有什么好处。使用高于 128 位的加密没有明显的好处。

4.2 使用 session 恢复

会话恢复是一种性能优化技术，可以节省昂贵的密码操作的结果，并重复使用一段时间。残疾或非功能性会话恢复机制可能会引起显着的性能损失。

4.3 使用 WAN 优化和 HTTP/2

这些天，TLS 开销不是来自 CPU 饥饿的加密操作，而是来自网络延迟。只有在 TCP 握手完成后才能启动TLS握手，需要进一步交换数据包，并且离开服务器的距离更远。最小化延迟的最佳方法是避免创建新的连接 - 换句话说，保持现有的连接长时间（keep-alives）。提供良好结果的其他技术包括支持现代协议（如HTTP / 2）和使用WAN优化（通常通过内容传送网络）。

4.4 隐藏公共内容

通过TLS进行通信时，浏览器可能会认为所有流量都是敏感的。它们通常会使用内存来缓存某些资源，但一旦关闭浏览器，所有内容可能会丢失。为了获得性能提升，并能够长期缓存一些资源，将公共资源（例如图像）标记为公开。

4.5 使用 OCSP Stapling

OCSP 装订是 OCSP 协议的扩展，可以直接从服务器提供撤销信息作为 TLS 握手的一部分。因此，客户端不需要联系 OCSP 服务器进行带外验证，并且总体 TLS 连接时间显着减少。OCSP 装订是一种重要的优化技术，但您应该注意，并不是所有的网络服务器都提供了可靠的 OCSP 装订实现。结合具有缓慢或不可靠的 OCSP 响应者的 CA，这样的 Web 服务器可能会产生性能问题。为了获得最佳效果，请模拟故障条件，看看它们是否会影响您的可用性。

4.6 使用快速加密

除了提供最佳的安全性，我推荐的密码套件配置也提供了最好的性能。尽可能使用支持硬件加速 AES 的 CPU。之后，如果您真的想要进一步的性能优势（大多数网站可能不需要），请考虑使用 ECDSA 密钥。

5 HTTP 和 应用安全

HTTP 协议和 Web 应用交付的周边平台在 SSL 诞生后继续快速发展。作为这一进化的结果，该平台现在包含可用于打败加密的功能。在本节中，我们列出了这些功能，以及安全使用它们的方法。

5.1 加密无处不在

加密是可选的事实可能是今天最大的安全问题之一。我们看到以下问题：

• 没有 TLS 需要它的网站
• 具有 TLS 但不执行 TLS 的站点
• 混合 TLS 和非 TLS 内容的网站，有时甚至在同一网页内
• 编程错误的网站会颠覆 TLS

尽管如果您确切了解您正在做的事情，许多这些问题可以被缓解，可靠地保护网站通信的唯一方法是无一例外地执行加密。

5.2 消除混合内容

混合内容页面是通过 TLS 传输但是包含不通过 TLS 传输的资源（例如，JavaScript 文件，images，CSS 文件）的页面。这样的页面不安全。一个活跃的中间人（MITM）攻击者可以搭载一个单独的未受保护的 JavaScript 资源，例如劫持整个用户会话。即使您遵循上一节的建议并对整个网站加密，您仍然可能会最终从第三方网站中检索未加密的一些资源。

5.3 使用可信第三方

网站通常使用通过从另一个服务器下载的 JavaScript 代码激活的第三方服务。这种服务的一个很好的例子是 Google Analytics（分析），用于 Web 的大部分。这种包含第三方代码创建一个隐含的信任连接，有效地使对方完全控制您的网站。第三方可能不是恶意的，但是这些服务的大型提供商越来越被视为目标。推理很简单：如果大型提供程序受到威胁，攻击者将被自动访问所有依赖该服务的站点。

如果您遵循第4.2节的建议，至少您的第三方链接将被加密，从而避免 MITM 攻击。但是，您应该进一步了解：了解您使用的服务和删除服务，将其替换为更安全的替代方案，或接受其继续使用的风险。一种称为子资源完整性（SRI）的新技术可用于通过第三方资源来减少潜在的风险。[3]

5.4 安全 cookie

要正确安全，网站需要 TLS，而且所有的 Cookie 在创建时都被明确标记为安全的。未能保护 cookies 可以让活跃的 MITM 攻击者通过聪明的技巧来挑逗一些信息，即使在 100％ 加密的网站上也是如此。为了获得最佳效果，请考虑为您的 Cookie 添加加密完整性验证或甚至加密。

5.5 安全 HTTP 压缩

2012 年 CRIME 攻击显示 TLS 压缩无法安全实施。唯一的解决方案是完全禁用 TLS 压缩。次年，随后再发生两次攻击。TIME 和 BREACH 专注于使用 HTTP 压缩压缩的 HTTP 响应实体中的秘密。与 TLS 压缩不同，HTTP 压缩是必需的，不能关闭。因此，为了解决这些攻击，需要对应用程序代码进行更改。[4]

TIME 和 BREACH 攻击并不容易实现，但是如果某人有足够的动力使用它们，则这种影响大致相当于成功的跨站点请求伪造（CSRF）攻击。

5.5 部署 HSTS

HTTP 严格传输安全（HSTS）是 TLS 的安全网。它旨在确保即使在配置问题和实施错误的情况下，安全性仍然保持不变。要激活 HSTS 保护，您可以向您的网站添加一个新的响应头。之后，支持 HSTS（此时所有现代浏览器）的浏览器执行它。

HSTS 的目标很简单：激活后，它不允许与使用它的网站进行任何不安全的通信。通过自动将所有明文链接转换为安全的链接，实现了这一目标。作为奖励，它还会禁用点击式证书警告。（证书警告是活动的 MITM 攻击的指标，研究表明大多数用户点击这些警告，所以绝对不要让他们感兴趣）。

添加对 HSTS 的支持是您可以为您的网站的 TLS 安全性做出的最重要的改进。新站点始终应设计为 HSTS，旧站点转换为尽可能快地支持。为了获得最佳安全性，请考虑使用 HSTS 预加载[5]，将HSTS配置嵌入到现代浏览器中，从而使您的网站的第一个连接安全。

以下配置示例将在主主机名及其所有子域上激活一段时间为一年的 HSTS，同时还允许预加载：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

5.6 部署 CSP

内容安全策略（CSP）是网站可以用来限制浏览器操作的安全机制。尽管最初旨在解决跨站点脚本（XSS），CSP 不断发展，并支持对增强TLS安全性有用的功能。特别地，它可以用于限制混合内容，当涉及到第三方网站，HSTS没有帮助。

要部署CSP以防止第三方混合内容，请使用以下配置：

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval';
                         connect-src https: wss:

注意
这不是部署 CSP 的最佳方法。为了提供不破坏混合内容以外的任何内容的示例，我不得不禁用某些默认安全功能。随着时间的推移，当您了解 CSP 的更多信息时，您应该更改您的策略以使其恢复。

5.7 不要缓存敏感内容

所有敏感内容必须仅传达给预定方，并由所有设备进行相应处理。虽然代理没有看到加密的流量，并且不能在用户之间共享内容，但是使用基于云的应用交付平台正在增加，这就是为什么在指定什么是公共的时候需要非常小心的是什么。

5.8 考虑其它威胁

TLS 旨在仅解决安全机密和您与用户之间通信的完整性的一个方面，但还有许多其他威胁需要处理。在大多数情况下，这意味着确保您的网站没有其他弱点。

6 验证

有许多配置参数可用于调整，预先知道某些变化会产生什么影响。此外，有时会意外地进行更改; 软件升级可以静默地引入更改。因此，我们建议您最初使用全面的 SSL/TLS 评估工具来验证您的配置，以确保您开始安全，然后定期确保您保持安全。对于公共网站，我们建议您免费使用SSL实验室服务器测试。[6]

6.1 高级主题

以下高级主题目前不在我们的指南范围之内。他们需要更深入地了解 SSL/TLS 和公钥基础设施（PKI），而且他们仍然被专家辩论。

6.2 使用 HPKP

公共密钥固定旨在使网站运营商有权限制哪些 CA 可以为其网站颁发证书。Google 已经部署了这个功能了一段时间（硬编码到他们的浏览器，Chrome），并且已被证明是非常有用的，以防止攻击并使公众了解它们。在 2014 年，Firefox 还增加了对硬编码固定的支持。现在可以使用一种称为 HTTP [7]的公钥固定扩展标准。公钥绑定解决了 PKI 最大的弱点（事实上，任何 CA 都可以为任何网站发布证书），但是这是一个成本; 部署需要大量精力和专业知识，并造成失去对您站点控制的风险（如果最终导致无效的固定配置）。你应该考虑固定很大程度上只有当你

6.2 使用 DNSSEC 和 DANE

域名系统安全扩展（DNSSEC）是一种增加域名系统完整性的技术。今天，一个活跃的网络攻击者可以轻松地劫持任何 DNS 请求并伪造任意的响应。使用 DNSSEC，所有响应都可以加密地跟踪到 DNS 根目录。命名实体的基于 DNS 的身份验证（DANE）是建立在 DNSSEC 之上的单独标准，用于提供 DNS 和 TLS 之间的绑定。DANE 可用于增强现有基于 CA 的 PKI 生态系统的安全性，或者完全绕过它。

即使不是每个人都同意，DNSSEC 是互联网的一个很好的方向，但对其的支持仍在继续改善。浏览器还不支持 DNSSEC 或 DANE（更喜欢 HSTS 和 HPKP 提供的类似功能），但有一些迹象表明它们正在开始用于提高电子邮件传递的安全性。

原文链接：HTTPS 安全最佳实践（一）之SSL/TLS部署

‍