+## 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
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
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
-On September 15th, 2003, Peter Gutmann contacted us and showed us part of a
-[writeup](http://www.mail-archive.com/cryptography@metzdowd.com/msg00891.html)
-which he posted to a
-[cryptography mailing list](http://www.mail-archive.com/cryptography%40metzdowd.com/maillist.html)
-on the 22th. In this writeup he identifies several security issues
-in CIPE, VTun and tinc. Below we will examine his findings and
-explain why some flaws or weaknesses Peter Gutmann found are in
-fact not a problem at all for a VPN daemon like tinc. As a reader
-you are ultimately left to draw your own conclusions, I encourage
-you to read all the arguments from both sides and, if possible,
-verify them by reading the documentation and source code of tinc.
-Comments are welcome.
+Although tinc uses the OpenSSL library, it does not use the SSL protocol
+to establish connections between daemons. The reasons for this were:
-### Predictable IV
+- 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.
-> *tinc uses a completely predictable 32-bit IV in combination with CBC encryption, which makes the first encrypted block vulnerable, but isn't quite as bad as the ECB used in vtun (actually it isn't an IV in the true sense, it prepends a 32-bit sequence number to the encrypted data, but it works the same way).*
+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.
-When the same key is used to encrypt more than one message with a
-symmetric cipher in CBC mode, one should use a different IV for
-each message, to prevent that packets with the same plaintext end
-up having the same ciphertext. That the IV is known to an attacker
-is not of any concern. The best way to provide an IV is to add a
-random number the size of one block in plaintext to the packet, or
-to add the last ciphertext block from the previous packet sent to
-the new packet.
+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 exchanging encryption keys, tinc also sends a full IV.
-However, although this IV is used it is the same for every packet
-sent with the same key, and thus does not provide much more
-security over no IV. In addition, tinc has added more data to each
-packet to act as a distinct IV for each packet. Because this means
-more overhead and possibly more fragmentation, tinc has always used
-much less than a full block for this. Up until 1.0pre4, a 16 bit
-random number was used (the length could only be changed at
-compiletime). After that, the 32 bit sequence number needed for
-replay protection was also used to act as an IV. For tinc 2.0, we
-will probably optionally add a full IV and move the sequence number
-out of the ciphertext, as described in RFC 2405 and 2406.
+### Predictable IV
-### Truncated MAC
+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.
-> *Packets are protected with a 32-bit (very) truncated HMAC using encrypt-then-MAC.*
+### Truncated MAC
-A MAC makes sure an attacker cannot alter a packet without the
-recipient noticing this. Tinc appends a HMAC of the ciphertext at
-the end of the packet, which is common practice. SHA1 is used as
-the hash function by default, but only the first 32 bits are
-appended to the packet by default. The more bits are used the
-stronger the MAC is, but it will also increase overhead. Still,
-using only 32 bits doesn't mean a trivial attack is possible. Again
-there must be a balance between security and performance; tinc will
-continue to use only the first 32 bits by default.
+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's real problem though is the handshake protocol, in which the client and server exchange random RSA-encrypted strings. That's raw bit strings, there's no PKCS #1 or OAEP padding, and the server is happy to act as an oracle for you too. This is a terrible way to use RSA, and usually compromises the key. There is a significant body of literature on this (too much to cite) going back to the early 1980s and continuing through to the current day, with probably the most recent publication in this area being the attack published at Usenix Security '03 only a few weeks ago (in that case it was a timing oracle).*
-
-When encrypting messages using the RSA algorithm, care must be
-taken to prevent certain attacks. The PKCS #1 and OAEP padding
-schemes are designed to prevent those attacks. Basically, OAEP
-ensures proper termination of the actual message, adds a hash of
-that message to make sure it isn't altered by an attacker, and pads
-the rest with the output of a PRNG until the resulting message has
-the same length as the RSA key, so that the message doesn't have
-too low entropy or trivial padding (such as 0 bits) which can be
-used in an attack.
-
-Tinc uses RSA encryption only once, during authentication. A
-message is sent which has the same length as the RSA key, and is
-completely filled with the output of a PRNG which is assumed to be
-secure and seeded using real random data (OpenSSL's
-`RAND_bytes()`). So, the message does not have low entropy and
-doesn't contain predictable bits. However, there is no guarantee
-that the message was encrypted using the correct public key or that
-noone has tampered with it. This is of no concern for tinc though.
-Part of the message is used as the key for the symmetric cipher
-that is used by the sender of this key to encrypt the rest of the
-messages it will send. A challenge-response exchange right after
-exchanging the RSA encrypted messages is done to ensure that both
-the sender of the symmetric cipher key has the right public key,
-the recipient has the right corresponding private key, and the
-message was not tampered with (because that would change the
-symmetric cipher key).
+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.
-Currently, tinc can be used as a timing oracle, because no RSA
-blinding is done. We tried to implement this, but unfortunately
-OpenSSL's library functions which would take care of this let tinc
-crash, and we haven't found the reason for this yet. We do not see
-how tinc could be used as any other kind of oracle.
+There are timing attacks against RSA.
+Tinc does not protect against those.
### Authentication protocol
-> *Beyond that, the [protocol writeup](http://www.tinc-vpn.org/documentation/tinc_6.html#SEC61) points out that:*
-> > the server sends exactly the same kind of messages over the wire as
-> > the client
->
-> *In case the problem isn't obvious yet, note that what's being exchanged is purely a random bit string, with no binding of client or server roles or identities into any part of the exchange. Again, there are way too many references to cite on these issues, although my favourite coverage of a lot of the things you need to think about is in "Network Security: Private Communication in a Public World" by Kaufman, Perlman, and Speciner.*
-
-There are no server and client roles in tinc, because it is
-peer-to-peer. When a new TCP connections is made, both peers have
-to authenticate themselves to eachother, and both have to be
-configured to trust the other to let the authentication succeed. We
-do not see how this remark about tinc not identifying a server and
-a client diminishes security.
-
-> *As an example, here's a simple attack. The documentation (section 6.3.1) is a bit vague about the message flow, but assuming I've understood it correctly, the message flow is:*
-> client server
-> rsa( random_key ) -->
-> random_key( challenge ) -->
-> <-- random_key( sha1( challenge ) )
->
-> *Simplifying things a bit so that the entire exchange can be abstracted down to "challenge" and "response" (with implied RSA decryption, etc etc taking place as part of that), let's say Mallet wants to mess with Alice and Bob. So Mallet sends a challenge to Bob (claming to be Alice) and gets back a response. Mallet gets Bob's encrypted key and challenge back and forwards it to Alice, who returns a response, which Mallet in turn forwards to Bob, a classic chess grandmaster attack. Bob now thinks he's talking to Alice, when in fact Mallet controls one of the two channels.*
-
-First of all, we assume Mallet does not know the private keys of
-Bob and Alice (Bob and Alice are not compromised), and Bob and
-Alice do not know Mallet at all (they don't trust Mallet, otherwise
-he could've made a connection without having to resort to a
-cryptographic attack). We do assume that Mallet knows the public
-keys of Alice and Bob. First, keys for the symmetric cipher
-encryption are exchanged. Mallet cannot decrypt keys he gets from
-Bob and Alice, because he doesn't have their private keys. He can
-send his own keys, encrypted with Bob and Alice's public keys. So
-after the key exchange, Mallet can send plaintext to Bob and Alice,
-which will decrypt them correctly, but he cannot read the plaintext
-Bob and Alice send to him. So Mallet sends a challenge to Bob, who
-can decrypt it, and Bob returns a response which Mallet cannot
-read. Mallet cannot decrypt it, reencrypt it and send it to Alice,
-and neither can he forward the ciphertext from Bob to Alice,
-because Alice uses a different key to decrypt messages from Mallet
-than Bob uses to encrypt messages to Mallet. Hence, this attack
-won't work, and Peter Gutmann is wrong on this point.
-
-### Configuration
-
-> *As an extension of the handshake problem, tinc relies heavily on an administrator at both ends of the link configuring the software identically for the handling of the handshake phase, replacing the authenticated parameter negotiation performed by protocols like SSL/TLS, SSH, and IPsec (during the data transfer phase there are ways of negotiating parameters, I haven't looked at this too much).*
-
-Tinc does not have to be configured identically on each endpoint.
-When making an encrypted connection between to hosts, it is common
-to negotiate which cipher to use. However, tinc does not just
-create a tunnel between two endpoints, it can handle any number of
-endpoints. Because it is very hard to negotiate a single cipher for
-all endpoints, tinc does not negotiate, and allows each endpoint to
-choose which cipher should be used to encrypt packets to it,
-regardless of what cipher the other endpoints use. This does not
-compromise security in itself, and in fact this might even improve
-security.
-On the other hand an administrator of one endpoint might choose to
-use an insecure cipher instead of the default, and compromise
-traffic other endpoints send to it. Tinc could be rewritten to
-always enforce the use of the strongest cipher, but we believe you
-should trust every participant in the VPN, and if one administrator
-is not trustworthy, he should be removed from the VPN: even with
-enforcement of strong ciphers, a malicious participant could just
-as easily post all the VPN traffic he receives on a website, so it
-really doesn't improve security at all.
-
-### General issues
-
-> *- Don't use the same key for encryption and authentication.*
-
-Nowhere in the authentication protocol does this happen.
-
-> *- Don't have the key chosen entirely by one side (even if it's only Alice and Bob on the line rather than Mallet, if one of the two has a poor RNG, all communications from them are compromised).*
-
-This is a valid point. Tinc can easily be changed to use keys
-composed of what both sides send, for example by using the
-Diffie-Helman scheme. This is planned for tinc 2.0.
-
-> *- Provide message freshness guarantees (and, if possible, some form of PFS).*
-
-Currently only the UDP packets sent by tinc have PFS, but this is
-not true for the TCP connections (the meta protocol). This will be
-resolved in tinc 2.0.
-
-> *- Bind the identity of the principals to the authentication.*
-
-The authentication is done using RSA encryption, the RSA keys are
-directly bound to the identities of the tinc daemons.
-
-> *- Don't use the same messages in both directions.*
-
-Tinc doesn't send the same messages, it sends the same *kinds* of
-messages.
-
-> *- Don't act as an oracle for an attacker.*
-
-Apart from possibly being susceptible to a timing attack, we don't
-believe, and Peter Gutmann has not convinced us, that tinc can be
-used as any other kind of oracle.
-
-> *As it stands the handshake protocol only narrowly avoids a variety of basic attacks, making it quite brittle in that the most trivial change (or someone thinking about possible attacks a bit further :-) would probably kill it.*
-
-I think this holds for virtually all cryptographic handshake
-protocols.
-
-### Thoughts
-
-> *These programs have been around for years (CIPE goes back to 1996 and vtun to 1998) and (apparently) have quite sizeable user communities without anyone having noticed (or caring, after flaws were pointed out) that they have security problems. I only heard of CIPE when a friend of mine mentioned it to me in passing, and came across vtun by coincidence when I was looking for more info on CIPE. Who knows how many more insecure Linux crypto-tunnel products there may be floating around out there.*
-
-Although security can only be proven by time and peer review, the
-lack of some people noticing certain software applications does not
-have a direct relation to their security. The fact that Peter
-Gutmann only examined three specific Open Source VPN products does
-not say anything about the security of other products.
-
-> *It's possible to create insecure "security" products just as readily with open-source as with closed-source software.*
-
-I don't think anyone disagrees with that.
-
-> *CIPE and vtun must be the OSS community's answer to Microsoft's PPTP implementation. What's even worse is that some of the flaws were pointed out nearly two years ago, but despite the hype about open-source products being quicker with security fixes, some of the protocols still haven't been fixed. At least Microsoft eventually tries to fix their stuff, given sufficient public embarrassment and the odd hundred thousand or so computers being taken out by attackers.*
-
-Microsoft sells its products as being secure, and the people who
-buy its products have expectations. But not everyone is out there
-to make software that is as secure as possible, VTun even mentions
-it is not intended to be secure, and CIPE focuses more on usability
-than on security.
-
-> *For all of these VPN apps, the authors state that they were motivated to create them as a reaction to the perceived complexity of protocols like SSL, SSH, and IPsec. The means of reducing the complexity was to strip out all those nasty security features that made the protocols complex (and secure). Now if you're Bruce Schneier or Niels Ferguson, you're allowed to reinvent SSL ("Practical Cryptography", John Wiley & Sons, 2003). Unfortunately the people who created these programs are no Bruce or Niels. The results are predictable.*
-
-Development of CIPE, VTun and tinc has started in times when SSH,
-SSL and IPsec were nowhere as popular as they are now. We certainly
-never claimed we created tinc in reaction to those protocols.
-Furthermore, SSL and SSH are reliable stream based protocols,
-unsuitable for VPNs which work best with unreliable datagrams,
-hence it wouldn't have been an obvious choice to use SSH or SSL in
-the first place. Both SSL and SSH have had their security problems
-in the past (and in the case of OpenSSH, even in the recent past),
-emphasizing that even these widely used and scrutinised protocols
-are not as perfect as Peter Gutmann would let us believe.
-Apart from that, there is no reason why people shouldn't create new
-protocols, which might in time become just as strong or even
-stronger. Even great names as Ron Rivest didn't get it right the
-first time.
-
-> *Whenever someone thinks that they can replace SSL/SSH with something much better that they designed this morning over coffee, their computer speakers should generate some sort of penis-shaped sound wave and plunge it repeatedly into their skulls until they achieve enlightenment.*
-
-A very professional and constructive argument.
-
-> *Replacing the SSL/SSH data channel is marginally justifiable, although usually just running SSL/SSH over UDP would be sufficient. Replacing the SSL/SSH control channel is never justifiable - even the WAP guys, with strong non-SSL/SSH requirements, simply adapted SSL rather than trying to invent their own protocol.*
-
-We have no obligation to justify anything we do. We also do not
-believe SSL is the be-all, end-all of cryptography.
+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.
projects / wiki / blobdiff