545329 - NetScaler SSL VIPs can be MITM'd due to insecure TLS renegotiation (CVE-2009-3555)

Status: RESOLVED FIXED

(mozilla.org Graveyard :: Server Operations: Projects, task)

Description

[Reed Loden [:reed]]

https://www.ssllabs.com/ssldb/analyze.html?d=www.mozilla.com&s=63.245.209.10

This server is vulnerable to MITM attacks because it supports renegotiation
Renegotiation  	 Supported INSECURE

Need to check with Citrix to see if they have an updated build that fixes this vulnerability. If not, either have them start working on a fix or speed-up moving away from using NetScaler.

Comment 1

[Reed Loden [:reed]]

http://support.citrix.com/article/CTX123359

Citrix NetScaler:
Appliance firmware version 8.1, build 68.7 or later, and version 9.1, build 99.8 or later. These builds are available at the following location:
https://www.citrix.com/English/ss/downloads/results.asp?productID=21679

Comment 2

[matthew zeier [:mrz]]

nslb02> show ver
        NetScaler NS8.1: Build 68.7, Date: Nov 27 2009, 10:11:44  
 Done

Comment 4

[Zack Weinberg (:zwol)]

The URL in the first comment still says "Renegotiation   Supported INSECURE" in red on www.mozilla.com; and the same is the case for bugzilla.mozilla.org (which is how I got here in the first place, via bug 546351) -- see https://www.ssllabs.com/ssldb/analyze.html?d=bugzilla.mozilla.org&s=63.245.209.86 and https://www.ssllabs.com/ssldb/analyze.html?d=bugzilla.mozilla.org&s=63.245.209.72 .

Our own probe code in Firefox trunk agrees - just point a Minefield build at www.mozilla.com and/or bugzilla.mozilla.org, open the error console, and you'll see "<site>: potentially vulnerable to CVE-2009-3555" at the top.

Comment 5

[matthew zeier [:mrz]]

Can someone point me at a tool to manually test this?

Comment 6

[Chris Lyon [:clyon]]

(In reply to comment #5)
> Can someone point me at a tool to manually test this?

Here are a few tools.

http://blog.zoller.lu/2009/11/new-sslv3-tls-vulnerability-mitm.html

I tried SSLTLS and ran it against bugzilla, it shows vulnerable.

Comment 7

[matthew zeier [:mrz]]

> Our own probe code in Firefox trunk agrees - just point a Minefield build at
> www.mozilla.com and/or bugzilla.mozilla.org, open the error console, and you'll
> see "<site>: potentially vulnerable to CVE-2009-3555" at the top.

www.mozilla.com isn't behind the Netscaler but Bugzilla is.  The Netscaler is running the latest code from Citrix, nothing I can do to fix that or cause it to get fixed faster.

www.mozilla.com hasn't been at 63.245.209.10 for some time. https://www.ssllabs.com/ssldb/analyze.html?d=www.mozilla.com still shows it for some reason.  The other address doesn't show any issue (other than DNS).

Comment 8

[Chris Lyon [:clyon]]

(In reply to comment #7)
> www.mozilla.com isn't behind the Netscaler but Bugzilla is.  The Netscaler is
> running the latest code from Citrix, nothing I can do to fix that or cause it
> to get fixed faster.

So there is still a problem with the Netscaler since it is up to date? All we can do is see if they have a fix.  

> www.mozilla.com hasn't been at 63.245.209.10 for some time.
> https://www.ssllabs.com/ssldb/analyze.html?d=www.mozilla.com still shows it for
> some reason.  The other address doesn't show any issue (other than DNS).

As for this issue, I will send these guys an email and see what they say.

Comment 9

[matthew zeier [:mrz]]

> So there is still a problem with the Netscaler since it is up to date? All we
> can do is see if they have a fix.  

They don't - they don't have anything more current than what we're running.  My heart aches.

Comment 10

[Chris Lyon [:clyon]]

(In reply to comment #8)
> As for this issue, I will send these guys an email and see what they say.

ok, so I see why they have an issue with it. The forward record for mozilla.com is going to 63.245.209.10. shouldn't www.mozilla.com and mozilla.com be the same?

$dig @ns1.mozilla.org -t a mozilla.com

;; QUESTION SECTION:
;mozilla.com.			IN	A

;; ANSWER SECTION:
mozilla.com.		600	IN	A	63.245.209.10

As for the cert issue, since it is a wildcard and you can connect to that IP https, it is coming up with a cert error.

"You attempted to reach mozilla.com, but instead you actually reached a server identifying itself as *.mozilla.com."


Should we change the record for mozilla.com to match www.mozilla.com?

Comment 11

[matthew zeier [:mrz]]

oops - updated dns for mozilla.com.  i'm not motivated to fix the cert issue unless someone tells me it's really an issue.  Been down this before - no one really uses https://mozilla.com.

Comment 13

[Daniel Veditz [:dveditz]]

(In reply to comment #9)
> they don't have anything more current than what we're running.  My
> heart aches.

But have we configured it to disable renegotiation?

How to Configure and Use the -denySSLReneg Parameter
http://support.citrix.com/article/CTX123680

Comment 14

[Daniel Veditz [:dveditz]]

(In reply to comment #4)
> Our own probe code in Firefox trunk agrees - just point a Minefield build at
> www.mozilla.com and/or bugzilla.mozilla.org, open the error console, and you'll
> see "<site>: potentially vulnerable to CVE-2009-3555" at the top.

Zack: this is slightly misleading. If the server does not ever renegotiate then there's not actually a problem with that server, but all the client knows is that the server does not support the new renegotiation extension (RFC 5746) -- it can't tell the difference between a safe server and an unsafe server if it doesn't supports the new extension. Thus "potentially" vulnerable.

Comment 15

[Chris Lyon [:clyon]]

(In reply to comment #13)
> How to Configure and Use the -denySSLReneg Parameter

Here is the setting from nslb01:
Deny SSL Renegotiation		NO

We should change this to "ALL" 

It looks like we are set to "NO". We should be set to "ALL"


> http://support.citrix.com/article/CTX123680 <snip>

"ALL: SSL renegotiation is prevented for both the above two cases, and for server initiated renegotiation by back-end resources."

Comment 16

[Zack Weinberg (:zwol)]

That's unfortunate, it means the warning in the error console will get tons of false positives.  Oh well.

Comment 17

[Zack Weinberg (:zwol)]

I was responding to comment 14, just to be clear.

Comment 18

[matthew zeier [:mrz]]

Fix applied.

Comment 19

[Chris Lyon [:clyon]]

(In reply to comment #18)
> Fix applied.

All the tools are reporting the same thing, this has been resolved.

Thanks mrz.