Invites can be very simple, if we make several dubious assumptions: - The inviter is port forwarded, their IP doesn't change before the invite is used, and they are online at the time the invite is used.
Hence: - The invite is IP, port, password. MUST be exchanged out of band, but it's short enough that that isn't a big deal. - Password can be short because we only use it once. - TLS-SRP provides password-based encryption setup for HTTP. So we run an HTTPS server with TLS-SRP. - The HTTPS server provides the executable, including noderefs etc. This might be useful for the limited cases where it works, which hopefully is a significant number of people. But IMHO we can extend it. We should look at TURN, apparently there are TURN servers out there, in spite of their inevitable abuse; and other automatic port forwarding tools (e.g. Bonjour). Providing a customised HOWTO for your specific router is probably not feasible, although portforward.com does provide a generic guide for just about every router on the planet; we can link this (and maybe recommend people use tor to view it). However, lets assume we still have difficulties forwarding ports. If the executable is signed by FPI, we can use a friend of the inviter if the inviter himself/herself isn't port forwarded. This would require more interaction: - The inviter generates an IP:port:password pair. - The invitee uses this to connect to the friend of the inviter. - The invitee downloads the Freenet executable, verifies the signature and installs it. - The Freenet installation should not silently accept any noderefs included. - The installation checks for invite noderefs. - The invite noderef file contains a primary invite noderef (the person they downloaded it from), which may or may not have a flag indicating that they don't know the user, and a list of secondary invites, which may or may not be port forwarded (this is indicated too). - Normally these will be the original inviter and some of their friends. - Freenet asks the user "Do you know these Freenet users?" (checkboxes). - We immediately make temporary connections to all the non-port-forwarded nodes, if necessary using connected nodes to exchange IP addresses with unconnected nodes. - If the user accepts an invite, we do an out-of-band password verification protocol, and upgrade to a full darknet peer. Note that this can be postponed, so should not rely on the primary invite; so we need some support for FOAF connections. - The out-of-band verification is not necessary with the node the exe was downloaded from. Trust issues with the executable: - HTTPS ensures that the executable hasn't been tampered with. However, the friend providing it may be malicious, computer illiterate, or running a corrupted build they got from another friend. Trusting your friend is not necessarily enough here IMHO. - Therefore we want to verify the signature from FPI as well. - So we need to provide a zip file, containing the exe, AND the noderefs. Windows can then verify the signature on the exe. - We could have the server provide a detailed HOWTO. The problem with this is that users are likely to follow it. So if the server is malicious, they may follow malicious instructions. Look at e.g. the failure of electronic voting systems because people enter codes they are only supposed to use for verification. So we are still dependant on the centralised code signing PKI. (Right now we don't sign our executables). Which will be a problem if Freenet goes underground. This seems to be unavoidable in the light of the first point above. Note that much of this has been proposed previously by various people. We've also discussed QR codes: QR codes might work for the case where we are installing Freenet, if we can encode a URL by IP address in a QR code readable by a standard smartphone. We would likely need a password printed separately to the QR code for the user to type in; TLS-SRP happens before we know the URL AFAICS?? There is no point encoding multiple IP addresses into a QR code if it can only be read by Freenet! We could however provide several QR codes using different nodes. Each would need a separate printed password, and if we want to avoid a phone call, we could then have a separate password at the bottom to be used on setup. This would be rather distinctive and therefore a physical security risk - but on the other hand, a QR code to a numeric IP address and port isn't common either. If the user already has Freenet, IP+port+password is enough, and it might be best to be consistent, but it might not work in the absence of port forwarding; inserting to a KSK would be better. We could probably fit enough data into a QR code to include the KSK as well as the IP and port, so make it usable for either case. One fundamental problem with QR codes is they're primarily read by phones and tablets, which can't realistically run Freenet.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
