Re: DTLSv1_listen in non-blocking
On 2/9/2011 10:59 AM, Nilesh Vaghela wrote: 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 ? Why is that a problem? Before the timeout, you *should* be doing other things. DS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
DTLSv1_listen in non-blocking
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: 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
__
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
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
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
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
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
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
