See inline
On Thu, Nov 27, 2014 at 1:36 AM, Matt Caswell via RT <r...@openssl.org> wrote:
> Resend this time including r...@openssl.org...sorry for the noise on
> openssl-dev...
>
> On 27/11/14 02:54, Praveen Kariyanahalli via RT wrote:
> >> The purpose of DTLSv1_listen is to listen for incoming datagrams from
> >> anyone. If it receives a ClientHello without a cookie it immediately
> >> responds with a HelloVerifyRequest containing a cookie. The client is
> >> expected to respond with a second ClientHello containing the cookie. The
> >> idea is that this is a DoS protection mechanism.
> >>
> >> If DTLSv1_listen receives a ClientHello *with* a cookie then it will
> >> return with a positive result. The server is then expected to continue
> >> the handshake with a call to SSL_accept. This is often done in a
> >> separate thread just for that SSL_accept call.
> >>
> >> So something like this:
> >> while(1)
> >> {
> >> ssl = SSL_new(ctx);
> >> while(DTLSv1_listen(ssl, &client_addr) <= 0);
> >> /* client_addr will contain ip address of the client */
> >> Create_a_thread(ssl);
> >> }
> >>
> >> In new thread:
> >> SSL_accept(ssl);
> >>
> >>
> > [praveen]
> >
> > Yes we do use the DTLS_listen in the same way, only difference being we
> are
> > not doing SSL_accept in a new thread. *Note we are doing it in NON
> blocking
> > fashion. *The main DTLSv1_listen responds with HelloVerify. When the next
> > client hello comes back in, the DTLSv1_listen returns a positive result
> and
> > then, we create a new socket and pass on the ssl context to this socket
> (*Note:
> > it is a connected socket, meaning more specific socket*). We create a
> new
> > event corresponding to this socket and call the SSL_do_handshake on this
> > socket. Then we create a new fd less specific for the listening socket
> > (server socket).
>
>
[praveen] Here is what I am confused about. The dtls1_listen is calling the
SSL_accept, even in you thread approach this can happen. I don't quite get
what is it you are saying.
*Your approach *
while(1)
{
ssl = SSL_new(ctx);
while(DTLSv1_listen(ssl, &client_addr) <= 0);
/* client_addr will contain ip address of the client */
Create_a_thread(ssl);
}
*My approach*
global_ssl = SSL_new(ctx);
In Server call back function
ret = DTLSv1_listen(global_ssl, client_addr);
if ret <= 0 return;
else socket,
bind,
connect (more specific) and
migrate the global_ssl to this peer (peer->ssl) and continue
SSL_do_handshake (NON blocking)
Create new global_ssl = SSL_new(ctx)
Go back to Server call back function
> I don't quite understand what you are saying here: "we do use the
> DTLS_listen in the same way". Are you saying you handle the initial
> "listen" part of the handshake with DTLSv1_listen and then call
> SSL_accept on the connected socket? Because this suggests you are
> calling DTLSv1_listen a second time (i.e. on a handshake that has
> already completed the initial ClientHello/HelloVerify/ClientHello
> exchange):
>
[praveen]
This should *never* be the case. I will put an assert and make sure *THIS*
situation never happens. Before we further discuss the original problem, do
you agree with me so far ?
Regards
-Praveen
> ==621== by 0x595C555: SSL_accept (ssl_lib.c:940)
>
> ==621== by 0x59539F7: dtls1_listen (d1_lib.c:491)
>
> ==621== by 0x59533BF: dtls1_ctrl (d1_lib.c:267)
>
> ==621== by 0x595CAF2: SSL_ctrl (ssl_lib.c:1106)
>
> ==621== by 0x416229: server_ssl_event_cb (server.c:3823)
>
> Either that or something has gone very wrong.
>
> Matt
>
>
>
>
>
--
Regards
-Praveen
