4 ms·

I thought the handshake phase that sends the client options -IS- the fingerprinting phase? Which means there are only 15-35 total fingerprints for that session,

I thought the handshake phase that sends the client options -IS- the fingerprinting phase? Which means there are only 15-35 total fingerprints for that session, no? I sense I'm missing something else... I mean, what else do you permute? The cipherstrings are already the permuted combinations of the crypto primitives.

pimterry 5y ago
There's one fingerprint per TLS session. It's clearer with a worked example. Let's say you send a client hello like this: TLS: 1 Ciphers: A, B, C Extensions: ExtensionX: ... ExtensionY: ... ExtensionZ: ... That gets converted into a string like "1-A,B,C-X,Y,Z", and then hashed with MD5 to get a value like "41b2054b6a0a7549fa963b232226f6ae". For every single server you talk to, those values will be the same, we'll get the same fingerprint, and so this distinctively identifies TLS connections made by this client. Another client might instead send: TLS: 1 Ciphers: C, B, A Extensions: ExtensionX: ... ExtensionY: ... ExtensionZ: ... That becomes a string like "1-C,B,A-X,Y,Z", which gets hashed to a fingerprint like "ae76e4566b036882147de2f7feddad4a". That gives us a totally different unique id, with the same ciphers but in a different order. (This is pseudocode of course - the actual fingerprints have a few more params and use the number ids for each cipher and extension instead of strings, but it's equivalent) Here, with 3 ciphers in two different orders, we've seen two different fingerprints already. With those three ciphers alone, there's actually 6 (3 factorial) possible permutations - i.e. a client could order those ciphers any one of 6 different ways, and each ordering has a different fingerprint. If you have 4 ciphers, there's 24 possible orderings, 6 gives 720, 10 gives 3.6 million, and this goes up very rapidly, so that for a more realistic set of 20 ciphers there's 2 * 10^18 possible orderings, each one of which gives a unique fingerprint, even before we start talking about extension order. Does that make more sense? The full algorithm is here: https://github.com/salesforce/ja3#how-it-works https://github.com/salesforce/ja3#how-it-works

pimterry 5y ago

There's one fingerprint per TLS session. It's clearer with a worked example. Let's say you send a client hello like this: TLS: 1 Ciphers: A, B, C Extensions: ExtensionX: ... ExtensionY: ... ExtensionZ: ... That gets converted into a string like "1-A,B,C-X,Y,Z", and then hashed with MD5 to get a value like "41b2054b6a0a7549fa963b232226f6ae". For every single server you talk to, those values will be the same, we'll get the same fingerprint, and so this distinctively identifies TLS connections made by this client. Another client might instead send: TLS: 1 Ciphers: C, B, A Extensions: ExtensionX: ... ExtensionY: ... ExtensionZ: ... That becomes a string like "1-C,B,A-X,Y,Z", which gets hashed to a fingerprint like "ae76e4566b036882147de2f7feddad4a". That gives us a totally different unique id, with the same ciphers but in a different order. (This is pseudocode of course - the actual fingerprints have a few more params and use the number ids for each cipher and extension instead of strings, but it's equivalent) Here, with 3 ciphers in two different orders, we've seen two different fingerprints already. With those three ciphers alone, there's actually 6 (3 factorial) possible permutations - i.e. a client could order those ciphers any one of 6 different ways, and each ordering has a different fingerprint. If you have 4 ciphers, there's 24 possible orderings, 6 gives 720, 10 gives 3.6 million, and this goes up very rapidly, so that for a more realistic set of 20 ciphers there's 2 * 10^18 possible orderings, each one of which gives a unique fingerprint, even before we start talking about extension order. Does that make more sense? The full algorithm is here: https://github.com/salesforce/ja3#how-it-works https://github.com/salesforce/ja3#how-it-works