On Thu, 25 Feb 2016 09:13:42 -1000 Brian Smith <[email protected]> wrote:
> Gervase Markham <[email protected]> wrote: > > > On 23/02/16 18:57, Gervase Markham wrote: > > > Mozilla and other browsers have been approached by Worldpay, a > > > large payment processor, via Symantec, their CA. They have been > > > transitioning to SHA-2 but due to an oversight have failed to do > > > so in time for a portion of their infrastructure, and failed to > > > renew some SHA-1 server certificates before the issuance deadline > > > of 31st December 2015. > > > > In relation to this issue, we just published a blog post: > > > > https://blog.mozilla.org/security/2016/02/24/payment-processors-still-using-weak-crypto/ > > > This is all very disappointing. Effectively, Mozilla is punishing, > economically, all of WorldPay's and Symantec's competitors who spent > real money and/or turned down money in an effort to comply with > Mozilla's guidance on SHA-1. Meanwhile, no doubt Symantec receives a > hefty fee in return for issuing these certificates. Thus, Mozilla has > effectively reversed the economic incentives for CAs so that it is > profitable to go against Mozilla's initiatives to improve web > security. And, in the course of doing so, Mozilla has damaged its own > credibility and reduced leverage in enforcing its CA policies going > forward. Very well said. Thank you for chiming in, Brian. > Even worse, Firefox still hasn't been changed to block SHA-1 > certificates that chain to publicly-trusted CAs with a notBefore date > after 2016-01-01. After I left Mozilla, I continued to work on > mozilla::pkix in part to make it easy for Mozilla to implement such > blocking, specifically, so I know as well as anybody that it is easy > to do. If such blocking were implemented then Firefox users wouldn't > even be affected by the above-mentioned certificates. Unfortunately, this is not the case, since the attacker can forge the notBefore date and bypass the check. You can see this with the rogue MD5 certificate: https://www.win.tue.nl/hashclash/rogue-ca/ The certificate issued by the CA had a notBefore date of 2008-11-03. The rogue certificate had an intentionally-chosen notBefore date of 2004-07-31. Firefox users are affected by the collision risk during issuance (not to mention the horrible signaling that this exception sends). The only surefire way to be safe from hash collisions is to stop issuing certificates with the weak algorithm, and for clients to stop accepting certificates signed by the weak algorithm. Disclosure, revocation, and validity period restrictions don't help. That said, I'm all for visual warnings based on validity dates as a way to educate site operators and encourage migration to SHA-2 so that browsers can get to the point where they can fully disable SHA-1. Regards, Andrew _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
