Toggle doesn't work, just refer to the security page.

[wiki] / security.mdwn

diff --git a/security.mdwn b/security.mdwn
index 91c5647..f08ba83 100644 (file)
--- a/security.mdwn
+++ b/security.mdwn
@@ -1,9 +1,54 @@
+## 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:
 ## 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
 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


@@ -22,7 +67,7 @@ well. Regenerate any keying material that you have exchanged via
 your tinc VPN if any of the nodes was running on an affected
 platform.
 
 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:
 
 Although tinc uses the OpenSSL library, it does not use the SSL protocol
 to establish connections between daemons. The reasons for this were:


@@ -37,10 +82,8 @@ René Korthaus, Andreas Hübner, Felix Stein and Wladimir Paulsen have also look
 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.
 
 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
 
 
 ### Predictable IV