102

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

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

  3. 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?

  4. 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)?

dfarrell07
  • 2,872
  • 2
  • 21
  • 26
Vadim Chekry
  • 1,243
  • 2
  • 12
  • 15

5 Answers5

115

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.

Joachim Isaksson
  • 176,943
  • 25
  • 281
  • 294
  • 4
    There are also tools like [sslstrip](http://www.thoughtcrime.org/software/sslstrip/), which will attempt to transparently rewrite https links into http links. – mpontillo Feb 16 '13 at 07:05
  • 3
    Another point about certificate verification is that the client needs to verify the host name. It's not good enough to check that the cert is genuine, it has to be issue to the entity you want to talk to (see [here](http://stackoverflow.com/a/13742121/372643) and [here](http://security.stackexchange.com/q/22965/2435)). As for sslstrip, it's ultimately [up to the user to check they want to use SSL/TLS](http://webmasters.stackexchange.com/a/28443/11628) unfortunately (although HSTS can help). – Bruno Feb 16 '13 at 13:07
  • Could I write a chrome (or any other browser for that matter) plugin that intercepts the data BEFORE the browser encrypt it? – Rosdi Kasim Mar 21 '14 at 04:01
  • Another reason is "Misuse of trust", as in TürkTrust issue. – ceremcem Apr 12 '14 at 10:38
  • Points 1 and 2 are more or less the same, aren't they? i.e. 2 is an elaboration of 1. – Remover Mar 21 '15 at 11:50
  • 1
    @Remover Not really... #1 is the private key on the server, paired with the genuine public key. In this scenario you'd talk to the real server but someone else could decrypt the traffic by being in the middle. They can't modify the certificate. #2 involves sending an entirely different certificate, issued by a "trusted" CA that will appear to be the legitimate to the client. The attacker can then proxy requests on your behalf and see messages that way. Both result in a compromise but #1 is under your control. #2, unfortunately, is not. – Basic Apr 03 '15 at 15:17
  • 1
    This answer, while not technically wrong, dates from the happy days before the NSA scandal, and the widespread use of ssl inspection. See my [answer](http://stackoverflow.com/a/32569050/1585345) below. – bbsimonbb Feb 09 '16 at 11:05
  • TLS provides no real security at all because as @Bruno points out it relies on users checking the URL, which none do. (And cannot even if they tried e.g. Mozilla.org is different from MoziIIa.org (capital I)) – Tuntable Jun 25 '19 at 05:02
21

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.

bbsimonbb
  • 27,056
  • 15
  • 80
  • 110
  • 1
    But this means this MITM equipment (the one that decrypts/scans and re-encrypts the traffic) needs to have access to one of the trusted CA right? (to "fake" the server certificate). Lets say this happens. Then someone busts this, the info becomes public, and there will be a scandal in the pres and the CA certificate will be removed from all browsers right? I mean, ideally... – jazzcat Sep 21 '16 at 18:35
  • 2
    No no. The "SSL Inspection" on the gateway needs create and sign certificates on the fly, but it doesn't need a root cert to do this. It has some intermediate cert, that has a chain. Whether or not the root of the chain is trusted by your browser determines whether you will see a certificate error. At work, we were asked to install the fortinet root cert so our browsers wouldn't give certificate errors. But if the chain terminated with an already trusted certificate, it's transparent. – bbsimonbb Sep 22 '16 at 07:26
  • A colleague at work was using a limited understanding of why these corporate network MITM techniques are a bad idea for Google to force SSL - Could he actually have a sliver of correctness? – EmSixTeen Sep 03 '18 at 12:43
  • 1
    Sorry I don't understand the question ! – bbsimonbb Sep 03 '18 at 12:52
  • @bbsimonbb, `No no. The "SSL Inspection" on the gateway needs create and sign certificates on the fly, but it doesn't need a root cert to do this. It has some intermediate cert, that has a chain.` But, the gateway _does_ need a valid CA to be able to sign these on-the-fly certificates, don't they? For a malicious MitM actor, isn't obtaining one of these intermediate CA's issued by a valid root CA unlikely? – jmrah Feb 09 '22 at 13:03
  • @jmrah what a coincidence. Something on hackernews today just led me to [this 2012 article](https://blog.cryptographyengineering.com/2012/02/28/how-to-fix-internet/). CA's may sell certs for SSL Inspection. – bbsimonbb Feb 09 '22 at 17:18
  • @bbsimonbb Thanks for sharing - a very informative article. I found it fascinating that the author, in 2012, talks about the idea of public certificate logs as a way to combat mississued certs and that a decade later (now), that is essentially what is being rolled out in the form of Certificate Transparency. It seems to me that the Certifcate Transparency system, together with its Signed Certificate Timestamp (and a client that actually verifies these things), is enough to thwart these on-the-fly creation of certs by malicious intermediate CAs. Would you agree with that? – jmrah Feb 10 '22 at 13:28
18

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.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thank you for your explanation. The only thing I didn't get is why you said a client doesn't send a session key to a server? Well, maybe I've used wrong terminology, [here](http://en.wikipedia.org/wiki/Transport_Layer_Security) this piece of data is called "pre-master secret", but anyway, isn't it sent by the client and it is decrypted with the server private key? – Vadim Chekry Feb 17 '13 at 07:30
  • 1
    @VadimChekry The pre-master secret is not the session key. It is one of several pieces of data used to generate the session key, independently at both ends. The process is described in RFC 2246. – user207421 Feb 17 '13 at 11:07
  • Thanks @EJP. I am out of my depth, but from this answer, can I assume that if you use the IP address to connect, you are not vulnerable to MITM attacks? It seems from everything I can find that MITM attacks depend on the mapping of a domain name to an illegitimate IP address. Apologies this is a dumb question to most people on this area of SO! – Chris Oct 15 '14 at 11:04
  • 1
    @Chris You are much less vulnerable, however IP address spoofing is possible. There is no substitute for checking the peer identity in the certificate yourself. – user207421 Mar 07 '16 at 06:15
  • 1
    +1 This is quite a good answer, for the most part. However, some points are lacking explanation with one-word responses. You could make it a definitive answer if you were to expand and/or elaborate on said points, (i.e. instead of, "no." you could briefly mention what *actually* happens.) in the main body. That would really clarify a few things. Thanks. – voices Jun 14 '16 at 13:30
  • 1
    @tjt263 The first 'no' provides an explanation of what really happens. The next two 'no's refer to the same misconception that produced the first 'no', and have the same explanation. The next and final 'no' refers to 'am I wrong' and it refers to the information just quoted from the OP. It is difficult therefore to undertasnd what you think is actually missing here. – user207421 Aug 06 '16 at 10:41
2
  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.
Boynux
  • 5,958
  • 2
  • 21
  • 29
  • About 2 - I'm assuming that the client is thoroughly checking the metadata sent by the server during the procedure of connection establishment and that the client doesn't trust to ALL certificates. So wouldn't such scenario be possible if - a) a client is not doing what I said above, or b) a man-in-the-middle has got somewhere a certificate signed by trusted CA? – Vadim Chekry Feb 16 '13 at 06:30
  • 1
    It happens very rare that the intermediate server sends valid certificate, last year it happend with Comodo CA if I remember well. But normally if it is a trusted connection then it is completely secure. – Boynux Feb 16 '13 at 07:03
1

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.

user207421
  • 305,947
  • 44
  • 307
  • 483
David Schwartz
  • 179,497
  • 17
  • 214
  • 278