20.xx: postponse LuCI HTTPS per default

[Fernando Frediani]

Yes, exactly it is only an issue when someone have to access the web 
interface via wifi. In a home environment that is a small issue. In a 
more corporate environment there are two options: 1) access is done via 
wired network or 2) enable HTTPS, which make more sense.

Enabling HTTPS by default is still not worth in my view given the extras 
that come with it and I like the idea of keep the default as simple and 
possible. Yes it is nice to have everything ready and automated to be 
done with a few clicks for those cases that require it. In fact I think 
this would be a better solution for now so it will be possible to gather 
gradually this transition (or not) from HTTP to HTTPS even for local/lan 
applications and see how often people would opt to use it.

Still should it end up having HTTPS by default I see self-signed 
certificates are the way to go. Yes there are the warnings and I really 
don't think there is any issue with it.
Those accessing the router Web Interface are not 'normal' Internet users 
and they know what they are doing so the warning from self-signed 
certificates should not be a surprise for them.
And those cases when admins prefer they can always replace the 
self-signed one for Let's Encrypt for example.

Regards
Fernando

On 20/11/2020 11:46, Alberto Bursi wrote:
>
>
> On 20/11/20 14:22, Fernando Frediani wrote:
>> I don't see having HTTPS by default in LuCI as something good or even 
>> necessary ? It's actually an unnecessary complication that could 
>> always be optional.
>>
>> One of the main reasons is that in many and probably most cases of a 
>> new deployed OpenWrt router there is still no Internet connection 
>> available. Also it doesn't seem to be that people need it since 
>> access by default is only done via the LAN interfaces.
>
> Not using SSL means anyone in the LAN can snoop the password to access 
> the router.
>
> While this is a non-issue for most home wired networks, it is for wifi 
> and most people will use wifi on their router.
>
> WPA2 is not going anywhere for a long while still and it is 
> susceptible to deauth attacks. After the attacker has captured enough 
> handshakes after the deauth they will know the wifi password. It just 
> takes a while but there are plenty of automated tools to do that 24/7 
> like Pawnagotchi (a raspberry zero running a dedicated application) or 
> wifi pineapples or whatever.
>
> Using SSL for web interface means the system is at least 
> compartimentalized so in case someone breaks into the wifi/LAN they 
> won't also take over the router as well.
>
>> If someone for some reason wishes for example to expose the LuCI web 
>> interface to the internet than fine to have it running on HTTPS and 
>> that can be enabled by those who wish to operate in such way. As this 
>> example there are certainly others that justify to have a HTTPS but I 
>> don't they they are most.
>>
>> The same way I see as interesting to have an automated way to 
>> generate SSL Certificates (ex: via Let's Encrypt), but again, that 
>> should be optional to only those who wish to use HTTPS for their 
>> specific needs.
>>
>> Fernando
>>
>> On 20/11/2020 06:44, Karl Palsson wrote:
>>> "Paul Spooren" <mail at aparcar.org> wrote:
>>>> Hi,
>>>>
>>>> The current list of release goals for 20.xx states[0] that LuCI
>>>> should use HTTPS per default. This works by creating on-device
>>>> a self-signed certificate. Self-signed certificates result in
>>>> warnings and may cause more harm than good, multiple discussion
>>>> are found in the mail archive.
>>>>
>>>> As no clean solution seems in reach while 20.xx seems close,
>>>> I'd like to suggest to postponse HTTPS LuCI (`luci-ssl` vs
>>>> `luci`) per default.
>>>>
>>>> This isn't a vote but a request for developer/user opinions.
>>> Very much in favour of leaving this off, self-signed isn't viable
>>> by default
>>>
>>> Sincerely,
>>> Karl Palsson
>>>
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>>
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel