j3d1/tinc
1
0
Fork 0
Code Issues 1 Pull requests Releases Wiki Activity
tinc/src/sptps_test.c

390 lines
9.5 KiB
C
Raw Permalink Normal View History

Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
/*
sptps_test.c -- Simple Peer-to-Peer Security test program
Use void pointers for opaque data blobs in the SPTPS code.
2014-12-24 21:15:40 +00:00
Copyright (C) 2011-2014 Guus Sliepen <guus@tinc-vpn.org>
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
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.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License along
with this program; if not, write to the Free Software Foundation, Inc.,
51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
#include "system.h"
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
#ifdef HAVE_LINUX
#include <linux/if_tun.h>
#endif
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
#include <getopt.h>
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
#include "crypto.h"
#include "ecdsa.h"
#include "sptps.h"
#include "utils.h"
Allow log messages to be captured by tincctl. This allows tincctl to receive log messages from a running tincd, independent of what is logged to syslog or to file. Tincctl can receive debug messages with an arbitrary level.
2012-02-26 17:37:36 +00:00
// Symbols necessary to link with logger.o
Ensure sptps_test compiles with -flto.
2012-09-13 19:35:29 +00:00
bool send_request(void *c, const char *msg, ...) { return false; }
Replace the connection_tree with a connection_list. The tree functions were never used on the connection_tree, a list is more appropriate. Also be more paranoid about connections disappearing while traversing the list.
2012-10-07 19:59:53 +00:00
struct list_t *connection_list = NULL;
Ensure sptps_test compiles with -flto.
2012-09-13 19:35:29 +00:00
bool send_meta(void *c, const char *msg , int len) { return false; }
Make sure sptps_test compiles without -flto.
2012-10-01 08:36:23 +00:00
char *logfilename = NULL;
Don't write log messages to the umbilical pipe if we don't detach. If we run in the foreground and are started by the CLI, this would otherwise cause the first few log messages to appear twice.
2015-05-20 19:25:06 +00:00
bool do_detach = false;
Drop libevent and use our own event handling again. There are several reasons for this: - MacOS/X doesn't support polling the tap device using kqueue, requiring a workaround to fall back to select(). - On Windows only sockets are properly handled, therefore tinc uses a second thread that does a blocking ReadFile() on the TAP-Win32/64 device. However, this does not mix well with libevent. - Libevent, event just the core, is quite large, and although it is easy to get and install on many platforms, it can be a burden. - Libev is more lightweight and seems technically superior, but it doesn't abstract away all the platform differences (for example, async events are not supported on Windows).
2012-11-29 11:28:23 +00:00
struct timeval now;
Allow log messages to be captured by tincctl. This allows tincctl to receive log messages from a running tincd, independent of what is logged to syslog or to file. Tincctl can receive debug messages with an arbitrary level.
2012-02-26 17:37:36 +00:00
Handle special characters in sptps_test only if the --special option is given. sptps_test treats lines starting with #, ^ and $ specially, in order to test the SPTPS protocol. However, this should only be done if explicitly requested, otherwise it can unexpectedly fail.
2016-04-17 14:01:49 +00:00
static bool special;
Make sptps_test less verbose by default.
2013-10-22 19:19:41 +00:00
static bool verbose;
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
static bool readonly;
static bool writeonly;
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
static int in = 0;
static int out = 1;
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
Use void pointers for opaque data blobs in the SPTPS code.
2014-12-24 21:15:40 +00:00
static bool send_data(void *handle, uint8_t type, const void *data, size_t len) {
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
char hex[len * 2 + 1];
Marked all unsued parameters found by -Werror=unused-parameter with UNUSED()
2015-07-02 16:37:08 +00:00
UNUSED(type);
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
bin2hex(data, hex, len);
Make sptps_test less verbose by default.
2013-10-22 19:19:41 +00:00
if(verbose)
fprintf(stderr, "Sending %d bytes of data:\n%s\n", (int)len, hex);
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
const int *sock = handle;
if(send(*sock, data, len, 0) != len)
return false;
return true;
}
Use void pointers for opaque data blobs in the SPTPS code.
2014-12-24 21:15:40 +00:00
static bool receive_record(void *handle, uint8_t type, const void *data, uint16_t len) {
Marked all unsued parameters found by -Werror=unused-parameter with UNUSED()
2015-07-02 16:37:08 +00:00
UNUSED(handle);
Make sptps_test less verbose by default.
2013-10-22 19:19:41 +00:00
if(verbose)
fprintf(stderr, "Received type %d record of %hu bytes:\n", type, len);
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
if(!writeonly)
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
write(out, data, len);
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return true;
}
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
static struct option const long_options[] = {
{"datagram", no_argument, NULL, 'd'},
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
{"quit", no_argument, NULL, 'q'},
{"readonly", no_argument, NULL, 'r'},
{"writeonly", no_argument, NULL, 'w'},
{"packet-loss", required_argument, NULL, 'L'},
{"replay-window", required_argument, NULL, 'W'},
Handle special characters in sptps_test only if the --special option is given. sptps_test treats lines starting with #, ^ and $ specially, in order to test the SPTPS protocol. However, this should only be done if explicitly requested, otherwise it can unexpectedly fail.
2016-04-17 14:01:49 +00:00
{"special", no_argument, NULL, 's'},
Make sptps_test less verbose by default.
2013-10-22 19:19:41 +00:00
{"verbose", required_argument, NULL, 'v'},
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
{"help", no_argument, NULL, 1},
{NULL, 0, NULL, 0}
};
Make sptps_speed and sptps_test compile TODO: tests do not work
2015-06-30 20:49:11 +00:00
static const char *program_name;
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
static void usage() {
Rename ECDSA to Ed25519.
2014-05-18 18:47:04 +00:00
fprintf(stderr, "Usage: %s [options] my_ed25519_key_file his_ed25519_key_file [host] port\n\n", program_name);
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
fprintf(stderr, "Valid options are:\n"
" -d, --datagram Enable datagram mode.\n"
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
" -q, --quit Quit when EOF occurs on stdin.\n"
" -r, --readonly Only send data from the socket to stdout.\n"
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
#ifdef HAVE_LINUX
" -t, --tun Use a tun device instead of stdio.\n"
#endif
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
" -w, --writeonly Only send data from stdin to the socket.\n"
" -L, --packet-loss RATE Fake packet loss of RATE percent.\n"
" -R, --replay-window N Set replay window to N bytes.\n"
Handle special characters in sptps_test only if the --special option is given. sptps_test treats lines starting with #, ^ and $ specially, in order to test the SPTPS protocol. However, this should only be done if explicitly requested, otherwise it can unexpectedly fail.
2016-04-17 14:01:49 +00:00
" -s, --special Enable special handling of lines starting with #, ^ and $.\n"
Make sptps_test less verbose by default.
2013-10-22 19:19:41 +00:00
" -v, --verbose Display debug messages.\n"
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
"\n");
fprintf(stderr, "Report bugs to tinc@tinc-vpn.org.\n");
}
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
int main(int argc, char *argv[]) {
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
program_name = argv[0];
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
bool initiator = false;
Add datagram mode to the SPTPS protocol. * Everything is identical except the headers of the records. * Instead of sending explicit message length and having an implicit sequence number, datagram mode has an implicit message length and an explicit sequence number. * The sequence number is used to set the most significant bytes of the counter.
2012-03-18 15:42:02 +00:00
bool datagram = false;
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
#ifdef HAVE_LINUX
bool tun = false;
#endif
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
int packetloss = 0;
int r;
int option_index = 0;
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
ecdsa_t *mykey = NULL, *hiskey = NULL;
bool quit = false;
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
Handle special characters in sptps_test only if the --special option is given. sptps_test treats lines starting with #, ^ and $ specially, in order to test the SPTPS protocol. However, this should only be done if explicitly requested, otherwise it can unexpectedly fail.
2016-04-17 14:01:49 +00:00
while((r = getopt_long(argc, argv, "dqrstwL:W:v", long_options, &option_index)) != EOF) {
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
switch (r) {
case 0: /* long option */
break;
case 'd': /* datagram mode */
datagram = true;
break;
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
case 'q': /* close connection on EOF from stdin */
quit = true;
break;
case 'r': /* read only */
readonly = true;
break;
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
case 't': /* read only */
#ifdef HAVE_LINUX
tun = true;
#else
fprintf(stderr, "--tun is only supported on Linux.\n");
usage();
return 1;
#endif
break;
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
case 'w': /* write only */
writeonly = true;
break;
case 'L': /* packet loss rate */
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
packetloss = atoi(optarg);
break;
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
case 'W': /* replay window size */
Allow testing the replay window with sptps_test.
2013-08-30 12:23:02 +00:00
sptps_replaywin = atoi(optarg);
break;
Make sptps_test less verbose by default.
2013-10-22 19:19:41 +00:00
case 'v': /* be verbose */
verbose = true;
break;
Handle special characters in sptps_test only if the --special option is given. sptps_test treats lines starting with #, ^ and $ specially, in order to test the SPTPS protocol. However, this should only be done if explicitly requested, otherwise it can unexpectedly fail.
2016-04-17 14:01:49 +00:00
case 's': /* special character handling */
special = true;
break;
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
case '?': /* wrong options */
usage();
return 1;
case 1: /* help */
usage();
return 0;
default:
break;
}
Add datagram mode to the SPTPS protocol. * Everything is identical except the headers of the records. * Instead of sending explicit message length and having an implicit sequence number, datagram mode has an implicit message length and an explicit sequence number. * The sequence number is used to set the most significant bytes of the counter.
2012-03-18 15:42:02 +00:00
}
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
argc -= optind - 1;
argv += optind - 1;
if(argc < 4 || argc > 5) {
fprintf(stderr, "Wrong number of arguments.\n");
usage();
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
}
if(argc > 4)
initiator = true;
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
srand(time(NULL));
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
#ifdef HAVE_LINUX
if(tun) {
in = out = open("/dev/net/tun", O_RDWR | O_NONBLOCK);
if(in < 0) {
fprintf(stderr, "Could not open tun device: %s\n", strerror(errno));
return 1;
}
struct ifreq ifr = {
.ifr_flags = IFF_TUN
};
if(ioctl(in, TUNSETIFF, &ifr)) {
fprintf(stderr, "Could not configure tun interface: %s\n", strerror(errno));
return 1;
}
ifr.ifr_name[IFNAMSIZ - 1] = 0;
fprintf(stderr, "Using tun interface %s\n", ifr.ifr_name);
}
#endif
Make sure tinc compiles on Windows.
2012-07-21 10:51:53 +00:00
#ifdef HAVE_MINGW
static struct WSAData wsa_state;
if(WSAStartup(MAKEWORD(2, 2), &wsa_state))
return 1;
#endif
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
struct addrinfo *ai, hint;
memset(&hint, 0, sizeof hint);
hint.ai_family = AF_UNSPEC;
Use UDP when using sptps_test in datagram mode.
2013-02-22 14:37:48 +00:00
hint.ai_socktype = datagram ? SOCK_DGRAM : SOCK_STREAM;
hint.ai_protocol = datagram ? IPPROTO_UDP : IPPROTO_TCP;
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
hint.ai_flags = initiator ? 0 : AI_PASSIVE;
Fix whitespace.
2012-10-10 15:17:49 +00:00
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
if(getaddrinfo(initiator ? argv[3] : NULL, initiator ? argv[4] : argv[3], &hint, &ai) || !ai) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "getaddrinfo() failed: %s\n", sockstrerror(sockerrno));
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
}
Use UDP when using sptps_test in datagram mode.
2013-02-22 14:37:48 +00:00
int sock = socket(ai->ai_family, ai->ai_socktype, ai->ai_protocol);
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
if(sock < 0) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "Could not create socket: %s\n", sockstrerror(sockerrno));
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
}
int one = 1;
setsockopt(sock, SOL_SOCKET, SO_REUSEADDR, (void *)&one, sizeof one);
if(initiator) {
if(connect(sock, ai->ai_addr, ai->ai_addrlen)) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "Could not connect to peer: %s\n", sockstrerror(sockerrno));
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
}
fprintf(stderr, "Connected\n");
} else {
if(bind(sock, ai->ai_addr, ai->ai_addrlen)) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "Could not bind socket: %s\n", sockstrerror(sockerrno));
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
}
Use UDP when using sptps_test in datagram mode.
2013-02-22 14:37:48 +00:00
if(!datagram) {
if(listen(sock, 1)) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "Could not listen on socket: %s\n", sockstrerror(sockerrno));
Use UDP when using sptps_test in datagram mode.
2013-02-22 14:37:48 +00:00
return 1;
}
fprintf(stderr, "Listening...\n");
sock = accept(sock, NULL, NULL);
if(sock < 0) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "Could not accept connection: %s\n", sockstrerror(sockerrno));
Use UDP when using sptps_test in datagram mode.
2013-02-22 14:37:48 +00:00
return 1;
}
} else {
fprintf(stderr, "Listening...\n");
char buf[65536];
struct sockaddr addr;
socklen_t addrlen = sizeof addr;
if(recvfrom(sock, buf, sizeof buf, MSG_PEEK, &addr, &addrlen) <= 0) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "Could not read from socket: %s\n", sockstrerror(sockerrno));
Use UDP when using sptps_test in datagram mode.
2013-02-22 14:37:48 +00:00
return 1;
}
if(connect(sock, &addr, addrlen)) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "Could not accept connection: %s\n", sockstrerror(sockerrno));
Use UDP when using sptps_test in datagram mode.
2013-02-22 14:37:48 +00:00
return 1;
}
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
}
fprintf(stderr, "Connected\n");
}
crypto_init();
FILE *fp = fopen(argv[1], "r");
Fix segfault when sptps_test cannot open the key files.
2015-01-11 00:52:37 +00:00
if(!fp) {
fprintf(stderr, "Could not open %s: %s\n", argv[1], strerror(errno));
return 1;
}
Use conditional compilation for cryptographic functions. This gets rid of the rest of the symbolic links. However, as a consequence, the crypto header files have now moved to src/, and can no longer contain library-specific declarations. Therefore, cipher_t, digest_t, ecdh_t, ecdsa_t and rsa_t are now all opaque types, and only pointers to those types can be used.
2013-05-01 15:17:22 +00:00
if(!(mykey = ecdsa_read_pem_private_key(fp)))
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
fclose(fp);
fp = fopen(argv[2], "r");
Fix segfault when sptps_test cannot open the key files.
2015-01-11 00:52:37 +00:00
if(!fp) {
fprintf(stderr, "Could not open %s: %s\n", argv[2], strerror(errno));
return 1;
}
Use conditional compilation for cryptographic functions. This gets rid of the rest of the symbolic links. However, as a consequence, the crypto header files have now moved to src/, and can no longer contain library-specific declarations. Therefore, cipher_t, digest_t, ecdh_t, ecdsa_t and rsa_t are now all opaque types, and only pointers to those types can be used.
2013-05-01 15:17:22 +00:00
if(!(hiskey = ecdsa_read_pem_public_key(fp)))
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
fclose(fp);
Make sptps_test less verbose by default.
2013-10-22 19:19:41 +00:00
if(verbose)
fprintf(stderr, "Keys loaded\n");
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
sptps_t s;
Add datagram mode to the SPTPS protocol. * Everything is identical except the headers of the records. * Instead of sending explicit message length and having an implicit sequence number, datagram mode has an implicit message length and an explicit sequence number. * The sequence number is used to set the most significant bytes of the counter.
2012-03-18 15:42:02 +00:00
if(!sptps_start(&s, &sock, initiator, datagram, mykey, hiskey, "sptps_test", 10, send_data, receive_record))
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
while(true) {
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
if(writeonly && readonly)
break;
Test corner cases in the SPTPS protocol. * Test zero-byte messages. * Test maximum size (65535 byte) messages. * Test different message types. * Test key renegotiation.
2011-10-05 20:05:13 +00:00
char buf[65535] = "";
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
Make sure tinc compiles on Windows.
2012-07-21 10:51:53 +00:00
fd_set fds;
FD_ZERO(&fds);
#ifndef HAVE_MINGW
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
if(!readonly && s.instate)
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
FD_SET(in, &fds);
Make sure tinc compiles on Windows.
2012-07-21 10:51:53 +00:00
#endif
FD_SET(sock, &fds);
if(select(sock + 1, &fds, NULL, NULL, NULL) <= 0)
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
sptps_test: allow using a tun device instead of stdio.
2014-04-15 15:26:08 +00:00
if(FD_ISSET(in, &fds)) {
ssize_t len = read(in, buf, sizeof buf);
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
if(len < 0) {
fprintf(stderr, "Could not read from stdin: %s\n", strerror(errno));
return 1;
}
Make sptps_test more easy to work with. It now defers reading from stdin until after the authentication phase is completed. Furthermore, it supports the -q, -r, -w options similar to those of Jürgen Nickelsen's socket.
2013-09-01 14:02:49 +00:00
if(len == 0) {
if(quit)
break;
readonly = true;
continue;
}
Handle special characters in sptps_test only if the --special option is given. sptps_test treats lines starting with #, ^ and $ specially, in order to test the SPTPS protocol. However, this should only be done if explicitly requested, otherwise it can unexpectedly fail.
2016-04-17 14:01:49 +00:00
if(special && buf[0] == '#')
Allow testing the replay window with sptps_test.
2013-08-30 12:23:02 +00:00
s.outseqno = atoi(buf + 1);
Handle special characters in sptps_test only if the --special option is given. sptps_test treats lines starting with #, ^ and $ specially, in order to test the SPTPS protocol. However, this should only be done if explicitly requested, otherwise it can unexpectedly fail.
2016-04-17 14:01:49 +00:00
if(special && buf[0] == '^')
Ensure all SPTPS functions are prefixed with sptps_.
2012-02-26 11:33:16 +00:00
sptps_send_record(&s, SPTPS_HANDSHAKE, NULL, 0);
Handle special characters in sptps_test only if the --special option is given. sptps_test treats lines starting with #, ^ and $ specially, in order to test the SPTPS protocol. However, this should only be done if explicitly requested, otherwise it can unexpectedly fail.
2016-04-17 14:01:49 +00:00
else if(special && buf[0] == '$') {
Ensure all SPTPS functions are prefixed with sptps_.
2012-02-26 11:33:16 +00:00
sptps_force_kex(&s);
Test SPTPS messages sent while key renegotation is in progress.
2012-03-18 16:42:43 +00:00
if(len > 1)
sptps_send_record(&s, 0, buf, len);
} else
Fix sending bulk data starting with a newline.
2013-10-22 19:28:44 +00:00
if(!sptps_send_record(&s, buf[0] == '!' ? 1 : 0, buf, (len == 1 && buf[0] == '\n') ? 0 : buf[0] == '*' ? sizeof buf : len))
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
}
Make sure tinc compiles on Windows.
2012-07-21 10:51:53 +00:00
if(FD_ISSET(sock, &fds)) {
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
ssize_t len = recv(sock, buf, sizeof buf, 0);
if(len < 0) {
Fix errno references when handling socket errors. When using socket functions, "sockerrno" is supposed to be used to retrieve the error code as opposed to "errno", so that it is translated to the correct call on Windows (WSAGetLastError() - Windows does not update errno on socket errors). Unfortunately, the use of sockerrno is inconsistent throughout the tinc codebase, as errno is often used incorrectly on socket-related calls. This commit fixes these oversights, which improves socket error handling on Windows.
2014-06-26 19:42:40 +00:00
fprintf(stderr, "Could not read from socket: %s\n", sockstrerror(sockerrno));
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 1;
}
if(len == 0) {
fprintf(stderr, "Connection terminated by peer.\n");
break;
}
Make sptps_test less verbose by default.
2013-10-22 19:19:41 +00:00
if(verbose) {
char hex[len * 2 + 1];
bin2hex(buf, hex, len);
fprintf(stderr, "Received %d bytes of data:\n%s\n", (int)len, hex);
}
if(packetloss && (rand() % 100) < packetloss) {
if(verbose)
fprintf(stderr, "Dropped.\n");
Add an option to test datagram SPTPS with packet loss.
2013-08-30 11:04:14 +00:00
continue;
}
Fix receiving SPTPS data in sptps_speed and sptps_test. The sptps_receive_data() was changed in commit d237efd to only process one SPTPS record from a stream input. So now we have to put a loop around it to ensure we process everything.
2015-06-07 21:14:48 +00:00
char *bufp = buf;
while(len) {
size_t done = sptps_receive_data(&s, bufp, len);
if(!done) {
if(!datagram)
return 1;
} else {
break;
}
bufp += done;
len -= done;
}
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
}
}
Ensure all SPTPS functions are prefixed with sptps_.
2012-02-26 11:33:16 +00:00
if(!sptps_stop(&s))
return 1;
Start of "Simple Peer-To-Peer Security" protocol. 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
2011-07-24 13:44:51 +00:00
return 0;
}
Reference in a new issue Copy permalink