Certificate Signature Algorithm differs from Signature Algorithm Negotiated for Connection

Question

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?

Answer 1

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.

From the comments:

[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.

Answer 2

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.