Date: Thu, 13 Mar 2014 20:43:26 -0400 (EDT) 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 > 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 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) iQEcBAEBAgAGBQJTIk9+AAoJEKllVAevmvms8cwIAMAbM0u4PpFxiH/tlqWhNfUx fukAZpTats9wdhjKFkXON6w7mchU1StCLwbRIQsaIHHtLmIUb3ytmrXPnFRtxveY ygMqo7qx9ypZrhAfXSj11WlSa2d9/I1Fp+S76hPMIjubYAwOaortNu7ds5QUt/kk qVrv/iKFvr7xaJdzoZbTQL7GjR5vEvieeSVK6zPeJ5ugd22XHovwz6jqnsZy318Q n71ORL6ZCC+qyl9sS0hbcJ2Uw7PTEyBlwjSvkrk9hCUis7A7+axWmNgz5jEjjQnY PNuOuNfXMa5DOkxK7F64G5SKcmSKQCuBcmRYp8P9A8DRUEIbYrwyKlkNvLZwGmY= =rl1y -----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.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ