20.xx: postponse LuCI HTTPS per default

[Stefan Lippers-Hollmann]

Hi

On 2020-11-19, TheWerthFam wrote:
> Given that the first login via LuCI, on a fresh install, is not with a 
> password anyway.  What if setting the initial password sets up 
> letsencrypt also. Then when letsencrypt's first successful cert install, 
> https gets enabled as the default and then requests the user reboot to 
> complete the setup and will force their next session to https.
[...]

This won't be possible in most cases. First of all you have a chicken
an egg problem, as you'd have to set a password over a different 
management channel (e.g. ssh) - this is more of a media-breach, than
accepting a self-signed certificate. Then there are a lot of cases where
setting up internet access in an automated fashion simply isn't possible,
at all, be it PPPoE (xDSL), having to use VLAN tagging, WAN over wireless
or LTE connections, before even thinking about internal infrastructure.
Users behind cgNAT (and that *very* common for cable, fibre or 4g/ 5g 
mobile users) simply don't have public IPv4 connectivity either (and often
no IPv6 connectivity either).

The next problem would be that this requires a public domain, which 
costs money and probably won't be easy to get sorted by many users.
Yes, OpenWrt 'could' fill this gap, by handing out subdomains to the
users, but this would require a lot of additional costly infrastructure 
and legal advice (what happens if a user doesn't behave and uses this 
for illegal activity, OpenWrt would be on the hook, at least first). 
Before even considering purely functional decisions, such as how to 
ensure unique DNS entries (no, as much as we'd like to, MAC addresses
aren't always reliably unique, even if you ignore intentionally spoofed
MACs) and stable over a factor reset.

Without a quite advanced service backend (similar to dDNS providers, 
which OpenWrt is unlikely to become), you'd also end up with rather
cryptic hostnames, which opens another can of worms (remembering it,
introducing ant raising the risk of phishing attacks, etc.).


Let's encrypt sounds like a great service, and it is for its intended
use cases, but it utterly fails for mostly stateless embedded systems
like routers, even more so for semi-internal (router behind a router, 
cgNAT, ...). I can't imagine any setup facilitating its features that
would cover a significant portion of OpenWrt's most common use cases,
without introducing serious problems and side-effects for a significant
number of OpenWrt users - and/or would require heavy investments into
OpenWrt's infrastructure (technical and legal).


Regards
	Stefan Lippers-Hollmann