Re: StartCom & Qihoo Incidents

[Matt Palmer]

On Sat, Oct 29, 2016 at 10:17:59PM -0700, Percy wrote:
> On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> > On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of 
> > > the
> > > entire company into question. And such trust, in my view, should be
> > > evaluated when WoSign/StartCom submit their re-inclusion requests in the
> > > future.
> > 
> > You can make that argument when WoSign/StartCom's reinclusion discussions
> > take place on this list.  Now is not the appropriate time for that.
> 
> WoSign/StartCom's re-inclusion request might be a year from now. In the
> meanwhile, those 400 million users will be exposed to MITM.  That's why
> I'm bringing it up now, rather than one year later.

And you've already been told that there is nothing that the Mozilla
community can do, at this time, to influence Qihoo 360 into tightening their
certificate validation code, so there's no reason to keep on about it on
this list, at this time.

- Matt

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

Re: StartCom & Qihoo Incidents

[Percy]

On Wednesday, October 12, 2016 at 12:12:08 PM UTC-7, 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.
> 
> 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 their browser as a critical Windows security update to IE 
> users.
> http://wmos.info/archives/7717 / 
> http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
> Qihoo displayed a misleading security update for Windows users that instead 
> installed their browser.
> 
> Q.C) Qihoo browser actively enables insecure cryptography.
> https://docs.google.com/document/d/1b7lenmn5XO06QohaJzVffnJxjXjY1rD70wg34gfuxRo/edit
> Qihoo's browser is notably insecure with respect to SSL/TLS, with some of the 
> insecure changes requiring active modification to the low-level source 
> libraries that Chromium (of which they're based on) uses.
> 
> Q.E) Qihoo apps removed from app stores due to malware
> https://www.techinasia.com/qihoo-committing-fraud-google-making-huge-mistake 
> / https://www.techinasia.com/qihoo-apps-banned-apple-app-store
> Qihoo Apps have repeatedly been banned from Apple's App Store due to issues
> 
> Q.G) Qihoo "security" apps repeatedly found as unfair competition
> https://www.techinasia.com/qihoo-360-loses-chinas-courts-ordered-pay-sogou-82-million-unfair-competition
> 
> 
> 
> I hope the above show that the odds are if the original 

Re: StartCom & Qihoo Incidents

[He]

On October 30, 2016 8:39:55 PM GMT+08:00, "谭晓生"  wrote:
>Nothing compelled by the gov to trust the self-issued certificates.
>
>It is because some very large website like 12306.cn(the only one online
>entry to buy rail way tickets in China) and some government websites,
>they still using self-issued certificates, even we tried to offer free
>trusted certificates to them, they rejected.
>If a local browser try to block the access to these websites, user will
>force the browser to trust the self-issued certificates and complain,
>for the behavior training to end users, it is also an issue, user will
>used to trust the certificates which have a warning message by
>browsers, even there is a MITM attack, they still could not identify
>it.
>
>That’s the dilemma we have:
>Block the access to self-issued certificates, user will ignore and
>force trust the certificated, bad behavior training, user might change
>to competitor’s product.
>Do not block the access, there are possibility to do the MITM attack,
>the community complains.
>
>We already worked on a solution for a while and will release a report
>soon, hopefully to find a tradeoff between user experience and
>security.
>
>Thanks，
>Xiaosheng Tan
Hi, Tan.

I once visited my college webvpn website which is use self-signed certs, but 
360 browser continued load which was shocked me. It is not a **government 
website**(like your said 12306.cn), and I need know certs error.

As a Chinese netizen,  I don't think that browser should not tell users 
something serious happened which some users may not know how to operate. 

Sincerely,
He

PGP key-id=0x12f3d9a31960c4d4
PGP key Fingerprint=C793 674B 8F3D A78E 5600 834D 408C 9364 0A6D 0519


___
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月30日星期日 UTC+8下午8:40:37，谭晓生写道：
> Nothing compelled by the gov to trust the self-issued certificates.
> 
> It is because some very large website like 12306.cn(the only one online entry 
> to buy rail way tickets in China) and some government websites, they still 
> using self-issued certificates, even we tried to offer free trusted 
> certificates to them, they rejected.
> If a local browser try to block the access to these websites, user will force 
> the browser to trust the self-issued certificates and complain, for the 
> behavior training to end users, it is also an issue, user will used to trust 
> the certificates which have a warning message by browsers, even there is a 
> MITM attack, they still could not identify it.
> 
> That’s the dilemma we have:
> Block the access to self-issued certificates, user will ignore and force 
> trust the certificated, bad behavior training, user might change to 
> competitor’s product.
> Do not block the access, there are possibility to do the MITM attack, the 
> community complains.
> 
> We already worked on a solution for a while and will release a report soon, 
> hopefully to find a tradeoff between user experience and security.
> 
> Thanks，
> Xiaosheng Tan
> 
> 
> 发件人: Percy <percyal...@gmail.com>
> 日期: 2016年10月30日 星期日 下午4:01
> 至: 晓生 谭 <tanxiaosh...@360.cn>
> 抄送: "mozilla-dev-security-pol...@lists.mozilla.org" 
> <mozilla-dev-security-pol...@lists.mozilla.org>
> 主题: Re: StartCom & Qihoo Incidents
> 
> As we observed the large scale MITM against iCloud, Outlook, Google and 
> Github carried out on the backbone router with self-signed certs, and that 
> the browsers are explicitly loads self-signed certs, I think it's clear that 
> browsers in China are compelled by the gov to enable insecure cryptography by 
> default.
> 
> Percy 
> Alpha(PGP<https://pgp.mit.edu/pks/lookup?op=vindex=0xF30D100F7FE124AE>)
> 
> 
> On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生 
> <tanxiaosh...@360.cn<mailto:tanxiaosh...@360.cn>> wrote:
> Is there anybody thought about why it happens in China? Why the local browser 
> did not block the self-issued certificates?
> 
> Thanks，
> Xiaosheng Tan
> 
> 
> 
> 在 2016/10/30 
> 下午1:17，“Percy”<percyal...@gmail.com<mailto:percyal...@gmail.com>> 写入:
> 
> On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> > On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness 
> of the
> > > entire company into question. And such trust, in my view, should be
> > > evaluated when WoSign/StartCom submit their re-inclusion requests in 
> the
> > > future.
> >
> > You can make that argument when WoSign/StartCom's reinclusion 
> discussions
> > take place on this list.  Now is not the appropriate time for that.
> >
> > - Matt
> WoSign/StartCom's re-inclusion request might be a year from now. In the 
> meanwhile, those 400 million users will be exposed to MITM. That's why I'm 
> bringing it up now, rather than one year later.
> ___
> dev-security-policy mailing list
> 
> dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-security-policy

I think that you can maintain a list to preload self-signed certificates, 
something like HSTS preload. For me the 12306's certficate has a securtiy 
exception for a long time and it still works.

And there's any other government sites using self-signed certs? Who?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Gervase Markham]

On 30/10/16 12:39, 谭晓生 wrote:
> That’s the dilemma we have:
> Block the access to self-issued certificates, user will ignore and force 
> trust the certificated, bad behavior training, user might change to 
> competitor’s product.
> Do not block the access, there are possibility to do the MITM attack, the 
> community complains.

These are not your only two options. You could build a system which was
the opposite of Mozilla's OneCRL, or the equivalent of Microsoft's root
list - i.e. a Qihoo-curated list of self-signed certificates which were
to be trusted, which was dynamically downloaded by the browser on a
regular basis. That way, you could enable these big sites without
enabling all self-signed certificates.

Why did 12306.cn and other sites actively reject using a
publicly-trusted cert?

Gerv

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

Re: StartCom & Qihoo Incidents

[谭晓生]

Nothing compelled by the gov to trust the self-issued certificates.

It is because some very large website like 12306.cn(the only one online entry 
to buy rail way tickets in China) and some government websites, they still 
using self-issued certificates, even we tried to offer free trusted 
certificates to them, they rejected.
If a local browser try to block the access to these websites, user will force 
the browser to trust the self-issued certificates and complain, for the 
behavior training to end users, it is also an issue, user will used to trust 
the certificates which have a warning message by browsers, even there is a MITM 
attack, they still could not identify it.

That’s the dilemma we have:
Block the access to self-issued certificates, user will ignore and force trust 
the certificated, bad behavior training, user might change to competitor’s 
product.
Do not block the access, there are possibility to do the MITM attack, the 
community complains.

We already worked on a solution for a while and will release a report soon, 
hopefully to find a tradeoff between user experience and security.

Thanks，
Xiaosheng Tan


发件人: Percy <percyal...@gmail.com>
日期: 2016年10月30日 星期日 下午4:01
至: 晓生 谭 <tanxiaosh...@360.cn>
抄送: "mozilla-dev-security-pol...@lists.mozilla.org" 
<mozilla-dev-security-pol...@lists.mozilla.org>
主题: Re: StartCom & Qihoo Incidents

As we observed the large scale MITM against iCloud, Outlook, Google and Github 
carried out on the backbone router with self-signed certs, and that the 
browsers are explicitly loads self-signed certs, I think it's clear that 
browsers in China are compelled by the gov to enable insecure cryptography by 
default.

Percy 
Alpha(PGP<https://pgp.mit.edu/pks/lookup?op=vindex=0xF30D100F7FE124AE>)


On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生 
<tanxiaosh...@360.cn<mailto:tanxiaosh...@360.cn>> wrote:
Is there anybody thought about why it happens in China? Why the local browser 
did not block the self-issued certificates?

Thanks，
Xiaosheng Tan



在 2016/10/30 下午1:17，“Percy”<percyal...@gmail.com<mailto:percyal...@gmail.com>> 
写入:

On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of 
the
> > entire company into question. And such trust, in my view, should be
> > evaluated when WoSign/StartCom submit their re-inclusion requests in the
> > future.
>
> You can make that argument when WoSign/StartCom's reinclusion discussions
> take place on this list.  Now is not the appropriate time for that.
>
> - Matt
WoSign/StartCom's re-inclusion request might be a year from now. In the 
meanwhile, those 400 million users will be exposed to MITM. That's why I'm 
bringing it up now, rather than one year later.
___
dev-security-policy mailing list

dev-security-policy@lists.mozilla.org<mailto: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: [FORGED] Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Percy  writes:

>As we observed the large scale MITM against iCloud, Outlook, Google and
>Github carried out on the backbone router with self-signed certs, and that
>the browsers are explicitly loads self-signed certs, I think it's clear that
>browsers in China are compelled by the gov to enable insecure cryptography by
>default.

Is that really the government compelling them, or just the browser vendors
deciding to enable a free market and/or remove dependency on non-Chinese CAs?
If the browsers secretly trusted some government-run CA that'd be a different
matter, but I'm not sure whether simply chosing to trust self-signed certs is
a genuine smoking gun...

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

Re: StartCom & Qihoo Incidents

[Percy]

As we observed the large scale MITM against iCloud, Outlook, Google and
Github carried out on the backbone router with self-signed certs, and that
the browsers are explicitly loads self-signed certs, I think it's clear
that browsers in China are compelled by the gov to enable insecure
cryptography by default.

Percy Alpha(PGP
)


On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生  wrote:

> Is there anybody thought about why it happens in China? Why the local
> browser did not block the self-issued certificates?
>
> Thanks，
> Xiaosheng Tan
>
>
>
> 在 2016/10/30 下午1:17，“Percy” 写入:
>
> On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> > On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > > Perhaps not. However, Qihoo 360's behavior calls the
> trustworthiness of the
> > > entire company into question. And such trust, in my view, should be
> > > evaluated when WoSign/StartCom submit their re-inclusion requests
> in the
> > > future.
> >
> > You can make that argument when WoSign/StartCom's reinclusion
> discussions
> > take place on this list.  Now is not the appropriate time for that.
> >
> > - Matt
>
> WoSign/StartCom's re-inclusion request might be a year from now. In
> the meanwhile, those 400 million users will be exposed to MITM. That's why
> I'm bringing it up now, rather than one year later.
> ___
> 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

[谭晓生]

Is there anybody thought about why it happens in China? Why the local browser 
did not block the self-issued certificates?

Thanks，
Xiaosheng Tan



在 2016/10/30 下午1:17，“Percy” 写入:

On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of 
the
> > entire company into question. And such trust, in my view, should be
> > evaluated when WoSign/StartCom submit their re-inclusion requests in the
> > future.
> 
> You can make that argument when WoSign/StartCom's reinclusion discussions
> take place on this list.  Now is not the appropriate time for that.
> 
> - Matt

WoSign/StartCom's re-inclusion request might be a year from now. In the 
meanwhile, those 400 million users will be exposed to MITM. That's why I'm 
bringing it up now, rather than one year later. 
___
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

[Percy]

On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:
> On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> > Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of the
> > entire company into question. And such trust, in my view, should be
> > evaluated when WoSign/StartCom submit their re-inclusion requests in the
> > future.
> 
> You can make that argument when WoSign/StartCom's reinclusion discussions
> take place on this list.  Now is not the appropriate time for that.
> 
> - Matt

WoSign/StartCom's re-inclusion request might be a year from now. In the 
meanwhile, those 400 million users will be exposed to MITM. That's why I'm 
bringing it up now, rather than one year later. 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Matt Palmer]

On Sat, Oct 29, 2016 at 02:59:07PM -0700, Percy wrote:
> Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of the
> entire company into question. And such trust, in my view, should be
> evaluated when WoSign/StartCom submit their re-inclusion requests in the
> future.

You can make that argument when WoSign/StartCom's reinclusion discussions
take place on this list.  Now is not the appropriate time for that.

- Matt

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

Re: StartCom & Qihoo Incidents

[Percy]

Perhaps not. However, Qihoo 360's behavior calls the trustworthiness of the
entire company into question. And such trust, in my view, should be
evaluated when WoSign/StartCom submit their re-inclusion requests in the
future.

Percy Alpha(PGP
)


On Sat, Oct 29, 2016 at 2:38 PM, Peter Bowen  wrote:

> On Sat, Oct 29, 2016 at 2:29 PM, Percy  wrote:
> > So 400 million Chinese users[1] are left vulnerable to MITM by even a
> casual attacker and we cannot do anything about it!?
>
> As stated previously, it is not for one browser to tell another how to
> behave and the CA/Browser Forum explicitly cannot set requirements on
> members for a number of reasons, including anti-trust concerns.
>
> While probably not equivalent, this is not all that different from
> software licensing discussions.  Each author of software can set
> licensing terms as permitted by law; these terms might mean the
> software qualifies as Free/Libre/Open Source Software (FLOSS) or they
> may have requirements that meet other needs.  As I’m sure you are
> aware, there are viewpoints that say that the only ethical stance is
> only FLOSS and there are viewpoints that FLOSS is almost always wrong.
> It is not for Mozilla to say that all browsers must be FLOSS (nor for
> the CAB Forum to say such), even if one could argue that the only
> option for a secure browser is for it to be FLOSS.
>
> Thanks,
> Peter
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Peter Bowen]

On Sat, Oct 29, 2016 at 2:29 PM, Percy  wrote:
> So 400 million Chinese users[1] are left vulnerable to MITM by even a casual 
> attacker and we cannot do anything about it!?

As stated previously, it is not for one browser to tell another how to
behave and the CA/Browser Forum explicitly cannot set requirements on
members for a number of reasons, including anti-trust concerns.

While probably not equivalent, this is not all that different from
software licensing discussions.  Each author of software can set
licensing terms as permitted by law; these terms might mean the
software qualifies as Free/Libre/Open Source Software (FLOSS) or they
may have requirements that meet other needs.  As I’m sure you are
aware, there are viewpoints that say that the only ethical stance is
only FLOSS and there are viewpoints that FLOSS is almost always wrong.
It is not for Mozilla to say that all browsers must be FLOSS (nor for
the CAB Forum to say such), even if one could argue that the only
option for a secure browser is for it to be FLOSS.

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

Re: StartCom & Qihoo Incidents

[Percy]

So 400 million Chinese users[1] are left vulnerable to MITM by even a casual 
attacker and we cannot do anything about it!?



[1]: http://se.360.cn/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Percy]

On Thursday, October 27, 2016 at 5:26:23 PM UTC-7, Erwann Abalea wrote:
> Le jeudi 27 octobre 2016 09:55:09 UTC+2, Percy a écrit :
> > So this is it? Qihoo can continue to get away with this MITM browser?
> 
> I'm afraid that can't be solved by Mozilla. Qihoo is free to sell or freely 
> distribute their browser.

Since I'm not familiar with CAB forum, does CAB forum has authority to compel 
its members to protect its users?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Erwann Abalea]

Le jeudi 27 octobre 2016 09:55:09 UTC+2, Percy a écrit :
> So this is it? Qihoo can continue to get away with this MITM browser?

I'm afraid that can't be solved by Mozilla. Qihoo is free to sell or freely 
distribute their browser.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Percy]

So this is it? Qihoo can continue to get away with this MITM browser?
___
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 Sunday, October 23, 2016 at 7:56:16 AM UTC+3, Peter Bowen wrote:

> is a wholly owned subsidiary of Tianjim Qixin Tongda Technology Co.,
> Ltd. 
> https://www.chinatechnews.com/2016/04/27/23475-qihoo-360s-privatization-approved-by-ndrc

>From the provided link, I am flabbergasted by the reason to go private:

"As a publicly-listed Chinese company in the United States, Qihoo 360 has faced 
the pressures of being a public company. Transparency dogged the company, which 
also has a security software component, and ultimately the company saw the U.S. 
public markets as incompatible with how the company wanted to conduct business."

so apropos...


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

Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Peter Bowen  writes:

>I think you found the "wrong" True Thrive Limited.

Ah, thanks.

>This appears to just be a name collision.  Naming is hard :(

Actually if you think that's tough, try figuring out who the real Midco is...

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

Re: StartCom & Qihoo Incidents

[Peter Bowen]

On Sat, Oct 22, 2016 at 9:08 PM, Peter Gutmann
 wrote:
> popcorn  writes:
>
>>There were comments admonishing StartCom and WoSign for not reporting change
>>of ownership in a timely manner.
>>
>>I am not sure if this has been reported earlier, but if not, then Qihoo 360
>>change of ownership may be relevant to the current discussion:
>>
>>http://www.prnewswire.com/news-releases/qihoo-360-announces-completion-of-merger-300299435.html
>
> If I've followed this complicated trail of breadcrumbs correctly, since Qihoo
> 360 is now "a wholly owned subsidiary of Midco" where Midco is True Thrive
> Limited, then True Thrive is a subsidiary of Greenland Hong Kong Holdings
> Limited:
>
> http://www.bloomberg.com/research/stocks/private/snapshot.asp?privcapId=252817367
>
> which is a subsidiary of Greenland Group:
>
> http://www.greenlandhk.com/pages/en/intro.html
>
> which is the Chinese government (as a state-owned enterprise).

I think you found the "wrong" True Thrive Limited.
https://www.miaxoptions.com/sites/default/files/alert-files/QIHU_Merger_39333.pdf
states that the True Thrive Limited involved in the Qihoo transaction
is a wholly owned subsidiary of Tianjim Qixin Tongda Technology Co.,
Ltd. 
https://www.chinatechnews.com/2016/04/27/23475-qihoo-360s-privatization-approved-by-ndrc
provides information on the buyers, none of whom are Greenland group.

This appears to just be a name collision.  Naming is hard :(

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

Re: StartCom & Qihoo Incidents

[Peter Gutmann]

popcorn  writes:

>There were comments admonishing StartCom and WoSign for not reporting change
>of ownership in a timely manner.
>
>I am not sure if this has been reported earlier, but if not, then Qihoo 360
>change of ownership may be relevant to the current discussion:
>
>http://www.prnewswire.com/news-releases/qihoo-360-announces-completion-of-merger-300299435.html

If I've followed this complicated trail of breadcrumbs correctly, since Qihoo
360 is now "a wholly owned subsidiary of Midco" where Midco is True Thrive
Limited, then True Thrive is a subsidiary of Greenland Hong Kong Holdings
Limited:

http://www.bloomberg.com/research/stocks/private/snapshot.asp?privcapId=252817367

which is a subsidiary of Greenland Group:

http://www.greenlandhk.com/pages/en/intro.html

which is the Chinese government (as a state-owned enterprise).

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

Re: Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

[Jakob Bohm]

On 18/10/2016 20:40, Eric Mill wrote:

The first thing that comes to mind is to define an intermediate
representation of per-root constraints, that Mozilla can distribute
alongside certdata.txt.

The simplest piece would be name constraints, but incorporating things like
CT constraints and date-based constraints would clearly be useful.

I think the tricky part would be deciding which things should go into the
data and which should go into the code. The spectrum could run all the way
from having the data store store all of "one Google and one non-Google log,
where certificates whose length is over X days require Y SCTs, etc." to
something as simple as "apply [the standard for this client] CT policy" and
having clients decide/iterate on what their preferred CT constraint policy
is. (I suspect the right answer is closer to the latter, but I don't manage
a client that performs TLS validation.)



I don't know the format of certdata.txt (since I am not the one who
clones it, or one of its historic formats(!)), but perhaps a simple
solution would be if that file was allowed, for each trust bit, to
specify the "third boolean value": Maybe, aka "X", aka "?".

That would signify, that for that particular trust bit, that there are
additional rules that a cloner need to look up and consider how this
applies to inclusion in his/her particular repository.

There should also be a web page, updated *before* the NSS code, with
those additional rules, as decided by the module owner.

Also there should obviously be a ChangeLog for certdata.txt split into
a "big news" document containing messages such as

"as of version X.Y.Z, the codesigning trust bit is no longer valid, and
roots that are only trusted for code signing have been omitted as if
they were distrusted, even though they might not be, Mozilla just isn't
tracking them anymore (Bugzilla #12345678)"
"As of version X.Y.Z, the trust bits columns in certdata.txt may now
contain the character (whatever) to indicate that trust for that
purpose is limited by a specific rule listed on the web page
https://foo.mozilla.org/bar/baz.  Changes to those rules will be listed
in the certdata ChangeLog even if the certdata.txt line was technically 
not changed (Bugzilla #12345678)"


While the main ChangeLog would also contain more normal changes such as:

"As of version X.Y.Z, WoSign was changed from trusted to maybe in
preparation for full distrust at a future date (Bugzilla #12345678)"
"As of version X.Y.Z, LetsEncrypt was added as trusted for TLS
(Bugzilla #12345678)"
"As of version X.Y.Z, certdata.txt is now encoded in UTF-8, previously
it was in ISO-8859-1 (Bugzilla #12345678)"
"As of version X.Y.Z, Geotrust root ABC was removed, because it is now
only trusted for codesigning, at the request of Symantec, and Mozilla
doesn't track codesigning (Bugzilla #12345678)"

(Of cause all of this would be in a more regular changelog format,
compatible with Mozilla internal procedures, the main point is to
include brief snippets that help downstream stores understand how a
change should be interpreted, with a special highlighting of changes
that affect the downstream import at a conceptual rather than just a
technical level).

Each of my examples above are examples of changes that could (and have
apparently in the past) lead downstream stores astray without that
tidbit of information.

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

Re: StartCom & Qihoo Incidents

[Michael Ströder]

Peter Gutmann wrote:
> Ryan Sleevi  writes:
> 
>> What is the goal of the root program? Should there be a higher bar for
>> removing CAs than adding them? Does trust increase or decrease over time?
> 
> Another thing I'd like to bring up is the absolute silence of the CAB forum
> over all this.  Apple have quietly unilaterally distrusted, Mozilla have
> debated at length (three months now) and are taking action, but the regulatory
> body that should be taking charge, the CAB forum, has (apparently) taken
> absolutely no action.
> 
> Does anyone know the position among other browser vendors, Chrome, IE, Opera,
> Konqueror, Chromium, Midori, the dozen or more forks of various bigger
> browsers, the dozens(?) of mobile browsers, and so on.

Most Linux distributions ship a package like "ca-certificates-mozilla" which
simply copies the Mozilla trusted CA cert set and converts it into several trust
store formats.
So the impact is much broader besides web browsers even affecting e.g. MTA-MTA
SMTP communication.

(Yes, I fully understand that Mozilla refuses to take responsibility for that.)

Ciao, Michael.

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

Re: Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

[Ryan Sleevi]

On Tuesday, October 18, 2016 at 11:42:17 AM UTC-7, Eric Mill wrote:
> I guess there's actually an RFC for something like this?
> https://tools.ietf.org/html/rfc5914 But I haven't looked at it in depth to
> see whether it's a good solution for this problem. I also don't think it
> requires an RFC to get something started.

It's not bad, for sure, but I think both Microsoft and Google's experiences 
with specialized constraints and extensions aren't always fully represented by 
5914. On a purely pragmatic level, it is a real pain to encode those 
constraints - which is an ongoing issue itself with the NSS_TRUST flags and how 
the binary representation of the structure is, is it extensible, etc.

The TL;DR: is that each CA incident has resulted in a special response, always 
with the goal of minimizing user impact relevant to the significance of the 
incident.

But it's doable, if we don't hate ASN.1 too much :)

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

Re: Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

[Eric Mill]

The first thing that comes to mind is to define an intermediate
representation of per-root constraints, that Mozilla can distribute
alongside certdata.txt.

The simplest piece would be name constraints, but incorporating things like
CT constraints and date-based constraints would clearly be useful.

I think the tricky part would be deciding which things should go into the
data and which should go into the code. The spectrum could run all the way
from having the data store store all of "one Google and one non-Google log,
where certificates whose length is over X days require Y SCTs, etc." to
something as simple as "apply [the standard for this client] CT policy" and
having clients decide/iterate on what their preferred CT constraint policy
is. (I suspect the right answer is closer to the latter, but I don't manage
a client that performs TLS validation.)

I guess there's actually an RFC for something like this?
https://tools.ietf.org/html/rfc5914 But I haven't looked at it in depth to
see whether it's a good solution for this problem. I also don't think it
requires an RFC to get something started.

-- Eric

On Tue, Oct 18, 2016 at 2:13 PM, Ryan Hurst  wrote:

> Tom,
>
> On the topic of tooling I have a console tool, and library, that can be
> used to parse and filter various certificate stores, you can find it here:
> https://github.com/PeculiarVentures/tl-create
>
> Ryan
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



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

Re: Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

[Ryan Hurst]

Tom,

On the topic of tooling I have a console tool, and library, that can be used to 
parse and filter various certificate stores, you can find it here: 
https://github.com/PeculiarVentures/tl-create

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

Mozilla Root Store Elsewhere (Was Re: StartCom & Qihoo Incidents)

[Tom Ritter]

On 18 October 2016 at 08:00, Jakob Bohm  wrote:
> On 18/10/2016 14:35, Gervase Markham wrote:
>>
>> On 17/10/16 16:35, Jakob Bohm wrote:
>>>
>>> In the not so distant past, the Mozilla root program was much more
>>> useful due to different behavior:
>>>
>>> 1. Mozilla managed the root program based on an assumption that relying
>>>   parties would use the common standard revocation checking methods
>>>   *only* (regular CRLs as present since Netscape created SSL and OCSP).
>>
>>
>> Now is not the time to re-debate the failings of those methods, but
>> please don't pretend you don't know why this change was made.
>>
>
> I wasn't in this instance, simply noting the following problem: By
> assuming all relying parties run code that implements Mozilla's other
> revocation methods (OneCRL, custom notBefore checks etc.), the root
> list published by Mozilla becomes less useful for relying parties whose
> applications do not.


I'm sympathetic to this - it's unfortunate that we've had to bolt on
certificate validation checks that do not appear in any standardized
form, in any central location, and differ from client to client. It
makes 'the most dangerous code in the world' even harder to get
correct. It seems like more and more of CA/HTTPS related ecosystem
could benefit from an equivalent to caniuse.com

But I'm not sure what Mozilla could do to help downstream users of the
root store? What would make you happier? Projects who blindly import
and trust it will be subject to the default decision Mozilla takes -
sure. (And hopefully they have the prescience to delineate between
default-trust certs and default-don't-trust certs!)

Two things I can see would be:
- Carefully choose the action taken with the root store to be a 'keep
in the root store' choice or a 'remove from the root store' choice.
For example, WoSign would probably be in the 'remove' category and
then FF gets special processing code to accept WoSign under specific
circumstances.
- Have some additional comments or tooling that are designed for
downstream importers. Maybe a script that runs over the official file
converting it to other frmats (Java keystore, directory-of-certs, etc)
and prompts people 'This CA is subject to specific filtering in FF, do
you want to include it in the export?'

Are there other actionable things Mozilla could do to make things
better-by-default for downstream users?

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

Re: StartCom & Qihoo Incidents

[Gervase Markham]

On 18/10/16 06:00, Jakob Bohm wrote:
> Non-https TLS is not (and should not be) a separate trust bit from
> https, but sometimes the logic applicable to trust policies, BRs etc.
> will be slightly different if one doesn't ignore non-https use of TLS.
> I have encountered arguments and policies that are valid only for the
> specific case of up-to-date-web-browser https.

When such arguments occur, please do us the service of pointing them out
:-) While it is true that HTTPS is a very important focus, Mozilla
should care about at least POPS, SMTPS and IMAPS, and other protocols
too. If we are taking actions which are problematic for non-HTTPS TLS,
we should at the very least take them with full knowledge of what those
problems are.

Gerv

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

Re: StartCom & Qihoo Incidents

[Mathias Tausig]

Ryan, can you tell us something about Google's plans concerning WoSign and
StartCom?

cheers
Mathias

On Son, 2016-10-16 at 11:55 -0700, Ryan Sleevi wrote:
> On Saturday, October 15, 2016 at 3:18:22 PM UTC-7, Eric Mill wrote:
> > 
> > On Sat, Oct 15, 2016 at 4:31 AM, Peter Gutmann 
> > wrote:
> > 
> > > 
> > >  The only one who's openly addressed this
> > > seems to be Mozilla.
> > > 
> > It would certainly be nice if Mozilla weren't the only openly operated root
> > program. :)
> > 
> > It seems to put Mozilla in the situation of being the effective first-mover
> > whether they want to be or not, since they're the only entity hosting
> > public discussions about what to do. It certainly felt that way with
> > WorldPay, and Ryan's comments to Kathleen in the other thread about whether
> > Mozilla could be more aggressive with WoSign if they knew they were not
> > going to be saddled with first/only-mover disadvantage seems to point to
> > this dynamic as well.
> To be clear: I don't think the fact that this is happening on
> mozilla.dev.security.policy is enough to suggest that there aren't
> open/transparent programs, or that it's limited to Mozilla's response.
> 
> Imagine a hypothetical world where there were multiple, independently approved
> root programs - that is, that the software vendor retains final choice in
> deciding to include/not include a given certificate. Let's say that these
> programs also adopted the principles that Mozilla has - of having a community
> driven focus, based on feedback and investigation, and an open period for
> review and discussion.
> 
> Would this hypothetical world benefit, or be harmed, if these conversations
> happened on independent lists? My belief is that it would be harmed - that is,
> that having separate root programs operate separate lists would invite all the
> same problems that the Common CA Cert Database (aka Salesforce) is trying to
> solve, by duplicating effort and activity, without providing new or unique
> information.
> 
> Instead, we might conclude that these independently operated programs might
> benefit from having a common, shared community review and discussion, but then
> independently declare their final results - whether to include, remove, or
> otherwise sanction or censure. This would allow involved members of the
> community a central place to discuss, publicly, and share information and
> perspectives, while also avoiding the issues alluded too earlier in the thread
> with respect to the antitrust statements of the CA/B Forum.
> 
> Whether such a shared list has a name like mozilla.dev.security.policy or some
> new email list largely seems irrelevant, and that the status quo, by having a
> large and involved membership, might be more preferable than creating yet
> another list.
> 
> Just a thought ;)
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
-- 
DI Mathias Tausig,
Kompetenzzentrum für IT-Security,

FH Campus Wien,
Informationstechnologien und Telekommunikation.

Favoritenstrasse 226, Raum B.2.18,
1100 Wien, Austria.
T: +43 1 606 68 77-2472, F: +43 1 606 68 77-2139.
mathias.tau...@fh-campuswien.ac.at
PGP Key-ID: 75656BBF

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

Re: StartCom & Qihoo Incidents

[Jakob Bohm]

On 18/10/2016 14:35, Gervase Markham wrote:

On 17/10/16 16:35, Jakob Bohm wrote:

In the not so distant past, the Mozilla root program was much more
useful due to different behavior:

1. Mozilla managed the root program based on an assumption that relying
  parties would use the common standard revocation checking methods
  *only* (regular CRLs as present since Netscape created SSL and OCSP).


Now is not the time to re-debate the failings of those methods, but
please don't pretend you don't know why this change was made.



I wasn't in this instance, simply noting the following problem: By
assuming all relying parties run code that implements Mozilla's other
revocation methods (OneCRL, custom notBefore checks etc.), the root
list published by Mozilla becomes less useful for relying parties whose
applications do not.


2. Mozilla managed trust bits and inclusion policies for https,
  non-https TLS (e.g. imaps, pops and smtps), e-mail S/MIME, and
  generic object/code signing.  Again, this was true since the days
  when this was the Netscape Navigator trust list.


We still do manage for HTTPS and email. There was never a separate trust
bit for non-https TLS; why is the trust and the requirements for that
different in practice from HTTPS TLS?



While Mozilla officially manages trust bits for e-mail, at least one
key participant in these threads repeatedly argues as if this was not
the case.

Non-https TLS is not (and should not be) a separate trust bit from
https, but sometimes the logic applicable to trust policies, BRs etc.
will be slightly different if one doesn't ignore non-https use of TLS.
I have encountered arguments and policies that are valid only for the
specific case of up-to-date-web-browser https.


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

Re: StartCom & Qihoo Incidents

[Jakob Bohm]

On 18/10/2016 01:22, Kurt Roeckx wrote:

On Tue, Oct 18, 2016 at 12:39:42AM +0200, Kurt Roeckx wrote:

On Tue, Oct 18, 2016 at 12:22:21AM +0200, Jakob Bohm wrote:


Over the past few years, this has caused the Mozilla root list to
become less and less useful for the rest of the open source world, a
fact which at least some of the Mozilla-root-list-copying open source
projects seem not to be aware of yet.


I think the problems for the open source community are:
1) There is no good way to deal with revocation checking, it
   doesn't have anything that deals with something like OneCRL
2) Mozilla doesn't care about non-https.


I wanted to add that none of this is relevant to what Ryan was
saying. Maybe the root list itself is becomming less useful, but
that doesn't mean the discussion list is.

Also, the problems for the open source community aren't new it's
just that some of Mozilla's solutions either don't work for them,
they don't know about them, or they don't use it. (It's probably a
combination.)



In the not so distant past, the Mozilla root program was much more
useful due to different behavior:

1. Mozilla managed the root program based on an assumption that relying
  parties would use the common standard revocation checking methods
  *only* (regular CRLs as present since Netscape created SSL and OCSP).

2. Mozilla managed trust bits and inclusion policies for https,
  non-https TLS (e.g. imaps, pops and smtps), e-mail S/MIME, and
  generic object/code signing.  Again, this was true since the days
  when this was the Netscape Navigator trust list.




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

Re: StartCom & Qihoo Incidents

[Kurt Roeckx]

On Tue, Oct 18, 2016 at 12:39:42AM +0200, Kurt Roeckx wrote:
> On Tue, Oct 18, 2016 at 12:22:21AM +0200, Jakob Bohm wrote:
> > 
> > Over the past few years, this has caused the Mozilla root list to
> > become less and less useful for the rest of the open source world, a
> > fact which at least some of the Mozilla-root-list-copying open source
> > projects seem not to be aware of yet.
> 
> I think the problems for the open source community are:
> 1) There is no good way to deal with revocation checking, it
>doesn't have anything that deals with something like OneCRL
> 2) Mozilla doesn't care about non-https.

I wanted to add that none of this is relevant to what Ryan was
saying. Maybe the root list itself is becomming less useful, but
that doesn't mean the discussion list is.

Also, the problems for the open source community aren't new it's
just that some of Mozilla's solutions either don't work for them,
they don't know about them, or they don't use it. (It's probably a
combination.)


Kurt

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

Re: StartCom & Qihoo Incidents

[Jakob Bohm]

On 18/10/2016 00:39, Kurt Roeckx wrote:

On Tue, Oct 18, 2016 at 12:22:21AM +0200, Jakob Bohm wrote:


Over the past few years, this has caused the Mozilla root list to
become less and less useful for the rest of the open source world, a
fact which at least some of the Mozilla-root-list-copying open source
projects seem not to be aware of yet.


I think the problems for the open source community are:
1) There is no good way to deal with revocation checking, it
   doesn't have anything that deals with something like OneCRL
2) Mozilla doesn't care about non-https.

The solution that seems to be prefered for 1) is to have mandatory
OCSP stapling. But I don't see that happening any time soon.



Let me add:

3) Any ad-hoc code added to Mozilla products (e.g. to apply some new
  checking method for WoSign certificates) will not magically appear
  in other code at the same time, if ever.

4) Contrary to what OCSP-stapling fans claim, it is not a panacea, and
  is notably missing in many server side code bases.

5) OneCRL, even if it was checked by other projects, is an arbitrary
  hodgepodge of CA revocations, SubCA revocations and selected end-cert
  revocations, that cannot possibly match the policies of anyone except
  its maintainers.


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

Re: StartCom & Qihoo Incidents

[Gervase Markham]

On 15/10/16 00:32, Peter Gutmann wrote:
> I would have expected some sort of coordinating action to provide a unified
> response to the issue and corresponding unified, consistent behaviour among
> the browsers, rather than the current lottery as to what a particular browser
> (other than Apple and Mozilla's ones) will do when it encounters a WoSign
> cert.

Browsers are capable of coordinating independent of the CAB Forum.
However, some browsers are concerned about doing so (for legal reasons,
I believe) and so the level of coordination is limited.

But actually, I think this is a feature. Root stores are a decision
about who to trust. It is entirely reasonable for different people to
have different views on a person or organization's trustworthiness.

Gerv

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

Re: StartCom & Qihoo Incidents

[Ryan Sleevi]

On Saturday, October 15, 2016 at 3:18:22 PM UTC-7, Eric Mill wrote:
> On Sat, Oct 15, 2016 at 4:31 AM, Peter Gutmann 
> wrote:
> 
> >  The only one who's openly addressed this
> > seems to be Mozilla.
> >
> 
> It would certainly be nice if Mozilla weren't the only openly operated root
> program. :)
> 
> It seems to put Mozilla in the situation of being the effective first-mover
> whether they want to be or not, since they're the only entity hosting
> public discussions about what to do. It certainly felt that way with
> WorldPay, and Ryan's comments to Kathleen in the other thread about whether
> Mozilla could be more aggressive with WoSign if they knew they were not
> going to be saddled with first/only-mover disadvantage seems to point to
> this dynamic as well.

To be clear: I don't think the fact that this is happening on 
mozilla.dev.security.policy is enough to suggest that there aren't 
open/transparent programs, or that it's limited to Mozilla's response.

Imagine a hypothetical world where there were multiple, independently approved 
root programs - that is, that the software vendor retains final choice in 
deciding to include/not include a given certificate. Let's say that these 
programs also adopted the principles that Mozilla has - of having a community 
driven focus, based on feedback and investigation, and an open period for 
review and discussion.

Would this hypothetical world benefit, or be harmed, if these conversations 
happened on independent lists? My belief is that it would be harmed - that is, 
that having separate root programs operate separate lists would invite all the 
same problems that the Common CA Cert Database (aka Salesforce) is trying to 
solve, by duplicating effort and activity, without providing new or unique 
information.

Instead, we might conclude that these independently operated programs might 
benefit from having a common, shared community review and discussion, but then 
independently declare their final results - whether to include, remove, or 
otherwise sanction or censure. This would allow involved members of the 
community a central place to discuss, publicly, and share information and 
perspectives, while also avoiding the issues alluded too earlier in the thread 
with respect to the antitrust statements of the CA/B Forum.

Whether such a shared list has a name like mozilla.dev.security.policy or some 
new email list largely seems irrelevant, and that the status quo, by having a 
large and involved membership, might be more preferable than creating yet 
another list.

Just a thought ;)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Eric Mill]

On Sat, Oct 15, 2016 at 4:31 AM, Peter Gutmann 
wrote:

>  The only one who's openly addressed this
> seems to be Mozilla.
>

It would certainly be nice if Mozilla weren't the only openly operated root
program. :)

It seems to put Mozilla in the situation of being the effective first-mover
whether they want to be or not, since they're the only entity hosting
public discussions about what to do. It certainly felt that way with
WorldPay, and Ryan's comments to Kathleen in the other thread about whether
Mozilla could be more aggressive with WoSign if they knew they were not
going to be saddled with first/only-mover disadvantage seems to point to
this dynamic as well.

-- Eric


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



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

Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Erwann Abalea  writes:

>And that's not CABF's duty and responsibility. What the CABF can impose to
>CABF members is to follow the bylaws, the internal governance rules. By
>following them, all members write the guidelines and decide on what changes
>to adopt, and browsers then impose CAs to follow these guidelines.

Hmm, OK.  I was just wondering why the CABF seemed to be missing in action,
since it appeared to be the logical place to address this sort of issue.

>What appears from the CABF meeting minutes is that the WoSign+StartCom+Qihoo
>combination is looked after, precisely regarding the bylaws.

Hmm, I'm not quite sure what you mean by that, but a quick check of the most
recently published minutes:

https://cabforum.org/2016/09/15/2016-09-15-minutes/
https://cabforum.org/2016/09/29/2016-09-29-minutes/

indicate that not much has happened, there's just a brief comment about
whether { WoSign, Startcom, Qihoo 360 } should be treated as one entity or
three.  I assume that's the bylaw issue?

So there really is no-one running the show, meaning no coordinating body that
can say "bad things are happening over here, you need to take action to deal
with them"?  It just seems odd that the next time a CA goes rogue, every end
user on the planet has to wait for whatever browser vendor they rely on to
make some arbitrary decision on what to do, or as it seems for many vendors in
the case of WoSign, do nothing.  The only one who's openly addressed this
seems to be Mozilla.

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

Re: StartCom & Qihoo Incidents

[Peter Bowen]

On Fri, Oct 14, 2016 at 4:32 PM, Peter Gutmann
 wrote:
> Peter Bowen  writes:
>
>>The CA/Browser Forum is not a regulatory body.  They publish guidelines but
>>do not set requirements nor regulate compliance.
>
> It's a bit hard to describe its actual functioning, in theory they just
> advise, but then so does ISO, IEEE, and others.  They're not regulatory bodies
> either, but when ISO or IEEE says X you do it.
>
>>What action would you expect the Forum to be taking?
>
> I would have expected some sort of coordinating action to provide a unified
> response to the issue and corresponding unified, consistent behaviour among
> the browsers, rather than the current lottery as to what a particular browser
> (other than Apple and Mozilla's ones) will do when it encounters a WoSign
> cert.
>
> Then there's the bigger question that if the CAB can't do anything about a CA
> going rogue (fraudulently issuing certs to evade restrictions), does that mean
> the web PKI is just a free-for-all?  Who's running the show if it's not the
> CAB?

As I wrote to someone else recently, there is no single or common "Web
PKI".  There are numerous PKIs operated by dozens of different
organizations and a number of privately managed trust anchor lists
(Adobe, Apple, Blackberry, Google, Microsoft, Mozilla, Opera, Oracle,
and many others). The contents of each trust anchor list vary and each
list maintainer has their own policies on what CAs they will include
under what circumstances.

The CA/Browser Forum doesn't even legally exist (it isn't an entity)
and you will note the bylaws (https://cabforum.org/bylaws/) have an
anti-trust statement that lays out a number of things not discussed or
coordinated.  Which CAs to accept is not coordinated between trust
anchor list maintainers - they each make their own decisions.

If some neutral organization wanted to publish a trust anchor list
that others could use, great.  Maybe browsers would choose to leave it
up to that org to choose which CAs are trusted.  But that isn't how it
works today.

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

Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Peter Bowen  writes:

>The CA/Browser Forum is not a regulatory body.  They publish guidelines but
>do not set requirements nor regulate compliance.

It's a bit hard to describe its actual functioning, in theory they just
advise, but then so does ISO, IEEE, and others.  They're not regulatory bodies
either, but when ISO or IEEE says X you do it.

>What action would you expect the Forum to be taking?

I would have expected some sort of coordinating action to provide a unified
response to the issue and corresponding unified, consistent behaviour among
the browsers, rather than the current lottery as to what a particular browser
(other than Apple and Mozilla's ones) will do when it encounters a WoSign
cert.

Then there's the bigger question that if the CAB can't do anything about a CA
going rogue (fraudulently issuing certs to evade restrictions), does that mean
the web PKI is just a free-for-all?  Who's running the show if it's not the
CAB?

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

Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Ryan Sleevi  writes:
>On Friday, October 14, 2016 at 3:44:50 PM UTC-7, Peter Gutmann wrote:
>> Another thing I'd like to bring up is the absolute silence of the CAB forum
>> over all this. 
>
>It has not been.

I haven't heard anything from them.  If they've made any statements, they've
been very quiet about it.

>> Apple have quietly unilaterally distrusted, Mozilla have
>> debated at length (three months now) and are taking action, 
>
>mid-August to mid-October is not three months.

August, September, October, seems like three to me.

>[blah blah blah nitpick nitpick nitpick]

Response, response, response, boring boring boring.

Any chance of answering my question?  What's the CAB forum doing? What are
other browser vendors doing?

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

Re: StartCom & Qihoo Incidents

[Ryan Sleevi]

On Friday, October 14, 2016 at 3:44:50 PM UTC-7, Peter Gutmann wrote:
> Another thing I'd like to bring up is the absolute silence of the CAB forum
> over all this. 

It has not been.

> Apple have quietly unilaterally distrusted, Mozilla have
> debated at length (three months now) and are taking action, 

mid-August to mid-October is not three months.

> but the regulatory body that should be taking charge, the CAB forum, 

The CA/B Forum is not a regulatory body.

> has (apparently) taken absolutely no action.

What action is there for the Forum to take, if your description (though 
inaccurate) was accepted?

> Does anyone know the position among other browser vendors, Chrome, IE, 

IE > Edge

> Opera, Konqueror, Chromium, Midori,

You treated three Chromium-based browsers (Opera, Chrome, Chromium) as 
distinct, and referenced two others (Konqueror, Midori) which have yet to 
manage their own root store or policies.

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

Re: StartCom & Qihoo Incidents

[Peter Gutmann]

Ryan Sleevi  writes:

>What is the goal of the root program? Should there be a higher bar for
>removing CAs than adding them? Does trust increase or decrease over time?

Another thing I'd like to bring up is the absolute silence of the CAB forum
over all this.  Apple have quietly unilaterally distrusted, Mozilla have
debated at length (three months now) and are taking action, but the regulatory
body that should be taking charge, the CAB forum, has (apparently) taken
absolutely no action.

Does anyone know the position among other browser vendors, Chrome, IE, Opera,
Konqueror, Chromium, Midori, the dozen or more forks of various bigger
browsers, the dozens(?) of mobile browsers, and so on.

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

Re: StartCom & Qihoo Incidents

[Eddy Nigg]

On 10/14/2016 01:00 PM, Gervase Markham wrote:

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.

I do consider it a significant error of judgement for Eddy to have
chosen www.mozilla.com, rather than a site owned and controlled by him
or by a third party with whom he had an agreement, for his demonstration.


Well, at time I didn't think that much - I noticed it when requesting a 
certificate for startcom.org in order to investigate a completely 
different issue and later got one for mozilla.org (note it wasn't .com). 
Initially I thought about some really high-profile name, but then I 
tried with mozilla.org since I assumed that A) Mozilla will forgive me 
and B) I was frequently involved here at that time. :-)


Surprisingly it worked and I got my certificate for mozilla.org


On the other hand, this happened 8 years ago. I'd be interested in your
comments, Ryan, on whether you think it's appropriate for us to have
some sort of informal "statute of limitations". That is to say, in
earlier messages you were worried about favouring incumbents. But if
there is no such statute, doesn't that disadvantage incumbents? No code
is bug-free, and so a large CA with many products is going to have
occasional troubles over the years. If they then have a larger issue, is
it reasonable to go trawling back 10 years through the archives and pull
out every problem there's ever been? This is a genuine question, not a
rhetorical one.


I believe there is also something called "reasonability " - I believe 
during my tenure StartCom tried to reduce risks first and foremost 
through its policies, honestly and earnest. And then unintentional 
mistakes and issues can happen


Of course every CA wants to issue hundreds of thousands of certificates, 
but it usually doesn't start like this. I admit that some of the issues 
were due to growth pain, scalability or simply doesn't happen below a 
certain number of users/certificates. Any programmer working on larger 
scale projects and long enough in the profession can tell some stories 
about bugs that happen only every 50K or 50M time.


I don't want to offer cheap excuses, but reality has it that things do 
happen and this is also part of that "reasonability". CAs must however 
have policies and procedures in order to evaluate issues that do happen, 
make the correct assessment and deliver a reasonable solution based 
thereof. This is the logic of a correctly functioning CA (or other 
businesses for that matter), this is what auditors verify and what 
software vendors should expect.


There is no business, no software and no certificate authority without 
fault - realistically and reasonably.


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

[Ryan Sleevi]

On Friday, October 14, 2016 at 3:01:16 AM UTC-7, Gervase Markham wrote:
> There are indeed more of these than I remember or knew about. Perhaps it
> would have been sensible to start a StartCom issues list earlier. In my
> defence, investigating one CA takes up a lot of time on its own, let
> alone two :-)

10 minutes with "site:bugzilla.mozilla.org StartCom"

Which was only possible due to the many Mozilla contributors who, when they saw 
something improper, filed bugs. I just want to make sure to thank all of the 
contributors who have done so, and hopefully continue to do so.

> On the other hand, this happened 8 years ago. I'd be interested in your
> comments, Ryan, on whether you think it's appropriate for us to have
> some sort of informal "statute of limitations". That is to say, in
> earlier messages you were worried about favouring incumbents. But if
> there is no such statute, doesn't that disadvantage incumbents? No code
> is bug-free, and so a large CA with many products is going to have
> occasional troubles over the years. If they then have a larger issue, is
> it reasonable to go trawling back 10 years through the archives and pull
> out every problem there's ever been? This is a genuine question, not a
> rhetorical one.

Right, I had the same question when investigating. We know Eddy's position on 
it ('It was in the past, get over it' - if I may so aggressively strawman). I 
suppose a core question is: What is the goal of the root program? Should there 
be a higher bar for removing CAs than adding them? Does trust increase or 
decrease over time?

That is, I can totally see the argument that frequently adding new CAs is bad, 
because new CAs may not have the organizational or operational experience to 
meet the high bar expected of CAs. We frequently see this with addition 
requests - CAs well below what the community standard might be. In this model, 
the more time passes, the more institutional knowledge and expertise the 
organization develops, the better users are protected by keeping CAs in longer 
(and allowing them to remediate).

Another view is that we want a consistent bar, and that means CAs that fall 
short of that should be culled, regardless of age of the CA. This model 
suggests that a longitudinal analysis of a CA's operation is necessary - that 
we must never forget past mistakes when evaluating current mistakes or in 
predicting future mistakes.

We can hopefully assume that CA are rare, at least for an individual CA, and so 
we may never get sufficient samples to accurately predict future behaviour. 
Analyzing a longer period of time gives us data to establish a pattern and 
trend, but also disadvantages those who go through 'growing pains' on their way 
to becoming a mature CA.

I don't have a good answer for your question in the general case, for reasons 
hopefully explained, but I think towards the question of predicting 
responsiveness to incidents, and how they'll be treated, I think the longer 
analysis of StartCom is useful for the discussion. My own gut is that the 
ecosystem is better served if we look at the whole of a CA's operation. My view 
is that the theory that experience is developed over time is one not borne out 
by practice - what we see instead is the same players from existing CAs 
shifting around to different organizations.

> All the WoSign issues I documented where the past two years. Many of the
> StartCom issues you list are 2.5 - 3.5 years old. That may not be long
> enough, but how long is?

Well, the past year it's been run by WoSign, so 2.5 - 3.5 years really reflects 
the past 1.5 to 2.5 years of independent operation, right?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: StartCom & Qihoo Incidents

[Gervase Markham]

On 12/10/16 20:11, 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.

There are indeed more of these than I remember or knew about. Perhaps it
would have been sensible to start a StartCom issues list earlier. In my
defence, investigating one CA takes up a lot of time on its own, let
alone two :-)

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

I do consider it a significant error of judgement for Eddy to have
chosen www.mozilla.com, rather than a site owned and controlled by him
or by a third party with whom he had an agreement, for his demonstration.

On the other hand, this happened 8 years ago. I'd be interested in your
comments, Ryan, on whether you think it's appropriate for us to have
some sort of informal "statute of limitations". That is to say, in
earlier messages you were worried about favouring incumbents. But if
there is no such statute, doesn't that disadvantage incumbents? No code
is bug-free, and so a large CA with many products is going to have
occasional troubles over the years. If they then have a larger issue, is
it reasonable to go trawling back 10 years through the archives and pull
out every problem there's ever been? This is a genuine question, not a
rhetorical one.

All the WoSign issues I documented where the past two years. Many of the
StartCom issues you list are 2.5 - 3.5 years old. That may not be long
enough, but how long is?

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

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: 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: 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: 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: 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, 

Re: StartCom & Qihoo Incidents

[谭晓生]

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 
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 their browser as a critical Windows security update to 
IE users.
> http://wmos.info/archives/7717 / 
http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
> Qihoo displayed a misleading security update for Windows 

Re: StartCom & Qihoo Incidents

[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.
___
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上午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 their browser as a critical Windows security update to IE 
> users.
> http://wmos.info/archives/7717 / 
> http://www.theregister.co.uk/2013/02/01/qihoo_government_warning_fraud/
> Qihoo displayed a misleading security update for Windows users that instead 
> installed their browser.
> 
> Q.C) Qihoo browser actively enables insecure cryptography.
> https://docs.google.com/document/d/1b7lenmn5XO06QohaJzVffnJxjXjY1rD70wg34gfuxRo/edit
> Qihoo's browser is notably insecure with respect to SSL/TLS, with some of the 
> insecure changes requiring active modification to the low-level source 
> libraries that Chromium (of which they're based on) uses.
> 
> Q.E) Qihoo apps removed from app stores due to malware
> https://www.techinasia.com/qihoo-committing-fraud-google-making-huge-mistake 
> / https://www.techinasia.com/qihoo-apps-banned-apple-app-store
> Qihoo Apps have repeatedly been banned from Apple's App Store due to issues
> 
> Q.G) Qihoo "security" apps repeatedly found as unfair competition
> https://www.techinasia.com/qihoo-360-loses-chinas-courts-ordered-pay-sogou-82-million-unfair-competition
> 
> 
> 
> I hope the above show that the odds are if the original StartCom systems are 
> 

Re: StartCom & Qihoo Incidents

[Percy]

I'd also like to point out the Qihoo 360 cheated in all anti-virus tests 
http://www.computerworld.com/article/2917384/malware-vulnerabilities/antivirus-test-labs-call-out-chinese-security-company-as-cheat.html
 When Qihoo was caught out, Qihoo turned it into a market campaign, calling 
AV-C outdated and saying Qihoo's cloud engine is much more advanced and 
announced it quit 
(http://tech.sina.com.cn/i/2015-05-02/doc-icczmvup0903459.shtml article in 
Chinese )
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy