Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 20 Sep 2016 15:11:58 -0400 (EDT)
Subject: Re: Possible CVE for TLS protocol issue

Hash: SHA256


Our initial thought is that the essence of the issue is stated very
near the end of section 5.3 of the
document: "can derive the same master secret MS just by engaging in
the exact same computation." We are not sure whether it makes sense to
assign a CVE ID to a mathematical fact of that form. The vulnerability
seems to be that the TLS protocol definition allows rsa_fixed_dh,
dss_fixed_dh, rsa_fixed_ecdh, and ecdsa_fixed_ecdh, but protocol
documentation such as RFC 5246 Appendix F does not explicitly point
out the severity of the outcome when any arbitrary installed client
certificate is compromised. It does, for example, say "For TLS to be
able to provide a secure connection, both the client and server
systems, keys, and applications must be secure," but it doesn't
delineate the level of connection insecurity that results from a
seemingly minor client insecurity.

Use CVE-2015-8960 for this vulnerability in the TLS documentation.

It is possible that other issues described in the
woot15-paper-hlauschek.pdf paper, such as issues related to handling
of key usage extensions, need their own separate CVE IDs.

In addition, as suggested by section 5.2, a product that originally
shipped with a compromised client certificate should, in many cases,
be considered a vulnerable product, regardless of whether that client
certificate has any known use for authenticating a client. We don't
know whether there are a huge number of products that have, for
example, installed test client certificates. Our initial thought is
that there should be a unique CVE ID for any product that satisfies
these criteria:

 - when the product was shipped, a default or recommended
   configuration had an installed client certificate and associated
   secret key that were both known to the general public (e.g., they
   were known by anyone who had a copy of the product)

 - the product can be used in a KCI attack, e.g., it meets all of the
   requirements of section 5.1.1

 - the product could realistically be expected to need secure
   communication with a server for which a certificate exists, from a
   commonly recognized Certification Authority, meeting the
   requirements of section 5.1.2 (e.g., this would often exclude a
   product that can establish TLS sessions only to a server operated
   by the vendor)

Post-shipment compromise of a client certificate's secret key is
currently outside the scope of CVE. The vulnerable behavior is
releasing a product where a client certificate is installed and its
secret key is already publicly documented.

Third-party suggestions for improving warning messages for
client-certificate installation are also currently outside the scope
of CVE. Although it might be nice for some products to have a warning
of "Are you completely sure that you want to install this client
certificate because no unauthorized party knows the secret key?" (or
similar), we don't want to have free-for-all CVE ID assignment. For
now, we'll let vendors have CVE IDs if they decide their existing
certificate-installation dialog is a security problem and they compose
a better dialog warning that's understandable by their customers.

- -- 
CVE Assignment Team
M/S M300, 202 Burlington Road, Bedford, MA 01730 USA
[ A PGP key is available for encrypted communications at ]
Version: GnuPG v1


Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ