Open Stack

+1 to what Bryan said. I prefer to do SSL/TLS in things like Apache, nginx,
etc because they typically pay much closer attention to SSL support,
validation, and security (see all the changes to OpenStack services to
switch out HTTPSConnection for requests).  Additionally, performance of
these are typically much better than SSL in Python (I've seen 5-10x or more
improvements).

Nate
On Mar 25, 2014 5:54 PM, "Bryan D. Payne" <bdpayne at acm.org> wrote:

> A few thoughts come to mind:
>
> * For any production system, I suspect that you will be running a front
> end server in front of the actual endpoint.  So, at a minimum, that server
> is where the TLS termination would happen.  Depending on your setup, it may
> make more sense to terminate directly at that server (e.g., Apache or
> Nginx), or using a dedicated / purpose built TLS termination shim (e.g.,
> Stud or Pound).
>
> * In many deployments, the control plane uses a different trust model than
> the external networks.  Services on the control plane may not trust the
> same set of root certs that clients on the external network choose to
> trust.  As such, the TLS setup would need to be different.  Re-encrypting
> the connection at a proxy that sits on the boundary of the external network
> and the control plane serves to handle this use somewhat common use case.
>
> * In some cases it may be useful for purposes of load balancing, and
> auditing to be able to inspect the traffic at a proxy sitting between the
> external network and the control plane.
>
> * If there is no use case to inspect the traffic, and there is a common
> set of trusted root certs on both networks, then I see no problem just
> taking the TLS all the way back to the front-end server handling the
> endpoint (these would likely be deployed on the same machine... and could
> then just communicate the clear-text information over a unix socket or
> similar setup).
>
> If others agree, perhaps there is room to improve the wording in the book
> around this point?  I do suspect that the setup described in the book is
> most common for real world deployments, but I don't see anything wrong with
> the other setup from a security standpoint.
>
> My two cents,
> -bryan
>
>
>
> On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder <nkinder at redhat.com> wrote:
>
>> Hi,
>>
>> The Security Guide currently recommends that SSL/TLS be used to protect
>> the API endpoints (as it should).  We specifically mention that SSL
>> proxies should be used for this, as opposed to configuring SSL natively
>> in the services themselves:
>>
>>
>> http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html
>>
>> Is there any particular reason why we don't recommend configuring
>> SSL/TLS natively in the services?  It seems like that would be an ideal
>> approach, as it eliminates the need for running proxies.  It also keeps
>> access to the unencrypted traffic closer to the actual services that
>> need to access it, which is better from a security standpoint.
>>
>> I'm not sure that all of the integrated projects actually have working
>> native SSL/TLS support, but I know that a number of them claim to have
>> support.  Shouldn't native support be the preferred recommendation from
>> a security standpoint?
>>
>> Thanks,
>> -NGK
>>
>> _______________________________________________
>> Openstack-security mailing list
>> Openstack-security at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>>
>
>
> _______________________________________________
> Openstack-security mailing list
> Openstack-security at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-security/attachments/20140325/6966bc2d/attachment.html>