Could be interesting to see what Let’s Encrypt would say, yeah – but I don’t think they’re the ones blocking any of this (DNS is the main challenge). Though if there were some trick for them to be able to issue certs for private IP addresses or .local domains, it could be interesting, but seems unlikely (as no trusted CA should be allowed to do this, as they can’t verify ownership).
I agree that asking end-users to set up the network pieces for the “general case” would be hard, but the specific case I’m thinking of is preloaded hotspot devices like a Raspberry Pi or RACHEL (Intel CAP), which serve as the access point and also the web server. These devices already act as a DNS server (via dnsmasq), have their own fixed IP, and could be preloaded with a unique cert that does what we described above. No special configuration would then be needed by the end user. If a router were being used instead of something integrated into the server, then one additional step would be necessary: logging into the router and setting the DNS server to point to the local server’s IP. And if it’s a semi-connected scenario (with a low-bandwidth upstream Internet connection), then even without local DNS set up, the central DNS would kick in and point clients to the correct local IP for the server.
In terms of identity/MITM, an attack scenario could be:
- Set up a spoofed access point with the same SSID as the one listed on instructions on the wall.
- People accidentally connect to the spoofed access point instead of the legit one (no way to tell the difference).
- They would go to the Kolibri web UI. It might have HTTPS set up as well, and look “trusted”. They enter their credentials, which are then logged by the attacker.
This is where identity comes in – in principle, the poster on the wall could also list the expected subdomain. If we only issued a single certificate for each subdomain (or only reissued to someone from the same org/email), then there’s no way the attacker could provide HTTPS over that same subdomain, so the certificate is serving its role as an identity provider. This of course assumes that the human would be paying attention to this, which is frequently going to be unlikely (just as it is on the Internet, with phishing sites – most users don’t know how to interpret URLs). However, in Kolibri, we also do a lot of P2P backend communications over the local network – e.g. syncing user data from one device to another – and computers are far better at paying attention to identity, so this could be a huge security boost to the backend communications).