exact insecurity of --bypass-security ?

[Brian Costello]

Christoph:

I'm not positive about the consequences of --bypass-security... The man
page says "disables encryption and authentication of the meta protocol".
Assuming this is accurate, the meta protocol is the (I think) tcp
connection that passes node & subnet addition messages to each node in
the tinc network.  If you bypass the security, you should be able to
connect to the tincd port (usually 655/tcp) with netcat and enter raw
commands as explained in:
http://tinc.nl.linux.org/documentation/tinc_6.html#IDX98

So perhaps this means that the entire *TCP* connection is unencrypted.
But that leaves me wondering how the UDP link could be encryptoed since
the meta protocol seems to be where the key exchange takes place.  It
SEEMS like --bypass-security would result in BOTH the tcp & udp
connections being unauthenticated AND unecnrypted.  Maybe you're seeing
compression in the UDP packets and mistaking it for encryption?  I'd be
really surprised if the UDP packets excchange keys using UDP, since the
tcp connection is available and would be a lot easier to implement using
those.

Looking through the source code, the "Bogus data" seems to come from the
client passing illegal commands to the server.  Therefore, I'm guessing
that your problem is the version mismatch.  Just build openssl-0.9.7b
(./config shared && make && make install), install, remove the old
verison's .so symlinks, .a files, add /usr/local/ssl/lib to
/etc/ld.so.conf, and make sure the /usr/include/openssl files are the
latest, build the new tincd, install and you should be good to go.  To
check which version tinc's linked against, type ldd `which tincd`   -
you should see it linked against libcrypto.so.0.9.7.  If not, you didn't
remove the .so symlink to the old version of libcrypto.

I realize that was a pretty compressed version of openssl upgrade
instructions, so if you need help upgrading your openssl, let me know
and I'll try to help - I've done hundreds of openssl upgrades over the
last few years, so I've gotten pretty good at it :)

Hope this helped somewhat...

Brian Costello

-----Original Message-----
From: Dipl.-Ing. C. Lechleitner [mailto:christoph.lechleitner at ibcl.at] 
Sent: Tuesday, September 02, 2003 12:48 PM
To: tinc at nl.linux.org
Subject: exact insecurity of --bypass-security ?


Hello!

First, nice peace of work, thx ;->>

After some production server crashes with a far too early version of
FreeSWAN (abaout 3 years ago) and the unwillingness to get an OpenSSL
expert just to build a VPN, I was happy to read about the rather simple
configuration of tinc ("Linux Magazin", a monthly Linux paper published
in Germany, gave an overview of free VPN solutions in their brand new
10/2003 release).

Unfortunately, I could only get the tinc VPN working using the
--bypass-security parameter, without this switch I got "Bogus data from
... " messages in syslog. I have tried the statical linked 1.0.1 binary
as well as a self compiled binary, both under SuSE 8.2.

The problem might be that tinc 1.0.1 relies on OpenSSL 0.9.7, while our
SuSE systems use a SuSE patched 0.9.6i release (there are no OpenSSL
0.9.7 packages available for most Linux distributions). Of course I
upgraded to 0.9.7 temporarily, just to be able to compile tinc myself,
but I am not entirely sure if I had 0.9.7 (and only 0.9.7) active, and,
it did not help.

As we do not really need the VPN so far (ssh tunnels are quite ok for
the few linux-to-linux connections we really do need), I am not planning
to invest too much time just to get rid of the --bypass-security switch,
so I would like just to ask ...

  What _exactly_ are the consequences and risks of using
--bypass-security ?

My network sniffs as well as an earlier posting here seem to show that
the packets are still not sent in clear text, but what does the
--bypass-security turn off if not encryption?

As far as I think to understand protocol_auth.c, it
- switches of the check of RSA keys
- suppresses the checking of IndirectData and TCPOnly settings
  (therefore forcing UDP usage?)

The "only" security leak seems to be that a foreign system might join
the VPN, if it has the same tinc configuration as the real partner _and_
"steels" the real partner's IP address (by IP spoofing or by a kind of
man-in-the-middle attack).

As a conclusion, using --bypass-security would mean:
- Data still are transfered encrypted, but
- a man-in-the-middle attack would be possible and could start anytime a
  connection is (re)established

Am I correct?

Kind regards,

Christoph Lechleitner

Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://tinc.nl.linux.org/

Tinc:         Discussion list about the tinc VPN daemon
Archive:      http://mail.nl.linux.org/lists/
Tinc site:    http://tinc.nl.linux.org/