A proposal of https certificate assignment system for luci

[Daniel Golle]

Hi Alberto,
Hi Michael,
Hi everyone else,

On Tue, Oct 06, 2020 at 11:00:42PM +0200, Alberto Bursi wrote:
> 
> 
> On 06/10/20 19:43, Michael Richardson wrote:
> 
> 
> > 
> > Training users to click through those warnings is exactly what browser makers
> are trying to avoid, and browser makers have been trying to make the
> exception harder and harder to find.  Many would like it removed.
> And, for good reason, because it is almost always inappropriate for most
> non-technical users to do that.  [Children, (grand)parents, etc...]
> 
> What are childern and grandparents or non-technical users doing with a
> network device's administration interface? There is nothing for them there,
> most functions are well above their understanding of the device and network,
> they can break configuration, lock themselves out from Internet access, or
> disable security settings.
> 
> The device interface even on a normal router or NAS is actually accessed
> only by people that have some idea of what they are doing, or tinkerers that
> are playing with it, or power users that use it in a more professional way.
> 
> Which is why I'm saying the warnings and clicking the buttons are fine,
> because the audience is a specific subset of the population.
> 
> Grandma, kids, non-tech-savyy people and whatnot will have someone, the
> so-called "friendly family nerd" or an actual specialist that will set up
> the device for them.
> 
> > So, honestly, anyone that needs screenshots to figure it out, should never
> be clicking through the links.
> 
> new generations of power users still need to learn from somewhere.
> 
> > So, just to be clear, are you saying that we should design openwrt to only be
> > useable by developers?
> 
> The right word is "power users" or "prosumers".
> 
> They aren't developers, they may not be network administrators either, but
> they know enough about the concepts to work on the devices in a relatively
> safe manner.
> 
> You don't seem to acknowledge that to get OpenWrt on your device, you must
> void warranty and install a custom firmware, taking risks and assuming
> responsibility of their actions. These aren't your kid or grandma or plumber
> or random commoner.

I don't understand how your argument is related to that pretty nice
suggestion regarding a fairly complex and (unfortunately) relevant
problem.
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/ )