Re: Remediation Plan for WoSign and StartCom

[Matt Palmer]

On Thu, Oct 13, 2016 at 09:49:50AM -0700, Kathleen Wilson wrote:
> 5. 100% embedded CT for all issued certificates, with embedded SCTs from
> at least one Google and one non-Google log not controlled by the CA.

Will there be any requirements around the qualification status of the logs,
or could anyone who wanted to be "nice" just stand up a log, and have these
CAs obtain precerts from them?

- Matt

-- 
Yes, Java is so bulletproofed that to a C programmer it feels like being in
a straightjacket, but it's a really comfy and warm straightjacket, and the
world would be a safer place if everyone was straightjacketed most of the
time.   -- Mark 'Kamikaze' Hughes

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

Re: Remediation Plan for WoSign and StartCom

[Percy]

> Others have noted the mismatch here with an October 1 date elsewhere in 
> the document. I think we should pick a single date in the future, to 
> allow the CAs concerned to wind down operations without leaving 
> customers having just obtained certs which will stop working in a few 
> months. So I would argue for October 21st in line with our principle of 
> minimal disruption to cert owners. 

I think Oct 1st is a better deadline. WoSign has stopped issuing DV certs since 
Sept 29th and Apple has banned certs after 2016-09-19. There is no reason to 
give WoSign another week of time to issuing new certs. 

"Sorry, due to some security consideration, 
WoSign decide to close the free SSL certificate application temporarily. Sept. 
29th 2016.
You can visit https://www.startssl.com to get a Free SSL Certificate."
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Nick Lamb]

On Thursday, 13 October 2016 20:52:54 UTC+1, Gervase Markham  wrote:
> To be clear, this is a permanent ban, applicable worldwide, but only to
> the Hong Kong branch of E (If further issues are found with E
> audits elsewhere, then we might consider something with wider scope.)

Please can Mozilla ensure that both EY Hong Kong and the overarching parent 
organisation in the United Kingdom (in Southwark) are informed of this ban and 
get a copy of Mozilla's findings if they haven't already ?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Gervase Markham]

On 13/10/16 17:49, Kathleen Wilson wrote:
> Thanks again to all of you who have put in so much time and effort to
> determine what happened with WoSign and StartCom and discuss what to
> do about it.

You are welcome.

As people will have read, the current decision at Mozilla is to treat
the WoSign and StartCom roots the same, except that StartCom has an
opportunity to be re-included faster than WoSign if they can meet the
conditions in time. It is also the current position that we will require
the companies to use new roots, although cross-signing of the new by the
old is permissible.

Some further comments for Kathleen:

> Within this message, the term “Affected Roots” applies to the
> following 7 root certificates.

Yes; it appears my root list in the investigation document missed one.
Sorry about that.

> 1) Distrust certificates chaining up to Affected Roots with a
> notBefore date after October 21, 2016. 

Others have noted the mismatch here with an October 1 date elsewhere in
the document. I think we should pick a single date in the future, to
allow the CAs concerned to wind down operations without leaving
customers having just obtained certs which will stop working in a few
months. So I would argue for October 21st in line with our principle of
minimal disruption to cert owners.

> 3) No longer
> accept audits carried out by Ernst & Young Hong Kong. 

To be clear, this is a permanent ban, applicable worldwide, but only to
the Hong Kong branch of E (If further issues are found with E
audits elsewhere, then we might consider something with wider scope.)

> 4) Remove the
> Affected Roots from NSS after the SSL certificates issued before
> October 1, 2016, have expired or have been replaced.

That should be in approximately 39 months time, as that's the max
issuance length allowed by the BRs.

> 4. Provide auditor attestation that a full performance audit has been
> performed confirming compliance with the CA/Browser Forum's Baseline
> Requirements[6].  This audit may be part of an annual WebTrust BR
> audit. It must include a full security audit of the CA’s issuing
> infrastructure.

I would recommend that Mozilla retain the option to approve the security
auditor, and that it be an external company.

> 5. 100% embedded CT for all issued certificates, with embedded SCTs
> from at least one Google and one non-Google log not controlled by the
> CA.

StartCom/WoSign have indicated ro me that they may have trouble
complying with the non-Google log requirement because it's hard to find
a non-Google log which can scale sufficiently. I suggest we allow them
some leeway on this but they need to demonstrate evidence of efforts to
meet the requirement.

If anyone reading controls a CT log which could accept their volume,
even for payment, please contact StartCom/WoSign and let Mozilla know
you have done so.

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

Re: StartCom & Qihoo Incidents

[solar]

Indeed, Yahoo! has bad reputation on both spyware/malware[1] and censorship[2].

Ironically, Yahoo! Assistant, the successor of 3721 Internet Assistant (also 
called 3721 helper) was identified as malware by 360Safe, which is a product of 
Qihoo 360.[3]

In 2007, Eric Yang, the co-founder and CEO of Yahoo! faced questions from a 
Congressional committee with respect to the company role in the arrests of 
journalists in China.[4]

Recentlly, It was exposed that Yahoo! secretly built a custom software program 
to search all of its customers' incoming emails for specific information.[5]

[1] https://en.wikipedia.org/wiki/Criticism_of_Yahoo!#Adware_and_spyware
[2] 
https://en.wikipedia.org/wiki/Criticism_of_Yahoo!#Work_in_the_People.27s_Republic_of_China
[3] https://en.wikipedia.org/wiki/Yahoo!_Assistant
[4] 
https://en.wikipedia.org/wiki/Jerry_Yang#Chinese_government_collaboration_controversies
[5] http://www.reuters.com/article/us-yahoo-nsa-exclusive-idUSKCN1241YT

On Thursday, October 13, 2016 at 11:01:22 PM UTC+8, 谭晓生 wrote:
> Are there any words saying “award to Qihoo to recognize their long time 
> support for censorship”? 
> It is an official thanks letter from The Ministry of Public Security of the 
> People’s Republic of China, the equivalent organization with FBI of U.S, it 
> thanks for my team and myself to join the information security work the 3rd 
> Sept military review affair! I can tell you that my team and myself joined 
> the information security work for G20 meeting just finished last month, I 
> might got a thanks letter soon, is there anything wrong to do that? 
>   
> If anybody care about this, please ask somebody to translate this letter for 
> you, I do not have time to waste here on somebody lied.
> 
> For the malware accuses, Yahoo acquired 3721 in 2003, do you think Yahoo 
> acquired a malware company? Is there any anti-virus software killed 3721’s 
> software? 
> 
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 下午5:26，“dev-security-policy 代表 
> solar” sofl...@gmail.com> 写入:
> 
> Some more information. 
> 
> 3721 helper, the most notorious malware in china was created by Hongyi 
> zhou and his company 3721 in 1998. According to Mr. Tan's bio, he was the 
> development director of 3721. So I believe he directly participated in and 
> led the development of the malware.
> 
> There is another evidence of Qihoo cooperating with chinese government to 
> censor the internet. Last year, the Ministry of Public Security (the 
> stakeholder of GFW) give an award to Qihoo to recognize their long time 
> support for censorship especially during the event of the 70th anniversary of 
> the victory of World War II. The official paper of the award 
> (http://www.canyu.org/n102771c6.aspx) was listed on Qihoo website. But it was 
> soon removed before widely exposed in public. Moreover, the chinese name(谭晓生) 
> of Mr. Tan Xiaosheng was mentioned in the official paper.
> 
> I do NOT trust the person who developed malware, and I also do NOT trust 
> the CA involved in censorship.
> ___
> 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: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Thursday, October 13, 2016 at 10:39:05 AM UTC-7, Han Yuwei wrote:
> 
> Is this the final decision or still pending?

Please consider this the draft of my decision. We are actively working on the 
Mozilla action items, but this plan is still open for discussion.

Thanks,
Kathleen


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

Re: Remediation Plan for WoSign and StartCom

[Han Yuwei]

在 2016年10月14日星期五 UTC+8上午12:50:02，Kathleen Wilson写道：
> All,
> 
> Thanks again to all of you who have put in so much time and effort to 
> determine what happened with WoSign and StartCom and discuss what to do about 
> it.
> 
> Based on the information that I have seen regarding WoSign, I believe that 
> WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL 
> certs, when they knew full well that was no longer allowed. I also believe 
> that the deception continued even after Mozilla directly asked WoSign about 
> this. WoSign has lost my confidence in their ability and intention to follow 
> Mozilla's policies. Therefore, I think we should respond similarly to WoSign 
> as we did to CNNIC [1][2]. Unfortunately, the number of certificates and the 
> timescales involved are such that we prefer not to create a list of the 
> domains for which previously-issued certs that chain up to the Affected Roots 
> may continue to be trusted, so our approach will be a little different, as 
> Gerv previously described[3].
> 
> Within this message, the term “Affected Roots” applies to the following 7 
> root certificates.
> 
> 1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
> Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
> SHA-1 Fingerprint   
> 16:32:47:8D:89:F9:21:3A:92:00:85:63:F5:A4:A7:D3:12:40:8A:D6
> SHA-256 Fingerprint   
> D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54
> 
> 2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA 
> Limited, C=CN
> Certificate Serial Number: 5e68d61171946350560068f33ec9c591
> SHA-1 Fingerprint   
> B9:42:94:BF:91:EA:8F:B6:4B:E6:10:97:C7:FB:00:13:59:B6:76:CB
> SHA-256 Fingerprint   
> 4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08
> 
> 3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA 
> Limited, C=CN
> Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
> SHA-1 Fingerprint   
> FB:ED:DC:90:65:B7:27:20:37:BC:55:0C:9C:56:DE:BB:F2:78:94:E1
> SHA-256 Fingerprint   
> D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16
> 
> 4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
> Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
> SHA-1 Fingerprint   
> D2:7A:D2:BE:ED:94:C0:A1:3C:C7:25:21:EA:5D:71:BE:81:19:F3:2B
> SHA-256 Fingerprint   
> 8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02
> 
> 5) Subject: CN=StartCom Certification Authority, OU=Secure Digital 
> Certificate Signing, O=StartCom Ltd., C=IL
> Certificate Serial Number: 01
> SHA-1 Fingerprint   
> 3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F
> SHA-256 Fingerprint   
> C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA
> 
> 6) Subject: CN=StartCom Certification Authority, OU=Secure Digital 
> Certificate Signing, O=StartCom Ltd., C=IL
> Certificate Serial Number: 2d
> SHA-1 Fingerprint   
> A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
> SHA-256 Fingerprint   
> E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11
> 
> 7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., 
> C=IL
> Certificate Serial Number: 3b
> SHA-1 Fingerprint   
> 31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
> SHA-256 Fingerprint   
> C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95
> 
> I intend to move forward as follows, unless further information or input 
> causes me to rethink this plan. Therefore, I will continue to appreciate your 
> input, and this discussion is still open.
> 
> Mozilla will perform the following 4 actions. I have filed Bugzilla Bug 
> #1309707 to track the engineering work for this. Please keep discussion here 
> in mozilla.dev.security.policy, and not in the bug.
> 
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date 
> after October 21, 2016. If additional back-dating is discovered (by any 
> means) to circumvent this control, then Mozilla will immediately and 
> permanently revoke trust in the Affected Roots.
> -- This change will go into the Firefox 51 release train [4]. 
> -- The code will use the subject key id (hash of public key) to identify the 
> Affected Roots, so that the control will also apply to cross-certs of the 
> Affected Roots.
> 2) Add the previously identified backdated SHA-1 certs chaining up to the 
> Affected Roots to OneCRL.
> 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> 4) Remove the Affected Roots from NSS after the SSL certificates issued 
> before October 1, 2016, have expired or have been replaced.
> 
> WoSign may apply for inclusion of new (replacement) root certificates 
> following Mozilla's normal root inclusion/change process (minus waiting 

Re: Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

On Thursday, October 13, 2016 at 10:17:28 AM UTC-7, Jonathan Rudenberg wrote:
> Can you clarify if the notBefore cutoff is October 1, 2016, and 
> not October 21, 2016? There are two conflicting dates in the listed actions.

My thinking is that we would distrust certs issued after next week (Oct 21), 
and that Oct 1 would be sufficient time for any clients to find an alternative 
solution. 

But, as you mention, that may be too confusing, so we should pick one date.

Is there any reason why that date cannot be October 1?

Thanks,
Kathleen


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

Re: List Content Policy

[Han Yuwei]

在 2016年10月13日星期四 UTC+8下午11:58:54，Gervase Markham写道：
> A note on accepted content for this list:
> 
> Concrete information which may be important for security policy
> decisions Mozilla has to make is welcome. Wild and unsubstantiated
> accusations are not, nor are comments which attack a person or company
> based on their nationality. I have already rejected one message of this
> type and will reject further ones as necessary.
> 
> Gerv

What handl...@gmail.com said at "StartCom & Qihoo incidents" in Chinese is also 
a offended content. Sent time is 2016OCT13 15:10 UTC
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Remediation Plan for WoSign and StartCom

[Jonathan Rudenberg]

On Oct 13, 2016, at 12:49, Kathleen Wilson  wrote:
> 
> 1) Distrust certificates chaining up to Affected Roots with a notBefore date 
> after October 21, 2016. If additional back-dating is discovered (by any 
> means) to circumvent this control, then Mozilla will immediately and 
> permanently revoke trust in the Affected Roots.
> -- This change will go into the Firefox 51 release train [4]. 
> -- The code will use the subject key id (hash of public key) to identify the 
> Affected Roots, so that the control will also apply to cross-certs of the 
> Affected Roots.
> 2) Add the previously identified backdated SHA-1 certs chaining up to the 
> Affected Roots to OneCRL.
> 3) No longer accept audits carried out by Ernst & Young Hong Kong.
> 4) Remove the Affected Roots from NSS after the SSL certificates issued 
> before October 1, 2016, have expired or have been replaced.

Can you clarify if the notBefore cutoff is October 1, 2016, and not October 21, 
2016? There are two conflicting dates in the listed actions.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[nessuno . acasa]

On Thursday, October 13, 2016 at 7:51:11 PM UTC+3, Jakob Bohm wrote:

> I just skimmed it, and that just looks like Qihoo 360 acquired some
> other companies that I don't recognize and did so by technically
> merging the company while concentrating ownership with the existing
> Qihoo 360 shareholders.

"the Company (namely, Qihoo 360) became a wholly owned subsidiary of Midco"

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

Remediation Plan for WoSign and StartCom

[Kathleen Wilson]

All,

Thanks again to all of you who have put in so much time and effort to determine 
what happened with WoSign and StartCom and discuss what to do about it.

Based on the information that I have seen regarding WoSign, I believe that 
WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL 
certs, when they knew full well that was no longer allowed. I also believe that 
the deception continued even after Mozilla directly asked WoSign about this. 
WoSign has lost my confidence in their ability and intention to follow 
Mozilla's policies. Therefore, I think we should respond similarly to WoSign as 
we did to CNNIC [1][2]. Unfortunately, the number of certificates and the 
timescales involved are such that we prefer not to create a list of the domains 
for which previously-issued certs that chain up to the Affected Roots may 
continue to be trusted, so our approach will be a little different, as Gerv 
previously described[3].

Within this message, the term “Affected Roots” applies to the following 7 root 
certificates.

1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 50706bcdd813fc1b4e3b3372d211488d
SHA-1 Fingerprint   
16:32:47:8D:89:F9:21:3A:92:00:85:63:F5:A4:A7:D3:12:40:8A:D6
SHA-256 Fingerprint   
D6:F0:34:BD:94:AA:23:3F:02:97:EC:A4:24:5B:28:39:73:E4:47:AA:59:0F:31:0C:77:F4:8F:DF:83:11:22:54

2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, 
C=CN
Certificate Serial Number: 5e68d61171946350560068f33ec9c591
SHA-1 Fingerprint   
B9:42:94:BF:91:EA:8F:B6:4B:E6:10:97:C7:FB:00:13:59:B6:76:CB
SHA-256 Fingerprint   
4B:22:D5:A6:AE:C9:9F:3C:DB:79:AA:5E:C0:68:38:47:9C:D5:EC:BA:71:64:F7:F2:2D:C1:D6:5F:63:D8:57:08

3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA 
Limited, C=CN
Certificate Serial Number: 6b25da8a889d7cbc0f05b3b17a614544
SHA-1 Fingerprint   
FB:ED:DC:90:65:B7:27:20:37:BC:55:0C:9C:56:DE:BB:F2:78:94:E1
SHA-256 Fingerprint   
D4:87:A5:6F:83:B0:74:82:E8:5E:96:33:94:C1:EC:C2:C9:E5:1D:09:03:EE:94:6B:02:C3:01:58:1E:D9:9E:16

4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
Certificate Serial Number: 684a5870806bf08f02faf6dee8b09090
SHA-1 Fingerprint   
D2:7A:D2:BE:ED:94:C0:A1:3C:C7:25:21:EA:5D:71:BE:81:19:F3:2B
SHA-256 Fingerprint   
8B:45:DA:1C:06:F7:91:EB:0C:AB:F2:6B:E5:88:F5:FB:23:16:5C:2E:61:4B:F8:85:56:2D:0D:CE:50:B2:9B:02

5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate 
Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 01
SHA-1 Fingerprint   
3E:2B:F7:F2:03:1B:96:F3:8C:E6:C4:D8:A8:5D:3E:2D:58:47:6A:0F
SHA-256 Fingerprint   
C7:66:A9:BE:F2:D4:07:1C:86:3A:31:AA:49:20:E8:13:B2:D1:98:60:8C:B7:B7:CF:E2:11:43:B8:36:DF:09:EA

6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate 
Signing, O=StartCom Ltd., C=IL
Certificate Serial Number: 2d
SHA-1 Fingerprint   
A3:F1:33:3F:E2:42:BF:CF:C5:D1:4E:8F:39:42:98:40:68:10:D1:A0
SHA-256 Fingerprint   
E1:78:90:EE:09:A3:FB:F4:F4:8B:9C:41:4A:17:D6:37:B7:A5:06:47:E9:BC:75:23:22:72:7F:CC:17:42:A9:11

7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., 
C=IL
Certificate Serial Number: 3b
SHA-1 Fingerprint   
31:F1:FD:68:22:63:20:EE:C6:3B:3F:9D:EA:4A:3E:53:7C:7C:39:17
SHA-256 Fingerprint   
C7:BA:65:67:DE:93:A7:98:AE:1F:AA:79:1E:71:2D:37:8F:AE:1F:93:C4:39:7F:EA:44:1B:B7:CB:E6:FD:59:95

I intend to move forward as follows, unless further information or input causes 
me to rethink this plan. Therefore, I will continue to appreciate your input, 
and this discussion is still open.

Mozilla will perform the following 4 actions. I have filed Bugzilla Bug 
#1309707 to track the engineering work for this. Please keep discussion here in 
mozilla.dev.security.policy, and not in the bug.

1) Distrust certificates chaining up to Affected Roots with a notBefore date 
after October 21, 2016. If additional back-dating is discovered (by any means) 
to circumvent this control, then Mozilla will immediately and permanently 
revoke trust in the Affected Roots.
-- This change will go into the Firefox 51 release train [4]. 
-- The code will use the subject key id (hash of public key) to identify the 
Affected Roots, so that the control will also apply to cross-certs of the 
Affected Roots.
2) Add the previously identified backdated SHA-1 certs chaining up to the 
Affected Roots to OneCRL.
3) No longer accept audits carried out by Ernst & Young Hong Kong.
4) Remove the Affected Roots from NSS after the SSL certificates issued before 
October 1, 2016, have expired or have been replaced.

WoSign may apply for inclusion of new (replacement) root certificates following 
Mozilla's normal root inclusion/change process (minus waiting in the queue for 
the discussion), after they have completed all of the following action items, 
and no earlier than June 1, 2017. If StartCom is able to provide proof enough 
to convince the Mozilla community in the mozilla.dev.security.policy forum 

Re: WoSign: updated report and discussion

[Jakob Bohm]

On 13/10/2016 04:36, 谭晓生 wrote:

The HSM is stored offline, in the Vault of Qihoo 360’s head quarter, a little 
bit surprised by this question, I don’t know if there other CAs put their Root 
Certificates online?
If anybody have evident to say “Wosign have the private key of StartCom”, 
please show us here.



Thanks for that information.  Your previous post saying the "PKI
server" was completely duplicated at WoSign HQ without saying that
server did not contain the the private key was what made me ask about
that possibility.

For additional clarification, the HSM that is only in the Qihoo 360 HQ
vault, is this the HSM for the StartCOM CA root, and/or the HSM for the
Intermediary certificates?


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

List Content Policy

[Gervase Markham]

A note on accepted content for this list:

Concrete information which may be important for security policy
decisions Mozilla has to make is welcome. Wild and unsubstantiated
accusations are not, nor are comments which attack a person or company
based on their nationality. I have already rejected one message of this
type and will reject further ones as necessary.

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

Re: StartCom & Qihoo Incidents

[amelyee]

Just add more info: WireLurker Virus on ios and OS X 
https://beijingtoday.com.cn/2014/11/wirelurker-virus-cripples-qihoo-360s-credibility/

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

Re: StartCom & Qihoo Incidents

[handleft]

360 和 周鸿祎 都是无耻的。
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[galaxy001]

Accroding to this newspaper, 360 do have join the GFW project at 2012-07-02.
http://web.archive.org/web/20120705031419/http://www.21cbh.com/HTML/2012-7-2/2NMDM2XzQ2NTU2Nw.html

However, the chief of 360, 周鸿祎, personally said it is not true in a local SNS 
site.

On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
> never been involved in * Fire Wall project, if you did some investigation 
> to the message that accused Qihoo 360 joined the project “Search Engine 
> Content Security Management System”, you should know the project had been 
> done on Feb 2005, before Qihoo 360 was founded on Aug 2005, and the project 
> is neither part of the * fire wall project nor a project done by Qihoo 
> 360, actually it is part of the efforts to help Yahoo’s search engine could 
> work in China, I was the tech head of Yahoo!China ‘s tech team, director of 
> engineering and soon the CTO of Yahoo!China, I know what happened at that 
> time.
>  
> Thanks，
> Xiaosheng Tan
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[谭晓生]

Are there any words saying “award to Qihoo to recognize their long time support 
for censorship”? 
It is an official thanks letter from The Ministry of Public Security of the 
People’s Republic of China, the equivalent organization with FBI of U.S, it 
thanks for my team and myself to join the information security work the 3rd 
Sept military review affair! I can tell you that my team and myself joined the 
information security work for G20 meeting just finished last month, I might got 
a thanks letter soon, is there anything wrong to do that? 

If anybody care about this, please ask somebody to translate this letter for 
you, I do not have time to waste here on somebody lied.

For the malware accuses, Yahoo acquired 3721 in 2003, do you think Yahoo 
acquired a malware company? Is there any anti-virus software killed 3721’s 
software? 

Thanks，
Xiaosheng Tan



在 2016/10/13 下午5:26，“dev-security-policy 代表 
solar” 写入:

Some more information. 

3721 helper, the most notorious malware in china was created by Hongyi zhou 
and his company 3721 in 1998. According to Mr. Tan's bio, he was the 
development director of 3721. So I believe he directly participated in and led 
the development of the malware.

There is another evidence of Qihoo cooperating with chinese government to 
censor the internet. Last year, the Ministry of Public Security (the 
stakeholder of GFW) give an award to Qihoo to recognize their long time support 
for censorship especially during the event of the 70th anniversary of the 
victory of World War II. The official paper of the award 
(http://www.canyu.org/n102771c6.aspx) was listed on Qihoo website. But it was 
soon removed before widely exposed in public. Moreover, the chinese name(谭晓生) 
of Mr. Tan Xiaosheng was mentioned in the official paper.

I do NOT trust the person who developed malware, and I also do NOT trust 
the CA involved in censorship.
___
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: WoSign: updated report and discussion

[Han Yuwei]

在 2016年10月13日星期四 UTC+8下午9:09:11，uri...@gmail.com写道：
> >WoSign will resell other trusted CA's SSL certificate to our customers to 
> >provide best product and best service to our customers. 
> 
> Is the plan to resell StartCom certificates?
> 
> On Thursday, October 13, 2016 at 4:18:54 AM UTC-4, Richard Wang wrote:
> > Percy,
> > 
> > I think your English is too bad! And the English translation from Chinese 
> > is very bad.
> > The report said: "Richard Wang will be relieved of his duties as CEO of 
> > WoSign", it is "will be". Now I am the Acting CEO of WoSign till the new 
> > CEO arrives. Anybody that is interesting in this hot position of the CEO of 
> > WoSign can send your Resume to me.
> > 
> > WoSign will resell other trusted CA's SSL certificate to our customers to 
> > provide best product and best service to our customers.
> > 
> > Again, your English translation from Chinese is very bad, I copy the 
> > Chinese sentence here that I wish somebody can translate it correctly.
> > 沃通(WoSign)能取得今天的成绩，除了需要感谢公司创始人/CEO王高华先生带领全体员工一起努力拼搏和全力奉献以外，更应该感谢多年来广大用户对沃通(WoSign)品牌的厚爱，我们对这样的信任倍感珍惜，将不负使命克服各种困难为广大用户提供更好的产品和更优质的服务。
> >  
> > 
> > Best Regards,
> > 
> > Richard Wang
> > 
> > 
> > -Original Message-
> > From: dev-security-policy 
> > [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] 
> > On Behalf Of Percy
> > Sent: Thursday, October 13, 2016 8:25 AM
> > To: mozilla-dev-security-pol...@lists.mozilla.org
> > Subject: Re: WoSign: updated report and discussion
> > 
> > WoSign has so far announced nothing about those incidents or immediate 
> > distrust (Apple and Mozilla) to its end users. On the contrary, WoSign had 
> > a press release dated Oct 8th 
> > (https://www.wosign.com/news/netcraft-ssl-oct.htm) titled "WoSign SSL certs 
> > reaches almost 50% market share in China". In the press release, it stated 
> > that "WoSign's achievement today is due to company founder and CEO Richard 
> > Wang leads all staff to be dedicated". WoSign is depicted as this positive, 
> > strong growing company. Nothing about its distrust in the immediate future 
> > is mentioned. 
> > 
> > In Oct 7th, in the incident report in English, WoSign admitted multiple 
> > intentional mistakes and deceptions  
> > (https://www.google.com/url?q=https%3A%2F%2Fwww.wosign.com%2Freport%2FWoSign_Incident_Report_Update_07102016.pdf=D=1=AFQjCNGRzAxwYrEEiA_SN5gfcsftSst0nA)
> >  and that the CEO Richard Wang to be relieved of its duties. 
> > 
> > I'm calling WoSign out on this two-faced behavior towards Chinese end users 
> > and foreign security researchers.
> > ___
> > dev-security-policy mailing list
> > dev-security-policy@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-security-policy

Wosign's initial business is reselling other's certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Han Yuwei]

在 2016年10月13日星期四 UTC+8下午2:01:19，yliv...@gmail.com写道：
> Would this be enough? 
> http://www.cac.gov.cn/2016-09/19/c_1119583763.htm
> 
> On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> > Yuwei, 
> > I don’t know who you are, but I can tell you and the community, Qihoo 360 
> > never been involved in * Fire Wall project, if you did some 
> > investigation to the message that accused Qihoo 360 joined the project 
> > “Search Engine Content Security Management System”, you should know the 
> > project had been done on Feb 2005, before Qihoo 360 was founded on Aug 
> > 2005, and the project is neither part of the * fire wall project nor a 
> > project done by Qihoo 360, actually it is part of the efforts to help 
> > Yahoo’s search engine could work in China, I was the tech head of 
> > Yahoo!China ‘s tech team, director of engineering and soon the CTO of 
> > Yahoo!China, I know what happened at that time.
> >  
> > Thanks，
> > Xiaosheng Tan
> > 
> > 
> > 
> > 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
> > Yuwei” > hanyuwe...@gmail.com> 写入:
> > 
> > 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > > As Gerv suggested this was the official call for incidents with 
> > respect to StartCom, it seems appropriate to start a new thread.
> > > 
> > > It would seem that, in evaluating the relationship with WoSign and 
> > Qihoo, we naturally reach three possible conclusions:
> > > 1) StartCom is treated as an independent entity
> > > 2) StartCom is treated as a subsidiary of Qihoo
> > > 3) StartCom is treated as a subsidiary of WoSign
> > > 
> > > We know there are serious incidents with WoSign that, collectively, 
> > encourage the community to distrust future certificates. However, there 
> > hasn't been a similar investigation into the trustworthiness of StartCom as 
> > an independent entity or as an entity operated by Qihoo. It would seem that 
> > germane to the discussion is how trustworthy the claims are - from either 
> > StartCom or Qihoo - and how that affects trust.
> > > 
> > > Incidents with StartCom:
> > > A) Duplicate Serials. 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > > We know that StartCom had issues issuing duplicate serials, in 
> > violation of RFC 5280. We know that they did not prioritize resolution, and 
> > when attempting resolution, did so incompletely, as the issue still 
> > resurfaced.
> > > 
> > > C) Improper OCSP responder. 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > > We know that StartCom continues to have issue with their OCSP 
> > responder after they issue certificates. Presumably, this is a CDN 
> > distribution delay, but we can't be sure, especially considering Incident A 
> > was with the underlying systems. As a consequence of this, users with 
> > StartCom certificates are disproportionately disadvantaged from enabling 
> > OCSP stapling, which many browser programs support (and is perhaps the only 
> > viable path towards a complete revocation solution).
> > > 
> > > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > > We know StartCom had a notoriously poor response to HeartBleed. Eddy 
> > first dismissed the significance, and then when proven wrong, still 
> > continued to charge $25 USD for revocation. Ostensibly, this is a violation 
> > of the Baseline Requirements, in that CAs are required to revoke 
> > certificates suspected of Key Compromise. However, despite the BRs 
> > effective date of 2012, Mozilla was not aggressively imposing compliance 
> > then (... or now, to be fair).
> > > 
> > > G) StartCom BR violations - IV 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> > > StartCom was materially violating its CP/CPS and the Baseline 
> > Requirements with respect to certain types of validation. No explanation 
> > for the root cause provided.
> > > 
> > > I) StartCom BR violations (2) - Key Sizes 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> > > StartCom was issuing certificates less than 2048 bits.
> > > 
> > > K) StartCom impersonating mozilla.com. 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> > > StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
> > www.mozilla.com and placed it on an Internet-facing server.
> > > 
> > > M) StartCom BR violations (3) - Key exponents 
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> > > StartCom was not enforcing the BRs with respect to RSA public 
> > exponents.
> > > 
> > > O) StartCom BR violations (4) - Curve violations 
> > https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> > > StartCom was not enforcing the BRs with respect to EC 

Re: StartCom & Qihoo Incidents

[Han Yuwei]

在 2016年10月13日星期四 UTC+8上午10:58:34，谭晓生写道：
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
> never been involved in * Fire Wall project, if you did some investigation 
> to the message that accused Qihoo 360 joined the project “Search Engine 
> Content Security Management System”, you should know the project had been 
> done on Feb 2005, before Qihoo 360 was founded on Aug 2005, and the project 
> is neither part of the * fire wall project nor a project done by Qihoo 
> 360, actually it is part of the efforts to help Yahoo’s search engine could 
> work in China, I was the tech head of Yahoo!China ‘s tech team, director of 
> engineering and soon the CTO of Yahoo!China, I know what happened at that 
> time.
>  
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
> Yuwei” hanyuwe...@gmail.com> 写入:
> 
> 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > As Gerv suggested this was the official call for incidents with respect 
> to StartCom, it seems appropriate to start a new thread.
> > 
> > It would seem that, in evaluating the relationship with WoSign and 
> Qihoo, we naturally reach three possible conclusions:
> > 1) StartCom is treated as an independent entity
> > 2) StartCom is treated as a subsidiary of Qihoo
> > 3) StartCom is treated as a subsidiary of WoSign
> > 
> > We know there are serious incidents with WoSign that, collectively, 
> encourage the community to distrust future certificates. However, there 
> hasn't been a similar investigation into the trustworthiness of StartCom as 
> an independent entity or as an entity operated by Qihoo. It would seem that 
> germane to the discussion is how trustworthy the claims are - from either 
> StartCom or Qihoo - and how that affects trust.
> > 
> > Incidents with StartCom:
> > A) Duplicate Serials. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > We know that StartCom had issues issuing duplicate serials, in 
> violation of RFC 5280. We know that they did not prioritize resolution, and 
> when attempting resolution, did so incompletely, as the issue still 
> resurfaced.
> > 
> > C) Improper OCSP responder. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > We know that StartCom continues to have issue with their OCSP responder 
> after they issue certificates. Presumably, this is a CDN distribution delay, 
> but we can't be sure, especially considering Incident A was with the 
> underlying systems. As a consequence of this, users with StartCom 
> certificates are disproportionately disadvantaged from enabling OCSP 
> stapling, which many browser programs support (and is perhaps the only viable 
> path towards a complete revocation solution).
> > 
> > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > We know StartCom had a notoriously poor response to HeartBleed. Eddy 
> first dismissed the significance, and then when proven wrong, still continued 
> to charge $25 USD for revocation. Ostensibly, this is a violation of the 
> Baseline Requirements, in that CAs are required to revoke certificates 
> suspected of Key Compromise. However, despite the BRs effective date of 2012, 
> Mozilla was not aggressively imposing compliance then (... or now, to be 
> fair).
> > 
> > G) StartCom BR violations - IV 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> > StartCom was materially violating its CP/CPS and the Baseline 
> Requirements with respect to certain types of validation. No explanation for 
> the root cause provided.
> > 
> > I) StartCom BR violations (2) - Key Sizes 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> > StartCom was issuing certificates less than 2048 bits.
> > 
> > K) StartCom impersonating mozilla.com. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> > StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
> www.mozilla.com and placed it on an Internet-facing server.
> > 
> > M) StartCom BR violations (3) - Key exponents 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> > StartCom was not enforcing the BRs with respect to RSA public exponents.
> > 
> > O) StartCom BR violations (4) - Curve violations 
> https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> > StartCom was not enforcing the BRs with respect to EC curve algorithms.
> > 
> > 
> > 
> > In addition to discussion of StartCom issues, it seems relevant to 
> future trust to evaluate issues with Qihoo. Many in the Mozilla community may 
> not have direct interactions with Qihoo, but they have obtained some 
> notoriety in security circles.
> > 
> > Q.A) Qihoo masking 

Re: WoSign: updated report and discussion

[urijah]

>WoSign will resell other trusted CA's SSL certificate to our customers to 
>provide best product and best service to our customers. 

Is the plan to resell StartCom certificates?

On Thursday, October 13, 2016 at 4:18:54 AM UTC-4, Richard Wang wrote:
> Percy,
> 
> I think your English is too bad! And the English translation from Chinese is 
> very bad.
> The report said: "Richard Wang will be relieved of his duties as CEO of 
> WoSign", it is "will be". Now I am the Acting CEO of WoSign till the new CEO 
> arrives. Anybody that is interesting in this hot position of the CEO of 
> WoSign can send your Resume to me.
> 
> WoSign will resell other trusted CA's SSL certificate to our customers to 
> provide best product and best service to our customers.
> 
> Again, your English translation from Chinese is very bad, I copy the Chinese 
> sentence here that I wish somebody can translate it correctly.
> 沃通(WoSign)能取得今天的成绩，除了需要感谢公司创始人/CEO王高华先生带领全体员工一起努力拼搏和全力奉献以外，更应该感谢多年来广大用户对沃通(WoSign)品牌的厚爱，我们对这样的信任倍感珍惜，将不负使命克服各种困难为广大用户提供更好的产品和更优质的服务。
>  
> 
> Best Regards,
> 
> Richard Wang
> 
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
> Behalf Of Percy
> Sent: Thursday, October 13, 2016 8:25 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: WoSign: updated report and discussion
> 
> WoSign has so far announced nothing about those incidents or immediate 
> distrust (Apple and Mozilla) to its end users. On the contrary, WoSign had a 
> press release dated Oct 8th 
> (https://www.wosign.com/news/netcraft-ssl-oct.htm) titled "WoSign SSL certs 
> reaches almost 50% market share in China". In the press release, it stated 
> that "WoSign's achievement today is due to company founder and CEO Richard 
> Wang leads all staff to be dedicated". WoSign is depicted as this positive, 
> strong growing company. Nothing about its distrust in the immediate future is 
> mentioned. 
> 
> In Oct 7th, in the incident report in English, WoSign admitted multiple 
> intentional mistakes and deceptions  
> (https://www.google.com/url?q=https%3A%2F%2Fwww.wosign.com%2Freport%2FWoSign_Incident_Report_Update_07102016.pdf=D=1=AFQjCNGRzAxwYrEEiA_SN5gfcsftSst0nA)
>  and that the CEO Richard Wang to be relieved of its duties. 
> 
> I'm calling WoSign out on this two-faced behavior towards Chinese end users 
> and foreign security researchers.
> ___
> 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: StartCom & Qihoo Incidents

[solar]

Some more information. 

3721 helper, the most notorious malware in china was created by Hongyi zhou and 
his company 3721 in 1998. According to Mr. Tan's bio, he was the development 
director of 3721. So I believe he directly participated in and led the 
development of the malware.

There is another evidence of Qihoo cooperating with chinese government to 
censor the internet. Last year, the Ministry of Public Security (the 
stakeholder of GFW) give an award to Qihoo to recognize their long time support 
for censorship especially during the event of the 70th anniversary of the 
victory of World War II. The official paper of the award 
(http://www.canyu.org/n102771c6.aspx) was listed on Qihoo website. But it was 
soon removed before widely exposed in public. Moreover, the chinese name(谭晓生) 
of Mr. Tan Xiaosheng was mentioned in the official paper.

I do NOT trust the person who developed malware, and I also do NOT trust the CA 
involved in censorship.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[谭晓生]

The information on Baidu Baike is not correct, I tried to correct it, but 
failed, I don’t know why.
I’m the Vice President of Qihoo 360 from end of 2009, installed as Chief 
Privacy Officer from 15th March 2012 as well, titled as Chief Security Officer 
of Qihoo 360 from Feb 2016, I never been the CTO of Qihoo 360.
I’m the school mate of Mr.Hongyi Zhou, same grade, but not in the same class, 
both in Computer Science and Engineering Dept of Xi’an Jiaotong University from 
1988 to 1992, I worked for Mr.Zhou from 2003 to 2005, then 2009 till now.
I’m here on behalf of myself, and answer some question about Qihoo 360 under 
the authority of my responsibility: Chief Security Officer, I should take care 
of the information security related issues.
Is there anybody think any information in the cyber space is truth? It is funny.

Thanks，
Xiaosheng Tan

在 2016/10/13 下午4:22，“dev-security-policy 代表 
solar” 写入:

Mr. Xiaosheng Tan

According to the page of your personal details 
(http://baike.baidu.com/view/4571996.htm) in Baidu BaiKe. Currently you are the 
CTO and VP of Qihuoo. And you have a long recorder working and even studying 
with Hongyi Zhou, the CEO and the owner of Qihoo who was entitled as "the 
father of Chinese malware" by netizen.

So, do you represent your company to explain the issues? or Hongyi Zhou? or 
only yourself?

On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
never been involved in * Fire Wall project, if you did some investigation 
to the message that accused Qihoo 360 joined the project “Search Engine Content 
Security Management System”, you should know the project had been done on Feb 
2005, before Qihoo 360 was founded on Aug 2005, and the project is neither part 
of the * fire wall project nor a project done by Qihoo 360, actually it is 
part of the efforts to help Yahoo’s search engine could work in China, I was 
the tech head of Yahoo!China ‘s tech team, director of engineering and soon the 
CTO of Yahoo!China, I know what happened at that time.
>  
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
Yuwei” 写入:
> 
> 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > As Gerv suggested this was the official call for incidents with 
respect to StartCom, it seems appropriate to start a new thread.
> > 
> > It would seem that, in evaluating the relationship with WoSign and 
Qihoo, we naturally reach three possible conclusions:
> > 1) StartCom is treated as an independent entity
> > 2) StartCom is treated as a subsidiary of Qihoo
> > 3) StartCom is treated as a subsidiary of WoSign
> > 
> > We know there are serious incidents with WoSign that, collectively, 
encourage the community to distrust future certificates. However, there hasn't 
been a similar investigation into the trustworthiness of StartCom as an 
independent entity or as an entity operated by Qihoo. It would seem that 
germane to the discussion is how trustworthy the claims are - from either 
StartCom or Qihoo - and how that affects trust.
> > 
> > Incidents with StartCom:
> > A) Duplicate Serials. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > We know that StartCom had issues issuing duplicate serials, in 
violation of RFC 5280. We know that they did not prioritize resolution, and 
when attempting resolution, did so incompletely, as the issue still resurfaced.
> > 
> > C) Improper OCSP responder. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > We know that StartCom continues to have issue with their OCSP 
responder after they issue certificates. Presumably, this is a CDN distribution 
delay, but we can't be sure, especially considering Incident A was with the 
underlying systems. As a consequence of this, users with StartCom certificates 
are disproportionately disadvantaged from enabling OCSP stapling, which many 
browser programs support (and is perhaps the only viable path towards a 
complete revocation solution).
> > 
> > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 
/ https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > We know StartCom had a notoriously poor response to HeartBleed. 
Eddy first dismissed the significance, and then when proven wrong, still 
continued to charge $25 USD for revocation. Ostensibly, this is a violation of 
the Baseline Requirements, in that CAs are required to revoke certificates 
suspected of Key Compromise. However, despite the BRs effective date of 2012, 

Re: StartCom & Qihoo Incidents

[Eddy Nigg]

On 10/12/2016 10:11 PM, Ryan Sleevi wrote:

As Gerv suggested this was the official call for incidents with respect to 
StartCom, it seems appropriate to start a new thread.


Ryan, it was probably easy to dig up any possible claimed or proven 
issue ever surrounding StartCom during its ~ 10 years of operation. But 
if this is your level of measurement for remaining in a root store, than 
you have probably some other and larger CAs that would require your 
immediate attention more urgently



Incidents with StartCom:


As most issues have been discussed and explained at that time, I'm not 
sure about it's usefulness to repeat the same arguments and explanations 
again. Most issues you are listing were mostly minor (but makes your 
list longer of course) and have been effectively and properly dealt with.



K) StartCom impersonating mozilla.com. 
https://bugzilla.mozilla.org/show_bug.cgi?id=471702
StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
www.mozilla.com and placed it on an Internet-facing server.


You make this appear as if StartCom used its capacity as a certificate 
authority to somehow abuse somebody or something, but for the wider 
audience:


I was able to obtain a certificate for mozilla.org from Comodo without 
having the authority to validate said domain name - in fact I could have 
obtained also wild cards and many more certificates for any domain name 
would I have been willing to pay for it. I installed the certificate at 
a local server as a proof in the same fashion millions of web sites 
install theirs. The private key has never published to any third party 
and was eventually destroyed.


Interesting that you are using it to shoot the messenger from back then 
and list this as an item against StartCom :-)



I hope the above show that the odds are if the original StartCom systems are 
restored, we're likely to continue to have significant BR violations - a 
pattern StartCom has repeatedly demonstrated over several years.


There is no plan to use software that doesn't comply to the various 
requirements and it has never been. I'm not claiming that there have 
been zero issues during the last ten years, but StartCom has had always 
clear policies and practices in place about how to deal with an issue 
reasonably according to its significance, seriousness and importance.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. 
XMPP:   start...@startcom.org 

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

Re: StartCom & Qihoo Incidents

[solar]

Mr. Xiaosheng Tan

According to the page of your personal details 
(http://baike.baidu.com/view/4571996.htm) in Baidu BaiKe. Currently you are the 
CTO and VP of Qihuoo. And you have a long recorder working and even studying 
with Hongyi Zhou, the CEO and the owner of Qihoo who was entitled as "the 
father of Chinese malware" by netizen.

So, do you represent your company to explain the issues? or Hongyi Zhou? or 
only yourself?

On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
> never been involved in * Fire Wall project, if you did some investigation 
> to the message that accused Qihoo 360 joined the project “Search Engine 
> Content Security Management System”, you should know the project had been 
> done on Feb 2005, before Qihoo 360 was founded on Aug 2005, and the project 
> is neither part of the * fire wall project nor a project done by Qihoo 
> 360, actually it is part of the efforts to help Yahoo’s search engine could 
> work in China, I was the tech head of Yahoo!China ‘s tech team, director of 
> engineering and soon the CTO of Yahoo!China, I know what happened at that 
> time.
>  
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
> Yuwei” hanyuwe...@gmail.com> 写入:
> 
> 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > As Gerv suggested this was the official call for incidents with respect 
> to StartCom, it seems appropriate to start a new thread.
> > 
> > It would seem that, in evaluating the relationship with WoSign and 
> Qihoo, we naturally reach three possible conclusions:
> > 1) StartCom is treated as an independent entity
> > 2) StartCom is treated as a subsidiary of Qihoo
> > 3) StartCom is treated as a subsidiary of WoSign
> > 
> > We know there are serious incidents with WoSign that, collectively, 
> encourage the community to distrust future certificates. However, there 
> hasn't been a similar investigation into the trustworthiness of StartCom as 
> an independent entity or as an entity operated by Qihoo. It would seem that 
> germane to the discussion is how trustworthy the claims are - from either 
> StartCom or Qihoo - and how that affects trust.
> > 
> > Incidents with StartCom:
> > A) Duplicate Serials. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > We know that StartCom had issues issuing duplicate serials, in 
> violation of RFC 5280. We know that they did not prioritize resolution, and 
> when attempting resolution, did so incompletely, as the issue still 
> resurfaced.
> > 
> > C) Improper OCSP responder. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > We know that StartCom continues to have issue with their OCSP responder 
> after they issue certificates. Presumably, this is a CDN distribution delay, 
> but we can't be sure, especially considering Incident A was with the 
> underlying systems. As a consequence of this, users with StartCom 
> certificates are disproportionately disadvantaged from enabling OCSP 
> stapling, which many browser programs support (and is perhaps the only viable 
> path towards a complete revocation solution).
> > 
> > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > We know StartCom had a notoriously poor response to HeartBleed. Eddy 
> first dismissed the significance, and then when proven wrong, still continued 
> to charge $25 USD for revocation. Ostensibly, this is a violation of the 
> Baseline Requirements, in that CAs are required to revoke certificates 
> suspected of Key Compromise. However, despite the BRs effective date of 2012, 
> Mozilla was not aggressively imposing compliance then (... or now, to be 
> fair).
> > 
> > G) StartCom BR violations - IV 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> > StartCom was materially violating its CP/CPS and the Baseline 
> Requirements with respect to certain types of validation. No explanation for 
> the root cause provided.
> > 
> > I) StartCom BR violations (2) - Key Sizes 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> > StartCom was issuing certificates less than 2048 bits.
> > 
> > K) StartCom impersonating mozilla.com. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> > StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
> www.mozilla.com and placed it on an Internet-facing server.
> > 
> > M) StartCom BR violations (3) - Key exponents 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> > StartCom was not enforcing the BRs with respect to RSA public exponents.
> > 
> > O) StartCom BR violations (4) - Curve violations 
> 

Re: WoSign: updated report and discussion

[Eddy Nigg]

On 10/11/2016 11:57 AM, Gervase Markham wrote:


There is also the case of StartEncrypt. While no known
cert-to-wrong-person misissuance occurred because the researchers in
question used domains they already controlled to prove their point, but
there seemed to be multiple holes by which this might be possible.


I haven't forgotten it and mentioned that Inigo has several tasks at hand:

"/... he'll have to review also other areas and implement controls in 
case they were lacking or insufficient, something he's doing as we speak/"


This includes obviously development cycles and other areas, even if no 
issues have been detected or reported.



Of course, people can reasonably disagree on the seriousness of the
issue (standalone, and by comparison with e.g. WoSign issue N), and it
is true that StartCom took this codebase wholesale from WoSign, but it
seems incomplete to leave this out entirely.


It wasn't my intention to ignore it, but I understand that this issue 
has been quickly contained at that time.




Eddy: does StartCom currently have any fully-automated certificate
issuance mechanisms, or does every certificate request pass by human
eyes before issuance?


Generally speaking it's semi-automated with a flagging system that 
forces about 20% of all lower level certificates for a manual review and 
approval by the verification team. Of course EV and code signing 
certificates are issued only manually. The rest is issued automatically.


--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. 
XMPP:   start...@startcom.org 

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

Re: StartCom & Qihoo Incidents

[谭晓生]

There could be multiple books to tell the story of Qihoo 360 and Mr.Hongyi 
Zhou, Qihoo 360 fighted with Baidu, Alibaba & Tencent, the three largest 
internet companies of China in the past 10 years, there were a lot of law suits 
there, win and lose together, the ecosystem of China internet is a little bit 
special with others of the world, it is not my focus to discuss that here.
After 11 years, Qihoo 360 is the largest internet security company of China, 
the products are widely adopted by China internet users, it is not something 
could be instructed by the government, we must did something right.

Thanks，
Xiaosheng Tan

在 2016/10/13 上午10:35，“dev-security-policy 代表 
shangh...@gmail.com” 写入:

在 2016年10月13日星期四 UTC+8上午6:24:50，Percy写道：
> The Chinese wikipedia has well documented controversies surrounding Qihoo 
360. Unfortunately, it's not translated into the English Wikipedia. So please 
go to 
https://zh.wikipedia.org/wiki/%E5%A5%87%E8%99%8E360#.E5.95.86.E4.B8.9A.E7.9F.9B.E7.9B.BE.E4.B8.8E.E4.BA.89.E8.AE.AE.E4.BA.8B.E4.BB.B6
 and use Google Translate.

金山公司发布“360涉嫌偷窃用户隐私”的文章，并通过金山电池医生的弹窗散布相关信息

This is true, Search upload.360safe.com.
___
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: StartCom & Qihoo Incidents

[谭晓生]

Things went interesting, the webpage is about the 19 honored internet security 
researcher by China government, some of them are professors of university, like 
Professor Xiaoyun Wang who contributed a lot on cryptology(MD5 ), Min 
Yang, Haixin Duan, Jianwei Liu, Xingshu Chen……, and the fellow of China Academy 
of Engineering, Mr.Changxiang Shen, there is also officers of the 
Administration of public security, are they treated as “Bad Guys” in this 
community? 

Mr.Wenbin Zheng, the GM of Core Security BU of Qihoo 360, is one of the 19 
honored peoples there, he is the top experienced engineer on Microsoft Windows 
Driver development, focus on DEFENDING the virus/Trojan attack for Microsoft 
Windows, the XP Shield made by his team provide additional protect to XP users, 
effectively.

Maybe we should consider technology, product/service and politics separately, 
somebody may not be funs of some government, but if we mixed the technology, 
product/service and politics together, it might make the world even worse.

Thanks，
Xiaosheng Tan


在 2016/10/13 下午12:42，“dev-security-policy 代表 
yliva...@gmail.com” 写入:

Would this be enough? 
http://www.cac.gov.cn/2016-09/19/c_1119583763.htm

On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
never been involved in * Fire Wall project, if you did some investigation 
to the message that accused Qihoo 360 joined the project “Search Engine Content 
Security Management System”, you should know the project had been done on Feb 
2005, before Qihoo 360 was founded on Aug 2005, and the project is neither part 
of the * fire wall project nor a project done by Qihoo 360, actually it is 
part of the efforts to help Yahoo’s search engine could work in China, I was 
the tech head of Yahoo!China ‘s tech team, director of engineering and soon the 
CTO of Yahoo!China, I know what happened at that time.
>  
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
Yuwei” 写入:
> 
> 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > As Gerv suggested this was the official call for incidents with 
respect to StartCom, it seems appropriate to start a new thread.
> > 
> > It would seem that, in evaluating the relationship with WoSign and 
Qihoo, we naturally reach three possible conclusions:
> > 1) StartCom is treated as an independent entity
> > 2) StartCom is treated as a subsidiary of Qihoo
> > 3) StartCom is treated as a subsidiary of WoSign
> > 
> > We know there are serious incidents with WoSign that, collectively, 
encourage the community to distrust future certificates. However, there hasn't 
been a similar investigation into the trustworthiness of StartCom as an 
independent entity or as an entity operated by Qihoo. It would seem that 
germane to the discussion is how trustworthy the claims are - from either 
StartCom or Qihoo - and how that affects trust.
> > 
> > Incidents with StartCom:
> > A) Duplicate Serials. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > We know that StartCom had issues issuing duplicate serials, in 
violation of RFC 5280. We know that they did not prioritize resolution, and 
when attempting resolution, did so incompletely, as the issue still resurfaced.
> > 
> > C) Improper OCSP responder. 
https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > We know that StartCom continues to have issue with their OCSP 
responder after they issue certificates. Presumably, this is a CDN distribution 
delay, but we can't be sure, especially considering Incident A was with the 
underlying systems. As a consequence of this, users with StartCom certificates 
are disproportionately disadvantaged from enabling OCSP stapling, which many 
browser programs support (and is perhaps the only viable path towards a 
complete revocation solution).
> > 
> > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 
/ https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > We know StartCom had a notoriously poor response to HeartBleed. 
Eddy first dismissed the significance, and then when proven wrong, still 
continued to charge $25 USD for revocation. Ostensibly, this is a violation of 
the Baseline Requirements, in that CAs are required to revoke certificates 
suspected of Key Compromise. However, despite the BRs effective date of 2012, 
Mozilla was not aggressively imposing compliance then (... or now, to be fair).
> > 
> > G) StartCom BR violations - IV 

Re: WoSign: updated report and discussion

[Gervase Markham]

On 13/10/16 01:40, Percy wrote:
> (Hmm, my previous comment about two faced WoSign disappeared from
> Google group probably due to anti-spam. Gerv, can you recover it for
> me?)

I have that message via the news interface, so it did get posted. It's
not in the spam filter.

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

Re: StartCom & Qihoo Incidents

[zjuniverse]

The person who founded Qihoo 360， Hongwei Zhou（周鸿祎）, is the creator of the 
malware named 3721. 3721 is the most widely spread malware in China before the 
company Qihoo 360 was founded. The reason that "360安全卫士" (360 Total Security), 
which is the most important product of Qihoo 360, became popular is that it was 
the best software to remove malwares, especially 3721. As the creator of the 
most widely spread malware, it is not surprising 360 Total Security works well 
at removing malwares. However, I will never trust a security software made by 
the one made a malware. Just like I will never hire a guard that was a thief. 

As a Chinese Internet user, I strongly recommend removing the CAs related to 
Qihoo 360.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[anklm]

You have mentioned "Qihoo masking their browser as a critical Windows security 
update to IE users. " , but their browser is fully insecure.

"Qihoo 360 Safe Browser" ignores ssl certificate error , open page directly 
with cookie. 

First seen 2014: https://cabforum.org/pipermail/public/2014-October/004284.html

2015 again: https://cabforum.org/pipermail/public/2015-May/005579.html

Until now I downloaded their browser in my virtual machine, it's still open my 
website with self-signed certificate without warning.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[ylivan09]

Would this be enough? 
http://www.cac.gov.cn/2016-09/19/c_1119583763.htm

On Thursday, October 13, 2016 at 10:58:34 AM UTC+8, 谭晓生 wrote:
> Yuwei, 
> I don’t know who you are, but I can tell you and the community, Qihoo 360 
> never been involved in * Fire Wall project, if you did some investigation 
> to the message that accused Qihoo 360 joined the project “Search Engine 
> Content Security Management System”, you should know the project had been 
> done on Feb 2005, before Qihoo 360 was founded on Aug 2005, and the project 
> is neither part of the * fire wall project nor a project done by Qihoo 
> 360, actually it is part of the efforts to help Yahoo’s search engine could 
> work in China, I was the tech head of Yahoo!China ‘s tech team, director of 
> engineering and soon the CTO of Yahoo!China, I know what happened at that 
> time.
>  
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/13 上午5:22，“dev-security-policy 代表 Han 
> Yuwei” hanyuwe...@gmail.com> 写入:
> 
> 在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：
> > As Gerv suggested this was the official call for incidents with respect 
> to StartCom, it seems appropriate to start a new thread.
> > 
> > It would seem that, in evaluating the relationship with WoSign and 
> Qihoo, we naturally reach three possible conclusions:
> > 1) StartCom is treated as an independent entity
> > 2) StartCom is treated as a subsidiary of Qihoo
> > 3) StartCom is treated as a subsidiary of WoSign
> > 
> > We know there are serious incidents with WoSign that, collectively, 
> encourage the community to distrust future certificates. However, there 
> hasn't been a similar investigation into the trustworthiness of StartCom as 
> an independent entity or as an entity operated by Qihoo. It would seem that 
> germane to the discussion is how trustworthy the claims are - from either 
> StartCom or Qihoo - and how that affects trust.
> > 
> > Incidents with StartCom:
> > A) Duplicate Serials. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
> > We know that StartCom had issues issuing duplicate serials, in 
> violation of RFC 5280. We know that they did not prioritize resolution, and 
> when attempting resolution, did so incompletely, as the issue still 
> resurfaced.
> > 
> > C) Improper OCSP responder. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1006479 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1151270
> > We know that StartCom continues to have issue with their OCSP responder 
> after they issue certificates. Presumably, this is a CDN distribution delay, 
> but we can't be sure, especially considering Incident A was with the 
> underlying systems. As a consequence of this, users with StartCom 
> certificates are disproportionately disadvantaged from enabling OCSP 
> stapling, which many browser programs support (and is perhaps the only viable 
> path towards a complete revocation solution).
> > 
> > E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 / 
> https://bugzilla.mozilla.org/show_bug.cgi?id=994478
> > We know StartCom had a notoriously poor response to HeartBleed. Eddy 
> first dismissed the significance, and then when proven wrong, still continued 
> to charge $25 USD for revocation. Ostensibly, this is a violation of the 
> Baseline Requirements, in that CAs are required to revoke certificates 
> suspected of Key Compromise. However, despite the BRs effective date of 2012, 
> Mozilla was not aggressively imposing compliance then (... or now, to be 
> fair).
> > 
> > G) StartCom BR violations - IV 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1266942
> > StartCom was materially violating its CP/CPS and the Baseline 
> Requirements with respect to certain types of validation. No explanation for 
> the root cause provided.
> > 
> > I) StartCom BR violations (2) - Key Sizes 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1015767
> > StartCom was issuing certificates less than 2048 bits.
> > 
> > K) StartCom impersonating mozilla.com. 
> https://bugzilla.mozilla.org/show_bug.cgi?id=471702
> > StartCom's (former) CEO Eddy Nigg obtained a key and certificate for 
> www.mozilla.com and placed it on an Internet-facing server.
> > 
> > M) StartCom BR violations (3) - Key exponents 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1212655
> > StartCom was not enforcing the BRs with respect to RSA public exponents.
> > 
> > O) StartCom BR violations (4) - Curve violations 
> https://bug98304.bugzilla.mozilla.org/show_bug.cgi?id=1269183
> > StartCom was not enforcing the BRs with respect to EC curve algorithms.
> > 
> > 
> > 
> > In addition to discussion of StartCom issues, it seems relevant to 
> future trust to evaluate issues with Qihoo. Many in the Mozilla community may 
> not have direct interactions with Qihoo,