SSL Certs for Malicious Websites

[Kathleen Wilson]

All,

I have been receiving questions about the following items in the CA/Browser Forum Baseline Requirements, and I would appreciate your input on what the answers are or should be.

== In the Baseline Requirements ==

Definitions:

Certificate Problem Report: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates.

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 names at higher risk for phishing or other fraudulent usage, names contained in previously rejected certificate requests or revoked Certificates, names listed on the Miller Smiles phishing list or the Google Safe Browsing list, or names that the CA identifies using its own risk‐mitigation criteria.

Section 4.2.1:
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.

Section 4.9.1.1:
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;

Section 4.9.2:
Additionally, 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.

Section 4.9.5:
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.

Section 4.10.2:
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.

== Questions ==
1) What does "Certificate misuse, or other types of fraud" in the definition of Certificate Problem Report actually mean?
2) What does "misused" mean in Section 4.9.1.1?
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?
4) Does a website who is known to an issuing CA to inject malware count as high risk?
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?
==

As always, I will appreciate your thoughtful and constructive input on these questions.

Thanks,
Kathleen

[Peter Bowen]

(Top posting to bring the questions to the top)

> 1) What does "Certificate misuse, or other types of fraud" in the definition of Certificate Problem Report actually mean?
> 2) What does "misused" mean in Section 4.9.1.1?

I think there are a several of different things that could fall within
"misuse or fraud". For example:

- The certificate is being used for a purpose outside of that
contained in the certificate, for example taking advantage of a bug in
a certificate validation library to use a server authentication
certificate for code signing

- The Applicant for the certificate provided fraudulent information in
order to receive the certificate, for example claiming to be an
employee or authorized agent of a company with whom they have no
relationship

> 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?
> 4) Does a website who is known to an issuing CA to inject malware count as high risk?
> 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?

Some CAs may choose to not issue to sites known to inject malware, but
this outside the scope of the SSL requirements. The EV Guidelines it
very clear that the reputation and actions of the Subject are not in
scope:

"EV Certificates focus only on the identity of the Subject named in
the Certificate, and not on the behavior of the Subject. As such, an
EV Certificate is not intended to provide any assurances, or otherwise
represent or warrant:
(1) That the Subject named in the EV Certificate is actively engaged
in doing business;
(2) That the Subject named in the EV Certificate complies with applicable laws;
(3) That the Subject named in the EV Certificate is trustworthy,
honest, or reputable in its business dealings;
(4) That it is “safe” to do business with the Subject named in the EV
Certificate."

The definition of "High Risk" explicitly leaves it up to the CA to
determine what criteria are used. A CA might, for example, consider
requests for popular websites to be high risk due to frequent requests
from unauthorized Applicants for their domains. Alternatively a CA
might consider hostnames that appear to be algorithmically generated
from IP addresses.

The EV Guidelines themselves explain why it is valuable to encourage
all sites to use certificates issued by a third party:

"By providing more reliable third-party verified identity and address
information regarding the business, EV Certificates may help to [...]
Assist law enforcement organizations in their investigations of
phishing and other online identity fraud, including where appropriate,
contacting, investigating, or taking legal action against the
Subject."

This makes is clear it is highly valuable to have CAs issue
certificates to websites irrespective of content.

Thanks,
Peter

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Richard Wang]

There are a good malware test site that WoSign used: https://www.virustotal.com/en/.
If WoSign receive report for malware, we test this URL in this site, if the test result is negative, then we will revoke the SSL or code signing that signed malware.


Best Regards,

Richard

[Richard Z]

On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:

> Some CAs may choose to not issue to sites known to inject malware, but
> this outside the scope of the SSL requirements. The EV Guidelines it
> very clear that the reputation and actions of the Subject are not in
> scope:

knowingly issuing/tolerating certificates for sites known to inject
malware is
* contrary to user expectaions
* possible case of criminal felony and a liablility issue

So irrespective of what EV Guidelines say there may be other common
sense reasons to require revocation of such certificates and I would
not want Mozilla to underbid the already minimalistic security
promise of TLS.

Having an identity established by EV is nice but in most cases of
malware attacks the user has no chance to examine this identity if
the attack comes in an injected iframe.

Richard

--
Name and OpenPGP keys available from pgp key servers

[Kurt Roeckx]

On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:

> "By providing more reliable third-party verified identity and address
> information regarding the business, EV Certificates may help to [...]
> Assist law enforcement organizations in their investigations of
> phishing and other online identity fraud, including where appropriate,
> contacting, investigating, or taking legal action against the
> Subject."
>
> This makes is clear it is highly valuable to have CAs issue
> certificates to websites irrespective of content.

This makes perfect sense to me for EV certificates. What about
DV?


Kurt

[Rob Stradling]

On 16/05/16 01:43, Peter Bowen wrote:
<snip>

> Some CAs may choose to not issue to sites known to inject malware, but
> this outside the scope of the SSL requirements. The EV Guidelines it
> very clear that the reputation and actions of the Subject are not in
> scope:

Peter, I'd just like to point out that the EVGs also say (emphasis mine):
"The Guidelines describe an integrated set of technologies, protocols,
identity proofing, lifecycle management, and auditing practices
specifying the *minimum requirements* that must be met in order to issue
and maintain Extended Validation Certificates (“EV Certificates”)
concerning an organization."

This discussion should consider what's best for Mozilla's users.
Perhaps that aligns precisely with the minimum requirements in the EVGs,
or perhaps it doesn't. Mozilla are free to specify additional
requirements if they feel the need to do so, just as Microsoft did
recently...

https://aka.ms/rootcert
"If Microsoft, it its sole discretion, identifies a DV Server
Authentication certificate is being used to promote malware or unwanted
software, Microsoft will contact the responsible CA and request that it
revoke the certificate. The CA must either revoke the certificate within
a commercially-reasonable timeframe, or it must request an exception
from Microsoft within two (2) business days of receiving Microsoft’s
request. Microsoft may either grant or deny the exception at its sole
discretion. In the event that Microsoft does not grant the exception,
the CA must revoke the certificate within a commercially-reasonable
timeframe not to exceed two (2) business days."

[Please note: In this post I have not actually offered any opinions,
either my own or those of my employer, on the questions that Kathleen
asked at the beginning of this thread]

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Peter Bowen]

On Mon, May 16, 2016 at 6:06 AM, Rob Stradling <rob.st...@comodo.com> wrote:
> On 16/05/16 01:43, Peter Bowen wrote:
>
> This discussion should consider what's best for Mozilla's users. Perhaps
> that aligns precisely with the minimum requirements in the EVGs, or perhaps
> it doesn't. Mozilla are free to specify additional requirements if they
> feel the need to do so, just as Microsoft did recently...

Maybe I misunderstood the original email from Kathleen, but my
impression was that she was looking purely for clarification of what
is already required by the CA/Browser Forum Baseline Requirements. As
you point out Mozilla can adopt additional requirements as part of the
Mozilla CA Certificate Policy, but I think that is a different
discussion. In order to have that discussion, one needs to understand
what is already required by the Policy, and that is what I was
addressing.

Thanks,
Peter

[Gervase Markham]

On 16/05/16 01:13, Kathleen Wilson wrote:
> 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?

Counter-question to many of these: who defines what is malware, and who
made them king?

> 4) Does a website who is known to an issuing CA to inject malware count as high risk?

Well, the definition of High Risk has a clause which basically says that
the CA can define High Risk, so you'd have to ask the CA :-) But I'd say
no, because the fact that they do this doesn't make them at greater risk
for someone impersonating _them_.

Gerv

[Kathleen Wilson]

> > This discussion should consider what's best for Mozilla's users. Perhaps
> > that aligns precisely with the minimum requirements in the EVGs, or perhaps
> > it doesn't. Mozilla are free to specify additional requirements if they
> > feel the need to do so, just as Microsoft did recently...
>
> Maybe I misunderstood the original email from Kathleen, but my
> impression was that she was looking purely for clarification of what
> is already required by the CA/Browser Forum Baseline Requirements. As
> you point out Mozilla can adopt additional requirements as part of the
> Mozilla CA Certificate Policy, but I think that is a different
> discussion. In order to have that discussion, one needs to understand
> what is already required by the Policy, and that is what I was
> addressing.
>

My original email was regarding the current state of the BRs, and I would like to clarify what current requirements are. However, I think it is reasonable for this discussion to progress into whether or not the BRs and/or Mozilla policy need to be updated to address the questions.

I am wondering if the BRs need to be updated to:
+ Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
+ Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.

In regards to Mozilla policy, maybe we should consider adding text about Mozilla's expectations for CAs when they find out that a TLS/SSL certificate that they issued is being used to do bad things. I've added a link to this discussion to
https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_Currently_in_Discussion

Thanks,
Kathleen

[Rob Stradling]

On 16/05/16 17:20, Kathleen Wilson wrote:
>>> This discussion should consider what's best for Mozilla's users. Perhaps
>>> that aligns precisely with the minimum requirements in the EVGs, or perhaps
>>> it doesn't. Mozilla are free to specify additional requirements if they
>>> feel the need to do so, just as Microsoft did recently...
>>
>> Maybe I misunderstood the original email from Kathleen, but my
>> impression was that she was looking purely for clarification of what
>> is already required by the CA/Browser Forum Baseline Requirements. As
>> you point out Mozilla can adopt additional requirements as part of the
>> Mozilla CA Certificate Policy, but I think that is a different
>> discussion. In order to have that discussion, one needs to understand
>> what is already required by the Policy, and that is what I was
>> addressing.
>

> My original email was regarding the current state of the BRs, and I would like to clarify what current requirements are.

ISTM that the current state of the BRs is that "misuse" is inadequately
defined.

Some groups of people will tell you that CAs MUST revoke certs for sites
that are deemed to have served malware, whilst other groups of people
will tell you that this absolutely isn't a requirement.

> However, I think it is reasonable for this discussion to progress into whether or not the BRs and/or Mozilla policy need to be updated to address the questions.

I think the discussion must progress in that manner, or else we'll be
arguing this point forever. Good luck trying to achieve consensus though!

> I am wondering if the BRs need to be updated to:
> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.
>
> In regards to Mozilla policy, maybe we should consider adding text about Mozilla's expectations for CAs when they find out that a TLS/SSL certificate that they issued is being used to do bad things. I've added a link to this discussion to
> https://wiki.mozilla.org/CA:CertificatePolicyV2.3#Proposed_Changes_Currently_in_Discussion
>
> Thanks,
> Kathleen

[Matt Palmer]

On Mon, May 16, 2016 at 09:20:40AM -0700, Kathleen Wilson wrote:
> In regards to Mozilla policy, maybe we should consider adding text about
> Mozilla's expectations for CAs when they find out that a TLS/SSL
> certificate that they issued is being used to do bad things.

Mozilla should expect that CAs will do nothing when they find out that a
TLS/SSL certificate that they issued is being used to do "bad things" (for
values of "bad things" that do not subvert the PKI ecosystem itself). The
purpose of a CA is to attest as to *identity*, not *activity*. We have
other, more effective, mechanisms for dealing with bad actors.

- Matt

[Matt Palmer]

On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote:
> On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:
>

> > Some CAs may choose to not issue to sites known to inject malware, but
> > this outside the scope of the SSL requirements. The EV Guidelines it
> > very clear that the reputation and actions of the Subject are not in
> > scope:
>

> knowingly issuing/tolerating certificates for sites known to inject
> malware is
> * contrary to user expectaions

[Citation needed]

> * possible case of criminal felony and a liablility issue

[Citation needed]

- Matt

[Charles Reiss]

Do you think revoking certificate from malware-injecting sites would
have or has had meaningful effects on the security received by users?

I'd note that, even with OCSP hard-fail (not default), revocation takes
at least the duration of OCSP response validity to reliably take effect,
often 1 week.

Even if it did not, CAs seem to be in a very poor position to evaluate
whether sites are serving malware (compared to, say, browser vendors who
run programs like the Google Safe Browsing list) or to have nuanced
responses to tricky cases, like shared web hosts or advertising networks
who have some customers which are serving malware.

[Peter Gutmann]

Matt Palmer <mpa...@hezmatt.org> writes:
>On Mon, May 16, 2016 at 02:22:08PM +0200, Richard Z wrote:

>> knowingly issuing/tolerating certificates for sites known to inject
>> malware is
>> * contrary to user expectaions
>

>[Citation needed]

So you're saying users expect CAs to certify malware sites?

(There have been plenty of user studies showing that users expect the padlock
to protect them from malware, hackers, and all sorts of other stuff. Please
produce a study showing that users expect CAs to certify malware sites and
virus authors).

Peter.

[Hubert Kario]

then users expect impossible

Go to Firefox and check what the connection information dialog says.
Does it say that the party you're communicating with is trustworthy?

CAs certify identity, always had, and unless they themselves start
hosting those websites, they have no way to certify trustworthiness of
the data served.
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

[Peter Gutmann]

Hubert Kario <hka...@redhat.com> writes:

>then users expect impossible

Users expect CAs to be something other than certificate vending machines. The
fact that CAs fail to do this is a problem with browser PKI and CAs, not with
users.

(There have been numerous cases of security people reporting CA-certified
phishing and malware sites to the CAs that did it. The general response has
been "not our problem, they paid their money and we gave them a cert". So
even if you tell the CA, they're likely not going to fix it).

Peter.

[Hubert Kario]

problem is, that this is a slippery slope. What's malware for one person
is a research subject for another. What's inflammatory or misleading
information for one person is parody and joke material to other. What's
illegal in one jurisdiction is completely legal and normal or at least
socially acceptable behaviour in another.

Remember, the web audience spans continents and vastly different
cultures.

Asking CAs to police such space is asking for trouble.

[Jernej Simončič]

On Tue, 17 May 2016 12:51:53 +0200, Hubert Kario wrote:

> problem is, that this is a slippery slope. What's malware for one person
> is a research subject for another. What's inflammatory or misleading
> information for one person is parody and joke material to other. What's
> illegal in one jurisdiction is completely legal and normal or at least
> socially acceptable behaviour in another.

I've had problems in the past because files that I host consistently
trigger antivirus warnings, despite being harmless (examples: GIMP
installer for Windows, debug data for GIMP and wget, netcat for Windows).
Luckily, the worst that came from it were some e-mail exchanges and a
lengthy phonecall with my ISP, but I know of people who lost their hosting
thanks to having files that were similarly triggering false antivirus
alerts.

--
begin .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end

[Nick Lamb]

On Tuesday, 17 May 2016 04:19:57 UTC+1, Peter Gutmann wrote:
> So you're saying users expect CAs to certify malware sites?

I'm a user, and that's what I expect, so trivially yes.

[Kathleen Wilson]

On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote:
> I am wondering if the BRs need to be updated to:
> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.
>

Would someone please volunteer to take this up with the CA/Browser Forum?


I also see a couple places in Mozilla's CA Certificate Policy where the words 'fraudulent' and 'misused' appear without having been defined...

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
"4. We reserve the right to not include a particular CA certificate in our software products. This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) would cause undue risks to users’ security, for example, with CAs that
- knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or
- knowingly issue certificates that appear to be intended for fraudulent use."

What is meant by "fraudulent use"?
Is the second bullet point essentially a restatement of the first bullet point?
Should the second bullet point be deleted?


https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/
"2. CAs must revoke Certificates that they have issued upon the occurrence of any of the following events:
... the CA obtains reasonable evidence that the subscriber’s private key (corresponding to the public key in the certificate) has been compromised or is suspected of compromise (e.g. Debian weak keys), or that the certificate has otherwise been misused;"

Proposal:
Change
"or that the certificate has otherwise been misused;"
to
"or that the certificate has been used for a purpose outside of that indicated in the certificate or in the CA's subscriber agreement;"


Thanks,
Kathleen

[Eric Mill]

On Mon, May 16, 2016 at 8:24 AM, Ben Wilson <ben.w...@digicert.com> wrote:

> Gerv wrote,

> "Counter-question to many of these: who defines what is malware, and who
> made them king?"
>

> The contract that the CA enters into with the subscriber should have done
> that.
>
> Subscriber Agreements should have language in them that says something to
> the effect, "We can revoke your certificate if you are [insert bad
> behavior]
> as we determine [insert evidentiary standard or threshold]." (The
> evidentiary standard might be "as we reasonably believe", "as we determine
> in our sole discretion", etc.)
>

Individual CA terms of service are a much more reasonable place for these
kinds of requirements. That's something CAs can put in their marketing as a
feature to audiences that want that. It doesn't stop malware actors from
getting certificates from CAs that don't police malware, but given that
certificates today are being automatically dispensed for free based sheerly
on technical validation, preventing malware from *obtaining* a certificate
seems like a losing battle.

Putting malware policing into root program requirements is significantly
more dangerous, because that root program has what amounts to unchecked
policing power over any HTTPS domain. And since revocation isn't even
enforced except in limited circumstances by the most popular browser
(Chrome), the positive impact of revoking a malware site's certificate is
quite limited.

So using revocation to block malware is the worst of both worlds: revoking
a "bad guy" certificate fails to save everyone from the bad guy, yet
revoking a "good guy" certificate prevents the good guy from serving a
significant chunk of the global population. And while the folks on this
list might have a similar and narrow shared mental conception of malware,
in the long run and at global scale, "misuse" can get a lot more
subjective.

Will this also be how IP holders might pursue relief if they don't like how
the DMCA safe harbor is working out? Or how a government blocks the release
of material it believes to be classified or societally harmful? It could be
a lot easier and cheaper to convince a root program to tell a CA to revoke
a certificate than it is to convince a judge or go through ICANN's UDRP. It
would also come with zero oversight or defined public process, or the
opportunity for the public interest to be represented.

The absolute last place it should be is in CA/B Forum requirements. Peter
already pointed to some helpful language in the EV Guidelines that suggests
that the Baseline Requirements are explicitly not trying to be in this
business. If there's still ambiguity, maybe Mozilla can be helpful in
resolving it.

More generally, the IANA transition has brought a ton of scrutiny to
internet governance and the role of US governments and corporations in
managing the internet's name system. That scrutiny will only increase,
especially as other large countries clamor for more control and
sovereignty. If HTTPS should be the default on the internet, and the CA
system is the only thing we have right now that can guarantee it, then root
programs and the CA/B Forum start to look a lot like a new internet
governance body.

Being an internet governance body comes with real obligations to the
public, and the real potential to see involuntary regulation if
self-regulation fails. Since only CAs can issue certificates, while other
layers can defend users against malware, the CA system at large should be
very careful about how it weighs malware defense alongside its other
responsibilities.

-- Eric

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>

--
konklone.com | @konklone <https://twitter.com/konklone>

[Roland Shoemaker]

In the case of a DV certificate it's exactly what it says, validating
the ownership of a domain, and nothing more. While users _may believe_
that TLS is supposed to protect them from malware, hackers, or
'untrustworthy' sites in general _it is not_. TLS exists to encrypt the
connection between a client and a server.

What users expect, because of poor wording by people conveying the use
of TLS in the past (I think we are all probably a bit guilty of
perpetuating this error), should not dictate how CAs actually operate.

On 05/17/2016 12:36 PM, Peter Gutmann wrote:
> Hubert Kario <hka...@redhat.com> writes:
>
>> then users expect impossible
>
> Users expect CAs to be something other than certificate vending machines. The
> fact that CAs fail to do this is a problem with browser PKI and CAs, not with
> users.
>
> (There have been numerous cases of security people reporting CA-certified
> phishing and malware sites to the CAs that did it. The general response has
> been "not our problem, they paid their money and we gave them a cert". So
> even if you tell the CA, they're likely not going to fix it).
>

> Peter.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--

Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group

[Gervase Markham]

On 17/05/16 22:41, Kathleen Wilson wrote:
> On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote:
>> I am wondering if the BRs need to be updated to:
>> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
>> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.
>
> Would someone please volunteer to take this up with the CA/Browser Forum?

To be clear: you would like the CA/Browser Forum to define more
explicitly what is meant by "Certificate misuse, or other types of
fraud" in the definition of "Certificate Problem Report"? And your
initial proposal for a definition is "being used for a purpose outside
of that contained in the cert, or applicant provided false information"?

If we can be clear by the end of the week what we are asking, I can
bring this up in the CAB Forum face-to-face meeting next week.

> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> "4. We reserve the right to not include a particular CA certificate in our software products. This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) would cause undue risks to users’ security, for example, with CAs that
> - knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or
> - knowingly issue certificates that appear to be intended for fraudulent use."
>
> What is meant by "fraudulent use"?

I think the bullet as a whole could mean that we reserve the right to
not include CAs who happily issue certs to "www.paypalpayments.com" to
just anyone without any checks or High Risk string list or anything.
Such a cert, unless issued to Paypal, Inc., is clearly to be used for
fraud, IMO, and a CA is negligent in issuing it given that it's not hard
to flag for manual review any cert containing the names of major banks
and payment companies.

Gerv

[Peter Bowen]

On Wed, May 18, 2016 at 7:16 AM, Gervase Markham <ge...@mozilla.org> wrote:
> I think the bullet as a whole could mean that we reserve the right to
> not include CAs who happily issue certs to "www.paypalpayments.com" to
> just anyone without any checks or High Risk string list or anything.
> Such a cert, unless issued to Paypal, Inc., is clearly to be used for
> fraud, IMO, and a CA is negligent in issuing it given that it's not hard
> to flag for manual review any cert containing the names of major banks
> and payment companies.

Playing Devil's Advocate for a moment, if paypalpayments.com is a
valid registered domain and is owned by A Better World LLC (a Delaware
Corporation), why should they not be able to get a certificate for
their domain?

How far do you take it? According to
http://brandirectory.com/league_tables/table/banking-500-2014, top
bank brands include "TD", "UBS", and "ING", should CAs block on
"outdoor.sh", "nightclubs.io", and "exceeding.ly"?

Why should Hong Kong and Shanghai Banking Corporation be considered to
have claim to HSBC than the Humane Society of Broward County, the
House Small Business Committee, or Hobe Sound Bible College?

Given that there is already the ICANN UDRP, shouldn't that be the
venue to decide who is authorized to have what domain names? Should
CAs be responsible for making calls on who is authorized for a domain
name?

Thanks,
Peter

[Nick Lamb]

On Wednesday, 18 May 2016 16:22:39 UTC+1, Peter Bowen wrote:
> Given that there is already the ICANN UDRP, shouldn't that be the
> venue to decide who is authorized to have what domain names? Should
> CAs be responsible for making calls on who is authorized for a domain
> name?

The UDRP and the registrars only get to see the 2LD, whereas a CA is making an assertion about the entire name certified.

I would be a lot more comfortable just saying "No" here if Mozilla had mandated CT logging. With CT logging you can argue that figuring out if hsbc.customerhelp.example is "legitimate" is left as a problem for HSBC via log monitoring (either with their own monitor or more likely a service provider), as they please.

However with the current level of voluntary logging you have the same situation as CAA. The most scrupulous CAs log everything, some others selectively opt out for paying customers, and some log nothing whatsoever. A policy change, and in the longer term a commitment to require SCTs would alter that landscape. But until then it's easy to have some sympathy for the idea of "high risk" names as a check for CAs to perform to protect the ecosystem. More sympathy than for the idea of them inspecting a site's contents.

Also, FWIW I believe that even though I sometimes insist on expanding it to Hong Kong and Shanghai Banking Corporation that isn't legally correct. HSBC today doesn't stand for anything at all, the name of the globally famous bank is literally just HSBC.

[Eric Mill]

On Wed, May 18, 2016 at 9:35 AM, Ben Wilson <ben.w...@digicert.com> wrote:

> Looking at the threat from a defense-in-depth/orthogonal perspective,
> doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does
> something to combat malicious websites for the public?
>

It certainly could, and so far no one's argued that individual CAs should
be forbidden from revoking certificates used for malware. The issue is
whether CAs should be universally required, via CA/B or Mozilla rules, to
do so.

-- Eric

> Given that there is already the ICANN UDRP, shouldn't that be the
> venue to decide who is authorized to have what domain names? Should
> CAs be responsible for making calls on who is authorized for a domain name?
>

> Thanks,
> Peter

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>


--

konklone.com | @konklone <https://twitter.com/konklone>

[jo...@letsencrypt.org]

I would simply like to state that my views, and the views of Let's Encrypt, are closely aligned with those already expressed here by Peter Bowen and Eric Mill.

I will add, since I don't think it has been made clear enough here already, that violations of a CA's subscriber agreement can and should be considered fraud and abuse, in addition to the other general definitions given here.

[Matt Palmer]

On Wed, May 18, 2016 at 04:35:49PM +0000, Ben Wilson wrote:
> Looking at the threat from a defense-in-depth/orthogonal perspective,
> doesn't it make sense that everyone -- browsers, ICANN, CAs, etc. -- does
> something to combat malicious websites for the public?

Because the next steps after "we must do something!" is invariably "this is
something" and "we must do this", regardless of efficacy. We can't get CAs
to do what they *have* to do (attest as to identity) in a reliable manner;
how is heaping more nuanced decision-making on them going to help?

As far as browsers doing "something" to combat malicious websites, they are
doing plenty already, with things like the Google Safe Browsing list. Not
everything needs to be hit with the CA stick.

- Matt

[Matt Palmer]

On Wed, May 18, 2016 at 03:16:59PM +0100, Gervase Markham wrote:
> > What is meant by "fraudulent use"?
>

> I think the bullet as a whole could mean that we reserve the right to
> not include CAs who happily issue certs to "www.paypalpayments.com" to
> just anyone without any checks or High Risk string list or anything.
> Such a cert, unless issued to Paypal, Inc., is clearly to be used for
> fraud, IMO

How so? It could be a site providing information from a third party on how
to make and receive payments via PayPal. It could also be a site operated
by a third party on behalf of PayPal. Inferring nefarious intent from a
domain name seems like a really great way to make some fairly spectacular
mistakes.

- Matt

--
My favourite was some time ago, and involved a female customer thanking "Mr.
Daemon" for his effort trying to deliver her mail, and offering him a "good
time" if he ever visited Sydney.
-- Matt McLeod

[Richard Z]

On Tue, May 17, 2016 at 01:04:28AM +0000, Charles Reiss wrote:
> On 05/16/16 12:22, Richard Z wrote:
> >On Sun, May 15, 2016 at 05:43:39PM -0700, Peter Bowen wrote:
> >
> >>Some CAs may choose to not issue to sites known to inject malware, but
> >>this outside the scope of the SSL requirements. The EV Guidelines it
> >>very clear that the reputation and actions of the Subject are not in
> >>scope:
> >

> >knowingly issuing/tolerating certificates for sites known to inject
> >malware is
> >* contrary to user expectaions

> >* possible case of criminal felony and a liablility issue
> >
> >So irrespective of what EV Guidelines say there may be other common
> >sense reasons to require revocation of such certificates and I would
> >not want Mozilla to underbid the already minimalistic security
> >promise of TLS.
> >
> >Having an identity established by EV is nice but in most cases of
> >malware attacks the user has no chance to examine this identity if
> >the attack comes in an injected iframe.
>
> Do you think revoking certificate from malware-injecting sites would have or
> has had meaningful effects on the security received by users?
>
> I'd note that, even with OCSP hard-fail (not default), revocation takes at
> least the duration of OCSP response validity to reliably take effect, often
> 1 week.
>
> Even if it did not, CAs seem to be in a very poor position to evaluate
> whether sites are serving malware (compared to, say, browser vendors who run
> programs like the Google Safe Browsing list) or to have nuanced responses to
> tricky cases, like shared web hosts or advertising networks who have some
> customers which are serving malware.

the point is if mozilla would say "we don't care the least if certificates are
used for illegal or malicious purposes as long as the identity is established"
it might actually encourage some CAs to search for new business models.
There are crime friendly providers already and having crime friendly CAs is
something that users would definitely notice.

Richard

--
Name and OpenPGP keys available from pgp key servers

[Matt Palmer]

On Tue, May 17, 2016 at 11:14:21PM +0200, Richard Z wrote:
> There are crime friendly providers already and having crime friendly CAs is
> something that users would definitely notice.

Why? Do users typically notice the crime friendly hosting providers?

- Matt

[Peter Kurrasch]

Hi Gerv,

I would recommend against asking CA's to necessarily judge "malicious intent" on their own. Many CA's have enough to worry about just making sure they issue certs properly that I would question their ability to take on this extra work and perform it sufficiently well.

That said, it may be worthwhile bringing up for discussion the idea of malicious intent and what roles or responsibilities are reasonable for a CA. There are undoubtedly parallels here to how anti-spam and IP address blacklisting services go about their functions as well as Microsoft's response to malicious code that is signed with a cert that is recognized by their code signing program. Perhaps there are lessons learned there or good practices that could be adopted.

Possible talking points:

* In simplest terms I imagine most all CA's would agree that "we have the right to refuse service to anyone for any reason, up to and including revocation of already-issued certs". Certainly, something that can be seen as harmful to the reputation of a CA would qualify as one such reason?

* ‎If a CA is notified that a cert under their purview is being used for malicious intent, what will their response be and what should it be? Can a CA individually specify what they might consider malicious, how a judgment might be reached, any notifications made? Certainly each case and situation will have its own considerations but maybe some general guidelines could still be documented.

Even if the best a CA can do is revoke the cert, that still has value. At least we might have some assurance that future encounters with the malicious activity will have limited effect.

Thanks.

From: Gervase Markham Sent: Wednesday, May 18, 2016 9:17 AM To: Kathleen Wilson; mozilla-dev-s...@lists.mozilla.org Subject: Re: SSL Certs for Malicious Websites

On 17/05/16 22:41, Kathleen Wilson wrote:

> On Monday, May 16, 2016 at 9:20:56 AM UTC-7, Kathleen Wilson wrote:
>> I am wondering if the BRs need to be updated to:
>> + Define what is meant by "Certificate misuse, or other types of fraud". (e.g. being used for a purpose outside of that contained in the cert, or applicant provided false information.)
>> + Add text similar to what is in the EV Guidelines stating that TLS/SSL certificates focus only on the ownership of the domain name(s) included in the certificate, and not on the behavior of the website. Note that the BRs already have section 9.6.1 about certificate warranties.
>
> Would someone please volunteer to take this up with the CA/Browser Forum?

To be clear: you would like the CA/Browser Forum to define more

explicitly what is meant by "Certificate misuse, or other types of

fraud" in the definition of "Certificate Problem Report"? And your

initial proposal for a definition is "being used for a purpose outside

of that contained in the cert, or applicant provided false information"?

If we can be clear by the end of the week what we are asking, I can
bring this up in the CAB Forum face-to-face meeting next week.

> https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/
> "4. We reserve the right to not include a particular CA certificate in our software products. This includes (but is not limited to) cases where we believe that including a CA certificate (or setting its "trust bits" in a particular way) would cause undue risks to users’ security, for example, with CAs that
> - knowingly issue certificates without the knowledge of the entities whose information is referenced in the certificates; or
> - knowingly issue certificates that appear to be intended for fraudulent use."
>
> What is meant by "fraudulent use"?

I think the bullet as a whole could mean that we reserve the right to

not include CAs who happily issue certs to "www.paypalpayments.com" to
just anyone without any checks or High Risk string list or anything.
Such a cert, unless issued to Paypal, Inc., is clearly to be used for

fraud, IMO, and a CA is negligent in issuing it given that it's not hard
to flag for manual review any cert containing the names of major banks
and payment companies.

Gerv