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

[Guus Sliepen]

On Wed, Jan 30, 2013 at 01:53:56AM -0600, Rob Townley wrote:

> 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

No. If you want the behaviour of a traditional VPN, *use* a traditional VPN.

> > You can dump the graph and visualize it with the following command with tinc 1.1:
> >
> > tincctl -n <netname> dump graph | circo -Txlib
> >
> 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.

The case your are referring to was more equivalent to giving your private keys
to someone else. There is nothing you can do against that of course. But
indeed, with plain tinc, exchanging public keys is all that is needed to
introduce another node to the VPN. If you want centralized management, then you
could use a wrapper around tinc like ChaosVPN, which takes care of centralized
management of host config files, and uses StrictSubnets to make it "paranoid".

> 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?

Effectively, yes. But it will add even more restrictions. I don't recommend
using this option.

> 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) (*).

This would indeed only complicate things.

-- 
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/20130130/3035f8fb/attachment.pgp>