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.ga...@rackspace.com>wrote: > > On Apr 18, 2014, at 12:36 PM, Stephen Balukoff <sbaluk...@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.eichber...@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:sbaluk...@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@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@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 > > -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
