-1

If the attacker does the MIM attack before the handshake and whatch it being done, get both public certificates and act just as a listener.

Instead of trying to act as one of the parties, just read all the communication to get useful information like JWT tokens and other informations about what the user is doing on that site.

Given that the attacker will be able to intercept the certificates before the connection goes secured, it can open all the packets after the handshake is done, I am wrong?

Is that possible?

Marco Silva
  • 564
  • 5
  • 15
  • The only way the MITM can succeed at all is if the client accepts his certificate, in other words if he can appear to the client to be the server. – user207421 Apr 26 '18 at 01:39

2 Answers2

5

Yes and No, it depends on some other elements in game...

The answer is YES in the case where there's no SSL certificate!

How?

Let's consider the classic case where the 2 peers are Alice and Bob trying to communicate via HTTPs.

The MITM can get only the public key from Alice and Bob. Not the private keys. Even in the original situation, Alice can only encrypt information to Bob using Bob's public key and Bob can only encrypt information to Alice using Alice's public key.

What a "smart" MITM would do is to REPLACE the public keys that are delivered in the channel for each pair. In other words: Alice sends the key that Bob is supposed to receive. The MITM will intercept this key and not deliver it to Bob, but instead, he/she will replace by its own key (let's call the hacker key) and then deliver to Bob this hacker key.

The same thing above will happen in the other direction with the key that Bob is supposed to send to Alice.

Well... now both Alice and Bob received a hacker key and they THINK the key is the original from the other peer (because there is no certificate), but the original is kept by hacker. Do you see? The hacker can just receive information from one of the sides and decrypt (because it was encrypted with the hacker's public key) and then re-encrypt with the original public key of the other side. Simple like that!

... BUT the answer is NO if there is an SSL certificate.

Why?

Because certificates exists exactly to solve this problem described above. It means, the public key coming from Alice/Bob can be verified by digital signatures if they in fact belong to Alice and Bob, so, if they are using an SSL certificate Alice and Bob are able to detected that some MITM swapped the original keys. How this works is out of scope of this question, but "as a short answer" both sites will have third-party certificates "pre-installed" that can be used to validate the authenticity of the public keys being exchanged.

Wagner Patriota
  • 5,494
  • 26
  • 49
  • Even with a certificate... If the man in the middle tricked the end client to accept its own certificate (instead of the true server ones) and at the same time connects to the true final server, so that it just proxy traffic but since it terminates the client TLS connection it has access to all of its clear data. – Patrick Mevzek Apr 26 '18 at 15:37
  • 2
    Yes, that is right. But obviously in this scope we assume that MITM is just a MITM. "Mathematically speaking", Alice and Bob are not compromised. This one you described is a different type of attack beyond MITM. If you compromise the root certificates then everything changes. – Wagner Patriota Apr 26 '18 at 15:50
  • No, it is NOT a compromise of any certificate. Just tricking the client to accept another certificate. This happens often. See link in my answer (not a MITM just a stealing) for the most recent case: people were just accepting a self signed certificate instead of the true one. It is an attack on the human between chair and keyboard, the less secure part. The connection was TLS... just not to the true intended recipient. This shows one of the point less understood: contrary to feeling, authentication is more important than integrity, or at least you need it first.But it is more complicated too! – Patrick Mevzek Apr 26 '18 at 15:54
  • 2
    accept another certificate is another detail. It still doesn't invalidate my answer. I am talking about a valid certificate signed by a third-party. What is your problem? – Wagner Patriota Apr 26 '18 at 17:50
  • 1
    I do not have a "problem". I just think that "BUT the answer is NO if there is an SSL certificate." is wrong in a generic case, hence my details. It also kind of propagate the ideas that TLS is ok as soon as you have a certificate, which is clearly not the case. See my answer for complete reasoning. – Patrick Mevzek Apr 26 '18 at 18:07
  • "If the man in the middle tricked the end client to accept its own certificate... bla bla bla" ... this OUT OF SCOPE OF THE MITM ATTACK explanation! It is the same thing as saying: "if the MITM tricked the end client and make him to accetp a trojan horse then he doesn't even need to worry about HTTPs anymore and will hack his machine and do whatever he wants" I am just explaining how MITM works and the basic of how a certificate (NON-COMPROMISED) can solve the problem. Again, what is your problem? – Wagner Patriota Apr 26 '18 at 18:14
  • Sorry that you do seem to accept that people have different viewpoints than yours (i am not seeing things as in/out of scope as you do and the fact is that it has nothing to do about certificate compromise at all). So I will stop discussing this with you now. No problem, just different view, ok? – Patrick Mevzek Apr 26 '18 at 19:00
1

You are coming at wrong conclusions because of this: "Given that the attacker will be able to intercept the certificates before the connection goes secured ".

In classic PKI model used for TLS communications, like HTTPS, where basically only the client authenticates the server (it could be mutual too), the client has a list of trusted Certificate Authorities. These authorities are supposed to deliver certificates only after careful reviews.

So "normally" only the true owner of "www.example.com" could get the certificate for it. Hence the client will validate the certificate because it has a trusted CA in its local store (it has its "root" and eventually intermediary certificate(s) that has issued this certificate)

It is not the certificate just by itself that identifies something, as this is public. It is the whole trust path from a trusted CA to the final certificate that should be signed by it.

If there is a man in the middle, either the certificate will be for another name or it will be issued by an unknown CA, typically when it is signed by itself for example (latest famous such case: https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/ )

Now, the whole problem of this PKI model for the web is that clients need to trust hundreds of CA on their end and any CA can deliver a certificate for any name. So as soon as you found a rogue one or a glitch into one you could theoretically have a second certificate for a resource you do not really own. This happened multiple times in the past.

There are various options to deal with that, both on the client or server side. The client could trim its list of allowed CA. The server can use DANE in the DNS to publish exactly which certificate or which CA the clients should be expected to see when connecting to it (and a MiTM would not be able to defeat that as DANE is protected by DNSSEC).

Patrick Mevzek
  • 10,995
  • 16
  • 38
  • 54