From 8d307c2fbf2c20eb53909f74c81e03db838fb55e Mon Sep 17 00:00:00 2001 From: Guus Sliepen Date: Fri, 25 May 2001 18:57:37 +0000 Subject: [PATCH] Fix sample configuration to show keys in PEM format and correct tapdevice. --- doc/SECURITY | 151 ------------------------------ doc/sample-config/hosts/alpha | 6 +- doc/sample-config/hosts/alpha.key | 1 - doc/sample-config/hosts/beta | 6 +- doc/sample-config/hosts/beta.key | 1 - doc/sample-config/tinc-down | 2 +- doc/sample-config/tinc-up | 4 +- 7 files changed, 11 insertions(+), 160 deletions(-) delete mode 100644 doc/SECURITY delete mode 100644 doc/sample-config/hosts/alpha.key delete mode 100644 doc/sample-config/hosts/beta.key diff --git a/doc/SECURITY b/doc/SECURITY deleted file mode 100644 index 670135c7..00000000 --- a/doc/SECURITY +++ /dev/null @@ -1,151 +0,0 @@ -This is the security documentation for tinc, a Virtual Private Network daemon. - - Copyright 2000,2001 Guus Sliepen , - 2000,2001 Ivo Timmmermans - - Permission is granted to make and distribute verbatim copies of - this documentation provided the copyright notice and this - permission notice are preserved on all copies. - - Permission is granted to copy and distribute modified versions of - this documentation under the conditions for verbatim copying, - provided that the entire resulting derived work is distributed - under the terms of a permission notice identical to this one. - - $Id: SECURITY,v 1.1.2.4 2001/01/07 17:08:03 guus Exp $ - - -1. Authentication ------------------- - -The authentication protocol (see protocol.c for the up-to-date version) is: - - Client Server - send_id(u) - send_challenge(R) - send_chal_reply(H) - send_id(u) - send_challenge(R) - send_chal_reply(H) - send_metakey(R) - send_metakey(R) - send_ack(u) - send_ack(u) - --------------------------------------- - Other requests(E)... - - (u) Unencrypted, - (R) RSA, - (H) SHA1, - (E) Encrypted with symmetric cipher. - -See section 4 for a detailed example version of the authentication. - -Authentication in tinc will be done in a way that is very similar to the way -the SSH (Secure SHell) authentication protocol works. It is based on public -key cryptography. - -Every tinc host has its own public/private key pair. Suppose there are two -tinc hosts, A and B. If A and B trust each other, they store a copy of -eachothers public key (in the same way passphrases were stored in versions -of tinc <= 1.0pre2). They know these public keys beforehand, and the origin -of the public keys has to be known for sure. - -To make sure that when a connection is made from A to B that B knows A is -really who he claims to be, B encrypts a totally random string of bytes with -A's public key. B also calculates the hash value from the unencrypted random -string. B then sends the encrypted string to A. A then has to decrypt the -string, calculate the hash value from that string and send it back to B. Since -only he who possesses A's private key can decrypt this string, only he can send -back the correct hash value. So, if B receives the same hash value he -calculated himself, he knows for sure A is A. - -Both SSH and tinc use RSA for the public key cryptography. SSH uses MD5 as a -secure hash algorithm, tinc uses SHA1. The reason for our choice of SHA1 is -the fact that SHA1 is 160 bits instead of 128 (MD5), which makes brute force -attacks harder. Also, the OpenSSL documentation recommends SHA1. - -2. Key exchange ----------------- - -The rest of the meta connection in tinc will be encrypted with a symmetric -block cipher, since RSA is not really suited for this. When a connection is -made, both sides have to agree on a key for this block cipher. To make sure -that this key exchange is also done securely, and no man-in-the-middle attack -is possible, RSA would be the best choice for exchanging keys. - -3. Symmetric cipher --------------------- - -Since the generalized encryption functions of OpenSSL are used, any symmetric -cipher that is available in OpenSSL could possibly be used. The default however -will be Blowfish. Blowfish is widely in use and still has not been cracked -today (as far as we know). It also is one of the faster ciphers available. - -4. Detailed "example" of communication ---------------------------------------- - -Tinc uses a peer-to-peer protocol, but during the authentication phase we will -make a distinction between a server (a tinc daemon listening for incoming -connections) and a client (a tinc daemon that is trying to connect to the tinc -daemon playing server). - -The message strings here are kept short for clarity. The real length of the -exchanged messages is indicated. The capital words ID, CHALLENGE, CHAL_REPLY, -META_KEY and ACK are in reality replaced by the numbers 0, 1, 2, 3 and 4 -respectively. - -daemon message --------------------------------------------------------------------------- -server -client -server -client ID client 8 0 - | | +-> options - | +---> version - +-------> name of tinc daemon -server CHALLENGE 57fb4b2ccd70d6bb35a64c142f47e61d - \______________________________/ - +-> KEYLENGTH bits totally random string, encrypted - with client's public RSA key -client CHAL_REPLY 191e23 - +-> 160 bits SHA1 value of the complete decrypted - CHALLENGE sent by the server -server ID server 8 0 - | | +-> options - | +---> version - +-------> name of tinc daemon -client CHALLENGE da02add1817c1920989ba6ae2a49cecb - \______________________________/ - +-> KEYLENGTH bits totally random string, encrypted - with server's public RSA key -server CHAL_REPLY 2bdeed - +-> 160 bits SHA1 value of the complete decrypted - CHALLENGE sent by the client -client META_KEY 5f0823a93e35b69e7086ec7866ce582b - \______________________________/ - +-> KEYLENGTH bits totally random string, encrypted - with server's public RSA key -server META_KEY 6ab9c1640388f8f045d1a07f8a672630 - \______________________________/ - +-> KEYLENGTH bits totally random string, encrypted - with client's public RSA key -client ACK -server ACK --------------------------------------------------------------------------- - -When the server receives the ACK from the client, it should prepare itself -for the fact that any subsequent data will be encrypted with the key the server -sent itself in the META_KEY. Ofcourse, this key is taken from the decrypted -version of that META_KEY, so that we will know for sure only the real client -can send us messages. The same goes for the client when it receives an ACK. - -5. Encryption of VPN packets ------------------------------ - -The VPN packets are also encrypted, but with a different key than the one used -for the meta connection. The reason is that VPN packets can also come from -other clients which do not have a meta connection with server. Each tinc daemon -propagates (on request) a separate key for packets that it receives. This key -is a random string, generated on the fly. Since it is exchanged using the meta -connection, this key itself will be encrypted. diff --git a/doc/sample-config/hosts/alpha b/doc/sample-config/hosts/alpha index 95315e1f..0f5e56a9 100644 --- a/doc/sample-config/hosts/alpha +++ b/doc/sample-config/hosts/alpha @@ -9,5 +9,7 @@ Port = 655 # Subnet on the virtual private network that is local for this host. Subnet = 192.168.1.0/24 -# The file in which the public key for this host is stored. Required. -PublicKeyFile = /etc/tinc/example/hosts/alpha.key +# The public key generated by `tincd -n example -K' is stored here +-----BEGIN RSA PUBLIC KEY----- +... +-----END RSA PUBLIC KEY----- diff --git a/doc/sample-config/hosts/alpha.key b/doc/sample-config/hosts/alpha.key deleted file mode 100644 index ac135363..00000000 --- a/doc/sample-config/hosts/alpha.key +++ /dev/null @@ -1 +0,0 @@ -# Generate this file with `tincd -n example -K` diff --git a/doc/sample-config/hosts/beta b/doc/sample-config/hosts/beta index 9e357b22..6f70d4f7 100644 --- a/doc/sample-config/hosts/beta +++ b/doc/sample-config/hosts/beta @@ -10,5 +10,7 @@ Port = 6500 # Subnet on the virtual private network that is local for this host. Subnet = 192.168.2.0/24 -# The file in which the public key for this host is stored. Required. -PublicKeyFile = /etc/tinc/example/hosts/beta.key +# The public key generated by `tincd -n example -K' is stored here +-----BEGIN RSA PUBLIC KEY----- +... +-----END RSA PUBLIC KEY----- diff --git a/doc/sample-config/hosts/beta.key b/doc/sample-config/hosts/beta.key deleted file mode 100644 index 4470b704..00000000 --- a/doc/sample-config/hosts/beta.key +++ /dev/null @@ -1 +0,0 @@ -# This file has not been generated by this host, but by beta. diff --git a/doc/sample-config/tinc-down b/doc/sample-config/tinc-down index 9f3b499d..12749919 100644 --- a/doc/sample-config/tinc-down +++ b/doc/sample-config/tinc-down @@ -4,4 +4,4 @@ # need to do anything; once tinc quits the tap device is already # removed by the kernel. -ifconfig tap0 down +ifconfig tap1 down diff --git a/doc/sample-config/tinc-up b/doc/sample-config/tinc-up index 98df7638..f515e51d 100644 --- a/doc/sample-config/tinc-up +++ b/doc/sample-config/tinc-up @@ -6,9 +6,9 @@ # but for the universal tun/tap device use $NETNAME. # Set hardware ethernet address (required!) -ifconfig tap0 hw ether fe:fd:0:0:0:0 +ifconfig tap1 hw ether fe:fd:0:0:0:0 # Give it the right ip and netmask. Remember, the subnet of the # tap device must be larger than that of the individual Subnets # as defined in the host configuration file! -ifconfig tap0 192.168.1.1 netmask 255.255.0.0 -arp +ifconfig tap1 192.168.1.1 netmask 255.255.0.0 -arp -- 2.39.5