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 > 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. Regards, Jo
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
