5 ms·

Why is providing wildcard certs not secure???? Amazon seems to do it?

eropple 9y ago
Because once your wildcard certificate is compromised--and you must design systems with the assumption that your certificates will be compromised--it becomes a very achievable exercise to use that wildcard certificate to compromise users going to any of your subdomains. With each domain governed under its own TLS certificate, you install firebreaks between systems to contain the damage an attacker can do. There are vanishingly few reasons to ever share private keys across multiple automated systems. This is not one of them. (Are your systems not automated? Fix that.)
- tokenizerrr 9y ago
  Meanwhile SAN is fine? The alternative to wildcards is that you get a single cert with tons of subdomains as alternative name. Exact same risks, yet much more hassle to add subdomains. I don't see it.
  - eropple 9y ago
    That's a fine point, if you're using SANs. With Let's Encrypt, you don't need to use a SAN so long as each of your endpoints is distinct. (If they're not, I'm uneasy with your architecture in the first place, y'know?) However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists.
    - tokenizerrr 9y ago
      SNI is not yet always an option if you have to support older clients. It's not about if I'm using SANs anyway. It's that LE is fine with that, but not with wildcard certs. > However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists. Can you elaborate what you mean here?
      - eropple 9y ago
        If you have to support older clients--definitely, SAN is your only option if you have to run on the same host. (And I sympathize, because that sucks.) At that point, though, my inclination becomes to attach a bunch more public IPs and wire up my DNS correctly to match. > Can you elaborate what you mean here? Me saying "this cert is valid for example.com, foo.example.com, and bar.example.com" is an incrementally better security posture than saying "this cert is valid for *.example.com". It constrains an attacker from running a phishing attack from, say, "private.example.com" or "secure.example.com". You're whitelisting what you're covering by explicitly declaring all of them. It is incremental, but it's a thing.
        tokenizerrr 9y ago
        IPv4 addresses are relatively expensive. I encounter it quite often where a wildcard gets pointed to a single server (with single IP) which hosts multiple services. There are no security issues compared to a large SAN that I can see in such a situation.
        eropple 9y ago
        I would submit, respectfully, that you're not being creative enough. When it comes to security, including phishing, it behooves all of us to not assume that permissiveness is a de facto positive.
        tokenizerrr 9y ago
        Very helpful. Thanks.
- philliphaydon 9y ago
  So the Low risk of compromise for most people is more important than the ability to easily maintain a system? If a certificate is going to be compromised it's most likely going to be the most important cert to the system anyway. A hacker isn't going to go after the meaningless ones. But by your logic I should increase the maintainability of the system for no benefit. Obviously this is highly dependent on the usage of the certs to begin with.
cyphar 9y ago
Yes, many services "seem to do it". The problem is how do you safely verify that a wildcard certificate is actually being given to the owner of that domain space? It's "trivial" to provide a certificate for a particular domain is owned by someone, but the same techniques don't work for wildcard certificates because now you're verifying only a single domain and providing certificates for an entire class of domains. If you work through all of the ways ACME verification works (/.well-known/, DNS, and so on) you can come up with several plausible setups that become insecure if you allow wildcard certificates. Here's a stack exchange question about it: https://security.stackexchange.com/questions/157972/why-cant-lets-encrypt-support-wildcard-certificates https://security.stackexchange.com/questions/157972/why-cant....
- tokenizerrr 9y ago
  That SO post makes no sense to me. It claims: > The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either. This just seems wrong. Performing the check like that seems to be a sane way to do it. If people can't control the base domain they have no business requesting a wildcard cert.
  - cyphar 9y ago
    But *.a.com doesn't cover a.com, so it's not very clear that the inverse ownership relationship should hold. Yes, it's true on a DNS level but that's one argument I would imagine against doing it that way.
    - tokenizerrr 9y ago
      No, but ownership of a.com heavily implies ownership of (wildcard).a.com (HN is being weird with the asterisk) Alternatively they could just do a DNS check. If you can configure DNS for a.com, you control *.a.com.
      - cyphar 9y ago

Because once your wildcard certificate is compromised--and you must design systems with the assumption that your certificates will be compromised--it becomes a very achievable exercise to use that wildcard certificate to compromise users going to any of your subdomains. With each domain governed under its own TLS certificate, you install firebreaks between systems to contain the damage an attacker can do. There are vanishingly few reasons to ever share private keys across multiple automated systems. This is not one of them. (Are your systems not automated? Fix that.)

tokenizerrr 9y ago
Meanwhile SAN is fine? The alternative to wildcards is that you get a single cert with tons of subdomains as alternative name. Exact same risks, yet much more hassle to add subdomains. I don't see it.
- eropple 9y ago
  That's a fine point, if you're using SANs. With Let's Encrypt, you don't need to use a SAN so long as each of your endpoints is distinct. (If they're not, I'm uneasy with your architecture in the first place, y'know?) However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists.
  - tokenizerrr 9y ago
    SNI is not yet always an option if you have to support older clients. It's not about if I'm using SANs anyway. It's that LE is fine with that, but not with wildcard certs. > However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists. Can you elaborate what you mean here?
    - eropple 9y ago
      If you have to support older clients--definitely, SAN is your only option if you have to run on the same host. (And I sympathize, because that sucks.) At that point, though, my inclination becomes to attach a bunch more public IPs and wire up my DNS correctly to match. > Can you elaborate what you mean here? Me saying "this cert is valid for example.com, foo.example.com, and bar.example.com" is an incrementally better security posture than saying "this cert is valid for *.example.com". It constrains an attacker from running a phishing attack from, say, "private.example.com" or "secure.example.com". You're whitelisting what you're covering by explicitly declaring all of them. It is incremental, but it's a thing.
      - tokenizerrr 9y ago
        IPv4 addresses are relatively expensive. I encounter it quite often where a wildcard gets pointed to a single server (with single IP) which hosts multiple services. There are no security issues compared to a large SAN that I can see in such a situation.
        eropple 9y ago
        I would submit, respectfully, that you're not being creative enough. When it comes to security, including phishing, it behooves all of us to not assume that permissiveness is a de facto positive.
        tokenizerrr 9y ago
        Very helpful. Thanks.
philliphaydon 9y ago
So the Low risk of compromise for most people is more important than the ability to easily maintain a system? If a certificate is going to be compromised it's most likely going to be the most important cert to the system anyway. A hacker isn't going to go after the meaningless ones. But by your logic I should increase the maintainability of the system for no benefit. Obviously this is highly dependent on the usage of the certs to begin with.

cyphar 9y ago

Yes, many services "seem to do it". The problem is how do you safely verify that a wildcard certificate is actually being given to the owner of that domain space? It's "trivial" to provide a certificate for a particular domain is owned by someone, but the same techniques don't work for wildcard certificates because now you're verifying only a single domain and providing certificates for an entire class of domains. If you work through all of the ways ACME verification works (/.well-known/, DNS, and so on) you can come up with several plausible setups that become insecure if you allow wildcard certificates. Here's a stack exchange question about it: https://security.stackexchange.com/questions/157972/why-cant-lets-encrypt-support-wildcard-certificates https://security.stackexchange.com/questions/157972/why-cant....

tokenizerrr 9y ago
That SO post makes no sense to me. It claims: > The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either. This just seems wrong. Performing the check like that seems to be a sane way to do it. If people can't control the base domain they have no business requesting a wildcard cert.
- cyphar 9y ago
  But *.a.com doesn't cover a.com, so it's not very clear that the inverse ownership relationship should hold. Yes, it's true on a DNS level but that's one argument I would imagine against doing it that way.
  - tokenizerrr 9y ago
    No, but ownership of a.com heavily implies ownership of (wildcard).a.com (HN is being weird with the asterisk) Alternatively they could just do a DNS check. If you can configure DNS for a.com, you control *.a.com.
    - cyphar 9y ago