7

I do understand that it is a good security measure to implement HSTS, because it will reduce the number of incidents.

Statement 1: If clients IO traffic goes through MITM from the start, can the attacker can just strip Strict-Transport-Security header, even from initial HTTPS connection?

I'm aware of the pre-defined HSTS lists that browsers are implementing. This measure does not cover all sites/browsers.

Statement 2: Attacker can pass Strict-Transport-Security: max-age=0 header at any time, and disable HSTS.

If both of these are true, or even number 2 alone, HSTS seems pretty useless. It can't be that easy, where am I wrong?

Slava
  • 285
  • 1
  • 2
  • 9

3 Answers3

10

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).

Community
  • 1
Peter Green
  • 4,918
  • 1
  • 21
  • 26
  • well done and 100% accurate. Strict and Pinning together post-client-session requires a new protocol, browser code, or cipher attack. None exist for the current un-flagged ciphers and patched browsers under TLS 1.2.. – user1276423 Dec 08 '17 at 18:55
10

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!

Darsstar
  • 266
  • 4
  • 8
  • 2
    Okay, basically, HSTS depends on HTTPS connection, so it can only be compromised when SSL is compromised. So it provides defense only from the sslstrip attack, and only in the case the browser already received HSTS header. It's kind of narrow protection scope, but it's something. – Slava Sep 01 '14 at 13:49
  • 2
    Correct. It doesn't provide security for first time visitors, but enforces httpd for every subsequent request. – David Houde Sep 01 '14 at 14:35
  • 5
    First time visitors could be secure through other means, such as clicking an https link in a google (https) result page. Then if the person ever goes back to the site by manually typing the url in, or clicking an http link, they will still be safe because of HSTS. – Buge Aug 25 '15 at 18:07
  • The first time visitors can be protected by the so called "HSTS Preloading". It is not part of the HSTS standart, but it is used, at least, by the majority of the browsers. – Predte4a Sep 28 '19 at 10:49
3

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?

Community
  • 1
JonnyWizz
  • 1,971
  • 1
  • 14
  • 34