Reporting security issues

In case you have found a security issue in tinc, please report it via email to Guus Sliepen, preferrably PGP encrypted. We will then try to get a CVE number assigned, and coordinate a bugfix release with major Linux distributions.

Security advisories

The following list contains advisories for security issues in tinc in old versions:

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: 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 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.

Predictable IV

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.

Truncated MAC

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 MACLength option. 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.

Authentication protocol

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.