## 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) 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. ## Security issues in tinc 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. ### Predictable IV > *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 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. 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. ### Truncated MAC > *Packets are protected with a 32-bit (very) truncated HMAC using encrypt-then-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. ### 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). 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. ### 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.