Alex wrote: > 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?
Yes, it can be indicated in PONGs. A TLS handshake is also attempted on unexpected connection resets. > We could default to TLS and only fall back if that fails (maybe gated > by config switch?). Yes, that could be done. > I assume from a health point of few the entire > query network should be encrypted within the next year or so? No, not the entire network. People will be using deprecated software for years, decades, centuries and millennia as they always do. I don't think you would lose a noteworthy amount of peers if you restricted connections to those capable of encryption. > > 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? Maybe. > > 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? Not necessarily. Normally connections are persistent. It simply applies to every connect after a previous successful connection attempt. Download requests are certainly the most-likely case. > > 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. Then read upon it. > I thought magnet links where a pure content > identifier rather than what hosts had it? A magnet provides information about a file including optionally one or more URLs. -- 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-gnutella-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
