Hi Thierry > Le 25 févr. 2017 à 13:01, [email protected] a écrit : > > Hi all, > > On Thu, 9 Feb 2017 07:37:51 +0100 > Willy Tarreau <[email protected]> wrote: > >> Hi Olivier, >> >> On Sat, Feb 04, 2017 at 11:52:30AM +0100, Olivier Doucet wrote: >>> Hello, >>> >>> I'm trying to capture the cipher suites sent by browser when negociating >>> the encryption level with HAProxy. >>> Digging into the haproxy doc, I can already find the TLS version and cipher >>> used (variables %sslc and %sslv), but not the complete list of ciphers sent >>> by the browser. >>> >>> Why such information ? This could be used as a method of fingerprintin ! >>> For example, finding malware that emulates a browser. Such malwares could >>> be spotted by comparing the user-agent field (on http level) with the >>> cipher suites used (and how the are ordered) and see if they match. An >>> example of implementation could be found here : >>> https://www.securityartwork.es/2017/02/02/tls-client-fingerprinting-with-bro/ >> >> That's an interesting idea! I'm not sure how accurate it can be since >> users can change their ciphers in their browser's config, and even the >> list of negociated TLS versions (I do it personally). > > > Yes, it is interesting ! > > >>> Is this even possible with HAProxy ? >> >> I'm not sure. I don't even know if openssl exposes this. However if you >> want to do this on the TCP connection only (without deciphering), you >> could possibly extend the SSL client hello parser to emit the list of >> such ciphers as a string. > > > The patch implementing this idea is in attachment. It returns the > client-hello cioher list as binary, hexadecimal string, xxh64 and with > the decoded ciphers.
xxh64 is not a fingerprint class algorithme, sha256 should be use. Manu
