Activate https server support in 21.02 by default

[Etienne Champetier]

Hi Hauke,

Le dim. 16 mai 2021 à 09:21, Hauke Mehrtens <hauke at hauke-m.de> a écrit :
>
> On 5/14/21 4:22 PM, Etienne Champetier wrote:
> > Hi All,
> >
> > Le ven. 14 mai 2021 à 05:00, Petr Štetiar <ynezz at true.cz> a écrit :
> >>
> >> Fernando Frediani <fhfrediani at gmail.com> [2021-05-11 20:13:18]:
> >>
> >> Hi,
> >>
> >>> I am no sure https support should still be something by default in the
> >>> images as it's not something really essential
> >>
> >> to me it's like discussion about telnet versus SSH. (Puting aside, that one
> >> shouldn't be using password at all) If it's fine with you to send your
> root
> >> password over telnet, then SSH is not essential, I agree.
> >>
> >> FYI HTTPS wouldn't be enabled by default, it would be *available* by default,
> >> giving users of default release images choice for management of their devices
> >> over HTTPS, by doing so *explicitly*.
> >
> > I'm all for HTTPS to be shipped by default
> > One painfull "bug" that some people might face having both HTTP and HTTPS,
> > when you login using HTTPS, the sysauth cookie has secure=true,
> > so you can't login via HTTP anymore because it's trying to modify the
> > secure=true sysauth cookie :(
> >
> > Etienne
>
> I ran into this when I first used an image with luci-ssl and then
> changed to one without it. What about setting a not secure cookie that
> tells the browser that https was used when we access LuCI over https.
> When the browser accesses LuCI now over unencrypted http the code will
> check for this cookie and forward the browser to the https version. If
> this cookie is not found, it behaves like before. If https worked once it
> will probably also work a second time.
>
> Is it even possible to handle the error when we want to overwrite the
> secure=true cookie and do a forward to https instead?

I would keep it simple and use different names, sysauth-http and sysauth-https,
and if you want to be redirected to HTTPS, just configure the redirection,
or trust your browser remembered to use https like last time (firefox
does for me)

Shipping at least 1 release without the redirection allows to iron out
any small bugs like that
and maybe get more people looking at the https config and cert we generate.
A quick look on my router:
- it talks TLS 1.2/1.3 only :)
- we generate RSA 2048 key which should be fine for some more years
but code signing now requires 3072
so don't know how many more years it'll be ok for HTTPS
- my cert is expired because it was generated before time was synced I guess
- cert life is 2 years
If I remember correctly notbefore / notafter constraints just do not
apply to self signed certs, so seems pretty good to me

Etienne

>
> Hauke