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:
- RFC 5246 specifies that it is optional (see section 126.96.36.199.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.
- Some browsers (e.g., Android 2.3-4.3) support SHA2 but not TLS 1.2 (see feature matrix)
- 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).