OpenSSL 1.0.1e CipherSuites和TLS1.2混合信号比我的xgf更多

Question

我目前正在开发一个使用Windows的高安全性Web服务器(我知道,如果它取决于我,那将是OpenBSD)Server 2012.

在查看密码套件的选择并快速了解被认为最强大和不强的东西时,我有几个问题.

1. 我的理解是,从OpenSSL 1.0.1e(或当前的TLS 1.2)开始,阻塞密码(特别是AES和Camellia)不再容易受到缓存时序旁路攻击的攻击.它是否正确？

2. 知道#1,现在可以肯定地说CBC模式下的分组密码再次是安全的,即使有一些已知的弱攻击向量可以略微简化它们.

3. SHA1已知已知冲突,SHA2-256是新的最小已知安全标准,对吗？

4. 对于所有正常意图和目的,RC4完全被打破.不要使用它.这是正确的一揽子声明吗？

5. 短暂的密钥是使用OpenSSL或TLS 1.2实现完美前向保密的唯一方法,对吗？

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

在此先感谢大家,这是很多BS通过谷歌和维基洗牌,我无法找到一个直接的,最新的答案.

Answer 1

对于以下格式抱歉.我将尝试按主题对它们进行分组,这意味着有些问题会被多次访问并且无序.

我的理解是,从OpenSSL 1.0.1e(或当前的TLS 1.2)开始,阻塞密码(特别是AES和Camellia)不再容易受到缓存时序旁路攻击的攻击.

好吧,OpenSSL使用秘密执行分支,因此容易受到缓存定时攻击(本地和网络)的影响.我记得读过一篇论文,但我现在没有参考.我认为伯恩斯坦在下面的引言中谈到了这一点.我知道有一组密码学家对OpenSSL非常不满,因为该项目不会接受补丁来修复一些痛处.

关于这个主题的平易近人的谈话,请参阅丹尼尔伯恩斯坦的密码学最差实践.

据我所知,伯恩斯坦的NaCl是唯一试图移除所有侧通道的库.但NaCl不是通用的SSL/TLS库.

我的理解是,从OpenSSL 1.0.1e(或当前的TLS 1.2)开始,阻塞密码(特别是AES和Camellia)不再容易受到缓存时序旁路攻击的攻击.

SSL/TLS使用Authenticate-then-Encrypt方案(AtE).该计划基本上是:

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

Send {C} to peer

由于身份验证标记已加密,因此协议必须先解密消息,然后才能验证消息的真实性.这就是Serge Vaudenay的Padding Oracles蓬勃发展的地方,而这正是Duong和Rizzo的BEAST所使用的.这是因为在进行身份验证之前正在使用密文.

可以使用Authenticate-then-Encrypt,但细节可能很难实现.如果它与一个对密钥流进行异或的流密码一起使用,那么它通常是正常的.如果它与分组密码一起使用,那么你必须要小心.官方处理可以在Hugo Krawczyk的"保护通信的加密和认证顺序"中找到.

OpenSSL和其他库已经修补了最近一轮的分组密码填充oracles.

流密码并不可行,因为RC4并不适合在TLS中使用.请参阅问题4的答案.

这就是2011年左右SSL/TLS糟透了的原因.流密码和分组密码都被破坏了,我们没有很好的选择/替代使用.(大多数人选择RC4而不是分组密码).

由于协议所存在的体系结构缺陷和实现缺陷,您应该期待更多的侧通道攻击.

为了完整起见,这是您想要在理想世界中使用的内容.它是IPSec使用的Encrypt-then-Authenticate方案(EtA).IETF拒绝为SSL/TLS指定它,即使它在通用组合下可证明是安全的(参见Krawczyk的论文):

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

Send {C || T} to peer

在上述方案中,对等体拒绝任何C未对认证标签进行认证的密文T.填充oracle不会显示自己,因为从未执行解密.

现在有一个IETF草案在SSL/TLS中使用Enrcypt-then-Authenticate.有关TLS和DTLS,请参阅Peter Gutmann的Encrypt-then-MAC.

为了更完整,这是SSH所做的.它是一个Authenticate-and-Encrypt方案(A&E),它在验证之前使用密文:

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

Send {C || T} to peer

由于身份验证标记应用于纯文本邮件,因此必须解密密文才能恢复纯文本邮件.这意味着密码文本在经过身份验证之前正在使用.

Code Project的Authenticated Encryption提供程序员可接受的经过身份验证的加密处理.

对于所有正常意图和目的,RC4完全被打破.不要使用它.这是正确的一揽子声明吗？

它没有完全破碎,但它的偏差是TLS中的一个真正问题.来自AlFardan,Bernstein(等),关于TLS和WPA中RC4的安全性:

... 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. 

知道#1,现在可以肯定地说CBC模式下的分组密码再次是安全的,即使有一些已知的弱攻击向量可以略微简化它们.

嗯,这是你的风险姿势或逆境问题.如果您知道RC4不适合在TLS中使用,那么只会留下分组密码.但是我们知道OpenSSL在使用分组密码时仍然会遭受旁道攻击,因为它们分支在密钥密钥材料上.所以你可以选择你的毒药.

知道#1,现在可以肯定地说CBC模式下的分组密码再次是安全的,即使有一些已知的弱攻击向量可以略微简化它们.

分组密码不是唯一的向量.攻击者可以在密钥传输期间恢复AES(或Camellia)密钥.参见Bleichenbacher 对RSA的"百万消息攻击" ; 和15000条消息中的"百万消息攻击".这意味着繁忙的网站可能每10分钟左右更改一次长期签名/加密密钥.

你还有其他的通道/甲骨文攻击,比如Duong和Rizzo对压缩的攻击.它们的攻击针对套接字层(CRIME)和应用层(BREACH),并适用于HTTPS和SPDY等相关协议.

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

这取决于你如何使用它以及你问谁.如果您在随机数生成器中将其用作伪随机函数(PRF),则可以使用SHA1.如果您在需要抗冲击性的地方使用它,例如数字签名,则SHA1低于其理论安全级别2 ^80位.事实上,由于Marc Stevens(见HashClash),我们知道它接近2 ⁶⁰.这意味着它可能会受到一些攻击者的影响.

对于SSL/TLS,SHA1只需要足够长的抗冲突性,以便通过空中或线路推送SSL/TLS记录.因为时间长度很短 - 它大约是网络的2MSL,所以2 ⁶⁰可能已经足够了.换句话说,攻击者可能无法在2分钟内伪造网络数据包.

另一方面,您可能需要使用SHA256的X509证书,因为与TLS记录不同,生存时间几乎无限制.

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

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

有一些机构发布了这些最低标准,112位安全性似乎是现在约定的最低限度.这意味着算法是:

• DH-2048
• RSA-2048
• SHA-224
• 3键TDEA(三重DES)
• AES128(或以上)

这些是常见的美国算法.如果需要,您还可以使用Camellia(AES等效)和Whirlpool(SHA等效).双密钥TDEA提供80位安全性,不应使用.(3键TDEA使用24字节密钥,2键使用16字节密钥.SSL/TLS指定RFC 2246中的24字节变量).

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

我认为在Crypto ++的安全级别上可以找到关于这个主题的一些好的阅读.它讨论了安全级别,并召集了ECRYPT(亚洲),ISO/IEC(全球),NESSIE(欧洲)和NIST(美国)等标准机构.

甚至NSA也具有最低安全级别.它的128位(而不是112位)用于SECRET,算法在其Suite B中指定.

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

删除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下层版本是1.0.0,并且不支持TLS 1.2.

在这种情况下,您可能仍然可以使用SHA1,但将其下推到首选密码列表中.

短暂的密钥是使用OpenSSL或TLS 1.2实现完美前向保密的唯一方法,对吗？

短暂的密钥交换提供完美的前向保密(PFS).这意味着如果长期签名密钥被泄露,那么过去的会话不会因为失去隐私而受到威胁.也就是说,攻击者无法恢复过去会话的纯文本.

短暂的密钥交换在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

短暂的密钥是使用OpenSSL或TLS 1.2实现完美前向保密的唯一方法,对吗？

即使是短暂的密钥交换,也有办法摧毁PFS.例如,会话恢复需要保留预主密钥.保留premaster秘密来执行next = Hash( current)某种破坏财产的行为.

在Apache服务器场中,这也意味着将premaster机密写入磁盘.(我上次检查时,Apache没有办法将内存分发到服务器场中的服务器).

在本轮OpenSSL更新后,是否有数学或概率理由认为GCM比CBC更安全？

GCM是一种流模式,所以它不应该遭受填充oracle攻击.然而,有些人声称他们为你不认识的魔鬼交易了你知道的魔鬼.例如,请参阅密码邮件列表中关于真实世界密码学研讨会的讨论.

相关:通过控制加密套件(例如,ECDHE-RSA-AES256-GCM-SHA384),则可以控制算法(例如,ECDHE,RSA,AES256,SHA384)和控制协议(例如,TLSv1.2工作).

在OpenSSL中,它是一个控制这些事情的三步过程(步骤2在下面是可选的):

1. 删除损坏/受伤的协议.使用该SSLv23_method方法,然后SSL_CTX_set_options使用SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3.这会让你TLSv1.0及以上.
2. SSL_OP_NO_COMPRESSION由于CRIME,也可能是一个好主意.由于BREACH等协议(如SPDY和HTTP),您仍然需要注意更高层的压缩泄漏.
3. 选择您的密码套件,然后使用它们进行设置SSL_set_cipher_list.不要将密码套件与RC4或MD5等算法一起使用.样本串是低于还除去RC4和SHA1(和其他较小的密码).
4. 在服务器上,不允许客户端选择弱密码或受损密码(默认情况下,根据RFC,服务器尊重客户端的选择).不允许客户端通过告诉服务器使用SSL_CTX_set_options和进行选择来进行选择SSL_OP_CIPHER_SERVER_PREFERENCE.

以下是设置密码列表以控制密码套件和协议时代码的外观:

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个密码套件.

相关:Apple在其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和苹果都显然,迪克斯...了解详情.

相关:OpenSSL和椭圆曲线的细节还有另外一个恶魔.目前,使用OpenSSL 1.0.1e时无法指定字段.因此,在协商AES256密码(256位安全性)时,您最终可能会得到一条弱曲线(比如P-160,具有80位安全性).显然,你的攻击者会追逐弱曲线而不是强块密码.这就是为什么它与安全级别相匹配的重要性.

如果您想要注意安全级别,则必须t1_lib.c在第1690行附近修补OpenSSL,以确保pref_list不包括较弱的曲线.

OpenSSL 1.0.2允许您设置椭圆曲线大小.请参阅SSL_CTX_set1_curves.

相关:PSK是预共享密钥,SRP是安全远程密码.我看到很多人删除PSK并且SRP作为坏密码(例如,首选密码包括"!PSK:!SRP").实际上它们通常是不需要的,因为没有人使用它们,但它们并不像是RC4或者坏MD5.它们实际上是首选,因为它们具有理想的安全属性

PSK并且SRP是使用密码或共享机密的应用程序最需要的.它们是最理想的,因为它们提供客户端和服务器的相互身份验证,并且它们不会遭受中间人拦截.也就是说,客户端和服务器都知道密码和通道设置成功,或者一个(或两个)不知道密码或秘密和通道设置失败.他们不会在纯文本中将用户名或密码放在网上,因此恶意服务器或攻击者在攻击期间什么也得不到.

PSK并SRP具有"渠道约束"的属性,这是一个重要的安全属性.在经典的基于RSA的SSL/TLS中,设置安全通道,然后在不相交的步骤中按下线路上的用户密码.如果客户端出错并使用流氓服务器建立通道,则会将用户名和密码提供给流氓服务器.在这种情况下,认证机制是一个不相交的步骤或"未绑定"到下面的层的工作.PSK并且SRP不会受到未绑定的通道,因为绑定已内置到协议中.