Hi,
> And this program generated a file rfc5077-output-1389174665--p-4431- > 192.168.35.254.csv with following contet: This output is extremely useful. What it says is that session id caching works perfectly fine; as long as TLS ticket remains disabled on the client side. But when the client uses TLS Tickets, session cannot be resumed, and haproxy is roundrobin between the backends. > Jan 8 11:51:05 lb1 haproxy[22836]: 192.168.35.1:62488 > [08/Jan/2014:11:51:05.889] etlive_https etlive_https/etlive1 1/0/11 1853 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:05 lb1 haproxy[22836]: 192.168.35.1:62490 > [08/Jan/2014:11:51:05.900] etlive_https etlive_https/etlive1 1/0/43 347 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:05 lb1 haproxy[22836]: 192.168.35.1:62490 > [08/Jan/2014:11:51:05.900] etlive_https etlive_https/etlive1 1/0/43 347 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:05 lb1 haproxy[22836]: 192.168.35.1:62492 > [08/Jan/2014:11:51:05.944] etlive_https etlive_https/etlive1 1/0/40 347 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:05 lb1 haproxy[22836]: 192.168.35.1:62492 > [08/Jan/2014:11:51:05.944] etlive_https etlive_https/etlive1 1/0/40 347 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62494 > [08/Jan/2014:11:51:05.984] etlive_https etlive_https/etlive1 1/0/41 347 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62494 > [08/Jan/2014:11:51:05.984] etlive_https etlive_https/etlive1 1/0/41 347 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62496 > [08/Jan/2014:11:51:06.024] etlive_https etlive_https/etlive1 1/0/39 347 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62496 > [08/Jan/2014:11:51:06.024] etlive_https etlive_https/etlive1 1/0/39 347 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62498 > [08/Jan/2014:11:51:06.072] etlive_https etlive_https/etlive2 1/0/13 2032 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62498 > [08/Jan/2014:11:51:06.072] etlive_https etlive_https/etlive2 1/0/13 2032 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62500 > [08/Jan/2014:11:51:06.086] etlive_https etlive_https/etlive1 1/0/10 2032 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62500 > [08/Jan/2014:11:51:06.086] etlive_https etlive_https/etlive1 1/0/10 2032 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62502 > [08/Jan/2014:11:51:06.097] etlive_https etlive_https/etlive2 1/0/12 2032 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62502 > [08/Jan/2014:11:51:06.097] etlive_https etlive_https/etlive2 1/0/12 2032 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62505 > [08/Jan/2014:11:51:06.109] etlive_https etlive_https/etlive1 1/0/12 2032 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62505 > [08/Jan/2014:11:51:06.109] etlive_https etlive_https/etlive1 1/0/12 2032 -- > 0/0/0/0/0 0/0 > Jan 8 11:51:06 lb1 haproxy[22836]: 192.168.35.1:62507 > [08/Jan/2014:11:51:06.122] etlive_https etlive_https/etlive2 1/0/12 2032 -- > 0/0/0/0/0 0/0 > > These HAproxy log and rfc5077-client log files show where is no sticky > sessions usage and ssl session id changes ! Actually no, what the log shows is that in the first 9 requests everything goes to backend etlive1. Only in the second part (when TLS tickets are enabled on the client) the stickiness doesn't work - which is expected behavior. Try using Internet Explorer or Safari on Windows 7 or older, you will see that the session affinity works fine, because the ssl library used by those browser (schannel) doesn't support TLS Tickets. Only Windows 8 supports it. To fix this, we would need to disable TLS Tickets on the Apache backends. But from the documentation this seems to be supported only in Apache 2.4.8 or later in combination with OpenSSL 1.0.2 or later [1], even though disabling tickets with openssl is just about setting SSL_OP_NO_TICKET [2], available since openssl 0.9.8 (haproxy can do it [3]). So either there is some other way in Apache to disable tickets, I'm not sure (check with apache folks), or you can't use stickiness based on the SSL session ID (you will have to use source ip based load-balancing instead). Regards, Lukas [1] http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslopensslconfcmd [2] http://www.openssl.org/docs/ssl/SSL_CTX_set_options.html [3] http://haproxy.1wt.eu/git?p=haproxy.git;a=commitdiff;h=2d0c48268202690ee96bd6c6a91b5e353be13b14
