Re: [FORGED] Re: SSL Certs for Malicious Websites

[Gervase Markham]

On 29/05/16 11:48, Peter Gutmann wrote:
> Are you really trying to claim that the sad farce that is current browser PKI
> is absolutely the very best that browser vendors can do in terms of protecting
> users online?

I'm sure things can always be better. My point was that the current
system, for all its flaws, prevents a great deal of evil in a way which
is pretty much totally transparent to users. And that's a big benefit.
We may find, like people find when they analyse passwords and the
alternatives to them, that actually what we have now has some important
features it's hard to replicate in other systems.

>> Whatever the disadvantages of the current system, it must be recognised that
>> it provides the ability for every single Internet user to have their
>> communications with any website that opts-in encrypted on the wire without
>> them having to do, know or configure _anything_. That's huge.
> 
> So would straight anon-DH.  In fact it's interesting to compare the two: Anon-
> DH provides encryption on the wire, as does browser PKI.  Anon-DH has no
> effect on phishing, but then neither does browser PKI.  The one thing that
> anon-DH doesn't handle is MITM 

Oh, a tiny and trivial difference. After all, the one thing we've
learned over the past 3 years or so is that the network is generally
secure and trustworthy, right?

> In terms of "configuration-free idiot-proof secure communications technology",
> the answer is "pretty much anything but browser PKI".  Skype, WhatsApp,
> Signal, Silent Circle (just off the top of my head, I can google several pages
> worth of others if you like) all do a pretty good job of providing secure,
> mutually authenticated communications (which browser PKI still can't do thanks
> to the failure to launch of client certs) without needing any PKI.

And all have a single point of failure. It's much easier, I agree, to do
what WhatsApp did and deploy encryption to every single user if there's
a central controlling entity. (And Signal is moving that way for
precisely that reason, as perhaps you know.) Doing it in a mechanism
over which no party has total control is much harder - but yet, this is
a key and non-negotiable value of the web.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: SSL Certs for Malicious Websites

[Peter Gutmann]

Gervase Markham  writes:

>It depends what alternative configuration-free idiot-proof secure
>communications technology you have invented in your fantasy world to take its
>place.

Are you really trying to claim that the sad farce that is current browser PKI
is absolutely the very best that browser vendors can do in terms of protecting
users online?

>Whatever the disadvantages of the current system, it must be recognised that
>it provides the ability for every single Internet user to have their
>communications with any website that opts-in encrypted on the wire without
>them having to do, know or configure _anything_. That's huge.

So would straight anon-DH.  In fact it's interesting to compare the two: Anon-
DH provides encryption on the wire, as does browser PKI.  Anon-DH has no
effect on phishing, but then neither does browser PKI.  The one thing that
anon-DH doesn't handle is MITM while browser PKI often does, but then again
anon-DH allows automatic, transparent crypto everywhere without having to mess
around with certificates while browser PKI requires it, so let's call that one
a draw depending on which one you consider more important.

In terms of "configuration-free idiot-proof secure communications technology",
the answer is "pretty much anything but browser PKI".  Skype, WhatsApp,
Signal, Silent Circle (just off the top of my head, I can google several pages
worth of others if you like) all do a pretty good job of providing secure,
mutually authenticated communications (which browser PKI still can't do thanks
to the failure to launch of client certs) without needing any PKI.  Just for
one single example, WhatsApp, about a billion or so nontechnical users have no
problems with secure communications.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: SSL Certs for Malicious Websites

[Gervase Markham]

On 27/05/16 13:20, Peter Gutmann wrote:
> Apart from the lucky CAs who have been given government-
> mandated monopolies, would any CA still exist today if there weren't a need to
> pay someone to turn off the browser warnings?

It depends what alternative configuration-free idiot-proof secure
communications technology you have invented in your fantasy world to
take its place.

Whatever the disadvantages of the current system, it must be recognised
that it provides the ability for every single Internet user to have
their communications with any website that opts-in encrypted on the wire
without them having to do, know or configure _anything_. That's huge.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: SSL Certs for Malicious Websites

[Peter Gutmann]

Ryan Sleevi  writes:

>This seems both off-topic and not productively addressing the topic at hand.

Yeah, maybe it's best taken to another list like cypherpunks or the crypto
list.  It was intended as an honest, and probably pretty blunt, assessment of
the state of HTTPS: It was introduced to build consumer, and merchant,
confidence in using the Internet for business, killing the competing SET in
the process, and it's succeeded in doing that.  Once that was done, which
happened about 15-20 years ago, its main role became perpetuating the
existence of CAs.  Apart from the lucky CAs who have been given government-
mandated monopolies, would any CA still exist today if there weren't a need to
pay someone to turn off the browser warnings?

Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: SSL Certs for Malicious Websites

[Hubert Kario]

On Thursday 26 May 2016 05:13:43 Peter Gutmann wrote:
> Richard Z  writes:
> >If any criminal can easily get EV certificates what is the point of
> >https?
> The point of HTTPS is twofold:
> 
> 1. Convince users that the Internet is safe to do business on
> (financial transfers, medical data).
> 
> 2. Provide a steady revenue stream for CAs.
> 
> There's also something about privacy from NSA snooping, but that's a
> recent thing, and mostly only geeks care about it.  In addition
> depending on how paranoid the geeks are, HTTPS may not provide the
> privacy they want).

people don't care only if you are asking the wrong questions[1], if you 
frame the question in the way they do understand, they do care: 
https://www.youtube.com/watch?v=XEVlyP4_11M

 1 - https://www.youtube.com/watch?v=G0ZZJXw4MTA
 
> Finally, point 1 doesn't really need HTTPS, you could just slap a
> padlock into the UI and not bother with encryption.  So it's mostly
> point 2.

I don't think that this level of cynicism is helping...

-- 
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

signature.asc
Description: This is a digitally signed message part.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Ryan Sleevi]

On Wed, May 25, 2016 at 6:50 AM,   wrote:
> If I understand you correctly, you are saying that CAs should not be doing 
> any "internet policing" or "content policing" when they receive credible 
> reports their certs are being used by phishers, malware providers, etc. -- 
> but that browsers can and should do "internet policing" or "content policing" 
> when they blacklist sites on such applications as Google Safe Browsing and 
> Microsoft Smart Screen -- am I stating that correctly?  If so, I was not the 
> one to introduce the topic to this string.

As Eric pointed out, no, you are not understanding correctly. I was
merely addressing Kathleen's question about whether all CAs are
required to police, not whether some CAs can, if they so decide. I
don't believe CAs SHOULD police, but that's irrelevant to the more
substantial question - I don't believe CAs MUST police.

> Plus -- I don't agree this string is about promoting encryption only.

That's OK. It's clear we disagree about the value of privacy,
confidentiality, and integrity - which TLS provides. I believe these
three are valuable in and of themselves, and we must not sacrifice
them in order to also add 'brand protection'.

>  Kathleen started by asking for interpretation of existing BR language that 
> requires CAs to revoke and/or non-issue for things like "Certificate misuse, 
> or other types of fraud, compromise, misuse, or inappropriate conduct related 
> to Certificates."

And that's what I was responding to, but you then dove-tailed into an
unrelated discussion about how Microsoft/Google technologies work,
which doesn't seem as germane to the question.

> Why should CAs delegate to or rely on browsers for this type of user 
> protection?

Because security works best when it's composed. Why should CAs
delegate encryption to TLS? Why shouldn't each CA come up with their
own encryption technology, and deploy it using browser plugins? Why
should CAs rely on DNS? Why shouldn't they come up with their own
naming schemes?

The answer is that different parties in the ecosystem have different
roles, and are best suited to different tasks. You've already heard,
several times, the answer to your question - because CAs content
policing themselves comes with real risks and harm. While some CAs
may, as part of their brand, choose to do content policing, site
operators have an easy recourse - simply don't use those CAs. The
market is flexible to permit that. Suggesting, however, that ALL CAs
must do so, implies that ALL CAs must share your values, and it's
clear that such a position can and does cause real harm.

> Isn't it better for CAs to remain involved by revoking certs / refusing to 
> issue certs to known bad sites, like CAs have done for at least the past 8 
> years - why change that now?  Why can't both CAs and browsers work together 
> for maximum user protection?

This has already been responded to several times by participants on
the thread. I don't think it adds value to keep saying it, and it's
been said in a variety of ways that I don't think it bears restating.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: [FORGED] Re: SSL Certs for Malicious Websites

[Peter Gutmann]

Richard Z  writes:

>If any criminal can easily get EV certificates what is the point of https?

The point of HTTPS is twofold:

1. Convince users that the Internet is safe to do business on (financial 
   transfers, medical data).

2. Provide a steady revenue stream for CAs.

There's also something about privacy from NSA snooping, but that's a recent 
thing, and mostly only geeks care about it.  In addition depending on how 
paranoid the geeks are, HTTPS may not provide the privacy they want).

Finally, point 1 doesn't really need HTTPS, you could just slap a padlock 
into the UI and not bother with encryption.  So it's mostly point 2.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Richard Z]

On Wed, May 25, 2016 at 11:54:50AM -0400, Eric Mill wrote:
> On Wed, May 25, 2016 at 9:50 AM,  wrote:
> 
> >
> > Why should CAs delegate to or rely on browsers for this type of user
> > protection?  Isn't it better for CAs to remain involved by revoking certs /
> > refusing to issue certs to known bad sites, like CAs have done for at least
> > the past 8 years - why change that now?  Why can't both CAs and browsers
> > work together for maximum user protection?
> >
> 
> Because users use browsers (and choose them). Users don't choose what
> certificates or CAs sites use. So users have no recourse if the CA is
> taking an inappropriate action, and no strong market signal gets sent to
> CAs about the appropriateness of their actions.

users do choose what CAs they use (or rather trust). On every new install
I spend a few minutes reviewing CAs and disabling several dozens of those
which I will never miss.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Eric Mill]

On Wed, May 25, 2016 at 9:50 AM,  wrote:

>
> Why should CAs delegate to or rely on browsers for this type of user
> protection?  Isn't it better for CAs to remain involved by revoking certs /
> refusing to issue certs to known bad sites, like CAs have done for at least
> the past 8 years - why change that now?  Why can't both CAs and browsers
> work together for maximum user protection?
>

Because users use browsers (and choose them). Users don't choose what
certificates or CAs sites use. So users have no recourse if the CA is
taking an inappropriate action, and no strong market signal gets sent to
CAs about the appropriateness of their actions.

In any case, the question here isn't whether CAs should be *forbidden* from
revoking certificates for malware, it's whether they should be *required*
to. Requiring every CA to become content/malware police is extreme. The
only reasons it hasn't felt extreme to CAs until recently is because the
customer base was much smaller and more homogeneous than it's becoming
today, and certificates were not yet becoming required to use the full
featureset of the web.

-- Eric


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



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Richard Z]

On Wed, May 25, 2016 at 01:09:53AM -0700, Ryan Sleevi wrote:
> On Tue, May 24, 2016 at 10:25 AM,   wrote:
> > Here's my question -- what do Google and Microsoft do with such reports?  
> > Do they investigate and then put a site on the "bad" list, eg, for 
> > injecting malware?  If not, then no one will stop the malware site.  If yes 
> > -- what criteria does Google (and Microsoft, etc.) use to put the site on 
> > your bad list?
> 
> https://www.microsoft.com/security/portal/mmpc/shared/objectivecriteria.aspx
> https://www.google.com/transparencyreport/safebrowsing/faq/?hl=en#how-do-you-determine-that-a-site-is-unsafe
> 
> > It seems the problem of "what is malware, what is phishing, what is abuse" 
> > must be decided by someone.  My opinion is that CAs at least have to try 
> > (set up a meaningful process, and respond to complaints by following the 
> > process, and in some cases revoking), and not just defer all action to 
> > browsers.
> 
> Unsurprisingly, I disagree. We're debating whether the ability to have
> encryption - which provides an incredibly value service against
> network level attackers - should be coupled with trust.

imho it is debattable whether https-everywhere is worth any tradeoffs 
in CA requirements. If any criminal can easily get EV certificates what
is the point of https?

>  Coupling
> certificates to this can do greater HARM than good - imagine a
> download site that provides general purpose file hosting from users,
> and one user happens to upload malware. If you revoke that
> certificate, you introduce active harm to all the good files being
> downloaded.

How is any harm done here - with or without certificate you have not 
the slightest assurance that any of the files is "good"?

However, when visiting my home-banking site I indeed want the assurance
that the site owning the EV certificate takes full responsibility
for all content.

> Further, the distinction between "Why is it different from browsers"
> is the ability for the end user to have choice. The end user can't
> change the site's certificate.

You can choose to accept any certificate of any site if you think
you want to trust the site whether or not it has been issued by a CA. 
One of my banks did deliberately provide a self signed certificate
(without any CA validation) and asked customers to verify the certificate 
by comparing the fingerprint with a hardcopy sent by surface mail.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Ryan Sleevi]

On Tue, May 24, 2016 at 10:25 AM,   wrote:
> Here's my question -- what do Google and Microsoft do with such reports?  Do 
> they investigate and then put a site on the "bad" list, eg, for injecting 
> malware?  If not, then no one will stop the malware site.  If yes -- what 
> criteria does Google (and Microsoft, etc.) use to put the site on your bad 
> list?

https://www.microsoft.com/security/portal/mmpc/shared/objectivecriteria.aspx
https://www.google.com/transparencyreport/safebrowsing/faq/?hl=en#how-do-you-determine-that-a-site-is-unsafe

> It seems the problem of "what is malware, what is phishing, what is abuse" 
> must be decided by someone.  My opinion is that CAs at least have to try (set 
> up a meaningful process, and respond to complaints by following the process, 
> and in some cases revoking), and not just defer all action to browsers.

Unsurprisingly, I disagree. We're debating whether the ability to have
encryption - which provides an incredibly value service against
network level attackers - should be coupled with trust. Coupling
certificates to this can do greater HARM than good - imagine a
download site that provides general purpose file hosting from users,
and one user happens to upload malware. If you revoke that
certificate, you introduce active harm to all the good files being
downloaded.

Further, the distinction between "Why is it different from browsers"
is the ability for the end user to have choice. The end user can't
change the site's certificate.

>  And does Safe Browsing have a method by which a site can appeal and get off 
> the list?

While I'm sure your curiosity is real, it remains unclear how or why
that relates. The information can also be obtained independently, so
perhaps you could clarify how/why it relates to this topic? Otherwise,
I might suggest you read the above links.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[tech29063]

On Tuesday, May 24, 2016 at 2:01:22 PM UTC+2, Ryan Sleevi wrote:
> On Friday, May 20, 2016 at 10:24:56 AM UTC-7, Andrew Ayer wrote:
> > In fact, Kathleen asked explicitly for what the answers "should be" in
> > addition to what they are, so my email was not unrelated. To be more
> > explicit, I think the answers to questions 3-5 should be no.  The
> > reason why is explained in my email: requiring CAs to be responsible
> > for content has unintended negative effects on HTTPS adoption.  I
> > think that causes more harm than good to Internet security.
> 
> At the risk of "me too," I think Andrew and Eric have properly captured the 
> concerns, and agree with their conclusions.
> 
> I do not believe the "should" answers should encompass or include "malware," 
> a phrase which is necessarily subjective and subject to interpretation. For 
> example, if a piece of software may be illegal within a local jurisdiction, 
> does it constitute malware? If the issuing CA is in an independent 
> jurisdiction that disagrees with that local jurisdiction, is the CA obligated 
> to revoke such a certificate?
> 
> The dangers to policing content are well known and well understood. In the 
> promotion of more encrypted communications, we should not let the ambitions 
> of some CAs to be Internet judges get in the way.

Ryan, here is a related question (a serious inquiry, not argument).  A number 
of people on this discussion have said "responding to Certificate Problem 
Reports should not be the job of a CA.  Instead, the public (or the CA?) should 
just report a site to Google Safe Browsing and Microsoft SmartScreen and be 
done with it."

Here's my question -- what do Google and Microsoft do with such reports?  Do 
they investigate and then put a site on the "bad" list, eg, for injecting 
malware?  If not, then no one will stop the malware site.  If yes -- what 
criteria does Google (and Microsoft, etc.) use to put the site on your bad list?

It seems the problem of "what is malware, what is phishing, what is abuse" must 
be decided by someone.  My opinion is that CAs at least have to try (set up a 
meaningful process, and respond to complaints by following the process, and in 
some cases revoking), and not just defer all action to browsers.

So speaking generally (not asking for trade secrets), what criteria does Google 
use to put a site on its Safe Browsing list?  And how does Google deal with the 
issue of what are bad sites (as you know, Google's decisions feed back into the 
CA loop - many CAs will use a listing on Google Safe Browsing as a reason to 
refuse to issue any more certs to a user).  And does Safe Browsing have a 
method by which a site can appeal and get off the list?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Ryan Sleevi]

On Friday, May 20, 2016 at 10:24:56 AM UTC-7, Andrew Ayer wrote:
> In fact, Kathleen asked explicitly for what the answers "should be" in
> addition to what they are, so my email was not unrelated. To be more
> explicit, I think the answers to questions 3-5 should be no.  The
> reason why is explained in my email: requiring CAs to be responsible
> for content has unintended negative effects on HTTPS adoption.  I
> think that causes more harm than good to Internet security.

At the risk of "me too," I think Andrew and Eric have properly captured the 
concerns, and agree with their conclusions.

I do not believe the "should" answers should encompass or include "malware," a 
phrase which is necessarily subjective and subject to interpretation. For 
example, if a piece of software may be illegal within a local jurisdiction, 
does it constitute malware? If the issuing CA is in an independent jurisdiction 
that disagrees with that local jurisdiction, is the CA obligated to revoke such 
a certificate?

The dangers to policing content are well known and well understood. In the 
promotion of more encrypted communications, we should not let the ambitions of 
some CAs to be Internet judges get in the way.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Jason -]

On Wednesday, May 18, 2016 at 6:22:39 PM UTC+3, Peter Bowen wrote:
> On Wed, May 18, 2016 at 7:16 AM, Gervase Markham  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

I will also add a classical example that used to exist there: gmail.de
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Eric Mill]

On Sat, May 21, 2016 at 12:04 PM,  wrote:
>
> Peter, once again you are ignoring the full language of BR 4.9.2 to
> 4.10.2.  These CA requirements are not limited to reports of "misuse"
> submitted to a CA, but apply to reports of "suspected Key Compromise,
> Certificate misuse, or other types of fraud, compromise, misuse, or
> inappropriate conduct related to Certificates."
>
> So please don't try to limit this conversation to what is "misuse" --
> that's just inaccurate for defining a CA's obligations.


No one's limiting the conversation. This is the conversation that was
requested. Here are Kathleen's 5 questions:

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

Your citing of language that says "suspected Key Compromise, Certificate
misuse, or other types of fraud, compromise, misuse, or inappropriate
conduct related to Certificates." doesn't answer this question. It just
brings the question up again.

You clearly feel it necessarily includes malware injection, and believe
that this is the general consensus among CAs. Peter is telling you he
doesn't read it that way, and Kathleen is asking for clarification from the
community because it's not obvious to Mozilla.

In 4.9.2 to 4.10.2, every provision you list includes room for CA
discretion and independent judgment.

That discretion and independent judgment is also free to be fully encoded
in software, rather than requiring a human on the line per-request. That
software could encode a definition of "certificate misuse, or other types
of fraud" that is different than yours.

> 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?

Everything I said above also applies to these two questions. It is up to
the CA

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

As written, completely up to the CA. General consensus among the leaders of
some large CAs about how to interpret this question does not make a binding
definition.

> 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?

Even were policing malware a requirement of the BRs or EVG, implementation
details of how to do that seem out of scope.

On Sat, May 21, 2016 at 12:04 PM,  wrote:

> We as CAs need to be protecting users once we receive Certificate Problem
> Reports of certs being used for malware injection.
>

And CAs who wish to do that are completely free to. Whether all CAs are
required to be malware police is, clearly, a matter of debate created by
vague wording in the BRs.

The language was probably intentionally vague, so as to give CAs some
flexibility in explaining to auditors how their controls meet the Baseline
Requirements. That's okay -- laws (the better ones, anyway) are generally
intentionally written to be vague, to futureproof the text and to allow
some level of private sector and federal agency implementation and
discretion.

And do you really want a maximalist reading of the BR text?

The BR language as written includes the phrase "inappropriate conduct". Do
you really think individual certificate authorities should be required to
police a broad definition of "inappropriate conduct" online? In my opinion,
that phrase should be stricken from the BRs immediately, but while it's in
there, I would hope it would be interpreted as narrowly as possible.

People should really heed Andrew Ayer's post about the practical
difficulties of operating a commercial certificate business with the way
many CAs currently design their review processes to hold on "risky"
certificates: "Without exception, every time has been a false positive."

In my work capacity, I actually had such an experience with Andrew's
business myself, documented on a public thread:
https://github.com/SSLMate/sslmate/issues/7

Andrew patiently worked with our team through delays from one CA because
our certificate had ".gov" in it, and a second CA that flagged the word
"treasury". Apparently no domain that uses the lower-case English word
"treasury" should enjoy the cost, security, and operational benefits of
inexpensive automatic issuance premised entirely on technical controls, and
nor should any office in US federal, state, or local government.

That's just my own little parochial issue -- again, at global scale, a
broad interpretation of "misuse" and "inappropriate conduct" are so much
more harmful than any single experience one of us is likely to have as a
customer.

CAs can always exercise judgment and vigorously watch for malware use among
their certificates -- it can even be something they compete on. But Mozilla
and the web PKI community should avoid, wherever possible, 

Re: SSL Certs for Malicious Websites

[Richard Z]

On Thu, May 19, 2016 at 05:20:07PM +1000, Matt Palmer wrote:
> 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?

they do. You can argue that in absence of crime friendly providers the
criminals have other methods but having rogue providers certainly
makes their business easier.

There should be some reasonable middle ground. CAs can not be responsible 
for the contents served by their clients servers. However, CAs also must 
not knowingly or by gross negligence support malicious operations.

Richard

-- 
Name and OpenPGP keys available from pgp key servers

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[tech29063]

On Friday, May 20, 2016 at 6:22:21 PM UTC-7, Peter Bowen wrote:
> [ Disclaimer: This message is my personal view and does not
> necessarily represent that of my employer. ]
> 
> On Fri, May 20, 2016 at 5:41 PM,  [Kirk Hall] wrote:
> > Peter -- the reference to BR 9.6.8(8) is interesting, but is not really 
> > relevant to discussion of the requirements of BR 4.2.1 through 4.9.10 
> > quoted by Kathleen in her first message above (and which are enforced by 
> > Section 5 of the Baseline Requirments WebTrust audit - see 
> > http://www.webtrust.org/homepage-documents/item76002.pdf) What about those 
> > sections?  Look again at the first analysis I posted.
> >
> > I don't understand the resistance to complying with these provisions -- 
> > it's not that hard.
> >
> > If you think the requirements of BR 4.2.1 through 4.9.10 should be softened 
> > or deleted, then I suggest you are the one who needs to propose a ballot!  
> > CAs have been following  these rules for about eight years now, so there is 
> > a pretty solid history and precedence.
> 
> You are right, it is not hard to comply with 4.2.1 to 4.9.10.  However
> they say absolutely nothing about malware.  The do discuss "misuse"
> but it is up to the CA to define misuse.
> 
> >From the sections you explicitly called out in your original email:
> 
> 4.9.3: Requires CAs provide ability for anyone to report things.  No
> action is required of the CA other than accepting the report.
> 
> 4.9.2: Says what must be in a certificate problem report, does not
> address processing the report.
> 
> 4.9.5: CA must decide _if_ revocation is warranted. However does not
> state conditions under which revocation must be warranted.
> 
> 4.10.2: CA must be able to respond to problem reports 24x7.
> _Where_appropriate_ the CA can either forward the complaint to law
> enforcement and/or revoke the certificate.  Again does not specify any
> conditions where the CA must do so.
> 
> 4.9.1.1(4): Requires the CA to revoke if the Certificate was misused.
> CA is free to define misuse as they see fit.
> 
> 4.2.1: Requires "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."  Simply requires CAs to be sure
> they are properly identifying the subject authorization and DNS name
> control, as that is what is verified.
> 
> High Risk Certificate Request: ": A Request that the CA flags for
> additional scrutiny by reference to internal criteria and databases
> maintained by the CA".  Does not define any specific mandatory
> requirements for the criteria or database contents.  It does have "may
> include", but that means it is up to the CA.
> 
> I think one of the things that frequently is missed by people not used
> to technical specifications is the meaning of section 1.6.4 of the
> BRs.  It says that the 'words “MUST”, “MUST NOT”, "REQUIRED", "SHALL",
> "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> "OPTIONAL" in these Requirements shall be interpreted in accordance
> with RFC 2119.'  This basically means that anything labeled "should",
> "may", "recommended", or "optional" can be ignored.  The BRs become
> much clearer if you simply remove all the text that uses these words.
> This is why I recommended that they be amended if there is a desire
> that CAs be required to do something currently allowed to be ignored.
> 
> Thanks,
> Peter

Peter, once again you are ignoring the full language of BR 4.9.2 to 4.10.2.  
These CA requirements are not limited to reports of "misuse" submitted to a CA, 
but apply to reports of "suspected Key Compromise, Certificate misuse, or other 
types of fraud, compromise, misuse, or inappropriate conduct related to 
Certificates."

So please don't try to limit this conversation to what is "misuse" -- that's 
just inaccurate for defining a CA's obligations.  We as CAs need to be 
protecting users once we receive Certificate Problem Reports of certs being 
used for malware injection.

4.9.2: Anyone can submit “Certificate Problem Reports” to the issuing CA.   
That includes “Complaint of suspected Key Compromise, Certificate misuse, or 
other types of fraud, compromise, misuse, or inappropriate conduct related to 
Certificates.”

4.9.3: “Certificate misuse, or other types of fraud, compromise, misuse, 
inappropriate conduct, or any other matter related to Certificates”

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 

Re: SSL Certs for Malicious Websites

[Peter Bowen]

[ Disclaimer: This message is my personal view and does not
necessarily represent that of my employer. ]

On Fri, May 20, 2016 at 5:41 PM,   wrote:
> Peter -- the reference to BR 9.6.8(8) is interesting, but is not really 
> relevant to discussion of the requirements of BR 4.2.1 through 4.9.10 quoted 
> by Kathleen in her first message above (and which are enforced by Section 5 
> of the Baseline Requirments WebTrust audit - see 
> http://www.webtrust.org/homepage-documents/item76002.pdf) What about those 
> sections?  Look again at the first analysis I posted.
>
> I don't understand the resistance to complying with these provisions -- it's 
> not that hard.
>
> If you think the requirements of BR 4.2.1 through 4.9.10 should be softened 
> or deleted, then I suggest you are the one who needs to propose a ballot!  
> CAs have been following  these rules for about eight years now, so there is a 
> pretty solid history and precedence.

You are right, it is not hard to comply with 4.2.1 to 4.9.10.  However
they say absolutely nothing about malware.  The do discuss "misuse"
but it is up to the CA to define misuse.

From the sections you explicitly called out in your original email:

4.9.3: Requires CAs provide ability for anyone to report things.  No
action is required of the CA other than accepting the report.

4.9.2: Says what must be in a certificate problem report, does not
address processing the report.

4.9.5: CA must decide _if_ revocation is warranted. However does not
state conditions under which revocation must be warranted.

4.10.2: CA must be able to respond to problem reports 24x7.
_Where_appropriate_ the CA can either forward the complaint to law
enforcement and/or revoke the certificate.  Again does not specify any
conditions where the CA must do so.

4.9.1.1(4): Requires the CA to revoke if the Certificate was misused.
CA is free to define misuse as they see fit.

4.2.1: Requires "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."  Simply requires CAs to be sure
they are properly identifying the subject authorization and DNS name
control, as that is what is verified.

High Risk Certificate Request: ": A Request that the CA flags for
additional scrutiny by reference to internal criteria and databases
maintained by the CA".  Does not define any specific mandatory
requirements for the criteria or database contents.  It does have "may
include", but that means it is up to the CA.

I think one of the things that frequently is missed by people not used
to technical specifications is the meaning of section 1.6.4 of the
BRs.  It says that the 'words “MUST”, “MUST NOT”, "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in these Requirements shall be interpreted in accordance
with RFC 2119.'  This basically means that anything labeled "should",
"may", "recommended", or "optional" can be ignored.  The BRs become
much clearer if you simply remove all the text that uses these words.
This is why I recommended that they be amended if there is a desire
that CAs be required to do something currently allowed to be ignored.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Peter Bowen]

[ Disclaimer: This message is my personal view and does not
necessarily represent that of my employer. ]

On Thu, May 19, 2016 at 9:15 AM,   wrote:
> 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.”

Kirk,

Addressing your question directly, the _Trust Service Principles and
Criteria for Certification Authorities, Version 2.0_ (better know as
WebTrust for Certification Authorities 2.0) very much does not require
such.  This WebTrust audit is designed to provide assurance that the
CA does what it says it does when it comes to Subscriber Registration
and Certificate Issuance.  It is up to the CA to determine the rules
about when it issues a certificate and document those in its CPS.

When it comes to public certificates, which is what the Mozilla CA
program covers and are the subject of the BRs and EV Guidelines
(EVGs), there is assurance that certificates do the the following:

Provide global identification by certifying:
1) A binding between the identity of a natural person or institution
and a cryptographic key
2) Confirmation that the identified named entity authorized issuance
of the certificate
Alternatively they explicitly may not provide identity.

Provide assurance that the subscriber either had control of the hosts,
control of the domain namespace, or was a contact for the domain
namespace for all DNS names or the equivalent for all alternative
names in the certificate at the time the certificate was issued.  In
some cases, such as an electronic identity certificate, there may be
no alternative name.

This is all that they do.  Now some CAs may choose to make further
assurances, for example they may assert that the person named in the
certificate is a citizen of a certain country or assert that the
company is a member of an organization or has been licensed for
certain activities  However this is outside the scope of the BRs and
EVGs.

Just like state, province, territory, or district issued identity
cards in the US and Canada, Certificates do not directly assert
anything about the character of the individual identified.  Someone
with multiple felony convictions can get an identity card.   However,
what the identity card or certificate does so it help provide a
consistent identity that can be looked up in systems to find out about
the character of the person.

Certificates for a critical part of securing communication.  They
solve the a priori knowledge problem when initiating a conversation
with a previously unknown party.  The certificate allows the one party
to say to the other "I'm Bob and you can be assured of that because
our mutual friend Charlie confirmed a much".This avoids a
switcheroo taking place where someone else claims to be Bob.

If CAs want to add additional assertions to certificates, that should
be their prerogative.  If this is included in a manner that allows
automatic extraction, then it is something that firewall or end point
security vendors might be able use to help classify websites.  For
example, a certificate can declare it is a website operated by a
national government which might cause the security software to make
certain decisions.  However this is out of scope for the BRs, EVGs,
and Mozilla CA program.

Thanks,
Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Andrew Ayer]

On Thu, 19 May 2016 16:52:26 -0700 (PDT)
tech29...@gmail.com wrote:

> Your main concern – unjustified delay in issuing a certificate to
> your customer while a human looks at the domain to decide if there is
> a problem - is not really related to any of Kathleen’s questions.
> Your other comments express what you think the role of a CA *should*
> be, but don’t address what the current BRs actually require CAs to do
> (which is what Kathleen was asking).

In fact, Kathleen asked explicitly for what the answers "should be" in
addition to what they are, so my email was not unrelated. To be more
explicit, I think the answers to questions 3-5 should be no.  The
reason why is explained in my email: requiring CAs to be responsible
for content has unintended negative effects on HTTPS adoption.  I
think that causes more harm than good to Internet security.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Gervase Markham]

On 19/05/16 00:45, Matt Palmer wrote:
> 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.

Consider my comment withdrawn :-) Don't know what I was thinking.

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Gervase Markham]

On 18/05/16 17:35, 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?

Not necessarily, if what they do ends up damaging innocent parties due
to lack of sufficient information.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[tech29063]

On Friday, May 20, 2016 at 2:09:42 AM UTC-7, Ben Laurie wrote:

> > 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."
> 
> I've tried a few times to find these readily accessible instructions
> for any CA whatsoever. Do they exist? Where are Trend Micro's, for
> example?

http://www.trendmicro.com/us/enterprise/cloud-solutions/deep-security/ssl-certificates/#support

PROBLEM REPORTING

If you need to revoke a certificate issued by Trend Micro SSL or if you want to 
report a problem with a site secured by a Trend Micro SSL certificate, please 
send details about the problem to ssl_supp...@trendmicro.com.

By the way, I no longer work for Trend Micro
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[tech29063]

Matt, that's a bit harsh, and you are all over the map.  I was only responding 
to Kathleen's questions, which asked what do the current BRs require CAs to do 
when they receive reports of SSL certificates issued to malware injection 
sites.  I was not proposing any new rules or any new interpretations of the 
existing rules -- I was explaining what the existing rules say, and how CAs 
(including the ones I have worked for) have applied them for many years (I 
believe these rules were first adopted, with the concurrence of all the 
browsers, in 2008 as part of the EV Guidelines).  I was also pointing out that 
with the commendable adoption of ssl-everywhere, we all face new challenges as 
fraudsters are forced to use SSL, and use it to hide malware from user security 
software.

If you don't like the current BR rules, you are free to argue for change.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[tech29063]

Andrew - As I outlined in my message above, the BRs cover two distinct 
situations: (1) when must CAs revoke certs that have already been issued for 
“Certificate misuse, or other types of fraud, compromise, misuse, or 
inappropriate conduct related to Certificates,” and (2) when CAs must refuse to 
issue because their High Risk Certificate Request checking algorithms indicate 
the subscriber should not receive a new certificate.

Kathleen’s questions cover both situations (1) and (2):

== Questions == 

   1) What does "Certificate misuse, or other types of fraud" in the definition 
of Certificate Problem Report actually mean? [KH - This relates to revocation 
of an issued certificate]

   2) What does "misused" mean in Section 4.9.1.1? [KH - This relates to 
revocation of an issued certificate]

   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 - This relates to 
revocation of an issued certificate]

   4) Does a website who is known to an issuing CA to inject malware count as 
high risk? [This relates to refusal to issue a new certificate to a subscriber 
based on known bad acts, not possible identity confusion in a name like 
“yourfacebookpage123.net” that is properly registered to a hacker.]

   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? [This 
relates to refusal to issue a new certificate to a subscriber based on known 
bad acts, not possible identity confusion in a name like 
“yourfacebookpage123.net” that is properly registered to a hacker.]

Your main concern – unjustified delay in issuing a certificate to your customer 
while a human looks at the domain to decide if there is a problem - is not 
really related to any of Kathleen’s questions.  Your other comments express 
what you think the role of a CA *should* be, but don’t address what the current 
BRs actually require CAs to do (which is what Kathleen was asking).

I think it’s a huge mistake to leave all user protection solely o software 
processing features like Microsoft SmartScreen and Google Safe Browsing.  
First, there are millions of users around the world who will not be protected 
by such features.  Second, who knows what really goes in to these software 
processing features – and who knows if a malware site known to the CA who 
issued a cert for the site will ever be reported by the CA to all the possible 
software applications used around the world.  

When a certificate is used to hide malware from users and prevent their 
security software from detecting the malware, that certificate should be 
revoked by the issuing CA once it receives credible information that the 
certificate is being used by a malware site (after the CA receives no timely or 
adequate response from the subscriber when asked about the report).  That’s the 
first line of defense for users.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Matt Palmer]

Well said, Andrew.  You've summarised the issue excellently.

- Matt

On Thu, May 19, 2016 at 03:19:13PM -0700, Andrew Ayer wrote:
> Kathleen,
> 
> I believe that certificate authorities should be content-neutral.  They
> should not be required to assess "misuse" or "fraud," nor be required
> to revoke certificates except upon request of the owner of a domain
> listed in the certificate.
> 
> Requiring CAs to police website content is incompatible with Mozilla's
> goal of deprecating non-secure HTTP.  Requiring HTTPS for all sites is
> only attainable if all sites can easily obtain certificates, and
> content policing by CAs undermines that.  As the operator of an
> automated certificate reseller, I have witnessed countless cases of
> certificate authorities flagging certificate requests as "High Risk"
> due to the DNS name being supposedly similar to a popular brand name.
> Without exception, every time has been a false positive.  The best
> outcome is a multi-hour delay as a human reviews the website, and the
> worst outcome is an outright rejection of the request.  Either way, it
> creates uncertainty: you don't know if or when you can get a
> certificate, which makes it hard to automate certificate deployment,
> which makes it hard to deploy HTTPS.  Given that CAs have only the
> DNS name on which to base their decision, a high false positive rate
> seems inevitable.
> 
> Requiring CAs to revoke certificates based on website content creates
> another way for websites to be taken offline.  What recourse does a
> site operator have when their certificate is erroneously revoked by a
> CA?  How can websites that host user-uploaded content operate? These
> are difficult questions which will need adequate answers if HTTPS is to
> become mandatory for all websites.  It would be much better if CAs
> weren't required to police content and instead focused solely on what
> certificates are meant to do: certify that a public key belongs to a
> particular entity.
> 
> Protecting users from malicious content should be left to the
> software processing the content (e.g. Firefox), which can do a better
> job than a CA ever could.  Firefox already uses Google Safe Browsing to
> protect users from phishing and malware.  It works for content
> delivered over both HTTPS and HTTP, doesn't suffer from the multi-day
> delay inherent with certificate revocation, and can operate on a
> per-file level, using the URL or the hash of the file.  Thus, a known
> malware file can be blocked even when it appears on a brand new domain,
> and if only a single file on a domain is malicious, only that file is
> blocked instead of the entire site, which would cause collateral damage
> in the case of a site like GitHub which serves user-uploaded content.
> 
> Regards,
> Andrew
> -- 
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 

-- 
If someone tells you to forward an e-mail to all your friends, please -
forget that I'm your friend.  If you don't, I will.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Andrew Ayer]

On Tue, 17 May 2016 03:19:22 +
Peter Gutmann  wrote:

> Matt Palmer  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?

I suspect that the vast majority of users have no idea what a CA is and
thus have no expectations for what they should do.

> 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.

This may be the case, but this would be an argument for changing the UI
to avoid giving this misleading impression.  For instance, HTTPS could
be displayed with a neutral indication, and HTTP with an insecure
indication.

(Note that the padlock is misleading *today*, because even with CAs'
current efforts to police content, it's easy to serve malware over
HTTPS.  Even if the CA revokes the cert, the attacker can circumvent
the revocation for days by stapling a valid OCSP response.)

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Andrew Ayer]

Kathleen,

I believe that certificate authorities should be content-neutral.  They
should not be required to assess "misuse" or "fraud," nor be required
to revoke certificates except upon request of the owner of a domain
listed in the certificate.

Requiring CAs to police website content is incompatible with Mozilla's
goal of deprecating non-secure HTTP.  Requiring HTTPS for all sites is
only attainable if all sites can easily obtain certificates, and
content policing by CAs undermines that.  As the operator of an
automated certificate reseller, I have witnessed countless cases of
certificate authorities flagging certificate requests as "High Risk"
due to the DNS name being supposedly similar to a popular brand name.
Without exception, every time has been a false positive.  The best
outcome is a multi-hour delay as a human reviews the website, and the
worst outcome is an outright rejection of the request.  Either way, it
creates uncertainty: you don't know if or when you can get a
certificate, which makes it hard to automate certificate deployment,
which makes it hard to deploy HTTPS.  Given that CAs have only the
DNS name on which to base their decision, a high false positive rate
seems inevitable.

Requiring CAs to revoke certificates based on website content creates
another way for websites to be taken offline.  What recourse does a
site operator have when their certificate is erroneously revoked by a
CA?  How can websites that host user-uploaded content operate? These
are difficult questions which will need adequate answers if HTTPS is to
become mandatory for all websites.  It would be much better if CAs
weren't required to police content and instead focused solely on what
certificates are meant to do: certify that a public key belongs to a
particular entity.

Protecting users from malicious content should be left to the
software processing the content (e.g. Firefox), which can do a better
job than a CA ever could.  Firefox already uses Google Safe Browsing to
protect users from phishing and malware.  It works for content
delivered over both HTTPS and HTTP, doesn't suffer from the multi-day
delay inherent with certificate revocation, and can operate on a
per-file level, using the URL or the hash of the file.  Thus, a known
malware file can be blocked even when it appears on a brand new domain,
and if only a single file on a domain is malicious, only that file is
blocked instead of the entire site, which would cause collateral damage
in the case of a site like GitHub which serves user-uploaded content.

Regards,
Andrew
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[kirkhallpdx]

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 

Re: SSL Certs for Malicious Websites

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Richard Z]

On Tue, May 17, 2016 at 01:04:28AM +, 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Matt Palmer]

On Wed, May 18, 2016 at 04:35:49PM +, 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


signature.asc
Description: Digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[josh]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Eric Mill]

On Wed, May 18, 2016 at 9:35 AM, Ben Wilson <ben.wil...@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



>
> -Original Message-
> From: dev-security-policy
> [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On
> Behalf Of Peter Bowen
> Sent: Wednesday, May 18, 2016 9:23 AM
> To: Gervase Markham <g...@mozilla.org>
> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Kathleen Wilson
> <kwil...@mozilla.com>
> Subject: Re: SSL Certs for Malicious Websites
>
> On Wed, May 18, 2016 at 7:16 AM, Gervase Markham <g...@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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>


-- 
konklone.com | @konklone <https://twitter.com/konklone>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Peter Bowen]

On Wed, May 18, 2016 at 7:16 AM, Gervase Markham  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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  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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> 

-- 
Roland Bracewell Shoemaker
Software Engineer
Linux Foundation / Internet Security Research Group
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Eric Mill]

On Mon, May 16, 2016 at 8:24 AM, Ben Wilson  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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>


-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Hubert Kario]

On Tuesday 17 May 2016 03:19:22 Peter Gutmann wrote:
> Matt Palmer  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).

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

signature.asc
Description: This is a digitally signed message part.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SSL Certs for Malicious Websites

[Peter Gutmann]

Matt Palmer  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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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


--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: SSL Certs for Malicious Websites

[Ben Wilson]

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.)


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Peter Bowen]

On Mon, May 16, 2016 at 6:06 AM, Rob Stradling  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[Rob Stradling]

On 16/05/16 01:43, 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:


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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: SSL Certs for Malicious Websites

[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


On Sun, May 15, 2016 at 5:13 PM, Kathleen Wilson  wrote:
> 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