Open Stack

German:

I'm hearing from a lot of different sources / organizations on this list
that re-encryption at the load balancer is a must-have feature. And I was
already part of previous discussions on SSL functionality. (
https://wiki.openstack.org/wiki/Neutron/LBaaS/SSL )

Also, even if the load balancer does support re-encryption on the back-end,
this doesn't prevent users from using a VPN-based solution either.

Stephen


On Mon, Apr 21, 2014 at 11:51 AM, Eichberger, German <
german.eichberger at hp.com> wrote:

>  Hi,
>
>
>
> Despite there are some good use cases for the re-encryption I think it’s
> out of scope for a Load Balancer. We can defer that functionality to the
> VPN – as long as we have a mechanism to insert a LoadBalancer as a VPN node
> we should get all kind of encryption infrastructure “for free”.
>
>
>
> I like the Unix philosophy of little programs doing one task very well and
> can be chained. So in our case we might want to chain a firewall to a load
> balancer to a VPN to get the functionality we want.
>
>
>
> Thoughts?
>
>
>
> German
>
>
>
> *From:* Stephen Balukoff [mailto:sbalukoff at bluebox.net]
> *Sent:* Friday, April 18, 2014 9:07 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron][LBaaS] SSL re-encryption
> scenario question
>
>
>
> Hi y'all!
>
>
>
> Carlos: When I say 'client cert' I'm talking about the certificate / key
> combination the load balancer will be using to initiate the SSL connection
> to the back-end server. The implication here is that if the back-end server
> doesn't like the client cert, it will reject the connection (as being not
> from a trusted source). By 'CA cert' I'm talking about the certificate
> (sans key) that the load balancer will be using the authenticate the
> back-end server. If the back-end server's "server certificate" isn't signed
> by the CA, then the load balancer should reject the connection.
>
>
>
> Of course, the use of a client cert or CA cert on the load balancer should
> be optional: As Clint pointed out, for some users, just using SSL without
> doing any particular authentication (on either the part of the load
> balancer or back-end) is going to be good enough.
>
>
>
> Anyway, the case for supporting re-encryption on the load-balancers has
> been solidly made, and the API proposal we're making will reflect this
> capability. Next question:
>
>
>
> When specific client certs / CAs are used for re-encryption, should these
> be associated with the pool or member?
>
>
>
> I could see an argument for either case:
>
>
>
> *Pool* (ie. one client cert / CA cert will be used for all members in a
> pool):
>
> * Consistency of back-end nodes within a pool is probably both extremely
> common, and a best practice. It's likely all will be accessed the same way.
>
> * Less flexible than certs associated with members, but also less
> complicated config.
>
> * For CA certs, assumes user knows how to manage their own PKI using a CA.
>
>
>
> *Member* (ie. load balancer will potentially use a different client cert
> / CA cert for each member individually):
>
> * Customers will sometimes run with inconsistent back-end nodes (eg.
> "local" nodes in a pool treated differently than "remote" nodes in a pool).
>
> * More flexible than certs associated with members, more complicated
> configuration.
>
> * If back-end certs are all individually self-signed (ie. no single CA
> used for all nodes), then certs must be associated with members.
>
>
>
> What are people seeing "in the wild"? Are your users using
> inconsistently-signed or per-node self-signed certs in a single pool?
>
>
>
> Thanks,
>
> Stephen
>
>
>
>
>
>
>
>
>
> On Fri, Apr 18, 2014 at 5:56 PM, Carlos Garza <carlos.garza at rackspace.com>
> wrote:
>
>
>
> On Apr 18, 2014, at 12:36 PM, Stephen Balukoff <sbalukoff at bluebox.net>
> 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 <
> german.eichberger at hp.com> 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:sbalukoff at bluebox.net]
> *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
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>
> --
> Stephen Balukoff
> Blue Box Group, LLC
> (800)613-4305 x807
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
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/20140421/324a8b6b/attachment.html>