Intuiting TLS(kprotty.me)
kprotty.me
Intuiting TLS
http://kprotty.me/2025/04/01/intuiting-tls.html
9 comments
To quickly build something with signatures, key exchange and encryption, I'd recommend starting with libhydrogen: https://github.com/jedisct1/libhydrogen
Interest article, but overlooks SPEKE, which solves problem #1.
There is another protocol for authenticated and integrity protected key exchange, one that solved both the problem of authenticity and integrity attacks, but I cannot recall it.
Hoping someone else remembers it.
There is another protocol for authenticated and integrity protected key exchange, one that solved both the problem of authenticity and integrity attacks, but I cannot recall it.
Hoping someone else remembers it.
> Interest article, but overlooks SPEKE, which solves problem #1.
Well, sort of.
At a high level there are two scenarios:
1. The endpoints have had no prior contact. 2. The endpoints have had some prior opportunity to establish shared state.
The common version of case (1) is the Web, where the client has the server's identity (i.e., a domain name). When the client connects to the server, the server has to prove its identity, specifically a binding between its name and its public key. That's where certificates come in because they allow the server to prove [0] its identity to a third party who when vouches for that attestation.
The case where the endpoints have had an opportunity to establish shared state is different. There are basically three settings:
- The shared state is one side's public key. In this case, you can (mostly) use the same kinds of authenticated key establishment protocols as before, just without the certificate. This is how SSH works. - The shared state is a high entropy secret (a pre-shared key). In this case, you can use it to bootstrap up to a shared key by authenticating the endpoints. TLS 1.3 provides such a PSK mode. - The shared state is a low entropy secret (a password).
This last case is challenging because in the obvious protocol where you use it like a PSK an attacker can record a single protocol run and then exhaustively search the password space. The solution here is what's called a password authenticated key agreement (PAKE) protocol, which resists this kind of attack. SPEKE is one such protocol, though most of the interest now is in newer protocols like OPAQUE or SPAKE2+. There are proposals to bind these to TLS (https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/) but they don't really work for the Web (https://educatedguesswork.org/posts/password-proto/#password...).
[0] For some value of prove. Terms and conditions may apply.
Well, sort of.
At a high level there are two scenarios:
1. The endpoints have had no prior contact. 2. The endpoints have had some prior opportunity to establish shared state.
The common version of case (1) is the Web, where the client has the server's identity (i.e., a domain name). When the client connects to the server, the server has to prove its identity, specifically a binding between its name and its public key. That's where certificates come in because they allow the server to prove [0] its identity to a third party who when vouches for that attestation.
The case where the endpoints have had an opportunity to establish shared state is different. There are basically three settings:
- The shared state is one side's public key. In this case, you can (mostly) use the same kinds of authenticated key establishment protocols as before, just without the certificate. This is how SSH works. - The shared state is a high entropy secret (a pre-shared key). In this case, you can use it to bootstrap up to a shared key by authenticating the endpoints. TLS 1.3 provides such a PSK mode. - The shared state is a low entropy secret (a password).
This last case is challenging because in the obvious protocol where you use it like a PSK an attacker can record a single protocol run and then exhaustively search the password space. The solution here is what's called a password authenticated key agreement (PAKE) protocol, which resists this kind of attack. SPEKE is one such protocol, though most of the interest now is in newer protocols like OPAQUE or SPAKE2+. There are proposals to bind these to TLS (https://datatracker.ietf.org/doc/draft-bmw-tls-pake13/) but they don't really work for the Web (https://educatedguesswork.org/posts/password-proto/#password...).
[0] For some value of prove. Terms and conditions may apply.
HMAC?
No, though HMACs can play a role. It was a protocol developed specifically for establishment of secure, encrypted, authenticated, and integrity-protected sessions.
I've been racking my brain trying to remember (rarely accessed memories from ~27 years ago). The basic challenge is that unless authenticity, key exchange, and integrity are managed simultaneously during session establishment, there are attacks possible against whatever was omitted. There was a protocol developed at that time that did all of the above as part of session establishment, but I don't remember it really taking off (IIRC, it was patent-encumbered, and that was an obstacle to adoption).
I've been racking my brain trying to remember (rarely accessed memories from ~27 years ago). The basic challenge is that unless authenticity, key exchange, and integrity are managed simultaneously during session establishment, there are attacks possible against whatever was omitted. There was a protocol developed at that time that did all of the above as part of session establishment, but I don't remember it really taking off (IIRC, it was patent-encumbered, and that was an obstacle to adoption).
the jump between paragraphs 2 and 3 of the "key exchange" section totally lost me, as it does not explain how (K1 op P2) and (K2 op P1) produce a shared secret...
That part is implementation-specific. Traditional RSA uses multiplication of prime numbers, Wikipedia's explanation is decent: https://en.m.wikipedia.org/wiki/RSA_cryptosystem
In modern times other implementations are used such as elliptic curves (which have better performance, especially important for battery powered devices like phones) or lattice based cryptography (which are not vulnerable to quantum computers)
In modern times other implementations are used such as elliptic curves (which have better performance, especially important for battery powered devices like phones) or lattice based cryptography (which are not vulnerable to quantum computers)
Nitpick: the claim that digital signatures and certificates are necessary because otherwise "it requires a PSK per website which is impractical", is false.
This claim is very frequently heard, but repeating it does not make it any truer.
There are advantages in using digital signatures and certificates, but this is not among them. The main advantage of digital signatures and certificates is that they allow semi-authenticated connections, where only the server is authenticated, but the client is not authenticated.
When pre-shared keys (PSK) are used instead of digital signatures and certificates, the pre-shared keys must be used only for the authentication of the key-exchange messages, which are used to establish fresh session keys, exactly like when using certificates instead of PSK.
While one implementation option is to store PSKs for all the systems with whom one may want to establish connections, the other option is to store the PSKs on one central server (or on a few servers).
When establishing a connection, the two parties interrogate the central server to get the authentication keys that must be used for this pair of communicating parties. While this adds overhead to connection establishment, the overhead is less than checking for certificate revocation.
The overhead can be reduced by standard techniques, i.e. caching the authentication keys of frequent communication partners. When done correctly, using PSKs instead of certificates always results in much less overhead for connection establishment.
However, as I have mentioned before, while PSKs can be superior for communication inside a closed organization, on the public Internet certificates provide the desirable feature of semi-authenticated connections, where a previously unknown client can still connect securely to an authenticated server.
Because all Web browsers must implement certificate-based authentication for communication with public websites, it becomes more convenient to use the same authentication method even inside closed organizations, where using PSKs might have been more efficient.
A database with PSKs for pairs of communicating computers is much smaller than a database with certificates when the number of communicating computers is small. Because the number of entries grows with the square of the number of communicating parties, the size of the PSK database will become too large at some threshold, which is the second reason why certificates are better for the public Internet.
However, this database size problem exists only when the PSKs are stored centrally. If a computer would store locally either the PSKs or the certificates for all possible communication partners, PSKs would need the same number of entries as certificates, but much less storage, regardless of the number of communication partners.
Certificates avoid the storage problem by using a hierarchy of certificates. Similarly, a hierarchical organization of PSK-providing servers could reduce the requirements for storing PSKs in the centralized variant. There is also the variant where the central server does not store PSKs for each pair of communicating nodes, but it generates new authentication keys for that pair, at each request. In general, there are workarounds for any of the possible advantages of certificates vs. PSKs, except for the implementation of semi-authenticated connections.
This claim is very frequently heard, but repeating it does not make it any truer.
There are advantages in using digital signatures and certificates, but this is not among them. The main advantage of digital signatures and certificates is that they allow semi-authenticated connections, where only the server is authenticated, but the client is not authenticated.
When pre-shared keys (PSK) are used instead of digital signatures and certificates, the pre-shared keys must be used only for the authentication of the key-exchange messages, which are used to establish fresh session keys, exactly like when using certificates instead of PSK.
While one implementation option is to store PSKs for all the systems with whom one may want to establish connections, the other option is to store the PSKs on one central server (or on a few servers).
When establishing a connection, the two parties interrogate the central server to get the authentication keys that must be used for this pair of communicating parties. While this adds overhead to connection establishment, the overhead is less than checking for certificate revocation.
The overhead can be reduced by standard techniques, i.e. caching the authentication keys of frequent communication partners. When done correctly, using PSKs instead of certificates always results in much less overhead for connection establishment.
However, as I have mentioned before, while PSKs can be superior for communication inside a closed organization, on the public Internet certificates provide the desirable feature of semi-authenticated connections, where a previously unknown client can still connect securely to an authenticated server.
Because all Web browsers must implement certificate-based authentication for communication with public websites, it becomes more convenient to use the same authentication method even inside closed organizations, where using PSKs might have been more efficient.
A database with PSKs for pairs of communicating computers is much smaller than a database with certificates when the number of communicating computers is small. Because the number of entries grows with the square of the number of communicating parties, the size of the PSK database will become too large at some threshold, which is the second reason why certificates are better for the public Internet.
However, this database size problem exists only when the PSKs are stored centrally. If a computer would store locally either the PSKs or the certificates for all possible communication partners, PSKs would need the same number of entries as certificates, but much less storage, regardless of the number of communication partners.
Certificates avoid the storage problem by using a hierarchy of certificates. Similarly, a hierarchical organization of PSK-providing servers could reduce the requirements for storing PSKs in the centralized variant. There is also the variant where the central server does not store PSKs for each pair of communicating nodes, but it generates new authentication keys for that pair, at each request. In general, there are workarounds for any of the possible advantages of certificates vs. PSKs, except for the implementation of semi-authenticated connections.
I spent several years implementing TLS in embedded systems, and I've never seen the intuition behind authenticated key exchange explained this clearly. The author manages to capture both the "why" and the "how" without getting bogged down in mathematical notation.
The explanation of the man-in-the-middle vulnerability was especially well-done - most articles either skip over this crucial weakness or explain it so technically that newcomers get lost. The starbucks router example makes it immediately obvious why key authenticity matters.
One tiny nitpick: the article simplifies by saying "you can't know you're talking to someone if you don't already know who they are" - but this overlooks the role of certificate transparency logs and OCSP, which add significant layers of protection beyond just trusting certificate authorities.
For anyone wanting to learn more, I'd second the recommendation of Julia Evans' materials. Her zines explain these concepts visually in ways that make this stuff click for many engineers.