1 ## Possible weak keys generated by tinc on Debian (and derivates) due to a security bug in Debian's OpenSSL packages
3 For those who run tinc on Debian or Debian-based distributions like
4 Ubuntu and Knoppix, be advised that the following security issue
6 [http://www.debian.org/security/2008/dsa-1571](http://www.debian.org/security/2008/dsa-1571)
7 In short, if you generated public/private keypairs for tinc between
8 2006 and May 7th, 2008 on a machine running Debian or a derivative,
9 they may have been generated without a properly seeded random
10 number generator. Please ensure you have updated your OpenSSL
11 packages and regenerate all suspect keypairs. Do not forget to
13 If you have compiled a static version of tinc on an affected
14 platform, you need to recompile tinc to ensure it is statically
15 linked with a fixed OpenSSL library.
16 I do not know if the session keys also have been weak, but it is
17 best to assume they were. If you exchanged private key material via
18 your tinc VPN, then an eavesdropper may have seen seen this as
19 well. Regenerate any keying material that you have exchanged via
20 your tinc VPN if any of the nodes was running on an affected
23 ## Security issues in tinc
25 On September 15th, 2003, Peter Gutmann contacted us and showed us part of a
26 [writeup](http://www.mail-archive.com/cryptography@metzdowd.com/msg00891.html)
28 [cryptography mailing list](http://www.mail-archive.com/cryptography%40metzdowd.com/maillist.html)
29 on the 22th. In this writeup he identifies several security issues
30 in CIPE, VTun and tinc. Below we will examine his findings and
31 explain why some flaws or weaknesses Peter Gutmann found are in
32 fact not a problem at all for a VPN daemon like tinc. As a reader
33 you are ultimately left to draw your own conclusions, I encourage
34 you to read all the arguments from both sides and, if possible,
35 verify them by reading the documentation and source code of tinc.
40 > *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).*
42 When the same key is used to encrypt more than one message with a
43 symmetric cipher in CBC mode, one should use a different IV for
44 each message, to prevent that packets with the same plaintext end
45 up having the same ciphertext. That the IV is known to an attacker
46 is not of any concern. The best way to provide an IV is to add a
47 random number the size of one block in plaintext to the packet, or
48 to add the last ciphertext block from the previous packet sent to
51 When exchanging encryption keys, tinc also sends a full IV.
52 However, although this IV is used it is the same for every packet
53 sent with the same key, and thus does not provide much more
54 security over no IV. In addition, tinc has added more data to each
55 packet to act as a distinct IV for each packet. Because this means
56 more overhead and possibly more fragmentation, tinc has always used
57 much less than a full block for this. Up until 1.0pre4, a 16 bit
58 random number was used (the length could only be changed at
59 compiletime). After that, the 32 bit sequence number needed for
60 replay protection was also used to act as an IV. For tinc 2.0, we
61 will probably optionally add a full IV and move the sequence number
62 out of the ciphertext, as described in RFC 2405 and 2406.
66 > *Packets are protected with a 32-bit (very) truncated HMAC using encrypt-then-MAC.*
68 A MAC makes sure an attacker cannot alter a packet without the
69 recipient noticing this. Tinc appends a HMAC of the ciphertext at
70 the end of the packet, which is common practice. SHA1 is used as
71 the hash function by default, but only the first 32 bits are
72 appended to the packet by default. The more bits are used the
73 stronger the MAC is, but it will also increase overhead. Still,
74 using only 32 bits doesn't mean a trivial attack is possible. Again
75 there must be a balance between security and performance; tinc will
76 continue to use only the first 32 bits by default.
80 > *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).*
82 When encrypting messages using the RSA algorithm, care must be
83 taken to prevent certain attacks. The PKCS #1 and OAEP padding
84 schemes are designed to prevent those attacks. Basically, OAEP
85 ensures proper termination of the actual message, adds a hash of
86 that message to make sure it isn't altered by an attacker, and pads
87 the rest with the output of a PRNG until the resulting message has
88 the same length as the RSA key, so that the message doesn't have
89 too low entropy or trivial padding (such as 0 bits) which can be
92 Tinc uses RSA encryption only once, during authentication. A
93 message is sent which has the same length as the RSA key, and is
94 completely filled with the output of a PRNG which is assumed to be
95 secure and seeded using real random data (OpenSSL's
96 `RAND_bytes()`). So, the message does not have low entropy and
97 doesn't contain predictable bits. However, there is no guarantee
98 that the message was encrypted using the correct public key or that
99 noone has tampered with it. This is of no concern for tinc though.
100 Part of the message is used as the key for the symmetric cipher
101 that is used by the sender of this key to encrypt the rest of the
102 messages it will send. A challenge-response exchange right after
103 exchanging the RSA encrypted messages is done to ensure that both
104 the sender of the symmetric cipher key has the right public key,
105 the recipient has the right corresponding private key, and the
106 message was not tampered with (because that would change the
107 symmetric cipher key).
109 Currently, tinc can be used as a timing oracle, because no RSA
110 blinding is done. We tried to implement this, but unfortunately
111 OpenSSL's library functions which would take care of this let tinc
112 crash, and we haven't found the reason for this yet. We do not see
113 how tinc could be used as any other kind of oracle.
115 ### Authentication protocol
117 > *Beyond that, the [protocol writeup](http://www.tinc-vpn.org/documentation/tinc_6.html#SEC61) points out that:*
118 > > the server sends exactly the same kind of messages over the wire as
121 > *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.*
123 There are no server and client roles in tinc, because it is
124 peer-to-peer. When a new TCP connections is made, both peers have
125 to authenticate themselves to eachother, and both have to be
126 configured to trust the other to let the authentication succeed. We
127 do not see how this remark about tinc not identifying a server and
128 a client diminishes security.
130 > *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:*
132 > rsa( random_key ) -->
133 > random_key( challenge ) -->
134 > <-- random_key( sha1( challenge ) )
136 > *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.*
138 First of all, we assume Mallet does not know the private keys of
139 Bob and Alice (Bob and Alice are not compromised), and Bob and
140 Alice do not know Mallet at all (they don't trust Mallet, otherwise
141 he could've made a connection without having to resort to a
142 cryptographic attack). We do assume that Mallet knows the public
143 keys of Alice and Bob. First, keys for the symmetric cipher
144 encryption are exchanged. Mallet cannot decrypt keys he gets from
145 Bob and Alice, because he doesn't have their private keys. He can
146 send his own keys, encrypted with Bob and Alice's public keys. So
147 after the key exchange, Mallet can send plaintext to Bob and Alice,
148 which will decrypt them correctly, but he cannot read the plaintext
149 Bob and Alice send to him. So Mallet sends a challenge to Bob, who
150 can decrypt it, and Bob returns a response which Mallet cannot
151 read. Mallet cannot decrypt it, reencrypt it and send it to Alice,
152 and neither can he forward the ciphertext from Bob to Alice,
153 because Alice uses a different key to decrypt messages from Mallet
154 than Bob uses to encrypt messages to Mallet. Hence, this attack
155 won't work, and Peter Gutmann is wrong on this point.
159 > *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).*
161 Tinc does not have to be configured identically on each endpoint.
162 When making an encrypted connection between to hosts, it is common
163 to negotiate which cipher to use. However, tinc does not just
164 create a tunnel between two endpoints, it can handle any number of
165 endpoints. Because it is very hard to negotiate a single cipher for
166 all endpoints, tinc does not negotiate, and allows each endpoint to
167 choose which cipher should be used to encrypt packets to it,
168 regardless of what cipher the other endpoints use. This does not
169 compromise security in itself, and in fact this might even improve
171 On the other hand an administrator of one endpoint might choose to
172 use an insecure cipher instead of the default, and compromise
173 traffic other endpoints send to it. Tinc could be rewritten to
174 always enforce the use of the strongest cipher, but we believe you
175 should trust every participant in the VPN, and if one administrator
176 is not trustworthy, he should be removed from the VPN: even with
177 enforcement of strong ciphers, a malicious participant could just
178 as easily post all the VPN traffic he receives on a website, so it
179 really doesn't improve security at all.
183 > *- Don't use the same key for encryption and authentication.*
185 Nowhere in the authentication protocol does this happen.
187 > *- 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).*
189 This is a valid point. Tinc can easily be changed to use keys
190 composed of what both sides send, for example by using the
191 Diffie-Helman scheme. This is planned for tinc 2.0.
193 > *- Provide message freshness guarantees (and, if possible, some form of PFS).*
195 Currently only the UDP packets sent by tinc have PFS, but this is
196 not true for the TCP connections (the meta protocol). This will be
197 resolved in tinc 2.0.
199 > *- Bind the identity of the principals to the authentication.*
201 The authentication is done using RSA encryption, the RSA keys are
202 directly bound to the identities of the tinc daemons.
204 > *- Don't use the same messages in both directions.*
206 Tinc doesn't send the same messages, it sends the same *kinds* of
209 > *- Don't act as an oracle for an attacker.*
211 Apart from possibly being susceptible to a timing attack, we don't
212 believe, and Peter Gutmann has not convinced us, that tinc can be
213 used as any other kind of oracle.
215 > *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.*
217 I think this holds for virtually all cryptographic handshake
222 > *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.*
224 Although security can only be proven by time and peer review, the
225 lack of some people noticing certain software applications does not
226 have a direct relation to their security. The fact that Peter
227 Gutmann only examined three specific Open Source VPN products does
228 not say anything about the security of other products.
230 > *It's possible to create insecure "security" products just as readily with open-source as with closed-source software.*
232 I don't think anyone disagrees with that.
234 > *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.*
236 Microsoft sells its products as being secure, and the people who
237 buy its products have expectations. But not everyone is out there
238 to make software that is as secure as possible, VTun even mentions
239 it is not intended to be secure, and CIPE focuses more on usability
242 > *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.*
244 Development of CIPE, VTun and tinc has started in times when SSH,
245 SSL and IPsec were nowhere as popular as they are now. We certainly
246 never claimed we created tinc in reaction to those protocols.
247 Furthermore, SSL and SSH are reliable stream based protocols,
248 unsuitable for VPNs which work best with unreliable datagrams,
249 hence it wouldn't have been an obvious choice to use SSH or SSL in
250 the first place. Both SSL and SSH have had their security problems
251 in the past (and in the case of OpenSSH, even in the recent past),
252 emphasizing that even these widely used and scrutinised protocols
253 are not as perfect as Peter Gutmann would let us believe.
254 Apart from that, there is no reason why people shouldn't create new
255 protocols, which might in time become just as strong or even
256 stronger. Even great names as Ron Rivest didn't get it right the
259 > *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.*
261 A very professional and constructive argument.
263 > *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.*
265 We have no obligation to justify anything we do. We also do not
266 believe SSL is the be-all, end-all of cryptography.
projects / wiki / blob