DTLSv1_listen in non-blocking

2011-02-09 Thread Nilesh Vaghela
I am using DTLSv1_listen in non-blocking underlying socket layer. I am using 
openssl-0.9.8o and I looked at the implementation. 

int dtls1_listen(SSL *s, struct sockaddr *client) 
{ 
int ret; 

SSL_set_options(s, SSL_OP_COOKIE_EXCHANGE); 
s-d1-listen = 1; 

ret = SSL_accept(s); 
if (ret = 0) return ret; 

(void) BIO_dgram_get_peer(SSL_get_rbio(s), client); 
return 1; 
} 

Does this mean that we do not have to call SS_accept after DTLSv1_listen() 
returns with 1. And if it returns -1 with SSL_ERROR_WANT_READ or 
SSL_ERROR_WANT_WRITE 
then we call again till we get the connection established ? My understanding 
was that we have to do SSL_accept on a connected socket so that SSL handshake 
happens 
separately(certificate/key exchange) and listen socket only receives 
ClientHello, sends Helloverify Request and receives ClientHelloWithCookie. 

In some examples on web we see that we do call SSL_accept() after DTLSv1_listen 
returns with 1. But I looked at s_server.c in the openssl sources, it does not 
even call DTLSv1_listen(). How do I understand this ? 

I am confused here. 

If some one can guide I would appreciate. 

--Nilesh. 



Re: OpenSSL Security Advisory: OCSP stapling vulnerability

2011-02-09 Thread Rob Stradling
Bodo, some comments inline...

On Tuesday 08 Feb 2011 18:09:46 Bodo Moeller wrote:
 OpenSSL Security Advisory [8 February 2011]
 
 OCSP stapling vulnerability in OpenSSL
snip
 Which applications are affected
 ---
 
 Applications are only affected if they act as a server and call
 SSL_CTX_set_tlsext_status_cb on the server's SSL_CTX. This includes
 Apache httpd = 2.3.3.

In httpd = 2.3.3, OCSP Stapling is currently disabled by default.  To enable 
it, the SSLUseStapling On directive must be added to the config.  Since 
SSL_CTX_set_tlsext_status_cb() is only called when OCSP Stapling has been 
enabled, I conclude that the default configuration is not vulnerable.

A couple of months ago I proposed to httpd-dev that OCSP Stapling should be 
enabled by default.  Steve Henson was cautiously sympathetic to the idea...
My personal opinion would be to, at least initially, require an explicit 
directive to enable it and leave the option in future to have it enabled by 
default.
...but Igor Galić replied with...
If we want to see more extensive testing in the field, then this is the right 
time to make 'On' the default.

Maybe httpd should:
1. Check the version number of the OpenSSL runtime library.
2. Log a warning if a vulnerable OpenSSL version is detected.
3. Definitely avoid enabling Stapling by default if a vulnerable OpenSSL 
version is detected.

(Sorry, I guess I've drifted a bit off-topic for this list).

snip
 OCSP stapling is defined in RFC 2560.

RFC 2560 defines OCSP, but not OCSP Stapling.

OCSP Stapling is the popular term for the Certificate Status Request TLS 
Extension defined most recently by RFC 6066 (previous versions: RFC 4366, RFC 
3546).

Rob Stradling
Senior Research  Development Scientist
COMODO - Creating Trust Online
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: DTLSv1_listen in non-blocking

2011-02-09 Thread Robin Seggelmann
Hi Nilesh,

On Feb 9, 2011, at 4:05 AM, Nilesh Vaghela wrote:

 I am using DTLSv1_listen in non-blocking underlying socket layer. I am using 
 openssl-0.9.8o and I looked at the implementation.

Don't use any 0.9.8 release if you want to work with DTLS. There are a *lot* of 
bugs which are fixed in 1.0.0a and later.

 int dtls1_listen(SSL *s, struct sockaddr *client)
 {
 int ret;
 
 SSL_set_options(s, SSL_OP_COOKIE_EXCHANGE);
 s-d1-listen = 1;
 
 ret = SSL_accept(s);
 if (ret = 0) return ret;
 
 (void) BIO_dgram_get_peer(SSL_get_rbio(s), client);
 return 1;
 }
 
 Does this mean that we do not have to call SS_accept after DTLSv1_listen() 
 returns with 1. And if it returns -1 withSSL_ERROR_WANT_READ or 
 SSL_ERROR_WANT_WRITE
 then we call again till we get the connection established ? My understanding 
 was that we have to do SSL_accept on a connected socket so that SSL handshake 
 happens
 separately(certificate/key exchange) and listen socket only receives 
 ClientHello, sends Helloverify Request and receives ClientHelloWithCookie.

Since there is no accept() for UDP, you need to handle incoming connections 
otherwise. The DLTSv1_listen() call waits for incoming connections and responds 
to ClientHellos with a ServerHello including a cookie. It discards any other 
message and does not allocate any memory. If a client responds to the 
ServerHello correctly, that is resends its ClientHello with the cookie 
attached, it returns 1. The SSL object can then be used to handle the 
connection to that client (in a new thread). To do this, the socket should be 
set 'connected'. However, the handshake has not been completed yet, only the 
Hellos have been exchanged. Therefore, you still have to call SSL_accept() to 
complete the handshake. Meanwhile, the listen has to be called with a new SSL 
object to watch for other new connections. If you are non-blockig and it 
returns -1, just call it again.

This is the only way you can write a multi-threaded server which also performs 
the cookie exchange to avoid denial of service attacks. The examples at 
http://sctp.fh-muenster.de show how its done correctly. For non-blocking 
implementations, make sure you handle DTLS timers. Use DTLSv1_get_timeout(SSL 
*ssl, struct timeval *timeleft) to get the time until the next timeout (you can 
use that for a select() timeout) and call DTLSv1_handle_timeout(SSL *ssl) when 
a timeout occurred and there is nothing to read or write, so retransmissions of 
handshake messages etc. can still be done.

 In some examples on web we see that we do call SSL_accept() after 
 DTLSv1_listen returns with 1. But I looked at s_server.c in the openssl 
 sources, it does not even call DTLSv1_listen(). How do I understand this ?

The s_server code has not been modified to support DTLS cookies correctly or 
multiple connections. It's basically a TLS server which can also use DTLS.

Best regards
Robin







__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: OpenSSL Security Advisory: OCSP stapling vulnerability

2011-02-09 Thread Bodo Moeller
Thanks, Rob; I have updated the Security Advisory at
http://www.openssl.org/news/secadv_20110208.txt.

Bodo


OpenSSL v1.0.0 backward compatibility

2011-02-09 Thread kari.sulander
Hi,



I'm interested to know if it is safe to upgrade our OpenSSL version from 0.9.8f 
to 1.0.0c without any issues in compatibility? So in practice the 
functionalities supported by the 0.9.8f should still be supported by the 1.0.0, 
is this the case?



Also, what is the reason for keeping the old 0.9.8 branch in parallel with the 
1.0.0?



BR,

Kari





[openssl.org #2448] [1.0.0d] Typo in source files

2011-02-09 Thread Samuel LACAS via RT
Hi,

I have just noticed that the word distribution was mispelled at 
several places in the source code (you have distr_u_bution instead). 
For the copyright notices, it is not very important, but it appears in 
some X.509v3 output messages.

openssl-1.0.0d/crypto/bf/COPYRIGHT:copied and put under another 
distrubution license
openssl-1.0.0d/crypto/des/COPYRIGHT:copied and put under another 
distrubution license
openssl-1.0.0d/crypto/objects/obj_dat.h:{issuingDistributionPoint,X509v3 
Issuing Distrubution Point,
openssl-1.0.0d/crypto/objects/obj_dat.h:770,/* X509v3 Issuing 
Distrubution Point */
openssl-1.0.0d/crypto/objects/obj_mac.h:#define 
LN_issuing_distribution_pointX509v3 Issuing Distrubution Point
openssl-1.0.0d/crypto/objects/objects.txt:id-ce 28: 
issuingDistributionPoint : X509v3 Issuing Distrubution Point
openssl-1.0.0d/include/openssl/obj_mac.h:#define 
LN_issuing_distribution_pointX509v3 Issuing Distrubution Point


Sincerely yours,

*Samuel LACAS*

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: DTLSv1_listen in non-blocking

2011-02-09 Thread Nilesh Vaghela
Thanks Robin. 

Just wanted to give additional information that I am not implementing 
multi-threaded server as there can be thousands of connections. Having said 
that I would have to use select for both the fds (one listen socket and many 
connected sockets). With this model, do I still have to handle DTLS timers ? 
The way I was thinking of implementing is 
to have read interest on the listen fd and when it gets triggered call 
DTLSv1_listen and of it returns -1 then keep the interest and call 
DTLSv1_listen again when read fd is triggered. At the same time I would also 
have other connected fds in the (read/write) fdset for select. Will this works 
like that ? 

--Nilesh. 


- Original Message - 
From: Robin Seggelmann seggelm...@fh-muenster.de 
To: Nilesh Vaghela nvagh...@stratacache.com 
Cc: openssl-dev@openssl.org 
Sent: Wednesday, February 9, 2011 1:21:22 AM GMT -08:00 US/Canada Pacific 
Subject: Re: DTLSv1_listen in non-blocking 

Hi Nilesh, 

On Feb 9, 2011, at 4:05 AM, Nilesh Vaghela wrote: 

 I am using DTLSv1_listen in non-blocking underlying socket layer. I am using 
 openssl-0.9.8o and I looked at the implementation. 

Don't use any 0.9.8 release if you want to work with DTLS. There are a *lot* of 
bugs which are fixed in 1.0.0a and later. 

 int dtls1_listen(SSL *s, struct sockaddr *client) 
 { 
 int ret; 
 
 SSL_set_options(s, SSL_OP_COOKIE_EXCHANGE); 
 s-d1-listen = 1; 
 
 ret = SSL_accept(s); 
 if (ret = 0) return ret; 
 
 (void) BIO_dgram_get_peer(SSL_get_rbio(s), client); 
 return 1; 
 } 
 
 Does this mean that we do not have to call SS_accept after DTLSv1_listen() 
 returns with 1. And if it returns -1 withSSL_ERROR_WANT_READ or 
 SSL_ERROR_WANT_WRITE 
 then we call again till we get the connection established ? My understanding 
 was that we have to do SSL_accept on a connected socket so that SSL handshake 
 happens 
 separately(certificate/key exchange) and listen socket only receives 
 ClientHello, sends Helloverify Request and receives ClientHelloWithCookie. 

Since there is no accept() for UDP, you need to handle incoming connections 
otherwise. The DLTSv1_listen() call waits for incoming connections and responds 
to ClientHellos with a ServerHello including a cookie. It discards any other 
message and does not allocate any memory. If a client responds to the 
ServerHello correctly, that is resends its ClientHello with the cookie 
attached, it returns 1. The SSL object can then be used to handle the 
connection to that client (in a new thread). To do this, the socket should be 
set 'connected'. However, the handshake has not been completed yet, only the 
Hellos have been exchanged. Therefore, you still have to call SSL_accept() to 
complete the handshake. Meanwhile, the listen has to be called with a new SSL 
object to watch for other new connections. If you are non-blockig and it 
returns -1, just call it again. 

This is the only way you can write a multi-threaded server which also performs 
the cookie exchange to avoid denial of service attacks. The examples at 
http://sctp.fh-muenster.de show how its done correctly. For non-blocking 
implementations, make sure you handle DTLS timers. Use DTLSv1_get_timeout(SSL 
*ssl, struct timeval *timeleft) to get the time until the next timeout (you can 
use that for a select() timeout) and call DTLSv1_handle_timeout(SSL *ssl) when 
a timeout occurred and there is nothing to read or write, so retransmissions of 
handshake messages etc. can still be done. 

 In some examples on web we see that we do call SSL_accept() after 
 DTLSv1_listen returns with 1. But I looked at s_server.c in the openssl 
 sources, it does not even call DTLSv1_listen(). How do I understand this ? 

The s_server code has not been modified to support DTLS cookies correctly or 
multiple connections. It's basically a TLS server which can also use DTLS. 

Best regards 
Robin 









Re: DTLSv1_listen in non-blocking

2011-02-09 Thread Nilesh Vaghela
Hi, 
Two more questions 
1. I assume that = 1.0.0a version has FIPS support fro DTLS ? 
2. What is the difference between 0.9.8 and 1.0.0 ? Assuming that program 
tested with 0.9.8 (with FIPS) would work without any changes on 1.0.0. 

--Nilesh. 

 I am using DTLSv1_listen in non-blocking underlying socket layer. I am using 
 openssl-0.9.8o and I looked at the implementation. 

Don't use any 0.9.8 release if you want to work with DTLS. There are a *lot* of 
bugs which are fixed in 1.0.0a and later. 




Re: DTLSv1_listen in non-blocking

2011-02-09 Thread Robin Seggelmann
Hi Nilesh,

On 09.02.2011, at 17:15, Nilesh Vaghela wrote:

 Just wanted to give additional information that I am not implementing 
 multi-threaded server as there can be thousands of connections. Having said 
 that I would have to use select for both the fds (one listen socket and many 
 connected sockets). With this model, do I still have to handle DTLS timers ? 
 The way I was thinking of implementing is
 to have read interest on the listen fd and when it gets triggered call 
 DTLSv1_listen and of it returns -1 then keep the interest and call 
 DTLSv1_listen again when read fd is triggered. At the same time I would also 
 have other connected fds in the (read/write) fdset for select. Will this 
 works like that ?


You have to handle the timers for every single DTLS connection.

 1. I assume that = 1.0.0a version has FIPS support fro DTLS ?
 2. What is the difference between 0.9.8 and 1.0.0 ? Assuming that program 
 tested with 0.9.8 (with FIPS) would work without any changes on 1.0.0.


1. Probably not. The DTLS implementation was a proof of concept and we provided 
as many patches as necessary to get it running and compliant to RFC 4347. I 
don't think anyone took care about FIPS yet.

2. The latest bugfixes have not been backported because the differences between 
the versions became too large. In 0.9.8 you don't have IPv6 support, the replay 
handling is erroneous, the reassembly is entirely broken and many other things. 
Have a look at http://sctp.fh-muenster.de/dtls-patches.html, there are pretty 
much all of the recent DTLS patches listed and only very few have made their 
way into the 0.9.8 branch.

 I just realized that may be DTLSv1_get_timeout and handle timeout is 
 important because when server sends Server Hello we need to get back the 
 response in time out.
 Is that right understanding ? If that is the case then in select I can not 
 mix other fds as the may get activity before timeout of DTLS.


You're right. You need to handle the timeouts for every DTLS connection 
separately. That's why threads are recommended.

 How does DTLSv1_listen handle multiple ClientHellos at the same time, let us 
 say multiple clients are connecting.
 It looks like unless for one client hello session is not completed it can not 
 start hello session for other client.
 I understand this way because we have to call DTLSv1_handle_timeout() in 
 order to update the timer in SSL library for
 retransmission of Hello. My understanding may be wrong. I would appreciate if 
 some one clarifies.

You can handle multiple connection attempts with DTLSv1_listen. The call will 
answer ever ClientHello with a ServerHello and returns if a ClientHello has 
been repeated with the cookie. Since its socket will then be replaced, an other 
connection attempt only gets lost if two ClientHellos with a cookie arrive at 
the exact same time and there was no chance to exchange the socket in the 
meantime. Then one ClientHello can't be processed and has to be retransmitted. 
The cookie generation and verification works even if the SSL object was 
exchanged in between, because it's done with independent callback functions.

You don't need to care about timeouts at this point because the DTLSv1_listen 
will not start any timers. It's supposed to prevent denial of service attacks 
so it only responds to incoming ClientHellos and either returns if a 
verification was successful or just continues. The client will have a timer and 
repeats the ClientHello if anything gets lost. You will need the timer handling 
for the connected socket after the ClientHello, when the handshake is completed 
as well as for renegotiations.

It's done this way because the OpenSSL API does not allow one-to-many sockets 
to be used, which would be the actual way to work with UDP instead of creating 
many connected sockets. To supply a destination with e.g. a SSL_read(), 
significant changes to the architecture would have to be made. To avoid that, 
the workaround with connected UDP sockets is used to emulate a one-to-one 
scenario similar to TCP.

Best regards
Robin







__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org


Re: DTLSv1_listen in non-blocking

2011-02-09 Thread Nilesh Vaghela
Hi, 
I just realized that may be DTLSv1_get_timeout and handle timeout is important 
because when server sends Server Hello we need to get back the response in time 
out. 
Is that right understanding ? If that is the case then in select I can not mix 
other fds as the may get activity before timeout of DTLS. 

So how do we handle this ? 

--Nilesh. 

- Original Message - 
From: Nilesh Vaghela nvagh...@stratacache.com 
To: Robin Seggelmann seggelm...@fh-muenster.de 
Cc: openssl-dev@openssl.org 
Sent: Wednesday, February 9, 2011 8:15:03 AM GMT -08:00 US/Canada Pacific 
Subject: Re: DTLSv1_listen in non-blocking 


Thanks Robin. 

Just wanted to give additional information that I am not implementing 
multi-threaded server as there can be thousands of connections. Having said 
that I would have to use select for both the fds (one listen socket and many 
connected sockets). With this model, do I still have to handle DTLS timers ? 
The way I was thinking of implementing is 
to have read interest on the listen fd and when it gets triggered call 
DTLSv1_listen and of it returns -1 then keep the interest and call 
DTLSv1_listen again when read fd is triggered. At the same time I would also 
have other connected fds in the (read/write) fdset for select. Will this works 
like that ? 

--Nilesh. 


- Original Message - 
From: Robin Seggelmann seggelm...@fh-muenster.de 
To: Nilesh Vaghela nvagh...@stratacache.com 
Cc: openssl-dev@openssl.org 
Sent: Wednesday, February 9, 2011 1:21:22 AM GMT -08:00 US/Canada Pacific 
Subject: Re: DTLSv1_listen in non-blocking 

Hi Nilesh, 

On Feb 9, 2011, at 4:05 AM, Nilesh Vaghela wrote: 

 I am using DTLSv1_listen in non-blocking underlying socket layer. I am using 
 openssl-0.9.8o and I looked at the implementation. 

Don't use any 0.9.8 release if you want to work with DTLS. There are a *lot* of 
bugs which are fixed in 1.0.0a and later. 

 int dtls1_listen(SSL *s, struct sockaddr *client) 
 { 
 int ret; 
 
 SSL_set_options(s, SSL_OP_COOKIE_EXCHANGE); 
 s-d1-listen = 1; 
 
 ret = SSL_accept(s); 
 if (ret = 0) return ret; 
 
 (void) BIO_dgram_get_peer(SSL_get_rbio(s), client); 
 return 1; 
 } 
 
 Does this mean that we do not have to call SS_accept after DTLSv1_listen() 
 returns with 1. And if it returns -1 withSSL_ERROR_WANT_READ or 
 SSL_ERROR_WANT_WRITE 
 then we call again till we get the connection established ? My understanding 
 was that we have to do SSL_accept on a connected socket so that SSL handshake 
 happens 
 separately(certificate/key exchange) and listen socket only receives 
 ClientHello, sends Helloverify Request and receives ClientHelloWithCookie. 

Since there is no accept() for UDP, you need to handle incoming connections 
otherwise. The DLTSv1_listen() call waits for incoming connections and responds 
to ClientHellos with a ServerHello including a cookie. It discards any other 
message and does not allocate any memory. If a client responds to the 
ServerHello correctly, that is resends its ClientHello with the cookie 
attached, it returns 1. The SSL object can then be used to handle the 
connection to that client (in a new thread). To do this, the socket should be 
set 'connected'. However, the handshake has not been completed yet, only the 
Hellos have been exchanged. Therefore, you still have to call SSL_accept() to 
complete the handshake. Meanwhile, the listen has to be called with a new SSL 
object to watch for other new connections. If you are non-blockig and it 
returns -1, just call it again. 

This is the only way you can write a multi-threaded server which also performs 
the cookie exchange to avoid denial of service attacks. The examples at 
http://sctp.fh-muenster.de show how its done correctly. For non-blocking 
implementations, make sure you handle DTLS timers. Use DTLSv1_get_timeout(SSL 
*ssl, struct timeval *timeleft) to get the time until the next timeout (you can 
use that for a select() timeout) and call DTLSv1_handle_timeout(SSL *ssl) when 
a timeout occurred and there is nothing to read or write, so retransmissions of 
handshake messages etc. can still be done. 

 In some examples on web we see that we do call SSL_accept() after 
 DTLSv1_listen returns with 1. But I looked at s_server.c in the openssl 
 sources, it does not even call DTLSv1_listen(). How do I understand this ? 

The s_server code has not been modified to support DTLS cookies correctly or 
multiple connections. It's basically a TLS server which can also use DTLS. 

Best regards 
Robin 









Re: DTLSv1_listen in non-blocking

2011-02-09 Thread Nilesh Vaghela
Hi, 
One more question : 
How does DTLSv1_listen handle multiple ClientHellos at the same time, let us 
say multiple clients are connecting. 
It looks like unless for one client hello session is not completed it can not 
start hello session for other client. 
I understand this way because we have to call DTLSv1_handle_timeout() in order 
to update the timer in SSL library for 
retransmission of Hello. My understanding may be wrong. I would appreciate if 
some one clarifies. 

--Nilesh. 

- Original Message - 
From: Robin Seggelmann seggelm...@fh-muenster.de 
To: Nilesh Vaghela nvagh...@stratacache.com 
Cc: openssl-dev@openssl.org 
Sent: Wednesday, February 9, 2011 1:21:22 AM GMT -08:00 US/Canada Pacific 
Subject: Re: DTLSv1_listen in non-blocking 

Hi Nilesh, 

On Feb 9, 2011, at 4:05 AM, Nilesh Vaghela wrote: 

 I am using DTLSv1_listen in non-blocking underlying socket layer. I am using 
 openssl-0.9.8o and I looked at the implementation. 

Don't use any 0.9.8 release if you want to work with DTLS. There are a *lot* of 
bugs which are fixed in 1.0.0a and later. 

 int dtls1_listen(SSL *s, struct sockaddr *client) 
 { 
 int ret; 
 
 SSL_set_options(s, SSL_OP_COOKIE_EXCHANGE); 
 s-d1-listen = 1; 
 
 ret = SSL_accept(s); 
 if (ret = 0) return ret; 
 
 (void) BIO_dgram_get_peer(SSL_get_rbio(s), client); 
 return 1; 
 } 
 
 Does this mean that we do not have to call SS_accept after DTLSv1_listen() 
 returns with 1. And if it returns -1 withSSL_ERROR_WANT_READ or 
 SSL_ERROR_WANT_WRITE 
 then we call again till we get the connection established ? My understanding 
 was that we have to do SSL_accept on a connected socket so that SSL handshake 
 happens 
 separately(certificate/key exchange) and listen socket only receives 
 ClientHello, sends Helloverify Request and receives ClientHelloWithCookie. 

Since there is no accept() for UDP, you need to handle incoming connections 
otherwise. The DLTSv1_listen() call waits for incoming connections and responds 
to ClientHellos with a ServerHello including a cookie. It discards any other 
message and does not allocate any memory. If a client responds to the 
ServerHello correctly, that is resends its ClientHello with the cookie 
attached, it returns 1. The SSL object can then be used to handle the 
connection to that client (in a new thread). To do this, the socket should be 
set 'connected'. However, the handshake has not been completed yet, only the 
Hellos have been exchanged. Therefore, you still have to call SSL_accept() to 
complete the handshake. Meanwhile, the listen has to be called with a new SSL 
object to watch for other new connections. If you are non-blockig and it 
returns -1, just call it again. 

This is the only way you can write a multi-threaded server which also performs 
the cookie exchange to avoid denial of service attacks. The examples at 
http://sctp.fh-muenster.de show how its done correctly. For non-blocking 
implementations, make sure you handle DTLS timers. Use DTLSv1_get_timeout(SSL 
*ssl, struct timeval *timeleft) to get the time until the next timeout (you can 
use that for a select() timeout) and call DTLSv1_handle_timeout(SSL *ssl) when 
a timeout occurred and there is nothing to read or write, so retransmissions of 
handshake messages etc. can still be done. 

 In some examples on web we see that we do call SSL_accept() after 
 DTLSv1_listen returns with 1. But I looked at s_server.c in the openssl 
 sources, it does not even call DTLSv1_listen(). How do I understand this ? 

The s_server code has not been modified to support DTLS cookies correctly or 
multiple connections. It's basically a TLS server which can also use DTLS. 

Best regards 
Robin