TLS/SSLv3是否不安全？

玩弄F2F网络应用程序的想法，我刚刚阅读了有关安全通信的内容。 我很快就决定使用TLS/SSL作为任何通信的基础，因为它在协议级别使用公钥加密，因此非常适合我的需要。 然而，当我（在维基百科上）看到最新版本的TLS SSLv3混合使用MD5和SHA-1时，我很惊讶，“因为如果在其中一种算法中发现任何漏洞，另一种算法将阻止它危害SSLv3”。然而，正如我所认为的，最近两个都被发现有缺陷

因此，我的问题是：
这不意味着SSLv3基本上有缺陷，或者我读得不够仔细吗？

---

如果是这样，是否存在SSLv3的“安全”替代方案？

TLSv1和所有早期SSL版本中使用的PRF使用MD5和SHA1的异或。两种哈希算法都可能发生冲突。MD5碰撞更容易生成。来自维基百科2^24 MD5 vs 2^63 SHA1操作。在TLSv2中，PRF（而不是硬编码）现在可以以与早期SSL版本中的基础密码大致相同的方式进行协商。TLSv2的初始必须实现为未混合SHA2

然而，仅仅因为哈希容易受到冲突的攻击，并不一定会使它对所有应用程序都不安全

例如，单独使用易受攻击的哈希来验证文件的签名是非常危险的，因为以保持原始签名的方式更改数据是非常可行的。（通过发现碰撞）

在PRF（伪随机函数）的情况下，您要做的是基于秘密的知识提供可预测的输出，而该秘密不可能通过反向工程获得输入秘密。在这种情况下，成功搜索碰撞并不像前一种情况那样有用

查找冲突仍然应该关注哈希算法的任何使用，因为历史表明，它可以为将来发现更重要的漏洞打开大门

---

就我个人而言，TLS最让我担忧的是之前的案例，在检查根证书和中间证书之间的信任链时，MD5/SHA1通常用于签名验证。已成功证明通过产生碰撞来锻造中介体。

MD5和SHA-1中的弱点不会影响在TLS中使用MD5和SHA-1。但是，如果您发现由于使用MD5或SHA-1而导致TLS不可接受（例如，由于某种法规要求逐步淘汰MD5和SHA-1，或者您发现这不利于公共关系），则您可以进行调查，它使用类似的概念。

在进一步挖掘之后，我发现了RFC5246，它指定了TLS 1.2：有趣的是，他们似乎已经解决了这个问题，但不幸的是，它的实现似乎仍然落后：所以，有人找到了一些好的替代方案吗？Windows 7已经实现了TLS 1.2。TLS<1.2中的散列不是异或的，而是连接在一起的，因此对于每个输入，实际上得到的散列至少与两个散列中最强的散列一样强。不正确，来自RFC 2246的第5节：PRF（秘密，标签，种子）=P_MD5（S1，标签+种子）XOR P_SHA-1（S2，标签+种子）；我很想知道为什么MD5/SHA-1的弱点不适用。这适用于哪个版本？MD5和SHA-1的已知弱点是碰撞。在SSL/TLS（所有版本）中，MD5和/或SHA-1用于伪随机数生成、数字签名和完整性检查；这些用法都不会受到碰撞的影响。它们依赖于原像抵抗力（以及一些相关特性），MD5和SHA-1的抵抗力与以往一样稳定（即，目前还没有已知的弱点）。