Hi Gregg,
thanks for testing, see comments below.
On 24.03.2010 23:17, Gregg L. Smith wrote:
Rainer Jung wrote:
On 22.03.2010 14:52, William A. Rowe Jr. wrote:
Wondering if we are comfortable tagging and releasing 2.0.64 in the
I agree there should be a release fixing (at least) CVE-2009-3555 (ssl
reneg). My tests were positive, but more eyes are very welcome.
Rainer,
XP SP2 VC6 SDK 2003 R2
Apache/2.0.64-dev (Win32) mod_ssl/2.0.64-dev OpenSSL/0.9.8m
In reference to the CVE-2009-3555 patches and the
SSLInsecureRenegotiation patch
Following your instructions;
* Patch applies also on top of the two above partial fixes for
CVE-2009-3555 with some offset and fuzz.
cve-2009-3555_httpd_2_0_x-v2.patch
+ cve-2009-3555_httpd_2_0_x-backport-r891282.patch
+ SSLInsecureRenegotiation_httpd_2_0_x-backport-r917044.patch
= Failure
You mean functional failure, not failed to apply patch?
There are two ways, how an SSL renegotiation can be initiated:
- the client can initiate it
- the server can initiate it
All your tests - using the OpenSSL "R" command - perform a client
initiated renegotiation. The first patch disables client initiated
renegotiations completely. They are not needed for making the server
work and are one possible attack vector.
The server only needs server initiated renegotiations. For testing those
you can e.g. use some cipher X in the ssl configuration of a vhost and
require another cipher Y in some <Location> below that vhost. If you now
visit the vhost, the initial handshake should result in the cipher X.
When browing to the location, a server initiated renegotiation will
happen and lead to the other cipher Y. You can check that by logging the
cipher in the access log. You can also log the ssl session id in the
access log and verify that the ssl session does not change. For this
final check to work, you will need to disable client side session
handling. E.g. for Firefox you go to the URL "about:config" and set
"security.enable_tls_session_tickets" to "false".
HTH!
Regards,
Rainer
SSLInsecureRenegotiation On
=========================================================================
R
RENEGOTIATING
3664:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:.\ssl\s3_pkt.c:530:
I had accidentally left out the first patch when I was building and it
worked fine. Realizing I had left one out and not sure which, I did it
again with the three patches and it failed. I then tried the
combinations 1 & 3, failure, 2 & 3 success.
So;
cve-2009-3555_httpd_2_0_x-backport-r891282.patch
+ SSLInsecureRenegotiation_httpd_2_0_x-backport-r917044.patch
= Success as advertised
SSLInsecureRenegotiation Off = Renegotiation failed
SSLInsecureRenegotiation On = Renegotiation succeeded
SSLInsecureRenegotiation Off
=========================================================================
E:\AOSSL098k>openssl
OpenSSL> version
OpenSSL 0.9.8k 25 Mar 2009
OpenSSL> s_client -connect localhost:443
---
R
RENEGOTIATING
3696:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:.\ssl\s3_pkt.c:530:
OpenSSL> exit
=========================================================================
SSLInsecureRenegotiation On
=========================================================================
---
R
RENEGOTIATING
depth=0 /C=US/ST=IOWA/L=DESMOINES/O=Snake Oil Ltd/OU=Snake Oil Ltd
verify error:num=18:self signed certificate
verify return:1
depth=0 /C=US/ST=IOWA/L=DESMOINES/O=Snake Oil Ltd/OU=Snake Oil Ltd
verify return:1
GET /
<html><body><h1>It works!</h1></body></html>
closed
To make sure I had it right, I reproduced it twice again.
I do not pretend to know the consequence of leaving out the first patch.
This is just my accidental observation.
Since I know all three of the 2.2.x patches were applied to 2.2.15 I
just gave it a try against my server running 2.2.15. There is the same
problem as well. SSLInsecureRenegotiation On and it still fails to
renegotiate with 0.9.8k client. I missed this during my tests leading up
to 2.2.15.
Gregg
