<div dir="ltr"><div><div>If you're using StrictSubnets, you will still be fine. StrictSubnets means that A will only use B's key (which C does not know) to send packets to B's statically configured subnets. C cannot impersonate B (as in, take its node name) because it would have to know B's private key to do so, and it cannot impersonate B's subnets because A is using StrictSubnets. The worst that C can do is to stop relaying (i.e. denial of service), but that's somewhat obvious.<br><br></div><div>(There is a caveat though: A will refuse to *send* packets using C's key, but it will *accept* any packet that uses any known key - including C's key - no matter which subnet it's coming from. This is a known limitation which I think can easily be fixed through some simple code changes. Arguably that's not a big deal anyway, because there's not much an attacker can do if they are unable to control both sides of the conversation.)<br></div><div><br></div>Note that all this assumes you're using StrictSubnets (both on A and B). If you're not using StrictSubnets, C would be able to intercept B's ADD_SUBNET messages and reroute subnets to itself instead, resulting in a an extremely simple and devastating man-in-the-middle attack. Currently the only way to prevent that is to use StrictSubnets, but I believe Guus has plans to introduce more sophisticated mechanisms in the future.<br></div><div><div><br></div><div>In any case, I should probably mention that, to the best of my knowledge (Guus might be able to confirm), right now tinc is mostly designed to protect from attacks coming from *outside* the VPN (as in, outside the web of metaconnections). Protecting against insider attacks (from inside the metagraph) doesn't get anywhere near as much attention. This means it is more likely that there are vulnerabilities lurking in the code that we're not aware of. Compared to an outside attacker, an inside attacker has a much larger attack surface to exploit because they can send arbitrary messages through a fully authenticated metaconnection, which tinc might or might not be prepared for. If you really, deeply care about the integrity of the link between A and B and you want to protect against a full compromise of C by a determined hostile party, I would not recommend such a setup.<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 September 2016 at 16:14, Armin Schindler <span dir="ltr"><<a href="mailto:armin@melware.de" target="_blank">armin@melware.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 09/03/2016 10:56 AM, Etienne Dechamps wrote:<br>
> C will still need keys in order to establish metaconnections with A and B (as<br>
> well as a few other things). However there is no need for C to own any<br>
> "Subnets" at all.<br>
<br>
</span>If somebody breaks into C, he could get access to the vpn network, right?<br>
Because the keys are there, it will be possible to use them to get access.<br>
Even if A-B connections via C are not decrypted, connection A-C and B-C are<br>
still possible, right?<br>
<br>
Armin<br>
<span class=""><br>
<br>
> On 3 September 2016 at 06:21, Armin <<a href="mailto:armin@melware.de">armin@melware.de</a><br>
</span><span class="">> <mailto:<a href="mailto:armin@melware.de">armin@melware.de</a>>> wrote:<br>
><br>
> On 09/02/2016 08:51 PM, Etienne Dechamps wrote:<br>
> > What version of tinc are you using? tinc 1.1 already does what you want out of<br>
> > the box: packets sent from node A to node B through node C will use a key that<br>
> > A and B will negotiate between themselves. C doesn't have the key, and will<br>
> > act as a blind relay. C will not be able to decipher the packets flowing<br>
> > between A and B.<br>
> ><br>
> > This is different from tinc 1.0, where C would have to decipher the packet in<br>
> > order to determine what its final destination is. In tinc 1.1 that routing<br>
> > information is sent in cleartext so that C can forward the packet without<br>
> > having to decipher it.<br>
><br>
> I am using tinc 1.0.<br>
> Switching to 1.1 makes sense then.<br>
> Can C then be completely without keys, forwarder only with not access to the<br>
> network at all?<br>
><br>
> Armin<br>
><br>
> > On 2 September 2016 at 09:40, Armin <<a href="mailto:armin@melware.de">armin@melware.de</a> <mailto:<a href="mailto:armin@melware.de">armin@melware.de</a>><br>
</span><span class="">> > <mailto:<a href="mailto:armin@melware.de">armin@melware.de</a> <mailto:<a href="mailto:armin@melware.de">armin@melware.de</a>>>> wrote:<br>
> ><br>
> > Hello all,<br>
> ><br>
> > as written in my other posts, I have a setup of about seven<br>
> > hosts. Two of them (A and B) use StrictSubnets and an own routing via<br>
> > a special host (C), because C has better connection to the A and B than a<br>
> > direct A-B connection.<br>
> ><br>
> > Host C is in a place where I need to create special security settings.<br>
> > The VPN encrypted data shall not be available on host C.<br>
> > There is no need for host C be in routing of tinc vpn, it just shall<br>
> > forward the encrypted packets to another host when needed.<br>
> ><br>
> > Is it possible to setup a host as part of a tinc network without the<br>
> > access to the packets (decrypted)?<br>
> > Or do I need to setup some other kind of tunnel for this?<br>
> ><br>
> > Armin<br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > tinc mailing list<br>
> > <a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a> <mailto:<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a>><br>
</span>> <mailto:<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a> <mailto:<a href="mailto:tinc@tinc-vpn.org">tinc@tinc-vpn.org</a>>><br>
> > <a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">https://www.tinc-vpn.org/cgi-<wbr>bin/mailman/listinfo/tinc</a><br>
> <<a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">https://www.tinc-vpn.org/cgi-<wbr>bin/mailman/listinfo/tinc</a>><br>
> > <<a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">https://www.tinc-vpn.org/cgi-<wbr>bin/mailman/listinfo/tinc</a><br>
> <<a href="https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc" rel="noreferrer" target="_blank">https://www.tinc-vpn.org/cgi-<wbr>bin/mailman/listinfo/tinc</a>>><br>
><br>
><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Cytronics & Melware<br>
Weinbergstrasse 39, 55296 Loerzweiler / Germany<br>
Tel: <a href="tel:%2B49%206138%2099998-100" value="+49613899998100">+49 6138 99998-100</a><br>
Fax: <a href="tel:%2B49%206138%2099998-109" value="+49613899998109">+49 6138 99998-109</a><br>
VoIP: <a href="mailto:sip%3Ainfo@melware.net">sip:info@melware.net</a><br>
mailto:<a href="mailto:info@melware.de">info@melware.de</a><br>
<a href="http://www.melware.de" rel="noreferrer" target="_blank">http://www.melware.de</a><br>
</font></span></blockquote></div><br></div>