Browser Fingerprinting via SSL Client Hello Messages

Published: 2013-12-11. Last Updated: 2013-12-11 19:15:41 UTC
by Johannes Ullrich (Version: 1)

Encrypted traffic has long been a challenge for network monitoring. But even if traffic is encrypted, there is still plenty of information that can be extracted. In this little example, we are looking at "SSL Hello" messages. These messages are sent by the client to initiate the SSL connection. They include a number of parameters that may vary depending on the SSL library used or the SSL clients preference.

The SSL Hello message contains a couple of major parts [1]

a timestamp. This is the local time of the client, even if the RFC doesn't require it to be accurate.
28 random bytes
a list of cipher suites the client supports
the SSL version the client is using (e.g. TLS 1.0)
any extensions the client may support (including compression)

This gives us quite a bit of data to fingerprint clients. The timestamp can be used to check if the clients time is in sync. The supported cipher suites and extensions may tell us what browser version the host is running and could for example be used to block out of date browsers at a gateway that is not able to decrypt traffic.

Ivan Ristic has published similar data in the past focusing on SSL ciphers [2], and p0f considered including some of that data.

My tool of choice to extract this information from packet captures is tshark. To run this test, I collected a couple minutes of traffic. I also extracted the IP addresses and user agents from the web server log to be able to link the "SSL Fingerprint" to the user agent. I ignored all IP addresses for which I saw multiple user agents (looks like mostly mobile devices that accessed the podcast via a podcast client as well as the web site via a browser).

In tshark, to extract the "fingerprint" I used:

tshark -r test.pcap -T fields -e ip.src -e ssl.handshake.ciphersuite -e ssl.handshake.version -e ssl.handshake.extension.type -R "ssl.handshake.type=-1"

Here is a partial result:

Firefox 25 on Windows 7 ( Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 )

Cipher Suites: 0x00ff,0xc00a,0xc014,0x0088,0x0087,0x0039,0x0038,0xc00f,0xc005,0x0084,0x0035,0xc007,0xc009,0xc011,0xc013,0x0045,0x0044,0x0033,0x0032,0xc00c,0xc00e,0xc002,0xc004,0x0096,0x0041,0x0005,0x0004,0x002f,0xc008,0xc012,0x0016,0x0013,0xc00d,0xc003,0xfeff,0x000a
SSL Version: 0x0301 (TLS 1.0)
Extensions: 0x0301 0x0000,0x000a,0x000b,0x0023,0x3374

Chrome 31 on Windows 7 (Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36)

Cipher Suites:
0xc02b,0xc02f,0x009e,0x009c,0xc00a,0xc014,0x0039,0x0035,0xc007,0xc009,0xc011,0xc013,0x0033,0x0032,0x0005,0x0004,0x002f,0x000a
SSL Version: 0x0303 (TLS 1.2)
Extensions: 0x0000,0xff01,0x000a,0x000b,0x0023,0x3374,0x0010,0x754f,0x0005,0x000d

Internet Explorer 7 on Windows 7 (Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; InfoPath.2; .NET4.0E; Microsoft Outlook 14.0.7109; ms-office; MSOffice 14)

Cipher Suites:
0x003c,0x002f,0x003d,0x0035,0x0005,0x000a,0xc027,0xc013,0xc014,0xc02b,0xc023,0xc02c,0xc024,0xc009,0xc00a,0x0040,0x0032,0x006a,0x0038,0x0013,0x0004
SSL Version: 0x0303 (TLS 1.2)
Extensions: 0xff01,0x0000,0x0005,0x000a,0x000b,0x000d

These three examples, all from Windows 7, show how different browser result in very different fingerprints. The order of ciphers and extensions appears to vary as well allowing for more detailed distinctions, and something that needs a bit more data to work with.

Timestamps

Timestamp fingerprinting was kind of interesting as well. Turns out that out of the times are actually very accurate. Out of a total of 3814 Client Hello messages, 3109 where within 5 seconds. A couple of time stamps where "far outliers" with timestamps in 1970, likely indicating a "time since reboot" instead of the absolute time.