-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Markus,
Thanks for the clarification! I had thought a FreedomBuddy was a friend of Bob's, but your explanation makes more sense. So please forget my previous questions. :-) If every user has a Tor hidden service where their current contact details are stored, would it make sense to allow connections to be proxied through the hidden service when a direct connection isn't possible (eg due to firewalls or NATs)? Cheers, Michael On 26/06/12 15:28, Markus Sabadello wrote: > My understanding is that "FreedomBuddy" is my Tor hidden service > (formerly Santiago) that others can use to discover my various > services (in this case ssh-vpn). So if you know my FreedomBuddy Tor > hidden service address and I trust you, you can discover and use my > stuff (e.g. VPN). > > When Nick says that Alice and Bob know and trust one another, then > this means that they already know each other's FreedomBuddy Tor > hidden service address. > > So in Nick's flow, there are no Carols or any of Alice's or Bob's > friends or any other third parties involved. > > Right? > > The only thing I don't understand about the flow is why Bob would > have multiple FreedomBuddy services. Is the assumption that Bob has > multiple FreedomBoxes and therefore multiple FreedomBuddys, and > they would all be tried? > > Markus > > On Tue, Jun 26, 2012 at 11:07 AM, Michael Rogers > <[email protected] <mailto:[email protected]>> > wrote: > > Hi Nick, > > This sounds pretty solid. A few questions - sorry if these have > already been covered: > > * How does Alice discover who Bob's buddies are and stay > up-to-date with their IP addresses (since presumably buddies might > also have dynamic addresses)? > > * Is there any form of revocation if Bob stops trusting a buddy? > > * When Alice connects to a buddy, how does she tell the buddy > whose ssh-vpn service she's looking for? > > * What happens if she asks the buddy for Carol's ssh-vpn service > instead of Bob's? > > * When Alice receives an ssh-vpn service location from Bob's > buddy, how does the buddy (or Alice) know the IP address provided > by the buddy is up to date? > > Cheers, Michael > > On 26/06/12 02:44, Nick M. Daly wrote: >> Hi FreedomBoxers, > >> I'd appreciate your review and comments on the following, so I >> can improve it and take any holes out before the hackfest rolls >> around. > >> I believe this pretty effectively solves the magic routing >> problem, at least between friends. This system should allow >> friends to organize VPNs over dynamic IPs, without relying on the >> existing DNS system. There's some hand-waving here, because a lot >> of the underlying system is documented elsewhere [0]. Let me >> know if things are unclear or insufficiently described. > >> Alice and Bob mutually know and trust one another. Bob has >> previously agreed to host a SSH VPN service for Alice. Alice >> now wants to connect to Bob's VPN host. > >> Alice, as the client, will run: > >> $ freedombuddy-ssh-client (Bob's Key Id) > >> This will: > >> 1. Attmept to connect to all of Bob's ssh servers that Alice has >> locally cached and trusts. > >> 2. If none of those connect, Alice will iterate through each of >> Bob's known FreedomBuddies, doing the following, and stopping >> when a connection is successfully made: > >> A. Connect to the FreedomBuddy, querying for the "ssh-vpn" >> service. > >> B. Bob replies to Alice's requesting FreedomBuddy with zero or >> more "ssh-vpn" service locations. > >> C. Alice attempts to connect to each of the locations she's >> learned. > >> Note: Alice doesn't need to carry out step 2 sequentially. She >> could complete step 2 in a single burst, querying all of Bob's >> FreedomBuddies at once, or sequentially, in any defined (or >> random) order. The current structure doesn't support that, >> though, we'd need to include a random request ID with each >> request (with a request-specific timeout) to support that. Not >> difficult, just needs to be documented as a different protocol >> version, because it's an incompatible protocol change. > >> I don't believe there are any holes in that system, but I'd >> appreciate your review. > >> In summary: > >> 1. If Alice has a list of still valid locations that start >> hosting for her (through necessary heartbeat testing), we're >> done, she's just connected to a working location. > >> 2. If none of Alice's known locations reply, she'll query Bob's >> FreedomBuddy service for new ssh locations, and then connect to >> those. > >> Thanks for your time, Nick > >> 0: >> https://github.com/NickDaly/Plinth/tree/santiago/ugly_hacks/santiago > >> > > > >> _______________________________________________ >> Freedombox-discuss mailing list >> [email protected] > <mailto:[email protected]> > > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss > > > > _______________________________________________ Freedombox-discuss > mailing list [email protected] > <mailto:[email protected]> > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss > > > > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJP6c2fAAoJEBEET9GfxSfMtSIH/2cGdaXj/mddAhTxeybuJ1gr +XsyfXWWyQp15k+Mv8P4DNIMUfmWY50D13J2A6Otg5vfKFhCkb1RWQIG9ZoiUBe7 U1N6D0u3Y0al4E5jnnJb4esf4c7JV2RGC235I0bZnPZBW6JPn0h+OdXMl244bZff OZFdU4a72z/UGuCAsMg6lO9QbqDAoTFbGo/xvYjdqe+uSPKPcxxBiO60ZN5qqJUO epau97H4RVWonwV6Xssv3Jy04lW4bQ7vSRp/11CJ45Y8Wq1dKgFK/ntwYfGr5lck rX1gnlNDvbWizP1i6btXUd0s/eQ0wUutifUGSUBH4G0oR08/Ql3rPcwnCvDIpNo= =Wje7 -----END PGP SIGNATURE----- _______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
