A proposal of https certificate assignment system for luci

[Fernando Frediani]

I am not sure click though certificate warning is that much of a 
security issue in this context neither OpenWrt should have certificates 
issued by default if I understood it correctly.

Most people accessing OpenWrt LuCI interface knows what it is and would 
not find it strange to have to accept a self-signed certificate.
Also OpenWrt devices mostly are accessible from internal and restricted 
networks and not exposed to the Internet. Still if necessary it is still 
possible to add its own valid certificate to it on those cases where 
necessary.

I think the steps outlined below can be a valid thing, but not to be 
done automatically. As an optional procedure to make the things easier 
for those who have a need to a certificate on certain scenarios.
In such way we keep the things simple as possible.

Regards
Fernando

On 04/10/2020 10:48, abnoeh wrote:
> Few months ago there was some debate for how we handle certificate for
> luci page: make user to click though certificate warning is not that
> great for security so here is a  proposal for autometically assign a
> worldwide unique subdomain and how to make valid certificate for it, and
> make sure we and connect to the device he is expecting.
>
> Openwrt as project get a CA certificate with name constrained to only
> able to sign subdomains of [luci.openwrt.org]. this makes we Technically
> Constrained Subordinate CA, (from let's encrypt or digicert), let's call
> it the Openwrt CA here (CA ) this makes we don't create too much load to
> normal CA like let's encrypt, and as we have complete control of this
> zone we can give subdomains as we want like, and don't need full audit
> like fully pledged CA and handled like a wildcard cert for them, but the
> CA system can be hosted by us and request won't offloaded to upper CA's
> server. (except OCSP request, but it can be cashed)
>
> and assignment of a subdomain and it's certificate happens this way :
>
> {everything below will be done on https or otherwise encrypted channel}
> 1. on first boot, router want to get it's luci certificate send its ssh
> host key to Openwrt CA reserve subdomain base32(hash of public
> key).luci.openwrt.org (like onion v3 addressed does)
> 2. Openwrt CA sends nonce to our router
> 3. router signs nonce+timestamp+[hash of CSR] with sent ssh host key,
> and send back to openwrt CA send this signed message with CSR
> 4. Openwrt CA verify other end controls host key match with hash and
> confirmed the CSR, sign the certificate with (key from CSR/SAN with
> domain we derived from host key) and sent back to router
> 5. router now has valid cerfiticate, redirect 192.168.1.1 or openwrt lan
> to https version of signed subdomain
>
>
> now user only have to check :
>
> 1. page has valid certificate
>
> 2. the subdomain is match with device's ssh host key
>
> and this verify  it's the device we wanted.
>
>
> --- some consideration
> A. how authoritative DNS server reply on public dns lookup those
> luci.openwrt.org? act like an dDNS with same verification for DNS
> update, or just not answer?
> B. router itself need to catches it's on subdomain lookup and answers
> it's own address on LAN side.
> C. this idea doesn't have real way to ratelimit the certificate request
> other them by request ip: I'm not sure that'll be enough
>
> D. Let's encrypt doesn't like to sign such certificate as normal
> service, but maybe we can persuade them to sign one (it's one time job
> for them)
>
> E. with this now we have another server to manage.
>
>
> P.S is this too large wall of text?
>
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel