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 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
>
>



--
- Ariel Salomon / Senior Software Engineer
Real-Time Innovations (RTI) / www.rti.com
408 990-7439 / ariel@rti.com

RTI - The Real-Time Middleware Experts


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