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

RESOLVED FIXED

Status

mozilla.org Graveyard
Server Operations
RESOLVED FIXED
8 years ago
3 years ago

People

(Reporter: BenB, Assigned: oremj)

Tracking

Details

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
> Compare bug 530575

Correction: Bug 526689
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 545329
Actually, versioncheck.addons.mozilla.org is not on the NetScaler, so this isn't a dupe. In these cases, the ACE LB is involved.
Severity: critical → normal
Status: RESOLVED → REOPENED
OS: Linux → All
Hardware: x86 → All
Resolution: DUPLICATE → ---
Summary: Update SSL on AUS, update server etc., due to TLS bug CVE-2009-3555 → ACE SSL VIPs can be MITM'd due to insecure TLS renegotiation (CVE-2009-3555)

Comment 4

8 years ago
We aren't doing SSL termination on the Cisco ACE, changing summary.
Summary: ACE SSL VIPs can be MITM'd due to insecure TLS renegotiation (CVE-2009-3555) → ZXTM SSL VIPs can be MITM'd due to insecure TLS renegotiation (CVE-2009-3555)

Updated

8 years ago
Assignee: server-ops → jeremy.orem+bugs
Status: REOPENED → NEW
(Assignee)

Comment 5

8 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED
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?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 7

8 years ago
(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'
(Assignee)

Comment 8

8 years ago
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

8 years ago
(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.
(Reporter)

Comment 10

8 years ago
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

8 years ago
(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

8 years ago
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
(Reporter)

Comment 13

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

You'll be able to watch here live how well this will work... :)
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.
(Assignee)

Comment 15

8 years ago
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

8 years ago
(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.
(Assignee)

Comment 17

8 years ago
Ah, I assumed comment 14 meant we were okay. I'll switch it to never tonight.
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.
(Assignee)

Comment 19

8 years ago
I've changed it to never.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago8 years ago
Resolution: --- → FIXED

Comment 20

8 years ago
(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.
(Reporter)

Comment 21

8 years ago
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.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.