让我们假设有一个服务器和一个客户机,并且您想连接这两者。服务器有一个自签名证书,在第一次建立连接(注册)之前,服务器创建一个客户端证书,并为特定客户端创建一个一次性密码。(在服务器上启动)
管理员前面有两台机器,然后在客户机中输入一次性密码(假设令牌安全地传输到客户端)。然后,客户端连接到服务器(https),并在成功时使用一次性密码进行标识。然后,服务器将客户端证书发送到客户端。
不安全是在第一次联系的时刻。由于客户端不知道服务器的证书(并且它是自签名的),有人可以劫持连接并将客户端重定向到“坏服务器”,并在不知情的情况下向该服务器发送一次性密码。(内联网很可能很好,真正的危险是在因特网上完成这一工作)
有一种方法可以完全解决这个问题:不仅给客户提供一个一次性密码,而且还提供服务器证书的指纹。不幸的是,在这种情况下不能这样做,而且为了验证证书,我只能将4字节传输到6字节或8字节。
我知道这不能建立完全的安全,但我想这总比没有检查好,对吗?对于攻击者来说,创建一个拥有正确的url和匹配的证书是多么容易的事。说指纹的前4-8个字符。是否有一种方法,使它更安全,只有4-8字节?
发布于 2013-01-10 14:23:14
理论上的解决方案是与TLS-SRP进行第一个连接。这是SSL,但是有一个特殊的密码套件,它不使用任何证书;相反,客户端和服务器在公共“密码”的知识方面相互认证;这甚至容忍低熵密码,因为它本身就不受离线字典攻击的影响。在这个初始连接中,服务器应该发送其“正常”证书的副本,用于进一步的连接。这种策略在某些情况下用于对蓝牙设备。
不幸的是,并不是所有的SSL/TLS库都知道SRP。GnuTLS有。
如果您可以获得指纹的前8个真实字节(而不是8个十六进制字符),那么这就足够了。生成一个与指纹的前8字节(即64位)匹配的假证书在技术上是可行的,但代价很高(想想看,几百台PC运行了几个月)。
发布于 2013-01-10 14:25:36
服务器不应该创建客户端证书,客户端应该创建证书并通过您描述的SSL通道向服务器发送私钥。在您描述的情况下,攻击者可以假装是服务器(客户端不知道服务器,因为证书是自签名的),然后使用密码向服务器发出请求。然后,攻击者可以保留私钥并将其转发给用户,而服务器或用户都不知道存在问题。
如果客户端生成证书并将公钥发送给服务器并使用私钥对公钥进行签名,则攻击者仍然可以截获密码并发送自己的公钥,但客户端将无法连接并检测到入侵。但是,如果攻击者能够持久地假装自己是服务器,这是行不通的,因为他们可以隐藏客户端没有连接到真正服务器的事实。
https://security.stackexchange.com/questions/27822
复制相似问题