OpenSSL 1.0.1e密码套件和TLS1.2的混合信号比我的xgf多

我目前正在使用Windows（我知道，如果由我决定，它将是OpenBSD）server 2012开发一个高安全性的web服务器

在查看密码套件的选择并了解哪些是最强大的，哪些不是，我有几个问题

据我所知，从OpenSSL 1.0.1e（或当前的TLS 1.2）开始，块密码（特别是AES和Camellia）不再容易受到缓存定时侧通道攻击。这是正确的吗

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

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

出于所有正常意图和目的，RC4被完全破坏。不要用它。这是一个正确的总括声明吗

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

最后一个问题：在当前OpenSSL更新之后，有没有考虑GCM比CBC更安全的数学或概率原因？

---

提前感谢各位，通过谷歌和维基，这是一大堆的废话，我找不到一个直接的、最新的答案。

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

---

据我所知，从OpenSSL 1.0.1e（或当前的TLS 1.2）开始，块密码（特别是AES和Camellia）不再容易受到缓存定时侧通道攻击

OpenSSL使用秘密执行分支，因此它容易受到缓存定时攻击（本地和网络）。我记得读过一篇关于它的论文，但我现在没有参考资料。我认为伯恩斯坦在下面引用的演讲中谈到了这一点。我知道有一组密码学家对OpenSSL非常不满，因为该项目不会接受修补程序来修复一些痛处

关于这个话题的平易近人的演讲，请看丹尼尔·伯恩斯坦的

据我所知，Bernstein's是唯一一个尝试删除所有侧边通道的库。但是NaCl不是一个通用的SSL/TLS库

---

据我所知，从OpenSSL 1.0.1e（或当前的TLS 1.2）开始，块密码（特别是AES和Camellia）不再容易受到缓存定时侧通道攻击

SSL/TLS使用先验证后加密方案（AtE）。该计划基本上是：

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

Send {C} to peer

由于身份验证标记是加密的，因此协议必须先解密消息，然后才能验证消息的真实性。这就是Serge Vaudenay的填充神谕繁荣的地方，这就是Duong和Rizzo的野兽所使用的。这是因为密码文本在经过身份验证之前正在使用

可以先使用身份验证，然后再进行加密，但细节可能很难掌握。如果它与XOR密钥流的流密码一起使用，那么它通常是OK的。如果它与分组密码一起使用，那么您必须小心。官方的治疗可以在雨果·克劳茨克的诊所找到

OpenSSL和其他库修补了最近一轮的块密码填充预言

流密码并不真正可行，因为RC4并不真正适合在TLS中使用。见问题4的答案

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

由于协议的体系结构缺陷和实现缺陷，您应该预计将来会有更多的侧通道攻击

---

为了完整起见，以下是您希望在理想世界中使用的内容。它是IPSec使用的先加密后认证方案（EtA）。IETF拒绝为SSL/TLS指定它，即使它在通用组合下是可证明安全的（参见Krawczyk的论文）：

在上述方案中，对等方拒绝任何未针对认证标签

T

进行认证的密码文本

C

。填充oracle不会显示自己，因为从未执行解密

现在有一个IETF草案使用Enrcypt，然后在SSL/TLS中进行身份验证。看彼得·古特曼的

为了更完整，下面是SSH的功能。它是一个身份验证和加密方案（A&E），在进行身份验证之前也会使用密文：

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

Send {C || T} to peer

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

在代码项目中，可以使用程序员可接近的身份验证加密处理

---

出于所有正常意图和目的，RC4被完全破坏。不要用它。这是一个正确的总括声明吗

它并没有完全被打破，但它的偏见在TLS中是一个真正的问题。来自AlFardan，Bernstein（等人），：

---

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

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

---

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

分组密码并不是唯一的向量。攻击者可以恢复AES（或

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

Send {C || T} to peer

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

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";