Next: Simple Peer-to-Peer Security, Up: Security [Contents][Index]
daemon message
--------------------------------------------------------------------------
client <attempts connection>
server <accepts connection>
client ID client 17.2
| | +-> minor protocol version
| +----> major protocol version
+--------> name of tinc daemon
server ID server 17.2
| | +-> minor protocol version
| +----> major protocol version
+--------> name of tinc daemon
client META_KEY 94 64 0 0 5f0823a93e35b69e...7086ec7866ce582b
| | | | \_________________________________/
| | | | +-> RSAKEYLEN bits totally random string S1,
| | | | encrypted with server's public RSA key
| | | +-> compression level
| | +---> MAC length
| +------> digest algorithm NID
+---------> cipher algorithm NID
server META_KEY 94 64 0 0 6ab9c1640388f8f0...45d1a07f8a672630
| | | | \_________________________________/
| | | | +-> RSAKEYLEN bits totally random string S2,
| | | | encrypted with client's public RSA key
| | | +-> compression level
| | +---> MAC length
| +------> digest algorithm NID
+---------> cipher algorithm NID
--------------------------------------------------------------------------
The protocol allows each side to specify encryption algorithms and parameters, but in practice they are always fixed, since older versions of tinc did not allow them to be different from the default values. The cipher is always Blowfish in OFB mode, the digest is SHA1, but the MAC length is zero and no compression is used.
From now on:
--------------------------------------------------------------------------
client CHALLENGE da02add1817c1920989ba6ae2a49cecbda0
\_________________________________/
+-> CHALLEN bits totally random string H1
server CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d57f
\_________________________________/
+-> CHALLEN bits totally random string H2
client CHAL_REPLY 816a86
+-> 160 bits SHA1 of H2
server CHAL_REPLY 928ffe
+-> 160 bits SHA1 of H1
After the correct challenge replies are received, both ends have proved
their identity. Further information is exchanged.
client ACK 655 123 0
| | +-> options
| +----> estimated weight
+--------> listening port of client
server ACK 655 321 0
| | +-> options
| +----> estimated weight
+--------> listening port of server
--------------------------------------------------------------------------
This legacy authentication protocol has several weaknesses, pointed out by security export Peter Gutmann. First, data is encrypted with 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. Tinc always encrypts random nonces that have the same size as the RSA key, so we do not believe this leads to a break of the security. There might be timing or other side-channel attacks against RSA encryption and decryption, tinc does not employ any protection against those. Furthermore, both sides send identical messages to each other, there is no distinction between server and client, which could make a MITM attack easier. However, no exploit is known in which a third party who is not already trusted by other nodes in the VPN could gain access. Finally, the RSA keys are used to directly encrypt the session keys, which means that if the RSA keys are compromised, it is possible to decrypt all previous VPN traffic. In other words, the legacy protocol does not provide perfect forward secrecy.
Next: Simple Peer-to-Peer Security, Up: Security [Contents][Index]