3
$\begingroup$

For years we've been warned that SHA-1 is weaker than originally thought and should not be used. This reached its peak with the Shappening and experts from Schneier on down have been warning that we should get off SHA-1, or something bad will happen.

What are the practical 'something bad's? Once an attacker has the capability to create a SHA-1 collision, what then can they do? I'm interested in confidentiality and integrity of HTTPS, but am open to broader answers.

Specifically would it be feasible to do a MITM attack by creating a fake certificate for an existing website? It seems plausible: the attacker creates a fake certificate with the same name, but varies the other data in order to produce a SHA-1 hash that matches the SHA-1 hash of the original certificate.

$\endgroup$
  • $\begingroup$ Your idea for attacking an existing website would require a preimage attack - and that is not considered broken yet (like collision resistance has been for years). Basically for certain uses (e.g. HMAC) you don't have to replace SHA-1 in existing systems yet - just don't use it to build anything new. $\endgroup$ – tylo Jan 18 '17 at 12:56
  • $\begingroup$ @tylo I don't agree. If you can obtain a MD5 certificate for any site from a trusted CA and you are able to pre-compute then you could change the server name and perform a man-in-the-middle attack. That would only require second preimage resistance. Not that that is already feasible. $\endgroup$ – Maarten Bodewes Jan 18 '17 at 17:12
  • $\begingroup$ @MaartenBodewes You're right about second preimage resistance, but that's strictly stronger than a collision attack. Also for a chosen prefix collision the effort is higher than a regular collision attack - which is possible for MD5, like in the Flame malware. But their claim is finding freestart collisions, and that's easier than finding regular collisions. On the scale of things, if SHA-1 is the apple going bad right now, then MD5 has crumbled to dust alreay. $\endgroup$ – tylo Jan 19 '17 at 9:31
3
$\begingroup$

SHA1 certificate is getting weaker because computing power grows to Moore's Law. According to Jesse Walker, who made a back of the envelope calculation of the cost of SHA1 collision attack:

the cost of the attack will be approximately:

  • \$2.77M in 2012
  • \$700K by 2015
  • \$173K by 2018
  • \$43K by 2021

A collision attack is therefore well within the range of what an organized crime syndicate can practically budget by 2018, and a university research project by 2021.

To your question:

What are the practical 'something bad's?

The practical "something bad" is that sometime this year, all major browser vendors (Google, Firefox, Microsoft) would distrust sha1 certificate. This means that your site/servers will be blocked with a big security warning, it might actually be more sensible to not use HTTPS at all than to use SHA1 certificate at that point. Some browsers now already no longer shows the secure lock icon on sites with SHA1 certificate.

Once an attacker has the capability to create a SHA-1 collision, what then can they do?

Certificate signature is made by taking a hash of the public key and attached data (owner identity and Common Name/SAN) and then the CA signing that hash with the CA's private key.

If you generate two keypairs with the same SHA1 signature, you can convince a CA to sign one of the public key and that signature will also be valid for the other key. From there on, it's a simple matter to implant the CA's signature on the second certificate. That second certificate could be for a different domain that you don't actually control.

$\endgroup$
  • $\begingroup$ The thing I didn't realise until very recently is, as you say, certificate users need to change because of reputational harm from browser warnings. $\endgroup$ – Tony Jan 18 '17 at 21:28
1
$\begingroup$

See Why We Need To Move To SHA-2, which sums thing up nicely:

Hash attacks are described as follows, in increasing order of difficulty for an attacker:

Collision – A collision attack occurs when it is possible to find two different messages that hash to the same value. A collision attack against a CA happens at the time of certificate issuance. In a past attack against MD5, the attacker was able to produce a pair of colliding messages, one of which represented the contents of a benign end-entity certificate, and the other of which formed the contents of a malicious CA certificate. Once the end-entity certificate was signed by the CA, the attacker reused the digital signature to produce a fraudulent CA certificate. The attacker then used their CA certificate to issue fraudulent end-entity certificates for any domain. Collision attacks can be mitigated by putting entropy into the certificate, which makes it difficult for the attacker to guess the exact content of the certificate that will be signed by the CA. Entropy is typically found in the certificate serial number or in the validity periods. SHA-1 is known to have weaknesses in collision resistance.

Second-preimage – In a second-preimage attack, a second message can be found that hashes to the same value as a given message. This allows the attacker to create fraudulent certificates at any time, not just at the time of certificate issuance. SHA-1 is currently resistant to second-preimage attacks.

Preimage – A preimage attack is against the one-way property of a hash function. In a preimage attack, a message can be determined that hashes to a given value. This could allow a password attack, where the attacker can determine a password based on the hash of the password found in a database. SHA-1 is currently resistant to preimage attacks.

So a successful collision attack would indeed pretty much break SSL/TLS, as it did for MD5, and that's why browser vendors and CAs need to move to not use SHA-1. At this time, the requirement for certificate owners to move away from SHA-1 is, as noted elsewhere, largely reputational.

$\endgroup$
0
$\begingroup$

I think the best example is to just look at what happened with MD5, as detailed in what's (IMHO) one of the most dramatic practical cryptographic attacks ever demonstrated:

  • Sotirov, Alexander, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik and Benne de Weger. 2008. "MD5 considered harmful today: Creating a rogue CA certificate." Webpage at: https://www.win.tue.nl/hashclash/rogue-ca/

As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol.

Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats.

As a result of this successful attack, we are currently in possession of a rogue Certification Authority certificate. This certificate will be accepted as valid and trusted by all common browsers, because it appears to be signed by one of the root CAs that browsers trust by default. In turn, any website certificate signed by our rogue CA will be trusted as well. If an unsuspecting user is a victim of a man-in-the-middle attack using such a certificate, they will be assured that the connection is secure through all common security indicators: a "https://" url in the address bar, a closed padlock and messages such as "This certificate is OK" if they chose to inspect the certificate.

So yeah, the ability to do chosen-prefix collision attacks allows you to forge as many certificates as you like, and this completely breaks HTTPS.

$\endgroup$

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.