[OpenWrt-Devel] [PATCH uhttpd] client: allow keep-alive for POST requests

Wes Turner wes.turner at gmail.com
Fri Mar 13 13:42:41 EDT 2020

On Fri, Mar 13, 2020, 12:39 PM Jo-Philipp Wich <jo at 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


> > 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"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20200313/72aaf92b/attachment.htm>
-------------- next part --------------
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list