Fingerprinting Tor relays with JARM & RECAP

Fingerprinting Tor relays with JARM & RECAP

In this article we will discuss a interesting way to fingerprint Tor relays using JARM and build a small application to fingerprint relays.

sweat-fingerprint on a CD-cover photographed in reflexlight
Photo by Immo Wegmann / Unsplash

Last year Salesforce released JARM a Transport Layer Security (TLS) server fingerprinting tool.

JARM hashes can be used to:

  • Quickly verify that all servers in a group have the same TLS configuration.
  • Group disparate servers on the internet by configuration, identifying that a server may belong to Google vs. Salesforce vs. Apple, for example.
  • Identify default applications or infrastructure.
  • Identify malware command and control infrastructure and other malicious servers on the Internet.

JARM basically works by sending probes and then hashing the Server Hello responses.

Some JARM hashes for Tor relays

Whilst working on new and interesting ways to fingerprint hidden services on Tor I've stumbled across JARM. I decided to take a look at fingerprinting Tor relays for the following reasons.

  • Are there any non-standard relays running interesting TLS implementations?
  • Can we find any malicious relays and fingerprint them to find other malicious relays?
  • What does the Tor network look like from a TLS perspective.

As such RECAP was born! RECAP is a small Go based program that uses some code from Jarm-Go to automatically fingerprint all known Tor relays, it does this by asking onionoo for a list of Tor relays and their OR ports, and it then launches JARM probes at their OR ports to fingerprint their TLS implementation and return these over stdout in a comma-delimited format.

When writing this article the top 3 JARM hashes for Tor relays are as follows

  • 2ad2ad16d2ad2ad00042d42d000000332dc9cd7d90589195193c8bb05d84fa
  • 2ad2ad16d2ad2ad22c42d42d000000d342d5966a57139eeaff9f8bc4841b25
  • 2ad2ad16d2ad2ad22c2ad2ad2ad2adce2e4c8c53174ecbf5529ce7584d5518

You can obtain RECAP over at Github

RECAP will eventually be integrated into OSINT.PARTY allowing researchers to view past JARM hashes for relays, and identify interesting relays.

I'm also planning to publish a follow-up article at a later stage detailing some of my findings by running RECAP on Tor relays!


Shortly after writing this article I realised that together with other metadata JARM can be used to identify potential Tor bridges.

  • Tor bridges always have their ORport exposed
  • Tor bridges do not show up on ExoneraTor
  • Tor bridges do not show up in the network consensus
  • Tor bridges, just like Tor relays have a easily identifyable TLS certificate with random domains of a known length.
  • Tor bridges usually match a small set of JARM hashes

Whilst JARM alone is not enough to identify a Tor bridge one can use JARM to quickly select hosts out a internet-wide scan, and then apply the rest of the checks to determine how likely a given host is to be a Tor bridge.

Currently there is no way to probe obfs4 bridges directly, but there are ways to identify the traffic as explained in HackerFactor's blog.

Tor 0day: Burning Bridges - The Hacker Factor Blog

I'm also on Twitter. Feel free to give me a follow!

Show Comments