Forum Discussion

DanielMoeller_3's avatar
DanielMoeller_3
Icon for Nimbostratus rankNimbostratus
Jul 21, 2017

Determine SSL client profile by client's TLS version

Hello all,

 

this is my first post in this board, so please do not hesitate to make me aware of any rules or best practices I might have missed.

 

I am in charge of one BigIP 7000 loadbalancer for telecommunication brand in Germany. The loadbalancer serves an application, which is used by modern HTTP client being capable of TLS v1.2 and SHA-2 certificates and legacy clients being capable of TLS 1.0 and MD5-signed certficates. Both use the same Virtual Server and this cannot be changed.

 

I was asked to improve security by serving a "good" certificate to the modern clients and a weaker one for the legacy clients. My first idea was to identify the modern clients by the SNI extension. Unfortunately, they do not support this and will not. My second approach was to distinguish the modern from the legacy ones by support of Elliptic Curvers ciphers vs. plain RSA. Unfortunately the modern clients do not support EC, either and will not in future.

 

My next idea is to have an iRule decide which SSL client profile to provide. Of course we cannot do it based on information in the HTTP header (as far as I understood, it is possible with renegotiation, but honestly I do not like this approach).

 

Is it possible to evaluate the Client Hello and see the client's TLS protocol and select the SSL client profile based on that?

 

Any help on this is highly appreciated.

 

Thanks in advance Daniel

 

BIG-IP
iRules
security
  • tatmotiv's avatar
    tatmotiv
    Icon for Cirrostratus rankCirrostratus
    Jul 21, 2017

    Hi Daniel, welcome aboard.

     

    According to this SOL, it is not possible to use any SSL-related information derived after a CLIENTSSL_CLIENTHELLO event in order to chose an SSL-profile:

     

    It is not possible to utilize SSL::extensions or other SSL commands to make a profile selection using the SSL::profile command. To select a profile based on the Client Hello contents, it is still required to manually interpret the raw TCP data in CLIENT_DATA. Though the Client Hello is where the client proposes ciphers, there is no command to access this information in the event.

     

    As I understand that, this is caused by the fact that CLIENTSSL_CLIENTHELLO is triggered AFTER the selection of a clientssl profile. Hence, in order to solve this with an iRule, you will have to use TCP::collect and - as described in the above solution - manually interpret the raw TCP data in CLIENT_DATA. There might be some examples for that here on devcentral.

     

    However, I could also think of another way to accomplish that: Can't you find another means of identifying your "newer" clients (e.g. user-agent) and redirect them (using http redirect) to a more secure virtual with higher-level clientssl profile AFTER the initial SSL handshake while leaving the others on the less-secure one? Might be easier to implement...

     

    HTH,

     

    Martin