Open Stack

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 <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
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>