[Freedombox-discuss] Request for Comment: FreedomBuddy-VPN Setup

Tue Jun 26 14:56:31 UTC 2012

-----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 
> <michael at briarproject.org <mailto:michael at briarproject.org>>
> 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
>> Freedombox-discuss at lists.alioth.debian.org
> <mailto:Freedombox-discuss at lists.alioth.debian.org>
> 
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>
> 
> 
> _______________________________________________ Freedombox-discuss
> mailing list Freedombox-discuss at lists.alioth.debian.org 
> <mailto:Freedombox-discuss at lists.alioth.debian.org> 
> 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-----