3 ms·

That permutation list is too comprehensive. In reality, the ciphersuite that is chosen is far more limited based on current best practices. For example, up unti

• pimterry 5y ago
  The cipher list here is the full list _offered_ by the client, this isn't about the final single cipher that's selected and used. Yes, most aren't used for many real sessions, but they're all still supported and available for fingerprinting. The selected cipher isn't relevant. The quadrillion total meanwhile it the total number of _permutations_ not the number of ciphers. In local testing, every single client (e.g. curl, Firefox, chrome) I've seen sends between 15 to 35 options in every client hello, which already gives you a huge number of possible permutations, though you couldn't really reorder them completely freely without real security implications. As in the article, the extensions are more interesting for increasing permutations though, since order there really is totally arbitrary.
  • SavantIdiot 5y ago
    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