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) Thanks for those links. We can surely ignore (the major problem with) SSLv2 and IE5, both are EOL/EOS since at least a decade. We can probably ignore (the minor bug [1] in) IE6 and IE7 now, since even Windows XP users can upgrade to IE8 via windows update, and the bug is triggered in corner cases only. > 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? All desktop browser support SSL session ID reuse correctly, but it looks like this is not always the case on smartphones, as Vincent Bernat mentioned here [2]: > Surprisingly, Android 2.3.4 browser (as shipped by Cyanogen Mod) does > not support any session resume. Support for TLS tickets on the other hand is not that widely supported currently, with schannel (Internet Explorer and Safari on Windows) only introducing RFC5077 support in Windows 8. But TLS Tickets need to be disabled anyway, if you are relying on the session ID for persistence (this is important!). > I'm a bit doubtful if using ssl-session-id is actually a good way to > enforce persistence. Its probably not ideal and will not work in 100% of the use-cases. Terminating SSL on the load-balancer can be an option (but there are scalability concerns with it). Reverting back to good old source ip based persistence has problems on its own (clients changing IP addresses due to load-balanced NAT or networking changes from Wifi-to-Wifi or Wifi-to-3G). When your SSL terminating backend supports sharing of the session cache with other backends, for example via memcached, then you can workaround this problem [3]. Btw, any possibility to do this with HAProxy would be great. Vincent sums it up here [4]. Having said this, I do think session ID based persistence has its a valid use-case. Regards, Lukas [1] http://support.microsoft.com/kb/937480/en-us [2] http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html [3] https://github.com/bumptech/stud/pull/29 [4] http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html#web-server-support
