[Freedombox-discuss] Santiago Updates
On Sun, 04 Mar 2012 19:56:43 -0500, James Vasile <vasile at freedomboxfoundation.org> wrote:
> > - Consider changing message contents. Do we include meta-information in
> > the replies to reduce the number of sent messages overall? Is sending
> > data that can identify a single Santiago port to the recipient a
> > greater risk than sending out many more messages per request, while
> > keeping the responder hidden?
>
> Data that can ID the owner of a santiago port should be withheld until
> the client hitting the port has authenticated and is allowed to know the
> ID. We need an ACL system for that.
When B is replying to a Santiago request, A has no idea that B is doing
so. So, A might send a request message to several of B's Santiagi,
before it gets a response. In turn, B might end up sending multiple
response messages back to A if A's original Santiagi aren't accessible.
A then needs to send B back and acknowledgment message to B to tell it
to stop sending accept messages.
Assuming that both A and B have 3 Santiagi, and only the third of each
is accessible (a fairly common worst-case scenario, I imagine), we're
talking sending up to 6 or 9 messages to negotiate one service between
two nodes.
The first request (the query), A finds B's third Santiago:
A -> B1, A -> B2, A -> B3
The first response, B finds A's third Santiago:
B -> A1, B -> A2, B -> A3
The first acknowledgment, A answers B's Santiago, but has no clue which
Santiago actually received the first message, so tries all three of them
again:
A -> B1, A -> B2, A -> B3
If we let A and B both define "reply to" headers (which we have for A's
first query to B, but not for B's response back to A), then we can get
steps 2 and 3 down to one message each, or 3 - 5 total (again, 9 in the
worst case). The disadvantage here is that A and B know which Santiagi
are both active and available on the other's node.
A queries B:
A -> B1, A -> B2, A -> B3
B tries A's reply to, first:
B -> A3
If that doesn't work, B moves on:
B -> A2
A acknowledges B, so B doesn't need to reply to any more Santiagi. A
already knows which Santiago received the initial query, so A sends it
there:
A -> B3
I'm going to go ahead and say that allowing each message to contain a
"reply to" header seems like a win, because it prioritizes known
connections. It doesn't *seem* like an attacker (A) gets a lot from
knowing that B's third Santiago was the reachable one. That'll take
some additional thought though.
A lot of it depends on where your Santiagi are reachable. Advertising a
Santiago on a bare IP address is probably ill advised, but nonetheless
not very useful to an outside attacker: only your friends will know what
services you're willing to tell them about. There's no guarantee that
the services you're advertising are running on your box anyway.
> > - Store and load the data from FileDict objects correctly. James, I'll
> > have to ask you about that, I'm getting weird threading errors that
> > are probably due to building this outside of the main Plinth system.
>
> Let's confer on those. Are you using my withsqlite package for the file
> dict?
Probably not. I'll look at it more later this week. I tried to
duplicate what you did with the users, but didn't mock it up very well,
it seems.
> > - Build a non-HTTP protocol.
>
> This interests me. What do you have in mind here?
Something that isn't HTTP? I just want to get rid of the blank 200s.
That's a reply along the onion connection that it might be possible
(desirable?) to get rid of. Granted, I don't think that matters much,
so it might not be worth it for that reason alone. However, having
multiple protocols could be useful if we want to use Santiago over SSH
or something.
> > I would prefer end-users stay away from it until the message queuing
> > is worked out, but the worst that *should* happens is that the
> > Santiago process (and the plug it's running on) are (D)DOSed, which
> > will be inconvenient, but not harmful. Until the PGP encryption and
> > signature verification are in, this may be very harmful.
>
> In thinking about FreedomBox, some of us have quietly assumed that if we
> have to draw a line in the sand on vulnerability, DDoS is a good line.
> At any point, if the worst that can happen is DDoS, that might be
> acceptable.
Yeah, flip through the readme. You'll be interested in the "Attacks" ->
"Methods" -> "Flood" section.
Let me know what you think when you get time,
Nick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20120304/61231d2c/attachment-0001.pgp>
Reply to: