对不起下面的格式。我将尝试按主题对它们进行分组，因此这意味着某些问题会被多次访问且无序。
据我了解，从 OpenSSL 1.0.1e（或当前的 TLS 1.2）开始，阻止密码（特别是 AES 和 Camellia）不再容易受到缓存定时侧信道攻击。
好吧，OpenSSL 使用秘密执行分支，因此它容易受到缓存定时攻击（本地和网络）。我记得读过一篇关于它的论文，但我目前没有参考资料。我认为伯恩斯坦在下面引用的演讲中谈到了这一点。我知道一组密码学家对 OpenSSL 非常不满，因为该项目不会接受补丁来修复一些痛点。
有关该主题的平易近人的演讲，请参阅 Daniel Bernstein 的Cryptography's Worst Practices。
据我所知，Bernstein 的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 的The Order of Encryption and Authentication for Protecting Communications中找到。
OpenSSL 和其他库已经修补了最近一轮关于分组密码的填充预言。
流密码实际上并不可行，因为 RC4 并不真正适合在 TLS 中使用。请参阅问题 4 的答案。
这就是为什么 SSL/TLS 在 2011 年左右如此糟糕的原因。流密码和分组密码都被破解了，我们没有好的选择/替代方案可以使用。（大多数人选择 RC4 而不是分组密码）。
由于协议存在的架构缺陷和实现缺陷，您应该预计未来会有更多的旁道攻击。
为了完整起见，这是您希望在理想世界中使用的内容。它是 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 和 DTLS。
为了更完整，这就是 SSH 的作用。它是一种身份验证和加密方案 (A&E)，并且在对其进行身份验证之前也使用密文：
C = Enc(m)
T = Auth(m)
Send {C || T} to peer
由于认证标签被应用于明文消息，因此必须对密文进行解密才能恢复明文消息。这意味着密文在经过身份验证之前就被使用了。
Code Project 的Authenticated Encryption中提供了一种程序员对认证加密的平易近人的处理方式。
对于所有正常的意图和目的，RC4 完全被破坏了。不要使用它。这是一个正确的一揽子陈述吗？
它并没有完全崩溃，但它的偏见是 TLS 中的一个真正问题。来自 AlFardan, Bernstein (et al), 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.
知道 #1，现在可以肯定地说 CBC 模式下的分组密码再次是安全的，尽管有一些已知的弱攻击向量可以稍微简化它们。
好吧，这取决于您的风险状况或逆境。鉴于您知道 RC4 不适合在 TLS 中使用，它只会留下分组密码。但是我们知道 OpenSSL 在使用分组密码时仍然会遭受侧信道攻击，因为它们在密钥材料上分支。所以你可以选择你的毒药。
知道 #1，现在可以肯定地说 CBC 模式下的分组密码再次是安全的，尽管有一些已知的弱攻击向量可以稍微简化它们。
分组密码不是唯一的向量。攻击者可以在密钥传输过程中恢复 AES（或 Camellia）密钥。参见 Bleichenbacher对 RSA 的“百万消息攻击”；以及15 000 条消息中的“百万消息攻击”。这意味着一个繁忙的网站可能必须每 10 分钟左右更改一次其长期签名/加密密钥。
您还有其他侧通道/预言机攻击，例如 Duong 和 Rizzo 对压缩的攻击。他们的攻击同时针对套接字层 (CRIME) 和应用层 (BREACH)，并适用于 HTTPS 和 SPDY 等相关协议。
SHA1 有已知的冲突，SHA2-256 是新的最低已知安全标准，对吗？
这取决于你如何使用它以及你问谁。如果您在随机数生成器中将其用作伪随机函数 (PRF)，则可以使用 SHA1。如果您在需要抗碰撞性的地方使用它，例如数字签名，则 SHA1 低于其 2 80位的理论安全级别。事实上，多亏了 Marc Stevens ，我们知道它接近 2 60 （参见HashClash）。这意味着它可能在一些攻击者的范围内。
对于 SSL/TLS，SHA1 只需要足够长的时间抗冲突，以通过无线或有线方式推送 SSL/TLS 记录。2 60可能就足够了，因为时间长度很短——大约是网络的 2MSL。换句话说，攻击者可能无法在 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）。2-key TDEA 提供 80 位的安全性，不应使用。（3-key TDEA 使用 24 字节的密钥，2-key 使用 16 字节的密钥。SSL/TLS 在 RFC 2246 中指定了 24 字节的种类）。
椭圆曲线也有大小，也基于素数场或二元场特征的大小。例如，如果您想要一个具有 112 位安全性的素数域上的椭圆曲线，那么我相信您会使用 P-224 或更高版本（或大小为 233 或更大的二进制域）。
我认为可以在Crypto++ 的 Security Levels中找到有关该主题的一些好读物。它讨论了安全级别，并提到了 ECRYPT（亚洲）、ISO/IEC（全球）、NESSIE（欧洲）和 NIST（美国）等标准机构。
甚至美国国家安全局也有最低安全级别。它的 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 secret。保留 premaster 机密以执行next = Hash( current)某种破坏该属性。
在 Apache 服务器场中，这也意味着将 premaster secret 写入磁盘。（我上次检查时，Apache 没有办法将它在内存中分发到场中的服务器）。
在当前一轮 OpenSSL 更新之后，是否有数学或概率理由认为 GCM 比 CBC 更安全？
GCM 是一种流模式，所以它不应该遭受 padding oracle 攻击。然而，有些人声称它用你认识的魔鬼换你不认识的魔鬼。例如，参见密码学邮件列表上关于真实世界密码学研讨会的讨论。
相关：通过控制密码套件（例如ECDHE-RSA-AES256-GCM-SHA384），您可以控制算法（例如 、ECDHE、RSA、AES256）SHA384和控制协议（例如 TLSv1.2）。
在 OpenSSL 中，控制这些事情的三个步骤（下面的第 2 步是可选的）：
- 删除损坏/受伤的协议。使用该
SSLv23_method方法，然后调用SSL_CTX_set_optionswith SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3。这将为您提供 TLSv1.0 及更高版本。
SSL_OP_NO_COMPRESSION由于犯罪，这也可能是一个好主意。由于 SPDY 和 HTTP 等协议的 BREACH，您仍然需要注意更高层的压缩泄漏。- 选择您的密码套件，然后使用
SSL_set_cipher_list. 不要将密码套件与 RC4 或 MD5 等算法一起使用。下面的示例字符串也删除了RC4和SHA1（以及其他较小的密码）。
- 在服务器上，不允许客户端选择弱或受伤的密码（默认情况下，根据 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. 并且某些版本的 iOS 可能会被破坏。
请务必使用 OpenSSLSSL_OP_SAFARI_ECDHE_ECDSA_BUG作为上下文选项。有关详细信息，请参阅SSL_OP_SAFARI_ECDHE_ECDSA_BUG和Apple 显然是笨蛋……。
相关：OpenSSL 和椭圆曲线的细节还有另一个问题。目前，您无法在使用 OpenSSL 1.0.1e 时指定字段。因此，在协商 AES256 密码（256 位安全性）时，您最终可能会得到一条较弱的曲线（例如具有 80 位安全性的 P-160）。显然，您的攻击者将使用弱曲线而不是强分组密码。这就是为什么匹配安全级别很重要的原因。
如果您想注意安全级别，则必须t1_lib.c在 1690 行附近修补 OpenSSL，以确保pref_list不包括较弱的曲线。
OpenSSL 1.0.2 将允许您设置椭圆曲线大小。请参阅SSL_CTX_set1_curves。
相关：PSK是预共享密钥和SRP安全远程密码。我看到很多人删除PSK了SRP错误的密码（例如，首选密码包括“！PSK：！SRP”）。实际上，它们通常是不需要的，因为没有人使用它们，但它们也不错，例如RC4or MD5。它们实际上是首选，因为它们具有理想的安全特性。
PSK并且SRP是使用密码或共享机密的应用程序最需要的。它们是最理想的，因为它们提供客户端和服务器的相互身份验证，并且它们不会遭受中间人拦截。也就是说，客户端和服务器都知道密码并且通道设置成功，或者其中一个（或两者）不知道密码或秘密并且通道设置失败。他们不会将用户名或密码以纯文本形式放在网络上，因此流氓服务器或攻击者在攻击期间一无所获。
PSK并且SRP具有“通道绑定”的属性，这是一个重要的安全属性。在经典的基于 RSA 的 SSL/TLS 中，会设置一个安全通道，然后在一个不相交的步骤中将用户密码向下推送。如果客户端出错并与流氓服务器建立通道，则将用户名和密码提供给流氓服务器。在这种情况下，身份验证机制是一个不相交的步骤或“不受约束”到下面层的工作。PSK并且SRP不要遭受未绑定的通道，因为绑定是内置在协议中的。