Date: Tue, 4 Mar 2014 10:19:29 -0500 (EST) From: cve-assign@...re.org To: dkg@...thhorseman.net Cc: cve-assign@...re.org, oss-security@...ts.openwall.com Subject: Re: CVE Request?: konqueror - https uses all ciphers, even weak ones -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > A misconfigured server might only offer a 40-bit cipher to a peer that > offers a 40-bit cipher, but might offer a stronger cipher to a peer that > does *not* offer any 40-bit ciphers. > > arguably, this involves two different misconfigurations (both server and > client), but the issue would be mitigated if the client was not offering > a weak cipher and claiming it was a successfully secure connection. This can be interpreted as a design tradeoff between two cases. In the original case, it is best for Konqueror to include 40-bit cipher suites, because the stated user behavior is to react to a handshake failure by typing in the http:// URL. In this new case, it is best for Konqueror to omit 40-bit cipher suites. However, the new case calls into question the entire protocol. For that type of server behavior, if a client wants to achieve the best possible connection at all costs, it should send a series of Client Hello messages that specify exactly one cipher suite (i.e., its current first preference), and make sure that the handshake fails before moving on to other cipher suites. In this specific case, Konqueror would withhold information about whether it would agree to a 40-bit cipher suite until it is sure that every stronger cipher suite is actually rejected with a handshake failure. Similarly, any other browser would withhold information about whether it would agree to a 128-bit cipher suite until it is sure that every 256-bit cipher suite is actually rejected with a handshake failure. In other words, your proposed "might offer a stronger cipher" case ultimately isn't about a problem with Konqueror; it's about a limitation of the protocol itself. > issue would be mitigated if the client was not offering > a weak cipher and claiming it was a successfully secure connection. > > Here is another situation where konqueror successfully indicates a > "secure" connection to a server that has a known-insecure configuration: > point konqueror at: https://demo.cmrg.net/ -- you'll see a successful > connection, though that server only offers DHE over a > trivially-crackable 16-bit group. > > NSS-based browsers will throw an ssl_error_weak_server_ephemeral_dh_key > error and refuse the connection; konqueror claims it is a secure connection. 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.) One might argue that the right approach is to expand the amount of information in the directly visible UI beyond one bit. However, this could require years of possibly futile efforts at user training. One might, more specifically, argue that the ONLY way to go beyond one bit of information is to make the insufficiently strong sessions fail. For example, http is presented as one color, "good https" is presented as a different color, and "40-bit bad https" is presented as an error message. Not everyone agrees that this is the only way. The current Konqueror behavior ("40-bit bad https" isn't directly reported to be any different from "good https") is suboptimal, but this seems best treated as an opportunity for security improvement, with more than one reasonable design alternative. Finally, again, the objective here isn't to convince anyone that Konqueror should continue to use 40 bits forever. The best and cleanest way to make progress for the https ecosystem is for all clients and all servers to drop support for all of the weak cipher suites (40-bit ones are just an example). This can be achieved without labeling Konqueror's behavior as a vulnerability. - -- CVE assignment team, MITRE CVE Numbering Authority M/S M300 202 Burlington Road, Bedford, MA 01730 USA [ PGP key available through http://cve.mitre.org/cve/request_id.html ] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (SunOS) iQEcBAEBAgAGBQJTFe4QAAoJEKllVAevmvmsLBQH/j4W4V0IB65G+aX9F4bUZP1i 5MCNvUuveTFzXd4NVk9kt7JWfcnZNiFeDz+KouyGG/l7K/glY/Jqo4/lLxzpDvTS s9bdXxYeCVczNmnMUmXCAK+RV6Jzpm2dLeoenQMtoGr6zsqW9UODWxADGu1XeMFG +a6ucpR/nCW3lR0nJUUYlJCpplQ+FG308RS4CR8xBC1q9VerfWPUB8ZBYxpMWPyn QzCx4jBv1lnnRjeAEc2euLMMU4QhoW1YdEUy7g7TNNW2IwvRnjwCohYhhXo8UES7 FW9FN6HL6MDbG5Wn7VcWpyQuz85/B5+uLetXGs1XUNTYvBdOY2Fg+dS3geSduqw= =DOs8 -----END PGP SIGNATURE-----
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.