5 ms·

While I agree that it is better from a security perspective not to issue long lived certificate and that automation would be best, I dislike the fact that the s

While I agree that it is better from a security perspective not to issue long lived certificate and that automation would be best, I dislike the fact that the subdomain of any certificate I issue becomes public due to Google's certificate transparency project. By making every subdomain public, it makes the job easier for any attacker wanting to try and find smaller servers to target. It's not that I believe in security through obscurity but besides making sure all servers are as secure as they can be, I do believe in not making the job easier for adversaries. So, instead I use wildcard certificates, and for this automation gets much more annoying, you need to use DNS to validate it (route 53 or similar does provide an api that can be used) and then I'm not sure if I'm confortable having each server generate their own wildcard certificate, leading to 100s of wildcard certificates... This is why I currently use old style 1 year wildcard certificate which gets updated through chef but I'm really not sure if this is the best solution or not.

iso1210 7y ago
Without certificate transparency how do you know nobody has issued a certificate for your server? Surely that's a far higher risk than knowing a domain?
- nicolas_t 7y ago
  oh, I completely agree that certificate transparency is beneficial for that and we have an alert setup. But, that still leaves me not wanting to leak every single subdomain we use internally. Hence using wildcard certificates.
  - njsubedi 7y ago
    Wouldn't it be a better idea to use alternate domains instead of subdomains? You could use something like [any subdomain].atdie8e73bhdbdie93ruhe.[any tld] for obfuscation?
    - saagarjha 7y ago
      Those cost money.
  - tialaramex 7y ago
    CT didn't change this for bad guys. If you're a bad guy (or a neutral researcher with a budget for the data) you can buy what's called "Passive DNS". Several suppliers will give you a list of DNS requests and their answers, the identifying information for who made the requests is elided so it's not PII but it has the same effect of making the fact servername.example.com exists in effect public information. Even if you are unusual in actually having machines named cy23hdc9.example.com not exchange2016.example.com then the existence of this service means you need to stop assuming nobody knows these names. Anybody who cares knows them.
    - xg15 7y ago
      Yes, which is why you used to be able to have fully internal domains that are served by an internal DNS server and are never seen on the public internet.
      - castillar76 7y ago
        You can still have this: it's called 'split-horizon' or 'split-brain' DNS. It can be tough to set up and maintain for large DNS environments, but not /that/ difficult even at that level. If you do this and you don't want those names in the public CT records, though, you have to implement a private internal PKI for those servers so they're not getting public certs. Or use a wildcard, which carries its own significant security risks.
        xg15 7y ago
        > you have to implement a private internal PKI for those servers so they're not getting public certs This would also involve setting up a custom CA and distributing your CA cert to all machines that should be able to access the page. Good luck with that! All of this is a ridiculous amount of effort to set up and maintain. It's a lot easier to just make the internal domains accessible to the internet and be done with it. The effect being that networks are being nudged into exposing a lot more surface to the internet - and this somehow in the name of more security.
X-Istence 7y ago
You could automate the generation of the wildcard certificate and push it out with chef to all your servers. Instead of replacing it once a year, you replace it every 90 days.
castillar76 7y ago
I think a lot of places do this for convenience, and don't realize the risk it puts them under (not that you are unaware of this, just that others may not be). Whether they have everything generate its own wildcard certificate, or create one wildcard and share it to everything, they've created a significant security risk. Namely, any time a wildcard cert and private key leaks, the attacker can now impersonate literally everything behind that name. By using wildcards everywhere, they're creating tons of leakage points, and only one of them has to leak the private key and the attacker wins, particularly if they can grab it without the user being aware.

iso1210 7y ago

Without certificate transparency how do you know nobody has issued a certificate for your server? Surely that's a far higher risk than knowing a domain?

nicolas_t 7y ago
oh, I completely agree that certificate transparency is beneficial for that and we have an alert setup. But, that still leaves me not wanting to leak every single subdomain we use internally. Hence using wildcard certificates.
- njsubedi 7y ago
  Wouldn't it be a better idea to use alternate domains instead of subdomains? You could use something like [any subdomain].atdie8e73bhdbdie93ruhe.[any tld] for obfuscation?
  - saagarjha 7y ago
    Those cost money.
- tialaramex 7y ago
  CT didn't change this for bad guys. If you're a bad guy (or a neutral researcher with a budget for the data) you can buy what's called "Passive DNS". Several suppliers will give you a list of DNS requests and their answers, the identifying information for who made the requests is elided so it's not PII but it has the same effect of making the fact servername.example.com exists in effect public information. Even if you are unusual in actually having machines named cy23hdc9.example.com not exchange2016.example.com then the existence of this service means you need to stop assuming nobody knows these names. Anybody who cares knows them.
  - xg15 7y ago
    Yes, which is why you used to be able to have fully internal domains that are served by an internal DNS server and are never seen on the public internet.
    - castillar76 7y ago
      You can still have this: it's called 'split-horizon' or 'split-brain' DNS. It can be tough to set up and maintain for large DNS environments, but not /that/ difficult even at that level. If you do this and you don't want those names in the public CT records, though, you have to implement a private internal PKI for those servers so they're not getting public certs. Or use a wildcard, which carries its own significant security risks.
      - xg15 7y ago
        > you have to implement a private internal PKI for those servers so they're not getting public certs This would also involve setting up a custom CA and distributing your CA cert to all machines that should be able to access the page. Good luck with that! All of this is a ridiculous amount of effort to set up and maintain. It's a lot easier to just make the internal domains accessible to the internet and be done with it. The effect being that networks are being nudged into exposing a lot more surface to the internet - and this somehow in the name of more security.

X-Istence 7y ago

You could automate the generation of the wildcard certificate and push it out with chef to all your servers. Instead of replacing it once a year, you replace it every 90 days.

castillar76 7y ago

I think a lot of places do this for convenience, and don't realize the risk it puts them under (not that you are unaware of this, just that others may not be). Whether they have everything generate its own wildcard certificate, or create one wildcard and share it to everything, they've created a significant security risk. Namely, any time a wildcard cert and private key leaks, the attacker can now impersonate literally everything behind that name. By using wildcards everywhere, they're creating tons of leakage points, and only one of them has to leak the private key and the attacker wins, particularly if they can grab it without the user being aware.