2

I want to perform a Man-in-the-Middle attack against my own network for educational purposes. I want the following scenario: Perform a MITM attack with Bettercap, navigate to a website and accept the certificate warning,which means accept the certificate presented by Bettercap (the attacker).

Question 1:

I want to know if this is possible nowadays with HSTS security policy being implemented on websites and HSTS preload list?

Question 2:

Are my only possibilities the websites that don't have the HSTS implemented or is there a way to remove HSTS and perform the attack by accepting the certificate?

1

Question 1: Yes, this is possible. The fact that the site is on the HSTS preload list only tells the browser that it should always connect to the site by https and not http. The HSTS preload list does not contain any information about the certificate itself.

Question 2: No, because of the answer to question 1.

| improve this answer | |
  • But if the HSTS security policy is implemented on websites, I can't bypass anymore the "Your connection is not private" warning and proceed to the website in an insecure way, so it means that it's not possible to accept the certificate ? – user241274 Aug 25 at 11:44
  • If the browser knows that the site uses HSTS, there is typically no button to proceed anyway. In Chrome at least, you can type "this is unsafe" if you really must bypass the warning. – multithr3at3d Aug 25 at 11:47
  • You should be able to connect to the site directly with https. Then, the browser will show a warning that the certificate is invalid, but there should be a way to proceed anyway with the invalid certificate. – mti2935 Aug 25 at 11:49
  • So if it type "this is unsafe", i can proceed to the page and the attack succeeds? – user241274 Aug 25 at 11:49
  • 1
    HSTS doesn't only require upgrade to TLS, but also a valid certificate. See my answer for why it's not possible to proceed. – Esa Jokinen Aug 25 at 18:31
1

Although non-normative, the browsers are generally following the well-reasoned User Agent Implementation Advices from RFC 6797, 12 for not letting the user to bypass the errors if there's a known HSTS policy in place.

12.1. No User Recourse

Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry.

Essentially, "any warnings or errors" means anything that would cause the UA implementation to announce to the user that something is not entirely correct with the connection establishment.

Not doing this, i.e., allowing user recourse such as "clicking through warning/error dialogs", is a recipe for a man-in-the-middle attack. If a web application issues an HSTS Policy, then it is implicitly opting into the "no user recourse" approach, whereby all certificate errors or warnings cause a connection termination, with no chance to "fool" users into making the wrong decision and compromising themselves.

If you need to be able to MitM your own connections e.g. for testing or debugging purposes, the only way around HSTS is to install the root CA certificate of your HTTPS proxy as a trusted root CA. This way the certificate used by the proxy becomes a valid certificate and, therefore, HSTS isn't a problem.

According to Provide a Bettercap's CA certificate to integrate into browser #536, the root CA certificate of Bettercap would be stored in /root/.bettercap-ca-cert.pem.

| improve this answer | |

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.