Securing tinc config files

[Graham Cobb]

On 24/01/16 12:19, Yazeed Fataar wrote:
> I cannot use dynamic dns , the remote sites connect through 4G LTE and
> get assigned "Private Addresses" that are NATd to a Public Address. The
> LTE clients can only make connections outward to the Internet and
> features such as PAT and Dynamic DNS will not work. Therfor for these
> remote sites I need a Central Server Located on Internet to peer with in
> order for the Site to Site connection to work. Tinc works perfectly in
> this and I have tested it thoroughly, I just have concerns now over the
> Central Server which holds all the tinc configuration data.

The issue with all security is to understand what is the threat (who are
you trying protect from), how long do you need to resist the threat, and
how much is the protected asset worth (i.e. how much are you willing to
spend to protect it).  If you are REALLY serious about your question,
and are willing to spend money to fix it, you need to pay a security
consultant to come up with the required design that trades these three
off in the way you choose.

That said, here are some free thoughts (and I am no expert) - which are
worth all that you are paying for them :-)

In my experience, in practice, a paid-for VPS, from a reputable
supplier, is secure enough for most purposes.  Even small businesses.  A
medium-sized business might prefer a physical co-lo server in a locked
cage.  In either case, you have a contract with the provider, they have
a policy (such as the Digital Ocean policy you quoted), and they have a
reputation to uphold. Of course, that will not protect you from state
actors (police, spies, etc), and it won't protect you against someone
who is willing to bribe the VPS staff.  On the other hand, I have run
tinc with a VPS central node for many years (probably more than 10) and
have never seen any unexpected node appear (of course, I can't tell if
someone is decrypting all my traffic).

If you really want to avoid having the keys on the central server, you
could arrange to run tinc on a server you control (e.g. at home) and
forward all the (encrypted) tinc traffic from the central server to it.
 You could, for example, make an outgoing SSH connection from your home
node to the central server with port forwarding, so that all traffic to
the tinc port on the central server gets forwarded to the tinc port on
your home server.  You would have to write some scripts to make sure the
connection was reconnected whenever it failed, and performance would
probably be very poor, but it would avoid the keys being on the central
server.

But, is it worth it?  If you are trying to protect against state actors
you have probably already lost.  If not, a VPS is probably good enough.
 If it isn't, you are probably a large corporation with plenty of real
physical servers visible on the internet.

Just my thoughts.

Graham