Kostas Kalevras <[EMAIL PROTECTED]> wrote:
> For the core dump now:
...
> (gdb) print s->s2
> $2 = (struct ssl2_state_st *) 0x8117400
> (gdb) print s->s3
> $3 = (struct ssl3_state_st *) 0x0
>
> In other words the s->s3 structure is NULL.
See RFC 2716, top of page 3. TLS version 1 is required. See
ssl/ssl.h, SSLv3 is pretty much TLS version 1.
So the TLS session SHOULD have been rejected, as soon as the client
tried to use SSLv2. This may be a failure in the EAP-TLS code.
Hmm... See: src/modules/rlm_eap/types/rlm_eap_tls/rlm_eap_tls.c,
line 185:
/*
* Set ctx_options
*/
ctx_options |= SSL_OP_NO_SSLv2;
ctx_options |= SSL_OP_NO_SSLv3;
So SSLv2 and SSLv3 should NOT be used. Ever.
> In any case that one is causing the core dumps. If there are no
> objections i can add a few checks in eaptls_gen_mppe_keys() and
> eapttls_gen_challenge() for s->s3 being NULL
I'd say add a few checks to the TLS module, eaptls_process(), so
that at it returns FAILED if s->s3 == NULL. That will prevent the
core dump, but it will also prevent your client from working.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
