2020-11-21 오전 12:31에 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
if we move to https by default them it will include acme client by
default too?
if so, what client we will use? We currently have two choice for client
in package repo, acme.sh (named acme in openwrt) and
uacme(https://github.com/openwrt/packages/tree/master/net/uacme). but
non of that currently support wolfssl. (where we move to include by default.
acme.sh have gui luci-app-acme but it only runs with openssl, uacme
support embedded mbedtls(and can use openssl or mbedtls if supplied) and
somewhat smaller, but currently doesnt support any luci manager.
_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
