The what? RFC5280 does not contain the string "finger".
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
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 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. 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. 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@nanog.org] On Behalf Of Matt Palmer Sent: Wednesday, March 1, 2017 1:34 PM To: nanog@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.