Can SHA256 signature support be deduced from TLS cipher suites or any other part of ClientHello (if no signature_algorithm sent)?

Question

Websites aiming to maintain maximum compatibility with (legacy) browsers may wish to serve SHA2-signed certificate chains to those user agents that support them, and SHA1 to those that don't.

The TLS 1.2 spec (https://www.ietf.org/rfc/rfc5246.txt) defines a new signature_algorithm extension that, when sent by the browser, can be used to detect support for SHA2. For example, if the browser includes "SHA256/RSA" it is telling the server it supports this specific hash/signature algorithm pair. The server can then select a compatible chain and return it, or fall back to something like "SHA/RSA".

There are two main issues with relying on this extension, however:

1. RFC 5246 specifies that it is optional (see section 7.4.1.4.1)

If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension. If the client does not support the default algorithms, or supports other hash and signature algorithms (and it is willing to use them for verifying messages sent by the server, i.e., server certificates and server key exchange), it MUST send the signature_algorithms extension, listing the algorithms it is willing to accept.

2. Some browsers (e.g., Android 2.3-4.3) support SHA2 but not TLS 1.2 (see feature matrix)
   1. If the server side logic requires the extension, it may "over serve" SHA1 certificates to clients that could otherwise process SHA2.

Given the above two deficiencies, is there any other part of the TLS handshake ClientHello message that can be used to detect SHA2 support?

Original thinking was to see if SHA256 appeared in the PRF/MAC field of a cipher suite (e.g., the SHA256 at the end of TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256), but it seems that these too will only be present as of TLS 1.2).

Answer 1

The only reliable places to know which signature algorithms are supported you've already detected:

• the signature_algorithms extension
• and the TLS version offered by the client, which shows that the client implements (hopefully) at least the minimum requirements of this TLS version

Everything else is guessing. You might try to fingerprint the client based on the ciphers offered and on the order of the ciphers (see the SSLLabs client tests). You might add use of other extensions like SNI to the fingerprint. And then you could map the fingerprint to the supported signatures.

But I would recommend against such unreliable hacks. Lots of big sites like Facebook move or moved already to SHA-256 and those will break every client which does not support these signature algorithms. This should put a lot of pressure on the clients to support SHA-256.