[Freedombox-discuss] Santiago Updates

[James Vasile]

On Sun, 04 Mar 2012 20:06:26 -0600, "Nick M. Daly" <nick.m.daly at gmail.com> wrote:
> 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.

OK, I see what you mean.  You're right.

[snip]

> 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.

Agreed.

> 
> 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.

Ok, shoot me a line when you're ready to dive in.

> 
> > > - 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.

Will do.

> 
> 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: 489 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20120304/96ded0d9/attachment.pgp>