On 04/29/2014 08:03 AM, Hao Wang wrote: > SSL terminator will terminates at the network boundary. I am thinking if > the crackers can figure out a way to sneak into the internal network and > capture all the sensitive information still. Is this a concern for a > private cloud?
Yes, it's definitely still a concern. If you read the blog post that Rob mentioned, it's talking about setting up a SSL/TLS terminator on the same physical system as the API endpoints to prevent traffic from being sent over the network in the clear. You might also have SSL/TLS termination at the network boundary for load-balancing purposes, then a re-encryption to protect traffic on the internal networks. -NGK > > > On Tue, Apr 29, 2014 at 10:39 AM, Rob Crittenden <rcrit...@redhat.com > <mailto:rcrit...@redhat.com>> wrote: > > Hao Wang wrote: > > Thanks. It makes sense. The other questions are, would > Heartbleed be a > potential risk? Which solution is being used in OpenStack SSL? > > > Native SSL services (eventlet) are based on OpenSSL, as is Apache > (horizon) so yes, the risk is there if you haven't updated your > OpenSSL libraries. > > The general consensus however is to use SSL terminators rather than > enabling SSL in the endpoints directly. You'd need to investigate > the SSL library in the terminator you choose, though it would likely > be OpenSSL. > > Check this out as well, https://blog-nkinder.rhcloud.__com/?p=7 > <https://blog-nkinder.rhcloud.com/?p=7> > > rob > > > > On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham > <robert.cl...@hp.com <mailto:robert.cl...@hp.com> > <mailto:robert.cl...@hp.com <mailto:robert.cl...@hp.com>>> wrote: > > This is why any production API servers should all be running > TLS/SSL > – to protect the confidentiality of messages in flight.____ > > __ __ > > > There have been efforts to remove sensitive information from > logs, > I’m a little surprised that passwords are logged in Neutron.____ > > __ __ > > *From:*Hao Wang [mailto:hao.1.w...@gmail.com > <mailto:hao.1.w...@gmail.com> > <mailto:hao.1.w...@gmail.com <mailto:hao.1.w...@gmail.com>>] > *Sent:* 29 April 2014 14:06 > *To:* openstack-security@lists.__openstack.org > <mailto:openstack-secur...@lists.openstack.org> > <mailto:openstack-security@__lists.openstack.org > <mailto:openstack-secur...@lists.openstack.org>> > *Cc:* openstack; Aaron Knister > *Subject:* Re: [Openstack-security] [Openstack] API Security____ > > __ __ > > Adding security group...____ > > __ __ > > > On Sat, Apr 26, 2014 at 4:25 PM, Hao Wang > <hao.1.w...@gmail.com <mailto:hao.1.w...@gmail.com> > <mailto:hao.1.w...@gmail.com <mailto:hao.1.w...@gmail.com>>> > wrote:____ > > It is the client. I got this message with DEBUG enabled:____ > > > curl -i 'http://192.168.56.103:35357/__v2.0/tokens > <http://192.168.56.103:35357/v2.0/tokens>' -X POST -H > "Content-Type: application/json" -H "Accept: > application/json" > -H "User-Agent: python-novaclient" -d '{"auth": > {"tenantName": > "admin", "passwordCredentials": {"username": "admin", > "password": "admin"}}}'____ > > __ __ > > > It can be seen that username and password are right in the > message.____ > > __ __ > > Hao____ > > __ __ > > > On Sat, Apr 26, 2014 at 4:08 PM, Aaron Knister > <aaron.knis...@gmail.com > <mailto:aaron.knis...@gmail.com> > <mailto:aaron.knister@gmail.__com <mailto:aaron.knis...@gmail.com>>> > wrote:____ > > > Was it the client or the server that exposed the > credentials? > > Sent from my iPhone____ > > > > On Apr 26, 2014, at 2:28 PM, Hao Wang > <hao.1.w...@gmail.com <mailto:hao.1.w...@gmail.com> > <mailto:hao.1.w...@gmail.com > <mailto:hao.1.w...@gmail.com>>> wrote:____ > > Hi,____ > > __ __ > > > I am troubleshooting a neutron case. It was just > found > that if DEBUG was enabled, neutron would print > out JSON > data with username and password. I am wondering what > kind of protocol is used in production > environment to > prevent this security risk from happening.____ > > __ __ > > Thanks,____ > > Hao____ > > > _________________________________________________ > Mailing list: > > http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack> > Post to : openstack@lists.openstack.org > <mailto:openstack@lists.openstack.org> > <mailto:openstack@lists.__openstack.org > <mailto:openstack@lists.openstack.org>> > Unsubscribe : > > http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack____ > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack____> > > __ __ > > __ __ > > > > > _________________________________________________ > Openstack-security mailing list > Openstack-security@lists.__openstack.org > <mailto:openstack-secur...@lists.openstack.org> > > http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-security > > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security> > > > > > > _______________________________________________ > Openstack-security mailing list > openstack-secur...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > _______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : openstack@lists.openstack.org Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack