The OpenSSL DTLS implementation was significantly improved for 0.9.8f;
it had some serious bugs in 0.9.8e (including a security advisory). You
are recommended to use at least 0.9.8f for DTLS. See the 12-Oct-2007
Security Advisory note at http://openssl.org/ and the 0.9.8f and g
release notes.
As far as handshaking in a separate thread, OpenSSL does support the
non-blocking I/O model which will allow you to do this. This is
non-trivial to get working; I'd recommend starting with example code
such as what's in the O'Reilly "Network Security with OpenSSL" book.
- Ariel
Rudolf Polzer wrote:
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 routines:DTLS1_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 routines:DTLS1_GET_RECORD:wrong version
number:d1_pkt.c:540:
8031:error:1410C0E5:SSL routines:DTLS1_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 [email protected]
Automated List Manager [EMAIL PROTECTED]
--
- Ariel Salomon / Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 990-7439 / [EMAIL PROTECTED]
RTI - The Real-Time Middleware Experts
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
