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 1195 articles. 1 followers. Post Follow

23 Replies
123 Views

Similar Articles

[PageSpeed] 30

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
<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);">Hi Ryan--</div><div style=3D"width: 100%; font-size: initial; f=
ont-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73=
, 125); text-align: initial; background-color: rgb(255, 255, 255);"><br></d=
iv><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sl=
ate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: init=
ial; background-color: rgb(255, 255, 255);">To your first comment, I'm afra=
id 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 o=
f 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 wildca=
rd cert.</div><div style=3D"width: 100%; font-size: initial; font-family: C=
alibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-=
align: initial; background-color: rgb(255, 255, 255);"><br></div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);">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:</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);"><br></div><div style=3D"width: 100%; 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)=
;">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, inter=
mediate, and tiny. A "substantial" presence almost certainly has a large en=
terprise behind it with staff and capital resources to maintain the service=
.. If we can assume that such organizations have tighter controls over use o=
f 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.</div><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);"><br></div><div style=3D"width: 100%; font-size: initial; font-f=
amily: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125=
); text-align: initial; background-color: rgb(255, 255, 255);">For an "inte=
rmediate" presence, I'm thinking of places like universities that have a la=
rge number of subdomains in use but might not have a good set of controls o=
ver use of the domain name space and certificates and so forth. In this typ=
e of setting I think the use of wildcards might be appealing because it sim=
plifies management of the network but if the controls are not in place, the=
re 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 th=
at all academic environments are not suitably managed.) This category can b=
e of concern.</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);"><br></div><div =
style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro'=
, sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; bac=
kground-color: rgb(255, 255, 255);">The "tiny" category almost speaks for i=
tself and probably applies to all individuals and small businesses--people =
who want some presence but might not be all that diligent about it. In othe=
r words, these are the systems that probably have the weakest security meas=
ures in place. These are the systems that are regularly compromised and use=
d for spam campaigns, fake login screens, and such. This is also the catego=
ry for whom wildcard certs pose the greatest risk=E2=80=8E to everyone else=
..</div><div style=3D"width: 100%; 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);"><br></div><div style=3D"wid=
th: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif=
, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-colo=
r: rgb(255, 255, 255);">Consider a case where someone has a custom domain--=
let's say easypete.ninja--and perfectly reasonable subdomains. So:</div><di=
v style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pr=
o', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; b=
ackground-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; =
font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-ser=
if; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255=
, 255, 255);"><span style=3D"font-size: initial; text-align: initial; line-=
height: initial;">&nbsp;- easypete.ninja </span></div><div style=3D"width: =
100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sa=
ns-serif; color: rgb(31, 73, 125); text-align: initial; background-color: r=
gb(255, 255, 255);">&nbsp;=E2=80=8E- www.easypete.ninja</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);">&nbsp;- email.easypete.ninja</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);"><br></div><div style=3D"width: 100%; 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)=
;">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:</div><div style=3D"width: 100%; font=
-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; =
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 25=
5, 255);"><br></div><div style=3D"width: 100%; font-size: initial; font-fam=
ily: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125);=
 text-align: initial; background-color: rgb(255, 255, 255);">&nbsp;- com.ea=
sypete.ninja</div><div style=3D"width: 100%; font-size: initial; font-famil=
y: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); t=
ext-align: initial; background-color: rgb(255, 255, 255);">&nbsp;- paypal.c=
om.easypete.ninja</div><div style=3D"width: 100%; font-size: initial; font-=
family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 12=
5); text-align: initial; background-color: rgb(255, 255, 255);">&nbsp;- goo=
gle.com.easypete.ninja</div><div style=3D"width: 100%; font-size: initial; =
font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 7=
3, 125); text-align: initial; background-color: rgb(255, 255, 255);">&nbsp;=
- &lt;random characters&gt;.easypete.ninja</div><div style=3D"width: 100%; =
font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-ser=
if; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255=
, 255, 255);">&nbsp;- facebook.com.loginassistant.easypete.ninja</div><div =
style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro'=
, sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; bac=
kground-color: rgb(255, 255, 255);"><br></div><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);">...and all sorts of variants of the above.=E2=80=8E&nbsp;<span =
style=3D"font-size: initial; line-height: initial; text-align: initial;">Pe=
r the wildcard cert, all of the above domains are perfectly valid. Per the =
actual intent of th=E2=80=8Ee domain holder, most of the above are surely n=
ot valid.</span></div><div style=3D"width: 100%; font-size: initial; font-f=
amily: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125=
); text-align: initial; background-color: rgb(255, 255, 255);"><br></div><d=
iv style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);">So, the problem becomes how a relyin=
g party may determine if the site/domain is legitimate. If I have some indi=
cator in the browser UI that says "secure" because the FQDN matching has be=
en satisfied, I'll probably proceed to use the page that is presented. If t=
he indicator is missing, there is a chance I'll think twice about proceedin=
g any further. The trouble in this situation is that if the FQDN is nefario=
us but satisfies the wildcard contained in the cert, I will probably make t=
he wrong decision and open myself up to who knows what.</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);"><br></div><div style=3D"width: 100%; 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)=
;"><br></div>                                                              =
                                                                       <div=
 style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro=
', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; ba=
ckground-color: rgb(255, 255, 255);"><br style=3D"display:initial"></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);"></di=
v>                                                                         =
                                                                           =
                              <table width=3D"100%" style=3D"background-col=
or:white;border-spacing:0px;"> <tbody><tr><td colspan=3D"2" style=3D"font-s=
ize: initial; text-align: initial; background-color: rgb(255, 255, 255);"> =
                          <div style=3D"border-style: solid none none; bord=
er-top-color: rgb(181, 196, 223); border-top-width: 1pt; padding: 3pt 0in 0=
in; font-family: Tahoma, 'BB Alpha Sans', 'Slate Pro'; font-size: 10pt;">  =
<div><b>From: </b>Ryan Sleevi</div><div><b>Sent: </b>Tuesday, April 25, 201=
7 12:44 AM</div><div><b>To: </b>Peter Kurrasch</div><div><b>Reply To: </b>r=
yan@sleevi.com</div><div><b>Cc: </b>mozilla-dev-security-policy</div><div><=
b>Subject: </b>Re: Removing "Wildcard DV Certs" from Potentially Problemati=
c Practices list</div></div></td></tr></tbody></table><div style=3D"border-=
style: solid none none; border-top-color: rgb(186, 188, 209); border-top-wi=
dth: 1pt; font-size: initial; text-align: initial; background-color: rgb(25=
5, 255, 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=
=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On T=
ue, Apr 25, 2017 at 1:31 AM, Peter Kurrasch via dev-security-policy <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:dev-security-policy@lists.mozilla.org" tar=
get=3D"_blank">dev-security-policy@lists.mozilla.org</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div lang=3D"en-US" style=3D"background-c=
olor:rgb(255,255,255);line-height:initial">                                =
                                                      <div style=3D"width:1=
00%;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)"=
>Wildcard certs present a level of risk that is different (higher?) than fo=
r other end-entity certs.=E2=80=8E The risk as I see it is two-fold:<span s=
tyle=3D"font-family:arial,sans-serif;font-size:small;color:rgb(34,34,34)">&=
nbsp;</span></div></div></blockquote><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div la=
ng=3D"en-US" style=3D"background-color:rgb(255,255,255);line-height:initial=
"><div style=3D"width:100%;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)"><br></div><div style=3D"width:100%;font-size:initia=
l;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125=
);text-align:initial;background-color:rgb(255,255,255)">1) Issuance: Settin=
g aside the merits of the 10 Blessed Methods, there is no clear way to extr=
apolate 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.</div></div></blockquote><div><br></div><div>See the discussion in t=
he CA Browser Forum regarding 3.2.2.4 and "Domain Namespace". There's an ar=
guable interpretation that allows for a single domain validation and an unl=
imited number of certificates for an arbitrary number of subdomains.</div><=
div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"en-US" style=3D=
"background-color:rgb(255,255,255);line-height:initial"><div style=3D"width=
:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-serif,sans-ser=
if;color:rgb(31,73,125);text-align:initial;background-color:rgb(255,255,255=
)"><br></div><div style=3D"width:100%;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)">2) Abuse: Once the wildcard cert has bee=
n issued there is no way to check that the host (or FQDN) to which I'm conn=
ecting is a legitimate part of the broader domain or if it has been taken o=
ver for nefarious purposes. This is in contrast to the non-wildcard case wh=
erein I know it's a legitimate part because I see the FQDN listed explicitl=
y in the SAN field. So the risk in this sense is to the relying party who i=
s less able to protect himself or herself from connecting to bad servers.</=
div></div></blockquote><div><br></div><div>I'm not sure I understand this p=
oint. Of course it's legitimate - as it's part of the subdomain. Could you =
expand further what you see as wrong here?</div><div><br></div></div><br></=
div></div>
<br><!--end of _originalContent --></div><br><br></body></html>
0
Peter
4/26/2017 7:17:57 PM
On Wed, Apr 26, 2017 at 3:17 PM, Peter Kurrasch <fhw843@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 fo=
r
> 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 an=
d
> 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 t=
he
> 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 s=
et
> 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 the=
se
> certs pose. (And to be fair, this isn't to say that only academic
> environments face this situation or that all academic environments are no=
t
> 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 cert=
s
> pose the greatest risk=E2=80=8E 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.=E2=80=8E Per the wildcard cert=
, all of
> the above domains are perfectly valid. Per the actual intent of th=E2=80=
=8Ee 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 tha=
t
> 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 decisi=
on
> 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!
0
Ryan
4/26/2017 7:46:24 PM
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 nam=
es 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 num=
ber of servers (I'll spare you the details ;-). This setup gives me flexibi=
lity 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 inst=
ead.

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 phi=
shing domain from LetsEncrypt.

5) Trying to do something that certificates are not meant for. I don't thin=
k 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
0
okaphone
4/26/2017 8:02:17 PM
On Wed, Apr 26, 2017 at 4:02 PM, okaphone.elektronika--- via
dev-security-policy <dev-security-policy@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.
0
Ryan
4/26/2017 8:42:57 PM
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:
>=20
> > I think this is getting weird.
> >
> > At first (some other thread) it get's explained that e.g. LetsEncrypt d=
oes
> > not do anything beyond domain validation and possibly on notification t=
ake
> > down a few certificates of phishing site. And that was "... all OK beca=
use
> > we want SSL to be used everywhere, and anyway domain validation means j=
ust
> > that, nothing more..."
> >
> > And now you guys are suddenly seeing problems in wild card certificates
> > "... because it could be use for phishing..." Ehm, what?
>=20
> 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 t=
hen. 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 al=
so 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:
>=20
> 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. ;-)

=20
> > 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 si=
tes
> > are not used for phishing.
>=20
> I think almost everyone on this thread has expressed general agreement :)
>=20
> 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 (ov=
er
> a subdomain), and thus much greater risk, and the desire to balance that
> risk.
>=20
> 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 a=
llows for enough flexibility, so I can arrange the HTTPS everywhere you guy=
s (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 ar=
e 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 inst=
ance. Would that be an improvement?

CU Hans
0
okaphone
4/26/2017 9:17:09 PM
On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
dev-security-policy <dev-security-policy@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 :)
0
Ryan
4/26/2017 10:41:59 PM
On Thursday, 27 April 2017 00:42:20 UTC+2, Ryan Sleevi  wrote:
> On Wed, Apr 26, 2017 at 5:17 PM, okaphone.elektronika--- via
> dev-security-policy <dev-security-policy@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 :)

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

CU Hans
0
okaphone
4/27/2017 6:42:14 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);">I'll be the first to admit that the example I put together is f=
ar from ideal.&nbsp;<span style=3D"font-size: initial; text-align: initial;=
 line-height: initial;">Perhaps a shortcoming is the lack of any explicit m=
ention regarding the knowledge, skill, competence, etc. of the cert request=
er--or "system administrator" if you will. The ability of individual people=
 to navigate the minefield of security practices and exploits is at least a=
s important as the relative size of the Internet presence a given domain ma=
y have. There should also be some mention of attack vectors as they are an =
important consideration in evaluating the relative disadvantages of wildcar=
d certs. (I think the advantages are widely understood and not disputed, so=
 I'll skip that side of the debate.)</span></div><div style=3D"width: 100%;=
 font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-se=
rif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(25=
5, 255, 255);"><span style=3D"font-size: initial; text-align: initial; line=
-height: initial;"><br></span></div><div style=3D"width: 100%; font-size: i=
nitial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: r=
gb(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);=
"><span style=3D"font-size: initial; text-align: initial; line-height: init=
ial;"><br></span><span style=3D"font-size: initial; text-align: initial; li=
ne-height: initial;">I'll talk about an attack vector first:</span></div><d=
iv style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%;=
 font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-se=
rif; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(25=
5, 255, 255);">Suppose I want to set up a system to be used for spam, malwa=
re 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 as=
sume I can find such a server and I'm able to obtain access to the admin pa=
nel or a command line/shell that controls it.&nbsp;<span style=3D"font-size=
: initial; line-height: initial; text-align: initial;">With this access, le=
t's also just assume I'm able to obtain the certificate and private key dat=
a that the legitimate site owner is using.</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);"><span style=3D"font-size: initial; line-height: initia=
l; text-align: initial;"><br></span></div><div style=3D"width: 100%; font-s=
ize: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; co=
lor: 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;">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 spa=
m-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 m=
y victims from there. The benefit is that I don't need my own hardware some=
where else and worry about DNS settings but there is a much higher risk tha=
t someone will eventually figure out what I'm doing. Someone could be monit=
oring network bandwidth or server logs or the file system capacity or some =
other data point that prompts a closer look.</span></div><div style=3D"widt=
h: 100%; 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);"><span style=3D"font-size: initial; line-height: init=
ial; text-align: initial;"><br></span></div><div style=3D"width: 100%; font=
-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; =
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 25=
5, 255);"><span style=3D"font-size: initial; line-height: initial; text-ali=
gn: initial;">If, instead, the cert is a wildcard, I have more freedom to =
=E2=80=8Edo 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 i=
s handling the legitimate traffic. I do need to manipulate DNS lookups in t=
he 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 choos=
e, I am ready to go. I can send spam, offer up a variety of malware and ran=
somware, and host the phishing sites/pages all while keeping a very low pro=
file--at least as far as the legitimate site owner is aware.</span></div><d=
iv style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate P=
ro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; =
background-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; l=
ine-height: initial; text-align: initial;"><br></span></div><div style=3D"w=
idth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-ser=
if, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-co=
lor: rgb(255, 255, 255);"><span style=3D"font-size: initial; line-height: i=
nitial; text-align: initial;">Granted, there is a healthy amount of hand wa=
ving in this illustration and frankly there are situations where other atta=
ck 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 possibili=
ties for me as the bad guy that I might not have otherwise.</span></div><di=
v style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pr=
o', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; b=
ackground-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; te=
xt-align: initial; line-height: initial;"><br></span></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);"><span style=3D"font-size: initial; text-align: ini=
tial; line-height: initial;">With that I'll (briefly) address the role of t=
he system administrator's skill level:</span></div><div style=3D"width: 100=
%; 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);"><span style=3D"font-size: initial; text-align: initial; li=
ne-height: initial;"><br></span></div><div style=3D"width: 100%; 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=
);"><span style=3D"font-size: initial; text-align: initial; line-height: in=
itial;">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 do=
main and cross-reference that with lists of accounts/passwords that have be=
en compromised. Since it's common for people to use the same password on mu=
ltiple sites I might get lucky.</span></div><div style=3D"width: 100%; font=
-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; =
color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255, 25=
5, 255);"><span style=3D"font-size: initial; text-align: initial; line-heig=
ht: initial;"><br></span></div><div style=3D"width: 100%; font-size: initia=
l; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31=
, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><sp=
an style=3D"font-size: initial; text-align: initial; line-height: initial;"=
>From there, I'm mostly in the free and clear. In some situations I might w=
ant to tweak the DNS settings in the legit name servers so perhaps I will h=
ave 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 nam=
e servers?</span></div><div style=3D"width: 100%; font-size: initial; font-=
family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 12=
5); text-align: initial; background-color: rgb(255, 255, 255);"><span style=
=3D"font-size: initial; text-align: initial; line-height: initial;"><br></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; text-align: initial; line-height: initial;">The point here is th=
at there are important security measures that a system administrator must t=
ake. I think we can all agree that a competent administrator will take thos=
e steps while a lesser administrator might not. When this lack of skill (or=
 perhaps "diligence" is a better word?) are combined with wildcard certs, t=
he consequences can be very bad for everyone else.</span></div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; text-alig=
n: initial; line-height: initial;"><br></span></div><div style=3D"width: 10=
0%; 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);"><span style=3D"font-size: initial; text-align: initial; l=
ine-height: initial;">Again, I'll be the first to admit this is perhaps not=
 the best illustration of the risks posed by wildcard certs but hopefully i=
t'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.</span></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);"=
><span style=3D"font-size: initial; text-align: initial; line-height: initi=
al;"><br></span></div><div style=3D"width: 100%; font-size: initial; font-f=
amily: 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; text-align: initial; line-height: initial;">And, fo=
r the record, I don't think wildcard certs should be banned outright. I als=
o think that Hans and his network situation represent a good example where =
actual need and skill of the administrator combine to give one confidence t=
hat the wildcard cert's risks are controlled, and perhaps minimized.</span>=
</div><div style=3D"width: 100%; font-size: initial; font-family: Calibri, =
'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: i=
nitial; background-color: rgb(255, 255, 255);"><span style=3D"font-size: in=
itial; text-align: initial; line-height: initial;"><br></span></div><div st=
yle=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', =
sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backg=
round-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; text-a=
lign: initial; line-height: initial;">And, finally, I'll just say CAA sound=
s like a good addition to the security toolbox but does have some shortcomi=
ngs. The extent to which it can limit unintended wildcard certs is probably=
 a good thing but clearly it will rely on a sufficiently skilled administra=
tor for any effectiveness to be realized.&nbsp;</span></div><div style=3D"w=
idth: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-ser=
if, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-co=
lor: rgb(255, 255, 255);"><span style=3D"font-size: initial; text-align: in=
itial; line-height: initial;"><br></span></div><div style=3D"width: 100%; f=
ont-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-seri=
f; color: rgb(31, 73, 125); text-align: initial; background-color: rgb(255,=
 255, 255);"><span style=3D"font-size: initial; text-align: initial; line-h=
eight: initial;"><br></span></div>                                         =
                                                                           =
                                                                           =
    <div style=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sa=
ns-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgro=
und-color: rgb(255, 255, 255);"></div>                                     =
                                                                           =
                                                                  <table wi=
dth=3D"100%" style=3D"background-color:white;border-spacing:0px;"> <tbody><=
tr><td colspan=3D"2" style=3D"font-size: initial; text-align: initial; back=
ground-color: rgb(255, 255, 255);">                           <div style=3D=
"border-style: solid none none; border-top-color: rgb(181, 196, 223); borde=
r-top-width: 1pt; padding: 3pt 0in 0in; font-family: Tahoma, 'BB Alpha Sans=
', 'Slate Pro'; font-size: 10pt;">  <div><b>From: </b>Ryan Sleevi</div><div=
><b>Sent: </b>Wednesday, April 26, 2017 2:46 PM</div><div><b>To: </b>Peter =
Kurrasch=E2=80=8E</div><div><b>Reply To: </b>ryan@sleevi.com=E2=80=8E</div>=
<div><b>Cc: </b>Ryan Sleevi; mozilla-dev-security-policy</div><div><b>Subje=
ct: </b>Re: Removing "Wildcard DV Certs" from Potentially Problematic Pract=
ices list</div></div></td></tr></tbody></table><div style=3D"border-style: =
solid none none; border-top-color: rgb(186, 188, 209); border-top-width: 1p=
t; font-size: initial; text-align: initial; background-color: rgb(255, 255,=
 255);"></div><br><div id=3D"_originalContent" style=3D""><div dir=3D"ltr">=
<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Apr 2=
6, 2017 at 3:17 PM, Peter Kurrasch <span dir=3D"ltr">&lt;<a href=3D"mailto:=
fhw843@gmail.com" target=3D"_blank">fhw843@gmail.com</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div lang=3D"en-US" style=3D"background-c=
olor:rgb(255,255,255);line-height:initial">                                =
                                                      <div style=3D"width:1=
00%;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)"=
>Hi Ryan--</div><div style=3D"width:100%;font-size:initial;font-family:Cali=
bri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initi=
al;background-color:rgb(255,255,255)"><br></div><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)">To yo=
ur 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 unlimite=
d 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. Bo=
ttom line though, I don't think it makes sense that anyone and everyone be =
allowed to obtain a wildcard cert.</div></div></blockquote><div><br></div><=
div>Right, but there's definitely a more careful argument you'll need to ma=
ke, because that is _precisely_ what is (effectively) desired, not just by =
CAs, but most users of more than a few TLS certificates.</div><div><br></di=
v><div>I'm not even sure that I disagree with you - my history in the CA/Br=
owser Forum hopefully demonstrates Google's deep concern with the security =
of the validation methods, the capabilities possible with each validation m=
ethod, and the frequency of which they're performed. However, finding conse=
nsus is, at this point, difficult, despite it being plainly obvious to folk=
s with a security background :)</div><div><br></div><div>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 proc=
edure. So if your concern is helping protect a _competent_ organization fro=
m a rogue wildcard, that already exists and is (in the process of) being re=
quired.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"en-=
US" style=3D"background-color:rgb(255,255,255);line-height:initial"><div st=
yle=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-color:rgb=
(255,255,255)">Let's suppose we break up everyone with a server on the Inte=
rnet into 3 categories based on the size of their Internet presence: substa=
ntial, intermediate, and tiny. A "substantial" presence almost certainly ha=
s a large enterprise behind it with staff and capital resources to maintain=
 the service. If we can assume that such organizations have tighter control=
s over use of the domain name space, servers, certificates, and so forth, t=
hen I think some of the risks posed by wildcard certs are reduced. That bei=
ng the case, I'm less concerned about this category.</div></div></blockquot=
e><div><br></div><div>Regrettably, I think this inverts the priority. "subs=
tantial" presence are often the slowest to deploy, have the most complexity=
 in their infrastructure, and similarly, suffer the greatest risk from a ro=
gue wildcard.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lan=
g=3D"en-US" style=3D"background-color:rgb(255,255,255);line-height:initial"=
><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro'=
,sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-c=
olor:rgb(255,255,255)">For an "intermediate" presence, I'm thinking of plac=
es like universities that have a large number of subdomains in use but migh=
t not have a good set of controls over use of the domain name space and cer=
tificates and so forth. In this type of setting I think the use of wildcard=
s 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 env=
ironments face this situation or that all academic environments are not sui=
tably managed.) This category can be of concern.</div></div></blockquote><d=
iv><br></div><div>This is most organizations :)</div><div>&nbsp;</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex"><div lang=3D"en-US" style=3D"background-color:rgb=
(255,255,255);line-height:initial"><div style=3D"width:100%;font-size:initi=
al;font-family:Calibri,'Slate Pro',sans-serif,sans-serif;color:rgb(31,73,12=
5);text-align:initial;background-color:rgb(255,255,255)">The "tiny" categor=
y almost speaks for itself and probably applies to all individuals and smal=
l businesses--people who want some presence but might not be all that dilig=
ent about it. In other words, these are the systems that probably have the =
weakest security measures in place. These are the systems that are regularl=
y compromised and used for spam campaigns, fake login screens, and such. Th=
is is also the category for whom wildcard certs pose the greatest risk=E2=
=80=8E to everyone else.</div></div></blockquote><div><br></div><div>I disa=
gree 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.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D=
"en-US" style=3D"background-color:rgb(255,255,255);line-height:initial"><di=
v style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',san=
s-serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color=
:rgb(255,255,255)"><span style=3D"font-size:initial;text-align:initial">...=
and all sorts of variants of the above.=E2=80=8E&nbsp;</span><span style=3D=
"font-size:initial;text-align:initial;line-height:initial">Per the wildcard=
 cert, all of the above domains are perfectly valid. Per the actual intent =
of th=E2=80=8Ee domain holder, most of the above are surely not valid.</spa=
n></div></div></blockquote><div><br></div><div>CAA solves that ;)</div><div=
>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div lang=3D"en-US" style=3D"ba=
ckground-color:rgb(255,255,255);line-height:initial"><div style=3D"width:10=
0%;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)">=
So, the problem becomes how a relying party may determine if the site/domai=
n is legitimate. If I have some indicator in the browser UI that says "secu=
re" 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 cha=
nce I'll think twice about proceeding any further. The trouble in this situ=
ation 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.</div></div></blockquote><div><br></div><div>But that's no =
different than shopping Target or Home Depot and their credit card processo=
r / 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!&nbsp;</div></div></div>=
</div>
<br><!--end of _originalContent --></div><br><br><br><br><br><br><br></body=
></html>
0
Peter
4/28/2017 1:48:09 PM
On Fri, Apr 28, 2017 at 9:48 AM, Peter Kurrasch <fhw843@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 :)
0
Ryan
4/28/2017 2:51:15 PM
<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);">"Incomplete understanding"? That's rich.</div><div style=3D"wid=
th: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif=
, sans-serif; color: rgb(31, 73, 125); text-align: initial; background-colo=
r: rgb(255, 255, 255);"><br></div><div style=3D"width: 100%; font-size: ini=
tial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb=
(31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);">=
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.</div><div style=3D"width: 100%; font-size: init=
ial; font-family: Calibri, 'Slate Pro', sans-serif, sans-serif; color: rgb(=
31, 73, 125); text-align: initial; background-color: rgb(255, 255, 255);"><=
br></div><div style=3D"width: 100%; font-size: initial; font-family: Calibr=
i, 'Slate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align=
: initial; background-color: rgb(255, 255, 255);">As for the weak link, it =
isn't necessarily weak. True, I could get additional subdomain certs by exp=
loiting the weak validation methods that CABF has endorsed. In many cases t=
hat will work just fine but I do still have to interact with the CA which l=
eaves a paper trail--especially if the cert gets published via CT.</div><di=
v style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pr=
o', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; b=
ackground-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; li=
ne-height: initial; text-align: initial;"><br></span></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);"><span style=3D"font-size: initial; line-height: in=
itial; text-align: initial;">In the wildcard scenario, there is no need for=
 that interaction. Less interaction, low profile, few opportunities for det=
ection, ability to operate unimpeded...this is the dream for any bad guy. W=
ildcard 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.</span></d=
iv><div style=3D"width: 100%; font-size: initial; font-family: Calibri, 'Sl=
ate Pro', sans-serif, sans-serif; color: rgb(31, 73, 125); text-align: init=
ial; background-color: rgb(255, 255, 255);"><span style=3D"font-size: initi=
al; line-height: initial; text-align: initial;"><br></span></div><div style=
=3D"width: 100%; font-size: initial; font-family: Calibri, 'Slate Pro', san=
s-serif, sans-serif; color: rgb(31, 73, 125); text-align: initial; backgrou=
nd-color: rgb(255, 255, 255);"><span style=3D"font-size: initial; line-heig=
ht: initial; text-align: initial;"><br></span></div><div style=3D"width: 10=
0%; 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);"><span style=3D"font-size: initial; line-height: initial; =
text-align: initial;">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.</span></div><div style=3D"width: 100%; f=
ont-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, sans-seri=
f; 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;"><br></span></div><div style=3D"width: 100%; font-size: ini=
tial; font-family: 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: initia=
l;"><br></span></div>                                                      =
                                                                           =
                                                                  <div styl=
e=3D"font-size: initial; font-family: Calibri, 'Slate Pro', sans-serif, san=
s-serif; color: rgb(31, 73, 125); text-align: initial; background-color: rg=
b(255, 255, 255);"></div>                                                  =
                                                                           =
                                                     <table width=3D"100%" =
style=3D"background-color:white;border-spacing:0px;"> <tbody><tr><td colspa=
n=3D"2" style=3D"font-size: initial; text-align: initial; background-color:=
 rgb(255, 255, 255);">                           <div style=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 Alpha Sans', 'Slate Pro=
'; font-size: 10pt;">  <div><b>From: </b>Ryan Sleevi</div><div><b>Sent: </b=
>Friday, April 28, 2017 9:51 AM=E2=80=8E</div></div></td></tr></tbody></tab=
le><div style=3D"border-style: solid none none; border-top-color: rgb(186, =
188, 209); border-top-width: 1pt; font-size: initial; text-align: initial; =
background-color: rgb(255, 255, 255);"></div><br><div id=3D"_originalConten=
t" style=3D""><div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Fri, Apr 28, 2017 at 9:48 AM, Peter Kurrasch <span dir=
=3D"ltr">&lt;<a href=3D"mailto:fhw843@gmail.com" target=3D"_blank">fhw843@g=
mail.com</a>&gt;</span> wrote:<blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang=3D"e=
n-US" style=3D"background-color:rgb(255,255,255);line-height:initial"><div =
style=3D"width:100%;font-size:initial;font-family:Calibri,'Slate Pro',sans-=
serif,sans-serif;color:rgb(31,73,125);text-align:initial;background-color:r=
gb(255,255,255)">Suppose I want to set up a system to be used for spam, mal=
ware distribution, and phishing but, naturally, I want to operate undetecte=
d. First step is to find a (legitimate) server that is already set up and i=
s 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.&nbsp;<span style=3D"font-si=
ze:initial;line-height:initial;text-align:initial">With this access, let's =
also just assume I'm able to obtain the certificate and private key data th=
at the legitimate site owner is using.</span></div></div></blockquote><div>=
<br></div><div>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 g=
ot file control on the server, or can demonstrate control of the base, you =
can get the subdomains.</div><div><br></div><div>That's the weak link in yo=
ur attack model, and for that to change, it will at least require some acti=
on on the CA/Browser Forum to restrict the file-based controls or 'practica=
l demonstration of control'. If you just compromise the server/key, you've =
compromise every subdomain, as it stands today. That's not because of wildc=
ards. That's because of the CA/Browser Forum.</div><div>&nbsp;</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex"><div lang=3D"en-US" style=3D"background-color:rgb(2=
55,255,255);line-height:initial"><div style=3D"width:100%;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)"><span style=3D"font-=
size:initial;line-height:initial;text-align:initial">Granted, there is a he=
althy amount of hand waving in this illustration and frankly there are situ=
ations where other attack methods are more advantageous for any number of r=
easons. That said, the point I am hoping to make is that a wildcard certifi=
cate opens up possibilities for me as the bad guy that I might not have oth=
erwise.</span></div></div></blockquote><div><br></div><div>Right, not reall=
y, because above :)</div><div>&nbsp;</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv lang=3D"en-US" style=3D"background-color:rgb(255,255,255);line-height:in=
itial"><div style=3D"width:100%;font-size:initial;font-family:Calibri,'Slat=
e Pro',sans-serif,sans-serif;color:rgb(31,73,125);text-align:initial;backgr=
ound-color:rgb(255,255,255)"><span style=3D"font-size:initial;text-align:in=
itial;line-height:initial">Again, I'll be the first to admit this is perhap=
s not the best illustration of the risks posed by wildcard certs but hopefu=
lly it's at least good enough. I don't think the above is a major problem t=
oday but if the desire is make wildcard certs ubiquitous (?), I hope people=
 will at least think twice.</span></div></div></blockquote><div><br></div><=
div>I appreciate your threat modelling of this space, but I think it's oper=
ating on incomplete understanding of what the reasonable security boundary =
is, but also tries to rely on certificates as a spam/phishing protection, o=
f which they most certainly are not :)</div></div></div></div>
<br><!--end of _originalContent --></div><br></body></html>
0
Peter
4/28/2017 7:37:36 PM
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
0
Gervase
5/1/2017 8:28:59 AM
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".
0
Itzhak
5/4/2017 9:01:34 PM
Reply: