Capturing browser TLS cipher suites

[Olivier Doucet]

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/


Is this even possible with HAProxy ?

Thanks all

Olivier

Re: Propagating agent-check weight change to tracking servers

[Michał]

Hi,
I checked it and during synthetic tests it worked. I use same
mechanism as origin agent-check, so it's ready to merge.

It doesn't need to be backported.

2017-01-27 15:38 GMT+01:00 Michał :

> Hello,
>
> So here's patch, which includes all functionalities I think about.
> It propagates the response for every tracking server without changing it
> and without intercepting it. In my opinion we should propagate relative
> and absolute weights, because if you use weight=0 server's to offload
> checks then you can send relative weight change and 0 will stay where it
> is.
>
> Regards,
> Michał
>
>
> 2017-01-20 10:54 GMT+01:00 Willy Tarreau :
>
>> Hi Michal,
>>
>> On Thu, Jan 19, 2017 at 11:45:57PM +0100, Micha?? wrote:
>> > Hello,
>> >
>> > We use track's in haproxy to minimize check traffic in some situations
>> and
>> > after my last patch we are probably going to switch to agent-checks for
>> > live management of weights and statuses. One problem I see now - track
>> > don't propagate weight setting to trackers, so if we set agent-check on
>> > track we can manage status only.
>> >
>> > My first PoC solution works good, so I thought about introducing
>> something
>> > like agent-track or track-agent directive set on backends (or maybe it
>> > should be default, non-configurable behaviour) to propagate agent-check
>> > responses from main check to all tracking backends. Both default
>> behaviour
>> > and directive approach are small changes in code, but a little bigger in
>> > functionality.
>> >
>> > In my opinion if we set agent-check on backend which is tracked by
>> others -
>> > it should propagate agent-check weight response to those tracking
>> backend
>> > and set weight on them too. Configurable or not - it will be good
>> feature.
>>
>> I think we at least propagate the DRAIN state which is equivalent to
>> weight == 0. If so I too think we should propagate *relative* weights.
>> Agent-checks can return a relative weight (eg: 50%, 100%, 150%) or an
>> absolute weight (eg: 10, 20). If you have two farms configured like this :
>>
>>backend farm1
>>  server new1 1.1.1.1:8000 weight 10 agent-check
>>  server new2 1.1.1.2:8000 weight 10 agent-check
>>
>>backend farm2
>>  server new1 1.1.1.1:8000 weight 20 track farm1/new1
>>  server new2 1.1.1.2:8000 weight 20 track farm1/new2
>>  server old1 1.1.1.3:8000 weight 10 check
>>  server old2 1.1.1.4:8000 weight 10 check
>>
>> Then you want the weight changes on farm1 to be applied proportionally
>> to farm2 (ie: a ratio of the configured absolute weight, which is iweight
>> IIRC).
>>
>> Otherwise that sounds quite reasonable to me given that the agent-check's
>> purpose is to provide a more accurate vision of the server's health, and
>> that tracking is made to share the same vision across multiple farms.
>>
>> Regards,
>> Willy
>>
>
>
>