Forum Discussion

Stephen_Archer_'s avatar
Stephen_Archer_
Historic F5 Account
Oct 28, 2011

SHA2 / SHA256 certificates

I have a customer that wants to use SHA2 / SHA256 certificates on their website (fronted by LTM), however clients such as Windows XP SP2 are unable to verify such certificates. The customer would like to detect these clients and redirect them to a web page providing remediation advice.

 

 

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.

 

 

So my question is, do I understand this issue correctly, and if I do, has anyone thought of a way to overcome it?

 

 

Thanks in advance!

 

15 Replies

  • Steve_Brown_882's avatar
    Steve_Brown_882
    Historic F5 Account
    Hey Arch,

     

     

    I found this question to be very interesting so I spent some time thinking about a possible solution. It occurred to me that the issue is really a combination of OS and Browser as any browser using its own version of TLS should work fine. So Firefox or Chrome running on XP will likely work for the same reason they also support SNI on XP. So this leaves us with IE and possibly older versions of Chrome and Firefox to consider. The one thing that all of these browsers would have in common on XP is that they likely won't support SNI.

     

     

    So what I think you could do is use the logic from Joels SNI iRule( http://goo.gl/ZbU8u) to determine if the browser making the request supports SNI or not. This really won't get you all the way there as from my understanding IE running on XP with SP3 will support the SHA2 certificates, but not SNI data.

     

     

    So you would need to terminate the non SNI supported browsers with a weaker certificate and then present the client with a remediation page that gave them the option to click through if they confirmed that SP3 was installed on or something along those lines.

     

    Obviously you would need some logic to then allow the client to pass through without SNI and don't have that fully thought out. I am sure there are some holes in my logic, but it was such an interesting question to me that I wanted to dig into other possible solutions.

     

     

  • Sorry to barge in, but the user-agent string does seem to give away something about the OS as well, this is my WinXP SP3 PC:

     

     

    User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET CLR 2.0.50727)

     

    Is does look a bit weird (SV1), but maybe you can find a common string in the user-agent header of WinXP SP2 stations?

     

  • Sorry about this, each time I got a message the post was rejected but it still ended up here.