Hi Matt
See inline ..
On Wed, Nov 26, 2014 at 3:52 PM, Matt Caswell via RT <r...@openssl.org> wrote:
>
>
> On 25/11/14 23:20, Praveen Kariyanahalli wrote:
> > Hi Matt
> >
> > Trying out your patch. Will keep you posted. In meanwhile we ran into
> > more valgrind issues .. on the server end. Can you please comment on
> them?
> >
> > ==621== 8,680 (1,488 direct, 7,192 indirect) bytes in 62 blocks are
> > definitely lost in loss record 899 of 952
> > ==621== at 0x4A05F80: malloc (vg_replace_malloc.c:296)
> >
> > ==621== by 0x5BFCC86: default_malloc_ex (mem.c:79)
> >
> > ==621== by 0x5BFD315: CRYPTO_malloc (mem.c:308)
> >
> > ==621== by 0x5D2414D: pitem_new (pqueue.c:73)
> >
> > ==621== by 0x5958F74: dtls1_buffer_message (d1_both.c:1233)
> >
> > ==621== by 0x594E3B2: dtls1_send_server_done (d1_srvr.c:1032)
>
> This doesn't look right. The code is sending a ServerHelloDone message
> here, but...
>
>
> >
> > ==621== by 0x594D696: dtls1_accept (d1_srvr.c:564)
> >
> > ==621== by 0x595C555: SSL_accept (ssl_lib.c:940)
> >
> > ==621== by 0x59539F7: dtls1_listen (d1_lib.c:491)
> >
> ...here you have entered dtls1_listen.
>
> This internal function gets called when you call the public API function
> DTLSv1_listen - which is actually implemented as a macro that calls
> SSL_ctrl - which explains the rest of the stack trace below:
>
[praveen] Agreed.
>
>
>
> > ==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)
>
>
> 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).
*Reiterating: Non blocking and single threaded server*
Similar to what is suggested in page number 9
http://sctp.fh-muenster.de/DTLS.pdf
Also note that the cookie is global and periodically changing .. having a
tolerance of accepting previous cookie.
Hope that clarifies.
Regards
-Praveen
> Now under the covers DTLSv1_listen calls dlts1_listen which calls
> SSL_accept. The difference being that it has set various flags etc to
> put it into the "listen" state.
>
> In your stack trace you are sending a ServerHelloDone, which suggests to
> me you are attempting to *complete* a handshake whilst in DTLSv1_listen.
> So, in other words, in the above example once you have completed the
> initial part of the handshake, you are completing it by calling
> DTLSv1_listen again instead of calling SSL_accept (this will at least
> look like its working because DTLSv1_listen does eventually call
> SSL_accept).
>
> Its not clear to me what will happen in that scenario...at best the
> behaviour is "undefined" (we should probably put a check in to prevent
> this from happening...if that is indeed what is going on). I'm not sure
> whether that is the cause of this memory leak or not, but it certainly
> won't help track it down.
>
> Can you confirm whether you are using DTLSv1_listen like this or not? If
> not something really weird is going on.
>
> Matt
>
>
>
--
Regards
-Praveen
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
