Live data from Hacker News

Everything you should know about certificates and PKI but are too afraid to ask

smallstep.com

21–30 of 54 posts

Re: Everything you should know about certificates and PKI but are too afraid to ask

#21

The stuff about CAA is wrong. CAA is NOT checked by browsers, the BRs do not say browsers should check CAA, and indeed it is specifically NOT designed to be checked by RPs at all. CAA tells the Issuers (Certificate Authorities) whether the name owner authorises them to issue at a moment in time. If you think "that seems useless" it's probably because you completely misunderstood the security model it's written for. W…

And if a non-authorized CA ignores it and creates a cert anyway, that cert will still work. It's basically a kind of robots.txt file for CAs.

I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#23

PKI works. Period. I don't understand how knowledgeable engineers complain about PKI being "too complex". The same people complain that SMTP, DNS and NTP is too difficult too (and claim it can only be solved with external services). Granted having your own home-grown authentication & identity management "salad", or a very complex system that never addressed identity/authenticity, ... then replacing this with PKI will…

I'm halfway through the article so far, but I didn't perceive the message as complaining about PKI being "too complex". The author outlines the fact that some aspects of PKI or certificate design are basically remnants of the past that don't make much sense in reality nowadays (e.g. encoding locality, state, and country). The author in fact complains about over-complication and ambiguity of various cert formats, but his claims are not without some merit here.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#24

The stuff about CAA is wrong. CAA is NOT checked by browsers, the BRs do not say browsers should check CAA, and indeed it is specifically NOT designed to be checked by RPs at all. CAA tells the Issuers (Certificate Authorities) whether the name owner authorises them to issue at a moment in time. If you think "that seems useless" it's probably because you completely misunderstood the security model it's written for. W…

And if a non-authorized CA ignores it and creates a cert anyway, that cert will still work. It's basically a kind of robots.txt file for CAs. I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

No, it's still about security, in a defense-in-depth sense. Even if your trusting CA's in this context they all count as attack surface: CAA helps minimize it. For example, it's possible that a CA's validation process has a flaw. A CAA record may isolate you from that.

Even the "corporate policies" is a security thing, not "making someone's job easier". Presumably Facebook handles their certificates carefully: if any engineer could obtain certificates the odds that they would and that the certificates would be passed around in email attachments is 100%.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#25

The stuff about CAA is wrong. CAA is NOT checked by browsers, the BRs do not say browsers should check CAA, and indeed it is specifically NOT designed to be checked by RPs at all. CAA tells the Issuers (Certificate Authorities) whether the name owner authorises them to issue at a moment in time. If you think "that seems useless" it's probably because you completely misunderstood the security model it's written for. W…

And if a non-authorized CA ignores it and creates a cert anyway, that cert will still work. It's basically a kind of robots.txt file for CAs. I always wondered why there wasn't a secure way to prevent rogue CAs from creating valid certs, but your explanation pretty much sums it up: this is about enforcing corporate policies and making someone's job easier, not so much security.

And if it is a publicly trusted CA, it now gets to explain to browser and OS vendors how it managed to fail to comply with a required policy. (although there's of course difficulty in proving that a DNS entry existed)

Re: Everything you should know about certificates and PKI but are too afraid to ask

#26
post #4

The other day I noticed that most mail doesn’t come through when disabling TLS 1.0 & TLS 1.1. To my dismay it seems some major smtp service don’t support TLS 1.2. After enabling 1.0 & 1.1 mail came rolling in. Anyone able to shed some light on what happened there to me?

It sounds like you've already figured it out.

You were requiring TLSv1.2 but some other remote mail systems didn't support it and were unable to fallback and, as a result, couldn't negotiate a secure connection.

Or did I miss something?

Re: Everything you should know about certificates and PKI but are too afraid to ask

#27

PKI works. Period. I don't understand how knowledgeable engineers complain about PKI being "too complex". The same people complain that SMTP, DNS and NTP is too difficult too (and claim it can only be solved with external services). Granted having your own home-grown authentication & identity management "salad", or a very complex system that never addressed identity/authenticity, ... then replacing this with PKI will…

It "works" only at relatively low values of "work". By that I mean you are fine with various governments having complete control as long as it keeps the 14yo moms-basement sorts at bay.

My complaints with PKI aren't technical difficulty but administrative and bureaucratic. Consider; The NSA issues an NSL for all the root keys to YourCA Inc. Now what?

We would flee PKI like rats from a sinking ship if the capacity for a government to obtain any CAs private keys was written into code. But because its written into policy we simply ignore it.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#29
Hah, I think "Trust CA" deserves just as much of a "(lol)" as "Trust DMV" given the shit some CAs have done in recent years, how many vulnerabilities they've swept under the rug and how many of them are run by governmental agencies in less than scrupulous places.

Re: Everything you should know about certificates and PKI but are too afraid to ask

#30
post #4

The other day I noticed that most mail doesn’t come through when disabling TLS 1.0 & TLS 1.1. To my dismay it seems some major smtp service don’t support TLS 1.2. After enabling 1.0 & 1.1 mail came rolling in. Anyone able to shed some light on what happened there to me?

Determine whether security is important (protip: it is important). If so, then file bug reports to the originators of your missing mail.

It's far better to force them to upgrade than to allow them to force you to be insecure.

Post reply on HN