Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Gervase Markham]

There is an entry on Mozilla's Potentially Problematic CA Practices list
for Wildcard DV certs:
https://wiki.mozilla.org/CA:Problematic_Practices#Wildcard_DV_SSL_Certificates

This text was added by Frank Hecker when this page was very new back in
2008, and has been basically unchanged since then:
https://wiki.mozilla.org/index.php?title=CA:Problematic_Practices&diff=92109&oldid=92084

I don't believe the issuance of wildcard DV certs is problematic in
practice. Mozilla is of the view that ubiquitous SSL is the highest
priority for the Web PKI, and wildcard certs are a part of that. Mozilla
also doesn't believe that it's the job of CAs to police phishing, which
is the concern raised.

I propose this section be removed from the document.

Gerv

[Alex Gaynor]

+1 on removal, that paragraph doesn't square with current ideas about
what's problematic in the WebPKI; as you've noted wildcards and DV are
really orthogonal concerns.

Alex

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

[Matt Palmer]

On Thu, Apr 20, 2017 at 02:02:59PM +0100, Gervase Markham via dev-security-policy wrote:
> I propose this section be removed from the document.

My name is Matt Palmer, and I endorse this proposal.

<fx: waving flag, fade to black>

- Matt

[Eric Mill]

Major +1. Removing this language is consonant with Mozilla objectives, with
Web PKI trends, and with the health of the open web.

-- Eric

On Thu, Apr 20, 2017 at 9:02 AM, Gervase Markham via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> There is an entry on Mozilla's Potentially Problematic CA Practices list
> for Wildcard DV certs:
> https://wiki.mozilla.org/CA:Problematic_Practices#
> Wildcard_DV_SSL_Certificates
>
> This text was added by Frank Hecker when this page was very new back in
> 2008, and has been basically unchanged since then:
> https://wiki.mozilla.org/index.php?title=CA:Problematic_Practices&diff=
> 92109&oldid=92084
>
> I don't believe the issuance of wildcard DV certs is problematic in
> practice. Mozilla is of the view that ubiquitous SSL is the highest
> priority for the Web PKI, and wildcard certs are a part of that. Mozilla
> also doesn't believe that it's the job of CAs to police phishing, which
> is the concern raised.
>

> I propose this section be removed from the document.
>

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

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

[Nick Lamb]

On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham wrote:
> I propose this section be removed from the document.

I am not so sure the section ought to be removed. Wildcard DV is potentially problematic. Historically we have seen problems that wouldn't have happened or would be much less serious without Wildcard DV issuance. In particular because domain "validation" for the wildcard is sketchy.

While of course the Ballot 169 rules are a big improvement, I'm really not sure I'm comfortable with the implication today that well, we did one of the Ballot 169 checks for example.com, so now we'll issue for *.example.com and everything is just fine.

I'm not so uncomfortable with it that I want Mozilla to try to get it stopped, but I think signalling some residual discomfort here is worthwhile until somebody has thought through a good policy, and preferably at least got the big CAs to go along with it in principle even if we don't have it in formal Mozilla policy or the BRs.

[Henri Sivonen]

On Thu, Apr 20, 2017 at 4:02 PM, Gervase Markham via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
> I don't believe the issuance of wildcard DV certs is problematic in
> practice. Mozilla is of the view that ubiquitous SSL is the highest
> priority for the Web PKI, and wildcard certs are a part of that. Mozilla
> also doesn't believe that it's the job of CAs to police phishing, which
> is the concern raised.
>

> I propose this section be removed from the document.

I support this proposal.

To get code isolation in a browser, you have to have different origins
for the things you are isolating from each other. A security system
(like Sandstorm.io) can mint new origins by minting hostnames. Even
with ACME, getting a non-wildcard cert for each throw-away
on-demand-minted hostname doesn't make sense in terms of CA latency
and CA rate limits.

A wildcard cert solves this, and the solution should be broadly
available (not just to those who pay for OV).

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Gervase Markham]

On 21/04/17 10:12, Nick Lamb wrote:
> I'm not so uncomfortable with it that I want Mozilla to try to get it
> stopped, but I think signalling some residual discomfort here is
> worthwhile until somebody has thought through a good policy, and
> preferably at least got the big CAs to go along with it in principle
> even if we don't have it in formal Mozilla policy or the BRs.

This is all a bit inchoate :-) Can you give me any idea at all of what
such a policy would look like? Requiring OV is not an option IMO.

Are we going to do anything differently, today, for a CA who issues DV
wildcard certs compared to one who is not? I don't believe so. And if
that's the case, I can't see any value in having this issue on the list.

Gerv

[Nick Lamb]

On Friday, 21 April 2017 11:02:01 UTC+1, Gervase Markham wrote:
> This is all a bit inchoate :-) Can you give me any idea at all of what
> such a policy would look like? Requiring OV is not an option IMO.

Yes, it's inchoate, if I had a fully filled out policy in mind here I'd be proposing that policy, rather than expressing my concern that just removing this from the problematic list isn't solving a real problem.

I have no interest in requiring OV for wildcards. The two things have nothing to do with each other, so that wouldn't make any sense.

Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate for verifying that the applicant controls the entire domain and thus *.example.com, whereas say 3.2.2.4.6 proves only that the applicant controls a web server, it seems quite likely they have neither the legal authority nor the practical ability to control servers with other names in that domain. I can see arguments either way for 3.2.2.4.4, depending on how well email happens to be administrated in a particular organisation.

That adds up to an opportunity for someone to get a nasty surprise, one rogue employee at a cheap shared host can turn their ability to pass 3.2.2.4.6 for a brochureware site on www.example.com into a working *.example.com wildcard that can MitM SMTP, HTTPS-based APIs, VPNs, any sort of TLS traffic at all into any name in example.com.

[Matt Palmer]

On Fri, Apr 21, 2017 at 04:09:57AM -0700, Nick Lamb via dev-security-policy wrote:
> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate for
> verifying that the applicant controls the entire domain and thus
> *.example.com, whereas say 3.2.2.4.6 proves only that the applicant
> controls a web server, it seems quite likely they have neither the legal
> authority nor the practical ability to control servers with other names in
> that domain. I can see arguments either way for 3.2.2.4.4, depending on
> how well email happens to be administrated in a particular organisation.
>
> That adds up to an opportunity for someone to get a nasty surprise, one
> rogue employee at a cheap shared host can turn their ability to pass
> 3.2.2.4.6 for a brochureware site on www.example.com into a working
> *.example.com wildcard that can MitM SMTP, HTTPS-based APIs, VPNs, any
> sort of TLS traffic at all into any name in example.com.

Didn't a CA get caught fairly recently issuing certs with sAN:example.com
when the validation was for www.example.com, and got a stern talking to as a
result? I vaguely recall something about that, but not with enough detail
to trawl the archives looking for it.

At any rate, I don't believe the BRs permit such an issuance. At most, if
someone demonstrated control of www.example.com they would be able to get a
cert for sAN:*.www.example.com (which is still not great, but not quite the
complete disaster getting one for sAN:*.example.com would be). If your read
of the BRs indicates otherwise, I'd be interested in your reasoning.

That being said, I certainly agree that demonstrating control of a website
is not *nearly* the same thing as demonstrating control over DNS, and I
wouldn't be a sad panda if demonstrating control over a website didn't
permit wildcard issuance. Perhaps Mozilla policy (or the BRs) could
differentiate between "wildcard-permitted" vs "literal FQDN only" validation
methods? That would, presumably, be applied independent of DV/OV validation
grade.

- Matt

[Matt Palmer]

On Fri, Apr 21, 2017 at 02:12:51AM -0700, Nick Lamb via dev-security-policy wrote:
> On Thursday, 20 April 2017 14:03:36 UTC+1, Gervase Markham wrote:

> > I propose this section be removed from the document.
>

> I am not so sure the section ought to be removed. Wildcard DV is
> potentially problematic. Historically we have seen problems that wouldn't
> have happened or would be much less serious without Wildcard DV issuance.
> In particular because domain "validation" for the wildcard is sketchy.

Can you remind me (and the list) what specific instances you're referring
to?

- Matt

--
A woman in liquor production / Owns a still of exquisite construction.
The alcohol boils / Through magnetic coils.
She says that it's "proof by induction."
-- http://limerickdb.com/?34

[Nick Lamb]

On Saturday, 22 April 2017 02:24:50 UTC+1, Matt Palmer wrote:
> Can you remind me (and the list) what specific instances you're referring
> to?

I was thinking of things like the GoDaddy incident reported in January where they had mistakenly been accepting HTTP 404s to validate a domain or the 2016 Comodo "re-dressing" attack where a bad guy could arrange for your contact to get emails from Comodo saying they need to click a button to prevent an SSL certificate being issued, but actually clicking will cause it to be issued to the attacker...

In such cases bad guys can get a wildcard rather than validation just for one affected name, and that makes their life much easier.

Going further back DigiNotar was made worse by the certificate being issued for *.google.com, not to say it wasn't bad enough to have bad guys essentially issuing whatever they wanted from a trusted CA.

Also whenever we see people blaming the issuer for phishing sites protected by SSL, a wildcard would of course let its subscriber create any number of phishing sites, without any oversight of the names used prior to issuance. I happen to think that's fine, but it wouldn't even be a factor without wildcards.

[Ryan Sleevi]

On Sun, Apr 23, 2017 at 7:41 AM, Nick Lamb via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:
>
> I was thinking of things like the GoDaddy incident reported in January
> where they had mistakenly been accepting HTTP 404s to validate a domain or
> the 2016 Comodo "re-dressing" attack where a bad guy could arrange for your
> contact to get emails from Comodo saying they need to click a button to
> prevent an SSL certificate being issued, but actually clicking will cause
> it to be issued to the attacker...
>
> In such cases bad guys can get a wildcard rather than validation just for
> one affected name, and that makes their life much easier.
>

Are you talking per-certificate? Because the validation method is used for
the domain namespace can be applied to the subdomains.

> Going further back DigiNotar was made worse by the certificate being
> issued for *.google.com, not to say it wasn't bad enough to have bad guys
> essentially issuing whatever they wanted from a trusted CA.
>

Right, that's the high-order bit: Wildcards would not have changed that
situation at all. They also did *.*.com, so it's not like that's a strike
against wildcards.

We have to remember that attacks target the weakest link, and that link
isn't wildcards, under any of the present or (unfortunately) proposed
validation methods.

> Also whenever we see people blaming the issuer for phishing sites
> protected by SSL, a wildcard would of course let its subscriber create any
> number of phishing sites, without any oversight of the names used prior to
> issuance. I happen to think that's fine, but it wouldn't even be a factor
> without wildcards.

Well, again, that's mistating that there is any oversight today. There
isn't - nothing formalized or normalized, it's ad-hoc, CA defined
procedures. Considering that CAs are deciding that violating the BRs by
doing things like cross-signing unaudited sub-CAs because they determined
"there wouldn't be any risk" because of contractual prohibitions, I hope we
can see that the argument that CAs are technically capable and cognizant,
to the same level, across the industry, is uh... wishful thinking :)

[Gervase Markham]

On 21/04/17 12:09, Nick Lamb wrote:
> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate
> for verifying that the applicant controls the entire domain and thus
> *.example.com, whereas say 3.2.2.4.6 proves only that the applicant
> controls a web server, it seems quite likely they have neither the
> legal authority nor the practical ability to control servers with
> other names in that domain. I can see arguments either way for
> 3.2.2.4.4, depending on how well email happens to be administrated in
> a particular organisation.

So your concern is that a subset of the 10 Blessed Methods might not be
suitable for verifying the level of control necessary to safely issue a
wildcard cert?

If that's true, we should look at it, but I don't see how that's
connected with saying or not saying on our wiki page that wildcard certs
are inherently problematic.

So, to analyse: you are saying that demonstrating control over
http://www.example.com/ and getting a cert for *.www.example.com is
shaky? Or demonstrating control of http://example.com/ and getting a
cert for *.example.com? Or something else?

Gerv

[Gervase Markham]

On 22/04/17 02:23, Matt Palmer wrote:
> Didn't a CA get caught fairly recently issuing certs with sAN:example.com
> when the validation was for www.example.com, and got a stern talking to as a
> result? I vaguely recall something about that, but not with enough detail
> to trawl the archives looking for it.

Yes, it was WoSign.
https://wiki.mozilla.org/CA:WoSign_Issues#Issue_N:_Additional_Domain_Errors_.28June_2015.29
Bug N1.

Gerv

[Peter Kurrasch]

Wildcard certs present a level of risk that is different (higher?) than for other end-entity certs.‎ The risk as I see it is two-fold:

1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is no clear way to extrapolate a successful validation for one domain into a plethora of FQDN's in a way that works for all scenarios. So the risk in this sense is that the issuer might allow a cert requester to over-subscribe a given domain's name space.

2) Abuse: Once the wildcard cert has been issued there is no way to check that the host (or FQDN) to which I'm connecting is a legitimate part of the broader domain or if it has been taken over for nefarious purposes. This is in contrast to the non-wildcard case wherein I know it's a legitimate part because I see the FQDN listed explicitly in the SAN field. So the risk in this sense is to the relying party who is less able to protect himself or herself from connecting to bad servers.

The use of "problematic" to describe wildcard certs is perhaps misleading. Perhaps the wildcard‎ certs themselves are not problematic but trying to manage or mitigate the risk they pose is. Either way, I don't think it would be wise to remove this from the problematic practices list.

‎

From: Gervase Markham via dev-security-policy Sent: Monday, April 24, 2017 4:16 AM‎

On 21/04/17 12:09, Nick Lamb wrote:

> Of the ballot 169 methods, 3.2.2.4.7 is most obviously appropriate
> for verifying that the applicant controls the entire domain and thus
> *.example.com, whereas say 3.2.2.4.6 proves only that the applicant
> controls a web server, it seems quite likely they have neither the
> legal authority nor the practical ability to control servers with
> other names in that domain. I can see arguments either way for
> 3.2.2.4.4, depending on how well email happens to be administrated in
> a particular organisation.

So your concern is that a subset of the 10 Blessed Methods might not be
suitable for verifying the level of control necessary to safely issue a
wildcard cert?

If that's true, we should look at it, but I don't see how that's
connected with saying or not saying on our wiki page that wildcard certs
are inherently problematic.

So, to analyse: you are saying that demonstrating control over
http://www.example.com/ and getting a cert for *.www.example.com is
shaky? Or demonstrating control of http://example.com/ and getting a
cert for *.example.com? Or something else?

Gerv

[Ryan Sleevi]

On Tue, Apr 25, 2017 at 1:31 AM, Peter Kurrasch via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> Wildcard certs present a level of risk that is different (higher?) than
> for other end-entity certs.‎ The risk as I see it is two-fold:
>

> 1) Issuance: Setting aside the merits of the 10 Blessed Methods, there is
> no clear way to extrapolate a successful validation for one domain into a
> plethora of FQDN's in a way that works for all scenarios. So the risk in
> this sense is that the issuer might allow a cert requester to
> over-subscribe a given domain's name space.
>

See the discussion in the CA Browser Forum regarding 3.2.2.4 and "Domain
Namespace". There's an arguable interpretation that allows for a single
domain validation and an unlimited number of certificates for an arbitrary
number of subdomains.

>
> 2) Abuse: Once the wildcard cert has been issued there is no way to check
> that the host (or FQDN) to which I'm connecting is a legitimate part of the
> broader domain or if it has been taken over for nefarious purposes. This is
> in contrast to the non-wildcard case wherein I know it's a legitimate part
> because I see the FQDN listed explicitly in the SAN field. So the risk in
> this sense is to the relying party who is less able to protect himself or
> herself from connecting to bad servers.
>

I'm not sure I understand this point. Of course it's legitimate - as it's
part of the subdomain. Could you expand further what you see as wrong here?

[Peter Kurrasch]

Hi Ryan--

To your first comment, I'm afraid I won't have the time to take a closer look at the discussion on 3.2.2.4. Hopefully a path from single domain to unlimited domains exists (or will). It makes sense to me (without fully considering the consequences) that a "special" validation path be used for wildcards. Perhaps it could be part of an existing validation method, I'm not sure. Bottom line though, I don't think it makes sense that anyone and everyone be allowed to obtain a wildcard cert.

As for the subdomain stuff, I was hoping to avoid providing some examples because I couldn't come up with a simple one. However, I think it's necessary so let's try this out:

Let's suppose we break up everyone with a server on the Internet into 3 categories based on the size of their Internet presence: substantial, intermediate, and tiny. A "substantial" presence almost certainly has a large enterprise behind it with staff and capital resources to maintain the service. If we can assume that such organizations have tighter controls over use of the domain name space, servers, certificates, and so forth, then I think some of the risks posed by wildcard certs are reduced. That being the case, I'm less concerned about this category.

For an "intermediate" presence, I'm thinking of places like universities that have a large number of subdomains in use but might not have a good set of controls over use of the domain name space and certificates and so forth. In this type of setting I think the use of wildcards might be appealing because it simplifies management of the network but if the controls are not in place, there remains a certain level of risk that these certs pose. (And to be fair, this isn't to say that only academic environments face this situation or that all academic environments are not suitably managed.) This category can be of concern.

The "tiny" category almost speaks for itself and probably applies to all individuals and small businesses--people who want some presence but might not be all that diligent about it. In other words, these are the systems that probably have the weakest security measures in place. These are the systems that are regularly compromised and used for spam campaigns, fake login screens, and such. This is also the category for whom wildcard certs pose the greatest risk‎ to everyone else.

Consider a case where someone has a custom domain--let's say easypete.ninja--and perfectly reasonable subdomains. So:

 - easypete.ninja

 ‎- www.easypete.ninja

 - email.easypete.ninja

Clearly there is a slight advantage for a wildcard cert in this case--it's easier than listing those subdomains. However, a wildcard cert opens up the possibility for other things like:

 - com.easypete.ninja

 - paypal.com.easypete.ninja

 - google.com.easypete.ninja

 - <random characters>.easypete.ninja

 - facebook.com.loginassistant.easypete.ninja

...and all sorts of variants of the above.‎ Per the wildcard cert, all of the above domains are perfectly valid. Per the actual intent of th‎e domain holder, most of the above are surely not valid.

So, the problem becomes how a relying party may determine if the site/domain is legitimate. If I have some indicator in the browser UI that says "secure" because the FQDN matching has been satisfied, I'll probably proceed to use the page that is presented. If the indicator is missing, there is a chance I'll think twice about proceeding any further. The trouble in this situation is that if the FQDN is nefarious but satisfies the wildcard contained in the cert, I will probably make the wrong decision and open myself up to who knows what.

[Ryan Sleevi]

On Wed, Apr 26, 2017 at 3:17 PM, Peter Kurrasch <fhw...@gmail.com> wrote:

> Hi Ryan--
>
> To your first comment, I'm afraid I won't have the time to take a closer
> look at the discussion on 3.2.2.4. Hopefully a path from single domain to
> unlimited domains exists (or will). It makes sense to me (without fully
> considering the consequences) that a "special" validation path be used for
> wildcards. Perhaps it could be part of an existing validation method, I'm
> not sure. Bottom line though, I don't think it makes sense that anyone and
> everyone be allowed to obtain a wildcard cert.
>

Right, but there's definitely a more careful argument you'll need to make,
because that is _precisely_ what is (effectively) desired, not just by CAs,
but most users of more than a few TLS certificates.

I'm not even sure that I disagree with you - my history in the CA/Browser
Forum hopefully demonstrates Google's deep concern with the security of the
validation methods, the capabilities possible with each validation method,
and the frequency of which they're performed. However, finding consensus
is, at this point, difficult, despite it being plainly obvious to folks
with a security background :)

For context, I've been pushing for exploring CAA methods to reduce the
permissible validation methods, and CAA already has the ability to restrict
wildcard issuance via issuewild to set a of CAs, for which you can then
establish a defined procedure. So if your concern is helping protect a
_competent_ organization from a rogue wildcard, that already exists and is
(in the process of) being required.

Let's suppose we break up everyone with a server on the Internet into 3
> categories based on the size of their Internet presence: substantial,
> intermediate, and tiny. A "substantial" presence almost certainly has a
> large enterprise behind it with staff and capital resources to maintain the
> service. If we can assume that such organizations have tighter controls
> over use of the domain name space, servers, certificates, and so forth,
> then I think some of the risks posed by wildcard certs are reduced. That
> being the case, I'm less concerned about this category.
>

Regrettably, I think this inverts the priority. "substantial" presence are
often the slowest to deploy, have the most complexity in their
infrastructure, and similarly, suffer the greatest risk from a rogue
wildcard.

> For an "intermediate" presence, I'm thinking of places like universities
> that have a large number of subdomains in use but might not have a good set
> of controls over use of the domain name space and certificates and so
> forth. In this type of setting I think the use of wildcards might be
> appealing because it simplifies management of the network but if the
> controls are not in place, there remains a certain level of risk that these
> certs pose. (And to be fair, this isn't to say that only academic
> environments face this situation or that all academic environments are not
> suitably managed.) This category can be of concern.
>

This is most organizations :)

> The "tiny" category almost speaks for itself and probably applies to all
> individuals and small businesses--people who want some presence but might
> not be all that diligent about it. In other words, these are the systems
> that probably have the weakest security measures in place. These are the
> systems that are regularly compromised and used for spam campaigns, fake
> login screens, and such. This is also the category for whom wildcard certs
> pose the greatest risk‎ to everyone else.
>

I disagree that you can attribute that cost to wildcards. That's the cost
of the organization itself. The wildcard doesn't really contribute or
change that calculus.

> ...and all sorts of variants of the above.‎ Per the wildcard cert, all of
> the above domains are perfectly valid. Per the actual intent of th‎e domain
> holder, most of the above are surely not valid.
>

CAA solves that ;)

> So, the problem becomes how a relying party may determine if the
> site/domain is legitimate. If I have some indicator in the browser UI that
> says "secure" because the FQDN matching has been satisfied, I'll probably
> proceed to use the page that is presented. If the indicator is missing,
> there is a chance I'll think twice about proceeding any further. The
> trouble in this situation is that if the FQDN is nefarious but satisfies
> the wildcard contained in the cert, I will probably make the wrong decision
> and open myself up to who knows what.
>

But that's no different than shopping Target or Home Depot and their credit
card processor / POS terminal being compromised, is it? You trusted an
organization with an insufficient security practice relative to the threats
faced. We don't say credit cards caused Target to be hacked though!

[okaphone.e...@gmail.com]

I think this is getting weird.

At first (some other thread) it get's explained that e.g. LetsEncrypt does not do anything beyond domain validation and possibly on notification take down a few certificates of phishing site. And that was "... all OK because we want SSL to be used everywhere, and anyway domain validation means just that, nothing more..."

And now you guys are suddenly seeing problems in wild card certificates "... because it could be use for phishing..." Ehm, what?

Our site (category tiny) has LetsEncrypt certificates on several domain names and a single Comodo wildcard certificate for okaphone.com,*okaphone.com. We currently have the following set of domain names in the global DNS:

klant.okaphone.com
munin.okaphone.com
hans.okaphone.com
kassa.okaphone.com
ntp.okaphone.com
okaphone.com
stats.okaphone.com
svn.okaphone.com
vpn.okaphone.com
webcam.okaphone.com
www.okaphone.com

I terminate HTTPS with Pound and distribute the traffic from there to a number of servers (I'll spare you the details ;-). This setup gives me flexibility and it changes regularly for all kinds of reasons that have to do with our business.

I like it this way. Thats why I'm paying Comodo for their services. If you are going to make this kind of thing impossible then you are:

1) Frustrating me.

2) Causing Comodo to lose business, for I will have to use LetsEncrypt instead.

3) Putting all my eggs in one basket (there is currently no alternative for LetsEncrypt).

4) Not solving the problem at all, it's easy to get a certificate for a phishing domain from LetsEncrypt.

5) Trying to do something that certificates are not meant for. I don't think it is (or should be) the responsibility of CA's to verify that sites are not used for phishing.

I'd say, this is not a good idea at all. :-(

CU Hans

[Ryan Sleevi]

On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika--- via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:

> I think this is getting weird.
>
> At first (some other thread) it get's explained that e.g. LetsEncrypt does
> not do anything beyond domain validation and possibly on notification take
> down a few certificates of phishing site. And that was "... all OK because
> we want SSL to be used everywhere, and anyway domain validation means just
> that, nothing more..."
>
> And now you guys are suddenly seeing problems in wild card certificates
> "... because it could be use for phishing..." Ehm, what?
>

Could you point to examples? I think the tone of this thread has almost
universally been consistent with the people who have said phishing isn't
for the CAs :)

> I like it this way. Thats why I'm paying Comodo for their services. If you
> are going to make this kind of thing impossible then you are:
>

Who do you believe "you guys" are?

>
> 1) Frustrating me.
>
> 2) Causing Comodo to lose business, for I will have to use LetsEncrypt
> instead.
>
> 3) Putting all my eggs in one basket (there is currently no alternative
> for LetsEncrypt).
>
> 4) Not solving the problem at all, it's easy to get a certificate for a
> phishing domain from LetsEncrypt.
>
> 5) Trying to do something that certificates are not meant for. I don't
> think it is (or should be) the responsibility of CA's to verify that sites
> are not used for phishing.
>

I think almost everyone on this thread has expressed general agreement :)

I think you may be confusing the phishing discussion (which was only
brought up once or twice) with the general _capability_/_security_
discussion, for which a wildcard certificate has unlimited capability (over
a subdomain), and thus much greater risk, and the desire to balance that
risk.

The risk is not phishing. The risk is incidental effects of compromise.
It's no different than a discussion of compromise of a technically
constrained sub-CA (which is an 'ultra-wildcard') or of an unconstrained
sub-CA/CA itself (which is a 'global-wildcard'). Each level has different
risks, and we want to make sure they're all treated accordingly. Phishing
has not been preeminent among that discussion of risks, and so if that's
your takeaway, I would say the message on this thread has been fairly
consistent in agreeing with you that certs don't solve phishing.

[okaphone.e...@gmail.com]

On Wednesday, 26 April 2017 22:43:19 UTC+2, Ryan Sleevi wrote:

> On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika wrote:
>
> > I think this is getting weird.
> >
> > At first (some other thread) it get's explained that e.g. LetsEncrypt does
> > not do anything beyond domain validation and possibly on notification take
> > down a few certificates of phishing site. And that was "... all OK because
> > we want SSL to be used everywhere, and anyway domain validation means just
> > that, nothing more..."
> >
> > And now you guys are suddenly seeing problems in wild card certificates
> > "... because it could be use for phishing..." Ehm, what?
>
> Could you point to examples? I think the tone of this thread has almost
> universally been consistent with the people who have said phishing isn't
> for the CAs :)

Good, I guess I simplified that to the point of not being correct anymore then. Just read "incidental effects of compromise" where I said phishing. It doesn't change what I'm saying all that much. After all LetsEncrypt can also be abused for this when a site has been compromised. ;-)

> > I like it this way. Thats why I'm paying Comodo for their services. If you
> > are going to make this kind of thing impossible then you are:
>
> Who do you believe "you guys" are?

Well anybody in here in favour of doing away with wildcard certificates. It's a forum, anybody can join the discussion don't they? (Even though "some pigs may be more equal" in this context I expect. ;-)

> > 1) Frustrating me.
> >
> > 2) Causing Comodo to lose business, for I will have to use LetsEncrypt
> > instead.
> >
> > 3) Putting all my eggs in one basket (there is currently no alternative
> > for LetsEncrypt).
> >
> > 4) Not solving the problem at all, it's easy to get a certificate for a
> > phishing domain from LetsEncrypt.
> >
> > 5) Trying to do something that certificates are not meant for. I don't
> > think it is (or should be) the responsibility of CA's to verify that sites
> > are not used for phishing.
>
> I think almost everyone on this thread has expressed general agreement :)
>
> I think you may be confusing the phishing discussion (which was only
> brought up once or twice) with the general _capability_/_security_
> discussion, for which a wildcard certificate has unlimited capability (over
> a subdomain), and thus much greater risk, and the desire to balance that
> risk.
>
> The risk is not phishing. The risk is incidental effects of compromise.
> It's no different than a discussion of compromise of a technically
> constrained sub-CA (which is an 'ultra-wildcard') or of an unconstrained
> sub-CA/CA itself (which is a 'global-wildcard'). Each level has different
> risks, and we want to make sure they're all treated accordingly. Phishing
> has not been preeminent among that discussion of risks, and so if that's
> your takeaway, I would say the message on this thread has been fairly
> consistent in agreeing with you that certs don't solve phishing.

If this is about the possible consequences of compromise, then I'd say you should try to adres that. But please do come up with something that still allows for enough flexibility, so I can arrange the HTTPS everywhere you guys (browsers that is ;-) want so much. At least while there is only a single CA (LetsEncrypt) that offers an alternative for wildcards for a reasonable fixed price.

After all the internet is also about variety isn't it? Seems to me there are not all that much CA's around... I do like the LetsEncrypt initiative but I also do hope they will not become the only choice. :-(

I could live with wildcards that would only work for one DNS level for instance. Would that be an improvement?

CU Hans

[Ryan Sleevi]

On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
dev-security-policy <dev-secur...@lists.mozilla.org> wrote:
>
> If this is about the possible consequences of compromise, then I'd say you
> should try to adres that. But please do come up with something that still
> allows for enough flexibility, so I can arrange the HTTPS everywhere you
> guys (browsers that is ;-) want so much. At least while there is only a
> single CA (LetsEncrypt) that offers an alternative for wildcards for a
> reasonable fixed price.
>

I'm not sure your concern - there's otherwise been broad support for
wildcards, only concerns related to the methods used to validate them to
ensure they're meaningful.

> After all the internet is also about variety isn't it? Seems to me there
> are not all that much CA's around... I do like the LetsEncrypt initiative
> but I also do hope they will not become the only choice. :-(
>
> I could live with wildcards that would only work for one DNS level for
> instance. Would that be an improvement?

They already only work for one DNS level, as a certificate. The
authorization the CA performs, however, lets them issue wildcards for any
number of subordinate subdomains - but only one wildcard in each, and each
certificate only covers a single hierarchy.

I realize that the conversation may be complex here, but I think it might
be best to simply assure you that your concerns are not misunderstood, but
more importantly, they are unwarranted, because no one is discussing
anything that would (negatively) impact the set of use cases you've
described so far. It's probably just a misunderstanding as to what's being
discussed and the subtlety of the validation points :)

[okaphone.e...@gmail.com]

Well, sorry I misunderstood then. And thanks for reassuring me. ;-)

CU Hans

[Peter Kurrasch]

I'll be the first to admit that the example I put together is far from ideal. Perhaps a shortcoming is the lack of any explicit mention regarding the knowledge, skill, competence, etc. of the cert requester--or "system administrator" if you will. The ability of individual people to navigate the minefield of security practices and exploits is at least as important as the relative size of the Internet presence a given domain may have. There should also be some mention of attack vectors as they are an important consideration in evaluating the relative disadvantages of wildcard certs. (I think the advantages are widely understood and not disputed, so I'll skip that side of the debate.)

I'll talk about an attack vector first:

Suppose I want to set up a system to be used for spam, malware distribution, and phishing but, naturally, I want to operate undetected. First step is to find a (legitimate) server that is already set up and is not well secured. Without getting bogged down in the details, let's just assume I can find such a server and I'm able to obtain access to the admin panel or a command line/shell that controls it. With this access, let's also just assume I'm able to obtain the certificate and private key data that the legitimate site owner is using.

If the cert is not a wildcard, my options are limited. I could use the server and its domain name to send out my spam. In practice, though, it's probably easier to just commandeer the domain name and find some spam-as-a-service provider in the underground market. I could probably copy my malware objects into some obscurely-named directory and serve them up to my victims from there. The benefit is that I don't need my own hardware somewhere else and worry about DNS settings but there is a much higher risk that someone will eventually figure out what I'm doing. Someone could be monitoring network bandwidth or server logs or the file system capacity or some other data point that prompts a closer look.

If, instead, the cert is a wildcard, I have more freedom to ‎do what I want while reducing the chances of getting caught. I can exploit the domain and it's cert without tying myself to the server that is handling the legitimate traffic. I do need to manipulate DNS lookups in the right manner, but let's again just assume I can do that just fine. With DNS pointing my nefarious subdomains to my own nefarious server and with a wildcard cert and private key ready to validate with whatever names I choose, I am ready to go. I can send spam, offer up a variety of malware and ransomware, and host the phishing sites/pages all while keeping a very low profile--at least as far as the legitimate site owner is aware.

Granted, there is a healthy amount of hand waving in this illustration and frankly there are situations where other attack methods are more advantageous for any number of reasons. That said, the point I am hoping to make is that a wildcard certificate opens up possibilities for me as the bad guy that I might not have otherwise.

With that I'll (briefly) address the role of the system administrator's skill level:

In order for my wildcard attack to work, I need to find the server. Perhaps I'll skulk around the Internet looking for servers with unpatched vulnerabilities. Perhaps then I'll look up ownership information on that domain and cross-reference that with lists of accounts/passwords that have been compromised. Since it's common for people to use the same password on multiple sites I might get lucky.

From there, I'm mostly in the free and clear. In some situations I might want to tweak the DNS settings in the legit name servers so perhaps I will have direct access to it once I pop the server. Maybe the control panel also can modify the DNS records or maybe the same password will work on the name servers?

The point here is that there are important security measures that a system administrator must take. I think we can all agree that a competent administrator will take those steps while a lesser administrator might not. When this lack of skill (or perhaps "diligence" is a better word?) are combined with wildcard certs, the consequences can be very bad for everyone else.

Again, I'll be the first to admit this is perhaps not the best illustration of the risks posed by wildcard certs but hopefully it's at least good enough. I don't think the above is a major problem today but if the desire is make wildcard certs ubiquitous (?), I hope people will at least think twice.

And, for the record, I don't think wildcard certs should be banned outright. I also think that Hans and his network situation represent a good example where actual need and skill of the administrator combine to give one confidence that the wildcard cert's risks are controlled, and perhaps minimized.

And, finally, I'll just say CAA sounds like a good addition to the security toolbox but does have some shortcomings. The extent to which it can limit unintended wildcard certs is probably a good thing but clearly it will rely on a sufficiently skilled administrator for any effectiveness to be realized. 

From: Ryan Sleevi Sent: Wednesday, April 26, 2017 2:46 PM To: Peter Kurrasch‎ Reply To: ry...@sleevi.com‎ Cc: Ryan Sleevi; mozilla-dev-security-policy Subject: Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list

[Ryan Sleevi]

On Fri, Apr 28, 2017 at 9:48 AM, Peter Kurrasch <fhw...@gmail.com> wrote:
>
> Suppose I want to set up a system to be used for spam, malware
> distribution, and phishing but, naturally, I want to operate undetected.
> First step is to find a (legitimate) server that is already set up and is
> not well secured. Without getting bogged down in the details, let's just
> assume I can find such a server and I'm able to obtain access to the admin
> panel or a command line/shell that controls it. With this access, let's
> also just assume I'm able to obtain the certificate and private key data
> that the legitimate site owner is using.
>

You can stop here. Once you've done that, it's game over for any subdomains
as it stands. Wildcard certs are a red herring. If you've got file control
on the server, or can demonstrate control of the base, you can get the
subdomains.

That's the weak link in your attack model, and for that to change, it will
at least require some action on the CA/Browser Forum to restrict the
file-based controls or 'practical demonstration of control'. If you just
compromise the server/key, you've compromise every subdomain, as it stands
today. That's not because of wildcards. That's because of the CA/Browser
Forum.

> Granted, there is a healthy amount of hand waving in this illustration and
> frankly there are situations where other attack methods are more
> advantageous for any number of reasons. That said, the point I am hoping to
> make is that a wildcard certificate opens up possibilities for me as the
> bad guy that I might not have otherwise.
>

Right, not really, because above :)

> Again, I'll be the first to admit this is perhaps not the best
> illustration of the risks posed by wildcard certs but hopefully it's at
> least good enough. I don't think the above is a major problem today but if
> the desire is make wildcard certs ubiquitous (?), I hope people will at
> least think twice.
>

I appreciate your threat modelling of this space, but I think it's
operating on incomplete understanding of what the reasonable security
boundary is, but also tries to rely on certificates as a spam/phishing
protection, of which they most certainly are not :)

[Peter Kurrasch]

"Incomplete understanding"? That's rich.

There is no reliance on certs as a protection mechanism. Rather, the use of certs/encryption help to facilitate my bad acts. If I'm doing malvertising I basically must use an encrypted channel. If I'm doing other bad things, encryption frustrates the efforts of security personnel to figure out that something bad is happening.

As for the weak link, it isn't necessarily weak. True, I could get additional subdomain certs by exploiting the weak validation methods that CABF has endorsed. In many cases that will work just fine but I do still have to interact with the CA which leaves a paper trail--especially if the cert gets published via CT.

In the wildcard scenario, there is no need for that interaction. Less interaction, low profile, few opportunities for detection, ability to operate unimpeded...this is the dream for any bad guy. Wildcard certs make it easier for me to get there. One can definitely reach that goal using non-wildcard tactics but it might not be as easy.

Getting back to Gerv's original question, should the wildcard section be removed? My answer is: no, it should not be removed. It could stand to be updated though.

[Gervase Markham]

On 20/04/17 14:02, Gervase Markham wrote:
> I propose this section be removed from the document.

This section has now been removed. Regardless of other points raised,
the issuing of wildcard certs /per se/ is not a Problematic Practice.

Gerv

[Itzhak Daniel]

On Thursday, April 20, 2017 at 4:03:36 PM UTC+3, Gervase Markham wrote:
> Mozilla also doesn't believe that it's the job of CAs to police phishing

CAs should police as long as the browser gives positive reinforcement to the end-users when they access a [phishing] site.

There were suggestions in the past to remove the 'green lock' for DV/OV certificates. Once this is done, I believe CAs that generates those certs can stop "policing".