Hello ! I made some tests using the https://github.com/vincentbernat/rfc5077/blob/master/rfc5077-client.c compiled and linked programm to test my solution. Here are the results
I runned the programm ./rfc5077-client -p 4431 192.168.35.254 And this program generated a file rfc5077-output-1389174665--p-4431-192.168.35.254.csv with following contet: test;IP;try;version;cipher;compression;reuse;session id;master key;ticket;answer Without tickets;192.168.35.254;0;TLSv1;ECDHE-RSA-AES256-SHA;0;0;10668DFC46A6A953AE0954811FE5E4DEFCA5EEE19574F21160BC4E13256DCA74;18C79D3D50C419EAF6B99CCDEFCA3104325F7F657653F258D736266BAE4142ABE71447C17237607830F6CF7DC9C74242;0;HTTP/1.1 403 Forbidden Without tickets;192.168.35.254;1;TLSv1;ECDHE-RSA-AES256-SHA;0;1;10668DFC46A6A953AE0954811FE5E4DEFCA5EEE19574F21160BC4E13256DCA74;18C79D3D50C419EAF6B99CCDEFCA3104325F7F657653F258D736266BAE4142ABE71447C17237607830F6CF7DC9C74242;0;HTTP/1.1 403 Forbidden Without tickets;192.168.35.254;2;TLSv1;ECDHE-RSA-AES256-SHA;0;1;10668DFC46A6A953AE0954811FE5E4DEFCA5EEE19574F21160BC4E13256DCA74;18C79D3D50C419EAF6B99CCDEFCA3104325F7F657653F258D736266BAE4142ABE71447C17237607830F6CF7DC9C74242;0;HTTP/1.1 403 Forbidden Without tickets;192.168.35.254;3;TLSv1;ECDHE-RSA-AES256-SHA;0;1;10668DFC46A6A953AE0954811FE5E4DEFCA5EEE19574F21160BC4E13256DCA74;18C79D3D50C419EAF6B99CCDEFCA3104325F7F657653F258D736266BAE4142ABE71447C17237607830F6CF7DC9C74242;0;HTTP/1.1 403 Forbidden Without tickets;192.168.35.254;4;TLSv1;ECDHE-RSA-AES256-SHA;0;1;10668DFC46A6A953AE0954811FE5E4DEFCA5EEE19574F21160BC4E13256DCA74;18C79D3D50C419EAF6B99CCDEFCA3104325F7F657653F258D736266BAE4142ABE71447C17237607830F6CF7DC9C74242;0;HTTP/1.1 403 Forbidden With tickets;192.168.35.254;0;TLSv1;ECDHE-RSA-AES256-SHA;0;0;75B5DB2C1CFF3F6C6F6209ECDC62E36D2EE1ABEB9722CE31EFBE0FCD6A610DA8;6C8A8F6F771FCC23745382FFE884242C90620A9F85D790DC1E0FC8FFC3D2CD80A0AB95EFF92B5770591B66287B05BE51;1;HTTP/1.1 403 Forbidden With tickets;192.168.35.254;1;TLSv1;ECDHE-RSA-AES256-SHA;0;0;86B0A2F8572210D13F66DD68F203AC3D7CA589774D5E934C4A0F17B970673A2B;FD7B11CF0D133FA643B52EA380A2A6F115F9BC59D0B83668A557DBC75D4E0A12BE6267B65C08182086D6C4DA247EE527;1;HTTP/1.1 403 Forbidden With tickets;192.168.35.254;2;TLSv1;ECDHE-RSA-AES256-SHA;0;0;883934911C3720A2D4BC4CBCCFF2074B434CF50876BFF9037B3D67BE9A4C6ADF;57D27B61627ECEB8904127799B9952AA52A1D283EA26C6379C8E7858B0491FEAEB204425997AB60B2991EE2307C7C40C;1;HTTP/1.1 403 Forbidden With tickets;192.168.35.254;3;TLSv1;ECDHE-RSA-AES256-SHA;0;0;F0E7331632D10381D4D4B67DA1BDFFC1B1201F0747322A9F90EECEB5B05B0318;5C9F0F79AB3F5C380A51261975C819D1649D979EA084D257D2E68F405F42A2E7B5CA949FBC8F1EC877E64522A6F96129;1;HTTP/1.1 403 Forbidden With tickets;192.168.35.254;4;TLSv1;ECDHE-RSA-AES256-SHA;0;0;06321F2CABFFBD1BBAED6DE5890DE2C35B7687F4EF040762B10102E1DB790241;F34C3728959A1F7E37DFCB4C3C0E08BA518BA9D6E46538AB0B3A906CA991995C468365B411F19A81ED98BDDD16D3E037;1;HTTP/1.1 403 Forbidden Here is a HAproxy log which the usage of progrem rfc5077-client -p 4431 192.168.35.254 produced: 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 ! Here is my HAproxy vonfiguration again: global #stats socket /var/run/haproxy.sock mode 666 stats socket /var/run/haproxy.stat mode 666 log /dev/log local0 info log /dev/log local0 notice # log 127.0.0.1 local0 chroot /var/lib/haproxy maxconn 100000 maxpipes 30000 ulimit-n 500000 user root group haproxy daemon defaults log global option tcplog option dontlognull retries 3 option redispatch option splice-auto timeout connect 5000ms timeout client 50000ms timeout server 50000ms option tcp-smart-accept # option tcp-smart-connect frontend etlive_http bind 192.168.35.254:81,192.168.35.253:81 mode http redirect location https://eteenindus.mnt.ee/eteenused/main.jsf frontend etlive_https bind 192.168.35.254:4431,192.168.35.253:4431 option tcplog maxconn 10000 log global default_backend etlive_https backend etlive_https mode tcp # option ssl-hello-chk # option httpchk GET /test.html option tcplog balance roundrobin stick-table type binary len 32 size 30k expire 30m acl clienthello req_ssl_hello_type 1 acl serverhello rep_ssl_hello_type 2 # use tcp content accepts to detects ssl client and server hello. tcp-request inspect-delay 5s tcp-request content accept if clienthello # no timeout on response inspect delay by default. tcp-response content accept if serverhello # SSL session ID (SSLID) may be present on a client or server hello. # Its length is coded on 1 byte at offset 43 and its value starts # at offset 44. # Match and learn on request if client hello. stick on payload_lv(43,1) if clienthello # Learn on response if server hello. stick store-response payload_lv(43,1) if serverhello server etlive1 192.168.35.232:443 check maxconn 5000 server etlive2 192.168.35.233:443 check maxconn 5000 #### Lauri-Alo Adamson AS Andmevara -----Original Message----- From: Lukas Tribus [mailto:[email protected]] Sent: Sunday, January 05, 2014 9:57 PM To: Lauri-Alo Adamson; [email protected] Subject: RE: HA-Proxy version 1.5-dev21-51437d2 2013/12/29 sticky ssl sessons are not working in my environment Hi, > My web servers contain text file wich contain name of that server. > Then put following line to web browser https://X.X.X.X/index.txt and > browse this page it displays server name One server file index.txt > contains server name etee-live1 and other server the file contains > this server name etee-live2. If affinity works browser displays always > the same server name and then in the sticky tabel must contain one entry. > > But in my SSL affinity case web browser displays once one server name > and on the other refresh browser displays other server name . Then i > look sticky table it displays two entries but in then SSL affinity - > (SSL sticky session) case there must be one entry. > > My sticky table displys: > echo "show table etlive_https" | socat > unix-connect:/var/run/haproxy.stat stdio # table: etlive_https, type: > binary, size:30720, used:2 > 0x17eddd4: > key=7D4CD359DDAB9F3F7F976E7A995045670FFF0118FDDB72773165273BE6DA16FA > use=0 exp=1778829 server_id=2 > 0x17ee1d4: > key=905273E4AC943682F48106A6BD07777486F8FD60F8B80E4860FE7032F7D69DC2 > use=0 exp=1783937 server_id=1 That sounds like your apache backend server doesn't actually cache the session. > If undestood you correctly you suspect that SSL sessions are changing > all the time. What software is responsible changing SSL sessioon ID - > browser , Apache web server ?! The Apache backend server (the browsers you mentioned all reuse the SSL session ID by default). > Person who configred these apache server ensures that these things are > working Please double check with that person that the configuration directives SSLSessionCache [1] and SSLSessionCacheTimeout [2] are properly configured. It looks like Apache by default does not cache at all. Also you can try with Vincent's test tool at [3] whether session resumption is actually done or not. Regards, Lukas [1] http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessioncache [2] http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessioncachetimeout [3] https://github.com/vincentbernat/rfc5077/blob/master/rfc5077-client.c
