8

Is it possible to passively fingerprint a HTTPS client, based solely on data visible to a network eavesdropper?

In other words, consider a network monitoring box that can see all the packets (but doesn't know any private keys and is only passively monitoring traffic). Can infer a reasonable guess at the version of the client that's being used, based only on what is visible in the network trace? For instance, can we guess what browser and what version is being used on the client side?

Of course TLS encrypts the data and payload, but there are some values that are sent in the clear: the set of ciphersuites suggested by the client, the client's date/time (first 4 bytes of client_random), a list of compression methods supported by the client, and a list of TLS extensions supported by the client, and of course the order of values in each of these lists. Is there enough variation here to infer which browser the user is using and distinguish among most major browsers? Is there enough to distinguish between browser versions?

I'm thinking of something analogous to p0f (which does passive OS fingerprinting), but here we're looking the unencrypted part of a HTTPS connection (rather than TCP headers), and here the goal is to infer the browser/HTTPS client used by the client host (rather than to infer the OS used by the client).

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 1
    [HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting (2015)](http://is.muni.cz/repo/1299983/https_client_identification-paper.pdf), [ssllabs - Passive SSL Client Fingerprinting (2012)](https://github.com/ssllabs/research/wiki/Passive-SSL-Client-Fingerprinting). The latter also includes passive SSL fingerprinting for p0f. – Steffen Ullrich Jun 17 '16 at 05:44
  • @SteffenUllrich, wow, that's perfect and exactly the sort of thing I was looking for! Care to post an answer with that, so I can upvote & accept that? – D.W. Jun 17 '16 at 05:52
  • I've only had a look at the first paper a while ago and do not know sufficient details anymore to write a good answer. But If you take a fresh look at these literature maybe you could write the answer yourself :) – Steffen Ullrich Jun 17 '16 at 05:55

3 Answers3

2

Lee Brotherston spoke at DerbyCon 2015 on Stealthier Attacks and Smarter Defending with TLS Fingerprinting -- slides -- video.

He also released code to go along with the talk -- https://github.com/LeeBrotherston/tls-fingerprinting/tree/master/fingerprintls

The below is taken from his website -- http://blog.squarelemon.com/tls-fingerprinting/

Transport Layer Security (TLS) provides security in the form of encryption to all manner of network connections from legitimate financial transactions, to private conversations, and malware calling home. The inability for an eavesdropper to analyze this encrypted traffic protects its users, whether they are legitimate or malicious. Those using TLS operate under the assumption that although an eavesdropper can easily observe the existence of their session, its source and destination IP addresses, that the content itself is secure and unreadable without access to cryptographic keying material at one or both ends of the connection. On the surface this holds true, barring any configuration flaws or exploitable vulnerabilities. However, using TLS Fingerprinting, it is easy to quickly and passively determine which client is being used, and then to apply this information from both the attacker and the defender perspectives.

[...]

FingerprinTLS

FingerprinTLS is designed to rapidly identify known TLS connections and to fingerprint unknown TLS connections. Input is taken either via live network sniffing or reading a PCAP file. Output for recognized connections is (currently) in human readable form and for unknown fingerprints in the JSON format used for the fingerprint definitions.

Fingerprints which are generated can be exported as a C struct by Fingerprintout and compiled back into FingerprinTLS to enable detecting in future instances.

Lee demonstrates how easy it is to fingerprint clients by the TLS signatures in a later talk he did at SecTor CA -- http://www.slideshare.net/LeeBrotherston/tls-fingerprinting-sectorca-edition -- be sure to check out slides 66 and 69-70.

fingerprintls -i en0 -s

He also shows how to import new signatures here -- https://gist.github.com/LeeBrotherston/1a0ae1aedd968af1fce3

Another demonstration shows how to leverage the Berkeley Packet Filter (BPF) from other tools and frameworks such as Wireshark, tcpdump, and/or libpcap -- https://gist.github.com/LeeBrotherston/92cc2637f33468485b8f

Finally, Lee analyses a sample pcap from the Pokemon Go video game off an Android device -- https://gist.github.com/LeeBrotherston/5cca4b372277d7c6a049b26f87544351

Certainly older methods described by some of the other answers here may still be relevant, but I do suggest you check out the work above. For more on the work that SSLLabs did, check out -- https://github.com/ssllabs/sslhaf -- which is an Apache module for passive SSL client fingerprinting

Community
  • 1
atdre
  • 18,885
  • 6
  • 58
  • 107
0

Yes, you can perform some fingerprinting of SSL traffic. Although you may find fingerprinting a client hard as most of them will be using one of the common libraries such as openssl. So you may be able to fingerprint different versions of these libraries as opposed to curl vs firefox vs wget.

wireghoul
  • 5,745
  • 2
  • 17
  • 26
  • Firefox uses Mozilla's NSS (network security services) not OpenSSL. curl and wget can use _at least_ OpenSSL GnuTLS or NSS at the option of the person who compiles them (for a packaged version the person who builds the package) and I believe curl has additional though less often used options. – dave_thompson_085 Jun 17 '16 at 10:19
0

Yes. It's possible to fingerprint clients in this way. There are even some existing tools that implement this.

However, it appears to not be very accurate. It might be able to recognize a major browser type (e.g., Firefox, Chrome, Safari), but it's unlikely to be able to accurately identify the version number, and any fingerprints obtained in this way have a significant chance of being ambiguous. It appears that there will often be multiple clients that could be consistent with the observed SSL trace, and you typically get only a few bits of entropy in this way.

The p0f tool includes support for inferring the TLS client based on a trace, using a database of fingerprints. You can find descriptions of how it works on SSL Labs' github page.

The following paper also discusses experiments to fingerprint TLS clients in this way:

Martin Husák, Milan Čermák, Tomáš Jirsı́k, Pavel Čeleda. HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting. URASIP Journal on Information Security, 2016

D.W.
  • 98,420
  • 30
  • 267
  • 572