>From: owner-openssl-us...@openssl.org On Behalf Of Hermes Flying
>Sent: Tuesday, 27 November, 2012 07:13
>To: openssl-...@openssl.org; openssl-users@openssl.org
Answering only -users, this is not a -dev question.
>How can I test if my server is vulnerable for SSL renegotiation?
>I tried the following (using `OpenSSL 0.9.8j-fips 07 Jan 2009`:
I doubt it. 5746 was first implemented (or at least first released)
in 0.9.7m 25 Feb 2010. The attack it addresses wasn't even disclosed
until Nov 2009 (and 0.9.7l was rushed out to disable all renegotiation
pending the real fix then under discussion). Check your version again.
>`openssl s_client -connect 10.2.10.54:443`
>I see it connects, it brings the certificate chain, it shows
>the server certificate, and last:
> SSL handshake has read 2275 bytes and written 465 bytes
> ---
> New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
> Server public key is 1024 bit
> Secure Renegotiation IS supported
<snip>
>What does `Secure Renegotiation IS supported` mean?
It means RFC5746 is supported: the client proposed
either the extension or the 'signaling' suite and the
server accepted (with extension). Thus the initial
negotiation is known not to have been subject to the
Apache prefix attack. Any (subsequent) renegotiations
will also be known to be sequenced properly, but AFAIK
there is no attack against renegotiations unless the
(first) negotiation was anull enull which is just loony.
This doesn't necessarily mean 5746 is *enforced*;
some servers also accept "legacy" renegotiation
from clients that don't implement 5746.
>That SSL renegotiation is allowed?
That's a separate question. One can implement 5746 for
initial negotiation but not support later renegotiation.
AFAIK Tomcat/Coyote uses either Java-builtin SSL (JSSE) or
APR=OpenSSL and JSSE has no way to disable renegotiation,
although since the implementation of 5746 (6u22 according to
http://www.oracle.com/technetwork/java/javase/documentation/tlsreadme2-17633
0.html
) it does need an option to reenable legacy "unsafe"
renegotiation, which I hope Tomcat wouldn't do.
(Note that there are other security flaws and fixes in Java,
so for your server to be secure overall you may need > 6u22.)
OpenSSL does have an option to prohibit all renegotiation,
but I don't know if Tomcat can use that since it may *need*
(server) renegotiation depending on configuration. OpenSSL
since 0.9.8m normally prohibits legacy renegotiation, but
has an option to enable which I hope Tomcat wouldn't do.
>Then I did but did not get an exception or get the certificate again:
I assume you "did" R,return to invoke (client) renegotiation.
s_client renegotiation does not display the cert, but the verify
callbacks show a cert was received, and with -msg you can see it.
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> verify error:num=27:certificate not trusted
> verify return:1
> verify error:num=21:unable to verify the first certificate
> verify return:1
I assume you (also) sent an HTTP request to get the following response:
> HTTP/1.1 200 OK
> Server: Apache-Coyote/1.1
<snip>
>So is the server vulnerable to SSL renegotiation or not?
Probably not, but see above. Note the above considers only
protocol level -- can Mallory create a spliced request
that kindof-appears associated with Alice's auth?
That request produces a real vulnerability only if the server
uses client auth to control access and functionality -- which
is one way Apache can be configured but not the only way.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
