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

2014-03-27 Thread Nathan Kinder
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

2014-03-27 Thread Clint Byrum
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

2014-03-26 Thread stuart . mclaren

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


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

2014-03-26 Thread Chris Jones
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

2014-03-26 Thread stuart . mclaren

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

2014-03-26 Thread Clint Byrum
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

2014-03-26 Thread Chris Jones
Hi

On 26 March 2014 16:51, Clint Byrum cl...@fewbar.com 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