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?

  • 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, 2020 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, 2020 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, 2020 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, 2020 at 17:10
  • But the certificate is not signed by a trusted CA right, because I am using Bettercap's certificate?
    – user1235
    Aug 19, 2020 at 17:11

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.