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.ga...@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 <sbaluk...@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 we
b 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@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
