javascript - 可以使用Javascript反击SSL/TLS漏洞吗？

Question

令我震惊的是，最近我发现，直到那时我一直认为确保用户完整性的安全选择的SSL / TLS协议实际上存在多个漏洞，并且存在可用的漏洞利用程序（CAs in 2009，renegotiation exploit in 2009和< aa>）。因此，似乎还存在其他几个较小的漏洞。

因此，最大的问题仍然是，该怎么办？据我了解，我上面链接的最后两个漏洞利用需要大量先前已知的信息，然后需要进行一些猜测（BEAST）或只能部分利用我的“安全”连接，因为它实际上无法解密发送的数据（重新协商） 。但是，这些方法似乎仍然非常非常具有威胁性，而且我怀疑，将黑客添加到他们的武器库中还需要很长时间。

作为一个明显的对策，我想到了在我处理的Web应用程序的其他敏感部分添加Java加密的附加层。我知道那里有一些好的加密库，因此加密本身不是问题。但是，问题是我也阅读了BEAST in 2011，并且对该方法的批评使我想知道使用Javascript的附加安全性是否可能/合理。

问题是，我认为Javascript加密无论如何都能使事情变得更安全，因为至少我链接的最后两个是中间人攻击，因此，额外的加密可能会破坏他们的攻击（而我不会完全不了解SSL / TLS协议）。

您是否认为使用Javascript添加额外的加密（到受保护的受控环境）可以消除这些威胁？

编辑：

我认为到目前为止的3个答案对我有些误解了。我非常清楚，完全破坏的SSL / TLS连接会使任何进一步的Javascript加密都无用（正如您所指出的那样-Javascript本身将受到损害并且可能会被更改）。但是，据我所知，我所提到的漏洞利用方法都没有允许攻击者立即完全破坏连接，尤其是重新协商漏洞利用。问题更多的是，是否有谁对SSL / TLS了如指掌，并且对Java脚本的加密难度很高，是否可以就Java加密是否可以抵御这两个特定漏洞的问题有所了解？

不过，我要得出的结论是，它不会增加安全性。如果有的话，因为我怀疑Java脚本本身是一种能够正确进行加密（在阅读this fine article about Javascript as a cryptographic security measure之后）的语言，主要是因为它缺乏安全的随机数生成器。然后在答案中写出的所有其他很好的理由使棺材最终钉在了这个想法上。

Answer 1

在考虑由于据说SSL / TLS已被破坏而使用JavaScript添加额外的加密层之前，您应该真正了解您提到的关于SSL / TLS的问题实际上是什么。普通出版物（您已发布的链接）中发布的信息可能是简化，误导或耸人听闻的。

证书问题

虽然这很重要，但它本身并不是SSL / TLS的漏洞。无论您设计什么新系统，都必须依靠基础架构来识别远程方。有许多用于此的模型（基于公共密钥密码学），主要是PKI（la X.509，请参见RFC 5280）和信任网络（la PGP）。

这些问题分为以下几类：


未正确检查已颁发证书的主机名（例如\0会传递给另一台主机）：这是一个实现错误。令人遗憾的是，漏洞是定期实现的，有时确实是在与安全性相关的代码中实现的。 SSL / TLS的设计不在这里。主机名验证的实现是。 （有关HTTPS或RFC 2818 section 3.1，请参见RFC 6125。）这可以通过修复库/浏览器中的错误并升级到固定版本来解决。任何协议（无论是否使用SSL / TLS）都会偶尔出现未能正确执行规范的情况。 （当然，制作X.509证书的ASN.1结构的“声明”无济于事...）
主机名可能无法在浏览器中清楚显示。 GUI是可以改进的领域，但是似乎也很难相应地教育用户。例如，已经尝试推动使用扩展验证证书（绿色条形），但这可能还会造成一些额外的混乱（并非没有从那些从EV证书中受益最大的人进行明智的营销）。
CA有时会在颁发证书时出错（或被泄露）。也许这些CA证书不应该首先放在您的浏览器中。


这些问题在这里并不是纯粹的技术问题。作为一个人，这更多地是关于如何检查您是否希望信任摆在您面前的信息（即您是否相信证书是真实的，以及您想与之交谈的服务器的信息）。

我相信这个问题没有完美的解决方案。信任是很难建模的东西。这种情况可能在任何情况下都发生，不一定与SSL / TLS或Internet相关。 （您看过您朋友的几本护照，以检查他们的名字？他们都是真实的吗？您确定吗？
在当局提供了一些虚假信息后还没有发布？）

这些实现可能并不完美，浏览器开发人员可以修复错误并改善GUI。但是，我认为没有JavaScript插件可以解决任何问题：您仍然需要类似的方法来识别远程方。有一些浏览器插件可以部分帮助您（例如，通过与证书的其他缓存副本进行比较），但是最终，选择是否信任服务器的身份是用户的责任。

（这样做的另一个缺点是，某些开发人员似乎不想过多地了解该领域：请参阅SO上的问题数量，询问如何禁用证书验证以摆脱警告消息。这也是一个人为问题，如果人们不想看到警告消息。）

重新协商利用（CVE-2009-3555）和BEAST

重新协商利用确实是一个协议错误，但这已在RFC 5746中修复。 （当时有人争辩说，它并不是纯粹的SSL / TLS错误，但它也是SSL / TLS与它所保护的应用程序协议交互方式的一个问题。如果HTTP栈已经能够收到SSL / TLS重新协商的通知，但这是一个灰色区域，并且HTTP服务器并不是真的为此设计的：太晚和/或太大的任务。）与修复有关的问题有与部署有关。同时升级每个人非常困难。鼓励人们升级到TLS的新版本（实际上是沟渠SSL）会有所帮助。

BEAST是一个问题（特定于浏览器），但是可以通过更好地配置SSL / TLS堆栈或再次升级到最新版本的SSL / TLS来解决。

在这里，似乎SSL / TLS是版本升级时停滞的受害者。当然，这比其他软件要麻烦得多，因为远程用户（可能是您从未遇到过的在线客户）也常常也必须升级其SSL / TLS版本。
我要说的是，尽管重要的是（通常出于商业目的）不排除许多无法或不会更新其浏览器/操作系统的用户，但有时服务器还是需要进行升级。
同样，不幸的是，这并非特定于SSL / TLS。任何需要支持IE6的Web开发都会遇到类似的问题（和it should be killed off...）。

再次，我非常怀疑基于JavaScript的解决方案不会遭受类似的问题（特别是浏览器兼容性和版本问题）。