SHA-1 exception First Data

[Nick Lamb]

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.

[Dean Coclin]

 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

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

[Michael Ströder]

Dean Coclin wrote:
> First Data's customers don't use browsers so Firefox can disable SHA-1 tomorrow
> and not affect them.

So why to have your CA certificate trusted in Firefox's cert DB?

> First Data has asked for a reasonable extension which doesn't affect browsers.

If it does not "affect browsers" why do you need an extension?

Ciao, Michael.

[Peter Bowen]

On Wed, Oct 5, 2016 at 10:02 PM, Michael Ströder <mic...@stroeder.com> wrote:
> Dean Coclin wrote:
>> First Data's customers don't use browsers so Firefox can disable SHA-1 tomorrow
>> and not affect them.
>

> So why to have your CA certificate trusted in Firefox's cert DB?
>

>> First Data has asked for a reasonable extension which doesn't affect browsers.
>

> If it does not "affect browsers" why do you need an extension?

The impact on browsers could be broken down into two parts:
1) An expectation they would work with the resulting certificate
2) The risk that someone uses this to create hash collision allowing
them to create a different certificate that is used with browsers.

I think Dean's point is that #1 is not true here. Presumably these
certificates could even be blacklisted by browsers. However #2 is
where the risk lies.

As we have seen with previous requests, the core challenge here is
that many device vendors have chosen to embed a CA trust list in their
devices that is based on the list used by web browsers. From my own
experience, this is something that continues today with consumer
electronics. They take a point in time snapshot of the Mozilla list,
embed it in the device, and expect anyone interacting with the device
to get a certificate from one of those CAs. This inherently sets up a
conflict -- these same device vendors frequently don't release updates
for the devices, so the assumption is that the CAs they choose (which
is usually a unilateral decision) will continue to issue certs
compatible with the device for the lifetime of the device. With the
transition to SHA-256 or better, this has become a challenge.

I think we can all look back with 20/20 hindsight and say that device
vendors should not use the same roots as browsers and that maybe CAs
should have created "SHA-1 forever" roots for devices that never plan
to update, but that is great hindsight. We have the problem now, so we
need an answer.

Thanks,
Peter

[Hanno Böck]

On Wed, 5 Oct 2016 22:46:24 -0700
Peter Bowen <pzb...@gmail.com> wrote:

> I think we can all look back with 20/20 hindsight and say that device
> vendors should not use the same roots as browsers and that maybe CAs
> should have created "SHA-1 forever" roots for devices that never plan
> to update, but that is great hindsight. We have the problem now, so we
> need an answer.

I find that a rather strange conclusion.
Device vendors shouldn't ship devices they never plan to update. If we
can't even agree on that... (after the Brian Krebs incident even more
so)

Also one thing I'd like to point out that I find very strange in this
discussion: The demise of SHA-1 was known since 2004.

Do these financial vendors use products that are older than 2004? Or
have they ignored the issue until 2014 when browser vendors finally
started to indicate some action on the issue?
The First Data request sent to the cabf list indicates that they
started the transition in 2014.

--
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

[Kurt Roeckx]

On Thu, Oct 06, 2016 at 08:22:20AM +0200, Hanno Böck wrote:
> On Wed, 5 Oct 2016 22:46:24 -0700
> Peter Bowen <pzb...@gmail.com> wrote:
>
> > I think we can all look back with 20/20 hindsight and say that device
> > vendors should not use the same roots as browsers and that maybe CAs
> > should have created "SHA-1 forever" roots for devices that never plan
> > to update, but that is great hindsight. We have the problem now, so we
> > need an answer.
>
> I find that a rather strange conclusion.
> Device vendors shouldn't ship devices they never plan to update. If we
> can't even agree on that... (after the Brian Krebs incident even more
> so)
>
> Also one thing I'd like to point out that I find very strange in this
> discussion: The demise of SHA-1 was known since 2004.
>
> Do these financial vendors use products that are older than 2004? Or
> have they ignored the issue until 2014 when browser vendors finally
> started to indicate some action on the issue?

I think everybody ignored this until around 2013.


Kurt

[Jakob Bohm]

Which is why I have repeatedly suggested that maybe the rules should be
changed to promote/demote some of the historic SHA-1 root certs into
"SHA-1 forever" roots that can service older devices and browsers, even
for regular websites concerned about allowing visits from older devices
while transitioning their websites to HTTPS-only.

This should of cause be supplemented by stronger serial number
randomness rules such as at least 100 bits of unpredictable CA-supplied
entropy in the serial number, mandatory numeric high entropy serial
number in the distinguished name, 1 year end certificates issued by 15
month intermediary certs that change quarterly.

The justified comment by someone else that they shouldn't have made
devices then refused to update them is true, but unlike "rent-a-payment-
terminal" financial services (who are big enough to go through
individual applications for CAB/F exceptions), most unupdatable devices
were sold in large numbers to end users in the form of phones, PDAs etc.

Ideally, there should also be a way for TLS servers (such as web
servers) to detect if the TLS client suffers from historic public key
limitations such as SHA-1 only, low maximum DH key size etc., thus
allowing the TLS server to use stronger certificates and FS keys for
new clients.

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

[Gervase Markham]

On 06/10/16 12:38, Jakob Bohm wrote:
> Which is why I have repeatedly suggested that maybe the rules should be
> changed to promote/demote some of the historic SHA-1 root certs into
> "SHA-1 forever" roots that can service older devices and browsers, even
> for regular websites concerned about allowing visits from older devices
> while transitioning their websites to HTTPS-only.

That has effectively happened; those roots have been removed from
current root stores, but if you talk to the right CA you can still get a
cert from one.

> Ideally, there should also be a way for TLS servers (such as web
> servers) to detect if the TLS client suffers from historic public key
> limitations such as SHA-1 only, low maximum DH key size etc., thus
> allowing the TLS server to use stronger certificates and FS keys for
> new clients.

Again, this exists - people use the cipher suite set, or support (or
lack of it) for TLS or TLS 1.2.

Gerv

[Jakob Bohm]

On 06/10/2016 15:58, Gervase Markham wrote:
> On 06/10/16 12:38, Jakob Bohm wrote:
>> Which is why I have repeatedly suggested that maybe the rules should be
>> changed to promote/demote some of the historic SHA-1 root certs into
>> "SHA-1 forever" roots that can service older devices and browsers, even
>> for regular websites concerned about allowing visits from older devices
>> while transitioning their websites to HTTPS-only.
>
> That has effectively happened; those roots have been removed from
> current root stores, but if you talk to the right CA you can still get a
> cert from one.
>

Good, now communicate it.

>> Ideally, there should also be a way for TLS servers (such as web
>> servers) to detect if the TLS client suffers from historic public key
>> limitations such as SHA-1 only, low maximum DH key size etc., thus
>> allowing the TLS server to use stronger certificates and FS keys for
>> new clients.
>
> Again, this exists - people use the cipher suite set, or support (or
> lack of it) for TLS or TLS 1.2.
>

I know, I do that too, but it is quite a wobbly heuristic as there is
no clear set of those to indicate e.g. support for >1024 bit EDH or
>256 bit ECC EDH. Nor do I see a good candidate for indicating >16384
bits RSA (as a future example not yet supported by some SSL clients).

P.S.

I seem to receive 3 copies of your replies, 2 in my inbox and 1 in the
newsgroup.

[Gervase Markham]

On 06/10/16 15:22, Jakob Bohm wrote:
> Good, now communicate it.

Companies should be talking to their CAs, who will offer this service if
they have it.

Gerv

[Gervase Markham]

On 06/10/16 06:46, Peter Bowen wrote:
> I think we can all look back with 20/20 hindsight and say that device
> vendors should not use the same roots as browsers and that maybe CAs
> should have created "SHA-1 forever" roots for devices that never plan
> to update, but that is great hindsight. We have the problem now, so we
> need an answer.

The trouble with this line of argument is that way back at the beginning
of the CAB Forum in the middle of the last decade, we had various
troubles of this sort where CAs said "well, people keep embedding our
roots and then coming to us and expecting certificates, so we can't do
X, Y or Z because otherwise they'll be in trouble" - i.e. exactly the
same problem, and yet here we are in 2016 and it keeps happening. How
can we dissuade people from this idiotic behaviour? It seems like CAs
haven't managed to educate them (if they've even tried). One starts to
think that only if this course of action becomes painful and expensive
rather than grudgingly tolerated will word get around.

Gerv

[Nick Lamb]

So here we are, three months later, First Data are back, as predicted, asking for another "exception".

First Data's original notice seeking the exception asserts that staging
environments for these systems had SHA-256 certificates from November
2014 giving their VARs plenty of time to react.

Actual documents released from First Data's Datawire to their vendors
give a different story, saying that SHA-256 certificates will be on the
staging environment stg.dw.us.fdcnet.biz (which corresponds to a
production service prod.dw.us.fdcnet.biz in the exception request) from
March 9, 2016.

That's 16 months later, and well after the point where Symantec will have
informed First Data that it was no longer possible to issue SHA-1
certificates.

Worse, I have been unable to find any evidence that this change to the
staging environment even went ahead as scheduled. The first SHA-256 certificate
recorded for stg.dw.us.fdcnet.biz is instead dated June, 2016.

https://crt.sh/?serial=71b81e959ac09d6c172e50abf849e3e5

This is 19 months after the claimed date, and their VARs now had only about 3 months left to test and validate new releases against SHA-256 certificates, then ship them as final production systems to all end users.

Symantec forwarded the exception request. Did Dean or his co-workers take a moment to wonder what SHA-256 certificates First Data supposedly had in their staging environment in November 2014, since they were issuing SHA-1 certificates for those very machines just a few months before ?

[Nick Lamb]

By the way Gerv, in your flurry of posts to CA/B Forum public you comment
"If I were going to calculate a SHA-1 collision, the certificate of a
machine handling tens or hundreds of thousands of credit cards a day
would be a reasonably obvious target, ISTM."

This would need a second pre-image attack. No such attack exists nor is thought likely to exist in the foreseeable future for SHA-1.

I think you've misunderstood here (perhaps only momentarily). A collision attack is a very limited sort of attack, not capable of getting much value from any ordinary legitimate issuances. If not for this the whole SHA-1 Exception process would no doubt have been resisted firmly by Google's team who seem to have their fingers very much on the pulse.

Collision only lets you make two documents, A and B, such that when A is signed the resulting signature may be instead fastened to B and appear legitimate. The contents of B may be quite different from A, and the signer of A has no idea what they are. Of course to make use of this you need to get someone to sign document A. The SHA-1 Exception process makes the Subject jump through lots of hoops not merely because it is fun to see fools jump through hoops but because it gives us confidence that they aren't presenting document A for a collision attack.

* We ask to see the entire tbsCertificate before it is signed (the first time around Symantec managed to screw this part up...) which lets us see if it has any suspicious properties, gibberish, unexplained padding, etc.

* We ask for a waiting period, which gives us time to run tools specifically built to look for document A, finding for example weird patterns in the intermediate results inside the hash calculations, and also to go back and ask for a slightly different tbsCertificate, not the one which was originally proposed, thereby destroying the value of any pre-computation done to create document A

* We do the whole laborious process only on request. A real attacker would probably want to try many times, because often they have some statistics on their side if only they can try often enough or spend enough money. Insisting they try only rarely forces up the cost greatly.

* We ask the Issuer (so far invariably Symantec) to produce the actual tbsCertificate based on details from the Subject, this means the only way it can be document A is if the Issuer and Subject collude (or are secretly one and the same) or if the Issuer is incompetent.

* We want to talk to an actual representative of the Subject, and understand what they want this certificate for. A group actually seeking to get document A signed would doubtless want to remain anonymous because it will soon be apparent that they've conducted a swindle.

So long as this hoop jumping continues, the practical risk from each SHA-1 Exception is very low. The problem is, the moral hazard creates the potential for so many exceptions to be requested that people start to wonder about automating it, and without all the hoop jumping the risks become quite serious. Like Uranium 235, SHA-1 is not very dangerous so long as it remains something a handful of careful people are using in small quantities under supervision, rather than something anybody can get for $19.99 by filling out a web form.

[Gervase Markham]

On 16/12/16 17:55, Nick Lamb wrote:
> So here we are, three months later, First Data are back, as predicted, asking for another "exception".

Those reading the CAB Forum list will note that Mozilla has declined to
grant an additional exception.

Gerv