20.xx: postponse LuCI HTTPS per default

Paul Spooren mail at aparcar.org
Fri Nov 20 14:23:04 EST 2020


On Fri Nov 20, 2020 at 7:35 AM HST, Adrian Schmutzler wrote:
> Hi,
>
> > -----Original Message-----
> > From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> > On Behalf Of Alberto Bursi
> > Sent: Freitag, 20. November 2020 17:32
> > To: openwrt-devel at lists.openwrt.org
> > Subject: Re: 20.xx: postponse LuCI HTTPS per default
> > 
> > 
> > 
> > On 20/11/20 17:17, Fernando Frediani wrote:
> > > Hi Alberto
> > >
> > > On 20/11/2020 13:09, Alberto Bursi wrote:
> > >>
> > >> <clip>
> > >>
> > >> The only thing I can accept as a valid complaint against https by
> > >> default is the increased minimum space requirements, everything else
> > >> I really don't understand nor agree with.
> > >
> > > It's exactly this I am referring to when I talk about the extras not
> > > the steps the user will take to enable it. So why I mentioned to leave
> > > it as optional and easy to do for those who wish (and have space) to have
> > it.
> > >
> > 
> > Devices with low flash space (and RAM) are already receiving special
> > treatment (different compile options, different default packages) to lower
> > space footprint.
> > 
> > These devices can (should?) be left out of the "https by default" easily.
>
> No, this is not an option. We certainly won't have (read "maintain")
> _two_ defaults for a matter like this.
>
> Apart from that, this discussion was not intended to discuss the various
> options _again_, but to ask whether we should have "https by default" as
> a _blocker_ for the next release.
> Personally, since the discussion seems to be as open and unresolved as a
> few months ago, I'm against making this a blocker. I'm curious where the
> whole topic evolves to, but that's not the subject of this thread.

How about we use `luci-ssl` per default but set `redirect_https` to 0.
This way everyone can access in a secure way, without changing the
current user experience.

An optional combination of Luiz idea could warn the users using HTTP,
allowing to "ignore" or "activate redirect".

I think that's a feasible solution for 20.xx. Spinning up a massive
HTTPS dDNS or defining a new standard accepted in all common browsers
seems a bit out of scope, for now.

Paul

>
> Best
>
> Adrian
>
> > 
> > But I would be strongly against degrading security for everyone just because
> > of these devices.
> > 
> > -Alberto
> > 
> > > Regards
> > > Fernando
> > >
> > >>
> > >>
> > >>> 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
> > >>
> > >>
> > >> -Alberto
> > >>
> > >> _______________________________________________
> > >> 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




More information about the openwrt-devel mailing list