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
