Show HN: My Book Bulletproof TLS and PKI (Second Edition) Is Out

While 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.

Serious question, how did you weigh up taking the "SSL" out of the book title?

I 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.

I 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.

Agreed. 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".

There was actually some discussion on the IETF WG list about changing the name back to SSL when TLS 1.3 was being discussed, because of all the confusion.

I think TLS 4 would have been a good choice, given the massive changes made to the protocol. Fun fact: internally, the protocol version still follows the original SSL numbering scheme. TLS 1.3 is actually SSL 3.4 :)

Your description here: https://www.feistyduck.com/books/bulletproof-tls-and-pki/ still talks about the second edition in the future tense.

Do you mean the text in the "What's In The Book" section? I adapted that bit from the preface and it was actually written late last year. I'll look into rewording it to read better. Thanks!

Yeah, "I am now working on the second edition, and the situation is very similar." - could read correctly in the book itself, but in the text it makes it sound like I should wait, the second edition will be here soon.

Since I left EFF, I haven't followed the ECH mechanism's progress (also, I know this keeps getting renamed, so maybe it's called something else again now).

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?

(Not Ivan)

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.

Well, ECH (Encrypted ClientHello) got... complicated and it's still in development.

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-...

Thanks! SVCB looks like an interesting development.

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).

https://defo.ie

Test whether SNI is encrypted:

https://crypto.cloudflare.com/cdn-cgi/trace

I'm so, so excited for the release of ECH. This is going to revolutionize internet access in so many countries.

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"

ECH doesn't hide IP addresses, which can lead to discovery of the site being accessed even when a CDN is being used.

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.

What if we just want to heap praises upon you?

That, too, would be most welcome :)

Does the book say anything about best practices for deploying PKI on IoT?

There isn't a section in the book that covers IoT specifically. Most of the book is relevant to the topic because it provides a generic foundation that's necessary for more specific use cases.

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.

My main usecase is for remote meter reading. The plan so far is to install self signed certificates at manufacturing and then to update them periodically with OTA. OTAs will be fetched via https. The device will communicate with our backend via mqtt with tls, but not using mutual tls. I suppose I'm asking if this is a suitable approach for deploying a device that mostly has one direction communication.

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.

If you don't want to do mutual authentication then may not need to do anything special. In theory, your servers can get a regular certificate from a public CA. You would get better security with a private CA, ensuring that your devices submit data only to you and not to an impersonator.

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...

Thanks!

Awesome 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?

Personally 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 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.

Awesome, many thanks for the recommendations. I will check it out.

I 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?

Thanks Ivan I've thoroughly enjoyed the previous version.

Hey, thanks for the second release. I’ve purchased a hard copy last month, right after it came out. Very good read.

This is a really thorough book. I think most people working in this area can learn a lot from it.

Love your newsletter! It's been very insightful and informative!

Just purchased thanks!

how cool is that

I have a makefile to share at some point. Great work!