A proposal of https certificate assignment system for luci
Bas Mevissen
abuse at basmevissen.nl
Mon Oct 12 04:44:55 EDT 2020
On 2020-10-11 00:58, Michael Richardson wrote:
> Bas Mevissen <abuse at 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 [
> ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on
> rails [
>
>
> _______________________________________________
> 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