20.xx: postponse LuCI HTTPS per default

[Alberto Bursi]

On 20/11/20 19:22, W. Michael Petullo wrote:
>>>>> 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.

I think that if the first setup is done with only the router and the 
trusted PC connected to it through an ethernet cable (wifi is disabled 
by default), there is physically nothing else on that "network" so 
whatever you see can be accepted even if you don't have "dual 
authentication" with the serial port.

The only way for that to go bad is if your PC isn't trusted, but if 
that's the case, using a serial console from the same PC won't help much.

Although I understand what you mean.

> 
> 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.
> 

How can you recreate a secure two-step verification process without two 
different communication mediums? I don't think it is possible, so this 
isn't viable.

Imho the only thing that can be done for most devices is adding a http 
landing page that explains how to do the first pairing in the most 
secure way, like I said above.

"make sure the device is connected through an ethernet cable to a 
trusted PC only, and that there are no other ethernet cables connected 
to this device, when you are ready to accept the self-signed certificate 
press OK button"

And when you press OK it will redirect to https and you will get the 
warning and must accept it.

Does it make sense to add this kind of "first setup" webpage to the 
device's web interface? Maybe.

I have already mentioned some time ago in the older version of this 
discussion that 99% of the users that are doing this for the first time 
are going to be following some documentation anyway, so we could just 
write this down in the install tutorial in the wiki.

-Alberto