2
$\begingroup$

I captured a TLS 1.2 handshake on my server (WIN2012.R2/IIS 8.5) and noticed that SHA1 is being used to hash ECDHE parameters despite both the server and client(s) supporting SHA2 signatures. 

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)

TLSv1.2 Record Layer: Handshake Protocol: Multiple Handshake Messages
         Content Type: Handshake (22)
         Version: TLS 1.2 (0x0303)
         Length: 1980
    Handshake Protocol: Server Key Exchange
            Handshake Type: Server Key Exchange (12)
            Length: 361
            EC Diffie-Hellman Server Params
                Curve Type: named_curve (0x03)
                Named Curve: secp384r1 (0x0018)
                Pubkey Length: 97
                Pubkey: 
                Signature Hash Algorithm: 0x0201
                    Signature Hash Algorithm Hash: SHA1 (2)
                    Signature Hash Algorithm Signature: RSA (1)
                Signature Length: 256
                Signature:

  • I've tested the clients with other servers and found SHA2 was chosen in many cases so it seems to be my server (not clients) forcing the use of SHA1 for some reason.

  • I've also tested another 2012 R2 VM I have as well as 2016 TP5 and again with both, SHA1 is chosen for ECDHE.

  • The certificate chain is signed using SHA2 and the HMAC chosen in this case was SHA384 so the server doesn't seem to have any problem using SHA2 signatures in other cases.

Could this be misconfiguration on my part? I haven't found any way to effect the (EC)DHE signature algorithm in Windows either accidently or intentionally.

Could this just be a known trait of Schannel in server 2012? (If someone has a similar setup and could confirm by capturing a handshake, I'd appreciate it.)

In any case, is there any risk in SHA1 being used here?

Thanks!

Improve this question
$\endgroup$
3
  • $\begingroup$ Just to be clear: it's the signature being generated by the private key of the TLS server certificate over the handshake frames that uses SHA-1. This SHA-1 is not used for certificate chain verification or for key derivation after the ECDH key agreement. In that sense it could very well be a misconfiguration IMHO, but I'm not that familiar with SChannel to know for sure. $\endgroup$
    – Maarten Bodewes ♦
    Apr 19, 2016 at 13:41
  • $\begingroup$ Maarten, could you expand a little on why this leads you to believe it could be misconfiguration on my part? I was thinking the opposite just because it seems there is less user involvement with the hashes related to DHE than there is with certificate signing or even the choice for HMAC. Thanks! $\endgroup$
    – Rowbby
    Apr 19, 2016 at 22:34
  • $\begingroup$ It could be a misconfiguration as the private key operation itself is performed at the server side. As far as I know the server is responsible for indicating the hash algorithm. I'm not sure you can (easily) configure this for SChannel though, so hence the comment instead of an answer. $\endgroup$
    – Maarten Bodewes ♦
    Apr 21, 2016 at 12:54

2 Answers 2

Reset to default
2
$\begingroup$

I'm led to believe the use of SHA-1 for the ECDHE parameters is not due to misconfiguration, but is rather the intended (albeit not ideal) behaviour of server-side Schannel. This behavior seems to be present in versions up to Windows Server 2012 R2 and even continues with Windows Server 2016 Technical Preview 5.

I've captured handshakes with many, many random servers that advertise they're using some version of IIS and the negotiated cipher suite uses ECDHE. In all cases, the signature algorithm chosen for ECDHE params is SHA-1. I couldn't find a single IIS server that used SHA-2.

If anyone has any evidence that IIS/Schannel is capable of using SHA-2 in this scenario, please post, otherwise for now I'm going to consider this answered as "by design".

Improve this answer
$\endgroup$
1
1
$\begingroup$

On the server, the certificate is stored in a certificate store, that includes a link to the private key. That link really is the name of a CSP (Cryptographic Service Provider) and the name of a container in that CSP. CSP relate to CryptoAPI, the old cryptographic API that is unfortunately hostile to hash functions other than MD5 and SHA-1. Chances are that it is what happens in your case.

It is possible that SHA-256 usage may be enabled if the private key is registered as being part of a "KSP" (a "key storage provider", that works with CNG, the new cryptographic API, that is compatible with SHA-2 functions). Since standard software-based CSP and KSP ultimately store keys in the same place (user profile or registry), this might be just a matter of modifying the CSP name in the link from the certificate, so that it points to the "Microsoft Key Storage Provider", which is the name for the CNG-aware KSP. See this page as a starting point for some guidance.

(Altering the link can be done programmatically with some C code, or C# with Interops, but from the command-line you might have to report to exporting the certificate and key as PFX, then importing them back with certutil -importPFX and an explicit CSP name. Either way, make sure to keep a backup of your key somewhere, or to be able to obtain a fresh certificate readily, because keys can get lost that way -- although usually a certutil -repairstore can find them back.)

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ Read your comment and thought this could very well be what was causing the problem, but I just double checked and my website certificate's key shows as "Provider = Microsoft Software Key Storage Provider" so it would seem it's already in the CNG KSP. $\endgroup$
    – Rowbby
    Apr 19, 2016 at 22:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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