Conflicting Default Values. A trusts B. B trusts EvilNode. Does that mean A trusts EvilNode?

[Guus Sliepen]

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>