SSL和中间人的误解 [英] SSL and man-in-the-middle misunderstanding

查看:173
本文介绍了SSL和中间人的误解的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我已经阅读了有关此问题的大量文档,但仍然无法将所有内容汇总在一起,所以我想提出几个问题.

I've read tons of documentation related to this problem but I still can't get all the pieces together, so I'd like to ask a couple of questions.

  1. 首先,我将简要介绍我所了解的身份验证过程,因为在这方面可能会引起我的误解:客户端启动连接,服务器使用公共密钥的组合来响应该连接,其中一些可信机构的元数据和数字签名.然后,客户端将决定是否信任服务器,并使用公共密钥对某些随机会话密钥进行加密并将其发送回去.只能使用存储在服务器上的私钥来解密此会话密钥.服务器执行此操作,然后HTTPS会话开始.

  1. First of all I'll describe briefly the authentication procedure as I understand it, as I may be mistaken in that regard: A client starts a connection, which a server responds to with a combination of public key, some metadata and digital signature of a trusted authority. Then the client takes the decision if she trusts the server, encrypts some random session key with the public key and sends it back. This session key can be decrypted only with private key stored on the server. Server does this and then the HTTPS session begins.

因此,如果我在上面是正确的,那么问题是在这种情况下如何发生中间人攻击?我的意思是,即使有人用公钥拦截了服务器(例如www.server.com)的响应,并且有某种手段使我认为他是www.server.com,他仍然无法解密我的会话密钥没有私钥.

So, if I'm correct above, the question is how the man-in-the-middle attack can occur in such scenario? I mean, even if somebody intercepts the server (e.g. www.server.com) response with public key and has some means to make me think that he is www.server.com, he still wouldn't be able to decrypt my session key without the private key.

谈到相互认证,这是否完全有关服务器对客户端身份的信心?我的意思是,客户端已经可以确定自己正在与正确的服务器通信,但是现在服务器希望找出客户端是谁,对吗?

Speaking about the mutual authentication, is it all about the server confidence about the client identity? I mean, the client can already be sure that she is communicating with the right server, but now the server wants to find out who the client is, right?

最后一个问题是关于相互身份验证的替代方法.如果我在上述情况下充当客户端,如果在建立SSL会话后在HTTP标头中发送登录名/密码怎么办?如我所见,该信息无法被截取,因为连接已被保护,服务器可以依靠它来识别我.我错了吗?与双向身份验证相比,这种方法的缺点是什么(仅安全问题很重要,实现的复杂性并不重要)?

And the last question is about the alternative to the mutual authentication. If I act as a client in the situation described, what if I send a login/password in the HTTP header after the SSL session is established? As I see it, this information can't be intercepted because the connection is already secured and the server can rely on it for my identification. Am I wrong? What are the downsides of such an approach compared with mutual authentication (only security issues are important, not the implementation complexity)?

推荐答案

只有在SSL的先决条件之一被破坏的情况下,对SSL的中间人攻击实际上才有可能,下面是一些示例;

Man-in-the-middle attacks on SSL are really only possible if one of SSL's preconditions is broken, here are some examples;

  • 服务器密钥已被盗-意味着攻击者似乎是服务器,客户端无法知道 .

客户端信任一个不可信的CA(或已被盗用其根密钥的CA)-持有可信CA密钥的任何人都可以生成一个伪装成服务器的证书,并且客户端将信任它.随着当今浏览器中已经存在大量的CA,这可能是一个真正的问题.这意味着服务器证书似乎将更改为另一有效证书,这是大多数客户端都对您隐藏的东西.

The client trusts an untrustworthy CA (or one that has had it's root key stolen) - whoever holds a trusted CA key can generate a certificate pretending to be the server and the client will trust it. With the number of CAs pre-existing in browsers today, this may be a real problem. This means that the server certificate would appear to change to another valid one, which is something most clients will hide from you.

客户端无需费心对照受信任的CA列表正确验证证书-任何人都可以创建CA.未经验证,"Ben的汽车和证书"将与Verisign一样有效.

The client doesn't bother to validate the certificate correctly against its list of trusted CA's - anyone can create a CA. With no validation, "Ben's Cars and Certificates" will appear to be just as valid as Verisign.

客户端已受到攻击,伪造的CA已注入其受信任的根颁发机构中-允许攻击者生成他喜欢的任何证书,客户端将信任它.恶意软件通常会这样做,例如将您重定向到伪造的银行站点.

The client has been attacked and a fake CA has been injected in his trusted root authorities - allows the attacker to generate any cert he likes, and the client will trust it. Malware tends to do this to for example redirect you to fake banking sites.

尤其是#2令人讨厌,即使您为高度受信任的证书付费,您的网站也不会以任何方式锁定到该证书,您必须信任客户端浏览器中的所有 CA因为它们中的任何一个都可以为您的网站生成同样有效的伪造证书.它还不需要访问服务器或客户端.

Especially #2 is rather nasty, even if you pay for a highly trusted certificate, your site will not be in any way locked to that certificate, you have to trust all CAs in the client's browser since any of them can generate a fake cert for your site that is just as valid. It also does not require access to either the server or the client.

这篇关于SSL和中间人的误解的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆