向后HTTPS;用户与先前生成的私钥通信

时间:2010-08-05 18:09:03

标签: security web-applications encryption cryptography

我正在寻找像https这样的东西,但是倒退了。用户(提前)生成他们自己的私钥,然后(仅稍后)为Web应用程序提供相关的公钥。这部分交换应该(如有必要)在带外发生。然后使用这些密钥对通信进行加密/解密。

我已经想到了一些奇怪的JavaScript方法来实现这一点(从客户端的角度来看:表单提交是在他们的出路加密而(在ajax响应上)Web内容被解密。我认识到这很可怕,但你可以'否认这将是一个有趣的黑客。但是,我想知道是否已经存在某些东西...通常在浏览器和Web /应用程序服务器中实现的东西。

主要是为了解决在不知不觉中通过可能拦截https连接并发布自己的证书的恶意接入点进行通信时的安全性受损。最近(在我自己的网络中)我重新创建了这个并且(非常恐怖)很快就以纯文本形式看到了我的gmail密码!我有一个网络应用程序,只有我和其他一些人使用,但安全(从学习的角度来看)需要是顶尖的。

我应该补充一点,解决方案不需要实用

另外,如果我的思维过程中存在一些本质上的错误,如果有人让我走上正轨或指导我阅读适当的文献,我将非常感激。科学不是要找到更好的答案;科学是关于形成更好的问题。

感谢您的时间, O∴D

4 个答案:

答案 0 :(得分:2)

如果恶意接入点可以嗅探数据包,它也可以改变数据包('主动'中间人攻击)。因此,客户端脚本可能提供的任何安全措施都可以通过在发送给客户端的路径上禁止脚本本身来轻松规避。

HTTPS - 以及当MitM试图愚弄你时获得的未经授权的证书警告 - 就像它获得的一样好。

答案 1 :(得分:2)

这已经完成了。它们被称为TLS客户端证书。 SSL不一定是单向的;它可以是两方相互认证。

您所做的是让客户端生成私钥。然后,客户端向服务器发送CSR(证书签名请求),服务器在其中签署公钥并将其返回给客户端。私钥永远不会通过网络发送。如果AP拦截并修改密钥,则客户端将知道。

但是,会阻止恶意AP代表客户端请求证书。您需要一个带外通道来验证身份。 没有办法阻止一个中间人冒充客户而没有办法绕过那个MITM。

答案 2 :(得分:1)

SSL和HTTPS用于允许客户端证书。在服务器端,您可以使用these environment variables来验证证书。如果您只有1台服务器和一堆客户端,则不需要完整的PKI。相反,您可以在数据库中拥有有效客户端证书的列表。 Here是有关该主题的更多信息。

在JavaScript中实现这样的事情是一个坏主意。

答案 3 :(得分:1)

我不明白,为什么你在这里使用不对称加密。一方面,它很慢,其次,无论如何,它很容易受到中间人的伤害 通常,您使用非对称加密来进行相对安全的会话协商,包括交换对称加密的密钥,对会话有效。

由于您使用安全通道进行协商,我真的不明白为什么您甚至发送公钥,这些公钥本身仅对一个会话有效。
如果你有共享秘密,非对称加密是有意义的,它允许验证公钥。如果您不更改每个会话的密钥,并且密钥是在中央位置(即服务器而不是所有客户端)生成的话,那么拥有此共享密钥会非常容易。

此外,正如车已经指出的那样,JavaScript是一个坏主意。你必须从头开始编写所有内容,从基本的算术运算开始,因为Number不会让你走得太远,如果你想使用一个数量级的密钥,那就提供了合理的安全性。

格尔茨
back2dos