<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Sep 2, 2016 at 11:30 PM, Masanori Itoh <span dir="ltr"><<a href="mailto:masanori.itoh@gmail.com" target="_blank">masanori.itoh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It eliminates 'stud' usage and replace it by apache2/mod_ssl, right?<br>
<br>
But, there are use cases like:<br>
  - use apache2/mod_wsgi for better performance<br>
  and<br>
  - have an out-of-the-box SSL terminator (box)<br></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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So, I think it's better to leave 'tls-proxy' using a non-apache SSL<br>
terminater like 'stud' or 'hitch'<br>
as an option for the use case above.<br>
My fix is like that.<br>
<br>
What do you think about?<br></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).</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.</div><div><br></div><div>Eek, making DevStack more secure, who whoulda thunk it?</div><div><br></div><div>dt</div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Dean Troyer<br><a href="mailto:dtroyer@gmail.com" target="_blank">dtroyer@gmail.com</a><br></div>
</div></div>