OpenWRT LuCI GUI with UHTTPD using HTTPS

It is needlessly confusing, even with the OpenWRT GUI interface...

Installation

opkg update

opkg install luci-ssl-openssl luci-app-uhttpd

Configuration File(s) Location(s)

/etc/config/uhttpd

Default location for HTTPS / Certificate related files: /etc

Working Configuration File (with a catch)

The catch is that the uhttpd.crt and uhttpd.key file must exist (read on)

config uhttpd 'main'
	option home '/www'
	option rfc1918_filter '1'
	option max_requests '3'
	option max_connections '100'
	option cgi_prefix '/cgi-bin'
	list lua_prefix '/cgi-bin/luci=/usr/lib/lua/luci/sgi/uhttpd.lua'
	option script_timeout '60'
	option network_timeout '30'
	option http_keepalive '20'
	option tcp_keepalive '1'
	option cert '/etc/uhttpd.crt'
	option key '/etc/uhttpd.key'
	list listen_http '0.0.0.0:80'
	list listen_https '0.0.0.0:443'
	option redirect_https '1'

config cert 'defaults'
	option days '730'
	option key_type 'rsa'
	option bits '2048'
	option ec_curve 'P-256'
	option country 'ZZ'
	option state 'Somewhere'
	option location 'Unknown'
	option commonname 'OpenWrt'

Firewall

Don't forget to add settings to the Firewall. This is only needed if remote management is needed. Even though UHTTPD is really good about security, it is strongly recommended to restrict GUI access to a limited number of IP Addresses. See example below;

config rule
        option dest_port '22'
        option src 'wan'
        option target 'ACCEPT'
        option family 'ipv4'
        list proto 'tcp'
        list src_ip 'W.X.Y.Z/S'
        list dest_ip 'Z.Y.X.W'
        option name 'SSH_TCP_22'

config rule
        option dest_port '80'
        option src 'wan'
        option target 'ACCEPT'
        option family 'ipv4'
        list proto 'tcp'
        list src_ip 'W.X.Y.Z/S'
        list dest_ip 'Z.Y.X.W'
        option name 'HTTP_TCP_80'

config rule
        option dest_port '443'
        option src 'wan'
        option target 'ACCEPT'
        option family 'ipv4'
        list proto 'tcp'
        list src_ip 'W.X.Y.Z/S'
        list dest_ip 'Z.Y.X.W'
        option name 'HTTPS_TCP_443'


config rule
        option dest_port '4443'
        option src 'wan'
        option target 'ACCEPT'
        option family 'ipv4'
        list proto 'tcp'
        list src_ip 'W.X.Y.Z/S'
        list dest_ip 'Z.Y.X.W'
        option name 'HTTPS_TCP_4443'

In the above example, of course replace 'source' and 'destination' IP Addresses with proper ones. The port 8080 and 4443 items are shown as a reminder that anyone using OpenWRT as a web server will need to take ports 80 and 443 into consideration when managing a router (IE, can't double up on the ports, as something won't work properly).

Configuring SSL (but not with the LuCI GUI)

Forget about installing or configuring access to the LuCI GUI with the LuCI GUI. How, oh how can it be configured to work?

• Go back up to the top and read the part about installing the luci-ssl-openssl package. Make sure it is installed.
• Restart the UHTTPD service and it will generate the proper SSL certificate, etc.
• Good to go

Here's why the GUI is a bit misleading: There are two buttons that prompt one to "Select file". What it doesn't say is that the "Remove old certificate and key" Button will not work reliably unless the above information is configured in the /etc/config/uhttpd file.

In fact after an hour of testing the LuCU HTTPD GUI was so wonky and unpredictable, it became pointless to give explicit directions. That combined with a rather curious feature of clicking on the "Remove old certificate and key" Button redirecting to a URL that claims it "can't display this page", but is the exact same as the one can go "back" to, that works.

And the final nail in the coffin is this: "This permanently deletes the cert, key, and configuration to use same." What? What is that? That is a direct copy and paste from the help information available in the LuCI GUI about what will happen if the "Remove configuration for certificate and key" Button. It is not helpful at all. It is confusing. The label on the Button itself is more clear than the help information. And having help information that makes things more confusing is not helpful. That much is obvious. OK, enough bashing. That's easy to do. Understanding is difficult. The best guess as to what happened with the UN-helpful information is that someone familiar with the subject matter, probably the programmer, quickly jotted down a note that made complete sense to them. And there wasn't enough time to proof read it or no one like an editor came behind them and tried to correct anything. So here's my contribution for the "help information";

- First, the "Remove configuration for certificate file and key" Button label should be changed to DELETE or REMOVE as the text that precedes the Button already says, you guessed it "Remove configuration for certificate and key"

- Second, here's what the "help information" should say: Clicking the "Remove / Delete" Button will permanently delete the certificate and the key files that are required for HTTPS* to function (*HTTPS utilizes what is commonly referred to as SSL, but is now TLS (see https://en.wikipedia.org/wiki/Transport_Layer_Security)).

- Third, a comforting follow up statement should be made: ...but even though those files will be deleted, that's OK. Here's why. We (being the OpenWRT people or the UHTTP people), were smart enough and wise enough to program the UHTTPD service to automatically create a new certificate and key when restarted. So even if you delete the certificate and key file, that's OK, a new one will be created. Below is the output generated if the certificate and key are deleted and the UHTTPD service is then restarted

root@OpenWrt:/etc# service uhttpd restart
4+0 records in
4+0 records out
Generating a RSA private key
..........................+++++
..................................+++++
writing new private key to '/etc/uhttpd.key.new'
-----

Wait! What about the configuration file? Yes, that will be deleted too. Solution? Command line prompt, remove UHTTPD, reinstall UHTTPD. This of course assumes one has command line prompt access to the router. But that's easy. If you're reading this, you probably already know how. If you don't, it's new and might be scary, but it's easy. Relax.

Items of Note

The "Redirect all HTTP to HTTPS" check box should be renamed to "Redirect all HTTP to HTTPS (if HTTPS is available)". IE, if that check box / setting is enabled AND HTTPS is not functional, HTTP will work. This is a good thing. Otherwise the LuCI GUI wouldn't work.

The Remove configuration for certificate and key button should have it's help information re-written to this: Clicking this button will result in the deletion of HTTPS related certificate information. This includes settings and the files (/etc/uhttpd.crt and /etc/uhttpd.key by default).

Do not put in the entry: list listen_https '0.0.0.0:443'

...unless this is also set to enabled: option redirect_https '1' (if it isn't set to enabled, the above 443 entry by itself will break access to port 80)

The "Add" Button is misleading because of its placement. It has nothing to do with certificates. It generates configuration for an additional instance of the LuCI GUI. Really useful. Not.

The "Remove old certificate and key" Button is very unpredictable based on too many variables to keep track of. See above section on how to manipulate it into creating a certificate file. Wow! Here's an idea: What about a button that says "Generate New Certificate (based on the below information)"* *Note: This will delete the old certificate related information and replace it with new information. Oh, and also make it work by having some GUI validation that doesn't allow checking of the use HTTPS unless there is certificate information available. And about a dozen other things.

Bottom line is that this LuCI GUI is rough and needs some tweaks. You're better off using text files to configure UHTTPD.

Questions

Given the push for everything being secure, it's really a wonder all of this isn't part of a default package thing for the Linksys AC Series of routers given how much storage space they have. For smaller routers with less storage space, it is certaintly understandable for conserving storage space, yet... Hmmm...