[openstack-dev] [TripleO] proxying SSL traffic for API requests

Clint Byrum clint at fewbar.com
Thu Mar 27 21:39:08 UTC 2014

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

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.

More information about the OpenStack-dev mailing list