Using TrafficScript to analyze client TLS Server Name support (10/05/2009)
TrafficScript is very powerful at manipulating requests and responses, however it can also be used to analyze clients to see what functionality they support. In particular in this article we will look at the TLS Server Name Extension, using TrafficScript to see the percentage of clients that support the feature.
One major disadvantage with the original SSL and TLS specification was that it required one IP address per encrypted service. This limitation arises as a result of the the clients needing to validate the certificate presented by the server. The only way for the server to know which certificate to present was based on the IP address that the client connected to (an alternative is wild-carded certificates which I won't touch on here).
Back in the dark ages (well, 2003), an extension was added to TLS 1.0 that gave a way for the client to provide the server with the hostname for which to provide the certificate. It has taken a while for this extension to be implemented in browsers such as Internet Explorer and Firefox, and longer still for end users to upgrade.
TLS Server Name extension support was added to SXTM in version 5.1, and can be configured from the Virtual Server -> Edit -> SSL decryption page (use host names rather than IP addresses to select the certificate to send to the client). However, except in tightly controlled environments, I wouldn't recommend it currently be used.
Even if you don't use the support inside SXTM you can still use TrafficScript to see if your clients support the extension:
- # Don't run this rule for non SSL decrypting traffic
- if( ! ssl.isSSL() ) break;
- if( ssl.getTLSServerName() == "" ) {
- log.info( "TLS Server name not supported" );
- } else {
- log.info( "TLS Server name supported" );
- }
What this rule will show you is FireFox has supported it since version 2.0, but Internet Explorer hasn't properly supported it on XP until version 8. The gory details are on the Wikipedia page.
A slight modification to the rule allows you to count the number of clients that support the extension:
- # Don't run this rule for non SSL decrypting traffic
- if( ! ssl.isSSL() ) break;
- if( ssl.getTLSServerName() == "" ) {
- counter.increment( 0 );
- } else {
- counter.increment( 1 );
- }
Using the above rule you can graph user counters 0 and 1 in the Current Activity page of the administration server to see the ratio of users of your site that use clients that support the extension. You can also get the raw numbers using SNMP.
As with most little TrafficScript rules they tend to grow over time. In the end I ended up with a rule that periodically logs the user agents to the event log that support and don't support the extension. This is great for testing but I wouldn't recommend it on a production site:
- # Don't run this rule for non SSL decrypting traffic
- if( ! ssl.isSSL() ) break;
- if( ssl.getTLSServerName() != "" ) {
- # This client supports the TLS Server Name extension
- counter.increment( 1 );
- log.info.limit( "TLS Server Name supported by: " . getuseragent(), 60 );
- } else {
- # This client does not support the TLS Server Name Extension
- log.info.limit( "No TLS Server Name support from: " . getuseragent(), 60 );
- counter.increment( 0 );
- }
- # Get the user agent from the HTTP headers
- sub getuseragent()
- {
- return http.getheader( "User-Agent" ) || "unknown user agent";
- }
- # Call log.info for an indivdual msg once per $interval time
- sub log.info.limit($msg, $interval)
- {
- $last = data.get( "limit!" . $msg );
- if( ! $last || $last > sys.time() - $interval ) {
- log.info( $msg );
- data.set( "limit!" . $msg, sys.time() );
- }
- }
In an ideal world, you would find that all your clients supported the extension, and you could then reduce IP address usage and potentially save some money, in practice, though you will probably find that 50% of your users don't support the extension currently.
Hopefully in 5 years time we will all be able to use the extension as it was originally intended...
1 Comment
