[RADIATOR] random EAP authentication errors since 4.17

[Hartmaier Alexander]

On 2016-12-16 12:40, Heikki Vatiainen wrote:
> On 16.12.2016 11.46, Hartmaier Alexander wrote:
>
>> Sadly the sh** didn't stop there, OpenSSL segfaults when
>> Net::SSLeay::session_reused gets passed an undefined value:
>
> For Net::SSLeay this is just a pass through call to OpenSSL's
> respective function. I think the caller is responsible for not handing
> undef/NULL as the argument.
>
> For this reason I'd say this is not a candiate for a ticket against
> Net::SSLeay and is not something that neither Net::SSLeay or OpenSSL
> needs to handle.
I agree with your view regarding Net::SSLeay but not on OpenSSL,
function args should always be validated.
>
>> Is Mike (author of Net::SSLeay) still working for you? I haven't opened
>> a RT for the module as I'm not sure if this should be handled at the
>> Perl XS layer or in OpenSSL.
>
> Mike is still maintainer for Net::SSLeay, but he is not with us
> anymore. About the ticket, as I mentioned above, I think we need to do
> the null check inside Radiator hook.
>
>> As a workaround I'll check for exists $p->{EAPContext} && exists
>> $p->{EAPContext}->{ssl} before calling the function. This was enough for
>> MAC bypass auths (non-EAP) but expired certs crashed Radiator again
>> today.
>
> I'd add && $p->{EAPContext}->{ssl} to the checks too. What likely
> happens now is that the hash key 'ssl' exists but the value for the
> key is undef. I'd say this is caused by the code that runs when the
> expiration was noticed.
Already done that last week ;) Seems to be stable so far.
>> Would you advise to use Radius::TLS::contextSessionCheckReuse instead of
>> Net::SSLeay::session_reused directly?
>
> I think what could be done in this function is to set something like
> $context->{eap_tls_session_resumed} to the value returned by
> Net::SSLeay::session_reused or implement the resume counter which I
> mentioned earlier. I would not call this function from a hook since
> its purpose is to check if the session was resumed or not and do
> what's appropriate based on resumption and configured resumption
> settings.
We'd prefer to have a special variable we can use for logging instead of
having to do the determination ourselves.
>
>> Please advise a safe way of determining and logging EAP session
>> resumption, we seem to stumble from one pitfall to another ourselves.
>
> I'd say the above extra check allow session_reused() to work for now
> until we add the extras/helpers mentioned above and the earlier messages.
Ok, thanks!
>
> Thanks for your patience,
> Heikki
>



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*