These are my thoughts on the matter, especially point 1: - The spreading of false info is leads to quite some inefficiency for the network in general. - Even if you spread X false adresses for you, "they" can always issue X+1 search orders/legal procedures and catch you. - If you are worried about not getting recognized as a GNUnet user, I think the best way to do this is to run in F2F mode and have your friends not spread your HELLO at all. If anybody wants anything from you, he can connect you on mesh level (tunnel through your friends). If you trust your friends enought to allow them connect to you, you should trust them not to spread your hello, right? Otherwise, acquire new friends, repeat ;)
Bart Polot On 24 November 2012 13:56, LRN <lrn1...@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > This is the idea that i've been thinking on. > It should be possible for GNUnet node operator to hide the fact that > his machine runs a GNUnet node. > > Ways to achieve this: > > 1) Fake HELLO messages. > AFAIU, right now anyone can collect HELLO messages (by running a node, > or by querying a hostlist server), and then claim (with certain degree > of sureness) that GNUnet nodes run on all addresses listed in these > messages. Companies that track torrent users do this for BitTorrent. > They may then proceed to actually connect to listed addresses to > verify them, but that is quite another story. > The solution is to spread fake HELLOs with fake public keys and fake > addresses. > A node should use its private key (key K) as a seed to generate a set > fake of addresses (set A). Then use K and A themselves to generate > fake public key (key F) for each A, thus getting a complete HELLO > message. The use of K as a seed ensures that the node will keep lying > about the same set of addresses (how large that set should be is an > open question) with the same keys, making the fakes more believable > (observer might think that these are real nodes, maintaining their > real HELLOs over time; failure to validate any of them might be blamed > on firewalls, etc). > Address sets will intersect (A1 and A2 generated from K1 and K2 may > share some elements), obviously, although that might not be true for > IPv6 addresses... > I expect that address generator will apply some rules to generate > believable addresses (i.e. don't generate invalid IP addresses, like > 10.1.0.255). > As an extra, a node could validate generated addresses and do > non-agressive portscanning (or something similar - we're not speaking > only of tcp) on them, to be able to add ports (or other parts of the > address) that look believable to observers. > > AFAIU, right now nodes won't gossip about fake HELLOs (i.e. a node > will never tell another node about a HELLO it got, unless it validated > that HELLO). That might need to be changed to allow nodes to choose a > random subset of invalid HELLOs and gossip about them as well. > Otherwise only the node that generated them will be able to spread them. > Not sure about hostlists. > > Extra yummy feature - add user-configurable fake templates, which > could have addresses only, or addresses and private keys. GNUnet node > will use templates from time to time (configurable) instead of > generated addresses, and will generate missing template elements. > It would be neat to be able to tell the world that 65.55.58.201 [1] > runs a GNUnet http_server transport on port 80... > > 2) Transport disguise. > Modify the protocol to allow clients to ignore initial data sent by > the server, and require clients to be the first ones to speak GNUnet > protocol after connecting (i'm not sure how the protocol works right > now; what a GNUnet node sends to the connected party immediately after > accepting an incoming connection? Does it send anything at all?). > A node should send fake data that looks like, say, FTP greeting, > faking a real-life FTP server. > This will prevent casual observers from identifying the node as GNUnet > node. > Non-casual observer should not follow the fake protocol, but proceed > to send a normal GNUnet handshake. > If the node doesn't get a GNUnet handshake as a reply to its fake > greeting, it might either drop the connection, or use some kind of > bogus access control error as an excuse to drop it (i.e. ask for ftp > login/password combo, and then reject all such combos and drop > "clients" that failed to "authenticate" this way). > > Or a node should simply remain silent until it gets incoming handshake > message. > > 3) Handshake-first protocol > Besides (2), which may or may not be implemented, don't identify > yourself as GNUnet node until incoming peer sends a handshake, then > drop it, if it doesn't match one of your friends, if you're running in > F2F-only mode. You will be able to hide the fact that you're a GNUnet > node, since only friends will get _anything_ out of you. Other > non-friend (normal or malicious) GNUnet clients will have their > connections dropped after their handshake message. > > To make it work both ways, GNUnet should establish a generic session > with TLS encryption first. Again, it's not uncommon for services to > have ports on which clients are expected to connect with an SSL/TLS > session (instead of connecting normally and then issuing StartTLS). > The point here is to use common TLS certificates and TLS connections > for initial authentication (friend nodes will know TLS certificates of > each other in advance). Otherwise your node will not be able to > connect to any of your friends without revealing that it's a GNUnet > node (friend won't identify itself as a GNUnet node initially, until > you send a handshake, thus preventing you from verifying that you've > connected to your friend, not to some man in the middle; and if you > send a GNUnet handshake, you will reveal yourself as GNUnet node to > the other end of the connection, not knowing who might be there). TLS > allows authentication without revealing that nodes are using GNUnet. > And using TLS itself is, thankfully, not illegal yet (and, hopefully, > will never be). > > This will have to be a separate transport, since > > A) that is somewhat incompatible with existing tcp transport, which > does not rely in TLS at all, AFAIK. > B) Your friend might not be running in F2F-mode only, in which case > you will reveal that you run GNUnet by connecting to your friend on > the same port that other nodes connect to. If there's a separate port, > which only accepts TLSed sessions, and only accepts known friends on > them (at TLS level), it will be much more difficult for non-friends to > identify you. If you make a TLS connection on port A to a machine that > _also_ runs GNUnet on port B, that will not immediately prove that you > are running GNUnet in F2F-only mode. > > We already discussed (3) in the past, AFAIR, just making sure that > this discussion sticks somewhere. > > > > > [1] That's what microsoft.com resolves to, for me. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.11 (MingW32) > Comment: Using GnuPG with undefined - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJQsMQKAAoJEOs4Jb6SI2Cwl+kH/3witTSFCo+AnfKVvp5Rgc4l > gOJxfH3EXp4UkuwVSQqbsnocknzRnb/nrvqgKZ/vukcQOKWtH1N8NxU8+MOHfUsH > cNkA2KojEvrFM4TlI4o5uSOM1/f8nyBiui5pqb4bxi8MVv47WwStX2WqCiziNxml > UcQwD/0yneoj3blV2DAKA7V09pccniX35GQpluB1WZcJoSGvqhYbYeEVigtrZFmu > lKDS32fZE104HGbrhksox1/wa+wPysk/174xOvCJOzQWCAWK8N31QZRUQphSlyvv > dyjIU77G/ftOjiNhgd1uskhAbKU7mZoDa6J52+Nc3+Gik8cIwJCgrYHG3kEP9ro= > =bqkM > -----END PGP SIGNATURE----- > > _______________________________________________ > GNUnet-developers mailing list > GNUnet-developers@gnu.org > https://lists.gnu.org/mailman/listinfo/gnunet-developers >
_______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
