Hacker News Reader

Comment by xutopia | Hacker News Reader

The one thing stopping adoption for a lot of people is wilcard support.

https://community.letsencrypt.org/t/please-support-wildcard-...

It's been discussed in details here the reason why they don't support wildcard: "doing domain validation for wildcard certificates is not currently in the ACME spec because it's a hard problem."[1]

LetsEncrypt CA allows Subject Alternative Names (SAN), the true need for an unlimited sub-domains TLS cert vs. a SAN TLS cert is minimum, given Certbot's automation capability.

[1]: https://github.com/certbot/certbot/issues/66#issuecomment-16...

SAN isn't a practical solution for cases where you don't want to expose which subdomains exist, or where you allocate them dynamically.

Unless all your subdomains are unique (e.g. coming out of a PRNG) AND there are no public DNS entries for them, subdomain enumeration by DNS or IP space is super easy. Not using SAN because of info disclosure concerns is security through obscurity.

Well yes, that's the idea: Say you have a wildcard DNS entry and you cryptographically-randomly-generate hostnames in it, as an added layer of defense against CSRF bugs in the applications running on these hosts.

https://docs.sandstorm.io/en/latest/administering/wildcard/#...

That doesn't prevent domain enumeration for your application though. Once you publish an application, anyone using it can find the address its hosted behind

> publish

Sandstorm is a platform for personal computing; each person runs their own applications, much like in a PC. Also, applications don't get hostnames; each document (or equivalent) in the application gets its own hostname.

It's even finer-grained than that. Each session gets a hostname -- if you open the same document twice, it's at a different hostname each time. This also implies that different users get different hostnames, so you can't discover the host another user sees even if you have access to the same document.

Isn't that insecure because hostnames are sent in the clear? (both in TLS handshake and DNS lookup?)

The hostnames aren't authentication, just another layer of defense, mostly against JavaScript attacks (e.g. from hacked applications): https://docs.sandstorm.io/en/latest/administering/wildcard/#...

Right, this is about mitigating the damage when apps have a bug -- risk management. Instead of being exploitable from anywhere on the internet, the bug becomes exploitable only by attackers who have a passive network MITM, which, while possible, is a very high barrier.

For such applications, there are plenty of relatively inexpensive paid options for wildcard certs. I don't think this is something Let's Encrypt should solve. I'd rather see them invest more time into supporting dynamic dns provider domains better, which imho is a much larger issue for small/hobby/free projects.

I'm ready to pay a reasonable amount for a wildcard cert to use with some hobby projects. Is there a trustworthy cheap wildcard cert provider which is not Comodo?

Have you checked StartSSL? They've worked fine for me.

What's the problem with dynamic dns provider domains?

I mean domains on no-ip, freedns, dyndns and the like.. that are subdomains are more likely to hit the default limits with Let's Encrypt... I'd like to see some auto-whitelisting for some of the more popular ones.

I thought sandstorm was a self-hosted thing. Why do the certs need to be signed by a public CA at all? A self-signed certificate is fine (and in some ways better than a public CA) when you can verify the source yourself because you generated it.

Sure, you can use a self-signed cert, if you don't mind going through the process of installing the cert into every browser that you'll use to access the server.

But Sandstorm is designed for sharing and collaboration. For example, you might write a document in Etherpad which you want other people to comment on. It may be tough to get the right certificate into all your friends' and family's browsers.

(Note that Sandstorm actually provides free wildcard certificates if you are OK with using a subdomain of sandcats.io.)

At which point we're back to my original point of why does the information disclosure matter?

Defense-in-depth against CSRF attacks, which are still way too common. Sandstorm can't security-review the apps for you but it can mitigate most vulnerabilities.

I would like to add that security through obscurity is not bad when it used as layers in the security cake. Delicious red velvet cake with cool fluffy chocolate frosting and a side of ice cream.

If it doesn't count as secure unless there's perfect information transparency, most of cryptography is based on "security through obscurity."

Wildcard certificates have significant constraints of single level of the subdomain matching and security risks[1], putting side the debate of the real benefits of "not exposing subdomains".

[1]: https://tools.ietf.org/html/rfc6125#section-7.2

A good example is the Sandstorm platform, which fits both cases.

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.

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.

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)

Are you saying you're OK with co.uk getting a cert for foo.co.uk, even though they're under different administrative control? I'm not OK with that.

I understand that other CA's provide wildcard certs, but frankly I see them as a giant problem. It's bad enough that I only have to have something listening on port 80 to prove that I control a domain. Let's not make it more attractive for people to start fooling Let's Encrypt into getting certs for domains they don't control.

CAs are forbidden from issuing a cert for * .co.uk. The Baseline Requirements say:

> The CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a "registry-controlled" label or "public suffix" (e.g. "* .com", "* .co.uk", see RFC 6454 Section 8.2 for further explanation).

This basically means that the CA should check the Public Suffix List before they issue a wildcard.

As a 'just in case' measure, most modern browsers also reject certs where the wildcard is directly below something on the PSL.

(sorry for the spaces after the asterisks, HN seemed to like converting big chunks of the post to italics)

So pick a different DNS zone that isn't in the PSL but that is not an administrative boundary. They exist.

The Public Suffix list is an imperfect maintained list. You're relying on Mozilla to maintain it. You also never know if someone is selling names below their own zone. What if Mozilla decides to no longer maintain it? What if the volunteers stop maintaining it?

Maybe the PSL is a good start, but I would rather not rely on it. It's a convenience vs. security balance issue, and I'm leaning towards security.

> Are you saying you're OK with co.uk getting a cert for foo.co.uk, even though they're under different administrative control?

This argument hasn't been made, or hinted at, by anyone, anywhere in this thread. And $50 isn't the difference between that being possible or not.

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.

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

Wildcards are in the version of the ACME spec at https://letsencrypt.github.io/acme-spec/:

> A server MAY consider a client authorized for a wildcard domain if it is authorized for the underlying domain name (without the “*” label).

Although this seems to be gone from https://ietf-wg-acme.github.io/acme/, which I think is the later version.

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 certificates on the fly in response to user signups.

[1]: https://letsencrypt.org/docs/rate-limits/

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.

I deploy all the different little code projects I make to different domains and I've hit the Let's Encrypt rate limit. If (like me) you waited a couple months to secure these little side projects, you'll hit the rate limit too. That being said, I just waited a week -- now everything is secure.

I'd imagine you might be able to reach out to them in that case.

Even with good tooling the current restrictions on Let's Encrypt make it impossible, you can batch many subdomains into 1 request however if you're requesting subdomains by customer username or similar, you can't exactly wait around to batch them. And you can only make a maximum of 5 requests per week, so unless you're incredibly tiny it's non-viable.

I don't understand why Let's Encrypt can't consider validation of the root domain good enough to produce a wildcard. Email at the root domain is what most providers use, not exactly much worse.

EDIT: It's now 20 per domain per week, better but still not viable for even a mid scale operation. A single wildcard is a much nicer and easier to maintain solution in any case.

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.

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

Maybe: games.example.com/foobarbarz instead of foobarbaz.example.com?

how would this help? Like Plex each game is running a local webserver on a user's home computer/apple tv/android tv/etc. It's those devices that need the certs in order to serve content to browsers on player's smartphones.

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.

I feel like this is one of those "faster horse" moments.

You don't need a wildcard cert! Just get certs for each one of your subdomains, even internally.

I get where you're coming from but I depend on a subdomain for each one of my user signups and we're talking thousands. LE limits us to 100 subdomains on a single cert and would require a restart for each signup. I'll definitely be using LE for other projects but many use cases require wildcards.

And most of those wildcard use cases are business sites/applications that can/should just buy a wildcard cert. That said, I wouldn't mind seeing better support for the freedns/dyndns subdomains.

Some people are using dynamic dns records, so the list of subdomains is not static. This is where wildcard ssl is perfect. And what if you have hundreds or thousands of subdomains? It unnecessarily bulks up your configuration as you have to do a cert per site instead of a single one.

Check out GlobalSigns Cloud SSL product if you want a cert that can mix wildcards with top level SANs....not free but....https://www.globalsign.com/en/cloud/

Or AWS Certificate Manager for free if you use AWS.

Reply on news.ycombinator.com