7
$\begingroup$

Is using the SHA-1 algorithm insecure for hashing the ephemeral ECDH public key in the signed_params structure?

There are some worrying articles about using SHA-1:

My server sends the following Server Key Exchange message for TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b).

TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange 
    Content Type: Handshake (22)
    Version: TLS 1.2 (0x0303)
    Length: 148
    Handshake Protocol: Server Key Exchange
        Handshake Type: Server Key Exchange (12)
        Length: 144
        EC Diffie-Hellman Server Params
            Curve Type: named_curve (0x03)
            Named Curve: secp256r1 (0x0017)
            Pubkey Length: 65
            Pubkey: 0...  
            Signature Hash Algorithm: 0x0203
                Signature Hash Algorithm Hash: SHA1 (2)  <<<=============
                Signature Hash Algorithm Signature: ECDSA (3) 
            Signature Length: 71
            Signature: 3...  

Should I change it to use SHA256 like server certificate? Or is it safe since it is used to sign the ephemeral key?

$\endgroup$
  • $\begingroup$ Why would you deliberately use SHA1 today? This is like building a new car with a 20 year old engine design. It still works, but it simply isn't up-to-date any more. $\endgroup$ – tylo Aug 13 '15 at 9:13
  • $\begingroup$ You could at least configure your server to allow clients to indicate SHA-256 in the right handshake extension, but I would suggest you make sure that it would not result in strongly degraded performance. $\endgroup$ – Maarten Bodewes Aug 13 '15 at 19:09
7
$\begingroup$

SHA-1 is still thought to be secure whenever collision resistance isn't required.

The hash is both used for signing certificates and ECDHE public keys. There's however a difference with regard to collision attacks. It is possible for an attacker to attack the collision resistance with certificates by getting their own certificate signed by a CA. In ECDHE however the attacker shouldn't be able to control the ECDHE public key parameters that are signed.

So, while I wouldn't recommend using SHA-1 in new applications if you can just as well use another hash, TLS is what it is and this kind of a cipher suite is still thought to be secure.

$\endgroup$
  • $\begingroup$ Thanks. I did some more test according to the comments. - A server with two certs below was tested. 1. id-ecPublicKey/ecdsa-with-SHA256 2. id-ecPublicKey/sha256WithRSAEncryption - In both cases, cipher suite negotiation was done by "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384" - In both cases, the server was sending it's ephemeral pub key with "sha1" hash. - When I tested another server with the same certs, that was sending 1. "sha512" hash to openssl client 2. "sha256" hash to gnutls client # So I'll try to find a way to make my server to select sha256/512 hash. $\endgroup$ – wilson Aug 14 '15 at 11:08
  • $\begingroup$ @wilson, good to know that you can get rid of SHA-1 if you really want to, but currently there doesn't seem to be a pressing need if a server doesn't support the extensions in question. $\endgroup$ – otus Aug 15 '15 at 15:02

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.