reauth-problem with WPA2-tls

Alexander Clouter alex at digriz.org.uk
Fri Jun 4 20:31:33 CEST 2010


Andreas Hartmann <andihartmann at 01019freenet.de> wrote:
>> 
>> So I guess the warning means that either SSL_SESSION_set_ex_data() or
>> SSL_SESSION_get_ex_data() failed.  A useful change would be testing the
>> return value of SSL_SESSION_set_ex_data() and print a warning if it
>> fails, possibly using ERR_get_error() and ERR_error_string() or similar
>> to get the actual error.  The latter would also be useful in the
>> SSL_SESSION_get_ex_data() failure case
> 
> Debugging of SSL_SESSION_set_ex_data()
> 
> The returncode of the function is 1 (don't know, if it should be 0 - but
> it could be correct too, if it means, that one pair has been stored).
> 
> vps, which SSL_SESSION_set_ex_data() is given as argument, consists of
> one NULL element.
> 
> request->packet->vps->name gives User-Name, request->reply-vps is null
> (should be PW_USER_NAME). But there cant be any password, because there
> exists no password, because the authentication is done exclusively with
> keys.
> Could this problem be solved by a configuration entry or must it be
> hacked? Is it possible to give wpa_supplicant a dummy password?
> 
> Debugging of SSL_SESSION_get_ex_data()
> 
> At resuming, Index is 2 (eaptls_session_idx). This would be ok. Seems,
> that the returncode 1 from SSL_SESSION_set_ex_data() means, that nothing
> has been saved.
> 
> I would be happy to get some more hints :-).
> 
This all sounds horribly familiar and related to:

git log -n1 -p 2377012692e22532ed1c1e1e852d843861ce5367
https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=15
http://rt.openssl.org/Ticket/Display.html?id=2036

I prodded Alan as I noticed that openssl would occasionally claim that 
the session was a resumed one when in fact it was not.  FreeRADIUS 
interpreted this as a successful login regardless and so you could run 
into the situation where you would get an Access-Accept with no user 
credentials being sent or used at all!

The solution was, as it seems to be an OpenSSL bug the maintainers 
refuse to acknowledge, to reject the 'resumption' if no cached data is 
returned at all[1] and force the client to go the whole hog and do a 
full authentication run.

Cheers

[1] as if there is data, it's obviously from somewhere

Cheers

-- 
Alexander Clouter
.sigmonster says: Don't get to bragging.




More information about the Freeradius-Users mailing list