Open Bug 1353710 Opened 3 years ago Updated 5 months ago
identity ui: Non-PFS should be called as weak encryption (yellow triangle)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0 Build ID: 20170404100210 Steps to reproduce: https://www.xing.com/ Actual results: Plain RSA is shown as secure as the best encryption like TLS 1.3 or TLS1.2 + ECDHE-RSA-AES256-GCM-SHA384. Expected results: A plain RSA website should not have a green padlock without a yellow triangle. (weak encryption identity) Please make a pref to warn about ancient encryption, which should get enabled in Nightly be default (for now). What should get checked for this: * cert has OCSP address, but not response is stapled + response is not available * if TLS 1.0 or TLS 1.1 is used * if the cipher (even in TLS 1.2) is TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA * show warning also if a subrequest breaches this and later in the future when TLS 1.3 is avaiable in Nginx+Apache, those additional ciphers: TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA we may open a new bug for this far later. This is in a line with bug 1310447 and bug 1353705 for bug 1351684.
https://dxr.mozilla.org/mozilla-central/search?q=weak+encryption The weak cipher locales are not needed anymore, as RC4 got kicked out, right? Perhaps there is a need to modify them or extend them because it would a little bit too hard to say that this website "is not private". <!ENTITY identity.description.weakCipher "Your connection to this website uses weak encryption and is not private."> Source: https://dxr.mozilla.org/mozilla-central/source/browser/locales/en-US/chrome/browser/browser.dtd#724 Maybe something like this to even cover a soft-failed OCSP: "Your connection to this website is not secured by modern encryption."
I think I asked this in another bug already, but what's the point of enabling security indicators in Nightly only? I don't think that helps anyone. In any case, I'm moving this to Firefox:Security to get it a broader audience (I guess it fits in both components). If I'm not mistaken this affects about 8-10% of the entire secured web right now: https://mzl.la/2r5yMhO
Component: Site Identity and Permission Panels → Security
Priority: -- → P3
(In reply to Johann Hofmann [:johannh] from comment #2) > I think I asked this in another bug already, but what's the point of enabling security indicators in Nightly only? I don't think that helps anyone. > > In any case, I'm moving this to Firefox:Security to get it a broader audience (I guess it fits in both components). > > If I'm not mistaken this affects about 8-10% of the entire secured web right now: https://mzl.la/2r5yMhO My thought was that webdevelopers and server administrators use Nightly and Chrome Canary to check their websites. So they could see they currently doing something very bad and they risking that it would be shown to all users in the future. As you are saying there are not that few Non-PFS sites: https://www.trustworthyinternet.org/ssl-pulse/#chart-forward-secrecy I think it would be easier to get a positive decision about this bug if it's in Nightly first and behind a pref in beta/release.
I think it would be a very good idea to have a list of known not-very-secure ciphers where the connection is still established but the green padlock isn't shown. If you don't think this is a good idea, just remember the ancient 3DES is still enabled and cannot be easily disabled for compatibility reasons, and it currently shows a perfectly green padlock _without any warning_. If there is opposition to yet another icon, use the one that is already used when part of the site is transferred over HTTP (grey padlock with red strike).
You need to log in before you can comment on or make changes to this bug.