Hi,

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..

https://www.f5.com/pdf/white-papers/cookies-sessions-persistence-wp.pdf
"SSL persistence was suddenly rendered inoperable" (in IE5)

http://docwiki.cisco.com/wiki/Secure_Sockets_Layer_Persistence_Configuration_Example
"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 real environment...
Still thought what i found might be useful for others.

Greets PiBa-NL

Lukas Tribus schreef op 3-1-2014 22:41:
Hi,

Hello ,

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
same

I experimented with following versions

At first i testing with
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev21.tar.gz

After i tested with these
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev20.tar.gz
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev18.tar.gz
http://haproxy.1wt.eu/download/1.5/src/devel/haproxy-1.5-dev17.tar.gz

latest downloded was haproxy-ss-LATEST.tar.gz from
http://haproxy.1wt.eu/download/1.5/src/snapshot/

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 \
USE_ZLIB=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?


Regards,

Lukas                                   


Reply via email to