A proposal of https certificate assignment system for luci

[Eric Luehrsen]

> Apart from it being hard to proof that people wanting to access the
> configuration (and status!) interface of a device running OpenWrt (or
> something based on it) are all prosumers or developers, for future
> users this assumption even has the taste of a self fullfilling
> prophecy. To me, the situation with self-signed certificates and the
> resulting warnings is a bug, not a feature, and I do appreciate the
> debate on what we could do about it.
> 
> The suggested approach is possibly the best we can do in a world where
> reasonable connection security can only be achieved with the help of
> external certification authorities (and browser/consumer-OS vendors
> making everyone 'trust' them, by itself also a major bug which we are
> trying to work around here...).
> 
> It's a bit a matter of taste if the OpenWrt CA should associate the SSH
> host key (which then requires SSH on the router to be accessible for
> the CA to verify it) or if it wouldn't be easier to just use a hash of
> the to-be-signed public key. The latter option has the disadvantage
> that user then has no means to verify the identity using the SSH host
> key (which had to be accepted previously, a warning not as scary
> looking but technically quite the same as accepting a self-signed
> certificate in a browser). It has the advantage that it's even easier
> to do as no verification of any kind would have to be done while still
> providing a great improvement in terms of security by asserting a
> mapping between hostname and TLS key used for HTTPS.
> 
> However, then we still only got stuff like
> https://[b32(hash(pubkey))].devices.openwrt.org
> working, and of course http://192.168.1.1 and http://openwrt.lan may
> redirect to that, but httpS://192.168.1.1 would still give a warning
> about the certificate not being issued for that hostname.
> 
> Though it would also create some non-neglectable administrational
> overhead if actually deployed for the .openwrt.org domain, even just
> using a designated OpenWrt toy root CA certificate people can install
> manually in their browsers, downloadable from httpS://OpenWrt.org, is
> already much better than training users to accept invalid certificates
> (as long as they still can). And it provides a good example of how
> vendors downstream could do it right as well (and that may ultimately
> converge into a new industry standard for which there is obviously a
> desperate need. and that could then result in lobbying for a way
> to operate subordinate CA for such type of purpose).
> 
> A truely good solution to the actual problem imho doesn't exist
> (because https://youbroketheinternet.org/ )
> 

How about a completely different approach? Install a custom certificate 
on the developer or prosumer machine. It is normal to have an out of 
chain "business intranet" certificate to install. Most OS and browsers 
have a means to support this. OpenWrt would just need tools, helper 
scripts, or instructions for three cases: (1) For those using ready 
built images, each release (19.7.3 vs 19.7.4) has a different 
certificate the user can install. They download the image and 
certificate. This will get them the default "OpenWrt.lan" domain. (2) 
For those saving configurations, their router ID or domain can have its 
own certificate they install. LuCI can help build this for their first 
run through configuration before they save. (3) For those building their 
own images, they locally install a certificate of their own 
construction. They can option to find and include that certificate as 
part of menuconfig or just stuff in /file/etc/...

Anyway a start of an idea.
- Eric