<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div>On Sat, Sep 3, 2016, at 09:41 AM, Dean Troyer wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><div defang_data-gmailquote="yes"><div>On Fri, Sep 2, 2016 at 11:30 PM, Masanori Itoh <span dir="ltr"><<a href="mailto:masanori.itoh@gmail.com">masanori.itoh@gmail.com</a>></span> wrote:<br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote="yes"><div>It eliminates 'stud' usage and replace it by apache2/mod_ssl, right?<br></div>
<div> <br></div>
<div> But, there are use cases like:<br></div>
<div> - use apache2/mod_wsgi for better performance<br></div>
<div> and<br></div>
<div> - have an out-of-the-box SSL terminator (box)<br></div>
</blockquote><div><br></div>
<div>What is the ongoing use case for a distinct terminator? To simulate an actual non-Apache terminator? I really don't know how often this is needed, if the TLS can be properly handled otherwise.<br></div>
</div>
</div>
</div>
</blockquote><div><br></div>
<div>I actually think the split isn't a bad idea - IMO I would have just made one user facing var for the sake of simplicity (which is what Dean seems to be proposing below) but internally its still probably good to make a split between ssl frontend and internal apis. The way things are coded this split is already paid for: service installers already bind to their own internal port and tell the tls proxy about the mapping, and by having the split we get a bunch of extra flexibility.<br></div>
<div><br></div>
<div>My thinking is that with [1] we can support a mix of services which support ssl termination on their own (simply run them with ssl termination on and have apache ssl to the backend as well), run only http (done in the patch), or run within apache (keystone/horizon) using a single service and code path which looks almost identical. It also is trivial to support the use case Masanori was describing with this setup (although I'm still unsure whether devstack actually wants to support that).<br></div>
<div><br></div>
<blockquote type="cite"><div dir="ltr"><div><div defang_data-gmailquote="yes"><div> <br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote="yes">Also, we have 'USE_TLS' option enabling to terminate SSL by apache2/mod_ssl.<br></blockquote><div><br></div>
<div>This should become a default True<br></div>
<div> <br></div>
<blockquote style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;" defang_data-gmailquote="yes"><div>So, I think it's better to leave 'tls-proxy' using a non-apache SSL<br></div>
<div> terminater like 'stud' or 'hitch'<br></div>
<div> as an option for the use case above.<br></div>
<div> My fix is like that.<br></div>
<div> <br></div>
<div> What do you think about?<br></div>
</blockquote><div><br></div>
<div>The addition of stud was originally driven in order to test client TLS operation because of the mess that enabling SSL/TLS on the services directly was at the time and haproxy was overkill. The complicated split configuration should really be an anti-pattern for OpenStack deployment and needs to just go away in favor of a TLS-everywhere approach using preferably Apache or haproxy (although this is still overkill for DevStack IMHO). We should be doing that anyway to ensure that all of the internally used client libs are properly TLS-capable (I believe this is the case now).<br></div>
<div><br></div>
<div>The TLS_PROXY setting could either go away or be an alias for USE_TLS. And honestly, we should think about setting USE_TLS True by default anyway.<br></div>
</div>
</div>
</div>
</blockquote><div><br></div>
<div>Getting tls on by default is exactly what I was going for in <a href="https://review.openstack.org/#/c/364016/2">https://review.openstack.org/#/c/364016/2</a> but this is making me rethink the method I proposed there. I now think the easiest way to attack this is to make tls-proxy work again, and then make USE_SSL turn on tls-proxy by default (or require it to be enabled). After that whether a service manages ssl directly is an unrelated issue we can solve service-by-service while still working and having tls on by default - we just turn on tls for the services and have them tell the tls-proxy to talk to the backend over tls.<br></div>
<div><br></div>
<blockquote type="cite"><div dir="ltr"><div><div defang_data-gmailquote="yes"><div><br></div>
<div>Eek, making DevStack more secure, who whoulda thunk it?<br></div>
<div><br></div>
<div>dt<br></div>
</div>
<div><br></div>
<div>-- <br></div>
<div><div><br></div>
<div>Dean Troyer<br></div>
<div><a href="mailto:dtroyer@gmail.com">dtroyer@gmail.com</a><br></div>
</div>
</div>
</div>
</blockquote><div><br></div>
<div>Cheers,<br></div>
<div>Greg</div>
</body>
</html>