SHA2 / SHA256 certificates

I know it's possible to detect the cipher suites supported by the client: create a client SSL profile with weak ciphers allowed, then after SSL handshake completion, check the cipher suite used. It would then be possible to redirect clients using weak ciphers to the remediation page. But... if the client is unable to validate the SHA2 certificate, the SSL handshake will never complete.

 

 

The next option would be to binary scan the TCP::payload on the 'client hello' and check the presented cipher suites... however, I don't think that the list of cipher suites presented by the client tells us whether the client is able to validate a SHA2 certificate, or not. i.e. it may be possible that a client that does NOT list SHA2 / SHA256 in the list of supported cipher suites, but is still actually able to verify a SHA2 certificate.

 

 

I see two ways to solve this.

 

 

1.) Use a "weak" ssl profile as the default and let all clients connect to a VS that uses the "weak" profile. After the SSL handshake you will know the supported ciphers of the client. If it supports SHA2/SHA256, send a HTTP redirect to a different site (VS) that uses a strong ssl profile. All other clients will be redirected to an error page or something, telling them to upgrade their browser. There is a huge disadvantage with this: you will need two certificates, as the redirect must use a different domain, like: www.strong.sample.com. Furthermore users might get confused due to the redirect and the different domain.

 

 

2.) Use a strong SSL profile as default. Then do a binary scan of TCP::payload to extract the ciphers offered in the CLIENT HELLO. If a client does NOT offer SHA2/SHA256 you can safely send an error message (by using a different SSL profile SSL::profile and either a HTTP::redirect or HTTP::respond). The client would never expect and probably not accept a SHA2/SHA256 reply from the server, if it had not offered that "cipher".

 

 

I would suggest option 2.

 

 

Regards

 

Kurt Knochner