4

There was a recent question about trusting (or not) a website showing an SHA-1 certificate. I would like to know whether I understand the actual issue correctly.

The dangers are (a) that someone manages to redirect me to a different site, produces a fake certificate, and as a result I get a totally secure connection to a website run by evil hackers. And (b) that I connect to the site I want to connect to, but evil hackers decode what I send and receive.

Is it correct that hackers could at a huge but not impossible cost create a fake SHA-1 certificate for some small website, and at the same cost create a fake SHA-1 certificate for www.amazon.com? Since they would redirect me to their site, the security of the actual website would be completely irrelevant. That small website, and amazon's website, could have unbreakable security, which doesn't help since I never actually manage to contact them. In other words, if I see an SHA-1 certificate for Amazon, then it is most likely fake.

On the other hand, if that small website, or www.amazon.com, genuinely used an SHA-1 certificate, would that make it easier to decrypt the messages that I exchange with the site? Could a hacker somehow "break" the certificates and then easily decrypt all messages exchanged with amazon? Or is the communication just as safely encrypted independent of the certificate?

Thanks, Gordon, for answering the question: So using a low quality certificate on your site doesn't make your site any less secure. The problem is indirect: Low quality certificates could be forged, therefore browsers (and users) should reject low quality certificates, but as long as many sites use low quality certificates, browsers can't do that.

7

The real security risk of using SHA-1 (or MD5) certificates is indirect, and therefore easy to miss. The problem isn't the security of the server's real certificate, it's the client policy that allows the client to trust low-security certificates. Consider two scenarios here (and I'll use MD5, because it's already been proven inadequate):

  • A client connects to your server, the server presents an MD5-signed cert, the client receives your certificate (i.e. if there's an attack going on, it's one that lets your real cert through to the client), and (for some reason) the client accepts it. This connection is secure. The only thing the signature is needed for is to verify that the client received the your certificate, and since it did... all is fine.

    In this case, the security level of the signature on your cert is irrelevant.

  • A client attempts to connect to your server, but sort of interception/MITM/impersonation attack takes place that substitutes a different (impostor) certificate. The signature algorithm on the impostor cert does not need to match your real cert; you could have an SHA-2-signed cert, and the impostor could present an MD5-signed cert instead, and the client wouldn't be able to tell it wasn't seeing your real cert.

    Again, the security level of the signature on your (real) cert is irrelevant. And there's no way for the client to tell the difference between the two cases.

So the signing algorithm on your cert is irrelevant, right? Not exactly. What really matters is what the client will accept as a valid cert. If the client will accept MD5-signed certs, the client will be vulnerable to impostor certs. Similarly, if the client will accept SHA-1 certs without throwing a hissy fit, it'll become vulnerable sometime in the future (maybe soon?) when forging SHA-1 certs becomes practical. To prevent this vulnerability, clients (mostly browsers) are gradually being updated with stricter cert validation requirements.

But the client cert requirements can't practically be upgraded until all/most server certs are upgraded, otherwise the clients will be throwing warnings/reject errors/etc all over, and we'll be in the position of teaching users to bypass/ignore security warnings, which is a very bad thing to teach them.

And that's the real problem with SHA-1 certificates: they require clients to have low security expectations in order to connect to your server. And not just for your specific server; they also they have an indirect effect on the security of the web (and TLS infrastructure) as a whole, because they make it hard for clients (both software and users) from having high expectations about security and trust.

If you still use SHA-1 certificates at this point, you're holding back the overall security of the internet.

  • 1
    The signature algorithm on the impostor cert does not need to match your real cert; you could have an SHA-2-signed cert, and the impostor could present an MD5-signed cert instead but in that case, how does the client recognize the cert as valid concerning the certificate authority ? – user2284570 Dec 11 '16 at 12:10
8

The issue is caused by the unavoidable phenomenon of "Hash Collision"

The dangers of trusting certificates that use SHA1 starts from the technique used by Certificate Authorities (CA) to sign them and how the web browser verifies them.

As you may know the entire certificate is not signed, instead only the hash of the certificate gets signed.

Lets assume a certificate with the following data inside A with value A produces a hash 7d157d7c000ae27db146575c08ce30df893d3a64.

Now if a third party is able to create a certificate X with arbitrary value *************** such that the sha1 hash is 7d157d7c000ae27db146575c08ce30df893d3a64 then it can be used as a replacement and the browser would not be able to tell the difference as the hashes would be same and hence the signatures would match.

The villain in this story is no one else but our trusted Moore's Law

A sha1 hash is a 120 bit (20 bytes) one way hash algorithm. Which means it can produce 2^120 = 1329227995784915872903807060280344576 unique values.

This was more than enough years ago when all this story began but computers have become so fast that the computing power that is needed to produce a collision is dropping every year.

In 2012, Jesse Walker wrote an estimation of cost to produce a collision. Based on the estimates, collision would cost $2M in 2012, $700K in 2015, $173K in 2018, and $43K in 2021 ->https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html

That means that many companies, organizations and governments today has sufficient computing power to produce a fake certificate that will pass through the test.

You are right, if there is a site using sha1 there is a great chance it can be broken. Not yet by small time hacker but it is better to close the holes before water starts seeping in.

  • Regarding the cost of producing a SHA1 collision, wouldn't an attack like this require more than just a collision? I believe what's actually needed here is a second preimage attack, which is significantly harder to carry out than just a collision. (Even MD5 is still resistant to second preimage attacks.) – Ajedi32 Jun 1 '16 at 14:20
  • Teh condition for second-preimage is that given x, it is difficult to find a second preimage x′ ≠ x`1`` such that h(x) = h(x′)```. In this case that is exactly what happens. You can find an Y that does not equal X but produces the same SHA1 out as X. Both attacks are possible here. Collision resistance implies second-preimage resistance, but does not guarantee preimage resistance. How is MD5 second-preimage resistant ?? Refer: crypto.stackexchange.com/questions/1434/… – BMC Jun 4 '16 at 11:26
  • Collision resistance does imply second preimage resistance (if you can't find any collision, then obviously you can't find a collision for a fixed x), but the reverse is not true. Just because you can't find a collision for a predetermined x, doesn't mean you can't find any collision, period. (See crypto.stackexchange.com/q/20997/21238 ) MD5 is still considered second-preimage resistant (see crypto.stackexchange.com/q/13303/21238 ), but not collision resistant. – Ajedi32 Jun 4 '16 at 18:09
  • 1. I said -> Collision resistance implies second-preimage resistance, but does not guarantee preimage resistance. 2. How does something that is not Collision resistant be Second preimage resistant? 3. Collision for ANY 2^n bit hash value can be found theoretically and especially with low lengths such as 120, 128 etc it is easier now. REFER : schneier.com/academic/paperfiles/paper-preimages.pdf , iacr.org/archive/eurocrypt2009/54790136/54790136.pdf – BMC Jun 5 '16 at 12:39
  • 1. Correct. (Assuming of course you're not conflating preimage resistance with second-preimage resistance. Those are two different things.) 2. Are you trying to say that second preimage resistance implies collision resistance? That's not the case. Again, see crypto.stackexchange.com/q/20997/21238 3. Interesting. That first paper in particular seems to be specifically concerned with second-preimage attacks on MD5 and SHA-1. This question explicitly references the method in that paper though, calling it "impractical". Is that incorrect? – Ajedi32 Jun 5 '16 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.