[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 13 Mar 2014 17:51:32 -0400
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: cve-assign@...re.org
CC: oss-security@...ts.openwall.com
Subject: Re: CVE Request?: konqueror - https uses all ciphers, even weak ones
On 03/04/2014 10:19 AM, cve-assign@...re.org wrote:
> There are also design tradeoffs in how a browser should present
> information to the user about the cipher suite. Suppose that the
> directly visible UI can present only one bit of information about the
> https status (e.g., either the SSL icon is there or it isn't, or the
> SSL color is there or it isn't). One option is to report that the
> connection is "secure" if SSL is in use at all, and "insecure"
> otherwise. Another option is to report that the connection is "secure"
> if SSL is being used with a sufficiently strong cipher suite, and
> "insecure" otherwise. Possibly the second option isn't used anywhere:
> in other words, there's no browser that lets 40-bit sessions occur but
> uses its one bit on information to report "insecure."
>
> (In practice, there's no longer only one bit of information because
> of the "green color" convention for EV.)
I agree that the flexibility of the browser UI is weak at best, and that
adding more bits of information to the UI is probably a bad idea. But
UI is not the only thing (see below).
at most, we have roughly 4 states of UI that users can distinguish for
security levels of connections to HTTP URLs:
0) plain HTTP
1) "broken HTTPS"
2) HTTPS
3) HTTPS with EV certification
category 1 ("broken HTTPS") might include mixed-content sigils, or
epiphany's broken-lock or <strikethrough>https://</strikethrough> in the
address bar for failed X.509 validation; i submit that most users cannot
distinguish between features within this category, but might be able to
detect the difference between these states and either condition 0 or
condition 2.
The basic training we give to users is "if you see the lock icon, your
session is secure", which i think is the right message to distinguish
between cases (0 or 1) and cases (2 or 3).
I'd argue that known-broken ciphersuites or weak key agreement schemes
or crackable server EE keys or mis-certified X.509 chains should all
fall into category 1 at most (and maybe should just be terminated or
treated as state 0). It sounds to me like you're saying you're OK with
placing at least some of these cases into group 2 or 3. I disagree with
that assessment, because i think it makes the HTTPS indicator
meaningless at the level of semantics that users are used to.
But in the browser case specifically, we have a non-UI issue as well,
which is whether the browser should treat a given connection as secure
when it does things like replaying cookies over it (or permitting
resource loading in an otherwise secure mixed-content scenario, or
sending REFERER headers, or any of the other ways that browsers do
things differently based on whether they think the current connection is
"https" or not).
If a browser receives a cookie marked "secure" under a strong https
connection, and then replays that cookie to the same server on a new
HTTPS connection that is markedly weaker, the browser has potentially
compromised the user's entire session. Does this seem like a vulnerability?
--dkg
Download attachment "signature.asc" of type "application/pgp-signature" (1011 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
