防止对非 HTTPS 的中间人攻击答案

【问题标题】：Preventing Man-in-the-middle attacks on non-HTTPS防止对非 HTTPS 的中间人攻击
【发布时间】：2012-04-07 17:13:38
【问题描述】：

有什么方法可以防止或检测基于普通 HTTP 的中间人攻击？

我想在客户端机器上运行一个 JavaScript 小程序，确信代码没有被修改。是否有任何巧妙的技巧来签署代码或安全地交付代码，而无需走通常的 HTTPS 和证书路线？

【问题讨论】：

只是好奇 - 你为什么不使用 https？
您永远不应该依赖 javascript 来确保安全。如果有人可以修改您的 html，那么可以修改您的 javascript。
只是好奇是否可能。
我，一方面，期待量子密码学的时代，当我们回到这个问题并说，“是的，现在有可能。”

标签： security http https man-in-the-middle

【解决方案1】：

不，不是真的。当你让它安全时，你将不得不重新发明至少 90% 的 HTTPS（或者非常类似的东西，无论如何）——但可能做得很差。无意侮辱，但非常很少有人能够充分设计出这样的东西。通常是由专家（或其中一些人）尽可能地设计它，并且仍然计划在未来几年内至少解决一些问题，因为更多的密码分析家会关注它。非专业人士第一次做对的机会与赢得大乐透并在同一时刻被闪电击中的机会差不多。

【讨论】：

+1，既是为了正确，也是为了生动生动的例子。

【解决方案2】：

我相信，无论哪种形式，都会涉及公钥加密。您可能自己实现它，但它可能不安全且困难。为什么不想使用 HTTPS？它就是为此而存在的。

【讨论】：

【解决方案3】：

如果他们可以修改 javascript，那么他们可以删除您输入的任何校验和或类似内容。您最好的选择是使用 javascript 混淆器/最小化器，因为这只会让您很难更改并仍然运行.我相信雅虎有一个很好的，谷歌也有。

这不是万无一失的，但它可能会淘汰几乎所有考虑篡改您的小程序的人。前往 maps.google.com 并查看他们的 javascript。考虑偷偷地修改一些关于它的东西。可能不会发生。

编辑：毕竟这可能不是那么好，请参阅下面的链接

【讨论】：

有趣！感谢您的链接

【解决方案4】：

如果是 javascript，那么无论您是否使用 SSL，您甚至都无法确认 客户端机器上的人没有修改您的小程序。

【讨论】：

我同意客户修改代码，它通过一条不安全的线路传递初始未修改的包，这让我很困惑。（或者能够检测到初始包被修改了。）
@arby：这根本不可行，容易出错，而且通常浪费时间，甚至考虑更少的追求。