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
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
