Nick,
First Data's customers don't use browsers so Firefox can disable SHA-1 tomorrow and not affect them.

Remember, many of these "customers" are small businesses or non-profits. I think about places like a private school or church that whip out the terminal when it's time for the festival or auction and then put it back in the drawer till next year. Most don't even know who First Data is (because they are serviced by thousands of VARs).
Also, in many of these payment processor cases, the terminals don't belong to the processor. They are brought in by the business, much like any telephone is plugged into the PSTN. They are supposed to support it.
First Data has asked for a reasonable extension which doesn't affect browsers. There will be no further extensions beyond that and they totally understand.
Thanks,
Dean Coclin
Symantec
 
 
On 10/05/16, Nick Lamb<tialara...@gmail.com> wrote:
 
We had a thread about the TSYS application but not for First Data.

Unlike with TSYS I don't see anything here that leaps out as problematic in the to-be-signed certificates but I do think the moral hazard problem is larger here than with TSYS and anyway bears revisiting.

First Data say they told their customers about a fixed deadline at the end of June. Many customers ignored/ missed this deadline, so First Data announced a new one, large numbers of customers (300 000 or 25%) also missed this deadline. First Data want new SHA-1 certificates in order to continue servicing these customers anyway.

I haven't much confidence that First Data's customers will be upgraded for the new deadline implied by the SHA-1 exception. That means we're going to be here again in 2017, and also we're going to hear that Firefox can't disable SHA-1 because it will break all these "temporary" exceptions.

I looked at the public communications from First Data (e.g. from 12 months ago) and I was disappointed. These are not effective calls to action. Every First Data customer who got these communications should have come away understanding if they needed to do anything, and if so with a clear idea what they could do. Instead these messages are vague, and mostly try to push all the work onto VARs, even though First Data admits their customers may not know who their VAR is, if they even have one. First Data sites today don't put this _vital_ information about SHA-1 deprecation front and centre, there's no sign anything is wrong at all unless you look for it.

The communications also load all the onus to act onto customers who are worst affected, a customer with a serious problem is expected to reach out to a specific contact point, receive new documentation, act on the documentation and so on. This is the opposite way around from an approach that's actually going to succeed. _First Data was within its rights to act this way, but shouldn't feign surprise that instead many customers did nothing_.


"FD believes that these businesses, which by their nature are not technically sophisticated, should not be put to experience an extended business disruption that would result from the inability to extend SHA-1 certificates for the period requested."

They're First Data's customers, not ours. First Data made all the bad decisions that lead here, not us. This "guilt" approach isn't good, and I don't want to keep seeing this from SHA-1 exception applicants. If First Data really believes it's important that their customers shouldn't be disrupted, the work to be done lay with First Data, not with everybody else who managed their transition properly in plenty of time.
_______________________________________________
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

Reply via email to