StartCom & Qihoo Incidents

[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 restored, we're likely to continue to have significant BR violations - a pattern StartCom has repeatedly demonstrated over several years. Similarly, if we were to accept trust in Qihoo, then we would be ignoring the precedent Qihoo has set of choosing insecure and anti-user behaviours masked as "security".

[Han Yuwei]

在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：

As a Chinese Internet user, I would say that Qihoo has a very negative reputation on China online community for its precedent's malware(maybe not accurate) and some awful actions such as "3Q Battle", installing software sliently, misleading ads, suspiciously collecting data which is believed helping govnerment monitoring citizens and so on. But on the other hand, their product, "360安全卫士" (360 Total Security)(two names are not the same version but I can't find another english name),as I thought, has improved the total security level of China Internet. And it has changed the ecosystem of Chinese anti-malware software,which I don't know it is good or bad. And it's believed that Qihoo have a tight connection with the Great Fire Wall project.

Since "The Big Brother is Watching you" is not accepted in Mozilla, I thought Qihoo is not trustworthy in operating a CA.

P.S. Anyone who knows to change the font size of google group? As a non-english native speaker it is hard for me to read such a small size in the content.

[Stefan Paletta]

> Similarly, if we were to accept trust in Qihoo, then we would be ignoring the precedent Qihoo has set of choosing insecure and anti-user behaviours masked as "security".

I dare say your cert store will end up as a pretty lonely place if you start investigating CAs –outside the realm of CA per se– and their parent companies for questionable security and shady business.

–Stefan

[谭晓生]

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”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 hanyu...@gmail.com> 写入:

在 2016年10月13日星期四 UTC+8上午3:12:08，Ryan Sleevi写道：

As a Chinese Internet user, I would say that Qihoo has a very negative reputation on China online community for its precedent's malware(maybe not accurate) and some awful actions such as "3Q Battle", installing software sliently, misleading ads, suspiciously collecting data which is believed helping govnerment monitoring citizens and so on. But on the other hand, their product, "360安全卫士" (360 Total Security)(two names are not the same version but I can't find another english name),as I thought, has improved the total security level of China Internet. And it has changed the ecosystem of Chinese anti-malware software,which I don't know it is good or bad. And it's believed that Qihoo have a tight connection with the Great Fire Wall project.

Since "The Big Brother is Watching you" is not accepted in Mozilla, I thought Qihoo is not trustworthy in operating a CA.

P.S. Anyone who knows to change the font size of google group? As a non-english native speaker it is hard for me to read such a small size in the content.

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

[shan...@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.

[yliv...@gmail.com]

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

[yliv...@gmail.com]

Anywany, Qihoo is a SOB company in China.

When I bought my Nokia 5320 in 2010, I installed 360 anti-virus on my Nokia, it got my contacts and made it a text as txt format, I am scared, i never use any of 360 since.

[zjuni...@gmail.com]

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.

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

[谭晓生]

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 &SHA-1), 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 代表 yliv...@gmail.com”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 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:

[谭晓生]

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 代表 shan...@gmail.com”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 shan...@gmail.com> 写入:

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

[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. <http://www.startcom.org>
XMPP: star...@startcom.org <xmpp:star...@startcom.org>

[谭晓生]

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”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 sof...@gmail.com> 写入:

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:

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

[Han Yuwei]

在 2016年10月13日星期四 UTC+8上午10:58:34，谭晓生写道：

Maybe my English is not good enough so you may mistaken my meaning. What I said is pointing out there may be a connection between Qihoo and GFW project. There's a lot of reports saying that 360 has reported their Shadowsocks/VPN server IP address and their server got banned. I am not supporting these reports and just tell everyone there are something about this. I do appericate what you and your team done to the security of China Internet. And personlly I am supporting survillance over Internet for public security. But when it comes to CA, I think Qihoo is not enough to operate a CA due to the security flaws and attitude shown at 360 Secure Browser and Greb may remember that.

[Han Yuwei]

在 2016年10月13日星期四 UTC+8下午2:01:19，yliv...@gmail.com写道：

They have improved the security of China Internet, OK? It seems like somebody regard offical security staffs as devils who help government to restrict China Internet. This kind of discrimination will DESTORY the China Internet.

[谭晓生]

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”<dev-security-policy-bounces+tanxiaosheng=360...@lists.mozilla.org 代表 sof...@gmail.com> 写入:

[hand...@gmail.com]

360 和 周鸿祎 都是无耻的。

[gala...@gmail.com]

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:

[amelyee]

Qihoo was considered the one behind the malware wirelurker on ios and OS X.
https://www.zhihu.com/question/26544641

[popcorn]

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

[Jakob Bohm]

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.

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

[nessun...@gmail.com]

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"

[Ryan Sleevi]

On Thursday, October 13, 2016 at 2:03:05 AM UTC-7, Eddy Nigg wrote:
> 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....

As usual, you seem to be dismissive of any concerns about StartCom's compliance.

At core issue is whether StartCom is a trustworthy organization, if operated independently. Key to that is the ability of StartCom to abide by the Baseline Requirements and to treat the incidents as serious and warranting attention. Your reply, though unclear in what capacity you continue to represent StartCom, highlights the traditional dismissiveness - both of the message and the messenger - and the attempt to reply to incidents with "Somebody else did this".

If we are to accept that WoSign's past actions are not predictive of StartCom's future, then we must accept that Startcom's past actions are - and the past actions show a pattern of disregard. Whether or not others show that similar disregard is, to some extent, immaterial to the question as to whether StartCom was competently operated, is competently operated, and will be competently operated.

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

Isn't this the same response WoSign made? Isn't the fact that there is a pattern of misissuances - and dismissiveness - material to the claim as to whether StartCom ever was, or is, trustworthy?

> You make this appear as if StartCom used its capacity as a certificate
> authority to somehow abuse somebody or something,

I didn't - and the linked bug doesn't suggest that either.

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

The ability to responsibly handle security incidents in the past is relevant to the ability to responsibly handle security incidents in the future.

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

For those that do investigate into the linked bugs, I suspect they will likely reach a conclusion that you and StartCom have routinely underestimated significance, downplayed seriousness, and not always acted reasonably. Similarly, with respect to elements such as duplicate serial numbers or OCSP responders, patterns of behaviour which have short- and long-term negative effects on the WebPKI are routinely missed for deadlines and remediation.

This naturally argues for a conclusion that, for the set of outstanding issues to be remediated in response to the WoSign acquisition of StartCom, that StartCom may miss deadlines for remediation.

To some extent, this may be moot due to Kathleen's proposal, but I don't think your assertions should remain unchallenged while people mull and evaluate whether or not it's appropriate to treat StartCom as the WoSign subsidiary that it was and currently is.

[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

[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

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

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

[Peter Gutmann]

Ryan Sleevi <ry...@sleevi.com> 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.

[Peter Bowen]

On Fri, Oct 14, 2016 at 3:44 PM, Peter Gutmann
<pgu...@cs.auckland.ac.nz> wrote:
> Ryan Sleevi <ry...@sleevi.com> 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.

The CA/Browser Forum is not a regulatory body. They publish
guidelines but do not set requirements nor regulate compliance. The
Forum does not require that members follow the Forum guidelines; it
only requires that they are either a browser or CA operator following
the basic WebTrust requirements or ETSI requirements.

What action would you expect the Forum to be taking?

Thanks,
Peter

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

[Peter Gutmann]

Ryan Sleevi <ry...@sleevi.com> 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.

[Peter Gutmann]

Peter Bowen <pzb...@gmail.com> 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.

[Peter Bowen]

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

[Erwann Abalea]

Le samedi 15 octobre 2016 01:33:05 UTC+2, Peter Gutmann a écrit :
> Peter Bowen <pzb...@gmail.com> 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.

Not that hard in fact.
ISO/IEEE/ETSI/CABF write guidelines and recommendations, which you're free to follow or not.
A regulatory body says: you must follow recommendation X and Y or Z from ISO/IEEE/... to be part of my club.

Here, browser vendors are regulatory bodies, and take a suitable combination of ETSI+WebTrust+CABF recos that CAs are required to follow.

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

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.

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

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

Browsers.

[Peter Gutmann]

Erwann Abalea <eab...@gmail.com> 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.

[Eric Mill]

On Sat, Oct 15, 2016 at 4:31 AM, Peter Gutmann <pgu...@cs.auckland.ac.nz>
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-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
konklone.com | @konklone <https://twitter.com/konklone>

[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 <pgu...@cs.auckland.ac.nz>
> 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 ;)

[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

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

[Jakob Bohm]

Unfortunately this line of thinking is hugely contradicted by some key
people on this mailing list repeatedly insisting on ignoring any
consequences outside the limited scope of the next release of Firefox.

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.

[Kurt Roeckx]

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.


Kurt

[Jakob Bohm]

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.

[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

[Jakob Bohm]

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.

[Gervase Markham]

On 17/10/16 16:08, Jakob Bohm wrote:
> 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.

Once fully deployed (soon), it will be all CA revocations, all
intermediate revocations, and selected high-profile end-entity cert
revocations. That is the design goal, and we are working towards it.

Gerv

[Gervase Markham]

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.

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

Gerv

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

[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 <pgu...@cs.auckland.ac.nz>
> > 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.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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...@fh-campuswien.ac.at
PGP Key-ID: 75656BBF

[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

[Michael Ströder]

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.

[Peter Gutmann]

popcorn <nessun...@gmail.com> 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.

[Peter Bowen]

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

[Peter Gutmann]

Peter Bowen <pzb...@gmail.com> 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.

[nessun...@gmail.com]

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

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

[Ryan Sleevi]

On Friday, October 28, 2016 at 11:06:26 AM UTC-7, Percy wrote:
> Since I'm not familiar with CAB forum, does CAB forum has authority to compel its members to protect its users?

No. The CA/Browser Forum is just a discussion group between CAs and Browsers to collaboratively develop a set of guidelines relevant to certificates, largely in order to reduce the odds of conflicts among various root store requirements, and to ensure there is a venue for discussing industry-wide concerns.

It is not a legal entity. The bylaws are accepting of anyone who meets membership criteria (which means, conversely, there is not the ability to expel organizations), and the Forum itself has very strict rules regarding its activities to avoid Antitrust concerns (as per the Bylaws)

[Peter Bowen]

On Sat, Oct 29, 2016 at 2:29 PM, Percy <percy...@gmail.com> 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

[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

[谭晓生]

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”<percy...@gmail.com> 写入:

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.

[Peter Gutmann]

Percy <percy...@gmail.com> 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.

[Han Yuwei]

在 2016年10月30日星期日 UTC+8下午2:37:12，谭晓生写道：

I am listening.

[谭晓生]

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 <percy...@gmail.com>
日期: 2016年10月30日 星期日 下午4:01
至: 晓生 谭 <tanxia...@360.cn>
抄送: "mozilla-dev-s...@lists.mozilla.org" <mozilla-dev-s...@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&search=0xF30D100F7FE124AE>)

On Sat, Oct 29, 2016 at 11:36 PM, 谭晓生 <tanxia...@360.cn<mailto:tanxia...@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”<percy...@gmail.com<mailto:percy...@gmail.com>> 写入:

On Saturday, October 29, 2016 at 5:54:10 PM UTC-7, Matt Palmer wrote:

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-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[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

[Han Yuwei]

在 2016年10月30日星期日 UTC+8下午8:40:37，谭晓生写道：

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?

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

> 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