CWE-296: Improper Following of a Certificate's Chain of Trust
Weakness ID: 296
Abstraction: Base Structure: Simple
The software does not follow, or incorrectly follows, the chain of trust for a certificate back to a trusted root certificate, resulting in incorrect trust of any resource that is associated with that certificate.
If a system does not follow the chain of trust of a certificate to a root server, the certificate loses all usefulness as a metric of trust. Essentially, the trust gained from a certificate is derived from a chain of trust -- with a reputable trusted entity at the end of that list. The end user must trust that reputable source, and this reputable source must vouch for the resource in question through the medium of the certificate.
In some cases, this trust traverses several entities who vouch for one another. The entity trusted by the end user is at one end of this trust chain, while the certificate-wielding resource is at the other end of the chain. If the user receives a certificate at the end of one of these trust chains and then proceeds to check only that the first link in the chain, no real trust has been derived, since the entire chain must be traversed back to a trusted source to verify the certificate.
There are several ways in which the chain of trust might be broken, including but not limited to:
Any certificate in the chain is self-signed, unless it the root.
Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate.
An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions.
The root certificate has been compromised or authorized to the wrong party.
The table(s) below shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.
Relevant to the view "Research Concepts" (CWE-1000)
The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the software life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.
Architecture and Design
REALIZATION: This weakness is caused during implementation of an architectural security tactic.
The listings below show possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.
The table below specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.
Technical Impact: Hide Activities
Exploitation of this flaw can lead to the trust of data that may have originated with a spoofed source.
Integrity Confidentiality Availability Access Control
Technical Impact: Gain Privileges or Assume Identity; Execute Unauthorized Code or Commands
Data, requests, or actions taken by the attacking entity can be carried out as a spoofed benign entity.
Likelihood Of Exploit
This code checks the certificate of a connected peer.
Example Language: C
if ((cert = SSL_get_peer_certificate(ssl)) && host)
if ((X509_V_OK==foo) || X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN==foo))
// certificate looks good, host can be trusted
In this case, because the certificate is self-signed, there was no external authority that could prove the identity of the host. The program could be communicating with a different system that is spoofing the host, e.g. by poisoning the DNS cache or conducting a man-in-the-middle attack.
Cryptographic API, as used in web browsers, mail clients, and other software, does not properly validate Basic Constraints.
Phase: Architecture and Design
Ensure that proper certificate checking is included in the system design.
Understand, and properly implement all checks necessary to ensure the integrity of certificate trust integrity.
This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.
Failure to follow chain of trust in certificate validation
[REF-245] Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh
and Vitaly Shmatikov. "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software". 2012-10-25.
[REF-44] Michael Howard, David LeBlanc
and John Viega. "24 Deadly Sins of Software Security". "Sin 23: Improper Use of PKI, Especially SSL." Page
347. McGraw-Hill. 2010.