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
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
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 ?
Willing to be part of OpenSSL Development Group
Hi Team, Please guide me to be the part of Development group. Thanks,Anup Kumar
Re: Willing to be part of OpenSSL Development Group
On 28/11/14 06:33, Anup Kumar wrote: Hi Team, Please guide me to be the part of Development group. Hello Anup, Thanks for your interest in OpenSSL. I have attempted to answer this question here: https://wiki.openssl.org/index.php/Developing_For_OpenSSL Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3544] Remove MWERKS support
Hi Rich, On 25.09.2014 00:09, Rich Salz via RT wrote: All sorts of pre-OSx mac support has been removed. commit 92c78463720f71e47c251ffa58493e32cd793e13 Author: Rich Salz rs...@openssl.org Date: Wed Sep 24 12:18:19 2014 -0400 RT3544: Remove MWERKS support The following #ifdef tests were all removed: __MWERKS__ MAC_OS_pre_X MAC_OS_GUSI_SOURCE MAC_OS_pre_X OPENSSL_SYS_MACINTOSH_CLASSIC OPENSSL_SYS_MACOSX_RHAPSODY Reviewed-by: Andy Polyakov ap...@openssl.org Rich Salz, OpenSSL dev team; rs...@openssl.org as already mentioned on the list the Metrowerks CodeWarrior for NetWare compiler also sets the __MWERKS__ macro - therefore please revert the changes to /crypto/rand/rand_nw.c of commit 92c78463720f71e47c251ffa58493e32cd793e13 because this is a NetWare-only file and has nothing to do with your intention to remove old MAC_OS support. Thanks! __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3544] Remove MWERKS support
Yes, I will revert the change.
RE: [openssl.org #3544] Remove MWERKS support
Yes, I will revert the change. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3604] [PATCH] User can specify the public exponent in genrsa
Quentin, Please can you resubmit this patch as an attachment rather than inline? Email has mangled it, and I am unable to review it. Thanks Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3602] [PATCH]
Error codes aren't part of the API. It's a bit of a grey area in some cases, but for EVP_DecryptFinal_ex, you really should be checking the return value and not relying on errors left on stack. In particular, reporting detailed decryption errors was a historical mistake that has led to serious attacks; it's a coding pattern we should eradicate. This particular change was made to avoid a timing leak and provide callers an opportunity to proceed in constant time. (But most callers won't care, it only affects mac-then-encrypt.) In your case, it sounds like the right thing to do is fix the unittest to be more robust. I'm going to reject this for now; I'll revisit if we get reports that this is causing more widespread problems, though. Cheers, Emilia __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3601] [PATCH] Improves the proxy certificates howto doc.
I just read them through, and it looks good, I just needed to do a couple of layout adjustments. Committed. Thank you. On Sat Nov 15 11:17:51 2014, a...@squareup.com wrote: Hi, The current documentation (hosted at https://www.openssl.org/docs/HOWTO/proxy_certificates.txt) contains a bunch of spelling and grammar mistakes. I also found it hard to understand some paragraphs, so here is my attempt to improve its overall readability. Alok -- Richard Levitte levi...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3592] bug report. Crash. Critical? Security bug?
Hmm try add ENV... valgrind is clear but asterisk crash with d1_both.c(332): OpenSSL internal error, assertion failed: len = DTLS1_HM_HEADER_LENGTH 2014-11-24 20:06 GMT+03:00 Matt Caswell via RT r...@openssl.org: On Sat Nov 22 13:19:13 2014, v.badal...@open-bs.ru wrote: Find this: https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=987158 http://openssl.6102.n7.nabble.com/AES-cbc-encrypt-amp-aesni-cbc- encrypt-length-parameter-td52370.html http://www.hardening-consulting.com/en/posts/20140512openssl-and- valgrind.html 2014-11-22 15:09 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: We fix all leaks in asteris and libsrtp many calls have one leak path ==44910== Use of uninitialised value of size 8 ==44910== at 0x4A08DEF: memcpy (mc_replace_strmem.c:882) ==44910== by 0x38E3EFD266: c2i_ASN1_INTEGER (string3.h:52) ==44910== by 0x38E3F08823: asn1_ex_c2i (tasn_dec.c:992) ==44910== by 0x38E3F0929A: asn1_d2i_ex_primitive (tasn_dec.c:907) ==44910== by 0x38E3F09A61: ASN1_item_ex_d2i (tasn_dec.c:233) ==44910== by 0x38E3F0A683: ASN1_item_d2i (tasn_dec.c:136) ==44910== by 0x38E424D421: d2i_SSL_SESSION (ssl_asn1.c:395) ==44910== by 0x38E4232324: tls_decrypt_ticket (t1_lib.c:2235) ==44910== by 0x38E423251B: tls1_process_ticket (t1_lib.c:2124) ==44910== by 0x38E42474DC: ssl_get_prev_session (ssl_sess.c:482) ==44910== by 0x38E421F94E: ssl3_get_client_hello (s3_srvr.c:1017) ==44910== by 0x38E4FC: ssl3_accept (s3_srvr.c:357) ==44910== Uninitialised value was created by a stack allocation ==44910== at 0x38E3E90077: aesni_cbc_encrypt (aesni- x86_64.s:2149) This is a false positive. See the RT ticket linked to from the redhat link you sent above: https://rt.openssl.org/Ticket/Display.html?id=2862 You can configure with no-asm for the purposes of testing to get rid of this. With all the other leaks resolved are you still experiencing crashes? Matt -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3604] [PATCH] User can specify the public exponent in genrsa
Hi Matt, Sure I will do that! Viktor, the point is that is some cases it would nuce to be able to change exponents, especially the day that we might discover any threat in F4. Also just adding more possibilities for the user. Best Le 28 nov. 2014 10:28, Viktor Dukhovni openssl-us...@dukhovni.org a écrit : On Fri, Nov 28, 2014 at 02:29:43PM +0100, Matt Caswell via RT wrote: Please can you resubmit this patch as an attachment rather than inline? Email has mangled it, and I am unable to review it. Also, what is the rationale for exponents other than F_4? -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3592] bug report. Crash. Critical? Security bug?
Full backtrace 2014-11-28 19:26 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: Hmm try add ENV... valgrind is clear but asterisk crash with d1_both.c(332): OpenSSL internal error, assertion failed: len = DTLS1_HM_HEADER_LENGTH 2014-11-24 20:06 GMT+03:00 Matt Caswell via RT r...@openssl.org: On Sat Nov 22 13:19:13 2014, v.badal...@open-bs.ru wrote: Find this: https://bugzilla.redhat.com/show_bug.cgi?format=multipleid=987158 http://openssl.6102.n7.nabble.com/AES-cbc-encrypt-amp-aesni-cbc- encrypt-length-parameter-td52370.html http://www.hardening-consulting.com/en/posts/20140512openssl-and- valgrind.html 2014-11-22 15:09 GMT+03:00 Вячеслав Бадалян v.badal...@open-bs.ru: We fix all leaks in asteris and libsrtp many calls have one leak path ==44910== Use of uninitialised value of size 8 ==44910== at 0x4A08DEF: memcpy (mc_replace_strmem.c:882) ==44910== by 0x38E3EFD266: c2i_ASN1_INTEGER (string3.h:52) ==44910== by 0x38E3F08823: asn1_ex_c2i (tasn_dec.c:992) ==44910== by 0x38E3F0929A: asn1_d2i_ex_primitive (tasn_dec.c:907) ==44910== by 0x38E3F09A61: ASN1_item_ex_d2i (tasn_dec.c:233) ==44910== by 0x38E3F0A683: ASN1_item_d2i (tasn_dec.c:136) ==44910== by 0x38E424D421: d2i_SSL_SESSION (ssl_asn1.c:395) ==44910== by 0x38E4232324: tls_decrypt_ticket (t1_lib.c:2235) ==44910== by 0x38E423251B: tls1_process_ticket (t1_lib.c:2124) ==44910== by 0x38E42474DC: ssl_get_prev_session (ssl_sess.c:482) ==44910== by 0x38E421F94E: ssl3_get_client_hello (s3_srvr.c:1017) ==44910== by 0x38E4FC: ssl3_accept (s3_srvr.c:357) ==44910== Uninitialised value was created by a stack allocation ==44910== at 0x38E3E90077: aesni_cbc_encrypt (aesni- x86_64.s:2149) This is a false positive. See the RT ticket linked to from the redhat link you sent above: https://rt.openssl.org/Ticket/Display.html?id=2862 You can configure with no-asm for the purposes of testing to get rid of this. With all the other leaks resolved are you still experiencing crashes? Matt -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru -- С уважением, Бадалян Вячеслав Борисович ООО Открытые бизнес-решения Технический директор +7 (495) 666-0-111 http://www.open-bs.ru bt_full.txt.gz Description: GNU Zip compressed data
Re: [openssl.org #3604] [PATCH] User can specify the public exponent in genrsa
On Fri, Nov 28, 2014 at 10:31:57AM -0600, Quentin Gouchet wrote: Viktor, the point is that is some cases it would nuce to be able to change exponents, especially the day that we might discover any threat in F4. If F_4 is found to be weak, RSA crypto-system will be abandoned. There will not be a fix by choosing something other than F_4. Also just adding more possibilities for the user. I call this more rope. In my view this patch just adds code, that provides users with options they don't need and should not use. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3596] [1.0.2] -checkhost and -verify_hostname options documentation errors
It's the same with s_server, I might add. I'm looking into this. On Tue Nov 11 00:34:14 2014, hka...@redhat.com wrote: Current git OpenSSL_1_0_2-stable branch (39679d858) has errors related to hostname-, IP- and email-verification options. openssl s_client -help lists following options: -checkhost host - check peer certificate matches host -checkemail email - check peer certificate matches email -checkip ipaddr - check peer certificate matches ipaddr which in fact are not implemented. (unknown option -check_hostname) At the same time the options -verify_hostname, -verify_ip and -verify_email are implemented, but not documented -- Richard Levitte levi...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3596] [1.0.2] -checkhost and -verify_hostname options documentation errors
Please look at https://github.com/richsalz/openssl/tree/master/apps which will be merged into master soon (I hope)
[openssl.org #3597] [PATCH] Advance to the next state variant when reusing messages.
Applied, committed and pushed. Thanks! On Tue Nov 11 00:34:37 2014, pi...@cloudflare.com wrote: Advance to the next state variant when reusing messages. Previously, state variant was not advanced, which resulted in state being stuck in the st1 variant (usually _A). This broke certificate callback retry logic when accepting connections that were using SSLv2 ClientHello (hence reusing the message), because their state never advanced to SSL3_ST_SR_CLNT_HELLO_C variant required for the retry code path. Reported by Yichun Zhang (agentzh). Signed-off-by: Piotr Sikora pi...@cloudflare.com --- ssl/s3_both.c | 1 + 1 file changed, 1 insertion(+) diff --git a/ssl/s3_both.c b/ssl/s3_both.c index beef06f..10921a2 100644 --- a/ssl/s3_both.c +++ b/ssl/s3_both.c @@ -358,6 +358,7 @@ long ssl3_get_message(SSL *s, int st1, int stn, int mt, goto f_err; } *ok=1; + s-state=stn; s-init_msg = s-init_buf-data + 4; s-init_num = (int)s-s3-tmp.message_size; return s-init_num; -- Richard Levitte levi...@openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
2014 Nov 29 Snaphots
Something did not work tonight. Please eximane why nightly snapshots suddenly cannot materialise correctly. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2014 and Happy New Year 2015 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
