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/
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@ibcl.at]
Sent: Tuesday, September 02, 2003 12:48 PM
To: tinc@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/
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@ibcl.at] Sent: Tuesday, September 02, 2003 12:48 PM To: tinc@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/
On Tue, Sep 02, 2003 at 09:47:47PM +0200, Dipl.-Ing. C. Lechleitner wrote:> 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.It could be a problem caused by differing OpenSSL versions. But it could also caused by putting a public or private key in the wrong place. Try removing all the public/private keys and generate them again.> What _exactly_ are the consequences and risks of using --bypass-security ?As Brian said, it disables authentication and encryption of the TCP connections, and allows you to telnet to a tinc daemon and type commands. It will still encrypt UDP packets, but since the key used to encrypt those is sent via the unencrypted TCP connections, it's not safe at all. There are other attacks possible as well. In short, never use --bypass-security :) -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@sliepen.eu.org> -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://brouwer.uvt.nl/pipermail/tinc/attachments/20030903/bb47cb1e/attachment.pgp