On Fri, Mar 13, 2020, 12:39 PM Jo-Philipp Wich <j...@mein.io> wrote: > Hi Wes, > > > Are there *new* security implications of allowing keep-alive? > > I don't see any immediate concerns. You can trigger resource intensive > calls > via GET, HEAD, PATCH, PUT or DELETE as well, all of them were allowed for > keep-alive previously, only POST was filtered for unknown reasons. > > > Slowloris DoS comes to mind: > > https://en.wikipedia.org/wiki/Slowloris_(computer_security) > > The DoS susceptibility should be same with or without this patch. > > > Older devices are likely somewhat trivially DoS-able without this patch; > but > > maybe include a config option to disable keep-alive? >
> Disabling keep-alive has always been supported, either use > uci set uhttpd.main.http_keepalive=0 or alternatively uhttpd -k 0 > Thanks > > What happens to RAM and CPU usage when there are multiple tabs open with > > keep-alive on? > > Testing with 6 open browser tabs, all refreshing the main status page: > > With POST keep-alive: uhttpd VSZ 4316K, CPU 5% usr, 6% sys > Without POST keep-alive: uhttpd VSZ 4756K, CPU 11% usr, 8% sys > > Thats not a scientific benchmark though. In general you trade CPU (TLS > setup, > TCP connects) for memory (resident established connections). > > In case of non-malicious clients (like normal browser tabs background > refreshing data) the memory resource consumption seems to be even lower > because there's less active TLS sessions at every point in time. And > almost no > TLS connection attempts once all requires sessions are established. > 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?
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
