On 2020-10-11 00:58, Michael Richardson wrote:
Bas Mevissen <ab...@basmevissen.nl> wrote:
> A security conscious user/administrator would install a router
without any
> untrusted computers connected to the LAN side and setup the
device properly
> before allowing others to connect. The WAN side connection is
not important,
> as Luci is not listening there by default.
sure.
What do security unconcious people do?
Just put it in use with the build-in defaults. It is not without reason
that ISP routers nowadays come with a semi-unique SSID and securely
generated wifi passwords. With OpenWRT we should aim to get the best
possible security with the least effort (on user side) possible.
ISP routers usually only support HTTP or HTTPS with a self-signed bogus
certificate for the admin interface.
> previous OpenWRT install. Then the user can setup the WAN side
if needed and
> upload (from local PC), generate (self-signed) or acquire (e.g.
Let's
> Encrypt) the certificates for Luci. After that, the connection
is switched to
> HTTPS and HTTP switched off.
This is a a good story, but it doesn't have to be the only story.
It is the story where we can give the best out-of-the-box guidance and
hopefully cover most installs.
> The only issue I see, is how to transfer admin, WAN and WiFi
passwords at
> first boot in a secure way. Even though the user/admin should be
alone on the
> connection, sending those unencrypted over the line is not
desirable. Maybe
> those can be encrypted using client side javascript.
There is nothing you can with javascript here that wouldn't just be
security threatre. If you had anchors you could trust, then it would
be done.
The trust comes from being the only one connected to the specific box.
If that is not guaranteed, it is very hard to impossible to be 100%
sure. It at least requires a specific certificate being installed on a
specific box. If you are on that level, you don't need the guided
certificate install anyway. With my proposal and the requirement of
being the only one on the network, you get pretty close to that level.
> The challenges IMHO are being able to safely retain previously
installed
> certificates over OpenWRT reflashes/upgrades and having user
friendly tools
> to get new certificates uploaded, generated or acquired. For the
latter part,
> some configurable service to periodically download and install
certificates
> from an external host might be desirable (that's how I do it with
my NAS
> boxes at home).
You need a name is DNS, then it's just a dns-01 challenge.
I believe the most common being an HTTP-01 challenge (see
https://letsencrypt.org/docs/challenge-types/). So you need a DNS entry
pointing to your (dynamic?) IP and a HTTP server under OpenWRT control
running on port 80 or 443. That is not always practicable for home
internet connections.
I found it to be much more practicable to have the certificate generated
and renewed on an external host (with the FQDN of my NAS boxes pointing
to that host in public DNS) and download the certificate files at
regular intervals. Inside my network, the name of the NAS is resolved to
its local IP address.
Anyway, the options to upload, generate or acquire will probably cover
the most common cases and are not hard to implement.
Regards,
Bas.
--
] Never tell me the odds! | ipv6 mesh
networks [
] Michael Richardson, Sandelman Software Works | IoT
architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on
rails [
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
