thr3ads.net - tinc devel - friend of a friend type darknets [Sep 2010]

If this information is useful, please help other people find it:
Share via:

Alex

2010-Sep-17 22:25 UTC

friend of a friend type darknets

Hi!
here a little patch for darknet functionality, i hope it does what its
intended for sufficiently ... but it seems to work :).

what should it do?

imagine your friend-network. A trusts B and C. B trusts D and E, D trust
F, C trusts G. All trust relationships are mutal

 A <---> C <---> G
 ^
 \
  \-----> B <---> D <---> F
          ^
          \
           \---> E

now they want to share some files, but they do not want that untrusted
users know who shares the files.

The idea: just route over friend-routes. solution: use IndirectData
connections of tinc, and connect only to trusted persons.

what was missing from tinc: anonymity. do a killall -USR2 tincd and you
can see the ips of everybody in your syslog.

what the patch adds: if FriendOfAFriend is set, then your node does not
distribute information about the IP and port of other known nodes. so A
can reach G only indirect, because C does not disclose the real IP of G
to A.
A can reach F only over B and D, and because A and B, B and D and D and
F are friends, the data can still be routed indirectly.




and here is the patch:


diff -Nur tinc-1.0.13/doc/tinc.conf.5.in tinc-1.0.13-patched/doc/tinc.conf.5.in
--- tinc-1.0.13/doc/tinc.conf.5.in  2010-04-11 19:44:12.000000000 +0200
+++ tinc-1.0.13-patched/doc/tinc.conf.5.in  2010-09-17 23:36:59.031491597 +0200
@@ -209,6 +209,13 @@
 This option selects the way indirect packets are forwarded.
 .Bl -tag -width indent
 
+.It Va FriendOfAFriend Li = off | on Po off Pc Bq experimental
+If this option is set, indirect data is implied and your node
+will lie to other nodes when its asked about the ip of its peers.
+This enables a FriendOfAFriend mode, where everybody just trusts
+his direct peers and noone else.
+.Bl -tag -width indent
+
 .It off
 Incoming packets that are not meant for the local node,
 but which should be forwarded to another node, are dropped.
diff -Nur tinc-1.0.13/src/net_setup.c tinc-1.0.13-patched/src/net_setup.c
--- tinc-1.0.13/src/net_setup.c 2010-04-11 04:34:31.000000000 +0200
+++ tinc-1.0.13-patched/src/net_setup.c 2010-09-17 23:38:05.591481035 +0200
@@ -337,6 +337,10 @@
 
    /* Check some options */
 
+   get_config_bool(lookup_config(config_tree, "FriendOfAFriend"),
&foaf);
+    if(foaf)
+        myself->options |= OPTION_INDIRECT;
+
    if(get_config_bool(lookup_config(config_tree, "IndirectData"),
&choice) && choice)
        myself->options |= OPTION_INDIRECT;
 
diff -Nur tinc-1.0.13/src/protocol.c tinc-1.0.13-patched/src/protocol.c
--- tinc-1.0.13/src/protocol.c  2010-03-13 18:53:33.000000000 +0100
+++ tinc-1.0.13-patched/src/protocol.c  2010-09-17 23:38:50.121482641 +0200
@@ -29,6 +29,7 @@
 #include "xalloc.h"
 
 bool tunnelserver = false;
+bool foaf = false;
 bool strictsubnets = false;
 
 /* Jumptable for the request handlers */
diff -Nur tinc-1.0.13/src/protocol_edge.c
tinc-1.0.13-patched/src/protocol_edge.c
--- tinc-1.0.13/src/protocol_edge.c 2010-03-13 18:53:33.000000000 +0100
+++ tinc-1.0.13-patched/src/protocol_edge.c 2010-09-18 00:05:18.471993705 +0200
@@ -39,7 +39,13 @@
    bool x;
    char *address, *port;
 
-   sockaddr2str(&e->address, &address, &port);
+    if(foaf){
+        address = xstrdup("0.0.0.0");
+        port = xstrdup("0.0.0.0");
+    }else{
+       sockaddr2str(&e->address, &address, &port);
+    }
+
 
    x = send_request(c, "%d %x %s %s %s %s %x %d", ADD_EDGE, rand(),
                     e->from->name, e->to->name, address, port,
diff -Nur tinc-1.0.13/src/protocol.h tinc-1.0.13-patched/src/protocol.h
--- tinc-1.0.13/src/protocol.h  2010-03-13 18:53:33.000000000 +0100
+++ tinc-1.0.13-patched/src/protocol.h  2010-09-17 23:28:44.671480039 +0200
@@ -53,6 +53,7 @@
 } past_request_t;
 
 extern bool tunnelserver;
+extern bool foaf;
 extern bool strictsubnets;
 
 /* Maximum size of strings in a request.

Guus Sliepen

2010-Sep-19 21:23 UTC

head link

friend of a friend type darknets

On Sat, Sep 18, 2010 at 12:25:29AM +0200, Alex wrote:
> here a little patch for darknet functionality, i hope it does what its
> intended for sufficiently ... but it seems to work :).
> 
> what should it do?
> 
> imagine your friend-network. A trusts B and C. B trusts D and E, D trust
> F, C trusts G. All trust relationships are mutal
> 
>  A <---> C <---> G
>  ^
>  \
>   \-----> B <---> D <---> F
>           ^
>           \
>            \---> E
You have drawn an acyclic graph, but tinc can work with any kind of topology,
including cycles (in fact, that makes it more robust in case some connection
fails).
> now they want to share some files, but they do not want that untrusted
> users know who shares the files.
> 
> The idea: just route over friend-routes. solution: use IndirectData
> connections of tinc, and connect only to trusted persons.
I don't really see why you want to avoid nodes from connecting to each other
directly. If you use IndirectData, it just decreases the efficiency of the
network. All the nodes can still send data to each other via the VPN.

You could combine this with the DirectOnly option, but that means
friends-of-friends cannot talk to each other at all.
> what was missing from tinc: anonymity. do a killall -USR2 tincd and you
> can see the ips of everybody in your syslog.
> 
> what the patch adds: if FriendOfAFriend is set, then your node does not
> distribute information about the IP and port of other known nodes. so A
> can reach G only indirect, because C does not disclose the real IP of G
> to A.
> A can reach F only over B and D, and because A and B, B and D and D and
> F are friends, the data can still be routed indirectly.
Personally, I do not see any point in hiding a node's public IP and port,
while
still allowing traffic to their VPN interface. I would assume that if they are
using a VPN, then their public IP is behind some firewall at least, so I do not
see a security advantage.

The patch itself looks nice. However, you only hide the public IP and port in
send_add_edge(). But you could receive those ADD_EDGE messages back (it is
possible even when you have an acyclic graph), so you need to deal with it in
add_edge_h() and del_edge_h() as well. It is less simple there. Also, when you
have a graph with cycles (for example, G connects to F as well), and not
everyone is using the FriendOfAFriend option, then you will get conflicting
ADD_EDGE messages, which will trigger a never-ending flood of correcting
DEL_EDGE and ADD_EDGE messages.

I do not really see this working for tinc 1.x. The TunnelServer option is
something related to this, but I'm also not so happy with it, although some
people are using it. These options that hide information are just very tricky
to implement correctly.

What exactly do you want to achieve? Anonymity of nodes? What attacks are you
trying to defend from?

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20100919/ee4f4e12/attachment.pgp>

Reasonably Related Threads

Search for more reasonably related threads

tinc devel - Sep 2010 - friend of a friend type darknets

friend of a friend type darknets

friend of a friend type darknets

Reasonably Related Threads