On Sep 12, 2024, at 10:20 AM, Luca Borruto via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
Hey ! I am currently using FreeRADIUS with EAP-TLS for client authentication, and I have configured a TLS session cache directory at `/var/log/freeradius/tlscache/`. However, every time a client reconnects, FreeRADIUS creates new `.vps` and `.asn1` files for each session, even though the session details remain the same.
If it creates new cache files, then the session details aren't the same.
**Expected Behavior**: FreeRADIUS should reuse the cached session when a client reconnects instead of creating new cache files.
**Actual Behavior**: A new pair of `.vps` and `.asn1` files is created for every connection, leading to unnecessary cache file creation and a potential performance hit.
**Logs Showing the Issue**: When a client reconnects, FreeRADIUS logs indicate that it doesn’t find the cached session, even though it previously created one:
FreeRADIUS isn't at fault here. If the the client reconnects and uses session resumption, then the client sends the session ticket to FreeRADIUS. This must be the same session ticket which it received fly FreeRADIUS in the previous session.
For the second connection attempt: ``` (8) eap_tls: Peer requested cached session: 604b28a21b0839df85aac31a93fc59ae1efa3f58781088cb0df999c05fa9d01b (8) eap_tls: WARNING: (TLS) TLS - No persisted session file /var/log/freeradius/tlscache/604b28a21b0839df85aac31a93fc59ae1efa3f58781088cb0df999c05fa9d01b.asn1: No such file or directory
What's going on here is: 1) something on the FreeRADIUS system is cleaned up the cache files, so that's why they don't exist. FreeRADIUS doesn't do this by default, so it's something else. 2) the client is send an old / wrong session ticket.
(8) eap_tls: (TLS) TLS - Handshake state - Server SSLv3/TLS read client hello ```
Then it recreates the session file:
No, it creates a *different* session file, with a *different* key. Session files are keyed by the session ticket. That's how the sessions are identified. There's no other magic token saying "it's the same session". The only token is the session ticket.
Why is FreeRADIUS not reusing the cached session and instead creating new cached session files for every connection attempt? Is there a configuration issue or a potential bug that might be causing this?
Session resumption works when: 1) nothing else deletes the cache files 2) the client gets the session ticket from FreeRADIUS, and then returns the *same* session ticket when doing session resumption. Alan DeKok.