On Thu, Feb 25, 2010, Victor Duchovni wrote:
>
> If I am reading this correctly, unpatched OpenSSL clients will definitely
> hang if the client initiates renegotiation to a patched server? If so,
> why not send a fatal alert (especially if non-buggy clients treat it
> as fatal)? What is the point of tying up server and client resources
> with stuck connections?
>
It was reported that some SSL clients (not based on OpenSSL) periodically
attempt to renegotiate a connection. When they get sent a no renegotiation
alert they decide that it's fine that the server wont allow it and proceed
normally.
OpenSSL clients treat the warning as fatal because there is no API provision
to renegotiate and then continue if it is refused. So to be cautious we assume
that if an application wants a renegotiation it expects it to succeed and
close the connection if it doesn't.
>
> If so, does anyone have a patch that would send a fatal alert instead?
> I'd rather not risk DoS for RFC correctness if non-buggy clients treat
> the warning as fatal anyway.
>
I'd considered including a flag to do this but unfortunately we'd run out of
flags, reorganising flags would've caused further binary compatibility issues.
You can change the behaviour by looking in s3_pkt.c where we have the line:
ssl3_send_alert(s,SSL3_AL_WARNING, SSL_AD_NO_RENEGOTIATION);
change that to something like:
al = SSL_AD_HANDSHAKE_FAILURE;
goto f_err;
should do the trick.
This isn't a DoS issue as such it's just the client sending a message and
never getting the reply it expects. You'd get exactly the same behaviour by
connecting to a server and either never sending any data or deliberately not
completing the handshake.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
