Discovery using QR codes and LetsEncrypt, fixes #3

[michielbdejong]

No description provided.

[pauljt]

So drawback of this solution that I overlooked is the need for the Bridge to publish a DNS record so that the generated sub-domain used for issuing the certificate resolves to an internal address. Apart from the privacy concern of publishing an internal IP address, DNS propagation time or other DNS issues might be a problem. (especially for internal networks which switch DHCP-assigned addresses frequently)

[michielbdejong]

Yes! Another option would be to include the IP address in the domain name (like plex do with https://192-168-0-16.deadbeefdeadbeefdeadbeefdeadbeef.plex.direct/), and then either use a wild card cert (not currently supported by LE) or simply register a new cert each time the IP address changes.

But then how does the client discover the new URL? They would either have to scan a dynamic QR code each time, or visit some redirecting/iframing URL.

[michielbdejong]

EDIT: No separate QR-code reader needed if we include https://webqr.com/ into the app.

[michielbdejong]

Ah, thought of another option: don't create <fingerprint>.knilxof.org but <fingerprint>-1.knilxof.org; when the client loses ping of the Box, it checks if <fingerprint>-2.knilxof.org exists, and if so, switches to it. Testing this now to see if DNS propagation is then really instant.

[pauljt]

I'm sure you just assume this, but as part of this process the box needs to generate an RSA keypair (unique, and never leaves the device)

[michielbdejong]

In this proposal, using the QR code has two advantages:

• avoids the leap-of-faith for the client when first connecting to the box (but this can be mitigated by the third bullet point from Whitelist Box client certs and app origins registration_server#16 (comment))
• adding a secret into the QR code URL allows the Box to know whether a connecting client has had physical/optical access to QR code sticker. But if a malicious device does the Box's initial admin user setup before the user's legitimate client does, the user will be able to detect this (an admin user already exists, and the user cannot get in), and reset to factory settings. If we abandon passwords then we can just allow (bar rate limiting) random clients to try to brute force access to the Box, since it would be very unlikely they would succeed.

It also has a big disadvantage compared to #6: the user needs to scan a QR code, enter a serial number, or perform some other type of action to prove that they have physical access to the Box. The concensus within Project Link is that this disadvantage doesn't weigh up to the advantages, so I'll retract this proposal.