Live data from Hacker News

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

smallstep.com

41–50 of 54 posts

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

#41

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.

It turns out that making someone's job easier is in fact the foundation of good security.

One way this is true is that people won't use security if it isn't usable or easy to use. For almost two decades we had CA workflows that sucked. Certificate use has spiked in the last couple of years. Why? Witness the outstanding work by LetsEncrypt which is now allowing Chrome to flag insecure login forms.

Other examples; DDoS defense as a service, facial recognition that unlocks your phone every time you pick it up, cars that lock when driving, and fobs that make passwords almost irrelevant.

Good security and making someone's job easier are one and the same.

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

#42

Earlier quoted context omitted.

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…

Speaking of defense-in-depth. I don't understand why do certificates released by public CAs not add an extension to the cert if the cert was given to a DNSSEC validated host.

As browsers are unwilling to validate DNSSEC directly it would allow browsers to just check the certificate. This could be complemented with a relevant HTTP header that forces the browser to only accept the certificate if it has been given out to DNSSEC validated host.

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

#43

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…

PKI solves a lot of problems but it sure doesn't solve government making choices you don't like. That's not a PKI problem, though, that's a government problem, and asking PKI to solve that is way outside the arena.

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

#44
post #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…

my comment was in agreement and support for the article and not a critic of it. the article was pretty awesome! I should have made that clearer in my comment, apologies for that.

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

#45
post #28

See also Everything you Never Wanted to Know about PKI but were Forced to Find Out , by Peter Gutmann: http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf

It's funny how this area seems to attract titles like this. I used the same for my blog post, "Everything You Ever Wanted to Know About SSL (but Were Afraid to Ask)"

http://www.robinhowlett.com/blog/2016/01/05/everything-you-e...

Disclaimer: I write blog posts to figure out if I understand something correctly and appreciate any and all feedback, negative or positive.

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

#46

Earlier quoted context omitted.

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.

> 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. Pretty much the best attempt at this I've seen is the Certificate Transparency thing designed by Google and implemented in Let's Encrypt and a few other CAs. Having a public, audi…

We still have to depend on CAs to 'follow the rules', and the client has to support it (does your mail client verify Cert Transparency? does your backend microservice?) and be connected to the Internet, and Google, etc.

There are better ways to handle it, I think, but they may involve changing how we both sign and verify certs.

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

#47
Here's something nasty. The firewall where I am working (provided by Palo Alto Networks) can decrypt https and other "secure" traffic passing through it. I believe it auto-negotiates down to TLS 1.1 at which point it can decrypt everything to plain-text and can examine it to its hearts content.

They are supposed to whitelist financial addresses (such as banking details) but would you trust that to be happening?

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

#48
post #16

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…

> 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 Perhaps as knowledgeable engineers they can understand accidental complexity when they see it.

OTOH it's easy to dismiss something as overly complex before you understand it yourself.

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

#49
post #16

Earlier quoted context omitted.

> 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 Perhaps as knowledgeable engineers they can understand accidental complexity when they see it.

OTOH it's easy to dismiss something as overly complex before you understand it yourself.

It's even easier to build something that's more complex than needed, because of original bad design or accumulated cruft.

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

#50

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…

Hi, am author. Ah, yea, I know that CAs are supposed to check CAA before issuing and I do understand the security model. Figured browsers could/should too, but just dug a bit more and you’re right that CAA is explicitly not supposed to be checked by RPs.

Conceptually I don’t see any major problem with using CAA for this purpose though, at least for your own internal PKI. The only potential issue is that if you change your CAA record your issued certs would break, so there’s an availability attack.

I just found a reference to another standard called DANE that’s supposed to do this, but I don’t know anything about it.

Post reply on HN