JavaScript代码签名

使用现代主流浏览器之一的用户，怎么知道他正在运行我未经修改的javascript代码，即使是在不受信任的网络上

以下是有关我的情况的更多信息：

我有一个处理私人信息的web应用程序。 登录过程是JavaScript中的一个实现。基本上，在登录期间，客户端和服务器之间会建立一个共享密钥。用户登录后，使用共享密钥对与服务器的所有通信进行加密。系统必须能够安全抵御主动中间人攻击。 假设我的实现是正确的，并且用户足够聪明，不会成为网络钓鱼攻击的受害者，那么系统中只剩下一个大漏洞：攻击者可以在下载我的应用程序时篡改它，并注入窃取密码的代码。基本上，整个系统依赖于这样一个事实，即用户可以信任其机器上运行的代码。

---

我想要类似于已签名小程序的东西，但如果可能的话，我更喜欢纯javascript解决方案。

您可以拥有一个外部javascript文件，该文件接受登录JS的MD5哈希，并向服务器发送一个Ajax请求，以验证其正确性和最新性。在这里使用基本的安全或加密实践-公钥/私钥或其他一些方法来确保响应来自您的服务器

---

然后，您可以自信地向用户显示客户端脚本已验证，并允许登录脚本继续运行。

也许我误解了您的问题，但我的第一个想法是使用SSL。它的设计目的是确保您正在与您认为自己是的服务器交谈，并且没有人在中途修改内容。在这种情况下，由于SSL的性质，您甚至不必信任网络

---

这种方法的好处是，您可以相当轻松地将其放入现有的web应用程序中。在大多数情况下，您基本上可以将HTTP服务器配置为使用SSL，并将您的

HTTP://

请求更改为

https://

这是一个古老的开放性问题，但答案似乎并不公平

https://提供了完整性，非真实身份验证或不可抵赖性

我指示你

不要在JS中进行加密，因为恶意注入的脚本很容易获取密码或更改库。SJCL很整洁，但它提供了一种明显错误的安全感（他们的引用，上面引用）

不幸的是，这并不像桌面应用程序那样好 因为完全针对代码进行保护是不可行的 注入、恶意服务器和侧通道攻击

长期的问题是JavaScript缺少：

均匀工作常数

使物体非常恒定而不可指责的能力

代码签名

//代码签名：证书：（十六进制指纹）签名：（十六进制MAC）

证书的管理类似于CA证书。MAC将与适当的签名/验证结构一起使用

加密、剪贴板之类的东西是使用JavaScript本机插件（当然是签名的）的原因

---

让JavaScript引擎都实现一个标准是另一回事，但这是可行的，而且终结大量恶意软件是绝对必要的。

哇，你已经实现了吗？重新发明轮子的方法。不是重新发明轮子，而是重新实现轮子。也许你还没有注意到，但是有很多不同类型的轮子。你如何保护你的密钥交换免受MITM攻击？显然，您似乎不了解SSL如何容易受到MITM攻击，并且您已经提出了一个更容易受到攻击的实现。我在最初的问题中提到了它，我使用了一个经过密码验证的密钥交换方案。我认为stack overflow是回答问题，而不是质疑提问者的动机。我想知道的是，如果有人有过分发可信javascript的经验，我知道Netscape 4有解决方案（但几乎没有人再使用了），Firefox也有解决方案。我对其他浏览器或其他跨浏览器解决方案感兴趣。在经过密码验证的密钥交换（如J-PAKE或SRP）中，密码永远不会离开客户端，但这正是客户端需要确保它正在运行我的代码的原因。如果他没有运行我的代码，所有的赌注都没有了。我可以告诉每个客户将登录页面保存在磁盘上（它是一个静态html文件），或者我可以用登录页面创建一个bookmarklet（或者至少是引导登录过程的东西）但如果可能的话，我希望避免这种情况。我不确定我是否理解您的解决方案，但我认为这将改变对验证脚本的信任。我编写这个系统的全部原因是为了避免SSL，无论是出于性能还是安全方面的原因。@Toni:TLS/SSL是处理这个特定问题的行业标准，这是有原因的。它以相对较低的成本提供非常高的安全性。当然，使用SSL会对性能造成影响，但这还不足以证明推出自己的基于Javascript的解决方案是合理的。无论您提出了什么Javascript解决方案，您都将很难防止DNS欺骗破坏整个系统。如果行业标准如此安全，为什么会有这么多安全问题？在走这条路线之前，我已经非常仔细地研究了替代方案，即使TLS比我的定制系统更安全，但它缺少我的应用程序所需的控制。尽管如此，我还是很感激你的建议。@Toni:你能列举一些你正在谈论的安全问题吗？SSL的大多数问题都是由于密钥长度短得离谱或浏览器安全漏洞造成的，而这些都不是SSL本身的问题。基础协议是退出