RE: [FORGED] Re: Incidents involving the CA WoSign

[Peter Gutmann]

Peter Bowen  writes:

>It was brought to my attention that there is another incident. 

This is great stuff, it's like watching a rerun of Diginotar.  Definitely the
best web soap in the last few weeks...

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

Re: Incidents involving the CA WoSign

[Richard Wang]

It is posted, just Peter not find it that I told him the   Log id.

We are also checking system again to double check if we missed some.

Please be patient for our full 20 pages report, thanks,

Regards,

Richard

> On 4 Sep 2016, at 12:12, Matt Palmer  wrote:
> 
>> On Sat, Sep 03, 2016 at 02:18:44PM -0700, Peter Bowen wrote:
>> Can you also please check the following two certificates?  It looks
>> like they were missed when logging all the 2015 certs.
>> 
>> https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
>> https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720
>> 
>> Additionally, it looks like there may be a gap in logging for 2016.
>> For example, 
>> https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
>> does not show up in any log.
> 
> Our of curiosity, is anyone keeping a tally of the number of times WoSign
> has said, "yep, they're all logged now", only to have more unlogged
> certificates turn up?  This is starting to feel like a bit of a repeat of
> DigiNotar, insofar as a CA doesn't appear to have a clear record of all
> issuance.
> 
> - Matt
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Richard Wang]

This is another case that we will include it in our report.
We issued two test cert using SM2 algorithm that used the same serial number as 
the RSA cert (same subject) to test if we can setup a gateway that install this 
two type cert, it can shake hand automatically using different cert based on 
the browser algorithm support.

Regards,

Richard

> On 4 Sep 2016, at 12:49, Peter Bowen  wrote:
> 
>> On Thu, Sep 1, 2016 at 9:00 AM, Ryan Sleevi  wrote:
>>> On Wed, August 31, 2016 10:09 pm, Richard Wang wrote:
>>> Thanks for your so detail instruction.
>>> Yes, we are improved. The two case is happened in 2015 and the mis-issued
>>> certificate period is only 5 months that we fixed 3 big bugs during the 5
>>> months.
>>> For CT, we will improve the posting system.
>> 
>> I had a little trouble parsing this, but let's make sure we're on the same
>> page. I've continued Gerv's original numbering:
>> 
>> Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1
>> certificates ( https://cert.webtrust.org/SealFile?seal=2019&file=pdf )
>> Incident -1: April 4, 2015 - WoSign is informed it's routinely violating
>> its CPS for issued certificates (
>> https://www.wosign.com/policy/wosign-policy-1-2-10.pdf )
>> Incident X: April 9 - April 14, 2015 - 392 duplicate serial numbers
>> Incident 0: April 23, 2015 - 72 potentially dangerous port-validated
>> certificates
>> Incident 1: June, 2015 - 33 unvalidated base-domain from sub-domain
>> certificates
>> Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this
>> the only one? I wasn't clear from
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ
>> )
> 
> It was brought to my attention that there is another incident.  WoSign
> issued at least two certificates that have subject public keys which
> are for the SM2 algorithm.  SM2 is an elliptic curve based algorithm
> but it does not use the US NIST P-256, P-384, or P-512 curves.  The
> CA/Browser Forum Baseline Requirements and Mozilla CA Certificate
> Maintenance Policy both require that only these three curves be used
> for elliptic curve keys.
> 
> In addition to including subjects keys using unapproved parameters, it
> seems these each share their serial number with another certificate
> for the same subject.  So these are two more cases of duplicate serial
> numbers for different content.
> 
> The log entries for the SM2 certificates are
> https://ctlog.wosign.com/ct/v1/get-entries?start=109239&end=109240;
> crt.sh doesn't have them.  The matching serial numbers are
> https://crt.sh/?id=30613201 and https://crt.sh/?id=30613200.
> 
> Thanks,
> Peter


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Peter Bowen]

On Thu, Sep 1, 2016 at 9:00 AM, Ryan Sleevi  wrote:
> On Wed, August 31, 2016 10:09 pm, Richard Wang wrote:
>>  Thanks for your so detail instruction.
>>  Yes, we are improved. The two case is happened in 2015 and the mis-issued
>>  certificate period is only 5 months that we fixed 3 big bugs during the 5
>>  months.
>>  For CT, we will improve the posting system.
>
> I had a little trouble parsing this, but let's make sure we're on the same
> page. I've continued Gerv's original numbering:
>
> Incident -2: 16 January 2015 - 5 March 2015 - 1,132 BR-violating SHA-1
> certificates ( https://cert.webtrust.org/SealFile?seal=2019&file=pdf )
> Incident -1: April 4, 2015 - WoSign is informed it's routinely violating
> its CPS for issued certificates (
> https://www.wosign.com/policy/wosign-policy-1-2-10.pdf )
> Incident X: April 9 - April 14, 2015 - 392 duplicate serial numbers
> Incident 0: April 23, 2015 - 72 potentially dangerous port-validated
> certificates
> Incident 1: June, 2015 - 33 unvalidated base-domain from sub-domain
> certificates
> Incident 2: July, 2016 - At least 1 backdated SHA-1 certificate (was this
> the only one? I wasn't clear from
> https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/gksYkOTLCwAJ
> )

It was brought to my attention that there is another incident.  WoSign
issued at least two certificates that have subject public keys which
are for the SM2 algorithm.  SM2 is an elliptic curve based algorithm
but it does not use the US NIST P-256, P-384, or P-512 curves.  The
CA/Browser Forum Baseline Requirements and Mozilla CA Certificate
Maintenance Policy both require that only these three curves be used
for elliptic curve keys.

In addition to including subjects keys using unapproved parameters, it
seems these each share their serial number with another certificate
for the same subject.  So these are two more cases of duplicate serial
numbers for different content.

The log entries for the SM2 certificates are
https://ctlog.wosign.com/ct/v1/get-entries?start=109239&end=109240;
crt.sh doesn't have them.  The matching serial numbers are
https://crt.sh/?id=30613201 and https://crt.sh/?id=30613200.

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

Re: StartCom's StartPKI

[Matt Palmer]

On Sat, Sep 03, 2016 at 01:26:51PM -0700, Percy wrote:
> 1.WoSign actively mislead users in marketing emails.

As much as the inaccuracies and misleading statements in WoSign's marketing
materials rub me the wrong way, too, if we were to start pulling the roots
of CAs for lying in their marketing, we'd very quickly have an *extremely*
small set of trusted CAs.

- Matt

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

Re: Incidents involving the CA WoSign

[Matt Palmer]

On Sat, Sep 03, 2016 at 02:18:44PM -0700, Peter Bowen wrote:
> Can you also please check the following two certificates?  It looks
> like they were missed when logging all the 2015 certs.
> 
> https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
> https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720
> 
> Additionally, it looks like there may be a gap in logging for 2016.
> For example, 
> https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
> does not show up in any log.

Our of curiosity, is anyone keeping a tally of the number of times WoSign
has said, "yep, they're all logged now", only to have more unlogged
certificates turn up?  This is starting to feel like a bit of a repeat of
DigiNotar, insofar as a CA doesn't appear to have a clear record of all
issuance.

- Matt

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

Re: StartCom's StartPKI

[Matt Palmer]

On Sat, Sep 03, 2016 at 10:54:26PM +0200, Kurt Roeckx wrote:
> I see no problem with StartCom or WoSign being owned by the same
> person.

I didn't, either, until they started throwing around legal threats to bury
the fact that there was common ownership, and trying to use threats against
the original poster of the information to prevent others from
re-broadcasting the information.

- Matt

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

RE: Incidents involving the CA WoSign

[Richard Wang]

Sorry, I am busy with incident report that up to 20 pages.
It will be released soon today.

Two reports: one for the incident 0-2, another one is for incident X including 
you point out one.


Best Regards,

Richard

-Original Message-
From: Peter Bowen [mailto:pzbo...@gmail.com] 
Sent: Sunday, September 4, 2016 5:19 AM
To: Richard Wang 
Cc: Ryan Sleevi ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Incidents involving the CA WoSign

Richard,

Can you also please check the following two certificates?  It looks like they 
were missed when logging all the 2015 certs.

https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720

Additionally, it looks like there may be a gap in logging for 2016.
For example, 
https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
does not show up in any log.

Thanks,
Peter

On Fri, Sep 2, 2016 at 8:31 AM, Richard Wang  wrote:
> We will check this tomorrow.
> Now our time is 23:32 at night.
>
>
> Regards,
>
> Richard
>
>> On 2 Sep 2016, at 23:20, Peter Bowen  wrote:
>>
>>> On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang  wrote:
>>> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>>>
 On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
 Based on CT logs, I have seen certificates from the CAs below, all 
 of which have "WoSign" in the name.  Have you logged all 
 certificates which are signed by these CAs and have a notBefore 
 date of 2015010100Z or later to the WoSign CT log?
>>
>> Richard,
>>
>> It seems then there is a newly exposed bug.
>> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf578
>> 1edbe9d78f9cada8f1d702d5e340ad shows a certificate issued by your CA 
>> that has a notBefore in March 2015.  It does not appear in the CT 
>> log.  However another certificate with identical serial number and 
>> subject, but different Validity, does appear in the log.
>>
>> Are you aware of a bug where you were issuing certificates identical 
>> except for validity period?
>>
>> Thanks,
>> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Sanctions short of distrust

[John Nagle]

Date: Sat, 3 Sep 2016 01:45:48 +0200
From: Patrick Figel 
Subject: Re: Sanctions short of distrust

On 03/09/16 01:15, Matt Palmer wrote:

On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote:

On 09/02/2016 01:04 PM, Patrick Figel wrote:

On 02/09/16 21:14, John Nagle wrote:

2. For certs under this root cert, always check CA's
certificate transparency server.   Fail if not found.


To my knowledge, CT does not have any kind of online check
mechanism. SCTs can be embedded in the certificate (at the time
of issuance), delivered as part of the TLS handshake or via OCSP
stapling.


You're supposed to be able to check if a cert is known by querying
an OCSP responder.   OCSP stapling is just a faster way to do
that.



...

In addition to these concerns, (and assuming Mozilla would even be
willing to go down that route), I'm not sure how reliable a
Mozilla-operated OCSP responder would be given that the majority of
users who visit sites that use WoSign are probably behind the GFW.


   It would probably be necessary to offer an OCSP responder in
China.  Mozilla already has a small presence in China. See

https://www.mozilla.org/en-US/contact/spaces/beijing/

So Mozilla can apply for an ICP license, if it doesn't
have one already, and obtain server capacity in China.

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

Re: Incidents involving the CA WoSign

[Peter Bowen]

Richard,

Can you also please check the following two certificates?  It looks
like they were missed when logging all the 2015 certs.

https://www.censys.io/certificates/c04748c89de2bf73d56b601cf61db32953dfeca5ef62e0281d326c4ce9035fe2
https://www.censys.io/certificates/d99309f071141454f805c13551a827aa116bb53daefd8609e296c06b0dcdf720

Additionally, it looks like there may be a gap in logging for 2016.
For example, 
https://www.censys.io/certificates/06797f8095ba4d9c9ec5b9475cff7df3b258069cc89f303cd91dc329eaf0c08f
does not show up in any log.

Thanks,
Peter

On Fri, Sep 2, 2016 at 8:31 AM, Richard Wang  wrote:
> We will check this tomorrow.
> Now our time is 23:32 at night.
>
>
> Regards,
>
> Richard
>
>> On 2 Sep 2016, at 23:20, Peter Bowen  wrote:
>>
>>> On Fri, Sep 2, 2016 at 8:11 AM, Richard Wang  wrote:
>>> Yes, we posted all 2015 issued SSL from WoSign trusted root.
>>>
 On 2 Sep 2016, at 22:55, Peter Bowen  wrote:
 Based on CT logs, I have seen certificates from the CAs below, all of
 which have "WoSign" in the name.  Have you logged all certificates
 which are signed by these CAs and have a notBefore date of
 2015010100Z or later to the WoSign CT log?
>>
>> Richard,
>>
>> It seems then there is a newly exposed bug.
>> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
>> shows a certificate issued by your CA that has a notBefore in March
>> 2015.  It does not appear in the CT log.  However another certificate
>> with identical serial number and subject, but different Validity, does
>> appear in the log.
>>
>> Are you aware of a bug where you were issuing certificates identical
>> except for validity period?
>>
>> Thanks,
>> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom's StartPKI

[Kurt Roeckx]

On Sat, Sep 03, 2016 at 01:33:38PM -0700, Percy wrote:
> Based on the disclosure WoSign/StartCom is trying to bury, WoSign CEO is now 
> also in control of StartCom. Hence, the actively misleading information 
> spread by him should be taken into consideration when talking about StartCom 
> as well.  

Percy,

This really isn't helpful. You've already made your point several
times. Repeating it isn't going to help anybody.

I see no problem with StartCom or WoSign being owned by the same
person. What might be a problem is that they might run some of the
same software. And that if WoSign's software is having issues that
StartCom's software might have the same issues. It would be good
to know what the relationship between the 2 companies is exactly,
to know if we need to have the same concerns for both of them or
not. I understand that at least some of the infrastructure is
shared, but it said nothing about the issuing itself.

If you think there is something wrong with StartSSL, it would be
nice if you can point to specific issues you find with them.

>From the little I understand, I think the frontend might be shared
and that there is a parameter that say to which backend needs to
be connected. And so that the backend might actually run totally
different software for both. At least, that's what I think he
tried to explain, but it wasn't really clear.


Kurt

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

Re: StartCom's StartPKI

[Percy]

Based on the disclosure WoSign/StartCom is trying to bury, WoSign CEO is now 
also in control of StartCom. Hence, the actively misleading information spread 
by him should be taken into consideration when talking about StartCom as well.  
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Ryan Sleevi]

Trust me, the disclosure was not buried, and the factual details are being 
sorted. However, it would be better for the tone and focus of the thread that 
we make sure to focus on the factual elements, which, as you note, can be 
publicly obtained easily, than to try to imply there's something wrong with 
poor translations.

In any event, we have significant information here to evaluate, ranging from 
the original issues to matters such as the incomplete disclosure of issues 
certificates, and we should be focusing on those elements, the expectations 
under the Mozilla policies, and what responses that best balance the need of 
Mozilla users (relying parties) and the Internet at large.

For example, a key question remains is: Can/Should WoSign be trusted after 
these incidents? If so, is that trust unconditional, or do there need to be 
improvements, and in what form? If WoSign can no longer be trusted, what steps 
should be taken to reflect that across Mozilla products, in a way that, 
ideally, avoids conditioning users, particularly in the emerging markets 
seemingly most served by WoSign, that TLS errors are OK to ignore?

This is where understanding options is important for the discussion.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom's StartPKI

[Percy]

On Saturday, September 3, 2016 at 12:46:02 PM UTC-7, Ryan Sleevi wrote:
> Hi Percy,
> 
> This does not seem to be a useful or productive contribution to the community 
> discussion. Whether or not a given CA uses English as a first language, or 
> has translation issues, should not be part of the calculus of 
> trustworthiness. The actions, however, are far more relevant and important, 
> such as having actively misleading information, but it is not and should not 
> be an issue to have a poor translation.
> 
> I would appreciate if you would stop trying to suggest otherwise.

I completely agree. Let's talk about actively misleading information. 

1.WoSign actively mislead users in marketing emails. This is a typical 
marketing email they sent.  
https://pbs.twimg.com/media/CrXf7w3W8AA2zd7.jpg:large Translated below. 
--- 
Dear friend: 
I'm *** from WoSign CA. WoSign is the first SSL cert company in China. Your 
website *'s SSL cert is from Let's Encrypt, expiring at Oct, 2016. If you 
switch to WoSign before the expiration you can enjoy buy one year get one year 
free. 

The risks associated with foreign CA: 
1. Cert revocation 
If foreign CA is influenced by politics and revoke certs for important Chinese 
organizations, the entire system will be paralyzed. 

2. Information security risks 
If the website uses foreign certs, users need to send information to foreign 
servers in every visit. Time of the visit, the location of the visit, IP 
addresses, and the browser, frequency of the visits are all collected by 
foreign CA. This will leak commercial secrets and sensitive data, and is a very 
risky! 

3. Server latency 
Foreign CA cannot provide 24*7 local support. Servers are overseas and affected 
by submarine cables, latency is 10X. If something happens to submarine cables, 
and cert revocation list is not accessible, important systems with foreign 
certs will be paralyzed. In 2012, there is a incident that submarine cables was 
broken. 

 (contact info stuff) 

Best regards and thanks, 

WoSign CA Limited. 

2. After my post about the above marketing email, WoSign CEO accused me 
publicly of working for Let's Encrypt to undermine WoSign, "From the 
screenshot, we know why Percy hate WoSign so deeply, we know he represent which 
CA, everything is clear now. "

3. WoSign CEO claimed on social media that "WoSign has been oppressed by large 
American companies over the years but has been growing steadily over the past 
10 years and is now the 8th largest CA in the world""  
https://pbs.twimg.com/media/CrZ1Oc6WIAABtrg.jpg:large

4. WoSign CEO also claimed on social media that 
(https://pbs.twimg.com/media/CrZ4GV7WgAESKyn.jpg:large) way back in 2014 that 
"If you deploy foreign certificates, you still will not have any security in 
online commerce". 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Percy]

Ryan,
I agree completely that we shouldn't imply fundamental guilt by
association. However, WoSign threatened legal actions against Itzhak
Daniel's disclosure compiled purely from public sources. I just want to
make sure the disclosure was not buried after the content was taken down.

Richard, the CEO of WoSign, stated "From the screenshot, we know why Percy
hate WoSign so deeply, we know he represent which CA, everything is clear
now." The screenshot refers to
https://groups.google.com/d/msg/mozilla.dev.security.policy/k9PBmyLCi8I/5Lelu0oyDQAJ
and the screenshot proves WoSign is actively misleading the public.
He further seems to think I'm working for Let's Encrypt and consequently
want to undermine WoSign. It is he that needs to answer the questions and
concerned raised rather than discrediting the questioners
or threatening legal actions. For the record, I'm not and have not worked
for Let's Encrypt or any CA.

Percy Alpha(PGP
)


On Sat, Sep 3, 2016 at 12:51 PM, Ryan Sleevi  wrote:

> Percy,
>
> As I suggested in the other thread, this does not seem a productive or
> fruitful line of inquiry, nor does it seem relevant to the issue at hand,
> nor does it seem to be done respectfully.
>
> That is, the extent of the country of origin of a CA is not itself a
> fundamental issue of trust, nor should translation errors be. I agree that
> there's a line where elements such as actively misleading the public become
> a matter of public concern, but let's try not to suggest there is something
> wrong with being from a particular country, nor that it represents proof of
> wrongdoing.
>
> I believe we are on the cusp of crossing a line here, and would love if we
> could focus on the technical and factual issues, without attempting to
> imply fundamental guilt by association or pseudo-phrenological analysis of
> speech patterns to show some form of wrongdoing.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Ryan Sleevi]

Percy,

As I suggested in the other thread, this does not seem a productive or fruitful 
line of inquiry, nor does it seem relevant to the issue at hand, nor does it 
seem to be done respectfully.

That is, the extent of the country of origin of a CA is not itself a 
fundamental issue of trust, nor should translation errors be. I agree that 
there's a line where elements such as actively misleading the public become a 
matter of public concern, but let's try not to suggest there is something wrong 
with being from a particular country, nor that it represents proof of 
wrongdoing.

I believe we are on the cusp of crossing a line here, and would love if we 
could focus on the technical and factual issues, without attempting to imply 
fundamental guilt by association or pseudo-phrenological analysis of speech 
patterns to show some form of wrongdoing.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom's StartPKI

[Ryan Sleevi]

Hi Percy,

This does not seem to be a useful or productive contribution to the community 
discussion. Whether or not a given CA uses English as a first language, or has 
translation issues, should not be part of the calculus of trustworthiness. The 
actions, however, are far more relevant and important, such as having actively 
misleading information, but it is not and should not be an issue to have a poor 
translation.

I would appreciate if you would stop trying to suggest otherwise.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom's StartPKI

[Percy]

Yeah, their entire website is designed and implemented by someone in China. See 
my analysis here 
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html

On Thursday, August 25, 2016 at 10:11:21 AM UTC-7, rugk wrote:
> Hi,
> I stumbled across this service by StartCom: 
> https://startssl.com/StartPKI (archive link: https://archive.is/GRkAK)
> I got a bit afraid when looking at their nice screenshots 
> (https://archive.is/GRkAK#75%), because they offer intermediate 
> certificates for companies allowing them to issue certificates by 
> themself.
> 
> So I checked their site to find out what this is about.
> The certs are "Trusted by all browsers" 
> (https://archive.is/GRkAK#selection-419.0-419.23).
> So I thought in this case they (StartCom) need to control the process, 
> especially as they allow EV certs to be issued.
> However here is what they state on their website: "StartPKI, let you 
> control your SSL certificate life cycle management by yourself, not by 
> the CA!" (https://archive.is/GRkAK#selection-517.0-517.96)
> This does rather sound as if the company would have a web interface 
> where they can issue certificates like they want...
> 
> So I thought they at least keep the private key on their servers/HSMs. 
> However they mention "FIPS 140 Luna G5 HSM Secured" under "Setup your 
> name issuing CA" (https://archive.is/GRkAK#selection-619.0-631.24), so 
> does this indicate the companies have to setup a HSM? If so, for what if 
> it is not the private key of the intermediate?
> On the other hand they say it you need no "No PKI infrastructure 
> Investment" (https://archive.is/GRkAK#selection-449.0-449.32), but the 
> "All controlled by yourself" 
> (https://archive.is/GRkAK#selection-673.0-673.26) is not a very 
> appeasing statement when it comes to who can issue certificates.
> Also they say you can "Issue certificates instantly" 
> (https://archive.is/GRkAK#selection-425.0-425.28) (for free) I am 
> wondering how this can work for EV certificates.
> 
> On their news page (https://startssl.com/NewsDetails?date=20160428) they 
> say the intermediate CA is "for the exclusive use of the verified 
> organization". But how can they enforce this?
> At least they say that "the intermediate CA will be provided by 
> StartCom's [...] infrastructure", so it seems they keep the intermediate 
> themself.
> 
> So at least they keep the private key. However this still does not 
> answer the question how they control the certificates issued by this 
> intermediate - especially when it comes to EV certificates.
> It is also unclear what kind of verification is made when a company 
> issues a certificate with their own intermediate.
> 
> Also note that there is a difference to StartResell. On their hompage 
> (https://startssl.com/NewsDetails?date=20160530) they also state, that 
> resellers have their own intermediate certificate.
> However there they seem to do the verification by themself and "charge 
> the end user identity validation". This obviously does not happen for 
> StartPKI...
> As StartPKI is "Ready to use in 3 days" 
> (https://archive.is/GRkAK#selection-413.0-413.22) I doubt that they can 
> trust all companies they issue intermediates for to do sane 
> verification.
> 
> The service is all in all quite questionable and statements like "All 
> controlled by yourself" are horrible to hear. I hope this statement is 
> just wrong and they somehow keep control.
> 
> Best regards,
> rugk
> 
> -- 
> I offer PGP support. To send me a PGP-encrypted mail, please ask for my 
> private mail address.

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

Re: Incidents involving the CA WoSign

[Percy]

Andy, are you from the UK office?  Can you explain why your office in UK
fails to identify even the most obvious mistakes on the StartCom website as
outlined in
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html ?
E.g

Start to sell, make big money!
Setup your own website, start to sell your brand SSL certificate to your
customers. Post customer’s identity information to StartSSL, StartCom
charge the validation cost only with 50% off discount, all certificates
issued from your intermediate CA is FREE. StartCom don’t charge your
certificate cost, you make big money!

StartResell is in the background, you focus your sales, we do everything
for you including PKI system, CRL and OCSP distribution, identity
validation etc., we will use your company name to call your customer for
identity validation, no other contact to your customer


Percy Alpha(PGP
)


On Sat, Sep 3, 2016 at 10:29 AM, Andy Ligg  wrote:

> You are completely wrong!
>
> StartCom not only have office in Israel and in China, but also have office
> in UK, welcome to visit our UK office: T05, Castlemead, Lower Castle
> Street, Bristol, BS1 3AG, UK.
>
> And We will setup office in Bilbao, Spain in this month, Inigo Barreia is
> the general manager of StartCom Europe that Eddy announced this in CABF
> mail list.
>
> Regards,
>
> Andy
>
>
> On 2016/9/3 16:17, Percy wrote:
>
>> I did an analysis of the new StartCom website and determined that it was
>> designed and implemented solely in China.  http://www.percya.com/2016/09/
>> startcom-operated-solely-in-china.html  I'm further concerned with the
>> security of "StartResell - Setup your own website, start to sell your brand
>> SSL certificate to your customers". Details here
>> ___
>> 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: Incidents involving the CA WoSign

[Andy Ligg]

You are completely wrong!

StartCom not only have office in Israel and in China, but also have 
office in UK, welcome to visit our UK office: T05, Castlemead, Lower 
Castle Street, Bristol, BS1 3AG, UK.


And We will setup office in Bilbao, Spain in this month, Inigo Barreia 
is the general manager of StartCom Europe that Eddy announced this in 
CABF mail list.


Regards,

Andy

On 2016/9/3 16:17, Percy wrote:

I did an analysis of the new StartCom website and determined that it was designed and 
implemented solely in China.  
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html  I'm further 
concerned with the security of "StartResell - Setup your own website, start to sell 
your brand SSL certificate to your customers". Details here
___
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: Incidents involving the CA WoSign

[Kurt Roeckx]

On Sat, Sep 03, 2016 at 11:45:21AM +0200, Kurt Roeckx wrote:
> On Sat, Sep 03, 2016 at 09:29:45AM +0100, Gervase Markham wrote:
> > On 02/09/16 16:21, Peter Bowen wrote:
> > > It seems then there is a newly exposed bug.
> > > https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
> > > shows a certificate issued by your CA that has a notBefore in March
> > > 2015.  It does not appear in the CT log.  However another certificate
> > > with identical serial number and subject, but different Validity, does
> > > appear in the log.
> > 
> > https://crt.sh/?id=30326062 appears in the log; I assume that's the cert
> > you mean.
> > 
> > > Are you aware of a bug where you were issuing certificates identical
> > > except for validity period?
> > 
> > Well, the _period_ is the same; the start and end dates are offset by an
> > identical amount ;-)
> 
> That offset being 37 seconds.
> 
> I've submitted it to Google's aviator log.

So the two are:
https://crt.sh/?id=30326062
https://crt.sh/?id=30736090


Kurt

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

Re: Incidents involving the CA WoSign

[Kurt Roeckx]

On Sat, Sep 03, 2016 at 09:29:45AM +0100, Gervase Markham wrote:
> On 02/09/16 16:21, Peter Bowen wrote:
> > It seems then there is a newly exposed bug.
> > https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
> > shows a certificate issued by your CA that has a notBefore in March
> > 2015.  It does not appear in the CT log.  However another certificate
> > with identical serial number and subject, but different Validity, does
> > appear in the log.
> 
> https://crt.sh/?id=30326062 appears in the log; I assume that's the cert
> you mean.
> 
> > Are you aware of a bug where you were issuing certificates identical
> > except for validity period?
> 
> Well, the _period_ is the same; the start and end dates are offset by an
> identical amount ;-)

That offset being 37 seconds.

I've submitted it to Google's aviator log.


Kurt

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

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 02/09/16 16:21, Peter Bowen wrote:
> It seems then there is a newly exposed bug.
> https://www.censys.io/certificates/e2665bb07940b5bee73145f47c99dcf5781edbe9d78f9cada8f1d702d5e340ad
> shows a certificate issued by your CA that has a notBefore in March
> 2015.  It does not appear in the CT log.  However another certificate
> with identical serial number and subject, but different Validity, does
> appear in the log.

https://crt.sh/?id=30326062 appears in the log; I assume that's the cert
you mean.

> Are you aware of a bug where you were issuing certificates identical
> except for validity period?

Well, the _period_ is the same; the start and end dates are offset by an
identical amount ;-)

Gerv


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

Re: Incidents involving the CA WoSign

[Percy]

I did an analysis of the new StartCom website and determined that it was 
designed and implemented solely in China.  
http://www.percya.com/2016/09/startcom-operated-solely-in-china.html  I'm 
further concerned with the security of "StartResell - Setup your own website, 
start to sell your brand SSL certificate to your customers". Details here
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incidents involving the CA WoSign

[Gervase Markham]

On 02/09/16 18:00, Andrew Ayer wrote:
> I don't think relying on the notBefore date is a viable option.
> WoSign seems to have such a poor handle on their operations that I
> think it would be inevitable that someone would find a certificate in
> the wild with a notBefore date in the past that had not been
> disclosed.  What action would Mozilla take if that happened?

A fair question. I think one would need to have the consequences of
further issues mapped out beforehand.

Gerv


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