openssl - 与我的xgf相比，OpenSSL 1.0.1e CipherSuites和TLS1.2混合信号更多

Question

我目前正在使用Windows的高安全性Web服务器上工作(我知道，如果由我决定，它将是OpenBSD)Server 2012。

在研究密码套件的选择并加快了解哪些被认为最强和什么不是最强时，我有几个问题。

据我了解，从OpenSSL 1.0.1e(或当前的TLS 1.2)开始，阻止密码(特别是AES和Camellia)的密码不再容易受到缓存定时边信道攻击。这样对吗？

知道了＃1，现在可以肯定地说CBC模式下的分组密码再次是安全的，尽管有一些已知的弱攻击向量可以稍微简化它们。

SHA1已知冲突，SHA2-256是新的最低已知安全标准，对吗？

对于所有正常意图和目的，RC4都被完全破坏了。不要使用它。这是正确的一揽子声明吗？

临时 key 是使用OpenSSL或TLS 1.2实现完美前向保密性的唯一方法，对吗？

最后是一个问题:在本轮OpenSSL更新之后，是否有数学或概率上的理由认为GCM比CBC更安全？

预先感谢大家，这是许多BS，需要通过google和wiki来进行改编，而我无法找到一个直接的最新答案。

Answer 1

抱歉，下面的格式。我将尝试按主题对它们进行分组，因此这意味着一些问题会被多次访问且无序。

It is my understanding that as of OpenSSL 1.0.1e (or current TLS 1.2) that block ciphers (specifically AES and Camellia) are no longer vulnerable to cache timing side-channel attacks.

好吧，OpenSSL使用 secret 执行分支，因此它容易受到缓存定时攻击(本地和网络)。我记得读过一篇论文，但是目前没有引用。我认为伯恩斯坦在下面引用的演讲中谈到了这一点。我知道一组密码学家对OpenSSL确实感到不满，因为该项目不会接受修补某些痛点的补丁程序。

有关此主题的平易近人的讨论，请参见Daniel Bernstein的 Cryptography's Worst Practices。

据我所知，Bernstein的 NaCl是唯一尝试删除所有旁 channel 的库。但是NaCl并不是通用的SSL/TLS库。

It is my understanding that as of OpenSSL 1.0.1e (or current TLS 1.2) that block ciphers (specifically AES and Camellia) are no longer vulnerable to cache timing side-channel attacks.

SSL/TLS使用身份验证然后加密方案(AtE)。该方案本质上是:

T = Auth(m)
C = Enc(m||t)

Send {C} to peer

由于身份验证标签已加密，因此协议(protocol)必须先解密消息，然后才能验证消息的真实性。那是Serge Vaudenay的Padding Oracles蓬勃发展的地方，而Duong和Rizzo的BEAST正是在这里使用的。这是因为在身份验证之前使用了密文。

可以使用Authenticate-then-Encrypt，但细节可能很难掌握。如果将其与对 key 流进行XOR的流密码一起使用，则通常可以。如果将其与分组密码一起使用，则必须小心。官方待遇可以在Hugo Krawczyk的 The Order of Encryption and Authentication for Protecting Communications中找到。

OpenSSL和其他库已对块密码上的最近一轮填充预告片进行了修补。

流密码实际上并不可行，因为RC4并不真正适合在TLS中使用。请参阅问题4的答案。

这就是为什么SSL/TLS在2011年左右糟糕透顶的原因。流密码和分组密码都被破坏了，我们没有很好的选择/替代选择。 (大多数人选择RC4而不是分组密码)。

由于协议(protocol)和实现方面的缺陷，您将来应该会遇到更多的侧信道攻击。

为了完整起见，这就是您想要在理想世界中使用的东西。它是IPSec使用的先加密后认证方案(EtA)。 IETF拒绝为SSL/TLS指定它，即使它在通用组成下可证明是安全的(请参阅Krawczyk的论文):

C = Enc(m)
T = Auth(C)

Send {C || T} to peer

在上述方案中，对等方拒绝任何未针对身份验证标签 C进行身份验证的密文 T。填充预告片不会显示自己，因为从未执行过解密。

现在有一个IETF草案，可以在SSL/TLS中使用Enrcypt-then-Authenticate。参见彼得·古特曼(Peter Gutmann)的 Encrypt-then-MAC for TLS and DTLS。

为了更完整，这是SSH的作用。它是一个身份验证和加密方案(A＆E)，并且在对它进行身份验证之前也使用了密文:

C = Enc(m)
T = Auth(m)

Send {C || T} to peer

由于身份验证标签已应用于纯文本消息，因此必须对密文进行解密以恢复纯文本消息。这意味着密文在通过身份验证之前已被使用。

代码项目的 Authenticated Encryption提供了程序员对身份验证加密的可处理方法。

For all normal intents and purposes RC4 is completely broken. Don't use it. Is this a correct blanket statement?

它没有完全打破，但它的偏差是TLS中的一个实际问题。来自AlFardan，Bernstein等人， On the Security of RC4 in TLS and WPA:

... While the RC4 algorithm is known to have a
variety of cryptographic weaknesses (see [26]
for an excellent survey), it has not been previously
explored how these weaknesses can be exploited
in the context of TLS. Here we show that new and
recently discovered biases in the RC4 keystream
do create serious vulnerabilities in TLS when using
RC4 as its encryption algorithm. 

Knowing #1, it is now safe to say that block ciphers in CBC mode are once again safe, even though that there are a few known weak attack vectors that simplify them slightly.

好吧，这取决于您的风险状况或逆境。知道RC4不适合在TLS中使用，只能保留分组密码。但是我们知道，使用分组密码时，OpenSSL仍会遭受侧 channel 攻击，因为它们在 secret key Material 上分支。这样你就可以挑选毒药了。

Knowing #1, it is now safe to say that block ciphers in CBC mode are once again safe, even though that there are a few known weak attack vectors that simplify them slightly.

分组密码不是唯一的向量。攻击者可以在 key 传输期间恢复AES(或山茶花) key 。参见Bleichenbacher的 “Million message attack” on RSA；和 The “Million Message Attack” in 15 000 Messages。这意味着繁忙的网站可能必须每10分钟左右更改其长期签名/加密 key 。

您还具有其他副 channel /oracle攻击，例如Duong和Rizzo对压缩的攻击。它们的攻击既针对套接字层(CRIME)也针对应用程序层(BREACH)，并且适用于HTTPS和相关协议(protocol)(如SPDY)。

SHA1 has known collisions, SHA2-256 is the new minimum known secure standard, correct?

这取决于您如何使用它以及问谁。如果将其用作随机数生成器中的伪随机函数(PRF)，则可以使用SHA1。如果在要求抗碰撞的地方(例如数字签名)使用它，则SHA1低于其280位的理论安全级别。实际上，感谢Marc Stevens(请参阅 HashClash)，我们知道它接近260。这意味着某些攻击者可能会接触到它。

对于SSL/TLS，SHA1只需具有足够长的抗碰撞能力，即可通过空中或沿电线推送SSL/TLS记录。 260可能已经足够了，因为时间长度很小-它大约与网络的2MSL有关。换句话说，攻击者可能无法在2分钟内伪造网络数据包。

另一方面，您可能需要具有SHA256的X509证书，因为与TLS记录不同，生存时间几乎是无限的。

生命周期长的X509证书上几乎无限的时间是开发 FLAME如此有效的原因。攻击者有无限时间在该Microsoft TS证书上找到MD5前缀冲突。一旦找到，便可以在有运行该服务的Microsoft盒的任何地方使用它。

SHA1 has known collisions, SHA2-256 is the new minimum known secure standard, correct?

有几家机构发布了这类最低标准，现在看来，已同意的最低安全标准是112位。因此，这意味着算法为:

DH-2048

RSA-2048

SHA-224

3键TDEA(三重DES)

AES128(或更高版本)

这些是美国常见的算法。如果需要，您还可以使用山茶花(等效于AES)和漩涡(等效于SHA)。 2键TDEA提供80位安全性，不应使用。 (3 key TDEA使用24字节 key ，而2 key 使用16字节 key 。SSL/TLS指定RFC 2246中的24字节变量)。

椭圆曲线也有大小，这也是基于素数场或二进制场特征的大小。例如，如果您想在具有112位安全性的素数字段上绘制椭圆曲线，那么我相信您会使用P-224或更高版本(或大小为233或更高的二进制字段)。

我认为可以在 Crypto++'s Security Levels上找到有关该主题的一些不错的阅读 Material 。它讨论了安全级别，并提出了ECRYPT(亚洲)，ISO/IEC(全局)，NESSIE(欧洲)和NIST(美国)之类的标准机构。

甚至国家安全局(NSA)都有最低的安全级别。用于SECRET的128位(而不是112位)和算法在其 Suite B中指定。

SHA1 has known collisions, SHA2-256 is the new minimum known secure standard, correct?

您必须小心删除SHA1。如果这样做，则可能会删除所有常见的TLSv1.0算法，这可能会影响可用性。就个人而言，我想掩埋TLSv1.0，但我认为它是互操作性所必需的，因为很少有客户端和服务器完全实现TLSv1.1和TLSv1.2。

另外，Ubuntu 12.04 LTS禁用TLSv1.1和TLSv1.2。因此，您将需要可用于TLSv1.0的最佳哈希，我相信这是SHA1。参见 Ubuntu 12.04 LTS: OpenSSL downlevel version is 1.0.0, and does not support TLS 1.2。

在这种情况下，您可能仍可以使用SHA1，但是将其向下推到首选密码列表中。

Ephemeral keys are are the only way to achieve perfect forward secrecy using OpenSSL or TLS 1.2, correct?

临时 key 交换提供完善的前向保密性(PFS)。这意味着，如果长期签名 key 遭到破坏，那么过去的 session 就不会因为失去隐私而受到威胁。也就是说，攻击者无法恢复过去 session 的纯文本。

临时 key 交换最早是在SSL 3.0中发现的。以下是您感兴趣的算法(我不使用RC4和MD变体，因为我没有使用它们):

EDH-DSS-DES-CBC3-SHA

EDH-RSA-DES-CBC3-SHA

TLS 1.0添加了以下内容:

DHE-DSS-AES256-SHA

DHE-RSA-AES256-SHA

DHE-DSS-AES128-SHA

DHE-RSA-AES128-SHA

TLS 1.1没有添加算法。

TLS 1.2添加了以下内容:

ECDHE-ECDSA-AES256-GCM-SHA384

ECDHE-RSA-AES256-GCM-SHA384

ECDHE-ECDSA-AES128-GCM-SHA256

ECDHE-RSA-AES128-GCM-SHA256

DHE-DSS-AES256-GCM-SHA384

DHE-RSA-AES256-GCM-SHA384

DHE-DSS-AES128-GCM-SHA256

DHE-RSA-AES128-GCM-SHA256

Ephemeral keys are are the only way to achieve perfect forward secrecy using OpenSSL or TLS 1.2, correct?

即使使用临时 key 交换，也有办法销毁PFS。例如， session 恢复需要保留premaster secret 。保留premaster secret 以执行 next = Hash( current)破坏该属性。

在Apache服务器场中，这也意味着将premaster secret 写入磁盘。 (我上次检查时，Apache无法将其在内存中分发到服务器场中的服务器)。

Is there a mathematical or probability reason to consider GCM safer than CBC after the current round of OpenSSL updates?

GCM是一种流模式，因此它不应遭受填充Oracle攻击。但是，有些人声称将您知道的恶魔换成您不知道的恶魔。例如，请参阅加密邮件列表上有关 Workshop on Real-World Cryptography的讨论。

相关:通过控制密码套件(例如 ECDHE-RSA-AES256-GCM-SHA384)，您可以控制算法(例如 ECDHE， RSA， AES256， SHA384)并控制协议(protocol)(例如TLSv1.2)。

在OpenSSL中，控制这些内容的过程分为三步(下面的第2步是可选的):

删除损坏/受伤的协议(protocol)。使用SSLv23_method方法，然后使用SSL_CTX_set_options调用SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3。这使您可以使用TLSv1.0及更高版本。

由于CRIME，

SSL_OP_NO_COMPRESSION也可能是一个好主意。您仍然需要注意更高级别的压缩泄漏，这是因为SPDY和HTTP等协议(protocol)的BREACH造成的。

选择您的密码套件，然后使用SSL_set_cipher_list进行设置。不要将密码套件与RC4或MD5之类的算法一起使用。下面的示例字符串也删除了RC4和SHA1(以及其他较小的密码)。

在服务器上，不允许客户端选择弱密码或受伤密码(默认情况下，根据RFC，服务器会接受客户端的选择)。禁止客户端通过告诉服务器使用SSL_CTX_set_options和SSL_OP_CIPHER_SERVER_PREFERENCE进行选择来进行选择。

设置密码列表以控制密码套件和协议(protocol)时，代码可能如下所示:

const char* const PREFERRED_CIPHERS = "kEECDH:kEDH:kRSA:AESGCM:AES256:AES128:3DES:"
                  "!MD5:!RC4:!aNULL:!eNULL:!EXP:!LOW:!MEDIUM:!ADH:!AECDH";

int res = SSL_set_cipher_list(ssl, PREFERRED_CIPHERS);
if(1 != res) handleFailure();

这是设置密码列表的另一种方法:

const char* const PREFERRED_CIPHERS =

  /* TLS 1.2 only */
  "ECDHE-ECDSA-AES256-GCM-SHA384:"
  "ECDHE-RSA-AES256-GCM-SHA384:"
  "ECDHE-ECDSA-AES128-GCM-SHA256:"
  "ECDHE-RSA-AES128-GCM-SHA256:"

  /* TLS 1.2 only */
  "DHE-DSS-AES256-GCM-SHA384:"
  "DHE-RSA-AES256-GCM-SHA384:"
  "DHE-DSS-AES128-GCM-SHA256:"
  "DHE-RSA-AES128-GCM-SHA256:"

  /* TLS 1.0 and above */
  "DHE-DSS-AES256-SHA:"
  "DHE-RSA-AES256-SHA:"
  "DHE-DSS-AES128-SHA:"
  "DHE-RSA-AES128-SHA:"

  /* SSL 3.0 and TLS 1.0 */
  "EDH-DSS-DES-CBC3-SHA:"
  "EDH-RSA-DES-CBC3-SHA:"
  "DH-DSS-DES-CBC3-SHA:"
  "DH-RSA-DES-CBC3-SHA";

相关:根据下面的Steffen，F5 BIG-IP负载均衡器存在一个错误，即它们拒绝太大的 ClientHello。这是限制公布为受支持的密码套件数量的另一个原因，因为每个密码套件都需要两个字节。因此，您可以将密码套件所需的大小从160个字节(每个密码套件80个)减少到大约30个字节(约15个密码套件)。

下面是在Wireshark下跟踪 ClientHello的 openssl s_client -connect www.google.com:443。注意79个密码套件。



相关消息:苹果的TLSv1.2代码存在一个错误，其中Safari无法像所宣传的那样协商ECDHE-ECDSA密码。该错误存在于OS X 10.8至10.8.3中，据称已在OS X 10.8.4中修复。 Apple没有提供修补程序，也没有将修补程序应用于其 SecureTransport的受影响版本，因此10.8至10.8.3仍将不起作用。而且某些版本的iOS可能会被破坏。

确保使用OpenSSL的 SSL_OP_SAFARI_ECDHE_ECDSA_BUG作为上下文选项。有关详细信息，请参见 SSL_OP_SAFARI_ECDHE_ECDSA_BUG和 Apple are, apparently, dicks...。

相关:OpenSSL和椭圆曲线在细节上还有另一个魔鬼。当前，在使用OpenSSL 1.0.1e时无法指定字段。因此，在协商AES256密码(256位安全性)时，您可能会遇到一条弱曲线(例如具有80位安全性的P-160)。显然，您的攻击者将遵循弱曲线而不是强分组密码。这就是匹配安全级别很重要的原因。

如果要注意安全级别，则必须在1690行周围打补丁OpenSSL的 t1_lib.c，以确保 pref_list不包括较弱的曲线。

OpenSSL 1.0.2将允许您设置椭圆曲线的大小。参见 SSL_CTX_set1_curves。

相关: PSK是预共享 key ，而 SRP是安全远程密码。我看到很多人都将 PSK和 SRP删除为错误的密码(例如，首选密码包括“!PSK:!SRP”)。实际上，通常不需要它们，因为没有人使用它们，但是它们也像 RC4或 MD5一样不错。实际上，它们是首选的，因为它们具有所需的安全性。

对于使用密码或共享 secret 的应用程序，最需要 PSK和 SRP。它们是最可取的，因为它们提供了客户端和服务器的相互身份验证，并且不会遭受中间人拦截。也就是说，客户端和服务器都知道密码和 channel 设置成功，或者一个(或两者)都不知道密码或 key 而 channel 设置失败。他们不会以纯文本形式将用户名或密码放在网络上，因此恶意服务器或对手在攻击过程中一无所获。
PSK和 SRP具有“ channel 绑定(bind)”属性，这是重要的安全属性。在传统的基于RSA的SSL/TLS中，设置了安全 channel ，然后在不相交的步骤中将用户密码压入线路。如果客户端出错，并与恶意服务器建立了 channel ，则将用户名和密码提供给恶意服务器。在这种情况下，身份验证机制与下一层的工作是脱节的或“未绑定(bind)的”。 PSK和 SRP不会遇到未绑定(bind)的 channel ，因为绑定(bind)内置在协议(protocol)中。