A proposal of https certificate assignment system for luci

[Bas Mevissen]

On 2020-10-11 00:58, Michael Richardson wrote:
> Bas Mevissen <abuse at basmevissen.nl> wrote:
>     > A security conscious user/administrator would install a router 
> without any
>     > untrusted computers connected to the LAN side and setup the
> device properly
>     > before allowing others to connect. The WAN side connection is
> not important,
>     > as Luci is not listening there by default.
> 
> sure.
> What do security unconcious people do?
> 
Just put it in use with the build-in defaults. It is not without reason 
that ISP routers nowadays come with a semi-unique SSID and securely 
generated wifi passwords. With OpenWRT we should aim to get the best 
possible security with the least effort (on user side) possible.
ISP routers usually only support HTTP or HTTPS with a self-signed bogus 
certificate for the admin interface.

>     > previous OpenWRT install. Then the user can setup the WAN side
> if needed and
>     > upload (from local PC), generate (self-signed) or acquire (e.g. 
> Let's
>     > Encrypt) the certificates for Luci. After that, the connection
> is switched to
>     > HTTPS and HTTP switched off.
> 
> This is a a good story, but it doesn't have to be the only story.

It is the story where we can give the best out-of-the-box guidance and 
hopefully cover most installs.

> 
>     > The only issue I see, is how to transfer admin, WAN and WiFi 
> passwords at
>     > first boot in a secure way. Even though the user/admin should be
> alone on the
>     > connection, sending those unencrypted over the line is not
> desirable. Maybe
>     > those can be encrypted using client side javascript.
> 
> There is nothing you can with javascript here that wouldn't just be
> security threatre.  If you had anchors you could trust, then it would 
> be done.

The trust comes from being the only one connected to the specific box. 
If that is not guaranteed, it is very hard to impossible to be 100% 
sure. It at least requires a specific certificate being installed on a 
specific box. If you are on that level, you don't need the guided 
certificate install anyway. With my proposal and the requirement of 
being the only one on the network, you get pretty close to that level.

> 
>     > The challenges IMHO are being able to safely retain previously 
> installed
>     > certificates over OpenWRT reflashes/upgrades and having user
> friendly tools
>     > to get new certificates uploaded, generated or acquired. For the
> latter part,
>     > some configurable service to periodically download and install
> certificates
>     > from an external host might be desirable (that's how I do it with 
> my NAS
>     > boxes at home).
> 
> You need a name is DNS, then it's just a dns-01 challenge.

I believe the most common being an HTTP-01 challenge (see 
https://letsencrypt.org/docs/challenge-types/). So you need a DNS entry 
pointing to your (dynamic?) IP and a HTTP server under OpenWRT control 
running on port 80 or 443. That is not always practicable for home 
internet connections.

I found it to be much more practicable to have the certificate generated 
and renewed on an external host (with the FQDN of my NAS boxes pointing 
to that host in public DNS) and download the certificate files at 
regular intervals. Inside my network, the name of the NAS is resolved to 
its local IP address.

Anyway, the options to upload, generate or acquire will probably cover 
the most common cases and are not hard to implement.

Regards,

Bas.

> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh 
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT 
> architect   [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on 
> rails    [
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel