3 ms·

In theory it is good, but somehow it is also a big threat to privacy and security of your infrastructure. No need anymore to scan your network to map the compl

In theory it is good, but somehow it is also a big threat to privacy and security of your infrastructure. No need anymore to scan your network to map the complete endpoints of your infrastructure! And it's a new single point of control and failure!

Eikon 2y ago
You're essentially advocating for security through obscurity. The fact that public infrastructure is mappable is actually beneficial. It helps enforce best practices rather than relying on the flawed 'no one will discover this endpoint' approach. > And it's a new single point of control and failure! This reasoning is flawed. X.509 certificates themselves embed SCTs. While log unavailability may temporarily affect new certificate issuance, there are numerous logs operated by diverse organizations precisely to prevent single points of failure. Certificate validation doesn't require active log servers once SCTs are embedded.
- cle 2y ago
  They are tradeoffs and it’s not all-or-nothing. There’s a reason security clearances exist, and that’s basically “security through obscurity”. The argument here is that the loss of privacy and the incentives that will increase centralization might not be worth the gain in security for some folks, but good luck opting out. It basically requires telling bigco about your domains. How convenient for crawlers…
- tzs 2y ago
  > You're essentially advocating for security through obscurity So? The problem with security through obscurity is when it is the only security you are using. I didn't see anything in his comment that implied his only protection was the secrecy of his endpoints. Security through obscurity can be fine when used in addition to other security measures, and has tangible benefits in a significant fraction of real world situations.
  - grayhatter 2y ago
    > So? The problem with security through obscurity is when it is the only security you are using. I didn't see anything in his comment that implied his only protection was the secrecy of his endpoints. Directly, or unintentionally implied or not. That's an implication you're allowed to infer when obscurity is the only thing listed, because it's *very* common that is the only defense mechanism. Also, when given the choice between mentioning something that works (literally any other security measure), or mentioning something well known to fail more often than work (obscurity). You're supposed to mention the functioning one, and omit the non-functioning one. https://xkcd.com/463/ https://xkcd.com/463/ > Security through obscurity can be fine when used in addition to other security measures, No, it also has subtle downsides as well. It changes the behavior of everything that interacts with the system. Humans constantly over value the actual value of security though obscurity. And will make decisions based on that misconceived notion. I once heard an engineer tell me. "I didn't know you could hit this endpoint with curl". The mental model for permitting secrets to be used as part of security is actively harmful to security. Much more than it has ever shown to benefit it. Thus, the cure here is to affirmatively reject security though obscurity. We should treat it the same way we treat goto. Is goto useful, absolutely. Are there places where it improves code? Another absolutely. Did code quality as a whole improve once SWE collectively shunned goto? Yes! Security though obscurity is causing the exact same class of issues. And until the whole industry adapts to the understanding that it's actually more harmful than useful, we still let subtle bugs like "I thought no one knew about this" sneak in. We're not going to escape this valley while people are still advocating for security theatre. We all collectively need to enforce the idea that secrets are dangerous to software security. > and has tangible benefits in a significant fraction of real world situations. So does racial profiling, but humans have proven over and over and over again, that we're incapable of not misusing in a way that's also actively harmful. And again, when there are options that are better in every way, it's malpractice to use the error prone methods.
    - Eikon 2y ago
      Thank you for putting this up so clearly!
tialaramex 2y ago
"Passive DNS" is a thing people sell. If people connect to your systems and use public DNS servers, chances are I can "map the complete endpoints of your infrastructure" without touching that infrastructure for a small cost. If client X doesn't want client-x.your-firm.example to show up by all means obtain a *.your-firm.example wildcard and let them use any codename they like - but know that they're going to name their site client-x.your-firm.example, because in fact they don't properly protect such "secrets". "Blue Harvest" is what secrets look like. Or "Argo" (the actual event not the movie, although real life is much less dramatic, they didn't get chased by people with guns, they got waved through by sleepy airport guards, it's scary anyway but an audience can't tell that). What you're talking about is like my employer's data centre being "unlisted" and having no logo on the signs. Google finds it with an obvious search, it's not actually secret.
lxgr 2y ago
> And it's a new single point of control and failure! That’s why there is a mandatory minimum of several unaffiliated logs that each certificate has to be submitted to. If all of these were to catastrophically fail, it would still always be possible for browsers or central monitors to fall back to trusting certificates logged by exactly these without inclusion verification.
perching_aix 2y ago
It does leak domain name info, but then you do still have the option to use a wildcard certificate or set up a private CA instead of relying on public ones, which likely makes more sense when dealing with a private resource anyways. I guess there might be a scenario where you need "secret" domains be publicly resolvable and use distinct certs, but an example escapes me.
bawolff 2y ago
> In theory it is good, but somehow it is also a big threat to privacy and security of your infrastructure. This is silly. Certificates have to be in CT logs regardless of if firefox valudates or not. Additionally this doesnt apply to private CAs, so internal infrastructure is probably not affected unless you are using public web pki on them.
- tialaramex 2y ago
  technically incorrect which is presumably the best kind of incorrect? Certificate logging is not mandatory, none of the Root Programmes (agreements with typically browser vendors to recognise your CA roots) require logging. Now, in practice the browsers may reject certificates if they aren't presented a logging proof (in the certificate or stapled to it by the protocol, or some other means) but that's not a violation of your agreement with the vendor. Most CAs (obviously including ISRG / Let's Encrypt) always log every certificate, but some either have programmes where you can pick or legacy systems which just don't do this. You can log such a certificate yourself, if you want, and then staple the receipts to your connection setup - but most people don't know how and don't want to learn.

Eikon 2y ago

You're essentially advocating for security through obscurity. The fact that public infrastructure is mappable is actually beneficial. It helps enforce best practices rather than relying on the flawed 'no one will discover this endpoint' approach. > And it's a new single point of control and failure! This reasoning is flawed. X.509 certificates themselves embed SCTs. While log unavailability may temporarily affect new certificate issuance, there are numerous logs operated by diverse organizations precisely to prevent single points of failure. Certificate validation doesn't require active log servers once SCTs are embedded.

cle 2y ago
They are tradeoffs and it’s not all-or-nothing. There’s a reason security clearances exist, and that’s basically “security through obscurity”. The argument here is that the loss of privacy and the incentives that will increase centralization might not be worth the gain in security for some folks, but good luck opting out. It basically requires telling bigco about your domains. How convenient for crawlers…
tzs 2y ago
> You're essentially advocating for security through obscurity So? The problem with security through obscurity is when it is the only security you are using. I didn't see anything in his comment that implied his only protection was the secrecy of his endpoints. Security through obscurity can be fine when used in addition to other security measures, and has tangible benefits in a significant fraction of real world situations.
- grayhatter 2y ago
  > So? The problem with security through obscurity is when it is the only security you are using. I didn't see anything in his comment that implied his only protection was the secrecy of his endpoints. Directly, or unintentionally implied or not. That's an implication you're allowed to infer when obscurity is the only thing listed, because it's *very* common that is the only defense mechanism. Also, when given the choice between mentioning something that works (literally any other security measure), or mentioning something well known to fail more often than work (obscurity). You're supposed to mention the functioning one, and omit the non-functioning one. https://xkcd.com/463/ https://xkcd.com/463/ > Security through obscurity can be fine when used in addition to other security measures, No, it also has subtle downsides as well. It changes the behavior of everything that interacts with the system. Humans constantly over value the actual value of security though obscurity. And will make decisions based on that misconceived notion. I once heard an engineer tell me. "I didn't know you could hit this endpoint with curl". The mental model for permitting secrets to be used as part of security is actively harmful to security. Much more than it has ever shown to benefit it. Thus, the cure here is to affirmatively reject security though obscurity. We should treat it the same way we treat goto. Is goto useful, absolutely. Are there places where it improves code? Another absolutely. Did code quality as a whole improve once SWE collectively shunned goto? Yes! Security though obscurity is causing the exact same class of issues. And until the whole industry adapts to the understanding that it's actually more harmful than useful, we still let subtle bugs like "I thought no one knew about this" sneak in. We're not going to escape this valley while people are still advocating for security theatre. We all collectively need to enforce the idea that secrets are dangerous to software security. > and has tangible benefits in a significant fraction of real world situations. So does racial profiling, but humans have proven over and over and over again, that we're incapable of not misusing in a way that's also actively harmful. And again, when there are options that are better in every way, it's malpractice to use the error prone methods.
  - Eikon 2y ago
    Thank you for putting this up so clearly!

tialaramex 2y ago

"Passive DNS" is a thing people sell. If people connect to your systems and use public DNS servers, chances are I can "map the complete endpoints of your infrastructure" without touching that infrastructure for a small cost. If client X doesn't want client-x.your-firm.example to show up by all means obtain a *.your-firm.example wildcard and let them use any codename they like - but know that they're going to name their site client-x.your-firm.example, because in fact they don't properly protect such "secrets". "Blue Harvest" is what secrets look like. Or "Argo" (the actual event not the movie, although real life is much less dramatic, they didn't get chased by people with guns, they got waved through by sleepy airport guards, it's scary anyway but an audience can't tell that). What you're talking about is like my employer's data centre being "unlisted" and having no logo on the signs. Google finds it with an obvious search, it's not actually secret.

lxgr 2y ago

> And it's a new single point of control and failure! That’s why there is a mandatory minimum of several unaffiliated logs that each certificate has to be submitted to. If all of these were to catastrophically fail, it would still always be possible for browsers or central monitors to fall back to trusting certificates logged by exactly these without inclusion verification.

perching_aix 2y ago

It does leak domain name info, but then you do still have the option to use a wildcard certificate or set up a private CA instead of relying on public ones, which likely makes more sense when dealing with a private resource anyways. I guess there might be a scenario where you need "secret" domains be publicly resolvable and use distinct certs, but an example escapes me.

bawolff 2y ago

> In theory it is good, but somehow it is also a big threat to privacy and security of your infrastructure. This is silly. Certificates have to be in CT logs regardless of if firefox valudates or not. Additionally this doesnt apply to private CAs, so internal infrastructure is probably not affected unless you are using public web pki on them.

tialaramex 2y ago
technically incorrect which is presumably the best kind of incorrect? Certificate logging is not mandatory, none of the Root Programmes (agreements with typically browser vendors to recognise your CA roots) require logging. Now, in practice the browsers may reject certificates if they aren't presented a logging proof (in the certificate or stapled to it by the protocol, or some other means) but that's not a violation of your agreement with the vendor. Most CAs (obviously including ISRG / Let's Encrypt) always log every certificate, but some either have programmes where you can pick or legacy systems which just don't do this. You can log such a certificate yourself, if you want, and then staple the receipts to your connection setup - but most people don't know how and don't want to learn.