# Certificate Signature Algorithm differs from Signature Algorithm Negotiated for Connection

With the upcoming sunsetting of SHA-1 by browsers I was checking signature algorithms for sites I visit. I'm using Firefox 43.0.2 on Windows.

I noticed something interesting when I visited the site Origin Energy site: https://online.originenergy.com.au.

The site's (leaf) certificate uses the SHA-2/SHA-256 signature algorithm. See certificate details dialog screenshot.

Where as the connection cipher suite appears to use SHA-1. See page info dialog screenshot.

I have a few questions:

Q1. Are the Certificate Signature Algorithm and signature algorithm in the negotiated connection cipher suite used for different purposes?

If these signature algorithms are used for different purposes.

Q2. Does the upcoming sunset for SHA-1 relate to the Certificate Signature Algorithm and signature algorithm in the connection cipher suite?

and

Q3. The SSL Labs scan for the site shows the web service cipher suite lists supports SHA-2 and SHA-1 algorithms.

If I'm using the latest version of Firefox why does the server/client negotiation not use the preferred SHA-2 algorithm for the connection?

• related question on the server end of things: serverfault.com/questions/686170/… – Richie Frame Dec 23 '15 at 21:58
• Note that the upcoming TLS 1.3 completely does away with the PRF (replacing it with HKDF based on SHA-2 - it uses HMAC internally) and CBC replacing it with AEAD cipher modes. There was one mode proposed in a separate RFC that used CBC + AES-CMAC for integrity, but it seems that one didn't make it. – Maarten Bodewes Dec 24 '15 at 11:04
• MD5 and SHA-1 for signatures are merely deprecated though. – Maarten Bodewes Dec 24 '15 at 11:10

Are the Certificate Signature Algorithm and signature algorithm in the negotiated connection cipher suite used for different purposes?

Yes they are.
The hash negotiated in the cipher suite is completely irrelevant to the certificate. The verification of the certificate and the signatures in the TLS handshake use the hash / signature pair negotiated in the signature_algorithms extension. The hash from the cipher suite is called the Pseudorandom Function (PRF) which is used for authentication (in HMAC-mode) for CBC cipher suites and to derive the [master_secret][4] from the pre_master_secret.

Does the upcoming sunset for SHA-1 relate to the Certificate Signature Algorithm and signature algorithm in the connection cipher suite?

The sunset of SHA-1 only affects the use of SHA-1 in certificates. The SHA-1 based cipher suites will still be available as HMAC-SHA-1 isn't broken by collisions on SHA-1.

If I'm using the latest version of Firefox why does the server/client negotiation not use the preferred SHA-2 algorithm for the connection?

Usually the server picks the cipher suites himself, i.e. the server picks the cipher suite it considers strongest and unfortunately most clients (including Firefox) don't support AES-256-GCM but AES-256-CBC so AES-256-CBC gets picked. As for why it picks SHA-1 over SHA-2 then, it's again the support question. Firefox only supports CBC with SHA-1 but not with SHA-2 so SHA-1 gets picked because of the stronger key size.

In your case the server prefers DHE_RSA_* over everything else. It prefers DHE_RSA_AES_*_GCM_* first, but Firefox doesn't support them (Firefox only supports GCM with ECDHE_*) so it picks the next suite in the list which is DHE_RSA_WITH_AES_256_CBC_SHA.

[D]oes it alert on intermediate certs as SHA-1 may impact on the clients ability to validate the trust chain?

Yes, the browser automatically trusts intermediate certificates signed by a trusted root CA. Thus it may not have seen the exact certificate before, meaning if somebody could find a colliding certificate and somehow make the root CA sign it, you're trusting a malicious certificate (this is the same with leaf certificates).

Also why not alert on the root cert?

The browser or the OS have a so-called "certificate store" where they store trusted root certificates. There are three reasons why it collisions on SHA-1 don't matter for root certificates.

1. If the root certificate is sent by the server, the browser may just compare this one byte-by-byte to the local copy and thus any change would cause the alert, but the SHA-1 hash isn't verified explicitely.
2. If the root certificate is sent by the server, the browser may just compute the hash of the received certificate and compare with the hash of the stored certificate. You'd need a second-preimage on SHA-1 to break this which is considered infeasible as of now.
3. Usually the root certificate isn't sent by the server. In this case the browser looks at the issuer of the intermediate certificate and check if this one is in the trust store and accepts it if it is in there.
• Thanks for your well explained answer that makes alot of sense! I have noticed that Firefox and SSL Labs alerts on intermediate certificates whose Certificate Signature Algorithm is SHA-1 (but not on the root cert). This is probably a gumby question but - does it alert on intermediate certs as SHA-1 may impact on the clients ability to validate the trust chain? Also why not alert on the root cert? – Michael Dec 24 '15 at 1:17
• It should alert on any certificate that is not stored in the trust store of the browser. If the certificate is already in the trust store of the browser then it obviously doesn't need verification anymore, and the used hash algorithm is therefore a moot point. – Maarten Bodewes Dec 24 '15 at 10:54
• I think that this is a pretty good and well worked answer. I'm however completely missing the terms Pseudorandom Function and PRF in the answer. Could you include it? – Maarten Bodewes Dec 24 '15 at 10:57
• Thanks for the answers to the additional questions and clarifications! – Michael Dec 29 '15 at 13:17

What's happening there is that the certificate signature algorithm is used to validate the certificate chain from the leaf certificate to the root CA. What is done is to verificate the leaf certificate's digital signature with the Issuer CA's public key and to compute the SHA-256 of the leaf certificate. The certificate is considered secure only if the hash and the verification matches. This process is repeated for each certificate. Remember that when a CA signs a certificate it puts a hash signed by its private key. This all happens when client receives the "Certificate" TLS message during the handshake.

Also, the SHA-1 is relative to TLS protocol, it is not used for verificating destination certificate, but for the pseudo random function.

The hash function that will be used to verificate the integrity of TLS handshake parameters is cointained in the signature_algorithms field so Diffie-Hellman ephemeral parameters are hashed an signed by the private key of the destination. Destination will send this info along the DH parameters in plaintext in the ServerKeyExchange so if the certificate is valid you will grab certificate's public key and verify the digital signature of the ServerKeyExchange packet.

The verification has to match the hash of the DH params, that's why you verify the digital signature, just compute hash over plaintext parameters and then compare hashes.

In https://www.howsmytls.com you can check what cipher suite your browser accepts.

Regards.

• "decipher the leaf certificate's digital signature" - Please. You don't "decrypt with the public key" or "encrypt with the private key". – SEJPM Dec 23 '15 at 20:04
• "SHA-1 will be used to hash the Diffie-Hellman ephemeral parameters so the hash is signed by the private key of the destination" - You can't state that based on the given data. Signing / hashing anything is negotiated via the signature_algorithms extension and not by the PRF (=SHA-1). – SEJPM Dec 23 '15 at 20:06
• SEJPM: As you say you do not decipher a digital signature, you verificate it, sorry for the mistake I already knew that. Also I didn't point to signature algorithn, I'll fix that. Thanks for your comment. Regards. – kub0x Dec 23 '15 at 21:13