Open Bug 1353710 Opened 8 years ago Updated 2 years ago

identity ui: Non-PFS should be called as weak encryption (yellow triangle)

Categories

(Firefox :: Security, defect, P3)

Product:
Firefox
Component:
Security
Version:
55 Branch
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: jan, Unassigned)

References

(Blocks 3 open bugs)

Details

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.
Blocks: 1351684, 942136
Component: Untriaged → Site Identity and Permission Panels
See Also: → https://bugzilla.mozilla.org/show_bug.cgi?id=1310447, https://bugzilla.mozilla.org/show_bug.cgi?id=1353705
Summary: identity ui: Non-PFS should be called as weak encryption → identity ui: Non-PFS should be called as weak encryption (yellow triangle)
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."
Blocks: https-everything, lockicon
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).

Isn't there an indicator precisely for this now? I've seen it mentioned in the TLS 1.0 deprecation ticket here: https://bugzilla.mozilla.org/show_bug.cgi?id=1227521

Since it exists now, it wouldn't hurt / clutter the UI more when also using it for weak ciphers and eventually lack of PFS, right? So wouldn't that be a great idea to give server vendors a big nudge to improve this while avoiding breaking the sites entirely? (Which full removal of questionable ciphers will do)

I don't have a strong opinion on that, to be honest, Dana maybe?

Flags: needinfo?(dkeeler)

TLS 1.0 and TLS 1.1 have already been degraded by bug 1535210. Thank you! :)
This bug asked for degrading everything that is not PFS AEAD, at least initially for Nightly (to DevEdition?) to establish awareness among developers.

https://searchfox.org/mozilla-central/rev/662de518b1686c4769320d6b8825ce4864c4eda0/security/manager/ssl/nsNSSCallbacks.cpp#1274-1275
Would it be possible to extend it to something like this?

#if defined(MOZ_DEV_EDITION) || defined(EARLY_BETA_OR_EARLIER)
  bool deprecatedTlsVer;
  switch (channelInfo.cipherSuite) {
    case TLS_CHACHA20_POLY1305_SHA256:
    case TLS_AES_256_GCM_SHA384:
    case TLS_AES_128_GCM_SHA256:
    case TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256:
    case TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256:
    case TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:
    case TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:
    case TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:
    case TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:
      deprecatedTlsVer = false;
      break;
    default:
      deprecatedTlsVer = true;
      break;
  }
#else
  bool deprecatedTlsVer = (channelInfo.protocolVersion < SSL_LIBRARY_VERSION_TLS_1_2);
#endif

I think it would be more appropriate for something like this to go in the web console or the network security panel (and that way we could actually ship it to release).

Flags: needinfo?(dkeeler)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.