FR3 and EAP-TLS session cache
Hi, I have been trying to get FR (3.0.4) EAP-TLS session caching to work with ‘check-eap-tls’ virtual server, so far no luck. Initial EAP-TLS session is established correctly and Windows 7 clients get access to protected WLAN but requests following initial request fail to utilise data stored TLS session cache data client is force to proceed with full TLS handshake. Virtual server 'check-eap-tls’ which is configured to verify client certificates fails when cached TLS session calls this method, variables needed for verification are not propagated correctly. server check-eap-tls { authorize { if ("%{TLS-Client-Cert-Subject-Alt-Name-Upn}" =~ /^([a-z0-9]|[\w\.-]?)+\@example\.com$/i) { update config { Auth-Type := Accept } } elsif ("%{TLS-Client-Cert-Subject-Alt-Name-Dns}" =~ /^([a-z0-9]|[\w\-]?)+\.example\.com$/i) { update config { Auth-Type := Accept } } else { update config { Auth-Type := Reject } } } This is a fragment from log file: Sun Jun 14 14:56:11 2015 : Auth: (44) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [host/xxxxx.example.com/<via Auth-Type = EAP>] (from client wc-s1-01 port 2 cli 00-24-d7-03-2b-38) Sun Jun 14 14:56:16 2015 : Error: Couldn't open /var/log/radius/tlscache/c0373a395b8cc8bc3bd2fe453c3f235454b5216a47c1cb66e30580cd697033f1.vps for reading: No such file or directory Sun Jun 14 14:56:16 2015 : Auth: (52) Login OK: [host/xxxxx.example.com] (from client wc-s1-01 port 2 cli 00-24-d7-03-2b-38 via TLS tunnel) Sun Jun 14 14:56:16 2015 : Auth: (52) Login OK: [host/xxxxx.example.com] (from client wc-s1-01 port 2 cli 00-24-d7-03-2b-38) So is there a way to check session status in ‘authorize’ block and accept auth when cached TLS session is detected? This is written to stdout when running in debug mode (15) eap_tls : Length Included (15) eap_tls : eaptls_verify returned 11 (15) eap_tls : (other): before/accept initialization (15) eap_tls : TLS_accept: before/accept initialization (15) eap_tls : <<< TLS 1.0 Handshake [length 007c], ClientHello SSL: Client requested cached session f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967 reading pairlist file /var/log/radius/tlscache/f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967.vps Couldn't open /var/log/radius/tlscache/f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967.vps for reading: No such file or directory SSL: could not load persisted VPs for session f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967 (15) eap_tls : TLS_accept: SSLv3 read client hello A (15) eap_tls : >>> TLS 1.0 Handshake [length 0059], ServerHello (15) eap_tls : TLS_accept: SSLv3 write server hello A (15) eap_tls : >>> TLS 1.0 Handshake [length 0c46], Certificate (15) eap_tls : TLS_accept: SSLv3 write certificate A (15) eap_tls : >>> TLS 1.0 Handshake [length 014b], ServerKeyExchange (15) eap_tls : TLS_accept: SSLv3 write key exchange A (15) eap_tls : >>> TLS 1.0 Handshake [length 005b], CertificateRequest (15) eap_tls : TLS_accept: SSLv3 write certificate request A (15) eap_tls : TLS_accept: SSLv3 flush data (15) eap_tls : TLS_accept: Need to read more data: SSLv3 read client certificate A In SSL Handshake Phase In SSL Accept mode Regards, Jyri.
On Jun 14, 2015, at 8:11 AM, Jyri Palis <jyri.palis@gmail.com> wrote:
I have been trying to get FR (3.0.4) EAP-TLS session caching to work with ‘check-eap-tls’ virtual server, so far no luck. Initial EAP-TLS session is established correctly and Windows 7 clients get access to protected WLAN but requests following initial request fail to utilise data stored TLS session cache data client is force to proceed with full TLS handshake.
You can do in-memory caching. I suggest trying that first. It works in all of my tests. As a second step, enable on-disk caching.
Virtual server 'check-eap-tls’ which is configured to verify client certificates fails when cached TLS session calls this method, variables needed for verification are not propagated correctly.
What does that mean?
server check-eap-tls { authorize {
if ("%{TLS-Client-Cert-Subject-Alt-Name-Upn}" =~ /^([a-z0-9]|[\w\.-]?)+\@example\.com$/i) { update config { Auth-Type := Accept
This is in the inner tunnel, right?
This is a fragment from log file:
Why? We recommend reading the *debug* output.
Sun Jun 14 14:56:11 2015 : Auth: (44) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [host/xxxxx.example.com/<via Auth-Type = EAP>] (from client wc-s1-01 port 2 cli 00-24-d7-03-2b-38) Sun Jun 14 14:56:16 2015 : Error: Couldn't open /var/log/radius/tlscache/c0373a395b8cc8bc3bd2fe453c3f235454b5216a47c1cb66e30580cd697033f1.vps for reading: No such file or directory
Probably because the TLS data isn't being cached.
So is there a way to check session status in ‘authorize’ block and accept auth when cached TLS session is detected?
The server does that automatically. That's the whole point of the cache,
This is written to stdout when running in debug mode
And... you've only posted part of the debug log. How about looking *earlier* in the log, for the first EAP-TLS session? Does the debug log say it's caching that session? no? of course caching won't work yes? something else is going wrong, like the cached sessions are being deleted.
(15) eap_tls : Length Included (15) eap_tls : eaptls_verify returned 11 (15) eap_tls : (other): before/accept initialization (15) eap_tls : TLS_accept: before/accept initialization (15) eap_tls : <<< TLS 1.0 Handshake [length 007c], ClientHello SSL: Client requested cached session f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967 reading pairlist file /var/log/radius/tlscache/f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967.vps Couldn't open /var/log/radius/tlscache/f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967.vps for reading: No such file or directory
That would be pretty definitive. The TLS data wasn't written to the persistent disk cache. Alan DeKok.
Hi,
You can do in-memory caching. I suggest trying that first. It works in all of my tests.
As a second step, enable on-disk caching.
Does not matter if I use in-memory or persistent on-disk caching, result is always the same, first run succeeds and second one fails, cache is invalidated and full TLS handshake is performed again.
Virtual server 'check-eap-tls’ which is configured to verify client certificates fails when cached TLS session calls this method, variables needed for verification are not propagated correctly.
What does that mean?
When TLS implementation detects request to use cached session data, variables like %{TLS-Client-*} are not propagated and code in check-eap-tls virtual server fails because variables needed for client certificate validation do not contain any data.
server check-eap-tls { authorize {
if ("%{TLS-Client-Cert-Subject-Alt-Name-Upn}" =~ /^([a-z0-9]|[\w\.-]?)+\@example\.com$/i) { update config { Auth-Type := Accept
This is in the inner tunnel, right?
This is defined in eap configuration's tls section.
This is a fragment from log file:
Why? We recommend reading the *debug* output.
To demonstrate my issue more clearly I have attached three files to this message, configuration, first run and second run. Output is generated by running freeradius -Xxx
Sun Jun 14 14:56:11 2015 : Auth: (44) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [host/xxxxx.example.com/<via Auth-Type = EAP>] (from client wc-s1-01 port 2 cli 00-24-d7-03-2b-38) Sun Jun 14 14:56:16 2015 : Error: Couldn't open /var/log/radius/tlscache/c0373a395b8cc8bc3bd2fe453c3f235454b5216a47c1cb66e30580cd697033f1.vps for reading: No such file or directory
Probably because the TLS data isn't being cached.
First run ... Mon Jun 15 08:29:23 2015 : Debug: (14) eap_tls : TLS_accept: SSLv3 flush data 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 Second run … Mon Jun 15 08:59:42 2015 : Auth: (23) Login incorrect: [host/user_host.private.com/<via Auth-Type = Reject>] (from client wc-s1-01 port 2 cli 00-24-d7-03-2b-38 via TLS tunnel) Mon Jun 15 08:59:42 2015 : Debug: (23) Using Post-Auth-Type Reject Mon Jun 15 08:59:42 2015 : Debug: (23) Post-Auth-Type sub-section not found. Ignoring. Mon Jun 15 08:59:42 2015 : Debug: (23) Reply: Mon Jun 15 08:59:42 2015 : Debug: (23) } # server check-eap-tls Mon Jun 15 08:59:42 2015 : Debug: (23) eap_tls : Certificates were rejected by the virtual server Mon Jun 15 08:59:42 2015 : Debug: SSL: Removing session 5bb22b52d5ab6b8e0e2c0be1c0054e8d5e3a11198dd85a74ff14d199374706e9 from the cache Mon Jun 15 08:59:42 2015 : ERROR: (23) eap : Failed continuing EAP TLS (13) session. EAP sub-module failed Debug logs: Regards, Jyri.
Hi, Any ideas what could be wrong with my setup? Regards, Jyri On Sunday, June 14, 2015, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 14, 2015, at 8:11 AM, Jyri Palis <jyri.palis@gmail.com <javascript:;>> wrote:
I have been trying to get FR (3.0.4) EAP-TLS session caching to work with ‘check-eap-tls’ virtual server, so far no luck. Initial EAP-TLS session is established correctly and Windows 7 clients get access to protected WLAN but requests following initial request fail to utilise data stored TLS session cache data client is force to proceed with full TLS handshake.
You can do in-memory caching. I suggest trying that first. It works in all of my tests.
As a second step, enable on-disk caching.
Virtual server 'check-eap-tls’ which is configured to verify client certificates fails when cached TLS session calls this method, variables needed for verification are not propagated correctly.
What does that mean?
server check-eap-tls { authorize {
if ("%{TLS-Client-Cert-Subject-Alt-Name-Upn}" =~ /^([a-z0-9]|[\w\.-]?)+\@example\.com$/i) { update config { Auth-Type := Accept
This is in the inner tunnel, right?
This is a fragment from log file:
Why? We recommend reading the *debug* output.
Sun Jun 14 14:56:11 2015 : Auth: (44) Login incorrect (eap: Failed continuing EAP TLS (13) session. EAP sub-module failed): [host/ xxxxx.example.com/<via Auth-Type = EAP>] (from client wc-s1-01 port 2 cli 00-24-d7-03-2b-38) Sun Jun 14 14:56:16 2015 : Error: Couldn't open /var/log/radius/tlscache/c0373a395b8cc8bc3bd2fe453c3f235454b5216a47c1cb66e30580cd697033f1.vps for reading: No such file or directory
Probably because the TLS data isn't being cached.
So is there a way to check session status in ‘authorize’ block and accept auth when cached TLS session is detected?
The server does that automatically. That's the whole point of the cache,
This is written to stdout when running in debug mode
And... you've only posted part of the debug log.
How about looking *earlier* in the log, for the first EAP-TLS session? Does the debug log say it's caching that session?
no? of course caching won't work
yes? something else is going wrong, like the cached sessions are being deleted.
(15) eap_tls : Length Included (15) eap_tls : eaptls_verify returned 11 (15) eap_tls : (other): before/accept initialization (15) eap_tls : TLS_accept: before/accept initialization (15) eap_tls : <<< TLS 1.0 Handshake [length 007c], ClientHello SSL: Client requested cached session f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967 reading pairlist file /var/log/radius/tlscache/f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967.vps Couldn't open /var/log/radius/tlscache/f35d02540a8e9c4faf8620dfe25e4e82941192f8686390ec3591df41ba22f967.vps for reading: No such file or directory
That would be pretty definitive. The TLS data wasn't written to the persistent disk cache.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 15, 2015, at 2:16 PM, Jyri Palis <jyri.palis@gmail.com> wrote:
Any ideas what could be wrong with my setup?
Since you're not posting the debug log from the initial EAP-TLS session... no, I don't know what's wrong with your setup. What's with not posting the full debug log as I suggested? It's really quite simple. You ask a question, and either I answer it, or I tell you what *else* I need to answer the question. That involves *you* doing work to answer my question. If you're not going to follow instructions, you shouldn't be posting questions. Alan DeKok.
Hi, This morning i posted a replay message to your first reply. My replay had three attachments, first one contained my configuration, the second one contained entire debug log for initial successful auth and the third one contained entire debug log for client session refresh. The last one shows clearly that cached session is discarded and full tls auth cycle is performed again. If you did not receive those three files then i'll be more than happy to send them again. J.
On 15.06.2015, at 21:19, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 15, 2015, at 2:16 PM, Jyri Palis <jyri.palis@gmail.com> wrote: Any ideas what could be wrong with my setup?
Since you're not posting the debug log from the initial EAP-TLS session... no, I don't know what's wrong with your setup.
What's with not posting the full debug log as I suggested?
It's really quite simple. You ask a question, and either I answer it, or I tell you what *else* I need to answer the question. That involves *you* doing work to answer my question.
If you're not going to follow instructions, you shouldn't be posting questions.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 15, 2015, at 2:28 PM, Jyri Palis <jyri.palis@gmail.com> wrote:
This morning i posted a replay message to your first reply. My replay had three attachments, first one contained my configuration, the second one contained entire debug log for initial successful auth and the third one contained entire debug log for client session refresh. The last one shows clearly that cached session is discarded and full tls auth cycle is performed again. If you did not receive those three files then i'll be more than happy to send them again.
Your message bounced because it was too long. And don't send 3 debug messages. I only asked for one. The first one, which shows the initial authentication. And it's possible for *you* to read the debug output, too. Does it show the server writing the session to the cache? No? Then that's why the caching doesn't work. Alan DeKok.
Hi, I have attached initial TLS session debug log to this message (114KB) and yes I read debug log and searched the web for days before I turned to this list for additional help. As I said before, the first TLS session for supplicant proceeds exactly the way I should, debug log states that TLS session is successfully created and that same session is saved in cache. 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 The problem I’m facing is related directly to reusing data already available in cache and avoiding full TLS handshake. 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. Regards, Jyri. On 15 Jun 2015, at 21:51, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 15, 2015, at 2:28 PM, Jyri Palis <jyri.palis@gmail.com> wrote:
This morning i posted a replay message to your first reply. My replay had three attachments, first one contained my configuration, the second one contained entire debug log for initial successful auth and the third one contained entire debug log for client session refresh. The last one shows clearly that cached session is discarded and full tls auth cycle is performed again. If you did not receive those three files then i'll be more than happy to send them again.
Your message bounced because it was too long. And don't send 3 debug messages. I only asked for one. The first one, which shows the initial authentication.
And it's possible for *you* to read the debug output, too. Does it show the server writing the session to the cache? No? Then that's why the caching doesn't work.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
You can only use information which is present at the time of the access request. If you resume an SSL session there is no client certificate presented and thus there is no TLS-Client-Cert-Subject-Alt-Name-Upn variable set. You can see all attributes available in the debug log and as you can see there, there are no TLS attributes when the session resumes. If you need the client certificate name for a session you have to save it in Cached-Session-Policy and extract it from there when the session SSL resumes. I don't think there is any other way to obtain SSL information from the original access request. I'm no expert on this but that's how I understand it... Cheers, Gerald Thus, if you need the client certificate name On 16/06/15 07:45, Jyri Palis wrote:
Hi,
I have attached initial TLS session debug log to this message (114KB) and yes I read debug log and searched the web for days before I turned to this list for additional help. As I said before, the first TLS session for supplicant proceeds exactly the way I should, debug log states that TLS session is successfully created and that same session is saved in cache.
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
The problem I’m facing is related directly to reusing data already available in cache and avoiding full TLS handshake. 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.
Regards, Jyri. On 15 Jun 2015, at 21:51, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 15, 2015, at 2:28 PM, Jyri Palis <jyri.palis@gmail.com> wrote:
This morning i posted a replay message to your first reply. My replay had three attachments, first one contained my configuration, the second one contained entire debug log for initial successful auth and the third one contained entire debug log for client session refresh. The last one shows clearly that cached session is discarded and full tls auth cycle is performed again. If you did not receive those three files then i'll be more than happy to send them again.
Your message bounced because it was too long. And don't send 3 debug messages. I only asked for one. The first one, which shows the initial authentication.
And it's possible for *you* to read the debug output, too. Does it show the server writing the session to the cache? No? Then that's why the caching doesn't work.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi, Hmm, are you sure? When I enabled persistent caching then all needed information was stored in vps file (session id plus all certificate related data like variables I mentioned before) so I assumed that when FR detects that client requested cached TLS session, this data can still be used for additional decision making and identity verification otherwise I do not see any reason to for caching unless check-eap-tls contains means to detect cached session (also means that FR trusts the contents of TLS cache) , which can be then used for over ruling unlang code and still return TRUE update config { Auth-Type := Accept } With this basic configuration, caching works but this renders the whole concept of additional checking of TLS session with unlang useless for this particular setup. Maybe I have missed something, can’t rule that out :) Regards, Jyri On 16 Jun 2015, at 09:43, Gerald Vogt <vogt@spamcop.net> wrote:
You can only use information which is present at the time of the access request. If you resume an SSL session there is no client certificate presented and thus there is no TLS-Client-Cert-Subject-Alt-Name-Upn variable set. You can see all attributes available in the debug log and as you can see there, there are no TLS attributes when the session resumes.
If you need the client certificate name for a session you have to save it in Cached-Session-Policy and extract it from there when the session SSL resumes. I don't think there is any other way to obtain SSL information from the original access request.
I'm no expert on this but that's how I understand it...
Cheers,
Gerald
Thus, if you need the client certificate name
On 16/06/15 07:45, Jyri Palis wrote:
Hi,
I have attached initial TLS session debug log to this message (114KB) and yes I read debug log and searched the web for days before I turned to this list for additional help. As I said before, the first TLS session for supplicant proceeds exactly the way I should, debug log states that TLS session is successfully created and that same session is saved in cache.
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
The problem I’m facing is related directly to reusing data already available in cache and avoiding full TLS handshake. 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.
Regards, Jyri. On 15 Jun 2015, at 21:51, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 15, 2015, at 2:28 PM, Jyri Palis <jyri.palis@gmail.com> wrote:
This morning i posted a replay message to your first reply. My replay had three attachments, first one contained my configuration, the second one contained entire debug log for initial successful auth and the third one contained entire debug log for client session refresh. The last one shows clearly that cached session is discarded and full tls auth cycle is performed again. If you did not receive those three files then i'll be more than happy to send them again.
Your message bounced because it was too long. And don't send 3 debug messages. I only asked for one. The first one, which shows the initial authentication.
And it's possible for *you* to read the debug output, too. Does it show the server writing the session to the cache? No? Then that's why the caching doesn't work.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 16, 2015, at 1:45 AM, Jyri Palis <jyri.palis@gmail.com> wrote:
I have attached initial TLS session debug log to this message (114KB) and yes I read debug log and searched the web for days before I turned to this list for additional help. As I said before, the first TLS session for supplicant proceeds exactly the way I should, debug log states that TLS session is successfully created and that same session is saved in cache.
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.
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.
The problem I’m facing is related directly to reusing data already available in cache and avoiding full TLS handshake.
Which is NOT what you said in your original message. Please keep a *consistent* description of the problem.
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. Alan DeKok.
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.
On Jun 17, 2015, at 1:13 AM, Jyri Palis <jyri.palis@gmail.com> wrote:
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.
It was clear. The problem is that the explanation changed. When I help people, I assume that the description of the problem is correct. So that I'm giving *useful* help. When it turns out that the description was wrong, it means I wasted my time helping you. Which is frustrating, and doesn't help anyone.
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.
I'll not I didn't ask for 3 debug logs. Being able to follow instructions is a good skill. Being able to correctly describe the problems you're seeing is also a good skill.
So, you suggest to CO version directly from the head of git FR 3.0.x branch?
That's what my message said.
My configuration and sequence of execution seems correct to you, maybe I missed something?
If you had missed something, I would have said it. What you missed is that my message said I pushed some minor fixes and better debug messages. i.e. messages which you should post to the list, and messages which will help me track down the problem. If you want your problem solved, then follow instructions. It's that simple. Alan DeKok.
Hi, Compiled 3.0.x (3.0.9) from git, the result is still the same, Win7 supplicant EAP-TLS caching still triggers resumed session check-eap-tls code failure because %{TLS-*} variables are not propagated from cache. Inital session stores data in cache: Thu Jun 18 08:14:58 2015 : Debug: (6) eap_tls: Serialising session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a, and storing in cache Thu Jun 18 08:14:58 2015 : Debug: (7) eap_tls: Saving session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a vps 0x283f220 in the cache I have attached debug log of failed Win7 session resumption to this message. Regards, Jyri On 17 Jun 2015, at 16:06, Alan DeKok <aland@deployingradius.com> wrote:
If you had missed something, I would have said it.
What you missed is that my message said I pushed some minor fixes and better debug messages. i.e. messages which you should post to the list, and messages which will help me track down the problem. If you want your problem solved, then follow instructions. It's that simple.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 18, 2015, at 2:22 AM, Jyri Palis <jyri.palis@gmail.com> wrote:
Compiled 3.0.x (3.0.9) from git, the result is still the same, Win7 supplicant EAP-TLS caching still triggers resumed session check-eap-tls code failure because %{TLS-*} variables are not propagated from cache.
Inital session stores data in cache:
Unfortunately, no. It's not.
Thu Jun 18 08:14:58 2015 : Debug: (6) eap_tls: Serialising session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a, and storing in cache Thu Jun 18 08:14:58 2015 : Debug: (7) eap_tls: Saving session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a vps 0x283f220 in the cache
If it *actually* stored the data, you would also see a message like this: Wrote session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a to 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a.asn1 (65544bytes)" I've pushed a fix to the debug messages which makes it clearer when the session is actually cached, and when it isn't. So far as I can tell, you're not setting "persist_dir". That's why it's not doing any caching. Alan DeKok.
Hi, But I had an impression that in-memory and persistent cache behave exactly the same way except persistent cache can survive daemon restarts. So what you are saying is that EAP-TLS session resumption works only when persistent disk caching is enabled? Regards, Jyri. On 18 Jun 2015, at 14:20, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 18, 2015, at 2:22 AM, Jyri Palis <jyri.palis@gmail.com> wrote:
Compiled 3.0.x (3.0.9) from git, the result is still the same, Win7 supplicant EAP-TLS caching still triggers resumed session check-eap-tls code failure because %{TLS-*} variables are not propagated from cache.
Inital session stores data in cache:
Unfortunately, no. It's not.
Thu Jun 18 08:14:58 2015 : Debug: (6) eap_tls: Serialising session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a, and storing in cache Thu Jun 18 08:14:58 2015 : Debug: (7) eap_tls: Saving session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a vps 0x283f220 in the cache
If it *actually* stored the data, you would also see a message like this:
Wrote session 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a to 1152bd8cb3b437c001f6f035cd3027f3388b9f1aa1547ab53247fdbceb4df40a.asn1 (65544bytes)"
I've pushed a fix to the debug messages which makes it clearer when the session is actually cached, and when it isn't.
So far as I can tell, you're not setting "persist_dir". That's why it's not doing any caching.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 18, 2015, at 7:25 AM, Jüri Palis <jyri.palis@gmail.com> wrote:
But I had an impression that in-memory and persistent cache behave exactly the same way except persistent cache can survive daemon restarts. So what you are saying is that EAP-TLS session resumption works only when persistent disk caching is enabled?
No. My tests show that if you enable the "cache" sub-section of the EAP module, it does in-memory session caching. You MUST set attributes to cache. See raddb/mods-available/eap, and the "cache" sub-section. The TLS-* attributes are available ONLY when a client certificate is used, as with EAP-TLS. It works in all of my tests. Alan DeKok.
Hi, This my eap configuration. In-memory cache is enabled, persistent cache is not as there is no path defined (persist_dir) for saving session data. Thu Jun 18 07:30:20 2015 : Debug: # Linked to sub-module rlm_eap_tls Thu Jun 18 07:30:20 2015 : Debug: tls { Thu Jun 18 07:30:20 2015 : Debug: tls = "tls-common" Thu Jun 18 07:30:20 2015 : Debug: virtual_server = "check-eap-tls" Thu Jun 18 07:30:20 2015 : Debug: } Thu Jun 18 07:30:20 2015 : Debug: tls-config tls-common { Thu Jun 18 07:30:20 2015 : Debug: rsa_key_exchange = no Thu Jun 18 07:30:20 2015 : Debug: dh_key_exchange = yes Thu Jun 18 07:30:20 2015 : Debug: rsa_key_length = 512 Thu Jun 18 07:30:20 2015 : Debug: dh_key_length = 512 Thu Jun 18 07:30:20 2015 : Debug: verify_depth = 0 Thu Jun 18 07:30:20 2015 : Debug: pem_file_type = yes Thu Jun 18 07:30:20 2015 : Debug: private_key_file = "/etc/raddb/certs/radius.key" Thu Jun 18 07:30:20 2015 : Debug: certificate_file = "/etc/raddb/certs/radius.crt" Thu Jun 18 07:30:20 2015 : Debug: ca_file = "/etc/raddb/certs/root_ca.crt" Thu Jun 18 07:30:20 2015 : Debug: private_key_password = “xxxxxx" Thu Jun 18 07:30:20 2015 : Debug: dh_file = "/etc/raddb/certs/dh" Thu Jun 18 07:30:20 2015 : Debug: fragment_size = 1024 Thu Jun 18 07:30:20 2015 : Debug: include_length = yes Thu Jun 18 07:30:20 2015 : Debug: check_crl = no Thu Jun 18 07:30:20 2015 : Debug: cipher_list = "ALL:!MEDIUM:!LOW" Thu Jun 18 07:30:20 2015 : Debug: check_cert_issuer = “/DC=com/DC=example/CN=RootCA” Thu Jun 18 07:30:20 2015 : Debug: ecdh_curve = "prime256v1" Thu Jun 18 07:30:20 2015 : Debug: cache { Thu Jun 18 07:30:20 2015 : Debug: enable = yes Thu Jun 18 07:30:20 2015 : Debug: lifetime = 24 Thu Jun 18 07:30:20 2015 : Debug: max_entries = 255 Thu Jun 18 07:30:20 2015 : Debug: } Thu Jun 18 07:30:20 2015 : Debug: verify { Thu Jun 18 07:30:20 2015 : Debug: } Thu Jun 18 07:30:20 2015 : Debug: ocsp { Thu Jun 18 07:30:20 2015 : Debug: enable = no Thu Jun 18 07:30:20 2015 : Debug: override_cert_url = yes Thu Jun 18 07:30:20 2015 : Debug: url = "http://127.0.0.1/ocsp/" Thu Jun 18 07:30:20 2015 : Debug: use_nonce = yes Thu Jun 18 07:30:20 2015 : Debug: timeout = 0 Thu Jun 18 07:30:20 2015 : Debug: softfail = no Thu Jun 18 07:30:20 2015 : Debug: } Thu Jun 18 07:30:20 2015 : Debug: } It’s done more or less the way comments in original eap configuration file instruct.
But I had an impression that in-memory and persistent cache behave exactly the same way except persistent cache can survive daemon restarts. So what you are saying is that EAP-TLS session resumption works only when persistent disk caching is enabled?
No. My tests show that if you enable the "cache" sub-section of the EAP module, it does in-memory session caching.
You MUST set attributes to cache. See raddb/mods-available/eap, and the “cache" sub-section.
What does this mean? Do I have to explicitly define a list of attributes including TLS-* which must be stored in cache?
The TLS-* attributes are available ONLY when a client certificate is used, as with EAP-TLS.
This is exactly the case here, clients authenticate with certificates, that’s the whole point of EAP-TLS
It works in all of my tests.
Did you test Win7 supplicant with EAP-TLS? Did you test configuration with ‘check-eap-tls’? Regards, Jyri.
On Jun 18, 2015, at 8:49 AM, Jüri Palis <jyri.palis@gmail.com> wrote:
This my eap configuration. In-memory cache is enabled, persistent cache is not as there is no path defined (persist_dir) for saving session data.
OK. After wandering around in the code for a while, I have a fix. The code was restoring the cached attributes before EAP-TLS ran the inner-tunnel server. I changed it so that the cached attributes were restored before EAP-TLS runs the inner-tunnel server. The v3.0.x branch should now work. Alan DeKok.
Hi, Almost there :) but now the code which handles persistent cache writes incorrectly formatted vps file to disk: Fri Jun 19 09:02:20 2015 : Debug: reading pairlist file /var/log/radius/tlscache/baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8.vps Fri Jun 19 09:02:20 2015 : Error: /var/log/radius/tlscache/baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8.vps[16]: Parse error (reply) for entry baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8: Expected end of line or comma Fri Jun 19 09:02:20 2015 : WARNING: (65) eap_tls: Failed loading persisted VPs for session baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8 After inspecting VP cache file, indeed there is a formatting error at line 16 …. TLS-Client-Cert-X509v3-Authority-Key-Identifier += 'keyid:71:FC:8C:7D:7C:8E:3B:F7:F1:99:98:65:C9:E2:E4:21:5C:B9:EE:49 ‘ ... The value of TLS-Client-Cert-X509v3-Authority-Key-Identifier is missing terminating apostrophe. Regards, Jyri. On 19 Jun 2015, at 00:05, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 18, 2015, at 8:49 AM, Jüri Palis <jyri.palis@gmail.com> wrote:
This my eap configuration. In-memory cache is enabled, persistent cache is not as there is no path defined (persist_dir) for saving session data.
OK. After wandering around in the code for a while, I have a fix. The code was restoring the cached attributes before EAP-TLS ran the inner-tunnel server. I changed it so that the cached attributes were restored before EAP-TLS runs the inner-tunnel server.
The v3.0.x branch should now work.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 19, 2015, at 2:19 AM, Jyri Palis <jyri.palis@gmail.com> wrote:
Almost there :) but now the code which handles persistent cache writes incorrectly formatted vps file to disk:
Can you send the complete file, instead of just a piece? It works in my tests. Please be sure that you've deleted all old files from the system.
Fri Jun 19 09:02:20 2015 : Debug: reading pairlist file /var/log/radius/tlscache/baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8.vps Fri Jun 19 09:02:20 2015 : Error: /var/log/radius/tlscache/baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8.vps[16]: Parse error (reply) for entry baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8: Expected end of line or comma Fri Jun 19 09:02:20 2015 : WARNING: (65) eap_tls: Failed loading persisted VPs for session baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8
After inspecting VP cache file, indeed there is a formatting error at line 16 …. TLS-Client-Cert-X509v3-Authority-Key-Identifier += 'keyid:71:FC:8C:7D:7C:8E:3B:F7:F1:99:98:65:C9:E2:E4:21:5C:B9:EE:49 ‘ ...
The value of TLS-Client-Cert-X509v3-Authority-Key-Identifier is missing terminating apostrophe.
It's on the next line.... maybe the Key-Identifier has an embedded carriage return? That's why I ask for the whole file... that lets me see *exactly* what's going on, instead of getting just a sample which is taken out of context. Alan DeKok.
Hi, Here is the invalid cache file PS. Certificates involved with EAP-TLS in my environment are AD auto enrolled (user or host) certificates. Regards, Jyri. On 19 Jun 2015, at 17:05, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 19, 2015, at 2:19 AM, Jyri Palis <jyri.palis@gmail.com> wrote:
Almost there :) but now the code which handles persistent cache writes incorrectly formatted vps file to disk:
Can you send the complete file, instead of just a piece?
It works in my tests. Please be sure that you've deleted all old files from the system.
Fri Jun 19 09:02:20 2015 : Debug: reading pairlist file /var/log/radius/tlscache/baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8.vps Fri Jun 19 09:02:20 2015 : Error: /var/log/radius/tlscache/baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8.vps[16]: Parse error (reply) for entry baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8: Expected end of line or comma Fri Jun 19 09:02:20 2015 : WARNING: (65) eap_tls: Failed loading persisted VPs for session baa4c42c8274dcb7d560072c5fe9040003f1c03e2d4d744114f55c096dfea3a8
After inspecting VP cache file, indeed there is a formatting error at line 16 …. TLS-Client-Cert-X509v3-Authority-Key-Identifier += 'keyid:71:FC:8C:7D:7C:8E:3B:F7:F1:99:98:65:C9:E2:E4:21:5C:B9:EE:49 ‘ ...
The value of TLS-Client-Cert-X509v3-Authority-Key-Identifier is missing terminating apostrophe.
It's on the next line.... maybe the Key-Identifier has an embedded carriage return?
That's why I ask for the whole file... that lets me see *exactly* what's going on, instead of getting just a sample which is taken out of context.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 19, 2015, at 10:30 AM, Jüri Palis <jyri.palis@gmail.com> wrote:
Here is the invalid cache file <invalid_cache.vps>
PS. Certificates involved with EAP-TLS in my environment are AD auto enrolled (user or host) certificates.
With embedded carriage returns in them. That's stupid, but allowed by the spec. I've pushed a fix. Alan DeKok.
Hi, I can confirm that after applying last PVS cache file formatting fix, TLS-EAP cache module works now correctly with win7 supplicants. Regards, Jyri. On 19 Jun 2015, at 21:02, Alan DeKok <aland@deployingradius.com> wrote:
On Jun 19, 2015, at 10:30 AM, Jüri Palis <jyri.palis@gmail.com> wrote:
Here is the invalid cache file <invalid_cache.vps>
PS. Certificates involved with EAP-TLS in my environment are AD auto enrolled (user or host) certificates.
With embedded carriage returns in them. That's stupid, but allowed by the spec.
I've pushed a fix.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
participants (4)
-
Alan DeKok -
Gerald Vogt -
Jyri Palis -
Jüri Palis