Hacker News Reader

Comment by bklyn11201 | Hacker News Reader

Getting a basic certificate issued is incredibly easy these days. If you own the DNS resolution, you can get a cert.

Here a few ways I can think of to make this harder for an attacker:

* Add a Strict-Transport-Security to all HTTPS requests. This means the attacker will need to get a valid cert (still easy if you can hijack BGP).

* Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing that one issuer.

* Go through the EV SSL process with your preferred issuer. Now modify your CAA DNS record to add an EV policy. This should make it very difficult for an attacker to get a cert issued during a BGP hijack.

* DNSSEC? Make sure to choose an SSL issuer that will correctly test DNSSEC?

View on HN

If I control the network, I can strip off any security that might be in DNS. I can change or remove CAA records, DNSSEC, etc. Those things currently fail open, which exception to DNS replication which will take "refresh" time to fail. I can then get new certs for the DNS I now control. HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the client, such as mobile apps.

> HSTS just means use HTTPS. It doesn't validate the previous cert. That is HPKP which almost nobody uses unless they control the client, such as mobile apps.

I thought HPKP is TOFU, not (necessarily?) preloaded? Meaning you don't need to control the client for the client to be able to take advantage of it?

There might be a small preload list for HPKP. I'm pretty sure google uses key-pinning on their domains on chrome. Not sure if they use HPKP for that though.

I think chrome now ignores HPKP headers, and only respects the pre-load list. The risk of someone hijacking a domain, and inserting a malicious HKPK header had become too high.

HPKP can be either TOFU or preloaded. Google maintains a preload list that is included with Chrome, Firefox, Opera, Safari, IE 11 and Edge, but that is not a scalable solution for the future.

This came up when the root servers for .io were hijacked. It's really the same problem. Short of monitoring for such anomalies, the only saving grace would be HPKP which is just too risky to use outside of mobile apps. Why the attackers in this case didn't get valid certs, I have no idea. It takes seconds to get a wildcard now.

(For those like me who may not be familiar with the acronym, TOFU = Trust On First Use)

One could argue that in a perfect world the combination of DNSSEC and CAA should stop attacks of this nature. However, this only holds up under a rather limited set of circumstances:

1. The targeted domain would need to make use of both DNSSEC and CAA in the first place. I doubt that's true for more than a tenth of one percent of all domains out there.

2. The attackers would have to only target DNS resolution, and not the IP ranges hosting the targeted domain itself.*

3. Every single CA out there would have to follow the Baseline Requirements to the letter and fail closed for DNSSEC-enabled domains.†

I'm not sure if that makes for a good argument in favour of wading into the cesspit of DNSSEC.

* By targeting the IP ranges the site is hosted at, rather than the authoritative DNS, an attacker would be able to complete a "Agreed-Upon Change to Website" challenge as defined in the Baseline Requirements (http-01 in ACME). There's work being done to somewhat mitigate this by extending CAA to support whitelisting domain validation methods.

† From what I recall, when researchers looked into this this shortly after CAA became mandatory for CAs, a number of CAs were found to have issues with DNSSEC enforcement. Additionally, some argued the language in the Baseline Requirements regarding CAA and DNSSEC was quite ambiguous.

If you have DNSSEC with CAA, you can use that to choose a CA which has a contractual relationship with you. That contract can say anything you both like, for example it can say:

"All issuances under example.com shall first be approved by telephone call to our security office on 1-234-567-8900, and the certificate issued shall have a notBefore timestamp no earlier than 24 hours after an SCT included in the certificate"

This requires no new technology that I can see. If CAA and DNSSEC work together as intended (which I admit is a big "If" but they can and should) the Bad Guys now need to mess with the phone system for approval, then wait past the MMD and hope you aren't watching for their shenanigans. Or break into a CA and issue for themselves. That's a much higher bar, albeit at great cost.

If the DNS servers providing that message are hijacked due to BGP, the hijacker can simply not serve that notice and the registrar doing the lookup would never see it.

This is under the assumption that CAs fail closed when they encounter DNSSEC errors (which, by some interpretations, is mandatory according to the Baseline Requirements).

Merely hijacking the authoritative DNS for a domain does not defeat DNSSEC, which chains from the root to TLDs to registered domains. In other words, and assuming all CAs are perfect w.r.t DNSSEC, you cannot spoof a "No CAA record here" response for a DNSSEC-enabled domain merely by hijacking the authoritative DNS or a resolver.

Assuming that all CAs are perfect w.r.t DNSSEC is a big assumption to make. has anyone tried verifying that for every CA?

I also had been referring more to CAA than DNSSEC. It is a premium feature at certain registrars such as GoDaddy, which hinders adoption.

Yes, but under such a scheme, once I’ve wrestled control back of DNS, your ability to use those ill-gotten certs is reduced/eliminated.

Today, if I got a basic cert for your domain by temporarily hijacking DNS, I can later use it to MITM you even without DNS poisoning/takeover.

None of these steps would help against a BGP hijack since the IP address space itself is being stolen, not just the domain name. Heck, with a good hijack, the attacker could even get himself a valid automated certificate from let's encrypt.

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?

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.

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

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

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/

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

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

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

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

Choosing a particular CA doesn't help, since attackers can pick whichever CA is optimal for their attack.

> * Pick a preferred SSL issuer and stick with them. Add a CAA DNS record only allowing that one issuer.

It may be worth also suggesting HPKP here. That would be effective for many customers.

> * DNSSEC? Make sure to choose an SSL issuer that will correctly test DNSSEC?

This basically means you can't use Route53, which is a deal-breaker for a lot of people running services.

GCP supports DNSSEC, I moved all my domains away from Amazon due to this

was very easy to setup on GCP too

I thought HPKP was essentially deprecated - too many footgun scenarios and not enough specificity on "what to pin" since CAs can use / issue with multiple intermediates.

There are definitely a series of foot-gun-y scenarios with HPKP, just as with full DNSSEC. It's just one of the few things I can think of that gives you the ability to detect when a cert has changed unexpectedly.

Use cloudflare. Unlike Amazon, their DNS is free and it is supposed to be among the fastest.

Then again, DNSSEC is useless against a BGP hijack where the nameservers for the domain are replaced with malicious ones.

Believe me, I'd very much like that. I'm better aware than most of their technical capabilities and speed.

When I say "a lot of people running services", I don't mean me. I mean a lot of people I know and associate with. A lot of them have grown to rely on close integration between DNS and all their other infrastructure services. That CF covers them technically isn't helpful - they expected it all under one roof and they need to not spend cycles on thinking about something marginal to them like DNS.

One of the biggest selling-points of AWS is that it puts all your services in one spot. It limits orchestration work and makes life simpler. Asking people to leave that for security improvements may be necessary, but it's not a small ask.

A CAA DNS record won't help much if the attacker can just go to the certificate issuer and request a valid SSL certificate because they own DNS. Plus can't they just change the CAA DNS record?

If you are using DNSSEC, hopefully the issuers are validating it.

I'm not able to find any information on Let's Encrypt and DNSSEC validation. Anyone know if they validate it?

Yes, (last I checked at least) Let's Encrypt validates DNSSEC, this causes problem periodically for users who expected something to work but the DNSSEC setup is wrong and they never noticed before because nothing checked.

If you have DNSSEC that protects against CAA spoofing, that should also protect against A-record spoofing. Unless we fail open on A records but closed on CAA records.

For ultimate protection, add HTTP Public Key Pinning (HPKP) as well.

Warning: this is only to be used by experts. Otherwise, your site is going to become permanently/long-term inaccessible by the browser if you screw up just once.

An Expect-CT header would have mitigated this attack (but not for new users).

MyEtherWallet (which was the target) has an EV SSL certificate. That could be why they couldn't get it as easily.

Sorry, why couldn't they just replace the EV certificate with a regular "valid" certificate that they purchased from a valid CA if they controlled DNS and thus email?

Reply on news.ycombinator.com