Next: Simple Peer-to-Peer Security, Up: Security [Contents][Index]

#### 7.3.1 Legacy authentication protocol

    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:

- the client will symmetrically encrypt outgoing traffic using S1
- the server will symmetrically encrypt outgoing traffic using S2

    --------------------------------------------------------------------------
    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]