exact insecurity of --bypass-security ?

[Brian Costello]

Christoph:

Sorry to post again so quickly, but it looks FOR SURE like your problem
is the version mismatch.  Look at this:

>From http://tinc.nl.linux.org/documentation/tinc_6.html#SEC67

"A new scheme for authentication in tinc has been devised, which offers
some improvements over the protocol used in 1.0pre2 and 1.0pre3.
Explanation is below"

So it's time for an upgrade, I think, considering the source code that
appears to go with your error message appears to be directly related to
this authentication code.

tinc is really great, so you should stick with it!  It took me a little
while to get switch mode working, but it ended up working very nicely,
and was so much easier than getting FreeSWAN and KAME working together.

If you upgrade but still have problems with tincd, post back to this
list and I'll try to help.

bc

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