3 ms·

> a considerable number of wildcard (*.huawei.com) certificates issued for whatever reason... Is there any downside to this? I mean, I have several wildcard ce

by oefrha 7y ago

> a considerable number of wildcard (*.huawei.com) certificates issued for whatever reason... Is there any downside to this? I mean, I have several wildcard certs issued for each of my personal domains mainly because it's more convenient to get separate certs on each host with certbot than trying to sync certs from one host to another. Is there any reason I shouldn't do this?

tialaramex 7y ago
Yes, but the downside may be acceptable to you. A bad guy who gets any of the private keys associated with any of these certificates can use that to impersonate any service with the corresponding name, even a quite different one. So say you've got mail.oefrha.example that's a mail server using a *.oefrha.example cert, and the Dread Pirate Roberts breaks into it, they can use that when impersonating your web server www.oefrha.example or your Q&A site faq.oefrha.example even if those are on totally different hardware that Roberts wasn't able to penetrate. For older TLS (or SSL) versions there's a trick called implied authentication used with RSA. After showing the certificate, instead of your server signing something to prove it knows the corresponding private key, the client sends something across which your server decrypts. Only the real server could decrypt it with the private key to continue the conversation so authentication is implied. However, in doing this your server has to be _extremely careful_, because it's easy to give away information when things go wrong. If it's not careful enough, a bad guy doesn't learn the key but they can use your answers to work out how you'd sign RSA messages. This means if you've got old-crap.oefrha.example which does TLS 1.0 with crappy RSA implied auth enabled so as to make it work with some rotten turn of the century tech, and it has a wildcard certificate, some bad guys can maybe exploit that to pretend they are www.oefrha.example even though your actual www.oefrha.example web server only speaks TLS 1.2 or newer with elliptic curves. You say a "personal domain", and I don't recognise your name, so chances are that this just doesn't matter. We're not talking about something a bored teenager can do, but if real bad guys with resources are attacking you, then it's probably not a smart idea to have so many wildcards. Edited: Repeatedly to try to get HN's half-arsed parser to stop ruining everything. Gave up. HN use a parser that has working escapes, or remove the parser and just say the site only has text too bad.
acdha 7y ago
Wildcard certificates are a greater risk since they can be used for things you didn’t intend, so a lot of it comes down to how scoped they are (a subdomain like *.app.eng.example.com is way less effective for phishing) and how hard it would be for an attacker to reuse them (e.g. there’s less risk if it’s generated on an HSM or something like AWS ACM which doesn’t allow the private key to be transferred). For a large organization, this probably just says that they have a lot of different systems and groups operating relatively independently with poor practices, which isn’t an immediate problem but suggests that they’re an easier target than some.

by oefrha 7y ago

tialaramex 7y ago

Yes, but the downside may be acceptable to you. A bad guy who gets any of the private keys associated with any of these certificates can use that to impersonate any service with the corresponding name, even a quite different one. So say you've got mail.oefrha.example that's a mail server using a *.oefrha.example cert, and the Dread Pirate Roberts breaks into it, they can use that when impersonating your web server www.oefrha.example or your Q&A site faq.oefrha.example even if those are on totally different hardware that Roberts wasn't able to penetrate. For older TLS (or SSL) versions there's a trick called implied authentication used with RSA. After showing the certificate, instead of your server signing something to prove it knows the corresponding private key, the client sends something across which your server decrypts. Only the real server could decrypt it with the private key to continue the conversation so authentication is implied. However, in doing this your server has to be _extremely careful_, because it's easy to give away information when things go wrong. If it's not careful enough, a bad guy doesn't learn the key but they can use your answers to work out how you'd sign RSA messages. This means if you've got old-crap.oefrha.example which does TLS 1.0 with crappy RSA implied auth enabled so as to make it work with some rotten turn of the century tech, and it has a wildcard certificate, some bad guys can maybe exploit that to pretend they are www.oefrha.example even though your actual www.oefrha.example web server only speaks TLS 1.2 or newer with elliptic curves. You say a "personal domain", and I don't recognise your name, so chances are that this just doesn't matter. We're not talking about something a bored teenager can do, but if real bad guys with resources are attacking you, then it's probably not a smart idea to have so many wildcards. Edited: Repeatedly to try to get HN's half-arsed parser to stop ruining everything. Gave up. HN use a parser that has working escapes, or remove the parser and just say the site only has text too bad.

acdha 7y ago

Wildcard certificates are a greater risk since they can be used for things you didn’t intend, so a lot of it comes down to how scoped they are (a subdomain like *.app.eng.example.com is way less effective for phishing) and how hard it would be for an attacker to reuse them (e.g. there’s less risk if it’s generated on an HSM or something like AWS ACM which doesn’t allow the private key to be transferred). For a large organization, this probably just says that they have a lot of different systems and groups operating relatively independently with poor practices, which isn’t an immediate problem but suggests that they’re an easier target than some.