Hacker News Reader

Comment by hannob | Hacker News Reader

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.

View on HN

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.

Trolling open sources for operational intelligence on internal factors which should not be publicly traded is often recommended to both attackers and defenders.

> 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.

There is also the open network movement where work services are available from the internet directly without a VPN.

Beyond corp doesn’t mean that there are no private systems. You still have jump boxes….

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.

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.

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

> 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.

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.

> 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.

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.

> 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.

Not quite. Bank cards can be revoked after unsuccessful attempts while doing that with usernames is problematic.

You need a carefully constructed system to make the use of passwords viable.

> Not quite. Bank cards can be revoked after unsuccessful attempts while doing that with usernames is problematic.

The same happens with websites, have you never been locked out of a website (or had your IP temp banned) for failing too many login attempts?

Again, the reason that bank cards only require a PIN from you is that _the card_ provides the other half of the credentials.

If a bank card simply contained the equivalent of a username (say your legal name and address), then it would not use just a PIN.

A temporary ban is just a rate limit by another name. Blocking IP’s is all well and good expect you can multiple attempts * thousands of IP’s means a 4 numeric digit password would literally always get cracked.

The reason you can get away with a 4 digit PIN is that you can only try the PIN if you’re in physical possession of the card. And if an attacker is already in physical possession of the card, you want revoke the card in any case.

Web sites however, cannot just revoke the username - it would allow for trivial denial of service attacks. I could just enumerate all account numbers for my bank and lock out all customers. So the best that’s available is a temporary lockout, and then the attacker gets to try again.

Plus all you can lose is money (not privacy / control / data) and the CC companies take the hit as cost of doing business.

It's not that black and white. Port knocking for instance, is basically extending the password. Is the port configuration "implementation"?

You mean "it's not always black and white" and you are right. However the grandparent's case is clear-cut.

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.

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.

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.

A castle on the hill is hard to hide but also hard to approach, and requires hauling breaching tools and weaponry uphill.

Reply on news.ycombinator.com