Currently, the location bar distinguishes between: * Encrypted, EV * Encrypted, non-EV * Unencrypted but not blocked subresources on an encrypted page * Unencrypted and blocked subresources on an encrypted page * Top-level document not encrypted There's no distinction in the UI between sites whose encryption is properly configured and sites whose encryption is badly configured. Anecdotal observation suggests that, on one hand, sites don't make improvements that are not visible and, on the other hand, sites do want to have a "better" security indicator. Banks flock to EV certs but don't appear pay proper attention to ciphersuites. For example: https://www.ssllabs.com/ssltest/analyze.html?d=auth.aktia.fi In order to nudge sites to improve their crypto config, I suggest we, *orthogonally from EV* (in order to have influence over sites that don't pay for EV), make the lock more attractive when the site's encryption is configured according to best practices as far as Firefox can see. (I don't have a concrete proposal for what exactly the lock should look like for properly-configured sites and what it should look like for encrypted but badly-configured sites. I'm hoping that UI designers have ideas.) The more attractive lock would be shown if the document and its subresources satisfy all of the following: * The negotiated protocol version is TLS 1.2 * The negotiated cipher suite is a DHE suite with a DH group size of 2048 bit or higher or an ECDHE suite. (Forward secrecy.) * The negotiated cipher suite is an AES suite (or in the future a ChaCha20 suite if we start supporting it). (No RC4.) * The authentication key is a 2048-bit or higher RSA key or an equivalent ECDSA key. ...and additionally the top-level resource has HSTS enabled for its host.

I'm kind of pessimistic that UI nudges will help much here. EV itself is a pretty significant indicator (compared to non-EV), but seems to have had limited success (although that's tied up with the greater cost for EV certs, I'm sure). It's hard to explain the extra states to users, and without user demand I'd doubt that sites would feel more compelled to change. I'd tend to think that if we're serious about this, and can craft a message regarding it's virtues, that we should go the route of treating it as non-SSL. Similar to what we do with Mixed Content. No user education needed. I suppose one could go the Mixed Content route fully and add a "Notice! This site's security is weak!" kind of indicator if one really wanted to give an extra push. Probably a tougher sell, and risks being a user-annoyance.

(In reply to Justin Dolske [:Dolske] from comment #1) > I'm kind of pessimistic that UI nudges will help much here. EV itself is a > pretty significant indicator (compared to non-EV), but seems to have had > limited success (although that's tied up with the greater cost for EV certs, > I'm sure). EV is a price discrimination mechanism, so of course it's not used by all https sites. If it were, it would no longer be an effective price discrimination mechanism. Furthermore, even some entities that could afford an EV cert might opt not to do so, because EV certs being of dubious security value. If you are being MITMed with a fraudulent DV cert on a domain whose legitimate cert is an EV cert, you, the user, are supposed to be aware that this particular site is supposed to have an EV cert and to treat the lack of an EV indicator as a single or something being very wrong. However: * Even if you have visited before, Firefox won't alert you that the site downgraded from EV to DV. * On the contrary, Firefox will happily treat EV https://example.com and DV https://example.com as the same origin and send client-side data (e.g. cookies) obtained from EV https://example.com to DV https://example.com, so even if you notice that something is wrong, the MITM already has your login cookie. * Some sites go from EV to DV without there being a MITM involved: https://hsivonen.fi/extended-uncertainty/ * Some companies have EV on some of their hosts but not others, which shows how futile it is to expect the user to mentally keep track of which sites are supposed to have EV. For example, https://twitter.com/ is EV but https://mobile.twitter.com/ is not. The Finnish bank Nordea shows EV when a customer navigates to their net bank directly but doesn't show EV when a customer is redirected to the back by a merchant or an IdP relying party (of course, EV would be all the more important in that case...). So EV is in practice just as vulnerable to MITM with a fraudulent cert as DV is, but on top of that the users who do notice imperfect deployments get the agony of thinking an attack might be going on even when it isn't. (E.g. when visiting https://mobile.twitter.com/) What I'm suggesting is very different from EV. EV is supposed to have value when you notice its *absent* even though it's supposed to be present, but it's not reasonable for users to notice it or to keep track of where they should be noticing it considering the above problems. The configurations that I proposed to get a more attractive padlock offer security benefits when they are *present*. Moreover, the configurations I listed in comment 0 are all within the power of the site itself and are not a function of the relationship with the site with a CA who is looking to capture surplus money. > It's hard to explain the extra states to users, and without user > demand I'd doubt that sites would feel more compelled to change. I think there is some chance that e.g. Evernote would be ashamed enough to fix their config if even a handful of users asked them why Gmail and Twitter have a cooler lock that Evernote. > I'd tend to think that if we're serious about this, and can craft a message > regarding it's virtues, that we should go the route of treating it as > non-SSL. Similar to what we do with Mixed Content. No user education needed. > > I suppose one could go the Mixed Content route fully and add a "Notice! This > site's security is weak!" kind of indicator if one really wanted to give an > extra push. Probably a tougher sell, and risks being a user-annoyance. The problem is that the vast majority of https sites today would fail the check, so giving warnings on just about every https site today would look like crying wolf. Hence, the suggestion to give sites that are getting things right a new kind of indicator instead of withholding the old indicator from sites that don't get it right.

s/single or/signal of/

(In reply to Frank Ch. Eigler from comment #4) > See also the Calomel SSL Validation extension; it's frustrated by Firefox > not propagating enough ssl connection metadata. > https://forums.mozilla.org/addons/viewtopic.php?f=7&t=14680 Please email me (brian@briansmith.org) what handshake metadata items you want exposed, and I will ensure that the information you need is exposed to addons. It is very easy for us to do, though there will be limitations for a while on the metadata we return from pages that were loaded from our HTTP(s) cache. Note that currently we already expose the full name of the cipher suite (check out the UI in Firefox Nightly), accidentally. I intend to keep it that way. From Slashdot: > Along the same lines, I also recommend CipherFox [github.com], which has a > configurable status-bar display of symmetric/asymmetric algos and their > bit-lengths, and the hash function used in a secure connection. CipherFox also > allows RC4 to be toggled, which is handy in conjunction Calomel. Both of these addons can serve as inputs into what we add to Firefox. Personally, I would like to move all the details regarding the SSL connection from the site identity block to the network tab of the developer tools. The reason is that a page us usually comprised of multiple resources from multiple servers, and there will be a mix of good/back/neutral practices from each server. But, our current UI really only shows you the information about the connection that the page was loaded from. For example, if the page was loaded over a TLS 1.2 connection with perfect forward secrecy (e.g. TLS_ECDHE_ECDSA_WITH_AES_126_GCM_SHA256), but all the personal data was loaded over an SSL 3.0 connection that used TLS_RSA_WITH_RC4_128_SHA, then it is misleading for us to claim the page is using (only) TLS_ECDHE_ECDSA_WITH_AES_126_GCM_SHA256. Also, even though I am very much in favor of perfect forward secrecy, it is hard to argue that PFS is needed for a CDN that is only used for <script src>. I am not sure that we should be penalizing websites that do that. But, if we try to be smart about calculating a goodness score, then it seems like a lot of work to get right, if getting it right is even possible.

If we were to do this, then it would depend on bug 886752, because we would need to make sure that whatever criteria we use to make this determination is exposed in the UI.

See bug 956744 for FS See bug 947149 for RC4 See bug 901393 for TLS on Mozilla servers

We are now on the way to show no longer the padlock icon on sites that support SSL 3/RC4 and we warn if a SHA-1 cert is used. There are more great ideas depending on bug 1068944.

I would also like to easily distinguish (even grade) TLS connections. The PCI SSC had originally envisioned to ban TLS 1.0 (what they call early TLS) in June 2016, but had to push back the date to June 2018 http://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls since many e-commerce web sites are far from being ready for such a switch and way to many old browsers (IE 9/Vista, Android 4.x native browser, Chrome 28 on Samsung devices...) are still around. The new PCI DSS (3.1 revised) mandatory requirement after June 2016 is that TLS 1.1/1.2 has be offered during the payment step. Current browsers do not clearly report when a site is limited to TLS 1.0 and has not yet switched to TLS 1.2 (with modern ciphers) for the fine folks running SSL Labs https://www.ssllabs.com/ this is considered as a serious drawback since last May: https://community.qualys.com/blogs/securitylabs/2015/05/22/ssl-labs-increased-penalty-when-tls-12-is-not-supported it would be very nice if everybody could easily judge if an HTTPS connection still relies on old TLS 1.0 stuff or "fresh" TLS 1.2. Considering that TLS 1.3 is just around the corner I wouldn't mind putting some pressure on sites that are stuck solely with TLS 1.0.