+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" <cl...@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@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