ToB企服应用市场:ToB评测及商务社交产业平台

标题: HTTPS 安全最佳实践（一）之SSLTLS部署 [打印本页]
作者: 饭宝    时间: 2024-11-14 01:08
标题: 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 掩护你的私钥

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

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：

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 套件。还有一些其他较弱的套房可能仍然得到支持，只要它们只能与不支持任何更好的老客户举行协商。
有几个逾期的加密原语必须避免：

使用以RSA和ECDSA键为基础的以下套件设置，作为起点：
  1. TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  2. TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  3. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  4. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  5. TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  6. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  7. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  8. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  9. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  10. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  11. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  12. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  13. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  14. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  15. TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  16. TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  17. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  18. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
复制代码
  警告：
我们建议您始终起首在分段环境中测试TLS设置，仅在确定全部内容按预期工作时将更改应用到生产环境。请注意，以上是一个通用列表，并不是全部系统（特别是较旧的）支持全部套件。这就是为什么测试很重要，推荐您使用《SSL/TLS安全评估》举行检查。
  上述示例设置使用标准 TLS 套件名称。一些平台使用非标准名称; 有关具体信息，请参阅您的平台的文档。比方，以下套件名称将与OpenSSL 一起使用：
  1. ECDHE-ECDSA-AES128-GCM-SHA256
  2. ECDHE-ECDSA-AES256-GCM-SHA384
  3. ECDHE-ECDSA-AES128-SHA
  4. ECDHE-ECDSA-AES256-SHA
  5. ECDHE-ECDSA-AES128-SHA256
  6. ECDHE-ECDSA-AES256-SHA384
  7. ECDHE-RSA-AES128-GCM-SHA256
  8. ECDHE-RSA-AES256-GCM-SHA384
  9. ECDHE-RSA-AES128-SHA
  10. ECDHE-RSA-AES256-SHA
  11. ECDHE-RSA-AES128-SHA256
  12. ECDHE-RSA-AES256-SHA384
  13. DHE-RSA-AES128-GCM-SHA256
  14. DHE-RSA-AES256-GCM-SHA384
  15. DHE-RSA-AES128-SHA
  16. DHE-RSA-AES256-SHA
  17. DHE-RSA-AES128-SHA256
  18. 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 加密无处不在

加密是可选的毕竟可能是本日最大的安全题目之一。我们看到以下题目：

只管如果您确切了解您正在做的事情，许多这些题目可以被缓解，可靠地掩护网站通信的唯一方法是无一例外地执行加密。
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，同时还答应预加载：
  1. Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
复制代码
5.6 部署 CSP

内容安全计谋（CSP）是网站可以用来限定浏览器操纵的安全机制。只管最初旨在办理跨站点脚本（XSS），CSP 不断发展，并支持对加强TLS安全性有用的功能。特别地，它可以用于限定混合内容，当涉及到第三方网站，HSTS没有资助。
要部署CSP以防止第三方混合内容，请使用以下设置：
  1. Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval';
  2.                          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部署
‍

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4