Show HN: My Book Bulletproof TLS and PKI (Second Edition) Is Out (feistyduck.com)
I am excited to share with you my new book, Bulletproof TLS and PKI. I've worked in this space since the very early days (think SSLv2), always frustrated with the fact that the field is vast but the documentation poor. That first led me to create SSL Labs (which ended up being very popular) and then the first edition of my book (in 2014), where I aimed to cover everything a curious person needed to know about SSL/TLS and PKI. Most importantly, it's a very practical book that you can use to just learn what you need at that moment. The second edition (just out) adds coverage of TLS 1.3. I publish two chapters as a separate (and free) OpenSSL Cookbook. There's another free sample chapter as well.
The best part of Bulletproof TLS and PKI is that it's a living book. There's nothing worse than obsolete documentation! Because none of the traditional publishers were interested in that sort of thing, we did everything ourselves. The manuscript is in DocBook, I write using OxygenXML, my copyeditor uses it as well, and there's a nightly build process that generates everything. We can even show exact differences across versions, for example you can see that here: https://blog.ivanristic.com/2022/02/bulletproof-tls-and-pki-...
I hope you'll enjoy the book.
36 comments
[ 3.7 ms ] story [ 104 ms ] threadOn a positive note, I was able to add "PKI" to the title, which makes sense because the book is actually about PKI as much as it is about TLS. A win-win, I think.
TLS 1.3 is definitely a good breaking point. If you understood exactly how SSLv3 works, you could read TLS 1.2 and say to yourself OK, this is basically the same protocol except with some fresh paint and with some extra gadgets I needn't care about yet, whereas you just can't do that with TLS 1.3.
I also see you put TLS 1.3 first, and I think that's a good choice, show people the Right Thing™ as we understand it today first, this is not a history lesson.
How is that doing? What's the status of the ability to connect to a CDN without revealing to the network which CDN customer you're talking to?
Is there still a new DNS RR for communicating ECH public keys along with IP addresses?
Encrypted Client Hello is still named Encrypted Client Hello, as of https://www.ietf.org/archive/id/draft-ietf-tls-esni-14.txt
It's not really true that "it keeps getting renamed" the original intent in ekr's draft was to encrypt SNI, but then the question is why not encrypt other things in the client hello, and if you're going to then why not encrypt the entire client hello?
There isn't really room for further scope increase, the server hello was already encrypted in TLS 1.3 anyway.
For context: one of the long-standing problems with TLS was and still is the fact that it leaks a lot of metadata. You could say that it's a chicken and egg problem. To encrypt anything you first need to agree on the parameters, which happens during the handshake. TLS 1.3 improved things a lot by encrypting all server handshake traffic that can be encrypted, but a lot of metadata remained in plaintext. That information can be used for client fingerprinting, for example.
Among other things, website name is transported in the clear, in the Server Name Indication (SNI) extension. This is a problem if you want to access a particular website but don't want, say, the authorities to know.
This problem was discussed during the development of TLS 1.3, but didn't make the cut. However, development continued afterwards, with the first attempt being Encrypted SNI. That work eventually evolved into ECH. More powerful, but also more complicated. The basic idea behind both ESNI and ECH is that websites can announce public keys for clients to use to encrypt data even on the first flight. As the name says, ECH is designed to encrypt the entire ClientHello (the first message in a TLS handshake.) ESNI relies on a custom DNS TXT record, but ECH uses the new SVCB DNS RR https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https... (which is interesting for a couple of other features, for example to use as an indication that a website is HTTPS-only).
Cloudflare have been working on ESNI and ECH. Here's one good blog post where they go into detail about how it all works: https://blog.cloudflare.com/handshake-encryption-endgame-an-...
We saw with the rollout of CAA that it's actually kind of challenging to add new DNS RRs because a lot of DNS implementations are hard-coded to block ones they don't understand, even though the DNS standards tell them not to do that. So I'm a bit worried that a lot of DNS services will have a hard time with SVCB records for a long while.
I guess having SVCB queries get dropped (or return false negatives or spurious errors) would be catastrophic for the ability to negotiate via ECH, since then the client won't know the key, but not catastrophic for the ability to negotiate a TLS session at all (since you can still fall back to CNAME and A/AAAA records in this case).
Test whether SNI is encrypted:
https://crypto.cloudflare.com/cdn-cgi/trace
I hope services setup a "ech.fqdn" endpoint that forces ECH and doesn't work without it. Something like "encrypted.google.com" from before https was so popular.
E.g. "ech.facebook.com", or "ech.youtube.com"
https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an... https://news.ycombinator.com/item?id=28103770
Only something like Apple Private Relay or Tor can solve that issue.
I feel that in many situations the solution for IoT PKI is to find a good vendor who will support you, and there's plenty of those around to choose from.
If you have a moment, I would appreciate if you could share some more specific questions, and perhaps your use cases. That will help me understand if it's something I can cover in a future update. That said, the book is already quite big at 500 pages.
I suppose my biggest gripe is that it has been hard to find sources of best practices. Almost everything I find is amateurish/not designed to scale or white papers designed to sell services. Or when I encounter best practices, they are too vague to be actionable.
Without mutual authentication you won't be able to authenticate the devices themselves. Perhaps you intend to have a different mechanism, perhaps sign the messages? I feel that signing the messages would provide better security guarantees as the signatures will accompany the data.
I think the most important aspect to get right is to have the ability to update the root material. No matter what CAs you end up using, their roots will eventually expire and will need to be replaced. Clearly, you don't want to lose the root material as that would be catastrophic. Using two separately managed roots would probably be a good idea.
AWS and Google have private CA services, and EJBCA is also worth exploring, for example: https://doc.primekey.com/ejbca/solution-areas/iot-and-device...
I have a makefile to share at some point. Great work!
A more specific IoT question. For an IoT gateway, I look for a way to safely generate and revoke certificates for different protocols and mTLS (certificate to be be installed on the counterpart of the gateway). Any tips on best practices or companies?
On the do-it-yourself side, take a look at Google's Certificate Authority Service https://cloud.google.com/certificate-authority-service and the AWS Certificate Manager Private Certificate Authority https://aws.amazon.com/certificate-manager/private-certifica...
Another choice is EJBCA, and here's their documentation for the IoT use case: https://doc.primekey.com/ejbca/solution-areas/iot-and-device... EJBCA is open source, but at least some of the IoT features (specifically those that deal with device enrolment) are enterprise-only.