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

 

Hi Kurt, I appreciate the reply, but unfortunately I don't think either option will work. I've done a bit more investigation since my first post - and to confirm my thoughts, I ran a quick (successful) test to an SSL site with SHA2 cert... the Client Hello contains the following Cipher Suites (36 suites) presented by my browser:

 

 

Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)

 

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)

 

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)

 

Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)

 

Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)

 

Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)

 

Cipher Suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA (0xc00f)

 

Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA (0xc005)

 

Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)

 

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

 

Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

 

Cipher Suite: TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007)

 

Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)

 

Cipher Suite: TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011)

 

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)

 

Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)

 

Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)

 

Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)

 

Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)

 

Cipher Suite: TLS_ECDH_RSA_WITH_RC4_128_SHA (0xc00c)

 

Cipher Suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA (0xc00e)

 

Cipher Suite: TLS_ECDH_ECDSA_WITH_RC4_128_SHA (0xc002)

 

Cipher Suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA (0xc004)

 

Cipher Suite: TLS_RSA_WITH_SEED_CBC_SHA (0x0096)

 

Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)

 

Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

 

Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)

 

Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)

 

Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)

 

Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)

 

Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)

 

Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

 

Cipher Suite: TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA (0xc00d)

 

Cipher Suite: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc003)

 

Cipher Suite: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff)

 

Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

 

 

...as you can see, SHA2 is not listed. The Server Hello then shows the selected suite:

 

 

Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)

 

 

... the certificate sent by the server shows the following information:

 

 

Certificates Length: 3714

 

Certificates (3714 bytes)

 

Certificate Length: 2083

 

Certificate (id-at-commonName=*detail removed*)

 

signedCertificate

 

algorithmIdentifier (sha256WithRSAEncryption)

 

Algorithm Id: 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)

 

Padding: 0

 

encrypted: 54f056b0f5ec7b2a15d6e756c058d3df65d22cfaf8ed4e20...

 

Certificate Length: 1625

 

Certificate (id-at-commonName=*detail removed*)

 

signedCertificate

 

algorithmIdentifier (shaWithRSAEncryption)

 

Algorithm Id: 1.2.840.113549.1.1.5 (shaWithRSAEncryption)

 

Padding: 0

 

encrypted: 5d4f84f1a888d3a3b2bc9c6de5294977e1e7d6dca9d835ae...

 

 

You can see that the algorithmIdentifier is sha256WithRSAEncryption. So, in summary, my browser/OS was able to verify the SHA256 cert, but did not present any cipher suites with SHA256 included.

 

 

I guess this means that LTM SSL profiles plays no part in the certificate verification process, has no view of it, and therefore this problem can not be solved.

 

 

I hope I'm wrong :)

 

 

 

 

i understand sha2 is not an option in cipher suite of ssl2.0, ssl3.0, tls1.0.

@Stephen:

 

 

If the client does not offer the cipher you want to see, you cannot assume anything. The client might have good reasons not to offer SHA256.

 

 

So, you still have only those options I described. I would suggest option 2. In your example, the client MIGHT be able to handle SHA256, but you don't know, as it did not indicate that by offering the right cipher. If you answer with SHA256, and the client is not able to handle it, you will create an ssl handshake error and you have no chance at all to tell the client to try again with a different cipher set.

 

 

So, in your example, the remaining option is to use a "weak" ssl client profile for that request, redirect the client to an error page and tell it to upgrade or change the configuration/cipher set.

 

 

Regards

 

Kurt Knochner

Posted By nitass on 10/30/2011 08:02 AM

 

i understand sha2 is not an option in cipher suite of ssl2.0, ssl3.0, tls1.0.

 

The newer SHA hash methods (SHA256, etc.) are defined in TLS 1.2 (RFC5246). TMOS 11.0 is the first version to support TLS 1.2 and thus SHA2 and SHA256.

 

 

Regards

 

Kurt Knochner

 

thanks Kurt. i think we might misunderstand Stephen's question a bit.

 

 

as i read through it again, i think he is asking about sha2/sha256 certificate i.e. not sha2/sha256 cipher suite.

 

 

or am i totally lost? :-)

> as i read through it again, i think he is asking about sha2/sha256 certificate i.e. not sha2/sha256 cipher suite.

 

 

good point!!

 

 

If that's the case, I see only one way to figure out if a client supports that or not, because that's just a feature of the browser and not related to SSL/TLS.

 

 

Let all clients connect to a VS with a SHA1 cert. Check the User-Agent string. If it's a "decent" browser (you know it supports SHA256 certs), redirect it to a different VS with a SHA256 cert, otherwise just balance the request or send an error message.

 

 

BTW: If you don't want to redirect the newer clients to a different VS, just remember the client IP in a session table (table command). Then redirect the client to the same VS. If the request comes in, check if the IP address is available in the session table. If yes, you know it supports SHA256. Then use a different ssl client profile, with the SHA256 cert (SSL::profile).

 

 

WARNING: This does not work properly, if the users are connecting through a proxy (same ip, different browser) or if they work from a terminal server, though chances are good that they use the same browser on the terminal server.

 

 

@Stephen: how does that sound to you?

 

 

Regards

 

Kurt Knochner

i feel SHA2 certificate is OS thing rather than browser one.

 

 

SHA2 and Windows

 

http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx

Thanks Kurt and Nitass... appreciate your comments. Agree that OS is responsible. Don't think there is a cool way out of this one.

 

> i feel SHA2 certificate is OS thing rather than browser one.

 

 

I don't think that Firefox relies too much upon the OS when it comes to encryption and hashes. At least I hope so ;-)

 

 

Regards

 

Kurt Knochner