Just as important as browser users are the people who rely on payment terminals to enjoy their daily life. Here, the affected customer states no intent to put these certificates into browser accessible space. They state no business case where the 9 payment gateways are accessible by browsers or that any business case exists on the gateways that uses any client other than the payment terminal.
Their path to avoid disruption to consumers on Sunday is the 9 gateways, not the 10,000+ terminals. Pushing firmware to devices that handle money in a hurry would show very poor security and privacy posture. I don't want yesterday's build in my wallet. If the 9 certificates were issued in December, this conversation wouldn't exist and the certificates would be valid likely into December this year. But a mark on the calendar was crossed when we all agreed this would end. The situation puts people who rely on payment terminals out of service and is claimed to be oversight. The potential for a relying party of the trust in the root store cultivated by Mozilla to be harmed is quite low, there is no browser use case. Contrast that with 10,000 merchants and how many people per day, per hour, are denied card swipes to live their daily lives. Everyone agrees there are significant technical issues with SHA-1 hashes. However, once the certificates are issued, the status of the certificate is not significant even if there are collision blocks in the public key because the serial numbers would differ in the collision pair. Once the certificates exist, the strength of their use depends on server cipher suite configuration. So it comes down to precedent and causing certificate users to take requirements seriously. While I can't speak authoritatively, there appears to be no malicious intent here. The assertion is that many other payment terminals were upgraded on time. So Johnny got a 98 on the exam, but we send him to his room. This isn't a case of an attacker submitting keys with manipulated collision blocks. This is a case of a major business that looks back in horror at a mistake that is about to cost them untold customer relationships. There are four days left to solve this. The customer would have had 10 months to solve this if they caught it in December. The same 9 certificates would exist, the same potential collision surface, and 10 more months of closed community operation. As we look toward barriers, constraints, and performance expectations, I suggest that a compromise that maintains security across this community is to permit careful yet accelerated deployment of SHA256-capable devices to solve this problem at a pace that avoids accidents and oversights that come from haste and could lead to PII exposure. I suggest we shift from prevention to duration, the lifespan of the SHA-1 certificates to be deployed in this case. Kind regards, Steve On Wed, Feb 24, 2016 at 6:24 AM Rob Stradling <[email protected]> wrote: > On 24/02/16 10:20, Peter Gutmann wrote: > > Rob Stradling <[email protected]> writes: > > > >> But if it's an old version of NSS or OpenSSL, then the community could > help > >> find an exploitable bug. > > > > If it's a remote-code-exec we could patch their firmware for them to > support > > SHA-256. Think of it as an undocumented remote admin capability. > > > > (Something like this has been done in the past to fix a commercial > vendor's > > gear). > > True, although engineering and deploying that to 10,000+ terminals > within the next 4 days could be a bit of a challenge! ;-) > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
