The following list contains advisories for security issues in tinc in old versions:
CVE-2002-1755: tinc 1.0pre3 and 1.0pre4 VPN do not authenticate forwarded packets, which allows remote attackers to inject data into user sessions without detection, and possibly control the data contents via cut-and-paste attacks on CBC.
CVE-2001-1505: tinc 1.0pre3 and 1.0pre4 allow remote attackers to inject data into user sessions by sniffing and replaying packets.
Possible weak keys generated by tinc on Debian (and derivates) due to a security bug in Debian’s OpenSSL packages
For those who run tinc on Debian or Debian-based distributions like Ubuntu and Knoppix, be advised that the following security issue affects tinc as well: http://www.debian.org/security/2008/dsa-1571 In short, if you generated public/private keypairs for tinc between 2006 and May 7th, 2008 on a machine running Debian or a derivative, they may have been generated without a properly seeded random number generator. Please ensure you have updated your OpenSSL packages and regenerate all suspect keypairs. Do not forget to restart tinc.
If you have compiled a static version of tinc on an affected platform, you need to recompile tinc to ensure it is statically linked with a fixed OpenSSL library.
I do not know if the session keys also have been weak, but it is best to assume they were. If you exchanged private key material via your tinc VPN, then an eavesdropper may have seen seen this as well. Regenerate any keying material that you have exchanged via your tinc VPN if any of the nodes was running on an affected platform.
Known security issues in tinc 1.0.x
Although tinc uses the OpenSSL library, it does not use the SSL protocol to establish connections between daemons. The reasons for this were:
- When tinc was created, SSL 3.0 was only just gaining popularity for use outside web browsers and servers.
- SSL at that time did not make it easy to have both sides of the connection authenticate each other.
- SSL requires a TCP-like transport layer to function, whereas a VPN works much more efficient if it can send encapsulated packets via a UDP-like transport layer.
When tinc 1.0 was released, the protocol used was declared stable and would not change anymore. However, since then some weaknesses were found, mainly by Peter Gutmann in 2003. René Korthaus, Andreas Hübner, Felix Stein and Wladimir Paulsen have also looked at tinc’s protocol recently, and have provided a more in-depth analysis of the most critical weaknesses. In the interest of full disclosure we will list the known weaknesses below.
Tinc 1.1pre3 and later will use a new protocol that fixes all these issues, and that is similar to (D)TLS with a strong cipher suite.
When encrypting UDP packets, tinc uses the CBC block cipher mode with a 32-bit counter as the IV. This was chosen to avoid the overhead of a full random IV for every packet. However, due to the predictable IV, an attacker could launch a chosen-plaintext attack (Katz/Lindell, “Introduction to cryptography”, p.97), allowing it to distinguish known plaintexts from each other.
By default, tinc uses a HMAC to authenticate packets that is trunctated to 32 bits.
This default was chosed to avoid the overhead of a full 160 bit hash for every packet.
An attacker on a high-speed network connection could inject a forged packet by sending it 2^31 times on average with different HMACs.
It is possible to change the strength of the HMAC with the
We will change the default length in the future.
Use of RSA
Tinc uses RSA without padding. Padding schemes are designed to prevent attacks when the size of the plaintext is not equal to the size of the RSA key. However, tinc always encrypts random numbers that have the same size as the RSA key, which should safe.
There are timing attacks against RSA. Tinc does not protect against those.
Tinc uses RSA encryption to send symmetric cipher keys to its peer. Then, a challenge/response exchange is done to verify that each peer indeed has the private key. However, there is a man-in-the-middle possible where an attacker that has the public key of the peers can gain control over one side of the communication between two peers. The MITM cannot decrypt messages between peers, but it can send messages to the peer that initiated the connection. If the MITM knows enough about the VPN, it could trick peers into sending it packets that it can decrypt. However, the MITM cannot send packets to other peers.