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