info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
website control validation problem
234 views
Skip to first unread message
Richard Wang
Sep 1, 2016, 9:16:53 PM9/1/16
to mozilla-dev-s...@lists.mozilla.org
For this case, WoSign notice Alibaba after getting report.
I think this case is another case for website control validation problem.
Now, many CDN, Internet service provider provide a subdomain to its customer like: myname.CDNprovider.com, this customer can do the website control validation, then he can get this certificate. You can't say this is mis-issued or fake cert.
This validation method is allowed by BR, so we need to make clear that if the ISP/Cloud service provider don't notice CA that which domain's subdomain is not allowed to issue certificate to customer, then this issued certificate is OK.
Best Regards,
Richard
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Percy
Sent: Friday, September 2, 2016 5:50 AM
To: Gervase Markham <ge...@mozilla.org>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign
They have confirmed that it's a fake cert. Alibaba knew this prior to my contact and said they already contacted WoSign.
Percy Alpha(PGP
<https://pgp.mit.edu/pks/lookup?op=vindex&search=0xF30D100F7FE124AE>)
On Wed, Aug 31, 2016 at 3:15 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 29/08/16 22:53, Percy wrote:
> > Gerv, I've notified the security team in Alibaba about this possible
> fake cert and ask them to confirm that they have not applied a cert.
> > It's unlikely that Alibaba will use a free cert from WoSign. As a
> commercial site, they usually use Verisign or globalSign
>
> That might also help; thank you. Please ask them to contact me
> directly to confirm this cert was not requested by them.
>
> Gerv
>
>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
I think this case is another case for website control validation problem.
Now, many CDN, Internet service provider provide a subdomain to its customer like: myname.CDNprovider.com, this customer can do the website control validation, then he can get this certificate. You can't say this is mis-issued or fake cert.
This validation method is allowed by BR, so we need to make clear that if the ISP/Cloud service provider don't notice CA that which domain's subdomain is not allowed to issue certificate to customer, then this issued certificate is OK.
Best Regards,
Richard
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Percy
Sent: Friday, September 2, 2016 5:50 AM
To: Gervase Markham <ge...@mozilla.org>
Cc: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign
They have confirmed that it's a fake cert. Alibaba knew this prior to my contact and said they already contacted WoSign.
Percy Alpha(PGP
<https://pgp.mit.edu/pks/lookup?op=vindex&search=0xF30D100F7FE124AE>)
On Wed, Aug 31, 2016 at 3:15 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 29/08/16 22:53, Percy wrote:
> > Gerv, I've notified the security team in Alibaba about this possible
> fake cert and ask them to confirm that they have not applied a cert.
> > It's unlikely that Alibaba will use a free cert from WoSign. As a
> commercial site, they usually use Verisign or globalSign
>
> That might also help; thank you. Please ask them to contact me
> directly to confirm this cert was not requested by them.
>
> Gerv
>
>
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Ryan Sleevi
Sep 1, 2016, 9:59:32 PM9/1/16
to mozilla-dev-s...@lists.mozilla.org
On Thursday, September 1, 2016 at 6:16:53 PM UTC-7, Richard Wang wrote:
> For this case, WoSign notice Alibaba after getting report.
>
> I think this case is another case for website control validation problem.
>
> Now, many CDN, Internet service provider provide a subdomain to its customer like: myname.CDNprovider.com, this customer can do the website control validation, then he can get this certificate. You can't say this is mis-issued or fake cert.
If you authenticate myname.cdnprovider.com, then the BRs prevent you - before and after - from issuing the certificate to cdnprovider.com. This was already true under the previous version of the Baseline Requirements to which you were audited, v 1.3.3, Section 3.2.2.4, Method 6.
> For this case, WoSign notice Alibaba after getting report.
>
> I think this case is another case for website control validation problem.
>
> Now, many CDN, Internet service provider provide a subdomain to its customer like: myname.CDNprovider.com, this customer can do the website control validation, then he can get this certificate. You can't say this is mis-issued or fake cert.
The specific allowance is for FQDN. You can validate that the subscriber has control of myname.cdnprovider.com, however, that is NOT permitted to validate any other subdomain under cdnprovider.com.
>
> This validation method is allowed by BR, so we need to make clear that if the ISP/Cloud service provider don't notice CA that which domain's subdomain is not allowed to issue certificate to customer, then this issued certificate is OK.
This certificate's misissuance does not match any of the Website Control violations you've mentioned yet. That is, rather than adding the bare domain and www, as you previously suggested you did (in 2015), this appears to have been for a variety of subdomains, clearly of security importance.
It suggests that the 2015 issue was not actually resolved, or, if it was, that there's a new issue.
It's also important to consider the date - June 23, 2016. At this point, WoSign had already seen and been aware of multiple circulations of the BR pre-ballot to reform the means of domain control validation, an issue I first raised to the CA/Browser Forum and the Management List over two years ago as an area of security concern for CAs to be aware of.
Can you please clarify exactly the method you used to authenticate and authorize this request? Given that you're required to maintain unalterable audit logs of CA and Subscriber Certificate Lifecycle management events (per 5.4.1 of the BRs), it would be essential for the community that is considering the trustworthiness of WoSign that you explain how WoSign validated this request, when it was an authorized certificate.
Richard Wang
Sep 1, 2016, 10:24:14 PM9/1/16
to Ryan Sleevi, mozilla-dev-s...@lists.mozilla.org
For https://crt.sh/?id=29884704 , he finished the website control validation.
We and Alibaba are investigating why he can do the website control validation.
The is the log, but we can't expose more now since it is related to Alibaba.
2016-06-23 01:34:39: WoSign validation system received domain "alicdn.com" website control request，the url is "http://alicdn.com/alicdn.com.html", v_random is 2e3baabe989fad9f143517796ed4941c13e7177b, Validation system used Get method, 400 error, then change to use POST method, success.
By the way, as I said in the reply, we think the website control validation have potential risk that we need to discuss, so we decided to close this method.
Best Regards,
Richard
-----Original Message-----
We and Alibaba are investigating why he can do the website control validation.
The is the log, but we can't expose more now since it is related to Alibaba.
2016-06-23 01:34:39: WoSign validation system received domain "alicdn.com" website control request，the url is "http://alicdn.com/alicdn.com.html", v_random is 2e3baabe989fad9f143517796ed4941c13e7177b, Validation system used Get method, 400 error, then change to use POST method, success.
By the way, as I said in the reply, we think the website control validation have potential risk that we need to discuss, so we decided to close this method.
Best Regards,
Richard
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Ryan Sleevi
Sent: Friday, September 2, 2016 9:59 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: website control validation problem
On Thursday, September 1, 2016 at 6:16:53 PM UTC-7, Richard Wang wrote:
Sent: Friday, September 2, 2016 9:59 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: website control validation problem
On Thursday, September 1, 2016 at 6:16:53 PM UTC-7, Richard Wang wrote:
> For this case, WoSign notice Alibaba after getting report.
>
> I think this case is another case for website control validation problem.
>
> Now, many CDN, Internet service provider provide a subdomain to its customer like: myname.CDNprovider.com, this customer can do the website control validation, then he can get this certificate. You can't say this is mis-issued or fake cert.
>
> I think this case is another case for website control validation problem.
>
> Now, many CDN, Internet service provider provide a subdomain to its customer like: myname.CDNprovider.com, this customer can do the website control validation, then he can get this certificate. You can't say this is mis-issued or fake cert.
If you authenticate myname.cdnprovider.com, then the BRs prevent you - before and after - from issuing the certificate to cdnprovider.com. This was already true under the previous version of the Baseline Requirements to which you were audited, v 1.3.3, Section 3.2.2.4, Method 6.
The specific allowance is for FQDN. You can validate that the subscriber has control of myname.cdnprovider.com, however, that is NOT permitted to validate any other subdomain under cdnprovider.com.
>
The specific allowance is for FQDN. You can validate that the subscriber has control of myname.cdnprovider.com, however, that is NOT permitted to validate any other subdomain under cdnprovider.com.
>
> This validation method is allowed by BR, so we need to make clear that if the ISP/Cloud service provider don't notice CA that which domain's subdomain is not allowed to issue certificate to customer, then this issued certificate is OK.
Just to confirm, we're talking about https://crt.sh/?id=29884704 , issued on June 23, 2016. You're stating this certificate is misissued, correct? It is certainly revoked in http://crls1.wosign.com/ca6-server1-free.crl , CRL number 0202053E
This certificate's misissuance does not match any of the Website Control violations you've mentioned yet. That is, rather than adding the bare domain and www, as you previously suggested you did (in 2015), this appears to have been for a variety of subdomains, clearly of security importance.
It suggests that the 2015 issue was not actually resolved, or, if it was, that there's a new issue.
It's also important to consider the date - June 23, 2016. At this point, WoSign had already seen and been aware of multiple circulations of the BR pre-ballot to reform the means of domain control validation, an issue I first raised to the CA/Browser Forum and the Management List over two years ago as an area of security concern for CAs to be aware of.
Can you please clarify exactly the method you used to authenticate and authorize this request? Given that you're required to maintain unalterable audit logs of CA and Subscriber Certificate Lifecycle management events (per 5.4.1 of the BRs), it would be essential for the community that is considering the trustworthiness of WoSign that you explain how WoSign validated this request, when it was an authorized certificate.
This certificate's misissuance does not match any of the Website Control violations you've mentioned yet. That is, rather than adding the bare domain and www, as you previously suggested you did (in 2015), this appears to have been for a variety of subdomains, clearly of security importance.
It suggests that the 2015 issue was not actually resolved, or, if it was, that there's a new issue.
It's also important to consider the date - June 23, 2016. At this point, WoSign had already seen and been aware of multiple circulations of the BR pre-ballot to reform the means of domain control validation, an issue I first raised to the CA/Browser Forum and the Management List over two years ago as an area of security concern for CAs to be aware of.
Can you please clarify exactly the method you used to authenticate and authorize this request? Given that you're required to maintain unalterable audit logs of CA and Subscriber Certificate Lifecycle management events (per 5.4.1 of the BRs), it would be essential for the community that is considering the trustworthiness of WoSign that you explain how WoSign validated this request, when it was an authorized certificate.
Kurt Roeckx
Sep 2, 2016, 6:29:13 AM9/2/16
to mozilla-dev-s...@lists.mozilla.org
On 2016-09-02 04:22, Richard Wang wrote:
> For https://crt.sh/?id=29884704 , he finished the website control validation.
>
> We and Alibaba are investigating why he can do the website control validation.
>
> The is the log, but we can't expose more now since it is related to Alibaba.
>
> 2016-06-23 01:34:39: WoSign validation system received domain "alicdn.com" website control request，the url is "http://alicdn.com/alicdn.com.html", v_random is 2e3baabe989fad9f143517796ed4941c13e7177b, Validation system used Get method, 400 error, then change to use POST method, success.
I'm wondering why you try to use POST, and what you could be posting there.
> For https://crt.sh/?id=29884704 , he finished the website control validation.
>
> We and Alibaba are investigating why he can do the website control validation.
>
> The is the log, but we can't expose more now since it is related to Alibaba.
>
> 2016-06-23 01:34:39: WoSign validation system received domain "alicdn.com" website control request，the url is "http://alicdn.com/alicdn.com.html", v_random is 2e3baabe989fad9f143517796ed4941c13e7177b, Validation system used Get method, 400 error, then change to use POST method, success.
Kurt
0 new messages