tinc - Jan 2013 - Conflicting Default Values. A trusts B. B trusts EvilNode. Does that mean A trusts EvilNode?

*You should repeat this for all nodes you ConnectTo, or which ConnectTo
you. However, remember that you do not need to ConnectTo all nodes in the
VPN; it is only necessary to create one or a few meta-connections, after
the connections are made tinc will learn about all the other nodes in the
VPN, and will automatically make other connections as necessary. *


The above is from the docs.  Assuming all nodes in router mode.  How does
this not mean that "A trusts B.  B trusts EvilNode.  Does that mean A
trusts EvilNode? by default?"

If A and EvilNode, have not exchanged public keys directly, they can still
establish sockets with one another over their TINC IP addresses.
I know if both node A and EvilNode ConnectTo B, then EvilNode can establish
internet connections with node A's tinc IP.
"Forwarding=OFF" or "TunnelServer=YES" or
"IndirectData=NO"  are supposed
to prevent this.

EvilNode can connect and establish a tinc IP connection to A.  I have to
assume this happens because of Forwarding=internal by default.

"config get IndirectData" and "config get Forwarding" and
"config get
TunnelServer" all return "No matching configuration variables
found."  So
we have to rely on documentation or source code to determine what the
default values are.  Default configuration parameters are in conflict but
we have no way with tincctl to know what the actual parameters are for
verification.

The default value "Forwarding=internal"  contradicts both default
values
"IndirectData=NO"  AND "TunnelServer=no", however
"Forwarding=internal"
WINS allowing EvilNode to connect to A.

Is there an option to not allow any other node to connect to your node?  It
could still ConnectTo Server1, but not allow any incoming connections.

Without somewhat centralized control, it is hard to know who is connecting
to who, which would be a good reason to have the option to put network keys
into a DNSSEC server.


http://www.tinc-vpn.org/documentation-1.1/tinc_4.html#How-to-configure
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20130123/583db4e5/attachment.html>

On Wed, Jan 23, 2013 at 09:58:50PM -0600, Rob Townley wrote:
> *You should repeat this for all nodes you ConnectTo, or which ConnectTo
> you. However, remember that you do not need to ConnectTo all nodes in the
> VPN; it is only necessary to create one or a few meta-connections, after
> the connections are made tinc will learn about all the other nodes in the
> VPN, and will automatically make other connections as necessary. *
> 
> The above is from the docs.  Assuming all nodes in router mode.  How does
> this not mean that "A trusts B.  B trusts EvilNode.  Does that mean A
> trusts EvilNode? by default?"
Yes. That's a feature.
> If A and EvilNode, have not exchanged public keys directly, they can still
> establish sockets with one another over their TINC IP addresses.
> I know if both node A and EvilNode ConnectTo B, then EvilNode can establish
> internet connections with node A's tinc IP.
> "Forwarding=OFF" or "TunnelServer=YES" or
"IndirectData=NO"  are supposed
> to prevent this.
Neither Forwarding = off nor IndirectData = no will prevent this. The
TunnelServer = yes option might prevent it because it implies StrictSubnets yes.
> EvilNode can connect and establish a tinc IP connection to A.  I have to
> assume this happens because of Forwarding=internal by default.
No, the Forwarding option has, in principle, nothing to do with whether A
trusts EvilNode. You can however use the following combination of options to
only allow communication with nodes that you have a ConnectTo with:

Forwarding = off
DirectOnly = yes
IndirectData = yes
> "config get IndirectData" and "config get Forwarding"
and "config get
> TunnelServer" all return "No matching configuration variables
found."  So
> we have to rely on documentation or source code to determine what the
> default values are.  Default configuration parameters are in conflict but
> we have no way with tincctl to know what the actual parameters are for
> verification.
Hm, it would indeed be nice to have tincctl print the default value if it
isn't
found.
> The default value "Forwarding=internal"  contradicts both default
values
> "IndirectData=NO"  AND "TunnelServer=no", however
"Forwarding=internal"
> WINS allowing EvilNode to connect to A.
There is no contradiction.
> Is there an option to not allow any other node to connect to your node?  It
> could still ConnectTo Server1, but not allow any incoming connections.
There are two kinds of connections. If node A does not have the public key of
EvilNode, then EvilNode cannot make a meta-connection to A (it cannot ConnectTo
A). However, UDP packets to/from EvilNode will be allowed, unless you use
either StrictSubnets or the combination of Forwarding, DirectOnly and
IndirectData mentioned above.
> Without somewhat centralized control, it is hard to know who is connecting
> to who, which would be a good reason to have the option to put network keys
> into a DNSSEC server.
You can dump the graph and visualize it with the following command with tinc
1.1:

tincctl -n <netname> dump graph | circo -Txlib

(You can use neato or dot instead of circo for some alternative layouts.) This
will show you the graph of meta-connections. Besides the drawn lines, all nodes
can, unless prevented by NATs or firewalls, also exchange UDP packets directly
with each other.

In the case of EvilNode, the proper way to deny it access to the VPN would be
for B to remove hosts/EvilNode.  I agree this is not ideal. However,
"putting
the keys in DNSSEC" in itself is not an improvement, it merely shifts the
problem and makes the whole system more complex.

For tinc 1.1, I will probably add a way to blacklist specific nodes. A long
term solution will be implemented in tinc 2.0.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20130124/349a0cb8/attachment.pgp>

On Thu, Jan 24, 2013 at 10:53:18AM +0100, Guus Sliepen wrote:
> There are two kinds of connections. If node A does not have the public key
of
> EvilNode, then EvilNode cannot make a meta-connection to A (it cannot
ConnectTo
> A). However, UDP packets to/from EvilNode will be allowed, unless you use
> either StrictSubnets or the combination of Forwarding, DirectOnly and
> IndirectData mentioned above.
[...]
> In the case of EvilNode, the proper way to deny it access to the VPN would
be
> for B to remove hosts/EvilNode. [...]
What I forgot to mention is that EvilNode can only exchange packets with A,
either directly or forwarded via B, if and only if EvilNode has a working
meta-connection to B. So once B removes hosts/EvilNode and reloads its
configuration, it will kill the meta-connection between B and EvilNode, and A
will then immediately stop accepting packets from EvilNode.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc/attachments/20130124/bbc66627/attachment.pgp>

On Thu, Jan 24, 2013 at 4:14 AM, Guus Sliepen <guus at tinc-vpn.org>
wrote:
> On Thu, Jan 24, 2013 at 10:53:18AM +0100, Guus Sliepen wrote:
>
>> There are two kinds of connections. If node A does not have the public
key of
>> EvilNode, then EvilNode cannot make a meta-connection to A (it cannot
ConnectTo
>> A). However, UDP packets to/from EvilNode will be allowed, unless you
use
>> either StrictSubnets or the combination of Forwarding, DirectOnly and
>> IndirectData mentioned above.
> [...]
>> In the case of EvilNode, the proper way to deny it access to the VPN
would be
>> for B to remove hosts/EvilNode. [...]
>
> What I forgot to mention is that EvilNode can only exchange packets with A,
> either directly or forwarded via B, if and only if EvilNode has a working
> meta-connection to B. So once B removes hosts/EvilNode and reloads its
> configuration, it will kill the meta-connection between B and EvilNode, and
A
> will then immediately stop accepting packets from EvilNode.
>
> --
> Met vriendelijke groet / with kind regards,
>      Guus Sliepen <guus at tinc-vpn.org>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>
In a large network with large number of /hosts/ files on a large
number of not always connected machines, centralized management
provides a way to curtail the effects of a compromised machine
immediately.