For a long time, the UI has not made a distinction between low-, medium, and high- security cipher suites, even though PSM does try to classify cipher suites into those buckets. We have some preferences to turn on low- and no- encryption cipher suites. We should remove those preferences. Once we do that, we can remove PSM's reporting of the distinction between low, medium, and high security state. It would simply be the case that "high" is a synonym for "secure" (i.e. not mixed content, no cert override). This will simplify the implementation of nsISecureBrowserUI, which will help us make progress to replacing it with something that works much better. Chromium does not support these weak cipher suites: https://mxr.mozilla.org/chromium/source/src/net/socket/ssl_client_socket_mac.cc#356 Microsoft does support some of them, but off by default. http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757%28v=vs.85%29.aspx We do not need to support any "no encryption" configuration of Firefox. Firefox cannot work correctly in such a configuration because various Mozilla-provided services (AUS, addon blocklist, etc.) cannot work with those cipher suites. The preferences to enable these cipher suites are a footgun for users. Dao: Please review the changes to browser/. In particular, is it OK to remove the "level" attribute that is supposedly used only by third-party themes? Luke: Please review the trivial change to js/ Honza: Please review the rest. https://tbpl.mozilla.org/?tree=Try&rev=0060823b2b55

Comment on attachment 669014 [details] [diff] [review] Remove low-security cipher suites, PSM's reporting of security levels of a connection, and related UI Yes, third-party themes might still use the level attribute. Can you just set level=high for STATE_IS_SECURE regardless of STATE_SECURE_*?

Comment on attachment 669014 [details] [diff] [review] Remove low-security cipher suites, PSM's reporting of security levels of a connection, and related UI r+ for the js/src changes.

Addressed Dão's request.

Comment on attachment 669426 [details] [diff] [review] Remove low-security cipher suites, PSM's reporting of security levels of a connection, and related UI >--- a/browser/base/content/browser.js Sun Oct 07 08:19:00 2012 -0400 >+++ b/browser/base/content/browser.js Tue Oct 09 00:33:12 2012 -0700 >@@ -4232,35 +4232,31 @@ var XULBrowserWindow = { > this._host = gBrowser.contentWindow.location.host; > } catch(ex) { > this._host = null; > } > #endif > > this._hostChanged = false; > >+ // We don't style the Location Bar based on the the 'level' attribute >+ // anymore, but still set it for third-party themes. >+ The comment is a duplicate of the one a few lines further down, where I think it makes slightly more sense, as it annotates the code setting the attribute rather than some random variable declarations. >--- a/uriloader/base/nsIWebProgressListener.idl Sun Oct 07 08:19:00 2012 -0400 >+++ b/uriloader/base/nsIWebProgressListener.idl Tue Oct 09 00:33:12 2012 -0700 >- const unsigned long STATE_SECURE_HIGH = 0x00040000; >- const unsigned long STATE_SECURE_MED = 0x00010000; >- const unsigned long STATE_SECURE_LOW = 0x00020000; Would it make sense to keep these as aliases for STATE_IS_SECURE in order to avoid breaking a large number of add-ons?

Comment on attachment 669426 [details] [diff] [review] Remove low-security cipher suites, PSM's reporting of security levels of a connection, and related UI Review of attachment 669426 [details] [diff] [review]: ----------------------------------------------------------------- Looks good. r=honzab. ::: security/manager/boot/src/nsSecureBrowserUIImpl.cpp @@ +1052,5 @@ > prevContentSecurity->SetCountSubRequestsBrokenSecurity(saveSubBroken); > prevContentSecurity->SetCountSubRequestsNoSecurity(saveSubNo); > prevContentSecurity->Flush(); > + PR_LOG(gSecureDocLog, PR_LOG_DEBUG, ("SecureUI:%p: Saving subs in START to %p as %d,%d,%d\n", > + this, prevContentSecurity.get(), saveSubHigh, saveSubBroken, saveSubNo)); Maybe remove the white spaces?

https://hg.mozilla.org/integration/mozilla-inbound/rev/b36d5c933092 I removed the changes to nsIWebProgressListener based on dao's concern about addon compatibility. This means we set the STATE_SECURE_HIGH bit whenever we set STATE_IS_SECURE.

Backed out due to orange: https://hg.mozilla.org/integration/mozilla-inbound/rev/782f9b92815c

https://hg.mozilla.org/integration/mozilla-inbound/rev/b9a8253986f7 The orange was caused by this bad change: https://hg.mozilla.org/integration/mozilla-inbound/diff/b36d5c933092/security/manager/boot/src/nsSecureBrowserUIImpl.cpp#l1.52 Compare to this fixed change: https://hg.mozilla.org/integration/mozilla-inbound/diff/b9a8253986f7/security/manager/boot/src/nsSecureBrowserUIImpl.cpp#l1.51

Page Info still has support for weak security.

I was doing experimentation with SPDY and Firefox, analysing the communication with Wireshark. Using a null encryption scheme it was possible to see the SPDY data in hex-dump form within Wireshark. It appears that now I'm using a later version of Firefox to get SPDY/3 support, the support for null ciphers has disappeared. There was no need to remove this option, as there's already a scary warning when you go to the about:config page to enable these ciphers. Is it possible to re-enable them now this has been "fixed"? I understand that I could use ssltap, but that adds a middlebox that means that the setup is further from reflecting actual use.

irl, https://developer.mozilla.org/en-US/docs/NSS_Key_Log_Format this is a good way to get decodable wireshark traces that don't need the null cipher.

(In reply to Patrick McManus [:mcmanus] from comment #13) Ok, that does solve the problem of getting Wireshark traces. Still, it seems like functionality has been removed when it didn't need to be removed. Could the functionality remain but not be compiled in by default instead? I assume the ciphers are all part of openssl so it's only actually the option of enabling/disabling them that's changed.

(In reply to irl from comment #14) > Still, it seems like functionality has been removed when it didn't need to > be removed. Could the functionality remain but not be compiled in by default > instead? I assume the ciphers are all part of openssl so it's only actually > the option of enabling/disabling them that's changed. These features were removed because (a) they were dangerous to enable, and (b) they complicate maintenance of the UI. Notice that the patch that did the removal also removed the whole notion of "low security" from the UI. This was the main benefit. It is easy to enable these at build-time: just write a patch that enables them and apply that patch to your local test build.

I use Firefox to access the management ports of IBM pSeries p5 machines. These run a basic webserver and use https with low-security ciphers. They are not updateable to change this. Up until now, setting security.ssl3.rsa_rc4_40_md5;true has allowed me to continue to use Firefox to access these systems. With this "bug fix", actually a reduction in basic functionality, I can no longer do so. Our production servers are thus currently at risk. Any suggestions as to how I can get this necessary functionality back? Use some sort of "lite" browser just to access these management ports? As FireFox is my browser of choice, I do not want to have to permanently back-level it and expose myself to future security risks.

(In reply to rad56mail-marketing from comment #16) > currently at risk. Any suggestions as to how I can get this necessary > functionality back? Use some sort of "lite" browser just to access these > management ports? As FireFox is my browser of choice, I do not want to have > to permanently back-level it and expose myself to future security risks. For the next year or so, you can use the fully-supported Firefox 17 ESR to access your management console: http://www.mozilla.org/en-US/firefox/organizations/all.html You can configure it to live side-by-side with real Firefox, but you should use a separate Firefox profile for ESR than you use for real Firefox. Before Firefox 17 ESR support ends, I recommend asking IBM what solution they recommend. If they don't have a better solution, one possibility would be to keep using the Firefox 17 ESR in a very locked-down VM forever, for the sole purpose of accessing those management consoles. Another alternative would be to investigate using some kind of MitM proxy (also called a TLS Intercepting Proxy) that can be configured to accept secure cipher suites on its incoming interface and obsolete insecure cipher suites on its outgoing interface.

Thanks Brian. Have reverted completely to FF 17 ESR which works a treat. I have already opened a conversation with IBM on this issue - I tried a few other "lite" browsers but these all use engines that also no longer allow 40-bit or 56-bit ciphers.

you seem to think security is only about confidentiality. there is also an aspect of availability. removal of low encryption support is also a security breach. years ago french law mandated 40 bit as the maximum encryption for "international" supported interfaces. one of the reasons i was glad to be ff user was because of its continued support for so-called low encryption. just because others have dropped support, imho, is not a justification - at best it is an excuse. the "problem" it solves is smaller than the one it creates. basically, i cannot ever apply a security patch, because then i will lose the ability to manage servers service processors. just remember - this change creates a real problem for users. so sad to see you go into "follow the pack" mode. michael

p.s. "you" is not meant to be referring to anyone in particular - I am aware that it is a group process - so you is plural.

I am new here, just to say my opinion. I know your work is hard and great and decisions must be done... Since i use Mozilla Firefox ( 3.0 ) i was everytime happy with it. Then the developers MOVED AWAY the box-preferences where you could click, what you would like to warned about! I was angry and sad. Then I found out, that the strings were always left there in "about:config". Right okay. Bit more work, but okay. And now you removed THE SECURE dialogs. It is not an outdated concept. Please include it again! pls! If i come from my online banking site to a normal site I WOULD LIKE TO BE WARNED. And with mixed content too. And some people want eventually to be warned about going onto a "secure" connection. To know, that they are now making secure things. I cant understand why you deleted the whole function/code out of the project. There is no addon for it =( Can someone explain to me why the function is removed? And it has a bug, its better with a bug than NOTHING nowhere a warning or not? Sorry for bad english. Come from an not english talking country =( thx. bugreporting@tormail.org