Open Stack

    Trevor is referring to our plans on using the SSL session ID of the ClientHello to provide session persistence.
See RFC 5264 section 7.4.1.2 which sends an SSL session ID in the clear (Unencrypted) so that a load balancer with out the decrypting key can use it to make decisions on which
back end node to send the request to.  Users browsers while typically use the same session ID for a while between connections.

Also note this is supported in TLS 1.1 as well in the same section according to RFC 4346. And in TLS 1.0 RFC2246 as well.

    So we have the ability to offer http cookie based persistence as you described only if we have the key but if not we can also offer SSL Session Id based persistence.



On Apr 24, 2014, at 7:53 PM, Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>> wrote:

Hi Trevor,

If the use case here requires the same client (identified by session cookie) to go to the same back-end, the only way to do this with HTTPS is to decrypt on the load balancer. Re-encryption of the HTTP request may or may not happen on the back-end depending on the user's needs. Again, if the client can potentially change IP addresses, and the session still needs to go to the same back-end, the only way the load balancer is going to know this is by decrypting the HTTPS request. I know of no other way to make this work.

Stephen


On Thu, Apr 24, 2014 at 9:25 AM, Trevor Vardeman <trevor.vardeman at rackspace.com<mailto:trevor.vardeman at rackspace.com>> wrote:
Hey,

I'm looking through the use-cases doc for review, and I'm confused about one of them.  I'm familiar with HTTP cookie based session persistence, but to satisfy secure-traffic for this case would there be decryption of content, injection of the cookie, and then re-encryption?  Is there another session persistence type that solves this issue already?  I'm copying the doc link and the use case specifically; not sure if the document order would change so I thought it would be easiest to include both :)

Use Cases:  https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis

Specific Use Case:  A project-user wants to make his secured web based application (HTTPS) highly available. He has n VMs deployed on the same private subnet/network. Each VM is installed with a web server (ex: apache) and content. The application requires that a transaction which has started on a specific VM will continue to run against the same VM. The application is also available to end-users via smart phones, a case in which the end user IP might change. The project-user wishes to represent them to the application users as a web application available via a single IP.

-Trevor Vardeman

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org<mailto:OpenStack-dev at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140425/720ebe54/attachment.html>