0x01漏洞检测1.nmap2.2.漏洞类型是什么

0x01漏洞检测1.nmap

1
2

验证多种SSL漏洞问题
nmap www.baidu.com --vv --script sshv1,ssl-ccs-injection,ssl-cert,ssl-date,ssl-dh-params,ssl-enum-ciphers,ssl-heartbleed,ssl-known-key,sslv2

2.漏洞类型 加密算法

是一种老旧的弱加密算法，是被美国法律标示为可出口的加密算法，其限制对称加密最大强度位数为40位，限制密钥交换强度为最大512位。这是一个现今被强制丢弃的算法。

（降级攻击）

降级攻击是一种对计算机系统或者通信协议的攻击，在降级攻击中，攻击者故意使系统放弃新式、安全性高的工作方式，反而使用为向下兼容而准备的老式、安全性差的工作方式，降级攻击常被用于中间人攻击，讲加密的通信协议安全性大幅削弱，得以进行原本不可能做到的攻击。 在现代的回退防御中，使用单独的信号套件来指示自愿降级行为，需要理解该信号并支持更高协议版本的服务器来终止协商，该套件是()

MITM（中间人攻击）

MITM(Man-in-the-) ，是指攻击者与通讯的两端分别创建独立的联系，并交换其所有收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个对话都被攻击者完全控制，在中间人攻击中，攻击者可以拦截通讯双方的通话并插入新的内容。一个中间人攻击能成功的前提条件是攻击者能够将自己伪装成每个参与会话的终端，并且不被其他终端识破。

BEAST（野兽攻击）

BEAST(CVE-2011-3389) BEAST是一种明文攻击，通过从SSL/TLS加密的会话中获取受害者的值（通过进行一次会话劫持攻击），进而篡改一个加密算法的 CBC（密码块链）的模式以实现攻击目录，其主要针对TLS1.0和更早版本的协议中的对称加密算法CBC模式。

RC4 加密算法

由于早期的BEAST野兽攻击而采用的加密算法，RC4算法能减轻野兽攻击的危害，后来随着客户端版本升级，有了客户端缓解方案（ 和 提供了缓解方案），野兽攻击就不是什么大问题了。同样这是一个现今被强制丢弃的算法。

CRIME（罪恶攻击）

CRIME(CVE-2012-4929)，全称 Ratio Info-leak Made Easy，这是一种因SSL压缩造成的安全隐患，通过它可窃取启用数据压缩特性的HTTPS或SPDY协议传输的私密Web 。在成功读取身份验证后，攻击者可以实行会话劫持和发动进一步攻击。

SSL 压缩在下述版本是默认关闭的： nginx 1.1.6及更高/1.0.9及更高（如果使用了 1.0.0及更高）， nginx 1.3.2及更高/1.2.2及更高（如果使用较旧版本的 ）。

如果你使用一个早期版本的 nginx 或 ，而且你的发行版没有向后移植该选项，那么你需要重新编译没有一个 ZLIB 支持的 。这会禁止 使用 压缩方式。如果你禁用了这个，你仍然可以使用常规的 HTML 压缩。

（心血漏洞）

(CVE-2014-0160) 是一个于2014年4月公布的 加密库的漏洞，它是一个被广泛使用的传输层安全（TLS）协议的实现。无论是服务器端还是客户端在 TLS 中使用了有缺陷的 ，都可以被利用该缺陷。由于它是因 DTLS 心跳扩展（RFC 6520）中的输入验证不正确（缺少了边界检查）而导致的，所以该漏洞根据“心跳”而命名。这个漏洞是一种缓存区超读漏洞，它可以读取到本不应该读取的数据。如果使用带缺陷的版本，无论是服务器还是客户端，都可能因此受到攻击。

漏洞（卷毛狗攻击）

2014年10月14号由发现的漏洞，全称是 On ，又被称为“贵宾犬攻击”（CVE-2014-3566），漏洞只对CBC模式的明文进行了身份验证，但是没有对填充字节进行完整性验证，攻击者窃取采用SSL3.0版加密通信过程中的内容，对填充字节修改并且利用预置填充来恢复加密内容，以达到攻击目的。

TLS （TLS卷毛狗攻击）

TLS (CVE-2014-8730) 该漏洞的原理和漏洞的原理一致，但不是SSL3协议。由于TLS填充是SSLv3的一个子集，因此可以重新使用针对TLS的攻击。TLS对于它的填充格式是非常严格的，但是一些TLS实现在解密之后不执行填充结构的检查。即使使用TLS也不会容易受到攻击的影响。

CCS

CCS(CVE-2014-0224) 全称 MITM CCS ， 0.9.8za之前的版本、1.0.0m之前的以及1.0.1h之前的没有适当的限制信息的处理，这允许中间人攻击者在通信之间使用0长度的主密钥。

FREAK

FREAK(CVE-2015-0204) 客户端会在一个全安全强度的RSA握手过程中接受使用弱安全强度的出口RSA密钥，其中关键在于客户端并没有允许协商任何出口级别的RSA密码套件。

(CVE-2015-4000) 使用 - 密钥交换协议的 TLS 连接很容易受到攻击，尤其是DH密钥中的公钥强度小于。中间人攻击者可将有漏洞的 TLS 连接降级至使用 512 字节导出级加密。这种攻击会影响支持 密码的所有服务器。这个攻击可通过为两组弱 - 参数预先计算 512 字节质数完成，特别是 的 httpd 版本 2.1.5 到 2.4.7，以及 的所有版本。

DROWN（溺水攻击/溺亡攻击）

2016年3月发现的针对TLS的新漏洞攻击——DROWN（ RSA with and ，CVE-2016-0800），也即利用过时的、弱化的一种RSA加密算法来解密破解TLS协议中被该算法加密的会话密钥。 具体说来，DROWN漏洞可以利用过时的SSLv2协议来解密与之共享相同RSA私钥的TLS协议所保护的流量。 DROWN攻击依赖于SSLv2协议的设计缺陷以及知名的攻击。

通常检查以下两点服务器的配置

(CVE-2016-2107) 1.0.1t到 1.0.2h之前没有考虑某些填充检查期间的内存分配，这允许远程攻击者通过针对AES CBC会话的-攻击来获取敏感的明文信息。

强制丢弃的算法

#0x02修复建议

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

本篇文档的目的在于如何让系统管理员或开发者用尽可能少的时间部署一个安全的 web 站点或应用，即 SSL 和 TLS 部署最佳实践。

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 前缀有关（例如，它适用于 和

）。经验法则是，安全的 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 散列函数，现在被认为是不安全的。因此配置burpsuit谷歌浏览器证书及HSTS问题处理，我们正在向 转型。截至 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
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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 套件名称。一些平台使用非标准名称; 有关详细信息，请参阅您的平台的文档。例如，以下套件名称将与 一起使用：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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 使用强的密钥交换算法

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

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

3 减轻已知问题

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

4 性能

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

4.1 避免过度安全

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

4.2 使用 恢复

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

4.3 使用 WAN 优化和 HTTP/2

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

4.4 隐藏公共内容

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

4.5 使用 OCSP

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

4.6 使用快速加密

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