Vad*_*kry 87 security ssl man-in-the-middle
我已经阅读了大量与此问题相关的文档,但我仍然无法将所有内容整合在一起,所以我想问几个问题.
首先,我将简要描述一下我理解的身份验证过程,因为我在这方面可能会弄错:客户端启动连接,服务器使用公钥,某些元数据和数字签名来响应信任的权威.然后客户端决定是否信任服务器,使用公钥加密一些随机会话密钥并将其发回.该会话密钥只能用存储在服务器上的私钥解密.服务器执行此操作,然后HTTPS会话开始.
那么,如果我在上面是正确的,问题是如何在这种情况下发生中间人攻击？我的意思是,即使有人用公钥拦截服务器(例如www.server.com)的响应并且有一些方法让我认为他是www.server.com,他仍然无法解密我的会话密钥没有私钥.
谈到相互认证,是关于服务器对客户身份的信心吗？我的意思是,客户端已经可以确定她正在与正确的服务器进行通信,但现在服务器想要找出客户端是谁,对吧？
最后一个问题是关于相互认证的替代方案.如果我在所描述的情况下充当客户端,如果在SSL会话建立后在HTTP头中发送登录名/密码怎么办？正如我所看到的,这些信息无法被截获,因为连接已经被保护,服务器可以依赖它进行识别.我错了吗？与相互身份验证相比,这种方法有哪些缺点(只有安全问题很重要,而不是实现复杂性)？
Joa*_*son 100
如果SSL的一个前提条件被破坏,那么SSL中的中间人攻击真的是可能的,这里有一些例子;
服务器密钥被窃取-意味着攻击者可以出现在服务器,有没有办法为客户就知道了.
客户端信任不值得信任的CA(或者其根密钥被盗的CA) - 持有可信CA密钥的人可以生成假装为服务器的证书,客户端将信任它.由于今天浏览器中预先存在CA的数量,这可能是一个真正的问题.这意味着服务器证书似乎会更改为另一个有效证书,这是大多数客户端将隐藏的内容.
客户端无需根据其可信CA列表正确验证证书 - 任何人都可以创建CA. 没有验证,"Ben的汽车和证书"似乎与Verisign一样有效.
客户端遭到攻击,并且在其受信任的根权限中注入了假CA.允许攻击者生成他喜欢的任何证书,并且客户端将信任它.恶意软件往往会这样做,例如将您重定向到虚假的银行网站.
特别是#2是相当讨厌的,即使您支付高度可信的证书,您的网站也不会以任何方式锁定该证书,您必须信任客户端浏览器中的所有 CA,因为它们中的任何一个都可以生成假证书您的网站同样有效.它也不需要访问服务器或客户端.
use*_*421 17
首先,我将简要介绍一下我所理解的认证程序,也许我错了这一步.因此,客户端启动连接,服务器使用公钥,某些元数据和受信任机构的数字签名的组合来响应它.
服务器响应X.509证书链和使用自己的私钥签名的数字签名.
然后,如果客户信任服务器,则客户端会做出决定
正确.
使用公钥加密一些随机会话密钥并将其发回.
否.客户端和服务器参与相互会话密钥生成过程,从而根本不传输会话密钥本身.
该会话密钥只能用存储在服务器上的私钥解密.
没有.
服务器这样做
没有.
然后HTTPS会话开始.
该TLS/SSL会话开始,但也有更多的步骤第一.
所以,如果我上面的说法正确,那么问题是在这种情况下中间人攻击怎么会发生？
伪装成服务器并充当SSL端点.客户端必须省略任何授权步骤.遗憾的是,大多数HTTPS会话中唯一的授权步骤是主机名检查.
我的意思是,即使有人用公钥拦截服务器(例如www.server.com)的响应,然后通过某种方式让我认为他是www.server.com,他仍然无法解密我的会话密钥没有私钥.
往上看.没有会话密钥可以解密.SSL连接本身是安全的,与您交谈的人可能不安全.
谈到相互认证,是关于服务器对客户身份的信心吗？我的意思是,客户端已经可以确定她正在与正确的服务器通信,但现在服务器想要找出谁是客户端,对吧？
正确.
最后一个问题是关于相互认证的替代方案.如果我在所描述的情况下充当客户端,如果在SSL会话建立后在HTTP头中发送登录名/密码怎么办？正如我所见,这些信息无法被截获,因为连接已经被保护,服务器可以依赖它进行识别.我错了吗？
没有.
与相互身份验证相比,这种方法有哪些缺点(只有安全问题很重要,而不是实现复杂性)？
它只与用户名/密码一样安全,它比私钥更容易泄露.
bbs*_*nbb 17
在客户端和服务器之间的任何人都可以通过https在中间攻击中安排一个人.如果您认为这不太可能或罕见,请考虑有商业产品系统地解密,扫描并重新加密互联网网关上的所有 ssl流量.他们的工作方式是向客户端发送一个即时创建的ssl证书,其中包含从"真实"ssl证书复制的详细信息,但使用不同的证书链签名.如果此链终止于任何浏览器的可信CA,则该MITM对用户是不可见的.这些产品主要销售给"安全"(警察)公司网络的公司,并应与用户的知识和同意一起使用.从技术上讲,ISP和任何其他网络运营商都没有停止使用它们.(假设NSA 至少有一个受信任的根CA签名密钥是安全的).
如果您正在为一个页面提供服务,则可以包含一个HTTP标头,指示该页面应该使用哪个公钥进行签名.这可能有助于提醒用户注意MITM的"安全"连接,但这是一种信任首次使用的技术.如果Bob还没有"真正的"公钥引脚的记录,Mallory只会重写文档中的pkp头.使用该技术(HSTS)的网站列表令人沮丧.它包括谷歌和Dropbox,他们的功劳.通常,https拦截网关将浏览来自使用HSTS的少数大型可信站点的页面.如果您在不期待它时看到HSTS错误,请小心谨慎.
关于密码,https连接上的所有内容都由https保护,但域名除外,该域名需要清除,以便可以路由请求.一般情况下,建议不要将密码放在查询字符串中,它们可以在日志,书签等中闲置.但除非https被泄露,否则查询字符串不可见.
| 归档时间： |
|
| 查看次数： |
76363 次 |
| 最近记录： |