Let's Encrypt appears to issue a certificate for a domain that doesn't exist

[Tony Zhaocheng Tan]

On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com. However, until today, the domain apple-id-2.com has apparently never been registered. How was the certificate issued?

Sources:

https://crt.sh/?q=24ba82659f808f6c5af1816857701bf970cf6ec5751357fea42ef8c4140a4caf

https://twitter.com/beast_fighter/status/834190510642384897

https://news.ycombinator.com/item?id=13709150

[Gervase Markham]

On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never
> been registered. How was the certificate issued?

On Hacker News, Josh Aas writes:

"Head of Let's Encrypt here. Our team is looking into this and so far we
don't see any evidence of mis-issuance in our logs. It looks like the
domain in question, 'apple-id-2.com', was registered and DNS resolved
for it successfully at time of issuance. Here is the valid authorization
record including the resolved IP addresses for 'apple-id-2.com':

https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

We can't be sure why the reporter was unable to find a WHOIS record, we
can only confirm that validation properly succeeded at time of issuance.

Update: Squarespace has confirmed that they did register the domain and
then released it after getting a certificate from us."

There is currently an entry in WHOIS, because some well-meaning but
unhelpful person registered it today. I assume that if a domain is
registered and then released, and then re-registered, the "Creation"
date is of the re-registration, not the first ever registration.

So unless someone can show it was unregistered at the time of issuance,
I don't see an issue here.

Gerv

[Tony Zhaocheng Tan]

Yep, no issue here anymore. Josh Aas hadn't posted on hacker news when I sent this.

Thanks,
Tony

Tony Zhaocheng Tan | to...@tonytan.io | PGP Key
-------- Original Message --------

On Feb 22, 2017, 7:30 PM, Gervase Markham wrote:

On 22/02/17 14:42, Tony Zhaocheng Tan wrote:

> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never
> been registered. How was the certificate issued?

On Hacker News, Josh Aas writes:

[Richard Wang]

I think "apple-id-2.com" is a high risk domain that must be blocked to issue DV SSL to those domains.

Here is the list of some high risk domains related to Microsoft and Google that Let's Encrypt issued DV SSL certificates to those domains:
https://crt.sh/?id=77034583 for microsoftonline.us.com, a fake Office 365 login site
https://crt.sh/?id=71789336 for mail.google-androids.ru
https://crt.sh/?id=82075006 for marketgoogle.xyz
https://crt.sh/?id=65208905 for google.ligboy.org


Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, February 23, 2017 8:30 AM
To: Tony Zhaocheng Tan <to...@tonytan.io>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On 22/02/17 14:42, Tony Zhaocheng Tan wrote:

> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never
> been registered. How was the certificate issued?

On Hacker News, Josh Aas writes:

"Head of Let's Encrypt here. Our team is looking into this and so far we don't see any evidence of mis-issuance in our logs. It looks like the domain in question, 'apple-id-2.com', was registered and DNS resolved for it successfully at time of issuance. Here is the valid authorization record including the resolved IP addresses for 'apple-id-2.com':

https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

We can't be sure why the reporter was unable to find a WHOIS record, we can only confirm that validation properly succeeded at time of issuance.

Update: Squarespace has confirmed that they did register the domain and then released it after getting a certificate from us."

There is currently an entry in WHOIS, because some well-meaning but unhelpful person registered it today. I assume that if a domain is registered and then released, and then re-registered, the "Creation"
date is of the re-registration, not the first ever registration.

So unless someone can show it was unregistered at the time of issuance, I don't see an issue here.

Gerv

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

[George Macon]

On 2/22/17 7:30 PM, Gervase Markham wrote:
> On Hacker News, Josh Aas writes:
>

> <snip>

>
> Update: Squarespace has confirmed that they did register the domain and
> then released it after getting a certificate from us."

In this case, should Squarespace have requested that the certificate be
revoked before releasing the domain?

Is there a way to automatically detect that the domain was released? (I
suspect the answer to this question is "not easily".)

Would it make sense to prohibit certificate issuance during the grace
period?

-George

[Ryan Sleevi]

Hi Richard,

There's no policies in the Baseline Requirements or Mozilla Requirements
that normalize or define high risk domain, which I believe your suggestion
presupposes.

Perhaps you (or Qihoo 360, as the voting member of the Forum of the
Qihoo/WoSign/StartCom collection) would consider proposing a Ballot to the
Baseline Requirements to address this. Alternatively, perhaps you would
have a concrete suggestion for Mozilla Root CA Inclusion Policy 2.5 that
might be able to address this in a consistent and auditable way and in a
manner consistent with Mozilla's policy goals regarding misissuance.

This is https://github.com/mozilla/pkipolicy/issues/1 for what it's worth,
recently resolved in Policy 2.4

On Wed, Feb 22, 2017 at 5:08 PM, Richard Wang via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> I think "apple-id-2.com" is a high risk domain that must be blocked to
> issue DV SSL to those domains.
>
> Here is the list of some high risk domains related to Microsoft and Google
> that Let's Encrypt issued DV SSL certificates to those domains:
> https://crt.sh/?id=77034583 for microsoftonline.us.com, a fake Office
> 365 login site
> https://crt.sh/?id=71789336 for mail.google-androids.ru
> https://crt.sh/?id=82075006 for marketgoogle.xyz
> https://crt.sh/?id=65208905 for google.ligboy.org
>
>
> Best Regards,
>
> Richard
>
> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-bounces+richard=
> wosig...@lists.mozilla.org] On Behalf Of Gervase Markham via
> dev-security-policy
> Sent: Thursday, February 23, 2017 8:30 AM
> To: Tony Zhaocheng Tan <to...@tonytan.io>; mozilla-dev-security-policy@
> lists.mozilla.org
> Subject: Re: Let's Encrypt appears to issue a certificate for a domain
> that doesn't exist
>
> On 22/02/17 14:42, Tony Zhaocheng Tan wrote:

> > On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> > However, until today, the domain apple-id-2.com has apparently never
> > been registered. How was the certificate issued?
>

> On Hacker News, Josh Aas writes:
>

> "Head of Let's Encrypt here. Our team is looking into this and so far we
> don't see any evidence of mis-issuance in our logs. It looks like the
> domain in question, 'apple-id-2.com', was registered and DNS resolved for
> it successfully at time of issuance. Here is the valid authorization record
> including the resolved IP addresses for 'apple-id-2.com':
>
> https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...
>
> We can't be sure why the reporter was unable to find a WHOIS record, we
> can only confirm that validation properly succeeded at time of issuance.
>

> Update: Squarespace has confirmed that they did register the domain and
> then released it after getting a certificate from us."
>

[Richard Wang]

Hi Ryan,



As I understand, the BR 4.2.1 required this:

“The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.”



Please clarify this request, thanks.





Best Regards,



Richard

From: Ryan Sleevi [mailto:ry...@sleevi.com]
Sent: Thursday, February 23, 2017 11:21 AM
To: Richard Wang <ric...@wosign.com>
Cc: Gervase Markham <ge...@mozilla.org>; Tony Zhaocheng Tan <to...@tonytan.io>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

Hi Richard,



There's no policies in the Baseline Requirements or Mozilla Requirements that normalize or define high risk domain, which I believe your suggestion presupposes.



Perhaps you (or Qihoo 360, as the voting member of the Forum of the Qihoo/WoSign/StartCom collection) would consider proposing a Ballot to the Baseline Requirements to address this. Alternatively, perhaps you would have a concrete suggestion for Mozilla Root CA Inclusion Policy 2.5 that might be able to address this in a consistent and auditable way and in a manner consistent with Mozilla's policy goals regarding misissuance.



This is https://github.com/mozilla/pkipolicy/issues/1 for what it's worth, recently resolved in Policy 2.4

On Wed, Feb 22, 2017 at 5:08 PM, Richard Wang via dev-security-policy <dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>> wrote:

I think "apple-id-2.com<http://apple-id-2.com>" is a high risk domain that must be blocked to issue DV SSL to those domains.

Here is the list of some high risk domains related to Microsoft and Google that Let's Encrypt issued DV SSL certificates to those domains:

https://crt.sh/?id=77034583 for microsoftonline.us.com<http://microsoftonline.us.com>, a fake Office 365 login site
https://crt.sh/?id=71789336 for mail.google-androids.ru<http://mail.google-androids.ru>
https://crt.sh/?id=82075006 for marketgoogle.xyz<http://marketgoogle.xyz>
https://crt.sh/?id=65208905 for google.ligboy.org<http://google.ligboy.org>

Best Regards,

Richard


-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosig...@lists.mozilla.org<mailto:wosig...@lists.mozilla.org>] On Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, February 23, 2017 8:30 AM
To: Tony Zhaocheng Tan <to...@tonytan.io<mailto:to...@tonytan.io>>; mozilla-dev-s...@lists.mozilla.org<mailto:mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On 22/02/17 14:42, Tony Zhaocheng Tan wrote:

> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com<http://apple-id-2.com>.
> However, until today, the domain apple-id-2.com<http://apple-id-2.com> has apparently never

> been registered. How was the certificate issued?

On Hacker News, Josh Aas writes:

"Head of Let's Encrypt here. Our team is looking into this and so far we don't see any evidence of mis-issuance in our logs. It looks like the domain in question, 'apple-id-2.com<http://apple-id-2.com>', was registered and DNS resolved for it successfully at time of issuance. Here is the valid authorization record including the resolved IP addresses for 'apple-id-2.com<http://apple-id-2.com>':

https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...

We can't be sure why the reporter was unable to find a WHOIS record, we can only confirm that validation properly succeeded at time of issuance.

Update: Squarespace has confirmed that they did register the domain and then released it after getting a certificate from us."

There is currently an entry in WHOIS, because some well-meaning but unhelpful person registered it today. I assume that if a domain is registered and then released, and then re-registered, the "Creation"
date is of the re-registration, not the first ever registration.

So unless someone can show it was unregistered at the time of issuance, I don't see an issue here.

Gerv
_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>

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

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Peter Bowen]

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> As I understand, the BR 4.2.1 required this:
>
> “The CA SHALL develop, maintain, and implement documented procedures that identify and require additional verification activity for High Risk Certificate Requests prior to the Certificate’s approval, as reasonably necessary to ensure that such requests are properly verified under these Requirements.”
>
> Please clarify this request, thanks.

Richard,

That sentence does not say that domain names including "apple",
"google", or any other string are High Risk Certificate Requests
(HRCR). I could define HRCR as being those that contain domain names
that contain mixed script characters as defined in UTS #39 section
5.1. "apple-id-2.com" is not mixed script so it is not a HRCR based
on this definition.

Thanks,
Peter

[Richard Wang]

I don't agree this.
If "apple", "google", "Microsoft" is not a high risk domain, then I don’t know which domain is high risk domain, maybe only "github".

Best Regards,

Richard

-----Original Message-----
From: Peter Bowen [mailto:pzb...@gmail.com]
Sent: Thursday, February 23, 2017 11:53 AM
To: Richard Wang <ric...@wosign.com>
Cc: ry...@sleevi.com; mozilla-dev-s...@lists.mozilla.org; Tony
Zhaocheng Tan <to...@tonytan.io>; Gervase Markham <ge...@mozilla.org>
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that
doesn't exist

[Ryan Sleevi]

Hi Richard,

My point was that policy requirement simply states that there needs to be a
procedure, but does not establish any normative requirements. For example,
a CA could develop, maintain, and implement procedures which states that
any certificate that is qualified as High Risk requires Gerv Markham's
personal seal of approval - and could define the way to do so - but they
could also say that "Only certificates requested by Gerv Markham are
considered High Risk"

Alternatively, a CA could deem that all High Risk certificates will require
a second DNS resolution after 30 seconds, to make sure that the first was
not forged. And that can be developed, maintained, and implemented - but
again, doesn't do what you want.

Your suggestion - which was worded as specific domains, but if I might be
as bold as to suggest what you meant to say, likely meant substrings in
domains - implies that there is a certain common requirement either on how
to handle such High Risk requests (block/manually approve/require Gerv's
personal seal of approval imbued upon a wax maintained at a 78 degree
centrigrade temperature for no less than 30 minutes prior to imbuing) or
how to define what is high risk (e.g. substring, CAA, "people we don't like
because they embarrassed us")

Because the BRs (and Mozilla policy) neither specify what _is_ High Risk or
what is _acceptable_ when a High Risk request is processed, it does not
make any sense to suggest particular domains (or substrings) be prohibited
without tackling those two issues first. This is why I suggested that the
solution you've proposed, under the current policies in play, has zero
effect. If you believe your solution is right/appropriate, then the first
step would be to change the policies.

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang <ric...@wosign.com> wrote:

> Hi Ryan,

>
>
>
> As I understand, the BR 4.2.1 required this:
>
> “The CA SHALL develop, maintain, and implement documented procedures that
> identify and require additional verification activity for High Risk
> Certificate Requests prior to the Certificate’s approval, as reasonably
> necessary to ensure that such requests are properly verified under these
> Requirements.”
>
>
>
> Please clarify this request, thanks.
>
>
>
>
>

> Best Regards,
>
>
>
> Richard
>
>
>
> *From:* Ryan Sleevi [mailto:ry...@sleevi.com]
> *Sent:* Thursday, February 23, 2017 11:21 AM
> *To:* Richard Wang <ric...@wosign.com>
> *Cc:* Gervase Markham <ge...@mozilla.org>; Tony Zhaocheng Tan <
> to...@tonytan.io>; mozilla-dev-s...@lists.mozilla.org
>
> *Subject:* Re: Let's Encrypt appears to issue a certificate for a domain
> that doesn't exist
>
>
>

> Hi Richard,
>
>
>
> There's no policies in the Baseline Requirements or Mozilla Requirements
> that normalize or define high risk domain, which I believe your suggestion
> presupposes.
>
>
>
> Perhaps you (or Qihoo 360, as the voting member of the Forum of the
> Qihoo/WoSign/StartCom collection) would consider proposing a Ballot to the
> Baseline Requirements to address this. Alternatively, perhaps you would
> have a concrete suggestion for Mozilla Root CA Inclusion Policy 2.5 that
> might be able to address this in a consistent and auditable way and in a
> manner consistent with Mozilla's policy goals regarding misissuance.
>
>
>
> This is https://github.com/mozilla/pkipolicy/issues/1 for what it's
> worth, recently resolved in Policy 2.4
>
>
>

> On Wed, Feb 22, 2017 at 5:08 PM, Richard Wang via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> I think "apple-id-2.com" is a high risk domain that must be blocked to

> issue DV SSL to those domains.
>
> Here is the list of some high risk domains related to Microsoft and Google
> that Let's Encrypt issued DV SSL certificates to those domains:

> https://crt.sh/?id=77034583 for microsoftonline.us.com, a fake Office

> 365 login site
> https://crt.sh/?id=71789336 for mail.google-androids.ru

> https://crt.sh/?id=82075006 for marketgoogle.xyz
> https://crt.sh/?id=65208905 for google.ligboy.org
>
>

> Best Regards,
>
> Richard
>
>
> -----Original Message-----

> From: dev-security-policy [mailto:dev-security-policy-bounces+richard=
> wosig...@lists.mozilla.org] On Behalf Of Gervase Markham via
> dev-security-policy
> Sent: Thursday, February 23, 2017 8:30 AM

> To: Tony Zhaocheng Tan <to...@tonytan.io>; mozilla-dev-security-policy@
> lists.mozilla.org
> Subject: Re: Let's Encrypt appears to issue a certificate for a domain
> that doesn't exist
>

> On 22/02/17 14:42, Tony Zhaocheng Tan wrote:

> > On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> > However, until today, the domain apple-id-2.com has apparently never
> > been registered. How was the certificate issued?
>

> On Hacker News, Josh Aas writes:
>
> "Head of Let's Encrypt here. Our team is looking into this and so far we
> don't see any evidence of mis-issuance in our logs. It looks like the

> domain in question, 'apple-id-2.com', was registered and DNS resolved for

> it successfully at time of issuance. Here is the valid authorization record

> including the resolved IP addresses for 'apple-id-2.com':

>
> https://acme-v01.api.letsencrypt.org/acme/authz/uZGv2KXUJ6Hl...
>
> We can't be sure why the reporter was unable to find a WHOIS record, we
> can only confirm that validation properly succeeded at time of issuance.
>
> Update: Squarespace has confirmed that they did register the domain and
> then released it after getting a certificate from us."
>
> There is currently an entry in WHOIS, because some well-meaning but
> unhelpful person registered it today. I assume that if a domain is
> registered and then released, and then re-registered, the "Creation"
> date is of the re-registration, not the first ever registration.
>
> So unless someone can show it was unregistered at the time of issuance, I
> don't see an issue here.
>
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

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

> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
>

[Ryan Sleevi]

There is no definition or requirement for what a high risk domain is.
That's the point/problem.

WoSign may determine "apple", "google", "microsoft", and "github" as High
Risk.
Amazon may determine certificates issued on the first of the month are more
likely to be High Risk (because it may be that the 1st of the month is the
most lucrative time for credit card scammers to use their ill-gotten gains
to produce dangerous domains)

On Wed, Feb 22, 2017 at 7:55 PM, Richard Wang <ric...@wosign.com> wrote:

> I don't agree this.
> If "apple", "google", "Microsoft" is not a high risk domain, then I don’t
> know which domain is high risk domain, maybe only "github".
>

> Best Regards,
>
> Richard
>
> -----Original Message-----

> From: Peter Bowen [mailto:pzb...@gmail.com]
> Sent: Thursday, February 23, 2017 11:53 AM
> To: Richard Wang <ric...@wosign.com>
> Cc: ry...@sleevi.com; mozilla-dev-s...@lists.mozilla.org; Tony
> Zhaocheng Tan <to...@tonytan.io>; Gervase Markham <ge...@mozilla.org>

> Subject: Re: Let's Encrypt appears to issue a certificate for a domain that
> doesn't exist
>

> On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy
> <dev-secur...@lists.mozilla.org> wrote:
> > As I understand, the BR 4.2.1 required this:
> >
> > “The CA SHALL develop, maintain, and implement documented procedures that
> > identify and require additional verification activity for High Risk
> > Certificate Requests prior to the Certificate’s approval, as reasonably
> > necessary to ensure that such requests are properly verified under these
> > Requirements.”
> >
> > Please clarify this request, thanks.
>

[Vincent Lynch]

Hi Richard,

Peter's point is that there is no standard definition of a "high-risk"
request." It is a term defined in Section 1.6.1:

"High Risk Certificate Request: A Request that the CA flags for additional
scrutiny by reference to internal criteria and databases maintained by the
CA, which may include names at higher risk for phishing or other fraudulent
usage, names contained in previously rejected certificate requests or
revoked Certificates, names listed on the Miller Smiles phishing list or
the Google Safe Browsing list, or names that the CA identifies using its
own risk‐mitigation criteria."

Because of the ambiguity of the definition, CAs are essentially given full
discretion over what THEY think high risk is. You are allowed to say
domains containing the string "apple" are high risk, and treat them as
such. However, other CAs are allowed to decide that isn't high risk.

On Wed, Feb 22, 2017 at 10:55 PM, Richard Wang via dev-security-policy <

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

--
Vincent Lynch

[Matt Palmer]

On Wed, Feb 22, 2017 at 10:00:45PM -0500, George Macon via dev-security-policy wrote:
> On 2/22/17 7:30 PM, Gervase Markham wrote:

> > On Hacker News, Josh Aas writes:
> > Update: Squarespace has confirmed that they did register the domain and
> > then released it after getting a certificate from us."
>

> In this case, should Squarespace have requested that the certificate be
> revoked before releasing the domain?

No.

> Is there a way to automatically detect that the domain was released? (I
> suspect the answer to this question is "not easily".)

There have been feeds provided in the past (they may still exist, but I
haven't needed to look for them for some years) for registered domains, I
don't know if something exists for expiration, but it certainly seems like
it, given the speed with which squatters appear able to pick up expired
domains.

> Would it make sense to prohibit certificate issuance during the grace
> period?

No.

- Matt

[Matt Palmer]

On Thu, Feb 23, 2017 at 01:08:49AM +0000, Richard Wang via dev-security-policy wrote:
> I think "apple-id-2.com" is a high risk domain that must be blocked to issue DV SSL to those domains.

Why?

> Here is the list of some high risk domains related to Microsoft and Google that Let's Encrypt issued DV SSL certificates to those domains:
> https://crt.sh/?id=77034583 for microsoftonline.us.com, a fake Office 365 login site
> https://crt.sh/?id=71789336 for mail.google-androids.ru
> https://crt.sh/?id=82075006 for marketgoogle.xyz
> https://crt.sh/?id=65208905 for google.ligboy.org

... and? Issuance of a certificate (even EV) doesn't imply endorsement or an
attestation of anything other than "something has been done to verify
identity". It is a means of providing *communication security* only,
attempts by the marketing departments of certain CAs to fradulently imply
otherwise notwithstanding.

- Matt

[Peter Bowen]

On Wed, Feb 22, 2017 at 8:31 PM, Matt Palmer via dev-security-policy
<dev-secur...@lists.mozilla.org> wrote:
> On Wed, Feb 22, 2017 at 10:00:45PM -0500, George Macon via dev-security-policy wrote:
>> On 2/22/17 7:30 PM, Gervase Markham wrote:

>> > On Hacker News, Josh Aas writes:
>> > Update: Squarespace has confirmed that they did register the domain and
>> > then released it after getting a certificate from us."
>>

>> In this case, should Squarespace have requested that the certificate be
>> revoked before releasing the domain?
>
> No.
>
>> Is there a way to automatically detect that the domain was released? (I
>> suspect the answer to this question is "not easily".)
>
> There have been feeds provided in the past (they may still exist, but I
> haven't needed to look for them for some years) for registered domains, I
> don't know if something exists for expiration, but it certainly seems like
> it, given the speed with which squatters appear able to pick up expired
> domains.

There are several different possible feeds. I get a daily update of
zone files for all gTLDs (less .edu, .mil, .gov, and .int). It
doesn't tell if the whois information changed but you can tell
added/removed registered domains if you have the previous day's data.

[Peter Bowen]

Rather than what you suggest, I think the following could be high risk:

свiтова-пошта.info.
xn--i--7kcbgb7fdinng1f.info.

гooms17139.link.
xn--ooms17139-uzh.link.

мцяsц.lol.
xn--s-wtb4ab7b.lol.

сaентология.net.
xn--a-ftbfnnlhbvn2m.net.

aμ.net.
xn--a-mmb.net.

μc.net.
xn--c-lmb.net.

ωe.net.
xn--e-cnb.net.

аgentur.net.
xn--gentur-2nf.net.

ωomega.net.
xn--omega-gee.net.

phantфm.net.
xn--phantm-7rf.net.

रोले盧स.net.
xn--t2bes3ds6749n.net.

[Nick Lamb]

On Thursday, 23 February 2017 01:11:54 UTC, Richard Wang wrote:
> https://crt.sh/?id=65208905 for google.ligboy.org

Without wanting to jump on this pre-existing dogpile:

This specific example is illustrative of two important factors that should be considered in examining the threat here:

1. Neither registries nor registrars in the DNS system would ordinarily have control over the existence of sub-domains. In some cases the whole _purpose_ of the registration is to create such sub-domains without further administration, it would be untenable to run e.g. blogspot.co.uk with oversight from Nominet on every sub-domain for example. So nobody is in a position to ensure that when uninteresting.example is registered its new owners will never create an FQDN microsoft-tech-support.uninteresting.example

2. Wildcard DV certificates can't forbid such misleading labels because they deliberately cover all possible labels in that suffix. So the legitimate owner of uninteresting.example can apply for and receive a Wildcard DV certificate *.uninteresting.example and _only then_ create microsoft-tech-support.uninteresting.example for which the wildcard provides a perfectly good working SSL certificate.

Basically, "fixing" this through CA policy will either require a pretty big change in how DV is done across the industry or giving up on DV altogether. I don't believe either of those is likely.

By the way, the corporate enthusiasm for out-sourcing key internal services means you will see more and more FQDNs like fortune500corp.tiny-startup.example because the Fortunate 500 company is _paying_ the tiny startup to operate such a site for their people out on the public Internet.

[Gervase Markham]

On 22/02/17 17:08, Richard Wang wrote:
> I think "apple-id-2.com" is a high risk domain that must be blocked to issue DV SSL to those domains.

I don't represent Let's Encrypt, but their policy on such things is
relevant to this discussion, and it is here:
https://letsencrypt.org/2015/10/29/phishing-and-malware.html

Gerv

[Matt Palmer]

On Thu, Feb 23, 2017 at 01:55:40AM -0800, Nick Lamb via dev-security-policy wrote:
> 1. Neither registries nor registrars in the DNS system would ordinarily
> have control over the existence of sub-domains. In some cases the whole
> _purpose_ of the registration is to create such sub-domains without
> further administration, it would be untenable to run e.g. blogspot.co.uk
> with oversight from Nominet on every sub-domain for example. So nobody is
> in a position to ensure that when uninteresting.example is registered its
> new owners will never create an FQDN
> microsoft-tech-support.uninteresting.example

Registries and registrars aren't in a position to block or otherwise
interfere with shady subdomain labels, but recursive and "upstream"
authoritative nameservers are. Both get the full FQDN being resolved, and
while caching can mean that the root and '.example` authoritative
nameservers may, or may not, see that someone is looking up
`microsoft-tech-support.uninteresting.example`, whatever recursive resolver
the client is using (whether it be on-box, on-LAN, ISP-provided, or a public
service such as 8.8.8.8/8.8.4.4) definitely sees the full request.

- Matt

[Matt Palmer]

On Thu, Feb 23, 2017 at 03:55:43AM +0000, Richard Wang via dev-security-policy wrote:
> If "apple", "google", "Microsoft" is not a high risk domain, then I don’t know which domain is high risk domain, maybe only "github".

That's kinda the problem: you don't know, and neither does anyone else,
because there's no agreed-upon definition or policy for what constitutes a
"high risk domain".

- Matt

[Peter Kurrasch]

By and large I'd say that Matt's no's should instead be yes's. If we adopt the standpoint that releasing a domain is equivalent to saying "I no longer use that name" then a revocation is equivalent to adding "...and anyone who does use that name must surely be an imposter."

In other words, we should give relying parties every opportunity to determine legitimate-or-fraud to the greatest extent possible. Granted the real world is not quite so simple but I think that's (part of?) the spirit of what we're here to do.


  Original Message  
From: Matt Palmer via dev-security-policy
Sent: Wednesday, February 22, 2017 10:32 PM
To: dev-secur...@lists.mozilla.org
Reply To: Matt Palmer

Subject: Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On Wed, Feb 22, 2017 at 10:00:45PM -0500, George Macon via dev-security-policy wrote:
> On 2/22/17 7:30 PM, Gervase Markham wrote:

> > On Hacker News, Josh Aas writes:
> > Update: Squarespace has confirmed that they did register the domain and
> > then released it after getting a certificate from us."
>

> In this case, should Squarespace have requested that the certificate be
> revoked before releasing the domain?

No.

> Is there a way to automatically detect that the domain was released? (I
> suspect the answer to this question is "not easily".)

There have been feeds provided in the past (they may still exist, but I
haven't needed to look for them for some years) for registered domains, I
don't know if something exists for expiration, but it certainly seems like
it, given the speed with which squatters appear able to pick up expired
domains.

> Would it make sense to prohibit certificate issuance during the grace
> period?

No.

- Matt

[Eric Mill]

This list hosted an extensive discussion on this issue in May of 2016,
subject line "SSL Certs for Malicious Websites":

https://groups.google.com/d/topic/mozilla.dev.security.polic
y/vMrncPi3tx8/discussion

Most (all?) of the people on this thread participated on that one, and said
most (all?) of these things. It's probably not worth rehashing it in a new
thread that started on a different topic (misissuance to a non-existing
domain) that is now resolved.

-- Eric

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

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

[Richard Wang]

I am sure this site: https://www.microsoftonline.us.com/ is a phishing site and a fade office 365 site that I wish LE can revoke this cert.

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Gervase Markham via dev-security-policy
Sent: Friday, February 24, 2017 2:13 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that doesn't exist

On 22/02/17 17:08, Richard Wang wrote:

> I think "apple-id-2.com" is a high risk domain that must be blocked to issue DV SSL to those domains.

I don't represent Let's Encrypt, but their policy on such things is relevant to this discussion, and it is here:
https://letsencrypt.org/2015/10/29/phishing-and-malware.html

[Matt Palmer]

On Fri, Feb 24, 2017 at 01:12:38AM +0000, Richard Wang via dev-security-policy wrote:
> I am sure this site: https://www.microsoftonline.us.com/ is a phishing site and a fade office 365 site that I wish LE can revoke this cert.

Why? It works just fine over HTTP, too.

- Matt

[Richard Wang]

Do you think this site is an authentic site from Microsoft?
If it is a fake site, then CA should revoke the issued certificate.

Best Regards,

Richard

-----Original Message-----
From: dev-security-policy
[mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On
Behalf Of Matt Palmer via dev-security-policy
Sent: Friday, February 24, 2017 10:35 AM
To: dev-secur...@lists.mozilla.org
Subject: Re: Let's Encrypt appears to issue a certificate for a domain that
doesn't exist

On Fri, Feb 24, 2017 at 01:12:38AM +0000, Richard Wang via
dev-security-policy wrote:
> I am sure this site: https://www.microsoftonline.us.com/ is a phishing

site and a fake office 365 site that I wish LE can revoke this cert.

Why? It works just fine over HTTP, too.

- Matt

[Matt Palmer]

On Fri, Feb 24, 2017 at 03:09:10AM +0000, Richard Wang via dev-security-policy wrote:
> Do you think this site is an authentic site from Microsoft?
> If it is a fake site, then CA should revoke the issued certificate.

Why?

- Matt

[wuyi]

According to what I’ve known,


“Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber or Terms of Use Agreement or if the CA discovers that the Certificate is being used to enable criminal activities such as phishing attacks, fraud, or the distribution of malware.” (Let’s Encrypt’ CP 9.6.3)




Now that a phishing site has been detected with a valid certificate, but no immediate action was taken on it. I don’t think that this is what a CA, who states to “Support a more secure and privacy-respecting Web” is supposed to do.




Quoted from Google’s Policy, “it would be no different than a firefighter who was not responding to fires in which people died.”


It may be difficult to sort what types of domains are high risk, but when a certificate was used in this way without being revoked, it was no difference from the Google CP’s metaphor. As an Internet user I was disappointed about that, and those in the LE’ CP above can be treated as nonsense.


Nio
SZU

On Fri, Feb 24, 2017 at 01:12:38AM +0000, Richard Wang via dev-security-policy wrote:

> >I am sure this site: https://www.microsoftonline.us.com/ is a phishing site and a fade office 365 site that I wish LE can revoke this cert.

>Why? It works just fine over HTTP, too.


>- Matt
_______________________________________________


dev-security-policy mailing list


dev-secur...@lists.mozilla.org


https://lists.mozilla.org/listinfo/dev-security-policy

发自我的iPhone

[Vincent Lynch]

As you have quoted it, Let's Encrpyt's CPS says:

"the CA is *entitled* to revoke the certificate"

The key word is "entitled." Meaning that Let's Encrypt may revoke the
certificate if they chose, but are not required to. Therefore not revoking
the certificate is compatible with their CPS.

It's important to realize this is not an argument about what *should* be
done or what we think is right, but what *can* be done under the current
rules and regulations.

The fact is that the CAB/F BR's are so (intentionally) ambiguous about
"high risk" certificates that there is no real way meaning to that section
and no real way for a CA to violate said section.




As others have mentioned, please can we stop writing unrelated comments on
this thread. This thread is about a specific report about a DV cert being
issued to a non-existent domain. That report turned out to be false. Unless
comments are about that report, this is the wrong thread to post in.

I would also encourage anyone interested in the topic of high risk requests
and certs being issued to phishing sites to see Eric Mill's comment in this
thread. He has provided a link to past discussion on this topic, and I can
promise you that however displeasing and shocking this practice may be, it
has already been considered and debated.

--
Vincent Lynch

[wuyi]

Exactly that’s the meaning of “entitle”.
Based on the interpretation, I understand that when a firefighter is on a vocation, even a fire breaks next to him, it’s of his choice to go hiking, fly kites whatever as he may only be entitled on weekdays rather than in a vocation.
IMO, the point of the Let’s Encrypt’ CP 9.6.3 is to ensure that the CA has privilege to revoke certificate when certain issue happens as it describes. The deeper meaning of it is that it ensures the CA has ability to maintain online security anytime, but it’s enough. I am not going to debate here, I would rather go and teach my grandfather those green lock icons from some certain CA means anything but online security they states.
Nio
SZU


发自我的iPhone

------------------ Original ------------------
From: Vincent Lynch via dev-security-policy <dev-secur...@lists.mozilla.org>
Date: Fri,Feb 24,2017 15:10
To: dev-security-policy <dev-secur...@lists.mozilla.org>, wuyi <5943...@qq.com>

Subject: Re: Let's Encrypt appears to issue a certificate for a domain thatdoesn't exist

[Gervase Markham]

On 23/02/17 21:35, wuyi wrote:
> “Acknowledgment and Acceptance: An acknowledgment and acceptance that
> the CA is entitled to revoke the certificate immediately if the
> Applicant were to violate the terms of the Subscriber or Terms of Use
> Agreement or if the CA discovers that the Certificate is being used
> to enable criminal activities such as phishing attacks, fraud, or the
> distribution of malware.” (Let’s Encrypt’ CP 9.6.3)

Again, I don't represent LE, but "is entitled to" is not the same thing
as "must".

Gerv

[Peter Kurrasch]

What you've stumbled into is the unspoken truth that CA's want to have their cake and eat it too.

Specifically, they market themselves and their products under the umbrella of security: "You want to be secure on the Internet, right? We can help you do that!"‎ Then, most all CA's will turn around and say: "Oh by the way, if you encounter a situation in which something bad happens it's not our fault because we couldn't possibly ‎confirm that what we say is secure is in fact secure."

Let's Encrypt is not unique as I think most CA's express this viewpoint in one form or another. This may be acceptable from a legal or compliance standpoint but not in terms of reputation. As people find themselves in bad situations because of a malicious site that used one of their certs, they very well might blame the CA.

Certainly a CA does not want the reputation of being "the preferred cert vendor for malicious sites everywhere" so whatever principles they try to espouse, the reality will be more complicated.


  Original Message  
From: wuyi via dev-security-policy
Sent: Friday, February 24, 2017 1:57 AM
To: vtlynch; dev-security-policy
Reply To: wuyi

> “Acknowledgment and Acceptance: An acknowledgment and acceptance that the
> CA is entitled to revoke the certificate immediately if the Applicant were
> to violate the terms of the Subscriber or Terms of Use Agreement or if the
> CA discovers that the Certificate is being used to enable criminal
> activities such as phishing attacks, fraud, or the distribution of
> malware.” (Let’s Encrypt’ CP 9.6.3)
>
>
>
>