<div dir="ltr"><div>If the purpose of the software is not to be a dedicated purpose http daemon, use something that already exists with a deep feature set that can be configured as needed for the purpose, such as apache2 with openssl or nginx.<br></div><div><br></div><div>It's not reasonable to expect that the developers of elastiflow reinvent the wheel and write their own httpd with TLS support, if it can be easily put "behind" apache2 or nginx. The risks of having people who aren't full time httpd specialists write their own http daemon and mitigate every possible security risk in a TLS setup are greater than using what already exists. <br></div><div><br></div><div>It's a one page size configuration file in nginx.</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 26 Jan 2022 at 05:17, Laura Smith via NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br>
<br>
On Wednesday, January 26th, 2022 at 11:08, Eric Kuhnke <<a href="mailto:eric.kuhnke@gmail.com" target="_blank">eric.kuhnke@gmail.com</a>> wrote:<br>
<br>
> elastiflow is extremely easy to run on an httpd listening only on localhost and proxy behind a simple nginx TLS1.2/1.3 only configuration listening on port 443.<br>
><br>
<br>
I don't know about anyone else here, but frankly in 2022 TLS support should be a first class citizen.<br>
<br>
If I have to mess around with running something else as a proxy in front of it then that's the end of my software evaluation.<br>
<br>
Crypto is no longer "nice to have" option these days.<br>
</blockquote></div>