Hacker News Reader

Comment by EE84M3i | Hacker News Reader

Forgive my ignorance but I have a few questions:

* Why would HSTS help in this case? While HSTS is active, does it prevent clicking through the warning (which was done here)?

* How would a CAA record help against cert issuance in this case? Is it only helping against compromise of the authoritative during the remaining TTL of the record in recursives AND if the CAA record points to something that doesn't have on-demand DV like Lets Encrypt?

View on HN

HSTS does indeed prevent users from clicking through the warning - it makes handshake / trust chain failure fatal with no "proceed anyway" button.

Sorta. In most browsers you can manually delete the HSTS property on a per-domain basis. Presumably, anyone doing this knows the risks.

In Chrome, it's a real pain in the ass, and it's buried deeply. It's not available at all in the settings UI (not even in advanced settings).

You can type "badidea" at the warning page to skip it.

Changed to "This is unsafe" (followed by enter) in chrome 65. Try it at https://badssl.finn.io/

Doesn't work for me (anymore) in Chrome 65. Used to work.

I think it was changed to something like "thisisunsafe" now.

Just checked this on chrome 65 on https://badssl.finn.io/ seems to work (also need to press enter).

That's correct, tested it with https://badssl.finn.io/

Had no idea about that 'badidea' work around in chrome. Just tried it and it actually worked.

In Chrome, clearing the cache, clears the saved HSTS records which are not preloaded in the browser.

> * Why would HSTS help in this case? While HSTS is active, does it prevent clicking through the warning (which was done here)?

Yes, HSTS (if preloaded or cached by the browser) prevents clicking through the warning, although there's a secret code you can type in chrome? to get around it still.

> * CAA record

Yeah, a CAA record wouldn't help. Presumably the CA in question is going to want to get that record freshly, and while the DNS is hijacked, they can return whatever they like. DNSSEC could conceivably help, but that's a pretty big can of worms.

DNSSEC only "helps" if you can get CAA working reliably with it, because otherwise, it's only role in this attack is to lock CAs to a particular IP address. But this is a BGP hijack: attackers control IP.

HSTS wouldn't help users clicking through warnings, but it's a good thing to have (myetherwallet doesn't use HSTS).

CAA record would only help in remaining TTL. Once expired, then it doesn't matter.

So yeah, these seem like decent steps to help protect but certainly not going to 100% prevent an attack like this one.

>HSTS wouldn't help users clicking through warning

Actually it would have! Chrome and possible other browsers do not allow clicking throw certificate validation issues on sites with HSTS. For example, try to get to https://badssl.finn.io in Chrome.

Sorry how does that help if the attackers purchase a new "valid" SSL certificate since they control the DNS and thus email?

It does not help for that scenario, but it forces the attackers to jump through another hoop, and publish that a new cert was issued for the domain.

Once you control DNS, it doesn't require email, you can just use lets-encrypt. The lets-encrypt verification does not check HSTS.

Makes sense because it keeps HSTS from the lockout scenario that makes HPKP so scary.

Is it possible to get a TLD registrar to set a very short TTL like 5min on your NS record? Then you can switch to a backup DNS hosted on another network fast.

Yes, you can set a short TTL on your NS record, but that would not keep this attack from hijacking your site. This attack intercepts the clients DNS lookup, so the DNS a browser is talking to is ill-behaved. No amount of correct setup here will work because the ill-behaved DNS server will just replace your setup with whatever that server wants.

There is no strong defense against this as a website. With an app the solution would be certificate pinning. You could try HPKP but that comes with a host of issues and I think it is being deprecated.

Wait: in example.com say .com registrar sets a 5min TTL on NS record for example.com that resolves to 1.2.3.4. That means that your DNS server is at 1.2.3.4, serving your A and MX records. An attacker BGP hijacks 1.2.3.4. You change NS record in your .com registrar settings to 5.6.7.8 that is not compromised. Notice I am not talking about your A or MX records that you controlled on a compromised IP, but of NS record that a .com registrar controls. So after 5 min the browsers contact a non-compromised nameserver at 5.6.7.8 to get your A records.

I think unless a TLD registrar gets hijacked that mitigates the attack on your own DNS after the NS TTL

You are right, I was thinking of a different attack. Something like a BGP-hijack of 8.8.8.8 , 1.1.1.1 or similar often used DNS resolvers.

Here though, people using area53 for DNS probably can't move away from it as they are stuck on amazon.

I'm seeing HSTS on https://www.myetherwallet.com/

  curl -I https://www.myetherwallet.com/
  strict-transport-security: max-age=63072000; includeSubdomains; preload

Presumably that's fairly new. The domain hasn't made it on the HSTS preload list shipped by browsers yet, so my guess would be they started using HSTS in response to this attack.

It was addad at most a few hours earlier and as a response to the attack. That's when I checked and it did not have HSTS at that point.

I see. That is indeed bad that it wasn't there before.

wait, myetherwallet doesn't use HSTS? I thought they had a vulnerability analysis done a few months ago. I feel like this should have been something that was caught.

Wow, that's scary. I even told someone recently, jokingly of course, they forgot to add HSTS for their mvp app.

But MEW doesn't have HSTS? I would never use it personally on a public Wifi, but many people will for sure and they have no idea they'd be MITM'd.

> But MEW doesn't have HSTS? I would never use it personally on a public Wifi, but many people will for sure and they have no idea they'd be MITM'd.

Even without HSTS a bad actor would have to either trick a user to install a root cert or trick a certificate authority to generate a cert for the domain. Both of these are possible and have happened in the past, but they're also are a requirement for the attack you mention that you seemed to have completely forgotten about.

No they wouldn't, without HSTS a bad actor (public wifi) could just do an SSL strip attack. Sure, observant users would notice that the page isn't over https, and with browsers adding warnings on all http pages, that'll become more obvious, but it's still not something most people notice.

Are you thinking of HPKP?

ah, yes, I was confusing HSTS with HPKP.

Now I need to re-read the whole thread with this context. Thanks for the correction!

HSTS does prevent clicking through the warning. Here's a test page: https://subdomain.preloaded-hsts.badssl.com/

Reply on news.ycombinator.com