This has been a very surprising discussion to me. If most CAs were asked “Do
you think CAs are supposed to investigate and revoke one of your certificates
that is reported to you for injecting malware on Relying Parties clients?”
their answer would be “Yes, of course – that’s required under the Baseline
Requirements (BRs) and related WebTrust audit requirements.” So I’m very
surprised to see some on this list say CAs have no duties at all to protect
Relying Parties, or that their duties are somehow limited to “identity” issue.
Kathleen’s list of applicable BR sections should also include BR 4.9.3:
4.9.3. Procedure for Revocation Request
"*** The CA SHALL provide Subscribers, Relying Parties, Application Software
Suppliers, and other third parties with clear instructions for reporting
suspected Private Key Compromise, Certificate misuse, or other types of fraud,
compromise, misuse, inappropriate conduct, or any other matter related to
Certificates. The CA SHALL publicly disclose the instructions through a readily
accessible online means."
1. Breakdown of BR Requirements
This is a long post, but the subject is very important.
Looking at the BR requirements quoted in Kathleen’s initial message, it’s clear
they deal with two separate processes and requirements for CAs: (a) CA’s must
follow a process to revoke certificates already issued (and perhaps do other
things, like report the subscriber to law enforcement), and (b) CAs must follow
a process for refusing to issue new certificates to a subscriber.
2. Provisions requiring a CA to revoke a certificate
Looking at (a) first as a logical workflow, here is what the BRs require a CA
to do concerning revocation of certificates already issued.
(A) Provide Relying Parties and other third parties “with clear [online]
instructions for reporting suspected Private Key Compromise, Certificate
misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or
any other matter related to Certificates.” BR 4.9.3. This is a separate
requirement from the provisions using the term “Certificate Problem Reports”.
[Why would the BRs require this unless the CA is supposed to do something about
reported misuse, fraud, inappropriate conduct, or “any other matter related to
Certificates”?]
(B) This is supplemented by new BR 4.9.2, added just three months ago, in
February 2016:
“4.9.2 Who Can Request Revocation. *** Subscribers, Relying Parties,
Application Software Suppliers, and other third parties may submit Certificate
Problem Reports informing the issuing CA of reasonable cause to revoke the
certificate.”
Note that this is pretty wide open – a relying party can request revocation of
a certificate issued to a subscriber upon any “reasonable cause.”
(C) The CA shall maintain a “continuous 24x7 ability to respond internally
to a high-priority Certificate Problem Report, and where appropriate, forward
such a complaint to law enforcement authorities, and/or revoke a Certificate
that is the subject of such a complaint.” BR 4.10.2 on Service Availability.
Note that CAs “shall” revoke a certificate and/or report to law enforcement
where appropriate.
This section uses the term Certificate Problem Report, which is defined as
“Complaint of suspected Key Compromise, Certificate misuse, or other types of
fraud, compromise, misuse, or inappropriate conduct related to Certificates.”
That is pretty broad, and ties fairly closely to the reporting language in BR
4.9.3.
(D) The process that the CA “shall” follow after receiving a “Complaint of
Certificate misuse, or other types of fraud, compromise, misuse, or
inappropriate conduct related to Certificates” is laid out with some
specificity in BR 4.9.5. This is not optional, but mandatory:
"The CA SHALL begin investigation of a Certificate Problem Report within
twenty-four hours of receipt, and decide whether revocation or other
appropriate action is warranted based on at least the following criteria:
1. The nature of the alleged problem;
2. The number of Certificate Problem Reports received about a particular
Certificate or Subscriber;
3. The entity making the complaint (for example, a complaint from a law
enforcement official that a Web site is engaged in illegal activities should
carry more weight than a complaint from a consumer alleging that she didn’t
receive the goods she ordered); and
4. Relevant legislation. ***"
Clearly the CA must investigate, make judgments, and take action (for example,
if the Web site is “engaged in illegal activities” the CA should probably act
and revoke the certificate, while if a consumer complains about missing goods
the CA probably doesn’t need to act or revoke). Once the CA has completed the
process of investigation and analysis, the CA must “decide whether revocation
or other appropriate action is warranted.”
Those who say that CAs have no duty to investigate and act after receiving
complaints covering “Certificate misuse, or other types of fraud, compromise,
misuse, or inappropriate conduct related to Certificates“ are not correct.
(E) There’s another independent requirement for revocation (BR 4.9.1.1), but
this does not limit or override the stronger provisions quoted above:
"The CA SHALL revoke a Certificate within 24 hours if one or more of the
following occurs: ***
4. The CA obtains evidence that the Certificate was misused;"
It’s not very useful to play the dictionary game, but here is the first
definition I found for the word misused: “to treat badly or abusively;
maltreat.” That seems pretty close to the string “Certificate misuse, or other
types of fraud, compromise, misuse, or inappropriate conduct related to
Certificates” used in other sections on revocation of a certificate, and it
certainly would encompass things like a website that engages in illegal
activities or injects malware on relying parties’ clients.
2. Provisions requiring a CA to follow checking procedures before issuing a
certificate
The other provisions quoted by Katherine do not relate to revocation of issued
certificates, but instead list checks that CAs must do before issuing a new
certificate and which may result in refusal to issue the new certificate.
These are separate and independent CA requirements from certificate revocation
(note that the decision whether to issue a new certificate to a subscriber
depends in part on whether the CA has previously revoked a subscriber’s
certificate).
Here are those relevant provisions:
“The CA SHALL develop, maintain, and implement documented procedures that
identify and require additional verification activity for High Risk Certificate
Requests prior to the Certificate’s approval, as reasonably necessary to ensure
that such requests are properly verified under these Requirements.” BR 4.2.1
So what are High Risk Certificate Requests? Here is the definition, broken
down by individual criteria for easier reading:
“High Risk Certificate Request: A Request that the CA flags for additional
scrutiny by reference to internal criteria and databases maintained by the CA,
which may include
[a] names at higher risk for phishing or other fraudulent usage,
[b] names contained in previously rejected certificate requests or revoked
Certificates,
[c] names listed on the Miller Smiles phishing list or the Google Safe
Browsing list, or
[d] names that the CA identifies using its own risk‐mitigation criteria.”
All certificate requests received by a CA are potentially “high risk
certificate requests” at the start – the CA will only know after running each
and every certificate request through the types of tests listed at [a] through
[d] above. Note that under BR 4.2.1 the CA is required to perform “additional
verification activity” once a high risk certificate has been identified – the
CA can’t just close its eyes and issue the certificate.
Note also that criteria [b] includes names (presumably both identity names and
domain names) contained in previously rejected requests or revoked certificates
– so certificate revocation is very important under BR 4.2.1 to the later
decision on whether to issue a new certificate to the same subscriber (or in
the same name).
3. Is “misuse” limited to “identity”?
Some postings have suggested that revocation is only required for “misuse,” and
that misuse is limited to cases where the CA made a vetting mistake and issued
a certificate to the wrong party (and/or with the wrong identity information
inside).
Clearly this is not the case – many sections of the BRs go way beyond “misuse”
and require revocation for “Certificate misuse, or other types of fraud,
compromise, misuse, or inappropriate conduct related to Certificates”. Note
that the word “identity” never shows up in any of the applicable BR sections,
although errors by the CA in issuing to the wrong party or with the wrong
information inside could clearly be one form of misuse justifying or even
requiring revocation. (I would say that revocation for improper authentication
is required by other BR sections instead, including the CA warranties section.)
4. Response to Kathleen’s questions
So here are my responses to Kathleen’s questions (representing my personal
opinion only, not those of my company).
1) What does "Certificate misuse, or other types of fraud" in the definition
of Certificate Problem Report actually mean?
[KH] See discussion above. It includes “Certificate misuse, or other types of
fraud, compromise, misuse, or inappropriate conduct related to Certificates”,
and could potentially involve “illegal activities,” “phishing or other
fraudulent usage,” and other types of bad activity that puts a subscriber on
the “Miller Smiles phishing list or the Google Safe Browsing list.” (Please
forgive all the quotation marks, but these are all mentioned in the relevant
BRs quoted above – they must mean something.)
Note that these provisions do not make CAs the Internet Police – instead, the
BRs require CAs to set up and follow procedures and make reasonable judgments
about revocation and refusal to issue. It’s not that hard to do, and most CAs
are doing it today – and their WebTrust auditors want to see that they have a
process in place and are following it.
In the past, fraudsters didn’t need to use SSL to do their work – but with the
move to “https everywhere,” soon the fraudster websites won’t work without a
certificate as the browsers require SSL to render a “normal” UI instead of a
warning. Internet security works best when everyone helps fight the fraudsters
– starting with the CAs (who can revoke or refuse to issue, thereby making it
hard or impossible for fraudsters to maintain their malware sites), and
continuing with browsers (through such features as Microsoft SmartScreen and
Google Safe Browsing - although not all users will be protected by these
features, and some bad sites may never be reported) and security software
companies. No one line of defense can block every fraudster, so it’s important
to have many lines of defense, including CAs.
2) What does "misused" mean in Section 4.9.1.1?
[KH] See my comments at (5) above – Section 4.9.1.1 is a relatively unimportant
provision, as certificate misuse is just one of 15 listed “Reasons for Revoking
a Subscriber Certificate.” Section 4.9.1.1 may function mainly to fill in that
part of RFC 3647, which lists the provisions that should be in a CA’s CPS. The
more important BR provisions on required revocation are as described at 2(A)
through (D) above, which go far beyond the word “misused”.
However, as discussed at 2(E) above, I think “misused” at 4.9.1.1 should be
interpreted as the same as “Certificate misuse, or other types of fraud,
compromise, misuse, or inappropriate conduct related to Certificates” used in
the other applicable BR sections on revocation of a certificate. There’s no
reason to limit misuse to something narrower, such as identity only.
3) If a website is using its SSL certificate to mask injection of malware
and evidence of that is presented to the issuing CA, is that sufficient misuse
for the CA to be required to revoke the certificate?
[KH] Absolutely yes. It falls within “Certificate misuse, or other types of
fraud, compromise, misuse, or inappropriate conduct related to Certificates” as
well as “illegal activities”.
How can CAs know if a subscriber site is injecting malware? In most cases they
can’t know independently (although if the subscriber website is listed with the
Anti-Phishing Working Group, Microsoft SmartScreen, Google Safe Browsing, etc.
that’s a pretty conclusive reason for refusing to issue the certificate – in
the past, CAs I have been associated with have required a subscriber to get its
name off a blacklist before we would issue a certificate).
In addition, security software companies are constantly looking for bad sites
(such as those injecting malware) and are notifying the CAs who issued the
certificate to request revocation. See, for example, the following report from
Trend Micro:
http://blog.trendmicro.com/trendlabs-security-intelligence/lets-encrypt-now-being-abused-by-malvertisers/
The TrendLabs group found two websites (later five) apparently compromised by
bad actors using a technique called “domain shadowing” who obtained
certificates for legitimate websites. The bad actors then placed their
encrypted ads on the websites that led to sites hosting the Angler Exploit Kit,
which would download a banking Trojan onto the affected user machines.
One point of the TrendLabs report is that with the increasing availability of
DV certs from many CAs, and the difficulty that security software can have in
scanning encrypted web content for malware, these types of exploits are likely
to increase. This is especially true as browsers start to require https
everywhere, which pushes fraudsters to encrypt their malware. So revocation by
CAs of certificates used to hide malware has become even more important. Why
wouldn’t a CA want to help protect users??
In cases such as this, I think the CA could confidently rely on a security
company’s research, and after requesting a response from the subscriber (that’s
basic due process), must proceed and revoke the certificate under the BRs and
add the name to its High Risk Certificate Request database so it will never
issue a certificate to the subscriber in the future.
4) Does a website who is known to an issuing CA to inject malware count as
high risk?
Yes. See discussion at Section 2 above concerning procedures that CAs must
follow for High Risk Certificate Requests and refusal to issue a certificate to
a subscriber. These requirements include checking the following types of
criteria and databases, and refusal to issue if appropriate based on the
information found by the issuing CA:
"[a] names at higher risk for phishing or other fraudulent usage,
[b] names contained in previously rejected certificate requests or revoked
Certificates,
[c] names listed on the Miller Smiles phishing list or the Google Safe
Browsing list, ***"
What can put a “name” (domain name or identity name) on one of these
blacklists? Certainly for being a website known to an issuing CA to inject
malware. Such malicious activity is very much “high risk” and should prevent a
subscriber from receiving a certificate from the CA.
5) Are CAs required to maintain a list/database to prevent issuance of SSL
certificates for websites that are known to them to inject malware?
Yes. See discussion in prior paragraph. Websites that are known for injecting
malware will end up on one or more of the blacklists listed above, which the CA
must consult before issuing a certificate to a subscriber. In addition, once a
CA revokes a certificate for a site it knows has injected malware, it must add
that subscriber to its own blacklist and refuse to issue any more certificates
in the future.
5. Conclusion
Looking at some of the prior postings on this string, I think some people are
not actually reading the BRs and WebTrust/ETSI requirements on certificate
revocation, but instead are just stating their personal opinion of what the
rules *should* be – namely, that a CA should do nothing, just issue
certificates when requested, and never revoke anything. That’s just not what
the BRs and related audit requirements say – and CAs will be tested on that by
their auditors.
While the language of the BRs could have been written better the intent is very
clear, and I don’t think the BRs need any clarification as to the necessity of
revoking a certificate known to be used for injecting malware – it must be
done. I can say this as a person who has worked with several CAs on compliance
and WebTrust audit issues over many years – this is the common interpretation
and the common practice among CAs.
If people want to remove the current BR revocation requirements for
certificates used to hide malware, they can ask to amend the BRs to strip out
the current revocation provisions, but the proposal is unlikely to pass – most
CAs think they have an important role to play in fighting malware injection and
other types of certificate misuse.
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
