14

Does HSTS protect a domain from a publicly trusted CA that has gone rogue issuing a illegitimate valid certificate? Examples of publicly trusted CA's would be any of the members of the Mozilla CA Bundle.

Is there any way to protect a domain from having an illegitimate but publicly trusted CA issue a valid certificate?

Anders
  • 65,582
  • 24
  • 185
  • 221
ThorSummoner
  • 329
  • 1
  • 2
  • 7
  • 1
    Depending on how the HSTS is set-up on the particular site(subdomains and so on..), the browser does not ask anything further than a valid certificate for an HSTS site. That means it doesn’t require the certificate to be same exact as the last time site was visited. You’d think that’s a liability but not so much. Local ARP/DNS spoofing won’t allow you to generate a publicly-trusted CA, all modern browser will throw red flags. There is a risk though that a particular website gets hijacked.. but then would they even need to replace the cert? :) – I'm a TI calculator Sep 20 '19 at 17:11
  • @I'maTIcalculator I suppose my hope was that the certificate wanted to be trusted would be bundled and distributed by, for example, the browser vendor, such that the browser software would have no need to ask the host for any certificate and check validity, but could instead assume any other certificate than the one bundled is invalid. I know that's a lot to ask, and probably far out of line with how much of the industry wants to operate. I suppose what I really want is to require my organizations CA to have signed all certificates that are considered publicy valid for my organizations domains – ThorSummoner Sep 20 '19 at 17:20
  • 2
    In-case anyone else is pondering how to become a CA, its amazing: https://security.stackexchange.com/a/177897/53804 – ThorSummoner Sep 20 '19 at 17:59
  • How many man hours did it take you to submit, then audit and so on? Was it worth it in the end? Curious to know what’s the total % or # of sites with a valid CA on the web today, can’t be much.. maybe you know? – I'm a TI calculator Sep 20 '19 at 18:07

1 Answers1

18

No, HSTS does not protect against certificate misissuance. HSTS simply tells the browser to only allow connecting to that site over HTTPS, it doesn't have anything to do with checking whether the certificate should be trusted.

There are two things that can help with misissuance to some extent, Certificate Transparency (CT) and Certificate Authority Authorization (CAA).

Certificate Transparency won't prevent misissuance by a CA, but it requires that certificates are publicly logged, so you can check and see if any certificates have been issued for your domain that shouldn't have been. Since 2018 Google Chrome has required that all new certificates issued be CT logged in order to be trusted. Firefox does not yet unfortunately, but in practice all certificates issued these days are CT logged as otherwise they would not work with Chrome.

Certificate Authority Authorization allows you to indicate which CAs are allowed to issue certificates for your domain using a DNS record. This will prevent accidental issuance by a CA, but of course a bad actor will just ignore it. Since CAA is only intended to say which CAs are allowed to issue a certificate at a specific point in time, and not for the lifetime of the certificate (ie if the CAA record changes the certificate is still valid), this is only a useful control for CAs that aren't bad actors, as it can help prevent them from issuing a certificate they shouldn't have which could eventually lead to their being distrusted. In fact, the RFC specifically requires that browsers not check CAA records.

A third option is HPKP, which allows you to pin a specific certificate that must be used for your domain (it needn't be a leaf certificate, pinning your CA's root would be somewhat similar to using CAA, but more effective), but it has fallen out of favor and is no longer supported by Chrome.

EDIT: curiousguy points out an interesting attack to work around CT logging in some cases. If an attacker has a Man in the Middle position, they may be able to tell which browser is establishing a connection early on (eg due to minor behavioral differences in the TLS stack). This could allow them to decide not to attack connections from browsers known to check CT logs, simply forwarding the connection to the legitimate server, but present a misissued and non-CT logged certificate to other browsers in order to impersonate the legitimate server. It seems that the only way to prevent this would be for all browsers to check CT logs.

AndrolGenhald
  • 15,696
  • 5
  • 45
  • 51
  • I think your answer beats mine! Delete time... – Conor Mancone Sep 20 '19 at 17:41
  • 1
    Unfortunately HPKP is deprecated by Google, so as of writing this comment the only major browsers it works in is Firefox and Opera – Bear Sep 21 '19 at 03:34
  • @Bear: IOW 2 out of 4. "All the others" but Safari are just reskinned Chrome with random UI changes and bundled stuff. – R.. GitHub STOP HELPING ICE Sep 21 '19 at 03:56
  • 1
    Reading this, I figured CAA would be something the browser would also validate, so CA's can't accidentally do something wrong, and when they do something wrong on purpose, it doesn't even work, but... Kinda useless to be honest. – Adam Barnes Sep 21 '19 at 15:25
  • HSTS protects against a similar attack though, namely the "HTTP landing page hijack", where an attacker takes over an initial unsecured connection (to say, http://examplebank.com/) that's supposed to redirect the user to the secure site https://examplebank.com/), and instead redirects the browser to the attacker's own copy of the site at a different address (https://fakeexamplebank.com/), where the attacker of course has legitimate certs for that address. If a browser still remembers the legit site's HSTS headers, it will never fetch the HTTP landing page, foiling the attack. – Bass Sep 21 '19 at 17:32
  • 1
    But if a TLS server can detect which browser is asking early, it can present a different cert for Chrome and FF. – curiousguy Sep 21 '19 at 17:36
  • @Bass fakeexamplebank.com wouldn't fool most users, but examplebank.com.fakeexamplebank.com might. – curiousguy Sep 21 '19 at 17:37
  • @AdamBarnes Indeed, the RFC actually requires that browsers not check CAA records, as they can be changed after the certificate is issued. This means it's only a useful control for CAs since it's a cheap way to prevent accidental misissuance that could eventually lead to their removal from trusted root stores, it really does nothing to stop a bad actor. – AndrolGenhald Sep 21 '19 at 19:07
  • @curiousguy That's an interesting point that I hadn't considered, makes me want Firefox to start requiring CT log checks sooner rather than later. – AndrolGenhald Sep 21 '19 at 19:08