6 ms·
Show HN: My Book Bulletproof TLS and PKI (Second Edition) Is Out
Hello HN.
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-is-out.html https://blog.ivanristic.com/2022/02/bulletproof-tls-and-pki-...
I hope you'll enjoy the book.
- deleted 5y ago[deleted]
- gq0 5y agoAwesome book. Just started reading it a week ago 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?
- ivanr 5y agoPersonally I'd go with a third-party service that will manage the PKI side of things, possibly two. That would relieve you of a big burden, leaving you to only invoke their APIs as needed. Most big CAs have specific IoT products. On the do-it-yourself side, take a look at Google's Certificate Authority Service https://cloud.google.com/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-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-identities 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.
- gq0 5y agoAwesome, many thanks for the recommendations. I will check it out.
- iconhacker 5y agoI ordered the book on the Feisty Duck website last Friday. I still have not received the download link. Sent email to the link on the website. No response so far. Is this web site a hoax?
- ivanr 5y agoWhile we're here, please feel free to ask me anything, either about SSL/TLS and PKI or about the publishing process. I'll be around to answer your questions. Thanks.
- colmmacc 5y agoSerious question, how did you weigh up taking the "SSL" out of the book title?
- ivanr 5y agoI spent a lot of time thinking about that, but, in the end, I don't think anyone could justify the words "bulletproof" and "ssl" next to each other. So that was that. The "SSL" part was in the title chiefly because, colloquially, that's what everyone uses, especially for certificates. On 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.
- tialaramex 5y agoI would definitely have an easier time telling somebody they ought to read a book with "TLS" in the title. I think many conversations I have are already filled with too many parentheticals as it is, and so ducking out to agree that yes, it isn't called SSL any more is just one extra layer on a conversation that might already risk stack overflow. 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.
- ivanr 5y agoAgreed. Many modern systems need only TLS 1.3 and nothing older. Unfortunately, TLS 1.3 is saddled with the baggage of backward compatibility. This is not something you might care if you're deploying it, but if you're studying how things work, it's still necessary to understand TLS 1.2 and earlier protocols. There are many places where, in the TLS 1.3 chapter, I had to say something along the lines "this design decision ties to this TLS 1.2 behaviour or problem".
- schoen 5y agoThis is a really thorough book. I think most people working in this area can learn a lot from it.
- righttoolforjob 5y agoThanks Ivan I've thoroughly enjoyed the previous version.
- sirmike_ 5y agoJust purchased thanks!
- rad_gruchalski 5y agoHey, thanks for the second release. I’ve purchased a hard copy last month, right after it came out. Very good read.
- deleted 5y ago[deleted]
- AviationAtom 5y agoLove your newsletter! It's been very insightful and informative!
- foxhop 5y agohow cool is that I have a makefile to share at some point. Great work!