HTTPS on .local

[chrysn]

Hello Flyweb developers,

looking into the state of flyweb, I haven't found anything on the actual
status of HTTPS in the flyweb context; all the security documents are
problem statements, and the tracking bug[1] is empty.

The approach I'm seeing right now is to use _flyweb._tcp instead of
_http._tcp as an indicator to use ad-hoc UUID host names; that appears
to me to be a workaround for the origin issues that will only allow
persistent names at all if HTTPS is used and the name is derived from
the server key material ("application level CGAs?"), and will not
provide the sharability and reusability usually expected of a URL
(because while being universal, it fails the "L" in "URL").


To me it'd sound simple and straightforward to apply classical PKI based
identity checks where possible (eg. a media server on my LAN announces
itself as https://shared.example.com/; whatever is good enough to
certify the identity of that explicitly entered address will be good
enough serve the discovered service at that hostname[2]).

Only on the .local and (.home).arpa domains (and possibly raw addresses
or whichever scheme you'll use if this hits bluetooth), for which nobody
can create valid certificates from the PKI, a TOFU (or, later on, any of
the more elaborate one-touch schemes) approach is used to store the
server's certificate as the only valid certificate[3] for that name. The
server would be free to use certificate pinning to broaden the range of
acceptable certificates.

When the user browses to a service again (even on a different network in
a later browser session), it will be announced with the same name, and
checked against the stored key; the origin is then clear for access to
all personal data stored in that context (cookies, local storage, etc).
If the certificates don't match, a security warning is shown to the user
about the discovered server not being authorized to serve this resource
(or possibly, as would happen with the UUID names if they persisted,
something very similar to a "Server not found" message). The only user
visible option (apart from leaving the page) would be to clear all
memory of that server (including cookies etc), and TOFU again.


Wouldn't that cover the desired security properties without resorting to
unsharable and unreadable URLs?

Did I miss something that's already there to cover Flyweb over HTTPS, or
other reasons for the UUID URLs?

Best regards
chrysn

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1335286
[2]: Such announcements seem not to be supported by flyweb right now.
The ciaociao add-on happily uses them, though, and IMO flyweb should
too, as they are what I'd expect to happen in a managed but locally
discoverable network.

--
To use raw power is to make yourself infinitely vulnerable to greater powers.
-- Bene Gesserit axiom