Re: [openstack-dev] [TripleO] proxying SSL traffic for API requests
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
Re: [openstack-dev] [TripleO] proxying SSL traffic for API requests
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. > > So if we use apache for running the python app servers, that is not a > reason to also use apache for SSL. Quite the opposite I think. > > As far as "which is best".. there are benefits and drawbacks for all of > them, and it is modular enough that we can just stick with stunnel and > users who find problems with it can switch it out without too much hassle. > > ___ > 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
Re: [openstack-dev] [TripleO] proxying SSL traffic for API requests
Hi On 26 March 2014 16:51, Clint Byrum wrote: > 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. > This is a very good point, thanks :) -- Cheers, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] proxying SSL traffic for API requests
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. So if we use apache for running the python app servers, that is not a reason to also use apache for SSL. Quite the opposite I think. As far as "which is best".. there are benefits and drawbacks for all of them, and it is modular enough that we can just stick with stunnel and users who find problems with it can switch it out without too much hassle. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] proxying SSL traffic for API requests
Thanks Chris. Sounds like you're saying building out the apache element may be a sensible next step? -Stuart 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. Cheers, -- Chris Jones On 26 Mar 2014, at 13:49, stuart.mclaren at hp.com wrote: Just spotted the openstack-ssl element which uses 'stunnel'... On Wed, 26 Mar 2014, stuart.mclaren at hp.com wrote: All, I know there's a preference for using a proxy to terminate SSL connections rather than using the native python code. There's a good write up of configuring the various proxies here: http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html If we're not using native python SSL termination in TripleO we'll need to pick which one of these would be a reasonable choice for initial https support. Pound may be a good choice -- its lightweight (6,000 lines of C), easy to configure and gives good control over the SSL connections (ciphers etc). Plus, we've experience with pushing large (GB) requests through it. I'm interested if others have a strong preference for one of the other options (stud, nginx, apache) and if so, what are the reasons you feel it would make a better choice for a first implementation. Thanks, -Stuart ___ 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] proxying SSL traffic for API requests
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. Cheers, -- Chris Jones > On 26 Mar 2014, at 13:49, stuart.mcla...@hp.com wrote: > > Just spotted the openstack-ssl element which uses 'stunnel'... > > >> On Wed, 26 Mar 2014, stuart.mcla...@hp.com wrote: >> >> All, >> >> I know there's a preference for using a proxy to terminate >> SSL connections rather than using the native python code. >> >> There's a good write up of configuring the various proxies here: >> >> http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html >> >> If we're not using native python SSL termination in TripleO we'll >> need to pick which one of these would be a reasonable choice for >> initial https support. >> >> Pound may be a good choice -- its lightweight (6,000 lines of C), >> easy to configure and gives good control over the SSL connections (ciphers >> etc). >> Plus, we've experience with pushing large (GB) requests through it. >> >> I'm interested if others have a strong preference for one of the other >> options (stud, nginx, apache) and if so, what are the reasons you feel it >> would make a better choice for a first implementation. >> >> Thanks, >> >> -Stuart > > ___ > 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
Re: [openstack-dev] [TripleO] proxying SSL traffic for API requests
Just spotted the openstack-ssl element which uses 'stunnel'... On Wed, 26 Mar 2014, stuart.mcla...@hp.com wrote: All, I know there's a preference for using a proxy to terminate SSL connections rather than using the native python code. There's a good write up of configuring the various proxies here: http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html If we're not using native python SSL termination in TripleO we'll need to pick which one of these would be a reasonable choice for initial https support. Pound may be a good choice -- its lightweight (6,000 lines of C), easy to configure and gives good control over the SSL connections (ciphers etc). Plus, we've experience with pushing large (GB) requests through it. I'm interested if others have a strong preference for one of the other options (stud, nginx, apache) and if so, what are the reasons you feel it would make a better choice for a first implementation. Thanks, -Stuart ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
