Re: [gtk-gnutella-devel] Encryption and what is/isn't

[Alex <al...@be...>]

On Tue, Jul 01, 2008 at 02:25:27AM +0200, Christian Biere wrote:
> Alex wrote:
> > The world is getting more deep packet inspection happy. The obvious
> > next step is more routine use of encryption. I notice GTKG links
> > against TLS already. Will it use encryption for all connections?
> 
> You can tell which connections are encrypted by looking for an 'E' flag
> or a mention of 'TLS'.
> 
> > 1. Is the Gnutella Network P2P encrypted yet? If not do any
> >    proposals/other clients propose ways to do so? I assume you would
> >    have to know another node would accept encryption rather than try
> >    and connect and then fall back?
> 
> gtk-gnutella and LimeWire support TLS over TCP. UDP is never encrypted.
> gtk-gnutella never falls back. I've read LimeWire tries TLS first and
> falls back but this might not be the case in current versions.

How does gtkg know to try TLS. Do the pongs hold information about if
the node accepts encrypted connections?

We could default to TLS and only fall back if that fails (maybe gated
by config switch?). I assume from a health point of few the entire
query network should be encrypted within the next year or so?

>  The fall
> back option is not very sensible, but a fall forward toward TLS might be
> useful.

Ok, although at that point won't DPI of already figured out whats
going on?

> Once it's been determined that peer does indeed support TLS,
> falling back to a plain connection is simply absurd.

Indeed.

> > 2. Are the file fetches done with encryption? If not I guess this
> >    would be the easiest place to start as the there would already be
> >    information you could embed in the hit packet to say the servant
> >    accepts SSL sessions?
> 
> Yes, such hint is exchanged albeit this is rather for transition than an
> absolute requirement. At this point it should be supported by the vast
> majority of all peers, so an optimistic use of encryption might be
> sensible.

Ok

> 
> > Basically a summary of the state of encryption in the Gnutella network
> > and if there are any proposals/specs that could be implemented for
> > GTKG is what I'm curious about.
> 
> I'm not aware of any proposals with respect to encryption but there is
> certainly room for improvements with the current implementation. I don't
> think gtk-gnutella makes use of session resuming (unless GNUTLS does it
> transparently) which would reduce some overhead at the price of a bit
> memory.

I assume this is a cost when the servant gets the next chunk of a
multipart file?

> Also the "https:" URL scheme isn't supported as of yet which
> also means that magnet-links do not indicate support for encryption.

I don't understand. I thought magnet links where a pure content
identifier rather than what hosts had it?

> 
> -- 
> Christian
> 
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> gtk-gnutella-devel mailing list
> gtk...@li...
> https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel

-- 
Alex, homepage: http://www.bennee.com/~alex/
	Idaho state law makes it illegal for a man to give his sweetheart
a box of candy weighing less than fifty pounds.