[HN Gopher] Show HN: My Book Bulletproof TLS and PKI (Second Edi...
___________________________________________________________________
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-... I hope you'll enjoy the book.
Author : ivanr
Score : 79 points
Date : 2022-03-02 17:10 UTC (5 hours ago)
(HTM) web link (www.feistyduck.com)
(TXT) w3m dump (www.feistyduck.com)
| ivanr wrote:
| 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.
| schoen wrote:
| 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?
| aaomidi wrote:
| 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"
| tialaramex wrote:
| (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.
| ivanr wrote:
| 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-...
| 1vuio0pswjnm7 wrote:
| https://defo.ie
|
| Test whether SNI is encrypted:
|
| https://crypto.cloudflare.com/cdn-cgi/trace
| artificialLimbs wrote:
| What if we just want to heap praises upon you?
| ivanr wrote:
| That, too, would be most welcome :)
| colmmacc wrote:
| Serious question, how did you weigh up taking the "SSL" out of
| the book title?
| ivanr wrote:
| 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.
| tialaramex wrote:
| 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(tm) as we understand it
| today first, this is not a history lesson.
| ivanr wrote:
| 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".
| commandlinefan wrote:
| 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.
| ivanr wrote:
| 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 :)
| bombcar wrote:
| Your description here:
| https://www.feistyduck.com/books/bulletproof-tls-and-pki/ still
| talks about the second edition in the future tense.
| ivanr wrote:
| 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!
| bombcar wrote:
| 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.
| [deleted]
| righttoolforjob wrote:
| Thanks Ivan I've thoroughly enjoyed the previous version.
| sirmike_ wrote:
| Just purchased thanks!
| schoen wrote:
| This is a _really_ thorough book. I think most people working in
| this area can learn a lot from it.
___________________________________________________________________
(page generated 2022-03-02 23:00 UTC)