[Freedombox-discuss] Request for Comment: FreedomBuddy-VPN Setup
-----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-----
Reply to: