Have been wondering about if/how i could persist ssl sessions between
servers myself if i ever need it.
And found the concept of a SSL-session-id rather promising, then after
looking into how to use it and its reliability i found some articles
saying it might not be wise..
"SSL persistence was suddenly rendered inoperable" (in IE5)
"SSL stickiness is generally deemed unreliable."
"SSL stickiness is not recommended due to the numerous limitations that
can break client persistence"
Also one might need to enforce on the backend webservers that SSLv2 is
NOT used. ("SSLv2 places the session ID within the encrypted data"
according to the Cisco doc)
So now the question arises, are current browsers (including on mobile
devices) all sending the same SSL-session-ID properly during a hour of
'shopping'? Or are these described issues not currently applicable
anymore with recent software/devices?
I'm a bit doubtful if using ssl-session-id is actually a good way to
enforce persistence. Or should one try to avoid it with ssl-offloading
even though that puts more processing on a single haproxy instance thats
more difficult to scale up.. And puts all certificates in a 'central'
place which has some other security considerations..
I'm afraid i there are more questions than answers in my mail, but at
least its some stuff to think about..
For myself its currently not a problem. In my small test with 1.5dev21
ssl-persistence seemed to work ok. Though only 1 client pc, with 2
browsers running and hitting F5 a lot, so hardly representative for a
Still thought what i found might be useful for others.
Lukas Tribus schreef op 3-1-2014 22:41:
Many thanks for your replay. This thing is more stranger i downloaded and
compiled serverl versions of HAproxy 1.5.x.x and the result was alwase the
I experimented with following versions
At first i testing with
After i tested with these
latest downloded was haproxy-ss-LATEST.tar.gz from
All the time the result was same
Well, your make line looks very specific, whats the reason you use those
CFLAGS manually and don't use on the other hand a specific TARGET?
I suggest you give this a try:
make clean; make TARGET=linux2628 CPU=native USE_PCRE=1 USE_OPENSSL=1 \
With the custom make TARGET, you are not using epoll, falling back to
the slower poll().
This shouldn't make any difference regarding the ssl affinity though.
Regarding that, your configuration looks ok, and you have tested a
different releases, which make me think the issue may not be in haproxy.
How do you know HAProxy doesn't maintains the correct affinity? Are
you tcpdumping the frontent traffic? Are you sure your backend servers
have an session cache enabled and working?