4 ms·
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 wil
by 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 agoIf 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 agoIPv4 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 agoI 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 agoVery helpful. Thanks.