Hacker News Reader

Comment by peterwwillis | Hacker News Reader

Without verifying who controls the IP space?

If you don't verify who controls the IP space, then if you can control the DNS, you can generate certs. Certs that appear valid to unsuspecting users.

Putting that kind of trust in DNS is pretty crazy considering how insecure most DNS setups are. Not to mention general attacks on DNS. There's even a potential chicken and egg problem, if you need DNS to secure your HTTPS, but you use HTTPS to manage your DNS.

What's really crazy too is it seems like this can't even be avoided. Even if I'm not using Let's Encrypt, if someone owns my DNS, they can use Let's Encrypt to get valid certs for my domain. That's insane.

What am I missing here?

View on HN

> What am I missing here?

If I "own your DNS" wouldn't I just change them all to an IP space I control anyway? (If that was a requirement).

Unless I'm missing something, requiring "owning the IP space" seems to be an impossible requirement to fulfil. I'm on a virtual host in Azure/AWS/Linode I have no way of proving I own the IP (because I don't).

https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-...

DNS security

As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates. Servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP.

An ACME-based CA will often need to make DNS queries, e.g., to validate control of DNS names. Because the security of such validations ultimately depends on the authenticity of DNS data, every possible precaution should be taken to secure DNS queries done by the CA. It is therefore RECOMMENDED that ACME-based CAs make all DNS queries via DNSSEC-validating stub or recursive resolvers. This provides additional protection to domains which choose to make use of DNSSEC.

An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed. It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for both CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.).

If you're concerned about DNS security you can use DNSSEC and Let's Encrypt will cheerfully require DNSSEC signed answers.

If your situation really is that you have unsecured DNS that routinely gets hacked and you just sort of muddle among somehow with users frequently getting phished, malware downloaders, and so on, well, I guess Let's Encrypt doesn't magically solve the trouble you've stepped in.

I'm not quite sure how to answer this. DNS is used as ground truth for an enormous amount of certificate issuance by a broad range of CAs. This has been true for many years. Let's Encrypt didn't invent domain validation or the notion of relying on DNS as a basis for issuing DV certificates.

Honestly, it just hadn't occurred to me at all that DNS was the only thing stopping a blackhat from generating valid certs and siphoning or modifying traffic without anyone's knowledge. And users literally can't stop this other than to only accept EV certs, breaking most of the web. This is pretty nutty.

At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed?

How do you add that public key to the WHOIS register - Via your domain registrar (and it would have to be updateable/changeable outside of renewal cycles). Who is your DNS provider 90% of the time? Your domain registrar...

> At the very least, a public key in WHOIS should be required to generate certs. Why in the world isn't this being done? And is there some way Let's Encrypt can start checking for this (to not issue invalid certs for domains that do list a public key), so maybe the above insanity can be stemmed?

I would welcome an authenticated channel to domain registrars, and I would welcome making checking it mandatory for CAs. I think the lack of this is an unfortunate gap, although I don't think we've seen the epidemic of misissuance that you've worried about.

In order to make this happen, it would probably require some coordination between ICANN and the CA/Browser Forum. You can become an Interested Party at the CA/Browser Forum yourself in order to propose this kind of mechanism, or you can find an existing Member or Interested Party to bring it up.

I already participate as an Interested Party and I could bring it up eventually but I'm currently working on certificates for Tor onion services, and I'd rather get that finished before taking on something else.

There may have been previous discussions of this idea in some forum, but I don't know for sure where.

By the way, DNSSEC plus DNS CAA can already allow a domain registrant to use cryptographic means to forbid issuance by unauthorized CAs, and checking this is already mandatory for CAs.

https://en.wikipedia.org/wiki/DNS_Certification_Authority_Au...

This can achieve some of what you want on the negative side, but it's presumably not all the way there.

Thanks for pointing that out, I wasn't aware of it.

From Wikipedia: "As of February 2018, Qualys reports that 2.9% of the 150,000 most popular websites use CAA records."

So, about 97% of the most popular websites are currently vulnerable to having valid domain certs generated for their domains if their DNS is compromised, or if the CA doesn't strongly validate DNS responses.

Yikes.

Well, again, DNS has been treated as the source of ground truth for many PKI purposes most of the time for years. It's not new to Let's Encrypt in any way. And it's been a requirement in order to achieve this:

https://letsencrypt.org/stats/#percent-pageloads

And domain registrants and site operators are extremely heterogeneous in ways that could make cert issuance extremely difficult if we made applicants do something new and manual, especially in the offline world.

On the other hand, I've also written skeptical articles about PKI and worried about the fragility of Internet security. Your concerns aren't misplaced, in that a lot of the stuff we rely on is super-fragile.

But in many ways, it's been getting better over time as CAs' power has been getting more and more circumscribed by new rules and technical mechanisms. We have Baseline Requirements amendments that give CAs less discretion in their operations and require more transparency from them. We have CT, we have CAA, we have must-staple, we have databases that researchers can use to find problems. (For a while we also had HPKP.)

So I'd urge you to take your passion about this issue and work on some more security mechanisms to improve the infrastructure, because there's lots more that can be done.

Also, if you come up with good new deployable mechanisms, Ryan Sleevi will be glad to help you make them mandatory for CAs. :-)

While I appreciate your encouragement, I really dislike the trend of everyone using HTTPS. It's wasteful, it's inconvenient, it's unnecessary, it's overly complex, and it doesn't even provide much real security. People still get hacked, corporations still leak data, the governments of the world continue to spy on our digital emissions. But HTTPS gives everyone a nice fuzzy comfy warm blanket of security to wrap themselves around and forget about the pale reality of life on the internet. (My apologies, I've been really into Russian literature lately)

I don't think anybody would want to implement the kinds of technology and solutions I would provide, because every time I bring them up (in forums like this one, and others), people either ignore them or argue against them, and I have no interest in pushing large boulders up hills.

But I would like to thank you for your work. I appreciate that you all are trying to make things better.

> it's inconvenient, it's unnecessary, it's overly complex, and it doesn't even provide much real security. People still get hacked, corporations still leak data, the governments of the world continue to spy on our digital emissions. But HTTPS gives everyone a nice fuzzy comfy warm blanket of security to wrap themselves around and forget about the pale reality of life on the internet.

Yes, it's inconvenient, and people will still get hacked, but it's also getting easier to do, it _does_ help, and as Snowden showed, encryption really does help deter governments from spying.

I think it's currently unfair to https websites that non-https websites aren't considered insecure.

How would you go about verifying the domain from who controls the "IP space"?

A cloud provider/datacenter controls the IP space in the majority of cases.

If someone owns your DNS, they can use almost any CA to get valid certs for your domain (apart from EV only ones). That's kind of how Domain Certs work. "A domain-validated certificate (DV) is an X.509 digital certificate typically used for Transport Layer Security (TLS) where the identity of the applicant has been validated by proving some control over a DNS domain"

If this is something that worries you, then you should only trust sites that have Extended Validation certificates.

> If this is something that worries you, then you should only trust sites that have Extended Validation certificates.

Every user of the web in the world would have to do this in order to avoid this vulnerability.

Exactly. Domain verified certificates guarantee one thing and one thing only. The data transmitted is encrypted and cannot be tampered with. That's it. They do not guarantee you are communicating with who you think you are.

But to be honest if your DNS service is compromised, you have bigger problems.

The thing is... it shouldn't be this way.

The whole point of TLS is to provide privacy, integrity, and authority. Having a secured connection is pointless if it's a connection to an attacker. Oh, great, nobody can spy on my connection to the NSA.

All DNS is supposed to do is to point you at the server to get your connection from. It isn't supposed to mediate the security of the connection.

This is back to the old chicken-and-egg of public key crypto: public key connections are secure, as long as you provide the initial host key in a secure, out-of-bound method. If an attacker can circumvent this and inject their own initial host key, they can MITM. Hence why PKI exists: to prevent an outside service from defeating the security of the connection. But apparently, DNS can compromise the connection, by allowing attackers to just generate certs willy-nilly if they can guess your GoDaddy account password.

By "verifying who controls the IP space", do you mean verifying control over the IP a domain resolves to? In that case, what you're missing here is that control over DNS lets you alter that IP address to whatever you'd like. The attacker will have no difficulty demonstrating control over an IP address they own.

Reply on news.ycombinator.com