Closed Bug 555952 (moz-rfc5746) Opened 15 years ago Closed 12 years ago

Implement RFC 5746 for mozilla.org SSL sites to avoid Mozilla warning about CVE-2009-3555

Categories

(Security Assurance :: General, task)

Product:
Security Assurance
Component:
General
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: BenB, Assigned: michalpurzynski1)

References

Details

(Whiteboard: [infrasec:tls])

Setup: Use current Firefox (trunk or, probably, 3.6.2) Reproduction: 1. Watch error console when update check happens 2. Go to addons.mozilla.org 3. Set go to <about:config> and change security.ssl.require_safe_negotiation to true 4. Go to bugzilla.mozilla.org, addons.mozilla.org, versioncheck.mozilla.org Actual result: 1. "versioncheck.mozilla.org : potentially vulnerable to CVE-2009-3555" 2. "addons.mozilla.org : potentially vulnerable to CVE-2009-3555" 4. Access blocked, can't go to bugzilla, addons, updater Fix: Support RFC 5746 in SSL accelerator. Compare: Bug 526689 - (CVE-2009-3555) SSL3 & TLS Renegotiation Vulnerability Bug 549109 - Disable TLS renegotiation in ZXTM SSL VIPs Bug 549641 - Slightly alter Mozilla message in error console
Note: If people set security.ssl.require_safe_negotiation, this may pose a veritable security danger to them, because versioncheck.mozilla.org probably won't work anymore, i.e. updates break. (Compare bug 535649)
What software is being used in the SSL accelerator? The following toolkits supports RFC 5746: - NSS 3.12.6 - OpenSSL 0.9.8m - OpenSSL 1.0.0 (announced today)
ZXTM SSL VIPs, an SSL accelerator, as the summary says. (mozilla.org sites have a tremendous amount of traffic, esp. versioncheck)
Summary: Implement RFC 5647 for mozilla.org SSL sites (ZXTM SSL VIPs), to avoid Mozilla warning about CVE-2009-3555 → Implement RFC 5746 for mozilla.org SSL sites (ZXTM SSL VIPs), to avoid Mozilla warning about CVE-2009-3555
bugzilla should move to Zeus later this week. The other sites are already on Zeus and I thought we had already dealt with this: We've already set ssl!ssl3_allow_rehandshake to "never". This is describe as: 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. You're saying this is still an issue?
(In reply to comment #4) > bugzilla should move to Zeus later this week. The other sites are already on > Zeus and I thought we had already dealt with this: > > We've already set ssl!ssl3_allow_rehandshake to "never". This is describe as: > > 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. > > > You're saying this is still an issue? The issue is, the warnings in Firefox won't go away until you upgrade to hardware/software that supports RFC 5746. If you have disabled renegotiation on the server, the connection is safe, but the browser doesn't know. If you want the warnings to go away, please strive to upgrade your hardware/software. Please push your vendor to provide equipment or updates that supports RFC 5746.
Zeus fixed this in the r5 release last week. Punting to oremj to make sure all the remote Zeus nodes are also updated.
Assignee: server-ops → jeremy.orem+bugs
Did they? the release notes don't seem to mention it in any obvious way. http://knowledgehub.zeus.com/media/6.0/RELEASE_NOTES.60r5.txt
Summary: Implement RFC 5746 for mozilla.org SSL sites (ZXTM SSL VIPs), to avoid Mozilla warning about CVE-2009-3555 → Implement RFC 5746 for mozilla.org SSL sites, to avoid Mozilla warning about CVE-2009-3555
It was confirmed to me from their support. I forwarded you the email just now.
(In reply to comment #6) > Zeus fixed this in the r5 release last week. Punting to oremj to make sure all > the remote Zeus nodes are also updated. Does this mean it should already be fixed ? The message is still the today.
Both the Phoenix and San Jose Zeus have been updated to r5 (as of yesterday).
Anything else need to be done here?
In order to verify that this bug is fixed, use Firefox 3.6.2 or later and connect to a site using https and verify that error console does not mention CVE-2009-3555 for the site. As of today, I still get this message for addons.mozilla.org and bugzilla.mozilla.org
(In reply to comment #12) > In order to verify that this bug is fixed, > use Firefox 3.6.2 or later and connect to a site using https and verify that > error console does not mention CVE-2009-3555 for the site. > > As of today, I still get this message for addons.mozilla.org and > bugzilla.mozilla.org bugzilla.mozilla.org is still behind the netscalers so I would expect that one to not be resolved. addons.mozilla.org, I think we will need to do some more digging on the ZXTM side. It should be a setting, don't know but I am seeing the same thing.
For the Netscaler, the instructions to disable renegociation are available : http://support.citrix.com/article/CTX123359 http://support.citrix.com/article/CTX123680 Howewer the client has no way of knowing for sure if renegotiation is disabled at the server level, so you should ask Citrix for the time frame of a RFC 5746 conformant update Would be good to open an incident with Zeus so that they support you in understanding why the error is still visible on the ZXTM.
(In reply to comment #14) > For the Netscaler, the instructions to disable renegociation are available : > http://support.citrix.com/article/CTX123359 > http://support.citrix.com/article/CTX123680 > > Howewer the client has no way of knowing for sure if renegotiation is disabled > at the server level, so you should ask Citrix for the time frame of a RFC 5746 > conformant update > > Would be good to open an incident with Zeus so that they support you in > understanding why the error is still visible on the ZXTM. We are aware of how to turn off renegotiation and it has been turned off for both Zeus and Netscaler. As for the reason this bug was created, we are still talking with Zeus about the support for RFC5746 and the ETA of when it will be available.
Assignee: jeremy.orem+bugs → clyon
Update from Zeus, RFC 5746 will be implemented in a 6.0 r-release by the end of May.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.10pre) Gecko/20100415 SeaMonkey/2.0.5pre] (home, optim default) (W2Ksp4) services.addons.mozilla.org : potentially vulnerable to CVE-2009-3555 addons.mozilla.org : potentially vulnerable to CVE-2009-3555 aus2-community.mozilla.org : potentially vulnerable to CVE-2009-3555
Depends on: 545755
So 6.0r7 has been deployed which supports RFC 5746. We are still looking at some minor tweeks and have a few questions out to Zeus. When we force the security.ssl.require_safe_negotiation, everything checks out.
Is this fixed? All of the mozilla.org sites I have accessed recently have shown the blue site identity button with security.ssl.treat_unsafe_negotiation_as_broken enabled.
(In reply to comment #19) > Is this fixed? All of the mozilla.org sites I have accessed recently have > shown the blue site identity button with > security.ssl.treat_unsafe_negotiation_as_broken enabled. Not all the sites have been resolved. We have resolved the Zeus RFC5746 issues which you can see with bugzilla.mozilla.org & addons.mozilla.org. The others will need to be done on a case by case basis.
Summary: Implement RFC 5746 for mozilla.org SSL sites, to avoid Mozilla warning about CVE-2009-3555 → Implement RFC 5746 for mozilla.org SSL sites to avoid Mozilla warning about CVE-2009-3555
Whiteboard: [infrasec:tls]
(In reply to comment #20) > Not all the sites have been resolved. We have resolved the Zeus RFC5746 issues > which you can see with bugzilla.mozilla.org & addons.mozilla.org. The others > will need to be done on a case by case basis. I filed bug 578987 (wiki.mozilla.org server does not support RFC 5746, see CVE-2009-3555). Should I mark it as duplicate of this bug? Or can someone please confirm it?
Depends on: 602084, 578987
Re comment #20: This problem is still seen with bugzilla.mozilla.org.
...but as I said in bug 607004, only because it includes content from www.mozilla.org (the top background image, https://www.mozilla.org/images/subsite_back.gif ).
Blocks: 607004
Component: Server Operations → Server Operations: Security
QA Contact: mrz → clyon
Mozilla Services Operations was notified of this issue this morning and is tracking work to resolve the issue under bug 655822.
(In reply to comment #26) > Mozilla Services Operations was notified of this issue this morning and is > tracking work to resolve the issue under bug 655822. RFC 5746 support has been activated in all Services Zeus clusters at all sites.
> Mozilla Services Operations was notified of this issue this morning As the bug reporter, over one year ago, may I ask why this bug report here hasn't reached the awareness of "Mozilla Services Operations"?
(In reply to comment #28) > > Mozilla Services Operations was notified of this issue this morning > > As the bug reporter, over one year ago, may I ask why this bug report here > hasn't reached the awareness of "Mozilla Services Operations"? We are looking into how this was missed but it looks like not all the settings from the other Zeus clusters were copied over correctly. If there are other sites which are lacking full secure renegotiation support, separate bugs should be opened. I am closing this bug out since all the sites listed have been resolved.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
I am getting the warning on bugzilla.mozilla.org again, with Firefox 3.6.17 and NSS 3.12.10. Should I reopen, file a new bug, or what?
I am getting this warning on bugzilla.mozilla.org as well as versioncheck.addons.mozilla.org with the latter potentially causing a failure in at least one of my addons (xmarks; still trouble-shooting, but possible?). Firefox (Iceweasel) 4.0.1. Please advise so that "RESOLVED FIXED" == TRUE.
hunkirdowne, the warning shouldn't affect your extension. It's just warning.
(In reply to comment #30) > I am getting the warning on bugzilla.mozilla.org again, with Firefox 3.6.17 > and NSS 3.12.10. Should I reopen, file a new bug, or what? Yes, please file another bug if this issue is still happening.
Alias: moz-rfc5746
Depends on: 666106
Depends on: 545329
Depends on: 666107
Depends on: 666109
Depends on: 666110
Depends on: 666111
Depends on: 666112
Depends on: 666113
Depends on: 666114
I'm pretty sure whatever was "fixed" here has unfixed itself. Shall I keep filing individual bugs per comment 29?
Depends on: 666124
Depends on: 666126
Now I'm completely confused. I consistently get the RFC 5746 warning for lots of mozilla sites, on two different machines (Mac, Win) and have tried both Firefox 5 and nightly. Others seem to see the same problems judging by comment 30 and comment 31. But for some of the sites I checked (e.g. BMO) SSLlabs gives a clean bill of health (specifically for the IP address I'm reaching), as does glob in Australia. I compared certs with glob online and the certs match so it wouldn't appear to be a MITM.
neither safe-mode nor a new profile made any difference
Dan, that could be explained with a server farm, and some servers are compliant and others are not, and they all share the same cert. Given what Dan found, I am reopening this, as the original bug filer.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: chris → mcoates
Oremj, Do we have any idea on what is causing the behavior Dan was observing in comment 35?
I'm getting this on bugzilla.mozilla.org too, in Aurora nightlies (10.0a2)
Blocks: 716498
No longer blocks: 716498
Depends on: 716498
I have some info on this, from Riverbed (Zeus load balancer vendor): "safe mode" here refers to the setting in Zeus... that is, only allow "safe" renegotiations. --------- One subtlety is that the ZXTM (since 6.0r7) renegotiates immediately after the original handshake, which is why this is allowed in the 'safe' setting for ssl3_allow_rehandshake. If you try using a testing tool that does send data between the two handshakes you will see that the vulnerability is blocked when in 'safe' mode. In regards to your first point, about openSSL and SSL_labs check- the issue is that these tools do not send data between the first and the second handshakes- this the ZTM 'safe mode' and so it allows a re-negotiation. The result is a flag by the test even though the situation is safe. If you were to use a test tool that does send data between the two handshakes, you should see this vulnerability blocked. According to our development group, This situation is absolutely safe, and has been discussed on the ietf-tls mailing list. This is why the re-negotiation is allowed. I don't believe this is a bug in Firefox or Traffic Manager- from the Mozilla wiki: https://wiki.mozilla.org/Security:Renegotiation "Unfortunately, when a server is using the vulnerable SSL/TLS protocol version, it is impossible for the browser to know whether a site is protected or vulnerable (i.e whether session renegotiation is enabled or disabled on the server). "Because of this uncertainty, when using the existing SSL/TLS protocol versions, Firefox does not know whether a server is vulnerable. Firefox, therefore, is unable to determine whether a connection has been attacked." --------- It sounds to me like Firefox is overly anxious about it, and will throw that alert even when the server is not technically doing anything wrong. I suspect Firefox is seeing that initial renegotiation that Zeus does and using that as a trigger for the warning. I have tested this with the LB in all 4 settings: 1) Always allow 2) Allow safe re-handshakes (default) 3) Only if client uses RFC 5746 (Secure Renegotiation Extension) 4) Never allow #1 allows insecure renegotiation, confirmed by ssllabs.com. Firefox complains. #2 allows secure renegotiation, but is lenient about these not being RFC5746 ones. ssllabs is happy but complains that client-side renegotiations are allowed, which could be a DoS weakness. Firefox complains. #3 allows only RFC5746 renegotiation. Same test results as #2- ssllabs is happy but reports DoS weakness, Firefox complains. #4 allows no renegotiations at all. Firefox still complains, probably due to the way Zeus does a single renegotiation right away. ssllabs.com is *completely* happy with this... it says Secure Renegotiation is still supported, and that client-side renegotiation is not supported! I think we have multiple separate issues here: 1) Firefox may be triggering this warning based on a secure server-initiated renegotiation... maybe it's secure but not technically following RFC 5746 for some reason. In any case I get the impression it's not *checking*, but merely *inferring* based on what it's seen. 2) ssllabs.com incorrectly detects that secure renegotiation is still possible when it's really not (option #4)... maybe because the server does do a single renegotiation in a secure manner every time. 3) Zeus may be doing that single renegotiation in a way that is not listed as RFC 5746 compliant, thus triggering Firefox's warning. I am following up with them to double-check some things.
(In reply to Jake Maul [:jakem] from comment #40) > One subtlety is that the ZXTM (since 6.0r7) renegotiates immediately after > the original handshake, which is why this is allowed in the 'safe' setting > for > ssl3_allow_rehandshake. If you try using a testing tool that does send > data between the two handshakes you will see that the vulnerability is > blocked when in 'safe' mode. ... > It sounds to me like Firefox is overly anxious about it, and will throw that > alert even when the server is not technically doing anything wrong. This explanation doesn't make sense to me. The ONLY way to completely protect against this vulnerability in a way that the client and server can be confident in is for both sides to send the TLS extension and/or for the server to offer the special psuedo-ciphersuite defined in RFC 5746. For the purposes of the TLS vulnerability addressed in RFC 5746, it doesn't matter if a renegotiation actually happens or not, and it doesn't matter how much (if any) data is sent between any handshakes. AFAICT, Firefox is not being "overly anxious" about this. It reports the problem if and only if the server does not send the proper information (mentioned in my previous paragraph) in its server hello. > I suspect Firefox is seeing that initial renegotiation that Zeus does and > using that as a trigger for the warning. Firefox will issue the warning about insecure renegotiation as soon as it receives the *initial* (not renegotiation) server hello message that is missing the RFC 5746 extension. > I have tested this with the LB in all 4 settings: > > 1) Always allow > 2) Allow safe re-handshakes (default) > 3) Only if client uses RFC 5746 (Secure Renegotiation Extension) > 4) Never allow Whether or not the server is configured to allow renegotiations under certain conditions is orthogonal to whether or not the server is configured to correctly send the RFC 5746 extension. > #4 allows no renegotiations at all. Firefox still complains, probably due to > the way Zeus does a single renegotiation right away. Why would Zues ever initiate a renegotiation? The only time that makes sense is when it wants to request a client certificate. If Zues is starting a renegotiation in *any* other case, then that is a serious *performance* bug in Zeus or (much more likely) in our Zeus configuration. I can help you guys debug this. > 1) Firefox may be triggering this warning based on a secure server-initiated > renegotiation... maybe it's secure but not technically following RFC 5746 > for some reason. Again, Firefox will always warn when the server doesn't send the RFC 5746 extension. Our servers should be configured to *always* send the extension as long as Firefox sends the extension (which it always does, except when explicitly configured in about:config not to). A server that does *any* renegotiation (regardless of who initiated it) is vulnerable to the type of vulnerability that RFC 5746 prevents. > 3) Zeus may be doing that single renegotiation in a way that is not listed > as RFC 5746 compliant, thus triggering Firefox's warning. Isn't this the same as #1?
I did some testing with https://stage-account.services.mozilla.com/ (Zeus 8.0, "3) Only if RFC5746") and last night's Aurora, since I was curious. With default Aurora settings, it does show the Error Console warning. With security.ssl.require_safe_negotiation = TRUE (and then restart Aurora), it no longer shows the Error Console warning, and the page and all resources still load just fine. With s_client -tlsextdebug -msg -debug -state, I see (minus hex dumps): SSL_connect:before/connect initialization >>> SSL 2.0 [length 0080], CLIENT-HELLO SSL_connect:SSLv2/v3 write client hello A <<< TLS 1.0 Handshake [length 0051], ServerHello TLS server extension "renegotiate" (id=65281), len=1 SSL_connect:SSLv3 read server hello A <<< TLS 1.0 Handshake [length 0c19], Certificate ... So, the TLS extension is being advertised from the server to openssl s_client. Further testing with gnutls-cli -e --priority 'NORMAL:%SAFE_RENEGOTIATION' shows that the CLIENT HELLO and SERVER HELLO both contain 65281 and that renegotiation succeeds: |<2>| EXT[0xcbf470]: Sending extension SAFE_RENEGOTIATION |<3>| HSK[0xcbf470]: CLIENT HELLO was sent [152 bytes] |<3>| HSK[0xcbf470]: SERVER HELLO was received [85 bytes] |<2>| EXT[0xcbf470]: Found extension 'SAFE_RENEGOTIATION/65281' |<3>| Safe renegotiation succeeded. And 'NORMAL:%DISABLE_SAFE_RENEGOTIATION' shows 65281 is absent from CLIENT HELLO and SERVER HELLO and the renegotiation attempt is refused by the server: |<2>| ASSERT: ext_safe_renegotiation.c:90 |<3>| HSK[0xe52470]: CLIENT HELLO was sent [147 bytes] |<3>| HSK[0xe52470]: SERVER HELLO was received [80 bytes] |<4>| REC[0xe52470]: Sent Packet[2] Handshake(22) with length: 172 |<4>| REC[0xe52470]: Expected Packet[1] Handshake(22) with length: 1 |<4>| REC[0xe52470]: Received Packet[1] Alert(21) with length: 22 So, it appears that the server I'm testing against: (a) advertises the extension when the client presents it (b) refuses insecure renegotiation attempts I don't know enough about all this to tell whether that's a correct implementation or not, but in light of how changing "require_secure_renegotiation" magically hides the console error message, I'm concerned that Firefox may not be doing quite what we think it is here.
(In reply to Brian Smith (:bsmith) from comment #41) > AFAICT, Firefox is not being "overly anxious" about this. It reports the > problem if and only if the server does not send the proper information > (mentioned in my previous paragraph) in its server hello. Fair enough, but here's a question that immediate occurs to me: should it really trigger an error console warning if the server doesn't support *any* renegotiations? That appears to be one of the things happening here. > Firefox will issue the warning about insecure renegotiation as soon as it > receives the *initial* (not renegotiation) server hello message that is > missing the RFC 5746 extension. Thanks for the clarification. > Whether or not the server is configured to allow renegotiations under > certain conditions is orthogonal to whether or not the server is configured > to correctly send the RFC 5746 extension. Is it correct to send the RFC5746 extension if you're not going to support any renegotiations at all? > Why would Zues ever initiate a renegotiation? The only time that makes sense > is when it wants to request a client certificate. If Zues is starting a > renegotiation in *any* other case, then that is a serious *performance* bug > in Zeus or (much more likely) in our Zeus configuration. I can help you guys > debug this. I don't know, still waiting on an explanation for this. It seems quite strange to me as well. Zeus 6.0r7 is quite old (years), so this is not new behavior. It does support client certificates, but we don't use them anywhere that I know of. > A server that does *any* > renegotiation (regardless of who initiated it) is vulnerable to the type of > vulnerability that RFC 5746 prevents. This is confusing to me. My understanding is that there are some cases where secure renegotiations are possible *without* RFC5746. This is why Zeus has separate settings for allowing "safe" renegotiations and only allown RFC5746 ones. From Zeus support: " The addition of the setting to specifically reference RFC5476 is because some vulnerability scanners used by PCI DSS compliance software tests for the protocol vulnerability that unfortunately does not distinguish between vulnerable servers that permit re-handshakes and ones (like the 6.0r7 'safe' setting ZTM) that don't permit exploitable re-handshakes, but do permit non-exploitable ones from non-5746 compliant clients. " Would you have any sources indicating this is wrong?
(In reply to Richard Soderberg [:atoll] from comment #42) > I did some testing with https://stage-account.services.mozilla.com/ (Zeus > 8.0, "3) Only if RFC5746") and last night's Aurora, since I was curious. > > With default Aurora settings, it does show the Error Console warning. > > With security.ssl.require_safe_negotiation = TRUE (and then restart Aurora), > it no longer shows the Error Console warning, and the page and all resources > still load just fine. Interestingly, I just tested this as well and came up with different results. I often get the error screen, but sometimes content loads properly. It seems that this setting doesn't have an effect on the initial handshake, but does if a renegotiation is actually attempted? With the setting at the default (false), everything loads properly and the message in the error console always appears. With the setting at "TRUE", content sometimes loads properly, and other times results in a Firefox error screen complaining about that setting. Nothing is ever reported in the error console. I did not test exhaustively, and did not restart Aurora after changing the setting back and forth. The other relevant setting, security.ssl.treat_unsafe_negotiation_as_broken, seems to have no effect on wiki.mozilla.org. It throws the message in the error console like normal, but Firefox never complains about it in any other way that I can see. Our SNE wiki page says it should show a red/broken padlock... needs updated I guess. :) For what it's worth, I can duplicate your s_client results, testing against wiki.mozilla.org:443. This is fronted by Zeus 8.0, with the same setting "Only if RFC5746": [jakemaul@JakeBook ~]$ openssl s_client -connect wiki.mozilla.org:443 -tlsextdebug -msg -debug -state CONNECTED(00000003) SSL_connect:before/connect initialization >>> SSL 2.0 [length 0080], CLIENT-HELLO SSL_connect:SSLv2/v3 write client hello A <<< TLS 1.0 Handshake [length 0051], ServerHello TLS server extension "renegotiate" (id=65281), len=1 SSL_connect:SSLv3 read server hello A <<< TLS 1.0 Handshake [length 087b], Certificate SSL_connect:SSLv3 read server certificate A <<< TLS 1.0 Handshake [length 0004], ServerHelloDone SSL_connect:SSLv3 read server done A .... (lots of stuff omitted) .... Secure Renegotiation IS supported It's worth reiterating that a simple 'openssl s_client -connect wiki.mozilla.org:443' with no debug options will report that "Secure Renegotiation IS supported. By my understanding, we have 4 things saying we support secure renegotiations (openssl s_client, gnutls-cli, ssllabs.com, Zeus support), and 1 saying we don't (Firefox). This is by no means conclusive - the latter 2 could be simply based on the former 2, which could both be wrong in some way - but it's certainly cause for concern.
I will figure out why Firefox is complaining about this and whether this is a bug in Firefox or some problem with the server.
Assignee: mcoates → bsmith
Component: Server Operations: Security → Security Assurance: Operations
Suddenly started to get several error messages in console: Is this related to this bug or should I file a new bug? Vista Tb 12.0.1 I noticed that I suddenly could not open any link in an email to any website including GetSatisfaction where I help out. checked error console: Could not read chrome manifest 'file:///C:/Users/Anje/AppData/Roaming/Thunderbird/Profiles/yba3h802.default/extensions/en-GB@dictionaries.addons.mozilla.org/chrome.manifest'. Timestamp: Tue 8/05/12 16:03:03 Warning: Unknown property '-moz-column-fill'. Declaration dropped. Source File: resource://gre-resources/ua.css Line: 166 Timestamp: Tue 8/05/12 16:03:03 Warning: Expected end of value but found 'fill'. Error in parsing value for '-moz-border-image'. Declaration dropped. Source File: chrome://testpilot/content/browser.css Line: 78 Timestamp: Tue 8/05/12 16:03:03 Warning: Expected end of value but found 'fill'. Error in parsing value for '-moz-border-image'. Declaration dropped. Source File: chrome://testpilot/content/browser.css Line: 92 Timestamp: Tue 8/05/12 16:03:03 Warning: Use of getAttributeNodeNS() is deprecated. Use getAttributeNS() instead. Source File: chrome://messenger/content/messenger.xul Line: 0 mail.btinternet.com : server does not support RFC 5746, see CVE-2009-3555 www.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 Timestamp: Tue 8/05/12 16:03:13 Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIExternalProtocolService.loadUrl]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188" data: no] Timestamp: Tue 8/05/12 16:09:44 Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIExternalProtocolService.loadUrl]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188" data: no] Timestamp: Tue 8/05/12 16:09:21 Error: Image corrupt or truncated: mailbox:///C:/Users/Anje/AppData/Roaming/Thunderbird/Profiles/yba3h802.default/Mail/mail.btinternet.com/Inbox.sbd/Family?number=10403342&part=1.2&type=image/jpeg&filename=IMG_1792.JPG Source File: mailbox:///C:/Users/Anje/AppData/Roaming/Thunderbird/Profiles/yba3h802.default/Mail/mail.btinternet.com/Inbox.sbd/Family?number=10403342&part=1.2&type=image/jpeg&filename=IMG_1792.JPG Line: 0 Timestamp: Tue 8/05/12 16:09:21 Warning: Unknown descriptor 'panose-1' in @font-face rule. Skipped to next declaration. Source File: mailbox:///C:/Users/Anje/AppData/Roaming/Thunderbird/Profiles/yba3h802.default/Mail/mail.btinternet.com/Inbox.sbd/Family?number=22664424 Line: 12 there are several lines like the above. I have checked that the browser is set and correct, but no links open and I'm not happy about the my mail server and mozilla suddenly not supporting RFC 5746. All this happened symultaneously. I'm also using latest Firefox. Should this be filed as new bug?
(In reply to Anje from comment #49) > Should this be filed as new bug? Yes, please do.
These appear on "Error console" when loading https://bugzilla.mozilla.org and https://support.mozilla.org/en-US/home with Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120508030517 bugzilla.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 support.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 www.mozilla.org : server does not support RFC 5746, see CVE-2009-3555
(In reply to alex_mayorga from comment #51) > bugzilla.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 > support.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 > www.mozilla.org : server does not support RFC 5746, see CVE-2009-3555 We're waiting to hear back from :bsmith as to whether there's a bug in Firefox that's unnecessarily reporting CVE-2009-3555 warnings for sites that correctly implement secure renegotiation, such as the above-listed sites (and various others). See comment 42 and comment 46.
(In reply to Richard Soderberg [:atoll] from comment #52) > (In reply to alex_mayorga from comment #51) > We're waiting to hear back from :bsmith Ping.
Flags: needinfo?(bsmith)
It seems like the server is not sending the renegotiation_info extension during session resumption handshakes, which is required by the spec. It sends the renegotiation_info extension for full handshakes only. I verified this by using the NSS ssltap tool (ssltap -l -s bugzilla.mozilla.org:443) Here is part of a resumption handshake, which shows that the server is not sending the extension during a resumption handshake, even though Firefox is sending TLS_EMPTY_RENEGOTIATION_INFO_SCSV: Connected to bugzilla.mozilla.org:443 --> [ (198 bytes of 193) SSLRecord { [Mon Oct 15 01:17:35 2012] type = 22 (handshake) version = { 3,1 } length = 193 (0xc1) handshake { type = 1 (client_hello) length = 189 (0x0000bd) ClientHelloV3 { client_version = {3, 1} random = {...} session ID = { length = 32 contents = {...} } cipher_suites[36] = { (0x00ff) TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0xc00a) TLS/ECDHE-ECDSA/AES256-CBC/SHA (0xc014) TLS/ECDHE-RSA/AES256-CBC/SHA (0x0088) TLS/DHE-RSA/CAMELLIA256-CBC/SHA (0x0087) TLS/DHE-DSS/CAMELLIA256-CBC/SHA (0x0039) TLS/DHE-RSA/AES256-CBC/SHA (0x0038) TLS/DHE-DSS/AES256-CBC/SHA (0xc00f) TLS/ECDH-RSA/AES256-CBC/SHA (0xc005) TLS/ECDH-ECDSA/AES256-CBC/SHA (0x0084) TLS/RSA/CAMELLIA256-CBC/SHA (0x0035) TLS/RSA/AES256-CBC/SHA (0xc007) TLS/ECDHE-ECDSA/RC4-128/SHA (0xc009) TLS/ECDHE-ECDSA/AES128-CBC/SHA (0xc011) TLS/ECDHE-RSA/RC4-128/SHA (0xc013) TLS/ECDHE-RSA/AES128-CBC/SHA (0x0045) TLS/DHE-RSA/CAMELLIA128-CBC/SHA (0x0044) TLS/DHE-DSS/CAMELLIA128-CBC/SHA (0x0033) TLS/DHE-RSA/AES128-CBC/SHA (0x0032) TLS/DHE-DSS/AES128-CBC/SHA (0xc00c) TLS/ECDH-RSA/RC4-128/SHA (0xc00e) TLS/ECDH-RSA/AES128-CBC/SHA (0xc002) TLS/ECDH-ECDSA/RC4-128/SHA (0xc004) TLS/ECDH-ECDSA/AES128-CBC/SHA (0x0096) TLS/RSA/SEED-CBC/SHA (0x0041) TLS/RSA/CAMELLIA128-CBC/SHA (0x0005) SSL3/RSA/RC4-128/SHA (0x0004) SSL3/RSA/RC4-128/MD5 (0x002f) TLS/RSA/AES128-CBC/SHA (0xc008) TLS/ECDHE-ECDSA/3DES-EDE-CBC/SHA (0xc012) TLS/ECDHE-RSA/3DES-EDE-CBC/SHA (0x0016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA (0x0013) SSL3/DHE-DSS/DES192EDE3CBC/SHA (0xc00d) TLS/ECDH-RSA/3DES-EDE-CBC/SHA (0xc003) TLS/ECDH-ECDSA/3DES-EDE-CBC/SHA (0xfeff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA (0x000a) SSL3/RSA/3DES192EDE-CBC/SHA } compression[1] = { (00) NULL } extensions[44] = { extension type server_name, length [14] = { 0: 00 0c 00 00 09 6c 6f 63 61 6c 68 6f 73 74 | } extension type elliptic_curves, length [8] = { 0: 00 06 00 17 00 18 00 19 | } extension type ec_point_formats, length [2] = 0: 01 00 | } extension type session_ticket, length [0] extension type 13172, length [0] } } } } ] <-- [ (132 bytes of 80, with 47 left over) SSLRecord { [Mon Oct 15 01:17:35 2012] type = 22 (handshake) version = { 3,1 } length = 80 (0x50) handshake { type = 2 (server_hello) length = 76 (0x00004c) ServerHello { server_version = {3, 1} random = {...} session ID = { length = 32 contents = {...} } cipher_suite = (0x0005) SSL3/RSA/RC4-128/SHA compression method = (00) NULL extensions[4] = { extension type server_name, length [0] } } } } Compare this with an initial handshake to bugzilla.mozilla.org:443, or to any handshake (resumption or initial) to google.com:443.
Assignee: bsmith → nobody
Flags: needinfo?(bsmith)
QA Contact: chris
Assignee: nobody → mpurzynski
I will take a look at it next week, Tuesday I think.
That ssltap output looks to me like Firefox did not send the renegotiation_info extension, as required by http://tools.ietf.org/html/rfc5746#section-3.5 and http://tools.ietf.org/html/rfc5746#section-3.7. My reading suggests to me that Firefox MUST send this extension on a renegotiation, and MUST NOT send the SCSV... this differs from the initial handshake requirements, which simply requires either of them. Further down, http://tools.ietf.org/html/rfc5746#section-4.1 indicates that the client should be able to send the renegotiation_info extension *or* the TLS_EMPTY_RENEGOTIATION_INFO_SCSV SCSV, and that the server should be considered to support secure renegotiation only if it responds with the extension. However, I suspect this applies only to the initial connection, not a renegotiation- this section seems to be more concerned with detecting support for secure renegotiations rather than actual usage. In any case I'm updating our vendor with this info. I will report back any info from them. I'll also forward along any further updates that come in here.
(In reply to Jake Maul [:jakem] from comment #56) > That ssltap output looks to me like Firefox did not send the > renegotiation_info extension, as required by > http://tools.ietf.org/html/rfc5746#section-3.5 and > http://tools.ietf.org/html/rfc5746#section-3.7. My reading suggests to me > that Firefox MUST send this extension on a renegotiation, and MUST NOT send > the SCSV... this differs from the initial handshake requirements, which > simply requires either of them. This wasn't a renegotation handshake; it was a resumption handshake.
Ah, I misunderstood. Sorry, thanks for the clarification. :)
@Brian: would you be able to re-test this now? A while back (somewhere between comment 52 and 53) we changed these load balancers to reject all renegotiations. This may have affected the behavior enough to cause odd results. I have changed it back to allow RFC 5746 renegotiations. I'm confident that the Error Console still shows the warning either way, but I'm wondering if ssltap will show different results.
Status: REOPENED → NEW
Flags: needinfo?(bsmith)
Please ignore comment 52... the vendor has returned to us with a patch, that appears to solve the issue! I will be rolling it out more later this week. For the moment, one LB in PHX1 is patched, and I've confirmed that VIPs hosted on it do not throw a warning in the Firefox error console.
Flags: needinfo?(bsmith)
This is now rolled out on all our public-facing clusters. I'm no longer receiving this message in the Firefox error console for any of our major properties. Marking this as RESOLVED FIXED... please VERIFY or REOPEN as needed. Thanks to all who helped out on this bug over the past ~2.5 years. :)
Status: NEW → RESOLVED
Closed: 14 years ago → 12 years ago
Resolution: --- → FIXED
(In reply to Jake Maul [:jakem] from comment #59) > @Brian: would you be able to re-test this now? A while back (somewhere > between comment 52 and 53) we changed these load balancers to reject all > renegotiations. This may have affected the behavior enough to cause odd > results. I have changed it back to allow RFC 5746 renegotiations. (In reply to Jake Maul [:jakem] from comment #61) > This is now rolled out on all our public-facing clusters. I'm no longer > receiving this message in the Firefox error console for any of our major > properties. Great. I recommend that you re-disable client-initiated renegotiations if you haven't already done so. There's basically no need to support them, and there's still some risk in doing so. Was the patch to address the alleged bug I described in comment 54, or was it a different issue? And, is that patch generally available? It would be good to get a pointer to any public info about it.
It's worth noting, https://{www,addons,bugzilla}.mozilla.org and possibly other properties still lose the lock with security.ssl.treat_unsafe_negotiation_as_broken = true because they load content from https://statse.webtrendslive.com. But that should probably be a separate bug if anyone cares enough. (I don't right now.)
(In reply to Brian Smith (:bsmith) from comment #62) > Great. I recommend that you re-disable client-initiated renegotiations if > you haven't already done so. There's basically no need to support them, and > there's still some risk in doing so. Yep, already done! :) > Was the patch to address the alleged bug I described in comment 54, or was > it a different issue? And, is that patch generally available? It would be > good to get a pointer to any public info about it. I believe it was for the issue you discovered. That comment led *directly* to the resolution of the ticket on their end, and the eventual deployment of the patch. I don't believe the patch is meant to be generally available... they spun it because we asked, and it's specific to the version we're running. However, I have been told it is being rolled into the next release automatically, so any other Zeus/Stingray users will get it during a normal upgrade cycle. I'm sure anyone affected could contact them directly and request the fix (citing your comment 54 here if necessary), but I wouldn't want us to distribute it. (In reply to Matt McCutchen from comment #63) > It's worth noting, https://{www,addons,bugzilla}.mozilla.org and possibly > other properties still lose the lock with > security.ssl.treat_unsafe_negotiation_as_broken = true because they load > content from https://statse.webtrendslive.com. But that should probably be > a separate bug if anyone cares enough. (I don't right now.) There's a project to convert stuff from WebTrends to Google Analytics... I believe most of our web properties are involved in that. I don't know if Google is better than WebTrends in this respect, but it seemed worth mentioning. :)
Depends on: 1018878
No longer depends on: 1018878
See Also: → 1018878
Component: Operations Security (OpSec): General → General
Product: mozilla.org → Enterprise Information Security
You need to log in before you can comment on or make changes to this bug.