Just to add to my previous mail.
The peer specific handshake continues in a different event call back
routine. Note: sockets are NON blocking (async handling of events).
On Thu, Nov 27, 2014 at 7:22 AM, Praveen Kariyanahalli <prav...@viptela.com>
wrote:
> 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
>
--
Regards
-Praveen
