5 ms·

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

by ivanr 5y ago

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.

colmmacc 5y ago
Serious question, how did you weigh up taking the "SSL" out of the book title?
- ivanr 5y ago
  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 5y ago
    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.
    - ivanr 5y ago
      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 5y ago
      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 5y ago
        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 5y ago
Your description here: https://www.feistyduck.com/books/bulletproof-tls-and-pki/ https://www.feistyduck.com/books/bulletproof-tls-and-pki/ still talks about the second edition in the future tense.
- ivanr 5y ago
  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 5y ago
    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.
schoen 5y ago
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?
- tialaramex 5y ago
  (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 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 5y ago
  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/ 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-ech-update/ https://blog.cloudflare.com/handshake-encryption-endgame-an-...
artificialLimbs 5y ago
What if we just want to heap praises upon you?
- ivanr 5y ago
  That, too, would be most welcome :)
coupdejarnac 5y ago
Does the book say anything about best practices for deploying PKI on IoT?
- ivanr 5y ago
  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.
  - coupdejarnac 5y ago
    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.
    - ivanr 5y ago
      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-identities https://doc.primekey.com/ejbca/solution-areas/iot-and-device...

by ivanr 5y ago

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.

colmmacc 5y ago

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

ivanr 5y ago
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 5y ago
  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.
  - ivanr 5y ago
    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 5y ago
    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 5y ago
      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 5y ago

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

ivanr 5y ago
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 5y ago
  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.

schoen 5y ago

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?

tialaramex 5y ago
(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 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 5y ago
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/ 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-ech-update/ https://blog.cloudflare.com/handshake-encryption-endgame-an-...

artificialLimbs 5y ago

What if we just want to heap praises upon you?

ivanr 5y ago
That, too, would be most welcome :)

coupdejarnac 5y ago

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

ivanr 5y ago
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.
- coupdejarnac 5y ago
  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.
  - ivanr 5y ago
    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-identities https://doc.primekey.com/ejbca/solution-areas/iot-and-device...