Hi David,

I am the author of the research discussed in that Bleeping Computer post..

Your post is a bit brief, so I'm not sure if you are just sharing news, or
wanted to discuss a certain aspect of this story or topic.

So I will just share some general thoughts:

1. The most important thing to note is that Let's Encrypt has not violated
any issuance requirements by issuing these certificates.

The debate over malicious sites using SSL is certainly a popular topic, and
while many regularly discuss whether this is right or wrong,  there is no
such ambiguity in policy.

The CA/B Forum's Baseline Requirements (which set forth issuance practices
for CAs) do *not* forbid issuing certificates to phishing sites, or require
certificates for such sites to be revoked.

There is a section in the Baseline Requirements (BRs) about "high-risk"
certificate requests, which some cite and interpret as applying to this
situation. However, that section of the BRs is incredibly vague and does
not lay out any specific requirements.

The only relevant requirements a CA may need to follow would come from a
root program. For instance, Microsoft's root program includes a stipulation
that they may request a CA to revoke a certificate.

I don't think it's publicly known how often Microsoft exercises that rule.
But I am not aware of any cases where Let's Encrypt has ignored such
requests, and I highly doubt they would as the risks to their organization
would be obvious.

2. The topic of malicious certs has been thoroughly discussed by the
industry. These discussions have already taken place on this list, such as
this one:


Not to be rude to anyone, but I strongly suggest reading that those before
starting off on a new discussion, as most points have already been made and

3. After reading (and participating) in many discussions about the use of
SSL on malicious sites and CAs "policing" the content/purpose of websites,
it is clear to me that this is an issue that we will never come to an
ideological consensus on as an industry. So we must defer to the rules,
which do not forbid such a practice and are unlikely to ever be changed.

While I personally believe there are some changes that could be made to
improve current practices, it is more important to recognize that this is
simply an area where meaningful cooperation is not possible. Instead of
using up more time (and stressing relationships) on this debate, we should
look to make improvements in other areas of Web PKI where we can find

I think my research is useful in quantifying and showing the scale of SSL
use on phishing sites; and for security UX/user safety/user education
discussions, I think this should be considered. But overall, I hope that
people will not re-start a debate here over whether Let's Encrypt should be
dis-trusted or whether its acceptable to issue such certificates.

On Sun, Mar 26, 2017 at 1:14 PM Adam Caudill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Much has been written about this issue of late; most of the focus has been
> on Let's Encrypt, but they are not the only CA issuing certificates to
> phishing sites, though because of the scale Let's Encrypt operates at, they
> issue the most, and thus take most of the heat.
> One of the better articles on the topic is this one by Scott Helme, which
> is well worth reading:
> https://scotthelme.co.uk/lets-encrypt-are-enabling-the-bad-
> guys-and-why-they-should/
> DV certificates only prove control of a domain, not who operates it, or if
> it should be trusted. To try to read anything more into it is a mistake;
> this applies to all CAs issuing DV certificates, not just those issued by
> Let's Encrypt.
> The goal many share is to achieve near-ubiquitous TLS use to minimize
> insecure traffic as much as possible. To achieve that goal, the barrier to
> entry needs to be minimal, which means freely available DV certificates.
> Let's Encrypt issues certificates to anyone that can prove control of a
> domain (with few restrictions), and as with most other forms of secure
> communications, this means not everyone that uses it will have honest
> intentions. That is simply the cost of achieving ubiquitous encryption.
> Some have suggested a significant change to how browsers display status:
> display a warning for HTTP, and show HTTPS with a DV certificate as neutral
> (handling of OV & EV certificates in such an arrangement is more
> contentious). This would help to eliminate the erroneous feeling some have
> that certificates impart trust.
> On Sun, Mar 26, 2017 at 11:53 AM David E. Ross via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > The subject is the title of a Slashdot article posted today.  The
> > article can be accessed at
> > <
> > https://it.slashdot.org/story/17/03/25/2222246/over-14k-
> lets-encrypt-ssl-certificates-issued-to-paypal-phishing-sites
> > >.
> >
> >
> > The article contains two links.  One is to a Bleeping Computer article
> > that gives more detail.
> >
> > The other link is to a Let's Encrypt page where that certification
> > authority states:> Let’s Encrypt is going to be issuing Domain
> > Validation (DV)
> > > certificates. On a technical level, a DV certificate asserts that a
> > > public key belongs to a domain – it says nothing else about a site’s
> > > content or who runs it. DV certificates do not include any
> > > information about a website’s reputation, real-world identity, or
> > > safety. To me, this means that certificates can be freely issued to
> > criminal
> > enterprises.
> >
> > --
> > David E. Ross
> > <http://www.rossde.com>
> >
> > Consider:
> > *  Most state mandate that drivers have liability insurance.
> > *  Employers are mandated to have worker's compensation insurance.
> > *  If you live in a flood zone, flood insurance is mandatory.
> > *  If your home has a mortgage, fire insurance is mandatory.
> >
> > Why then is mandatory health insurance so bad??
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy
> >
> --
> --*Adam Caudill*
> http://adamcaudill.com
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
dev-security-policy mailing list

Reply via email to