On 4 May 2015 at 20:53, Anne-Gwenn Kettunen <anwen at asphodelium.eu> wrote:> We started to take a look about that, and apparently, it seems that the IP > in the public key is taken into account when a client connects to a gateway. > Spoofing at that level doesn't seem easy, because the IP address seems to be > part of the authentication process.I'm having trouble understanding what you mean by "gateway", "authentication process" and "IP address" especially when you say it's part of the "public key" (it's not). Can you clarify? I am pretty sure tinc doesn't use IP addresses in any of its security mechanisms, except when StrictSubnets is enabled.> Dealing with inside threats seems however a good feature for future versionsAccording to http://tinc-vpn.org/goals/ it's planned for tinc 2.0, which AFAIK won't arrive anytime soon. I have some ideas about implementing some crude form of Subnet access controls for centralized graphs in tinc 1.1 - it would basically look like StrictSubnets, but more flexible - I have not started on that yet.> ;) > > > Le 04/05/2015 21:50, Etienne Dechamps a ?crit : >> >> Whatever you do, keep in mind that tinc will always trust all nodes as >> long as they are part of the graph. It is not currently designed to >> deal with insider threats. Most importantly, that means anyone can >> impersonate any Subnet on a tinc network, just by changing the Subnet >> declaration in their node file. >> >> The only way around that is to use StrictSubnets, but that requires >> every node to be statically configured with the subnet of every other >> node.
On 05/04/2015 10:01 PM, Etienne Dechamps wrote:> On 4 May 2015 at 20:53, Anne-Gwenn Kettunen <anwen at asphodelium.eu> wrote: >> We started to take a look about that, and apparently, it seems that the IP >> in the public key is taken into account when a client connects to a gateway. >> Spoofing at that level doesn't seem easy, because the IP address seems to be >> part of the authentication process. > > I'm having trouble understanding what you mean by "gateway", > "authentication process" and "IP address" especially when you say it's > part of the "public key" (it's not). > > Can you clarify? I am pretty sure tinc doesn't use IP addresses in any > of its security mechanisms, except when StrictSubnets is enabled. >I tested with two node "miou" and "apeliote" they have a connectTo. and public key from "Neptune". "Neptune" node have their public key also. (and all node can play together) /etc/tinc/tinclan/host/miou contain a subnet with IP and public key from "miou" /etc/tinc/tinclan/host/apeliote contain a subnet with IP and public key from "apeliote" If IP from miou is changed with IP from apeliote, "miou" can not connect to "Neptune" even miou have apeliote's IP. ok, this is not the best spoofing tentative :p -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20150504/bc716346/attachment.sig>
> I'm having trouble understanding what you mean by "gateway", > "authentication process" and "IP address" especially when you say it's > part of the "public key" (it's not).gateway : The computer to whom a node connect to have access to the subnet (usually the ConnectTo line in tinc.conf IP address : the private and non-routable-over-the-internet IP address the node uses for itself in the VPN. In my VPN, most (if not all) of the keys have this kind of header #Name = Foobarlol Address = public_ip Subnet = tinc_ip/32 Port = 1042 And err404 was the one who led the tests ;)
I'm still confused, but in any case, there's nothing stopping "miou" from impersonating "apeliote"'s subnets in your case, unless you use StrictSubnets. Here's the easiest way to do the spoofing: In miou's own node file (on the miou machine itself), add apeliote's subnets with a Weight smaller than 10 (which is the default), so that it overrides them. For example, if apeliote has a single 1.2.3.0/24 subnet, then add the following to miou's own node file (on the miou machine, not on Neptune): Subnet = 1.2.3.0/24#1 Alternatively, you can do this without messing with the weights simply by declaring two more specific subnets: Subnet = 1.2.3.0/25 Subnet = 1.2.3.128/25 If you do this, then Neptune will happily accept the spoofed subnets, and apeliote will become unreachable while miou intercepts all communications. This is the primary reason why it's a very bad idea to let untrusted nodes join a tinc network. The only way to defend against this type of attack is to use StrictSubnets. On 4 May 2015 at 21:13, err404 <err404 at free.fr> wrote:> On 05/04/2015 10:01 PM, Etienne Dechamps wrote: >> On 4 May 2015 at 20:53, Anne-Gwenn Kettunen <anwen at asphodelium.eu> wrote: >>> We started to take a look about that, and apparently, it seems that the IP >>> in the public key is taken into account when a client connects to a gateway. >>> Spoofing at that level doesn't seem easy, because the IP address seems to be >>> part of the authentication process. >> >> I'm having trouble understanding what you mean by "gateway", >> "authentication process" and "IP address" especially when you say it's >> part of the "public key" (it's not). >> >> Can you clarify? I am pretty sure tinc doesn't use IP addresses in any >> of its security mechanisms, except when StrictSubnets is enabled. >> > > I tested with two node "miou" and "apeliote" > they have a connectTo. and public key from "Neptune". > > "Neptune" node have their public key also. (and all node can play together) > > /etc/tinc/tinclan/host/miou contain a subnet with IP and public key from "miou" > /etc/tinc/tinclan/host/apeliote contain a subnet with IP and public key from "apeliote" > > If IP from miou is changed with IP from apeliote, "miou" can not connect to "Neptune" > even miou have apeliote's IP. > > ok, this is not the best spoofing tentative :p > > > _______________________________________________ > tinc mailing list > tinc at tinc-vpn.org > http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc >