The documentation about renegotiation between an unpatched client and
a patched server reads:
Unpatched client and patched OpenSSL server
-------------------------------------------
The initial connection suceeds but client renegotiation is denied
by the server with a B<no_renegotiation> warning alert if TLS v1.0
is used or a fatal B<handshake_failure> alert in SSL v3.0.
If the patched OpenSSL server attempts to renegotiate a fatal
B<handshake_failure> alert is sent. This is because the server code
may be unaware of the unpatched nature of the client.
...
NB: a bug in OpenSSL clients earlier than 0.9.8m (all of which
are unpatched) will result in the connection hanging if it receives
a B<no_renegotiation> alert. OpenSSL versions 0.9.8m and later will
regard a B<no_renegotiation> alert as fatal and respond with a fatal
B<handshake_failure> alert. This is because the OpenSSL API currently
has no provision to indicate to an application that a renegotiation
attempt was refused.
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?
Does the documentation accurately reflect the behaviour of 0.9.8m
patched servers and earlier unpatched clients?
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.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
