]> git.meshlink.io Git - meshlink/commitdiff
Fix sample configuration to show keys in PEM format and correct tapdevice.
authorGuus Sliepen <guus@tinc-vpn.org>
Fri, 25 May 2001 18:57:37 +0000 (18:57 +0000)
committerGuus Sliepen <guus@tinc-vpn.org>
Fri, 25 May 2001 18:57:37 +0000 (18:57 +0000)
doc/SECURITY [deleted file]
doc/sample-config/hosts/alpha
doc/sample-config/hosts/alpha.key [deleted file]
doc/sample-config/hosts/beta
doc/sample-config/hosts/beta.key [deleted file]
doc/sample-config/tinc-down
doc/sample-config/tinc-up

diff --git a/doc/SECURITY b/doc/SECURITY
deleted file mode 100644 (file)
index 670135c..0000000
+++ /dev/null
@@ -1,151 +0,0 @@
-This is the security documentation for tinc, a Virtual Private Network daemon.
-
-   Copyright 2000,2001 Guus Sliepen <guus@sliepen.warande.net>,
-             2000,2001 Ivo Timmmermans <itimmermans@bigfoot.com>
-
-   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 <listening for connection>
-client  <tries to connect>
-server  <accepts connection>
-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.
index 95315e1f69e8f445d3f682bf637745aedfc5f9e1..0f5e56a9d2d8b7f41f9d9f0619ff4fb706f8e25d 100644 (file)
@@ -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 (file)
index ac13536..0000000
+++ /dev/null
@@ -1 +0,0 @@
-# Generate this file with `tincd -n example -K`
index 9e357b2244e083f1a0e02408e7181d547d2bba5a..6f70d4f7df9ac88f12904ac34cb8dc1f26376fdd 100644 (file)
@@ -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 (file)
index 4470b70..0000000
+++ /dev/null
@@ -1 +0,0 @@
-# This file has not been generated by this host, but by beta.
index 9f3b499d78f252a8f90a2a021d22d3a11a5a01d0..127499197ef70cf2401e6ea65ee81ad84700e7f3 100644 (file)
@@ -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
index 98df7638143305953cd6a92bfbb3607d7e4469c1..f515e51dacc79bdc113ec84730c3027c622d721a 100644 (file)
@@ -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