FR3 and EAP-TLS session cache

[Jyri Palis]

Hi,
>  Your first message didn't say that.  Which made me wonder if the data was being put into the cache.  The parts of the debug log you posted showed that the session wasn't being found in the cache.  Which again seems to indicate that the sessions weren't being cached.
> 
>  What that means is you need to give a CORRECT and COMPLETE description of the problem.  Changing the description part way through a conversation is annoying.  It means you're not clear on what's going on, and can't describe it, which means it's almost impossible to help you.
> 

Please accept my apologies if the initial problem description was not clear enough, I did not intend to create confusion and I thought that my problem was described rather clearly. That’s the reason why I posted a message which had three attachments: configuration, initial EAP-TLS and resumed EAP-TLS Those three illustrated rather clearly my configuration and the problem I’m facing.


>> Mon Jun 15 08:29:23 2015 : Debug:   SSL: adding session 5bb22b52d5ab6b8e0e2c0be1c0054e8d5e3a11198dd85a74ff14d199374706e9 to cache
>> Mon Jun 15 08:29:23 2015 : Debug: (14)  eap_tls : (other): SSL negotiation finished successfully
>> Mon Jun 15 08:29:23 2015 : Debug: SSL Connection Established
> 
>  That's what I asked you to post (or look for).  Which addresses the original problem as stated.  Sessions go into the cache.  If they're not found in the cache, it's because the cache entry was deleted, or the client is asking to resume a session which was never cached.
> 

This is a fragment from following initial EAP-TLS

Mon Jun 15 08:59:47 2015 : Debug:   SSL: Client requested cached session 5bb22b52d5ab6b8e0e2c0be1c0054e8d5e3a11198dd85a74ff14d199374706e9
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : TLS_accept: SSLv3 read client hello A
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : >>> TLS 1.0 Handshake [length 0059], ServerHello
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : TLS_accept: SSLv3 write server hello A
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : >>> TLS 1.0 Handshake [length 0c46], Certificate
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : TLS_accept: SSLv3 write certificate A
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : >>> TLS 1.0 Handshake [length 014b], ServerKeyExchange
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : TLS_accept: SSLv3 write key exchange A
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : >>> TLS 1.0 Handshake [length 005b], CertificateRequest
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : TLS_accept: SSLv3 write certificate request A
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : TLS_accept: SSLv3 flush data
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : TLS_accept: Need to read more data: SSLv3 read client certificate A
Mon Jun 15 08:59:47 2015 : Debug: In SSL Handshake Phase
Mon Jun 15 08:59:47 2015 : Debug: In SSL Accept mode
Mon Jun 15 08:59:47 2015 : Debug: (25)  eap_tls : eaptls_process returned 13

Seems that Win7 (maybe other versions as well) will refresh EAP-TLS with interval of 30 minutes.

>> Unfortunately this fails because unlang code I have written for virtual server check-eap-tls returns FALSE when verifying TLS session related data %{TLS-Client-Cert-Subject-Alt-Name-Upn} and %{TLS-Client-Cert-Subject-Alt-Name-Dns} and let me remind that the same code woks flawlessly if TLS cache is purged and full TLS handshake is performed.
> 
>  Please try the v3.0.x branch from github.  I've pushed some minor fixes and better debug messages.
> 

I’m running version 3.0.4

So, you suggest to CO version directly from the head of git FR 3.0.x branch? My configuration and sequence of execution seems correct to you, maybe I missed something?

 

Regards,
Jyri.