Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

Post reply on HN
Print view View original

291–300 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#291

Post by schoen »

peterwwillis wrote: post #286
schoen wrote: post #231

Earlier quoted context omitted.

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 d…

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

Re: ACME v2 and Wildcard Certificate Support is Live

#292

Post by slrz »

merb wrote: post #263
slrz wrote: post #198

Earlier quoted context omitted.

You can use Let's Encrypt certificates for non-publicly reachable hosts by using the dns-01 challenge type. That, of course, means that you need some way of properly automating your DNS infrastructure to add the necessary TXT records which, admittely, is sadly not the case in many organizations. It's a solvable problem, though. I don't understand your last point. Where do you see the problem with letting a reverse pr…

Well the last point means that I need to rollout the cert to multiple servers (as the poster below writes)

In the most common setups, the reverse proxy usually terminates the TLS session and uses a different connection to make requests to the backend servers (e.g. nginx proxy_pass directive).

This means the backend server certificates are only ever exposed to your reverse proxy. There's no need to use publicly-trusted certificates for that. Just generate your own ones and make them known to the proxy (either by private CA cert or by explicitly trusting the public keys).

Re: ACME v2 and Wildcard Certificate Support is Live

#293

Post by slrz »

rkistner wrote: post #260
kyledrake wrote: post #7

First, congrats, this is great news! There's a lot of use cases out there that require a wildcard cert or work far better with them. > It is our intent to transition all clients and subscribers to ACMEv2, though we have not set an end-of-life date for our ACMEv1 API yet. Please don't do this. It will break millions of sites needlessly. Most installations of lets encrypt plugins aren't going to auto update to v2. A lo…

They already disabled TLS-SNI-01 for new certificates because of security issues [1]. This was a major breaking change, without any advance notice, but nothing melted down. I'm sure the other validation endpoints are used a lot more, but the effect shouldn't be any different, especially if give a deprecation notice of a year or two. [1]: https://community.letsencrypt.org/t/important-what-you-need-...

While there was no world-destroying core meltdown, it was still super-annoying to deal with. Lots of code needed to be touched. I'd really like a comeback of a fixed TLS-SNI challenge as running a port 80 HTTP server just for LE sucks somewhat.

DNS challenges exist and are useful but have more extensive infrastructure requirements. Nothing beats the ease of use of "just put the box up and it'll retrieve its cert as needed".

Re: ACME v2 and Wildcard Certificate Support is Live

#294

Post by peterwwillis »

snowwolf wrote: post #287
peterwwillis wrote: post #284

Earlier quoted context omitted.

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

Re: ACME v2 and Wildcard Certificate Support is Live

#295

Post by mynameisvlad »

Karunamon wrote: post #270
mynameisvlad wrote: post #195

Earlier quoted context omitted.

Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening. Basically, I see it this way: - You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause th…

As less and less content is served over HTTP, it becomes more and more realistic for an attacker to simply inject their garbage into every unencrypted connection that has a browser user agent in it. Consider the websites you view every day.. most of them are probably HTTPS by now. It's the wild west, basically. Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can scr…

> As less and less content is served over HTTP, it becomes more and more realistic for an attacker to simply inject their garbage into every unencrypted connection that has a browser user agent in it.

I've already covered the general case above. Anyone in a position to intercept HTTP communications like that (into every unencrypted connection) is in a position where if they intercept and do enough to materially harm me or my users through their act, then they will likely be discovered and the world will turn against them. They have far more to lose than to gain by doing something actively malicious that can be perceived by the user. So I don't realistically see it happening.

> Regardless of how likely it is that someone is waiting for you to hit a HTTP site right now so they can screw with it, why even take that risk when the alternative is so easy?

I already said I use HTTPS, so your advice isn't really warranted. I also specifically asked how likely it is, so you can't just "regardless" it away. I get that there's a theoretical risk, and I've already addressed it. But as a thought experiment, it is helpful to know how realistic the threat actually is. So far, I haven't really been convinced it actually is anything other than a theoretical attack vector.

Re: ACME v2 and Wildcard Certificate Support is Live

#296

Post by peterwwillis »

schoen wrote: post #291
peterwwillis wrote: post #286

Earlier quoted context omitted.

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 d…

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

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.

Re: ACME v2 and Wildcard Certificate Support is Live

#297

Post by schoen »

peterwwillis wrote: post #296
schoen wrote: post #291

Earlier quoted context omitted.

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

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

Re: ACME v2 and Wildcard Certificate Support is Live

#298

Post by mjrpes »

slrz wrote: post #246
mjrpes wrote: post #242

Earlier quoted context omitted.

I'm in the same boat. I haven't found a guide for an easy and flawless way to automate cert renewal with letsencrypt when you use multiple services over different servers. For my wildcard, I use the same cert for: 1. Ubuntu VPS #1: a. dovecot ssl b. postfix ssl c. apache multiple virtual domains ssl d. pureftpd ssl 2. Ubuntu VPS #2: a. apache multiple virtual domains ssl 3. Microsoft Server a. IIS multiple virtual do…

Why does it have to be the same cert on every host? Use a separate cert for each and automation will be much easier. With Let's Encrypt, you don't need to minimize the number of certs just to save some money.

I'm just saying how I'm running things now. Totally open to better ways. Right now I pay $135 for a two year wildcard cert (very small business here). It takes 1 hour of my time to update the cert for all these applications. 1 hour of time and $135 every two years is not a lot. When I do a cursory look of how to reliably automate letsencrypt across all applications, there are people who have created scripts that help, but it does not give me reassurance that everything will run smoothly every 90 days. I am waiting for letsencrypt to get first-class support in dovecot, postfix, pureftpd, and IIS, so it can be set and forget, and I know long term support will be there.

Re: ACME v2 and Wildcard Certificate Support is Live

#299

Post by telcal »

Jaruzel wrote: post #80
Jaruzel wrote: post #74

One of the wonderful aspects of this, that no-ones pointed out yet, is that these can used for INTERNAL domains, without you having to run your own internal CA. i.e. lets say your internal network DNS domain is 'my-company-lan.com' - all you have to do is ensure that 'my-company-lan.com' is also registered in public DNS[1], and then you can secure ALL your internal services using a free LE wildcard cert, that's autom…

Going to reply to my own comment here. It's at this point that I swear profusely at Microsoft yet again, for pushing the concept of '.local' domain suffixes a decade ago. As it's not a legal TLD, I can't get certs for any of my internal services without rolling my own internal CA, which only works automatically for Windows domain machines, and not for anything else.

Can you create a CNAME on your internal DNS so server1.company.local = server1.company.com?

Found here: https://community.spiceworks.com/how_to/139715-letsencrypt-w...

Re: ACME v2 and Wildcard Certificate Support is Live

#300

Post by peterwwillis »

schoen wrote: post #297
peterwwillis wrote: post #296

Earlier quoted context omitted.

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 somethin…

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.

Post reply on HN