JA3 is good approach, but it lacks few ideas. we fingerprinted clients by "ssl ciphers" (all ciphers sent by client in Client Helo) + "all client curves" (also sent by client).
however you approach is flexible enough to be extended. пн, 12 июл. 2021 г. в 20:03, Marcin Deranek <marcin.dera...@booking.com>: > Hi, > > Over a past few weeks I have been working on implementing JA3 compatible > TLS Fingerprinting[1] in the HAProxy. You can find the outcome in > attachments. Feel free to review/comment them. > Here are some choices I made which you should be aware of: > - I decided to go with a "modular" approach where you can build JA3 > compatible fingerprint with available fetchers/converters rather than a > single JA3 fetcher. This makes approach more "reusable" in some other > scenarios. > - Each Client Hello related fetcher has option to include/exclude GREASE > (RFC8701) values from the output. This is mainly for backward compatibility > and ability to get "pure" data. I suspect in most cases people do not want > GREASE values to be present in the output (which is not the case right now > for cipherlist fetchers). > - exclude_grease function allocates trash on demand depending on GREASE > (RFC8701) values position in the list. We can get away without creating > trash buffer if GREASE values are present at the very beginning and/or the > very end of the list. I decided to allocate trash buffer only when it's > really needed, so that's why it's creation is "hidden" inside exlude_grease > function. > - Now ssl_capture (next to ciphersuite) contains data about extensions, ec > ciphers etc. One of the reasons I decided to merge all those values in a > single ssl_capture buffer is easier control of buffer size limit. I think > it's beneficial to have a single buffer limit for all those values rather > than separate values for each. Having said that probably > tune.ssl.capture-cipherlist-size needs to change it's name to eg. > tune.ssl.capture-buffer-limit to better reflect it's function. > - Instead of creating a new converter I decided to extend existing hex > conveter to provide a similar functionality to bin2int. I thought this > makes more sense as extended hex converter is fully backward compatible. It > has to be noted that extended hex converter is not strictly necessary to > produce JA3 TLS Fingerprint, but but might useful in some other scenarios. > > Example usage: > http-request set-header X-SSL-JA3 > %[ssl_fc_protocol_hello_id],%[ssl_fc_cipherlist_bin(1),bin2int(-,2)],%[ssl_fc_extlist_bin(1),bin2int(-,2)],%[ssl_fc_eclist_bin(1),bin2int(-,2)],%[ssl_fc_ecformats_bin,bin2int(-,1)] > http-request set-header X-SSL-JA3-Hash > %[req.fhdr(x-ssl-ja3),digest(md5),hex] > > Question: I noticed that during Client Hello parsing we calculate xxh64 > right away and store it. Isn't better to calculate it when it's actually > used? > Regards, > > Marcin Deranek > > [1] https://github.com/salesforce/ja3 > >
