Open Stack

+1 for German's use cases. We need SSL re-encryption for decisions the
load balancer needs to make at the l7 layer as well. Thanks Clint, for
your thorough explanation from a security standpoint.

Cheers,
--Jorge




On 4/18/14 1:38 PM, "Clint Byrum" <clint at fewbar.com> wrote:

>Excerpts from Stephen Balukoff's message of 2014-04-18 10:36:11 -0700:
>> 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.)
>> 
>
>No one person or even group of people on the operator's network will have
>full access to everything. Security is best when it comes in layers. Area
>51 doesn't just have a guard shack and then you drive right into the
>hangars with the UFO's and alien autopsies. There are sensors, mobile
>guards, secondary checkpoints, locks on the outer doors, and locks on
>the inner doors. And perhaps most importantly, the MP who approves your
>entry into the first gate, does not even have access to the next one.
>
>Your SSL terminator is a gate. What happens once an attacker (whoever
>that may be, your disgruntled sysadmin, or rogue hackers) is behind that
>gate _may_ be important.
>
>> 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.
>> 
>> 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.
>>
>
>A passive attack where the MITM does not have to witness the initial
>handshake or decrypt/reencrypt to sniff things is quite a bit easier to
>pull off and would be harder to detect. So "almost no extra security"
>is not really accurate. But this is just one point of data for risk
>assessment.
>
>> 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.")
>> 
>> It's a bit of a rabbit hole, eh.
>>
>
>Security turns into an endless rat hole when you just look at it as a
>product, such as "A secure load balancer."
>
>If, however, you consider that it is really just a process of risk
>assessment and mitigation, then you can find a sweet spot that works
>in your business model. "How much does it cost to mitigate the risk
>of unencrypted backend traffic from the load balancer?  What is the
>potential loss if the traffic is sniffed? How likely is it that it will
>be sniffed?" .. Those are ongoing questions that need to be asked and
>then reevaluated, but they don't have a fruitless stream of what-if's
>that have to be baked in like the product discussion. It's just part of
>your process, and processes go on until they aren't needed anymore.
>
>IMO a large part of operating a cloud is decoupling the ability to setup
>a system from the ability to enable your business with a system. So
>if you can communicate the risks of doing without backend encryption,
>and charge the users appropriately when they choose that the risk is
>worth the added cost, then I think it is worth it to automate the setup
>of CA's and client certs and put that behind an API. Luckily, you will
>likely find many in the OpenStack community who can turn that into a
>business opportunity and will help.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev