On Mon, 6 Mar 2017 14:54:44 +0100 Emmanuel Hocdet <[email protected]> wrote:
> 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. Hi Manu, My choice is driven regarding these hash algorithm elements: - The repartiion of the hash (and the collision risk) - The execution time. I choosed xxh64 because it is very quick, the repartion is good and the collision risk is low. Obviously sha1 is better because the collision risk is very low, but is very slow. So I prefer xxh64. I think that a low collision risk is acceptable because this hash is simply used for differenciating two different stack from two different client devices. If an attacker found two different cipher lists with the same xxh64, I dont care because this is not a risk. Maybe I can make this choice configurable, but it impact the memory allocation and implies a new "tune.*" directive. Thierry > Manu > > >
