It's planned to possibly use OpenSSL's DTLS1 to secure connections in
the DarkPlaces quake engine (possible purposes include nick name
certificates to protect against imposters, protection against packet
injection and a mutual player/clan trust system, server console access
authentication).

I understand that OpenSSL may be a bit oversized for that purpose (e.g.
it isn't THAT bad if the underlying cryptography gets broken), but it's
something that is already there and should spare us from reinventing the
wheel. So I first tried to get DTLS1 running with s_client and s_server,
but ran into the following problem:

$ openssl s_server -cert foo.pem -dtls1
Enter pass phrase for foo.pem:
Using default temp DH parameters
Using default temp ECDH parameters
ACCEPT
ERROR
7978:error:1410242E:SSL routinesTLS1_READ_BYTES:tlsv1 alert protocol version:d1_pkt.c:951:SSL alert number 70
shutting down SSL
CONNECTION CLOSED
ACCEPT

$ openssl s_client -dtls1
CONNECTED(00000003)
8031:error:140FE10B:SSL routinesTLS1_GET_RECORD:wrong version number:d1_pkt.c:540:
8031:error:1410C0E5:SSL routinesTLS1_WRITE_APP_DATA_BYTES:ssl handshake failure:d1_pkt.c:1148:

What does this mean, what am I doing wrong, and how to fix this? I'm using
OpenSSL 0.9.8e 23 Feb 2007 (Ubuntu). Or is this a bug that has already
been fixed? If that's the case, is it a bug in s_client/s_server or in
OpenSSL's internals? If it's a bug in the SSL library, we probably can't
use this feature till major Linux distros carry a fixed version of
OpenSSL, but if it's an issue in s_client or s_server, DarkPlaces could
be programmed to be not affected by it.

Also, is it possible to offload the SSL handshake overhead to another
thread? I got the following timings using "time openssl s_server" and
accepting 1000 SSLv3 connections (rows are server key length, columns
are client key length) on my Athlon 64 3700+:

1024 2048 4096 client certificate key length
1024 2.6ms 2.5ms 2.8ms
2048 5.9ms 6.5ms 6.4ms
4096 29.2ms 29.7ms 29.7ms

As it seems, only the length of the key in the SERVER certificate really
matters. However, for my purposes it isn't required that the server
authenticates to the client... so is it possible to run a server
without any server certificate (just CAs) to speed this up (openssl
s_server does not allow such operation), just like in regular HTTP SSL
connections, the client has no certificate? Even if not - would there be
any serious security impact from using a dummy 1024bit RSA certificate
on the server and 4096bit RSA certificates on the client (that is, would
this make it possible to break the client authentication easier)?

I also got no significance of the CA key length on the CPU time needed
on server side for the SSL handshake (actually, these tests were done
with a 4096bit CA already).

Best regards

Rudolf Polzer

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org