20.xx: postponse LuCI HTTPS per default

[W. Michael Petullo]

>>>> I think making use of self-signed certificates in production is a bad
>>>> idea because (1) it reinforces poor practices, namely electing to trust
>>>> a self-signed certificate and (2) it does not authenticate the
>>>> server/router, a critical piece of the TLS security model.

>>> maybe, but it's still better than sending all communication to the
>>> management interface as plain text.

>> What is the difference between transmitting packets containing cleartext
>> and transmitting encrypted packets to a party whose identity you do
>> not know?
 
> What are you talking about? After the initial "pairing" process where you
> see the warning, the browser remembers the certificate for all subsequent
> connections.
> If the certificate changes (and it will change only if you do a firmware
> reset to default settings) you will see the the warning again.
> 
> So you are just changing a CA-based system to a local pairing system.

(I really do not mean for any of my comments here or earlier to be
patronizing. I am just trying to describe my point of view.)

When I make the first SSH connection to a new router, I confirm the
fingerprint of the router's key using a serial-port connection. Thus
I know it is safe to accept the pairing. If I were to skip this step,
then I would have no assurance regarding to whom my encrypted messages
were being sent now and in the future.

How would our scheme recreate this? What would the interface provide
to the user to help them perform this step? What would it recommend?
Some tugging on Luiz Angelo Daros de Luca's proposal earlier in this
thread (Fri, 20 Nov 2020 14:25:10), especially the addition of a suggested
verification process, might help.

-- 
Mike

:wq