SHA1 collisions proven possisble

Wed Mar 1 21:28:23 UTC 2017

> The what?  RFC5280 does not contain the string "finger".

The fingerprint (or thumbprint) is the hash (sha1/sha256) of the certificate
data in DER format, it's not part of the actual certificate. The fingerprint
is largely used in the security and development community in order to
quickly identify a unique certificate. Application developers (See: Google,
Microsoft, Apple, etc) also hard-code fingerprints into applications to
defend against anyone attempting to MITM the traffic (for obscurity or
security purposes). 

Fingerprints are used instead of serial numbers since two CAs can issue two
certificates with the same serial number. It's also the fastest way to
determine the identity of a certificate without examining individual data in
certificates. 

> The CA doesn't "change" the serial number (a CSR doesn't have a place to
even ask for a serial), they pick one, and while it's *supposed* to be at
least partially random, given the largely appalling state of CA operations
(and, even worse, the competence of the auditors who are supposed to be
making sure they're doing the right thing), I'd be awfully surprised if
there wasn't at least one CA in a commonly-used trust store which was
issuing certificates with predictable serial numbers.

Predictable serial numbers still wouldn't help you here and certificates
contain multiple unique identifiers. There's a massive brute force component
to this attack as well, both the "good" and "bad" certificate would have to
be brute forced. Let's also remember the ONLY example of this so far is PDF
documents where massive amounts of data can be hidden in order to manipulate
the hashes. This isn't the case with certificates. 

On the subject of the example documents. The example documents given are
unbelievably basic in their differing appearances and the attack is _easily_
detected.  

> Except all the ones that the payment industry (there's a group with no
stake in good security, huh?) have managed to convince browsers to allow
(thankfully, they get a good counter-cryptanalysis over them first), and all
the ones that have been issued "by mistake" to inconsequential organizations
like, say, HMRC (which just appear in CT logs, and the vigilance of the
community finds and brings to the attention of trust stores).

Again, this attack doesn't work on any existing arbitrary item and is easily
detected. So any existing item is safe until a preimage attack is found. 

The sky is not falling. The most this will affect is generation of unique
identifiers (which is not security related) using the SHA1 algorithm. This
has already been seen when trying to commit both of the example PDF
documents to a git repository. 

This whole situation is being blown way out of proportion and significantly
oversimplified. This is a PR stunt by Google to keep to their timeline from
when they cried the sky was falling years ago about SHA1
(https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html). 

Nine quintillion (9,223,372,036,854,775,808) SHA1 computations in total
6,500 years of CPU computation to complete the attack first phase =
56,940,000 hours CPU time
110 years of GPU computation to complete the second phase = 963,600 hours
GPU time

Those statistics are nowhere near real world for ROI. You'd have to invest
at least 7 figures (USD) in resources. So the return must be millions of
dollars before anyone can detect the attack. Except, it's already
detectable. 

Google nullified their point of demonstrating the attack by showing it was
easily detectable.

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Matt Palmer
Sent: Wednesday, March 1, 2017 1:34 PM
To: nanog at nanog.org
Subject: Re: SHA1 collisions proven possisble

On Tue, Feb 28, 2017 at 01:16:23PM -0600, James DeVincentis via NANOG wrote:
> The CA signing the cert actually changes the fingerprint

The what?  RFC5280 does not contain the string "finger".

> (and serial number, which is what is checked on revocation lists)

The CA doesn't "change" the serial number (a CSR doesn't have a place to
even ask for a serial), they pick one, and while it's *supposed* to be at
least partially random, given the largely appalling state of CA operations
(and, even worse, the competence of the auditors who are supposed to be
making sure they're doing the right thing), I'd be awfully surprised if
there wasn't at least one CA in a commonly-used trust store which was
issuing certificates with predictable serial numbers.

> Beyond that, SHA1 signing of certificates has long been deprecated and 
> no new public CAs will sign a CSR and cert with SHA1.

Except all the ones that the payment industry (there's a group with no stake
in good security, huh?) have managed to convince browsers to allow
(thankfully, they get a good counter-cryptanalysis over them first), and all
the ones that have been issued "by mistake" to inconsequential organisations
like, say, HMRC (which just appear in CT logs, and the vigilance of the
community finds and brings to the attention of trust stores).

- Matt

--
<Igloo> I remember going to my first tutorial in room 404. I was most upset
when I found it.