<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 13, 2020, 12:39 PM Jo-Philipp Wich <<a href="mailto:jo@mein.io" target="_blank" rel="noreferrer">jo@mein.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Wes,<br>
<br>
> Are there *new* security implications of allowing keep-alive?<br>
<br>
I don't see any immediate concerns. You can trigger resource intensive calls<br>
via GET, HEAD, PATCH, PUT or DELETE as well, all of them were allowed for<br>
keep-alive previously, only POST was filtered for unknown reasons.<br>
<br>
> Slowloris DoS comes to mind:<br>
> <a href="https://en.wikipedia.org/wiki/Slowloris_(computer_security)" rel="noreferrer noreferrer noreferrer" target="_blank">https://en.wikipedia.org/wiki/Slowloris_(computer_security)</a><br>
<br>
The DoS susceptibility should be same with or without this patch.<br>
<br>
> Older devices are likely somewhat trivially DoS-able without this patch; but<br>
> maybe include a config option to disable keep-alive?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Disabling keep-alive has always been supported, either use<br>
uci set uhttpd.main.http_keepalive=0 or alternatively uhttpd -k 0<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Thanks</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> What happens to RAM and CPU usage when there are multiple tabs open with<br>
> keep-alive on?<br>
<br>
Testing with 6 open browser tabs, all refreshing the main status page:<br>
<br>
With POST keep-alive:    uhttpd VSZ 4316K, CPU 5% usr, 6% sys<br>
Without POST keep-alive: uhttpd VSZ 4756K, CPU 11% usr, 8% sys<br>
<br>
Thats not a scientific benchmark though. In general you trade CPU (TLS setup,<br>
TCP connects) for memory (resident established connections).<br>
<br>
In case of non-malicious clients (like normal browser tabs background<br>
refreshing data) the memory resource consumption seems to be even lower<br>
because there's less active TLS sessions at every point in time. And almost no<br>
TLS connection attempts once all requires sessions are established.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That sounds ideal. Is this with or without the "[OpenWrt-Devel] [PATCH ustream-ssl] ustream-openssl: clear error stack before SSL_read/SSL_write" patch?</div></div>