6 ms·

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

• Nullabillity 10y ago
  SAN isn't a practical solution for cases where you don't want to expose which subdomains exist, or where you allocate them dynamically.
  • icebraining 10y ago
    A good example is the Sandstorm platform, which fits both cases.
  • aroch 10y ago
    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.
    • kentonv 10y ago
      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/#why-sandstorm-needs-wildcard-dns https://docs.sandstorm.io/en/latest/administering/wildcard/#...
      • aroch 10y ago
        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
        • icebraining 10y ago
          > 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.
          • aroch 10y ago
            At which point we're back to my original point of why does the information disclosure matter?
            • kentonv 10y ago
              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.
          • kentonv 10y ago
            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.
            • collinmanderson 10y ago
              Isn't that insecure because hostnames are sent in the clear? (both in TLS handshake and DNS lookup?)
              • 10y ago
    • Jweb_Guru 10y ago
      If it doesn't count as secure unless there's perfect information transparency, most of cryptography is based on "security through obscurity."
    • deleted 10y ago
      [deleted]
    • LinuxBender 10y ago
      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.
  • deleted 10y ago
    [deleted]
  • devy 10y ago
    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 https://tools.ietf.org/html/rfc6125#section-7.2
• __david__ 10y ago
  Any idea what makes it a hard problem? I see nothing that actually explains the issue.
  • illumin8 10y ago
    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.
    • mieko 10y ago
      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.
      • rahkiin 10y ago
        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.
        • mieko 10y ago
          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)
• grahamedgecombe 10y ago
  Wildcards are in the version of the ACME spec at https://letsencrypt.github.io/acme-spec/ 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/ https://ietf-wg-acme.github.io/acme/, which I think is the later version.