[Freedombox-discuss] Request for Comment: FreedomBuddy-VPN Setup
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>wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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
> >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
> >
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iQEcBAEBAgAGBQJP6XvMAAoJEBEET9GfxSfM2xIIAKkejKp76OTI4P+lGVB5nZGJ
> yDl9ovgnxLmya9+F0pK69WhLT7yK1FMMYUYUvbXKOV1kmPWT6PtFaSd5hO/1urAF
> ESX0GVzUqOmYhmwuL6uV+Vq1GYmU1FQ2/8GCmI0nj4hgynX6Ryx3FWe62HbTeask
> 7TV/quK0riqkOH4Sz8zBG2t9RwVi7ptXpW42CQhM5bxFkoH5+i3G84Z8T1Y3mHqt
> i+mMlZ1558stvSdDn6A7ZLrqEm/jeUkTFyR2wNGhBtWhRWcH6/aXpHapUNZbHS2n
> KF/qdGT87pNjXkJ3xsqzlRUAFN7mYgSdTrIPeHaLHaIPZeP2B7VlNLwOcsf0XZw=
> =vjVu
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Freedombox-discuss mailing list
> Freedombox-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20120626/c32c9ec1/attachment.html>
Reply to: