20.xx: postponse LuCI HTTPS per default
Paul Oranje
por at oranjevos.nl
Fri Nov 27 17:51:59 EST 2020
> Op 20 nov. 2020, om 03:24 heeft ansuelsmth at gmail.com het volgende geschreven:
>
>> Given that the first login via LuCI, on a fresh install, is not with a
>> password anyway. What if setting the initial password sets up
>> letsencrypt also. Then when letsencrypt's first successful cert install,
>> https gets enabled as the default and then requests the user reboot to
>> complete the setup and will force their next session to https.
>>
>> I agree that https with self-signed certs are not good, especially on a
>> first boot/install device.
>>
>
> My 2 cents, I still think that have a properly verified cert is madness.
> I really think that to address this the best way would be to add a big
> And very explicative alert to the first login page.
> The process would be
> 1. First boot --> First login (no password set) Append to the already
> present alert about password-less system, an alert about self signed
> cert and that the browser will tell that the router page will not be secure.
> (again this must be very explicative and easy to understand)
> 2. As soon as the user set a password, the webserver is restarted with
> http disabled/redirected and https now enabled. The user should now
> know that the page is secure and that he can whitelist/allowlist(for the
> inclusive people :D) it.
>
> This way the user won't be scared of unsecure page and can understand
> why the page is secure. Also if we want to push security to an upper level
> with self signed cert, we can ask the user to insert some data so that the
> self signed cert can be generated based on that and actually validated by
> the user (to prevent any MIT attack)
+1
The only conceivable way to proceed from a first start where security only exists in that the first run is in an environment not exposed to the evil world towards being exposed and prepared. That without having to rely on previously established (secure) DNS combined with DANE (and a webbrowser that does support DANE, currently not one mayor does) or a valid certificate which does not fit the use-case at hand.
>
>> Cheers
>> Derek
>>
>> On 11/19/20 6:09 PM, Paul Spooren 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.
>>>
>>> Sunshine,
>>> Paul
>>>
>>> [0]: https://openwrt.org/docs/guide-developer/releases/goals/20.xx
>>>
>>> _______________________________________________
>>> 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