Re: [Openstack] Do we need SSL on nova-api ports?
On 3 May 2011, at 01:34, Eldar Nugaev wrote: #1 Replace existed plain http to ssl #2 Add additional ports for ssl (save plain http) #3 Do nothing I suggest: a) Make SSL only the default (ideally with client cert on as well). b) Postulate that one port lower there is an optional HTTP port (OFF, or tied to localhost). As having those is easy in proxy/behind loadbalancers/behind failover* situations. c) Postulate a certain header set used in the plain text case to pass on the client cert - and use this throughout*. Thanks, Dw. *: Unfortunately - a lot of people follow sites like [1] - and hence end up with weird/illegal headers (underscore) such as SSL_CLIENT_S_DN. But then again - this is sort of the standard (Oracle, IBM et.al. seem to use some variation of WL-Proxy-Client-Cert; with their respective products often worked in the name). 1: http://www.zeitoun.net/articles/client-certificate-x509-authentication-behind-reverse-proxy/start Eldar On Tue, Apr 26, 2011 at 11:27 AM, Dirk-Willem van Gulik dirk-willem.van.gu...@bbc.co.uk wrote: On 25 Apr 2011, at 19:47, Kirill Shileev wrote: Recently, playing with libcloud against a private openstack installation we realized that 8773 and 8774 ports listened by openstack-nova-api expect plain HTTP. This is something that is rarely allowed in production installations. . Other option would be making this configurable, although not sure why and where the plain HTTP might be justified. Any thoughts, comments? An important side effect of slapping SSL with client/server certs on pretty much all connection is that it makes all sort of governance and validation jobs much easier from an organisational point of view. With more 'reuse' of existing process and validation. The attack footprint/exposed estate now splits in three clean realms: issuing of client cert, security of the TCP and SSL layer - and a specific model for what happens within that connection. With the latter bound by the previous two. Furthermore client validation can be done with narly a secret in sight. So for those reasons alone - SSLis good. Dw. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Eldar Skype: eldar.nugaev smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Do we need SSL on nova-api ports?
On 3 May 2011, at 03:29, Todd Willey wrote: We should be able to do it with a wsgi middleware and either include it or not in the paste config file. In a heavily load-balanced environment you'll probably want to terminate SSL before it gets proxied to the actual api servers, Agreed. And using a standard set of headers is good here - as then your apache/proxy configs are easy and easily reused across the board. but it would be nice to support the simple case where the api server could have ssl. Middleware seems like a better, more reusable solution than a flag. Hmm - is that really the 'simple case' ? Or is having N of those in parallel the desired goal ? I am quite tempted at to launch into a L7/man-in-the-middle D/SPOF bits of kit are evil diatribe at this point. And really would like to assume that openstack ultimately gears towards a situation where one would not routinely use such (but perhaps for a few very specific locations where the 'customer' is a webbrowser or similar 'legacy' system) - and instead robustly assumes that any and all endpoints can have many CNAMEs which are tried in turn (or even bettter - full use of a DNS SRV record) - or similar loadbalancing/failover which does not requrire 'kit that can fail' inserted in the wire. Just a thought, Dw smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Do we need SSL on nova-api ports?
On 3 May 2011, at 10:31, Soren Hansen wrote: 2011/5/3 Todd Willey t...@ansolabs.com: In a heavily load-balanced environment you'll probably want to terminate SSL before it gets proxied to the actual api servers, Why is that? It seems like a win to distribute as much processing as possible, including SSL termination? Because most load balancing vendors are either 1) convinced that they need to go up the stack and have gradually made it impossible to do blind socket LB - and insist on looking at headers and what not, or 2) is soo far out of touch and old that blind socket forwarding is not overly practical as the outdated means to inform the LB what to blindly forward where is just too painful. But yes - a bright vendor/standard would indeed do a clever pass through to the distributed boxes for at least the initial exchange; optionally facilitate session sharing and/or providing it in-line and after the exchange it could be informed of the session key and then do a bit more than just blind forwarding. Dw. smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Do we need SSL on nova-api ports?
On 3 May 2011, at 13:30, Todd Willey wrote: On Tue, May 3, 2011 at 5:39 AM, Dirk-Willem van Gulik dirk-willem.van.gu...@bbc.co.uk wrote: On 3 May 2011, at 10:31, Soren Hansen wrote: 2011/5/3 Todd Willey t...@ansolabs.com: In a heavily load-balanced environment you'll probably want to terminate SSL before it gets proxied to the actual api servers, Why is that? It seems like a win to distribute as much processing as possible, including SSL termination? Because most load balancing vendors are either 1) convinced that they need to go up the stack and have gradually made it impossible to do blind socket LB - and insist on looking at headers and what not, or 2) is soo far out of touch and old that blind socket forwarding is not overly practical as the outdated means to inform the LB what to blindly forward where is just too painful. I was thinking of hardware acceleration. Aye, Agreed - though these days - once the intial DSA/RSA negotiation is done - the rest is getting less and less painful[1] in modern environments - and give its very cloudy nature - quite likely distributed with enough CPU spare cycles. But yes - a bright vendor/standard would indeed do a clever pass through to the distributed boxes for at least the initial exchange; optionally facilitate session sharing and/or providing it in-line and after the exchange it could be informed of the session key and then do a bit more than just blind forwarding. Dw. Dw. 1: http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Do we need SSL on nova-api ports?
On 3 May 2011, at 18:49, Richard Hartmann wrote: On Tue, May 3, 2011 at 08:09, Dirk-Willem van Gulik dirk-willem.van.gu...@bbc.co.uk wrote: a) Make SSL only the default (ideally with client cert on as well). Sounds good to me. b) Postulate that one port lower there is an optional HTTP port (OFF, or tied to localhost). The IETF _strongly_ prefers STARTTLS over separate TLS/non-TLS ports. If you ever want to get an IANA assignment, you are pretty much required to support STARTTLS unless you are working with legacy protocols. Actally - that is a very good point for anything non REST/http. Using STARTTLS and requiring TLS by default seems like a good option for the medium term, to me. Right - but I think it is fair to assume that any IAB concerns would only apply to two way chatty protocols. A pure 'rest' one-shot stateless protocol would not be burdened with a STARTTLS and all the risks that entails. Dw___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Do we need SSL on nova-api ports?
On 25 Apr 2011, at 19:47, Kirill Shileev wrote: Recently, playing with libcloud against a private openstack installation we realized that 8773 and 8774 ports listened by openstack-nova-api expect plain HTTP. This is something that is rarely allowed in production installations. . Other option would be making this configurable, although not sure why and where the plain HTTP might be justified. Any thoughts, comments? An important side effect of slapping SSL with client/server certs on pretty much all connection is that it makes all sort of governance and validation jobs much easier from an organisational point of view. With more 'reuse' of existing process and validation. The attack footprint/exposed estate now splits in three clean realms: issuing of client cert, security of the TCP and SSL layer - and a specific model for what happens within that connection. With the latter bound by the previous two. Furthermore client validation can be done with narly a secret in sight. So for those reasons alone - SSLis good. Dw. smime.p7s Description: S/MIME cryptographic signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
