I bought it and skimmed through most of it, and I have a hard time recommending it personally. It’s really short on the crypto and offers no insight into why TLS behaves the way it does. I would like to at least see an explanation of the TLS handshake process, but there is none. It’s a lot of “using openssl s_client”-type of discussion; i.e. how to use it, not so much on how it works, and that applies to most of the book (including the ocsp parts).
Practical, not necessarily theoretical; but if that’s what you are looking for, then it’s a great book.
> It’s really short on the crypto and offers no insight into why TLS behaves the way it does. ... It’s a lot of “using openssl s_client”-type of discussion;
That is literally how the author explained in his book's Amazon Kindle version's free preview[1]. The author specifically said he is not a brilliant mathematician so he's not going into the details of explaining the math but rather explain the how-to from a practitioner's standpoint. Obviously, you don't need to be a brilliant mathematician in order to under the math behind public-key cryptography but for many engineers, I agree with the author that I care more of about how to configure it and make it work securely rather than the reason behind the scene. The author also claimed that he would recommend some further readings if you would like to dig into it more.
TLS always felt like a scary beast to me until I started writing Go. The crypto/tls package is amazing and makes doing incredible things with TLS super easy. We're using it in lots of interesting ways behind the scenes for Encore, leveraging Vault, a custom CA, SPIFFE for workload identity and more.
I haven't read the book, but learning more about TLS is easily one of the best time investments I've made.
> TLS always felt like a scary beast to me until I started writing Go. The crypto/tls package is amazing and makes doing incredible things with TLS super easy.
This x100. I have been recently developing an embedded CA for a gRPC service in golang. Issuing a root, intermediate, server and a client cert for mtls is less than 350 lines of code. It’s incredible.
I see, so a workload spins up and wants to learn something about itself and uses identity verification to gain access to it? My use case was an untrusted node getting a centrally issued key to join a p2p VPN
In my opinion, Michael W Lucas is one of the best tech writers working today. I have made great use of his books Absolute OpenBSD, SSH Mastery, and Httpd & Relayd Mastery.
He also wrote Absolute FreeBSD and PGP & GPG: Email for the Practical Paranoid, among many others.
The contents look good and I feel like it might help me patch some holes in my knowledge. It has the advantage of at least looking like it's up to date (a lot of SSL writing has been obsoleted).
Just bought the Tux edition on Amazon for Kindle. $10. Says it was published/updated April 5, 2021. Hands on practice with OpenSSL. Engaging writing style. Doesn't assume too much or too little. No bullshit.
This command alone in the first ten pages makes it worth it. Establish TLS connection, get certs, and decode certs for any site:
And for the TLS handshake, this is incredibly useful: https://tls.ulfheim.net (The Illustrated TLS Connection). Towards the bottom of this page, you now have TLS 1.3 illustrated as well.
Encrypted Client Hello, which is what eSNI developed into, is an active draft for the TLS working group. If you have relevant expertise I'm sure that the group would be happy to have you, in particular if you have any insight into how to achieve goals like Don't Stand Out while also keeping ECH as simple as possible.
What you're describing can be achieved by misusing TLS session IDs, but the technique doesn't work reliably and it's not secure.
In essence, when client and server handshake, a unique session ID is generated. The server can associate this ID with a user account and use it to identify the user on subsequent requests. Except this works only when client and server are connected directly. If there is a CDN in front of the server, or a proxy in front of the client, the session ID will refer to the intermediary devices, which may be used among many users, and so on. In addition, clients can (and often do) throw away TLS sessions very frequently. The last time I tried this technique (admittedly some two decades ago) Internet Explorer was rotating the session ID every 5 minutes.
There is something called Channel Binding (or Token Binding, the names have changed a couple of times) that can be used to create a cryptographic identity at TLS level. It's the same idea as session ID binding, just properly secure. Google spent a lot of time experimenting with it but IIRC ultimately decided against it. Here's a link to the slides from a couple of years ago: https://tools.ietf.org/agenda/90/slides/slides-90-uta-0.pdf
There is also in TLS something called pre-shared key (PSK) authentication, which is a way to handshake without certificates, but client and server have to share a password instead. (In TLS 1.3, the PSK mechanism is also used for session resumption.)
> There is also in TLS something called pre-shared key (PSK) authentication, which is a way to handshake without certificates, but client and server have to share a password instead.
It is imperative to understand that passwords are not suitable for a TLS 1.3 PSK.
I even ran into this with some people working on CMP in LAMPS ("Limited Additional Mechanisms for PKIX and S/MIME" the poor group left with the work that couldn't be avoided entirely to fix problems in PKIX and/or S/MIME)
No, you can't just run the password through PBKDF2 and consider that good enough. If you really need password authentication, you need an actual password based authentication mechanism, do not try to jury rig PSKs.
This last sentence doesn't really make sense. PBKDF2 is a KDF; its whole purpose is to take low-entropy secrets like passwords and convert them into keys suitable for cryptography. That's not a jury-rigging; it's the intended function of the primitive.
If you share lots of good entropy which is secret then you can use PBKDF2 with that entropy as salt to turn bad passwords like "OpenSesame" into a good secret key.
And in that case you're right, TLS 1.3 PSKs made this way would in principle be safe because they meet the high entropy requirement. If I guess "OpenSesame" I can't guess the PSK because I don't know the salt.
But, wait, if we have enough shared entropy that's secret then we already have a suitable Pre-shared Secret Key and we didn't need to invoke PBKDF2, our design is over-complicated.
So why do people want to do PBKDF2 at all? Well of course they don't have that shared secret entropy, they were hoping "OpenSesame" was good enough and that if they can just squint hard at the PSK feature surely they can use their password for it, which is why TLS 1.3 explicitly cautions them not to do so.
What surprises people here is that there's a viable offline dictionary attack. What they tend to be imagining is that a hypothetical bad guy has to try connecting with password "Pass1234" and then try again "LetMeIn" and then again, and again, until they try "OpenSesame" and so that seems impractical.
But TLS 1.3 does afford a dictionary attack, during the unencrypted ClientHello the client sends over enough information for an attacker to confirm whether a PSK they've guessed is correct. So the attacker just collects that information, then they get to run an offline dictionary attack.
This isn't a threat for a good PSK because it's just random. You could try such an "attack" on everything else in TLS, and it would be just as (in)effective. But for a human memorable password of course dictionary attacks are a real threat because there may be only millions or even thousands of likely guesses.
Does spawning new incognito sessions mitigate this? I know for me I have set all my various browsers to use incognito mode by default, so all my sessions are insulated from each other and can't 'talk' to each other. For sessions where I need to be logged in/use cookies, I have a dedicated Firefox profile that I launch with the `-p` switch in the launcher icon, and I never do anything sensitive in this session, so I don't care about secrets being leaked into that session.
I think he might be referring to tls sessions. When a client comes back to a server it remembers that it connected to it can send a session Id encrypted with the master secret or a complete session ticket. When the handshake completes successfully you know who it was if you stored that information. It saves using a cookie. Also it might not be supported in every client.
I think you still need to have mTLS or another credential to use initially for auth. Unless I miss an option. As such I don’t see much value over mtls in a corporate network setting.
Step 1. Give up volition to a third party certificate authority and hope your internet service is never controversial enough to get it revoked like sci-hub.
I have my own certs signed by my own CA that I trust enough to have in my browser allowed CA cache
However I'd far rather be able to import a root cert with my own constraints -- use this root cert to authenticate by only for sites in my list (which I'd add say .blarge.com, .muhhaa.de, dohicky.google.com, etc), but that feature doesn't site in firefox, I either trust the root or I don't, which means I have to be far more careful about the root cert because rather than intercepting a few dev sites.
If you want this, (I don't advise it but you seem to have your heart set) the way to do it goes like this:
1. Generate a fresh root as you do today. Keep the resulting CA certificate for the root to one side, let's call this CA1
2. Create an intermediate CA certificate, this says there's a new CA, let's call it CA2 with a new private key, and this certificate gets to have constraints. Put all the constraints you've decided upon in here. Sign it using CA1 with your private key.
3. Destroy the private key for CA1.
4. Tell Firefox to trust root CA1.
5. You can now issue from CA2 and since it chains back to CA1 this is trustworthy, but only so long as it obeys the constraints. You can't issue from CA1 (which is fully trusted) because you destroyed the key.
Practical, not necessarily theoretical; but if that’s what you are looking for, then it’s a great book.