Excerpts from Nathan Kinder's message of 2014-03-27 13:25:02 -0700: > On 03/26/2014 09:51 AM, Clint Byrum wrote: > > Excerpts from Chris Jones's message of 2014-03-26 06:58:59 -0700: > >> Hi > >> > >> We don't have a strong attachment to stunnel though, I quickly dropped it > >> in front of our CI/CD undercloud and Rob wrote the element so we could > >> repeat the deployment. > >> > >> In the fullness of time I would expect there to exist elements for several > >> SSL terminators, but we shouldn't necessarily stick with stunnel because > >> it happened to be the one I was most familiar with :) > >> > >> I would think that an httpd would be a good option to go with as the > >> default, because I tend to think that we'll need an httpd running/managing > >> the python code by default. > >> > > > > I actually think that it is important to separate SSL termination from > > the app server. In addition to reasons of scale (SSL termination scales > > quite a bit differently than app serving), there is a security implication > > in having the private SSL keys on the same box that runs the app. > > There is also a security implication in having network traffic from the > SSL terminator to the application in the clear. If the app is > compromised, one could just read all incoming traffic anyway since it is > not encrypted. >
Reading all incoming traffic is a given if the app is compromised in the same way that one might compromise the secret keys. Terminator to app server encryption is only to prevent evil on your internal network. That is contained to your own network and thus can be measured and controlled. However, you don't want an attacker who has compromised your app to be able to go off and setup their own version of your app using your private key and some simple MITM techniques in a place where you cannot detect or control it at all. That's not to say that terminator<->app encryption is not a good idea too. But that should be using a separate set of encryption keys to mitigate the impact of a compromise to, again, your own network. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
