SSL 和中间人误解

我已经阅读了大量与这个问题相关的文档，但我仍然不能把所有的碎片放在一起，所以我想问几个问题。

  1. 首先，我将简要描述我所理解的身份验证过程，因为在这方面我可能会犯错: 一个客户端启动一个连接，服务器通过公钥、一些元数据和受信任的权威的数字签名的组合来响应该连接。然后，如果客户机信任服务器，客户机就会做出决定，用公钥加密某个随机会话密钥，并将其发送回来。只能使用存储在服务器上的私钥解密此会话密钥。服务器执行此操作，然后 HTTPS 会话开始。

  2. 那么，如果我上面说的没错，问题是在这种情况下，中间人攻击是如何发生的呢？我的意思是，即使有人用公钥拦截了服务器(例如 www.server.com)的响应，并且有一些方法让我认为他就是 www.server.com，他仍然不能在没有私钥的情况下解密我的会话密钥。

  3. 说到相互认证，它是否完全关系到服务器对客户机身份的信心？我的意思是，客户端已经可以确定她正在与正确的服务器通信，但现在服务器想要找出谁的客户端，对不对？

  4. 最后一个问题是关于相互认证的替代方案。如果我在所描述的情况下充当客户端，那么在建立 SSL 会话之后，如果我在 HTTP 头中发送一个登录/密码会怎么样？在我看来，这个信息不能被拦截，因为连接已经安全，服务器可以依赖它来识别我的身份。我说错了吗？与相互身份验证(只有安全问题重要，而不是实现复杂性)相比，这种方法的缺点是什么？

86594 次浏览
小开

Everything you have said is correct except the part about the session key. The point of CAs is to defeat a man-in-the-middle attack -- everything else is done by SSL itself. Client authentication is an alternative to a username and password scheme.

小开
  1. Correct
  2. Not so correct. In that kind of attack the itermediate server gets your request and send that to destination in behalf of you. and then respond to you with the result. Actually it is man-in-the-middle server which makes secure connection with you not actual server you are intended to comunicate. that is why you MUST always check the certicate is valid and trusted.
  3. could be correct
  4. If you are sure the secured connection is trusted then is would b safe to send username/password.
小开
最佳答案

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

  • The server key has been stolen - means the attacker can appear to be the server, and there is no way for the client to know.

  • 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.

  • 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.

  • 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.

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.

小开

First of all I'll describe briefly the authentification procedure as I understand it, maybe I'm mistaken on that step. So, a client starts a connection and a server responds it with combination of public key, some metadata and digital signature of a trusted authority.

The server responds with an X.509 certificate chain and a digital signature signed with its own private key.

Then the client takes the decision if she trusts the server

Correct.

encrypts some random session key with the public key and sends it back.

No. The client and server engage in a mutual session key generation process whereby the session key itself is never transmitted at all.

This session key can be decrypted only with private key stored on the server.

No.

Server does this

No.

and then the HTTPS session begins.

The TLS/SSL session begins, but there are more steps first.

So, if I'm correct above, the question is how does the man-in-the-middle attack can occur in such scenario?

By masquerading as the server and acting as the SSL endpoint. The client would have to omit any authorization step. Sadly the only authorization step in most HTTPS sessions is a hostname check.

I mean that even if somebody intercepts the server (e.g. www.server.com) response with public key and then with some means let me think that he is www.server.com, he still wouldn't be able to decrypt my session key without the private key.

See above. There is no session key to decrypt. The SSL connection itself is secure, it's who you're talking to that may not be secure.

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

Correct.

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, 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?

No.

What are the downsides of such approach comparing with mutual authentication (only security issues are important, not the implementation complexity)?

It's only as secure as the username/password, which are a lot easier to leak than a private key.

小开

Update 2022

This answer is now out of date thanks to Certificate Transparency.

Original answer

Anyone on the road between client and server can stage a man in the middle attack on https. If you think this is unlikely or rare, consider that there are commercial products that systematically decrypt, scan and re-encrypt all ssl traffic across an internet gateway. They work by sending the client an ssl cert created on-the-fly with the details copied from the "real" ssl cert, but signed with a different certificate chain. If this chain terminates with any of the browser's trusted CA's, this MITM will be invisible to the user. These products are primarily sold to companies to "secure" (police) corporate networks, and should be used with the knowledge and assent of users. Technically though, there's nothing stopping their use by ISPs or any other network carrier. (It would be safe to assume the NSA has at least one trusted root CA signing key).

If you're serving a page, you can include an HTTP header indicating what public key the page should be signed with. This may help to alert users to the MITM of their "secure" connection, but it's a trust-on-first-use technique. If Bob doesn't already have a record of the "real" public key pin, Mallory just rewrites the pkp header in the document. The list of web sites using this technology (HPKP) is depressingly short. It includes google and dropbox, to their credit. Usually, a https-intercepting gateway will wave through pages from the few big trusted sites that use HPKP. If you see an HPKP error when your not expecting it, be wary.

Regarding passwords, everything on an https connection is secured by https, except the domain name, which needs to be in the clear so the request can be routed. In general, it's recommended not to put passwords in the query string, where they can hang around in logs, bookmarks etc. But the query string is not visible unless https is compromised.


提交答案