I just installed the latest LEDE version 17.01.04 on a TPLINK WDR4300 (having OPENWRT 15 before) and the first thing I did is installing luci-ssl for secure access.
But in SSL mode luci takes 5-10 seconds to display a page. I also notice the browser TLS-handshaking messages in its status bar. Also I notice that a page it transferred quite "blockwise". So: first half of page, some seconds waiting and then another chunk or rest of the page.
When researching this I at first noticed the messages saying that LEDE 17 is quite more hungry for resources than OPENWRT 15. But then I disabled http redirecting and tried normal http on port 80.
This is incredibly fast without any lag!
So either then SSL encryption overhead in LEDE got incredibly high or there is something buggy here.
I also tried other uHTTPd parameters like http_keepalive = 0 to no avail.
Does anybode have a clue to come to normal speed in SSL mode with uHTTPD?
128 MB is still plenty for normal uses, https/ ssl doesn't really change that. My tl-wdr4300 running a recent master snapshot shows no such slowness using luci-ssl-openssl (~1s or less, the status overview takes slightly longer).
Thank you. I tried that and agree. I now installed luci-ssl-openssl and everything is high-speed as it always was before.
luci-ssl with mbedTLS seems to have a massive performance issue! I consider it unusable.
The performance impact should be noted somewhere in the package. I should maybe only be used for devices not having much RAM to afford the bigger openssl library.
It would probably be interesting to repeat that test with current master, before drawing any conclusions. While it's not surprising that openssl is faster than mbedtls, it shouldn't be to this extent.
I can confirm this behavior. My Luci has been very slow for as long as I can remember. I just installed luci-ssl-openssl after removing luci-ssl and luci is very snappy again. I'll test this out on a master branch as soon as I install a master branch for other purposes as well.
uHTTPd will always have a slight lag, as it's not asynchronous, however not to the degree you're experiencing.
As to luci-ssl-openssl, none of the luci-ssl packages are required for TLS, and the only thing the luci-ssl packages have that's different than the plain luci pacakge is a script that runs upon LuCI's first start to auto create a self-signed SSL cert. This is a horrendous way of securing a web server since it leaves the user wide open for a MITM attack.
Is an MITM attack likely on a home LAN, no, but it is possible. Things should be done right the first time around, and self-signed certs should never be used... period.
The correct way would be to create a self-signed CA with a 4096bit signing key and using that CA to sign the SSL cert for the web server.
Steps to do so, and commands required, can be found starting on Line 430 of this pre-built openssl.cnf
All information over HTTP is plain text, so accessing LuCI over HTTP sends the root password as unencrypted plain text.
I think this might be an edge case or the other way around as playing around with OpenVPN shows that mbedtls is faster than OpenSSL on MIPS at least. http://projects.pyret.net/dump/lede/openvpn-benchmarks.txt - Just a quick bench....
Not sure what this has to do with this thread... But SSL ciphers should not be used with OpenVPN, especially OpenVPN 2.4, which added support for EC ciphers. That test needs to be redone using EC TLS ciphers, preferably ECDHE.