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
