<p dir="ltr">+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). </p>
<p dir="ltr">Nate</p>
<div class="gmail_quote">On Mar 25, 2014 5:54 PM, "Bryan D. Payne" <<a href="mailto:bdpayne@acm.org">bdpayne@acm.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">A few thoughts come to mind:<div><br></div><div>* 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).</div>
<div><br></div><div>* 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.</div>
<div><br></div><div>* 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.</div><div><br></div>
<div>* 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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>My two cents,</div><div>-bryan</div><div><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder <span dir="ltr"><<a href="mailto:nkinder@redhat.com" target="_blank">nkinder@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
The Security Guide currently recommends that SSL/TLS be used to protect<br>
the API endpoints (as it should). We specifically mention that SSL<br>
proxies should be used for this, as opposed to configuring SSL natively<br>
in the services themselves:<br>
<br>
<br>
<a href="http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html" target="_blank">http://docs.openstack.org/security-guide/content/ch020_ssl-everywhere.html</a><br>
<br>
Is there any particular reason why we don't recommend configuring<br>
SSL/TLS natively in the services? It seems like that would be an ideal<br>
approach, as it eliminates the need for running proxies. It also keeps<br>
access to the unencrypted traffic closer to the actual services that<br>
need to access it, which is better from a security standpoint.<br>
<br>
I'm not sure that all of the integrated projects actually have working<br>
native SSL/TLS support, but I know that a number of them claim to have<br>
support. Shouldn't native support be the preferred recommendation from<br>
a security standpoint?<br>
<br>
Thanks,<br>
-NGK<br>
<br>
_______________________________________________<br>
Openstack-security mailing list<br>
<a href="mailto:Openstack-security@lists.openstack.org" target="_blank">Openstack-security@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</a><br>
</blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
Openstack-security mailing list<br>
<a href="mailto:Openstack-security@lists.openstack.org">Openstack-security@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security</a><br>
<br></blockquote></div>