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

2017-02-23 Thread wuyi via dev-security-policy 
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 

Date: Fri,Feb 24,2017 15:10
To: dev-security-policy , wuyi 
<594346...@qq.com>
Subject: Re: Let's Encrypt appears to issue a certificate for a domain 
thatdoesn't exist



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
___
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

2017-02-23 Thread 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

2017-02-23 Thread 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

2017-02-23 Thread 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

2017-02-23 Thread 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

2017-02-23 Thread 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: SHA-1 collision

2017-02-23 Thread Ryan Sleevi via dev-security-policy 
On Thu, Feb 23, 2017 at 5:16 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> For example, in a certificate request, while the attacker can "choose"
> such a bunch of bits in the public key, the value also has to be a valid
> public key for which the attacker can generate at least one digital
> signature (the one on the CSR).


I do not believe this is correct. Can you please point me to the Baseline
Requirements' requirement that the Applicant demonstrate proof of
possession of a private key through a CSR?



> For RSA certificates, this might be done by requesting a longer that 2048
> bit public key found by searching for primes whose most significant 1024
> bits multiply to form the attack value (such prime searching is a standard
> part of legitimate key generation).  The length of the request DN would
> then need to be adjusted to align the public key just right for the public
> key to start at a 64 byte boundary after adding the stuff the victim CA
> adds.  And after that, the actual 128 byte block would need the very costly
> calculation for a prefix corresponding to the combination of the chosen
> request parameters and whatever the CA is predicted to add, including any
> random serial number bits and whatever "predictable" serial number and
> timestamp will be used after the multi-month calculation period.
>

What you describe is not wrong, but it's also not right either. Perhaps
it'd be easier to simply point to the original, more accurate, and more
comprehensive description of the MD5 Rogue CA, which more accurately
addresses where the weaknesses are in the issuance process -
https://www.win.tue.nl/hashclash/rogue-ca/


> As a further countermeasure, I would suggest that CAs operating
> continued SHA-1 services (such as Windows XP compatible code signing
> certificate issuance and signature timestamping) should run a
> variation of the "sha1collisiondetection" check released Tuesday by the
> CWI/Google team, and simply refuse requests that this check flags as
> suspicious.


The checking for SHA-1 collision detection has been available from
Marc-et-al since 2012. There have been several improvements over the years
since, but that basic piece of advice is one that the community has already
been sharing for five years now.
___
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

2017-02-23 Thread 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

2017-02-23 Thread 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

Release and revoke (was: Let's Encrypt appears to issue a certificate for a domain that doesn't exist)

2017-02-23 Thread Peter Kurrasch via dev-security-policy 
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-security-policy@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

___
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

2017-02-23 Thread 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

2017-02-23 Thread 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: SHA-1 collision

2017-02-23 Thread Yuhong Bao via dev-security-policy 
identical prefix, not chosen prefix. I was more interested in an SHA-1 
collision ASIC.

From: dev-security-policy 
 on 
behalf of Adrian R. via dev-security-policy 

Sent: Thursday, February 23, 2017 8:26:10 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: SHA-1 collision

Hello

i just saw this in the news... a SHA-1 collision has been achieved.

https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/

proof site:  https://shattered.io/

authors:
Marc Stevens (1), Elie Bursztein (2), Pierre Karpman (1), Ange Albertini (2), 
Yarik Markov (2)
1 = CWI Amsterdam
2 = Google Research

File: shattered-1.pdf
  CRC-32: 348150fb
 MD5: ee4aa52b139d925f8d8884402b0a750c
   SHA-1: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a
 SHA-256: 2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0
 SHA-512: 
3c19b2cbcf72f7f5b252ea31677b8f2323d6119e49bcc0fb55931d00132385f1e749bb24cbd68c04ac826ae8421802825d3587fe185abf709669bb9693f6b416

File: shattered-2.pdf
  CRC-32: b3fbab1c
 MD5: 5bd9d8cabc46041579a311230539b8d1
   SHA-1: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a
 SHA-256: d4488775d29bdef7993367d541064dbdda50d383f89f0aa13a6ff2e0894ba5ff
 SHA-512: 
f39a04842e4b28e04558496beb7cb84654ded9c00b2f873c3ef64f9dfdbc760cd0273b816858ba5b203c0dd71af8b65d6a0c1032e00e48ace0b4705eedcc1bab

___
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

2017-02-23 Thread 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

SHA-1 collision

2017-02-23 Thread Adrian R. via dev-security-policy 
Hello

i just saw this in the news... a SHA-1 collision has been achieved.

https://arstechnica.com/security/2017/02/at-deaths-door-for-years-widely-used-sha1-function-is-now-dead/

proof site:  https://shattered.io/

authors: 
Marc Stevens (1), Elie Bursztein (2), Pierre Karpman (1), Ange Albertini (2), 
Yarik Markov (2)
1 = CWI Amsterdam
2 = Google Research

File: shattered-1.pdf
  CRC-32: 348150fb
 MD5: ee4aa52b139d925f8d8884402b0a750c
   SHA-1: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a
 SHA-256: 2bb787a73e37352f92383abe7e2902936d1059ad9f1ba6daaa9c1e58ee6970d0
 SHA-512: 
3c19b2cbcf72f7f5b252ea31677b8f2323d6119e49bcc0fb55931d00132385f1e749bb24cbd68c04ac826ae8421802825d3587fe185abf709669bb9693f6b416

File: shattered-2.pdf
  CRC-32: b3fbab1c
 MD5: 5bd9d8cabc46041579a311230539b8d1
   SHA-1: 38762cf7f55934b34d179ae6a4c80cadccbb7f0a
 SHA-256: d4488775d29bdef7993367d541064dbdda50d383f89f0aa13a6ff2e0894ba5ff
 SHA-512: 
f39a04842e4b28e04558496beb7cb84654ded9c00b2f873c3ef64f9dfdbc760cd0273b816858ba5b203c0dd71af8b65d6a0c1032e00e48ace0b4705eedcc1bab

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

Re: Audit Reminder Email Summary

2017-02-23 Thread Kathleen Wilson via dev-security-policy 
 Forwarded Message 
Subject: Summary of February 2017 Audit Reminder Emails
Date: Tue, 21 Feb 2017 20:00:51 + (GMT)

Mozilla: Audit Reminder
Root Certificates:
   ISRG Root X1
Standard Audit: https://cert.webtrust.org/SealFile?seal=1987=pdf
Audit Statement Date: 2015-12-15
BR Audit: https://cert.webtrust.org/SealFile?seal=1988=pdf
BR Audit Statement Date: 2015-12-15
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Staat der Nederlanden EV Root CA
   Staat der Nederlanden Root CA - G3
   Staat der Nederlanden Root CA - G2
Standard Audit: https://cert.webtrust.org/SealFile?seal=2010=pdf
Audit Statement Date: 2016-03-02
BR Audit: https://cert.webtrust.org/SealFile?seal=2010=pdf
BR Audit Statement Date: 2016-03-02
EV Audit: https://cert.webtrust.org/SealFile?seal=2010=pdf
EV Audit Statement Date: 2016-03-02
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SZAFIR ROOT CA2
Standard Audit: https://cert.webtrust.org/SealFile?seal=2018=pdf
Audit Statement Date: 2016-03-18
BR Audit: https://cert.webtrust.org/SealFile?seal=2018=pdf
BR Audit Statement Date: 2016-03-18
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   certSIGN ROOT CA
Standard Audit: 
https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA.pdf
Audit Statement Date: 2016-02-08
BR Audit: https://www.certsign.ro/certsign_en/files/certSIGN_Webtrust_CA.pdf
BR Audit Statement Date: 2016-02-08
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Cybertrust Global Root
Standard Audit: https://cert.webtrust.org/SealFile?seal=2165=pdf
Audit Statement Date: 2016-10-24
BR Audit: https://cert.webtrust.org/SealFile?seal=2016=pdf
BR Audit Statement Date: 2016-03-18
EV Audit: https://cert.webtrust.org/SealFile?seal=2166=pdf
EV Audit Statement Date: 2016-10-24
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   D-TRUST Root Class 3 CA 2 2009
   D-TRUST Root Class 3 CA 2 EV 2009
Standard Audit: https://www.tuvit.de/data/content_data/tuevit_en/6765UE_s.pdf
Audit Statement Date: 2016-01-20
Standard Audit: https://www.tuvit.de/data/content_data/tuevit_en/6766UE_s.pdf
Audit Statement Date: 2016-01-20
BR Audit: https://www.tuvit.de/data/content_data/tuevit_en/6765UE_s.pdf
BR Audit Statement Date: 2016-01-20
BR Audit: https://www.tuvit.de/data/content_data/tuevit_en/6766UE_s.pdf
BR Audit Statement Date: 2016-01-20
EV Audit: https://www.tuvit.de/data/content_data/tuevit_en/6766UE_s.pdf
EV Audit Statement Date: 2016-01-20
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   ACEDICOM Root
Standard Audit: https://cert.webtrust.org/SealFile?seal=1958=pdf
Audit Statement Date: 2015-11-03
BR Audit: https://cert.webtrust.org/SealFile?seal=1958=pdf
BR Audit Statement Date: 2015-11-03
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Hongkong Post Root CA 1
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8732899
Audit Statement Date: 2016-02-26
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8746166
BR Audit Statement Date: 2016-03-31
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   StartCom Certification Authority
   StartCom Certification Authority
   StartCom Certification Authority G2
Standard Audit: https://www.startssl.com/ey-webtrust.pdf
Audit Statement Date: 2016-03-18
BR Audit: https://www.startssl.com/ey-webtrust-br.pdf
BR Audit Statement Date: 2016-03-18
EV Audit: https://www.startssl.com/ey-webtrust-ev.pdf
EV Audit Statement Date: 2016-03-18
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   SwissSign Gold CA - G2
   SwissSign Platinum CA - G2
   SwissSign Silver CA - G2
Standard Audit: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268
Audit Statement Date: 2016-03-18
BR Audit: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268
BR Audit Statement Date: 2016-03-18
EV Audit: https://bug343756.bmoattachments.org/attachment.cgi?id=8781268
EV Audit Statement Date: 2016-03-18
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   TWCA Global Root CA
   TWCA Root Certification Authority
Standard Audit: https://cert.webtrust.org/SealFile?seal=1981=pdf
Audit Statement Date: 2016-02-15
BR Audit: https://cert.webtrust.org/SealFile?seal=1985=pdf
BR Audit Statement Date: 2016-02-15
EV Audit: https://cert.webtrust.org/SealFile?seal=1986=pdf
EV Audit Statement Date: 2016-02-15
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   Trustis Limited - Trustis FPS Root CA
Standard Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8745582
Audit Statement Date: 2016-02-03
BR Audit: https://bugzilla.mozilla.org/attachment.cgi?id=8745582
BR Audit Statement Date: 2016-02-03
CA Comments: null



Mozilla: Audit Reminder
Root Certificates:
   CA WoSign ECC Root
   Certification Authority of WoSign G2
   CA ?
   Certification Authority of WoSign
Standard Audit:

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

2017-02-23 Thread 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