7 ms·

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

387 points by zodvik 8y ago

yanslookup 8y ago
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.
- viraptor 8y ago
  I'm curious - I've never seen tech books that short that people actually buy. Could you link some example? The closest I know of are the Julia Evans' zines, but I think you meant something different.
  - jensv 8y ago
    Here's an example on GTFS. https://gumroad.com/l/gtfsbundle https://gumroad.com/l/gtfsbundle
  - coldtea 8y ago
    >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.
- tallanvor 8y ago
  $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.
smartbit 8y ago
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?
- jlgaddis 8y ago
  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?
- inetknght 8y ago
  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.
- dwd 8y ago
  Check your mail headers as they will show what protocol and cipher was negotiated - you'll be able to see if it was actually 1.0 or 1.1 that was used. If it was TLS 1.2, disable 1.0/1.1 again and check you still have that cipher available.
CHsurfer 8y ago
At work, on Chrome I get this error: `ERR_SSL_PROTOCOL_ERROR`... oh the irony.
- mmalone 8y ago
  That’s weird. Screen shot or something? (Edit: work at smallstep; want to fix)
  - Sahbak 8y ago
    You should disable tls1.0 (and 1.1, preferably). Chrome has disabled the support for that
sigsergv 8y ago
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 https://tools.ietf.org/html/rfc5280#section-4.1.2.6.
- juhanima 8y ago
  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.
- smartbit 8y ago
  Some SANs are more equal than others
zodvik 8y ago
FYI - I'm not the author of the article. I found it very useful and hence posted it here on HN.
known 8y ago
Love it. Very elaborate and informative.
tialaramex 8y ago
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. 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 8y ago
  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.
  - jacobparker 8y ago
    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%.
DyslexicAtheist 8y ago
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.
- Aqua 8y ago
  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.
  - DyslexicAtheist 8y ago
    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.
- coldtea 8y ago
  >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.
geoffbp 8y ago
Good article thanks for sharing
deleted 8y ago
[deleted]
teddyh 8y ago
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 http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf
- robinhowlett 8y ago
  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-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.
shittyadmin 8y ago
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.
cloudify 8y ago
Thanks for the great tutorial, just wanted to point out a typo in your homepage (permieter)
- mmalone 8y ago
  Lol oops. Thanks.
viralpoetry 8y ago
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 https://www.malgregator.com/key-management.html
Wildgoose 8y ago
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?
- black-tea 8y ago
  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.
teddyh 8y ago
There is more to HTTPS than just certificates. For instance, the website lacks an HSTS header.

387 points by zodvik 8y ago

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.

viraptor 8y ago
I'm curious - I've never seen tech books that short that people actually buy. Could you link some example? The closest I know of are the Julia Evans' zines, but I think you meant something different.
- jensv 8y ago
  Here's an example on GTFS. https://gumroad.com/l/gtfsbundle https://gumroad.com/l/gtfsbundle
- coldtea 8y ago
  >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.
tallanvor 8y ago
$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.

smartbit 8y ago

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?

jlgaddis 8y ago
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?
inetknght 8y ago
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.
dwd 8y ago
Check your mail headers as they will show what protocol and cipher was negotiated - you'll be able to see if it was actually 1.0 or 1.1 that was used. If it was TLS 1.2, disable 1.0/1.1 again and check you still have that cipher available.

CHsurfer 8y ago

At work, on Chrome I get this error: `ERR_SSL_PROTOCOL_ERROR`... oh the irony.

mmalone 8y ago
That’s weird. Screen shot or something? (Edit: work at smallstep; want to fix)
- Sahbak 8y ago
  You should disable tls1.0 (and 1.1, preferably). Chrome has disabled the support for that

sigsergv 8y ago

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 https://tools.ietf.org/html/rfc5280#section-4.1.2.6.

juhanima 8y ago
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.
smartbit 8y ago
Some SANs are more equal than others

zodvik 8y ago

FYI - I'm not the author of the article. I found it very useful and hence posted it here on HN.

known 8y ago

Love it. Very elaborate and informative.

tialaramex 8y ago

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. 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 8y ago
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.
- jacobparker 8y ago
  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%.

DyslexicAtheist 8y ago

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.

Aqua 8y ago
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.
- DyslexicAtheist 8y ago
  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.
coldtea 8y ago
>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.

geoffbp 8y ago

Good article thanks for sharing

deleted 8y ago

[deleted]

teddyh 8y ago

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 http://www.cs.auckland.ac.nz/~pgut001/pubs/pkitutorial.pdf

robinhowlett 8y ago
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-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.

shittyadmin 8y ago

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.

cloudify 8y ago

Thanks for the great tutorial, just wanted to point out a typo in your homepage (permieter)

mmalone 8y ago
Lol oops. Thanks.

viralpoetry 8y ago

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 https://www.malgregator.com/key-management.html

Wildgoose 8y ago

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?

black-tea 8y ago
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.

teddyh 8y ago

There is more to HTTPS than just certificates. For instance, the website lacks an HSTS header.