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

[Rob Townley]

On Thu, Jan 24, 2013 at 3:53 AM, Guus Sliepen <guus at tinc-vpn.org> wrote:
> 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

Could we have a Paranoid=< yes | no > (no)
   Paranoid=yes is an alias that sets other configuration options to make tinc
   behave more like a traditional VPN.  When setting this, it will forcibly
   set all of the following, but not limited to:
       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.

UDP packets ... that would explain a great deal.

>
>> 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.
>
The graphing features are cool and i like them, but if you want to be
absolutely certain of all nodes that could possibly connect into the
vpn, including those that are powered off, then a centralized node
management system.  Vain attempt to prevent one of the programmers
from sending his public key to China to outsource his own work.

> 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>
>
> _______________________________________________
> tinc mailing list
> tinc at tinc-vpn.org
> http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc
>

In addition to wondering aloud if a new configuration option could be
created that may be a set of aliases for existing config options.

TunnelServer = <yes|no> (no) [experimental]
Would setting TunnelServer=yes on each client do the same as the
paranoid setting above?

The following would way over complicate things unless a really good
data structure made it simple:

AllowConnectFrom=< NULL |  TrustedNodeName, ... | AnyTrustedNode  |
AnyUntrustedNode * >  (*)
  Specifying NULL here means that tinc will not service any incoming
connections.  Not even those in its /hosts/ folder.
  Specifying a comma separated TrustedNodeName list will allow
incoming connections from NodeNames in its known /hosts/ folder.
  Specifying AnyTrustedNode would mean any known /hosts/ entry would
be allowed an incoming connection.
  Specifying AnyTransitiveTrustedNode would mean any known /hosts/
entry from any other trusted host would be allowed an incoming
connection.
  Currently, by default, tinc accepts incoming connections from any
other node (AnyUntrustedNode) (*).


Guus, Thank You for reading.