Removing "Wildcard DV Certs" from Potentially Problematic Practices list

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
0
Gervase
4/20/2017 1:02:59 PM
mozilla.dev.security.policy 1024 articles. 1 followers. Post Follow

11 Replies
15 Views

Similar Articles

[PageSpeed] 17

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 potentiall=
y problematic. Historically we have seen problems that wouldn't have happen=
ed or would be much less serious without Wildcard DV issuance. In particula=
r 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 th=
e Ballot 169 checks for example.com, so now we'll issue for *.example.com a=
nd everything is just fine.

I'm not so uncomfortable with it that I want Mozilla to try to get it stopp=
ed, but I think signalling some residual discomfort here is worthwhile unti=
l somebody has thought through a good policy, and preferably at least got t=
he big CAs to go along with it in principle even if we don't have it in for=
mal Mozilla policy or the BRs.
0
Nick
4/21/2017 9:12:51 AM
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

0
Gervase
4/21/2017 10:01:29 AM
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 nothi=
ng 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 veri=
fying 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 pract=
ical 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 rog=
ue 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 wi=
ldcard that can MitM SMTP, HTTPS-based APIs, VPNs, any sort of TLS traffic =
at all into any name in example.com.
0
Nick
4/21/2017 11:09:57 AM
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

0
Matt
4/22/2017 1:23:23 AM
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

0
Matt
4/22/2017 1:24:20 AM
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 wher=
e 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 con=
tact to get emails from Comodo saying they need to click a button to preven=
t an SSL certificate being issued, but actually clicking will cause it to b=
e issued to the attacker...

In such cases bad guys can get a wildcard rather than validation just for o=
ne 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 essenti=
ally 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 wi=
ldcards.
0
Nick
4/23/2017 11:41:42 AM
On Sun, Apr 23, 2017 at 7:41 AM, Nick Lamb via dev-security-policy <
dev-security-policy@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 :)
0
Ryan
4/23/2017 3:28:25 PM
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
0
Gervase
4/24/2017 9:15:56 AM
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

0
Gervase
4/24/2017 9:16:55 AM
<html><head></head><body lang=3D"en-US" style=3D"background-color: rgb(255,=
 255, 255); line-height: initial;">                                        =
                                              <div style=3D"width: 100%; fo=
nt-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif=
; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, =
255, 255);">Wildcard certs present a level of risk that is different (highe=
r?) than for other end-entity certs.=E2=80=8E The risk as I see it is two-f=
old:</div><div style=3D"width: 100%; font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);"><br></div><div style=3D"=
width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-se=
rif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-c=
olor: rgb(255, 255, 255);">1) Issuance: Setting aside the merits of the 10 =
Blessed Methods, there is no clear way to extrapolate a successful validati=
on for one domain into a plethora of FQDN's in a way that works for all sce=
narios. So the risk in this sense is that the issuer might allow a cert req=
uester to over-subscribe a given domain's name space.</div><div style=3D"wi=
dth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-seri=
f, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-col=
or: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: in=
itial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rg=
b(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"=
>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 i=
s in contrast to the non-wildcard case wherein I know it's a legitimate par=
t 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.</div><div style=3D"width: 100%; fon=
t-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif;=
 color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 2=
55, 255);"><span style=3D"font-size: initial; line-height: initial; text-al=
ign: initial;"><br></span></div><div style=3D"width: 100%; font-size: initi=
al; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(3=
1, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><s=
pan style=3D"font-size: initial; line-height: initial; text-align: initial;=
"><br></span></div><div style=3D"width: 100%; font-size: initial; font-fami=
ly: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); =
text-align: initial; background-color: rgb(255, 255, 255);"><span style=3D"=
font-size: initial; line-height: initial; text-align: initial;">The use of =
"problematic" to describe wildcard certs is perhaps misleading. Perhaps the=
 wildcard=E2=80=8E certs themselves are not problematic but trying to manag=
e or mitigate the risk they pose is.&nbsp;</span><span style=3D"font-size: =
initial; line-height: initial; text-align: initial;">Either way, I don't th=
ink it would be wise to remove this from the problematic practices list.</s=
pan></div><div style=3D"width: 100%; font-size: initial; font-family: Calib=
ri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-alig=
n: initial; background-color: rgb(255, 255, 255);"><span style=3D"font-size=
: initial; line-height: initial; text-align: initial;"><br></span></div>   =
                                                                           =
                                                       <div style=3D"width:=
 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, s=
ans-serif; color: rgb(31, 73, 125); text-align: initial; background-color: =
rgb(255, 255, 255);"><br></div>                                            =
                                                                           =
                                                                           =
 <div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-=
serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; background=
-color: rgb(255, 255, 255);"></div>                                        =
                                                                           =
                                                               =E2=80=8E<ta=
ble width=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <t=
body><tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial=
; background-color: rgb(255, 255, 255);">                           <div st=
yle=3D"border-style: solid none none; border-top-color: rgb(181, 196, 223);=
 border-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alph=
a Sans', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Gervase Markham=
 via dev-security-policy</div><div><b>Sent: </b>Monday, April 24, 2017 4:16=
 AM=E2=80=8E</div></div></td></tr></tbody></table><div style=3D"border-styl=
e: solid none none; border-top-color: rgb(186, 188, 209); border-top-width:=
 1pt; font-size: initial; text-align: initial; background-color: rgb(255, 2=
55, 255);"></div><br><div id=3D"_originalContent" style=3D"">On 21/04/17 12=
:09, Nick Lamb wrote:<br>&gt; Of the ballot 169 methods, 3.2.2.4.7 is most =
obviously appropriate<br>&gt; for verifying that the applicant controls the=
 entire domain and thus<br>&gt; *.example.com, whereas say 3.2.2.4.6 proves=
 only that the applicant<br>&gt; controls a web server, it seems quite like=
ly they have neither the<br>&gt; legal authority nor the practical ability =
to control servers with<br>&gt; other names in that domain. I can see argum=
ents either way for<br>&gt; 3.2.2.4.4, depending on how well email happens =
to be administrated in<br>&gt; a particular organisation.<br><br>So your co=
ncern is that a subset of the 10 Blessed Methods might not be<br>suitable f=
or verifying the level of control necessary to safely issue a<br>wildcard c=
ert?<br><br>If that's true, we should look at it, but I don't see how that'=
s<br>connected with saying or not saying on our wiki page that wildcard cer=
ts<br>are inherently problematic.<br><br>So, to analyse: you are saying tha=
t demonstrating control over<br>http://www.example.com/ and getting a cert =
for *.www.example.com is<br>shaky? Or demonstrating control of http://examp=
le.com/ and getting a<br>cert for *.example.com? Or something else?<br><br>=
Gerv<br>_______________________________________________<br>dev-security-pol=
icy mailing list<br>dev-security-policy@lists.mozilla.org<br>https://lists.=
mozilla.org/listinfo/dev-security-policy<br></div></body></html>
0
Peter
4/25/2017 5:31:16 AM
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.=E2=80=8E 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 t=
he
> 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 par=
t
> 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?
0
Ryan
4/25/2017 5:44:05 AM
Reply: