mailing list archives
Re: CVE Request?: konqueror - https uses all ciphers, even weak ones
From: cve-assign () mitre org
Date: Thu, 13 Mar 2014 20:43:26 -0400 (EDT)
-----BEGIN PGP SIGNED MESSAGE-----
It sounds to me like you're saying you're OK with placing at least
some of these cases into group 2 or 3.
No, our previous message wasn't trying to comment on that, one way or
the other. We were simply arguing against
error-message-and-refusal-to-connect as the universally optimal UI
behavior upon having an SSL handshake arrive at a 40-bit cipher suite.
If the browser is capable of showing either a closed lock or an open
lock, and still allow use of SSL in both of those cases, we're not
suggesting that the closed lock is optimal.
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?
It still seems to be an opportunity for security improvement. Consider
these two cases:
A. I use Konqueror to connect to a shopping web site from a network
that likely has sniffers. The shopping web site has a bug that
occasionally causes it to agree to only 40-bit cipher suites. In
this case, I would prefer that Konqueror not use 40 bits.
B. I own some EOL'd networked outdoor video cameras that can't be
patched or replaced. They have a bug that occasionally causes
them to agree to only 40-bit cipher suites. In this case, I would
prefer that Konqueror use 40 bits.
There's no uniform answer about what Konqueror should do, so it's
difficult to consider A a vulnerability. The opportunity for security
improvement is that Konqueror could track the observed bit counts, and
ask the user "This site is normally 128 bits. Today it's 40 bits. Do
you really want to proceed? Just this one time, or every time this
happens for this specific site?" (This assumes that a wording exists
that users would understand.)
This security improvement might be unrealistic because there are no
known bugs that cause an intermittent maximum of 40 bits.
A better example is certificate pinning:
A. This site is normally verified by Google Internet Authority G2.
Today it is verified by OppressiveNationState Root CA. Do you
really want to proceed?
B. This site is normally verified by Google Internet Authority G2.
Today it is verified by YourCompanyITDepartmentMandatoryHTTPSProxy
Root CA. Do you really want to proceed?
In other words, we feel that this needs to be modified slightly:
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
The Konqueror user experience is "if the UI says https, it is https,
but that may or may not be especially meaningful." Because certificate
pinning isn't widely deployed, the experience of most web users
nowadays is "if the UI says https, it is https, but that may or may
not be especially meaningful." Addressing either case is best
interpreted as a security improvement, not a vulnerability fix.
CVE assignment team, MITRE CVE Numbering Authority
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)
-----END PGP SIGNATURE-----