TLS Cache

[Rodrigo Prieto]

Thanks Alan for replying. I did the test using:

eapol_test -r 1 -a 127.0.0.1 -c ap.conf -s testing123

and it appears that the session is reused. It works correctly with persistdir.

(18) eap_tls: Peer requested cached session:
8a6b359de164537d987b6c6bb03d83fdaff91bda8ebbbd63f6a004b69aedc768

I'm trying to use Redis and the keys are being written to the server,
but I'm getting the following error when using *EAP-TLS*. If I use
*TTLS-PAP*, the session is cached properly.

(8) eap_tls: WARNING: (TLS) EAP Total received record fragments (216
bytes), does not equal expected data length (0 bytes)
(8) eap_tls: (TLS) EAP Done initial handshake
(8) eap_tls: (TLS) TLS - Handshake state - before SSL initialization
(8) eap_tls: (TLS) TLS - Handshake state - Server before SSL initialization
(8) eap_tls: (TLS) TLS - Handshake state - Server before SSL initialization
(8) eap_tls: (TLS) TLS - recv TLS 1.3 Handshake, ClientHello
(8) eap_tls: Peer requested cached session:
5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f
(0)   cache load {
(0)     update {
rlm_redis (redis): Reserved connection (1)
rlm_redis (redis): executing the query: "GET
0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f"
(0)       rlm_redis (redis): Can't write result, insufficient space or
unsupported result
rlm_redis (redis): Released connection (1)
(0)       EXPAND %{redis:GET %{request:TLS-Session-ID}}
(0)          -->
(0)       &Tmp-String-0 :=
(0)     } # update = noop
(0)     if (!&Tmp-String-0 || &Tmp-String-0 =~ /\|/) {
(0)     if (!&Tmp-String-0 || &Tmp-String-0 =~ /\|/)  -> FALSE
(0)     update {
(0)       EXPAND %{Tmp-String-0}
(0)          -->
(0)       &session-state:TLS-Session-Data := 0x
(0)     } # update = noop
(0)   } # cache load = noop
(8) eap_tls: WARNING: (TLS) TLS - Failed loading persisted session:
error:068000E0:asn1 encoding routines::too small

127.0.0.1:6379[1]> keys *
1) "0x0911b9f3dee5a86bdbb90dffe520f7cae867f2d06c2e801391953da73a369085"
2) "0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f"

127.0.0.1:6379[1]> keys *
1) "0x0911b9f3dee5a86bdbb90dffe520f7cae867f2d06c2e801391953da73a369085"
2) "0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f"
127.0.0.1:6379[1]> get
0x0911b9f3dee5a86bdbb90dffe520f7cae867f2d06c2e801391953da73a369085
"0x30820497020101020203030402c03004200911b9f3dee5a86bdbb90dffe520f7cae867f2d06c2e801391953da73a3690850430e44e32fb6e4b7c7e3bcc9fbc578ca41ca97110114c24d077fdc94deb97f10eb03a033d999e0da0b3d80dd0fe0d1a412ba1060204687cdec1a2050203015180a3820402308203fe308202e6a003020102020102300d06092a864886f70d01010b0500308185310b3009060355040613024652310f300d06035504080c065261646975733112301006035504070c09536f6d65776865726531153013060355040a0c0c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e6f72673118301606035504030c0f667265652e6c6f6c692e6c6f63616c301e170d3235303532373037303732315a170d3235303732363037303732315a306c310b3009060355040613024652310f300d06035504080c0652616469757331153013060355040a0c0c4578616d706c6520496e632e310f300d06035504030c066c6f6c69746f3124302206092a864886f70d0109011615757365726473647364406578616d706c652e6f726730820122300d06092a864886f70d01010105000382010f003082010a0282010100d33575358e628bacdc3f4a81b3950808552d918ab197a30328ca140928d61ceb0a4c73ca9948816c42110f572660c422bbb9a7bca8c07666a30b9bf3a885b71225d5923a4a7cf67d16aff4adf512a937651650c50dffe24165deefcfda900317370525085d490d36217e1749cc4dfd8877efd946f7cea82fb7d089b60461d38986d6e718a345c78c427bc4448097df7b040cf56e325c151e121a27fafd31aa277b96f9e2a55cc2aa56d5ada0a2122e25760a8bac1e2fea7b87538fd68454fe48bc71cd17a7fdb5cf581069b55a53b3ff8b0bc7fe1186f1d7d4e7f95bda29cb60bf61586c06412da8a3cab742c8fc8389486ba8417fafb48ee46398e2be3119690203010001a3819030818d30130603551d25040c300a06082b0601050507030230360603551d1f042f302d302ba029a0278625687474703a2f2f7777772e6578616d706c652e636f6d2f6578616d706c655f63612e63726c301d0603551d0e04160414fdd342c84af10c65a5a3b68e2a73b0fab20dcfcd301f0603551d2304183016801486bc404a6eb2660281a57519df93b8ad12757560300d06092a864886f70d01010b05000382010100a7aa375b9089fccfda8c5d7400bb617d7fcc04239f7ae7df3e0fd8c9a8f880536208ef12512d631cb7600beefde5c2521318eb76cca8b23e47cd4f21bcbdd745e6fda94a62285a3f79ebdefcbba7194fdfc562cd50ad5f7ef9a501ba6c0b2b28de4661165879e576b9e765283c37bc679fa91d33377b87202fb61ad527b7eff38f015fd38dc8d683ccc2c793abb443af69b60f280ec2012b515b0dbb78ac7b9eb9cdd6203e5a246f6ec79835bab59528ba48858ee80d3250ddf1d52d181e10897073e021211e1cbc8e2cc8f4c3b17b23f43a8801ced77e6ed9552f3da07e184150835464fe07aeb0f39357d362419b9bd6eadbe2b05c4dda267fd18bfee1df5ca4170415465220656170203078353539306563323262646330ad03020101b303020117"
127.0.0.1:6379[1]> get
0x5b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f
"0x30820497020101020203030402c03004205b188250715704e4588e1362c66ab9ac4d9ee54d3dd6879b080f3511c9a0112f04301e2fc32854abd41277e5335eac92c221d0d2dc0400a377521212554de2e8c05384d7291d70403290a7e9b4e0376f60dda1060204687cdec1a2050203015180a3820402308203fe308202e6a003020102020102300d06092a864886f70d01010b0500308185310b3009060355040613024652310f300d06035504080c065261646975733112301006035504070c09536f6d65776865726531153013060355040a0c0c4578616d706c6520496e632e3120301e06092a864886f70d010901161161646d696e406578616d706c652e6f72673118301606035504030c0f667265652e6c6f6c692e6c6f63616c301e170d3235303532373037303732315a170d3235303732363037303732315a306c310b3009060355040613024652310f300d06035504080c0652616469757331153013060355040a0c0c4578616d706c6520496e632e310f300d06035504030c066c6f6c69746f3124302206092a864886f70d0109011615757365726473647364406578616d706c652e6f726730820122300d06092a864886f70d01010105000382010f003082010a0282010100d33575358e628bacdc3f4a81b3950808552d918ab197a30328ca140928d61ceb0a4c73ca9948816c42110f572660c422bbb9a7bca8c07666a30b9bf3a885b71225d5923a4a7cf67d16aff4adf512a937651650c50dffe24165deefcfda900317370525085d490d36217e1749cc4dfd8877efd946f7cea82fb7d089b60461d38986d6e718a345c78c427bc4448097df7b040cf56e325c151e121a27fafd31aa277b96f9e2a55cc2aa56d5ada0a2122e25760a8bac1e2fea7b87538fd68454fe48bc71cd17a7fdb5cf581069b55a53b3ff8b0bc7fe1186f1d7d4e7f95bda29cb60bf61586c06412da8a3cab742c8fc8389486ba8417fafb48ee46398e2be3119690203010001a3819030818d30130603551d25040c300a06082b0601050507030230360603551d1f042f302d302ba029a0278625687474703a2f2f7777772e6578616d706c652e636f6d2f6578616d706c655f63612e63726c301d0603551d0e04160414fdd342c84af10c65a5a3b68e2a73b0fab20dcfcd301f0603551d2304183016801486bc404a6eb2660281a57519df93b8ad12757560300d06092a864886f70d01010b05000382010100a7aa375b9089fccfda8c5d7400bb617d7fcc04239f7ae7df3e0fd8c9a8f880536208ef12512d631cb7600beefde5c2521318eb76cca8b23e47cd4f21bcbdd745e6fda94a62285a3f79ebdefcbba7194fdfc562cd50ad5f7ef9a501ba6c0b2b28de4661165879e576b9e765283c37bc679fa91d33377b87202fb61ad527b7eff38f015fd38dc8d683ccc2c793abb443af69b60f280ec2012b515b0dbb78ac7b9eb9cdd6203e5a246f6ec79835bab59528ba48858ee80d3250ddf1d52d181e10897073e021211e1cbc8e2cc8f4c3b17b23f43a8801ced77e6ed9552f3da07e184150835464fe07aeb0f39357d362419b9bd6eadbe2b05c4dda267fd18bfee1df5ca4170415465220656170203078353539306563323262646330ad03020101b303020117"


(9) eap_ttls: (TLS) EAP Done initial handshake
(9) eap_ttls: (TLS) TTLS - Handshake state - before SSL initialization
(9) eap_ttls: (TLS) TTLS - Handshake state - Server before SSL initialization
(9) eap_ttls: (TLS) TTLS - Handshake state - Server before SSL initialization
(9) eap_ttls: (TLS) TTLS - recv TLS 1.3 Handshake, ClientHello
(9) eap_ttls: Peer requested cached session:
ad0985c9cf07b899bb929529c09ca161d27bd690af1be4acb1c29a5fa0545ea0
(0)   cache load {
(0)     update {
rlm_redis (redis): Reserved connection (1)
rlm_redis (redis): executing the query: "GET
0xad0985c9cf07b899bb929529c09ca161d27bd690af1be4acb1c29a5fa0545ea0"
rlm_redis (redis): Released connection (1)
(0)       EXPAND %{redis:GET %{request:TLS-Session-ID}}
(0)          --> 0x308191020101... (truncated)
(0)       &Tmp-String-0 := 0x308191020101...
(0)     } # update = noop
(0)     if (!&Tmp-String-0 || &Tmp-String-0 =~ /\|/) {
(0)     if (!&Tmp-String-0 || &Tmp-String-0 =~ /\|/)  -> FALSE
(0)     update {
(0)       EXPAND %{Tmp-String-0}
(0)          --> 0x308191020101...
(0)       &session-state:TLS-Session-Data := 0x308191020101...
(0)     } # update = noop
(0)   } # cache load = noop
(9) eap_ttls: Successfully restored session
ad0985c9cf07b899bb929529c09ca161d27bd690af1be4acb1c29a5fa0545ea0

I didn't post the full debug because it's very long — but if you need
it, I can share it. Thanks.


El dom, 20 jul 2025 a las 9:01, Alan DeKok via Freeradius-Users (<
freeradius-users at lists.freeradius.org>) escribió:

> On Jul 19, 2025, at 1:05 PM, Rodrigo Prieto <rodrigoprieto2019 at gmail.com>
> wrote:
> >
> > Hello, I'm currently working on configuring the TLS cache and noticed
> that,
> > upon reconnection, the client rewrites both files (.asn1 and .vps) in the
> > configured directory.
>
>   That's fine,  If the files aren't changed, then the TLS resumption data
> could be used multiple times.
>
>   i.e. it could also share it with other systems, and then multiple
> systems could get online.
>
>   As a result, the files change every tme.
>
> > From what I understand, it should reuse the
> > information stored in those files to avoid reestablishing the TLS
> > connection from scratch.
>
>   Changing the files doesn't mean that it re-establishes the TLS
> connection from scratch.
>
>   Alan DeKok.
>
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html
>