No description
Encryption and authentication of the meta connection is spread out over meta.c and protocol_auth.c. The new protocol was added there as well, leading to spaghetti code. To improve things, the new protocol will now be implemented in sptps.[ch]. The goal is to have a very simplified version of TLS. There is a record layer, and there are only two record types: application data and handshake messages. The handshake message contains a random nonce, an ephemeral ECDH public key, and an ECDSA signature over the former. After the ECDH public keys are exchanged, a shared secret is calculated, and a TLS style PRF is used to generate the key material for the cipher and HMAC algorithm, and further communication is encrypted and authenticated. A lot of the simplicity comes from the fact that both sides must have each other's public keys in advance, and there are no options to choose. There will be one fixed cipher suite, and both peers always authenticate each other. (Inspiration taken from Ian Grigg's hypotheses[0].) There might be some compromise in the future, to enable or disable encryption, authentication and compression, but there will be no choice of algorithms. This will allow SPTPS to be built with a few embedded crypto algorithms instead of linking with huge crypto libraries. The API is also kept simple. There is a start and a stop function. All data necessary to make the connection work is passed in the start function. Instead having both send- and receive-record functions, there is a send-record function and a receive-data function. The latter will pass protocol data received from the peer to the SPTPS implementation, which will in turn call a receive-record callback function when necessary. This hides all the handshaking from the application, and is completely independent from any event loop or socket characteristics. [0] http://iang.org/ssl/hn_hypotheses_in_secure_protocol_design.html |
||
---|---|---|
doc | ||
gui | ||
m4 | ||
po | ||
src | ||
AUTHORS | ||
configure.in | ||
COPYING | ||
COPYING.README | ||
have.h | ||
Makefile.am | ||
NEWS | ||
README | ||
README.git | ||
system.h | ||
THANKS |
This is the README file for tinc version 1.1pre2. Installation instructions may be found in the INSTALL file. tinc is Copyright (C) 1998-2011 by: Ivo Timmermans, Guus Sliepen <guus@tinc-vpn.org>, and others. For a complete list of authors see the AUTHORS file. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. See the file COPYING for more details. This is a pre-release --------------------- Please note that this is NOT a stable release. Until version 1.1.0 is released, please use one of the 1.0.x versions if you need a stable version of tinc. Although tinc 1.1 will be protocol compatible with tinc 1.0.x, the functionality of the tincctl program may still change, and the control socket protocol is not fixed yet. Security statement ------------------ This version uses an experimental and unfinished cryptographic protocol. Use it at your own risk. Compatibility ------------- Version 1.1pre2 is compatible with 1.0pre8, 1.0 and later, but not with older versions of tinc. When the ExperimentalProtocol option is used, tinc is still compatible with 1.0.X and 1.1pre2 itself, but not with any other 1.1preX version. Requirements ------------ Either OpenSSL (http://www.openssl.org/) or libgcrypt (http://www.gnupg.org/download/#libgcrypt). The zlib library is used for optional compression. You can find it at http://www.gzip.org/zlib/. The lzo library is also used for optional compression. You can find it at http://www.oberhumer.com/opensource/lzo/. Since 1.1, the libevent library is used for the main event loop. You can find it at http://monkey.org/~provos/libevent/. In order to compile tinc, you will need a GNU C compiler environment. Please ensure you have the latest stable versions of all the required libraries. Features -------- This version of tinc supports multiple virtual networks at once. To use this feature, you may supply a netname via the -n or --net options. The standard locations for the config files will then be /etc/tinc/<net>/. tincd regenerates its encryption key pairs. It does this on the first activity after the keys have expired. This period is adjustable in the configuration file, and the default time is 3600 seconds (one hour). This version supports multiple subnets at once. They are also sorted on subnet mask size. This means that it is possible to have overlapping subnets on the VPN, as long as their subnet mask sizes differ. Since pre5, tinc can operate in several routing modes. The default mode, "router", works exactly like the older version, and uses Subnet lines to determine the destination of packets. The other two modes, "switch" and "hub", allow the tinc daemons to work together like a single network switch or hub. This is useful for bridging networks. The latter modes only work properly on Linux, FreeBSD and Windows. The algorithms used for encryption and generating message authentication codes can now be changed in the configuration files. All cipher and digest algorithms supported by OpenSSL can be used. Useful ciphers are "blowfish" (default), "bf-ofb", "des", "des3", etcetera. Useful digests are "sha1" (default), "md5", etcetera. Support for routing IPv6 packets has been added. Just add Subnet lines with IPv6 addresses (without using :: abbreviations) and use ifconfig or ip (from the iproute package) to give the virtual network interface corresponding IPv6 addresses. tinc does not provide autoconfiguration for IPv6 hosts, if you need it use radvd or zebra. It is also possible to make tunnels to other tinc daemons over IPv6 networks, if the operating system supports IPv6. tinc will automatically use both IPv6 and IPv4 when available, but this can be changed by adding the option "AddressFamily = ipv4" or "AddressFamily = ipv6" to the tinc.conf file. Normally, when started tinc will detach and run in the background. In a native Windows environment this means tinc will intall itself as a service, which will restart after reboots. To prevent tinc from detaching or running as a service, use the -D option.