[prev in list] [next in list] [prev in thread] [next in thread] 

List:       haproxy
Subject:    Re: Sticking on req_ssl_sni
From:       Baptiste <bedis9 () gmail ! com>
Date:       2013-02-28 7:38:50
Message-ID: CAODHi7q_65uuwFgpvM-DMKPCedE2yngvs34XdJw=-mN9LYbJKQ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Feb 27, 2013 at 3:00 PM, Robbert van Waveren <robbert1@gmail.com> wrote:
> Hi,
> 
> Ive got the following use-case that I cant seem to solve.
> 
> Problem:
> sticky session load balancing client-to-server SSL traffic without
> decrypting it
> assumption is that source ip and sslid can't be used as there are less
> clients then servers in my scenario.
> 
> My current solution (that does not work) is the following:
> using an alias of the java sessionid as subdomainname within the request
> and thus allowing HAProxy to see some per session unique id using SNI and
> stick on that.
> Both the clients and the servers run java 7 so they should be SSL SNI
> capable.
> 
> My problem is that currently "stick on req_ssl_sni" does not seem to be
> supported:
> 'stick': unknown fetch method 'req_ssl_sni'
> 
> 
> example hostname pattern:
> somesession1.myserver.local
> somesession2.myserver.local
> somesession3.myserver.local
> somesession4.myserver.local
> 
> my current configuration:
> listen sticky_server_to_server_ssl
> mode tcp
> bind :1000
> balance roundrobin
> 
> tcp-request inspect-delay 5s
> tcp-request content accept if { req_ssl_hello_type 1 }
> 
> stick-table type string len 20 size 2m expire 60m
> stick on req_ssl_sni
> 
> server srv1 10.0.0.1:2000 weight 1 maxconn 100 check
> server srv2 10.0.0.2:2000 weight 1 maxconn 100 check
> 
> Are there any obvious answers/solutions to this that could help me?
> If not, does my solution make sense to support in HAProxy?
> 
> Considering HAProxy does support sticking on payload, could I perhaps use
> that for this:
> acl clienthello req_ssl_hello_type 1
> stick-table type string len 20 size 2m expire 60m
> stick on payload(...) if clienthello
> 
> 
> Kind regards,
> 
> Robbert
> 

Hi Robbert,

first of all, in order to do this, you must have a wildcard
certificate, otherwise your client will get warnings (I don't know how
you can manage such warnings in your Java client code).
Second, you want to do persistence on an information provided by the
client, BUT HAProxy can't learn it on the fly from the server first,
which means that HAProxy may send the first and the second request
from the same session to 2 different servers. but from request #2, you
will have the persistence.
the diagram bellow shows what happens:
1. client to haproxy to server on https://domain.com with SNI domain.com
2. server answers "come back to clientX.domain.com"
3. client to haproxy with https://clientX.domain.com + SNI clientX.domain.com
==> there are no link between requests from #1 and #3.
so at #3, haproxy may choose a different server from #1, but will
store clientX.domain.com in the stick table
then whenever clientX.domain.com will get connected again, then
HAProxy will be able to maintain persistence and redirect this user to
the same server forerver (until expire timeout in the stick table
actually).

More about load-balancing and persistence:
http://blog.exceliance.fr/2012/03/29/load-balancing-affinity-persistence-sticky-sessions-what-you-need-to-know/


Last but not least, you should avoid persistence on the first domain,
because you may redirect all first requests to a single server, making
it to generate symmetric keys which takes a huge amount of CPU
resources (furthermore if your cert is big: 2K or more)... !

Baptiste


[prev in list] [next in list] [prev in thread] [next in thread]