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.



From: Ryan Sleevi
Sent: Tuesday, April 25, 2017 12:44 AM
To: Peter Kurrasch
Reply To: r...@sleevi.com
Cc: mozilla-dev-security-policy
Subject: Re: Removing "Wildcard DV Certs" from Potentially Problematic Practices list



On Tue, Apr 25, 2017 at 1:31 AM, Peter Kurrasch via dev-security-policy <dev-security-policy@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?





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

Reply via email to