Re: WoSign and StartCom
On 30/09/2016 13:21, Gervase Markham wrote: On 30/09/16 07:50, Jakob Bohm wrote: SHA-1 certs until the hardware dies. On a trust policy/BR level, the key detail here is that the issuing root cert is a SHA-1 cert itself and would thus be distrusted by SHA-1-distrusting systems anyway. That's not so; I believe most (all?) systems don't check the signatures on their own embedded root certificates, because they are implicitly trusted. There are many roots in the Mozilla program with SHA-1 signatures; see the Signature Hash Algorithm column in: https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport In fact, there are two with MD5 signatures, although as it happens they are only trusted for email. Gerv Well, at least the intermediaries involved would be SHA-1 and be checked against the SHA-1-distrust policy? 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: WoSign and StartCom: next steps
* Hanno Böck: > Minor sidenote: there have been some concerns about TLS security > vulnerabilities of the qihoo 360 browser [1] [2]. While this is not > directly related to the operation of a CA, it surely would increase the > community's trust of qihoo 360 if these issues get resolved quickly. > > > [1] https://cabforum.org/pipermail/public/2015-April/005441.html > [2] https://twitter.com/ryancdotorg/status/780470538686697472 It is certainly possible to implement access to servers using untrusted X.509 certificates in such a way that security is compromised only after further user action (e.g. supplying login credentials, despite the browser warning). A reasonable approximation of such a secure implementation is to visit the site with a fresh Firefox profile, and override the certificate warning. More care is needed to check the origin of the cookie which, according to Tom Ritter's post, the browser transmitted without further user interaction. It might be the case that the cookie is not marked as secure (restricting it to HTTPS), or it may have been created as a secure cookie over an untrusted HTTPS connection. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom: next steps
Hi, I just want to throw out some thoughts and I hope the people involved find it noteworthy. Please note that I am in no way in a position to decide anything here, I'm just someone who happens to have an opinion on the stuff going on. This seems to be some last minute attempt to rescue wosign/startcom as a CA. Despite all the stuff that happend I kinda sympathize with it, for two reasons: * I think wosign and startcom did a lot of good for the web by providing free certificate options and I think it'd be problematic to have a Let's Encrypt monopoly for free certificates. * I fear that if wosign gets removed that this might lead to a further separation of the chinese web. I don't want to see a situation where chinese webpages use a chinese certificate that the browsers from the rest of the world don't accept. I don't think this is in anyone's interest, as it would harm the Internet as a whole. I guess the community could agree to let wosign stay in the browsers, but it must be clear that there is a sincere will to handle things differently in the future. My advice to the representatives of wosign/startcom/quihoo would be to be as transparent as possible. I think the major reason people find this mozilla research so damning is because it looks a lot like you were trying to hide things. This was further fuelled by multiple statements in the form "we don't have to talk about this". If you want to regain trust from the community you'll have to talk about it. This isn't about any legal requirements, it's about trust from the community. Be open about who owns which company, who's in charge and also tell us exactly why these things happened in the past and how you want to prevent them from happening again. Minor sidenote: there have been some concerns about TLS security vulnerabilities of the qihoo 360 browser [1] [2]. While this is not directly related to the operation of a CA, it surely would increase the community's trust of qihoo 360 if these issues get resolved quickly. [1] https://cabforum.org/pipermail/public/2015-April/005441.html [2] https://twitter.com/ryancdotorg/status/780470538686697472 -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 pgppRcHcrXVwf.pgp Description: OpenPGP digital signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom: next steps
On 29/09/16 18:12, Han Yuwei wrote: > Could you disclosure what would you talk about or would be determined > on the meeting? And would there be a video or transcript about your > meeting? We don't plan to make a video or release a transcript, but Mozilla will also not be finalising any plans for action at the meeting either. From our perspective, the aim is to discuss whatever plans Qihoo/StartCom/WoSign have to improve the situation and help them understand what is most likely to be acceptable to us and to the community. Then they will go away and, hopefully fairly soon afterwards, make a public proposal for what they are going to do. That will be discussed here, and after the discussion, the Mozilla module owner (who takes the final decision) will decide whether we will continue to execute our proposed plan exactly as it stands, or modify it in the light of any new information or undertakings provided. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom
On 30/09/16 07:50, Jakob Bohm wrote: > SHA-1 certs until the hardware dies. On a trust policy/BR level, the > key detail here is that the issuing root cert is a SHA-1 cert itself > and would thus be distrusted by SHA-1-distrusting systems anyway. That's not so; I believe most (all?) systems don't check the signatures on their own embedded root certificates, because they are implicitly trusted. There are many roots in the Mozilla program with SHA-1 signatures; see the Signature Hash Algorithm column in: https://mozillacaprogram.secure.force.com/CA/IncludedCACertificateReport In fact, there are two with MD5 signatures, although as it happens they are only trusted for email. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom: next steps
On 30/09/16 03:14, 谭晓生 wrote: > So far 360 is just an investor of Wosign, but we think we need to do > something because of what happened. > I’d like to have suggestions from Gev to see if Richard Wang to join the > meeting is a better proposal. Hi Xiaosheng, I think it is a decision for Qihoo 360, WoSign and StartCom together to decide who represents them. I'm confident that the three companies will send representatives to the meeting who have the authority to discuss and then publicly propose a remediation plan that we can consider, and ensure that whatever is agreed is carried out. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
New categories on Mozilla security blog
At the suggestion of an m.d.s.policy reader, I've gone through the Mozilla security blog and added two new categories to the appropriate posts. Those categories are "CA Program": https://blog.mozilla.org/security/category/ca-program/ and "TLS": https://blog.mozilla.org/security/category/tls/ Those links might be useful for people wanting to track only what Mozilla is doing on one or both of those subjects, although the entire security blog remains a good read :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom
On 27/09/2016 21:02, Erwann Abalea wrote: Bonsoir, Le mardi 27 septembre 2016 18:43:29 UTC+2, Han Yuwei a écrit : 在 2016年9月27日星期二 UTC+8下午11:21:26，Hector Martin "marcan"写道： On 2016-09-27 23:21, Han Yuwei wrote: 在 2016年9月27日星期二 UTC+8下午8:33:28，Gervase Markham写道： On 27/09/16 13:13, adroidm...@gmail.com wrote: We must use Windows XP becuase some programs can only run on XP. We have no money to get new programs and new Windows. Do you give $$$￥￥￥ to me??? You don't right? So please understand why we use XP. Windows XP SP3 supports SHA-256. And of course, you always have the option of Linux, which is a free modern operating system. Gerv There are a lot of software whose company is already down running at factoies, critical public infrastructures even hospital. We can't take the risk to upgrade the operating system. But I am not supporting continous using of SHA1 certificates. Maybe you can understand this. :) *Not* upgrading the operating system is a security risk. If you need to interact with certificates, your computer is networked. If your computer is networked, you absolutely cannot afford *not* to keep it up to date and using a supported operating system. Anything else is asking to get compromised, and then certificates are going to be the least of your worries. The "install it once and don't touch it" mentality stops working the moment there's an Ethernet port with a cable connected to it. I would hope networked equipment at critical public infrastructure like a hospital is using a supported, updated operating system and software. -- Hector Martin "marcan" (mar...@marcan.st) Public Key: https://mrcn.st/pub Yes, I totally agree with you.But some software can't work under newer system. Maybe we can find a solution towards this. There are 2 solutions for this problem: 1/ a temporary one, where the certificate subscriber can demonstrate that it its relying parties can't accept SHA2 today but will be upgraded before the end of 2016. The procedure to get a SHA1 certificate is a public review with extended checks, it takes about 2 weeks to get the approval if nothing risky is found. It's the "SHA1 Exceptions process" described in the extensive report written by Gerv. WoSign and StartCom have chosen to not follow it, and to hide their actions. 2/ a permanent one, where it's really not possible to upgrade the relying parties' systems to accept SHA2, or the subscriber is not willing to do the effort. The SHA1 certificate is issued by a non public CA, and this non public CA is explicitly imported as trusted in the necessary relying parties' systems. There is no other alternative. Note that in my daily work, I am aware of at least one system where neither option is particularly viable, due to the platform vendor locking down the system and then abandoning the signing services that would usually authorize CA certificate imports. This leaves the system in question with a "set in stone" list of trusted (SHA-1) CAs. Thus to cater to those systems (especially when the actual devices are 3rd party owned), the only practical solution would be for one of the relevant old SHA-1 root CA certs to issue (via intermediaries etc.) new SHA-1 certs until the hardware dies. On a trust policy/BR level, the key detail here is that the issuing root cert is a SHA-1 cert itself and would thus be distrusted by SHA-1-distrusting systems anyway. 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
