Open Stack

Hi,

The work on SSL termination has started and is very near completion.
the blue print is in https://blueprints.launchpad.net/neutron/+spec/lbaas-ssl-termination and wiki is in https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL
Do you see anything missing there?


Regards,
	-Sam.




-----Original Message-----
From: Carlos Garza [mailto:carlos.garza at rackspace.com] 
Sent: Saturday, April 19, 2014 2:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question


On Apr 18, 2014, at 10:21 AM, Stephen Balukoff <sbalukoff at bluebox.net> wrote:

> Howdy, folks!
> 
> Could someone explain to me the SSL usage scenario where it makes 
> sense to re-encrypt traffic traffic destined for members of a back-end 
> pool?  SSL termination on the load balancer makes sense to me, but I'm 
> having trouble understanding why one would be concerned about then 
> re-encrypting the traffic headed toward a back-end app server. (Why 
> not just use straight TCP load balancing in this case, and save the 
> CPU cycles on the load balancer?)
> 

1. Some customers want their servers to be external from our data centers for example the loadbalancer is in Chicago with rackspace hosting the loadbalancers and the back end pool members being on Amazon AWS servers. (We don't know why they would do this but a lot are doing it). They can't can't simply just audit the links between AWS and our DataCenters for PCI lots of backbones being crossed. so they just want encryption to their backend pool members. Also take note that amazon has chosen to support encryption http://aws.amazon.com/about-aws/whats-new/2011/10/04/amazon-s3-announces-server-side-encryption-support/
They've had it for a while now and for what ever reason a lot of customers are now demanding it from us as well.  

I agree they could simply just use HTTPS load balancing but they seem to think providers that don't offer encryption are inferior feature wise.

2. User that are on providers that are incapable of "One Armed With Source Nat" load balancing capabilities (See link below) are at the mercy of using X-forwarded for style headers to determine the original  source of a connection. (A must if they want to know where abusive connections are coming from). Under traditional NAT routing the source ip will always be the loadbalancers ip so X-Forwarded for has been the traditional method of show the server this(This applies to HTTP load balancing as well). But in the case of SSL the loadbalancer unless its decrypting traffic won't be able to inject these headers in. and when the pool members are on an external network it is prudent to allow for encryption, this pretty much forces them to use a trusted LoadBalancer as a man in the middle to decrypt add X-forwarded for, then encrypting to the back end. 

http://docwiki.cisco.com/wiki/Basic_Load_Balancing_Using_One_Arm_Mode_with_Source_NAT_on_the_Cisco_Application_Control_Engine_Configuration_Example


3. Unless I'm mistaken it looks like encryption was already apart of the API or was accepted as a requirement for neutron lbaas.
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL#Current_design
is this document still valid?

4. We also assumed we were expected to support the use cases described in
https://docs.google.com/document/d/1Ewl95yxAMq2fO0Z6Dz6fL-w2FScERQXQR1-mXuSINis/edit?pli=1
where case 7 specifically is asking for Re-encryption.


> We terminate a lot of SSL connections on our load balancers, but have 
> yet to have a customer use this kind of functionality.  (We've had a 
> few ask about it, usually because they didn't understand what a load 
> balancer is supposed to do-- and with a bit of explanation they went 
> either with SSL termination on the load balancer + clear text on the 
> back-end, or just straight TCP load balancing.)

    We terminate a lot of SSL connections on our loadbalancers as well and we get a lot of pressure for this kind of functionality.  I think you have no customers using that functionality because you are unable to offer it  which is the case for us as well. But due to a significant amount of pressure we have a solution already ready and waiting for testing on our CLB1.0 offering. 

    We wished this was the case for us that only a few users are requesting this feature  but we have customers that really do want their backend pool members on a separate non secure network or worse want this as a more advance form of HTTPS passthrough(TCP load balancing as your describing it). 

    Providers may be able to secure their loadbalancers but they may not always be able to secure their back and forward connections. Users still want end to end encrypted connectivity but want the loadbalancer to be capable of making intelligent decisions(requiring decryption at the loadbalancer) as well as inject useful headers going to the back end pool member still need encryption functionality.

     When your customers do Straight TCP load balancing are you noticing you can only offer IP based session persistence at that point? If you only allow ip based persistence customers that share a NAT router will all hit the same node every time. We have lots of customers behind corporate NAT routers and they notice very quickly that hundreds of clients are all being shoved onto one back end pool member. They as of now only have the option to turn off session persistence but that breaks applications that require locally maintained sessions. We could offer TLS session based ID and we are planning to support this in the future for our CLB1.0 offering ,but we are not blind to the fact that lots of browser have a short interval before they attempt to generate a new TLS Session id :(. Like I said alot of our customers (The PHP ones especially) will use file based sessions on their backend pool member servers instead of sharing a database between pool members for sessions(Granteed most web developers these days would opt to use a database for sessions we do have a lot that feel its expensive to make a database query on every cookie that comes in and insist on store sessions in local files on the server.) These users absolutely need session cookie based persistence to be handled on the loadbalancer as switching to a different pool member breaks their session on the bake end. SSL Cookie based session persistence requires Cookie header injection. So for your TCP based SSL users you can't officer this.  Re-encryption may be ugly but its the awkward solution



Who offers re-encryption?

Amazon http://aws.amazon.com/about-aws/whats-new/2011/10/04/amazon-s3-announces-server-side-encryption-support/
BigIps F5 LoadBalancers http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_http_ssl.html
A10 LoadBalaners http://www.a10networks.com/resources/files/CS-Earth_Class_Mail.pdf
Netscaler http://support.citrix.com/proddocs/topic/netscaler-traffic-management-10-map/ns-ssl-offloading-end-to-end-encypt-tsk.html
Finally Stingray https://splash.riverbed.com/thread/5473

Stingray being the solution we use at backspace.

Carlos D. Garza
Rackspace.


> 
> 
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
> _______________________________________________
> OpenStack-dev mailing list
> 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