What is SHA-1?
Secure Hash Algorithm 1 (SHA-1) is a cryptological hash function. It is used to calculate a verification value for any digital data and is, among other things, the basis for creating a digital signature.
The check value is used to ensure the integrity of a message. If two messages result in the same verification value, the equality of the messages should be guaranteed according to normal judgement, without prejudice to targeted attempts to manipulate the messages.
Why is SHA-1 insecure?
Long story short: It is a “good hash algorithm” to use for hashing strings. It is fast and unlikely to generate collisions. However, it is no longer “cryptographically secure”. This means that SHA-1 will one day be completely broken without the need for computational resources to calculate collisions.
And progress is insane in how cheap a collision attack has become in recent years:
~ $2.77M by 2012https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
~ $700K by 2015
~ $173K by 2018
~ $43K by 2021
Where is SHA-1 used?
SHA-1 is very frequently used in TLS. This may come as a surprise to some. Because at one point the replacement of SHA-1 in TLS has already been accomplished: After much discussion and effort, all major browser manufacturers have decided to no longer accept SHA-1 signatures in certificates. Certification authorities have not been allowed to issue such certificates for some time now, although there are always exceptions.
But TLS uses hash functions in various places. The use of SHA-1 for the HMAC procedure is unproblematic, because collision resistance is not relevant here. This applies to cipher modes such as ECDHE-RSA-AES256-SHA. Here, AES is used in CBC mode and HMAC with the SHA-1 algorithm. The combination of CBC and HMAC is not recommended for other reasons, since it is very susceptible to timing attacks, but the weaknesses of SHA-1 do not play a role here.
SHA-1 in TLS Handshakes
However, a weak hash is definitely a problem in another place:
The problems posed by weak hashes in TLS were published by security researchers in early 2016 as the SLOTH attack.
How to prevent SHA-1 from being used in Forward Secrecy?
I don’t use SHA-1 because all of my ciphers are state of the art!Some random it security guy
Of course, this also depends on the encryption method used, but that’s too complicated to explain here. Even with the most secure best-practice ciphers, you will use SHA-1 (eventually).
The important point is: it is not! a server software configuration. It’s an OpenSSL thing…
That’s why: just fix it!
Find this line “[system_default_sect]” and append the next 4 lines after it. Save and restart your nginx, Apache or whatever you use. That’s it!
[system_default_sect] MinProtocol = TLSv1.2 CipherString = DEFAULT@SECLEVEL=2 SignatureAlgorithms = RSA+SHA512:ECDSA+SHA512:RSA+SHA384:ECDSA+SHA384:RSA+SHA256:ECDSA+SHA256 Groups = secp521r1:brainpoolP512r1:secp384r1:brainpoolP384r1:prime256v1:brainpoolP256r1:secp224r1
Please test your new server configurations before you use it in production!
Am I affected?
Let’s test it:
openssl s_client -connect badssl.com:443 -sigalgs RSA+SHA1
If you see something like…
Peer signing digest: SHA1 Server Temp Key: ECDH, P-256, 256 bits
then you are affected. But if you see…
CONNECTED(00000003) 140624615224984:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 185 bytes
all looks good 🙂
Make sure not to use the latest version of OpenSSL. For this example above, I used OpenSSL 1.0.2g. It doesn’t matter of your server uses the latest version of OpenSSL, you just need an older “client” version of OpenSSL to test this.
What could happen if I use SHA-1 in Forward Secrecy?
In a theoretical world, an attacker could compute a SHA-1 collision and influence the Forward Secrecy parameters, which in the worst case could result in no proper Forward Secrecy.
And what that means is another story 😉