Open Stack

Hello Stephen,

One use case we have, which was actually a highly requested feature for our service, was to ensure that traffic within the internal cloud network was not passed in the clear. I believe this mainly stems from the customers security requirements. I understand this reasoning to allow a centralized place to correct/prevent potential SSL attacks while still assuring data is secure all the way to the backend. I could probably dig up more details if this isn't clear enough, but is the way I understand this particular feature.


Thanks,
Phil

From: Stephen Balukoff <sbalukoff at bluebox.net<mailto:sbalukoff at bluebox.net>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Friday, April 18, 2014 10:21 AM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140418/3e3f7080/attachment.html>