+## Reporting security issues
+
+In case you have found a security issue in tinc, please report it via email
+to Guus Sliepen <guus@tinc-vpn.org>, 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:
+
+- [CVE-2018-16758](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16758):
+ Michael Yonli discovered that tinc 1.0.34 and earlier allow a [man-in-the-middle attack](https://en.wikipedia.org/wiki/Man-in-the-middle_attack)
+ that, even if the MITM cannot decrypt the traffic sent between the two
+ endpoints, when the MITM can correctly predict when an ephemeral key exchange
+ message is sent in a TCP connection between two nodes, allows the MITM to
+ force one node to send UDP packets in plaintext.
+ The tinc 1.1pre versions are not affected by this.
+
+- [CVE-2018-16738](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16738):
+ Michael Yonli discoverd that tinc versions 1.0.30 to 1.0.34 allow an [oracle attack](https://en.wikipedia.org/wiki/Oracle_attack),
+ similar to CVE-2018-16737, but due to the mitigations put in place for the Sweet32
+ attack in tinc 1.0.30, it now requires a [timing attack](https://en.wikipedia.org/wiki/Timing_attack)
+ that has only a limited time to complete.
+ Tinc 1.1pre16 and earlier are also affected if there are nodes on the same
+ VPN that still use the legacy protocol from tinc version 1.0.x.
+
+- [CVE-2018-16737](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16737):
+ Michael Yonly discovered that tinc 1.0.29 and earlier allow an [oracle attack](https://en.wikipedia.org/wiki/Oracle_attack)
+ that could allow a remote attacker to establish one-way communication with a
+ tinc node, allowing it to send fake control messages and inject packets into
+ the VPN. The attack takes only a few seconds to complete.
+ Tinc 1.1pre14 and earlier allow the same attack if they are configured to allow connections
+ from nodes using the legacy 1.0.x protocol.
+
+- [CVE-2013-1428](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-1428),
+ [DSA-2663](https://www.debian.org/security/2013/dsa-2663),
+ [Sitsec advisory](http://sitsec.net/blog/2013/04/22/stack-based-buffer-overflow-in-the-vpn-software-tinc-for-authenticated-peers):
+ stack based buffer overflow
+
+- [CVE-2002-1755](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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](https://cve.mitre.org/cgi-bin/cvename.cgi?name=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](http://www.debian.org/security/2008/dsa-1571)
+[https://www.debian.org/security/2008/dsa-1571](https://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
your tinc VPN if any of the nodes was running on an affected
platform.
-## Security issues in tinc
+## 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:
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.
-For tinc 2.0 and later we will use a standard protocol like SSH or TLS to perform authentication.
-For the encapsulated packets, we will consider protocols like DTLS, but due to the specific needs of a peer-to-peer VPN,
-we might also keep our own protocol, but update it to current security standards.
-We might also release an interim version that just fixes the vulnerabilities in tinc 1.x in the near future.
+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