On Apr 18, 2014, at 12:36 PM, Stephen Balukoff
<[email protected]<mailto:[email protected]>> wrote:
Dang. I was hoping this wasn't the case. (I personally think it's a little
silly not to trust your service provider to secure a network when they have
root access to all the machines powering your cloud... but I digress.)
Part of the reason I was hoping this wasn't the case, isn't just because it
consumes a lot more CPU on the load balancers, but because now we potentially
have to manage client certificates and CA certificates (for authenticating from
the proxy to back-end app servers). And we also have to decide whether we allow
the proxy to use a different client cert / CA per pool, or per member.
If you choose to support re-encryption on your service then you are free to
charge for the extra CPU cycles. I'm convinced re-encryption and SslTermination
is general needs to be mandatory but I think the API should allow them to be
specified.
Yes, I realize one could potentially use no client cert or CA (ie. encryption
but no auth)... but that actually provides almost no extra security over the
unencrypted case: If you can sniff the traffic between proxy and back-end
server, it's not much more of a stretch to assume you can figure out how to be
a man-in-the-middle.
Yes but considering you have no problem advocating pure ssl termination for
your customers(Decryption on the front end and plain text) on the back end I'm
actually surprised this disturbs you. I would recommend users use Straight SSL
passthrough or re-enecryption but I wouldn't force this on them should they
choose naked encryption with no checking.
Do any of you have a use case where some back-end members require SSL
authentication from the proxy and some don't? (Again, deciding whether client
cert / CA usage should attach to a "pool" or to a "member.")
When you say client Cert are you referring to the end users X509 Certificate
(To be rejected by the backend server)or are you referring to the back end
servers X509Certificate which the loadbalancer would reject if it discovered
the back end server had a bad signature or mismatched key? I am speaking of the
case where the user wants re-encryption but wants to be able to install CA
certificates that sign backend servers Keys via PKIX path building. I would
even like to offer the customer the ability to skip hostname validation since
not every one wants to expose DNS entries for IPs that are not publicly
routable anyways. Unless your suggesting that we should force this on the user
which likewise forces us to host a name server that maps hosts to the X509s
subject CN fields. Users should be free to validate back end hostnames, just
the subject name and key or no validation at all. It should be up to them.
It's a bit of a rabbit hole, eh.
Stephen
On Fri, Apr 18, 2014 at 10:21 AM, Eichberger, German
<[email protected]<mailto:[email protected]>> wrote:
Hi Stephen,
The use case is that the Load Balancer needs to look at the HTTP requests be it
to add an X-Forward field or change the timeout – but the network between the
load balancer and the nodes is not completely private and the sensitive
information needs to be again transmitted encrypted. This is admittedly an edge
case but we had to implement a similar scheme for HP Cloud’s swift storage.
German
From: Stephen Balukoff
[mailto:[email protected]<mailto:[email protected]>]
Sent: Friday, April 18, 2014 8:22 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][LBaaS] SSL re-encryption scenario question
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?)
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.)
Thanks,
Stephen
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807<tel:%28800%29613-4305%20x807>
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
