Let's Encrypt root certificate trusted by Mozilla • Hacker News Board

Re: Let's Encrypt root certificate trusted by Mozilla

#131

Post by tracker1 » Fri, Aug 05, 2016, 10:53 PM UTC

duskwuff wrote: post #80

chc wrote: post #60

Earlier quoted context omitted.

People distrust it because it's 99% spam?

.info is really not all that bad, in the grand scheme of things. .biz is much worse (and has been since its launch in 2001!), and some of the new TLDs like .top and .xyz have been abused pretty heavily as well.

I actually like the .info tld... perfect domain for "informational" websites, wikis etc. Though there may be better ones with the recent goldrush of new tlds available.

Though I also liked .io, and felt the higher pricing and harder registration kept a lot of the squatters away.

Re: Let's Encrypt root certificate trusted by Mozilla

#132

Post by mieko » Fri, Aug 05, 2016, 10:56 PM UTC

teraflop wrote: post #46

mholt wrote: post #33

Earlier quoted context omitted.

I spoke about this earlier this week at a meetup. The consensus in the group was that wildcard certificates are desirable because they're easier to manage. If your tooling is good, the automation afforded by ACME can invalidate the need for wildcard certificates.

The problem is that Let's Encrypt enforces rate limits on how frequently you can request new certificates. According to the documentation[1], the limit averages out to one certificate (which can include up to 100 hostnames) per roughly 8 hours, per domain. That's probably good enough for almost everyone who uses hostnames to represent physical machines or services. But it's totally unusable if you want to create cert…

This is the real issue with not allowing wildcard certs. If the rate limits were something that just cut in at abuse-levels, there'd be no need for them. Sites with per-user subdomains (to get security features like cookie isolation, break same-origin effects, etc) run into the limits really quickly, and must currently rely on a wildcard.

I've been calling this "the tumblr scenario", but people seem to think there's a way around it without just using another CA.

Re: Let's Encrypt root certificate trusted by Mozilla

#133

Post by rahkiin » Fri, Aug 05, 2016, 11:24 PM UTC

mieko wrote: post #130

illumin8 wrote: post #115

Earlier quoted context omitted.

It's because once someone has a wildcard cert they can use it anywhere, in malicious ways: phishing emails that send you to bankofamerica.banking.io or other nefarious type of things.

If I operated banking.io, I could get a bankofamerica.banking.io cert from LetsEncrypt today. Unless something has changed, I could also get bankofamerica.com.banking.io, from LE or many other CAs. The wildcard issue has no effect on this situation.

Problem is, that if ypu can prove you have access to someuser.github.com, it does not mean you have access to .github.com. Reversely, if you have access to .cs.mit.edu you might want a cert for it. So you cant give a wildcard using one subdomain test, nor can you simply test every domain. So they are looking in DNS verification. Given you have access to dns. But that also gives problems, as shown above.

Tldr: one verification limits another use, while another verification might expose domains that shouldnt be.

Re: Let's Encrypt root certificate trusted by Mozilla

#134

Post by mieko » Fri, Aug 05, 2016, 11:47 PM UTC

rahkiin wrote: post #133

mieko wrote: post #130

Earlier quoted context omitted.

If I operated banking.io, I could get a bankofamerica.banking.io cert from LetsEncrypt today. Unless something has changed, I could also get bankofamerica.com.banking.io, from LE or many other CAs. The wildcard issue has no effect on this situation.

Problem is, that if ypu can prove you have access to someuser.github.com, it does not mean you have access to .github.com. Reversely, if you have access to .cs.mit.edu you might want a cert for it. So you cant give a wildcard using one subdomain test, nor can you simply test every domain. So they are looking in DNS verification. Given you have access to dns. But that also gives problems, as shown above. Tldr: one ver…

That's not how domain-validated wildcard certificates from any CA have ever worked, and it's not how any proposed wildcard-supporting future LetsEncrypt would work.

I can, today, get a valid certificate for myname.github.io (getting GitHub to serve it is a different issue, but from an MITM, proof of ownership, and CA/Browser Forum standpoint, it's properly assigned.) That's not surprising or weird, and it's exactly how it's supposed to work.

A certificate for myname.github.io does not give me a valid certificate for someone-else.github.io or github.io. Similarly, a certificate for '* .myname.github.io', which can also be procured today from dozens of CAs, doesn't cause panic or change the situation at all. I just can't get it from LetsEncrypt.

If I can only prove control of 'cs.mit.edu', I can get a certificate for '* .cs.mit.edu', but not all of 'mit.edu'. If I can prove ownership of 'mit.edu', I can get a certificate that covers '* .mit.edu'. This is how it should and has always worked. It just doesn't work via LetsEncrypt.

Basically, heavier authority moves right, never left, in wildcard certificates.

(Edit: HN eating asterisks)

Re: Let's Encrypt root certificate trusted by Mozilla

#135

Post by haasn » Sat, Aug 06, 2016, 12:11 AM UTC

lucb1e wrote: post #85

Walkman wrote: post #62

Earlier quoted context omitted.

With Let's Encrypt, the trouble became "Whoaaa I just ran a command and everything works like magic!"

Yeah until two hours later when you notice it messed with random shit it wasn't even supposed to touch. At least, that was my experience; I suppose it depends on how common your setup happens to be. I still love Let's Encrypt for its principle, but I don't dare running it in full auto mode anymore. A few custom shell scripts get the job done easily enough.

There's always the option of running certbot in certonly mode - in fact, that's what I do for the majority of my setups (mostly because certbot doesn't support nginx).

Re: Let's Encrypt root certificate trusted by Mozilla

#136

Post by pfg » Sat, Aug 06, 2016, 12:16 AM UTC

tracker1 wrote: post #128

fredsted wrote: post #89

Earlier quoted context omitted.

The auto mode just confused me. Every setup is different. Some use Apache, nginx, or both -- and proxied behind Haproxy or varnish. Then there's stuff like cpanel or virtualmin. So you got to expect any combination of those -- one or more, or combined. Their scripts would have to accommodate for so many different things. How could I anticipate what it would do? Am I missing something that would make this magically wo…

Depends on where you want SSL termination, and if you want it federated out... The default Let's Encrypt project(s) integration tooling afaik isn't used by many people, but there have been a lot of tools to do more simple ACME integration into various web servers, reverse proxies and other configurations. It's pretty cool. I'm overall, very happy that it works at all... Some things I'd like to see... Namely, automati…

Dynamic DNS providers that are on the Public Suffix List are essentially treated like TLDs in terms of rate limiting, meaning each client subdomain has a separate counter. They should probably be on the PSL anyway; browsers rely on it for cookie scoping.

Re: Let's Encrypt root certificate trusted by Mozilla

#137

Post by pfooti » Sat, Aug 06, 2016, 12:20 AM UTC

xutopia wrote: post #15

The one thing stopping adoption for a lot of people is wilcard support. https://community.letsencrypt.org/t/please-support-wildcard-...

While there's reasons for wildcard support, I find the support for SAN and just many certs to be just fine in a lot of ways. I've purchased wildcard domains in the past mostly because it was more cost-effective than buying the individual mail, testing, www, and so on subdomains, especially if there's a cost associated with adding more subdomains later.

Having a scriptable renewal process and no real cost associated with getting additional subdomains on the cert (besides operator time) covers some significant portion of the generalized need for wildcard domains. I know there's other reasons, sure. But it's definitely not stopping me.

Re: Let's Encrypt root certificate trusted by Mozilla

#138

Post by greggman » Sat, Aug 06, 2016, 1:20 AM UTC

xienze wrote: post #113

GhotiFish wrote: post #91

Earlier quoted context omitted.

This 100% blocked me. I tried to work around it by using lets encrypt to provision me certificates on the fly, but I got rate limited. Then I started speccing out a way to get single certs for many subdomains in one request using SAN, and the whole thing looked like it would require more development time compared to just buying a wildcard cert. Very frustrating.

I mean it kind of makes sense doesn't it? If you need enough certs (> 20 per week) to hit the rate limit, you're probably running some sort of business -- in which case you probably shouldn't be depending on a free service and can likely afford the cost of wildcard certs.

I'm not running a business. I'm writing an open source library that needs certs because browsers are banning features unless served from https

http://docs.happyfuntimes.net

One cert per game * one hit game = need 10s of thousands of certs. But even without a hit game a single game jam would hit the limits

For reference here is an example of a similar problem and solution but it required $$$$$$

https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

PS: I know this is not a problem with Lets Encrypt. They are not trying to solve this problem.

It is a problem that needs a cheaper solution at least for open source projects.

Re: Let's Encrypt root certificate trusted by Mozilla

#139

Post by eeeeeeeeeeeee » Sat, Aug 06, 2016, 1:26 AM UTC

illumin8 wrote: post #115

__david__ wrote: post #112

Earlier quoted context omitted.

Any idea what makes it a hard problem? I see nothing that actually explains the issue.

It's because once someone has a wildcard cert they can use it anywhere, in malicious ways: phishing emails that send you to bankofamerica.banking.io or other nefarious type of things.

But you can get these at other providers already. And I haven't seen many phishing pages with SSL, it's usually always HTTP.

Re: Let's Encrypt root certificate trusted by Mozilla

#140

Post by eeeeeeeeeeeee » Sat, Aug 06, 2016, 1:29 AM UTC

rahkiin wrote: post #133

mieko wrote: post #130

Earlier quoted context omitted.

If I operated banking.io, I could get a bankofamerica.banking.io cert from LetsEncrypt today. Unless something has changed, I could also get bankofamerica.com.banking.io, from LE or many other CAs. The wildcard issue has no effect on this situation.

Problem is, that if ypu can prove you have access to someuser.github.com, it does not mean you have access to .github.com. Reversely, if you have access to .cs.mit.edu you might want a cert for it. So you cant give a wildcard using one subdomain test, nor can you simply test every domain. So they are looking in DNS verification. Given you have access to dns. But that also gives problems, as shown above. Tldr: one ver…

You can require that the validation DNS record exists on the root domain (mit.edu) to prove you control the entire domain. I think there are ways to fix this.