TLS Mastery
mwl.io
mwl.io
Practical, not necessarily theoretical; but if that’s what you are looking for, then it’s a great book.
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.
I haven't read the book, but learning more about TLS is easily one of the best time investments I've made.
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’ve written more about it here: https://gruchalski.com/posts/2021-03-28-firebuild-rootfs-grp....
http://www.moserware.com/2009/06/first-few-milliseconds-of-h...
He also wrote Absolute FreeBSD and PGP & GPG: Email for the Practical Paranoid, among many others.
I just sat through the 4 1/2 day online training they offer, and thought it was worth the price, as long as the company was picking up the tab.
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).
This command alone in the first ten pages makes it worth it. Establish TLS connection, get certs, and decode certs for any site:
openssl s_client -showcerts -connect www.mwl.io:443 </dev/null | openssl x509 -text -noout
10/10.
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.
Probably one of the best tech writers I’ve ever encountered. I own most of this books - especially the more BSD specific ones.
TLS privacy seems to be a big rather little-known topic. OCSP leaks etc. Does this book cover it in-depth?
EDIT: Okay, it looks like this is not yet ready for most people to use.
https://www.youtube.com/watch?v=AIDnO_QB64A is the most recent interim video conference meeting on this topic.
I expect that during 2021 they'll pin down the more controversial parts that remain to be done.
As an end user, I have been using ESNI-enabled openssl to make HTTP requests to sites using Cloudflare and for me it works great.
People were always surprised how they stay logged in after clearing cookies.
Basically, you need to get the session ticket from the webserver being available at the backend, and set its lifetime to something reasonable.
At least NGINX can then handle all of the session resume/renew logic by itself.
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.
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.)
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.
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.
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.
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.