Re: [briar-devel] How does Briar know where to send a message to reach a given user?

[James M. <ja...@jm...>]

Hi Julius,

Thanks for chiming in.  :)  Yes, I especially want to know about any
security concerns.

Responses inline:

[Sent from my phone.]

On Mon, Jul 22, 2019, 1:14 PM Julius ter Pelkwijk <pel...@gm...>
wrote:

> Hey James,
>
> Had to chime in here: Anything that loads any executable code can be
> considered "malicious", and should therefore not execute at all.
> That's how they found out about certain TOR users, by forcing their
> javascript to execute a PING request outside the tor network, which in
> return caused them to expose themselves
> (http://hal.inria.fr/docs/00/47/15/56/PDF/TorBT.pdf). Therefore,
> either use a VPN that does not expose any traffic to outside parties
> or just accept the fact that you cannot send anything other than
> "data" to the user. If you can make your website run on a terminal,
> you are already doing a good job at preventing anyone from exploiting
> your anonymous website.
>

Are you talking about the JS in the shareable HTML templates?  Yes, that's
a concern.  The plan is to parse and validate all templates to ensure that
all JS is restricted to certain allowed strings, like "function_name()".
There would be a JS library that we write that has all those functions.
This way, no malicious JS could be run.  I'm not even sure the templates
need to allow any JS, but in case we need it we will restrict it like this.

Note that this tool will not be web-based.  For end-to-end encryption, it
has to have a client app.



> If someone holds the data, even though it's encrypted, that's a
> goldmine for OPSEC. That means that if that server gets compromised,
> they can use it to track traffic flow. That's how they tracked a lot
> of users from the dark web: They close down all parties, steer them
> into a website that is already compromised and keep the impression
> that things are still working there. Then shut down the trap and
> voila, you suddenly have 50-100 potential targets on a silver platter.
>

That's a good point.  Traffic analysis can be done at any network node,
though, including at any compromised Tor node.  Or is there something more
dangerous that I'm missing?

I don't quite understand the exploit you describe.  If they compromise a
message-passing server, I don't see how they can get anything but which
other servers the compromised server connects to.  Which is not good, but I
don't see how they get all the 50-100 potential targets.  Unless you mean
other target message-passing servers, which also only see encrypted data.
So how is that worse than a compromised Tor node?



> If you are going with "multihopping" rather than P2P, I would
> recommend using mesh networks for this task. However, this does mean
> that you are broadcasting encrypted messages to everyone in the
> network, without knowing who will get it, and basically exposing
> yourself to a lot of random strangers. Not the best idea if you want
> to be secretive, but I have seen it being used in CJDNS and it seems
> to work pretty well.
>

Well, the tool needs to be scalable to millions of users, and be reasonably
fast, which I hear mesh networks aren't.  But I may just use Briar's
network transport, and let you all deal with those problems.  :)

Thanks Julius!

James



> Greetings,
>
> Julius
>
> On Mon, Jul 22, 2019 at 9:41 PM James Marshall <ja...@jm...>
> wrote:
> >
> > Thanks Greg, this is very helpful!
> >
> > Correction-- when I said "onion server", I meant a hidden service.
> >
> > Responses inline:
> >
> > [Sent from my phone.]
> >
> > On Mon, Jul 22, 2019, 4:02 AM Greg Troxel <gd...@le...> wrote:
> >>
> >> James Marshall <ja...@jm...> writes:
> >>
> >>
> >> Two thought from that:
> >>
> >>   Briar is essentially what you want, perhaps missing some features.
> >>   Consider extending Briar instead.
> >
> >
> > I've thought about that, and still may.  Another possibility is to use
> Briar's transport to send data as messages, which my tool could then format
> as needed, e.g. as JSON.
> >
> > I think there are features I want that may not fit in the full Briar
> model, though.  I want to use HTML templates with CSS and potentially JS,
> so that any UX designer who knows HTML can create their own UI for the
> tool; these could be shareable.  This would a) allow clean separation of
> design from code, b) leverage creativity of the user community, and c) let
> users choose the UI they prefer.
> >
> > I and others know HTML/CSS/JS already, which is a benefit.  I've never
> written a mobile app and I don't know how complicated the layout mechanism
> is... maybe it's easy!  But most people already know HTML etc.
> >
> > I also want cross-platform development.
> >
> > For both of these reasons, I'm looking at using Meteor to develop this,
> as it seems to have all I need and its users seem happy with it.  I've
> never used it, so all thoughts and concerns are welcome!
> >
> >>
> >>   Briar is heading in the direction of federated personal servers (but
> >>   with the big point of a server for each person), so that they can be
> >>   always reachable.  Understand Briar's issues with power usage, then
> >>   design, and then post it for review.
> >
> >
> > I'm considering that too, a personal server acting as a message relay,
> but for saving power when encrypting e.g. media files for your 500
> friends.  This server would need to see the message in order to encrypt it
> for everyone, so it would need to be secured and trusted.
> >
> > The other, main kind of server for this tool would *not* see message
> content; it would only pass encrypted messages among other servers and
> users, queueing as needed.  The user wouldn't need to trust this kind of
> server, and each server could be used by many users.  (It *could* learn
> things like "this user knows someone on that server.")
> >
> > But maybe I can just run a hidden service on each device, thus requiring
> tor (I was thinking of making tor usage optional).
> >
> >
> >>
> >> > As I understand it, a Briar user's identity is basically just their
> public
> >> > key (?).  If each user isn't associated with a server, like the
> >> > use...@se... that some federated tools use, then how does
> user A
> >> > know where to send a message to get to user B?
> >>
> >> There's identity, and there's address.  Briar shares a tor hidden
> >> service address with peers and one communication method is to contact
> >> the other briar node over tor.  The others are local only, so tor is the
> >> only method for people not near you, more or less.
> >
> >
> > Interesting, so each Briar installation includes its own hidden
> service.  And then presumably re-registers with the tor network whenever
> its IP address changes.
> >
> >
> >>
> >> > Unless I'm missing something, I don't see how to do that without a
> >> > centralized lookup server, which I thought Briar is trying to avoid.
> >> > Maybe server info is stored with each contact?
> >>
> >> Yes, the hidden service.  But you don't need a centralised server, you
> >> need a worldwide service which can be distributed.  tor HS are such a
> >> distributed service.
> >
> >
> > Right, that's what I meant, a service.
> >
> >
> >>
> >> > I would love for my tool not to require a server name in user IDs; it
> would
> >> > be easier to use onion servers, for example, and easier to
> transparently
> >> > migrate to a different server.
> >>
> >> I don't follow your concern.  Briar keeps the HS name in the db and
> >> doesn't show it to the user, so it isn't hard.  If you mean "just type
> >> in the name", then you need centralized registration, or to bootstrap on
> >> centralized registration like DNS.
> >
> >
> > My concern may be unfounded-- I'm new to hidden services and need to
> consider how this tool should best use them.
> >
> >
> >>
> >> > Thanks a lot!  Links to docs, discussions, or relevant source code
> are most
> >> > welcome.
> >>
> >> A huge issue in Briar was and still is power usage.  For reasons that
> >> aren't fundamental, tor uses huge amounts of power when offering a
> >> hidden service (on a phone; regular computers call this same usage very
> >> little power!).  So enabling the HS on your phone -- which is necessary
> >> to receive messages from people who aren't on the same wifi or in BT
> >> range -- runs the battery down, unacceptably for most.  Surely
> >> acceptable to some if their actual threat model is as bad as Briar's.
> >
> >
> > Interesting, thanks for the info that hidden services on mobile drain
> power.  I was mostly concerned about all the end-to-end encryption draining
> power, so this is good to know too.
> >
> >
> >>
> >> There are two paths forward, and as I understand it both are happening:
> >>
> >>   fix tor to not need a wake lock for a HS.  then it will just be sort
> >>   of heavy usage, but probably good enough
> >>
> >>   allow personal relay boxes that speak the protocol, but can't decrypt,
> >>   that are someplace with power, with a different HS, that the user
> >>   polls when they want to get mail (or when they are plugged in, etc.)
> >>
> >>
> >> Also, see the literature on Disruption Tolerant Networking, which for a
> >> time in the 2000s was very successful at extracting funding from
> >> research sponsors :-)   But seriously, there is the notion of
> >> transferring messages over a network with occasional connectivity and
> >> node movement.   The problems are:
> >>
> >>   figuring out routing is very hard,  You can't flood, because that
> >>   doesn't scale.  You don't know who is going where.
> >>
> >>   if you want to trust no one, do you trust strangers?
> >
> >
> > My goal is to not trust strangers with anything but encrypted data.
> Specifically, users should not have to trust any servers.  Right now, the
> federated tools I know of require each user to trust not only their server,
> but the servers of all their friends too.
> >
> >>
> >> briar avoids this by not doing routing, just direct delivery, via wifi,
> >> bt, or tor HS.  It is headed to 1-hop routing, where the intermediate is
> >> specified by the peer, avoiding both of the above issues.
> >
> >
> >
> > Thanks so much for all the great info!  And for your interest.  This
> helps me a lot.
> >
> > Best,
> > James
> >
> > _______________________________________________
> > briar-devel mailing list
> > bri...@li...
> > https://lists.sourceforge.net/lists/listinfo/briar-devel
>