One host for forwarding only without keys

Sat Sep 3 20:06:40 CEST 2016

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> 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>> 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>>> 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>>
> >     >     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
> Fax: +49 6138 99998-109
> VoIP: sip:info at melware.net
> mailto:info at melware.de
> http://www.melware.de
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tinc-vpn.org/pipermail/tinc/attachments/20160903/ed46565b/attachment.html>