Nginx 0.7.64 and CVE-2009-3555 TLS / SSL renegotiation

I’m running nginx/0.7.64, compiled from source.

The top of the changelog that came with the source says:

Changes with nginx 0.7.64 16 Nov
2009

*) Security: now SSL/TLS renegotiation is disabled.
   Thanks to Maxim D..

Also nginx security advisories says:

The renegotiation vulnerability in SSL protocol
Severity: major
VU#120541 CVE-2009-3555
Not vulnerable: 0.8.23+, 0.7.64+

I also checked against http://sysoev.ru/nginx/patch.cve-2009-3555.txt
and the
source I have does seem to contain that patch.

However, I’ve had a scanning vendor tell me I’m still vulnerable to the
problem:

" . . . service allows renegotiation of TLS / SSL connections."

and references CVE-2009-3555

What can I do in order to make sure this is fixed please?

Thanks,

JW

Hello!

On Fri, Feb 12, 2010 at 05:28:15PM -0600, JW wrote:

Also nginx security advisories says:

However, I’ve had a scanning vendor tell me I’m still vulnerable to the
problem:

" . . . service allows renegotiation of TLS / SSL connections."

and references CVE-2009-3555

What can I do in order to make sure this is fixed please?

Test is simple: run

openssl s_client -connect :443

and once connection is established press ‘R’ and hit enter to
trigger renegotiation.

Without the patch renegotiation will happend and connection will
stay alive. And you will be able to issue normal http request after
(something like “GET / HTTP/1.0”). With patch connection will be
dropped.

Note well:

  1. You need openssl <= 0.9.8k (unpatched one, not ‘l’!) on
    client to test it, as in 0.9.8l renegotiation is completely broken
    by default and connection will just hang.

  2. With openssl 0.9.8l on server connection will hang, too. This
    means that you aren’t vulnerable, but it’s not easy to distinguish
    this case from the case with 0.9.8l on client (which just doesn’t
    allow you to test).

  3. First of all you should patch openssl, not nginx. Once you’ll
    patch openssl on your system all programs which use it will be
    safe, not just nginx.

Maxim D.

On Fri, Feb 12, 2010 at 05:28:15PM -0600, JW wrote:

Also nginx security advisories says:

However, I’ve had a scanning vendor tell me I’m still vulnerable to the
problem:

" . . . service allows renegotiation of TLS / SSL connections."

and references CVE-2009-3555

What can I do in order to make sure this is fixed please?

Could you create nginx debug log of the scanning connections ?


Igor S.
http://sysoev.ru/en/

On Friday 12 February 2010 07:10:18 pm Maxim D. wrote:

dropped.
This is what I get:


R
RENEGOTIATING
21395:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake
failure:s3_pkt.c:530:

So does that mean that actually the server is not vulnerable?

Note well:

  1. You need openssl <= 0.9.8k (unpatched one, not ‘l’!) on
    client to test it, as in 0.9.8l renegotiation is completely broken
    by default and connection will just hang.

Got it on client.

  1. With openssl 0.9.8l on server connection will hang, too. This
    means that you aren’t vulnerable, but it’s not easy to distinguish
    this case from the case with 0.9.8l on client (which just doesn’t
    allow you to test).

Server has an older version

  1. First of all you should patch openssl, not nginx. Once you’ll
    patch openssl on your system all programs which use it will be
    safe, not just nginx.

Unfortunately our OS vendor has not yet released a patch for openssl.

JW

On Saturday 13 February 2010 01:03:16 am Igor S. wrote:

the source I have does seem to contain that patch.
What can I do in order to make sure this is fixed please?

Could you create nginx debug log of the scanning connections ?

I will see what I can do to accommodate that request.

JW

Hello!

On Sat, Feb 13, 2010 at 11:45:15PM -0600, JW wrote:

stay alive. And you will be able to issue normal http request after

So does that mean that actually the server is not vulnerable?

Yes. This means that you have patched nginx running, and it closes
connection once it detects renegotiation attempt. You aren’t
vulnerable.

Maxim D.