5 ms·

Counterpoint: In many simple cases it absolutely is okay to use public CA certificates for internal hosts. Point 1 will incentivize you to not create complexit

by hannob 4y ago

Counterpoint: In many simple cases it absolutely is okay to use public CA certificates for internal hosts. Point 1 will incentivize you to not create complexity where no complexity is needed. Just do what Let's Encrypt does, it'll be fine. Point 2 is true, but you can just as well use public DNS names. Point 3 is something to be aware of, but likely also just a reminder that security by obscurity is no good idea and never was. The advantages of using a public CA: It makes a lot of things simpler for you. You don't have to bother understanding the various complexities of X.509 and a PKI structure. Other people will make sure your certificates are well formed, your keys comply with common recommendations etc. pp. And you don't have to worry how to get that root certificate on a variety of devices.

marcosdumay 4y ago
Nobody verifies certificate policies anyway, you can't rely on it. So point 1 is moot.
m3047 4y ago
Just like security can mean "carefree" or "hypervigilant" depending on your POV, obscurity can mean different things. It can mean trivally or fatuously odd; it can mean hidden; it can mean removal or at a distance; it can mean friction. While these differ for evaluating a security posture, for the outside observer all of these can mean much the same: removal from view, consideration or observation. The outside observer is not preeminently qualified to pass judgement on the nature of obscurity from their "privileged" position no matter how certain they are of their inability to observe.
user3939382 4y ago
> security by obscurity I’ve often wondered at a more abstract level, where’s the line? A password or a private key are security by obscurity.
- shahbaby 4y ago
  All security relies on some sort of secret. When brute force guessing of that secret in the best case gives a motivated attacker or a random person a chance of stumbling upon it, that's a failure of security by obscurity. With passwords and private keys we can mathematically verify that brute force attacks won't work. At that point we're not relying on obscurity because we're assuming the attacker has knoweldege of everything except the secret itself.
  - m3047 4y ago
    A castle on the hill is hard to hide but also hard to approach, and requires hauling breaching tools and weaponry uphill.
- DiffEq 4y ago
  Security through obscurity is a great idea and works to slow down, prevent and even stop and attack from going forward for all kinds of systems whether is be an animal and their camouflage or a computer system holding PII with a vacuous name. Where the utility breaks down is when that is your ONLY means or layer of security. For example my house is hard to see from the road…so an opportunist thief might never see it and so just pass on by. But say this criminal finds my house by some fortuitous means. Well now he has to get past my locks and then the and if I am home, the bullets that may fly his way. And then he will have to try and get away before the police arrive.
- remram 4y ago
  > A password or a private key are security by obscurity. No, they're not. You could think that if you're trying to guess what the term means, but it means something specific that is the opposite of basing your security on a specific secret that is decoupled from all implementation concerns. >> Security by obscurity is the reliance on design or implementation secrecy as the main method of providing security to a system or component.
  - user3939382 4y ago
    It's not that black and white. Port knocking for instance, is basically extending the password. Is the port configuration "implementation"?
    - remram 4y ago
      You mean "it's not always black and white" and you are right. However the grandparent's case is clear-cut.
      - user3939382 4y ago
        They said “it means” i.e. defining a rule. The point of my original comment is that the boundaries are fuzzy, so I wasn’t commenting on specific examples but the concept of the rule.
  - Retric 4y ago
    Yes and no, passwords are an implementation detail. There’s a reason why bank cards can securely use 4 digit numeric pins but banking websites need much longer passwords.
    - cmeacham98 4y ago
      > Yes and no, passwords are an implementation detail. Passwords are not an "implementation detail" unless they are hardcoded (and a hardcoded password is very arguably security by obscurity). > There’s a reason why bank cards can securely use 4 digit numeric pins but banking websites need much longer passwords. Yes, because the bank card provides some additional form of authentication, typically in the form of a chip on the card.
- Spooky23 4y ago
  In online fora, “security by obscurity” is when you disagree with someone. In reality, it’s when the primary control used is restricted, shared knowledge. Famously back in the day if you knew a phone number and AT&T lingo, you could compromise the phone system. In the case of a public CA, if your hostnames aren’t license plates, the names of servers may provide context useful for an attacker. They also provide an attack vector - the control panel for the CA.
dogma1138 4y ago
Security by Obscurity is often misused. SBO is bad or insufficient when it’s the only control you have, when it’s not it’s just called OPSEC…. There is absolutely no reason to leak unnecessary information that can describe how your system is built, how many components are there and giving out information such as internal service names that make exploitation of various vulnerabilities such as SSRF easier. Heck you can look up just how many bounties Google has paid out because everyone is aware of what “dogfood” is these days and that it’s the nomenclature for their internal test environment/endpoints. You will never have a system that has no design or implementation flaws. The less information an attacker can gain about it the less likely they’ll be able to either discover a flaw or successfully exploit it. Relying on external CA’s opens you to additional supply chain attacks it’s not uncommon for highly regulated industries or high security systems in general to not only use an internal CA but to break the public chain of trust altogether by removing the public certs from the system. As far as the complexity goes yes running a CA adds another component but there are plenty of good solutions out there that abstract the complexity. Most of the “complexity” is around constructing the CSRs and getting the certificates securely deployed during the deployment or post deployment configuration management stages anyhow which a 3rd part public CA doesn’t solve. And tools like Istio and other service meshes usually allow you to automate all of that fairly easily regardless if you use an internal or external CA. lastly if you can’t figure out how to manage root CAs on your endpoints you shouldn’t do anything with PKI regardless of who issues your certificates.
- m3047 4y ago
  Trolling open sources for operational intelligence on internal factors which should not be publicly traded is often recommended to both attackers and defenders.
- livueta 4y ago
  > it’s not uncommon for highly regulated industries or high security systems in general to not only use an internal CA but to break the public chain of trust altogether by removing the public certs from the system. Yeah, I work with internal PKI systems professionally and that's usually the biggest or one of the biggest motivating factors, especially these days with Trustcor / the Turkish and Kazakh examples of public CA sussiness in the news. From the headline I assumed the article would be about this. I guess you could theoretically dump the bundle and explicitly only trust the public CA used to issue your internal certs, but I've never seen that configuration in the wild; public CA usually implies bundle.
Already__Taken 4y ago
I mean point 2 has parallels to ipv6. Addressable does not mean routable. Just own the domain you're using internally or it will become a headache.

by hannob 4y ago

marcosdumay 4y ago

Nobody verifies certificate policies anyway, you can't rely on it. So point 1 is moot.

m3047 4y ago

Just like security can mean "carefree" or "hypervigilant" depending on your POV, obscurity can mean different things. It can mean trivally or fatuously odd; it can mean hidden; it can mean removal or at a distance; it can mean friction. While these differ for evaluating a security posture, for the outside observer all of these can mean much the same: removal from view, consideration or observation. The outside observer is not preeminently qualified to pass judgement on the nature of obscurity from their "privileged" position no matter how certain they are of their inability to observe.

user3939382 4y ago

> security by obscurity I’ve often wondered at a more abstract level, where’s the line? A password or a private key are security by obscurity.

shahbaby 4y ago
All security relies on some sort of secret. When brute force guessing of that secret in the best case gives a motivated attacker or a random person a chance of stumbling upon it, that's a failure of security by obscurity. With passwords and private keys we can mathematically verify that brute force attacks won't work. At that point we're not relying on obscurity because we're assuming the attacker has knoweldege of everything except the secret itself.
- m3047 4y ago
  A castle on the hill is hard to hide but also hard to approach, and requires hauling breaching tools and weaponry uphill.
DiffEq 4y ago
Security through obscurity is a great idea and works to slow down, prevent and even stop and attack from going forward for all kinds of systems whether is be an animal and their camouflage or a computer system holding PII with a vacuous name. Where the utility breaks down is when that is your ONLY means or layer of security. For example my house is hard to see from the road…so an opportunist thief might never see it and so just pass on by. But say this criminal finds my house by some fortuitous means. Well now he has to get past my locks and then the and if I am home, the bullets that may fly his way. And then he will have to try and get away before the police arrive.
remram 4y ago
> A password or a private key are security by obscurity. No, they're not. You could think that if you're trying to guess what the term means, but it means something specific that is the opposite of basing your security on a specific secret that is decoupled from all implementation concerns. >> Security by obscurity is the reliance on design or implementation secrecy as the main method of providing security to a system or component.
- user3939382 4y ago
  It's not that black and white. Port knocking for instance, is basically extending the password. Is the port configuration "implementation"?
  - remram 4y ago
    You mean "it's not always black and white" and you are right. However the grandparent's case is clear-cut.
    - user3939382 4y ago
      They said “it means” i.e. defining a rule. The point of my original comment is that the boundaries are fuzzy, so I wasn’t commenting on specific examples but the concept of the rule.
- Retric 4y ago
  Yes and no, passwords are an implementation detail. There’s a reason why bank cards can securely use 4 digit numeric pins but banking websites need much longer passwords.
  - cmeacham98 4y ago
    > Yes and no, passwords are an implementation detail. Passwords are not an "implementation detail" unless they are hardcoded (and a hardcoded password is very arguably security by obscurity). > There’s a reason why bank cards can securely use 4 digit numeric pins but banking websites need much longer passwords. Yes, because the bank card provides some additional form of authentication, typically in the form of a chip on the card.
Spooky23 4y ago
In online fora, “security by obscurity” is when you disagree with someone. In reality, it’s when the primary control used is restricted, shared knowledge. Famously back in the day if you knew a phone number and AT&T lingo, you could compromise the phone system. In the case of a public CA, if your hostnames aren’t license plates, the names of servers may provide context useful for an attacker. They also provide an attack vector - the control panel for the CA.

dogma1138 4y ago

Security by Obscurity is often misused. SBO is bad or insufficient when it’s the only control you have, when it’s not it’s just called OPSEC…. There is absolutely no reason to leak unnecessary information that can describe how your system is built, how many components are there and giving out information such as internal service names that make exploitation of various vulnerabilities such as SSRF easier. Heck you can look up just how many bounties Google has paid out because everyone is aware of what “dogfood” is these days and that it’s the nomenclature for their internal test environment/endpoints. You will never have a system that has no design or implementation flaws. The less information an attacker can gain about it the less likely they’ll be able to either discover a flaw or successfully exploit it. Relying on external CA’s opens you to additional supply chain attacks it’s not uncommon for highly regulated industries or high security systems in general to not only use an internal CA but to break the public chain of trust altogether by removing the public certs from the system. As far as the complexity goes yes running a CA adds another component but there are plenty of good solutions out there that abstract the complexity. Most of the “complexity” is around constructing the CSRs and getting the certificates securely deployed during the deployment or post deployment configuration management stages anyhow which a 3rd part public CA doesn’t solve. And tools like Istio and other service meshes usually allow you to automate all of that fairly easily regardless if you use an internal or external CA. lastly if you can’t figure out how to manage root CAs on your endpoints you shouldn’t do anything with PKI regardless of who issues your certificates.

m3047 4y ago
Trolling open sources for operational intelligence on internal factors which should not be publicly traded is often recommended to both attackers and defenders.
livueta 4y ago
> it’s not uncommon for highly regulated industries or high security systems in general to not only use an internal CA but to break the public chain of trust altogether by removing the public certs from the system. Yeah, I work with internal PKI systems professionally and that's usually the biggest or one of the biggest motivating factors, especially these days with Trustcor / the Turkish and Kazakh examples of public CA sussiness in the news. From the headline I assumed the article would be about this. I guess you could theoretically dump the bundle and explicitly only trust the public CA used to issue your internal certs, but I've never seen that configuration in the wild; public CA usually implies bundle.

Already__Taken 4y ago

I mean point 2 has parallels to ipv6. Addressable does not mean routable. Just own the domain you're using internally or it will become a headache.