I mis quoted it should be in RFC 5246 not 5264.
On Apr 25, 2014, at 2:50 AM, Carlos Garza
<carlos.ga...@rackspace.com<mailto:carlos.ga...@rackspace.com>> wrote:
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
<sbaluk...@bluebox.net<mailto:sbaluk...@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.varde...@rackspace.com<mailto:trevor.varde...@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@lists.openstack.org<mailto:OpenStack-dev@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@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
