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.