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/ ) _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
