Force update of TLS cache

Jonathan Gazeley Jonathan.Gazeley at bristol.ac.uk
Mon Feb 29 17:26:39 CET 2016


On 29/02/16 16:02, Alan DeKok wrote:
> On Feb 29, 2016, at 10:59 AM, Jonathan Gazeley <Jonathan.Gazeley at bristol.ac.uk> wrote:
>> I added code as you suggested. It seems to be unable to copy the TLS-Session-Id attribute. The following was executed in inner post-auth section, but also choked with the same result when being executed in the inner authorize section.
>>
>> (8)        update request {
>> (8)          TLS-Session-Id skipped: No values available
>> (8)        } # update request (noop)
>> (8)        cache_tls_session (fail)
>>
>> Any suggestions?
>
>    The TLS-Session-Id is available once the TLS session is set up.  You should be able to update the "default" virtual server to see when the attribute is available.  Or, the debug output should tell you when it's created.
>

The debug log shows that TLS-Session-Id is created in packet 4, in the 
outer authorize section.

(4)    Auth-Type eduroameap {
(4)      eduroameap - Peer sent packet with EAP method PEAP (25)
(4)      eduroameap - Calling submodule eap_peap to process data
(4)      eap_peap - Continuing EAP-TLS
(4)      eap_peap - Peer indicated complete TLS record size will be 134 
bytes
(4)      eap_peap - Got complete TLS record, with length field (134 bytes)
(4)      eap_peap - [eap-tls verify] = ok
(4)      eap_peap - <<< recv handshake [length 70], client_key_exchange
(4)      eap_peap - TLS Accept: SSLv3 read client key exchange A
(4)      eap_peap - <<< recv change_cipher_spec [length 1]
(4)      eap_peap - <<< recv handshake [length 16], finished
(4)      eap_peap - TLS Accept: SSLv3 read finished A
(4)      eap_peap - >>> send change_cipher_spec [length 1]
(4)      eap_peap - TLS Accept: SSLv3 write change cipher spec A
(4)      eap_peap - >>> send handshake [length 16], finished
(4)      eap_peap - TLS Accept: SSLv3 write finished A
(4)      eap_peap - TLS Accept: SSLv3 flush data
(4)      eap_peap -   &TLS-Session-Id = 
0xd63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd
(4)      eap_peap -   &config:TLS-Session-Cache-Action = Write
(4)      eap_peap -   &session-state:TLS-Session-Data = 
0x308181020101020203010402c0140420d63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd04308c351e2af2cf67325937428ddc4e980826c350e2c63e6bb223db447765639cff4f5136f51eef36248c64f295aafdff71a106020456d46a63a2040202012ca412041046
(4)      Running Autz-Type Session-Cache-Write from file 
/etc/raddb/sites-enabled/tls-cache
(4)        Autz-Type Session-Cache-Write {
(4)          update control {
(4)            &control:Cache-TTL := 0
(4)          } # update control (noop)
(4)          cache_tls_session - No cache entry found for 
"\326=\332';7\310\3516ֻ\246e\273\317L\261A7\t\325A9\020\377\340q\025\002\033i\315"
(4)          cache_tls_session - Creating new cache entry
(4)          cache_tls_session -   &session-state:TLS-Session-Data := 
&session-state:TLS-Session-Data -> 
0x308181020101020203010402c0140420d63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd04308c351e2af2cf67325937428ddc4e980826c350e2c63e6bb223db447765639cff4f5136f51eef36248c64f295aafdff71a106020456d46a63a2040202012ca412041046522065617020307831393664383930
(4)          cache_tls_session -   &session-state:TLS-Session-Id := 
&TLS-Session-Id -> 
0xd63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd
(4)          cache_tls_session -   &session-state: += 
&session-state:TLS-Session-Data -> 
0x308181020101020203010402c0140420d63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd04308c351e2af2cf67325937428ddc4e980826c350e2c63e6bb223db447765639cff4f5136f51eef36248c64f295aafdff71a106020456d46a63a2040202012ca412041046522065617020307831393664383930
(4)          cache_tls_session - Committed entry, TTL 3600 seconds
(4)          cache_tls_session - Removing &control:Cache-TTL
(4)          cache_tls_session (ok)
(4)        } # Autz-Type Session-Cache-Write (ok)

This appears to be working so far.

Referencing it in inner authorize or inner post-auth fails. I can't see 
why it would be inaccessible. We're referencing it like this, as you 
suggested:

update request {
	TLS-Session-Id := &outer.request:TLS-Session-Id
}

And it does this:

(6)        update request {
(6)          TLS-Session-Id skipped: No values available
(6)        } # update request (noop)

I don't understand why the attribute is not available later on in the 
same session.

Thanks,
Jonathan


More information about the Freeradius-Users mailing list