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. We don't want untrustworthy or incompetent CAs at all, this is not a guard against those. This is a guard against trustworthy, competent CAs that you've got your own reasons to disallow for your specific names.
Example: Facebook for years had a single preferred CA and their contract with that CA said everything gets signed off by the certificates team. After Let's Encrypt came on the scene a subcontractor developing example.facebook.com needed HTTPS, didn't read all the paperwork from Facebook and just got a cert from Let's Encrypt. Facebook security freaked out because their team hadn't authorised this weird new certificate. Let's Encrypt did nothing wrong, but it looked exactly like an attack. CAA lets Facebook tell every CA except the one that knows about their internal policy, "Thanks, but no thanks". Let's Encrypt would have checked CAA and told the subcontractor "Sorry, no, policy forbids, check CAA" and when they went to Facebook to ask why they'd have got an earful for not obeying policy.
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.
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%.
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.
> 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, auditable log of every certificate officially issued could can be used to validate certs, Chrome enforces this with new EV certs and Symantec certs.
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.
More specifically: Log servers can be shown either a normal X.509 certificate or a "pre-certificate" which is proof that a Certificate Authority intends or intended to issue some particular certificate. Right now these are actually X.509 certs that were "poisoned" to make them useless, but in future they will probably be some other format.
Anyway, when shown a new certificate or pre-certificate, the log server gives you a Signed Certificate Timestamp proving when it saw the document.
Chrome (and eventually Safari and Firefox) require suitable SCTs when shown any modern public certificate or they may conclude the certificate should not exist and fail the connection or mark it insecure, or even report it to Google/ Apple/ Mozilla for investigation.
SCTs get to the browser in one of three ways:
1. Most popular. The site's CA made pre-certificates, logged those, got back SCTs and baked the SCTs inside the real certificate. This changes nothing for a site operator, if you use Let's Encrypt and have never heard of SCTs, don't worry, all your current Let's Encrypt certs are done this way.
2. Less popular: The CA doesn't put SCTs inside the certificate, but it DOES staple them inside OCSP responses. Then you staple an OCSP response into your certificate responses and everything works.
3. Also less popular: The SCTs go in a separate TLS extension when a client connects, saying "Hey, I want SCTs" and they get them back only if they ask for them.
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)
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.
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 force you to deal with a lot of technical debt. But don't blame PKI for it.
Blaming PKI has become rampant. Those that don't know can't dispute the nonsense and those that do know may have an agenda (snake oil vendors).
Hating on PKI has become like a bad habit in IoT (vendors see an opportunity to sell trash to an uninformed and ignorant audience). Be careful especially in IoT: There are a lot of snake oil proposals which promise to replace PKI here ... you should run as fast whenever you see these "proprietary, patent-pending, post-quantum-proof, blockchain solutions !! (the correct response to these vendors is: "BEGONE MAGICIAN!").
PKI isn't easy but neither is email, Kubernetes! It's as simply as it can be given the circumstance and job it has to solve. And PKI is essential knowledge as much as Latin is required for medicine.
>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.
PKI absolutely works, but the complexity complaint is still valid. I work in PKI, and we often tell people that PKI is difficult to do correctly, easy to do wrong, and nearly impossible to remove once you've screwed it up. That's the fundamental difference between something like PKI and DNS. It's very easy to set up a PKI and get things to trust your chain, but if you haven't done the leg-work to figure out how you'll replace it when it expires/breaks/needs upgrading/gets compromised, you're totally hosed. I've seen more than one environment brought to its knees because it was easy to check the "use certificates for my AD environment" boxes in Windows (just as an example), and then the root CA is on a laptop in Jim-Bob's desk drawer and five years after he retires the whole network goes sideways and no one knows why or how to fix it.
Fortunately, as someone pointed out up-thread, the demand for new PKI being generated not just for SSL by things like Let's Encrypt but also by things like device-aware trust is helping encourage a trend in making it easier to do it correctly and harder to do it wrong. Not quite there yet, but showing signs of improvement.
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.
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.
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.
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.
Usually when people complain about PKI being too complex, they're complaining about the opacity of the implementations. Certificates just stop working, and you don't get anything, and there's nowhere to look to figure out why unless you're really an expert on the topic.
Thanks for sharing, this kind of information is really rare and useful because A LOT of (techincal) people just don't understand PKI and certificates properly.
Also you've mentioned in the section “Naming things” that DN is deprecated, strictly speaking it's not. The Subject field is deprecated when browser matches certificate with domain, DN is still perfectly valid and Subject field MUST contain a proper DN as stated in https://tools.ietf.org/html/rfc5280#section-4.1.2.6.
Actually it seems there is a mixup in the original text between DN (Distinguished Name) and CN (Common Name). The former is a generic term for a structured X.500 name, the latter a specific field in the Subject Name of a certificate, which is technically a DN.
The convention used to be that the CN field must match the DNS name of the server in a server TLS certificate, but this feature is indeed deprecated and the DNS name extension should be used instead.
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?
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.
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?
That's sadly quite normal in corporate networks. It only works because on your computer you have the firewall installed a root CA, though. If you didn't you would immediately be alerted of the man-in-the-middle attack the firewall is doing.
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.
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)"
This is really good. Reformat it and turn it in to a book. Market it as essential reading for anyone running or thinking about running kubernetes or vault.
Edit: actually this is way more in depth than is needed for k8s. But, I think that's a good target market for a book you can sell like candy for $25.
>I'm curious - I've never seen tech books that short that people actually buy.
Not sure about 20 pages or so, but there's a whole variety of short tech books. O'Reilly had their "pocket reference" series, some of which are less than 100 pages.
$25 for what would amount to a 30 page book? I sincerely hope nobody is gullible enough to pay that much for information that can be found quite easily for free.
Shameless plug: For anybody interested in the cryptographic key management part there is a post about the hardware, people and processes behind the commercial cryptographic key management
https://www.malgregator.com/key-management.html
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. We don't want untrustworthy or incompetent CAs at all, this is not a guard against those. This is a guard against trustworthy, competent CAs that you've got your own reasons to disallow for your specific names.
Example: Facebook for years had a single preferred CA and their contract with that CA said everything gets signed off by the certificates team. After Let's Encrypt came on the scene a subcontractor developing example.facebook.com needed HTTPS, didn't read all the paperwork from Facebook and just got a cert from Let's Encrypt. Facebook security freaked out because their team hadn't authorised this weird new certificate. Let's Encrypt did nothing wrong, but it looked exactly like an attack. CAA lets Facebook tell every CA except the one that knows about their internal policy, "Thanks, but no thanks". Let's Encrypt would have checked CAA and told the subcontractor "Sorry, no, policy forbids, check CAA" and when they went to Facebook to ask why they'd have got an earful for not obeying policy.