Hi,
we still have an issue with session resumption where the EAP context
doesn't contain the custom variables we've stored in the
EAPTLS_CertificateVerifyHook of the initial, non-resumed, authentication.
How does EAPContextTimeout, which has been reduced from 1000 to 120
seconds in version 4.17, interact with EAPTLS_SessionResumptionLimit
which defaults to 43200 seconds (12 hours) which we have explictly
configured to this value?
If I've interpreted the code and OpenSSL docs correctly, OpenSSL would
keep the data required for a successful session resumption for
EAPTLS_SessionResumptionLimit (12 hours).
If a client sends a session id it would look up the session and find it
if < EAPTLS_SessionResumptionLimit but Radiator would have thrown away
its context because of > EAPContextTimeout and not return any reply
attributes in the accept reply.
We've increased EAPContextTimeout to the same 43200 seconds as
EAPTLS_SessionResumptionLimit which seems to have fixed the issue.
If you can confirm that our analysis is correct please add something
like this to the docs of EAPContextTimeout:
If the Radiator context timeout for the EAP session is shorter than the
OpenSSL session timeout (EAPTLS_SessionResumptionLimit) a session
resumption will succeed at the OpenSSL level but Radiator will create a
new context which doesn't include any custom data nor the initial Radius
reply attributes.
I'd also suggest to add a warning log message to Radius::Context::get if
a context can't be found and a new one is returned.
Thanks, Alex
On 2016-12-19 10:23, Hartmaier Alexander wrote:
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.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
_______________________________________________
radiator mailing list
radiator@lists.open.com.au
http://lists.open.com.au/mailman/listinfo/radiator
