浏览器加密问题

信息安全 网页浏览器
2021-09-07 09:48:07

有很多较早的文章1关于为什么浏览器内加密是一个坏主意。大多数总结通过：http ://bitwiseshiftleft.github.io/sjcl/

我们相信 SJCL 提供了 Javascript 中实际可用的最佳安全性。（不幸的是[原文如此]，这不如桌面应用程序那么好，因为完全防止代码注入、恶意服务器和侧信道攻击是不可行的。）

他们提到的最大问题似乎是攻击者可能会为您提供浏览器执行的糟糕 javascript，因为 XSS 非常普遍。

在 TLS 和极其严格的内容安全策略之间，这仍然是一个问题，因此浏览器内加密是一个坏主意吗？

加密的目标不是取代 TLS。它用于在文档到达服务器之前对其进行加密，因此只有发件人和收件人才能阅读它们。

1：

1个回答

我一直希望有人会问这个话题，我一直在这个领域做很多研究。

您是正确的，javascript-cryptography-considered-harmful 中的大多数点都已被较新的浏览器过时。除了有人破坏服务器的明显问题（这是一个单独的问题并且也给 TLS 带来问题）之外，要点现在“修复”了：

  • window.crypto.getRandomValues() 使用真正的 CSPRNG
  • HTTPS 现在很常见，而且比 2011 年便宜得多
  • CSPintegrity和nonce <script>属性可以确保脚本交付的安全，以确保正在运行的内容是预期的
  • SJCL 比 2011 年成熟了很多年，没有重大问题突出
  • 如果您没有 XSS，可延展的运行时并不重要，CSP 现在擅长阻止

此外，我们现在知道 HTTPS 不是隐私的绝对保证（snowden/heartbleed/crime/breach/etc），但适当的端到端加密是。我们现在还可以实现相当健壮、经过实战考验和安全的库，由比 2011 年提供的更安全的 JS 运行时提供支持；"use strict"广泛支持，CSPRNG，二进制结构，具有密封运行时环境的网络工作者等。

这些是对要点的更新，但是如果您对客户端密码学的其他方面有疑虑，我很乐意解决它们。

当然，没有什么是完美的：

  • 真正的旧浏览器仍然存在问题或无法安全地运行新代码
  • 用户添加的扩展可以运行他们想要的任何代码
  • 恶意软件可以用险恶的东西替换整个浏览器，或者窃取数据预加密
  • 网络钓鱼可以诱使用户使用除您的安全站点之外的其他内容。

简而言之，我认为在斯诺登之后，我们应该尽量将普通的私人数据保留在服务器之外，只要我们能提供帮助，并且正确的端到端加密，可以极大地增强用户的隐私和内容的安全性.

其它你可能感兴趣的问题
上一篇像 NSA 这样的人可以使用 Let's Encrypt 来有效地破坏 SSL/TLS 吗？ 下一篇Cache Bank 冲突和 CacheBleed：有什么可担心的？