www.tinc-vpn.org Git - wiki/blob - security.mdwn

   1 ## Possible weak keys generated by tinc on Debian (and derivates) due to a security bug in Debian's OpenSSL packages
   2
   3 For those who run tinc on Debian or Debian-based distributions like
   4 Ubuntu and Knoppix, be advised that the following security issue
   5 affects tinc as well:
   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
  12 restart tinc.
  13
  14 If you have compiled a static version of tinc on an affected
  15 platform, you need to recompile tinc to ensure it is statically
  16 linked with a fixed OpenSSL library.
  17
  18 I do not know if the session keys also have been weak, but it is
  19 best to assume they were. If you exchanged private key material via
  20 your tinc VPN, then an eavesdropper may have seen seen this as
  21 well. Regenerate any keying material that you have exchanged via
  22 your tinc VPN if any of the nodes was running on an affected
  23 platform.
  24
  25 ## Security issues in tinc
  26
  27 Although tinc uses the OpenSSL library, it does not use the SSL protocol
  28 to establish connections between daemons. The reasons for this were:
  29
  30 - When tinc was created, SSL 3.0 was only just gaining popularity for use outside web browsers and servers.
  31 - SSL at that time did not make it easy to have both sides of the connection authenticate each other.
  32 - 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.
  33
  34 When tinc 1.0 was released, the protocol used was declared stable and would not change anymore.
  35 However, since then some weaknesses were found, mainly by Peter Gutmann in 2003.
  36 René Korthaus, Andreas Hübner, Felix Stein and Wladimir Paulsen have also looked at tinc's protocol recently,
  37 and have provided a more in-depth analysis of the most critical weaknesses.
  38 In the interest of full disclosure we will list the known weaknesses below.
  39
  40 For tinc 2.0 and later we will use a standard protocol like SSH or TLS to perform authentication.
  41 For the encapsulated packets, we will consider protocols like DTLS, but due to the specific needs of a peer-to-peer VPN,
  42 we might also keep our own protocol, but update it to current security standards.
  43 We might also release an interim version that just fixes the vulnerabilities in tinc 1.x in the near future.
  44
  45 ### Predictable IV
  46
  47 When encrypting UDP packets, tinc uses the CBC block cipher mode with a 32-bit counter as the IV.
  48 This was chosen to avoid the overhead of a full random IV for every packet.
  49 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.
  50
  51 ### Truncated MAC
  52
  53 By default, tinc uses a HMAC to authenticate packets that is trunctated to 32 bits.
  54 This default was chosed to avoid the overhead of a full 160 bit hash for every packet.
  55 An attacker on a high-speed network connection could inject a forged packet by sending it 2^31 times on average with different HMACs.
  56 It is possible to change the strength of the HMAC with the `MACLength` option.
  57 We will change the default length in the future.
  58
  59 ### Use of RSA
  60
  61 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.
  62 However, tinc always encrypts random numbers that have the same size as the RSA key,
  63 which should safe.
  64
  65 There are timing attacks against RSA.
  66 Tinc does not protect against those.
  67
  68 ### Authentication protocol
  69
  70 Tinc uses RSA encryption to send symmetric cipher keys to its peer.
  71 Then, a challenge/response exchange is done to verify that each peer indeed has the private key.
  72 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.
  73 The MITM cannot decrypt messages between peers,
  74 but it can send messages to the peer that initiated the connection.
  75 If the MITM knows enough about the VPN, it could trick peers into sending it packets that it can decrypt.
  76 However, the MITM cannot send packets to other peers.