Commit graph

5 commits

Author SHA1 Message Date
Guus Sliepen
a1f4f14c6c Defer handling netname conflicts when accepting an invitation.
In case no explicit netname of configuration directory is specified when
accepting an invitation, the netname specified in the invitation data is
used. However, this new netname is only known after making the connection
to the server. If the new netname conflicts with an existing one at the
client, we ask the user for a netname that doesn't conflict. However, we
should first finish accepting the invitation, so we don't run into the
problem that the server times out and cancels the invitation. So, we create
a random netname and store the files there, and only after we finish
accepting the invitation we ask the user for a better netname, and then
just rename the temporary directory to the final name.
2013-07-26 15:48:52 +02:00
Guus Sliepen
d47c79533f Make absolutely sure we can write config files before accepting an invitation. 2013-07-26 15:44:05 +02:00
Guus Sliepen
37cca72e6c Choose a different Port when 655 isn't available when doing "tinc join". 2013-07-26 14:53:36 +02:00
Guus Sliepen
d6a67266c8 Don't forget the Port variable when creating an invitation URL. 2013-07-25 17:30:47 +02:00
Guus Sliepen
ced4c1a327 Add an invitation protocol.
Using the tinc command, an administrator of an existing VPN can generate
invitations for new nodes. The invitation is a small URL that can easily
be copy&pasted into email or live chat. Another person can have tinc
automatically setup the necessary configuration files and exchange keys
with the server, by only using the invitation URL.

The invitation protocol uses temporary ECDSA keys. The invitation URL
consists of the hostname and port of the server, a hash of the server's
temporary ECDSA key and a cookie. When the client wants to accept an
invitation, it also creates a temporary ECDSA key, connects to the server
and says it wants to accept an invitation. Both sides exchange their
temporary keys. The client verifies that the server's key matches the hash
in the invitation URL. After setting up an SPTPS connection using the
temporary keys, the client gives the cookie to the server. If the cookie
is valid, the server sends the client an invitation file containing the
client's new name and a copy of the server's host config file. If everything
is ok, the client will generate a long-term ECDSA key and send it to the
server, which will add it to a new host config file for the client.

The invitation protocol currently allows multiple host config files to be
send from the server to the client. However, the client filters out
most configuration variables for its own host configuration file. In
particular, it only accepts Name, Mode, Broadcast, ConnectTo, Subnet and
AutoConnect. Also, at the moment no tinc-up script is generated.

When an invitation has succesfully been accepted, the client needs to start
the tinc daemon manually.
2013-05-29 18:31:10 +02:00