True or False: HSTS is absolutely useless against MITM attacks

Statement 1: There should be no header for an attacker to strip since sending it over HTTP is useless. No idea why someone would send it over HTTP. And if the attacker has certificates that the client trust so a HTTPS connection will be established, then HTTPS won't bother the attacker. A connection over HTTP is still vulnerable, HSTS won't change this. It will transparently switch from HTTP to HTTPS if a valid HSTS entry exists.

Statement 2: Again, a browsers should only act on HSTS headers sent over a HTTPS connection. If the attacker can send that header (s)he won't be bothered by HTTPS.

Anyway, Defense in Depth! Which is why I do not think that HSTS is useless. If you immediately upgrade every HTTP connection to an HTTPS connection using redirects your users can be vulnerable a lot over the course of a year! Compare that to the initial connection when using HSTS and a browser that supports it!

True or False: HSTS is absolutely useless against MITM attacks

False, HSTS protects against certain categories of MITM attack but not against others.

HKP (I know you didn't ask about this but I feel it doesn't make sense to look at one without looking at the other) also protects against certain categories of MITM attacks but not against others.

The combination of HSTS and HKP protects against an attack scenario that neither alone can protect against.

There are some types of MITM attack that cannot be protected against by the combaintion of HSTS and HKP.

Lets look at some scenarios. In all scenarios I will assume that example.com is not in any browser prelod lists. I will also assume that http://example.com redirect to https://example.com

Scenario 1:

The client visits http://example.com/ and they had not visited example.com before the MITM esablished themselves.

In this scenario the MITM will succed. He can simply intercept the intial connection and prevent redirection to https.

Scenario 2:

The client visits https://example.com/ . The attacker does not posses a certificate that will pass the browsers normal certificate validation.

In this scenario the https connection will fail certificate validation and the MITM will fail. HSTS and HKP are not needed.

Scenario 3:

The client visits http://example.com/ and they had visited example.com before the MITM esablished themselves. The attacker does not posses a certificate that will pass the browsers normal certificate validation.

In this scenario without HSTS the MITM will succed. He can simply intercept the intial connection and prevent redirection to https.

With HSTS the browser will never try to make a plain http connection but will instead move straight to https. The https connection will fail certificate validation and the MITM will fail.

Scenario 4:

The client visits https://example.com/ and they had not visited example.com before the MITM esablished themselves. The attacker has obtained a certificate coverting example.com from a CA in the browsers default trusted roots list (by trickery, bribery, bullying or whatever)

In this scenario the attacker succeeds.

Scenario 5:

The client visits https://example.com/ and they had visited example.com before the MITM esablished themselves. The attacker has obtained a certificate coverting example.com from a CA in the browsers default trusted roots list.

In this scenario without HKP the attacker succeeds. With HKP the certificate validation fails.

Scenario 6:

The client visits http://example.com/ and they had visited example.com before the MITM esablished themselves. The attacker has obtained a certificate coverting example.com from a CA in the browsers default trusted roots list.

In this scenario without HSTS the MITM will succeed. He can simply intercept the intial connection and prevent redirection to https.

In this scenario without HKP the MITM will succeed. He can successfully MITM the https connection.

With both HSTS and HKP the browser will never try to make a plain http connection but will instead move straight to https. The https connection will fail certificate validation thanks to HKP and the MITM will fail.

Scenario 7:

The MITM has obtained the private key for (one of) the site's legitimate certificates

The MITM will succeed

Scenario 8:

The MITM has obtained a certficate for exampe.com from a CA that was manually added to the trusted roots list.

HKP is bypassed and the MITM will succed. (this allows corporate firewalls that inspect https to continue to work, whether that is a good thing or not is debatable).

One other way that HSTS could be compromised would be if you had a root CA installed on the computer that you were connecting from that enabled a MITM attacker to appear to be the original website.

E.g. if you were using a company computer to connect to Gmail, the company could intercept the traffic in the folllowing way:

• Company computers have a custom root CA installed
• The custom root CA is used to sign a "bad" certificate for Google
• Your computer connects to an intermediary device (e.g. firewall) using this "bad" certificate
• The communication is decrypted, then re-encrypted using the genuine certificate for Google.

See this question How can my employer be a man-in-the-middle when I connect to Gmail?