gtk-gnutella-devel Digest, Vol 23, Issue 1
|
View:
New views
1 Messages
—
Rating Filter:
Alert me
|
 |
gtk-gnutella-devel Digest, Vol 23, Issue 1
by gtk-gnutella-devel-request
::
Rate this Message:
Send gtk-gnutella-devel mailing list submissions to
gtk-gnutella-devel@... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel or, via email, send a message with subject or body 'help' to gtk-gnutella-devel-request@... You can reach the person managing the list at gtk-gnutella-devel-owner@... When replying, please edit your Subject line so it is more specific than "Re: Contents of gtk-gnutella-devel digest..." Today's Topics: 1. Re: Encryption and what is/isn't (xiando) 2. Re: Encryption and what is/isn't (Alex) 3. Re: Encryption and what is/isn't (Christian Biere) 4. Re: Encryption and what is/isn't (Alex) 5. Re: Encryption and what is/isn't (Christian Biere) 6. GUID reliably has IPv4 at [0-4] still? (Matthew Lye) ---------------------------------------------------------------------- Message: 1 Date: Tue, 1 Jul 2008 02:29:24 +0200 From: xiando <xiando@...> Subject: Re: [gtk-gnutella-devel] Encryption and what is/isn't To: gtk-gnutella-devel@... Message-ID: <200807010229.28581.xiando@...> Content-Type: text/plain; charset="iso-8859-1" > 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? A relevant article: "'Yes' to surveillance law", http://www.thelocal.se/12534/20080618/ "Swedish lawmakers voted late on Wednesday in favour of a controversial bill allowing all emails and phone calls to be monitored in the name of national security." The Swedish regime are about to monitor all contact you and your loved ones have with people within the regime. This means that if your gtk-gnutella software connects to someone within that regime then the regimes FRA agency will record and study your TCP/UDP packets. > 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? No. It is completely insecure. > 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? No. Swedens FRA, Norways NSM and England's GCHQ all get to see your file fetches. This is potentially very bad since torture for sharing information about false flag terrorism such as the US Department of Defence false-flag "terror" operation n NYC on September 11th, 2001 is quite common within the NATO alliance. > 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. It is not encrypted, and it should be. -------------- next part -------------- An HTML attachment was scrubbed... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part. ------------------------------ Message: 2 Date: Tue, 1 Jul 2008 08:28:55 +0000 From: Alex <alex@...> Subject: Re: [gtk-gnutella-devel] Encryption and what is/isn't To: gtk-gnutella-devel@... Message-ID: <20080701082854.GH12661@...> Content-Type: text/plain; charset=us-ascii 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-gnutella-devel@... > 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. ------------------------------ Message: 3 Date: Tue, 1 Jul 2008 11:36:38 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Encryption and what is/isn't To: gtk-gnutella-devel@... Message-ID: <20080701093638.GA700@cyclonus> Content-Type: text/plain; charset=utf-8 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 ------------------------------ Message: 4 Date: Tue, 1 Jul 2008 12:24:46 +0000 From: Alex <alex@...> Subject: Re: [gtk-gnutella-devel] Encryption and what is/isn't To: gtk-gnutella-devel@... Message-ID: <20080701122446.GI12661@...> Content-Type: text/plain; charset=us-ascii On Tue, Jul 01, 2008 at 11:36:38AM +0200, Christian Biere wrote: > Alex wrote: > > On Tue, Jul 01, 2008 at 02:25:27AM +0200, Christian Biere wrote: > > > Alex wrote: > > We could default to TLS and only fall back if that fails (maybe gated > > by config switch?). > > Yes, that could be done. Cool. I shall have to break out the src tree and have a poke about. > > 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. True but I would of thought this is a case of moving things on by policy (much like GTKG does with old CVS builds). > > > 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. OK, that would require some reading about the guts of GNU TLS. > > > 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. Ahh, the wikipedia article let me down in summary. Are we talking about the "mt" tag here? The spec I can see is quite old (v0.1 2002) and doesn't give many examples. -- Alex, homepage: http://www.bennee.com/~alex/ "I keep seeing spots in front of my eyes." "Did you ever see a doctor?" "No, just spots." ------------------------------ Message: 5 Date: Tue, 1 Jul 2008 18:47:28 +0200 From: Christian Biere <christianbiere@...> Subject: Re: [gtk-gnutella-devel] Encryption and what is/isn't To: gtk-gnutella-devel@... Message-ID: <20080701164728.GC865@cyclonus> Content-Type: text/plain; charset=utf-8 Alex wrote: > > A magnet provides information about a file including optionally one > > or more URLs. > Ahh, the wikipedia article let me down in summary. Are we talking > about the "mt" tag here? The spec I can see is quite old (v0.1 2002) > and doesn't give many examples. No, the "mt" key isn't supported at all. Apparently the "as" and "xs" keys are not officially documented but they are certainly supported by those which can handle magnets at all. -- Christian ------------------------------ Message: 6 Date: Tue, 1 Jul 2008 12:54:29 -0400 From: Matthew Lye <mlye@...> Subject: [gtk-gnutella-devel] GUID reliably has IPv4 at [0-4] still? To: gtk-gnutella-devel@... Message-ID: <602B5914-120C-4F0E-A46D-6BCF4DC523D8@...> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes I've been 'implementing' browsing of proxied hosts via command line/ search field[1]. The menu interface uses data from the original selected item to name the search entry after that address. It seems impossible to derive the local address from the GUID of the host. (a) Is guid_oob_get_addr_port(...)[2,3] broken, (b) am I making a semantic error with *guid (assuming that it is a raw 16-byte guid), or (c) does no-one ever encode the network bytes anymore? In other instances, they seem to still be being relied upon for some filtering of fake or impossible GUIDs from hosts. [1] via search_common.c:3100, search_gui_new_browse_host(...). [2] explicitly, guid.c:434, guid_oob_get_addr_port(...) [3] called by: oob_got_results(...)@oob.c: 656, build_search_msg(...)@search.c:2346 g, and search_request_preprocess(...)@search.c:5150 ------------------------------ ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 ------------------------------ _______________________________________________ gtk-gnutella-devel mailing list gtk-gnutella-devel@... https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel End of gtk-gnutella-devel Digest, Vol 23, Issue 1 ************************************************* |
| Free embeddable forum powered by Nabble | Forum Help |
