One host for forwarding only without keys

Armin armin at melware.de
Tue Sep 6 12:53:43 CEST 2016


Hello Etienne,

thank you for this detailed information and idea.
I guess I will setup a test environment for this.

Armin

On 03.09.2016 20:06, Etienne Dechamps wrote:
> 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.
>
> (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.)
>
> 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.
>
> 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.
>
> On 3 September 2016 at 16:14, Armin Schindler <armin at melware.de
> <mailto:armin at melware.de>> wrote:
>
>     On 09/03/2016 10:56 AM, Etienne Dechamps wrote:
>     > C will still need keys in order to establish metaconnections with A and B (as
>     > well as a few other things). However there is no need for C to own any
>     > "Subnets" at all.
>
>     If somebody breaks into C, he could get access to the vpn network,
>     right?
>     Because the keys are there, it will be possible to use them to get
>     access.
>     Even if A-B connections via C are not decrypted, connection A-C and
>     B-C are
>     still possible, right?
>
>     Armin
>
>
>     > On 3 September 2016 at 06:21, Armin <armin at melware.de <mailto:armin at melware.de>
>     > <mailto:armin at melware.de <mailto:armin at melware.de>>> wrote:
>     >
>     >     On 09/02/2016 08:51 PM, Etienne Dechamps wrote:
>     >     > What version of tinc are you using? tinc 1.1 already does what you want out of
>     >     > the box: packets sent from node A to node B through node C will use a key that
>     >     > A and B will negotiate between themselves. C doesn't have the key, and will
>     >     > act as a blind relay. C will not be able to decipher the packets flowing
>     >     > between A and B.
>     >     >
>     >     > This is different from tinc 1.0, where C would have to decipher the packet in
>     >     > order to determine what its final destination is. In tinc 1.1 that routing
>     >     > information is sent in cleartext so that C can forward the packet without
>     >     > having to decipher it.
>     >
>     >     I am using tinc 1.0.
>     >     Switching to 1.1 makes sense then.
>     >     Can C then be completely without keys, forwarder only with not access to the
>     >     network at all?
>     >
>     >     Armin
>     >
>     >     > On 2 September 2016 at 09:40, Armin <armin at melware.de <mailto:armin at melware.de> <mailto:armin at melware.de
>     <mailto:armin at melware.de>>
>     >     > <mailto:armin at melware.de <mailto:armin at melware.de> <mailto:armin at melware.de
>     <mailto:armin at melware.de>>>> wrote:
>     >     >
>     >     >     Hello all,
>     >     >
>     >     >     as written in my other posts, I have a setup of about seven
>     >     >     hosts. Two of them (A and B) use StrictSubnets and an own routing via
>     >     >     a special host (C), because C has better connection to the A and B than a
>     >     >     direct A-B connection.
>     >     >
>     >     >     Host C is in a place where I need to create special security settings.
>     >     >     The VPN encrypted data shall not be available on host C.
>     >     >     There is no need for host C be in routing of tinc vpn, it just shall
>     >     >     forward the encrypted packets to another host when needed.
>     >     >
>     >     >     Is it possible to setup a host as part of a tinc network without the
>     >     >     access to the packets (decrypted)?
>     >     >     Or do I need to setup some other kind of tunnel for this?
>     >     >
>     >     >     Armin
>     >     >
>     >     >     _______________________________________________
>     >     >     tinc mailing list
>     >     >     tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>
>     <mailto:tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>>
>     >     <mailto:tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>
>     <mailto:tinc at tinc-vpn.org <mailto:tinc at tinc-vpn.org>>>
>     >     >     https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>     <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc>
>     >     <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>     <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc>>
>     >     >     <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>     <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc>
>     >     <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>     <https://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc>>>
>     >
>     >
>
>
>     --
>     Cytronics & Melware
>     Weinbergstrasse 39, 55296 Loerzweiler / Germany
>     Tel: +49 6138 99998-100 <tel:%2B49%206138%2099998-100>
>     Fax: +49 6138 99998-109 <tel:%2B49%206138%2099998-109>
>     VoIP: sip:info at melware.net <mailto:sip%3Ainfo at melware.net>
>     mailto:info at melware.de <mailto:info at melware.de>
>     http://www.melware.de
>
>


More information about the tinc mailing list