-1

I am performing a MITM attack against my own network using bettercap and https proxy. On my client-side I use the Google Chrome browser and navigate to https://webs.com At the same time I use a script that analyzes client-side TLS security parameters.

Bettercap presents its certificate to the client-server connection and I accept the certificate warning (just for testing). When I see the result of the script which analyzes the client-side TLS security parameters, the parameters chosen between the client and the server have a strong security grade. How is this possible that even though a MITM attack has succeeded in injecting his certificate, the patameters are still secure between a client and a server?

user1235
  • 1
  • You accepted a certificate with the wrong DNS name in it, but the rest (algorithm, key size) can still be "strong". Define what you mean by "strong", and what you expect to see instead. – Marc Aug 19 '20 at 17:05
  • @Marc strong means that they are highly secured which in fact they shouldn't be because the connection is insecure (a MITM attack is in between) – user1235 Aug 19 '20 at 17:06
  • What I expect to see is: perform a MITM attack, accept the certificate on my browser , obtain insecure TLS parameters because a MITM attack is in between – user1235 Aug 19 '20 at 17:07
  • That's not how it works. You ignored the browser's warning and told it to proceed with a certificate that has the wrong name in it. The browser kept going with a TLS connection using the wrong certificate, but it's still TLS and can still be strong. It's just talking to the MITM, but it warned you about that and you ignored it. – Marc Aug 19 '20 at 17:10
  • But the certificate is not signed by a trusted CA right, because I am using Bettercap's certificate? – user1235 Aug 19 '20 at 17:11
  • Yes, and the browser didn't want to connect, but you overrode that decision and told it to anyway, security be damned. – Marc Aug 19 '20 at 17:12
  • Okay, I understand. Do you have any idea on what to do in order to obtain what I want? – user1235 Aug 19 '20 at 17:12
  • Yes, don't override the security warning, it will refuse to connect. But then there would be no parameters to examine since there would be no connection. – Marc Aug 19 '20 at 17:14
  • So there is no way to perform a MITM attack and have as a result insecure TLS parameters? – user1235 Aug 19 '20 at 17:16
  • You can use a certificate with weak algorithms or small key size, but why would you? And you still haven't defined "strong" or "insecure". – Marc Aug 19 '20 at 17:25
  • This is like the idea in old movies that a good person (hero) always kills the person they are shooting at, even miles away and moving rapidly, while a bad person (villain) can't ever hit the stereotypical side of a barn from 2 feet away. **Reality isn't like that.** Some heros are good shots and some are poor; some villains are good shots and some are poor. A legitimate server can use either strong or weak parameters, and a fraudulent and bogus server, if you wrongly accept it, also can use either strong or weak parameters. See also RFC 3514. – dave_thompson_085 Aug 19 '20 at 23:20

1 Answers1

1

A SSL MITM attack essentially consists of two independent TLS connections: one from client to attacker and one from attacker to server. For this to work all is needed that the client somehow trusts the certificate send by the attacker, as you do. The security of the TLS connection between client and attacker is fully independent to the connection between attacker and server. It is also not really restricted in what security settings it can use, i.e. everything which the client accepts can be done. This means it can even provide better security than the original connection to the server.

In other words: the only insecure thing in this setup was that the certificate from the attacker was not issued by a trusted CA. But this certificate was explicitly treated as trusted by ignoring the certificate warning.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424