[Openstack-security] SSL proxies vs. native SSL support
Bryan D. Payne
bdpayne at acm.org
Thu Apr 3 21:04:43 UTC 2014
I just read the blog post and it is a nice summary of the discussion we've
had in this thread. Thanks for putting that together. I'd be happy to
work with you to help make these improvements to the book.
-bryan
On Thu, Apr 3, 2014 at 1:49 PM, Nathan Kinder <nkinder at redhat.com> wrote:
> On 03/31/2014 12:12 PM, Nathan Kinder wrote:
> > On 03/25/2014 02:50 PM, Bryan D. Payne 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).
> >
> > A unix socket would definitely be ideal. As you say, if inspection of
> > the encrypted traffic is not needed for something like load balancing,
> > this sort of deployment would meet the goal of keeping clear-text
> > traffic off of the network. It would also add some privilege separation
> > by keeping access to the private key limited to the SSL terminator (vs.
> > allowing the API endpoint process to access it).
> >
> >>
> >> 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.
> >
> > I do think that some re-wording and more detail would add clarity in
> > this area. I think that each deployment will have different security
> > requirements and concerns. The Security Guide should spell out the
> > options, with limitations and concerns mentioned for each. This would
> > allow the reader to make their own decision about what type of
> > deployment would meet their requirements.
> >
> > I'm working on writing up some details in this area, so I'd be happy to
> > submit some patches for this chapter of the Security Guide.
>
> I've published a blog post based on my research of this topic:
>
> https://blog-nkinder.rhcloud.com/?p=7
>
> I'd like to use this as a basis for improving the Security Guide, but
> I'd love to get some feedback from others first. Any comments would be
> much appreciated!
>
> Thanks,
> -NGK
>
> >
> > -NGK
> >
> >>
> >> My two cents,
> >> -bryan
> >>
> >>
> >>
> >> On Tue, Mar 25, 2014 at 2:29 PM, Nathan Kinder <nkinder at redhat.com
> >> <mailto: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
> >> <mailto: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/20140403/741531b7/attachment.html>
More information about the Openstack-security
mailing list