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.
Actually, versioncheck.addons.mozilla.org is not on the NetScaler, so this isn't a dupe. In these cases, the ACE LB is involved.
We aren't doing SSL termination on the Cisco ACE, changing summary.
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.
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?
(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'
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?
(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.
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.
(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
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
> 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.
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.
(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.
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.
I've changed it to never.
(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.
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.