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

Status: RESOLVED FIXED

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

Description

[Ben Bucksch (:BenB)]

addons.mozilla.org : potentially vulnerable to CVE-2009-3555
versioncheck.addons.mozilla.org : potentially vulnerable to CVE-2009-3555
Same probably also applies to the application updater, which is bothersome.

Please update Apache or whatever SSL accelerator you use.

Compare bug 530575.

Comment 1

[Ben Bucksch (:BenB)]

> Compare bug 530575

Correction: Bug 526689

Comment 3

[Reed Loden [:reed]]

Actually, versioncheck.addons.mozilla.org is not on the NetScaler, so this isn't a dupe. In these cases, the ACE LB is involved.

Comment 4

[matthew zeier [:mrz]]

We aren't doing SSL termination on the Cisco ACE, changing summary.

Comment 5

[Jeremy Orem [:oremj]]

Zeus was fixed in 6.0r2 (http://knowledgehub.zeus.com/media/6.0/RELEASE_NOTES.60r2.txt) and we are running 6.0r3.

We have ssl!ssl3_allow_rehandshake: safe.

Comment 6

[Reed Loden [:reed]]

Visiting https://services.addons.mozilla.org/ still shows "services.addons.mozilla.org : potentially vulnerable to CVE-2009-3555" in my error console, so I don't think this is fixed.

kaie/dveditz: can you help here with confirming whether or not SAMO is actually vulnerable?

Comment 7

[Chris Lyon [:clyon]]

(In reply to comment #6)
> Visiting https://services.addons.mozilla.org/ still shows
> "services.addons.mozilla.org : potentially vulnerable to CVE-2009-3555" in my
> error console, so I don't think this is fixed.
> 
> kaie/dveditz: can you help here with confirming whether or not SAMO is actually
> vulnerable?

I am getting conflicting results from a few different tools but overall it still looks vulnerable. Based on the ZXTM, we can either be "always", "safe", or "never". It is showing safe right now. Can we change this to "never".

It is this param: 'ssl!ssl3_allow_rehandshake'

Comment 8

[Jeremy Orem [:oremj]]

From the zeus control panel: "Should SSL3 / TLS re-handshakes be supported? Enabling support for re-handshakes can expose services to Man in the Middle attacks. It is recommended that only 'safe' handshakes be permitted, or none at all. "

I can switch this to never, but I'd like to talk to support about why safe isn't actually safe. What should I ask/tell them?

Comment 9

[Chris Lyon [:clyon]]

(In reply to comment #8)
> I can switch this to never, but I'd like to talk to support about why safe
> isn't actually safe. What should I ask/tell them?

Not sure why they give you an option and what they define as "safe". It would be good to know, so let us know what they say. 

My guess would be this is why I am getting mixed results from various testing tools too.

Comment 10

[Ben Bucksch (:BenB)]

Why *would* you allow re-negotiation?
Do you actually need it? Given that there was hole in the protocol, I'd rather play the safe side and entirely disable it. IIRC, the solutions are just workarounds.

Comment 11

[Chris Lyon [:clyon]]

(In reply to comment #10)
> Why *would* you allow re-negotiation?
> Do you actually need it? Given that there was hole in the protocol, I'd rather
> play the safe side and entirely disable it. IIRC, the solutions are just
> workarounds.

I am pretty sure we are all in agreement that this needs to be turned off. I would like to find out what they mean by "safe" as this is giving false results on a few tools including ssllabs.

https://www.ssllabs.com/ssldb/analyze.html?d=services.addons.mozilla.org

Comment 12

[Kai Engert (:KaiE:)]

The message "potentially vulnerable" means, the server does not yet implement rfc 5746.

This means, the client has no way to know whether the server is safe or not.

Even if the server is safe, because the server has disable renegotiation completely, the client has no way to know, when using the old protocol.

The message will be shown by Mozilla clients for each server that still uses old software (not yet supporting rfc 5746), regardless whether the server uses a safe configuration.

Because the client can't tell, we're showing this warning, in order to push the world into upgrading their servers.

If you'd like to read more details, please visit
https://wiki.mozilla.org/Security:Renegotiation

Comment 13

[Ben Bucksch (:BenB)]

> Because the client can't tell, we're showing this warning

You'll be able to watch here live how well this will work... :)

Comment 14

[Daniel Veditz [:dveditz]]

Currently the only way to know if a server is safe is for every concerned user to call up the sysadmins and ask "have you disabled TLS renegotiation on your server?".

Or they could write up a client test tool that tries a client-initiated renegotiation with the server and see if the server rejects it. I'm pretty sure there's no way a user can make Firefox do that, though we could probably write an add-on for testing. Since ssllabs has an explicit renegotiation item in their report it looks like they have done something like that. SAMO looks good:
https://www.ssllabs.com/ssldb/analyze.html?d=services.addons.mozilla.org

The client warns that as far as it can tell SAMO is "potentially" vulnerable. In this case it is worried for nothing. HOWEVER, at some future point clients will have to start downgrading SSL connections to unpatched servers. This will likely take a long time, but there's broad agreement among browser vendors that first we'll stop showing SSL indicators on such sites, and later stop connecting to them entirely. A similar cut-off of SSLv2 hosts took a couple of years.

Comment 15

[Jeremy Orem [:oremj]]

I asked them, how do you define a safe re-handshake.

Response:

In relation to CVE-2009-3555, re-handshakes aren't safe, so they were 
disabled.  We do have a feature request open to implement RFC 5746 (Secure 
TLS re-handshakes), although there's no ETA for that at the moment.  Does 
this answer your questions?


So I assume this means safe == disabled.

Comment 16

[Chris Lyon [:clyon]]

(In reply to comment #15)
> So I assume this means safe == disabled.

It would appear that "safe" doesn't mean disable according to the testing. We should set this to "never" so that re-negotiations are turned off.

Comment 17

[Jeremy Orem [:oremj]]

Ah, I assumed comment 14 meant we were okay. I'll switch it to never tonight.

Comment 18

[Daniel Veditz [:dveditz]]

Re: comment 14 -- Kai points out in bug 549641 that no amount of client probing can 100% prove a site is safe. It can easily determine a site does unsafe renegotiations, but you can't prove that there are not situations in which it will do so.

Comment 19

[Jeremy Orem [:oremj]]

I've changed it to never.

Comment 20

[Chris Lyon [:clyon]]

(In reply to comment #19)
> I've changed it to never.

All the tools are now reporting the same result, renegotiation not supported. Thanks oremj.

Comment 21

[Ben Bucksch (:BenB)]

I just learn about Mozilla pref security.ssl.require_safe_negotiation = true. I set it. I can no longer go to bugzilla.

I think this is a good reason to implement RFC 5746. I filed bug 555952 about this, which is basically a continuation of this bug.