As a non-Firefox/non-HTTP consumer of NSS, I'd like to see an NSS API flag
indicating a cipher suite is retained for backwards compatibility but
considered inferior by cryptographic community standards at the time the
NSS library was built.
A. is unacceptable because it breaks copy/paste of URLs
B. For UI, I'd suggest a ? over the padlock rather than a red bar. The
community believes RC4 may be vulnerable to high-skill attackers and is
likely to become more vulnerable to other attackers over time. That's
questionable security, not no security. It's still a lot better than
unencrypted (which is what you get if you remove RC4 prematurely).
C. The "https" URI scheme specifies the protocol not the policy so it
technically does not imply the connection is or will be secure. But I agree
this is non-obvious to at least some users and prefer option B.
Regardless, I think NSS should provide the flag, and Firefox can design the
UI.
- Chris
--On February 3, 2014 8:49:27 -0800 florian.ben...@quantumedia.de wrote:
Hi folks,
there is consensus that some algorithms/ciphers (e.g. RC4) allowed by
default should not be considered secure, though because of interop
issues, they cannot be removed at this point.
The problem with this is that people may think they are using a secure
connection while in fact, someone could eavedrop. To reduce the impact of
this problem, I propose to implement a visual indicator for when a
connection should not be considered secure. The goal is not to show an
OMG-BEWARE message but instead to not show a (falsy) "secure" indicator.
Currently, there is a padlock shown for HTTPS connections in Firefox (see
first part of [1]). For insecure (but encrypted connections), there are
three options:
A. Make it look like an HTTP connection: No padlock but the "world" icon,
no "https:" string.
B. Indicate a broken padlock (e.g. with a big fat red bar crossing the
padlock), show the "https:" string (like in the second part of [2]).
C. Make it look like an HTTP connection but not lie about the protocol:
Use the globe icon but show the "https:" string (like part 3 of [1]).
(A) is lying but mostly obvious, i.e. it says that the user is not on an
encrypted connection and should act accordingly. (C) is non-obvious
because the globe can mean anything and the "https:" may confuse /
mislead people who are used to looking for this string. (B) may not be
completely obvious but it shows that there is something wrong although
you are on an encrypted connection - I prefer this last option.
I understand that this is not dev.firefox but I think this is a solution
that most can live with for the foreseeable future (this is no long-term
solution!). Do you agree?
(The UI resolution can also be adopted for HTTP/2.0 unauthenticated
HTTPS, and on any connection where the user bypassed any blocking
mechanism, e.g. for failed cert checks. It may require changes to the
identity panel as well to explain why the connection is shown as
"unencrypted".)
Best regards,
Florian Bender
[1] http://imgur.com/C6wOlRm
Am Samstag, 14. Dezember 2013 07:48:01 UTC+1 schrieb
marlen...@hushmail.com:
I present a proposal to remove some vulnerable/deprecated/legacy TLS
ciphersuits from Firefox. I am not proposing addition of any new
ciphersuits, changing of priority order, protocol removal, or any other
changes in functionality.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
