We've been having trouble getting the -05 version of the threat analysis
posted, so
my message about the changes that have been incorporated is a bit premature.
Here is the modified text:
*Introduction, page 4:*
Certificate Revocations Lists (CRLs) [RFC5280] are the primary meansof
certificate revocation established by IETF standards.Unfortunately,
most
browsers do not make use of CRLs to check therevocation status of
certificates
presented by a TLS Server(Subject). Some browsers make use of Online
Certificate StatusProtocol (OCSP) data [RFC6960] as a
standards-based alternative
toCRLs. If a certificate contains an Authority Information Access
(AIA )
extension [RFC5280], it directs a replying party to an OCSP server to
which a request can be directed. This extension also may be used by a
browser to request OCSP responses from a TLS server with which it is
communicating [RFC6066, RFC6961].
RFC 5280 does not require inclusion of an AIA extension in
certificates,
so a browser cannot assume that this extension will be present. The
Certification Authority and Browser Forum (CABF) baseline
requirements and
extended validation guidelines do mandate inclusion of this
extension in EE
certificates (in conjunction with their certificate policies). (See
https://cabforum.org for the most recent versions of these policies.)
In addition to the revocation status data dissemination mechanisms
specified
by IETF standards, most browser vendors employ proprietary means of
conveying certificate revocation status information to their products,
e.g.,
via a blacklist that enumerates revoked certificates (EE or CA).Such
capabilities enable a browser vendor to cause browsers toreject any
certificates on the blacklist. This approach also can be employed to
remedy mis-issuance.Throughout the remainder of this document
references to
certificaterevocation as a remedy encompass this and analogous forms of
browser behavior, if available. Note: there are no IETF standards
that define
browser blacklist mechanisms.
3.2.1.1.1. Self-monitoring Subject
< add a second paragraph>
A malicious CA might revoke a bogus certificate to avoid having browser
vendors take punitive action against the CA and/or to persuade them
to not
enter the bogus certificate on a vendor-maintained blacklist.
However, the CA
might provide a “good” OCSP response (from a server it operates) to
a targeted
user (browser instance) as a way to circumvent the remediation
nominally offered
by revocation. No component of CT is tasked with detecting this sort
of misbehavior
by a CA. (The misbehavior is analogous to a log offering split views
to different
clients. The Audit element of CT is tasked with detecting this sort
of attack.)
3.2.1.1.2. Benign third party Monitor
If a benign third party monitor is checking the logs to which
acertificate was
submitted and is protecting the targeted Subject, itwill detect the
bogus certificate
and will alert the Subject. TheSubject will then ask the CA to
revoke the bogus
certificate. As in3.2.1.1.1, the CA may or may not revoke the
certificate and it
might revoke the certificate but provide “good” OCSP responses to a
targeted user
(browser instance).
--------
3.3 Malicious, Colluding CAs
Section 3.2 examined attacks in which a single CA might issue a bogus
certificate. There is also the potential that two or more CAs might
collude to issue a bogus certificate in a fashion designed to foil the
remediation (but not detection) safeguards envisioned by CT. Their goal
would be trick a CT-aware browser into accepting a bogus certificate
because it was accompanied by a valid SCT, while evading certificate
revocation status indications. This section explores such scenarios.
In this attack two CAs that do not share a common path to a trust
anchor, collude to create a “doppelganger” (bogus) EE certificate. The
attack need not be initiated by trust anchors; any subordinate pair of
(not name-constrained) CAs can effect this attack without the knowledge
of superiors CAs (which are presumed to be benign). The two CAs must
have the same Subject name and the same public key for the attack. (RFC
5280 doe not explicitly preclude the creation of two CAs with the same
name, so long as the parent CAs are distinct. Requirements for Subject
name uniqueness apply individually to each CA but not across CA
boundaries, as per Section 4.2.1.6. However, the Security Considerations
section of RFC 5280 warns that name collisions could cause security
problems.)
Because the two CAs have the same name and make use of the same key,
each can issue the (bogus) doppelganger certificates. One of the CAs
would log the certificate and acquire an SCT for it, while the other
would not.
Because the bogus certificate is logged, it is subject to detection as
such by a Monitor. Once the bogus certificate is detected it is
anticipated that action will be taken to render it invalid. The bogus
certificate itself might be revoked by the CA that issued and logged it,
an action that masks the malicious intent of that CA. A browser vendor
might add the bogus certificate to a blacklist maintained by the vendor,
e.g., because the CA failed to revoke the bogus certificate.
If the CA that logged the bogus certificate is suspected of being
malicious, e.g., because it has a history of using bogus certificates,
the certificate of that CA might itself be revoked. This revocation
might be effected by the parent of that CA (which is not complicit), or
by a browser vendor using a blacklist. Whether the proposed attack can
achieve its goal depends on which revocation mechanism is employed, and
which certificate or certificates are revoked.
3.3.1 Revocation of the Bogus Certificate
If the bogus (EE) certificate is revoked by the CA that issued and
logged it, browsers should treat that certificate as invalid. However, a
browser checking a CRL or OCSP response might not match this revocation
status data against the doppelganger issued by the second CA. This is
because revocation status checking is performed in the context of a
certification path (during path validation). The doppelgangers have
different certification paths and thus the revocation status data for
each might be acquired and managed independently. (RFC 5280 does not
provide implementation guidance for management of revocation data. It is
known that some relying party implementations maintain such information
on a per-certificate path basis, but others might not.)
Even if the bogus certificates contain an AIA extension pointing to an
OCSP server the attack might still succeed. (As noted in the Section 1,
RFC 5280 does not mandate inclusion this extension, but its presence is
required by CABF requirements.) As noted in Section 3.2.1.1.1, a
malicious CA could send a “good” OCSP response to a targeted browser
instance, even if other parties are provided with a “revoked” response.
Also note that a TLS server can supply an OCSP response to a browser as
part of the TLS handshake [RFC6961], if requested by the browser. A TLS
server posing as the entity named in the bogus certificate could acquire
a “good” OCSP response from the colluding CAs to effect the attack. Only
if the browser relies upon a trusted, third-party OCSP responder, one
not part of the collusion, would the attack fail.
The analysis above also applies to the use of CRLs to disseminate
certificate revocation status data. The doppelganger certificate could
contain a CRL distribution point extension instead of an AIA extension.
In that case a site supplying CRLs for the colluding CAs could supply
different CRLs to different requestors, in an attempt to hide the
revocation status of the doppelganger from targeted browsers instances.
This is analogous to a split-view attack effected by a CT log. However,
as noted in Section 3.2.1.1 and 3.2.1.1.1, no element of CT is
responsible for detecting inconsistent reporting of certificate
revocation status data. (Monitoring in the CT context tracks log entries
made by CAs or Subjects. Auditing is designed to detect misbehavior by
logs, not by CAs per se.)
If the CA that logged the certificate does not revoke it, a browser
vendor might enter the bogus certificate into a “blacklist”.
Unfortunately, there are no IETF standards for such blacklists. Thus it
is conceivable that the revocation status data also might be managed in
a path-specific fashion. If that were true, then the attack could
succeed. However, if a vendor maintains revocation status data in a
path-independent fashion, then the attack will fail. For example, if
revoked certificates are identified by CA name and serial number, or a
hash of the certificate, this attack would fail.
3.2.2 Revocation of the Colluding CA Certificate
If the CA that logged the bogus certificate is viewed as acting
maliciously, its parent might revoke that CA’s certificate. Even though
the two colluding CAs have the same name and use the same public key,
their certificates are distinct, e.g., they were issued by different
parents and almost certainly have different certificate serial numbers.
Thus revocation of the certificate of the CA that logged the bogus
certificate does not affect the certificate of its colluding partner. In
this case, the bogus EE certificate would be treated as valid when it
appears in a certification path involving the second colluding CA. Thus
revocation the certificate for the CA that was detected as malicious
does not prevent this attack from succeeding.
A vendor also might choose to add the certificate of the CA that issued
the bogus certificate to its blacklist, e.g., if that CA refuses to
revoke the bogus certificate. This also may not prevent the bogus
certificate from being accepted by a browser. For example, if the CA
certificate blacklist entry is analogous to a CRL entry (Subject name of
the parent of the malicious CA and the serial number of the malicious
CA’s certificate), the colluding CA’s certificate would still be valid
in this case.
-------
3.4 Undetected Compromise of CAs or Logs
Sections 3.1 and 3.2 examined attacks in the context of non-malicious
and malicious CAs, and benign and misbehaving logs. Another class of
attacks might occur in the context of a non-malicious CA and/or a benign
log. Specifically these CT elements might be compromised and the
compromise might go undetected. Compromise of CAs and logs was noted in
Section 2, as was coercion of a CA. As noted there, a compromised CA is
essentially a malicious CA, and thus the discussions in Section 3.2 are
applicable. The case of an undetected compromise warrants some
additional discussion, since some relying parties may see signed objects
issued by the legitimate (non-malicious) CA, others may see signed
objects from its compromised counterpart, and some may see objects from
both. In the case of a compromised CA or log the adversary is presumed
to have access to the private key used by a CA to sign certificates, or
used by a log to sign SCTs and STHs. Because the compromise is
undetected, there will be no effort by a CA to have its certificate
revoked or by a log to shut down the log.
3.4.1 Compromised CA, Benign Log
In the case of a compromised (non-malicious) CA, an attacker uses the
purloined private key to generate a bogus certificate (that the
compromised CA would not issue). If this certificate is submitted to a
(benign) log, then it subject to detection by a Monitor, as discussed in
3.1.1.1. If the bogus certificate is submitted to a misbehaving log,
then an SCT can be generated, but there will be no entry for it, as
discussed in 3.1.1.2. If the bogus certificate is not logged, then there
will be no SCT, and the implications are as described in 3.1.2.
This sort of attack may be most effective if the CA that is the victim
of the attack has issueda certificate for the targeted Subject. In this
case the bogus certificate will then have the same certification path as
the legitimate certificate, which may help hide the bogus certificate.
However, means of remedying the attack are independent of this aspect,
i.e., revocation canbe effected irrespective of whether the targeted
Subject received its certificate from the compromised CA.
A compromised (non-malicious) CA may be able to revoke the bogus
certificate if it is detected by a Monitor, and the targeted Subject has
been notified. It can do so only when the serial number of the bogus
certificate is made known to this CA. Also, the bogus certificatecannot
have been issued with an Authority Information Access (AIA) or CRL
Distribution Point (CRL DP) extension that enables only the malicious
twin to revoke the certificate. (The AIA extension in the bogus
certificate could be used to direct relying parties to an OCSP server
controlled by the malicious twin. The CRL DP extension could be used to
direct relying parties to a CRL controlled by the malicious twin.) If
the bogus certificate contains either extension, the compromised CA
cannot effectively revoke it, but it will also be apparent that the
bogus certificate was issued by the malicious twin. (The AIA or CRL DP
extension would provide a strong indication that the bogus certificate
was not generated by the compromised CA itself.)
If the serial number of the bogus certificate is the same as for a
valid, not-expired certificate issued by the CA (to the target or to
another Subject), then revocationposes a problem. This is because
revocation of the bogus certificate will also invalidate a legitimate
certificate. This problem may cause the compromised CA to delay
revocation, thus allowing the bogus certificate to remain a danger for a
longer time.
The compromised CA may not realize that the bogus certificate was issued
by a malicious twin; one occurrence of this sort might be regarded as an
error, and not cause the CA to transition to a new key pair. (This
assumes that the bogus certificate does not contain an AIA or CRL DP
extension that wrests control of revocation from the compromised CA.) If
the compromised CA does determine that its private key has been stolen,
it may take some time to transition to a new key pair, and reissue
certificates to all of its legitimate Subjects. Thus an attack of this
sort may take a while to be remedied.
Also note that the malicious twin of the compromised CA may be capable
of issuing its own CRL or OCSP responses, without changing any AIA/CRL
DP data present in the targeted certificate. The revocation status data
from the evil twin will appear as valid as those of the compromised CA.
If the attacker has the ability to control the sources of revocation
status data available to a targeted user (browser instance), then the
user may not become aware of the attack.
A bogus certificate issued by the malicious CA will not match the SCT
for the legitimate certificate, since they are not identical, e.g., at a
minimum the private keys do not match. Thus a CT-aware browser that
rejects certificates without SCTs (see 3.1.2.2) will reject a bogus
certificate created under these circumstances if it is not logged. If
the bogus certificate is detected and logged, browsers that require an
SCT will reject the bogus certificate.
3.4.2 Benign CA, Compromised Log
A benign CA does not issue bogus certificates, except as a result of an
accident or attack. So, in normal operation, it is not clear what
behavior by a compromised log would yield an attack. If a bogus
certificate is issued by a benign CA (under these circumstances) is
submitted to a compromised (non-malicious) log, then both an SCT and a
log entry will be created. Again, it is not clear what additional
adverse actions the compromised log would perform to further an attack
on CT.
3.4.3 Compromised CA, Compromised Log
As noted in 3.4.1, an evil twin CA may issue a bogus certificate that
contains the same Subject name as a legitimate certificate issued by the
compromised CA. Alternatively, the bogus certificate may contain a
different name but reuse a serial number from a valid, not revoked
certificate issued by that CA.
The evil twin CA might submit a bogus certificate to the evil twin of a
compromised log. The operator of the evil twin log can use the purloined
private key to generate SCTs for certificates that have not been logged
by its legitimate counterpart. These SCTs will appear valid relative to
the public key associated with the legitimate log. However, an STH
issued by the legitimate log will not correspond to a tree containing
these SCTs. Thus thorough checking of the SCTs issued by the evil twin
log will identify this discrepancy.
An Auditor checking for log consistency might conclude that the
compromised log is acting maliciously, and is presenting a split view to
its clients. In this fashion the compromised log may be shunned and
forced to shut down. However, if an attacker targets a set of TLS
clients that do not have access to the legitimate log, they may not be
able to detect this inconsistency. In this case CT would need to rely on
a distributed gossiping audit mechanism to detect the compromise (see
Section 5.6).
In general, this sort of attack is analogous to a malicious CA creating
a bogus certificate and receiving an SCT (with no log entry) from a
misbehaving log (Section 4.2.1.2). The lack of a log entry prevents
detection of the bogus certificate by Monitors, and the presence of the
SCT prevents rejection by a CT-aware browser that accepts SCTs from the
compromised log.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
