On 04/25/2014 12:50 AM, Carlos Garza 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.
This is a nice approach, as it eliminates the need to decrypt/encrypt on
the load balancer. I know that HAProxy has the ability to do this, so
it's definitely possible.
I do recall reading that the session ID isn't always sent as a part of
the client hello, so you would need to check the server hello as well.
If there is a blueprint on this, it would be good to make sure it
mentions that the server hello should be checked as well.
>
> 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.
One other use-case that calls for re-encrypting on the load balancer is
when you want to use different certificates on the backend network (such
as a completely separate internal PKI).
I wrote up some thoughts on SSL/TLS with load balancers for the API
endpoints a few weeks ago. It wasn't related to LBaaS, but I think it's
applicable. It specifically discusses affinity via SSL/TLS session ID
as well as separate backend PKI use cases:
https://blog-nkinder.rhcloud.com/?p=7
I think the important take away is that everyone has different security
requirements, which requires flexibility. There are arguments to be
made for termination at the load balancer, passing SSL/TLS through the
load balancer, and re-encryption at the load balancer. Providing
support for all of these should be the goal.
Thanks,
-NGK
>
>
>
> 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
> 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
