[openssl-dev] [openssl.org #4521] openssl GCM ordering
Is there is a reason why openssl has restriction of auth before encrypt
order ? I dont believe there is an algo restriction, was wondering why
openssl has this.
*int CRYPTO_gcm128_aad(GCM128_CONTEXT *ctx, const unsigned char *aad,*
* size_t len)*
*{*
*[snip]*
*if (ctx->len.u[1])*
*return -2;<< Premature return*
*alen += len;*
The reason I bring this up, is that when I broadcast/multicast traffic need
not encrypt the payload multiple times, but need to auth the header
differently and openssl is refusing to cooperate :)
Please throw light on how to work around this problem. Also please correct
me if my assumption is wrong.
Thanks in advance
-Praveen
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4521
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3967] Assert hit in the latest 1.0.2d code
Yes that worked. The previous version we were using 1.0.1m. Thanks for the quick turn around -Praveen On Wed, Jul 29, 2015 at 3:35 PM, Matt Caswell via RT r...@openssl.org wrote: On Wed Jul 29 20:30:22 2015, prav...@viptela.com wrote: We seem to hit this assert with the latest code. Our sockets are all in non-blocking fashion. I dont see this assert in the previous releases. What was the last release you tried where this worked? Was this previously working on a 1.0.2 release? Can somebody throw more light on to this ? It is urgent. As we are not able to migrate to this version because of this regression. Please can you try the attached patch and let me know if that makes any difference. There seems to be an issue with DTLS1.2. If the underlying BIO write buffers are full DTLS is supposed to drop the packet and clear out the internal OpenSSL buffer. This code was only testing for DTLS1 not DTLS1 and DTLS1.2. If you are using DTLS1.2 then the internal buffer does not get cleared out, and the next time you try to write some data it falls over because the buffer should be empty but it isn't. Matt -- -Praveen ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3967] Assert hit in the latest 1.0.2d code
int do_dtls1_write(SSL *s, int type, const unsigned char *buf, unsigned int
len, int create_empty_fragment)
{
unsigned char *p,*pseq;
int i,mac_size,clear=0;
int prefix_len = 0;
SSL3_RECORD *wr;
SSL3_BUFFER *wb;
SSL_SESSION *sess;
int bs;
/* first check if there is a SSL3_BUFFER still being written
* out. This will happen with non blocking IO */
if (s-s3-wbuf.left != 0)
{
*OPENSSL_assert(0); /* XDTLS: want to see if we ever get
here */*
return(ssl3_write_pending(s,type,buf,len));
}
==
(gdb) frame 2
#2 0x76d690d5 in do_dtls1_write (s=0x74fe5c10, type=23,
buf=0x74bdf010 \005@\200, len=62, create_empty_fragment=0) at
d1_pkt.c:1505
1505OPENSSL_assert(0); /* XDTLS: want to see if we ever
get here */
(gdb) p s-s3-wbuf
$1 = {buf = 0x736f6010 \027\376\375, len = 17584, offset = 0, left =
99}
(gdb)
We seem to hit this assert with the latest code. Our sockets are all in
non-blocking fashion. I dont see this assert in the previous releases.
Can somebody throw more light on to this ? It is urgent. As we are not able
to migrate to this version because of this regression.
Thanks in Advance
-Praveen
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3929] Crash in EVP_PKEY_CTX_free in the client code ..
Version : 1.0.1m Platform: mips64 Client code crashed while timing out the peer (Freeing the SSL ctx). We are trying to reproduce the problem, will let you know if this happens again. Is this a known issue? Please let me know if you need any more info. Thanks in Advance -Praveen Kariyanahalli Program terminated with signal 10, Bus error. #0 EVP_PKEY_CTX_free (ctx=0x) at pmeth_lib.c:360 360*if (ctx-pmeth ctx-pmeth-cleanup)* (gdb) bt #0 EVP_PKEY_CTX_free (ctx=0x) at pmeth_lib.c:360 #1 0x00fff5f1efd8 in EVP_MD_CTX_cleanup (ctx=0xfff4be5c20) at digest.c:379 #2 0x00fff5f1f470 in EVP_MD_CTX_destroy (ctx=0xfff4be5c20) at digest.c:356 #3 0x00fff6061708 in ssl_clear_hash_ctx (hash=0xfff4bde4e8) at ssl_lib.c:3291 #4 0x00fff6061a38 in SSL_free (s=0xfff4bde410) at ssl_lib.c:562 #5 0x000120032db0 in client_peer_delete (p_global_ctx=0x1200c9b90 g_ctx, p_peerdb_hash=0xfff56dea10, p_peerdb_dll=0x1200cab50 g_ctx+4032, p_peer=0xfff47c6010, conn_flag=optimized out) at client_peer.c:1342 #6 0x000120033940 in peer_timer_expiry_cb (p_timer=optimized out, peer=0xfff47c6010, p_ctx=0x1200c9b90 g_ctx, arg3=optimized out, arg4=optimized out) at client_peer.c:270 #7 0x000120079c58 in timer_exec_pri (p_mgr=0xfff3658010, p_pri=0xfff3658080, p_starttime=optimized out, msecs=optimized out) at timer.c:638 #8 0x00012007a1e0 in timer_exec (p_mgr=0xfff3658010, pri_mask=optimized out, msecs=optimized out) at timer.c:524 #9 0x000120012800 in client_base_timer_cb (base_timer_fd=optimized out, what=optimized out, p_ctx=0x1200c9b90 g_ctx) at client.c:5086 #10 0x00fff611e054 in event_process_active_single_queue (activeq=0xfff4bff0d0, base=0xfff4becc10) at /usr/src/debug/libevent/2.0.21-r1/libevent-2.0.21-stable/event.c:1350 #11 event_process_active (base=optimized out) at /usr/src/debug/libevent/2.0.21-r1/libevent-2.0.21-stable/event.c:1420 #12 event_base_loop (base=0xfff4becc10, flags=optimized out) at /usr/src/debug/libevent/2.0.21-r1/libevent-2.0.21-stable/event.c:1621 #13 0x00012002376c in client_main (p_cfg=0xaca440) at client.c:5835 #14 0x000120023ebc in main (argc=optimized out, argv=optimized out) at client.c:6541 (gdb) ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3658] Memory leak in dtls1_send_server_certificate dtls1_buffer_message
Seeing the memory leak (process DTLS server) in the latest released 1.01k version on the server side. Any clue as to how to get this fixed? Regards -Praveen Kariyanahalli ==1162== 36,480 (1,920 direct, 34,560 indirect) bytes in 30 blocks are definitely lost in loss record 119 of 130 ==1162==at 0x4A08219: calloc (vg_replace_malloc.c:623) ==1162==by 0x4893C7: vip_guard_mem_openssl_alloc (vip_gaurd_mem.c:170) ==1162==by 0x5BFDC86: default_malloc_ex (mem.c:79) ==1162==by 0x5BFE33D: CRYPTO_malloc (mem.c:312) ==1162==by 0x5D24C9D: pitem_new (pqueue.c:73) ==1162==by 0x595A31F: dtls1_buffer_message (d1_both.c:1267) ==1162==by 0x5950BBD: dtls1_send_server_certificate (d1_srvr.c:1629) ==1162==by 0x594E439: dtls1_accept (d1_srvr.c:430) ==1162==by 0x595D8A4: SSL_accept (ssl_lib.c:934) ==1162==by 0x5954BBF: dtls1_listen (d1_lib.c:515) ==1162==by 0x59544DA: dtls1_ctrl (d1_lib.c:271) ==1162==by 0x595DDDC: SSL_ctrl (ssl_lib.c:1087) ==1162==by 0x4168B3: vbond_ssl_event_cb (vdaemon.c:3887) ==1162==by 0x54C2162: event_persist_closure (event.c:1301) ==1162==by 0x54C2271: event_process_active_single_queue (event.c:1345) ==1162==by 0x54C2540: event_process_active (event.c:1420) ==1162==by 0x54C2BA7: event_base_loop (event.c:1621) ==1162==by 0x41C0B6: vbond_main (vdaemon.c:5428) ==1162==by 0x41E096: main (vdaemon.c:6017) ==1162== ==1162== LEAK SUMMARY: ==1162==definitely lost: 4,032 bytes in 68 blocks ==1162==by 0x4893C7: vip_guard_mem_openssl_alloc (vip_gaurd_mem.c:170) ==1162==by 0x5BFDC86: default_malloc_ex (mem.c:79) ==1162==by 0x5BFE33D: CRYPTO_malloc (mem.c:312) ==1162==by 0x5D24C9D: pitem_new (pqueue.c:73) ==1162==by 0x595A31F: dtls1_buffer_message (d1_both.c:1267) ==1162==by 0x5950BBD: dtls1_send_server_certificate (d1_srvr.c:1629) ==1162==by 0x594E439: dtls1_accept (d1_srvr.c:430) ==1162==by 0x595D8A4: SSL_accept (ssl_lib.c:934) ==1162==by 0x5954BBF: dtls1_listen (d1_lib.c:515) ==1162==by 0x59544DA: dtls1_ctrl (d1_lib.c:271) ==1162==by 0x595DDDC: SSL_ctrl (ssl_lib.c:1087) ==1162==by 0x4168B3: vbond_ssl_event_cb (vdaemon.c:3887) ==1162==by 0x54C2162: event_persist_closure (event.c:1301) ==1162==by 0x54C2271: event_process_active_single_queue (event.c:1345) ==1162==by 0x54C2540: event_process_active (event.c:1420) ==1162==by 0x54C2BA7: event_base_loop (event.c:1621) ==1162==by 0x41C0B6: vbond_main (vdaemon.c:5428) ==1162==by 0x41E096: main (vdaemon.c:6017) ==1162== ==1162== LEAK SUMMARY: ==1162==definitely lost: 4,032 bytes in 68 blocks ==1162==indirectly lost: 41,024 bytes in 128 blocks ==1162== possibly lost: 9,160 bytes in 109 blocks ==1162==still reachable: 1,296,276 bytes in 21,109 blocks ==1162== suppressed: 0 bytes in 0 blocks ==1162== Reachable blocks (those to which a pointer was found) are not shown. ==1162== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==1162== ==1162== For counts of detected and suppressed errors, rerun with: -v ==1162== ERROR SUMMARY: 46 errors from 46 contexts (suppressed: 1 from 1) ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
Hi Matt No, we have not hit this issue for a while now. You can close the ticket. Thanks for following up. Just to make sure, we won't hit these issues . . We will upgrade to the latest stable version. Regards Praveen On Dec 22, 2014 3:50 AM, Matt Caswell via RT r...@openssl.org wrote: On Thu Nov 27 16:59:36 2014, prav...@viptela.com wrote: Thanks Matt. Will keep you posted on 1. Coming back to the original crash. Here is some update. Our server started seeing the crash and leaks, after our negative stress testing suite added some pmtu testcases. i.e., during 1000s of connections the underlying mtu(s) were changed (very low - to high) randomly and frequently. Once we reduced the frequency the server held up. Does that give u some clue ? Hi Praveen Are you still experiencing thse problems? There have been some significant commits in the stable branch recently with regards to DTLS mtu handing which might address your issues. Matt ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
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;
elsesocket,
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
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
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;
elsesocket,
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
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
Thanks Matt. Will keep you posted on 1. Coming back to the original crash. Here is some update. Our server started seeing the crash and leaks, after our negative stress testing suite added some pmtu testcases. i.e., during 1000s of connections the underlying mtu(s) were changed (very low - to high) randomly and frequently. Once we reduced the frequency the server held up. Does that give u some clue ? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
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
Re: [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
Thanks for your quick response. See inline.
On Mon, Nov 24, 2014 at 7:31 AM, Matt Caswell via RT r...@openssl.org wrote:
On Sun Nov 23 19:09:46 2014, prav...@viptela.com wrote:
This happens when the server is unreachable. The client when it is trying
to resend the client_hello is barfing on fragment-frag value. Is this
known issue ? Let me know if you need any more info.
Not consistently reproducible. Please let us know if I can work around
this
issue.
Curious.
Can you confirm the OpenSSL version and platform that you are using?
*[viptela.com http://viptela.com] Version: 1.0.1j, Platform: mips64 *
The only way I can see for frag-fragment to be NULL is if s-init_num is 0
*[viptela.com http://viptela.com] Yes that is correct.*
*(gdb) frame 1*
*#1 0x00fff7e35530 in dtls1_retransmit_message (s=0x1206dd750, seq=0,
frag_off=0, found=0xdfec60) at d1_both.c:1289*
*1289 memcpy(s-init_buf-data, frag-fragment,*
*(gdb) set pr pr*
*(gdb) set height 0*
*(gdb) p *s*
*$1 = {*
* version = 65279,*
* type = 4096,*
* method = 0xfff7e74e28 DTLSv1_client_method_data.14990,*
* rbio = 0x120869800,*
* wbio = 0x1205ce130,*
* bbio = 0x1205ce130,*
* rwstate = 1,*
* in_handshake = 1,*
* handshake_func = 0xfff7e29a88 dtls1_connect,*
* server = 0,*
* new_session = 0,*
* quiet_shutdown = 0,*
* shutdown = 0,*
* state = 4384,*
* rstate = 240,*
* init_buf = 0x1205ce110,*
* init_msg = 0x0,*
* init_num = 0,*
* init_off = 0,*
* packet = 0x1205bb063 ,*
* packet_length = 0,*
* s2 = 0x0,*
* s3 = 0x120774a60,*
* d1 = 0x1207560c0,*
* read_ahead = 1,*
* msg_callback = 0x0,*
* msg_callback_arg = 0x0,*
* hit = 0,*
* param = 0x120860b20,*
* cipher_list = 0x0,*
* cipher_list_by_id = 0x0,*
* mac_flags = 0,*
* enc_read_ctx = 0x0,*
* read_hash = 0x0,*
* expand = 0x0,*
* enc_write_ctx = 0x0,*
* write_hash = 0x0,*
* compress = 0x0,*
* cert = 0x120869880,*
* sid_ctx_length = 0,*
* sid_ctx = '\000' repeats 31 times,*
* session = 0x1206a6730,*
* generate_session_id = 0x0,*
* verify_mode = 5,*
* verify_callback = 0x12000f7b0 vdaemon_verify_callback,*
* info_callback = 0x0,*
* error = 0,*
* error_code = 0,*
* psk_client_callback = 0x0,*
* psk_server_callback = 0x0,*
* ctx = 0x12078b450,*
* debug = 0,*
* verify_result = 0,*
* ex_data = {*
*sk = 0x0,*
*dummy = 0*
* },*
* client_CA = 0x0,*
* references = 1,*
* options = 4100,*
* mode = 0,*
* max_cert_list = 102400,*
* first_packet = 0,*
* client_version = 65279,*
* max_send_fragment = 16384,*
* tlsext_debug_cb = 0x0,*
* tlsext_debug_arg = 0x0,*
* tlsext_hostname = 0x0,*
* servername_done = 0,*
* tlsext_status_type = -1,*
* tlsext_status_expected = 0,*
* tlsext_ocsp_ids = 0x0,*
* tlsext_ocsp_exts = 0x0,*
* tlsext_ocsp_resp = 0x0,*
* tlsext_ocsp_resplen = -1,*
* tlsext_ticket_expected = 0,*
* tlsext_ecpointformatlist_length = 0,*
* tlsext_ecpointformatlist = 0x0,*
* tlsext_ellipticcurvelist_length = 0,*
* tlsext_ellipticcurvelist = 0x0,*
* tlsext_opaque_prf_input = 0x0,*
* tlsext_opaque_prf_input_len = 0,*
* tlsext_session_ticket = 0x0,*
* tls_session_ticket_ext_cb = 0x0,*
* tls_session_ticket_ext_cb_arg = 0x0,*
* tls_session_secret_cb = 0x0,*
* tls_session_secret_cb_arg = 0x0,*
* initial_ctx = 0x12078b450,*
* next_proto_negotiated = 0x0,*
* next_proto_negotiated_len = 0 '\000',*
* srtp_profiles = 0x0,*
* srtp_profile = 0x0,*
* tlsext_heartbeat = 0,*
* tlsext_hb_pending = 0,*
* tlsext_hb_seq = 0,*
* renegotiate = 0,*
* srp_ctx = {*
*SRP_cb_arg = 0x0,*
*TLS_ext_srp_username_callback = 0x0,*
*SRP_verify_param_callback = 0x0,*
*SRP_give_srp_client_pwd_callback = 0x0,*
*login = 0x0,*
*N = 0x0,*
*g = 0x0,*
*s = 0x0,*
*B = 0x0,*
*A = 0x0,*
*a = 0x0,*
*b = 0x0,*
*v = 0x0,*
*info = 0x0,*
*strength = 1024,*
*srp_Mask = 0*
* }*
*}*
*(gdb) *
when the message is buffered in the first place. Messages get buffered in
dtls1_buffer_message in d1_both.c:
frag = dtls1_hm_fragment_new(s-init_num, 0);
if (!frag)
return 0;
memcpy(frag-fragment, s-init_buf-data, s-init_num);
If init_num is 0 then the memcpy does nothing and so will not fail if
frag-fragment is NULL.
dtls1_hm_fragment_new does this:
unsigned char *buf = NULL;
unsigned char *bitmask = NULL;
frag = (hm_fragment *)OPENSSL_malloc(sizeof(hm_fragment));
if ( frag == NULL)
return NULL;
if (frag_len)
{
buf = (unsigned char *)OPENSSL_malloc(frag_len);
if ( buf == NULL)
{
OPENSSL_free(frag);
return NULL;
}
}
/* zero length fragment gets zero frag-fragment */
frag-fragment = buf;
So if s-init_num is 0 then frag_len is 0 and frag-fragment gets set to
NULL.
*[viptela.com http://viptela.com] *
*(gdb) p frag*
*$2 = (hm_fragment *) 0x1205ce0a0*
*(gdb) p *frag*
*$3 = {*
* msg_header = {*
*type = 1 '\001',*
*msg_len = 55,*
*seq = 0,*
*frag_off = 0,*
*frag_len = 55,*
*is_ccs = 0,*
*saved_retransmit_state = {*
*
[openssl.org #3608] SEGV Crash in dtls1_retransmit_message function
This happens when the server is unreachable. The client when it is trying
to resend the client_hello is barfing on fragment-frag value. Is this
known issue ? Let me know if you need any more info.
Not consistently reproducible. Please let us know if I can work around this
issue.
# debug -a mips64 info.core.my_client.1626.pm1012.1416137224
[New LWP 1626]
[New LWP 1745]
Core was generated by `/usr/sbin/my_client -f'.
Program terminated with signal 11, Segmentation fault.
#0 0xeb851eb85454aaba in ?? ()
#0 0xeb851eb85454aaba in ?? ()
#1 0x00fff7e35530 in dtls1_retransmit_message (s=0x1206dd750, seq=0,
frag_off=0, found=0xdfec60) at d1_both.c:1289
#2 0x00fff7e34fb8 in dtls1_retransmit_buffered_messages
(s=0x1206dd750) at d1_both.c:1173
#3 0x00fff7e2e38c in dtls1_handle_timeout (s=0x1206dd750) at
d1_lib.c:464
#4 0x00fff7e2fbb0 in dtls1_read_bytes (s=0x1206dd750, type=22,
buf=0xdfee18
\377\377\377\377\204~{\210\377\377\377\377\204~{\020\377\377\377\377\204p,
len=12, peek=0) at d1_pkt.c:833
#5 0x00fff7e33ff8 in dtls1_get_message_fragment (s=0x1206dd750,
st1=4384, stn=4385, max=2, ok=0xdfef84) at d1_both.c:819
#6 0x00fff7e32c68 in dtls1_get_message (s=0x1206dd750, st1=4384,
stn=4385, mt=-1, max=2, ok=0xdfef84) at d1_both.c:443
#7 0x00fff7e01c34 in ssl3_get_server_hello (s=0x1206dd750) at
s3_clnt.c:832
#8 0x00fff7e2a120 in dtls1_connect (s=0x1206dd750) at d1_clnt.c:328
#9 0x00fff7e3a2d8 in SSL_connect (s=0x1206dd750) at ssl_lib.c:949
#10 0x00012003d70c in ssl_connect_timer_cb (p_timer=0x120869680,
peer=0x12085fdd0, arg2=0x0, arg3=0x0, arg4=0x0) at my_client_peer.c:330
#11 0x0001200a46f0 in timer_exec_pri (p_mgr=0x120397810,
p_pri=0x1203a3888, p_starttime=0xdff268, msecs=100) at timer.c:612
#12 0x0001200a40b4 in timer_exec (p_mgr=0x120397810,
pri_mask=TIMER_PRI_MASK_ALL, msecs=100) at timer.c:504
#13 0x000120021bf8 in g_base_timer_cb (base_timer_fd=-1, what=1,
g=0x1200e99d0 g_m_client) at my_client.c:4412
#14 0x00fff7ebe06c in event_process_active_single_queue
(base=0x120397270, activeq=0x120397760) at
/usr/src/debug/libevent/2.0.21-r3/libevent-2.0.21-stable/event.c:1350
#15 0x00fff7ebe3b8 in event_process_active (base=0x120397270) at
/usr/src/debug/libevent/2.0.21-r3/libevent-2.0.21-stable/event.c:1420
#16 0x00fff7ebeddc in event_base_loop (base=0x120397270, flags=0) at
/usr/src/debug/libevent/2.0.21-r3/libevent-2.0.21-stable/event.c:1621
(gdb) frame 1
#1 0x00fff7e35530 in dtls1_retransmit_message (s=0x1206dd750, seq=0,
frag_off=0, found=0xdfec60) at d1_both.c:1289
1289 memcpy(s-init_buf-data, frag-fragment,
(gdb) p *item
$1 = {priority = \000\000\000\000\000\000\000, data = 0x1205ce0a0, next =
0x0}
(gdb) p *frag
$2 = {msg_header = {type = 1 '\001', msg_len = 55, seq = 0, frag_off = 0,
frag_len = 55, is_ccs = 0, saved_retransmit_state = {enc_write_ctx = 0x0,
write_hash = 0x0, compress = 0x0,
session = 0x1206a6730, epoch = 0}}, fragment = 0x0, reassembly = 0x0}
(gdb) #
(gdb) #Note that the fragment is NULL
(gdb) #
(gdb) list
1284 if ( frag-msg_header.is_ccs)
1285 header_length = DTLS1_CCS_HEADER_LENGTH;
1286 else
1287 header_length = DTLS1_HM_HEADER_LENGTH;
1288
1289 memcpy(s-init_buf-data, *frag-fragment*,
1290 frag-msg_header.msg_len + header_length);
1291 s-init_num = frag-msg_header.msg_len + header_length;
1292
1293 dtls1_set_message_header_int(s, frag-msg_header.type,
*(gdb) p/x frag-fragment*
*$3 = 0x0*
(gdb) #
(gdb) #hence the crash
(gdb) #
(gdb)
Thanks in Advance
Praveen Kariyanahalli
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #3404] Bug report
Title : SSL_get_error returns SSL_ERROR_SYSCALL but errno is set to 0. How to reproduce? Set up a DTLSconnection. Then send fake DTLS (application data) as the server at high rate (400pps). Mix of fake packets make the problem reproduce more easily. Issue: The ssl_read reports SSL_ERROR_SYSCALL but the errno is set to 0. Please let me know if you need more details. Thanks -Praveen __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3286] DTLS client crash while clearing (freeing) the dtls1_buffer_record queue (buffered_app_data)
I am using openssl-1.0.1f. On mips64 platform.
Seeing a crash while cleaning up buffered_app_data.q during dtls1_free.
This queue is populated if the client receives application data between
ChangeCipherSpec and Finished messages. Are there known issues in this area
? Any help is greatly appreciated.
My code snippet:
if (peer-ssl != NULL) {
SSL_shutdown(peer-ssl);
SSL_free(peer-ssl);
peer-ssl = NULL;
}
Backtrace:
(gdb) bt
#0 0x in ?? ()
#1 signal handler called
#2 __GI___libc_free (mem=0x3) at malloc.c:2892
#3 0x00fff798e2a0 in CRYPTO_free (str=0x3) at mem.c:397
#4 0x00fff7c1a930 in dtls1_clear_queues (s=0x1205b2e80) at d1_lib.c:180
#5 0x00fff7c1a9f4 in dtls1_free (s=0x1205b2e80) at d1_lib.c:190
#6 0x00fff7c26160 in SSL_free (s=0x1205b2e80) at ssl_lib.c:586
(gdb) frame 4
#4 0x00fff7c1a930 in dtls1_clear_queues (s=0x1205b2e80) at d1_lib.c:180
180 OPENSSL_free(frag-fragment);
(gdb) p item
$10 = (pitem *) 0x120617070
(gdb) p *item
$11 = {
priority = \000\000\000\000\000\000\000\003,
data = 0x1205c5de0,
next = 0x0
}
(gdb) p *frag
$12 = {
msg_header = {
type = 0 '\000',
msg_len = 3185310234,
seq = 0,
frag_off = 17744,
frag_len = 481036337152,
is_ccs = 23,
saved_retransmit_state = {
enc_write_ctx = 0x0,
write_hash = 0x12060b5d0,
compress = 0x12060b5d0,
session = 0x0,
epoch = 0
}
},
fragment = 0x3 Address 0x3 out of bounds,
reassembly = 0xd3e5f80c21374e66 Address 0xd3e5f80c21374e66 out of bounds
}
*Thanks in Advance*
*-Praveen*
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
