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?
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? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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 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. 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. ___ 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 05/03/2011 06:39 AM, Dirk-Willem van Gulik wrote: 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 Willeyt...@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 How about nova-api does not get ssl/tls support but there is a reference way of setting up apache/nginx to be used as the web server for nova-api? I would much rather have the ability to run the api behind a web server that has the ability load modules to do whatever an end users wants e.g. ssl. To answers Sorens earlier question basically think of it this way ssl offload at the lb is needed if you have a layer 7 lb and want to use its fancy tricks. I have seen software based lbs do ssl offload at numbers that would probably make some of the hardware lb guys worry. ___ 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 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. Using STARTTLS and requiring TLS by default seems like a good option for the medium term, to me. Richard ___ 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?
I don't really see any reason for production apps to run on anything other than 80/443. In dev mode it is nice to have other ports, but I don't really see a reason for special ports in production systems. Vish On May 3, 2011, at 10:49 AM, 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. Using STARTTLS and requiring TLS by default seems like a good option for the medium term, to me. Richard ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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?
Hi all. So what is the decision? I see three decisions: #1 Replace existed plain http to ssl #2 Add additional ports for ssl (save plain http) #3 Do nothing 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 ___ 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?
Can we do this with a flag (or two) and just keep regular http if the flag is not set? Vish On May 2, 2011, at 4:34 PM, Eldar Nugaev wrote: Hi all. So what is the decision? I see three decisions: #1 Replace existed plain http to ssl #2 Add additional ports for ssl (save plain http) #3 Do nothing 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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?
More practical question: Should we use the same ports for SSL-enabled services as we have for plain-HTTP now (8773/8774)? If not, which ones should I choose for my SSL-protected Nova installation? Of course I can choose any on my own system - the question is - should we agree which ports will be OFFICIAL while using SSL on Nova installations across the globe? That's will be easy for community (at least to distingush between non-SSL and SSL setup in logs/etc). Andrey. 02.05.2011, в 16:42, Vishvananda Ishaya написал(а): Can we do this with a flag (or two) and just keep regular http if the flag is not set? Vish On May 2, 2011, at 4:34 PM, Eldar Nugaev wrote: Hi all. So what is the decision? I see three decisions: #1 Replace existed plain http to ssl #2 Add additional ports for ssl (save plain http) #3 Do nothing 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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?
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, 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. -todd[1] On Mon, May 2, 2011 at 7:42 PM, Vishvananda Ishaya vishvana...@gmail.com wrote: Can we do this with a flag (or two) and just keep regular http if the flag is not set? Vish On May 2, 2011, at 4:34 PM, Eldar Nugaev wrote: Hi all. So what is the decision? I see three decisions: #1 Replace existed plain http to ssl #2 Add additional ports for ssl (save plain http) #3 Do nothing 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 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ 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 04/25/2011 12:47 PM, Kirill Shileev wrote: Hi all, 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. We bypass the problem by providing stunnel proxy for those ports. Although, the fastest solution, it does not look satisfactory from the long term perspective. Hence the proposal: https://blueprints.launchpad.net/nova/+spec/openstack-api-ssl There is no any details so far, but the main idea is to change the default with nova-api to listen for SSL encoded transport. Other option would be making this configurable, although not sure why and where the plain HTTP might be justified. Any thoughts, comments? -- Best regards, Kirill Shileev Senior software engineer www.GridDynamics.com http://www.GridDynamics.com +7 495 787 49 44 office ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp Kirill Are you at the Openstack Confernece? Your ssl question is one of the things I would like to discuss in the discussion session I registered, http://openstack-spring2011.sched.org/event/4bb755f74fa7528bb5a0ccd20805ec0c Edward ___ 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
