Hi Илья, Well, JA3 is one the approaches which seems to be a "standard" our there. If you want to build your own you are still able to do so if you wish, however using a "standard" gives you a benefit of interoperability between different software (eg. JA3 on Nginx is the same JA3 on HAProxy) and ability to exchange information in a unified manner (eg. somebody posts JA3 fingerprint of some malware which you can block right away without a need of discovering it). Regards,
Marcin Deranek On Mon, Jul 12, 2021 at 7:37 PM Илья Шипицин <chipits...@gmail.com> wrote: > 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 >> <https://urldefense.com/v3/__https://github.com/salesforce/ja3__;!!FzMMvhmfRQ!_kUdt3LbsvygC0QjXBrvhTfZfa8a50VMpTB_iWOVP3m7HA7HD9Jy41snhTOKb2EYjKpf$> >> >> -- Marcin Deranek Senior Site Reliability Engineer [image: Booking.com] <https://www.booking.com/> Making it easier for everyone to experience the world. -- Marcin Deranek Senior Site Reliability Engineer [image: Booking.com] <https://www.booking.com/> Making it easier for everyone to experience the world.
