I'd say the top three terminators in use today are probably Stunnel, Stud and Pound - all rely on OpenSSL. I'm sure there's a plethora of alternatives but I'd imagine most are OpenSSL based, the most likely alternative being NSS which is a big library to use for something like a terminator.
> -----Original Message----- > From: Rob Crittenden [mailto:rcrit...@redhat.com] > Sent: 29 April 2014 15:39 > To: Hao Wang; Clark, Robert Graham > Cc: openstack-secur...@lists.openstack.org; openstack; Aaron Knister > Subject: Re: [Openstack-security] [Openstack] API Security > > 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 > > rob > > > > > > > On Tue, Apr 29, 2014 at 10:07 AM, Clark, Robert Graham > > <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>] > > *Sent:* 29 April 2014 14:06 > > *To:* openstack-secur...@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>> wrote:____ > > > > It is the client. I got this message with DEBUG enabled:____ > > > > curl -i '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>> > > 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>> 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 > > Post to : openstack@lists.openstack.org > > <mailto:openstack@lists.openstack.org> > > Unsubscribe : > > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack____ > > > > __ __ > > > > __ __ > > > > > > > > > > _______________________________________________ > > Openstack-security mailing list > > openstack-secur...@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ 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