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"
To: "Nilesh Vaghela"
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,
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"
To: "Robin Seggelmann"
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"
To: "Nilesh Vaghela"
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 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, 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
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"
To: "Nilesh Vaghela"
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
[openssl.org #2448] [1.0.0d] Typo in source files
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_point"X509v3 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_point"X509v3 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
OpenSSL v1.0.0 backward compatibility
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
Re: OpenSSL Security Advisory: OCSP stapling vulnerability
Thanks, Rob; I have updated the Security Advisory at http://www.openssl.org/news/secadv_20110208.txt. Bodo
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: OpenSSL Security Advisory: OCSP stapling vulnerability
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 > 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). > 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
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.
