[RFC] self-signed certificates for LuCI

[Michael Richardson]

Paul Spooren <mail at aparcar.org> wrote:
    > On 30.08.20 12:32, Michael Richardson wrote:
    >> Paul Spooren <mail at aparcar.org> wrote:
    >> > I recently rewrote px5g[1] to use WolfSSL instead of MbedTLS, as the former
    >> > will be included in OpenWrt 20.x per default.
    >>
    >> > Both implementations support the generation of RSA and ECC keys, where uhttpd
    >> > currently defaults to RSA with 2048 keys.
    >>
    >> > The question came up if we really want RSA certificates for LuCI or if the
    >> > faster and "more modern" ECC P-256 wouldn't be a better choice.
    >>
    >> Yes, it would be better.
    >>
    >> > If px5g is added to the next release, certificates are generated on first
    >> > boot and most users are unlikely to manually recreate RSA ones, not?
    >>
    >> But, this will result in a security warning for a self-signed key, and then
    >> we'd be training users to click through them.
    >> I am divided on whether this is better or worse than unencrypted.
    >> browsers are making doing that security exception more and more difficult,
    >> with the desire to eliminating it entirely.

    > I think we should write a bit of documentation explaining that a cert should
    > be accepted only once or a router reset is required. That seems more save
    > than sticking to unencrypted connections. If browsers decide to block
    > self-signed certs, most UBNT devices will break, too.

Yes, many many many devices will break.
But browser makers don't really care about that.
This is a no-win situation until we can find a way to give proper names and
certificates to devices.

    >> I have running code that deploys LetsEncrypt certificates to devices in the
    >> "factory".   This requires a DNS name for dns-01 challenge.
    >> That's clearly not feasible for random end-users who flash openwrt on their own.
    >> I would like to explore some additional options here.

    > Mind sharing this code? Me (and Daniel) had the same idea, so some ACME
    > support for px5g would be interesting.

Sent my private email.

    >> > So the question, shouldn't we drop all crypto options from the new px5g
    >> > implementation and _only_ offer P-256? Whoever wants something else than the
    >> > default may use px5g-mbedtls or some OpenSSL based tool?
    >>
    >> uhm, okay.  I can live with that for sure.
    >> I care more about what's in the certificate than the algorithm.

    > Fair, however this question is about the algorithm :)

Picking the algorithm is a detail that will change every five to eight years.
figuring out how to populate the SubjectDN and SubjectAltName is more
important.

As long as users are being trained to override certificate exceptions, then
the certificate provides very little benefit.

--
]               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    [