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

[Vincent Lynch via dev-security-policy]

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.



On Fri, Feb 24, 2017 at 12:36 AM wuyi via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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 +, 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-security-policy@lists.mozilla.org
>
>
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> 发自我的iPhone
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
-- 
Vincent Lynch
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[wuyi via dev-security-policy]

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 +, 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-security-policy@lists.mozilla.org


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


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

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

[Matt Palmer via dev-security-policy]

On Fri, Feb 24, 2017 at 03:09:10AM +, 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

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

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

[Richard Wang via dev-security-policy]

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=wosign@lists.mozilla.org] On
Behalf Of Matt Palmer via dev-security-policy
Sent: Friday, February 24, 2017 10:35 AM
To: dev-security-policy@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 +, 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

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

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

[Matt Palmer via dev-security-policy]

On Fri, Feb 24, 2017 at 01:12:38AM +, 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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Richard Wang via dev-security-policy]

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=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham via dev-security-policy
Sent: Friday, February 24, 2017 2:13 AM
To: mozilla-dev-security-pol...@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

Gerv

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

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

[Eric Mill via dev-security-policy]

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

On Thu, Feb 23, 2017 at 6:29 PM, Matt Palmer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Feb 23, 2017 at 03:55:43AM +, 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
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matt Palmer via dev-security-policy]

On Thu, Feb 23, 2017 at 03:55:43AM +, 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

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

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

[Matt Palmer via dev-security-policy]

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

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

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

[Gervase Markham via dev-security-policy]

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

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

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

[Nick Lamb via dev-security-policy]

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

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.



On Wed, Feb 22, 2017 at 7:55 PM, Richard Wang  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:pzbo...@gmail.com]
> Sent: Thursday, February 23, 2017 11:53 AM
> To: Richard Wang 
> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony
> Zhaocheng Tan ; Gervase Markham 
> 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
>  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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Matt Palmer via dev-security-policy]

On Thu, Feb 23, 2017 at 01:08:49AM +, 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

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

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

[Vincent Lynch via dev-security-policy]

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@lists.mozilla.org> 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:pzbo...@gmail.com]
> Sent: Thursday, February 23, 2017 11:53 AM
> To: Richard Wang 
> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony
> Zhaocheng Tan ; Gervase Markham 
> 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
>  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
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
Vincent Lynch
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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  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:pzbo...@gmail.com]
> Sent: Thursday, February 23, 2017 11:53 AM
> To: Richard Wang 
> Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony
> Zhaocheng Tan ; Gervase Markham 
> 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
>  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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi via dev-security-policy]

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  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:r...@sleevi.com]
> *Sent:* Thursday, February 23, 2017 11:21 AM
> *To:* Richard Wang 
> *Cc:* Gervase Markham ; Tony Zhaocheng Tan <
> t...@tonytan.io>; mozilla-dev-security-pol...@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-security-policy@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=
> wosign@lists.mozilla.org] On Behalf Of Gervase Markham via
> dev-security-policy
> Sent: Thursday, February 23, 2017 8:30 AM
> To: Tony Zhaocheng Tan ; 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 

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

[Richard Wang via dev-security-policy]

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:pzbo...@gmail.com]
Sent: Thursday, February 23, 2017 11:53 AM
To: Richard Wang 
Cc: r...@sleevi.com; mozilla-dev-security-pol...@lists.mozilla.org; Tony 
Zhaocheng Tan ; Gervase Markham 
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 
 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

On Wed, Feb 22, 2017 at 7:35 PM, Richard Wang via dev-security-policy
 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Richard Wang via dev-security-policy]

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:r...@sleevi.com]
Sent: Thursday, February 23, 2017 11:21 AM
To: Richard Wang 
Cc: Gervase Markham ; Tony Zhaocheng Tan ; 
mozilla-dev-security-pol...@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 
>
 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=wosign@lists.mozilla.org]
 On Behalf Of Gervase Markham via dev-security-policy
   Sent: Thursday, February 23, 2017 8:30 AM
   To: Tony Zhaocheng Tan >; 
mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org
   https://lists.mozilla.org/listinfo/dev-security-policy
   ___
   dev-security-policy mailing list
   
dev-security-policy@lists.mozilla.org
   https://lists.mozilla.org/listinfo/dev-security-policy



___
dev-security-policy mailing list

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

[Ryan Sleevi via dev-security-policy]

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-security-policy@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=
> wosign@lists.mozilla.org] On Behalf Of Gervase Markham via
> dev-security-policy
> Sent: Thursday, February 23, 2017 8:30 AM
> To: Tony Zhaocheng Tan ; 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-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[George Macon via dev-security-policy]

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?

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Richard Wang via dev-security-policy]

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=wosign@lists.mozilla.org] On 
Behalf Of Gervase Markham via dev-security-policy
Sent: Thursday, February 23, 2017 8:30 AM
To: Tony Zhaocheng Tan ; 
mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Tony Zhaocheng Tan via dev-security-policy]

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

Thanks,
Tony


Tony Zhaocheng Tan | t...@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:

"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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham via dev-security-policy]

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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy