[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
