5

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?

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!

  • 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. – Alph.Dev Sep 1 '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 1 '14 at 14:35
  • 4
    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 at 10:49
8

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

  • Overall a good answer. But I don't get your scenario 6. – kasperd May 7 '16 at 10:53
  • Sorry, typo, should be fixed now. – Peter Green May 7 '16 at 11:27
  • Now it makes sense. – kasperd May 7 '16 at 21:20
  • 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 8 '17 at 18:55
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?

1

To answer the original, broad question "HSTS is useless against MitM", the answer is sometimes. As others have answered, HSTS is not flaunted by the two statements you made. However, there are different ways to break HSTS and they have nothing to do with HSTS, TLS, or certificates.

HSTS is a major step in the right directon for HTTP security, but unfortunately, other critical components haven't caught up quite yet. DNS is one of the major ways to break, or rather, subvert HSTS. If an attacker is MitM on a network, that means they have the ability to spoof DNS replies. Let's say there is a client on the network who wants to connect to "accounts.google.com". The client's browser knows this host uses HSTS and that it must connect to it over HTTPS only. However, the attacker is spoofing DNS and has added a CNAME entry such that a DNS lookup for "accounts.google.com" resolves to "accounts.google.con" (or any other look-alike name), which in turn resolves to an address under the attacker's control (perhaps a cloned website or reverse proxy). The browser loads up "accounts.google.con" over plain HTTP and the user most likely does not notice. Now, the attacker can collect credentials or perform other MitM attacks with ease.

In short, HSTS protects against everything it is designed to protect, but lack of integrity in DNS can subvert it. Things like DNSSEC and DANE are the missing piece in this puzzle, but they are still a few years out from widespread adoption.

  • 1
    I don't think this answer is correct. As far as I know, DNS CNAME entries do not affect which hostname the certificate is validated against, so this attack would not work once the user agent has received the HSTS policy. – Tim McLean Apr 16 '16 at 4:01

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.