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.
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.
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.
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.
$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
tialaramex|7 years ago
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.
peterwwillis|7 years ago
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.
mmalone|7 years ago
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.
DyslexicAtheist|7 years ago
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.
coldtea|7 years ago
Perhaps as knowledgeable engineers they can understand accidental complexity when they see it.
arethuza|7 years ago
However, the systems that people build on top of SMTP (often to address shortcomings in SMTP being too simple) can often be Lovecraftian horrors.
castillar76|7 years ago
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.
syn0byte|7 years ago
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.
Aqua|7 years ago
commandlinefan|7 years ago
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.
blattimwind|7 years ago
rdtsc|7 years ago
Those are kind of two different things. Aircraft work. Brains work. CPUs work. Many things work and are still complex.
sigsergv|7 years ago
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.
juhanima|7 years ago
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.
smartbit|7 years ago
smartbit|7 years ago
Anyone able to shed some light on what happened there to me?
jlgaddis|7 years ago
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?
dwd|7 years ago
If it was TLS 1.2, disable 1.0/1.1 again and check you still have that cipher available.
inetknght|7 years ago
It's far better to force them to upgrade than to allow them to force you to be insecure.
Wildgoose|7 years ago
They are supposed to whitelist financial addresses (such as banking details) but would you trust that to be happening?
black-tea|7 years ago
shittyadmin|7 years ago
teddyh|7 years ago
http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
robinhowlett|7 years ago
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.
yanslookup|7 years ago
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.
viraptor|7 years ago
The closest I know of are the Julia Evans' zines, but I think you meant something different.
tallanvor|7 years ago
CHsurfer|7 years ago
mmalone|7 years ago
(Edit: work at smallstep; want to fix)
viralpoetry|7 years ago
known|7 years ago
teddyh|7 years ago
zodvik|7 years ago
cloudify|7 years ago
mmalone|7 years ago
unknown|7 years ago
[deleted]
geoffbp|7 years ago