From rt at openssl.org Thu Oct 1 14:18:48 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Thu, 01 Oct 2015 14:18:48 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560BE7FD.6050405@gmail.com> Message-ID: Hi, Good morning! Thanks for your response. I configured my OpenSSL with '-d' option to enable the debugging information. Where I don't know how to use it during my application running. So I used gcc GDB function to debug. My application is a multi-process program. I started my application and attached GDB to on process which will call SSL methods. I got the segmentation fault and dumped the calling stack like: (gdb) (gdb) Working Directory: /MCM_Red_Hat_Enterprise5_4_2_16old/ Home Directory: /MCM_Red_Hat_Enterprise5_4_2_16old/ (gdb) attach 3477 Attaching to program: /MCM_Red_Hat_Enterprise5_4_2_16old/mlt_serv4, process 3477 `system-supplied DSO at 0x9e6000' has disappeared; keeping its symbols. [Thread debugging using libthread_db enabled] [New Thread -1208351024 (LWP 3477)] [New Thread -1241924720 (LWP 3484)] [New Thread -1239299184 (LWP 3483)] [New Thread -1236673648 (LWP 3482)] [New Thread -1234048112 (LWP 3481)] [New Thread -1231422576 (LWP 3480)] Loaded symbols for /usr/lib/libkrb5.so.3 Loaded symbols for /usr/lib/libk5crypto.so.3 Loaded symbols for /usr/lib/libptcoresdk.so.2 Loaded symbols for /lib/libcom_err.so.2 Loaded symbols for /usr/lib/libstdc++.so.6 Loaded symbols for /usr/lib/libssl.so.1.0.0 Loaded symbols for /usr/lib/libcrypto.so.1.0.0 Loaded symbols for /lib/libdl.so.2 Loaded symbols for /lib/i686/nosegneg/libpthread.so.0 Loaded symbols for /lib/i686/nosegneg/libc.so.6 Loaded symbols for /usr/lib/libkrb5support.so.0 Loaded symbols for /lib/libresolv.so.2 Loaded symbols for /lib/libgcc_s.so.1 Loaded symbols for /lib/i686/nosegneg/libm.so.6 Loaded symbols for /lib/ld-linux.so.2 0x009e6402 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1231422576 (LWP 3480)] 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 219 if (s->renegotiate) { (gdb) where #0 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 #1 0x00db211f in ssl3_connect (s=0xb4a03ec8) at s3_clnt.c:209 #2 0x0810bf05 in ConnectSSL_ex (ssl=0xb4a03ec8, sock=8, error=0xb698f13c "072410333.qrl", diag=0xb699ac7c "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg", isDiag=2 '\002', timeout=15) at ../multi_client/source_Host_C_Code/ssl_open.c:556 #3 0x0810c26f in SSL_connect_tr_ex (sslc=0xb698f670, msg=0xb698f13c "072410333.qrl", pssl=0xb698ef10, diag=0xb699ac7c "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg", isDiag=2 '\002') at ../multi_client/source_Host_C_Code/ssl_open.c:693 #4 0x081088e1 in Givex_doSSLConnect (sslc=0xb698f670, dsp=0xb698f647 "??\217\204", CCi=0xb699ab14, IPind=1, ind2=0xb698f208, DiagFile=0xb699ac7c "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") at ../multi_client/source_Host_C_Code/openssl.c:1075 #5 0x08101441 in Givex_ConnectSSL (sslc=0xb698f670, dsp=0xb698f647 "??\217\204", CCi=0xb699ab14, Flg=0, DiagFile=0xb699ac7c "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") at ../multi_client/source_Host_C_Code/GIFT.c:213 #6 0x08103abc in sendtoGivex (TransType=68 'D', CCrq=0xb698fd6c, CCi=0xb699ab14, CCo=0xb6997d10, CCGr=0xb6990f08, OperatorId=0xb699c534 "", DiagFile=0xb699ac7c "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") at ../multi_client/source_Host_C_Code/GIFT.c:2166 #7 0x08105041 in GIFT_Authorize_cd (TransType=68 'D', AuthNum=0xb699c4af "", SecurityCode=0xb699c612 "", PromoCode=0xb699c528 "", OperatorId=0xb699c534 "", CCi=0xb699ab14, CCo=0xb6997d10, CCGr=0xb6990f08) at ../multi_client/source_Host_C_Code/GIFT.c:3013 #8 0x080b7849 in CCm_Authorize_cd (PosNum=0xb699c490 "100001", CardNo=0xb699c45b "603628465812000010140", ExpDate=0xb698ffaa "", AuthNum=0xb699c4af "", Amount=0, TransType=68 'D', CardType=51 '3', Fld3=0xb699c612 "", SAmount=0, PromoCode=0xb699c528 "", OperatorId=0xb699c534 "", CCi=0xb699ab14, CCo=0xb6997d10, CCGr=0xb6990f08, ProductCodes=0x0) at ../multi_client/source_Host_C_Code/CDCA_M.c:22148 #9 0x08059e94 in Authorize_cd (PosNum=0xb699c490 "100001", CardNo=0xb699c45b "603628465812000010140", ExpDate=0xb699c484 "", AuthNum=0xb699c4af "", Amount=0, TransType=68 'D', CardType=, Currency=0xb699c4c7 "124", Fld1=0xb699c4cb "", Fld2=0xb699c4ea "", Fld3=0xb699c612 "", SAmount=0, PromoCode=0xb699c528 "", OperatorId=0xb699c534 "", CCi=0xb699ab14, CCo=0xb6997d10, CCGr=0xb6990f08, ProductCodes=0x0) at mlt_lib4.c:353 #10 0x08064989 in do_one_transaction_post (cln_sock_id=7, CCAuth_Res=0xb6997d10, Tstr=0xb699c458, CCAuth_PC=0xb699d830, CCAuth_Main=0xb699ab14, Tcct=0xb69985f5) at mlt_srv4.c:1668 #11 0x080663f3 in hCCm_OneTransaction () at mlt_srv4.c:2100 #12 0x004a0302 in start_thread () from /lib/i686/nosegneg/libpthread.so.0 #13 0x007dc3ae in clone () from /lib/i686/nosegneg/libc.so.6 (gdb) up #1 0x00db211f in ssl3_connect (s=0xb4a03ec8) at s3_clnt.c:209 209 SSL_clear(s); (gdb) down #0 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 219 if (s->renegotiate) { (gdb) The above message shows my application crash when it tried to refer the ?renegotiate? value? I used the print command (gdb) print s->renegotiate And I got the value is : $1 = 0 /* this means the ?s->renegotiate? is 0 */ Could you help me to figure out what happened? Thanks, Tyler -----Original Message----- From: Wayming Zhang via RT [mailto:rt at openssl.org] Sent: September-30-15 9:48 AM To: Tiantian Liu Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function Is your process terminated or still alive after printing the last trace message? " Going to call SSL_connect() 15" If it is terminated already, is there any core dump file generated? If it is still alive, pstack command could help you to see what is happening. I don't see turning on debug could print any trace in SSL_Connect() funciton. If you want to see what happens inside the function, run your program under debugger and set break point in SSL_Connect(), then run it step by step. Wayming On 30/09/15 03:32, Tiantian Liu via RT wrote: > I downloaded the OpenSSL-1.0.1p. > > I configured it as : > > [root at lin5ent openssl-1.0.1p]# ./config -d --prefix=/usr/ shared > threads > > /**************************************************************** > ******The configuration result > as**************************************** > > Operating system: i686-whatever-linux2 Configuring for debug-linux-elf > Configuring for debug-linux-elf > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) > no-gmp [default] OPENSSL_NO_GMP (skip dir) > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > no-store [experimental] OPENSSL_NO_STORE (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > IsMK1MF=0 > CC =gcc > CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -g -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > EX_LIBS =-lefence -ldl > CPUID_OBJ =x86cpuid.o > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o > DES_ENC =des-586.o crypt586.o > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o > BF_ENC =bf-586.o > CAST_ENC =c_enc.o > RC4_ENC =rc4-586.o > RC5_ENC =rc5-586.o > MD5_OBJ_ASM =md5-586.o > SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o > RMD160_OBJ_ASM=rmd-586.o > CMLL_ENC =cmll-x86.o > MODES_OBJ =ghash-x86.o > ENGINES_OBJ = > PROCESSOR = > RANLIB =/usr/bin/ranlib > ARFLAGS = > PERL =/usr/bin/perl > THIRTY_TWO_BIT mode > DES_PTR used > DES_RISC1 used > DES_UNROLL used > BN_LLONG mode > RC4_INDEX mode > RC4_CHUNK is undefined > e_os2.h => include/openssl/e_os2.h > making links in crypto... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto' > crypto.h => ../include/openssl/crypto.h opensslv.h => > ../include/openssl/opensslv.h opensslconf.h => > ../include/openssl/opensslconf.h ebcdic.h => > ../include/openssl/ebcdic.h symhacks.h => > ../include/openssl/symhacks.h ossl_typ.h => > ../include/openssl/ossl_typ.h constant_time_test.c => > ../test/constant_time_test.c making links in crypto/objects... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > objects.h => ../../include/openssl/objects.h obj_mac.h => > ../../include/openssl/obj_mac.h > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > making links in crypto/md4... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > md4.h => ../../include/openssl/md4.h > md4test.c => ../../test/md4test.c > md4.c => ../../apps/md4.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > making links in crypto/md5... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > md5.h => ../../include/openssl/md5.h > md5test.c => ../../test/md5test.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > making links in crypto/sha... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > sha.h => ../../include/openssl/sha.h > shatest.c => ../../test/shatest.c > sha1test.c => ../../test/sha1test.c > sha256t.c => ../../test/sha256t.c > sha512t.c => ../../test/sha512t.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > making links in crypto/mdc2... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > mdc2.h => ../../include/openssl/mdc2.h mdc2test.c => > ../../test/mdc2test.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > making links in crypto/hmac... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/hmac' > hmac.h => ../../include/openssl/hmac.h ...... > srptest.c => ../../test/srptest.c > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/srp' > making links in crypto/cmac... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > cmac.h => ../../include/openssl/cmac.h > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto' > making links in ssl... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/ssl' > ssl.h => ../include/openssl/ssl.h > ssl2.h => ../include/openssl/ssl2.h > ssl3.h => ../include/openssl/ssl3.h > ssl23.h => ../include/openssl/ssl23.h > tls1.h => ../include/openssl/tls1.h > dtls1.h => ../include/openssl/dtls1.h > kssl.h => ../include/openssl/kssl.h > srtp.h => ../include/openssl/srtp.h > ssltest.c => ../test/ssltest.c > heartbeat_test.c => ../test/heartbeat_test.c > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/ssl' > making links in engines... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/engines' > making links in engines/ccgost... > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > make[2]: Nothing to be done for `links'. > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines' > making links in apps... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/apps' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/apps' > making links in test... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > making links in tools... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/tools' > make[1]: Nothing to be done for `links'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/tools' > generating dummy tests (if needed)... > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > make[1]: Nothing to be done for `generate'. > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > > Configured for debug-linux-elf. > > ***********************************************************/ > > > > Then I make it and got the ERROR message Told me undefined reference > to 'pthread_mutex_trylock' > Then I added '-lpthread' into the FLAG in Makefile. Then I went through and compiled successfully. > > Then I will ran my application again to see how SSL_connect() crash.... > Any requirement for me to start my application with OpenSSL (with > debug enabled)? I mean to show me more information inside > SSL_connect() > > Thanks, > Tyler > > > > > > -----Original Message----- > From: Matt Caswell via RT [mailto:rt at openssl.org] > Sent: September-29-15 10:55 AM > To: Tiantian Liu > Cc: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash > happened inside SSL_Connect function > > > > On 29/09/15 15:45, Tiantian Liu via RT wrote: >> Hi Matt, >> Thanks for prompt response! >> While I confirm with you that my application crashed INSIDE the SSL_connect() function. > Your previous email indicated it was not crashing with SSLv23_method(): > "While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as..." > > So my advice was meant for that scenario. > >> So SSL_connect has no chance to return the 'res' value to me for analysis. >> Because I inserted a debug message before and after SSL_connect(). You can see it in the following code. >> >> /* >> My debug statement wrote the " Going to call SSL_connect() 15" into my trace file >> And this message string is THE LAST message in my trace file. >> */ >> if (isDiag) { >> SerialWriteTestLine_int_Time("Going to call SSL_connect()", timeout, diag); >> } >> res = SSL_connect(ssl); >> /* >> Oooop!!! The following statement was not executed! No debug message in my trace file anymore. >> */ >> if (isDiag) { >> SerialWriteTestLine_int_Time("SSL_connect res ", res, diag); >> } >> if (res <= 0) { >> sslerror = SSL_get_error(ssl, res); >> if (sslerror == SSL_ERROR_WANT_READ) { >> isexp = is_expired(exptime); >> if (isexp == 1) { >> if (isDiag) { >> SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed Timeout", timeout, diag); >> } >> strcpy(error, "SSL connect error"); >> return 0; >> } >> continue; >> } >> >> So, do you have any idea to get more information inside the SSL_connect? > If its actually crashing then we need to see a backtrace and a wireshark packet capture. > >> Should I re-compile and re-install OpenSSL lib? >> I tried to configure OpenSSL with option '-d' to enable the debug feature, while I got compilation error. >> > You should not get a compilation error. Please post the steps you took to compile the library and the compilation error you received. > > > Matt > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Thu Oct 1 14:52:08 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 01 Oct 2015 14:52:08 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <560D4895.3010901@openssl.org> References: <560BE7FD.6050405@gmail.com> <560D4895.3010901@openssl.org> Message-ID: On 01/10/15 15:18, Tiantian Liu via RT wrote: > Hi, > > Good morning! Thanks for your response. > > I configured my OpenSSL with '-d' option to enable the debugging information. Where I don't know how to use it during my application running. Which version of OpenSSL did you download? My version 1.0.1p doesn't match up with the line numbers in your backtrace below, i.e. line 209 in s3_clnt.c is not 'SSL_clear(s);' as it appears to be for you. > Loaded symbols for /usr/lib/libkrb5.so.3 > Loaded symbols for /usr/lib/libk5crypto.so.3 > Loaded symbols for /usr/lib/libptcoresdk.so.2 > Loaded symbols for /lib/libcom_err.so.2 > Loaded symbols for /usr/lib/libstdc++.so.6 > Loaded symbols for /usr/lib/libssl.so.1.0.0 > Loaded symbols for /usr/lib/libcrypto.so.1.0.0 Where did you install the version of OpenSSL that you compiled? Did you replace the system supplied version in `/usr/lib`? If so that was probably not a good idea. > Loaded symbols for /lib/libdl.so.2 > Loaded symbols for /lib/i686/nosegneg/libpthread.so.0 > Loaded symbols for /lib/i686/nosegneg/libc.so.6 > Loaded symbols for /usr/lib/libkrb5support.so.0 > Loaded symbols for /lib/libresolv.so.2 > Loaded symbols for /lib/libgcc_s.so.1 > Loaded symbols for /lib/i686/nosegneg/libm.so.6 > Loaded symbols for /lib/ld-linux.so.2 > 0x009e6402 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1231422576 (LWP 3480)] > 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 > 219 if (s->renegotiate) { There is something not quite right about that. There is no way that line should seg fault. The deref of `s` has already occurred several times by the time it gets to that line so `s` should be sound. Either there is some memory corruption going on, or that's not really the line we're on. Matt From rt at openssl.org Thu Oct 1 14:57:30 2015 From: rt at openssl.org (Richard Moore via RT) Date: Thu, 01 Oct 2015 14:57:30 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560BE7FD.6050405@gmail.com> Message-ID: You have just leaked your credit card number to the internet. I'd suggest you cancel your card unless it is a test account. Rich. On 1 October 2015 at 15:18, Tiantian Liu via RT wrote: > Hi, > > Good morning! Thanks for your response. > > I configured my OpenSSL with '-d' option to enable the debugging > information. Where I don't know how to use it during my application running. > > So I used gcc GDB function to debug. > > My application is a multi-process program. I started my application and > attached GDB to on process which will call SSL methods. > I got the segmentation fault and dumped the calling stack like: > > > (gdb) > (gdb) Working Directory: /MCM_Red_Hat_Enterprise5_4_2_16old/ > Home Directory: /MCM_Red_Hat_Enterprise5_4_2_16old/ > > (gdb) attach 3477 > Attaching to program: /MCM_Red_Hat_Enterprise5_4_2_16old/mlt_serv4, > process 3477 > `system-supplied DSO at 0x9e6000' has disappeared; keeping its symbols. > [Thread debugging using libthread_db enabled] > [New Thread -1208351024 (LWP 3477)] > [New Thread -1241924720 (LWP 3484)] > [New Thread -1239299184 (LWP 3483)] > [New Thread -1236673648 (LWP 3482)] > [New Thread -1234048112 (LWP 3481)] > [New Thread -1231422576 (LWP 3480)] > Loaded symbols for /usr/lib/libkrb5.so.3 > Loaded symbols for /usr/lib/libk5crypto.so.3 > Loaded symbols for /usr/lib/libptcoresdk.so.2 > Loaded symbols for /lib/libcom_err.so.2 > Loaded symbols for /usr/lib/libstdc++.so.6 > Loaded symbols for /usr/lib/libssl.so.1.0.0 > Loaded symbols for /usr/lib/libcrypto.so.1.0.0 > Loaded symbols for /lib/libdl.so.2 > Loaded symbols for /lib/i686/nosegneg/libpthread.so.0 > Loaded symbols for /lib/i686/nosegneg/libc.so.6 > Loaded symbols for /usr/lib/libkrb5support.so.0 > Loaded symbols for /lib/libresolv.so.2 > Loaded symbols for /lib/libgcc_s.so.1 > Loaded symbols for /lib/i686/nosegneg/libm.so.6 > Loaded symbols for /lib/ld-linux.so.2 > 0x009e6402 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1231422576 (LWP 3480)] > 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 > 219 if (s->renegotiate) { > (gdb) where > #0 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 > #1 0x00db211f in ssl3_connect (s=0xb4a03ec8) at s3_clnt.c:209 > #2 0x0810bf05 in ConnectSSL_ex (ssl=0xb4a03ec8, sock=8, error=0xb698f13c > "072410333.qrl", diag=0xb699ac7c > "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg", isDiag=2 '\002', > timeout=15) at ../multi_client/source_Host_C_Code/ssl_open.c:556 > #3 0x0810c26f in SSL_connect_tr_ex (sslc=0xb698f670, msg=0xb698f13c > "072410333.qrl", pssl=0xb698ef10, diag=0xb699ac7c > "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg", isDiag=2 '\002') at > ../multi_client/source_Host_C_Code/ssl_open.c:693 > #4 0x081088e1 in Givex_doSSLConnect (sslc=0xb698f670, dsp=0xb698f647 > "??\217\204", CCi=0xb699ab14, IPind=1, ind2=0xb698f208, DiagFile=0xb699ac7c > "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") > at ../multi_client/source_Host_C_Code/openssl.c:1075 > #5 0x08101441 in Givex_ConnectSSL (sslc=0xb698f670, dsp=0xb698f647 > "??\217\204", CCi=0xb699ab14, Flg=0, DiagFile=0xb699ac7c > "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") at > ../multi_client/source_Host_C_Code/GIFT.c:213 > #6 0x08103abc in sendtoGivex (TransType=68 'D', CCrq=0xb698fd6c, > CCi=0xb699ab14, CCo=0xb6997d10, CCGr=0xb6990f08, OperatorId=0xb699c534 "", > DiagFile=0xb699ac7c "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") > at ../multi_client/source_Host_C_Code/GIFT.c:2166 > #7 0x08105041 in GIFT_Authorize_cd (TransType=68 'D', AuthNum=0xb699c4af > "", SecurityCode=0xb699c612 "", PromoCode=0xb699c528 "", > OperatorId=0xb699c534 "", CCi=0xb699ab14, CCo=0xb6997d10, CCGr=0xb6990f08) > at ../multi_client/source_Host_C_Code/GIFT.c:3013 > #8 0x080b7849 in CCm_Authorize_cd (PosNum=0xb699c490 "100001", > CardNo=0xb699c45b "603628465812000010140", ExpDate=0xb698ffaa "", > AuthNum=0xb699c4af "", Amount=0, TransType=68 'D', CardType=51 '3', > Fld3=0xb699c612 "", SAmount=0, > PromoCode=0xb699c528 "", OperatorId=0xb699c534 "", CCi=0xb699ab14, > CCo=0xb6997d10, CCGr=0xb6990f08, ProductCodes=0x0) at > ../multi_client/source_Host_C_Code/CDCA_M.c:22148 > #9 0x08059e94 in Authorize_cd (PosNum=0xb699c490 "100001", > CardNo=0xb699c45b "603628465812000010140", ExpDate=0xb699c484 "", > AuthNum=0xb699c4af "", Amount=0, TransType=68 'D', CardType= optimized out>, Currency=0xb699c4c7 "124", > Fld1=0xb699c4cb "", Fld2=0xb699c4ea "", Fld3=0xb699c612 "", SAmount=0, > PromoCode=0xb699c528 "", OperatorId=0xb699c534 "", CCi=0xb699ab14, > CCo=0xb6997d10, CCGr=0xb6990f08, ProductCodes=0x0) at mlt_lib4.c:353 > #10 0x08064989 in do_one_transaction_post (cln_sock_id=7, > CCAuth_Res=0xb6997d10, Tstr=0xb699c458, CCAuth_PC=0xb699d830, > CCAuth_Main=0xb699ab14, Tcct=0xb69985f5) at mlt_srv4.c:1668 > #11 0x080663f3 in hCCm_OneTransaction () at mlt_srv4.c:2100 > #12 0x004a0302 in start_thread () from /lib/i686/nosegneg/libpthread.so.0 > #13 0x007dc3ae in clone () from /lib/i686/nosegneg/libc.so.6 > (gdb) up > #1 0x00db211f in ssl3_connect (s=0xb4a03ec8) at s3_clnt.c:209 > 209 SSL_clear(s); > (gdb) down > #0 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 > 219 if (s->renegotiate) { > (gdb) > > The above message shows my application crash when it tried to refer the > ?renegotiate? value? > I used the print command > > (gdb) print s->renegotiate > And I got the value is : > $1 = 0 /* this means the ?s->renegotiate? is 0 */ > > Could you help me to figure out what happened? > Thanks, > Tyler > > > > > -----Original Message----- > From: Wayming Zhang via RT [mailto:rt at openssl.org] > Sent: September-30-15 9:48 AM > To: Tiantian Liu > Cc: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash > happened inside SSL_Connect function > > Is your process terminated or still alive after printing the last trace > message? > > " Going to call SSL_connect() 15" > > If it is terminated already, is there any core dump file generated? If it > is still alive, pstack command could help you to see what is happening. > > I don't see turning on debug could print any trace in SSL_Connect() > funciton. If you want to see what happens inside the function, run your > program under debugger and set break point in SSL_Connect(), then run it > step by step. > > Wayming > > > On 30/09/15 03:32, Tiantian Liu via RT wrote: > > I downloaded the OpenSSL-1.0.1p. > > > > I configured it as : > > > > [root at lin5ent openssl-1.0.1p]# ./config -d --prefix=/usr/ shared > > threads > > > > /**************************************************************** > > ******The configuration result > > as**************************************** > > > > Operating system: i686-whatever-linux2 Configuring for debug-linux-elf > > Configuring for debug-linux-elf > > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 > (skip dir) > > no-gmp [default] OPENSSL_NO_GMP (skip dir) > > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > > no-store [experimental] OPENSSL_NO_STORE (skip dir) > > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > > no-zlib [default] > > no-zlib-dynamic [default] > > IsMK1MF=0 > > CC =gcc > > CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DBN_DEBUG -DREF_CHECK > -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -g -march=i486 -Wall > -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > > EX_LIBS =-lefence -ldl > > CPUID_OBJ =x86cpuid.o > > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o > > DES_ENC =des-586.o crypt586.o > > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o > > BF_ENC =bf-586.o > > CAST_ENC =c_enc.o > > RC4_ENC =rc4-586.o > > RC5_ENC =rc5-586.o > > MD5_OBJ_ASM =md5-586.o > > SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o > > RMD160_OBJ_ASM=rmd-586.o > > CMLL_ENC =cmll-x86.o > > MODES_OBJ =ghash-x86.o > > ENGINES_OBJ = > > PROCESSOR = > > RANLIB =/usr/bin/ranlib > > ARFLAGS = > > PERL =/usr/bin/perl > > THIRTY_TWO_BIT mode > > DES_PTR used > > DES_RISC1 used > > DES_UNROLL used > > BN_LLONG mode > > RC4_INDEX mode > > RC4_CHUNK is undefined > > e_os2.h => include/openssl/e_os2.h > > making links in crypto... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto' > > crypto.h => ../include/openssl/crypto.h opensslv.h => > > ../include/openssl/opensslv.h opensslconf.h => > > ../include/openssl/opensslconf.h ebcdic.h => > > ../include/openssl/ebcdic.h symhacks.h => > > ../include/openssl/symhacks.h ossl_typ.h => > > ../include/openssl/ossl_typ.h constant_time_test.c => > > ../test/constant_time_test.c making links in crypto/objects... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > > objects.h => ../../include/openssl/objects.h obj_mac.h => > > ../../include/openssl/obj_mac.h > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > > making links in crypto/md4... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > > md4.h => ../../include/openssl/md4.h > > md4test.c => ../../test/md4test.c > > md4.c => ../../apps/md4.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > > making links in crypto/md5... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > > md5.h => ../../include/openssl/md5.h > > md5test.c => ../../test/md5test.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > > making links in crypto/sha... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > > sha.h => ../../include/openssl/sha.h > > shatest.c => ../../test/shatest.c > > sha1test.c => ../../test/sha1test.c > > sha256t.c => ../../test/sha256t.c > > sha512t.c => ../../test/sha512t.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > > making links in crypto/mdc2... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > > mdc2.h => ../../include/openssl/mdc2.h mdc2test.c => > > ../../test/mdc2test.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > > making links in crypto/hmac... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/hmac' > > hmac.h => ../../include/openssl/hmac.h ...... > > srptest.c => ../../test/srptest.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/srp' > > making links in crypto/cmac... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > > cmac.h => ../../include/openssl/cmac.h > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto' > > making links in ssl... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/ssl' > > ssl.h => ../include/openssl/ssl.h > > ssl2.h => ../include/openssl/ssl2.h > > ssl3.h => ../include/openssl/ssl3.h > > ssl23.h => ../include/openssl/ssl23.h > > tls1.h => ../include/openssl/tls1.h > > dtls1.h => ../include/openssl/dtls1.h > > kssl.h => ../include/openssl/kssl.h > > srtp.h => ../include/openssl/srtp.h > > ssltest.c => ../test/ssltest.c > > heartbeat_test.c => ../test/heartbeat_test.c > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/ssl' > > making links in engines... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/engines' > > making links in engines/ccgost... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > > make[2]: Nothing to be done for `links'. > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines' > > making links in apps... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/apps' > > make[1]: Nothing to be done for `links'. > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/apps' > > making links in test... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > > make[1]: Nothing to be done for `links'. > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > > making links in tools... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/tools' > > make[1]: Nothing to be done for `links'. > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/tools' > > generating dummy tests (if needed)... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > > make[1]: Nothing to be done for `generate'. > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > > > > Configured for debug-linux-elf. > > > > ***********************************************************/ > > > > > > > > Then I make it and got the ERROR message Told me undefined reference > > to 'pthread_mutex_trylock' > > Then I added '-lpthread' into the FLAG in Makefile. Then I went through > and compiled successfully. > > > > Then I will ran my application again to see how SSL_connect() crash.... > > Any requirement for me to start my application with OpenSSL (with > > debug enabled)? I mean to show me more information inside > > SSL_connect() > > > > Thanks, > > Tyler > > > > > > > > > > > > -----Original Message----- > > From: Matt Caswell via RT [mailto:rt at openssl.org] > > Sent: September-29-15 10:55 AM > > To: Tiantian Liu > > Cc: openssl-dev at openssl.org > > Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash > > happened inside SSL_Connect function > > > > > > > > On 29/09/15 15:45, Tiantian Liu via RT wrote: > >> Hi Matt, > >> Thanks for prompt response! > >> While I confirm with you that my application crashed INSIDE the > SSL_connect() function. > > Your previous email indicated it was not crashing with SSLv23_method(): > > "While the above code didn't work. I couldn't reach the server. Though > the SSL_connect() didn't crash, it returned as..." > > > > So my advice was meant for that scenario. > > > >> So SSL_connect has no chance to return the 'res' value to me for > analysis. > >> Because I inserted a debug message before and after SSL_connect(). You > can see it in the following code. > >> > >> /* > >> My debug statement wrote the " Going to call SSL_connect() > 15" into my trace file > >> And this message string is THE LAST message in my trace > file. > >> */ > >> if (isDiag) { > >> SerialWriteTestLine_int_Time("Going to call > SSL_connect()", timeout, diag); > >> } > >> res = SSL_connect(ssl); > >> /* > >> Oooop!!! The following statement was not executed! No debug > message in my trace file anymore. > >> */ > >> if (isDiag) { > >> SerialWriteTestLine_int_Time("SSL_connect res ", res, > diag); > >> } > >> if (res <= 0) { > >> sslerror = SSL_get_error(ssl, res); > >> if (sslerror == SSL_ERROR_WANT_READ) { > >> isexp = is_expired(exptime); > >> if (isexp == 1) { > >> if (isDiag) { > >> > SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed > Timeout", timeout, diag); > >> } > >> strcpy(error, "SSL connect error"); > >> return 0; > >> } > >> continue; > >> } > >> > >> So, do you have any idea to get more information inside the SSL_connect? > > If its actually crashing then we need to see a backtrace and a wireshark > packet capture. > > > >> Should I re-compile and re-install OpenSSL lib? > >> I tried to configure OpenSSL with option '-d' to enable the debug > feature, while I got compilation error. > >> > > You should not get a compilation error. Please post the steps you took > to compile the library and the compilation error you received. > > > > > > Matt > > > > > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Thu Oct 1 15:00:27 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Thu, 01 Oct 2015 15:00:27 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: Message-ID: That is ok. Just a test card. Thanks for your remainder. While, I am sure installed the OpenSSL1.01p to /usr/lib. Because I configured it with --prefix=/usr/. I can -redo it and confirm. And I will keep updating the ticket. Thanks, Tyler -----Original Message----- From: Richard Moore via RT [mailto:rt at openssl.org] Sent: October-01-15 10:58 AM To: Tiantian Liu Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function You have just leaked your credit card number to the internet. I'd suggest you cancel your card unless it is a test account. Rich. On 1 October 2015 at 15:18, Tiantian Liu via RT wrote: > Hi, > > Good morning! Thanks for your response. > > I configured my OpenSSL with '-d' option to enable the debugging > information. Where I don't know how to use it during my application running. > > So I used gcc GDB function to debug. > > My application is a multi-process program. I started my application > and attached GDB to on process which will call SSL methods. > I got the segmentation fault and dumped the calling stack like: > > > (gdb) > (gdb) Working Directory: /MCM_Red_Hat_Enterprise5_4_2_16old/ > Home Directory: /MCM_Red_Hat_Enterprise5_4_2_16old/ > > (gdb) attach 3477 > Attaching to program: /MCM_Red_Hat_Enterprise5_4_2_16old/mlt_serv4, > process 3477 > `system-supplied DSO at 0x9e6000' has disappeared; keeping its symbols. > [Thread debugging using libthread_db enabled] [New Thread -1208351024 > (LWP 3477)] [New Thread -1241924720 (LWP 3484)] [New Thread > -1239299184 (LWP 3483)] [New Thread -1236673648 (LWP 3482)] [New > Thread -1234048112 (LWP 3481)] [New Thread -1231422576 (LWP 3480)] > Loaded symbols for /usr/lib/libkrb5.so.3 Loaded symbols for > /usr/lib/libk5crypto.so.3 Loaded symbols for > /usr/lib/libptcoresdk.so.2 Loaded symbols for /lib/libcom_err.so.2 > Loaded symbols for /usr/lib/libstdc++.so.6 Loaded symbols for > /usr/lib/libssl.so.1.0.0 Loaded symbols for > /usr/lib/libcrypto.so.1.0.0 Loaded symbols for /lib/libdl.so.2 Loaded > symbols for /lib/i686/nosegneg/libpthread.so.0 > Loaded symbols for /lib/i686/nosegneg/libc.so.6 Loaded symbols for > /usr/lib/libkrb5support.so.0 Loaded symbols for /lib/libresolv.so.2 > Loaded symbols for /lib/libgcc_s.so.1 Loaded symbols for > /lib/i686/nosegneg/libm.so.6 Loaded symbols for /lib/ld-linux.so.2 > 0x009e6402 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1231422576 (LWP 3480)] > 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 > 219 if (s->renegotiate) { > (gdb) where > #0 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 > #1 0x00db211f in ssl3_connect (s=0xb4a03ec8) at s3_clnt.c:209 > #2 0x0810bf05 in ConnectSSL_ex (ssl=0xb4a03ec8, sock=8, > error=0xb698f13c "072410333.qrl", diag=0xb699ac7c > "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg", isDiag=2 '\002', > timeout=15) at ../multi_client/source_Host_C_Code/ssl_open.c:556 > #3 0x0810c26f in SSL_connect_tr_ex (sslc=0xb698f670, msg=0xb698f13c > "072410333.qrl", pssl=0xb698ef10, diag=0xb699ac7c > "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg", isDiag=2 '\002') at > ../multi_client/source_Host_C_Code/ssl_open.c:693 > #4 0x081088e1 in Givex_doSSLConnect (sslc=0xb698f670, dsp=0xb698f647 > "??\217\204", CCi=0xb699ab14, IPind=1, ind2=0xb698f208, > DiagFile=0xb699ac7c > "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") > at ../multi_client/source_Host_C_Code/openssl.c:1075 > #5 0x08101441 in Givex_ConnectSSL (sslc=0xb698f670, dsp=0xb698f647 > "??\217\204", CCi=0xb699ab14, Flg=0, DiagFile=0xb699ac7c > "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") at > ../multi_client/source_Host_C_Code/GIFT.c:213 > #6 0x08103abc in sendtoGivex (TransType=68 'D', CCrq=0xb698fd6c, > CCi=0xb699ab14, CCo=0xb6997d10, CCGr=0xb6990f08, OperatorId=0xb699c534 > "", DiagFile=0xb699ac7c "/MCM_Red_Hat_Enterprise5_4_2_16old/log/211.dg") > at ../multi_client/source_Host_C_Code/GIFT.c:2166 > #7 0x08105041 in GIFT_Authorize_cd (TransType=68 'D', > AuthNum=0xb699c4af "", SecurityCode=0xb699c612 "", > PromoCode=0xb699c528 "", > OperatorId=0xb699c534 "", CCi=0xb699ab14, CCo=0xb6997d10, CCGr=0xb6990f08) > at ../multi_client/source_Host_C_Code/GIFT.c:3013 > #8 0x080b7849 in CCm_Authorize_cd (PosNum=0xb699c490 "100001", > CardNo=0xb699c45b "603628465812000010140", ExpDate=0xb698ffaa "", > AuthNum=0xb699c4af "", Amount=0, TransType=68 'D', CardType=51 '3', > Fld3=0xb699c612 "", SAmount=0, > PromoCode=0xb699c528 "", OperatorId=0xb699c534 "", CCi=0xb699ab14, > CCo=0xb6997d10, CCGr=0xb6990f08, ProductCodes=0x0) at > ../multi_client/source_Host_C_Code/CDCA_M.c:22148 > #9 0x08059e94 in Authorize_cd (PosNum=0xb699c490 "100001", > CardNo=0xb699c45b "603628465812000010140", ExpDate=0xb699c484 "", > AuthNum=0xb699c4af "", Amount=0, TransType=68 'D', CardType= optimized out>, Currency=0xb699c4c7 "124", > Fld1=0xb699c4cb "", Fld2=0xb699c4ea "", Fld3=0xb699c612 "", > SAmount=0, > PromoCode=0xb699c528 "", OperatorId=0xb699c534 "", CCi=0xb699ab14, > CCo=0xb6997d10, CCGr=0xb6990f08, ProductCodes=0x0) at mlt_lib4.c:353 > #10 0x08064989 in do_one_transaction_post (cln_sock_id=7, > CCAuth_Res=0xb6997d10, Tstr=0xb699c458, CCAuth_PC=0xb699d830, > CCAuth_Main=0xb699ab14, Tcct=0xb69985f5) at mlt_srv4.c:1668 > #11 0x080663f3 in hCCm_OneTransaction () at mlt_srv4.c:2100 > #12 0x004a0302 in start_thread () from > /lib/i686/nosegneg/libpthread.so.0 > #13 0x007dc3ae in clone () from /lib/i686/nosegneg/libc.so.6 > (gdb) up > #1 0x00db211f in ssl3_connect (s=0xb4a03ec8) at s3_clnt.c:209 > 209 SSL_clear(s); > (gdb) down > #0 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 > 219 if (s->renegotiate) { > (gdb) > > The above message shows my application crash when it tried to refer > the ?renegotiate? value? > I used the print command > > (gdb) print s->renegotiate > And I got the value is : > $1 = 0 /* this means the ?s->renegotiate? is 0 */ > > Could you help me to figure out what happened? > Thanks, > Tyler > > > > > -----Original Message----- > From: Wayming Zhang via RT [mailto:rt at openssl.org] > Sent: September-30-15 9:48 AM > To: Tiantian Liu > Cc: openssl-dev at openssl.org > Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash > happened inside SSL_Connect function > > Is your process terminated or still alive after printing the last > trace message? > > " Going to call SSL_connect() 15" > > If it is terminated already, is there any core dump file generated? If > it is still alive, pstack command could help you to see what is happening. > > I don't see turning on debug could print any trace in SSL_Connect() > funciton. If you want to see what happens inside the function, run > your program under debugger and set break point in SSL_Connect(), then > run it step by step. > > Wayming > > > On 30/09/15 03:32, Tiantian Liu via RT wrote: > > I downloaded the OpenSSL-1.0.1p. > > > > I configured it as : > > > > [root at lin5ent openssl-1.0.1p]# ./config -d --prefix=/usr/ shared > > threads > > > > /**************************************************************** > > ******The configuration result > > as**************************************** > > > > Operating system: i686-whatever-linux2 Configuring for > > debug-linux-elf Configuring for debug-linux-elf > > no-ec_nistp_64_gcc_128 [default] > > OPENSSL_NO_EC_NISTP_64_GCC_128 > (skip dir) > > no-gmp [default] OPENSSL_NO_GMP (skip dir) > > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > > no-md2 [default] OPENSSL_NO_MD2 (skip dir) > > no-rc5 [default] OPENSSL_NO_RC5 (skip dir) > > no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) > > no-sctp [default] OPENSSL_NO_SCTP (skip dir) > > no-store [experimental] OPENSSL_NO_STORE (skip dir) > > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > > no-zlib [default] > > no-zlib-dynamic [default] > > IsMK1MF=0 > > CC =gcc > > CFLAG =-fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -DBN_DEBUG -DREF_CHECK > -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DL_ENDIAN -g -march=i486 > -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 > -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM > -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM > -DWHIRLPOOL_ASM -DGHASH_ASM > > EX_LIBS =-lefence -ldl > > CPUID_OBJ =x86cpuid.o > > BN_ASM =bn-586.o co-586.o x86-mont.o x86-gf2m.o > > DES_ENC =des-586.o crypt586.o > > AES_ENC =aes-586.o vpaes-x86.o aesni-x86.o > > BF_ENC =bf-586.o > > CAST_ENC =c_enc.o > > RC4_ENC =rc4-586.o > > RC5_ENC =rc5-586.o > > MD5_OBJ_ASM =md5-586.o > > SHA1_OBJ_ASM =sha1-586.o sha256-586.o sha512-586.o > > RMD160_OBJ_ASM=rmd-586.o > > CMLL_ENC =cmll-x86.o > > MODES_OBJ =ghash-x86.o > > ENGINES_OBJ = > > PROCESSOR = > > RANLIB =/usr/bin/ranlib > > ARFLAGS = > > PERL =/usr/bin/perl > > THIRTY_TWO_BIT mode > > DES_PTR used > > DES_RISC1 used > > DES_UNROLL used > > BN_LLONG mode > > RC4_INDEX mode > > RC4_CHUNK is undefined > > e_os2.h => include/openssl/e_os2.h > > making links in crypto... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto' > > crypto.h => ../include/openssl/crypto.h opensslv.h => > > ../include/openssl/opensslv.h opensslconf.h => > > ../include/openssl/opensslconf.h ebcdic.h => > > ../include/openssl/ebcdic.h symhacks.h => > > ../include/openssl/symhacks.h ossl_typ.h => > > ../include/openssl/ossl_typ.h constant_time_test.c => > > ../test/constant_time_test.c making links in crypto/objects... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > > objects.h => ../../include/openssl/objects.h obj_mac.h => > > ../../include/openssl/obj_mac.h > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/objects' > > making links in crypto/md4... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > > md4.h => ../../include/openssl/md4.h md4test.c => > > ../../test/md4test.c md4.c => ../../apps/md4.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md4' > > making links in crypto/md5... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > > md5.h => ../../include/openssl/md5.h md5test.c => > > ../../test/md5test.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/md5' > > making links in crypto/sha... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > > sha.h => ../../include/openssl/sha.h shatest.c => > > ../../test/shatest.c sha1test.c => ../../test/sha1test.c sha256t.c > > => ../../test/sha256t.c sha512t.c => ../../test/sha512t.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/sha' > > making links in crypto/mdc2... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > > mdc2.h => ../../include/openssl/mdc2.h mdc2test.c => > > ../../test/mdc2test.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/mdc2' > > making links in crypto/hmac... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/hmac' > > hmac.h => ../../include/openssl/hmac.h ...... > > srptest.c => ../../test/srptest.c > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/srp' > > making links in crypto/cmac... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > > cmac.h => ../../include/openssl/cmac.h > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto/cmac' > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/crypto' > > making links in ssl... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/ssl' > > ssl.h => ../include/openssl/ssl.h > > ssl2.h => ../include/openssl/ssl2.h > > ssl3.h => ../include/openssl/ssl3.h > > ssl23.h => ../include/openssl/ssl23.h tls1.h => > > ../include/openssl/tls1.h dtls1.h => ../include/openssl/dtls1.h > > kssl.h => ../include/openssl/kssl.h srtp.h => > > ../include/openssl/srtp.h ssltest.c => ../test/ssltest.c > > heartbeat_test.c => ../test/heartbeat_test.c > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/ssl' > > making links in engines... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/engines' > > making links in engines/ccgost... > > make[2]: Entering directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > > make[2]: Nothing to be done for `links'. > > make[2]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines/ccgost' > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/engines' > > making links in apps... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/apps' > > make[1]: Nothing to be done for `links'. > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/apps' > > making links in test... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > > make[1]: Nothing to be done for `links'. > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > > making links in tools... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/tools' > > make[1]: Nothing to be done for `links'. > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/tools' > > generating dummy tests (if needed)... > > make[1]: Entering directory `/home/tyler28/openssl-1.0.1p/test' > > make[1]: Nothing to be done for `generate'. > > make[1]: Leaving directory `/home/tyler28/openssl-1.0.1p/test' > > > > Configured for debug-linux-elf. > > > > ***********************************************************/ > > > > > > > > Then I make it and got the ERROR message Told me undefined > > reference to 'pthread_mutex_trylock' > > Then I added '-lpthread' into the FLAG in Makefile. Then I went > > through > and compiled successfully. > > > > Then I will ran my application again to see how SSL_connect() crash.... > > Any requirement for me to start my application with OpenSSL (with > > debug enabled)? I mean to show me more information inside > > SSL_connect() > > > > Thanks, > > Tyler > > > > > > > > > > > > -----Original Message----- > > From: Matt Caswell via RT [mailto:rt at openssl.org] > > Sent: September-29-15 10:55 AM > > To: Tiantian Liu > > Cc: openssl-dev at openssl.org > > Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash > > happened inside SSL_Connect function > > > > > > > > On 29/09/15 15:45, Tiantian Liu via RT wrote: > >> Hi Matt, > >> Thanks for prompt response! > >> While I confirm with you that my application crashed INSIDE the > SSL_connect() function. > > Your previous email indicated it was not crashing with SSLv23_method(): > > "While the above code didn't work. I couldn't reach the server. > > Though > the SSL_connect() didn't crash, it returned as..." > > > > So my advice was meant for that scenario. > > > >> So SSL_connect has no chance to return the 'res' value to me for > analysis. > >> Because I inserted a debug message before and after SSL_connect(). > >> You > can see it in the following code. > >> > >> /* > >> My debug statement wrote the " Going to call > >> SSL_connect() > 15" into my trace file > >> And this message string is THE LAST message in my > >> trace > file. > >> */ > >> if (isDiag) { > >> SerialWriteTestLine_int_Time("Going to call > SSL_connect()", timeout, diag); > >> } > >> res = SSL_connect(ssl); > >> /* > >> Oooop!!! The following statement was not executed! No > >> debug > message in my trace file anymore. > >> */ > >> if (isDiag) { > >> SerialWriteTestLine_int_Time("SSL_connect res ", res, > diag); > >> } > >> if (res <= 0) { > >> sslerror = SSL_get_error(ssl, res); > >> if (sslerror == SSL_ERROR_WANT_READ) { > >> isexp = is_expired(exptime); > >> if (isexp == 1) { > >> if (isDiag) { > >> > SerialWriteTestLine_int_Time("ConnectSSL [SSL_connect(ssl)] failed > Timeout", timeout, diag); > >> } > >> strcpy(error, "SSL connect error"); > >> return 0; > >> } > >> continue; > >> } > >> > >> So, do you have any idea to get more information inside the SSL_connect? > > If its actually crashing then we need to see a backtrace and a > > wireshark > packet capture. > > > >> Should I re-compile and re-install OpenSSL lib? > >> I tried to configure OpenSSL with option '-d' to enable the debug > feature, while I got compilation error. > >> > > You should not get a compilation error. Please post the steps you > > took > to compile the library and the compilation error you received. > > > > > > Matt > > > > > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From marquess at openssl.com Thu Oct 1 17:05:56 2015 From: marquess at openssl.com (Steve Marquess) Date: Thu, 1 Oct 2015 13:05:56 -0400 Subject: [openssl-dev] [openssl.org #4055] FIPS Object Module User Guide corrections needed for (*get_entropy)() In-Reply-To: References: Message-ID: <560D67F4.1050906@openssl.com> On 09/21/2015 08:00 PM, Gibbons, Lee D via RT wrote: > This is to highlight a bug in the FIPS Object Module 2.10 and corrective documentation in its User Guide. > > The User Guide for the FIPS Object Module 2.10 describes the (*get_entropy)() callback: > > size_t (*get_entropy)(DRBG_CTX *ctx, unsigned char **pout, > int entropy, size_t min_len, size_t max_len) > > "A call to this function requests entropy bits of entropy in a buffer of between min_len and > max_len size bytes inclusive. The values of these are mechanism specific and taken from > SP800-90 tables. This callback should then return the amount of data in the buffer *pout and the > length in the return value, or zero in case of being unable to retrieve sufficient entropy." > > The caller of (*get_entropy)() is the static function fips_get_entropy(). Notice how it constructs the value, which should be in bits: > > rv = dctx->get_entropy(dctx, &tout, entropy + bl, > min_len + bl, max_len + bl); > *pout = tout + bl; > if (rv < (min_len + bl) || (rv % bl)) > return 0; > > The "entropy + bl" expression is mixing types, adding bits and bytes together. Anyone defining a (*get_entropy)() callback had better ignore the parameter. What's more, the callback had better return rounded up to a dctx->entropy_blocklen boundary or face failure. The User Guide mentions none of this. > > I realize the FIPS Object Module is frozen. The documentation should be corrected to expose the real restrictions on the callback. Doug, it took awhile to respond to this because I had to check with one of my smarter colleagues (Steve Henson in this case). He confirms the bug, which fortunately is easy to work around and only matters when an application supplies external entropy callbacks (which few will). Documenting it coherently is another matter. Entropy is a bit of a mess in FIPS 140-2 due to the mandated continuous PRNG test which is completely useless and it very clearly doesn't fit properly with the new DRBGs and especially not entropy sources. For the #1747 validation we specifically asked if it was required were told said yes. The poor fit with entropy sources is that it's perfectly legal for an entropy source to provide the entropy in a non-uniform way. Say 256 bits of entropy at the start of a large buffer and the rest nothing (but not all zeroes!). If the input to the PRNG test is supplied as a big buffer like that the DRBG continuous test will compare the first block against the rest and then discard the first block which might remove a disproportionate amount of entropy. So after pondering a bit I came up with the following new text for section 6.1.1 of the User Guide. Any errors of omission or commission are mine, not Steve's: ----(addition to Section 6.1.1) Few applications provide external entropy callbacks, but due to a bug in the callback code those that do define a (*get_entropy)() callback should have that return at least two full "blocks" of entropy. This is because the FIPS 140-2 mandated continuous PRNG test has to be applied to the entropy source. It has to compare consecutive blocks (discarding the first) which means the entropy source needs to supply a multiple of the block size. The solution isn't obvious so a detailed discusson follows. FIPS_drbg_get_strength() returns the strength of the DRBG context which is the number of bits of entropy needed to seed the DRBG without the continuous PRNG test. When an application adds its own entropy callbacks it has to tell the FIPS module what the block length of the entropy source is. So arguably the entropy parameter with the continuous PRNG test is: FIPS_drbg_get_strength(dctx) + block_length * 8 But, that calculation determines a maximum value and an entropy source could conceivably supply less. For instance, suppose we want 256 bits of entropy and the callback supplies it as high grade entropy uniformly in a 32 byte buffer (the absolute minimum) and has a 16 byte block length. An extra block is needed for the PRNG test so we should supply a 48 byte buffer (three blocks) and effectively 384 bits of entropy. Now suppose we have a low grade entropy source which provides just 1 bit of entropy per byte. Again assume it is uniform (e.g. we don't get 8 bits of entropy in byte 1 and nothing in the next 7). Again lets have a block size of 16 bytes. This time to get 256 bits of entropy the source must provides it in a 256 byte buffer. An extra block is required which makes 272 bytes but because we only have 1 bit of entropy per byte it just needs to supply 272 bits of entropy. ---- -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rt at openssl.org Thu Oct 1 18:43:17 2015 From: rt at openssl.org (Tiantian Liu via RT) Date: Thu, 01 Oct 2015 18:43:17 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560D4895.3010901@openssl.org> Message-ID: Hi, I did another debug. I found one strange issue, and post the trace information below: Loaded symbols for /usr/lib/libcrypto.so.1.0.0 Loaded symbols for /lib/libdl.so.2 Loaded symbols for /lib/i686/nosegneg/libpthread.so.0 Loaded symbols for /lib/i686/nosegneg/libc.so.6 Loaded symbols for /usr/lib/libkrb5support.so.0 Loaded symbols for /lib/libresolv.so.2 Loaded symbols for /lib/libgcc_s.so.1 Loaded symbols for /lib/i686/nosegneg/libm.so.6 Loaded symbols for /lib/ld-linux.so.2 0x00cea402 in __kernel_vsyscall () (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1232073840 (LWP 17217)] 0x004ba332 in ssl3_clear (s=0xb4964ec8) at s3_lib.c:3069 3069 if (s->next_proto_negotiated) { (gdb) list 3064 s->s3->num_renegotiations = 0; 3065 s->s3->in_read_app_data = 0; 3066 s->version = SSL3_VERSION; 3067 3068 #if !defined(OPENSSL_NO_TLSEXT) && !defined(OPENSSL_NO_NEXTPROTONEG) 3069 if (s->next_proto_negotiated) { 3070 OPENSSL_free(s->next_proto_negotiated); 3071 s->next_proto_negotiated = NULL; 3072 s->next_proto_negotiated_len = 0; 3073 } (gdb) where #0 0x004ba332 in ssl3_clear (s=0xb4964ec8) at s3_lib.c:3069 #1 0x004c5f31 in tls1_clear (s=0xb4964ec8) at t1_lib.c:172 #2 0x004b9f08 in ssl3_new (s=0xb4964ec8) at s3_lib.c:2950 #3 0x004c5e98 in tls1_new (s=0xb4964ec8) at t1_lib.c:154 #4 0x00300376 in SSL_new () from /usr/lib/libptcoresdk.so.2 #5 0x00000144 in ?? () #6 0x00a2edf0 in _dl_runtime_resolve () from /lib/ld-linux.so.2 #7 0x0810c1a9 in SSL_connect_tr_ex (sslc=0x1, msg=0x6d2d326c
, pssl=0xc, diag=0x2d336c73
, isDiag=-56 '?') at ../multi_client/source_Host_C_Cod Previous frame inner to this frame (corrupt stack?) (gdb) quit The program is running. Quit anyway (and detach it)? (y or n) y I found my application called SSL_new from /usr/lib/libptcoresdk.so.2, which is third party library. I think it should call the SSL_new from your Openssl library, like /usr/lib/libssl.so.1.0.0. right? Thanks, Tyler -----Original Message----- From: Matt Caswell via RT [mailto:rt at openssl.org] Sent: October-01-15 10:52 AM To: Tiantian Liu Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function On 01/10/15 15:18, Tiantian Liu via RT wrote: > Hi, > > Good morning! Thanks for your response. > > I configured my OpenSSL with '-d' option to enable the debugging information. Where I don't know how to use it during my application running. Which version of OpenSSL did you download? My version 1.0.1p doesn't match up with the line numbers in your backtrace below, i.e. line 209 in s3_clnt.c is not 'SSL_clear(s);' as it appears to be for you. > Loaded symbols for /usr/lib/libkrb5.so.3 Loaded symbols for > /usr/lib/libk5crypto.so.3 Loaded symbols for > /usr/lib/libptcoresdk.so.2 Loaded symbols for /lib/libcom_err.so.2 > Loaded symbols for /usr/lib/libstdc++.so.6 Loaded symbols for > /usr/lib/libssl.so.1.0.0 Loaded symbols for > /usr/lib/libcrypto.so.1.0.0 Where did you install the version of OpenSSL that you compiled? Did you replace the system supplied version in `/usr/lib`? If so that was probably not a good idea. > Loaded symbols for /lib/libdl.so.2 > Loaded symbols for /lib/i686/nosegneg/libpthread.so.0 > Loaded symbols for /lib/i686/nosegneg/libc.so.6 Loaded symbols for > /usr/lib/libkrb5support.so.0 Loaded symbols for /lib/libresolv.so.2 > Loaded symbols for /lib/libgcc_s.so.1 Loaded symbols for > /lib/i686/nosegneg/libm.so.6 Loaded symbols for /lib/ld-linux.so.2 > 0x009e6402 in __kernel_vsyscall () > (gdb) c > Continuing. > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread -1231422576 (LWP 3480)] > 0x00dd87e8 in SSL_clear (s=0xb4a03ec8) at ssl_lib.c:219 > 219 if (s->renegotiate) { There is something not quite right about that. There is no way that line should seg fault. The deref of `s` has already occurred several times by the time it gets to that line so `s` should be sound. Either there is some memory corruption going on, or that's not really the line we're on. Matt From openssl-users at dukhovni.org Thu Oct 1 18:55:53 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 1 Oct 2015 18:55:53 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560D4895.3010901@openssl.org> Message-ID: <20151001185552.GJ18165@mournblade.imrryr.org> On Thu, Oct 01, 2015 at 06:43:17PM +0000, Tiantian Liu via RT wrote: > #3 0x004c5e98 in tls1_new (s=0xb4964ec8) at t1_lib.c:154 > #4 0x00300376 in SSL_new () from /usr/lib/libptcoresdk.so.2 > > I found my application called SSL_new from /usr/lib/libptcoresdk.so.2, which is third party library. > > I think it should call the SSL_new from your Openssl library, like /usr/lib/libssl.so.1.0.0. right? Yes, this is an instance of "DLL hell". You need to link with the right libssl. If libptcoresdk conflicts with the OpenSSL API, you can't use both OpenSSL and that library. -- Viktor. From rt at openssl.org Thu Oct 1 20:41:46 2015 From: rt at openssl.org (Chen, Feng via RT) Date: Thu, 01 Oct 2015 20:41:46 +0000 Subject: [openssl-dev] [openssl.org #4067] Bug - Header files in include folder differ for different extractiing methods In-Reply-To: References: Message-ID: Hi OpenSSL, I downloaded OpenSSL 1.0.0s.tar.gz and extracted files using following three ways. The header files in "openssl 1.0.0s\include\openssl" folder are different. I am working on Windows 7 Enterprise 64-bits with Service Pack 1. 1. Use Cygwin (version 1.7.25) command "tar xvf" All header files have type "C/C++ Header" and size 1KB. The contents look like: !??. . / . . / c r y p t o / a e s / a e s . h But those symlinks DO NOT work on Windows. 2. Highlight the tar.gz file, click right mouse, select "Extract Files" All header files are of "SYMLINK" type and 0KB. The symbolic link works fine. Whenever I opened it in text editor or displayed it in Command windows, the actual file is displayed. 3. Download and Install 7-zip program from www.7-zip.org, then use "Open Archive" to open tar.gz, then right click the tar file and open, drag the folder to Desktop All header files are real header files, not symbolic links. Is this a bug in packaging? What is the expected results on Windows? Thanks, Feng Chen _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From vince.technicaladdress at gmail.com Thu Oct 1 22:55:27 2015 From: vince.technicaladdress at gmail.com (vince technical address) Date: Fri, 2 Oct 2015 00:55:27 +0200 Subject: [openssl-dev] OCSP - BIO_get_fd fileDescriptor 0 invalid Message-ID: Hi, Can you tell me why in the source file "ocsp.c" (apps directory), the test on the return of the function BIO_get_fd defines 0 as an invalid file descriptor? if (BIO_get_fd (CBIO, & fd) <= 0) should be if (BIO_get_fd (CBIO, & fd) <0) Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Oct 2 02:06:12 2015 From: rt at openssl.org (vince technical address via RT) Date: Fri, 02 Oct 2015 02:06:12 +0000 Subject: [openssl-dev] [openssl.org #4068] Bug ocsp - bio_get_fd In-Reply-To: References: Message-ID: Hi, Can you tell me why in the source file "ocsp.c" (apps directory), the test on the return of the function BIO_get_fd defines 0 as an invalid file descriptor? if (BIO_get_fd (CBIO, & fd) <= 0) should be if (BIO_get_fd (CBIO, & fd) <0) Thank you -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Oct 2 11:26:36 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 02 Oct 2015 11:26:36 +0000 Subject: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length) In-Reply-To: <9318543.O2f6AukmLt@pintsize.usersys.redhat.com> References: <9318543.O2f6AukmLt@pintsize.usersys.redhat.com> Message-ID: Current git checkout of 1.0.1, 1.0.2 and master accept malformed Client Hello messages. If the client sends a Client Hello message with extensions.length field equal to 0, but padded with bytes FF01 0001 00 then the Server Hello will contain the renegotiation_info extension. This is in violation of RFC 3546 and RFC 4366 MUST: A server that supports the extensions mechanism MUST accept only client hello messages in either the original or extended ClientHello format, and (as for all other messages) MUST check that the amount of data in the message precisely matches one of these formats; if not then it MUST send a fatal "decode_error" alert. This overrides the "Forward compatibility note" in [TLS]. as well as the RFC 5246 MUST clause: A server MUST accept ClientHello messages both with and without the extensions field, and (as for all other messages) it MUST check that the amount of data in the message precisely matches one of these formats; if not, then it MUST send a fatal "decode_error" alert. Reproducer: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt -nodes -batch openssl s_server -key localhost.key -cert localhost.crt -www in other console: pip install --pre tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=. python scripts/test-truncating-of-client-hello.py -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Oct 2 11:51:10 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 02 Oct 2015 11:51:10 +0000 Subject: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length) In-Reply-To: <20151002115102.GA22500@kronk.local> References: <9318543.O2f6AukmLt@pintsize.usersys.redhat.com> <20151002115102.GA22500@kronk.local> Message-ID: On Fri, Oct 02, 2015 at 11:26:36am +0000, Hubert Kario via RT wrote: > Current git checkout of 1.0.1, 1.0.2 and master accept malformed Client > Hello messages. > > If the client sends a Client Hello message with extensions.length field > equal to 0, but padded with bytes > FF01 0001 00 > then the Server Hello will contain the renegotiation_info extension. Yup, ssl_scan_clienthello_tlsext() extracts the length but then it doesn't do anything with it. I wrote a patch [0] that fixes this specific problem in master, but the tlsfuzzer script has a bunch of other failures. Incidentally, with my patch applied, the tlsfuzzer test takes a lot less time (like it's seconds faster), not quite sure if that's good or bad... Cheers [0] https://github.com/openssl/openssl/pull/421 From rt at openssl.org Fri Oct 2 11:59:48 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 02 Oct 2015 11:59:48 +0000 Subject: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length) In-Reply-To: <20151002115939.GA23648@kronk.local> References: <9318543.O2f6AukmLt@pintsize.usersys.redhat.com> <20151002115102.GA22500@kronk.local> <20151002115939.GA23648@kronk.local> Message-ID: On Fri, Oct 02, 2015 at 11:51:10am +0000, Alessandro Ghedini via RT wrote: > On Fri, Oct 02, 2015 at 11:26:36am +0000, Hubert Kario via RT wrote: > > Current git checkout of 1.0.1, 1.0.2 and master accept malformed Client > > Hello messages. > > > > If the client sends a Client Hello message with extensions.length field > > equal to 0, but padded with bytes > > FF01 0001 00 > > then the Server Hello will contain the renegotiation_info extension. > > Yup, ssl_scan_clienthello_tlsext() extracts the length but then it doesn't do > anything with it. > > I wrote a patch [0] that fixes this specific problem in master, but the > tlsfuzzer script has a bunch of other failures. Incidentally, with my patch > applied, the tlsfuzzer test takes a lot less time (like it's seconds faster), > not quite sure if that's good or bad... I updated my patch as Matt suggested, and now all the failures seem to be gone. Cheers From rt at openssl.org Fri Oct 2 12:38:40 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 02 Oct 2015 12:38:40 +0000 Subject: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length) In-Reply-To: <2218201.DaJqhrnccB@pintsize.usersys.redhat.com> References: <20151002115102.GA22500@kronk.local> <2218201.DaJqhrnccB@pintsize.usersys.redhat.com> Message-ID: On Friday 02 October 2015 11:51:10 Alessandro Ghedini via RT wrote: > On Fri, Oct 02, 2015 at 11:26:36am +0000, Hubert Kario via RT wrote: > > Current git checkout of 1.0.1, 1.0.2 and master accept malformed > > Client Hello messages. > > > > If the client sends a Client Hello message with extensions.length > > field equal to 0, but padded with bytes > > FF01 0001 00 > > then the Server Hello will contain the renegotiation_info extension. > > Yup, ssl_scan_clienthello_tlsext() extracts the length but then it > doesn't do anything with it. > > I wrote a patch [0] that fixes this specific problem in master, but > the tlsfuzzer script has a bunch of other failures. Incidentally, > with my patch applied, the tlsfuzzer test takes a lot less time (like > it's seconds faster), not quite sure if that's good or bad... yes, all of the tests combined should finish in under 500ms on anything resembling a modern PC. any kind of "timed out" from tlsfuzzer means that the other side was expecting more data where it shouldn't have -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Oct 2 13:22:44 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 02 Oct 2015 13:22:44 +0000 Subject: [openssl-dev] [openssl.org #4068] Bug ocsp - bio_get_fd In-Reply-To: <20151002132241.GA22934@kronk.local> References: <20151002132241.GA22934@kronk.local> Message-ID: On Fri, Oct 02, 2015 at 02:06:12am +0000, vince technical address via RT wrote: > Hi, > > Can you tell me why in the source file "ocsp.c" (apps directory), the test > on the return of the function BIO_get_fd defines 0 as an invalid file > descriptor? > > if (BIO_get_fd (CBIO, & fd) <= 0) > > should be > > if (BIO_get_fd (CBIO, & fd) <0) For reference, I opened a GitHub pull request fixing this at: https://github.com/openssl/openssl/pull/423 Cheers From Stefan.Neis at t-online.de Fri Oct 2 14:53:16 2015 From: Stefan.Neis at t-online.de (Stefan.Neis at t-online.de) Date: Fri, 02 Oct 2015 16:53:16 +0200 Subject: [openssl-dev] =?utf-8?q?=5Bopenssl=2Eorg_=234067=5D_Bug_-_Header_?= =?utf-8?q?files_in_include_folder_differ_for_different_extractiing_method?= =?utf-8?q?s?= In-Reply-To: References: Message-ID: <1447843365560e9a5cce1b44.15949379@email.t-online.de> Hi, > I downloaded OpenSSL 1.0.0s.tar.gz and extracted files using following three ways. > The header files in "openssl 1.0.0s\include\openssl" folder are different. > (snipp) > Is this a bug in packaging? What is the expected results on Windows? At first glance, one could say, it's a bug in _un_packaging. Windows doesn't offer "real" symbolic links, so the programs extracting the them from the package convert them to something which they believe to be reasonable. Different programs just happen to do different things here. Thinking more about it, one could ask if it really is a good idea to put symbolic links into a cross-platform package when said package is targetting also platforms not having symbolic links, thus causing unneccessary headaches if you happen to use a "wrong" software to extract the package. Regards, Stefan From rt at openssl.org Fri Oct 2 15:29:43 2015 From: rt at openssl.org (Stefan.Neis@t-online.de via RT) Date: Fri, 02 Oct 2015 15:29:43 +0000 Subject: [openssl-dev] [openssl.org #4067] Bug - Header files in include folder differ for different extractiing methods In-Reply-To: <1447843365560e9a5cce1b44.15949379@email.t-online.de> References: <1447843365560e9a5cce1b44.15949379@email.t-online.de> Message-ID: Hi, > I downloaded OpenSSL 1.0.0s.tar.gz and extracted files using following three ways. > The header files in "openssl 1.0.0s\include\openssl" folder are different. > (snipp) > Is this a bug in packaging? What is the expected results on Windows? At first glance, one could say, it's a bug in _un_packaging. Windows doesn't offer "real" symbolic links, so the programs extracting the them from the package convert them to something which they believe to be reasonable. Different programs just happen to do different things here. Thinking more about it, one could ask if it really is a good idea to put symbolic links into a cross-platform package when said package is targetting also platforms not having symbolic links, thus causing unneccessary headaches if you happen to use a "wrong" software to extract the package. Regards, Stefan _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From bkaduk at akamai.com Fri Oct 2 17:37:45 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 2 Oct 2015 12:37:45 -0500 Subject: [openssl-dev] status of crypto/store/? Message-ID: <560EC0E9.5090901@akamai.com> Hi all, I happened to stumble across crypto/store while poking around at some other stuff, and it's unclear that the generic object (key, certificate, CRL, etc.) store is getting used. I don't see any consumers in the tree, and at present there only seems to be a memory-backed backend ("highly experimental", "to be used by other stores for internal caching") implemented. I guess it's possible that someone implemented an engine for this API, but even if they had, it doesn't seem terribly useful if there are no consumers of the API in the tree. Since it was added in 2003, and still has no consumers in 2015, it might be time to declare the experiment a failure and pull the code out of the support surface for 1.1. Is there a reason to keep it around? -Ben From wayming.z at gmail.com Sun Oct 4 11:12:29 2015 From: wayming.z at gmail.com (Wayming Zhang) Date: Sun, 04 Oct 2015 21:12:29 +1000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <20151001185552.GJ18165@mournblade.imrryr.org> References: <560D4895.3010901@openssl.org> <20151001185552.GJ18165@mournblade.imrryr.org> Message-ID: <5611099D.1080404@gmail.com> You need to run "ldd -v" on your executable to check why your binary has dependency on libptcorsdk.so.2, and then check your linking command if the dependency could be removed. A workaround you could give a try is to set LD_PRELOAD to forcibly load libssl before libptcoresdk if the dependency on libptcorsdk could not be removed. Wayming On 02/10/15 04:55, Viktor Dukhovni wrote: > On Thu, Oct 01, 2015 at 06:43:17PM +0000, Tiantian Liu via RT wrote: > >> #3 0x004c5e98 in tls1_new (s=0xb4964ec8) at t1_lib.c:154 >> #4 0x00300376 in SSL_new () from /usr/lib/libptcoresdk.so.2 >> >> I found my application called SSL_new from /usr/lib/libptcoresdk.so.2, which is third party library. >> >> I think it should call the SSL_new from your Openssl library, like /usr/lib/libssl.so.1.0.0. right? > Yes, this is an instance of "DLL hell". You need to link with the > right libssl. If libptcoresdk conflicts with the OpenSSL API, you > can't use both OpenSSL and that library. > From wayming.z at gmail.com Sun Oct 4 12:04:48 2015 From: wayming.z at gmail.com (Wayming Zhang) Date: Sun, 04 Oct 2015 22:04:48 +1000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <20151001185552.GJ18165@mournblade.imrryr.org> References: <560D4895.3010901@openssl.org> <20151001185552.GJ18165@mournblade.imrryr.org> Message-ID: <561115E0.2010205@gmail.com> You need to run "ldd -v" on your executable to check why your binary has dependency on libptcorsdk.so.2, and then check your linking command if the dependency could be removed. A workaround you could give a try is to set LD_PRELOAD to forcibly load libssl before libptcoresdk if the dependency on libptcorsdk could not be removed. Wayming On 02/10/15 04:55, Viktor Dukhovni wrote: > On Thu, Oct 01, 2015 at 06:43:17PM +0000, Tiantian Liu via RT wrote: > >> #3 0x004c5e98 in tls1_new (s=0xb4964ec8) at t1_lib.c:154 >> #4 0x00300376 in SSL_new () from /usr/lib/libptcoresdk.so.2 >> >> I found my application called SSL_new from /usr/lib/libptcoresdk.so.2, which is third party library. >> >> I think it should call the SSL_new from your Openssl library, like /usr/lib/libssl.so.1.0.0. right? > Yes, this is an instance of "DLL hell". You need to link with the > right libssl. If libptcoresdk conflicts with the OpenSSL API, you > can't use both OpenSSL and that library. > From rt at openssl.org Sun Oct 4 12:05:06 2015 From: rt at openssl.org (Wayming Zhang via RT) Date: Sun, 04 Oct 2015 12:05:06 +0000 Subject: [openssl-dev] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: <561115E0.2010205@gmail.com> References: <560D4895.3010901@openssl.org> <20151001185552.GJ18165@mournblade.imrryr.org> <561115E0.2010205@gmail.com> Message-ID: You need to run "ldd -v" on your executable to check why your binary has dependency on libptcorsdk.so.2, and then check your linking command if the dependency could be removed. A workaround you could give a try is to set LD_PRELOAD to forcibly load libssl before libptcoresdk if the dependency on libptcorsdk could not be removed. Wayming On 02/10/15 04:55, Viktor Dukhovni wrote: > On Thu, Oct 01, 2015 at 06:43:17PM +0000, Tiantian Liu via RT wrote: > >> #3 0x004c5e98 in tls1_new (s=0xb4964ec8) at t1_lib.c:154 >> #4 0x00300376 in SSL_new () from /usr/lib/libptcoresdk.so.2 >> >> I found my application called SSL_new from /usr/lib/libptcoresdk.so.2, which is third party library. >> >> I think it should call the SSL_new from your Openssl library, like /usr/lib/libssl.so.1.0.0. right? > Yes, this is an instance of "DLL hell". You need to link with the > right libssl. If libptcoresdk conflicts with the OpenSSL API, you > can't use both OpenSSL and that library. > From agostrer at gmail.com Mon Oct 5 06:42:40 2015 From: agostrer at gmail.com (Alexander Gostrer) Date: Sun, 4 Oct 2015 23:42:40 -0700 Subject: [openssl-dev] ECDH Engine Message-ID: Hi All, We are writing an ECDH engine. All private keys are in the hardware (including ephemeral keys). I found that the DH_METHOD has both (*generate_key) and (*compute_key) methods while the ECDH_METHOD has just the (*compute_key) method. We would like (once the engine is completed) to use standard SSL_accept() etc calls. But the compute_key() returns shared secret based on previously generated public/private key pair and the public key is already sent to a peer). Is there a hook to replace the public key before it is sent out? Thank you, Alex Gostrer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Oct 5 15:54:15 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Mon, 05 Oct 2015 15:54:15 +0000 Subject: [openssl-dev] [openssl.org #4026] patches to eliminate some warnings from clang In-Reply-To: <56129D20.5000605@akamai.com> References: <0CC79531-6841-48A0-B144-097B62785FF3@akamai.com> <56129D20.5000605@akamai.com> Message-ID: Updated patch series to address a couple of comments from Ben (made on now-orphaned github commits). Still available on github at a rebased https://github.com/kaduk/openssl/commits/warning-cleanup . -Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: warning-cleanup2.patch Type: text/x-patch Size: 11416 bytes Desc: not available URL: From rt at openssl.org Mon Oct 5 19:02:47 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 05 Oct 2015 19:02:47 +0000 Subject: [openssl-dev] [openssl.org #4069] Malformed Client Hello messages are accepted (custom message padding and length) In-Reply-To: <9318543.O2f6AukmLt@pintsize.usersys.redhat.com> References: <9318543.O2f6AukmLt@pintsize.usersys.redhat.com> Message-ID: Fixed in master, 1.0.2 and 1.0.1. Closing ticket. Matt From rt at openssl.org Mon Oct 5 20:34:58 2015 From: rt at openssl.org (Ellinger, Wesley M via RT) Date: Mon, 05 Oct 2015 20:34:58 +0000 Subject: [openssl-dev] [openssl.org #4070] OpenSSL 1.0.1p bug and suggested fix: su-filter.pl regex for struct/union definitions also matches other code In-Reply-To: <393F9D5F11A7114396FEC553BE3B61FA50465CBA@G1W3776.americas.hpqcorp.net> References: <393F9D5F11A7114396FEC553BE3B61FA50465CBA@G1W3776.americas.hpqcorp.net> Message-ID: The su-filter.pl script used for code reformatting in OpenSSL 1.0.1p has a regex that is looking for the start of a struct or union definition. It is supposed to match code similar to the following: struct identifier { However, to match the identifier it is using [^\s]+ which also matches characters that are not valid in identifiers. For example, it will also match code similar to the following. This can result in the rest of the file being truncated. if (foo = OPENSSL_malloc(sizeof(struct identifier))) { One possible fix is attached. Wesley Ellinger HP -------------- next part -------------- --- prev/su-filter.pl 2015-03-19 09:02:02.000000000 -0500 +++ su-filter.pl 2015-10-02 15:11:11.815000953 -0500 @@ -47,7 +47,7 @@ do_output($out); $in_su = 0; } - } elsif($incomm <= 0 && /( *)(static )?(const )?(union|struct) ([^\s]+ )?\{/) { + } elsif($incomm <= 0 && /( *)(static )?(const )?(union|struct) ([0-9a-zA-Z_]+ )?\{/) { $in_su = 1; $indent = $1; $out = $_; -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From beldmit at gmail.com Mon Oct 5 20:43:05 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 5 Oct 2015 23:43:05 +0300 Subject: [openssl-dev] Load config from apps Message-ID: Hello OpenSSL team, What is the reason to avoid loading a config file from the openssl command-line application in master? The 1.0.2 version loads the config file and it is possible to specify the config via OPENSSL_CONF variable. Such behaviouir allows to load an engine providing extra crypto algorithms. Master ignores config file for most commands. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro at ghedini.me Mon Oct 5 22:28:05 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Tue, 6 Oct 2015 00:28:05 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <560BA1C1.4030606@openssl.org> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> Message-ID: <20151005222804.GA14709@kronk.local> On Wed, Sep 30, 2015 at 10:48:01am +0200, Andy Polyakov wrote: > >>>> As for running tests in the context of query, i.e. mingw > >>>> cross-compilation on Linux. It actually was possible to > >>>> perform under 'wine' before and surely can be fixed now. Is > >>>> 'wine' an option in this case? > >>> > >>> I don't know if it actually works, but we can configure Travis > >>> CI to install wine before starting the builds. > >> > >> Can you test and figure out? As implied, currently new 'make > >> test' doesn't work with 'wine' yet, but you can replace 'make > >> test' with e.g. test/sha1test.exe alone. Just to figure out if it > >> works. It might happen that it's not sufficient to simply install > >> package, one might have to perform per-user config prior Win32 > >> .exes can be executed. > > > > It works!!! Well, sort of. It requires 3 patches [0] (including the > > changes to the Travis CI config) and there are 3 or so tests that > > fail (see log at [1]), but it's basically doable. > > > > Cheers > > > > [0] https://github.com/ghedo/openssl/commits/mingwci [1] > > https://travis-ci.org/ghedo/openssl/jobs/82727489 > > Thanks! I'm looking into it. On related note, you might notice a > number of mingw warnings addressed in master. I just want to say that > even more will be, i.e. it's work in progress. So, I just opened a new pull request to: - Fix a clang warning in the bn_dh.c file - Fix a gcc bogus warning in the packettest.c file - Revert the -d flag back to --debug in the travis script to make mingw debug builds run again - Use -Wno-pedantic-ms-format with mingw to silence the ms-format warnings - Mark mingw debug builds as "allowed failures" for the time being, until all the warnings have been fixed. I don't know if any of you have already provided patches for any of this internally, so just ignore any patch I proposed that duplicates other work. With all the above patches applied, the Travis CI status for the master branch turned green for the first time in a while [0]. I think this is pretty important, since even though none of the current failures are very important, they could potentially hide more severe failures in the future. So, could someone please have a look at my patches? I'm going to look into the failures of other branches as well, but that will probably involve just disabling various builds that are just not supported (e.g. clang and mingw debug). I'm also working into adding support for newer compilers like gcc-5 and clang-3.8. This could allow us to build with address sanitizer and other niceties. On a somewhat related note, I've noticed that the Travis failure messages are not actually sent to the mailing list. I suspect that this is due to some kind of filtering the mailing list does. Could the Travis messages be whitelisted or something? Or maybe just add a new "openssl-ci" mailing list dedicated to this? Cheers [0] https://travis-ci.org/openssl/openssl/builds/83787204 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From alessandro at ghedini.me Mon Oct 5 22:29:53 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Tue, 6 Oct 2015 00:29:53 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20151005222804.GA14709@kronk.local> References: <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> Message-ID: <20151005222953.GA15747@kronk.local> On Tue, Oct 06, 2015 at 12:28:05AM +0200, Alessandro Ghedini wrote: > On Wed, Sep 30, 2015 at 10:48:01am +0200, Andy Polyakov wrote: > > >>>> As for running tests in the context of query, i.e. mingw > > >>>> cross-compilation on Linux. It actually was possible to > > >>>> perform under 'wine' before and surely can be fixed now. Is > > >>>> 'wine' an option in this case? > > >>> > > >>> I don't know if it actually works, but we can configure Travis > > >>> CI to install wine before starting the builds. > > >> > > >> Can you test and figure out? As implied, currently new 'make > > >> test' doesn't work with 'wine' yet, but you can replace 'make > > >> test' with e.g. test/sha1test.exe alone. Just to figure out if it > > >> works. It might happen that it's not sufficient to simply install > > >> package, one might have to perform per-user config prior Win32 > > >> .exes can be executed. > > > > > > It works!!! Well, sort of. It requires 3 patches [0] (including the > > > changes to the Travis CI config) and there are 3 or so tests that > > > fail (see log at [1]), but it's basically doable. > > > > > > Cheers > > > > > > [0] https://github.com/ghedo/openssl/commits/mingwci [1] > > > https://travis-ci.org/ghedo/openssl/jobs/82727489 > > > > Thanks! I'm looking into it. On related note, you might notice a > > number of mingw warnings addressed in master. I just want to say that > > even more will be, i.e. it's work in progress. > > So, I just opened a new pull request to: Btw, the pull request can be found at https://github.com/openssl/openssl/pull/425 Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rsalz at akamai.com Tue Oct 6 02:54:28 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Oct 2015 02:54:28 +0000 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20151005222804.GA14709@kronk.local> References: <23ce6da0bb644733be9006dfe47e4705@ustx2ex-dag1mb1.msg.corp.akamai.com> <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> Message-ID: <7ef1bb7ba05a4ec786b8a68238c5e2c4@ustx2ex-dag1mb3.msg.corp.akamai.com> > With all the above patches applied, the Travis CI status for the master branch > turned green for the first time in a while [0]. I think this is pretty important, > since even though none of the current failures are very important, they > could potentially hide more severe failures in the future. So, could someone > please have a look at my patches? Yes, THANKS! From levitte at openssl.org Tue Oct 6 07:46:17 2015 From: levitte at openssl.org (Richard Levitte) Date: Tue, 06 Oct 2015 09:46:17 +0200 (CEST) Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20151005222804.GA14709@kronk.local> References: <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> Message-ID: <20151006.094617.2116202023259129807.levitte@openssl.org> In message <20151005222804.GA14709 at kronk.local> on Tue, 6 Oct 2015 00:28:05 +0200, Alessandro Ghedini said: alessandro> On a somewhat related note, I've noticed that the Travis failure messages are alessandro> not actually sent to the mailing list. I suspect that this is due to some kind alessandro> of filtering the mailing list does. Could the Travis messages be whitelisted or alessandro> something? Or maybe just add a new "openssl-ci" mailing list dedicated to this? Hi Alessandro, I was just looking into this... and I can't quite make heads or tails of how travis notification works. Can you help me figure it out? What I need to know is, what do I need to do to have it send notifications to the address configured in .travis.yml, and what will the sender address be? Right now, just from grepping for 'travis-ci' in the mail logs, or even just 'travis', I'd say travis is giving us no sign of life, mail wise. Cheers, Richard (please include my address when you answer... I don't read the lists very often...) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From alessandro at ghedini.me Tue Oct 6 09:58:46 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Tue, 6 Oct 2015 11:58:46 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20151006.094617.2116202023259129807.levitte@openssl.org> References: <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> <20151006.094617.2116202023259129807.levitte@openssl.org> Message-ID: <20151006095846.GA6867@kronk.local> On Tue, Oct 06, 2015 at 09:46:17am +0200, Richard Levitte wrote: > In message <20151005222804.GA14709 at kronk.local> on Tue, 6 Oct 2015 00:28:05 +0200, Alessandro Ghedini said: > > alessandro> On a somewhat related note, I've noticed that the Travis failure messages are > alessandro> not actually sent to the mailing list. I suspect that this is due to some kind > alessandro> of filtering the mailing list does. Could the Travis messages be whitelisted or > alessandro> something? Or maybe just add a new "openssl-ci" mailing list dedicated to this? > > Hi Alessandro, > > I was just looking into this... and I can't quite make heads or tails > of how travis notification works. Can you help me figure it out? > > What I need to know is, what do I need to do to have it send > notifications to the address configured in .travis.yml, and what will > the sender address be? I checked the documentation on the subject [0] and I think we had the wrong configuration all along (my fault :/), so that's probably why the notifications weren't received at all. I added another commit to my pull request to fix this, so now a notification may have been sent (but it still didn't show up in the openssl-commits archive). It should come from builds at travis-ci.org I think. Cheers [0] http://docs.travis-ci.com/user/notifications/#Email-notifications -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From levitte at openssl.org Tue Oct 6 10:38:28 2015 From: levitte at openssl.org (Richard Levitte) Date: Tue, 06 Oct 2015 12:38:28 +0200 (CEST) Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20151006095846.GA6867@kronk.local> References: <20151005222804.GA14709@kronk.local> <20151006.094617.2116202023259129807.levitte@openssl.org> <20151006095846.GA6867@kronk.local> Message-ID: <20151006.123828.778411873768889344.levitte@openssl.org> In message <20151006095846.GA6867 at kronk.local> on Tue, 6 Oct 2015 11:58:46 +0200, Alessandro Ghedini said: alessandro> I checked the documentation on the subject [0] and I think we had the wrong alessandro> configuration all along (my fault :/), so that's probably why the notifications alessandro> weren't received at all. I added another commit to my pull request to fix this, alessandro> so now a notification may have been sent (but it still didn't show up in the alessandro> openssl-commits archive). It should come from builds at travis-ci.org I think. Ah-AH! Ok, saw the change, commented it. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Tue Oct 6 13:27:17 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Tue, 06 Oct 2015 13:27:17 +0000 Subject: [openssl-dev] [openssl.org #4071] Doc Bug: SSL_CTX_set_tmp_dh_callback (and friends) and client code In-Reply-To: References: Message-ID: The docs for SSL_CTX_set_tmp_dh_callback(3) (https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_tmp_dh_callback.html) and friends state the functions are called for DH parameter selection. It fails to state they are only called in servers, and not clients. Please update the docs to make it clear they are server-only functions. It might be helpful to tell users there are currently no client-based APIs they can use to enforce an DH minimum. Also see "How to reject weak DH parameters in an OpenSSL client?" (http://stackoverflow.com/q/32947040) on Stack Overflow and "How to enforce DH field size in the client?" (http://openssl.6102.n7.nabble.com/How-to-enforce-DH-field-size-in-the-client-td60442.html) on the User's mailing list. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Oct 6 16:29:54 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 06 Oct 2015 16:29:54 +0000 Subject: [openssl-dev] [openssl.org #4071] Doc Bug: SSL_CTX_set_tmp_dh_callback (and friends) and client code In-Reply-To: References: Message-ID: On Tue Oct 06 13:27:17 2015, noloader at gmail.com wrote: > > Please update the docs to make it clear they are server-only > functions. It might be helpful to tell users there are currently no > client-based APIs they can use to enforce an DH minimum. > Well there is in the master branch through security levels and a custom callback (if the supplied levels don't meet your needs). Currently the callback operation is undocumented: that will be fixed. For other branches.. there *is* a way to limit DH parameters globally using a custom DH method but it's a bit messy. I've attached an example. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -------------- next part -------------- A non-text attachment was scrubbed... Name: dhdemo.c Type: text/x-csrc Size: 763 bytes Desc: not available URL: From alessandro at ghedini.me Tue Oct 6 19:37:53 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Tue, 6 Oct 2015 21:37:53 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20151005222804.GA14709@kronk.local> References: <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> Message-ID: <20151006193753.GA14151@kronk.local> On Tue, Oct 06, 2015 at 12:28:05AM +0200, Alessandro Ghedini wrote: > I'm going to look into the failures of other branches as well, but that will > probably involve just disabling various builds that are just not supported > (e.g. clang and mingw debug). I opened the following PR to fix the builds in the 1.0.2 branch: https://github.com/openssl/openssl/pull/428 The changes include: - The email address fix as in master. - Disabled mingw debug builds (as previously discussed, these are not gonna be fixed in the stable branches). - Added a new target debug-linu-x86_64-clang, to make the linux clang debug build work. - Added a fix for other bogus GCC warnings similar to the one fixed in master (but in a different file). I renamed all instances of the "index" variable to "ind" for consistency. Now the 1.0.2 branch is all green as well. I haven't looked at 1.0.1 yet, and for 0.9.8 we might want to just disable mingw builds completely, since they don't seem to work at all. > I'm also working into adding support for newer compilers like gcc-5 and > clang-3.8. This could allow us to build with address sanitizer and other > niceties. I've opened the following PR to add support for GCC v5 and address sanitizer (not sure if we want valgrind as well...): https://github.com/openssl/openssl/pull/429 I think we can just use that instead of adding support for v4.7, v4.8 and v4.9. I haven't looked into newer clang versions yet. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rsalz at akamai.com Tue Oct 6 19:41:13 2015 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Oct 2015 19:41:13 +0000 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20151006193753.GA14151@kronk.local> References: <56025D80.7060802@openssl.org> <20150923114607.GA27612@kronk.local> <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> <20151006193753.GA14151@kronk.local> Message-ID: > I opened the following PR to fix the builds in the 1.0.2 branch: > https://github.com/openssl/openssl/pull/428 I've started the internal review. > Now the 1.0.2 branch is all green as well. I haven't looked at 1.0.1 yet, and for > 0.9.8 we might want to just disable mingw builds completely, since they don't > seem to work at all. Yes, mingw is not supported in 0.9.8. As both it and 1.0.0 are end-of-life in 60 days, I would not worry about those two. > I've opened the following PR to add support for GCC v5 and address sanitizer > (not sure if we want valgrind as well...): > https://github.com/openssl/openssl/pull/429 I've started the internal review. Asan is awesome. > I think we can just use that instead of adding support for v4.7, v4.8 and v4.9. Agreed. This is great work, thank you! From rt at openssl.org Tue Oct 6 19:53:30 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Tue, 06 Oct 2015 19:53:30 +0000 Subject: [openssl-dev] [openssl.org #4072] dgst command incompatibility between 1.0.2 and 1.1.0 In-Reply-To: References: Message-ID: Hello! I've found a difference in behaviour between openssl cmdline 1.0.2 and 1.1.0 versions. The -macopt cmdline option is not recognized, openssl dgst expects -macop instead. -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Oct 6 20:08:12 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Tue, 06 Oct 2015 20:08:12 +0000 Subject: [openssl-dev] [openssl.org #4073] Segfault in engine processing In-Reply-To: References: Message-ID: Hello! I get a segfault when executing the command openssl dgst -engine gost -md_gost94 -mac hmac -macop key:123456901234567890123456789012 The stack trace is #0 0x0000000000000000 in ?? () #1 0x00007ffff763420d in look_str_cb (arg=, sk=, nid=, def=) at tb_asnmth.c:217 #2 look_str_cb (nid=815, sk=0x6afea0, def=, arg=0x7fffffffe300) at tb_asnmth.c:208 #3 0x00007ffff764091c in doall_util_fn (arg=, func_arg=, lh=0x6afd00, use_arg=, func=) at lhash.c:261 #4 lh_doall_arg (lh=0x6afd00, func=func at entry=0x7ffff7632550 , arg=arg at entry=0x7fffffffe2e0) at lhash.c:276 #5 0x00007ffff7632a31 in engine_table_doall (table=, cb=cb at entry=0x7ffff76341a0 , arg=arg at entry=0x7fffffffe300) at eng_table.c:357 #6 0x00007ffff76345d3 in ENGINE_pkey_asn1_find_str (pe=pe at entry=0x7fffffffe330, str=str at entry=0x7fffffffed4e "hmac", len=len at entry=4) at tb_asnmth.c:237 #7 0x00007ffff766d7f3 in EVP_PKEY_asn1_find_str (pe=pe at entry=0x7fffffffe390, str=str at entry=0x7fffffffed4e "hmac", len=4, len at entry=-1) at ameth_lib.c:198 #8 0x000000000042e510 in init_gen_str (pctx=pctx at entry=0x7fffffffe4c0, algname=algname at entry=0x7fffffffed4e "hmac", e=e at entry=0x0, do_param=0, do_param at entry=7013296) at genpkey.c:305 #9 0x00000000004282f1 in dgst_main (argc=1, argv=0x7fffffffeaf0) at dgst.c:303 #10 0x000000000041e1db in do_cmd (prog=prog at entry=0x6aaae0, argc=argc at entry=9, argv=0x7fffffffeab0) at openssl.c:641 #11 0x000000000041de29 in main (argc=9, argv=) at openssl.c:348 -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From matt at openssl.org Wed Oct 7 09:46:26 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2015 10:46:26 +0100 Subject: [openssl-dev] Adding async support Message-ID: <5614E9F2.4090303@openssl.org> Hi all A number of people have expressed interest in the async work that I have been doing in collaboration with Intel. This has now progressed to the point where it is going through team review. I thought some of you might like to get early sight of this so I have pushed it to my personal github repo (see the "main-async" branch): https://github.com/mattcaswell/openssl Obviously there may be some tweaks that occur during the review process but hopefully it is stable enough to give you an idea of how it will work. I have also opened a github pull request so you can post comments on the code there if you wish: https://github.com/openssl/openssl/pull/433 The idea is that async aware application code will be able to use OpenSSL to initiate crypto operations asynchronously. In order to work this will require the presence of an async capable engine. For example you could imagine an engine that could initiate work on some external hardware and enable application code to come back at some later time for the results. This has been implemented through the concept of an ASYNC_JOB. At the libcrypto level an application developer would write a function that they wish to execute asynchronously which might call a number of different crypto operations. They can then initiate that job using a new API call "ASYNC_start_job()". The function will then execute until the engine (or indeed anything - it doesn't have to be in an engine; it could be user code) calls "ASYNC_pause_job()". At this point control returns back to the application code. The job can be resumed later through a second call to "ASYNC_start_job()" - it will pick up where it left off. The main restriction here is that this must be done from the same thread as the original ASYNC_start_job() call. A flagging mechanism has been implemented to enable application code to know whether the async job is "ready" to be resumed. libssl has been made async aware through the introduction of a new mode "SSL_MODE_ASYNC". The mode is set using a call to one of the existing functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode calls to functions such as SSL_read/SSL_write etc, may now start returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine is present). To resume you simply recall SSL_read/SSL_write in the same way as you would if you got an SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same thread as the original call. In order to enable people to test this out I have provided a "Dummy Async" engine (dasync). This can't really do async work, but it pretends it can :-). For certain crypto operations (currently only SHA1 and RSA) it will call ASYNC_pause_job() at various points. Once you resume the job it will just continue synchronously. I have also added async support to s_server and s_client through the new "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an effect you will obviously also need an async engine (such as dasync) loaded through the "-engine" flag. Note that dasync will only be loaded dynamically and thus OpenSSL must be built "shared" for this to work. Documentation including some example code is available on all of this here: https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod I'd be interested to hear your thoughts. Matt From KThirumal at inautix.co.in Wed Oct 7 12:14:38 2015 From: KThirumal at inautix.co.in (Thirumal, Karthikeyan) Date: Wed, 7 Oct 2015 12:14:38 +0000 Subject: [openssl-dev] Elliptical Cipher Suites Message-ID: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> Team, Can some one tell me how to enable all the Elliptical Cipher suites ? Is there a single flag to enable all of the elliptical ciphers ? Thanks & Regards ________________________ Karthikeyan Thirumal ****************************************************** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. ****************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Oct 7 12:55:58 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 7 Oct 2015 12:55:58 +0000 Subject: [openssl-dev] Elliptical Cipher Suites In-Reply-To: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> References: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> Message-ID: <20151007125558.GA15070@mournblade.imrryr.org> On Wed, Oct 07, 2015 at 12:14:38PM +0000, Thirumal, Karthikeyan wrote: > Can some one tell me how to enable all the Elliptical Cipher suites ? Is > there a single flag to enable all of the elliptical ciphers ? This question belongs on the openssL-users list, and even there much more detail needs to be provided along with the question. * Compiling OpenSSL or using a precompiled version? * Which version? * Writing a program that use the API, or using the command-line tools? * What motivates this question? What have you tried and what were the results? -- Viktor. From openssl-users at dukhovni.org Wed Oct 7 13:29:05 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 7 Oct 2015 13:29:05 +0000 Subject: [openssl-dev] Adding async support In-Reply-To: <5614E9F2.4090303@openssl.org> References: <5614E9F2.4090303@openssl.org> Message-ID: <20151007132905.GD15070@mournblade.imrryr.org> On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote: > I have also added async support to s_server and s_client through the new > "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an > effect you will obviously also need an async engine (such as dasync) > loaded through the "-engine" flag. Note that dasync will only be loaded > dynamically and thus OpenSSL must be built "shared" for this to work. > > Documentation including some example code is available on all of this here: > https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod > > I'd be interested to hear your thoughts. Will existing applications doing non-blocking I/O with OpenSSL need to be modified to handle SSL_ERROR_WANT_ASYNC? Or does that happen only if they explicitly request "async mode"? Should applications generally enable async mode because that might be beneficial down the road? Or is this just for exotic hardware not likely to be seen in most environments? For example, should Postfix enable "async" support? It does timed non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}. -- Viktor. From matt at openssl.org Wed Oct 7 13:43:31 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2015 14:43:31 +0100 Subject: [openssl-dev] Adding async support In-Reply-To: <20151007132905.GD15070@mournblade.imrryr.org> References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> Message-ID: <56152183.8030909@openssl.org> On 07/10/15 14:29, Viktor Dukhovni wrote: > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote: > >> I have also added async support to s_server and s_client through the new >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an >> effect you will obviously also need an async engine (such as dasync) >> loaded through the "-engine" flag. Note that dasync will only be loaded >> dynamically and thus OpenSSL must be built "shared" for this to work. >> >> Documentation including some example code is available on all of this here: >> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod >> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod >> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod >> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod >> >> I'd be interested to hear your thoughts. > > Will existing applications doing non-blocking I/O with OpenSSL need > to be modified to handle SSL_ERROR_WANT_ASYNC? Or does that happen > only if they explicitly request "async mode"? No, they should not need to be modified. You will only get SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC. > > Should applications generally enable async mode because that might > be beneficial down the road? Or is this just for exotic hardware > not likely to be seen in most environments? It will only be helpful if you have an engine capable of supporting async. I can't really answer the question because I don't know how common this will be. My hope is that this will become relatively common. I have been toying with the idea of creating a multi-threaded async engine where the engine manages a pool of threads to offload async work to which would then offer true async support even if you don't have specialist hardware. > For example, should Postfix enable "async" support? It does timed > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}. If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I would encourage making the changes. You may want to consider making it a configurable option. There is a small overhead with creating ASYNC_JOBs and context switching into them when they start and finish. Matt From KThirumal at inautix.co.in Wed Oct 7 13:54:40 2015 From: KThirumal at inautix.co.in (Thirumal, Karthikeyan) Date: Wed, 7 Oct 2015 13:54:40 +0000 Subject: [openssl-dev] Elliptical Cipher Suites In-Reply-To: <20151007125558.GA15070@mournblade.imrryr.org> References: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> <20151007125558.GA15070@mournblade.imrryr.org> Message-ID: <55A0598A7539EC4BAB296D8BBA5AC122BFFC66F0@WTPCPMBMEM07.ams.bnymellon.net> Vik Am using 0.9.8a version. Am trying to fix few weak ciphers in my SSL connection and also to make Elliptical cipher suites enable. I see that ECDHE ciphers are elliptical - need more info on this. Thanks & Regards ________________________ Karthikeyan Thirumal -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, October 07, 2015 6:26 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Elliptical Cipher Suites On Wed, Oct 07, 2015 at 12:14:38PM +0000, Thirumal, Karthikeyan wrote: > Can some one tell me how to enable all the Elliptical Cipher suites ? > Is there a single flag to enable all of the elliptical ciphers ? This question belongs on the openssL-users list, and even there much more detail needs to be provided along with the question. * Compiling OpenSSL or using a precompiled version? * Which version? * Writing a program that use the API, or using the command-line tools? * What motivates this question? What have you tried and what were the results? -- Viktor. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ****************************************************** This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email. If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email. Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses. The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission. ****************************************************** From ellzey at strcpy.net Wed Oct 7 14:05:12 2015 From: ellzey at strcpy.net (Mark Ellzey) Date: Wed, 07 Oct 2015 14:05:12 +0000 Subject: [openssl-dev] Adding async support In-Reply-To: <56152183.8030909@openssl.org> References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> Message-ID: As a maintainer of libevent, and spending heaps of time in the ssl abstractions, anything to remove all the insane things you must do now for async io would be a reprieve of the horrors we've dealt with over the years. I do worry that these patches may take too much of the work away to the point of no decent control mechanism. When I see poll() everywhere, it throws up red flags. I will spend some time with the proposed patches here, and see if I can make libevent happy, and hopefully very less complex. Fingers crossed. Cheers! On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell wrote: > > > On 07/10/15 14:29, Viktor Dukhovni wrote: > > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote: > > > >> I have also added async support to s_server and s_client through the new > >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have an > >> effect you will obviously also need an async engine (such as dasync) > >> loaded through the "-engine" flag. Note that dasync will only be loaded > >> dynamically and thus OpenSSL must be built "shared" for this to work. > >> > >> Documentation including some example code is available on all of this > here: > >> > https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod > >> > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod > >> > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod > >> > https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod > >> > >> I'd be interested to hear your thoughts. > > > > Will existing applications doing non-blocking I/O with OpenSSL need > > to be modified to handle SSL_ERROR_WANT_ASYNC? Or does that happen > > only if they explicitly request "async mode"? > > No, they should not need to be modified. You will only get > SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC. > > > > > Should applications generally enable async mode because that might > > be beneficial down the road? Or is this just for exotic hardware > > not likely to be seen in most environments? > > It will only be helpful if you have an engine capable of supporting > async. I can't really answer the question because I don't know how > common this will be. My hope is that this will become relatively common. > I have been toying with the idea of creating a multi-threaded async > engine where the engine manages a pool of threads to offload async work > to which would then offer true async support even if you don't have > specialist hardware. > > > For example, should Postfix enable "async" support? It does timed > > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}. > > If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is > not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I > would encourage making the changes. You may want to consider making it a > configurable option. There is a small overhead with creating ASYNC_JOBs > and context switching into them when they start and finish. > > Matt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Oct 7 14:46:57 2015 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 07 Oct 2015 14:46:57 +0000 Subject: [openssl-dev] [openssl.org #4074] [PATCH] Fixes for when PSK, SRP, SRTP and DTLS1 are disabled In-Reply-To: <397A734D-588F-4E60-8DF1-BD485D3E92D3@akamai.com> References: <397A734D-588F-4E60-8DF1-BD485D3E92D3@akamai.com> Message-ID: Hello OpenSSL Org: While evaluating the master branch, I discovered that the code does not compile, nor do the unit tests pass, when disabling certain features. Specifically, PSK, SRP, SRTP and DTLS1. The following patch for master branch will fix the issues. Thanks, -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-when-SRP-SRTP-DTLS1-PSK-are-disabled.patch Type: application/octet-stream Size: 3533 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rsalz at akamai.com Wed Oct 7 15:09:13 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 7 Oct 2015 15:09:13 +0000 Subject: [openssl-dev] Test, sorry, please ignore. Message-ID: Thanks. /r$ -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Oct 7 15:26:05 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 7 Oct 2015 15:26:05 +0000 Subject: [openssl-dev] Sorry, another test Message-ID: <4024fe22b92e4ff2b4fd4b786ac0ad05@ustx2ex-dag1mb3.msg.corp.akamai.com> /r$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlmeetei at gmail.com Wed Oct 7 15:57:23 2015 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Wed, 7 Oct 2015 21:27:23 +0530 Subject: [openssl-dev] Adding async support In-Reply-To: <5614E9F2.4090303@openssl.org> References: <5614E9F2.4090303@openssl.org> Message-ID: On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell wrote: > > > libssl has been made async aware through the introduction of a new mode > "SSL_MODE_ASYNC". The mode is set using a call to one of the existing > functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode > calls to functions such as SSL_read/SSL_write etc, may now start > returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine > is present). To resume you simply recall SSL_read/SSL_write in the same > way as you would if you got an SSL_ERROR_WANT_READ or > SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same > thread as the original call. > Does this also mean that there will not be any libssl API change? I have been developing async calls of TLS I/O using bio pair, for instance for SSL_read, it is something like > int evt_tls_read( evt_tls_t *tls, void (*cb)(evt_tls_t* t, char *buf, int sz)) The cb will be called asynchronously whenever there is application data. Will there be any such change? Such API's will make integrating OpenSSL with other async lib like libevent, libev and libuv etc. Please forgive me if I am asking a dumb question without looking at code changes done. -- Warm Regards --Dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlmeetei at gmail.com Wed Oct 7 16:04:06 2015 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Wed, 7 Oct 2015 21:34:06 +0530 Subject: [openssl-dev] Adding async support In-Reply-To: References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> Message-ID: Hello Mark I have been working recently on evt , which is still in WIP, exposing a callback based async API's on top of libssl. The idea was to abstract libssl with well defined APIs that can be integrated with libraries like libevent and libuv. Thought It might be of interest to libevent. On Wed, Oct 7, 2015 at 7:35 PM, Mark Ellzey wrote: > As a maintainer of libevent, and spending heaps of time in the ssl > abstractions, anything to remove all the insane things you must do now for > async io would be a reprieve of the horrors we've dealt with over the > years. > > I do worry that these patches may take too much of the work away to the > point of no decent control mechanism. When I see poll() everywhere, it > throws up red flags. > > I will spend some time with the proposed patches here, and see if I can > make libevent happy, and hopefully very less complex. > > Fingers crossed. Cheers! > > On Wed, Oct 7, 2015 at 6:43 AM Matt Caswell wrote: > >> >> >> On 07/10/15 14:29, Viktor Dukhovni wrote: >> > On Wed, Oct 07, 2015 at 10:46:26AM +0100, Matt Caswell wrote: >> > >> >> I have also added async support to s_server and s_client through the >> new >> >> "-async" flag. The will set the SSL_MODE_ASYNC mode. In order to have >> an >> >> effect you will obviously also need an async engine (such as dasync) >> >> loaded through the "-engine" flag. Note that dasync will only be loaded >> >> dynamically and thus OpenSSL must be built "shared" for this to work. >> >> >> >> Documentation including some example code is available on all of this >> here: >> >> >> https://github.com/mattcaswell/openssl/blob/main-async/doc/crypto/ASYNC_start_job.pod >> >> >> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_error.pod >> >> >> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_get_async_wait_fd.pod >> >> >> https://github.com/mattcaswell/openssl/blob/main-async/doc/ssl/SSL_CTX_set_mode.pod >> >> >> >> I'd be interested to hear your thoughts. >> > >> > Will existing applications doing non-blocking I/O with OpenSSL need >> > to be modified to handle SSL_ERROR_WANT_ASYNC? Or does that happen >> > only if they explicitly request "async mode"? >> >> No, they should not need to be modified. You will only get >> SSL_ERROR_WANT_ASYNC if you have enabled SSL_MODE_ASYNC. >> >> > >> > Should applications generally enable async mode because that might >> > be beneficial down the road? Or is this just for exotic hardware >> > not likely to be seen in most environments? >> >> It will only be helpful if you have an engine capable of supporting >> async. I can't really answer the question because I don't know how >> common this will be. My hope is that this will become relatively common. >> I have been toying with the idea of creating a multi-threaded async >> engine where the engine manages a pool of threads to offload async work >> to which would then offer true async support even if you don't have >> specialist hardware. >> >> > For example, should Postfix enable "async" support? It does timed >> > non-blocking TLS I/O and currently handles SSL_ERROR_WANT_{READ,WRITE}. >> >> If applications already handle SSL_ERROR_WANT_READ/WRITE then IMO it is >> not much extra effort to additionally handle SSL_ERROR_WANT_ASYNC so I >> would encourage making the changes. You may want to consider making it a >> configurable option. There is a small overhead with creating ASYNC_JOBs >> and context switching into them when they start and finish. >> >> Matt >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- Warm Regards --Dev OpenPegasus Developer "I'm one of those people that think Thomas Edison and the light bulb changed the world more than Karl Marx ever did,? Steve Jobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 7 16:04:54 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2015 17:04:54 +0100 Subject: [openssl-dev] Adding async support In-Reply-To: References: <5614E9F2.4090303@openssl.org> Message-ID: <561542A6.7090102@openssl.org> On 07/10/15 16:57, Devchandra L Meetei wrote: > > > On Wed, Oct 7, 2015 at 3:16 PM, Matt Caswell > > wrote: > > > > libssl has been made async aware through the introduction of a new mode > "SSL_MODE_ASYNC". The mode is set using a call to one of the existing > functions SSL_CTX_set_mode() or SSL_set_mode(). Having set that mode > calls to functions such as SSL_read/SSL_write etc, may now start > returning an SSL_ERROR_WANT_ASYNC response (if an async capable engine > is present). To resume you simply recall SSL_read/SSL_write in the same > way as you would if you got an SSL_ERROR_WANT_READ or > SSL_ERROR_WANT_WRITE. Similarly to above you must do this from the same > thread as the original call. > > > Does this also mean that there will not be any libssl API change? There are no changes to the fundamental way the libssl API works. This is about integrating a new source of async events i.e. the capability to asynchronously process crypto operations by pushing the work off into some async capable engine. It's not about changing the way async events are presented to applications in libssl. > > I have been developing async calls of TLS I/O using bio pair, for instance > for SSL_read, it is something like > >> int evt_tls_read( evt_tls_t *tls, void (*cb)(evt_tls_t* t, char *buf, > int sz)) > > The cb will be called asynchronously whenever there is application data. > > Will there be any such change? Such API's will make integrating OpenSSL > with other > async lib like libevent, libev and libuv etc. There are no such changes planned. Matt From rt at openssl.org Wed Oct 7 20:17:15 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Wed, 07 Oct 2015 20:17:15 +0000 Subject: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests In-Reply-To: <20151007200902.GA11112@roeckx.be> References: <20151007200902.GA11112@roeckx.be> Message-ID: On Tue, Jun 02, 2015 at 03:50:19PM +0200, Pascal Cuoq via RT wrote: > The attached archive contains a collection of patches for undefined behaviors > that happen while the tests in directory tests/ are executed, with a recent > (as of June 2015) OpenSSL git version. > > Each undefined behavior really happens for at least one > execution, the execution of the test. In other terms, none of these is a > "false positive". The issues broadly fall in the following categories: So some of the patches got applied, but I have some comments about the remaining: - cast_lcl.h.patch: Your patch has the same effect as defining PEDANTIC. I recommend you at least run your tool with PEDANTIC defined. - ssl_locl.h.patch: I don't see a struct timeval crypto/x509v3/v3_scts.c. Does this comment still apply? Maybe we fixed the issue in some other way. - malloc.patch: I started looking at it, and I have some comments/questions: - I currently don't see a way that s->d1 can be NULL except after an dtls1_free() call. The same seem to go for DTLS_RECORD_LAYER_free(), ssl3_free(), pkey_hmac_cleanup(), aes_gcm_cleanup() and aes_ocb_cleanup(). Are you saying there are cases we could end up calling those twice? - It seems to contain changes to the test suite to check return values. It seems non-obvious that this is about memory allocation that might have failed, but it's probably the only reasons those failures can happen. It's a little confusing that it's in the same patch where you can't directly see the malloc failing. Kurt From beldmit at gmail.com Wed Oct 7 20:44:40 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 7 Oct 2015 23:44:40 +0300 Subject: [openssl-dev] Adding async support In-Reply-To: <56152183.8030909@openssl.org> References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> Message-ID: Dear Matt, On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell wrote: > > > On 07/10/15 14:29, Viktor Dukhovni wrote: > > > > Should applications generally enable async mode because that might > > be beneficial down the road? Or is this just for exotic hardware > > not likely to be seen in most environments? > > It will only be helpful if you have an engine capable of supporting > async. I can't really answer the question because I don't know how > common this will be. My hope is that this will become relatively common. > I have been toying with the idea of creating a multi-threaded async > engine where the engine manages a pool of threads to offload async work > to which would then offer true async support even if you don't have > specialist hardware. > If we have an engine executing long crypto operations, how can we adopt the engine and software using this engine to process them asynchronously? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Oct 7 21:32:00 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Oct 2015 22:32:00 +0100 Subject: [openssl-dev] Adding async support In-Reply-To: References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> Message-ID: <56158F50.1000100@openssl.org> On 07/10/15 21:44, Dmitry Belyavsky wrote: > Dear Matt, > > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell > wrote: > > > > On 07/10/15 14:29, Viktor Dukhovni wrote: > > > > Should applications generally enable async mode because that might > > be beneficial down the road? Or is this just for exotic hardware > > not likely to be seen in most environments? > > It will only be helpful if you have an engine capable of supporting > async. I can't really answer the question because I don't know how > common this will be. My hope is that this will become relatively common. > I have been toying with the idea of creating a multi-threaded async > engine where the engine manages a pool of threads to offload async work > to which would then offer true async support even if you don't have > specialist hardware. > > > If we have an engine executing long crypto operations, how can we adopt > the engine and software using this engine to process them asynchronously? The engine needs to have a way of offloading the work to "something else" so that it can come back and pick up the results later. Typically for an engine this would mean some external hardware, but as I suggested above it could be done using threads. >From an engine perspective the work would be: - Receive a request to do some crypto work in the normal way via the engine API. - Offload the work to "something else" - Call the new API function ASYNC_pause_job(). This will return control back to the calling application. - At sometime later, preferably when the application knows the work has completed (* see below), the application will resume the async job. From an engine perspective this just appears as the ASYNC_pause_job() function call returning - so it just continues where it left off - The engine should verify that the work offloaded to "something else" has completed. - If not it just calls ASYNC_pause_job() again as before. - If it has completed then it collects the results and returns them back in the normal way for an engine >From an application perspective it depends whether it is using libcrypto directly, or whether it is using libssl. If libssl then: - the application essentially operates as normal - additionally it must call either SSL_CTX_set_mode() or SSL_set_mode to set the SSL_ASYNC_MODE - In any call to SSL_read/SSL_write/SSL_accept/SSL_connect etc, it must be prepared to handle an SSL_ERROR_WANT_ASYNC response. This works in essentially the same way as SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, i.e sometime later (* see below) it recalls SSL_read/SSL_write/SSL_accept/SSL_connect and the async job is resumed. If using libcrypto then: - the application must determine which crypto operations it wants to perform asynchronously. Those operations should be wrapped in an application defined function. - the application initiates the async job by calling ASYNC_start_job and passing in a pointer to the function to be started as a job. - from an engine perspective it will work in exactly the same way as for libssl initiated crypto work. - ASYNC_start_job may return with an ASYNC_PAUSE response. The application can go off and do other work, and then resume the job at a later time by recalling ASYNC_start_job. So the next question is how does the application know when it is ok to resume a job? There are two basic models: - Event based...essentially the engine signals to the application that the results are ready for collection - Polling...in this model the application will have to periodically restart the job to see if it is ready to be continued or not There are API calls available for the event based model. See ASYNC_wake(), ASYNC_clear_wake(), ASYNC_get_wait_fd(), and SSL_get_async_wait_fd() in the documentation links I sent out previously. There is some example code in the ASYNC_start_job() documentation. You can also look at the source code for the dummy async engine. Matt From rt at openssl.org Thu Oct 8 00:47:21 2015 From: rt at openssl.org (Moonchild via RT) Date: Thu, 08 Oct 2015 00:47:21 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <5615B03F.9020303@palemoon.org> References: <5615B03F.9020303@palemoon.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello people, An enhancement request here for OpenSSL to add support for Camellia in GCM with ECC key exchange. Rationale: Camellia has been recognized as a modern and supported cipher by ENISA, NESSIE, CRYPTREC, ISO and IETF among others so should be supported long-term. OpenSSL currently only supports the (rather expensive) DHE/RSA CBC+IV versions of the suite, and should be updated with the ECC and GCM modes of operation. It's important to have at least one cipher coming from non-US expert bodies that is maintained to the same level as AES currently is, and OpenSSL seems to be trailing behind in that respect. I would request addition of at least the following: TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc086) TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc08a) And possibly their 256-bit counterparts These suites are already supported in e.g. GNUTLS, Botan and PolarSSL, iiuc. Firefox will also be adding the GCM versions of Camellia to NSS, and my own browser (Pale Moon) also has it slated for the next milestone. Considering the large use of OpenSSL to build other software on, including big names, e.g. nginx, it's of great importance to add these suites. Thanks for your consideration, Moonchild (AKA Mark) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iF4EAREIAAYFAlYVsD8ACgkQEguw022l8qzGgAD+K6r2gxYYQRjrfAqz+JX1ClG9 1wsCrrMe1GZlnQLjAS0BAJmLVXej56Xpd8qNK4+tMucquUIjip8TNxTKyQu/MOeB =wzz5 -----END PGP SIGNATURE----- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 8 08:53:26 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 08 Oct 2015 08:53:26 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <20151008085308.GA4347@kronk.local> References: <5615B03F.9020303@palemoon.org> <20151008085308.GA4347@kronk.local> Message-ID: On Thu, Oct 08, 2015 at 12:47:21AM +0000, Moonchild via RT wrote: > Hello people, > > An enhancement request here for OpenSSL to add support for Camellia in GCM > with ECC key exchange. > > Rationale: > Camellia has been recognized as a modern and supported cipher by ENISA, > NESSIE, CRYPTREC, ISO and IETF among others so should be supported > long-term. OpenSSL currently only supports the (rather expensive) DHE/RSA > CBC+IV versions of the suite, and should be updated with the ECC and GCM > modes of operation. > > It's important to have at least one cipher coming from non-US expert bodies > that is maintained to the same level as AES currently is, and OpenSSL seems > to be trailing behind in that respect. I would request addition of at least > the following: > > TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc086) > TLS_ECDHE_RSA_WITH_CAMELLIA_128_GCM_SHA256 (0xc08a) > And possibly their 256-bit counterparts Patches for this are available at [0], however there has been some resistance to adding the new TLS cipher suites to OpenSSL (see [1]), so the discussion has stalled. > These suites are already supported in e.g. GNUTLS, Botan and PolarSSL, iiuc. > Firefox will also be adding the GCM versions of Camellia to NSS Do you have a source for the news above? IIRC Firefox used to support Camellia, but dropped it in v37 or so. Cheers [0] https://github.com/openssl/openssl/pull/374 [1] https://rt.openssl.org/Ticket/Display.html?id=4017 From rt at openssl.org Thu Oct 8 08:55:45 2015 From: rt at openssl.org (Zhang Yan via RT) Date: Thu, 08 Oct 2015 08:55:45 +0000 Subject: [openssl-dev] =?utf-8?b?W29wZW5zc2wub3JnICM0MDc2XSBQUk9CTEVN77ya?= =?utf-8?q?_there_exists_a_wrong_return_value_of_function_int=5Frsa?= =?utf-8?b?X3ZlcmlmeSgp?= In-Reply-To: <6b37aa52.fb81.150467afad5.Coremail.rucsoftsec@163.com> References: <6b37aa52.fb81.150467afad5.Coremail.rucsoftsec@163.com> Message-ID: Bug Description: Function int_rsa_verify() defined in file crypto/rsa/rsa_sign.c would return 1 if a signature is valid, and 0 otherwise. The variable 'ret' keeps the return value, and it may be assigned to 1 if the condition in line 216 is satisfied. The signature is regarded as invalid if the conditions in line 241 are evaluated to be true, and the error message is dumped (in line 242) and the verify process is ended (in line 243). However, as variable 'ret' may keep value 1, this function will return 1 (in line 290) even if the signature is invalid, which will confuse the caller function whether the signature is really valid. The related code snippets in int_rsa_verify() is as following. 168 int int_rsa_verify(int dtype, const unsigned char *m, 169 unsigned int m_len, 170 unsigned char *rm, size_t *prm_len, 171 const unsigned char *sigbuf, size_t siglen, RSA *rsa) 172 { 173 int i, ret = 0, sigtype; ... 216 if (dtype == NID_mdc2 && i == 18 && s[0] == 0x04 && s[1] == 0x10) { 217 if (rm) { 218 memcpy(rm, s + 2, 16); 219 *prm_len = 16; 220 ret = 1; 221 } else if (memcmp(m, s + 2, 16)) 222 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE); 223 else 224 ret = 1; 225 } 226 227 /* Special case: SSL signature */ 228 if (dtype == NID_md5_sha1) { 229 if ((i != SSL_SIG_LENGTH) || memcmp(s, m, SSL_SIG_LENGTH)) 230 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE); 231 else 232 ret = 1; 233 } else { // dtype != NID_md5_sha1 234 const unsigned char *p = s; 235 sig = d2i_X509_SIG(NULL, &p, (long)i); 236 237 if (sig == NULL) 238 goto err; 239 240 /* Excess data can be used to create forgeries */ 241 if (p != s + i || !rsa_check_digestinfo(sig, s, i)) { 242 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE); 243 goto err; 244 } ... 283 err: 284 if (sig != NULL) 285 X509_SIG_free(sig); 286 if (s != NULL) { 287 OPENSSL_cleanse(s, (unsigned int)siglen); 288 OPENSSL_free(s); 289 } 290 return (ret); 291 } -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 8 10:12:51 2015 From: rt at openssl.org (Moonchild via RT) Date: Thu, 08 Oct 2015 10:12:51 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <56164199.9010101@palemoon.org> References: <5615B03F.9020303@palemoon.org> <20151008085308.GA4347@kronk.local> <56164199.9010101@palemoon.org> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/10/2015 10:53, Alessandro Ghedini via RT wrote: > Patches for this are available at [0], however there has been some > resistance to adding the new TLS cipher suites to OpenSSL (see [1]), so > the discussion has stalled. That's really disappointing! I don't understand the resistance to this addition. It's a cipher with no known attacks found over the past decade or so... >> These suites are already supported in e.g. GNUTLS, Botan and PolarSSL, >> iiuc. Firefox will also be adding the GCM versions of Camellia to NSS > > Do you have a source for the news above? IIRC Firefox used to support > Camellia, but dropped it in v37 or so. Other libs supporting this: GNUTLS: http://gnutls.org/manual/html_node/Supported-ciphersuites.html Botan: http://botan.randombit.net/manual/tls.html#tls-policies PolarSSL: https://tls.mbed.org/supported-ssl-ciphersuites Addition to Firefox/NSS: See recent discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=1211248 (which addresses the premature removal of Camellia CBC ciphers) and recent activity on https://bugzilla.mozilla.org/show_bug.cgi?id=940119 (the actual implementation bug, which had stalled for a while but seems to want to get moving again. It has a reviewed patch.) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iF4EAREIAAYFAlYWQZkACgkQEguw022l8qzFBgD/d+FXvjUQA8CiqpA1ID1hm5em DFTBvTWBq5h5TIITRQ0A/0szG+yjimez7doxczfqzCpa8pb67BgegSAkUpsF6z8a =hAzy -----END PGP SIGNATURE----- From beldmit at gmail.com Thu Oct 8 10:26:55 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 8 Oct 2015 13:26:55 +0300 Subject: [openssl-dev] Adding async support In-Reply-To: <56158F50.1000100@openssl.org> References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> <56158F50.1000100@openssl.org> Message-ID: Dear Matt, I have some questions. On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell wrote: > > > On 07/10/15 21:44, Dmitry Belyavsky wrote: > > Dear Matt, > > > > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell > > wrote: > > > > > > > > On 07/10/15 14:29, Viktor Dukhovni wrote: > > > > > > Should applications generally enable async mode because that might > > > be beneficial down the road? Or is this just for exotic hardware > > > not likely to be seen in most environments? > > > > It will only be helpful if you have an engine capable of supporting > > async. I can't really answer the question because I don't know how > > common this will be. My hope is that this will become relatively > common. > > I have been toying with the idea of creating a multi-threaded async > > engine where the engine manages a pool of threads to offload async > work > > to which would then offer true async support even if you don't have > > specialist hardware. > > > > > > If we have an engine executing long crypto operations, how can we adopt > > the engine and software using this engine to process them asynchronously? > > The engine needs to have a way of offloading the work to "something > else" so that it can come back and pick up the results later. Typically > for an engine this would mean some external hardware, but as I suggested > above it could be done using threads. > > From an engine perspective the work would be: > - Receive a request to do some crypto work in the normal way via the > engine API. > - Offload the work to "something else" > So what is a mechanism of such an offload? Can I, for example, get the (global) ASYNC_pool and add a job (function/pointer to context) to it? > - Call the new API function ASYNC_pause_job(). This will return control > back to the calling application. > > - At sometime later, preferably when the application knows the work has > completed (* see below), the application will resume the async job. From > an engine perspective this just appears as the ASYNC_pause_job() > function call returning - so it just continues where it left off > - The engine should verify that the work offloaded to "something else" > has completed. > - If not it just calls ASYNC_pause_job() again as before. > - If it has completed then it collects the results and returns them back > in the normal way for an engine > > From an application perspective it depends whether it is using libcrypto > directly, or whether it is using libssl. > > If libssl then: > - the application essentially operates as normal > - additionally it must call either SSL_CTX_set_mode() or SSL_set_mode to > set the SSL_ASYNC_MODE > - In any call to SSL_read/SSL_write/SSL_accept/SSL_connect etc, it must > be prepared to handle an SSL_ERROR_WANT_ASYNC response. This works in > essentially the same way as SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, > i.e sometime later (* see below) it recalls > SSL_read/SSL_write/SSL_accept/SSL_connect and the async job is resumed. > How will the SSL struct obtain a job id from the engine implementing, for example, "long" RSA_METHOD? > > If using libcrypto then: > - the application must determine which crypto operations it wants to > perform asynchronously. Those operations should be wrapped in an > application defined function. > - the application initiates the async job by calling ASYNC_start_job and > passing in a pointer to the function to be started as a job. > - from an engine perspective it will work in exactly the same way as for > libssl initiated crypto work. > - ASYNC_start_job may return with an ASYNC_PAUSE response. The > application can go off and do other work, and then resume the job at a > later time by recalling ASYNC_start_job. > So do I understand correctly that if I want to perform SSL operations asynchronously, I'm able to wrap the SSL functions into the application defined functions and then behave as described herein before? > > > So the next question is how does the application know when it is ok to > resume a job? There are two basic models: > > - Event based...essentially the engine signals to the application that > the results are ready for collection > - Polling...in this model the application will have to periodically > restart the job to see if it is ready to be continued or not > > There are API calls available for the event based model. See > ASYNC_wake(), ASYNC_clear_wake(), ASYNC_get_wait_fd(), and > SSL_get_async_wait_fd() in the documentation links I sent out previously. > > There is some example code in the ASYNC_start_job() documentation. You > can also look at the source code for the dummy async engine. > Thank you. I've looked through them but still did not understand completely. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Oct 8 10:56:44 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2015 11:56:44 +0100 Subject: [openssl-dev] Adding async support In-Reply-To: References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> <56158F50.1000100@openssl.org> Message-ID: <56164BEC.1070801@openssl.org> On 08/10/15 11:26, Dmitry Belyavsky wrote: > Dear Matt, > > I have some questions. > > On Thu, Oct 8, 2015 at 12:32 AM, Matt Caswell > wrote: > > > > On 07/10/15 21:44, Dmitry Belyavsky wrote: > > Dear Matt, > > > > On Wed, Oct 7, 2015 at 4:43 PM, Matt Caswell > > >> wrote: > > > > > > > > On 07/10/15 14:29, Viktor Dukhovni wrote: > > > > > > Should applications generally enable async mode because that might > > > be beneficial down the road? Or is this just for exotic hardware > > > not likely to be seen in most environments? > > > > It will only be helpful if you have an engine capable of supporting > > async. I can't really answer the question because I don't know how > > common this will be. My hope is that this will become relatively common. > > I have been toying with the idea of creating a multi-threaded async > > engine where the engine manages a pool of threads to offload async work > > to which would then offer true async support even if you don't have > > specialist hardware. > > > > > > If we have an engine executing long crypto operations, how can we adopt > > the engine and software using this engine to process them asynchronously? > > The engine needs to have a way of offloading the work to "something > else" so that it can come back and pick up the results later. Typically > for an engine this would mean some external hardware, but as I suggested > above it could be done using threads. > > From an engine perspective the work would be: > - Receive a request to do some crypto work in the normal way via the > engine API. > - Offload the work to "something else" > > > So what is a mechanism of such an offload? Can I, for example, get the > (global) ASYNC_pool and add a job (function/pointer to context) to it? The offload mechanism is entirely engine specific. We do not know how any specific engine works or how to interface to the hardware. An engine will be called in exactly the same way as now. The job of the engine will be to take the parameters passed to it and initiate the work in the engine hardware. So in pseudo code it might look something like this: static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out, const unsigned char *in, size_t inl) { int jobid; jobid = offload_cipher_to_hardware(ctx, out, in , inl); /* * jobid holds a reference in the engine back to the work we just * started */ while(work_not_finished_yet(jobid)) { /* Return control back to the calling application */ ASYNC_pause_job(); } return get_results_from_hardware(jobid); } You will note that ASYNC_pause_job() does *not* do a "return" to return control back to the user application...but calling ASYNC_pause_job() will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC nonetheless. The async job has its own private stack to enable this. Recalling SSL_read from the user application will appear to the engine like the function call ASYNC_pause_job() has returned. > How will the SSL struct obtain a job id from the engine implementing, > for example, "long" RSA_METHOD? It does not need to. The SSL object has a reference to the ASYNC_JOB. The engine can manage its own job ids - see the pseudo code above. > > > > If using libcrypto then: > - the application must determine which crypto operations it wants to > perform asynchronously. Those operations should be wrapped in an > application defined function. > - the application initiates the async job by calling ASYNC_start_job and > passing in a pointer to the function to be started as a job. > - from an engine perspective it will work in exactly the same way as for > libssl initiated crypto work. > - ASYNC_start_job may return with an ASYNC_PAUSE response. The > application can go off and do other work, and then resume the job at a > later time by recalling ASYNC_start_job. > > > So do I understand correctly that if I want to perform SSL operations > asynchronously, > I'm able to wrap the SSL functions into the application defined > functions and then behave as described > herein before? If you are doing SSL operations you do not need to wrap them in a function as described above (although you could do if you wanted to). libssl will do all of this for you. You only have to define your own function for the job if you are calling libcrypto directly. For an application doing SSL it will work very much like non-blocking IO works today. Matt From beldmit at gmail.com Thu Oct 8 11:18:21 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 8 Oct 2015 14:18:21 +0300 Subject: [openssl-dev] Adding async support In-Reply-To: <56164BEC.1070801@openssl.org> References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> <56158F50.1000100@openssl.org> <56164BEC.1070801@openssl.org> Message-ID: Dear Matt, On Thu, Oct 8, 2015 at 1:56 PM, Matt Caswell wrote: > > > The engine needs to have a way of offloading the work to "something > > else" so that it can come back and pick up the results later. > Typically > > for an engine this would mean some external hardware, but as I > suggested > > above it could be done using threads. > > > > From an engine perspective the work would be: > > - Receive a request to do some crypto work in the normal way via the > > engine API. > > - Offload the work to "something else" > > > > > > So what is a mechanism of such an offload? Can I, for example, get the > > (global) ASYNC_pool and add a job (function/pointer to context) to it? > > The offload mechanism is entirely engine specific. We do not know how > any specific engine works or how to interface to the hardware. An engine > will be called in exactly the same way as now. The job of the engine > will be to take the parameters passed to it and initiate the work in the > engine hardware. > > So in pseudo code it might look something like this: > > static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx, > unsigned char *out, const unsigned char *in, size_t inl) > { > int jobid; > > jobid = offload_cipher_to_hardware(ctx, out, in , inl); > > /* > * jobid holds a reference in the engine back to the work we just > * started > */ > > while(work_not_finished_yet(jobid)) { > /* Return control back to the calling application */ > ASYNC_pause_job(); > } > > return get_results_from_hardware(jobid); > } > > You will note that ASYNC_pause_job() does *not* do a "return" to return > control back to the user application...but calling ASYNC_pause_job() > will cause SSL_read (or whatever) to return with SSL_ERROR_WANT_ASYNC > nonetheless. The async job has its own private stack to enable this. > Recalling SSL_read from the user application will appear to the engine > like the function call ASYNC_pause_job() has returned. > > > > How will the SSL struct obtain a job id from the engine implementing, > > for example, "long" RSA_METHOD? > > It does not need to. The SSL object has a reference to the ASYNC_JOB. > The engine can manage its own job ids - see the pseudo code above. > I see. So am I correct supposing that pseudo code for offload_cipher_to_hardware looks like this: static int async_wrapper(void * args) { ... } static ASYNC_JOB *offload (void *args) { ASYNC_JOB *pjob = NULL; int funcret; size_t size = 0; int ret = ASYNC_start_job(&pjob, &funcret, async_wrapper, args, *args, size); if (ret != ASYNC_PAUSE) return NULL; return pjob; } ? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From aaronmdjones at gmail.com Thu Oct 8 11:27:30 2015 From: aaronmdjones at gmail.com (Aaron Jones) Date: Thu, 8 Oct 2015 11:27:30 +0000 Subject: [openssl-dev] Elliptical Cipher Suites In-Reply-To: <55A0598A7539EC4BAB296D8BBA5AC122BFFC66F0@WTPCPMBMEM07.ams.bnymellon.net> References: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> <20151007125558.GA15070@mournblade.imrryr.org> <55A0598A7539EC4BAB296D8BBA5AC122BFFC66F0@WTPCPMBMEM07.ams.bnymellon.net> Message-ID: <56165322.3030200@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 07/10/15 13:54, Thirumal, Karthikeyan wrote: > Vik Am using 0.9.8a version. Am trying to fix few weak ciphers in > my SSL connection and also to make Elliptical cipher suites > enable. I see that ECDHE ciphers are elliptical - need more info on > this. > > Thanks & Regards 0.9.8 will be end-of-life in a matter of days, and does not support elliptic curve cryptography; that was introduced in version 1.0.0, also end of life soon if I recall correctly. Version 1.0.1 is supported, and supports both ECC and TLSv1.2. I would recommend upgrading to atleast that. - -- Aaron Jones -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWFlMgAAoJEG6FTA+q1M6k8QwP/0PNp9igXfpzvPOclG0DublE 0atEp5pJwFATfphWi9ejhRJpXo4h6UP3QEhgX4e/y2RWmNdV2jCasRXGhjQEnDWD pnoeKgNdAIFxy7jcYfj0zXk8mudX992KTKzDWErprjE5PLVnUNOjYe2rlz6blCKV TKHafvCbUEA0B9cGJ2ed8wkDX9VZZq1pdT4Ji9oa7Nlh8jti598aO6TeJ36etfUM vQ7hZOQLbaft5VtmmahytFsw+n4DX2b87pNrSQZURhhcAR8ZWt0+wCl+HrWgNyrA OPEyDANys1y9u2MorxRHUtUErBD98MxklFwwc/r3DZbH6h/AxXsI4Jvz6CjMRo2G 3nuxqa4E6NELiykKccnFKiWYZHXqRNqp1OxtYO4N0HTy2EBuigyYMnVp5Lpv3r7f TXxfDWTvttd5S+0uZ0kfaT4xSs2ctbRemJ1iXVXGpdKv/V+qqJrSDwgSdgB/+FxG 4Tbcl6Uw/RVR1LCcq7Iu4oJhpL2LoGwqXcGYumI+suDP26rkea0VMWc4AZoEsZmb fJx3p5O4p8aMhtU+IorpnsBXRz11DrI7P/sLZdB490p2wNulNP9qNcC2SC5V4v3b fR40omXMBk4Pdm2cAuy+MCey1pf7B9qhqVrG2XPKbs1M2oGlnlfWb22YaxiDDKsK oskRsBrLNjugbntmtw5P =Aqxk -----END PGP SIGNATURE----- From rt at openssl.org Thu Oct 8 11:34:48 2015 From: rt at openssl.org (Simon Josefsson via RT) Date: Thu, 08 Oct 2015 11:34:48 +0000 Subject: [openssl-dev] [openssl.org #4077] Add support for EdDSA and Ed25519 In-Reply-To: <87mvvtu1kt.fsf@latte.josefsson.org> References: <87mvvtu1kt.fsf@latte.josefsson.org> Message-ID: I believe it would be useful to have OpenSSL support for Ed25519 signing and Curve25519 key agreement. I don't see anything on rt.openssl.org about this (maybe the proper place to open issue is on github these days?). Is there interest in this from the OpenSSL team? There are several implementations available, but I would coordinate which one to use with Peter Schwabe who has been working on proving correctness of Ed25519 implementations. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 8 11:39:56 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 08 Oct 2015 11:39:56 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: References: <5615B03F.9020303@palemoon.org> <20151008085308.GA4347@kronk.local> <56164199.9010101@palemoon.org> Message-ID: Also, note that the earliest this could happen is for 1.1 (it's a new feature), and it's not high on our priority list for that release right now. Patches that are regularly rebased against master would help. From rsalz at akamai.com Thu Oct 8 11:45:35 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 8 Oct 2015 11:45:35 +0000 Subject: [openssl-dev] [openssl.org #4077] Add support for EdDSA and Ed25519 In-Reply-To: References: <87mvvtu1kt.fsf@latte.josefsson.org> Message-ID: <5ccaa1caba784c7db37406e804fae785@ustx2ex-dag1mb3.msg.corp.akamai.com> There is a GREAT DEAL of interest in *25519 :) It would be great to see a PR against master; I'd push it through the review process as fast as possible. If you and Peter have the interest in working on this, that would be great. From matt at openssl.org Thu Oct 8 12:01:41 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2015 13:01:41 +0100 Subject: [openssl-dev] Elliptical Cipher Suites In-Reply-To: <56165322.3030200@gmail.com> References: <55A0598A7539EC4BAB296D8BBA5AC122BFFC6464@WTPCPMBMEM07.ams.bnymellon.net> <20151007125558.GA15070@mournblade.imrryr.org> <55A0598A7539EC4BAB296D8BBA5AC122BFFC66F0@WTPCPMBMEM07.ams.bnymellon.net> <56165322.3030200@gmail.com> Message-ID: <56165B25.3070507@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 08/10/15 12:27, Aaron Jones wrote: > On 07/10/15 13:54, Thirumal, Karthikeyan wrote: >> Vik Am using 0.9.8a version. Am trying to fix few weak ciphers >> in my SSL connection and also to make Elliptical cipher suites >> enable. I see that ECDHE ciphers are elliptical - need more info >> on this. > >> Thanks & Regards > > 0.9.8 will be end-of-life in a matter of days, and does not > support elliptic curve cryptography; that was introduced in version > 1.0.0, also end of life soon if I recall correctly. > > Version 1.0.1 is supported, and supports both ECC and TLSv1.2. I > would recommend upgrading to atleast that. Version 1.0.1 is EOL at end of 2016. An upgrade to 1.0.2 should be considered. Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWFlslAAoJENnE0m0OYESRIJYIAK+jHwV2NuaLxU3FiVbYVswh sBAczFvNTJggfZAQpaVK94S1rYK2XBeTlYz0bGv/zT74sARLtos2HxqqxLD10TgO 7yAw7OvtV5CxTu09Lf6UuYDTvATflKSREQOJQYXoMM/aK4pSQBvlChfkc7op9v+o 0RNHx4xK0A313B7tZ+fBPZnqwjruC/t1oDAVlVJ90W3y/Z0+w2cFZXbFXvUvkkPr 4HhTFXS8G1Yy+UjQ+tVbyKnHgAuR+xj6EuaLhS7xMAXJfVh34g0soB9zM36ygbHH /Pa33tFp66QlGyTlFosFrymcq9U3PXeSIzs7HCuJZSoaHv6RGe1LJDA3qeUccb4= =Glns -----END PGP SIGNATURE----- From rt at openssl.org Thu Oct 8 12:12:48 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 08 Oct 2015 12:12:48 +0000 Subject: [openssl-dev] [openssl.org #4075] Enhancement request: Camellia ECDHE+GCM suites In-Reply-To: <20151008121239.GA25792@kronk.local> References: <5615B03F.9020303@palemoon.org> <20151008085308.GA4347@kronk.local> <56164199.9010101@palemoon.org> <20151008121239.GA25792@kronk.local> Message-ID: On Thu, Oct 08, 2015 at 11:39:56am +0000, Salz, Rich via RT wrote: > Also, note that the earliest this could happen is for 1.1 (it's a new > feature), and it's not high on our priority list for that release right now. > Patches that are regularly rebased against master would help. I rebase my patches on master regularly when changes that cause merge conflicts are pushed, so my camellia patches should merge cleanly. Cheers From matt at openssl.org Thu Oct 8 12:17:16 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2015 13:17:16 +0100 Subject: [openssl-dev] Adding async support In-Reply-To: References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> <56158F50.1000100@openssl.org> <56164BEC.1070801@openssl.org> Message-ID: <56165ECC.9080107@openssl.org> On 08/10/15 12:18, Dmitry Belyavsky wrote: > > I see. So am I correct supposing that pseudo code for > offload_cipher_to_hardware looks like this: > > static int async_wrapper(void * args) > { > ... > } > > static ASYNC_JOB *offload (void *args) > { > ASYNC_JOB *pjob = NULL; > int funcret; > size_t size = 0; > > int ret = ASYNC_start_job(&pjob, &funcret, async_wrapper, args, > *args, size); > if (ret != ASYNC_PAUSE) return NULL; > return pjob; > } > > ? No. I think you are confusing two different things. 1) How does an *application* perform asynchronous work (via libssl or libcrypto) using an asynchronous capable engine? 2) How does an asynchronous capable engine offload async work to its hardware? These patches solve the first problem only. It provides an API and mechanism for control to pass between the application and engine and back again (perhaps multiple times) during the invocation of a long running crypto operation. It also provides some mechanisms to enable an engine to signal the completion of work to the application. The second problem is entirely engine dependant. It will be a different solution for different hardware. These patches do not provide a solution to that problem. Matt From rt at openssl.org Thu Oct 8 13:29:33 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 08 Oct 2015 13:29:33 +0000 Subject: [openssl-dev] =?utf-8?b?W29wZW5zc2wub3JnICM0MDc2XSBQUk9CTEVN77ya?= =?utf-8?q?_there_exists_a_wrong_return_value_of_function_int=5Frsa?= =?utf-8?b?X3ZlcmlmeSgp?= In-Reply-To: <6b37aa52.fb81.150467afad5.Coremail.rucsoftsec@163.com> References: <6b37aa52.fb81.150467afad5.Coremail.rucsoftsec@163.com> Message-ID: On Thu Oct 08 08:55:45 2015, rucsoftsec at 163.com wrote: > Bug Description: > Function int_rsa_verify() defined in file crypto/rsa/rsa_sign.c would > return 1 if a signature is valid, and 0 otherwise. The variable 'ret' > keeps the return value, and it may be assigned to 1 if the condition > in line 216 is satisfied. The signature is regarded as invalid if the > conditions in line 241 are evaluated to be true, and the error message > is dumped (in line 242) and the verify process is ended (in line 243). > However, as variable 'ret' may keep value 1, this function will return > 1 (in line 290) even if the signature is invalid, which will confuse > the caller function whether the signature is really valid. Thanks for your report. I think your analysis is partially correct. If the condition on line 216 evaluates to true then this means that the signature data is just a bare OCTETSTRING. Really there should be an "else" on line 225 to prevent the other branches from occurring. As it is the code will fall through to the "else" on line 233 and it will then attempt to parse the signature data as DigestInfo (X509_SIG). This will clearly fail because we already know that it is a bare OCTETSTRING. Therefore |sig| will be NULL and we will goto the |err| label - which is exactly where we would have ended up anyway had there been an else on line 225 as I suggest. So there is no real impact to this. You will never get to the signature validity test on line 241 as you suggest if line 216 evaluates to true (and that test would not apply anyway in this case). Functionally then it is working correctly (kind of). However I have applied a patch anyway to prevent the erroneous attempt to parse sig, and to make things look a bit more sane: https://github.com/openssl/openssl/commit/dffe51091f412dcbc18f6641132f0b4f0def6bce Closing this ticket. Matt > The related code snippets in int_rsa_verify() is as following. > 168 int int_rsa_verify(int dtype, const unsigned char *m, > 169 unsigned int m_len, > 170 unsigned char *rm, size_t *prm_len, > 171 const unsigned char *sigbuf, size_t siglen, RSA > *rsa) > 172 { > 173 int i, ret = 0, sigtype; > ... > 216 if (dtype == NID_mdc2 && i == 18 && s[0] == 0x04 && s[1] == > 0x10) { > 217 if (rm) { > 218 memcpy(rm, s + 2, 16); > 219 *prm_len = 16; > 220 ret = 1; > 221 } else if (memcmp(m, s + 2, 16)) > 222 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE); > 223 else > 224 ret = 1; > 225 } > 226 > 227 /* Special case: SSL signature */ > 228 if (dtype == NID_md5_sha1) { > 229 if ((i != SSL_SIG_LENGTH) || memcmp(s, m, SSL_SIG_LENGTH)) > 230 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE); > 231 else > 232 ret = 1; > 233 } else { // dtype != NID_md5_sha1 > 234 const unsigned char *p = s; > 235 sig = d2i_X509_SIG(NULL, &p, (long)i); > 236 > 237 if (sig == NULL) > 238 goto err; > 239 > 240 /* Excess data can be used to create forgeries */ > 241 if (p != s + i || !rsa_check_digestinfo(sig, s, i)) { > 242 RSAerr(RSA_F_INT_RSA_VERIFY, RSA_R_BAD_SIGNATURE); > 243 goto err; > 244 } > ... > 283 err: > 284 if (sig != NULL) > 285 X509_SIG_free(sig); > 286 if (s != NULL) { > 287 OPENSSL_cleanse(s, (unsigned int)siglen); > 288 OPENSSL_free(s); > 289 } > 290 return (ret); > 291 } > > > > > From rt at openssl.org Thu Oct 8 13:36:07 2015 From: rt at openssl.org (Pascal Cuoq via RT) Date: Thu, 08 Oct 2015 13:36:07 +0000 Subject: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests In-Reply-To: <423156DC-0112-4DD7-B690-3B0412C88181@trust-in-soft.com> References: <20151007200902.GA11112@roeckx.be> <423156DC-0112-4DD7-B690-3B0412C88181@trust-in-soft.com> Message-ID: Hello Kurt, thanks for looking into these ! On 07 Oct 2015, at 22:17, Kurt Roeckx via RT wrote: > > So some of the patches got applied, but I have some comments about > the remaining: > - ssl_locl.h.patch: I don't see a struct timeval > crypto/x509v3/v3_scts.c. Does this comment still apply? Maybe > we fixed the issue in some other way. Sorry, this comment was unnecessarily confusing. What we meant to say was that the OpenSSL header ssl/ssl_locl.h uses ?struct timeval? (at line 1445: https://github.com/openssl/openssl/blob/b3e2272c59a5720467045e2ae62940fdb708ce76/ssl/ssl_locl.h#L1445 ) but the POSIX header that is guaranteed to provide this type, sys/time.h, is not included. This is just a portability matter. It works in practice of most platforms because that header is dragged in by other headers. > - malloc.patch: I started looking at it, and I have some > comments/questions: > - I currently don't see a way that s->d1 can be NULL except > after an dtls1_free() call. The same seem to go for > DTLS_RECORD_LAYER_free(), ssl3_free(), pkey_hmac_cleanup(), > aes_gcm_cleanup() and aes_ocb_cleanup(). > Are you saying there are cases we could end up calling those > twice? All the patches in the file malloc.patch are for problems, typically null pointer dereferences, that arise when the function malloc() is modeled as either returning a null pointer or a valid pointer to a fresh block. We know this because we also ran all the tests in a mode in which malloc was assumed to always succeed, and in that mode, none of the fixes recommended in malloc.patch were necessary. So for instance, in the development version of OpenSSL that was current at the time of the report, that ?s->d1? could be NULL because a malloc call had returned NULL. > - It seems to contain changes to the test suite to check return > values. It seems non-obvious that this is about memory > allocation that might have failed, but it's probably the only > reasons those failures can happen. Yes, exactly. The failures of OpenSSL functions that malloc.patch adds tests for happen because of a specific sequence of allocation successes and failures. > It's a little confusing > that it's in the same patch where you can't directly see the > malloc failing. Yes, it is confusing! While we are confident that each of the null pointer dereferences we observed can happen for a specific sequence of malloc successes and failures (by design of the analysis process), the fixes that we are suggesting may be the wrong ones for the problems we have seen. What we are going to do now that you have already applied many of the patches is: - replay the same verification process on the most recent version of OpenSSL, and update this bug report with the issues that are still present only; - and then give you access to the analyzer results in a way that lets you observe the sequence of events leading to the null pointer dereferences, and choose for yourselves the best remedy. From rt at openssl.org Thu Oct 8 13:41:01 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 08 Oct 2015 13:41:01 +0000 Subject: [openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing In-Reply-To: <20151008134052.GA31565@kronk.local> References: <20151008134052.GA31565@kronk.local> Message-ID: The GitHub pull request was merged, so this can be closed now. Cheers From rt at openssl.org Thu Oct 8 13:43:19 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 08 Oct 2015 13:43:19 +0000 Subject: [openssl-dev] [openssl.org #3982] [PATCH] Fix unhandled error condition in sslv2 client hello parsing In-Reply-To: References: Message-ID: Patch was applied. Closing. Matt From rt at openssl.org Thu Oct 8 13:51:04 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 08 Oct 2015 13:51:04 +0000 Subject: [openssl-dev] [openssl.org #4078] remove MDC2 support (1.1 dev branch) References: Message-ID: Tracking ticket - if anyone has any concerns, please voice them now. From rt at openssl.org Thu Oct 8 16:09:36 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Thu, 08 Oct 2015 16:09:36 +0000 Subject: [openssl-dev] [openssl.org #4079] syntax error with EVP_CHECK_DES_KEY In-Reply-To: <5616953A.9090206@akamai.com> References: <5616953A.9090206@akamai.com> Message-ID: Code inspection of crypto/evp/e_des3.c reveals that !! was used instead of || (and then subsequently reformatted by a script): 272 # ifdef EVP_CHECK_DES_KEY 273 if (DES_set_key_checked(&deskey[0], &dat->ks1) 274 ! !DES_set_key_checked(&deskey[1], &dat->ks2)) 275 return 0; -Ben _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 8 16:12:50 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Thu, 08 Oct 2015 16:12:50 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> Message-ID: The server does not abort connection upon receiving a Client Hello message with malformed session_id field. Affects 1.0.1, 1.0.2 and master. In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is defined as opaque SessionID<0..32>; that means, that any SessionID longer than 32 bytes creates an incorrectly formatted Client Hello message, and as such, should be rejected. Reproducer: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt - nodes -batch openssl s_server -key localhost.key -cert localhost.crt In different console: pip install --pre tlslite-ng git clone https://github.com/tomato42/tlsfuzzer.git cd tlsfuzzer PYTHONPATH=. python scripts/test-invalid-session-id.py -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 8 16:18:53 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Thu, 08 Oct 2015 16:18:53 +0000 Subject: [openssl-dev] [openssl.org #4081] crypto/evp/e_dsa.c is orphaned In-Reply-To: <56169769.4010407@akamai.com> References: <56169769.4010407@akamai.com> Message-ID: crypto/evp/e_dsa.c contains only a single static struct variable, and the file appears unreferenced from anywhere else in the tree. It should be safe to remove. -Ben _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 8 17:19:06 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 08 Oct 2015 17:19:06 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <20151008171902.GA4825@kronk.local> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> <20151008171902.GA4825@kronk.local> Message-ID: On Thu, Oct 08, 2015 at 04:12:50pm +0000, Hubert Kario via RT wrote: > The server does not abort connection upon receiving a Client Hello > message with malformed session_id field. > > Affects 1.0.1, 1.0.2 and master. > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > defined as > > opaque SessionID<0..32>; > > that means, that any SessionID longer than 32 bytes creates an > incorrectly formatted Client Hello message, and as such, should be > rejected. Looking at the code in master, for non-v2 ClientHello messages the code uses the PACKET_get_length_prefixed_1() function to extract the SessionID, however I see no way to pass a maximum allowed length to it. I think a new function would have to be added to the PACKET_* interface (I can look into this). Haven't checked older branches yet. The problem most likely happens with SSLv2 backwards compatible ClientHello as well, but that seems to be easier to fix... or maybe it's time to just drop that compatibility code for v1.1? Cheers From rt at openssl.org Thu Oct 8 17:27:20 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 08 Oct 2015 17:27:20 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <20151008172715.GA27369@roeckx.be> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> <20151008171902.GA4825@kronk.local> <20151008172715.GA27369@roeckx.be> Message-ID: On Thu, Oct 08, 2015 at 05:19:06PM +0000, Alessandro Ghedini via RT wrote: > The problem most likely happens with SSLv2 backwards compatible ClientHello as > well, but that seems to be easier to fix... or maybe it's time to just drop > that compatibility code for v1.1? I would love to have dropped that too, but 0.9.8 still sends such client hello. I think we're stuck with having to support that for a while longer. Kurt From rt at openssl.org Thu Oct 8 17:32:06 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Thu, 08 Oct 2015 17:32:06 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <2927856.2MabSF2eLE@pintsize.usersys.redhat.com> References: <20151008171902.GA4825@kronk.local> <2927856.2MabSF2eLE@pintsize.usersys.redhat.com> Message-ID: On Thursday 08 October 2015 17:19:06 Alessandro Ghedini via RT wrote: > The problem most likely happens with SSLv2 backwards compatible > ClientHello as well, but that seems to be easier to fix... or maybe > it's time to just drop that compatibility code for v1.1? There is quite a bit of clients that do send SSLv2 backwards compatible Client Hello, dropping it completely, even though it allows to relatively safely negotiate TLS connections, is probably going one step too far. I don't plan to work on SSLv2 Client Hello fuzzing in near future though. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From openssl-users at dukhovni.org Thu Oct 8 17:37:12 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 8 Oct 2015 17:37:12 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> Message-ID: <20151008173712.GD15070@mournblade.imrryr.org> On Thu, Oct 08, 2015 at 04:12:50PM +0000, Hubert Kario via RT wrote: > The server does not abort connection upon receiving a Client Hello > message with malformed session_id field. > > Affects 1.0.1, 1.0.2 and master. > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > defined as > > opaque SessionID<0..32>; > > that means, that any SessionID longer than 32 bytes creates an > incorrectly formatted Client Hello message, and as such, should be > rejected. Can be rejected, and perhaps even should be rejected, but I don't see a MUST here. It seems there's little harm in tolerating longer session ids (which never match, so are effectively ignored). So yes, I support adding a check for this (likely above the PACKET layer), but I don't think this has much urgency and likely should not be back-ported to stable releases. -- Viktor. From kurt at roeckx.be Thu Oct 8 17:27:15 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 8 Oct 2015 19:27:15 +0200 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> <20151008171902.GA4825@kronk.local> Message-ID: <20151008172715.GA27369@roeckx.be> On Thu, Oct 08, 2015 at 05:19:06PM +0000, Alessandro Ghedini via RT wrote: > The problem most likely happens with SSLv2 backwards compatible ClientHello as > well, but that seems to be easier to fix... or maybe it's time to just drop > that compatibility code for v1.1? I would love to have dropped that too, but 0.9.8 still sends such client hello. I think we're stuck with having to support that for a while longer. Kurt From beldmit at gmail.com Thu Oct 8 17:56:41 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 8 Oct 2015 20:56:41 +0300 Subject: [openssl-dev] Adding async support In-Reply-To: <56165ECC.9080107@openssl.org> References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> <56158F50.1000100@openssl.org> <56164BEC.1070801@openssl.org> <56165ECC.9080107@openssl.org> Message-ID: Dear Matt, On Thu, Oct 8, 2015 at 3:17 PM, Matt Caswell wrote: > > > No. I think you are confusing two different things. > > 1) How does an *application* perform asynchronous work (via libssl or > libcrypto) using an asynchronous capable engine? > Ok. There is an example an explanation you have provided. > > 2) How does an asynchronous capable engine offload async work to its > hardware? > > These patches solve the first problem only. It provides an API and > mechanism for control to pass between the application and engine and > back again (perhaps multiple times) during the invocation of a long > running crypto operation. It also provides some mechanisms to enable an > engine to signal the completion of work to the application. > > The second problem is entirely engine dependant. It will be a different > solution for different hardware. These patches do not provide a solution > to that problem. > So I do not understand what you mean by "offload" :-( I understand that it's an engine-dependent, but I can't imagine a corresponding pseudo code. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Oct 8 18:14:00 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 08 Oct 2015 18:14:00 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <20151008181348.GA19043@kronk.local> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> <20151008171902.GA4825@kronk.local> <20151008181348.GA19043@kronk.local> Message-ID: On Thu, Oct 08, 2015 at 05:19:06pm +0000, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 04:12:50pm +0000, Hubert Kario via RT wrote: > > The server does not abort connection upon receiving a Client Hello > > message with malformed session_id field. > > > > Affects 1.0.1, 1.0.2 and master. > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > defined as > > > > opaque SessionID<0..32>; > > > > that means, that any SessionID longer than 32 bytes creates an > > incorrectly formatted Client Hello message, and as such, should be > > rejected. > > Looking at the code in master, for non-v2 ClientHello messages the code uses > the PACKET_get_length_prefixed_1() function to extract the SessionID, however I > see no way to pass a maximum allowed length to it. I think a new function would > have to be added to the PACKET_* interface (I can look into this). Haven't > checked older branches yet. So, it turns out the check was already performed, but this failure didn't cause the session to be aborted (the original PACKET was advanced anyway though, even is the session_id isn't actually extracted), I don't know if this was on purpose though. In any case I wrote a minimal patch that makes the tlsfuzzer test pass (it may even work for SSLv2 as well): https://github.com/openssl/openssl/pull/437 Cheers From rt at openssl.org Thu Oct 8 18:26:27 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 08 Oct 2015 18:26:27 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <20151008182623.GA19262@kronk.local> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> <20151008171902.GA4825@kronk.local> <20151008181348.GA19043@kronk.local> <20151008182623.GA19262@kronk.local> Message-ID: On Thu, Oct 08, 2015 at 06:14:00pm +0000, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 05:19:06pm +0000, Alessandro Ghedini via RT wrote: > > On Thu, Oct 08, 2015 at 04:12:50pm +0000, Hubert Kario via RT wrote: > > > The server does not abort connection upon receiving a Client Hello > > > message with malformed session_id field. > > > > > > Affects 1.0.1, 1.0.2 and master. > > > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > > defined as > > > > > > opaque SessionID<0..32>; > > > > > > that means, that any SessionID longer than 32 bytes creates an > > > incorrectly formatted Client Hello message, and as such, should be > > > rejected. > > > > Looking at the code in master, for non-v2 ClientHello messages the code uses > > the PACKET_get_length_prefixed_1() function to extract the SessionID, however I > > see no way to pass a maximum allowed length to it. I think a new function would > > have to be added to the PACKET_* interface (I can look into this). Haven't > > checked older branches yet. > > So, it turns out the check was already performed, but this failure didn't cause > the session to be aborted (the original PACKET was advanced anyway though, even > is the session_id isn't actually extracted), I don't know if this was on > purpose though. Another thing to consider is that the client already aborts when an invalid session_id is received in the ServerHello and sends the ILLEGAL_PARAMETER alert. My patch doesn't actually send any alert so the check should be moved earlier to allow an alert to be sent, if that is desired. Cheers From rt at openssl.org Thu Oct 8 19:05:51 2015 From: rt at openssl.org (=?UTF-8?B?RnJhbnRpxaFlayBCb8WZw6FuZWs=?= via RT) Date: Thu, 08 Oct 2015 19:05:51 +0000 Subject: [openssl-dev] [openssl.org #4082] Patch: Unable to read SMIME message if there is no signer In-Reply-To: <3054194218-1144@apu.kerio.local> References: <3054194218-1144@apu.kerio.local> Message-ID: Hi, I found that Outook for MAC can generate (depends on setting) signed message where is not included sender's certificate. It works pretty good, but verification requires that recipients must already have sender certificate. Such message is attached. Problem is that such message cannot be read by openssl. Normally, if a message has a sender certificate, following command print encapsulated message in?smime.p7m. ? ? $ openssl smime -verify -noverify -nosigs -in ~/workspace/00000004.eml? ? ? ?--- content of messge --- ? ? Verification successful however the current behaviour is that error is reported instead the content of message ? ? $ openssl smime -verify -noverify -in ~/workspace/00000005.eml? ? ? Verification failure ? ? 139741085296288:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:pk7_smime.c:462: The attached patch solve this issue. The signer certificate is not look up if there is no need for that. Here and results after what patch was applied. ? ? $ ./external/bin/openssl smime -in ~/workspace/00000005.eml -verify ? ? Verification failure ? ? 139737181419168:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:pk7_smime.c:472: ? ? ? ?$ ./external/bin/openssl smime -in ~/workspace/00000005.eml -verify -noverify ? ? ?--- content of message --- ? ? Verification failure ? ? 139737181419168:error:2107C080:PKCS7 routines:PKCS7_get0_signers:signer certificate not found:pk7_smime.c:472: ? ? $ ./external/bin/openssl smime -in ~/workspace/00000005.eml -verify -noverify -nosigs ? ? ?--- content of message --- ? ? Verification successful The result for arguments -verify -noverify corresponds with behaviour where there is certificate but the signature is not valid. The message write out, but openssl return error. ? --------------------------- Version: OpenSSL 1.0.1m 19 Mar 2015 OS: all affected Regards, Franti?ek Bo??nek developer - Kerio Connect ................................................................. Kerio Technologies s. r. o. Anglicke nabrezi 1, 301 49 Plzen Czech Republic tel. +420 378 225 158 http://www.kerio.com ................................................................. Connect. Communicate. Collaborate. Securely. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7m Type: application/pkcs7-mime Size: 1483 bytes Desc: not available URL: -------------- next part -------------- diff --git a/OpenSSL/crypto/pkcs7/pk7_smime.c b/OpenSSL/crypto/pkcs7/pk7_smime.c index dbd4100..60ce734 100644 --- a/OpenSSL/crypto/pkcs7/pk7_smime.c +++ b/OpenSSL/crypto/pkcs7/pk7_smime.c @@ -249,7 +249,7 @@ static int pkcs7_copy_existing_digest(PKCS7 *p7, PKCS7_SIGNER_INFO *si) int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, BIO *indata, BIO *out, int flags) { - STACK_OF(X509) *signers; + STACK_OF(X509) *signers = 0; X509 *signer; STACK_OF(PKCS7_SIGNER_INFO) *sinfos; PKCS7_SIGNER_INFO *si; @@ -294,14 +294,17 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, return 0; } - signers = PKCS7_get0_signers(p7, certs, flags); - - if (!signers) - return 0; + if(!(flags & PKCS7_NOSIGS) || !(flags & PKCS7_NOVERIFY)) { + /* allow to read encapsulated data even if there is no signer */ + signers = PKCS7_get0_signers(p7, certs, flags); + } /* Now verify the certificates */ - - if (!(flags & PKCS7_NOVERIFY)) + if (!(flags & PKCS7_NOVERIFY)) { + if (!signers) { + return 0; + } + for (k = 0; k < sk_X509_num(signers); k++) { signer = sk_X509_value(signers, k); if (!(flags & PKCS7_NOCHAIN)) { @@ -333,6 +336,7 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, } /* Check for revocation status here */ } + } /* * Performance optimization: if the content is a memory BIO then store @@ -384,7 +388,11 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, } /* Now Verify All Signatures */ - if (!(flags & PKCS7_NOSIGS)) + if (!(flags & PKCS7_NOSIGS)) { + if (!signers) { + return 0; + } + for (i = 0; i < sk_PKCS7_SIGNER_INFO_num(sinfos); i++) { si = sk_PKCS7_SIGNER_INFO_value(sinfos, i); signer = sk_X509_value(signers, i); @@ -394,6 +402,7 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, goto err; } } + } ret = 1; @@ -405,7 +414,8 @@ int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, } BIO_free_all(p7bio); - sk_X509_free(signers); + if (signers) + sk_X509_free(signers); return ret; } -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3295 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From matt at openssl.org Thu Oct 8 19:06:21 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 8 Oct 2015 20:06:21 +0100 Subject: [openssl-dev] Adding async support In-Reply-To: References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> <56158F50.1000100@openssl.org> <56164BEC.1070801@openssl.org> <56165ECC.9080107@openssl.org> Message-ID: <5616BEAD.1040700@openssl.org> On 08/10/15 18:56, Dmitry Belyavsky wrote: > The second problem is entirely engine dependant. It will be a different > solution for different hardware. These patches do not provide a solution > to that problem. > > > So I do not understand what you mean by "offload" :-( > > I understand that it's an engine-dependent, but I can't imagine a > corresponding pseudo code. Ok. So this is the pseudo code I posted before for how an engine might be implemented: static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx, unsigned char *out, const unsigned char *in, size_t inl) { int jobid; jobid = offload_cipher_to_hardware(ctx, out, in , inl); /* * jobid holds a reference in the engine back to the work we just * started */ while(work_not_finished_yet(jobid)) { /* Return control back to the calling application */ ASYNC_pause_job(); } return get_results_from_hardware(jobid); } So lets imagine an engine that works via threads and how those pseudo code function call might be implemented. It could be something like this: void initialise_engine(void) { start_thread(worker_main); } static int nextjobid = 0; struct work_st { int jobid; EVP_CIPHER_CTX *ctx; unsigned char *out; unsigned char *in; size_t inl; int ret; } int worker_main(void) { struct work_st *work; while(true) { work = get_work_off_in_queue(); /* This is a long running operation */ work->ret = do_aes128_cbc_cipher(work->ctx, work->out, work->in, work->inl); put_work_in_finished_set(work); } } int offload_cipher_to_hardware(EVP_CIPHER_CTX *ctx, unsigned char *out, unsigned char *in, size_t inl) { struct work_st *work; work = malloc(sizeof *work); work->ctx = ctx; work->out = out; work->in = in; work->inl = inl; work->jobid = nextjobid++; add_work_to_in_queue(work); return work->jobid; } int work_not_finished_yet(int jobid) { return !is_work_in_finished_set(jobid); } int get_results_from_hardware(int jobid) { struct work_st *work; work = get_work_out_of_finished_set(jobid); return work->ret; } In a hardware based engine everything in "worker_main" would be implemented in the hardware. So the hardware gets on with the long running crypto operation, whilst in the software control has returned back to the application. Does that make more sense? Matt From beldmit at gmail.com Thu Oct 8 19:11:29 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 8 Oct 2015 22:11:29 +0300 Subject: [openssl-dev] Adding async support In-Reply-To: <5616BEAD.1040700@openssl.org> References: <5614E9F2.4090303@openssl.org> <20151007132905.GD15070@mournblade.imrryr.org> <56152183.8030909@openssl.org> <56158F50.1000100@openssl.org> <56164BEC.1070801@openssl.org> <56165ECC.9080107@openssl.org> <5616BEAD.1040700@openssl.org> Message-ID: Dear Matt, On Thu, Oct 8, 2015 at 10:06 PM, Matt Caswell wrote: > > > On 08/10/15 18:56, Dmitry Belyavsky wrote: > > > The second problem is entirely engine dependant. It will be a > different > > solution for different hardware. These patches do not provide a > solution > > to that problem. > > > > > > So I do not understand what you mean by "offload" :-( > > > > I understand that it's an engine-dependent, but I can't imagine a > > corresponding pseudo code. > > Ok. So this is the pseudo code I posted before for how an engine might > be implemented: > > static int myengine_aes128_cbc_cipher(EVP_CIPHER_CTX *ctx, > unsigned char *out, const unsigned char *in, size_t inl) > { > int jobid; > > jobid = offload_cipher_to_hardware(ctx, out, in , inl); > > /* > * jobid holds a reference in the engine back to the work we just > * started > */ > > while(work_not_finished_yet(jobid)) { > /* Return control back to the calling application */ > ASYNC_pause_job(); > } > > return get_results_from_hardware(jobid); > } > > > So lets imagine an engine that works via threads and how those pseudo > code function call might be implemented. It could be something like this: > > void initialise_engine(void) > { > start_thread(worker_main); > } > > static int nextjobid = 0; > > struct work_st { > int jobid; > EVP_CIPHER_CTX *ctx; > unsigned char *out; > unsigned char *in; > size_t inl; > int ret; > } > > int worker_main(void) > { > struct work_st *work; > > while(true) { > work = get_work_off_in_queue(); > /* This is a long running operation */ > work->ret = do_aes128_cbc_cipher(work->ctx, work->out, work->in, > work->inl); > put_work_in_finished_set(work); > } > } > > int offload_cipher_to_hardware(EVP_CIPHER_CTX *ctx, unsigned char *out, > unsigned char *in, size_t inl) { > struct work_st *work; > > work = malloc(sizeof *work); > work->ctx = ctx; > work->out = out; > work->in = in; > work->inl = inl; > work->jobid = nextjobid++; > > add_work_to_in_queue(work); > > return work->jobid; > } > > int work_not_finished_yet(int jobid) > { > return !is_work_in_finished_set(jobid); > } > > int get_results_from_hardware(int jobid) > { > struct work_st *work; > > work = get_work_out_of_finished_set(jobid); > > return work->ret; > } > > In a hardware based engine everything in "worker_main" would be > implemented in the hardware. So the hardware gets on with the long > running crypto operation, whilst in the software control has returned > back to the application. > > Does that make more sense? > Thank you! I finally got it. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Thu Oct 8 19:37:28 2015 From: hkario at redhat.com (Hubert Kario) Date: Thu, 08 Oct 2015 21:37:28 +0200 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <20151008173712.GD15070@mournblade.imrryr.org> References: <20151008173712.GD15070@mournblade.imrryr.org> Message-ID: <3876137.2maAcyWPYs@pintsize.usersys.redhat.com> On Thursday 08 October 2015 17:37:12 Viktor Dukhovni wrote: > On Thu, Oct 08, 2015 at 04:12:50PM +0000, Hubert Kario via RT wrote: > > The server does not abort connection upon receiving a Client Hello > > message with malformed session_id field. > > > > Affects 1.0.1, 1.0.2 and master. > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > defined as > > > > opaque SessionID<0..32>; > > > > that means, that any SessionID longer than 32 bytes creates an > > incorrectly formatted Client Hello message, and as such, should be > > rejected. > > Can be rejected, and perhaps even should be rejected, but I don't > see a MUST here. It seems there's little harm in tolerating longer > session ids (which never match, so are effectively ignored). RFC 5246: decode_error A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal and should never be observed in communication between proper implementations (except when messages were corrupted in the network) (yes, it's not a MUST either, but I'm afraid that this was simply "too obvious" for designers of protocol) > So yes, I support adding a check for this (likely above the PACKET > layer), but I don't think this has much urgency and likely should > not be back-ported to stable releases. oh, sure, that particular problem isn't a serious issue, but I'm going through all fields and all messages so that we have full coverage (e.g. for valgrind) also, accepting bigger session id's means that the session cache code is exercised in ways that it usually isn't, that's not a good thing to happen (even if it handles them correctly, as it seems, defence in depth is a good idea anyway) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Thu Oct 8 19:57:21 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 08 Oct 2015 19:57:21 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <20151008195713.GA8667@kronk.local> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> <20151008171902.GA4825@kronk.local> <20151008181348.GA19043@kronk.local> <20151008182623.GA19262@kronk.local> <20151008195713.GA8667@kronk.local> Message-ID: On Thu, Oct 08, 2015 at 06:26:27pm +0000, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 06:14:00pm +0000, Alessandro Ghedini via RT wrote: > > On Thu, Oct 08, 2015 at 05:19:06pm +0000, Alessandro Ghedini via RT wrote: > > > On Thu, Oct 08, 2015 at 04:12:50pm +0000, Hubert Kario via RT wrote: > > > > The server does not abort connection upon receiving a Client Hello > > > > message with malformed session_id field. > > > > > > > > Affects 1.0.1, 1.0.2 and master. > > > > > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > > > defined as > > > > > > > > opaque SessionID<0..32>; > > > > > > > > that means, that any SessionID longer than 32 bytes creates an > > > > incorrectly formatted Client Hello message, and as such, should be > > > > rejected. > > > > > > Looking at the code in master, for non-v2 ClientHello messages the code uses > > > the PACKET_get_length_prefixed_1() function to extract the SessionID, however I > > > see no way to pass a maximum allowed length to it. I think a new function would > > > have to be added to the PACKET_* interface (I can look into this). Haven't > > > checked older branches yet. > > > > So, it turns out the check was already performed, but this failure didn't cause > > the session to be aborted (the original PACKET was advanced anyway though, even > > is the session_id isn't actually extracted), I don't know if this was on > > purpose though. > > Another thing to consider is that the client already aborts when an invalid > session_id is received in the ServerHello and sends the ILLEGAL_PARAMETER alert. > > My patch doesn't actually send any alert so the check should be moved earlier > to allow an alert to be sent, if that is desired. FYI, I just pushed another patch that does the above (moving the check and sending an alert) which I think is the best option (although, as Hubert pointed out, sending the decode_error alert is not a MUST). If that's ok with you, I can squash the two commits together and give them a better message, otherwise just ignore the second patch. Cheers From rt at openssl.org Thu Oct 8 20:03:17 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Thu, 08 Oct 2015 20:03:17 +0000 Subject: [openssl-dev] [openssl.org #4081] crypto/evp/e_dsa.c is orphaned In-Reply-To: <20151008200308.GA8746@kronk.local> References: <56169769.4010407@akamai.com> <20151008200308.GA8746@kronk.local> Message-ID: On Thu, Oct 08, 2015 at 04:18:53pm +0000, Kaduk, Ben via RT wrote: > crypto/evp/e_dsa.c contains only a single static struct variable, and > the file appears unreferenced from anywhere else in the tree. > > It should be safe to remove. This is now fixed in my "Remove useless code" patch at https://github.com/openssl/openssl/pull/436 Cheers From rt at openssl.org Thu Oct 8 23:11:50 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 08 Oct 2015 23:11:50 +0000 Subject: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests In-Reply-To: <20151008231141.GA13283@roeckx.be> References: <20151007200902.GA11112@roeckx.be> <423156DC-0112-4DD7-B690-3B0412C88181@trust-in-soft.com> <20151008231141.GA13283@roeckx.be> Message-ID: On Thu, Oct 08, 2015 at 01:36:07PM +0000, Pascal Cuoq via RT wrote: > > - ssl_locl.h.patch: I don't see a struct timeval > > crypto/x509v3/v3_scts.c. Does this comment still apply? Maybe > > we fixed the issue in some other way. > > Sorry, this comment was unnecessarily confusing. > > What we meant to say was that the OpenSSL header ssl/ssl_locl.h uses "struct timeval" (at line 1445: https://github.com/openssl/openssl/blob/b3e2272c59a5720467045e2ae62940fdb708ce76/ssl/ssl_locl.h#L1445 ) but the POSIX header that is guaranteed to provide this type, sys/time.h, is not included. This is just a portability matter. It works in practice of most platforms because that header is dragged in by other headers. I understand that it's a portability issue. But since it's not part of the C standard we can't unconditionally include it either because that would create other protability issues. d1_lib.c for instance has: #if defined(OPENSSL_SYS_VMS) # include #elif defined(OPENSSL_SYS_NETWARE) && !defined(_WINSOCK2API_) # include #elif defined(OPENSSL_SYS_VXWORKS) # include #elif !defined(OPENSSL_SYS_WIN32) # include #endif While bss_dgram.c just has: # if !(defined(_WIN32) || defined(OPENSSL_SYS_VMS)) # include # endif # if defined(OPENSSL_SYS_VMS) # include # endif > > - malloc.patch: I started looking at it, and I have some > > comments/questions: > > - I currently don't see a way that s->d1 can be NULL except > > after an dtls1_free() call. The same seem to go for > > DTLS_RECORD_LAYER_free(), ssl3_free(), pkey_hmac_cleanup(), > > aes_gcm_cleanup() and aes_ocb_cleanup(). > > Are you saying there are cases we could end up calling those > > twice? > > All the patches in the file malloc.patch are for problems, typically null pointer dereferences, that arise when the function malloc() is modeled as either returning a null pointer or a valid pointer to a fresh block. We know this because we also ran all the tests in a mode in which malloc was assumed to always succeed, and in that mode, none of the fixes recommended in malloc.patch were necessary. > > So for instance, in the development version of OpenSSL that was current at the time of the report, that "s->d1" could be NULL because a malloc call had returned NULL. I see a check for the malloc() return value there, and as far as I can see it's always been there. But you only mention the free calls while the variables are used at other places without checking that it's NULL or not. So I wonder if this is some false positive, which I understand you actually try to avoid. So I'm guessing we're missing something, like calling free after new failed or something. > - replay the same verification process on the most recent version of OpenSSL, and update this bug report with the issues that are still present only; > > - and then give you access to the analyzer results in a way that lets you observe the sequence of events leading to the null pointer dereferences, and choose for yourselves the best remedy. That would be great. Kurt From rt at openssl.org Fri Oct 9 03:11:53 2015 From: rt at openssl.org (christian fafard via RT) Date: Fri, 09 Oct 2015 03:11:53 +0000 Subject: [openssl-dev] [openssl.org #4084] correction to the message i sent earlier... In-Reply-To: References: Message-ID: In my previous message, i mixed "above" and "below" so it was maybe unreadable a bit. Sorry! Christian Fafard -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Oct 9 03:11:53 2015 From: rt at openssl.org (christian fafard via RT) Date: Fri, 09 Oct 2015 03:11:53 +0000 Subject: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW... In-Reply-To: References: Message-ID: With version 'openssl-1.0.2d',in file 'test/Makefile',at line 244 shown above, @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i tests passed\n"' Make test fail because you use this snippet of perl's code '(!/^0$$/)' to match any lines not containing only a single zero.It doesn't work as expected with the version 5.8.8 of perl distributed with mingw32, as you can see from the message above. verify BN_addFailed! bc: 0make[1]: *** [test_bn] Error 255 I use this equivalent line to avoid the problematic negation of regex match '!//', @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR "\n$$i tests passed\n"' I'm not expert enough to know if this code is more portable on every platforms and versions of perl, i'll leave it to you. ThanksChristian Fafard -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Oct 9 15:49:22 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Fri, 09 Oct 2015 15:49:22 +0000 Subject: [openssl-dev] [openssl.org #3987] Bug report about crash related to ASN1_primitive_free In-Reply-To: <007101d0cf3c$e9904d00$bcb0e700$@lge.com> References: <007101d0cf3c$e9904d00$bcb0e700$@lge.com> Message-ID: I'm afraid we can't tell from your report whether the bug is in OpenSSL or in your application code. We need a reproducible report - for example, a standalone code snippet, or a sample input to the openssl command-line tool. Cheers, Emilia From rt at openssl.org Fri Oct 9 16:53:03 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Fri, 09 Oct 2015 16:53:03 +0000 Subject: [openssl-dev] [openssl.org #4060] a crash happened inside SSL_Connect function In-Reply-To: References: Message-ID: Closing, because it's not an OpenSSL defect, but feel free to continue the discussion on openssl-users. Cheers, Emilia From rt at openssl.org Fri Oct 9 17:02:47 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 09 Oct 2015 17:02:47 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <20151009170235.GA32172@kronk.local> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> <20151008171902.GA4825@kronk.local> <20151008182623.GA19262@kronk.local> <20151008195713.GA8667@kronk.local> <20151009170235.GA32172@kronk.local> Message-ID: On Thu, Oct 08, 2015 at 07:57:21pm +0000, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 06:26:27pm +0000, Alessandro Ghedini via RT wrote: > > On Thu, Oct 08, 2015 at 06:14:00pm +0000, Alessandro Ghedini via RT wrote: > > > On Thu, Oct 08, 2015 at 05:19:06pm +0000, Alessandro Ghedini via RT wrote: > > > > On Thu, Oct 08, 2015 at 04:12:50pm +0000, Hubert Kario via RT wrote: > > > > > The server does not abort connection upon receiving a Client Hello > > > > > message with malformed session_id field. > > > > > > > > > > Affects 1.0.1, 1.0.2 and master. > > > > > > > > > > In SSLv3 and all versions of TLS (e.g. RFC 5246), the SessionID is > > > > > defined as > > > > > > > > > > opaque SessionID<0..32>; > > > > > > > > > > that means, that any SessionID longer than 32 bytes creates an > > > > > incorrectly formatted Client Hello message, and as such, should be > > > > > rejected. > > > > > > > > Looking at the code in master, for non-v2 ClientHello messages the code uses > > > > the PACKET_get_length_prefixed_1() function to extract the SessionID, however I > > > > see no way to pass a maximum allowed length to it. I think a new function would > > > > have to be added to the PACKET_* interface (I can look into this). Haven't > > > > checked older branches yet. > > > > > > So, it turns out the check was already performed, but this failure didn't cause > > > the session to be aborted (the original PACKET was advanced anyway though, even > > > is the session_id isn't actually extracted), I don't know if this was on > > > purpose though. > > > > Another thing to consider is that the client already aborts when an invalid > > session_id is received in the ServerHello and sends the ILLEGAL_PARAMETER alert. > > > > My patch doesn't actually send any alert so the check should be moved earlier > > to allow an alert to be sent, if that is desired. > > FYI, I just pushed another patch that does the above (moving the check and > sending an alert) which I think is the best option (although, as Hubert pointed > out, sending the decode_error alert is not a MUST). If that's ok with you, I > can squash the two commits together and give them a better message, otherwise > just ignore the second patch. So, I went ahead and squashed all the commits into one [0] and also added the SSLv2 check as well. Can someone please have a look? Anyway, I noticed that the client compares the session_id length against "sizeof s->session->session_id" (which is SSL_MAX_SSL_SESSION_ID_LENGTH, like I used in my patch), and also against SSL3_SESSION_ID_SIZE (which is equal to SSL_MAX_SSL_SESSION_ID_LENGTH). I think this second check is superfluous and the other one can just use SSL_MAX_SSL_SESSION_ID_LENGTH directly instead of sizeof (it'd be more obvious). Cheers [0] https://github.com/openssl/openssl/pull/437 From rt at openssl.org Fri Oct 9 17:06:04 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 09 Oct 2015 17:06:04 +0000 Subject: [openssl-dev] [openssl.org #4084] correction to the message i sent earlier... In-Reply-To: <20151009170556.GA32414@kronk.local> References: <20151009170556.GA32414@kronk.local> Message-ID: This was supposed to be a reply to another message (#4083), but a new report has been created instead. I think it can be closed. Cheers From peck at bay2sierra.com Fri Oct 9 17:08:25 2015 From: peck at bay2sierra.com (John Peck) Date: Fri, 9 Oct 2015 12:08:25 -0500 (CDT) Subject: [openssl-dev] Patch for openssl_1_0_2 link failure when OPENSSL_NO_SHA512 defined Message-ID: <1413788390.7650808.1444410505375.JavaMail.zimbra@bay2sierra.com> I discovered that when OPENSSL_NO_SHA512 is defined, the openssl_1_0_2 stable branch build fails during the link step with unresolved symbol EVP_sha384. The attached patch fixes this issue. peck at bay2sierra.com Mobile: +1-415-420-8449 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Fix_OPENSSL_NO_SHA512_link_error.patch Type: text/x-patch Size: 1316 bytes Desc: not available URL: From rt at openssl.org Fri Oct 9 17:36:11 2015 From: rt at openssl.org (christian fafard via RT) Date: Fri, 09 Oct 2015 17:36:11 +0000 Subject: [openssl-dev] [openssl.org #4084] correction to the message i sent earlier... In-Reply-To: References: <20151009170556.GA32414@kronk.local>, Message-ID: Thank you and sorry for that mess. I did a copy-paste from emacs and realize after, that there was no "cr-lf" so my email is unreadable.I'll get it right next time. What i've tried to say basically is that the "negate regex match" construct "!//" doesn't work with some versions of perl. I suggest inverting the if/else actions to get rid of the negation. I can send a patch if you have interests. Christian > Subject: Re: [openssl.org #4084] correction to the message i sent earlier... > From: rt at openssl.org > To: cfaf at hotmail.com > CC: openssl-dev at openssl.org > Date: Fri, 9 Oct 2015 17:06:04 +0000 > > This was supposed to be a reply to another message (#4083), but a new report > has been created instead. I think it can be closed. > > Cheers > > From rt at openssl.org Fri Oct 9 17:38:26 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 09 Oct 2015 17:38:26 +0000 Subject: [openssl-dev] [openssl.org #4084] correction to the message i sent earlier... In-Reply-To: References: Message-ID: Closing ticket. Matt From rt at openssl.org Fri Oct 9 18:02:41 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 09 Oct 2015 18:02:41 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <2792477.2WbUsZ0v2K@pintsize.usersys.redhat.com> References: <1931549.yl5LXHj3eD@pintsize.usersys.redhat.com> <2792477.2WbUsZ0v2K@pintsize.usersys.redhat.com> Message-ID: And for good measure, I also created a test script that combines fragmentation with interleaving. In other words, checks if writing first part of Handshake protocol message, Application Data and then rest of Handshake protocol message is handled correctly. The script is in the same repository, name: scripts/test-interleaved-application-data-and-fragmented-handshakes-in-renegotiation.py run in exact same way as previous ones -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Oct 9 18:05:19 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 09 Oct 2015 18:05:19 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <561801DC.9000200@openssl.org> References: <1931549.yl5LXHj3eD@pintsize.usersys.redhat.com> <2792477.2WbUsZ0v2K@pintsize.usersys.redhat.com> <561801DC.9000200@openssl.org> Message-ID: On 09/10/15 19:02, Hubert Kario via RT wrote: > And for good measure, I also created a test script that > combines fragmentation with interleaving. Did you try my patch with it? And if so what happened? Thanks Matt From rt at openssl.org Fri Oct 9 18:27:46 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 09 Oct 2015 18:27:46 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <2153461.k18k1FmMS7@pintsize.usersys.redhat.com> References: <561801DC.9000200@openssl.org> <2153461.k18k1FmMS7@pintsize.usersys.redhat.com> Message-ID: On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: > On 09/10/15 19:02, Hubert Kario via RT wrote: > > And for good measure, I also created a test script that > > combines fragmentation with interleaving. > > Did you try my patch with it? And if so what happened? no, I didn't (sorry, it's really late Friday for me :), ping me if you want me to do that) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Oct 9 19:03:45 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 09 Oct 2015 19:03:45 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <20151009190341.GA2465@kronk.local> References: <1931549.yl5LXHj3eD@pintsize.usersys.redhat.com> <2792477.2WbUsZ0v2K@pintsize.usersys.redhat.com> <561801DC.9000200@openssl.org> <20151009190341.GA2465@kronk.local> Message-ID: On Fri, Oct 09, 2015 at 06:05:19pm +0000, Matt Caswell via RT wrote: > > > On 09/10/15 19:02, Hubert Kario via RT wrote: > > And for good measure, I also created a test script that > > combines fragmentation with interleaving. > > Did you try my patch with it? And if so what happened? I just tried both the test-interleaved-application-data-in-renegotiation.py and test-interleaved-application-data-and-fragmented-handshakes-in-renegotiation.py scripts and they both fail with your patch applied. In fact, your patch made one more test from the first script to fail (3 failures with your patch, only 2 without the patch). On the other hand your patch makes the test in the test-openssl-3712.py script succeed (which was the original test for thus bug AFAIU). I haven't really followed this discussion though, so I'm not sure what the outcome should be (I'd imagine all tests should pass though). Cheers From liu.liuyongqiang at huawei.com Sat Oct 10 09:33:47 2015 From: liu.liuyongqiang at huawei.com (Liuyongqiang (A)) Date: Sat, 10 Oct 2015 09:33:47 +0000 Subject: [openssl-dev] ovsdb-client connected error when i update the ovsdb-server ca_cert.pem file Message-ID: <621FAA8B3DA4E14193D6933FB72489BA58265E4F@nkgeml511-mbx.china.huawei.com> Hi, all There is a probability error when I update the ovsdb-server ca_cert.pem file, the ovsdb-client was unable to connect to the ovsdb-server when it hanppened, the OVS version is 2.0.2. the update action steps on server: step1: rm ca_cert.pem step2: openssl x509 -inform PEM -in ca_cert.pem > /home/ca_cert.pem the server update script : #!/bin/bash SRC_CA_CRT_FILE=/home/pem/oam-network-agent_ca_crt.pem DST_CA_CRT_FILE=/home/oam-network-agent_ca_crt.pem for((i=0; i<50000; i++));do rm -f $DST_CA_CRT_FILE sleep 0.5 openssl x509 -inform PEM -in $SRC_CA_CRT_FILE > /home/ca_crt.pem.tmp mv /home/ca_crt.pem.tmp $DST_CA_CRT_FILE echo "update-----result $?-------------------------------------$i" done the client connect script: for((i=0; i<50000; i++));do ovsdb-client -v -p /home/oam-network-agent_private_key.pem -c oam-network-agent_crt.pem -C /home/oam-network-agent_ca_crt.pem get-schema ssl:9.42.3.9:6632 Open_vSwitch sleep 0.5 echo $i done running server update script and client connect script on the sametime, after a period of time, the ovsdb-client can not connect the server, the error like ERROR1 and ERROR2. I have found the direct cause is concurrency write-read file issues, the ovsdb-server probably read the wrong certificate from ca_cert.pem file, but this error is unrecoverable, it need to restart OVS to fix, did someone know about this problem? The ovsdb-client connected error like this: ERROR1: # ovsdb-client -v -p /home/oam-network-agent_private_key.pem -c oam-network-agent_crt.pem -C /home/oam-network-agent_ca_crt.pem get-schema ssl:9.42.3.9:6632 Open_vSwitch 2015-09-25T10:54:36Z|00001|stream_ssl|INFO|Trusting CA cert from /home/oam-network-agent_ca_crt.pem (/C=CN/ST=ZheJiang/O=Huawei/OU=Huawei/CN=*.*.*.domainname.com) (fingerprint 22:a3:49:97:e1:44:ab:fb:96:29:60:ab:b8:fc:69:8b:7d:af:6c:6e) 2015-09-25T10:54:36Z|00002|poll_loop|DBG|wakeup due to 0-ms timeout 2015-09-25T10:54:36Z|00003|poll_loop|DBG|wakeup due to [POLLOUT] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:716 2015-09-25T10:54:36Z|00004|stream_ssl|DBG|client0-->ssl:9.42.3.9:6632 handshake: client_hello (85 bytes) 2015-09-25T10:54:36Z|00005|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00006|stream_ssl|DBG|client0<--ssl:9.42.3.9:6632 handshake: server_hello (53 bytes) 2015-09-25T10:54:36Z|00007|stream_ssl|DBG|client0<--ssl:9.42.3.9:6632 handshake: certificate (1944 bytes) 2015-09-25T10:54:36Z|00008|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00009|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00010|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00011|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00012|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00013|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00014|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00015|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00016|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00017|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54185<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T10:54:36Z|00048|stream_ssl|DBG|client0<--ssl:9.42.3.9:6632 handshake: certificate_request (65559 bytes) 2015-09-25T10:54:36Z|00049|stream_ssl|DBG|client0-->ssl:9.42.3.9:6632 alert: fatal, decode_error (2 bytes) 2015-09-25T10:54:36Z|00050|stream_ssl|WARN|SSL_connect: error:1408709F:SSL routines:SSL3_GET_CERTIFICATE_REQUEST:length mismatch ovsdb-client: failed to connect to "ssl:9.42.3.9:6632" (Protocol error) ERROR2: # ovsdb-client -v -p /home/oam-network-agent_private_key.pem -c oam-network-agent_crt.pem -C /home/oam-network-agent_ca_crt.pem get-schema ssl:9.42.3.9:6632 Open_vSwitch 2015-09-25T11:01:06Z|00001|stream_ssl|INFO|Trusting CA cert from /home/oam-network-agent_ca_crt.pem (/C=CN/ST=ZheJiang/O=Huawei/OU=Huawei/CN=*.*.*.domainname.com) (fingerprint 22:a3:49:97:e1:44:ab:fb:96:29:60:ab:b8:fc:69:8b:7d:af:6c:6e) 2015-09-25T11:01:06Z|00002|poll_loop|DBG|wakeup due to 0-ms timeout 2015-09-25T11:01:06Z|00003|poll_loop|DBG|wakeup due to [POLLOUT] on fd 4 (9.62.243.149:54288<->9.42.3.9:6632) at lib/stream-ssl.c:716 2015-09-25T11:01:06Z|00004|stream_ssl|DBG|client0-->ssl:9.42.3.9:6632 handshake: client_hello (85 bytes) 2015-09-25T11:01:06Z|00005|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54288<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T11:01:06Z|00006|stream_ssl|DBG|client0<--ssl:9.42.3.9:6632 handshake: server_hello (53 bytes) 2015-09-25T11:01:06Z|00007|stream_ssl|DBG|client0<--ssl:9.42.3.9:6632 handshake: certificate (985 bytes) 2015-09-25T11:01:06Z|00008|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54288<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T11:01:06Z|00009|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54288<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T11:01:06Z|00010|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54288<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T11:01:06Z|00011|stream_ssl|DBG|client0<--ssl:9.42.3.9:6632 handshake: certificate_request (11019 bytes) 2015-09-25T11:01:06Z|00012|stream_ssl|DBG|client0<--ssl:9.42.3.9:6632 handshake: server_hello_done (4 bytes) 2015-09-25T11:01:06Z|00013|stream_ssl|DBG|client0-->ssl:9.42.3.9:6632 handshake: certificate (1944 bytes) 2015-09-25T11:01:06Z|00014|stream_ssl|DBG|client0-->ssl:9.42.3.9:6632 handshake: client_key_exchange (262 bytes) 2015-09-25T11:01:06Z|00015|stream_ssl|DBG|client0-->ssl:9.42.3.9:6632 handshake: certificate_verify (262 bytes) 2015-09-25T11:01:06Z|00016|stream_ssl|DBG|client0-->ssl:9.42.3.9:6632 change_cipher_spec (1 bytes) 2015-09-25T11:01:06Z|00017|stream_ssl|DBG|client0-->ssl:9.42.3.9:6632 handshake: finished (16 bytes) 2015-09-25T11:01:06Z|00018|poll_loop|DBG|wakeup due to [POLLIN] on fd 4 (9.62.243.149:54288<->9.42.3.9:6632) at lib/stream-ssl.c:723 2015-09-25T11:01:06Z|00019|stream_ssl|DBG|client0<--ssl:9.42.3.9:6632 alert: fatal, unknown_ca (2 bytes) 2015-09-25T11:01:06Z|00020|stream_ssl|WARN|SSL_connect: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca ovsdb-client: failed to connect to "ssl:9.42.3.9:6632" (Protocol error) the ovsdb-server log will print warning like this: ERROR1: 2015-09-25T11:05:15.633Z|02941|stream_ssl|WARN|SSL_accept: error:1409441A:SSL routines:SSL3_READ_BYTES:tlsv1 alert decode error 2015-09-25T11:05:15.633Z|02942|jsonrpc|WARN|ssl:9.62.243.149:54187: receive error: Protocol error 2015-09-25T11:05:15.634Z|02943|reconnect|WARN|ssl:9.62.243.149:54187: connection dropped (Protocol error) ERROR2: 2015-09-25T11:11:37.494Z|00449|stream_ssl|WARN|SSL_accept: error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:no certificate returned 2015-09-25T11:11:37.494Z|00450|jsonrpc|WARN|ssl:9.62.243.149:54289: receive error: Protocol error 2015-09-25T11:11:37.494Z|00451|reconnect|WARN|ssl:9.62.243.149:54289: connection dropped (Protocol error) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Oct 10 18:13:40 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sat, 10 Oct 2015 18:13:40 +0000 Subject: [openssl-dev] [openssl.org #4085] Bug in genpkey in master In-Reply-To: References: Message-ID: Hello, I've found a bug in the genpkey command in the master branch. If we use an algorithm provided by an engine and the engine is loaded via config, the algorithm can't be found during the command line options processing. The solution I suggest is moving the app_load_modules() call before the options loop. I think this can be used in all cmdline utilities accepting algorithm name from options. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Oct 10 18:49:49 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Sat, 10 Oct 2015 18:49:49 +0000 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: References: Message-ID: Closing, not an OpenSSL defect. From rt at openssl.org Sat Oct 10 21:44:04 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sat, 10 Oct 2015 21:44:04 +0000 Subject: [openssl-dev] [openssl.org #4086] s_server bug in master In-Reply-To: References: Message-ID: Hello, I've found a bug in s_server command line application in master branch. During apps_startup() the OpenSSL_add_ssl_algorithms() function is called before loading any engines. The OpenSSL_add_ssl_algorithms() is defined as SSL_library_init(). The SSL_library_init() builds a list of available ciphersuites. In case of engine-provided algorithms some ciphersuites will be disabled because the engine providing algorithms is not loaded yet. The list of ciphersuites is not rebuilded after loading engines. So the engine-dependent ciphersuites are not available. -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Oct 10 23:51:13 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 10 Oct 2015 23:51:13 +0000 Subject: [openssl-dev] [openssl.org #4079] syntax error with EVP_CHECK_DES_KEY In-Reply-To: <5616953A.9090206@akamai.com> References: <5616953A.9090206@akamai.com> Message-ID: Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sun Oct 11 00:52:40 2015 From: rt at openssl.org (John Peck via RT) Date: Sun, 11 Oct 2015 00:52:40 +0000 Subject: [openssl-dev] [openssl.org #4087] Patch for openssl_1_0_2 link failure when OPENSSL_NO_SHA512 defined In-Reply-To: <1159314437.8385055.1444501607462.JavaMail.zimbra@bay2sierra.com> References: <1413788390.7650808.1444410505375.JavaMail.zimbra@bay2sierra.com> <1159314437.8385055.1444501607462.JavaMail.zimbra@bay2sierra.com> Message-ID: I discovered that when OPENSSL_NO_SHA512 is defined, the openssl_1_0_2 stable branch build fails during the link step with unresolved symbol EVP_sha384. The attached patch fixes this issue. peck at bay2sierra.com -------------- next part -------------- A non-text attachment was scrubbed... Name: Fix_OPENSSL_NO_SHA512_link_error.patch Type: text/x-patch Size: 1317 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Oct 11 00:52:40 2015 From: rt at openssl.org (Zhang, Lily via RT) Date: Sun, 11 Oct 2015 00:52:40 +0000 Subject: [openssl-dev] [openssl.org #4088] RE: [Bug] Openssl caused CPU high to 100% In-Reply-To: References: Message-ID: Hi, I have found the API which caused high CPU. When calling API below, the CPU went to high in my host. FIPS_mode_set(1); Is it possible to reduce the CPU usage in this API? Thanks Lily From: Zhang, Lily (USD) Sent: Thursday, October 08, 2015 2:43 PM To: 'rt at openssl.org' Cc: Joshi, Samiksha Subject: [Bug] Openssl caused CPU high to 100% Hi Description: Client side uses openssl to communicate with https server, Openssl caused high CPU to 100% in client host. Detail: Our client uses openssl 0.9.8za-fips to communicate with a server. In our test, client is able to communicate with server without any issues, but we found our client caused CPU to 100% in client host, and it lasted about several seconds. When the CPU is high, some dumps were generated, it is in openssl area from the call stack, Dump 0's call stack: 0:000> .ttime Created: Thu Sep 10 03:28:11.968 2015 (GMT+8) 0:000> kb ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 0012fa34 0fb8ed9a 0fb96d8a 012e2998 2a7d0bb7 libeay32!bn_sub_words+0xf53 0012fa38 0fb96d8a 012e2998 2a7d0bb7 00000008 libeay32!bn_sub_words+0x92a 0012fa50 0fb96d4a 0fb96e2b 012e2998 012e2958 libeay32!BN_MONT_CTX_set_locked+0x1da 00000000 00000000 00000000 00000000 00000000 libeay32!BN_MONT_CTX_set_locked+0x19a Dump 1's call stack: 0:000> .ttime Created: Thu Sep 10 03:29:31.640 2015 (GMT+8) Kernel: 0 days 0:00:00.171 User: 0 days 0:00:01.546 0:000> kb ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 0012fb18 0fb8df9a 0fb96628 012e2868 012d32f8 libeay32!FINGERPRINT_premain+0x22c 0012fb1c 0fb96628 012e2868 012d32f8 00000020 libeay32!bn_mul_add_words+0xa 0012fb58 0fb8bac9 012d3d18 012e0bb0 0fb96b37 libeay32!BN_from_montgomery+0x108 0012fb64 0fb96b37 012d3d18 012e0b9c 012de8c0 libeay32!BN_CTX_get+0x49 0012fb84 0fb8de39 012d3d18 012d3d18 012d3d18 libeay32!BN_mod_mul_montgomery+0x57 0012fc48 0fb8fadf 012d3cf0 012d3cf0 012d3cdc libeay32!BN_mod_exp_mont+0x339 0012fc64 0fb90235 012d3cc8 00000002 012de8c0 libeay32!BN_GENCB_call+0x5f 0012fc9c 0fb95c86 012d3ca0 00000032 012d30b8 libeay32!BN_is_prime_fasttest_ex+0x345 00000000 00000000 00000000 00000000 00000000 libeay32!DSA_do_verify+0x5d6 Dump2's call stack: 0:000> .ttime Created: Thu Sep 10 03:29:36.687 2015 (GMT+8) Kernel: 0 days 0:00:00.125 User: 0 days 0:00:03.046 . 0 Id: d60.870 Suspend: 1 Teb: 7ffdd000 Unfrozen ChildEBP RetAddr Args to Child WARNING: Stack unwind information not available. Following frames may be wrong. 0012faf4 0fb8e041 04eb474c 00000000 8c3155d4 libeay32!FINGERPRINT_premain+0x276 0012fb1c 0fb96628 011aabf8 012d32f8 00000008 libeay32!bn_mul_add_words+0xb1 0012fb64 0fb96b37 012d3d58 012d3d6c 012de8c0 libeay32!BN_from_montgomery+0x108 0012fb84 0fb8dd27 012d3d58 012d3d44 012d3d1c libeay32!BN_mod_mul_montgomery+0x57 0012fbe8 78134c58 0fb82a9d 012d2e90 012d2e90 libeay32!BN_mod_exp_mont+0x227 0012fc2c 0fb8c85d 012d3d08 00000400 0fb8c840 msvcr80!free+0xec [f:\dd\vctools\crt_bld\self_x86\crt\src\free.c @ 115] 00000000 00000000 00000000 00000000 00000000 libeay32!BN_pseudo_rand+0x1d If I googled "openssl CPU high 100%", be able to list some links about this. Do you know if this is a known issue in openssl? Please let me know anything else needed to root cause this issue? Thanks Lily -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Oct 11 02:30:08 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 11 Oct 2015 02:30:08 +0000 Subject: [openssl-dev] [openssl.org #4088] RE: [Bug] Openssl caused CPU high to 100% In-Reply-To: References: Message-ID: More information is needed. But this is most likely not an OpenSSL bug, it's the FIPS setup-testing. From abhay.upadhyay at gmail.com Sun Oct 11 04:40:09 2015 From: abhay.upadhyay at gmail.com (abhay upadhyay) Date: Sun, 11 Oct 2015 10:10:09 +0530 Subject: [openssl-dev] Protecting SSL/TLS session keys into secure device/memory Message-ID: Hi, Is it possible to protect the SSL/TLS session keys generated during handshake into some secure device or memory? I have some basic information about OpenSSL Dynamic Engine, and have written a small proof of concept code to protect the RSA private key using dynamic engine. I do not understand how to use dynamic engine to protect the session keys. Please guide me in right direction. Any suggestion is highly appreciated. Thank you Abhay Upadhyay -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Oct 11 17:54:16 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sun, 11 Oct 2015 17:54:16 +0000 Subject: [openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master In-Reply-To: References: Message-ID: Hello! I use the command lines for s_client ans s_server (built from master): openssl s_server -www -cert cert.pem -key seckey.pem -cipher NULL-SHA256 -tls1 openssl s_client -connect localhost:4433 -CAfile sslCA/cacert.pem -verify_return_error -verify 1 -state -cipher NULL-SHA256 -ign_eof Client STDERR is verify depth is 1 SSL_connect:before/connect initialization SSL_connect:error in error 47960945916616:error:140830B5:SSL routines:ssl3_client_hello:no ciphers available:s3_clnt.c:865: SSL3 alert write:warning:close notify When I debug, I see that the cipher is forbidden by the ssl_security_default_callback function because of not enough security bits. Is it a bug or feature? -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Oct 11 18:13:11 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sun, 11 Oct 2015 18:13:11 +0000 Subject: [openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master In-Reply-To: <20151011181300.GA18548@roeckx.be> References: <20151011181300.GA18548@roeckx.be> Message-ID: On Sun, Oct 11, 2015 at 05:54:16PM +0000, Dmitry Belyavsky via RT wrote: > Hello! > > When I debug, I see that the cipher is forbidden by > the ssl_security_default_callback function because of not enough security > bits. You can change the security level by using: -cipher NULL-SHA256 at SECLEVEL=0 Kurt From beldmit at gmail.com Sun Oct 11 18:21:19 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Sun, 11 Oct 2015 21:21:19 +0300 Subject: [openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master In-Reply-To: References: <20151011181300.GA18548@roeckx.be> Message-ID: Dear Kurt, On Sun, Oct 11, 2015 at 9:13 PM, Kurt Roeckx via RT wrote: > On Sun, Oct 11, 2015 at 05:54:16PM +0000, Dmitry Belyavsky via RT wrote: > > Hello! > > > > When I debug, I see that the cipher is forbidden by > > the ssl_security_default_callback function because of not enough security > > bits. > > You can change the security level by using: > -cipher NULL-SHA256 at SECLEVEL=0 > Thank you! It works. Please close the ticket. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Oct 11 18:21:29 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sun, 11 Oct 2015 18:21:29 +0000 Subject: [openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master In-Reply-To: References: <20151011181300.GA18548@roeckx.be> Message-ID: Dear Kurt, On Sun, Oct 11, 2015 at 9:13 PM, Kurt Roeckx via RT wrote: > On Sun, Oct 11, 2015 at 05:54:16PM +0000, Dmitry Belyavsky via RT wrote: > > Hello! > > > > When I debug, I see that the cipher is forbidden by > > the ssl_security_default_callback function because of not enough security > > bits. > > You can change the security level by using: > -cipher NULL-SHA256 at SECLEVEL=0 > Thank you! It works. Please close the ticket. -- SY, Dmitry Belyavsky From rt at openssl.org Mon Oct 12 01:33:18 2015 From: rt at openssl.org (Zhang, Lily via RT) Date: Mon, 12 Oct 2015 01:33:18 +0000 Subject: [openssl-dev] [openssl.org #4088] RE: [Bug] Openssl caused CPU high to 100% In-Reply-To: References: Message-ID: Hi I debugged our client, when calling API below, I saw the client prococess's CPU went to 25% in my host(my host has 8 GB RAM which is more powerful). We reproduce this issue in different host, CPU can rise to 25%, 66%, 100% (different hosts have different RAMs, processors). FIPS_mode_set(1); Please let me know what info are needed for this issue. Thanks Lily -----Original Message----- From: Salz, Rich via RT [mailto:rt at openssl.org] Sent: Sunday, October 11, 2015 10:30 AM To: Zhang, Lily (USD) Cc: openssl-dev at openssl.org Subject: RE: [openssl-dev] [openssl.org #4088] RE: [Bug] Openssl caused CPU high to 100% More information is needed. But this is most likely not an OpenSSL bug, it's the FIPS setup-testing. From rt at openssl.org Mon Oct 12 02:03:00 2015 From: rt at openssl.org (christian fafard via RT) Date: Mon, 12 Oct 2015 02:03:00 +0000 Subject: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW... In-Reply-To: References: , , Message-ID: I'm sorry for that mess with the previous message.There was no CRLF because it was copy-pasted from emacs. What i tried to say basically is that the "negate regex match" (!/^0$$/) constructused in the line 244 of 'test/Makefile' does not work with some versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution. That's the reason why 'make test' fail on that platform. My proposal is to invert the if/else actions to get rid of the negation in the expression (/^0$$/). So the line: @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i tests passed\n"' would became: @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR "\n$$i tests passed\n"' I attached a patch. ThanksChristian -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-1.0.2d-MINGW32.patch Type: application/octet-stream Size: 876 bytes Desc: not available URL: From support at go-forward.net Mon Oct 12 06:04:09 2015 From: support at go-forward.net (Support) Date: Mon, 12 Oct 2015 16:04:09 +1000 Subject: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW... In-Reply-To: References: Message-ID: <561B4D59.4060409@go-forward.net> Hi Christian, A similar patch was already applied to the master branch - see https://rt.openssl.org/Ticket/Display.html?id=3346 and commit 028bac0670c167f154438742eb4d0fbed73df209 You could cherry-pick the commit and apply it to the 1.0.2 branch. Cheers, Peter Mosmans On 12-10-2015 12:03, christian fafard via RT wrote: > I'm sorry for that mess with the previous message.There was no CRLF because it was copy-pasted from emacs. > What i tried to say basically is that the "negate regex match" (!/^0$$/) constructused in the line 244 of 'test/Makefile' does not work with some versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution. > That's the reason why 'make test' fail on that platform. > My proposal is to invert the if/else actions to get rid of the negation in the expression (/^0$$/). > So the line: > @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i tests passed\n"' > would became: > @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR "\n$$i tests passed\n"' > I attached a patch. > ThanksChristian > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Oct 12 06:03:23 2015 From: rt at openssl.org (Support via RT) Date: Mon, 12 Oct 2015 06:03:23 +0000 Subject: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW... In-Reply-To: <561B4D59.4060409@go-forward.net> References: <561B4D59.4060409@go-forward.net> Message-ID: Hi Christian, A similar patch was already applied to the master branch - see https://rt.openssl.org/Ticket/Display.html?id=3346 and commit 028bac0670c167f154438742eb4d0fbed73df209 You could cherry-pick the commit and apply it to the 1.0.2 branch. Cheers, Peter Mosmans On 12-10-2015 12:03, christian fafard via RT wrote: > I'm sorry for that mess with the previous message.There was no CRLF because it was copy-pasted from emacs. > What i tried to say basically is that the "negate regex match" (!/^0$$/) constructused in the line 244 of 'test/Makefile' does not work with some versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution. > That's the reason why 'make test' fail on that platform. > My proposal is to invert the if/else actions to get rid of the negation in the expression (/^0$$/). > So the line: > @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i tests passed\n"' > would became: > @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR "\n$$i tests passed\n"' > I attached a patch. > ThanksChristian > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Mon Oct 12 09:08:06 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 09:08:06 +0000 Subject: [openssl-dev] [openssl.org #4073] Segfault in engine processing In-Reply-To: References: Message-ID: On Tue Oct 06 20:08:12 2015, beldmit at gmail.com wrote: > Hello! > > I get a segfault when executing the command > > openssl dgst -engine gost -md_gost94 -mac hmac -macop > key:123456901234567890123456789012 > I assume this is on master? I can't reproduce this. Are you using your new GOST engine or the one currently in master? Matt From beldmit at gmail.com Mon Oct 12 09:39:01 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 12 Oct 2015 12:39:01 +0300 Subject: [openssl-dev] [openssl.org #4073] Segfault in engine processing In-Reply-To: References: Message-ID: Hello Matt, On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT wrote: > On Tue Oct 06 20:08:12 2015, beldmit at gmail.com wrote: > > Hello! > > > > I get a segfault when executing the command > > > > openssl dgst -engine gost -md_gost94 -mac hmac -macop > > key:123456901234567890123456789012 > > > > I assume this is on master? I can't reproduce this. Are you using your new > GOST > engine or the one currently in master? > Yes, it's on master. I think that I use the engine currently in master. I'll try to reproduce it again. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Oct 12 09:39:08 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 12 Oct 2015 09:39:08 +0000 Subject: [openssl-dev] [openssl.org #4073] Segfault in engine processing In-Reply-To: References: Message-ID: Hello Matt, On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT wrote: > On Tue Oct 06 20:08:12 2015, beldmit at gmail.com wrote: > > Hello! > > > > I get a segfault when executing the command > > > > openssl dgst -engine gost -md_gost94 -mac hmac -macop > > key:123456901234567890123456789012 > > > > I assume this is on master? I can't reproduce this. Are you using your new > GOST > engine or the one currently in master? > Yes, it's on master. I think that I use the engine currently in master. I'll try to reproduce it again. -- SY, Dmitry Belyavsky From liu.liuyongqiang at huawei.com Mon Oct 12 10:59:51 2015 From: liu.liuyongqiang at huawei.com (Liuyongqiang (A)) Date: Mon, 12 Oct 2015 10:59:51 +0000 Subject: [openssl-dev] ovsdb-client connected error when i update the ovsdb-server ca_cert.pem file Message-ID: <621FAA8B3DA4E14193D6933FB72489BA58266011@nkgeml511-mbx.china.huawei.com> Does anybody know why ovsdb-server only use the openssl api SSL_CTX_add_client_CA to add certificate, but have no delete api to delete certificate. I found that if I update ca_crt.pem many times(SSL_CTX_add_client_CA add 649 certificates), the error of ovsdb-client connecting ovsdb-server will occur, I found that there are 649 certificates in stack list ctx->client_CA when the error occurred. Are there any limits on stack list ctx->client_CA? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Oct 12 11:11:58 2015 From: rt at openssl.org (christian fafard via RT) Date: Mon, 12 Oct 2015 11:11:58 +0000 Subject: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW... In-Reply-To: References: , , , , , <561B4D59.4060409@go-forward.net>, Message-ID: Hi Peter, You are completely right! Windows carriage return is the real problem. I should have done better testing before posting a ticket. I'll use your patch until it get commited to the 1.0.2 branch. Thank you Christian > Subject: Re: [openssl-dev] [openssl.org #4083] possible fix to make test failure with openssl-1.0.2d on MinGW... > From: rt at openssl.org > To: cfaf at hotmail.com > CC: openssl-dev at openssl.org > Date: Mon, 12 Oct 2015 06:03:23 +0000 > > > Hi Christian, > > A similar patch was already applied to the master branch - see > https://rt.openssl.org/Ticket/Display.html?id=3346 and commit > 028bac0670c167f154438742eb4d0fbed73df209 > > You could cherry-pick the commit and apply it to the 1.0.2 branch. > > > Cheers, > > > Peter Mosmans > > On 12-10-2015 12:03, christian fafard via RT wrote: > > I'm sorry for that mess with the previous message.There was no CRLF because it was copy-pasted from emacs. > > What i tried to say basically is that the "negate regex match" (!/^0$$/) constructused in the line 244 of 'test/Makefile' does not work with some versions of perl.Like for exemple, perl v5.8.8 in the MinGW/msys distibution. > > That's the reason why 'make test' fail on that platform. > > My proposal is to invert the if/else actions to get rid of the negation in the expression (/^0$$/). > > So the line: > > @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (!/^0$$/) {die "\nFailed! bc: $$_";} else {print STDERR "."; $$i++;}} print STDERR "\n$$i tests passed\n"' > > would became: > > @) {if (/^test (.*)/) {print STDERR "\nverify $$1";} elsif (/^0$$/) {print STDERR "."; $$i++;} else {die "\nFailed! bc: $$_";}} print STDERR "\n$$i tests passed\n"' > > I attached a patch. > > ThanksChristian > > > > > > _______________________________________________ > > openssl-dev mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > From rt at openssl.org Mon Oct 12 11:48:25 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 11:48:25 +0000 Subject: [openssl-dev] [openssl.org #4072] dgst command incompatibility between 1.0.2 and 1.1.0 In-Reply-To: References: Message-ID: On Tue Oct 06 19:53:30 2015, beldmit at gmail.com wrote: > Hello! > > I've found a difference in behaviour between openssl cmdline 1.0.2 and > 1.1.0 versions. > The -macopt cmdline option is not recognized, openssl dgst expects -macop > instead. > Fixed. Thanks. Matt From rt at openssl.org Mon Oct 12 11:49:24 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 11:49:24 +0000 Subject: [openssl-dev] [openssl.org #4089] NULL ciphersuites do not work in master In-Reply-To: References: Message-ID: Closing ticket. Matt From rt at openssl.org Mon Oct 12 13:10:26 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Mon, 12 Oct 2015 13:10:26 +0000 Subject: [openssl-dev] [openssl.org #4090] [PATCH] Assorted fixes In-Reply-To: <20151012131013.GA2747@kronk.local> References: <20151012131013.GA2747@kronk.local> Message-ID: Hello, I've prepared a few patches to fix several minor-ish issues (I though it didn't make much sense to submit them one by one). See GitHub pull request at: https://github.com/openssl/openssl/pull/436 The patches are: - Do not treat 0 return value from BIO_get_fd() as error (fixes RT#4068) - Replace malloc+strlcpy with strdup - Fix memory leaks and other mistakes on errors - Set salt length after the malloc has succeeded - Fix typos - Fix references to various RFCs - Check memory allocation - Remove useless code (fixes RT#4081) (some of the issues were found using Clang's static analyzer). They should be all pretty self-explanatory. Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Oct 12 13:45:20 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 12 Oct 2015 13:45:20 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> Message-ID: On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: > On 09/10/15 19:02, Hubert Kario via RT wrote: > > And for good measure, I also created a test script that > > combines fragmentation with interleaving. > > Did you try my patch with it? And if so what happened? I'm using interleave-data-102.patch attached to this ticket. So, for state-machine-rewrite branch it doesn't apply, there's no ssl/s3_pkt.c file. For current 1.0.1 branch, the patch applies, test case results are as follows: * test-openssl-3712.py - pass * test-interleaved-application-data-in-renegotiation.py - pass * test-interleaved-application-data-and-fragmented-handshakes-in- renegotiation.py - pass For current 1.0.2 branch, the patch applies, tests case results are as follows: * test-openssl-3712.py - pass * test-interleaved-application-data-in-renegotiation.py - pass * test-interleaved-application-data-and-fragmented-handshakes-in- renegotiation.py - pass for current master the patch doesn't apply, just like with state- machine-rewrite there's no ssl/s3_pkt.c file Note: the two latter test cases need the s_server run in -www mode, the first test case ignores server response so will work regardless, that may be why Alessandro testing doesn't show the issue as fixed -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Oct 12 15:03:22 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Mon, 12 Oct 2015 15:03:22 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <20151012150307.GA6068@kronk.local> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <20151012150307.GA6068@kronk.local> Message-ID: On Mon, Oct 12, 2015 at 01:45:20PM +0000, Hubert Kario via RT wrote: > On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: > > On 09/10/15 19:02, Hubert Kario via RT wrote: > > > And for good measure, I also created a test script that > > > combines fragmentation with interleaving. > > > > Did you try my patch with it? And if so what happened? > > I'm using interleave-data-102.patch attached to this ticket. > > So, for state-machine-rewrite branch it doesn't apply, there's no > ssl/s3_pkt.c file. > > For current 1.0.1 branch, the patch applies, test case results are as > follows: > * test-openssl-3712.py - pass > * test-interleaved-application-data-in-renegotiation.py - pass > * test-interleaved-application-data-and-fragmented-handshakes-in- > renegotiation.py - pass > > For current 1.0.2 branch, the patch applies, tests case results are as > follows: > * test-openssl-3712.py - pass > * test-interleaved-application-data-in-renegotiation.py - pass > * test-interleaved-application-data-and-fragmented-handshakes-in- > renegotiation.py - pass > > for current master the patch doesn't apply, just like with state- > machine-rewrite there's no ssl/s3_pkt.c file > > Note: the two latter test cases need the s_server run in -www mode, the > first test case ignores server response so will work regardless, that > may be why Alessandro testing doesn't show the issue as fixed Ah, yep, with -www it works for me too. Note that on master the file to change should be ssl/record/ssl3_record.c. However, while the patch applies cleanly to this file, all the tests fail (even with -www). It seems that the field in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent. Cheers From nmav at redhat.com Mon Oct 12 15:17:40 2015 From: nmav at redhat.com (Nikos Mavrogiannopoulos) Date: Mon, 12 Oct 2015 17:17:40 +0200 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> <5605183E.8070501@openssl.org> Message-ID: <1444663060.7189.7.camel@redhat.com> On Mon, 2015-09-28 at 11:35 +0000, Albe Laurenz via RT wrote: > The RFC writes: > > Note: If a rehandshake occurs while data is flowing on a > connection, > the communicating parties may continue to send data using the old > CipherSpec. However, once the ChangeCipherSpec has been sent, the > new CipherSpec MUST be used. The first side to send the > ChangeCipherSpec does not know that the other side has finished > computing the new keying material (e.g., if it has to perform a > time-consuming public key operation). Thus, a small window of > time, > during which the recipient must buffer the data, MAY exist. In > practice, with modern machines this interval is likely to be > fairly > short. > > Could that be interpreted to mean that the recepient should buffer > all incoming Application Data messages that are sent between > ChangeCipherSpec and Finished? That doesn't sound safe. Consider the case where re-authentication occurs and a different identity is presented while the previous commands are being cached. The server will see the commands of the initial session as commands coming from the new session which is under a new user. I think that unless you can separate re-authentication from rehandshake to refresh the keys, the current behavior of openssl which drops the session is quite safe. regards, Nikos From rt at openssl.org Mon Oct 12 15:17:46 2015 From: rt at openssl.org (Nikos Mavrogiannopoulos via RT) Date: Mon, 12 Oct 2015 15:17:46 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <1444663060.7189.7.camel@redhat.com> References: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com> <1818018.EjxOmpUFLh@pintsize.usersys.redhat.com> <5605183E.8070501@openssl.org> <1444663060.7189.7.camel@redhat.com> Message-ID: On Mon, 2015-09-28 at 11:35 +0000, Albe Laurenz via RT wrote: > The RFC writes: > > Note: If a rehandshake occurs while data is flowing on a > connection, > the communicating parties may continue to send data using the old > CipherSpec. However, once the ChangeCipherSpec has been sent, the > new CipherSpec MUST be used. The first side to send the > ChangeCipherSpec does not know that the other side has finished > computing the new keying material (e.g., if it has to perform a > time-consuming public key operation). Thus, a small window of > time, > during which the recipient must buffer the data, MAY exist. In > practice, with modern machines this interval is likely to be > fairly > short. > > Could that be interpreted to mean that the recepient should buffer > all incoming Application Data messages that are sent between > ChangeCipherSpec and Finished? That doesn't sound safe. Consider the case where re-authentication occurs and a different identity is presented while the previous commands are being cached. The server will see the commands of the initial session as commands coming from the new session which is under a new user. I think that unless you can separate re-authentication from rehandshake to refresh the keys, the current behavior of openssl which drops the session is quite safe. regards, Nikos From rt at openssl.org Mon Oct 12 15:39:45 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 15:39:45 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <561BD440.6030703@openssl.org> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <20151012150307.GA6068@kronk.local> <561BD440.6030703@openssl.org> Message-ID: On 12/10/15 16:03, Alessandro Ghedini via RT wrote: > On Mon, Oct 12, 2015 at 01:45:20PM +0000, Hubert Kario via RT wrote: >> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: >>> On 09/10/15 19:02, Hubert Kario via RT wrote: >>>> And for good measure, I also created a test script that >>>> combines fragmentation with interleaving. >>> >>> Did you try my patch with it? And if so what happened? >> >> I'm using interleave-data-102.patch attached to this ticket. >> >> So, for state-machine-rewrite branch it doesn't apply, there's no >> ssl/s3_pkt.c file. >> >> For current 1.0.1 branch, the patch applies, test case results are as >> follows: >> * test-openssl-3712.py - pass >> * test-interleaved-application-data-in-renegotiation.py - pass >> * test-interleaved-application-data-and-fragmented-handshakes-in- >> renegotiation.py - pass >> >> For current 1.0.2 branch, the patch applies, tests case results are as >> follows: >> * test-openssl-3712.py - pass >> * test-interleaved-application-data-in-renegotiation.py - pass >> * test-interleaved-application-data-and-fragmented-handshakes-in- >> renegotiation.py - pass >> >> for current master the patch doesn't apply, just like with state- >> machine-rewrite there's no ssl/s3_pkt.c file >> >> Note: the two latter test cases need the s_server run in -www mode, the >> first test case ignores server response so will work regardless, that >> may be why Alessandro testing doesn't show the issue as fixed > > Ah, yep, with -www it works for me too. Note that on master the file to change > should be ssl/record/ssl3_record.c. However, while the patch applies cleanly to > this file, all the tests fail (even with -www). It seems that the field > in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent. The value of "in_read_app_data" not being true when it is supposed to appears to be running into a slightly different bug. It's also present in 1.0.2 but you have to switch off version negotiation. So running s_server like this in 1.0.2 and rerunning Hubert's test will hit it: openssl s_server -www -tls1_2 The 1.0.2 version negotiation is hiding the issue. In master version neg has been completely rewritten and simplified - but in doing so no longer hides the problem. :-( Matt From rt at openssl.org Mon Oct 12 16:19:43 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 16:19:43 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <561BDD9B.3080108@openssl.org> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <20151012150307.GA6068@kronk.local> <561BD440.6030703@openssl.org> <561BDD9B.3080108@openssl.org> Message-ID: On 12/10/15 16:39, Matt Caswell via RT wrote: > > > On 12/10/15 16:03, Alessandro Ghedini via RT wrote: >> On Mon, Oct 12, 2015 at 01:45:20PM +0000, Hubert Kario via RT wrote: >>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: >>>> On 09/10/15 19:02, Hubert Kario via RT wrote: >>>>> And for good measure, I also created a test script that >>>>> combines fragmentation with interleaving. >>>> >>>> Did you try my patch with it? And if so what happened? >>> >>> I'm using interleave-data-102.patch attached to this ticket. >>> >>> So, for state-machine-rewrite branch it doesn't apply, there's no >>> ssl/s3_pkt.c file. >>> >>> For current 1.0.1 branch, the patch applies, test case results are as >>> follows: >>> * test-openssl-3712.py - pass >>> * test-interleaved-application-data-in-renegotiation.py - pass >>> * test-interleaved-application-data-and-fragmented-handshakes-in- >>> renegotiation.py - pass >>> >>> For current 1.0.2 branch, the patch applies, tests case results are as >>> follows: >>> * test-openssl-3712.py - pass >>> * test-interleaved-application-data-in-renegotiation.py - pass >>> * test-interleaved-application-data-and-fragmented-handshakes-in- >>> renegotiation.py - pass >>> >>> for current master the patch doesn't apply, just like with state- >>> machine-rewrite there's no ssl/s3_pkt.c file >>> >>> Note: the two latter test cases need the s_server run in -www mode, the >>> first test case ignores server response so will work regardless, that >>> may be why Alessandro testing doesn't show the issue as fixed >> >> Ah, yep, with -www it works for me too. Note that on master the file to change >> should be ssl/record/ssl3_record.c. However, while the patch applies cleanly to >> this file, all the tests fail (even with -www). It seems that the field >> in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent. > > The value of "in_read_app_data" not being true when it is supposed to > appears to be running into a slightly different bug. It's also present > in 1.0.2 but you have to switch off version negotiation. So running > s_server like this in 1.0.2 and rerunning Hubert's test will hit it: > > openssl s_server -www -tls1_2 > > The 1.0.2 version negotiation is hiding the issue. In master version neg > has been completely rewritten and simplified - but in doing so no longer > hides the problem. :-( Having done some more digging it seems the problem only occurs if you get the initial handshake, following by a second reneg handshake *and* interleaved app data all within the scope of a *single* SSL_read call. AFAICT if SSL_read returns between the first handshake and the second, you don't get the problem. That's starting to sound like quite an unlikely scenario and we're only hitting it now because of the slightly artificial nature of Hubert's test. I'm wondering whether "will not fix" is the right response to this second bug? Thoughts? Having said that it would be nice to have a reliable test for the interleaved-app data issue. Matt From rsalz at akamai.com Mon Oct 12 16:22:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 12 Oct 2015 16:22:30 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <20151012150307.GA6068@kronk.local> <561BD440.6030703@openssl.org> <561BDD9B.3080108@openssl.org> Message-ID: <71505bbd2a84430481bd48c0e2b02fef@ustx2ex-dag1mb1.msg.corp.akamai.com> > AFAICT if SSL_read returns between the first handshake and the second, you > don't get the problem. I think it should not matter when or what SSL_read returns. That should only be returning application-level data to the caller. All state manipulations, etc., should be done underneath and completely hidden. So yes, I vote for fixing. From rt at openssl.org Mon Oct 12 16:22:35 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 12 Oct 2015 16:22:35 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <71505bbd2a84430481bd48c0e2b02fef@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <561BD440.6030703@openssl.org> <561BDD9B.3080108@openssl.org> <71505bbd2a84430481bd48c0e2b02fef@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: > AFAICT if SSL_read returns between the first handshake and the second, you > don't get the problem. I think it should not matter when or what SSL_read returns. That should only be returning application-level data to the caller. All state manipulations, etc., should be done underneath and completely hidden. So yes, I vote for fixing. From alessandro at ghedini.me Mon Oct 12 17:22:05 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Mon, 12 Oct 2015 19:22:05 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: References: <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> <20151006193753.GA14151@kronk.local> Message-ID: <20151012172205.GA28726@kronk.local> On Tue, Oct 06, 2015 at 07:41:13pm +0000, Salz, Rich wrote: > > I've opened the following PR to add support for GCC v5 and address sanitizer > > (not sure if we want valgrind as well...): > > https://github.com/openssl/openssl/pull/429 > > I've started the internal review. Asan is awesome. Ping? Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From beldmit at gmail.com Mon Oct 12 17:33:27 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 12 Oct 2015 20:33:27 +0300 Subject: [openssl-dev] [openssl.org #4073] Segfault in engine processing In-Reply-To: References: Message-ID: Hello! Thank you, I can't reproduce it either. Please close the ticket. Sorry for disturbing. On Mon, Oct 12, 2015 at 12:39 PM, Dmitry Belyavsky via RT wrote: > Hello Matt, > > On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT > wrote: > > > On Tue Oct 06 20:08:12 2015, beldmit at gmail.com wrote: > > > Hello! > > > > > > I get a segfault when executing the command > > > > > > openssl dgst -engine gost -md_gost94 -mac hmac -macop > > > key:123456901234567890123456789012 > > > > > > > I assume this is on master? I can't reproduce this. Are you using your > new > > GOST > > engine or the one currently in master? > > > > Yes, it's on master. I think that I use the engine currently in master. > I'll try to reproduce it again. > > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Oct 12 17:33:36 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 12 Oct 2015 17:33:36 +0000 Subject: [openssl-dev] [openssl.org #4073] Segfault in engine processing In-Reply-To: References: Message-ID: Hello! Thank you, I can't reproduce it either. Please close the ticket. Sorry for disturbing. On Mon, Oct 12, 2015 at 12:39 PM, Dmitry Belyavsky via RT wrote: > Hello Matt, > > On Mon, Oct 12, 2015 at 12:08 PM, Matt Caswell via RT > wrote: > > > On Tue Oct 06 20:08:12 2015, beldmit at gmail.com wrote: > > > Hello! > > > > > > I get a segfault when executing the command > > > > > > openssl dgst -engine gost -md_gost94 -mac hmac -macop > > > key:123456901234567890123456789012 > > > > > > > I assume this is on master? I can't reproduce this. Are you using your > new > > GOST > > engine or the one currently in master? > > > > Yes, it's on master. I think that I use the engine currently in master. > I'll try to reproduce it again. > > > -- > SY, Dmitry Belyavsky > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- SY, Dmitry Belyavsky From amdeich at gmail.com Mon Oct 12 17:56:47 2015 From: amdeich at gmail.com (Andrey Kulikov) Date: Mon, 12 Oct 2015 20:56:47 +0300 Subject: [openssl-dev] [openssl.org #4073] Segfault in engine processing In-Reply-To: References: Message-ID: On 12 October 2015 at 12:08, Matt Caswell via RT wrote: > Are you using your new GOST > engine or the one currently in master? > Sorry to come in in the middle, but where to get that new GOST engine, that is not on master now? Is it on some other branch? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Oct 12 17:56:56 2015 From: rt at openssl.org (Andrey Kulikov via RT) Date: Mon, 12 Oct 2015 17:56:56 +0000 Subject: [openssl-dev] [openssl.org #4073] Segfault in engine processing In-Reply-To: References: Message-ID: On 12 October 2015 at 12:08, Matt Caswell via RT wrote: > Are you using your new GOST > engine or the one currently in master? > Sorry to come in in the middle, but where to get that new GOST engine, that is not on master now? Is it on some other branch? From rt at openssl.org Mon Oct 12 18:11:01 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 12 Oct 2015 18:11:01 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <20151012181103.GA3082@roeckx.be> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <561BD440.6030703@openssl.org> <561BDD9B.3080108@openssl.org> <20151012181103.GA3082@roeckx.be> Message-ID: On Mon, Oct 12, 2015 at 04:19:43PM +0000, Matt Caswell via RT wrote: > > Having done some more digging it seems the problem only occurs if you > get the initial handshake, following by a second reneg handshake *and* > interleaved app data all within the scope of a *single* SSL_read call. > AFAICT if SSL_read returns between the first handshake and the second, > you don't get the problem. > > That's starting to sound like quite an unlikely scenario and we're only > hitting it now because of the slightly artificial nature of Hubert's > test. I'm wondering whether "will not fix" is the right response to this > second bug? Thoughts? Having said that it would be nice to have a > reliable test for the interleaved-app data issue. Are you saying this is 1 TLS record with 2 handshakes in it? >From what I understand, the authentication could change. Doesn't that mean we should make sure the client reads all data with SSL_read() before we tell it authentication changes and that we might have to delay processing some messages until that is done? Kurt From rt at openssl.org Mon Oct 12 18:43:02 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Mon, 12 Oct 2015 18:43:02 +0000 Subject: [openssl-dev] [openssl.org #2923] X509_cmp() introduces unnecessary dependency on SHA1 In-Reply-To: <3ad3e323f53cc208961c50eaa3e2bc29.squirrel@mailhost.ut.ee> References: <3ad3e323f53cc208961c50eaa3e2bc29.squirrel@mailhost.ut.ee> Message-ID: Thanks for the report. This has now been addressed in 1.0.1+, see commit bfc19297cddd5bc2192c02c7f8896d804b0456cb. Cheers, Emilia From rt at openssl.org Mon Oct 12 18:54:46 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 18:54:46 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <561C01EB.5090302@openssl.org> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <561BDD9B.3080108@openssl.org> <20151012181103.GA3082@roeckx.be> <561C01EB.5090302@openssl.org> Message-ID: On 12/10/15 19:11, Kurt Roeckx via RT wrote: > On Mon, Oct 12, 2015 at 04:19:43PM +0000, Matt Caswell via RT wrote: >> >> Having done some more digging it seems the problem only occurs if you >> get the initial handshake, following by a second reneg handshake *and* >> interleaved app data all within the scope of a *single* SSL_read call. >> AFAICT if SSL_read returns between the first handshake and the second, >> you don't get the problem. >> >> That's starting to sound like quite an unlikely scenario and we're only >> hitting it now because of the slightly artificial nature of Hubert's >> test. I'm wondering whether "will not fix" is the right response to this >> second bug? Thoughts? Having said that it would be nice to have a >> reliable test for the interleaved-app data issue. > > Are you saying this is 1 TLS record with 2 handshakes in it? > > From what I understand, the authentication could change. Doesn't > that mean we should make sure the client reads all data with > SSL_read() before we tell it authentication changes and that we > might have to delay processing some messages until that is done? > No. I'm saying it is within the scope of one SSL_read. libssl will read 1 record at a time from the network, process it, then read the next one, and so on. It will continue until it returns back to the user code because it ran out of data to read (NBIO), or it has filled the buffer supplied by the user code. So there is not reason why it couldn't do multiple handshakes within a single SSL_read if the buffer is big enough (or not much app data is read between handshakes) and the data is coming in from the network fast enough to prevent an IO block (e.g. such as when we are running Hubert's test code on a single machine). Matt From rt at openssl.org Mon Oct 12 19:40:01 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 12 Oct 2015 19:40:01 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <20151012194006.GA4580@roeckx.be> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <20151012181103.GA3082@roeckx.be> <561C01EB.5090302@openssl.org> <20151012194006.GA4580@roeckx.be> Message-ID: On Mon, Oct 12, 2015 at 06:54:46PM +0000, Matt Caswell via RT wrote: > > > On 12/10/15 19:11, Kurt Roeckx via RT wrote: > > On Mon, Oct 12, 2015 at 04:19:43PM +0000, Matt Caswell via RT wrote: > >> > >> Having done some more digging it seems the problem only occurs if you > >> get the initial handshake, following by a second reneg handshake *and* > >> interleaved app data all within the scope of a *single* SSL_read call. > >> AFAICT if SSL_read returns between the first handshake and the second, > >> you don't get the problem. > >> > >> That's starting to sound like quite an unlikely scenario and we're only > >> hitting it now because of the slightly artificial nature of Hubert's > >> test. I'm wondering whether "will not fix" is the right response to this > >> second bug? Thoughts? Having said that it would be nice to have a > >> reliable test for the interleaved-app data issue. > > > > Are you saying this is 1 TLS record with 2 handshakes in it? > > > > From what I understand, the authentication could change. Doesn't > > that mean we should make sure the client reads all data with > > SSL_read() before we tell it authentication changes and that we > > might have to delay processing some messages until that is done? > > > > No. I'm saying it is within the scope of one SSL_read. libssl will read > 1 record at a time from the network, process it, then read the next one, > and so on. It will continue until it returns back to the user code > because it ran out of data to read (NBIO), or it has filled the buffer > supplied by the user code. So there is not reason why it couldn't do > multiple handshakes within a single SSL_read if the buffer is big enough > (or not much app data is read between handshakes) and the data is coming > in from the network fast enough to prevent an IO block (e.g. such as > when we are running Hubert's test code on a single machine). Maybe I should go and re-reads the RFCs again, or I'm missing something, but I don't see how we could have 2 unprocessed handshakes in the buffers. I expect that we need to write something before the 2nd can arrive. But maybe it's something related to NPN or something like that? Kurt From rt at openssl.org Mon Oct 12 20:00:14 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 20:00:14 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <561C1147.5000304@openssl.org> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <561C01EB.5090302@openssl.org> <20151012194006.GA4580@roeckx.be> <561C1147.5000304@openssl.org> Message-ID: On 12/10/15 20:40, Kurt Roeckx via RT wrote: > On Mon, Oct 12, 2015 at 06:54:46PM +0000, Matt Caswell via RT wrote: >> >> >> On 12/10/15 19:11, Kurt Roeckx via RT wrote: >>> On Mon, Oct 12, 2015 at 04:19:43PM +0000, Matt Caswell via RT wrote: >>>> >>>> Having done some more digging it seems the problem only occurs if you >>>> get the initial handshake, following by a second reneg handshake *and* >>>> interleaved app data all within the scope of a *single* SSL_read call. >>>> AFAICT if SSL_read returns between the first handshake and the second, >>>> you don't get the problem. >>>> >>>> That's starting to sound like quite an unlikely scenario and we're only >>>> hitting it now because of the slightly artificial nature of Hubert's >>>> test. I'm wondering whether "will not fix" is the right response to this >>>> second bug? Thoughts? Having said that it would be nice to have a >>>> reliable test for the interleaved-app data issue. >>> >>> Are you saying this is 1 TLS record with 2 handshakes in it? >>> >>> From what I understand, the authentication could change. Doesn't >>> that mean we should make sure the client reads all data with >>> SSL_read() before we tell it authentication changes and that we >>> might have to delay processing some messages until that is done? >>> >> >> No. I'm saying it is within the scope of one SSL_read. libssl will read >> 1 record at a time from the network, process it, then read the next one, >> and so on. It will continue until it returns back to the user code >> because it ran out of data to read (NBIO), or it has filled the buffer >> supplied by the user code. So there is not reason why it couldn't do >> multiple handshakes within a single SSL_read if the buffer is big enough >> (or not much app data is read between handshakes) and the data is coming >> in from the network fast enough to prevent an IO block (e.g. such as >> when we are running Hubert's test code on a single machine). > > Maybe I should go and re-reads the RFCs again, or I'm missing > something, but I don't see how we could have 2 unprocessed > handshakes in the buffers. I expect that we need to write > something before the 2nd can arrive. But maybe it's something > related to NPN or something like that? You can't. That's not what I'm saying. They only need to be in the buffer by the time you try to read the data. Or if you're using blocking IO, it will just keep trying to read app data until its got some to return, processing any handshake messages it encounters as it goes (and processing means it may swap to writing handshake messages out). Matt From rt at openssl.org Mon Oct 12 21:37:44 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 21:37:44 +0000 Subject: [openssl-dev] [openssl.org #4085] Bug in genpkey in master In-Reply-To: References: Message-ID: Fixed. Thanks Matt From rt at openssl.org Mon Oct 12 21:38:12 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 21:38:12 +0000 Subject: [openssl-dev] [openssl.org #4086] s_server bug in master In-Reply-To: References: Message-ID: Fixed. Thanks Matt From rt at openssl.org Mon Oct 12 21:44:50 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 12 Oct 2015 21:44:50 +0000 Subject: [openssl-dev] [openssl.org #4059] Error processing set_serial parameter of the req command In-Reply-To: References: Message-ID: Fixed, thanks for the report. Matt From rt at openssl.org Tue Oct 13 00:01:15 2015 From: rt at openssl.org (Ethan Barnes via RT) Date: Tue, 13 Oct 2015 00:01:15 +0000 Subject: [openssl-dev] [openssl.org #4091] Openssl make depends gives errors when no-md5 is specified In-Reply-To: <0DD21876FF6D2243AAA252365EAF85C604DCAE2B@SACMBXIP02.sdcorp.global.sandisk.com> References: <0DD21876FF6D2243AAA252365EAF85C604DCAE2B@SACMBXIP02.sdcorp.global.sandisk.com> Message-ID: Hi, I'm trying to compile with as few options as I can since I only need AEAD and thought I would use SHA256 or SHA512 and AES. However, when I try to disable certain cryptos and hashes I get errors: ./config no-ssl no-md5 no-rsa make depends gives: ... eth.c cm_pmeth.c make[2]: Leaving directory '/home/ruck/branches/fh-23489-encryption/src/lib/crypto/crypto/cmac' make[1]: Leaving directory '/home/ruck/branches/fh-23489-encryption/src/lib/crypto/crypto' making depend in ssl... make[1]: Entering directory '/home/ruck/branches/fh-23489-encryption/src/lib/crypto/ssl' In file included from s3_srvr.c:171:0: ../include/openssl/md5.h:70:4: error: #error MD5 is disabled. # error MD5 is disabled. ^ In file included from s3_clnt.c:158:0: ../include/openssl/md5.h:70:4: error: #error MD5 is disabled. # error MD5 is disabled. ^ In file included from s3_lib.c:155:0: ../include/openssl/md5.h:70:4: error: #error MD5 is disabled. # error MD5 is disabled. ^ In file included from s3_enc.c:141:0: ../include/openssl/md5.h:70:4: error: #error MD5 is disabled. # error MD5 is disabled. ^ In file included from s3_cbc.c:59:0: ../include/openssl/md5.h:70:4: error: #error MD5 is disabled. # error MD5 is disabled. ^ In file included from t1_enc.c:145:0: ../include/openssl/md5.h:70:4: error: #error MD5 is disabled. # error MD5 is disabled. ^ In file included from d1_srvr.c:123:0: ../include/openssl/md5.h:70:4: error: #error MD5 is disabled. # error MD5 is disabled. ^ In file included from d1_clnt.c:125:0: ../include/openssl/md5.h:70:4: error: #error MD5 is disabled. # error MD5 is disabled. ^ Makefile:98: recipe for target 'local_depend' failed make[1]: *** [local_depend] Error 1 I get the same errors if I include other no-ssl options, such as no-ssl2, no-ssl3, no-sslext, etc. It also appears I cannot specify "no-rsa", as I also get errors in 'make depend'. Can I exclude those options, and if so, what other options do I need to exclude in order to build? Thanks, Ethan ________________________________ PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies). -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Oct 13 02:49:29 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Tue, 13 Oct 2015 02:49:29 +0000 Subject: [openssl-dev] [openssl.org #4091] Openssl make depends gives errors when no-md5 is specified In-Reply-To: <2fec98f08b9940e9835a18c9ee970470@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <0DD21876FF6D2243AAA252365EAF85C604DCAE2B@SACMBXIP02.sdcorp.global.sandisk.com> <2fec98f08b9940e9835a18c9ee970470@ustx2ex-dag1mb1.msg.corp.akamai.com> Message-ID: Yes, the various no-options don't work well. Not a high priority for 1.0.2 unless patches are provided. From rt at openssl.org Tue Oct 13 09:22:53 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 13 Oct 2015 09:22:53 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <561CCD67.3000603@openssl.org> References: <561801DC.9000200@openssl.org> <3825500.OcayOqxLBC@pintsize.usersys.redhat.com> <561BD440.6030703@openssl.org> <561BDD9B.3080108@openssl.org> <561CCD67.3000603@openssl.org> Message-ID: On 12/10/15 17:19, Matt Caswell via RT wrote: > > > On 12/10/15 16:39, Matt Caswell via RT wrote: >> >> >> On 12/10/15 16:03, Alessandro Ghedini via RT wrote: >>> On Mon, Oct 12, 2015 at 01:45:20PM +0000, Hubert Kario via RT wrote: >>>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: >>>>> On 09/10/15 19:02, Hubert Kario via RT wrote: >>>>>> And for good measure, I also created a test script that >>>>>> combines fragmentation with interleaving. >>>>> >>>>> Did you try my patch with it? And if so what happened? >>>> >>>> I'm using interleave-data-102.patch attached to this ticket. >>>> >>>> So, for state-machine-rewrite branch it doesn't apply, there's no >>>> ssl/s3_pkt.c file. >>>> >>>> For current 1.0.1 branch, the patch applies, test case results are as >>>> follows: >>>> * test-openssl-3712.py - pass >>>> * test-interleaved-application-data-in-renegotiation.py - pass >>>> * test-interleaved-application-data-and-fragmented-handshakes-in- >>>> renegotiation.py - pass >>>> >>>> For current 1.0.2 branch, the patch applies, tests case results are as >>>> follows: >>>> * test-openssl-3712.py - pass >>>> * test-interleaved-application-data-in-renegotiation.py - pass >>>> * test-interleaved-application-data-and-fragmented-handshakes-in- >>>> renegotiation.py - pass >>>> >>>> for current master the patch doesn't apply, just like with state- >>>> machine-rewrite there's no ssl/s3_pkt.c file >>>> >>>> Note: the two latter test cases need the s_server run in -www mode, the >>>> first test case ignores server response so will work regardless, that >>>> may be why Alessandro testing doesn't show the issue as fixed >>> >>> Ah, yep, with -www it works for me too. Note that on master the file to change >>> should be ssl/record/ssl3_record.c. However, while the patch applies cleanly to >>> this file, all the tests fail (even with -www). It seems that the field >>> in_read_app_data is never true, so the UNEXPECTED_MESSAGE alert is sent. >> >> The value of "in_read_app_data" not being true when it is supposed to >> appears to be running into a slightly different bug. It's also present >> in 1.0.2 but you have to switch off version negotiation. So running >> s_server like this in 1.0.2 and rerunning Hubert's test will hit it: >> >> openssl s_server -www -tls1_2 >> >> The 1.0.2 version negotiation is hiding the issue. In master version neg >> has been completely rewritten and simplified - but in doing so no longer >> hides the problem. :-( > > Having done some more digging it seems the problem only occurs if you > get the initial handshake, following by a second reneg handshake *and* > interleaved app data all within the scope of a *single* SSL_read call. > AFAICT if SSL_read returns between the first handshake and the second, > you don't get the problem. > > That's starting to sound like quite an unlikely scenario and we're only > hitting it now because of the slightly artificial nature of Hubert's > test. I'm wondering whether "will not fix" is the right response to this > second bug? Thoughts? Having said that it would be nice to have a > reliable test for the interleaved-app data issue. Ok, updated version of the patch attached. This is for 1.0.2 but should pass Hubert's tests even when you run s_server with "-tls1_2". Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: interleave-data-102-v2.patch Type: text/x-patch Size: 4238 bytes Desc: not available URL: From rt at openssl.org Tue Oct 13 10:55:40 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Tue, 13 Oct 2015 10:55:40 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <20942006.h5UxoOO5Gb@pintsize.usersys.redhat.com> References: <561BDD9B.3080108@openssl.org> <20942006.h5UxoOO5Gb@pintsize.usersys.redhat.com> Message-ID: On Monday 12 October 2015 16:19:43 Matt Caswell via RT wrote: > On 12/10/15 16:39, Matt Caswell via RT wrote: > > On 12/10/15 16:03, Alessandro Ghedini via RT wrote: > >> On Mon, Oct 12, 2015 at 01:45:20PM +0000, Hubert Kario via RT wrote: > >>> On Friday 09 October 2015 18:05:19 Matt Caswell via RT wrote: > >>>> On 09/10/15 19:02, Hubert Kario via RT wrote: > >>>>> And for good measure, I also created a test script that > >>>>> combines fragmentation with interleaving. > >>>> > >>>> Did you try my patch with it? And if so what happened? > >>> > >>> I'm using interleave-data-102.patch attached to this ticket. > >>> > >>> So, for state-machine-rewrite branch it doesn't apply, there's no > >>> ssl/s3_pkt.c file. > >>> > >>> For current 1.0.1 branch, the patch applies, test case results are > >>> as > >>> > >>> follows: > >>> * test-openssl-3712.py - pass > >>> * test-interleaved-application-data-in-renegotiation.py - pass > >>> * test-interleaved-application-data-and-fragmented-handshakes-in- > >>> > >>> renegotiation.py - pass > >>> > >>> For current 1.0.2 branch, the patch applies, tests case results > >>> are as>>> > >>> follows: > >>> * test-openssl-3712.py - pass > >>> * test-interleaved-application-data-in-renegotiation.py - pass > >>> * test-interleaved-application-data-and-fragmented-handshakes-in- > >>> > >>> renegotiation.py - pass > >>> > >>> for current master the patch doesn't apply, just like with state- > >>> machine-rewrite there's no ssl/s3_pkt.c file > >>> > >>> Note: the two latter test cases need the s_server run in -www > >>> mode, the first test case ignores server response so will work > >>> regardless, that may be why Alessandro testing doesn't show the > >>> issue as fixed>> > >> Ah, yep, with -www it works for me too. Note that on master the > >> file to change should be ssl/record/ssl3_record.c. However, while > >> the patch applies cleanly to this file, all the tests fail (even > >> with -www). It seems that the field in_read_app_data is never > >> true, so the UNEXPECTED_MESSAGE alert is sent.> > > The value of "in_read_app_data" not being true when it is supposed > > to > > appears to be running into a slightly different bug. It's also > > present in 1.0.2 but you have to switch off version negotiation. So > > running s_server like this in 1.0.2 and rerunning Hubert's test > > will hit it: > > > > openssl s_server -www -tls1_2 > > > > The 1.0.2 version negotiation is hiding the issue. In master version > > neg has been completely rewritten and simplified - but in doing so > > no longer hides the problem. :-( > > Having done some more digging it seems the problem only occurs if you > get the initial handshake, following by a second reneg handshake *and* > interleaved app data all within the scope of a *single* SSL_read > call. AFAICT if SSL_read returns between the first handshake and the > second, you don't get the problem. It's completely valid and not at all unlikely to have two record layer records inside single TCP packet... -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Tue Oct 13 11:00:30 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 13 Oct 2015 11:00:30 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <561CE44C.3010102@openssl.org> References: <561BDD9B.3080108@openssl.org> <20942006.h5UxoOO5Gb@pintsize.usersys.redhat.com> <561CE44C.3010102@openssl.org> Message-ID: On 13/10/15 11:55, Hubert Kario via RT wrote: >>> The value of "in_read_app_data" not being true when it is supposed >>> to >>> appears to be running into a slightly different bug. It's also >>> present in 1.0.2 but you have to switch off version negotiation. So >>> running s_server like this in 1.0.2 and rerunning Hubert's test >>> will hit it: >>> >>> openssl s_server -www -tls1_2 >>> >>> The 1.0.2 version negotiation is hiding the issue. In master version >>> neg has been completely rewritten and simplified - but in doing so >>> no longer hides the problem. :-( >> >> Having done some more digging it seems the problem only occurs if you >> get the initial handshake, following by a second reneg handshake *and* >> interleaved app data all within the scope of a *single* SSL_read >> call. AFAICT if SSL_read returns between the first handshake and the >> second, you don't get the problem. > > It's completely valid and not at all unlikely to have two record layer > records inside single TCP packet... Oh, yes. That is common. I think what is less common is to have two handshakes back-to-back with the first app data received being interleaved in the second handshake. In any case the new patch deals with this scenario anyway. Matt From rt at openssl.org Tue Oct 13 11:31:16 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Tue, 13 Oct 2015 11:31:16 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <3519008.VAreeqH2KA@pintsize.usersys.redhat.com> References: <561CCD67.3000603@openssl.org> <3519008.VAreeqH2KA@pintsize.usersys.redhat.com> Message-ID: On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: > On 12/10/15 17:19, Matt Caswell via RT wrote: > > On 12/10/15 16:39, Matt Caswell via RT wrote: > >> The value of "in_read_app_data" not being true when it is supposed > >> to > >> appears to be running into a slightly different bug. It's also > >> present in 1.0.2 but you have to switch off version negotiation. > >> So running s_server like this in 1.0.2 and rerunning Hubert's test > >> will hit it: > >> > >> openssl s_server -www -tls1_2 > >> > >> The 1.0.2 version negotiation is hiding the issue. In master > >> version neg has been completely rewritten and simplified - but in > >> doing so no longer hides the problem. :-( > > > > Having done some more digging it seems the problem only occurs if > > you > > get the initial handshake, following by a second reneg handshake > > *and* interleaved app data all within the scope of a *single* > > SSL_read call. AFAICT if SSL_read returns between the first > > handshake and the second, you don't get the problem. > > Ok, updated version of the patch attached. This is for 1.0.2 but > should pass Hubert's tests even when you run s_server with "-tls1_2". yup, looks good with -tls1_2 now too for some reason my side can't negotiate TLS 1.1 or TLS 1.0 correctly so can't test -tls1_1 or -tls1 (I'm likely generating malformed CKE there, but need to check to be sure) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From matt at openssl.org Tue Oct 13 12:34:01 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Oct 2015 13:34:01 +0100 Subject: [openssl-dev] Engine removal Message-ID: <561CFA39.60407@openssl.org> There are a number of engines within OpenSSL which, I believe, are largely dead and unused. I would like to remove them from version 1.1.0. Before I do so, I'd like to hear from anyone that can tell me about any active use of these engines. Specifically the ones I am currently looking at are: 4758cca: This provides support for the IBM 4758 PCI Cryptographic Coprocessor which was discontinued in June 2005. It was replaced by the 4764 which was itself discontinued in December 2011. In its current form this was added in 2002. There were a few emails about it to openssl-users in 2002/2003 but not much since. I did find an email from 2006 from someone asking about support for the 4764. aep: Believed to be developed by AEP Systems ? which now does not seem to exist. My guess is it is a predecessor of Ultra Electronics AEP. In its current form the engine has been there since 2002. I found a reference from 2004 of someone actually using it, and a post to openssl-users in 2002, but that's about it. RT ticket 895 from 2004 describes a problem with the AEP engine not working with Linux pthreads. No solution is recorded and the code as described in the ticket is still present in the engine today. atalla: Atalla is (now?) an HP brand (previously believed to be Compaq). Earliest git log entry I could find was from 2000 (files have been renamed since). Very little activity since. RT ticket 816 from 2004 has a bug report filed by someone using the atalla engine (on HPUX). I found a small number of openssl-users emails dating from between 2001-2004. Nothing recent. cswift: This is for the Rainbow Technologies CryptoSwift HSM Cryptographic Accelerator. Rainbow Technologies was bought by SafeNet Inc. RT825 provided a patch for the engine in 2004, which was applied in 2005. No significant activity since then. RT275 from 2002 also provided a patch which was applied. I found a few openssl-users posts dating from 2001-2003 about it. Not much since then. I did find a post from 2007 about someone (unsuccessfully apparently) trying to get it going. nuron: Google has failed me. I can't find anything out about this engine at all. No posts to openssl-users. Moved as part of the engine rewrite in 2002. No significant activity since then. sureware: Engine for Sureware HSM from Baltimore Technologies, circa 2000. I found some openssl-users enquiries about this from 2004. No significant activity since the engine rewrite in 2002. If anyone can tell me good reasons why these engines shouldn't go, then please let me know! Thanks Matt From rt at openssl.org Tue Oct 13 12:50:39 2015 From: rt at openssl.org (Srinivas Thota via RT) Date: Tue, 13 Oct 2015 12:50:39 +0000 Subject: [openssl-dev] [openssl.org #4092] Fwd: Memory Leak in X509_STORE_CTX_init In-Reply-To: References: Message-ID: Hi, Valgrind Reported Leak ===================================== ==16773== 56 bytes in 1 blocks are definitely lost in loss record 806 of 1,182 ==16773== at 0x4A07F9E: malloc (vg_replace_malloc.c:291) ==16773== by 0x3613672AE7: CRYPTO_malloc (in /lib64/libcrypto.so.1.0.0) ==16773== by 0x361372B5F6: X509_VERIFY_PARAM_new (in /lib64/libcrypto.so.1.0.0) ==16773== by 0x3613725AAA: X509_STORE_CTX_init (in /lib64/libcrypto.so.1.0.0) .... ===================================== Code ======================================== void X509_STORE_CTX_cleanup(X509_STORE_CTX *ctx) { if (ctx->cleanup) ctx->cleanup(ctx); if (ctx->param != NULL) { if (ctx->parent == NULL) // ONLY if parent is NULL param is free'd. X509_VERIFY_PARAM_free(ctx->param); ctx->param = NULL; } ... } ========================================= Code checks for ctx->parent and only then it is freeing ctx->param. This has to be corrected to free ctx->param even if ctx->parent is NULL. Please let me know if this is correct fix. Thanks, -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Tue Oct 13 18:03:44 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 13 Oct 2015 18:03:44 +0000 Subject: [openssl-dev] [openssl.org #4088] RE: [Bug] Openssl caused CPU high to 100% In-Reply-To: References: Message-ID: On Mon Oct 12 01:33:17 2015, lily.zhang at emc.com wrote: > > I debugged our client, when calling API below, I saw the client > prococess's CPU went to 25% in my host(my host has 8 GB RAM which is > more powerful). > > We reproduce this issue in different host, CPU can rise to 25%, 66%, > 100% (different hosts have different RAMs, processors). > > FIPS_mode_set(1); > > Please let me know what info are needed for this issue. > This is caused by the POST in the FIPS module which runs some tests which are resource hungry. That can't be changed because the code is part of the validated module code. The 1.2 FIPS module used with OpenSSL 0.9.8 is obsolete anyway and OpenSSL 0.9.8 itself is soon to be EOLed. The 2.0 FIPS module used in OpenSSL 1.0.1 and later has had the POST optimised so it is not as computationally intensive. If possible use that instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Oct 14 01:39:47 2015 From: rt at openssl.org (Zhang, Lily via RT) Date: Wed, 14 Oct 2015 01:39:47 +0000 Subject: [openssl-dev] [openssl.org #4088] RE: [Bug] Openssl caused CPU high to 100% In-Reply-To: References: Message-ID: Thanks for your reply. I did a test with openssl 1.0.2.d and FIPS 2.0, CPU only went up to 7% in my host, this is the same as openssl.exe. Thanks Lily -----Original Message----- From: Stephen Henson via RT [mailto:rt at openssl.org] Sent: Wednesday, October 14, 2015 2:04 AM To: Zhang, Lily (USD) Cc: openssl-dev at openssl.org Subject: [openssl.org #4088] RE: [Bug] Openssl caused CPU high to 100% On Mon Oct 12 01:33:17 2015, lily.zhang at emc.com wrote: > > I debugged our client, when calling API below, I saw the client > prococess's CPU went to 25% in my host(my host has 8 GB RAM which is > more powerful). > > We reproduce this issue in different host, CPU can rise to 25%, 66%, > 100% (different hosts have different RAMs, processors). > > FIPS_mode_set(1); > > Please let me know what info are needed for this issue. > This is caused by the POST in the FIPS module which runs some tests which are resource hungry. That can't be changed because the code is part of the validated module code. The 1.2 FIPS module used with OpenSSL 0.9.8 is obsolete anyway and OpenSSL 0.9.8 itself is soon to be EOLed. The 2.0 FIPS module used in OpenSSL 1.0.1 and later has had the POST optimised so it is not as computationally intensive. If possible use that instead. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From appro at openssl.org Wed Oct 14 08:10:51 2015 From: appro at openssl.org (Andy Polyakov) Date: Wed, 14 Oct 2015 10:10:51 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <20151012172205.GA28726@kronk.local> References: <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> <20151006193753.GA14151@kronk.local> <20151012172205.GA28726@kronk.local> Message-ID: <561E0E0B.2080001@openssl.org> >>> I've opened the following PR to add support for GCC v5 and >>> address sanitizer (not sure if we want valgrind as well...): >>> https://github.com/openssl/openssl/pull/429 I've commented there on other -fsanitize options as well as about option to execute them without --debug and/or --strict-warnings. But I failed to recall all the details from last time the question was risen in context of RT#3422 through 3324. -fsanitize=undefined is expected to work only with --strict-warnings (or more specifically with -DPEDANTIC) and I wouldn't be surprised if -fsanitize=memory works only with -DPURIFY. From rt at openssl.org Wed Oct 14 10:46:56 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 14 Oct 2015 10:46:56 +0000 Subject: [openssl-dev] [openssl.org #4088] RE: [Bug] Openssl caused CPU high to 100% In-Reply-To: References: Message-ID: OK thanks for the update. Ticket closed. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Oct 14 17:54:04 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Wed, 14 Oct 2015 17:54:04 +0000 Subject: [openssl-dev] [openssl.org #3896] unable to install to openssldir In-Reply-To: <5570D131.4070808@mozilla.com> References: <5570D131.4070808@mozilla.com> Message-ID: Nope, not doing anything wrong. makedepend is bust and can't find the headers. Our clang and OS/X configurations were a bit off - I've changed them to use clang for 'make depend' as well when clang is the compiler, see commit c97c7f8d53dda12f4fda24fc7542281999df97f6. Cheers, Emilia From rt at openssl.org Wed Oct 14 19:10:53 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Wed, 14 Oct 2015 19:10:53 +0000 Subject: [openssl-dev] [openssl.org #4093] Problem loading engine from config In-Reply-To: References: Message-ID: Hello, I have a problem when I load an engine from config file in master. OpenSSL cmdline: /home/build/openssl-shell/openssl/apps/openssl dgst -md_gost94 dgst.dat Error configuring OpenSSL modules 47445915269832:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:172:filename(libengines.so): libengines.so: cannot open shared object file: No such file or directory 47445915269832:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:227: 47445915269832:error:0E07506E:configuration file routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:270:module=engines, path=engines 47445915269832:error:0E076071:configuration file routines:MODULE_RUN:unknown module name:conf_mod.c:212:module=engines The openssl.cnf file I use is: ======== openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] gost=gost_section [gost_section] dynamic_path=/home/build/openssl-shell/openssl/engines/ccgost/libgost.so engine_id=gost default_algorithms = ALL ======== The gost engine I build is from the master. If I delete the lines ======== engines = engine_section [engine_section] ======== I get another error: dgst: Unknown digest md_gost94 dgst: Use -help for summary. The behavior seems to be changed after the commit https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=a0a82324f965bbcc4faed4e1ee3fcaf81ea52166 Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Oct 14 19:29:42 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Wed, 14 Oct 2015 19:29:42 +0000 Subject: [openssl-dev] [openssl.org #4093] AutoReply: Problem loading engine from config In-Reply-To: References: Message-ID: Hello! The attached patch fixes it. On Wed, Oct 14, 2015 at 10:10 PM, The default queue via RT wrote: > > Greetings, > > This message has been automatically generated in response to the > creation of a trouble ticket regarding: > "Problem loading engine from config", > a summary of which appears below. > > There is no need to reply to this message right now. Your ticket has been > assigned an ID of [openssl.org #4093]. > > Please include the string: > > [openssl.org #4093] > > in the subject line of all future correspondence about this issue. To do > so, > you may reply to this message. > > Thank you, > rt at openssl.org > > ------------------------------------------------------------------------- > Hello, > > I have a problem when I load an engine from config file in master. > > OpenSSL cmdline: /home/build/openssl-shell/openssl/apps/openssl dgst > -md_gost94 dgst.dat > > Error configuring OpenSSL modules > 47445915269832:error:25066067:DSO support routines:DLFCN_LOAD:could not > load the shared library:dso_dlfcn.c:172:filename(libengines.so): > libengines.so: cannot open shared object file: No such file or directory > 47445915269832:error:25070067:DSO support routines:DSO_load:could not load > the shared library:dso_lib.c:227: > 47445915269832:error:0E07506E:configuration file > routines:MODULE_LOAD_DSO:error loading dso:conf_mod.c:270:module=engines, > path=engines > 47445915269832:error:0E076071:configuration file > routines:MODULE_RUN:unknown module name:conf_mod.c:212:module=engines > > The openssl.cnf file I use is: > > ======== > openssl_conf = openssl_def > [openssl_def] > engines = engine_section > [engine_section] > gost=gost_section > [gost_section] > dynamic_path=/home/build/openssl-shell/openssl/engines/ccgost/libgost.so > engine_id=gost > default_algorithms = ALL > ======== > > The gost engine I build is from the master. > > If I delete the lines > ======== > engines = engine_section > [engine_section] > ======== > I get another error: > > dgst: Unknown digest md_gost94 > dgst: Use -help for summary. > > The behavior seems to be changed after the commit > > https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=a0a82324f965bbcc4faed4e1ee3fcaf81ea52166 > > Thank you! > > -- > SY, Dmitry Belyavsky > > -- SY, Dmitry Belyavsky -------------- next part -------------- --- a/apps/openssl.c +++ b/apps/openssl.c @@ -175,6 +175,10 @@ static int apps_startup() ERR_load_crypto_strings(); ERR_load_SSL_strings(); + OPENSSL_load_builtin_modules(); +#ifndef OPENSSL_NO_ENGINE + ENGINE_load_builtin_engines(); +#endif if (!app_load_modules(NULL)) { ERR_print_errors(bio_err); BIO_printf(bio_err, "Error loading default configuration\n"); @@ -183,12 +187,8 @@ static int apps_startup() OpenSSL_add_all_algorithms(); OpenSSL_add_ssl_algorithms(); - OPENSSL_load_builtin_modules(); setup_ui_method(); /*SSL_library_init();*/ -#ifndef OPENSSL_NO_ENGINE - ENGINE_load_builtin_engines(); -#endif return 1; } From rt at openssl.org Thu Oct 15 03:11:11 2015 From: rt at openssl.org (Pascal Cuoq via RT) Date: Thu, 15 Oct 2015 03:11:11 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> Message-ID: As of 2015-10-14, the function PACKET_buf_init in ssl/packet_locl.h reads: static inline int PACKET_buf_init(PACKET *pkt, unsigned char *buf, size_t len) { /* Sanity check for negative values. */ if (buf + len < buf) return 0; pkt->curr = buf; pkt->remaining = len; return 1; } Link: https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/ssl/packet_locl.h#L113 The rules of pointer arithmetics are such that the condition (buf + len < buf) is always false when it is defined. A modern compiler, or even an old compiler, could suppress the entire conditional from the generated code without a second thought and without a warning. Please read https://lwn.net/Articles/278137/ . Note that in that very similar instance, the GCC developers did not acknowledge any bug in their compiler, did not change the compiler's behavior, and simply regretted that "their project has been singled out in an unfair way". That LWN story is not a about a compiler bug, or in any case, it is about a compiler bug that is here to stay. And according to GCC developers, to be common to several C compilers. As far as I can tell, no current compiler recognizes that the very same reasoning as in that old LWN story justifies the suppression of the conditional. I tested the compilers currently available on https://gcc.godbolt.org . However, any compiler willing to miscompile the examples in the LWN article would gladly miscompile the function PACKET_buf_init given the chance. If the function is intended to return 0 for large values of len, then the test should look like: if (len > (size_t)(SIZE_MAX / 2)) ... Here I have chosen a constant that happens to give a behavior close to the one obtained by luck with current compilers. If another constant makes sense, then that other constant can be used. The current implementation is an invitation for the compiler to generate code that, even when len is above the limit, sets pkt->curr to buf, sets pkt->remaining to len, and returns 1, which is not what is intended, and could have serious security-related consequences latter on. If, as the comment implies, the function is not intended to be called with a len so large that it causes (uintptr_t)buf + len to be lower than (uintptr_t)buf, then please, please, please simplify the function by removing this nonsensical "sanity check", and make this function, which cannot fail, return void-as the history of the rest of OpenSSL shows, remembering of testing all error codes returned by called functions is difficult enough, even when only functions that have reason to fail return such codes. PACKET_buf_init is called with (size_t)-1 for len in test/packettest.c: https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/test/packettest.c#L341 Since PACKET_buf_init could no longer fail, that test could be simplified, which is good. If a sanity check is indispensable in PACKET_buf_init, but is really a check for something not supposed to happen, then in order to keep the type returned by the function as void, the check could be expressed as: if (len > (size_t)(SIZE_MAX / 2)) abort(); or assert (len <= (size_t)(SIZE_MAX / 2)); -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 15 10:44:25 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 15 Oct 2015 10:44:25 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> Message-ID: Given OpenSSL's eternal type confusion, this check is meant to trap callers that get an error return (typically -1) from some API returning signed values and pass that on to PACKET_buf_init as a size_t. For example, ssl3_get_message returns a long to signal buffer length, and that makes me nervous. Except, yeah, it relies on undefined behaviour. OTOH as you note we do have a test for this and we've not seen it fail on any compiler. I agree the check is pointless if your sizes are correctly represented as size_t throughout, but perhaps marginally useful for OpenSSL in its current state. I don't feel too strongly about keeping or removing it - what do others think? From rt at openssl.org Thu Oct 15 12:41:47 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 15 Oct 2015 12:41:47 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <561F9F06.9030408@openssl.org> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> Message-ID: On 15/10/15 04:11, Pascal Cuoq via RT wrote: > As of 2015-10-14, the function PACKET_buf_init in ssl/packet_locl.h > reads: > > static inline int PACKET_buf_init(PACKET *pkt, unsigned char *buf, > size_t len) { /* Sanity check for negative values. */ if (buf + len < > buf) return 0; > > pkt->curr = buf; pkt->remaining = len; return 1; } > > Link: > https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/ssl/packet_locl.h#L113 > > The rules of pointer arithmetics are such that the condition (buf + > len < buf) is always false when it is defined. A modern compiler, or > even an old compiler, could suppress the entire conditional from the > generated code without a second thought and without a warning. Please > read https://lwn.net/Articles/278137/ . Note that in that very > similar instance, the GCC developers did not acknowledge any bug in > their compiler, did not change the compiler's behavior, and simply > regretted that "their project has been singled out in an unfair > way". > > That LWN story is not a about a compiler bug, or in any case, it is > about a compiler bug that is here to stay. And according to GCC > developers, to be common to several C compilers. The LWN story is about secure coding, and a specific pitfall to be aware of which may compile away a test for buffer underflow. Specifically they are talking about a length value received from an untrusted source and testing that it falls within the bounds of a buffer. That is *not* the case here. This test is not about adding a critical security check. The contract that PACKET_buf_init provides to code using it requires that the buffer provided must be (at least) |len| bytes long. It is for the calling code to perform this necessary security checks prior to calling PACKET_buf_init. This code can assume that |len| is from a trusted source. The purpose of the sanity check is not then for security, but to guard against programmer error. For a correctly functioning program this test should never fail. For an incorrectly functioning program it may do. It is not guaranteed to fail because the test could be compiled away but, most likely, it will. We can have some degree of confidence that the test works and does not get compiled away in most instances because, as you point out, an explicit check for it appears in packettest.c and, to date, we have had no reported failures. > > As far as I can tell, no current compiler recognizes that the very > same reasoning as in that old LWN story justifies the suppression of > the conditional. I tested the compilers currently available on > https://gcc.godbolt.org . However, any compiler willing to miscompile > the examples in the LWN article would gladly miscompile the function > PACKET_buf_init given the chance. > > If the function is intended to return 0 for large values of len, then > the test should look like: > > if (len > (size_t)(SIZE_MAX / 2)) ... > > Here I have chosen a constant that happens to give a behavior close > to the one obtained by luck with current compilers. If another > constant makes sense, then that other constant can be used. The > current implementation is an invitation for the compiler to generate > code that, even when len is above the limit, sets pkt->curr to buf, > sets pkt->remaining to len, and returns 1, which is not what is > intended, and could have serious security-related consequences latter > on. The biggest packet that I can think of that we will ever have to deal with within libssl would be a handshake message. This has a maximum length of 0xffffff plus 5 bytes of message header, i.e. 0x1000004. There could be an argument to say we should test against this to ensure that |len| is not too big. However that does not necessarily guard against the pointer overflowing. In an incorrect program where len is just a bit bigger than the actual size of buf this could, theoretically, be sufficient to overflow the pointer. > > If, as the comment implies, the function is not intended to be called > with a len so large that it causes (uintptr_t)buf + len to be lower > than (uintptr_t)buf, then please, please, please simplify the > function by removing this nonsensical "sanity check", and make this > function, which cannot fail, return void-as the history of the rest > of OpenSSL shows, remembering of testing all error codes returned by > called functions is difficult enough, even when only functions that > have reason to fail return such codes. You are correct that this has historically been a problem. All the dev team use the "--strict-warnings" parameter to config. One of the effects of this is to treat warnings as errors and this will therefore fail on any function declared with "__owur" where the return value is unused. We should ensure that PACKET_buf_init is declared with this (and I believe Emilia is making that change). Therefore this should not be an issue for this code. > > PACKET_buf_init is called with (size_t)-1 for len in > test/packettest.c: The issue you are raising is actually problematic for this test. We've not had a reported issue with it, but technically it is relying on undefined behaviour. If we additionally added the maximum length check then this would still pass, even if the underflow check got compiled away. > > https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/test/packettest.c#L341 > > Since PACKET_buf_init could no longer fail, that test could be > simplified, which is good. > > If a sanity check is indispensable in PACKET_buf_init, but is really > a check for something not supposed to happen, then in order to keep > the type returned by the function as void, the check could be > expressed as: > > if (len > (size_t)(SIZE_MAX / 2)) abort(); > > or > > assert (len <= (size_t)(SIZE_MAX / 2)); I do not agree that this is a good approach. Opinions on this differ within the dev team, however IMO we should never call abort in a library. I have seen too many instances where "should never happen" events which resulted in an abort did actually happen, and could be forced to happen under attacker control thus leading to a DoS. So whilst we do not rely on the test in question for adding security, aborting if it fails could lead to a CVE. In summary my opinion is: - I believe the sanity check does have some value in guarding against programmer error - If it were to be compiled away this does not have a detrimental impact on security (it just increases the likelihood of a crash in the event of a programmer error) - There could be a good argument for adding an additional maximum length check - I do not believe the function should be made void Matt From rt at openssl.org Thu Oct 15 13:33:35 2015 From: rt at openssl.org (tosif tamboli via RT) Date: Thu, 15 Oct 2015 13:33:35 +0000 Subject: [openssl-dev] [openssl.org #4095] X509_STORE_get_by_subject crash In-Reply-To: References: Message-ID: Hi, Recently we updated the openssl crypto from 0.9.7e 25 to 1.0.1e But it is always crashing while vertifying the certificates from image When debugged found that crash is happening when X509_STORE_get_by_subject called with issuer and issuer name is empty X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, pIssuer, &x509_obj); When searched for pIssuer, using below functions Char * issuer = X509_NAME_oneline (pIssuer, NULL, 0); Issuer is empty(not null). Hence application crashed. Can you please rpovide your inputs why we get the issuer as empty in newer version. But in older version it is correct and non-empty. also why does it crash. It will be helpful if you can provide your inputs for above query. Thanks & regards, Tosif -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rsalz at akamai.com Thu Oct 15 13:35:28 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 15 Oct 2015 13:35:28 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> Message-ID: <3a692587ff434240b29517d2f6a4f686@ustx2ex-dag1mb3.msg.corp.akamai.com> > PACKET_buf_init. This code can assume that |len| is from a trusted source. > > The purpose of the sanity check is not then for security, but to guard against > programmer error. For a correctly functioning program this test should never > fail. I would say that the combination of these two things means that it should be an assert. From rt at openssl.org Thu Oct 15 13:35:37 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 15 Oct 2015 13:35:37 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <3a692587ff434240b29517d2f6a4f686@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <3a692587ff434240b29517d2f6a4f686@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: > PACKET_buf_init. This code can assume that |len| is from a trusted source. > > The purpose of the sanity check is not then for security, but to guard against > programmer error. For a correctly functioning program this test should never > fail. I would say that the combination of these two things means that it should be an assert. From rt at openssl.org Thu Oct 15 14:13:52 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 15 Oct 2015 14:13:52 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <561FB49B.4040902@openssl.org> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <3a692587ff434240b29517d2f6a4f686@ustx2ex-dag1mb3.msg.corp.akamai.com> <561FB49B.4040902@openssl.org> Message-ID: On 15/10/15 14:35, Salz, Rich via RT wrote: > >> PACKET_buf_init. This code can assume that |len| is from a trusted source. >> >> The purpose of the sanity check is not then for security, but to guard against >> programmer error. For a correctly functioning program this test should never >> fail. > > I would say that the combination of these two things means that it should be an assert. assert has its uses, but it depends what you are trying to achieve. If you are developing new code and trying to track down a difficult to find problem - very useful. Even potentially if you are trying to track down a difficult issue in a production scenario, you could create a special debug build to help you pinpoint what is going wrong. I'm sure there are other scenarios which would be excellent uses of assert. IMO this test is about protecting ourselves in the unlikely event that a programmer error does not present itself until production. To protect production code assert is useless because it gets compiled away. If we are concerned about potential programmer errors not appearing until we get into production then assert is not the right tool. You could argue that you should use OPENSSL_assert(), but my views on that are well known. OPENSSL_assert calls abort() even in production which is wrong IMO and potentially dangerous. I know opinions differ on that point within the dev team and this ticket is probably not the place to reopen that particular debate. Suffice it to say I would not support the use of OPENSSL_assert here. Matt From rt at openssl.org Thu Oct 15 14:40:38 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 15 Oct 2015 14:40:38 +0000 Subject: [openssl-dev] [openssl.org #3979] New OpenSSL issue: valid certificate fails validation where subject text == issuer text In-Reply-To: References: Message-ID: Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Thu Oct 15 14:46:00 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 15 Oct 2015 14:46:00 +0000 Subject: [openssl-dev] [openssl.org #4095] X509_STORE_get_by_subject crash In-Reply-To: References: Message-ID: This sounds like an application problem. 1) Did you recompile your source? 0.9.7 and 1.0.1 are not binary-compatible. 2) The certificate hash format has changed between 1.0.1 and 0.9.7, which could explain why the lookup no longer works: https://www.openssl.org/docs/manmaster/apps/rehash.html If the above isn't helpful, try asking for help on openssl-users at . Rejecting the ticket (though please reopen if you find new evidence that this is a bug within OpenSSL). Cheers, Emilia From rt at openssl.org Thu Oct 15 15:12:38 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 15 Oct 2015 15:12:38 +0000 Subject: [openssl-dev] [openssl.org #3731] BUG darwin FIPS openssl-1.0.2 ssl/t1_lib.c line 472 In-Reply-To: <1CF6ABD3-6C3C-4F7E-B51C-7796CC15FCCC@thursby.com> References: <1CF6ABD3-6C3C-4F7E-B51C-7796CC15FCCC@thursby.com> Message-ID: This was fixed in January: 6fa805f516f5a6ff3872f1d1014a3dc9de460b99 From rt at openssl.org Thu Oct 15 15:19:26 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 15 Oct 2015 15:19:26 +0000 Subject: [openssl-dev] [openssl.org #3138] 80-bit Elliptic Curves with !MEDIUM !LOW !EXP cipher list In-Reply-To: References: Message-ID: Curves aren't negotiated with the ciphersuite, but rather via a separate extension. Since OpenSSL 1.0.2, there are SSL_CTX_set1_curves and SSL_CTX_set1_curves_list to configure supported curves: https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_ecdh_auto.html OpenSSL 1.1 also has a security levels API in the works to make this sort of configuration easier. From rt at openssl.org Thu Oct 15 15:22:19 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 15 Oct 2015 15:22:19 +0000 Subject: [openssl-dev] [openssl.org #3645] openssl-1.0.1h-cmp - Linking issue In-Reply-To: References: Message-ID: openssl-1.0.1h-cmp isn't an official OpenSSL version. You should seek help with whoever provides this library for you. Cheers, Emilia From rt at openssl.org Thu Oct 15 15:31:10 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Thu, 15 Oct 2015 15:31:10 +0000 Subject: [openssl-dev] [openssl.org #3013] Sending SCSV when TLS extensions are disabled In-Reply-To: <2B830C10D3A65B42856BB9DDF14806900A1F90@MIVEXAMER1N2.corp.nai.org> References: <2B830C10D3A65B42856BB9DDF14806900A1F90@MIVEXAMER1N2.corp.nai.org> Message-ID: Rejecting - SCSV is not a TLS extension. From rt at openssl.org Thu Oct 15 16:17:53 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Thu, 15 Oct 2015 16:17:53 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <561FD1AD.1000003@akamai.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <561FD1AD.1000003@akamai.com> Message-ID: On 10/15/2015 07:41 AM, Matt Caswell via RT wrote: > > In summary my opinion is: > - I believe the sanity check does have some value in guarding against > programmer error > - If it were to be compiled away this does not have a detrimental impact > on security (it just increases the likelihood of a crash in the event of > a programmer error) Strictly speaking, it is not a matter of "is the check left as-is" vs. "is the check compiled away". C's undefined behavior rules are pretty open-ended, and the compiler is free to generate code such that, if inputs that would trigger that check were supplied, does absolutely anything at all. Absolutely anything at all means just that; it does not need to be limited to the local scope and could include exiting from the program or also reading from /etc/ssh/ssh_host_rsa_key and sending it over the network. Now, the compiler is unlikely to do something "interesting" like that, since it would be at odds with the compiler's goal of producing fast code, but relying on that does not exactly make me comfortable. (N.B. this is not the common case of signed integer overflow that's easy to reason about; pointer arithmetic has its own rules for undefined behavior that get invoked when the resulting pointer would not point to inside (or one past) the same array object that the starting pointer pointed inside. This happens in many, many, many more cases than the current check would catch. Section 6.5.6 of n1256.pdf covers this topic.) -Ben > - There could be a good argument for adding an additional maximum length > check > - I do not believe the function should be made void > From rt at openssl.org Thu Oct 15 16:50:13 2015 From: rt at openssl.org (Peylo, Martin via RT) Date: Thu, 15 Oct 2015 16:50:13 +0000 Subject: [openssl-dev] [openssl.org #3645] openssl-1.0.1h-cmp - Linking issue In-Reply-To: <4A3C69272D7B60429FD7F8276C8CF9420C97020A@DEMUMBX008.nsn-intra.net> References: <4A3C69272D7B60429FD7F8276C8CF9420C97020A@DEMUMBX008.nsn-intra.net> Message-ID: Hi, Just as a note, in case anybody would find this thread in search for help in the future: The described issue likely wouldn't have appeared if following the full building instructions (for the CMP patch) as mentioned e.g. in RT#3101: ./config make depend make stacks make Cheers, Martin -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of EXT Emilia K?sper via RT Sent: Thursday, October 15, 2015 6:22 PM To: ajim_hussain at hotmail.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #3645] openssl-1.0.1h-cmp - Linking issue openssl-1.0.1h-cmp isn't an official OpenSSL version. You should seek help with whoever provides this library for you. Cheers, Emilia _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Oct 15 19:53:33 2015 From: rt at openssl.org (Alexander Cherepanov via RT) Date: Thu, 15 Oct 2015 19:53:33 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <5620023B.1000200@openwall.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620023B.1000200@openwall.com> Message-ID: On 2015-10-15 15:41, Matt Caswell via RT wrote: > The purpose of the sanity check is not then for security, but to guard > against programmer error. For a correctly functioning program this test > should never fail. For an incorrectly functioning program it may do. It > is not guaranteed to fail because the test could be compiled away but, > most likely, it will. We can have some degree of confidence that the > test works and does not get compiled away in most instances because, as > you point out, an explicit check for it appears in packettest.c and, to > date, we have had no reported failures. What was not entirely clear from the original bug report is that, while the check is not compiled away, it's compiled into something completely different from what is written in the source. Specifically, the check "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for overflow at all, it doesn't even depend on the value of "buf". If this is what was intended then it's better to write it explicitly. If this is not what was intended then some other approach is required. > The biggest packet that I can think of that we will ever have to deal > with within libssl would be a handshake message. This has a maximum > length of 0xffffff plus 5 bytes of message header, i.e. 0x1000004. There > could be an argument to say we should test against this to ensure that > |len| is not too big. > > However that does not necessarily guard against the pointer overflowing. > In an incorrect program where len is just a bit bigger than the actual > size of buf this could, theoretically, be sufficient to overflow the > pointer. Right. That's exactly one of the problem with the current code the way it is compiled by optimizing compilers. A couple of other remarks. 1. The mere fact that the (sub)expression "buf + len" is evaluated unconditionally permits a compiler to assume that this is a valid pointer (it's UB otherwise) and hence that it points inside an array. This, in turn, permits the compiler to remove some other checks against "buf + len" or "len" even if they are well-written. I'm not saying that any of current compilers can do it, I'm just saying that undefined behavior is a very delicate thing and it's better not to have it in your program. 2. If you want to simplify checking openssl for undefined behavior it's better to fix even non-critical cases of it. Otherwise everybody have to research it, to maintain their blacklists of things to ignore etc. It's similar to compiler warnings: if you want to get more value from compiler warnings you have to keep your project warnings-free fixing even minor and false ones. HTH -- Alexander Cherepanov From rt at openssl.org Thu Oct 15 21:52:46 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Thu, 15 Oct 2015 21:52:46 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <56202023.8090501@akamai.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <56202023.8090501@akamai.com> Message-ID: On 10/15/2015 05:44 AM, Emilia K?sper via RT wrote: > Given OpenSSL's eternal type confusion, this check is meant to trap callers > that get an error return (typically -1) from some API returning signed values > Hmm, do we have a sense for how typically "typically" is? Maybe just adding a check for (len == (size_t)-1) is the right thing to do. -Ben From rt at openssl.org Fri Oct 16 08:32:35 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 16 Oct 2015 08:32:35 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <5620B61D.3050200@openssl.org> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620023B.1000200@openwall.com> <5620B61D.3050200@openssl.org> Message-ID: On 15/10/15 20:53, Alexander Cherepanov via RT wrote: > On 2015-10-15 15:41, Matt Caswell via RT wrote: >> The purpose of the sanity check is not then for security, but to guard >> against programmer error. For a correctly functioning program this test >> should never fail. For an incorrectly functioning program it may do. It >> is not guaranteed to fail because the test could be compiled away but, >> most likely, it will. We can have some degree of confidence that the >> test works and does not get compiled away in most instances because, as >> you point out, an explicit check for it appears in packettest.c and, to >> date, we have had no reported failures. > > What was not entirely clear from the original bug report is that, while > the check is not compiled away, it's compiled into something completely > different from what is written in the source. Specifically, the check > "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. > "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for > overflow at all, it doesn't even depend on the value of "buf". > > If this is what was intended then it's better to write it explicitly. If > this is not what was intended then some other approach is required. I'd say that is an instance of the compiler knowing better than us how big |len| would have to be in order to trigger an overflow. Those rules are going to be platform specific so we should not attempt to second guess them, but instead let the optimiser do its job. Matt From rt at openssl.org Fri Oct 16 08:53:06 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 16 Oct 2015 08:53:06 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <5620BAF0.3020909@openssl.org> References: <561CCD67.3000603@openssl.org> <3519008.VAreeqH2KA@pintsize.usersys.redhat.com> <5620BAF0.3020909@openssl.org> Message-ID: On 13/10/15 12:31, Hubert Kario via RT wrote: > On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: >> On 12/10/15 17:19, Matt Caswell via RT wrote: >>> On 12/10/15 16:39, Matt Caswell via RT wrote: >>>> The value of "in_read_app_data" not being true when it is supposed >>>> to >>>> appears to be running into a slightly different bug. It's also >>>> present in 1.0.2 but you have to switch off version negotiation. >>>> So running s_server like this in 1.0.2 and rerunning Hubert's test >>>> will hit it: >>>> >>>> openssl s_server -www -tls1_2 >>>> >>>> The 1.0.2 version negotiation is hiding the issue. In master >>>> version neg has been completely rewritten and simplified - but in >>>> doing so no longer hides the problem. :-( >>> >>> Having done some more digging it seems the problem only occurs if >>> you >>> get the initial handshake, following by a second reneg handshake >>> *and* interleaved app data all within the scope of a *single* >>> SSL_read call. AFAICT if SSL_read returns between the first >>> handshake and the second, you don't get the problem. >> >> Ok, updated version of the patch attached. This is for 1.0.2 but >> should pass Hubert's tests even when you run s_server with "-tls1_2". > > yup, looks good with -tls1_2 now too > > for some reason my side can't negotiate TLS 1.1 or TLS 1.0 correctly so > can't test -tls1_1 or -tls1 (I'm likely generating malformed CKE there, > but need to check to be sure) I raised the ambiguity in the spec about when in the handshake interleaved app data is allowed with the TLS WG. You can see the thread here: https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017 I got a few responses, not all of which were consistent, and giving different views. To summarise what I interpret as the main points: 1) Where a view was given it seemed to concur with the views expressed here that the most sensible interpretation of the spec wording is that interleaved app data is allowed up until the CCS, but not between CCS and Finished. 2) There was also a view expressed that, regardless of what the spec says, allowing interleaved app data is *dangerous*! 3) There seemed to be differing views on just how dangerous ranging from it being "a highly dangerous idea" to "...there is a need for caution, but in reality, it's not like you can use renegotiation to hand-off to someone else entirely. The person you are talking to hasn't changed. What is dangerous is making assertions about *new* things that the renegotiation introduces", although the same person who made that last observation also provided a list of very onerous mitigations that we should put in place if were to do it (none of which are likely to be adopted IMO without some form of official advice from the TLS WG). So now I really don't know what the "right" way forward is. Should we be applying the patch or not? Matt From matt at openssl.org Fri Oct 16 08:55:41 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 16 Oct 2015 09:55:41 +0100 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <561CCD67.3000603@openssl.org> <3519008.VAreeqH2KA@pintsize.usersys.redhat.com> <5620BAF0.3020909@openssl.org> Message-ID: <5620BB8D.5030008@openssl.org> On 16/10/15 09:53, Matt Caswell via RT wrote: > > > On 13/10/15 12:31, Hubert Kario via RT wrote: >> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: >>> On 12/10/15 17:19, Matt Caswell via RT wrote: >>>> On 12/10/15 16:39, Matt Caswell via RT wrote: >>>>> The value of "in_read_app_data" not being true when it is supposed >>>>> to >>>>> appears to be running into a slightly different bug. It's also >>>>> present in 1.0.2 but you have to switch off version negotiation. >>>>> So running s_server like this in 1.0.2 and rerunning Hubert's test >>>>> will hit it: >>>>> >>>>> openssl s_server -www -tls1_2 >>>>> >>>>> The 1.0.2 version negotiation is hiding the issue. In master >>>>> version neg has been completely rewritten and simplified - but in >>>>> doing so no longer hides the problem. :-( >>>> >>>> Having done some more digging it seems the problem only occurs if >>>> you >>>> get the initial handshake, following by a second reneg handshake >>>> *and* interleaved app data all within the scope of a *single* >>>> SSL_read call. AFAICT if SSL_read returns between the first >>>> handshake and the second, you don't get the problem. >>> >>> Ok, updated version of the patch attached. This is for 1.0.2 but >>> should pass Hubert's tests even when you run s_server with "-tls1_2". >> >> yup, looks good with -tls1_2 now too >> >> for some reason my side can't negotiate TLS 1.1 or TLS 1.0 correctly so >> can't test -tls1_1 or -tls1 (I'm likely generating malformed CKE there, >> but need to check to be sure) > > I raised the ambiguity in the spec about when in the handshake > interleaved app data is allowed with the TLS WG. You can see the thread > here: > https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017 > > I got a few responses, not all of which were consistent, and giving > different views. To summarise what I interpret as the main points: > > 1) Where a view was given it seemed to concur with the views expressed > here that the most sensible interpretation of the spec wording is that > interleaved app data is allowed up until the CCS, but not between CCS > and Finished. > 2) There was also a view expressed that, regardless of what the spec > says, allowing interleaved app data is *dangerous*! > 3) There seemed to be differing views on just how dangerous ranging from > it being "a highly dangerous idea" to "...there is a need for caution, > but in reality, it's not like you can use renegotiation to hand-off to > someone else entirely. The person you are talking to hasn't changed. > What is dangerous is making assertions about *new* things that the > renegotiation introduces", although the same person who made that last > observation also provided a list of very onerous mitigations that we > should put in place if were to do it (none of which are likely to be > adopted IMO without some form of official advice from the TLS WG). > > So now I really don't know what the "right" way forward is. Should we be > applying the patch or not? I should add that another interesting point was that BoringSSL prohibits interleaved app data. Matt From appro at openssl.org Fri Oct 16 08:56:43 2015 From: appro at openssl.org (Andy Polyakov) Date: Fri, 16 Oct 2015 10:56:43 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <561E0E0B.2080001@openssl.org> References: <5602AFBE.4090407@openssl.org> <20150926091251.GA20827@kronk.local> <5607A98B.9010409@openssl.org> <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> <20151006193753.GA14151@kronk.local> <20151012172205.GA28726@kronk.local> <561E0E0B.2080001@openssl.org> Message-ID: <5620BBCB.4040108@openssl.org> >>>> I've opened the following PR to add support for GCC v5 and >>>> address sanitizer (not sure if we want valgrind as well...): >>>> https://github.com/openssl/openssl/pull/429 > > I've commented there on other -fsanitize options as well as about > option to execute them without --debug and/or --strict-warnings. But I > failed to recall all the details from last time the question was risen > in context of RT#3422 through 3324. -fsanitize=undefined is expected > to work only with --strict-warnings (or more specifically with > -DPEDANTIC) and I wouldn't be surprised if -fsanitize=memory works > only with -DPURIFY. The main weakness of the endeavour is that testing is limited to x86 hardware. I don't mean specifically -fsanitize, but in general. But let's concentrate on -fsanitize for a moment. Or more specifically why are there limitations for it, ones mentioned above. In the nutshell, remaining -fsanitize warnings were effectively about the fact that we sometimes rely on platform- or implementation-specific behaviour. But it is *conscious* choice and there always is platform-neutral fallback. So that above mentioned limitations are actually about nothing else but driving compiler toward these platform-neutral fallbacks. One can even take next step and say that in order to maximize -fsanitize utility, one should expose as much C code to -fsanitize as possible, or in other words adhere even to no-asm with -fsanitize. Incidentally this would also at least partially mitigate the main weakness, as -fsanitize should expose spots where platform-neutral fallback is not as platform-neutral as it should be, wouldn't it? From rt at openssl.org Fri Oct 16 09:43:12 2015 From: rt at openssl.org (tosif tamboli via RT) Date: Fri, 16 Oct 2015 09:43:12 +0000 Subject: [openssl-dev] [openssl.org #4095] X509_STORE_get_by_subject crash In-Reply-To: References: Message-ID: Hi, below is my application code sshX509CACertStore = X509_STORE_new(); X509_STORE_set_verify_cb_func(sshX509CACertStore, sshX509CertVerifyCallback); pLookup = X509_STORE_add_lookup(sshX509CACertStore, X509_LOOKUP_file()); X509_LOOKUP_load_file(pLookup,caFile,X509_FILETYPE_PEM) X509_STORE_CTX_init (pStoreCtx, sshX509CACertStore, pX509, NULL); ret = X509_verify_cert (pStoreCtx); in the callback function I just checked for retVal = X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, pSubject, &x509_obj); retVal = X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, pIssuer, &x509_obj); older openssl used md5 hash and newer doesn't seem to use it As you mentioned about c_rehash. How should I create new symlink in code. My application is to verify the certificate and signature in image It will be helpful if you can provide your inputs for crash of above application at X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, pIssuer, &x509_obj); Thanks & regards, Tosif On Thu, Oct 15, 2015 at 8:16 PM, Emilia K?sper wrote: > This sounds like an application problem. > 1) Did you recompile your source? 0.9.7 and 1.0.1 are not > binary-compatible. > 2) The certificate hash format has changed between 1.0.1 and 0.9.7, which > could > explain why the lookup no longer works: > https://www.openssl.org/docs/manmaster/apps/rehash.html > > If the above isn't helpful, try asking for help on openssl-users at . > Rejecting > the ticket (though please reopen if you find new evidence that this is a > bug > within OpenSSL). > > Cheers, > Emilia > > From rt at openssl.org Fri Oct 16 09:50:48 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 16 Oct 2015 09:50:48 +0000 Subject: [openssl-dev] [openssl.org #4093] Problem loading engine from config In-Reply-To: References: Message-ID: On Wed Oct 14 19:29:42 2015, beldmit at gmail.com wrote: > Hello! > > The attached patch fixes it. Patch applied. Thanks! Matt From hkario at redhat.com Fri Oct 16 09:51:36 2015 From: hkario at redhat.com (Hubert Kario) Date: Fri, 16 Oct 2015 11:51:36 +0200 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <5620BB8D.5030008@openssl.org> References: <5620BB8D.5030008@openssl.org> Message-ID: <2894147.0VZZ3gkRdG@pintsize.usersys.redhat.com> On Friday 16 October 2015 09:55:41 Matt Caswell wrote: > On 16/10/15 09:53, Matt Caswell via RT wrote: > > On 13/10/15 12:31, Hubert Kario via RT wrote: > >> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: > >>> On 12/10/15 17:19, Matt Caswell via RT wrote: > >>>> On 12/10/15 16:39, Matt Caswell via RT wrote: > >>>>> The value of "in_read_app_data" not being true when it is > >>>>> supposed > >>>>> to > >>>>> appears to be running into a slightly different bug. It's also > >>>>> present in 1.0.2 but you have to switch off version negotiation. > >>>>> So running s_server like this in 1.0.2 and rerunning Hubert's > >>>>> test > >>>>> will hit it: > >>>>> > >>>>> openssl s_server -www -tls1_2 > >>>>> > >>>>> The 1.0.2 version negotiation is hiding the issue. In master > >>>>> version neg has been completely rewritten and simplified - but > >>>>> in > >>>>> doing so no longer hides the problem. :-( > >>>> > >>>> Having done some more digging it seems the problem only occurs if > >>>> you > >>>> get the initial handshake, following by a second reneg handshake > >>>> *and* interleaved app data all within the scope of a *single* > >>>> SSL_read call. AFAICT if SSL_read returns between the first > >>>> handshake and the second, you don't get the problem. > >>> > >>> Ok, updated version of the patch attached. This is for 1.0.2 but > >>> should pass Hubert's tests even when you run s_server with > >>> "-tls1_2". > >> > >> yup, looks good with -tls1_2 now too > >> > >> for some reason my side can't negotiate TLS 1.1 or TLS 1.0 > >> correctly so can't test -tls1_1 or -tls1 (I'm likely generating > >> malformed CKE there, but need to check to be sure) > > > > I raised the ambiguity in the spec about when in the handshake > > interleaved app data is allowed with the TLS WG. You can see the > > thread here: > > https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017 > > > > I got a few responses, not all of which were consistent, and giving > > different views. To summarise what I interpret as the main points: > > > > 1) Where a view was given it seemed to concur with the views > > expressed here that the most sensible interpretation of the spec > > wording is that interleaved app data is allowed up until the CCS, > > but not between CCS and Finished. > > 2) There was also a view expressed that, regardless of what the spec > > says, allowing interleaved app data is *dangerous*! > > 3) There seemed to be differing views on just how dangerous ranging > > from it being "a highly dangerous idea" to "...there is a need for > > caution, but in reality, it's not like you can use renegotiation to > > hand-off to someone else entirely. The person you are talking to > > hasn't changed. What is dangerous is making assertions about *new* > > things that the renegotiation introduces", although the same person > > who made that last observation also provided a list of very onerous > > mitigations that we should put in place if were to do it (none of > > which are likely to be adopted IMO without some form of official > > advice from the TLS WG). > > > > So now I really don't know what the "right" way forward is. Should > > we be applying the patch or not? > > I should add that another interesting point was that BoringSSL > prohibits interleaved app data. just like OpenSSL now :) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Fri Oct 16 09:56:15 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 16 Oct 2015 09:56:15 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <1562949.zVfMrxuZIc@pintsize.usersys.redhat.com> References: <5620BAF0.3020909@openssl.org> <1562949.zVfMrxuZIc@pintsize.usersys.redhat.com> Message-ID: On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote: > On 13/10/15 12:31, Hubert Kario via RT wrote: > > On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: > >> On 12/10/15 17:19, Matt Caswell via RT wrote: > >>> On 12/10/15 16:39, Matt Caswell via RT wrote: > >>>> The value of "in_read_app_data" not being true when it is > >>>> supposed > >>>> to > >>>> appears to be running into a slightly different bug. It's also > >>>> present in 1.0.2 but you have to switch off version negotiation. > >>>> So running s_server like this in 1.0.2 and rerunning Hubert's > >>>> test > >>>> will hit it: > >>>> > >>>> openssl s_server -www -tls1_2 > >>>> > >>>> The 1.0.2 version negotiation is hiding the issue. In master > >>>> version neg has been completely rewritten and simplified - but in > >>>> doing so no longer hides the problem. :-( > >>> > >>> Having done some more digging it seems the problem only occurs if > >>> you > >>> get the initial handshake, following by a second reneg handshake > >>> *and* interleaved app data all within the scope of a *single* > >>> SSL_read call. AFAICT if SSL_read returns between the first > >>> handshake and the second, you don't get the problem. > >> > >> Ok, updated version of the patch attached. This is for 1.0.2 but > >> should pass Hubert's tests even when you run s_server with > >> "-tls1_2". > > > > yup, looks good with -tls1_2 now too > > > > for some reason my side can't negotiate TLS 1.1 or TLS 1.0 correctly > > so can't test -tls1_1 or -tls1 (I'm likely generating malformed CKE > > there, but need to check to be sure) > > I raised the ambiguity in the spec about when in the handshake > interleaved app data is allowed with the TLS WG. You can see the > thread here: > https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017 > > I got a few responses, not all of which were consistent, and giving > different views. To summarise what I interpret as the main points: > > 1) Where a view was given it seemed to concur with the views expressed > here that the most sensible interpretation of the spec wording is > that interleaved app data is allowed up until the CCS, but not > between CCS and Finished. > 2) There was also a view expressed that, regardless of what the spec > says, allowing interleaved app data is *dangerous*! > 3) There seemed to be differing views on just how dangerous ranging > from it being "a highly dangerous idea" to "...there is a need for > caution, but in reality, it's not like you can use renegotiation to > hand-off to someone else entirely. The person you are talking to > hasn't changed. What is dangerous is making assertions about *new* > things that the renegotiation introduces", although the same person > who made that last observation also provided a list of very onerous > mitigations that we should put in place if were to do it (none of > which are likely to be adopted IMO without some form of official > advice from the TLS WG). > > So now I really don't know what the "right" way forward is. Should we > be applying the patch or not? I can't think of a way to exploit it if two assumptions hold: 1). we have secure renegotiation 2). API calls return metadata (certificates especially) from *active* context, not one currently negotiated -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Oct 16 09:56:31 2015 From: rt at openssl.org (tosif tamboli via RT) Date: Fri, 16 Oct 2015 09:56:31 +0000 Subject: [openssl-dev] [openssl.org #4095] X509_STORE_get_by_subject crash In-Reply-To: References: Message-ID: My application is written for vxWorks OS and openssl and vxWorks are part of the binary that I need to verify On Fri, Oct 16, 2015 at 3:13 PM, tosif tamboli wrote: > Hi, > > below is my application code > sshX509CACertStore = X509_STORE_new(); > > X509_STORE_set_verify_cb_func(sshX509CACertStore, > sshX509CertVerifyCallback); > pLookup = X509_STORE_add_lookup(sshX509CACertStore, > X509_LOOKUP_file()); > X509_LOOKUP_load_file(pLookup,caFile,X509_FILETYPE_PEM) > > X509_STORE_CTX_init (pStoreCtx, sshX509CACertStore, pX509, NULL); > > ret = X509_verify_cert (pStoreCtx); > > in the callback function I just checked for > retVal = X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, > pSubject, &x509_obj); > > retVal = X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, > pIssuer, &x509_obj); > > older openssl used md5 hash and newer doesn't seem to use it > As you mentioned about c_rehash. How should I create new symlink in code. > My application is to verify the certificate and signature in image > > It will be helpful if you can provide your inputs for crash of above > application at > X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, > pIssuer, &x509_obj); > > Thanks & regards, > Tosif > > > On Thu, Oct 15, 2015 at 8:16 PM, Emilia K?sper wrote: > >> This sounds like an application problem. >> 1) Did you recompile your source? 0.9.7 and 1.0.1 are not >> binary-compatible. >> 2) The certificate hash format has changed between 1.0.1 and 0.9.7, which >> could >> explain why the lookup no longer works: >> https://www.openssl.org/docs/manmaster/apps/rehash.html >> >> If the above isn't helpful, try asking for help on openssl-users at . >> Rejecting >> the ticket (though please reopen if you find new evidence that this is a >> bug >> within OpenSSL). >> >> Cheers, >> Emilia >> >> > From rt at openssl.org Fri Oct 16 10:57:22 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Fri, 16 Oct 2015 10:57:22 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <20151016105308.GA30639@roeckx.be> References: <561CCD67.3000603@openssl.org> <3519008.VAreeqH2KA@pintsize.usersys.redhat.com> <5620BAF0.3020909@openssl.org> <20151016105308.GA30639@roeckx.be> Message-ID: On Fri, Oct 16, 2015 at 08:53:06AM +0000, Matt Caswell via RT wrote: > > So now I really don't know what the "right" way forward is. Should we be > applying the patch or not? Has anybody contact Oracle about this issue? It seems useful that they fix it on their end, regardless of what we do. Kurt From rt at openssl.org Fri Oct 16 11:00:09 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 16 Oct 2015 11:00:09 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <5620D892.50203@openssl.org> References: <561CCD67.3000603@openssl.org> <3519008.VAreeqH2KA@pintsize.usersys.redhat.com> <5620BAF0.3020909@openssl.org> <20151016105308.GA30639@roeckx.be> <5620D892.50203@openssl.org> Message-ID: On 16/10/15 11:57, Kurt Roeckx via RT wrote: > On Fri, Oct 16, 2015 at 08:53:06AM +0000, Matt Caswell via RT wrote: >> >> So now I really don't know what the "right" way forward is. Should we be >> applying the patch or not? > > Has anybody contact Oracle about this issue? It seems useful that > they fix it on their end, regardless of what we do. No, but according to the spec they are doing it right - nothing to fix. That's part of the problem: the spec says one thing but the advice we are getting from TLS WG says something slightly different. Matt From laurenz.albe at wien.gv.at Fri Oct 16 11:01:17 2015 From: laurenz.albe at wien.gv.at (Albe Laurenz) Date: Fri, 16 Oct 2015 11:01:17 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <5620BAF0.3020909@openssl.org> <1562949.zVfMrxuZIc@pintsize.usersys.redhat.com> Message-ID: Hubert Kario wrote: > On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote: >> I raised the ambiguity in the spec about when in the handshake >> interleaved app data is allowed with the TLS WG. You can see the >> thread here: >> https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017 >> >> I got a few responses, not all of which were consistent, and giving >> different views. To summarise what I interpret as the main points: >> >> 1) Where a view was given it seemed to concur with the views expressed >> here that the most sensible interpretation of the spec wording is >> that interleaved app data is allowed up until the CCS, but not >> between CCS and Finished. >> 2) There was also a view expressed that, regardless of what the spec >> says, allowing interleaved app data is *dangerous*! >> 3) There seemed to be differing views on just how dangerous ranging >> from it being "a highly dangerous idea" to "...there is a need for >> caution, but in reality, it's not like you can use renegotiation to >> hand-off to someone else entirely. The person you are talking to >> hasn't changed. What is dangerous is making assertions about *new* >> things that the renegotiation introduces", although the same person >> who made that last observation also provided a list of very onerous >> mitigations that we should put in place if were to do it (none of >> which are likely to be adopted IMO without some form of official >> advice from the TLS WG). >> >> So now I really don't know what the "right" way forward is. Should we >> be applying the patch or not? > > I can't think of a way to exploit it if two assumptions hold: > 1). we have secure renegotiation > 2). API calls return metadata (certificates especially) from *active* > context, not one currently negotiated I tend to agree. But isn't point 2) exactly what Matt calls a "very onerous mitigation"? Reading the replies Matt got from the TLS WG I got the impression that they go "yuck" when they hear the word "renegotiation", but that's hardly an option if you want to implement a RFC that says otherwise. Being the one who reported the problem, I am not impartial as to whether the patch should go in or not. Would it be an option to have the patch as it is, and if it is too hard to have all API calls return data pertaining to the old context, have them throw an error in that case? That would keep things on the safe side and improve interoperability. Yours, Laurenz Albe From rt at openssl.org Fri Oct 16 11:01:27 2015 From: rt at openssl.org (Albe Laurenz via RT) Date: Fri, 16 Oct 2015 11:01:27 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <5620BAF0.3020909@openssl.org> <1562949.zVfMrxuZIc@pintsize.usersys.redhat.com> Message-ID: Hubert Kario wrote: > On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote: >> I raised the ambiguity in the spec about when in the handshake >> interleaved app data is allowed with the TLS WG. You can see the >> thread here: >> https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017 >> >> I got a few responses, not all of which were consistent, and giving >> different views. To summarise what I interpret as the main points: >> >> 1) Where a view was given it seemed to concur with the views expressed >> here that the most sensible interpretation of the spec wording is >> that interleaved app data is allowed up until the CCS, but not >> between CCS and Finished. >> 2) There was also a view expressed that, regardless of what the spec >> says, allowing interleaved app data is *dangerous*! >> 3) There seemed to be differing views on just how dangerous ranging >> from it being "a highly dangerous idea" to "...there is a need for >> caution, but in reality, it's not like you can use renegotiation to >> hand-off to someone else entirely. The person you are talking to >> hasn't changed. What is dangerous is making assertions about *new* >> things that the renegotiation introduces", although the same person >> who made that last observation also provided a list of very onerous >> mitigations that we should put in place if were to do it (none of >> which are likely to be adopted IMO without some form of official >> advice from the TLS WG). >> >> So now I really don't know what the "right" way forward is. Should we >> be applying the patch or not? > > I can't think of a way to exploit it if two assumptions hold: > 1). we have secure renegotiation > 2). API calls return metadata (certificates especially) from *active* > context, not one currently negotiated I tend to agree. But isn't point 2) exactly what Matt calls a "very onerous mitigation"? Reading the replies Matt got from the TLS WG I got the impression that they go "yuck" when they hear the word "renegotiation", but that's hardly an option if you want to implement a RFC that says otherwise. Being the one who reported the problem, I am not impartial as to whether the patch should go in or not. Would it be an option to have the patch as it is, and if it is too hard to have all API calls return data pertaining to the old context, have them throw an error in that case? That would keep things on the safe side and improve interoperability. Yours, Laurenz Albe From rt at openssl.org Fri Oct 16 11:04:30 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Fri, 16 Oct 2015 11:04:30 +0000 Subject: [openssl-dev] [openssl.org #3645] openssl-1.0.1h-cmp - Linking issue In-Reply-To: References: Message-ID: Thanks Martin. (Re-closing the ticket.) From rt at openssl.org Fri Oct 16 13:52:14 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 16 Oct 2015 13:52:14 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <56210109.20208@openssl.org> References: <5620BAF0.3020909@openssl.org> <1562949.zVfMrxuZIc@pintsize.usersys.redhat.com> <56210109.20208@openssl.org> Message-ID: On 16/10/15 10:56, Hubert Kario via RT wrote: > On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote: >> So now I really don't know what the "right" way forward is. Should we >> be applying the patch or not? > > I can't think of a way to exploit it if two assumptions hold: > 1). we have secure renegotiation > 2). API calls return metadata (certificates especially) from *active* > context, not one currently negotiated But here is where we come unstuck I think. I've given this some thought and I think there is an exploit if we were to apply the patch as is. Consider a reneg where the server has requested a client certificate. The client responds with a valid certificate and chain....but where they do not possess the private key, i.e. they are attempting to impersonate someone else. The client sends the Certificate message and the server extracts it and verifies it successfully. On the server side the Certificate message is processed via the function "ssl3_get_client_certificate()". At the end of this function there are these two lines of code: s->session->peer = sk_X509_shift(sk); s->session->verify_result = s->verify_result; |s->session->peer| stores the newly received Certificate away for future use. Note that at this point the result of the verification (which is successful) is stored in both |s->session->verify_result| and |s->verify_result|. Now, before sending the CertificateVerify message, the client sends application data. Maybe that application data causes the application to try to do something privileged that only authorised users are allowed to do, so the application calls SSL_get_peer_certificate(): X509 *SSL_get_peer_certificate(const SSL *s) { X509 *r; if ((s == NULL) || (s->session == NULL)) r = NULL; else r = s->session->peer; if (r == NULL) return (r); X509_up_ref(r); return (r); } And SSL_get_verify_result(): long SSL_get_verify_result(const SSL *ssl) { return (ssl->verify_result); } So these API calls will return the *new* certificate and verification result *before* a CertificateVerify has been received. Fixing this sort of problem is going to be *hard* and probably require quite a lot of non-trivial changes - definitely not the sort of the thing I want to be doing in a stable branch. Fixing this is an example of what I meant by "onerous mitigations", but I now realise it is absolutely necessary if we wanted to pursue this. I think we should be marking this as a "won't fix" for all released versions. The question is whether we should even attempt to fix it for 1.1.0 or not. Matt From rt at openssl.org Fri Oct 16 15:05:37 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Fri, 16 Oct 2015 15:05:37 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> Message-ID: On Friday 16 October 2015 13:52:14 Matt Caswell via RT wrote: > On 16/10/15 10:56, Hubert Kario via RT wrote: > > On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote: > >> So now I really don't know what the "right" way forward is. Should > >> we > >> be applying the patch or not? > > > > I can't think of a way to exploit it if two assumptions hold: > > 1). we have secure renegotiation > > 2). API calls return metadata (certificates especially) from > > *active* > > context, not one currently negotiated > > So these API calls will return the *new* certificate and verification > result *before* a CertificateVerify has been received. > > Fixing this sort of problem is going to be *hard* and probably require > quite a lot of non-trivial changes - definitely not the sort of the > thing I want to be doing in a stable branch. Fixing this is an > example of what I meant by "onerous mitigations", but I now realise > it is absolutely necessary if we wanted to pursue this. > > I think we should be marking this as a "won't fix" for all released > versions. The question is whether we should even attempt to fix it for > 1.1.0 or not. we may actually be able to patch this up partially in 1.0.x the original problem description mentions server being unable to process application data before Certificate/Client Key Exchange, not in any place what so ever (Albe, please double check if you didn't saw Java sending app data at any different point) unless the server is completely asynchronous, it's unlikely it will send application data messages between handshake messages from a single flight, it will send app data only between different flights in other words, we should still be able to accept this data before the client responses had any chance to modify the certificates in the server. of course, that doesn't allow us to fix it for the other side of connection - where the application data is sent by server after Server Hello Done and before server Change Cipher Spec -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Oct 16 15:22:49 2015 From: rt at openssl.org (jeremy.compostella@intel.com via RT) Date: Fri, 16 Oct 2015 15:22:49 +0000 Subject: [openssl-dev] [openssl.org #4096] apps/req.c: support start_days_before option for x509 In-Reply-To: <87r3kuev9o.fsf@jcompost-MOBL1.tl.intel.com> References: <87r3kuev9o.fsf@jcompost-MOBL1.tl.intel.com> Message-ID: Hi, I'm using the openssl command to generate test certificates and I'm running into an annoying "not valid yet" certificate issue. I cannot set the notbefore field using the openssl command. I've made a patch (see attachment) that add the support of a "-start-days-before' option which is symmetric to the "-days" option. Patch commit message: "Sometimes the generated X509 certificate notbefore date must be in the past. For instance, if this certificate is going to be included in a device that might get its clock reset to its default time value, the included certificate notbefore field must match (or be prior) its default date value which might be in the past. This patch adds the support of a -start-days-before option which is symmetric to the -days option. " I'm not sure this is the best approach but having a -notbefore option taking a date string would require date parsing support which is not easy across platforms. I think that this totally symmetric to "-days" option is simple enough and should cover most of the use case. What do you think ? Cheers, J?r?my -- One Emacs to rule them all -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-apps-req.c-support-start_days_before-option-for-x509.patch Type: text/x-diff Size: 2861 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Fri Oct 16 16:09:57 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Fri, 16 Oct 2015 16:09:57 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <56212150.7050306@akamai.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620023B.1000200@openwall.com> <5620B61D.3050200@openssl.org> <56212150.7050306@akamai.com> Message-ID: On 10/16/2015 03:32 AM, Matt Caswell via RT wrote: > > On 15/10/15 20:53, Alexander Cherepanov via RT wrote: >> What was not entirely clear from the original bug report is that, while >> the check is not compiled away, it's compiled into something completely >> different from what is written in the source. Specifically, the check >> "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. >> "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for >> overflow at all, it doesn't even depend on the value of "buf". >> >> If this is what was intended then it's better to write it explicitly. If >> this is not what was intended then some other approach is required. > I'd say that is an instance of the compiler knowing better than us how > big |len| would have to be in order to trigger an overflow. Those rules > are going to be platform specific so we should not attempt to second > guess them, but instead let the optimiser do its job. > I hope I am not dragging this thread on too long, but with all due respect, we are not asking the compiler/optimizer to detect overflow -- we are asking the compiler to instantiate undefined behavior in a way that is convenient for us. This will only happen by chance, as a side effect of some other decisions made by the compiler authors, in the present state of compiler development. -Ben P.S. If you haven't encountered it yet, http://blog.regehr.org/archives/213 et. seq. make for fun reading. From openssl-users at dukhovni.org Fri Oct 16 16:32:09 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 16 Oct 2015 16:32:09 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620023B.1000200@openwall.com> <5620B61D.3050200@openssl.org> <56212150.7050306@akamai.com> Message-ID: <20151016163209.GX15070@mournblade.imrryr.org> On Fri, Oct 16, 2015 at 04:09:57PM +0000, Kaduk, Ben via RT wrote: > I hope I am not dragging this thread on too long, but with all due > respect, we are not asking the compiler/optimizer to detect overflow -- > we are asking the compiler to instantiate undefined behavior in a way > that is convenient for us. This will only happen by chance, as a side > effect of some other decisions made by the compiler authors, in the > present state of compiler development. My take is that we should generally stay clear of relying on any remotely sensible outcome for undefined behaviour. If this thread is about such a situation, then we may have to code around the issue. -- Viktor. From rt at openssl.org Fri Oct 16 16:50:59 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 16 Oct 2015 16:50:59 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <56212AF1.5020502@openssl.org> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620B61D.3050200@openssl.org> <56212150.7050306@akamai.com> <20151016163209.GX15070@mournblade.imrryr.org> <56212AF1.5020502@openssl.org> Message-ID: On 16/10/15 17:32, Viktor Dukhovni wrote: > On Fri, Oct 16, 2015 at 04:09:57PM +0000, Kaduk, Ben via RT wrote: > >> I hope I am not dragging this thread on too long, but with all due >> respect, we are not asking the compiler/optimizer to detect overflow -- >> we are asking the compiler to instantiate undefined behavior in a way >> that is convenient for us. This will only happen by chance, as a side >> effect of some other decisions made by the compiler authors, in the >> present state of compiler development. > > My take is that we should generally stay clear of relying on any > remotely sensible outcome for undefined behaviour. If this thread > is about such a situation, then we may have to code around the > issue. > We are *not* relying on that. Or at least we are only to the extent that we are talking about a scenario where something has gone wrong already and undefined behaviour is inevitable. We are hoping that our undefined behaviour is likely to be slightly less bad than the undefined behaviour that we would get otherwise. We cannot know that it will be...but in reality there is a reasonable chance that it will. In a well-behaved program there is no undefined behaviour. The "buf + len < buf" check will always evaluate to false, so in that sense is useless but it *is* well defined. In a non well-behaved program if we remove the check then undefined behaviour is almost certainly inevitable. Who don't know what it will do (it could do anything), but there is a reasonable chance that it could result in the disclosure or use of memory it shouldn't be touching. A CVE is quite a possible result of such undefined behaviour. In a non well-behaved program if we keep the check then we still have undefined behaviour. The check could do what we kind of expect that it might, it might do nothing at all, or it could do something entirely different. But without the check undefined behaviour is inevitable anyway, so in that sense we are no better off one way or the other. In reality however we have a reasonable hope that the check will do something like what we hope it might, in which case we will prevent a possible security issue. That said the packettest test where we deliberately use -1 for a len, is actually deliberately relying on undefined behaviour so perhaps should be changed. It may also be reasonable to add an additional max length check. Matt From kurt at roeckx.be Fri Oct 16 18:50:48 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 16 Oct 2015 20:50:48 +0200 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620B61D.3050200@openssl.org> <56212150.7050306@akamai.com> <20151016163209.GX15070@mournblade.imrryr.org> <56212AF1.5020502@openssl.org> Message-ID: <20151016185047.GA3924@roeckx.be> On Fri, Oct 16, 2015 at 04:50:59PM +0000, Matt Caswell via RT wrote: > In a well-behaved program there is no undefined behaviour. The "buf + > len < buf" check will always evaluate to false, so in that sense is > useless but it *is* well defined. The defined behaviour for the "buf + len" part is as far as I know that you're that the pointer should point inside the allocated object or 1 byte after it. So as long as "len" is in the valid range, the "buf + len" part should be well defined. The test with -1 is clearly undefined. As far as I know in the comparison pointers they should point to the same object. But the check seems to imply that they might not point to the same object or that buf is not the base of the object. But since len is unsigned only the option that they don't point to the same object seems to be left. So it's unclear to me if this is defined behaviour or not. Kurt From rt at openssl.org Fri Oct 16 18:50:36 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Fri, 16 Oct 2015 18:50:36 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <20151016185047.GA3924@roeckx.be> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <56212150.7050306@akamai.com> <20151016163209.GX15070@mournblade.imrryr.org> <56212AF1.5020502@openssl.org> <20151016185047.GA3924@roeckx.be> Message-ID: On Fri, Oct 16, 2015 at 04:50:59PM +0000, Matt Caswell via RT wrote: > In a well-behaved program there is no undefined behaviour. The "buf + > len < buf" check will always evaluate to false, so in that sense is > useless but it *is* well defined. The defined behaviour for the "buf + len" part is as far as I know that you're that the pointer should point inside the allocated object or 1 byte after it. So as long as "len" is in the valid range, the "buf + len" part should be well defined. The test with -1 is clearly undefined. As far as I know in the comparison pointers they should point to the same object. But the check seems to imply that they might not point to the same object or that buf is not the base of the object. But since len is unsigned only the option that they don't point to the same object seems to be left. So it's unclear to me if this is defined behaviour or not. Kurt From rt at openssl.org Fri Oct 16 20:42:17 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Fri, 16 Oct 2015 20:42:17 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <56216122.2010503@akamai.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <56212150.7050306@akamai.com> <20151016163209.GX15070@mournblade.imrryr.org> <56212AF1.5020502@openssl.org> <56216122.2010503@akamai.com> Message-ID: On 10/16/2015 11:50 AM, Matt Caswell via RT wrote: > > On 16/10/15 17:32, Viktor Dukhovni wrote: >> My take is that we should generally stay clear of relying on any >> remotely sensible outcome for undefined behaviour. If this thread >> is about such a situation, then we may have to code around the >> issue. >> > We are *not* relying on that. Or at least we are only to the extent that > we are talking about a scenario where something has gone wrong already > and undefined behaviour is inevitable. We are hoping that our undefined > behaviour is likely to be slightly less bad than the undefined behaviour > that we would get otherwise. We cannot know that it will be...but in > reality there is a reasonable chance that it will. > > In a well-behaved program there is no undefined behaviour. The "buf + > len < buf" check will always evaluate to false, so in that sense is > useless but it *is* well defined. > > In a non well-behaved program if we remove the check then undefined > behaviour is almost certainly inevitable. Who don't know what it will do > (it could do anything), but there is a reasonable chance that it could > result in the disclosure or use of memory it shouldn't be touching. A > CVE is quite a possible result of such undefined behaviour. > > In a non well-behaved program if we keep the check then we still have > undefined behaviour. The check could do what we kind of expect that it > might, it might do nothing at all, or it could do something entirely > different. But without the check undefined behaviour is inevitable > anyway, so in that sense we are no better off one way or the other. In > reality however we have a reasonable hope that the check will do > something like what we hope it might, in which case we will prevent a > possible security issue. I think we can have a check in the function that blocks (most of) the cases we are worried about encountering undefined behavior for, without actually involving undefined behavior, which at least resembles the best of both worlds. Does anyone object to changing the sanity check to be comparing len against (size_1)-1? Alternately, checking the range (size_t)-255 to (size_t)-1? My personal preference would be to make the function return void and have this sanity check be an assert() or explicit abort(), but I would not object to the above given your preference to retain a sanity check. > That said the packettest test where we deliberately use -1 for a len, is > actually deliberately relying on undefined behaviour so perhaps should > be changed. It may also be reasonable to add an additional max length check. > It would not rely on undefined behavior with my proposal above. Of course, a max length check would supersede my proposal; however, I think that the PACKET structure may well eventually be used for processing things other than TLS wire protocol packets, so I would suggest a limit at least somewhat higher than 2^14+2048. -Ben From rt at openssl.org Fri Oct 16 21:35:23 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Fri, 16 Oct 2015 21:35:23 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <20151016213536.GA6365@roeckx.be> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <20151016163209.GX15070@mournblade.imrryr.org> <56212AF1.5020502@openssl.org> <20151016185047.GA3924@roeckx.be> <20151016213536.GA6365@roeckx.be> Message-ID: On Fri, Oct 16, 2015 at 06:50:36PM +0000, Kurt Roeckx via RT wrote: > On Fri, Oct 16, 2015 at 04:50:59PM +0000, Matt Caswell via RT wrote: > > In a well-behaved program there is no undefined behaviour. The "buf + > > len < buf" check will always evaluate to false, so in that sense is > > useless but it *is* well defined. > > The defined behaviour for the "buf + len" part is as far as I know > that you're that the pointer should point inside the allocated > object or 1 byte after it. So as long as "len" is in the valid > range, the "buf + len" part should be well defined. The test with > -1 is clearly undefined. > > As far as I know in the comparison pointers they should point > to the same object. But the check seems to imply that they might > not point to the same object or that buf is not the base of the > object. But since len is unsigned only the option that they don't > point to the same object seems to be left. > > So it's unclear to me if this is defined behaviour or not. So thinking about this some more, it seems to be a check for undefined behaviour that probably itself is still defined. That probably also means the compiler can assume that it's always false and eliminate the check, it's probably just not smart enough yet. Kurt From rt at openssl.org Fri Oct 16 21:44:22 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Fri, 16 Oct 2015 21:44:22 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <56216FB1.6070405@akamai.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <20151016185047.GA3924@roeckx.be> <20151016213536.GA6365@roeckx.be> <56216FB1.6070405@akamai.com> Message-ID: On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote: > On Fri, Oct 16, 2015 at 06:50:36PM +0000, Kurt Roeckx via RT wrote: >> On Fri, Oct 16, 2015 at 04:50:59PM +0000, Matt Caswell via RT wrote: >>> In a well-behaved program there is no undefined behaviour. The "buf + >>> len < buf" check will always evaluate to false, so in that sense is >>> useless but it *is* well defined. >> The defined behaviour for the "buf + len" part is as far as I know >> that you're that the pointer should point inside the allocated >> object or 1 byte after it. So as long as "len" is in the valid >> range, the "buf + len" part should be well defined. The test with >> -1 is clearly undefined. >> >> As far as I know in the comparison pointers they should point >> to the same object. But the check seems to imply that they might >> not point to the same object or that buf is not the base of the >> object. But since len is unsigned only the option that they don't >> point to the same object seems to be left. >> >> So it's unclear to me if this is defined behaviour or not. > So thinking about this some more, it seems to be a check for > undefined behaviour that probably itself is still defined. > > That probably also means the compiler can assume that it's always > false and eliminate the check, it's probably just not smart enough > yet. > I think it is unambiguous that there are values of unsigned char *buf and size_t len for which evaluating (bug + len < buf) invokes undefined behavior -- the sheer act of performing the addition buf + len can produce undefined behavior, even before any comparison. I am as-yet uncertain whether the case when buf points into the middle of an object and len is (size_t)-1 invokes undefined behavior, but I am inclined to believe that it is also undefined behavior. -Ben From ben at links.org Fri Oct 16 22:45:52 2015 From: ben at links.org (Ben Laurie) Date: Fri, 16 Oct 2015 22:45:52 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620023B.1000200@openwall.com> <5620B61D.3050200@openssl.org> Message-ID: On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RT wrote: > > > On 15/10/15 20:53, Alexander Cherepanov via RT wrote: > > On 2015-10-15 15:41, Matt Caswell via RT wrote: > >> The purpose of the sanity check is not then for security, but to guard > >> against programmer error. For a correctly functioning program this test > >> should never fail. For an incorrectly functioning program it may do. It > >> is not guaranteed to fail because the test could be compiled away but, > >> most likely, it will. We can have some degree of confidence that the > >> test works and does not get compiled away in most instances because, as > >> you point out, an explicit check for it appears in packettest.c and, to > >> date, we have had no reported failures. > > > > What was not entirely clear from the original bug report is that, while > > the check is not compiled away, it's compiled into something completely > > different from what is written in the source. Specifically, the check > > "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. > > "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for > > overflow at all, it doesn't even depend on the value of "buf". > > > > If this is what was intended then it's better to write it explicitly. If > > this is not what was intended then some other approach is required. > > I'd say that is an instance of the compiler knowing better than us how > big |len| would have to be in order to trigger an overflow. Those rules > are going to be platform specific so we should not attempt to second > guess them, but instead let the optimiser do its job. > If it is, then the compiler is wrong, surely? e.g. if buf is 0xfff...fff, and len is 1, you get an overflow, which the optimised version does not catch. What I'm not understanding from this thread is what the argument is against avoiding undefined behaviour? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Oct 16 22:46:16 2015 From: rt at openssl.org (Ben Laurie via RT) Date: Fri, 16 Oct 2015 22:46:16 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620023B.1000200@openwall.com> <5620B61D.3050200@openssl.org> Message-ID: On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RT wrote: > > > On 15/10/15 20:53, Alexander Cherepanov via RT wrote: > > On 2015-10-15 15:41, Matt Caswell via RT wrote: > >> The purpose of the sanity check is not then for security, but to guard > >> against programmer error. For a correctly functioning program this test > >> should never fail. For an incorrectly functioning program it may do. It > >> is not guaranteed to fail because the test could be compiled away but, > >> most likely, it will. We can have some degree of confidence that the > >> test works and does not get compiled away in most instances because, as > >> you point out, an explicit check for it appears in packettest.c and, to > >> date, we have had no reported failures. > > > > What was not entirely clear from the original bug report is that, while > > the check is not compiled away, it's compiled into something completely > > different from what is written in the source. Specifically, the check > > "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. > > "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for > > overflow at all, it doesn't even depend on the value of "buf". > > > > If this is what was intended then it's better to write it explicitly. If > > this is not what was intended then some other approach is required. > > I'd say that is an instance of the compiler knowing better than us how > big |len| would have to be in order to trigger an overflow. Those rules > are going to be platform specific so we should not attempt to second > guess them, but instead let the optimiser do its job. > If it is, then the compiler is wrong, surely? e.g. if buf is 0xfff...fff, and len is 1, you get an overflow, which the optimised version does not catch. What I'm not understanding from this thread is what the argument is against avoiding undefined behaviour? From rt at openssl.org Sat Oct 17 02:32:40 2015 From: rt at openssl.org (Alexander Cherepanov via RT) Date: Sat, 17 Oct 2015 02:32:40 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <5621B33D.3090301@openwall.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620B61D.3050200@openssl.org> <5621B33D.3090301@openwall.com> Message-ID: On 2015-10-17 01:46, Ben Laurie via RT wrote: > On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RT wrote: >> On 15/10/15 20:53, Alexander Cherepanov via RT wrote: >>> On 2015-10-15 15:41, Matt Caswell via RT wrote: >>>> The purpose of the sanity check is not then for security, but to guard >>>> against programmer error. For a correctly functioning program this test >>>> should never fail. For an incorrectly functioning program it may do. It >>>> is not guaranteed to fail because the test could be compiled away but, >>>> most likely, it will. We can have some degree of confidence that the >>>> test works and does not get compiled away in most instances because, as >>>> you point out, an explicit check for it appears in packettest.c and, to >>>> date, we have had no reported failures. >>> >>> What was not entirely clear from the original bug report is that, while >>> the check is not compiled away, it's compiled into something completely >>> different from what is written in the source. Specifically, the check >>> "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. >>> "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for >>> overflow at all, it doesn't even depend on the value of "buf". >>> >>> If this is what was intended then it's better to write it explicitly. If >>> this is not what was intended then some other approach is required. >> >> I'd say that is an instance of the compiler knowing better than us how >> big |len| would have to be in order to trigger an overflow. Those rules >> are going to be platform specific so we should not attempt to second >> guess them, but instead let the optimiser do its job. Matt, I'm confused. In your previous email you yourself (correctly) explained why this check does not guard against the pointer overflowing. AIUI this check is not some clever trick, it's just ordinary simplification of "a + b < a" into "b < 0" by subtracting a common term from both sides (which is correct only if there is no overflow) with an additional twist that an unsigned integer are treated as signed. (IMHO this is a bug in compilers and I've just reported it in gcc -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999. But it doesn't really matter for our discussion.) On 2015-10-17 01:46, Ben Laurie via RT wrote: > If it is, then the compiler is wrong, surely? e.g. if buf is 0xfff...fff, > and len is 1, you get an overflow, which the optimised version does not > catch. Right. > What I'm not understanding from this thread is what the argument is against > avoiding undefined behaviour? I guess it's not clear what is the best way to fix it. You cannot check for a pointer overflow directly. There is no such notion in the C standards. Perhaps it's possible with casts to uintptr_t -- Alexander Cherepanov From rt at openssl.org Sat Oct 17 02:41:05 2015 From: rt at openssl.org (Alexander Cherepanov via RT) Date: Sat, 17 Oct 2015 02:41:05 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <5621B53F.2020408@openwall.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <5620B61D.3050200@openssl.org> <5621B53F.2020408@openwall.com> Message-ID: [Sorry, sent unfinished variant.] On 2015-10-17 01:46, Ben Laurie via RT wrote: > On Fri, 16 Oct 2015 at 01:32 Matt Caswell via RT wrote: >> On 15/10/15 20:53, Alexander Cherepanov via RT wrote: >>> On 2015-10-15 15:41, Matt Caswell via RT wrote: >>>> The purpose of the sanity check is not then for security, but to guard >>>> against programmer error. For a correctly functioning program this test >>>> should never fail. For an incorrectly functioning program it may do. It >>>> is not guaranteed to fail because the test could be compiled away but, >>>> most likely, it will. We can have some degree of confidence that the >>>> test works and does not get compiled away in most instances because, as >>>> you point out, an explicit check for it appears in packettest.c and, to >>>> date, we have had no reported failures. >>> >>> What was not entirely clear from the original bug report is that, while >>> the check is not compiled away, it's compiled into something completely >>> different from what is written in the source. Specifically, the check >>> "buf + len < buf" is optimized into "len >> 63" on 64-bit platform, i.e. >>> "(ssize_t)len < 0" or "len > SIZE_MAX / 2". This is not a check for >>> overflow at all, it doesn't even depend on the value of "buf". >>> >>> If this is what was intended then it's better to write it explicitly. If >>> this is not what was intended then some other approach is required. >> >> I'd say that is an instance of the compiler knowing better than us how >> big |len| would have to be in order to trigger an overflow. Those rules >> are going to be platform specific so we should not attempt to second >> guess them, but instead let the optimiser do its job. Matt, I'm confused. In your previous email you yourself (correctly) explained why this check does not guard against the pointer overflowing. AIUI this check is not some clever trick, it's just ordinary simplification of "a + b < a" into "b < 0" by subtracting a common term from both sides (which is correct only if there is no overflow) with an additional twist that an unsigned integer are treated as signed. (IMHO this is a bug in compilers and I've just reported it in gcc -- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67999. But it doesn't really matter for our discussion.) On 2015-10-17 01:46, Ben Laurie via RT wrote: > If it is, then the compiler is wrong, surely? e.g. if buf is 0xfff...fff, > and len is 1, you get an overflow, which the optimised version does not > catch. Right. > What I'm not understanding from this thread is what the argument is against > avoiding undefined behaviour? I guess the problem is that it's not entirely clear what this check is for at all. If it's there only to catch negative values it's easy to fix -- replace it with "len > SIZE_MAX /2", "len >> (sizeof len * 8 - 1)" or something. If the check is not needed at all it's easy to fix too:-) But if the intention was to specifically check for pointer overflow everything is a bit more complicated. You cannot check for a pointer overflow directly. There is no such notion in the C standards. Perhaps it's possible with casts to uintptr_t but it's kinda ugly. -- Alexander Cherepanov From rt at openssl.org Sat Oct 17 05:35:26 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sat, 17 Oct 2015 05:35:26 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <20151017053537.GA11200@roeckx.be> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <20151016213536.GA6365@roeckx.be> <56216FB1.6070405@akamai.com> <20151017053537.GA11200@roeckx.be> Message-ID: On Fri, Oct 16, 2015 at 09:44:22PM +0000, Kaduk, Ben via RT wrote: > On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote: > > On Fri, Oct 16, 2015 at 06:50:36PM +0000, Kurt Roeckx via RT wrote: > >> On Fri, Oct 16, 2015 at 04:50:59PM +0000, Matt Caswell via RT wrote: > >>> In a well-behaved program there is no undefined behaviour. The "buf + > >>> len < buf" check will always evaluate to false, so in that sense is > >>> useless but it *is* well defined. > >> The defined behaviour for the "buf + len" part is as far as I know > >> that you're that the pointer should point inside the allocated > >> object or 1 byte after it. So as long as "len" is in the valid > >> range, the "buf + len" part should be well defined. The test with > >> -1 is clearly undefined. > >> > >> As far as I know in the comparison pointers they should point > >> to the same object. But the check seems to imply that they might > >> not point to the same object or that buf is not the base of the > >> object. But since len is unsigned only the option that they don't > >> point to the same object seems to be left. > >> > >> So it's unclear to me if this is defined behaviour or not. > > So thinking about this some more, it seems to be a check for > > undefined behaviour that probably itself is still defined. > > > > That probably also means the compiler can assume that it's always > > false and eliminate the check, it's probably just not smart enough > > yet. > > > > I think it is unambiguous that there are values of unsigned char *buf > and size_t len for which evaluating (bug + len < buf) invokes undefined > behavior -- the sheer act of performing the addition buf + len can > produce undefined behavior, even before any comparison. I am as-yet > uncertain whether the case when buf points into the middle of an object > and len is (size_t)-1 invokes undefined behavior, but I am inclined to > believe that it is also undefined behavior. Just to clarify what I mean, buf + len can both have defined and undefined meaning, it depends on the value of len, so the compiler can probably not say anything about that part without knowing all the callers of that code. As long as it has a defined meaning the compiler will probably do it. buf + len < buf also seems to have a defined meaning, but in all defined meanings it's false, and so the compiler can just optimize that part away. Anyway, I would really like this to be changed. Kurt From openssl at roumenpetrov.info Sat Oct 17 19:45:40 2015 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Sat, 17 Oct 2015 22:45:40 +0300 Subject: [openssl-dev] OCSP issues in master 2015-10-17 Message-ID: <5622A564.3040908@roumenpetrov.info> Hello, After embed some attributes OCSP in master stop to work. The current status is the client comment report "Cert Status: unknown" and "Nonce Verify error" for X.509 certificates used in my ssh regression tests. The last known version to work is "47c9a1b5096be684c18335137284f0dfcefd12d6 : embed support for ASN1_STRING" (optionally with "Appease gcc's Wmaybe-uninitialized" if build fail due to pedantic compiler flags). First regression is from "af170194a88d6127d447bea826845c23ca192727 : embed OCSP_CERTID" - status is missing. Regards, Roumen Petrov From steve at openssl.org Sun Oct 18 02:41:39 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sun, 18 Oct 2015 02:41:39 +0000 Subject: [openssl-dev] OCSP issues in master 2015-10-17 In-Reply-To: <5622A564.3040908@roumenpetrov.info> References: <5622A564.3040908@roumenpetrov.info> Message-ID: <20151018024139.GA30084@openssl.org> On Sat, Oct 17, 2015, Roumen Petrov wrote: > Hello, > > After embed some attributes OCSP in master stop to work. > > The current status is the client comment report "Cert Status: > unknown" and "Nonce Verify error" for X.509 certificates used in my > ssh regression tests. > Try this patch: diff --git a/crypto/asn1/tasn_new.c b/crypto/asn1/tasn_new.c index 33a8e97..6a2ad62 100644 --- a/crypto/asn1/tasn_new.c +++ b/crypto/asn1/tasn_new.c @@ -352,6 +352,7 @@ static int asn1_primitive_new(ASN1_VALUE **pval, const ASN1_ITEM *it, if (embed) { str = *(ASN1_STRING **)pval; memset(str, 0, sizeof(*str)); + str->type = utype; str->flags = ASN1_STRING_FLAG_EMBED; } else { str = ASN1_STRING_type_new(utype); Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sun Oct 18 09:08:21 2015 From: rt at openssl.org (Manish Goregaokar via RT) Date: Sun, 18 Oct 2015 09:08:21 +0000 Subject: [openssl-dev] [openssl.org #4097] Re: Pull request In-Reply-To: References: Message-ID: I also made https://github.com/openssl/openssl/pull/444 -Manish Goregaokar On Sat, Oct 17, 2015 at 4:25 PM, Manish Goregaokar wrote: > https://github.com/openssl/openssl/pull/443 > > (README told me to email the pull request link here) > > -Manish Goregaokar > -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Oct 18 09:08:21 2015 From: rt at openssl.org (Manish Goregaokar via RT) Date: Sun, 18 Oct 2015 09:08:21 +0000 Subject: [openssl-dev] [openssl.org #4098] Pull request In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/443 (README told me to email the pull request link here) -Manish Goregaokar -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sun Oct 18 20:26:10 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Sun, 18 Oct 2015 20:26:10 +0000 Subject: [openssl-dev] [openssl.org #4099] Config is loaded twice in the openssl ts command line application In-Reply-To: References: Message-ID: Hello, I found that the openssl ts command in master tries to load config file twice. To prevent it, the lines 323-324 should be removed. The patch is attached. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- index 237dd01..222ca45 100644 --- a/apps/ts.c +++ b/apps/ts.c @@ -320,8 +320,6 @@ int ts_main(int argc, char **argv) } conf = load_config_file(configfile); - if (!app_load_modules(conf)) - goto end; /* Check parameter consistency and execute the appropriate function. */ switch (mode) { -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Oct 19 06:26:28 2015 From: rt at openssl.org (tosif tamboli via RT) Date: Mon, 19 Oct 2015 06:26:28 +0000 Subject: [openssl-dev] Fwd: [openssl.org #4095] X509_STORE_get_by_subject crash In-Reply-To: References: Message-ID: Hi, Can you please help me in below query Thanks & regards, Tosif ---------- Forwarded message ---------- From: tosif tamboli Date: Fri, Oct 16, 2015 at 3:26 PM Subject: Re: [openssl.org #4095] X509_STORE_get_by_subject crash To: rt at openssl.org My application is written for vxWorks OS and openssl and vxWorks are part of the binary that I need to verify On Fri, Oct 16, 2015 at 3:13 PM, tosif tamboli wrote: > Hi, > > below is my application code > sshX509CACertStore = X509_STORE_new(); > > X509_STORE_set_verify_cb_func(sshX509CACertStore, > sshX509CertVerifyCallback); > pLookup = X509_STORE_add_lookup(sshX509CACertStore, > X509_LOOKUP_file()); > X509_LOOKUP_load_file(pLookup,caFile,X509_FILETYPE_PEM) > > X509_STORE_CTX_init (pStoreCtx, sshX509CACertStore, pX509, NULL); > > ret = X509_verify_cert (pStoreCtx); > > in the callback function I just checked for > retVal = X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, > pSubject, &x509_obj); > > retVal = X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, > pIssuer, &x509_obj); > > older openssl used md5 hash and newer doesn't seem to use it > As you mentioned about c_rehash. How should I create new symlink in code. > My application is to verify the certificate and signature in image > > It will be helpful if you can provide your inputs for crash of above > application at > X509_STORE_get_by_subject (&storeCtx, X509_LU_CRL, > pIssuer, &x509_obj); > > Thanks & regards, > Tosif > > > On Thu, Oct 15, 2015 at 8:16 PM, Emilia K?sper wrote: > >> This sounds like an application problem. >> 1) Did you recompile your source? 0.9.7 and 1.0.1 are not >> binary-compatible. >> 2) The certificate hash format has changed between 1.0.1 and 0.9.7, which >> could >> explain why the lookup no longer works: >> https://www.openssl.org/docs/manmaster/apps/rehash.html >> >> If the above isn't helpful, try asking for help on openssl-users at . >> Rejecting >> the ticket (though please reopen if you find new evidence that this is a >> bug >> within OpenSSL). >> >> Cheers, >> Emilia >> >> > From laurenz.albe at wien.gv.at Mon Oct 19 10:18:57 2015 From: laurenz.albe at wien.gv.at (Albe Laurenz) Date: Mon, 19 Oct 2015 10:18:57 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> Message-ID: Hubert Kario wrote: >> Fixing this sort of problem is going to be *hard* and probably require >> quite a lot of non-trivial changes - definitely not the sort of the >> thing I want to be doing in a stable branch. Fixing this is an >> example of what I meant by "onerous mitigations", but I now realise >> it is absolutely necessary if we wanted to pursue this. >> >> I think we should be marking this as a "won't fix" for all released >> versions. The question is whether we should even attempt to fix it for >> 1.1.0 or not. > > we may actually be able to patch this up partially in 1.0.x > > the original problem description mentions server being unable to process > application data before Certificate/Client Key Exchange, not in any > place what so ever > > (Albe, please double check if you didn't saw Java sending app data at > any different point) I ran my test with the patched version of OpenSSL 1.0.2, PostgreSQL 9.4.5 and Java 1.7.0_71 which completes without errors, and this is a Wireshark trace: 4 0.002744000 10.155.6.40 10.153.93.229 TLSv1 62 Ignored Unknown Record 6 0.003135000 10.153.93.229 10.155.6.40 TLSv1 60 Ignored Unknown Record 7 0.189902000 10.155.6.40 10.153.93.229 TLSv1 259 Client Hello 8 0.192699000 10.153.93.229 10.155.6.40 TLSv1 1485 Server Hello, Certificate, Server Key Exchange, Server Hello Done 9 0.201141000 10.155.6.40 10.153.93.229 TLSv1 129 Client Key Exchange 10 0.208975000 10.155.6.40 10.153.93.229 TLSv1 60 Change Cipher Spec 12 0.210346000 10.155.6.40 10.153.93.229 TLSv1 107 Encrypted Handshake Message 13 0.210739000 10.153.93.229 10.155.6.40 TLSv1 113 Change Cipher Spec, Encrypted Handshake Message 14 0.211317000 10.155.6.40 10.153.93.229 TLSv1 187 Application Data 15 0.212242000 10.153.93.229 10.155.6.40 TLSv1 144 Application Data, Application Data 16 0.212865000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 17 0.212932000 10.155.6.40 10.153.93.229 TLSv1 123 Application Data 19 0.216170000 10.153.93.229 10.155.6.40 TLSv1 448 Application Data, Application Data 20 0.223596000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 21 0.223671000 10.155.6.40 10.153.93.229 TLSv1 155 Application Data 23 0.224256000 10.153.93.229 10.155.6.40 TLSv1 144 Application Data, Application Data 24 0.235175000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 25 0.235258000 10.155.6.40 10.153.93.229 TLSv1 171 Application Data 27 0.235622000 10.153.93.229 10.155.6.40 TLSv1 160 Application Data, Application Data 28 0.236106000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 29 0.236175000 10.155.6.40 10.153.93.229 TLSv1 155 Application Data 31 0.237038000 10.153.93.229 10.155.6.40 TLSv1 1514 Application Data 37 0.237265000 10.153.93.229 10.155.6.40 TLSv1 1020 Application Data 38 0.237265000 10.153.93.229 10.155.6.40 TLSv1 91 Encrypted Handshake Message 39 0.237265000 10.153.93.229 10.155.6.40 TLSv1 1008 Application Data, Application Data 41 0.241914000 10.155.6.40 10.153.93.229 TLSv1 331 Encrypted Handshake Message 42 0.244284000 10.153.93.229 10.155.6.40 TLSv1 1514 Encrypted Handshake Message, Encrypted Handshake Message 43 0.244285000 10.153.93.229 10.155.6.40 TLSv1 150 Encrypted Handshake Message 45 0.248419000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 46 0.248492000 10.155.6.40 10.153.93.229 TLSv1 155 Application Data 48 0.253568000 10.155.6.40 10.153.93.229 TLSv1 155 Encrypted Handshake Message 49 0.257257000 10.155.6.40 10.153.93.229 TLSv1 91 Change Cipher Spec 50 0.257494000 10.155.6.40 10.153.93.229 TLSv1 107 Encrypted Handshake Message 52 0.257939000 10.153.93.229 10.155.6.40 TLSv1 144 Change Cipher Spec, Encrypted Handshake Message 53 0.258048000 10.153.93.229 10.155.6.40 TLSv1 1514 Application Data 59 0.258282000 10.153.93.229 10.155.6.40 TLSv1 1020 Application Data 60 0.258283000 10.153.93.229 10.155.6.40 TLSv1 91 Encrypted Handshake Message 61 0.258283000 10.153.93.229 10.155.6.40 TLSv1 1008 Application Data, Application Data 63 0.265872000 10.155.6.40 10.153.93.229 TLSv1 331 Encrypted Handshake Message 64 0.266324000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 65 0.266431000 10.155.6.40 10.153.93.229 TLSv1 91 Encrypted Alert 67 0.267282000 10.153.93.229 10.155.6.40 TLSv1 293 Encrypted Handshake Message, Change Cipher Spec, Encrypted Handshake Message Ist that good enough? Can you infer from context which "Encrypted Handshake Message" is what? Yours, Laurenz Albe From rt at openssl.org Mon Oct 19 10:19:09 2015 From: rt at openssl.org (Albe Laurenz via RT) Date: Mon, 19 Oct 2015 10:19:09 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> Message-ID: Hubert Kario wrote: >> Fixing this sort of problem is going to be *hard* and probably require >> quite a lot of non-trivial changes - definitely not the sort of the >> thing I want to be doing in a stable branch. Fixing this is an >> example of what I meant by "onerous mitigations", but I now realise >> it is absolutely necessary if we wanted to pursue this. >> >> I think we should be marking this as a "won't fix" for all released >> versions. The question is whether we should even attempt to fix it for >> 1.1.0 or not. > > we may actually be able to patch this up partially in 1.0.x > > the original problem description mentions server being unable to process > application data before Certificate/Client Key Exchange, not in any > place what so ever > > (Albe, please double check if you didn't saw Java sending app data at > any different point) I ran my test with the patched version of OpenSSL 1.0.2, PostgreSQL 9.4.5 and Java 1.7.0_71 which completes without errors, and this is a Wireshark trace: 4 0.002744000 10.155.6.40 10.153.93.229 TLSv1 62 Ignored Unknown Record 6 0.003135000 10.153.93.229 10.155.6.40 TLSv1 60 Ignored Unknown Record 7 0.189902000 10.155.6.40 10.153.93.229 TLSv1 259 Client Hello 8 0.192699000 10.153.93.229 10.155.6.40 TLSv1 1485 Server Hello, Certificate, Server Key Exchange, Server Hello Done 9 0.201141000 10.155.6.40 10.153.93.229 TLSv1 129 Client Key Exchange 10 0.208975000 10.155.6.40 10.153.93.229 TLSv1 60 Change Cipher Spec 12 0.210346000 10.155.6.40 10.153.93.229 TLSv1 107 Encrypted Handshake Message 13 0.210739000 10.153.93.229 10.155.6.40 TLSv1 113 Change Cipher Spec, Encrypted Handshake Message 14 0.211317000 10.155.6.40 10.153.93.229 TLSv1 187 Application Data 15 0.212242000 10.153.93.229 10.155.6.40 TLSv1 144 Application Data, Application Data 16 0.212865000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 17 0.212932000 10.155.6.40 10.153.93.229 TLSv1 123 Application Data 19 0.216170000 10.153.93.229 10.155.6.40 TLSv1 448 Application Data, Application Data 20 0.223596000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 21 0.223671000 10.155.6.40 10.153.93.229 TLSv1 155 Application Data 23 0.224256000 10.153.93.229 10.155.6.40 TLSv1 144 Application Data, Application Data 24 0.235175000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 25 0.235258000 10.155.6.40 10.153.93.229 TLSv1 171 Application Data 27 0.235622000 10.153.93.229 10.155.6.40 TLSv1 160 Application Data, Application Data 28 0.236106000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 29 0.236175000 10.155.6.40 10.153.93.229 TLSv1 155 Application Data 31 0.237038000 10.153.93.229 10.155.6.40 TLSv1 1514 Application Data 37 0.237265000 10.153.93.229 10.155.6.40 TLSv1 1020 Application Data 38 0.237265000 10.153.93.229 10.155.6.40 TLSv1 91 Encrypted Handshake Message 39 0.237265000 10.153.93.229 10.155.6.40 TLSv1 1008 Application Data, Application Data 41 0.241914000 10.155.6.40 10.153.93.229 TLSv1 331 Encrypted Handshake Message 42 0.244284000 10.153.93.229 10.155.6.40 TLSv1 1514 Encrypted Handshake Message, Encrypted Handshake Message 43 0.244285000 10.153.93.229 10.155.6.40 TLSv1 150 Encrypted Handshake Message 45 0.248419000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 46 0.248492000 10.155.6.40 10.153.93.229 TLSv1 155 Application Data 48 0.253568000 10.155.6.40 10.153.93.229 TLSv1 155 Encrypted Handshake Message 49 0.257257000 10.155.6.40 10.153.93.229 TLSv1 91 Change Cipher Spec 50 0.257494000 10.155.6.40 10.153.93.229 TLSv1 107 Encrypted Handshake Message 52 0.257939000 10.153.93.229 10.155.6.40 TLSv1 144 Change Cipher Spec, Encrypted Handshake Message 53 0.258048000 10.153.93.229 10.155.6.40 TLSv1 1514 Application Data 59 0.258282000 10.153.93.229 10.155.6.40 TLSv1 1020 Application Data 60 0.258283000 10.153.93.229 10.155.6.40 TLSv1 91 Encrypted Handshake Message 61 0.258283000 10.153.93.229 10.155.6.40 TLSv1 1008 Application Data, Application Data 63 0.265872000 10.155.6.40 10.153.93.229 TLSv1 331 Encrypted Handshake Message 64 0.266324000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data 65 0.266431000 10.155.6.40 10.153.93.229 TLSv1 91 Encrypted Alert 67 0.267282000 10.153.93.229 10.155.6.40 TLSv1 293 Encrypted Handshake Message, Change Cipher Spec, Encrypted Handshake Message Ist that good enough? Can you infer from context which "Encrypted Handshake Message" is what? Yours, Laurenz Albe From steve at openssl.org Mon Oct 19 14:42:19 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 19 Oct 2015 14:42:19 +0000 Subject: [openssl-dev] OCSP issues in master 2015-10-17 In-Reply-To: <5622A564.3040908@roumenpetrov.info> References: <5622A564.3040908@roumenpetrov.info> Message-ID: <20151019144219.GA19762@openssl.org> On Sat, Oct 17, 2015, Roumen Petrov wrote: > Hello, > > After embed some attributes OCSP in master stop to work. > > The current status is the client comment report "Cert Status: > unknown" and "Nonce Verify error" for X.509 certificates used in my > ssh regression tests. > > The last known version to work is > "47c9a1b5096be684c18335137284f0dfcefd12d6 : embed support for > ASN1_STRING" > (optionally with "Appease gcc's Wmaybe-uninitialized" if build fail > due to pedantic compiler flags). > > First regression is from "af170194a88d6127d447bea826845c23ca192727 : > embed OCSP_CERTID" - status is missing. > Should be fixed by commit 7f3e6f8c243710b8dc89f385196987ad83c7848d in the master branch. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Mon Oct 19 15:00:18 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 19 Oct 2015 15:00:18 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <21917373.UaPtMbDzzS@pintsize.usersys.redhat.com> References: <21917373.UaPtMbDzzS@pintsize.usersys.redhat.com> Message-ID: On Monday 19 October 2015 10:19:09 Albe Laurenz via RT wrote: > 7 0.189902000 10.155.6.40 10.153.93.229 TLSv1 259 Client Hello > 8 0.192699000 10.153.93.229 10.155.6.40 TLSv1 1485 Server Hello, Certificate, Server Key Exchange, Server Hello Done so we know that 10.155.6.40 is the client while 10.153.93.229 is the server > 38 0.237265000 10.153.93.229 10.155.6.40 TLSv1 91 Encrypted Handshake Message Server is sending Hello Request > 39 0.237265000 10.153.93.229 10.155.6.40 TLSv1 1008 Application Data, Application Data Server is continuing sending the data > 41 0.241914000 10.155.6.40 10.153.93.229 TLSv1 331 Encrypted Handshake Message Client is sending Client Hello > 42 0.244284000 10.153.93.229 10.155.6.40 TLSv1 1514 Encrypted Handshake Message, Encrypted Handshake Message > 43 0.244285000 10.153.93.229 10.155.6.40 TLSv1 150 Encrypted Handshake Message Server replies with Server Hello, Certificate and Server Hello Done > 45 0.248419000 10.155.6.40 10.153.93.229 TLSv1 91 Application Data > 46 0.248492000 10.155.6.40 10.153.93.229 TLSv1 155 Application Data Client continues sending data > 48 0.253568000 10.155.6.40 10.153.93.229 TLSv1 155 Encrypted Handshake Message Client replies to Server Hello Done with Client Key Exchange... > 49 0.257257000 10.155.6.40 10.153.93.229 TLSv1 91 Change Cipher Spec > 50 0.257494000 10.155.6.40 10.153.93.229 TLSv1 107 Encrypted Handshake Message ...Change Cipher Spec and Finished > 52 0.257939000 10.153.93.229 10.155.6.40 TLSv1 144 Change Cipher Spec, Encrypted Handshake Message server replies with Change Cipher Spec and Finished > 53 0.258048000 10.153.93.229 10.155.6.40 TLSv1 1514 Application Data > 59 0.258282000 10.153.93.229 10.155.6.40 TLSv1 1020 Application Data server replies with data to client > Ist that good enough? Can you infer from context which "Encrypted > Handshake Message" is what? yes, thank you, if that exchange is typical, then it's enough to allow application data between Client Hello and Certificate/Client Key Exchange to at least "patch up" this issue -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Oct 19 15:55:09 2015 From: rt at openssl.org (Pascal Cuoq via RT) Date: Mon, 19 Oct 2015 15:55:09 +0000 Subject: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c In-Reply-To: <8E115EC2-6D07-412F-9771-7C725F6CB080@trust-in-soft.com> References: <8E115EC2-6D07-412F-9771-7C725F6CB080@trust-in-soft.com> Message-ID: Hello, this is a follow-up to #3891 (https://mta.openssl.org/pipermail/openssl-dev/2015-June/001667.html ). Kurt Roeckx has committed many fixes to the bugs aggregated in that report. Since, we have been replaying the tests in a recent OpenSSL development version, posterior to these commits, to see what issues remained and re-submit them individually with more explanation. This means that #3891 can now be closed (grouping too many fixes in a same entry may not have been such a good idea after all). First, an old problem for which detection was only implemented recently : the memcpy call in bn_add.c can be passed identical pointers, which are thus pointing to overlapping zones. The code has been so for a long time and someone would likely have noticed if this had practical consequences, but in principle, invoking memcpy to copy between overlapping memory zones is undefined behavior even if the overlap is exact. This can be fixed locally as in the attached patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: bn_memcpy_overlap.patch Type: application/octet-stream Size: 370 bytes Desc: not available URL: -------------- next part -------------- One actual sequence for which the pointers ap and rp end up being identical is as follows: 1/ probable_prime_dh_safe calls BN_sub(q, q, t1) 2/ in BN_sub, r and a are then aliases 3/ BN_sub calls BN_usub(r, a, b) so r and a are still aliases in BN_usub 4/ in BN_usub, ap = a->d; and rp = r->d; then the 2 pointers can be incremented, but an identical number of times 5/ then memcpy is called with rp and ap that are still aliases, which is undefined behavior -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Oct 19 18:09:53 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 19 Oct 2015 18:09:53 +0000 Subject: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c In-Reply-To: <20151019181001.GA9760@roeckx.be> References: <8E115EC2-6D07-412F-9771-7C725F6CB080@trust-in-soft.com> <20151019181001.GA9760@roeckx.be> Message-ID: On Mon, Oct 19, 2015 at 03:55:09PM +0000, Pascal Cuoq via RT wrote: > > One actual sequence for which the pointers ap and rp end up being identical is as follows: > > 1/ probable_prime_dh_safe calls BN_sub(q, q, t1) > > 2/ in BN_sub, r and a are then aliases > > 3/ BN_sub calls BN_usub(r, a, b) so r and a are still aliases in BN_usub > > 4/ in BN_usub, ap = a->d; and rp = r->d; > then the 2 pointers can be incremented, but an identical number of times > > 5/ then memcpy is called with rp and ap that are still aliases, which is undefined behavior So I've been looking at this, and it seems the patch makes sense at first sight. The manpage says that for BN_add(), BN_mul(), BN_sqr(), BN_mod_mul() and BN_gcd() r can be one of the other BIGNUMs that got passed, but it doesn't say so for BN_sub(). So one could also argue that probable_prime_dh_safe() shouldn't have called BN_sub() like that. But we have various other callers internally that call BN_sub() like that. So we should probably either fix all the callers not to do that, or really make sure that it works properly when they alias and document that they can. And I'm currently in favor of making it safe for them to alias. (It should probably only be allowed to alias a, not b.) But I need to take a closer look to make sure that the patch is enough or that something else needs to be changed too. Kurt From rt at openssl.org Mon Oct 19 18:15:53 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 19 Oct 2015 18:15:53 +0000 Subject: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c In-Reply-To: <20151019181612.GA10605@roeckx.be> References: <8E115EC2-6D07-412F-9771-7C725F6CB080@trust-in-soft.com> <20151019181001.GA9760@roeckx.be> <20151019181612.GA10605@roeckx.be> Message-ID: On Mon, Oct 19, 2015 at 08:10:01PM +0200, Kurt Roeckx wrote: > The manpage says that for BN_add(), BN_mul(), BN_sqr(), BN_mod_mul() > and BN_gcd() r can be one of the other BIGNUMs that got passed, but > it doesn't say so for BN_sub(). So one could also argue that > probable_prime_dh_safe() shouldn't have called BN_sub() like that. > But we have various other callers internally that call BN_sub() > like that. So we should probably either fix all the callers not > to do that, or really make sure that it works properly when they > alias and document that they can. And I'm currently in favor of > making it safe for them to alias. (It should probably only be > allowed to alias a, not b.) I think that only allow a to alias and not b doesn't make sense anymore, and clearly would be a problem since BN_sub() can call BN_usub() with a and b switched. Kurt From rt at openssl.org Mon Oct 19 18:22:52 2015 From: rt at openssl.org (Adam Eijdenberg via RT) Date: Mon, 19 Oct 2015 18:22:52 +0000 Subject: [openssl-dev] [openssl.org #4101] [PATCH] Doc clarification for EVP_DigestVerifyFinal In-Reply-To: References: Message-ID: Minor doc clarification: https://github.com/openssl/openssl/pull/446 I embarrassingly misread the previous documentation to indicate that 0 was a failure and other values mean success and figured others might do the same. Cheers, Adam -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Mon Oct 19 20:31:48 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 19 Oct 2015 20:31:48 +0000 Subject: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c In-Reply-To: <20151019203156.GA17364@roeckx.be> References: <8E115EC2-6D07-412F-9771-7C725F6CB080@trust-in-soft.com> <20151019181001.GA9760@roeckx.be> <20151019203156.GA17364@roeckx.be> Message-ID: On Mon, Oct 19, 2015 at 08:10:01PM +0200, Kurt Roeckx wrote: > The manpage says that for BN_add(), BN_mul(), BN_sqr(), BN_mod_mul() > and BN_gcd() r can be one of the other BIGNUMs that got passed, but > it doesn't say so for BN_sub(). BN_add() can of course already call BN_usub(), and BN_uadd() also already has the rp != ap check. Kurt From alessandro at ghedini.me Tue Oct 20 18:05:50 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Tue, 20 Oct 2015 20:05:50 +0200 Subject: [openssl-dev] who wants to fix travis builds? In-Reply-To: <5620BBCB.4040108@openssl.org> References: <20150928170340.GA8688@kronk.local> <56098BA8.8000809@openssl.org> <20150929124837.GA18210@kronk.local> <560BA1C1.4030606@openssl.org> <20151005222804.GA14709@kronk.local> <20151006193753.GA14151@kronk.local> <20151012172205.GA28726@kronk.local> <561E0E0B.2080001@openssl.org> <5620BBCB.4040108@openssl.org> Message-ID: <20151020180550.GA21983@kronk.local> On Fri, Oct 16, 2015 at 10:56:43am +0200, Andy Polyakov wrote: > >>>> I've opened the following PR to add support for GCC v5 and > >>>> address sanitizer (not sure if we want valgrind as well...): > >>>> https://github.com/openssl/openssl/pull/429 > > > > I've commented there on other -fsanitize options as well as about > > option to execute them without --debug and/or --strict-warnings. But I > > failed to recall all the details from last time the question was risen > > in context of RT#3422 through 3324. -fsanitize=undefined is expected > > to work only with --strict-warnings (or more specifically with > > -DPEDANTIC) and I wouldn't be surprised if -fsanitize=memory works > > only with -DPURIFY. > > The main weakness of the endeavour is that testing is limited to x86 > hardware. I don't mean specifically -fsanitize, but in general. But > let's concentrate on -fsanitize for a moment. Or more specifically why > are there limitations for it, ones mentioned above. In the nutshell, > remaining -fsanitize warnings were effectively about the fact that we > sometimes rely on platform- or implementation-specific behaviour. But it > is *conscious* choice and there always is platform-neutral fallback. So > that above mentioned limitations are actually about nothing else but > driving compiler toward these platform-neutral fallbacks. One can even > take next step and say that in order to maximize -fsanitize utility, one > should expose as much C code to -fsanitize as possible, or in other > words adhere even to no-asm with -fsanitize. Incidentally this would > also at least partially mitigate the main weakness, as -fsanitize should > expose spots where platform-neutral fallback is not as platform-neutral > as it should be, wouldn't it? FWIW both gcc and clang support some sort of blacklist to exclude particular functions from sanitizers. This would allow us to mark special cases manually in order to avoid missing accidental errors in non-debug builds... but that's work for some other time. For now, I added ubsan debug-only builds for Travis at [0], and fixed a couple of very minor issues (a test called memcmp() with a NULL pointer, and there was a missing, but probably irrelevant, cast). I'm not sure if the fixes are correct or not though. Sort of related: the usefulness of sanitizers is directly related to the coverage of the test suite, which, according to gcov, is currently around 50% or so of OpenSSL's code. Would it be ok to steal^Wget inspiration from other projects' test suites (e.g. BoringSSL and LibreSSL added some new tests) to try to increse that? One nice thing from BoringSSL's test suite is the Go-based test runner thingy. It'd be interesting to see how good or bad OpenSSL does against it. Cheers [0] https://github.com/openssl/openssl/pull/445 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From raysatiro at yahoo.com Wed Oct 21 01:30:43 2015 From: raysatiro at yahoo.com (Ray Satiro) Date: Tue, 20 Oct 2015 21:30:43 -0400 Subject: [openssl-dev] mingw: pkg-config --libs outputs gdi32 before crypto Message-ID: <5626EAC3.3060202@yahoo.com> OpenSSL 1.0.2d static built with mingw32. make clean perl ./Configure mingw make depend make make check make install I'm using the pkg-config 0.26 that comes with Strawberry Perl to get the libs when I want to link to OpenSSL: pkg-config --static --libs-only-l openssl -lssl -lws2_32 -lgdi32 -lcrypt32 -lcrypto I see errors related to the order: libcrypto.a(rand_win.o):rand_win.c:(.text+0xeab): undefined reference to `_GetDeviceCaps at 8' I'd expect gdi32 after crypto. The pc files generated by OpenSSL appear to do that but that's not the output pkg-config gives me. I'm not sure if this is an OpenSSL issue or a pkg-config issue. Is anyone else using pkg-config successfully in this configuration? Briefly: openssl.pc ---------- Name: OpenSSL Description: Secure Sockets Layer and cryptography libraries and tools Version: 1.0.2d Requires: libssl libcrypto libcrypto.pc ------------ Name: OpenSSL-libcrypto Description: OpenSSL cryptography library Version: 1.0.2d Requires: Libs: -L${libdir} -lcrypto Libs.private: -lws2_32 -lgdi32 -lcrypt32 Cflags: -I${includedir} libssl.pc --------- Name: OpenSSL-libssl Description: Secure Sockets Layer and cryptography libraries Version: 1.0.2d Requires.private: libcrypto Libs: -L${libdir} -lssl Libs.private: -lws2_32 -lgdi32 -lcrypt32 Cflags: -I${includedir} From ben at links.org Wed Oct 21 08:31:48 2015 From: ben at links.org (Ben Laurie) Date: Wed, 21 Oct 2015 08:31:48 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <20151016213536.GA6365@roeckx.be> <56216FB1.6070405@akamai.com> <20151017053537.GA11200@roeckx.be> Message-ID: On Sat, 17 Oct 2015 at 06:35 Kurt Roeckx via RT wrote: > On Fri, Oct 16, 2015 at 09:44:22PM +0000, Kaduk, Ben via RT wrote: > > On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote: > > > On Fri, Oct 16, 2015 at 06:50:36PM +0000, Kurt Roeckx via RT wrote: > > >> On Fri, Oct 16, 2015 at 04:50:59PM +0000, Matt Caswell via RT wrote: > > >>> In a well-behaved program there is no undefined behaviour. The "buf + > > >>> len < buf" check will always evaluate to false, so in that sense is > > >>> useless but it *is* well defined. > > >> The defined behaviour for the "buf + len" part is as far as I know > > >> that you're that the pointer should point inside the allocated > > >> object or 1 byte after it. So as long as "len" is in the valid > > >> range, the "buf + len" part should be well defined. The test with > > >> -1 is clearly undefined. > > >> > > >> As far as I know in the comparison pointers they should point > > >> to the same object. But the check seems to imply that they might > > >> not point to the same object or that buf is not the base of the > > >> object. But since len is unsigned only the option that they don't > > >> point to the same object seems to be left. > > >> > > >> So it's unclear to me if this is defined behaviour or not. > > > So thinking about this some more, it seems to be a check for > > > undefined behaviour that probably itself is still defined. > > > > > > That probably also means the compiler can assume that it's always > > > false and eliminate the check, it's probably just not smart enough > > > yet. > > > > > > > I think it is unambiguous that there are values of unsigned char *buf > > and size_t len for which evaluating (bug + len < buf) invokes undefined > > behavior -- the sheer act of performing the addition buf + len can > > produce undefined behavior, even before any comparison. I am as-yet > > uncertain whether the case when buf points into the middle of an object > > and len is (size_t)-1 invokes undefined behavior, but I am inclined to > > believe that it is also undefined behavior. > > Just to clarify what I mean, buf + len can both have defined and > undefined meaning, it depends on the value of len, so the compiler > can probably not say anything about that part without knowing all > the callers of that code. As long as it has a defined meaning the > compiler will probably do it. buf + len < buf also seems to have > a defined meaning, but in all defined meanings it's false, and so > the compiler can just optimize that part away. > > Anyway, I would really like this to be changed. > +1 > > > Kurt > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Oct 21 08:32:12 2015 From: rt at openssl.org (Ben Laurie via RT) Date: Wed, 21 Oct 2015 08:32:12 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <561F9F06.9030408@openssl.org> <56216FB1.6070405@akamai.com> <20151017053537.GA11200@roeckx.be> Message-ID: On Sat, 17 Oct 2015 at 06:35 Kurt Roeckx via RT wrote: > On Fri, Oct 16, 2015 at 09:44:22PM +0000, Kaduk, Ben via RT wrote: > > On 10/16/2015 04:35 PM, Kurt Roeckx via RT wrote: > > > On Fri, Oct 16, 2015 at 06:50:36PM +0000, Kurt Roeckx via RT wrote: > > >> On Fri, Oct 16, 2015 at 04:50:59PM +0000, Matt Caswell via RT wrote: > > >>> In a well-behaved program there is no undefined behaviour. The "buf + > > >>> len < buf" check will always evaluate to false, so in that sense is > > >>> useless but it *is* well defined. > > >> The defined behaviour for the "buf + len" part is as far as I know > > >> that you're that the pointer should point inside the allocated > > >> object or 1 byte after it. So as long as "len" is in the valid > > >> range, the "buf + len" part should be well defined. The test with > > >> -1 is clearly undefined. > > >> > > >> As far as I know in the comparison pointers they should point > > >> to the same object. But the check seems to imply that they might > > >> not point to the same object or that buf is not the base of the > > >> object. But since len is unsigned only the option that they don't > > >> point to the same object seems to be left. > > >> > > >> So it's unclear to me if this is defined behaviour or not. > > > So thinking about this some more, it seems to be a check for > > > undefined behaviour that probably itself is still defined. > > > > > > That probably also means the compiler can assume that it's always > > > false and eliminate the check, it's probably just not smart enough > > > yet. > > > > > > > I think it is unambiguous that there are values of unsigned char *buf > > and size_t len for which evaluating (bug + len < buf) invokes undefined > > behavior -- the sheer act of performing the addition buf + len can > > produce undefined behavior, even before any comparison. I am as-yet > > uncertain whether the case when buf points into the middle of an object > > and len is (size_t)-1 invokes undefined behavior, but I am inclined to > > believe that it is also undefined behavior. > > Just to clarify what I mean, buf + len can both have defined and > undefined meaning, it depends on the value of len, so the compiler > can probably not say anything about that part without knowing all > the callers of that code. As long as it has a defined meaning the > compiler will probably do it. buf + len < buf also seems to have > a defined meaning, but in all defined meanings it's false, and so > the compiler can just optimize that part away. > > Anyway, I would really like this to be changed. > +1 > > > Kurt > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Wed Oct 21 09:42:24 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 21 Oct 2015 09:42:24 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <56275DFC.3050404@openssl.org> References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> <56275DFC.3050404@openssl.org> Message-ID: On 16/10/15 16:05, Hubert Kario via RT wrote: > we may actually be able to patch this up partially in 1.0.x > > the original problem description mentions server being unable to process > application data before Certificate/Client Key Exchange, not in any > place what so ever > > (Albe, please double check if you didn't saw Java sending app data at > any different point) > > unless the server is completely asynchronous, it's unlikely it will send > application data messages between handshake messages from a single > flight, it will send app data only between different flights > > in other words, we should still be able to accept this data before the > client responses had any chance to modify the certificates in the > server. > > of course, that doesn't allow us to fix it for the other side of > connection - where the application data is sent by server after Server > Hello Done and before server Change Cipher Spec I think this is also not safe, in a slight amendment to my previous exploit. Imagine an attacker who is able to eavesdrop on messages between a legitimate client who presents a client certificate to the server during the initial handshake. As it is during the initial handshake this happens in the clear, including the server responding with a session id. Ordinarily knowing the session id does not help very much because the attacker does not know the associated keys so any attempt to reuse that session id will fail. However with the proposed patch in place the attacker can first establish a connection to the server anonymously. Then they send a new ClientHello, but this time provide the eavesdropped session id. The server updates the s->session value from the session cache which *includes* the peer certificate. The exploit can then proceed as before. The attacker does not continue the renegotiation handshake but instead sends application data attempting a privileged operation and the server application successfully verifies the identity. Matt From rt at openssl.org Wed Oct 21 15:20:03 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 21 Oct 2015 15:20:03 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> Message-ID: There seems a strong consensus to change this so: https://github.com/openssl/openssl/commit/3fde6c9276c9cd6e56e8e06e756350a4fbdd7031 Closing this ticket. Matt From rt at openssl.org Wed Oct 21 16:49:36 2015 From: rt at openssl.org (Der Fuchs via RT) Date: Wed, 21 Oct 2015 16:49:36 +0000 Subject: [openssl-dev] [openssl.org #4102] Typo bug in ssl_err.c version 1.0.0s In-Reply-To: <64bd7606bf7c96c6276677a8cb74752d@posteo.de> References: <64bd7606bf7c96c6276677a8cb74752d@posteo.de> Message-ID: Hello, I just want to report a small typo bug in the OpenSSL 1.0.0s branch. Patch file is attached. Br, David -------------- next part -------------- A non-text attachment was scrubbed... Name: patch.txt Type: text/x-diff Size: 582 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Oct 21 16:50:00 2015 From: rt at openssl.org (Srinivas Thota via RT) Date: Wed, 21 Oct 2015 16:50:00 +0000 Subject: [openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get In-Reply-To: References: Message-ID: Hi, I am trying figure out valgrind report leak. in openssl 1.0.1c. Can any one comment if this already fixed and what is the fix. ==30824== 912 (56 direct, 856 indirect) bytes in 1 blocks are definitely lost in loss record 837 of 907 ==30824== at 0x4A07F9E: malloc (vg_replace_malloc.c:291) ==30824== by 0x3613672AE7: CRYPTO_malloc (in /lib64/libcrypto.so.1.0.0) ==30824== by 0x36136FA2D9: EVP_PKEY_new (in /lib64/libcrypto.so.1.0.0) ==30824== by 0x3613708EC7: X509_PUBKEY_get (in /lib64/libcrypto.so.1.0.0) ==30824== by 0x3613724B41: X509_get_pubkey_parameters (in /lib64/libcrypto.so.1.0.0) ==30824== by 0x36137253D3: X509_verify_cert (in /lib64/libcrypto.so.1.0.0) Thanks, Srinivas -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Oct 21 17:16:07 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 21 Oct 2015 17:16:07 +0000 Subject: [openssl-dev] [openssl.org #3891] [PATCH] Fix undefined behavior executed through OpenSSL tests In-Reply-To: References: Message-ID: Kurt has addressed most of the issues in this ticket. Any that still remain are being handled by separate tickets for each issue. The original submitter suggest closing this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed Oct 21 18:48:46 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 21 Oct 2015 18:48:46 +0000 Subject: [openssl-dev] [openssl.org #4103] Valgrind reported memory leak in X509_PUBKEY_get In-Reply-To: References: Message-ID: > I am trying figure out valgrind report leak. in openssl 1.0.1c. You don't have enough of the backtrace for us to reproduce it. Please add a simple demo program. From rt at openssl.org Wed Oct 21 19:41:58 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Wed, 21 Oct 2015 19:41:58 +0000 Subject: [openssl-dev] [openssl.org #4104] A bug in the crl2pkc7 command in master In-Reply-To: References: Message-ID: Hello, I've found a bug in the crl2pkc7 command in the master branch. openssl crl2pkcs7 -in test.crl -certfile cert.pem -out p7.pem Output: error opening the file, -in error loading certificates 140737354073768:error:02001002:system library:fopen:No such file or directory:bss_file.c:175:fopen('-in','r') 140737354073768:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:178: The patch I attach fixes it. -- SY, Dmitry Belyavsky -------------- next part -------------- --- a/apps/crl2p7.c +++ b/apps/crl2p7.c @@ -138,7 +138,7 @@ int crl2pkcs7_main(int argc, char **argv) if ((certflst == NULL) && (certflst = sk_OPENSSL_STRING_new_null()) == NULL) goto end; - if (!sk_OPENSSL_STRING_push(certflst, *(++argv))) { + if (!sk_OPENSSL_STRING_push(certflst, opt_arg())) { sk_OPENSSL_STRING_free(certflst); goto end; } -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl at roumenpetrov.info Wed Oct 21 20:16:52 2015 From: openssl at roumenpetrov.info (Roumen Petrov) Date: Wed, 21 Oct 2015 23:16:52 +0300 Subject: [openssl-dev] OCSP issues in master 2015-10-17 In-Reply-To: <20151018024139.GA30084@openssl.org> References: <5622A564.3040908@roumenpetrov.info> <20151018024139.GA30084@openssl.org> Message-ID: <5627F2B4.4010907@roumenpetrov.info> Dr. Stephen Henson wrote: > On Sat, Oct 17, 2015, Roumen Petrov wrote: > >> Hello, >> >> After embed some attributes OCSP in master stop to work. >> >> The current status is the client comment report "Cert Status: >> unknown" and "Nonce Verify error" for X.509 certificates used in my >> ssh regression tests. >> > Try this patch: > > diff --git a/crypto/asn1/tasn_new.c b/crypto/asn1/tasn_new.c > index 33a8e97..6a2ad62 100644 > --- a/crypto/asn1/tasn_new.c > +++ b/crypto/asn1/tasn_new.c > @@ -352,6 +352,7 @@ static int asn1_primitive_new(ASN1_VALUE **pval, const > ASN1_ITEM *it, > if (embed) { > str = *(ASN1_STRING **)pval; > memset(str, 0, sizeof(*str)); > + str->type = utype; > str->flags = ASN1_STRING_FLAG_EMBED; > } else { > str = ASN1_STRING_type_new(utype); Thanks. Now my ssh regression tests pass with master. Regards, Roumen Petrov From rt at openssl.org Wed Oct 21 21:41:44 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 21 Oct 2015 21:41:44 +0000 Subject: [openssl-dev] [openssl.org #4102] Typo bug in ssl_err.c version 1.0.0s In-Reply-To: <64bd7606bf7c96c6276677a8cb74752d@posteo.de> References: <64bd7606bf7c96c6276677a8cb74752d@posteo.de> Message-ID: openssl 1.0.0 is end of life in 80 days :) we're only doing security fixes at this time. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Oct 22 14:16:46 2015 From: rt at openssl.org (Pascal Cuoq via RT) Date: Thu, 22 Oct 2015 14:16:46 +0000 Subject: [openssl-dev] [openssl.org #4105] null pointer dereference in BN_lshift when coming from dsa_builtin_paramgen In-Reply-To: <99D4E95E-4628-4F92-81DC-AFDBD5B001E9@trust-in-soft.com> References: <99D4E95E-4628-4F92-81DC-AFDBD5B001E9@trust-in-soft.com> Message-ID: BN_POOL_get() can return NULL when OPENSSL_malloc() fails: https://github.com/openssl/openssl/blob/984d6c6052169bcae8010de33f7796e455536d61/crypto/bn/bn_ctx.c#L365-L366 This causes BN_CTX_get() to return NULL: https://github.com/openssl/openssl/blob/984d6c6052169bcae8010de33f7796e455536d61/crypto/bn/bn_ctx.c#L287 In the function dsa_builtin_paramgen, the value returned by BN_CTX_get is not tested before calling BN_lshift which is then called with first argument NULL: https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/crypto/dsa/dsa_gen.c#L162 This causes a null pointer dereference in BN_lshift(), but it seems the correct fix would be to check the value of test after calling BN_CTX_get() at line 160: https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/crypto/dsa/dsa_gen.c#L160 ____________________________ It seems that another instance of the same problem in the file dsa_gen.c exists and is more subtle: r0 may be NULL. However BN_bin2bn() accepts NULL as third argument, in which case it tries to allocate a new BN. r0 remains NULL throughout this call: https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/crypto/dsa/dsa_gen.c#L247 IF THE CALL TO BN_bin2bn at line 247 SUCCEEDS, then r0 (still NULL) is passed to BN_lshift at line 249: https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/crypto/dsa/dsa_gen.c#L249 Extrapolating, it looks like it would be a good idea to guard all the calls to BN_CTX_get at lines 153-160: https://github.com/openssl/openssl/blob/310115448188415e270bb0bef958c7c130939838/crypto/dsa/dsa_gen.c#L153-L160 _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 22 18:02:46 2015 From: rt at openssl.org (Stefan.Neis@t-online.de via RT) Date: Thu, 22 Oct 2015 18:02:46 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <1445536945073.187883.e9e929bb07d4242986a0eedb892c4e4b9f697195@spica.telekom.de> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <1445536945073.187883.e9e929bb07d4242986a0eedb892c4e4b9f697195@spica.telekom.de> Message-ID: Hi, Wouldn't if ( UINTPTR_MAX - (uintptr_t) buffer < len) be closer to the intention of the original check? Or is this undefined behaviour as well and I stupidly missed that fact? Regards, Stefan From rt at openssl.org Thu Oct 22 18:53:54 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Thu, 22 Oct 2015 18:53:54 +0000 Subject: [openssl-dev] [openssl.org #4106] Bug in smime command in master In-Reply-To: References: Message-ID: Hello! When I try to verify the signed message using the master branch, I get an error. The command line is: openssl smime -verify -inform der -in signed2_2_256.asn -noverify -signer signer.certs -out was_signed.dat STDERR CONTENTS: smime: Cannot open input file signer.certs, No such file or directory The message does not match the documentation and the behavior of the command does not match the 1.0.2 version. -- SY, Dmitry Belyavsky -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 22 20:00:36 2015 From: rt at openssl.org (Kaduk, Ben via RT) Date: Thu, 22 Oct 2015 20:00:36 +0000 Subject: [openssl-dev] [openssl.org #4094] Nonsensical pointer comparison in PACKET_buf_init In-Reply-To: <56294060.8050902@akamai.com> References: <14e3166e2135447a871cb64907d54106@S1688.EX1688.lan> <1445536945073.187883.e9e929bb07d4242986a0eedb892c4e4b9f697195@spica.telekom.de> <56294060.8050902@akamai.com> Message-ID: On 10/22/2015 01:02 PM, Stefan.Neis at t-online.de via RT wrote: > Hi, > > Wouldn't > if ( UINTPTR_MAX - (uintptr_t) buffer < len) > be closer to the intention of the original check? > Or is this undefined behaviour as well and I > stupidly missed that fact? > That appears to be defined behavior, but the intention of the original check is not particularly well-specified. The committed version should be sufficient; there does not seem to be a reason to change it again. -Ben From rt at openssl.org Fri Oct 23 01:12:57 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 23 Oct 2015 01:12:57 +0000 Subject: [openssl-dev] [openssl.org #4101] [PATCH] Doc clarification for EVP_DigestVerifyFinal In-Reply-To: References: Message-ID: OpenSSL_1_0_1-stable 2d404dc Clarify return values for EVP_DigestVerifyFinal. OpenSSL_1_0_2-stable 8d43c00 Clarify return values for EVP_DigestVerifyFinal. master 8cbb048 Clarify return values for EVP_DigestVerifyFinal. Author: Adam Eijdenberg Date: Mon Oct 19 11:16:25 2015 -0700 Clarify return values for EVP_DigestVerifyFinal. Previous language was unclear. New language isn't pretty but I believe it is more accurate. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Oct 23 01:14:35 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 23 Oct 2015 01:14:35 +0000 Subject: [openssl-dev] [openssl.org #1544] bug report: openssl applications crashing due to uninitialized variables In-Reply-To: <1BCEE671C28040E99E76830F2D4A299D@nirvanaware.com> References: <1BCEE671C28040E99E76830F2D4A299D@nirvanaware.com> Message-ID: old release, many issues fixed. perhaps more remain; please open new tickets if/when found. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From mturk at apache.org Fri Oct 23 08:55:32 2015 From: mturk at apache.org (Mladen Turk) Date: Fri, 23 Oct 2015 10:55:32 +0200 Subject: [openssl-dev] [PATCH] Fix error in generated libeay32.def for OPENSSL_NO_ENGINE Message-ID: <5629F604.3030704@apache.org> Patch fixes LIBEAY32.def : error LNK2001: unresolved external symbol TS_CONF_set_crypto_device LIBEAY32.def : error LNK2001: unresolved external symbol TS_CONF_set_default_engine caused by always adding those functions to .def file Ensure they are added only if engine is not disabled Regards -- ^TM -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-1.0.2c-tsconf-engine.patch Type: text/x-patch Size: 1210 bytes Desc: not available URL: From alessandro at ghedini.me Fri Oct 23 13:22:39 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Fri, 23 Oct 2015 15:22:39 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG Message-ID: <20151023132238.GA32506@kronk.local> Hello everyone, (sorry for the wall of text...) one of the things that both BoringSSL and LibreSSL have in common is the replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner alternative. Given RAND_SSLeay() complexity I think it'd be worth to at least consider possible alternatives for OpenSSL. BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to RAND_bytes(). Additionally, if the RDRAND instruction is available, the output of RDRAND is mixed with the output of the system RNG using ChaCha20. This uses thread-local storage to keep the global RNG state. Incidentally, BoringSSL added a whole new API for thread-local storage which OpenSSL could adopt given that e.g. the ASYNC support could benefit from it (there are other interesting bits in BoringSSL, like the new threading API that could also be adopted by OpenSSL). The BoringSSL method is very simple but it needs a read from /dev/urandom for every call to RAND_bytes() which can be slow (though, BoringSSL's RAND_bytes() seems to implement some sort of buffering for /dev/urandom so the cost may be lower). On the other hand, LibreSSL replaced the whole RAND_* API with calls to OpenBSD's arc4random(). This is a nice and simple scheme that uses ChaCha20 to mix the internal RNG state, which is regularly reseeded from the system RNG. The core logic of this (excluding ChaCha20 and platform-specific bits) is implemented in less than 200 lines of code and, at least in theory, it's the one that provides the best performance/simplicity trade-off (ChaCha20 can be pretty fast even for non-asm platform-generic implementations). Both of these methods are robust and mostly platform-indipendent (e.g. none of them uses the system time, PID or uninitilized buffers to seed the RNG state) and have simple implementations, so I think OpenSSL can benefit a lot from adopting one of them. The astute readers may point out that OpenSSL doesn't support ChaCha20 yet, but that's hopefully coming soon. I think there's also room for improvement in the platform-specific RAND_poll() implementations, e.g.: - on Linux getrandom() should be used if available - on OpenBSD getentropy() should be used instead of arc4random() - the /dev/urandom code IMO can be simplified - the non-CryptGenRandom() code on Windows is just crazy. Do we even support Windows versions before XP? - is EGD actually used anywhere today? - what about Netware, OS/2 and VMS, do we have any users on them? IIRC support for other platforms has already been removed, what are the criteria for keeping support for one? - etc... For comparison, OpenBSD's getentropy() implementation [0] is much cleaner and supports many of the platforms supported by OpenSSL. So, any thought? If there's interest in this, I can look into investigating these things more in detail and propose possible patches. Cheers [0] https://github.com/libressl-portable/openbsd/tree/master/src/lib/libcrypto/crypto -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From tmraz at redhat.com Fri Oct 23 13:38:51 2015 From: tmraz at redhat.com (Tomas Mraz) Date: Fri, 23 Oct 2015 15:38:51 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023132238.GA32506@kronk.local> References: <20151023132238.GA32506@kronk.local> Message-ID: <1445607531.28080.16.camel@redhat.com> On P?, 2015-10-23 at 15:22 +0200, Alessandro Ghedini wrote: ... > BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to > RAND_bytes(). Additionally, if the RDRAND instruction is available, the output > of RDRAND is mixed with the output of the system RNG using ChaCha20. This uses > thread-local storage to keep the global RNG state. ... > The BoringSSL method is very simple but it needs a read from /dev/urandom for > every call to RAND_bytes() which can be slow (though, BoringSSL's RAND_bytes() > seems to implement some sort of buffering for /dev/urandom so the cost may be > lower). > > On the other hand, LibreSSL replaced the whole RAND_* API with calls to > OpenBSD's arc4random(). This is a nice and simple scheme that uses ChaCha20 to > mix the internal RNG state, which is regularly reseeded from the system RNG. > The core logic of this (excluding ChaCha20 and platform-specific bits) is > implemented in less than 200 lines of code and, at least in theory, it's the > one that provides the best performance/simplicity trade-off (ChaCha20 can be > pretty fast even for non-asm platform-generic implementations). > > Both of these methods are robust and mostly platform-indipendent (e.g. none of > them uses the system time, PID or uninitilized buffers to seed the RNG state) > and have simple implementations, so I think OpenSSL can benefit a lot from > adopting one of them. The astute readers may point out that OpenSSL doesn't > support ChaCha20 yet, but that's hopefully coming soon. How these libraries handle generation of random numbers after the fork()? The mixing in of the system time & PID before pulling bytes from RNG prevents sharing two identical streams of random numbers among forked processes. If there is a buffering of data pulled from the kernel RNG it is not sufficient to just say that all the data are pulled from the kernel and thus unique. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From alessandro at ghedini.me Fri Oct 23 14:00:51 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Fri, 23 Oct 2015 16:00:51 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <1445607531.28080.16.camel@redhat.com> References: <20151023132238.GA32506@kronk.local> <1445607531.28080.16.camel@redhat.com> Message-ID: <20151023140051.GA14295@kronk.local> On Fri, Oct 23, 2015 at 03:38:51pm +0200, Tomas Mraz wrote: > On P?, 2015-10-23 at 15:22 +0200, Alessandro Ghedini wrote: > ... > > BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to > > RAND_bytes(). Additionally, if the RDRAND instruction is available, the output > > of RDRAND is mixed with the output of the system RNG using ChaCha20. This uses > > thread-local storage to keep the global RNG state. > ... > > The BoringSSL method is very simple but it needs a read from /dev/urandom for > > every call to RAND_bytes() which can be slow (though, BoringSSL's RAND_bytes() > > seems to implement some sort of buffering for /dev/urandom so the cost may be > > lower). > > > > On the other hand, LibreSSL replaced the whole RAND_* API with calls to > > OpenBSD's arc4random(). This is a nice and simple scheme that uses ChaCha20 to > > mix the internal RNG state, which is regularly reseeded from the system RNG. > > The core logic of this (excluding ChaCha20 and platform-specific bits) is > > implemented in less than 200 lines of code and, at least in theory, it's the > > one that provides the best performance/simplicity trade-off (ChaCha20 can be > > pretty fast even for non-asm platform-generic implementations). > > > > Both of these methods are robust and mostly platform-indipendent (e.g. none of > > them uses the system time, PID or uninitilized buffers to seed the RNG state) > > and have simple implementations, so I think OpenSSL can benefit a lot from > > adopting one of them. The astute readers may point out that OpenSSL doesn't > > support ChaCha20 yet, but that's hopefully coming soon. > > How these libraries handle generation of random numbers after the > fork()? The mixing in of the system time & PID before pulling bytes from > RNG prevents sharing two identical streams of random numbers among > forked processes. If there is a buffering of data pulled from the kernel > RNG it is not sufficient to just say that all the data are pulled from > the kernel and thus unique. So, it seems that BoringSSL's /dev/urandom buffering is disabled by default and needs to be explicitly enabled by calling RAND_enable_fork_unsafe_buffering(). arc4random() detects forks by registering a pthread_atfork() handler and/or by checking changes in getpid() output before returning any randomness. When a fork is detected, the internal state is automatically re-seeded with the system RNG. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rsalz at akamai.com Fri Oct 23 14:30:14 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Oct 2015 14:30:14 +0000 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023132238.GA32506@kronk.local> References: <20151023132238.GA32506@kronk.local> Message-ID: <22408147cb5e49f9b051d09a6f440ef8@ustx2ex-dag1mb3.msg.corp.akamai.com> I am very interested in cleaning this area up. We still do care about Netware, OS/2, and VMS; I don't think we care about pre-XP Windows. We have broader portability issues than boringSSL does, so my thoughts on threading are different: two builds, either "not threaded" or "use native system threads" and internally use an API that is a very small thin layer per-OS. From laurenz.albe at wien.gv.at Fri Oct 23 14:33:54 2015 From: laurenz.albe at wien.gv.at (Albe Laurenz) Date: Fri, 23 Oct 2015 14:33:54 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> <56275DFC.3050404@openssl.org> Message-ID: Matt Caswell wrote: > On 16/10/15 16:05, Hubert Kario via RT wrote: >> we may actually be able to patch this up partially in 1.0.x >> >> the original problem description mentions server being unable to process >> application data before Certificate/Client Key Exchange, not in any >> place what so ever >> >> (Albe, please double check if you didn't saw Java sending app data at >> any different point) >> >> unless the server is completely asynchronous, it's unlikely it will send >> application data messages between handshake messages from a single >> flight, it will send app data only between different flights >> >> in other words, we should still be able to accept this data before the >> client responses had any chance to modify the certificates in the >> server. > > I think this is also not safe, in a slight amendment to my previous exploit. > > Imagine an attacker who is able to eavesdrop on messages between a > legitimate client who presents a client certificate to the server during > the initial handshake. As it is during the initial handshake this > happens in the clear, including the server responding with a session id. > > Ordinarily knowing the session id does not help very much because the > attacker does not know the associated keys so any attempt to reuse that > session id will fail. However with the proposed patch in place the > attacker can first establish a connection to the server anonymously. > Then they send a new ClientHello, but this time provide the eavesdropped > session id. The server updates the s->session value from the session > cache which *includes* the peer certificate. The exploit can then > proceed as before. The attacker does not continue the renegotiation > handshake but instead sends application data attempting a privileged > operation and the server application successfully verifies the identity. Do you mean that the attacker pretends to be the legitimate client and initiates renegotiation on their behalf? I thought that the ClientHello would have to be encrypted in that case, something which the attacker couldn't do. If I misunderstood and that is indeed not safe, wouldn't that mean that sending application data interleaved with renegotiation, like Java does, is a security leak? In that case it should be reported to Oracle. Yours, Laurenz Albe From rt at openssl.org Fri Oct 23 14:34:07 2015 From: rt at openssl.org (Albe Laurenz via RT) Date: Fri, 23 Oct 2015 14:34:07 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> <56275DFC.3050404@openssl.org> Message-ID: Matt Caswell wrote: > On 16/10/15 16:05, Hubert Kario via RT wrote: >> we may actually be able to patch this up partially in 1.0.x >> >> the original problem description mentions server being unable to process >> application data before Certificate/Client Key Exchange, not in any >> place what so ever >> >> (Albe, please double check if you didn't saw Java sending app data at >> any different point) >> >> unless the server is completely asynchronous, it's unlikely it will send >> application data messages between handshake messages from a single >> flight, it will send app data only between different flights >> >> in other words, we should still be able to accept this data before the >> client responses had any chance to modify the certificates in the >> server. > > I think this is also not safe, in a slight amendment to my previous exploit. > > Imagine an attacker who is able to eavesdrop on messages between a > legitimate client who presents a client certificate to the server during > the initial handshake. As it is during the initial handshake this > happens in the clear, including the server responding with a session id. > > Ordinarily knowing the session id does not help very much because the > attacker does not know the associated keys so any attempt to reuse that > session id will fail. However with the proposed patch in place the > attacker can first establish a connection to the server anonymously. > Then they send a new ClientHello, but this time provide the eavesdropped > session id. The server updates the s->session value from the session > cache which *includes* the peer certificate. The exploit can then > proceed as before. The attacker does not continue the renegotiation > handshake but instead sends application data attempting a privileged > operation and the server application successfully verifies the identity. Do you mean that the attacker pretends to be the legitimate client and initiates renegotiation on their behalf? I thought that the ClientHello would have to be encrypted in that case, something which the attacker couldn't do. If I misunderstood and that is indeed not safe, wouldn't that mean that sending application data interleaved with renegotiation, like Java does, is a security leak? In that case it should be reported to Oracle. Yours, Laurenz Albe From Matthias.St.Pierre at ncp-e.com Fri Oct 23 14:34:11 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Fri, 23 Oct 2015 16:34:11 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023132238.GA32506@kronk.local> References: <20151023132238.GA32506@kronk.local> Message-ID: <562A4563.3040902@ncp-e.com> Hi, I have a related question concerning alternative RNGs, hope it is not too off-topic: Currently we are using the NIST-SP800-90a compliant DRBG (FIPS_drbg_method()), because it seemed to us to be more sophisticated and mature than the default RAND_SSLeay(). At least it's better documented and tested. Currently this DRBG is only available through the FIPS object module, so you need to build a FIPS capable OpenSSL library in order to use it. Shouldn't the FIPS DRBG code be added to the normal code base in master, too, as an alternative RNG implemtation? Or is the NIST-SP800-90a DRG construction already obsolete outside of FIPS world? Regards, Matthias From loganaden at gmail.com Fri Oct 23 14:34:19 2015 From: loganaden at gmail.com (Loganaden Velvindron) Date: Fri, 23 Oct 2015 18:34:19 +0400 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023132238.GA32506@kronk.local> References: <20151023132238.GA32506@kronk.local> Message-ID: On Fri, Oct 23, 2015 at 5:22 PM, Alessandro Ghedini wrote: > Hello everyone, > > ... > > For comparison, OpenBSD's getentropy() implementation [0] is much cleaner > and > supports many of the platforms supported by OpenSSL. > > So, any thought? If there's interest in this, I can look into investigating > these things more in detail and propose possible patches. > > LibreSSL has been tested on a wider range of platforms. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Oct 23 14:40:29 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 23 Oct 2015 17:40:29 +0300 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023132238.GA32506@kronk.local> References: <20151023132238.GA32506@kronk.local> Message-ID: Hello Alexander, On Fri, Oct 23, 2015 at 4:22 PM, Alessandro Ghedini wrote: > So, any thought? If there's interest in this, I can look into investigating > these things more in detail and propose possible patches. > > In Russia we have to certify the RNG hardware and software for using in organizations where the certified products are required. Currently we are able to implement custom RAND_METHODs and provide it via engines. So if the hardware is unavailable, the RAND_bytes() call fails. In the 1.0.* versions of the OpenSSL library not all calls to RAND* functions were checked for success, and it caused some problems. LibreSSL treats their RNG functions as never-failed, and I do not know about BoringSSL. So we need non-void RAND API and possibility to provide our own RAND_METHODs. If the current code is to be refactored, I ask to leave these options possible. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro at ghedini.me Fri Oct 23 17:06:30 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Fri, 23 Oct 2015 19:06:30 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <22408147cb5e49f9b051d09a6f440ef8@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <20151023132238.GA32506@kronk.local> <22408147cb5e49f9b051d09a6f440ef8@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <20151023170630.GA7014@kronk.local> On Fri, Oct 23, 2015 at 02:30:14pm +0000, Salz, Rich wrote: > I am very interested in cleaning this area up. We still do care about > Netware, OS/2, and VMS; I don't think we care about pre-XP Windows. Ok. > We have broader portability issues than boringSSL does, so my thoughts on > threading are different: two builds, either "not threaded" or "use native > system threads" and internally use an API that is a very small thin layer > per-OS. Yes, that's what BoringSSL does. They have three implementations: pthread, windows and none (which is just nops). I don't know what the availability of pthreads is on the above platforms (NW, OS/2 and VMS), but it should cover quite a bit of platforms. Basically they deprecated the current CRYPTO_lock and CRYPTO_THREADID API, and replaced that with mutex objects (CRYPTO_MUTEX). Additionally, this API provides thread-local storage support and "once" objects (to execute functions only once, for example for initialization). On top of the CRYPTO_MUTEX they added a reference counting API (which can use C11 atomics instead of mutexes), but this is not used a lot so it can be ignored for now. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From alessandro at ghedini.me Fri Oct 23 17:07:21 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Fri, 23 Oct 2015 19:07:21 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: References: <20151023132238.GA32506@kronk.local> Message-ID: <20151023170721.GB7014@kronk.local> On Fri, Oct 23, 2015 at 05:40:29PM +0300, Dmitry Belyavsky wrote: > Hello Alexander, > > On Fri, Oct 23, 2015 at 4:22 PM, Alessandro Ghedini > wrote: > > > > So, any thought? If there's interest in this, I can look into investigating > > these things more in detail and propose possible patches. > > > > > In Russia we have to certify the RNG hardware and software for using in > organizations where the certified products are required. > Currently we are able to implement custom RAND_METHODs and provide it via > engines. So if the hardware is unavailable, the RAND_bytes() call fails. > > In the 1.0.* versions of the OpenSSL library not all calls to RAND* > functions were checked for success, and it caused some problems. > LibreSSL treats their RNG functions as never-failed, and I do not know > about BoringSSL. > > So we need non-void RAND API and possibility to provide our own > RAND_METHODs. If the current code is to be refactored, I ask to leave these > options possible. Yeah, the idea is to keep the current ENGINE API, and only change the default RAND_METHOD which is returned by RAND_SSLeay(). So if you use any other RNG this change shouldn't affect you. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rsalz at akamai.com Fri Oct 23 17:13:02 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Oct 2015 17:13:02 +0000 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023170630.GA7014@kronk.local> References: <20151023132238.GA32506@kronk.local> <22408147cb5e49f9b051d09a6f440ef8@ustx2ex-dag1mb3.msg.corp.akamai.com> <20151023170630.GA7014@kronk.local> Message-ID: <39bc0fd8f5224db2a95c34aba63e0396@ustx2ex-dag1mb3.msg.corp.akamai.com> > Yes, that's what BoringSSL does. They have three implementations: pthread, > windows and none (which is just nops). I don't know what the availability of > pthreads is on the above platforms (NW, OS/2 and VMS), but it should cover > quite a bit of platforms. I'd instead have two: native or none. Where hopefully native is mostly pthreads, but for NW,OS/2,VMS it can at least start at as none. > Basically they deprecated the current CRYPTO_lock and CRYPTO_THREADID > API, and replaced that with mutex objects (CRYPTO_MUTEX). Not sure about that, I could be persuaded either way, for CRYPTO_lock. The THREADID might need to stay for platform portability. > Additionally, > this API provides thread-local storage support and "once" objects (to > execute functions only once, for example for initialization). I'd probably leave thread-local storage up to the application. But the once stuff would be useful *iff and only iff we used it to make initialization simpler.* > On top of the CRYPTO_MUTEX they added a reference counting API (which > can use > C11 atomics instead of mutexes), but this is not used a lot so it can be ignored > for now. We already have CRYPTO_add ... From alessandro at ghedini.me Fri Oct 23 17:19:11 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Fri, 23 Oct 2015 19:19:11 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <562A4563.3040902@ncp-e.com> References: <20151023132238.GA32506@kronk.local> <562A4563.3040902@ncp-e.com> Message-ID: <20151023171911.GA7805@kronk.local> On Fri, Oct 23, 2015 at 04:34:11PM +0200, Dr. Matthias St. Pierre wrote: > > Hi, > > I have a related question concerning alternative RNGs, hope it is not too > off-topic: > > Currently we are using the NIST-SP800-90a compliant DRBG (fips_drbg_method()), > because it seemed to us to be more sophisticated and mature than the default > RAND_SSLeay(). At least it's better documented and tested. > > Currently this DRBG is only available through the FIPS object module, so you > need to build a FIPS capable OpenSSL library in order to use it. > > Shouldn't the FIPS DRBG code be added to the normal code base in master, too, > as an alternative RNG implemtation? Or is the NIST-SP800-90a DRG construction > already obsolete outside of FIPS world? FWIW, the FIPS module was recently removed, so FIPS_drbg_method() is not present in master anymore. I think there are plans to reimplement the whole thing, but I don't know anything about that. In general the NIST DRBGs seem fairly complicated (or completely untrustworthy like Dual EC DRBG), so I'd rather have a different implementation as default RNG for OpenSSL. Cheers -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vijju.singh at gmail.com Fri Oct 23 18:38:00 2015 From: vijju.singh at gmail.com (Vijay Singh) Date: Fri, 23 Oct 2015 18:38:00 +0000 Subject: [openssl-dev] AAD length with AES cipher Message-ID: It seems that the library uses 13 bytes of AAD data. Is this per-spec? The reason I am asking is that the new Intel AESNI APIs that provide HW support seem to require AAD as a multiple of 4 bytes, and 0 padding the AAD changes the computed auth value. Any insights are much appreciated. -vijay -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Fri Oct 23 18:57:10 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 23 Oct 2015 20:57:10 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023132238.GA32506@kronk.local> References: <20151023132238.GA32506@kronk.local> Message-ID: <20151023185710.GA17804@roeckx.be> On Fri, Oct 23, 2015 at 03:22:39PM +0200, Alessandro Ghedini wrote: > Hello everyone, > > (sorry for the wall of text...) > > one of the things that both BoringSSL and LibreSSL have in common is the > replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner > alternative. Given RAND_SSLeay() complexity I think it'd be worth to at least > consider possible alternatives for OpenSSL. I think at least a few of us want to see something changed, but I'm not sure what direction it's going to go. > BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to > RAND_bytes(). Additionally, if the RDRAND instruction is available, the output > of RDRAND is mixed with the output of the system RNG using ChaCha20. This uses > thread-local storage to keep the global RNG state. The problem with only relying on /dev/urandom on Linux is that it can give you data without having had enough entropy feed in it first. At least getrandom() will fix that, but that's only in the kernel since 3.17 and a lot of people still don't have that. But maybe most people will actually have it on systems that are going to run 1.1. This is of course not a new problem, we also already have that now. I think some people have concerns about only relying on the OSs RNG and instead want to get a high entropy seed from it and use that to feed our own RNG. We might use a better (by whatever definition) algorithm than the kernel is using. Only using /dev/urandom might result in people complaining that we start to drain their available entropy. I don't know enough about the Linux kernel's implementation of the RNG, but their calculation just seems wrong to me. > Incidentally, BoringSSL added a whole new API for thread-local storage which > OpenSSL could adopt given that e.g. the ASYNC support could benefit from it > (there are other interesting bits in BoringSSL, like the new threading API that > could also be adopted by OpenSSL). Threads, and so thread-local storage, is all very OS specific. And I'm afraid we don't have that on all platforms we still want to support. But I think that belongs in a different discussion. > The BoringSSL method is very simple but it needs a read from /dev/urandom for > every call to RAND_bytes() which can be slow (though, BoringSSL's RAND_bytes() > seems to implement some sort of buffering for /dev/urandom so the cost may be > lower). An other issue is that /dev/urandom might not be available in a chroot or when you run out of file descriptor. The chroot is at least something the LibreSSL seems to be running in to, but is nothing we can really do about on all OSs. > On the other hand, LibreSSL replaced the whole RAND_* API with calls to > OpenBSD's arc4random(). This is a nice and simple scheme that uses ChaCha20 to > mix the internal RNG state, which is regularly reseeded from the system RNG. I think the arc4random() thing is such a misleading name since it doesn't have anything to do with (A)RC4 anymore. I'm also not sure that the implementation with ChaCha20 is the best way to go, you could also go for something like Fortuna, or stay with whatever we use now. We currently don't reseed, and I have no idea what amount of data we should be able to safely extract from it now, I think it's rather large, but reseeding should never hurt. Kurt From dragon at dancingdragon.be Fri Oct 23 19:26:01 2015 From: dragon at dancingdragon.be (Joey Yandle) Date: Fri, 23 Oct 2015 12:26:01 -0700 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023132238.GA32506@kronk.local> References: <20151023132238.GA32506@kronk.local> Message-ID: <562A89C9.2070809@dancingdragon.be> > - the non-CryptGenRandom() code on Windows is just crazy. Do we even support > Windows versions before XP? Some of that code really needs to go away, specifically the heap walk code. It is extremely unsafe, and crashes ~66% of the time when running under the Visual Studio debugger. There's nothing OpenSSL can do about the crashes, because they occur deep in ntdll code. It used to be possible to avoid calling RAND_poll on windows, via RAND_screen etc (at least that's what Mr Google thinks). But RAND_screen now *calls* RAND_poll. And ssleay_get_rand_bytes has a weird static local variable that guarantees calling RAND_poll at least once even if you preseed the RNG via RAND_add. I removed the heap walk and all the other insane kernel loading code from my local tree, and just do the CryptGenRandom and the mixins at the end (pid, etc). I'd strongly suggest doing something similar in the future. cheers, Joey From bkaduk at akamai.com Fri Oct 23 21:32:35 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 23 Oct 2015 16:32:35 -0500 Subject: [openssl-dev] AAD length with AES cipher In-Reply-To: References: Message-ID: <562AA773.8080808@akamai.com> On 10/23/2015 01:38 PM, Vijay Singh wrote: > > It seems that the library uses 13 bytes of AAD data. Is this per-spec? > The reason I am asking is that the new Intel AESNI APIs that provide > HW support seem to require AAD as a multiple of 4 bytes, and 0 padding > the AAD changes the computed auth value. > Sorry, is the claim that the authentication tag is 13 bytes, or that some portion of the codebase is supplying additional authenticated data of length 13 bytes, or something else? OpenSSL does make use of the AESNI APIs for GCM, so it is not clear where you are observing this seemingly incompatible behavior. > Any insights are much appreciated. > > That will be difficult without better pointers to what behavior your are observing. -Ben Kaduk -------------- next part -------------- An HTML attachment was scrubbed... URL: From bl4ck5unxx at gmail.com Fri Oct 23 21:27:37 2015 From: bl4ck5unxx at gmail.com (Fan Zhang) Date: Fri, 23 Oct 2015 17:27:37 -0400 Subject: [openssl-dev] Guidance on browsing code base Message-ID: <6D21DB08-D94A-465D-9D0A-BED10191522A@gmail.com> Hi, all, Happy to meet your guys by this email. I?m trying to dig into the code base and find an implementation of RSA signature. Naturally, I looked into the function `int RSA_sign` in file `crypto/rsa/rsa_sign.c`, which further calls the `RSA_private_encrypt` and `RSA_private_encrypt` calls the method `rsa_priv_enc` in `rsa->meth`. 83 int RSA_private_encrypt(int flen, const unsigned char *from, 84 unsigned char *to, RSA *rsa, int padding) 85 { 86 return (rsa->meth->rsa_priv_enc(flen, from, to, rsa, padding)); 87 } After this, I got lost. I couldn't find when `rsa->meth` is initialized. Or maybe more directly, where is the actual code implementing the `rsa_priv_enc`? Thanks in advance! Best Fan Sent from my iPhone From bkaduk at akamai.com Fri Oct 23 21:50:19 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 23 Oct 2015 16:50:19 -0500 Subject: [openssl-dev] Guidance on browsing code base In-Reply-To: <6D21DB08-D94A-465D-9D0A-BED10191522A@gmail.com> References: <6D21DB08-D94A-465D-9D0A-BED10191522A@gmail.com> Message-ID: <562AAB9B.1070506@akamai.com> On 10/23/2015 04:27 PM, Fan Zhang wrote: > Hi, all, > > Happy to meet your guys by this email. I?m trying to dig into the code base and find an implementation of RSA signature. Naturally, I looked into the function `int RSA_sign` in file `crypto/rsa/rsa_sign.c`, which further calls the `RSA_private_encrypt` and `RSA_private_encrypt` calls the method `rsa_priv_enc` in `rsa->meth`. > > 83 int RSA_private_encrypt(int flen, const unsigned char *from, > 84 unsigned char *to, RSA *rsa, int padding) > 85 { > 86 return (rsa->meth->rsa_priv_enc(flen, from, to, rsa, padding)); > 87 } > > After this, I got lost. I couldn't find when `rsa->meth` is initialized. Or maybe more directly, where is the actual code implementing the `rsa_priv_enc`? Thanks in advance! > *rsa->meth is of type RSA_METHOD, which is a thing to search for. In particular, check out crypto/rsa/rsa_eay.c. -Ben Kaduk From rt at openssl.org Fri Oct 23 22:19:21 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 23 Oct 2015 22:19:21 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <562AB264.9020409@openssl.org> References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> <56275DFC.3050404@openssl.org> <562AB264.9020409@openssl.org> Message-ID: On 23/10/15 15:33, Albe Laurenz wrote: > Matt Caswell wrote: >> On 16/10/15 16:05, Hubert Kario via RT wrote: >>> we may actually be able to patch this up partially in 1.0.x >>> >>> the original problem description mentions server being unable to process >>> application data before Certificate/Client Key Exchange, not in any >>> place what so ever >>> >>> (Albe, please double check if you didn't saw Java sending app data at >>> any different point) >>> >>> unless the server is completely asynchronous, it's unlikely it will send >>> application data messages between handshake messages from a single >>> flight, it will send app data only between different flights >>> >>> in other words, we should still be able to accept this data before the >>> client responses had any chance to modify the certificates in the >>> server. >> >> I think this is also not safe, in a slight amendment to my previous exploit. >> >> Imagine an attacker who is able to eavesdrop on messages between a >> legitimate client who presents a client certificate to the server during >> the initial handshake. As it is during the initial handshake this >> happens in the clear, including the server responding with a session id. >> >> Ordinarily knowing the session id does not help very much because the >> attacker does not know the associated keys so any attempt to reuse that >> session id will fail. However with the proposed patch in place the >> attacker can first establish a connection to the server anonymously. >> Then they send a new ClientHello, but this time provide the eavesdropped >> session id. The server updates the s->session value from the session >> cache which *includes* the peer certificate. The exploit can then >> proceed as before. The attacker does not continue the renegotiation >> handshake but instead sends application data attempting a privileged >> operation and the server application successfully verifies the identity. > > Do you mean that the attacker pretends to be the legitimate client > and initiates renegotiation on their behalf? > > I thought that the ClientHello would have to be encrypted in that case, > something which the attacker couldn't do. No, that's not what I meant. The attacker eavesdrops on the initial handshake between a legitimate client (where that client has presented a certificate) and the server and makes a note of the session id. The attacker then creates a completely new anonymous connection (they don't use the session id yet). Then they initiate a renegotiation, but this time present the stolen session id. Before they complete the reneg handshake they start sending application data. That application data will be processed by the server application in the context of the certificate associated with the stolen session, but before the CCS has been processed. Matt From bkaduk at akamai.com Fri Oct 23 22:44:50 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 23 Oct 2015 17:44:50 -0500 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023132238.GA32506@kronk.local> References: <20151023132238.GA32506@kronk.local> Message-ID: <562AB862.9030508@akamai.com> On 10/23/2015 08:22 AM, Alessandro Ghedini wrote: > Hello everyone, > > (sorry for the wall of text...) > > one of the things that both BoringSSL and LibreSSL have in common is the > replacement of OpenSSL's default RNG RAND_SSLeay() with a simpler and saner > alternative. Given RAND_SSLeay() complexity I think it'd be worth to at least > consider possible alternatives for OpenSSL. I heartily support this; the existing RAND_SSLeay() is a bit frightening (though I take some solace in the existence of ENGINE_rdrand()). > BoringSSL started using the system RNG (e.g. /dev/urandom) for every call to > RAND_bytes(). Additionally, if the RDRAND instruction is available, the output > of RDRAND is mixed with the output of the system RNG using ChaCha20. This uses > thread-local storage to keep the global RNG state. /dev/urandom is simple and safe absent the chroot case. (Note that capsicum-using applications will frequently open a fd for /dev/urandom before entering capability mode and leave it open; the same might be worth considering.) Concerns about "running out of entropy" are unfounded; the kernel uses a CS-PRNG and if we trust its output to seed our own scheme, we can trust its output indefinitely. Intel recommends calling RDRAND in a loop since it does not always return successfully, and IIRC best practice is to mix it in with other inputs (i.e., not use it directly). > Incidentally, BoringSSL added a whole new API for thread-local storage which > OpenSSL could adopt given that e.g. the ASYNC support could benefit from it > (there are other interesting bits in BoringSSL, like the new threading API that > could also be adopted by OpenSSL). > > The BoringSSL method is very simple but it needs a read from /dev/urandom for > every call to RAND_bytes() which can be slow (though, BoringSSL's RAND_bytes() > seems to implement some sort of buffering for /dev/urandom so the cost may be > lower). Keeping the default method simple, slow, and reliable could be a reasonable approach, given that there is always the option of inserting an alternate implementation if performance is a concern. ("Simple" probably means "rely on the kernel for everything, do not use thread-local storage, etc.") It might also be worth having a more complicated scheme that does use thread-local storage (on systems where we know how to implement it) and runs fortuna or something similar, but that does not necessarily need to be the default implementation, in my opinion. > > On the other hand, LibreSSL replaced the whole RAND_* API with calls to > OpenBSD's arc4random(). This is a nice and simple scheme that uses ChaCha20 to > mix the internal RNG state, which is regularly reseeded from the system RNG. > The core logic of this (excluding ChaCha20 and platform-specific bits) is > implemented in less than 200 lines of code and, at least in theory, it's the > one that provides the best performance/simplicity trade-off (ChaCha20 can be > pretty fast even for non-asm platform-generic implementations). A single syscall to get entropy is nice, whether it's a sysctl node, getentropy(), getrandom(), or some other spelling; a library call like arc4random() is almost as good. But I don't think we're in a position to rip out the RAND_* API layer as LibreSSL did. > Both of these methods are robust and mostly platform-indipendent (e.g. none of > them uses the system time, PID or uninitilized buffers to seed the RNG state) > and have simple implementations, so I think OpenSSL can benefit a lot from > adopting one of them. The astute readers may point out that OpenSSL doesn't > support ChaCha20 yet, but that's hopefully coming soon. > > I think there's also room for improvement in the platform-specific RAND_poll() > implementations, e.g.: > > - on Linux getrandom() should be used if available > - on OpenBSD getentropy() should be used instead of arc4random() > - the /dev/urandom code IMO can be simplified > - the non-CryptGenRandom() code on Windows is just crazy. Do we even support > Windows versions before XP? > - is EGD actually used anywhere today? "I really hope not." > - what about Netware, OS/2 and VMS, do we have any users on them? IIRC support > for other platforms has already been removed, what are the criteria for > keeping support for one? > - etc... > > For comparison, OpenBSD's getentropy() implementation [0] is much cleaner and > supports many of the platforms supported by OpenSSL. > > So, any thought? If there's interest in this, I can look into investigating > these things more in detail and propose possible patches. > I'll just note in closing that there are a number of "fortuna-like" implementations out there that are not actually fortuna, for example, were implemented based off of the wikipedia article and not the actual textbook. https://github.com/krb5/krb5/blob/master/src/lib/crypto/krb/prng_fortuna.c was implemented from _Cryptography Engineering_, and I think https://github.com/freebsd/freebsd/blob/master/sys/dev/random/fortuna.c is another. -Ben From pwalten at au1.ibm.com Sat Oct 24 02:41:11 2015 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Sat, 24 Oct 2015 02:41:11 +0000 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <562AB862.9030508@akamai.com> References: <562AB862.9030508@akamai.com>, <20151023132238.GA32506@kronk.local> Message-ID: <201510240242.t9O2gAwR009387@d23av04.au.ibm.com> An HTML attachment was scrubbed... URL: From bl4ck5unxx at gmail.com Sat Oct 24 02:44:56 2015 From: bl4ck5unxx at gmail.com (Fan Zhang) Date: Fri, 23 Oct 2015 22:44:56 -0400 Subject: [openssl-dev] Guidance on browsing code base In-Reply-To: <562AAB9B.1070506@akamai.com> References: <6D21DB08-D94A-465D-9D0A-BED10191522A@gmail.com> <562AAB9B.1070506@akamai.com> Message-ID: Thanks that seems to be the right place to look into. btw, what does eay stand for? > On Oct 23, 2015, at 5:50 PM, Benjamin Kaduk wrote: > > On 10/23/2015 04:27 PM, Fan Zhang wrote: >> Hi, all, >> >> Happy to meet your guys by this email. I?m trying to dig into the code base and find an implementation of RSA signature. Naturally, I looked into the function `int RSA_sign` in file `crypto/rsa/rsa_sign.c`, which further calls the `RSA_private_encrypt` and `RSA_private_encrypt` calls the method `rsa_priv_enc` in `rsa->meth`. >> >> 83 int RSA_private_encrypt(int flen, const unsigned char *from, >> 84 unsigned char *to, RSA *rsa, int padding) >> 85 { >> 86 return (rsa->meth->rsa_priv_enc(flen, from, to, rsa, padding)); >> 87 } >> >> After this, I got lost. I couldn't find when `rsa->meth` is initialized. Or maybe more directly, where is the actual code implementing the `rsa_priv_enc`? Thanks in advance! >> > > *rsa->meth is of type RSA_METHOD, which is a thing to search for. > > In particular, check out crypto/rsa/rsa_eay.c. > > -Ben Kaduk > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From bkaduk at akamai.com Sat Oct 24 02:47:00 2015 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Fri, 23 Oct 2015 21:47:00 -0500 Subject: [openssl-dev] Guidance on browsing code base In-Reply-To: References: <6D21DB08-D94A-465D-9D0A-BED10191522A@gmail.com> <562AAB9B.1070506@akamai.com> Message-ID: <562AF124.7030207@akamai.com> EAY is Eric A. Young, the original author of SSLeay, which became OpenSSL. https://en.wikipedia.org/wiki/SSLeay -Ben On 10/23/2015 09:44 PM, Fan Zhang wrote: > Thanks that seems to be the right place to look into. > > btw, what does eay stand for? > >> On Oct 23, 2015, at 5:50 PM, Benjamin Kaduk wrote: >> >> On 10/23/2015 04:27 PM, Fan Zhang wrote: >>> Hi, all, >>> >>> Happy to meet your guys by this email. I?m trying to dig into the code base and find an implementation of RSA signature. Naturally, I looked into the function `int RSA_sign` in file `crypto/rsa/rsa_sign.c`, which further calls the `RSA_private_encrypt` and `RSA_private_encrypt` calls the method `rsa_priv_enc` in `rsa->meth`. >>> >>> 83 int RSA_private_encrypt(int flen, const unsigned char *from, >>> 84 unsigned char *to, RSA *rsa, int padding) >>> 85 { >>> 86 return (rsa->meth->rsa_priv_enc(flen, from, to, rsa, padding)); >>> 87 } >>> >>> After this, I got lost. I couldn't find when `rsa->meth` is initialized. Or maybe more directly, where is the actual code implementing the `rsa_priv_enc`? Thanks in advance! >>> >> *rsa->meth is of type RSA_METHOD, which is a thing to search for. >> >> In particular, check out crypto/rsa/rsa_eay.c. >> >> -Ben Kaduk >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Sat Oct 24 13:06:35 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 24 Oct 2015 13:06:35 +0000 Subject: [openssl-dev] [openssl.org #4090] [PATCH] Assorted fixes In-Reply-To: <20151012131013.GA2747@kronk.local> References: <20151012131013.GA2747@kronk.local> Message-ID: Closed; GH436 was merged. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Oct 24 13:07:16 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 24 Oct 2015 13:07:16 +0000 Subject: [openssl-dev] [openssl.org #4081] crypto/evp/e_dsa.c is orphaned In-Reply-To: <56169769.4010407@akamai.com> References: <56169769.4010407@akamai.com> Message-ID: Closed; GH436 was merged. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat Oct 24 13:07:48 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 24 Oct 2015 13:07:48 +0000 Subject: [openssl-dev] [openssl.org #4068] Bug ocsp - bio_get_fd In-Reply-To: References: Message-ID: Closed; GH436 was merged. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From alessandro at ghedini.me Sat Oct 24 14:22:38 2015 From: alessandro at ghedini.me (Alessandro Ghedini) Date: Sat, 24 Oct 2015 16:22:38 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <39bc0fd8f5224db2a95c34aba63e0396@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <20151023132238.GA32506@kronk.local> <22408147cb5e49f9b051d09a6f440ef8@ustx2ex-dag1mb3.msg.corp.akamai.com> <20151023170630.GA7014@kronk.local> <39bc0fd8f5224db2a95c34aba63e0396@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <20151024142238.GA3787@kronk.local> On Fri, Oct 23, 2015 at 05:13:02pm +0000, Salz, Rich wrote: > > Yes, that's what BoringSSL does. They have three implementations: pthread, > > windows and none (which is just nops). I don't know what the availability of > > pthreads is on the above platforms (NW, OS/2 and VMS), but it should cover > > quite a bit of platforms. > > I'd instead have two: native or none. Where hopefully native is mostly > pthreads, but for NW,OS/2,VMS it can at least start at as none. Yeah, I guess both pthread and Windows implementations can both be called "native". FWIW I did a quick research and NW, OS/2 and VMS all seem to support pthreads (but I don't know anything about those platforms, so I may be wrong). > > Basically they deprecated the current CRYPTO_lock and CRYPTO_THREADID > > API, and replaced that with mutex objects (CRYPTO_MUTEX). > > Not sure about that, I could be persuaded either way, for CRYPTO_lock. The > THREADID might need to stay for platform portability. I think it could be possible to implement CRYPTO_MUTEX and thread-local storage support by using CRYPTO_lock and CRYPTO_THREADID, so that could be kept as fallback (e.g. it could be hidden behind OPENSSL_NO_DEPRECATE). Incidentally a big user of the lock and thread-id API is mem_dbg.c, and looking at the code in it I was wondering whether we really need it, considering that now we have better tools to debug memory problems. So at some point I'd like to try and make OPENSSL_malloc & co. aliases for malloc(), realloc() and free() and remove (or deprecate) the custom memory functions... but that's probably a whole different discussion. > > Additionally, > > this API provides thread-local storage support and "once" objects (to > > execute functions only once, for example for initialization). > > I'd probably leave thread-local storage up to the application. FWIW the ASYNC pull request [0] already uses thread-local storage, but instead of using the pthread API (which is probably more portable) it uses the __thread syntax. The ERR_STATE thing could also be simplified a lot by using thread-local storage (and the fallback thread-local support can be implemented using THREADID as it's currently done in ERR_STATE itself, but all the complexity would be moved to its own file, leaving err.c cleaner). > But the once stuff would be useful *iff and only iff we used it to make > initialization simpler.* The RAND code would be an obvious candidate, but even in BoringSSL once objects are not used a lot (not that it would add a lot of code since it would be just a wrapper for pthread_once()). Cheers [0] https://github.com/openssl/openssl/pull/433 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kurt at roeckx.be Sat Oct 24 15:35:22 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 24 Oct 2015 17:35:22 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151024142238.GA3787@kronk.local> References: <20151023132238.GA32506@kronk.local> <22408147cb5e49f9b051d09a6f440ef8@ustx2ex-dag1mb3.msg.corp.akamai.com> <20151023170630.GA7014@kronk.local> <39bc0fd8f5224db2a95c34aba63e0396@ustx2ex-dag1mb3.msg.corp.akamai.com> <20151024142238.GA3787@kronk.local> Message-ID: <20151024153522.GA27797@roeckx.be> On Sat, Oct 24, 2015 at 04:22:38PM +0200, Alessandro Ghedini wrote: > > So at some point I'd like to > try and make OPENSSL_malloc & co. aliases for malloc(), realloc() and free() > and remove (or deprecate) the custom memory functions... but that's probably a > whole different discussion. Please note that at least on Windows you need to have a way that malloc() and free() are called from the same dll. > > > Additionally, > > > this API provides thread-local storage support and "once" objects (to > > > execute functions only once, for example for initialization). > > > > I'd probably leave thread-local storage up to the application. > > FWIW the ASYNC pull request [0] already uses thread-local storage, but instead > of using the pthread API (which is probably more portable) it uses the __thread > syntax. __thread isn't exactly portable, the "__" should make that clear. C11 does add support for threads, but we're still stuck at C89 with some minor extentions. But threading libraries always have to provide a way for thread local storage, and so pthreads provides pthread_key_create(), Windows has TlsAlloc(). Kurt From richard at levitte.org Sat Oct 24 15:41:31 2015 From: richard at levitte.org (Richard Levitte) Date: Sat, 24 Oct 2015 17:41:31 +0200 (CEST) Subject: [openssl-dev] mingw: pkg-config --libs outputs gdi32 before crypto In-Reply-To: <5626EAC3.3060202@yahoo.com> References: <5626EAC3.3060202@yahoo.com> Message-ID: <20151024.174131.477311541507665559.richard@levitte.org> This is quite odd. Just for comparison, I tried the same on my laptop (running Debian): : ; pkg-config --static --libs-only-l openssl -lssl -ldl -lcrypto -ldl My .pc files look like this: : ; cat /usr/lib/x86_64-linux-gnu/pkgconfig/openssl.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib/x86_64-linux-gnu includedir=${prefix}/include Name: OpenSSL Description: Secure Sockets Layer and cryptography libraries and tools Version: 1.0.2d Requires: libssl libcrypto : ; cat /usr/lib/x86_64-linux-gnu/pkgconfig/libssl.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib/x86_64-linux-gnu includedir=${prefix}/include Name: OpenSSL-libssl Description: Secure Sockets Layer and cryptography libraries Version: 1.0.2d Requires.private: libcrypto Libs: -L${libdir} -lssl Libs.private: -ldl Cflags: -I${includedir} : ; cat /usr/lib/x86_64-linux-gnu/pkgconfig/libcrypto.pc prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib/x86_64-linux-gnu includedir=${prefix}/include Name: OpenSSL-libcrypto Description: OpenSSL cryptography library Version: 1.0.2d Requires: Libs: -L${libdir} -lcrypto Libs.private: -ldl Cflags: -I${includedir} As you can see, my '-ldl' is specified the same way as your '-lws2_32 -lgdi32 -lcrypt32' (*). : ; pkg-config --version 0.28 Cheers, Richard (*) quite interestingly, really, as libssl doesn't have any direct dependency with libdl... In message <5626EAC3.3060202 at yahoo.com> on Tue, 20 Oct 2015 21:30:43 -0400, Ray Satiro said: raysatiro> OpenSSL 1.0.2d static built with mingw32. raysatiro> raysatiro> make clean raysatiro> perl ./Configure mingw raysatiro> make depend raysatiro> make raysatiro> make check raysatiro> make install raysatiro> raysatiro> I'm using the pkg-config 0.26 that comes with Strawberry Perl to get raysatiro> the libs when I want to link to OpenSSL: raysatiro> raysatiro> pkg-config --static --libs-only-l openssl raysatiro> -lssl -lws2_32 -lgdi32 -lcrypt32 -lcrypto raysatiro> raysatiro> I see errors related to the order: raysatiro> libcrypto.a(rand_win.o):rand_win.c:(.text+0xeab): undefined reference raysatiro> to `_GetDeviceCaps at 8' raysatiro> raysatiro> I'd expect gdi32 after crypto. The pc files generated by OpenSSL raysatiro> appear to do that but that's not the output pkg-config gives me. I'm raysatiro> not sure if this is an OpenSSL issue or a pkg-config issue. Is anyone raysatiro> else using pkg-config successfully in this configuration? raysatiro> raysatiro> Briefly: raysatiro> raysatiro> openssl.pc raysatiro> ---------- raysatiro> Name: OpenSSL raysatiro> Description: Secure Sockets Layer and cryptography libraries and tools raysatiro> Version: 1.0.2d raysatiro> Requires: libssl libcrypto raysatiro> raysatiro> raysatiro> libcrypto.pc raysatiro> ------------ raysatiro> Name: OpenSSL-libcrypto raysatiro> Description: OpenSSL cryptography library raysatiro> Version: 1.0.2d raysatiro> Requires: raysatiro> Libs: -L${libdir} -lcrypto raysatiro> Libs.private: -lws2_32 -lgdi32 -lcrypt32 raysatiro> Cflags: -I${includedir} raysatiro> raysatiro> raysatiro> libssl.pc raysatiro> --------- raysatiro> Name: OpenSSL-libssl raysatiro> Description: Secure Sockets Layer and cryptography libraries raysatiro> Version: 1.0.2d raysatiro> Requires.private: libcrypto raysatiro> Libs: -L${libdir} -lssl raysatiro> Libs.private: -lws2_32 -lgdi32 -lcrypt32 raysatiro> Cflags: -I${includedir} From meissner at suse.de Sat Oct 24 15:55:44 2015 From: meissner at suse.de (Marcus Meissner) Date: Sat, 24 Oct 2015 17:55:44 +0200 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151023171911.GA7805@kronk.local> References: <20151023132238.GA32506@kronk.local> <562A4563.3040902@ncp-e.com> <20151023171911.GA7805@kronk.local> Message-ID: <20151024155544.GB22128@suse.de> On Fri, Oct 23, 2015 at 07:19:11PM +0200, Alessandro Ghedini wrote: > On Fri, Oct 23, 2015 at 04:34:11PM +0200, Dr. Matthias St. Pierre wrote: > > > > Hi, > > > > I have a related question concerning alternative RNGs, hope it is not too > > off-topic: > > > > Currently we are using the NIST-SP800-90a compliant DRBG (fips_drbg_method()), > > because it seemed to us to be more sophisticated and mature than the default > > RAND_SSLeay(). At least it's better documented and tested. > > > > Currently this DRBG is only available through the FIPS object module, so you > > need to build a FIPS capable OpenSSL library in order to use it. > > > > Shouldn't the FIPS DRBG code be added to the normal code base in master, too, > > as an alternative RNG implemtation? Or is the NIST-SP800-90a DRG construction > > already obsolete outside of FIPS world? > > FWIW, the FIPS module was recently removed, so FIPS_drbg_method() is not present > in master anymore. I think there are plans to reimplement the whole thing, but > I don't know anything about that. > > In general the NIST DRBGs seem fairly complicated (or completely untrustworthy > like Dual EC DRBG), so I'd rather have a different implementation as default > RNG for OpenSSL. Well, the Dual EC has been removed from the guidance. The other 3 modes described in NIST 800-90a make sense though. I suggest to read the standard, the main things making it long are all the error handling and reseeding strategies. Ciao, Marcus From laurenz.albe at wien.gv.at Sun Oct 25 11:12:19 2015 From: laurenz.albe at wien.gv.at (Albe Laurenz) Date: Sun, 25 Oct 2015 11:12:19 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> <56275DFC.3050404@openssl.org> <562AB264.9020409@openssl.org>, Message-ID: Matt Caswell wrote: > On 23/10/15 15:33, Albe Laurenz wrote: >> Matt Caswell wrote: >>> Imagine an attacker who is able to eavesdrop on messages between a >>> legitimate client who presents a client certificate to the server during >>> the initial handshake. As it is during the initial handshake this >>> happens in the clear, including the server responding with a session id. >>> >>> Ordinarily knowing the session id does not help very much because the >>> attacker does not know the associated keys so any attempt to reuse that >>> session id will fail. However with the proposed patch in place the >>> attacker can first establish a connection to the server anonymously. >>> Then they send a new ClientHello, but this time provide the eavesdropped >>> session id. The server updates the s->session value from the session >>> cache which *includes* the peer certificate. The exploit can then >>> proceed as before. The attacker does not continue the renegotiation >>> handshake but instead sends application data attempting a privileged >>> operation and the server application successfully verifies the identity. >> >> Do you mean that the attacker pretends to be the legitimate client >> and initiates renegotiation on their behalf? >> >> I thought that the ClientHello would have to be encrypted in that case, >> something which the attacker couldn't do. > > No, that's not what I meant. The attacker eavesdrops on the initial > handshake between a legitimate client (where that client has presented a > certificate) and the server and makes a note of the session id. > > The attacker then creates a completely new anonymous connection (they > don't use the session id yet). Then they initiate a renegotiation, but > this time present the stolen session id. Before they complete the reneg > handshake they start sending application data. That application data > will be processed by the server application in the context of the > certificate associated with the stolen session, but before the CCS has > been processed. I think I get you - you are talking of an "abbreviated handshake" to duplicate an existing session. But RFC 5246 writes: When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters), the message flow is as follows: The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. At this point, both client and server MUST send ChangeCipherSpec messages and proceed directly to Finished messages. Once the re-establishment is complete, the client and server MAY begin to exchange application layer data. That seems to spell out in pretty uncertain terms that no application data may be exchanged until the handshake is complete, so OpenSSL should just error out in that case. Or are you saying that it is difficult to disambiguate between this case and a renegotiation from within the code? Yours, Laurenz Albe From rt at openssl.org Sun Oct 25 11:12:32 2015 From: rt at openssl.org (Albe Laurenz via RT) Date: Sun, 25 Oct 2015 11:12:32 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> <56275DFC.3050404@openssl.org> <562AB264.9020409@openssl.org>, Message-ID: Matt Caswell wrote: > On 23/10/15 15:33, Albe Laurenz wrote: >> Matt Caswell wrote: >>> Imagine an attacker who is able to eavesdrop on messages between a >>> legitimate client who presents a client certificate to the server during >>> the initial handshake. As it is during the initial handshake this >>> happens in the clear, including the server responding with a session id. >>> >>> Ordinarily knowing the session id does not help very much because the >>> attacker does not know the associated keys so any attempt to reuse that >>> session id will fail. However with the proposed patch in place the >>> attacker can first establish a connection to the server anonymously. >>> Then they send a new ClientHello, but this time provide the eavesdropped >>> session id. The server updates the s->session value from the session >>> cache which *includes* the peer certificate. The exploit can then >>> proceed as before. The attacker does not continue the renegotiation >>> handshake but instead sends application data attempting a privileged >>> operation and the server application successfully verifies the identity. >> >> Do you mean that the attacker pretends to be the legitimate client >> and initiates renegotiation on their behalf? >> >> I thought that the ClientHello would have to be encrypted in that case, >> something which the attacker couldn't do. > > No, that's not what I meant. The attacker eavesdrops on the initial > handshake between a legitimate client (where that client has presented a > certificate) and the server and makes a note of the session id. > > The attacker then creates a completely new anonymous connection (they > don't use the session id yet). Then they initiate a renegotiation, but > this time present the stolen session id. Before they complete the reneg > handshake they start sending application data. That application data > will be processed by the server application in the context of the > certificate associated with the stolen session, but before the CCS has > been processed. I think I get you - you are talking of an "abbreviated handshake" to duplicate an existing session. But RFC 5246 writes: When the client and server decide to resume a previous session or duplicate an existing session (instead of negotiating new security parameters), the message flow is as follows: The client sends a ClientHello using the Session ID of the session to be resumed. The server then checks its session cache for a match. If a match is found, and the server is willing to re-establish the connection under the specified session state, it will send a ServerHello with the same Session ID value. At this point, both client and server MUST send ChangeCipherSpec messages and proceed directly to Finished messages. Once the re-establishment is complete, the client and server MAY begin to exchange application layer data. That seems to spell out in pretty uncertain terms that no application data may be exchanged until the handshake is complete, so OpenSSL should just error out in that case. Or are you saying that it is difficult to disambiguate between this case and a renegotiation from within the code? Yours, Laurenz Albe From rsalz at akamai.com Sun Oct 25 12:07:50 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 25 Oct 2015 12:07:50 +0000 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151024142238.GA3787@kronk.local> References: <20151023132238.GA32506@kronk.local> <22408147cb5e49f9b051d09a6f440ef8@ustx2ex-dag1mb3.msg.corp.akamai.com> <20151023170630.GA7014@kronk.local> <39bc0fd8f5224db2a95c34aba63e0396@ustx2ex-dag1mb3.msg.corp.akamai.com> <20151024142238.GA3787@kronk.local> Message-ID: <323d1c8e3f6449398d158806581d5f70@ustx2ex-dag1mb3.msg.corp.akamai.com> > Yeah, I guess both pthread and Windows implementations can both be called > "native". Yes, that's the intent. > FWIW I did a quick research and NW, OS/2 and VMS all seem to support > pthreads (but I don't know anything about those platforms, so I may be > wrong). That would be good. > Incidentally a big user of the lock and thread-id API is mem_dbg.c, and > looking at the code in it I was wondering whether we really need it, Take a look at: https://github.com/openssl/openssl/pull/450 > FWIW the ASYNC pull request [0] already uses thread-local storage, but > instead of using the pthread API (which is probably more portable) it uses > the __thread syntax. That should probably be changed. > The ERR_STATE thing could also be simplified a lot by using thread-local > storage (and the fallback thread-local support can be implemented using > THREADID as it's currently done in ERR_STATE itself, but all the complexity > would be moved to its own file, leaving err.c cleaner). Yes, that should be changed too. In case it's not clear, I've changed my thoughts. Thread-local storage is more important and useful (thanks Kaduk and Ghedini!) than pthread-once kinds of things. I'd like to see a single API that initializes *everything* (or maybe takes a flag-bits) and a peer routine that takes down everything. It would handle fork() and reset the RNG, and so on. From rt at openssl.org Sun Oct 25 22:52:36 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Sun, 25 Oct 2015 22:52:36 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <562D5D30.9060909@openssl.org> References: <56210109.20208@openssl.org> <1978223.QIgxm0v1JF@pintsize.usersys.redhat.com> <562AB264.9020409@openssl.org> <562D5D30.9060909@openssl.org> Message-ID: On 25/10/15 11:12, Albe Laurenz via RT wrote: > Matt Caswell wrote: >> On 23/10/15 15:33, Albe Laurenz wrote: >>> Matt Caswell wrote: >>>> Imagine an attacker who is able to eavesdrop on messages between a >>>> legitimate client who presents a client certificate to the server during >>>> the initial handshake. As it is during the initial handshake this >>>> happens in the clear, including the server responding with a session id. >>>> >>>> Ordinarily knowing the session id does not help very much because the >>>> attacker does not know the associated keys so any attempt to reuse that >>>> session id will fail. However with the proposed patch in place the >>>> attacker can first establish a connection to the server anonymously. >>>> Then they send a new ClientHello, but this time provide the eavesdropped >>>> session id. The server updates the s->session value from the session >>>> cache which *includes* the peer certificate. The exploit can then >>>> proceed as before. The attacker does not continue the renegotiation >>>> handshake but instead sends application data attempting a privileged >>>> operation and the server application successfully verifies the identity. >>> >>> Do you mean that the attacker pretends to be the legitimate client >>> and initiates renegotiation on their behalf? >>> >>> I thought that the ClientHello would have to be encrypted in that case, >>> something which the attacker couldn't do. >> >> No, that's not what I meant. The attacker eavesdrops on the initial >> handshake between a legitimate client (where that client has presented a >> certificate) and the server and makes a note of the session id. >> >> The attacker then creates a completely new anonymous connection (they >> don't use the session id yet). Then they initiate a renegotiation, but >> this time present the stolen session id. Before they complete the reneg >> handshake they start sending application data. That application data >> will be processed by the server application in the context of the >> certificate associated with the stolen session, but before the CCS has >> been processed. > > I think I get you - you are talking of an "abbreviated handshake" to duplicate > an existing session. > > But RFC 5246 writes: > > When the client and server decide to resume a previous session or > duplicate an existing session (instead of negotiating new security > parameters), the message flow is as follows: > > The client sends a ClientHello using the Session ID of the session to > be resumed. The server then checks its session cache for a match. > If a match is found, and the server is willing to re-establish the > connection under the specified session state, it will send a > ServerHello with the same Session ID value. At this point, both > client and server MUST send ChangeCipherSpec messages and proceed > directly to Finished messages. Once the re-establishment is > complete, the client and server MAY begin to exchange application > layer data. > > That seems to spell out in pretty uncertain terms that no application data > may be exchanged until the handshake is complete, so OpenSSL should just > error out in that case. I don't think that it does say that. At least not the way I read it. The Client does not know that its request to reuse a session has been accepted by the server until it processes the ServerHello. I see nothing in the above which says a client is not allowed to send application data after it has sent its ClientHello but before it has processed the ServerHello. >From a server perspective if it receives ApplicationData after it has sent the ServerHello it would have to assume that it is "in transit" application data sent from the client before it has processed the ServerHello. My concern though is broader than this specific case. I have given two *examples* of exploits that we may open ourselves up to if we attempt to process this application data without some fairly significant refactoring of the code to separate out state currently in the process of being negotiated from state for the current epoch. We could probably patch things up to work around these two specific examples but I worry that without the more significant refactoring work, we may open ourselves up to other attacks that we haven't thought of. Matt From rt at openssl.org Mon Oct 26 10:29:43 2015 From: rt at openssl.org (Pascal Cuoq via RT) Date: Mon, 26 Oct 2015 10:29:43 +0000 Subject: [openssl-dev] [openssl.org #4107] [PATCH] null pointer dereference: bn_wexpand return code not checked in bn_g2fm.c In-Reply-To: <9CB36B86-4526-40CD-A546-2F7E69D21781@trust-in-soft.com> References: <9CB36B86-4526-40CD-A546-2F7E69D21781@trust-in-soft.com> Message-ID: The function bn_wexpand() can fail. Most of the invocations in bn_g2fm.c are guarded, but three of them aren't, causing a null pointer dereference when bn_wexpand() fails: https://github.com/openssl/openssl/blob/3f6c7691870d1cd2ad0e0c83638cef3f35a0b548/crypto/bn/bn_gf2m.c#L700 If the calls to bn_wexpand() are guarded as in the attached patch, the null pointer dereferences no longer occur. -------------- next part -------------- A non-text attachment was scrubbed... Name: bn_wexpand.patch Type: application/octet-stream Size: 911 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From tarunpolisetti at gmail.com Mon Oct 26 15:11:09 2015 From: tarunpolisetti at gmail.com (T@Run..............! Polisetty) Date: Mon, 26 Oct 2015 20:41:09 +0530 Subject: [openssl-dev] Memory Leak in Crypto_Malloc Message-ID: Hai All, We are running Dtls Calls and we are seeing the following Memory leaks. 1,340 bytes in 5 blocks are still reachable in loss record 2,684 of 3,019 ==22625== at 0x4C28BED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==22625== by 0x5156347: CRYPTO_malloc (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==22625== by 0x51B8AE1: BUF_MEM_grow (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==22625== by 0x51F9E68: X509_NAME_oneline (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==22625== by 0x51DEF6D: x509_cb (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==22625== by 0x51E5C83: ASN1_item_ex_d2i (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==22625== by 0x51E62E6: ASN1_item_d2i (in /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==22625== by 0x4E4F0BF: ssl3_get_client_certificate (in /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0) ==22625== by 0x4E67D63: dtls1_accept (in /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0) ==22625== by 0x4E6C384: dtls1_read_bytes (in /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0) ==22625== by 0x4E57626: ssl3_read (in /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0) There are many leaks because of crypto_malloc, just i pasted one for sample purpose. My question is how to free that above allocated memory. Do SSL_free() will clear above memory. Could any help me in this regard. Regards Satya -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Mon Oct 26 18:01:50 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Mon, 26 Oct 2015 19:01:50 +0100 Subject: [openssl-dev] Improving OpenSSL default RNG In-Reply-To: <20151024155544.GB22128@suse.de> References: <20151023132238.GA32506@kronk.local> <562A4563.3040902@ncp-e.com> <20151023171911.GA7805@kronk.local> <20151024155544.GB22128@suse.de> Message-ID: <562E6A8E.2070208@ncp-e.com> On 10/24/2015 05:55 PM, Marcus Meissner wrote: > On Fri, Oct 23, 2015 at 07:19:11PM +0200, Alessandro Ghedini wrote: >> On Fri, Oct 23, 2015 at 04:34:11PM +0200, Dr. Matthias St. Pierre wrote: >> ... >> In general the NIST DRBGs seem fairly complicated (or completely untrustworthy >> like Dual EC DRBG), so I'd rather have a different implementation as default >> RNG for OpenSSL. > > Well, the Dual EC has been removed from the guidance. > > The other 3 modes described in NIST 800-90a make sense though. I suggest to read > the standard, the main things making it long are all the error handling and > reseeding strategies. > > Ciao, Marcus I agree, to me it seems to be a rather straightforward implementation of a hybrid RNG. To get an impression of the essentials, e.g. for the DRBG based on AES-CTR, it helps to have a look at Figures 11 (p.49) and 12 (p.51) of . The nice part about the DRBG is that one can connect it to an external entropy source and configure the reseed interval. It also supports prediction resistance on demand, although this feature is not available through FIPS_drbg_method(), only if one uses FIPS_drbg_generate() directly. So it would be convenient for us to have it available in the normal OpenSSL library without having to fiddle with the FIPS object module. It wouldn't have to be the default OpenSSL RNG, though. Regards, Matthias From rt at openssl.org Tue Oct 27 03:13:27 2015 From: rt at openssl.org (Chris Conroy via RT) Date: Tue, 27 Oct 2015 03:13:27 +0000 Subject: [openssl-dev] [openssl.org #4108] Set TLS ticket keys API In-Reply-To: References: Message-ID: Pull request on github: https://github.com/openssl/openssl/pull/452 The existing API for managing RFC 5077 TLS ticket keys is cumbersome: callers must either specify a key once at startup or they must implement a complicated callback API. This new API allows a caller to set a list of TLS ticket keys. The first key in the list is preferred, and any other keys in the list will be accepted with an upgrade to a ticket with the preferred key. This scheme allows groups of servers to implement seamless key rotation strategies. The original patch comes from Twitter's https://github.com/twitter/sslconfig -------------- next part -------------- _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From openssl-users at dukhovni.org Tue Oct 27 03:39:56 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 27 Oct 2015 03:39:56 +0000 Subject: [openssl-dev] [openssl.org #4108] Set TLS ticket keys API In-Reply-To: References: Message-ID: <20151027033956.GV5570@mournblade.imrryr.org> On Tue, Oct 27, 2015 at 03:13:27AM +0000, Chris Conroy via RT wrote: > Pull request on github: https://github.com/openssl/openssl/pull/452 > > The existing API for managing RFC 5077 TLS ticket keys is cumbersome: > callers must either specify a key once at startup or they must implement a > complicated callback API. > > This new API allows a caller to set a list of TLS ticket keys. The first > key in the list is preferred, and any other keys in the list will be > accepted with an upgrade to a ticket with the preferred key. This scheme > allows groups of servers to implement seamless key rotation strategies. > > The original patch comes from Twitter's https://github.com/twitter/sslconfig Having written functionally similar code for Postfix some years back, I should probably review this one. A few quick comments: * The encryption algorithm for session tickets is hardcoded to aes-128-cbc. It should default to aes-256-cbc, and should be configurable. * I don't see any attempt to synchronize the key rotation cycle, with the session lifetime. If the session cache lifetime is shorter than the key lifetime, sessions will be refused as stale. * In the Postfix implementation, keys have a explicit end-time for use in creating new sessions, and another end time for use in decrypting existing sessions, and the session lifetime is set to exceed the latter. Instead of applications having to provide a list of keys up front, the callback fetches new keys as keys expire or session tickets arrive with a key that is not available in memory. This allows applications to generate new keys on demand, or fetch them "just-in-time", ... which is perhaps more flexible than preloading a list. I've not yet read all the code in detail, so I might retract some of the above, but I'd like to ask who'll be the primary contact to discuss any feedback on the proposed design? Perhaps we can do something that takes the best ideas from both the Twitter and the Postfix approaches (and any others that might have good ideas). -- Viktor. From tom.kacvinsky at vectorcast.com Tue Oct 27 17:15:45 2015 From: tom.kacvinsky at vectorcast.com (Tom Kacvinsky) Date: Tue, 27 Oct 2015 13:15:45 -0400 Subject: [openssl-dev] Building OpenSSL on Windows Message-ID: Hi, I've seen several messages float by about building OpenSSL on Windows. My understanding is that I'll need a Perl distribution, in addition to a specific assembler (MS's Macro Assemble is not up to the task is what I gather). Anything else I need to be aware of? I will be building in a DOS shell with Visual Studio 2008. Thanks, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Tue Oct 27 17:29:51 2015 From: foleyj at cisco.com (John Foley) Date: Tue, 27 Oct 2015 13:29:51 -0400 Subject: [openssl-dev] Building OpenSSL on Windows In-Reply-To: References: Message-ID: <562FB48F.4010305@cisco.com> Take a look at the INSTALL.W32 file in the tarball. This details all the requirements and steps to compile the code. On 10/27/2015 01:15 PM, Tom Kacvinsky wrote: > Hi, > > I've seen several messages float by about building OpenSSL on > Windows. My understanding is that I'll need a Perl distribution, in > addition to a specific assembler (MS's Macro Assemble is not up to the > task is what I gather). Anything else I need to be aware of? I will > be building in a DOS shell with Visual Studio 2008. > > Thanks, > > Tom > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From phpdev at ehrhardt.nl Tue Oct 27 18:49:22 2015 From: phpdev at ehrhardt.nl (Jan Ehrhardt) Date: Tue, 27 Oct 2015 19:49:22 +0100 Subject: [openssl-dev] Building OpenSSL on Windows References: Message-ID: <9ehv2b1cjlvjra8mp0au98s6jqh33tpsre@4ax.com> Tom Kacvinsky in gmane.comp.encryption.openssl.devel (Tue, 27 Oct 2015 13:15:45 -0400): >I've seen several messages float by about building OpenSSL on Windows. My >understanding is that I'll need a Perl distribution, in addition to a >specific assembler (MS's Macro Assemble is not up to the task is what I >gather). Anything else I need to be aware of? I will be building in a DOS >shell with Visual Studio 2008. Take a look at https://github.com/winlibs/openssl You will need nasm: C:\php-sdk>nasm -v NASM version 2.11.08 compiled on Feb 21 2015 -- Jan From rt at openssl.org Tue Oct 27 19:02:58 2015 From: rt at openssl.org (Dhruv Bhatt via RT) Date: Tue, 27 Oct 2015 19:02:58 +0000 Subject: [openssl-dev] [openssl.org #4109] Re: Error installing openssl version 1.0.2 In-Reply-To: References: Message-ID: Hi, I am trying to install openssl version 1.0.2. What I do: 1. tar the version openssl-1.0.2 2. cd to that directory . 3. ./config ?prefix=<> ?openssldir=<> 4. make Issue is something with crypto/modes/ghash-x86_64.s file at line 890. junk ?? after expression. Has this issue been fixed? Also it comes with 1.0.2d version as well. But if we try 1.0.1j version it works completely fine and I am able to install that version. Thanks, Dhruv. P.S. I am trying to help someone install openssl and I have seen this issue twice till now, I do not have any logs with me will try to get one. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Oct 28 00:57:46 2015 From: rt at openssl.org (Willy TARREAU via RT) Date: Wed, 28 Oct 2015 00:57:46 +0000 Subject: [openssl-dev] [openssl.org #4110] [PATCH] fix ssl_new() error handling on out of memory condition In-Reply-To: <20151027200838.GJ21257@haproxy.com> References: <20151027200838.GJ21257@haproxy.com> Message-ID: This patch fixes a reference issue when SSL_new() fails due to a low memory condition. What happens is that a few error checks end up with a "goto err" statement which calls SSL_free() to clear what was allocated, but since this function first checks that s->references was exactly one before proceeding, the fact that the references is set to 1 only after a successful SSL_new() makes SSL_free() abort() on all prior errors. The proper fix consists in moving the references assignment just after initialization of 's' so that all the error path is properly covered. The error was repeatedly encountered on openssl 1.0.1p. Tests with newer versions were not made yet. Backtrace : (gdb) bt #0 0x0000000000534c5f in SSL_free (s=0x7fa89ee11700) at ssl_lib.c:524 #1 0x00000000005347f6 in SSL_new (ctx=0x274dec8) at ssl_lib.c:393 --- ./ssl/ssl_lib.c.dist 2015-10-27 19:44:01.091392468 +0100 +++ ./ssl/ssl_lib.c 2015-10-27 20:31:57.747630748 +0100 @@ -299,6 +299,7 @@ if (s == NULL) goto err; memset(s, 0, sizeof(SSL)); + s->references = 1; /* to please SSL_free() along the "goto err" path */ #ifndef OPENSSL_NO_KRB5 s->kssl_ctx = kssl_ctx_new(); @@ -375,7 +376,6 @@ if (!s->method->ssl_new(s)) goto err; - s->references = 1; s->server = (ctx->method->ssl_accept == ssl_undefined_function) ? 0 : 1; SSL_clear(s); _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Wed Oct 28 00:58:09 2015 From: rt at openssl.org (Willy TARREAU via RT) Date: Wed, 28 Oct 2015 00:58:09 +0000 Subject: [openssl-dev] [openssl.org #4111] [PATCH] fix ssl3_free NULL dereference on out of memory condition In-Reply-To: <20151027200952.GK21257@haproxy.com> References: <20151027200952.GK21257@haproxy.com> Message-ID: This patch fixes a NULL dereference issue when SSL_new() fails due to a low memory condition. Here it is possible that ssl3_new() fails, but despite this ssl3_free() is called along the error path and doesn't check that s->s3 is valid before dereferencing it. The first victim here is ssl3_cleanup_key_block() but it can happen a few lines earlier depending on the #ifdef. Since ssl3_free() already used to check for the validity of its SSL pointer argument, let's make it also check for s->s3 which it works on, and make it ignore a NULL there. The error was repeatedly encountered on openssl 1.0.1p. Tests with newer versions were not made yet. Backtrace below : Program terminated with signal 11, Segmentation fault. #0 0x000000000051e2a7 in ssl3_cleanup_key_block (s=0x245e4f0) at s3_enc.c:456 456 if (s->s3->tmp.key_block != NULL) { (gdb) bt #0 0x000000000051e2a7 in ssl3_cleanup_key_block (s=0x245e4f0) at s3_enc.c:456 #1 0x000000000051ab76 in ssl3_free (s=0x245e4f0) at s3_lib.c:2968 #2 0x0000000000528319 in tls1_free (s=0x245e4f0) at t1_lib.c:167 #3 0x0000000000534fba in SSL_free (s=0x245e4f0) at ssl_lib.c:597 #4 0x0000000000534802 in SSL_new (ctx=0x205e938) at ssl_lib.c:395 # --- ./ssl/s3_lib.c.dist 2015-10-27 20:21:47.980188704 +0100 +++ ./ssl/s3_lib.c 2015-10-27 20:21:48.868193718 +0100 @@ -2955,7 +2955,7 @@ void ssl3_free(SSL *s) { - if (s == NULL) + if (s == NULL || s->s3 == NULL) return; #ifdef TLSEXT_TYPE_opaque_prf_input _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From tshort at akamai.com Wed Oct 28 15:26:09 2015 From: tshort at akamai.com (Short, Todd) Date: Wed, 28 Oct 2015 15:26:09 +0000 Subject: [openssl-dev] [openssl.org #4109] Re: Error installing openssl version 1.0.2 In-Reply-To: References: Message-ID: <78B03E51-F67E-4B78-815B-4FF974D24823@akamai.com> This is likely the same as RT3885. Check out this fix: https://github.com/akamai/openssl/commit/15ecb1a4dc4f75d6c33e8cd9089ca5cfc78d28dc You may be running a 32-bit version of Perl on a 64-bit platform. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Oct 27, 2015, at 3:02 PM, Dhruv Bhatt via RT wrote: Hi, I am trying to install openssl version 1.0.2. What I do: 1. tar the version openssl-1.0.2 2. cd to that directory . 3. ./config ?prefix=<> ?openssldir=<> 4. make Issue is something with crypto/modes/ghash-x86_64.s file at line 890. junk ?? after expression. Has this issue been fixed? Also it comes with 1.0.2d version as well. But if we try 1.0.1j version it works completely fine and I am able to install that version. Thanks, Dhruv. P.S. I am trying to help someone install openssl and I have seen this issue twice till now, I do not have any logs with me will try to get one. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Oct 28 15:26:23 2015 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 28 Oct 2015 15:26:23 +0000 Subject: [openssl-dev] [openssl.org #4109] Re: Error installing openssl version 1.0.2 In-Reply-To: <78B03E51-F67E-4B78-815B-4FF974D24823@akamai.com> References: <78B03E51-F67E-4B78-815B-4FF974D24823@akamai.com> Message-ID: This is likely the same as RT3885. Check out this fix: https://github.com/akamai/openssl/commit/15ecb1a4dc4f75d6c33e8cd9089ca5cfc78d28dc You may be running a 32-bit version of Perl on a 64-bit platform. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Oct 27, 2015, at 3:02 PM, Dhruv Bhatt via RT wrote: Hi, I am trying to install openssl version 1.0.2. What I do: 1. tar the version openssl-1.0.2 2. cd to that directory . 3. ./config ?prefix=<> ?openssldir=<> 4. make Issue is something with crypto/modes/ghash-x86_64.s file at line 890. junk ?? after expression. Has this issue been fixed? Also it comes with 1.0.2d version as well. But if we try 1.0.1j version it works completely fine and I am able to install that version. Thanks, Dhruv. P.S. I am trying to help someone install openssl and I have seen this issue twice till now, I do not have any logs with me will try to get one. _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at 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 From rt at openssl.org Wed Oct 28 22:33:11 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Wed, 28 Oct 2015 22:33:11 +0000 Subject: [openssl-dev] [openssl.org #4111] [PATCH] fix ssl3_free NULL dereference on out of memory condition In-Reply-To: <20151028223302.GA12023@roeckx.be> References: <20151027200952.GK21257@haproxy.com> <20151028223302.GA12023@roeckx.be> Message-ID: On Wed, Oct 28, 2015 at 12:58:09AM +0000, Willy TARREAU via RT wrote: > This patch fixes a NULL dereference issue when SSL_new() fails due to a > low memory condition. Here it is possible that ssl3_new() fails, but > despite this ssl3_free() is called along the error path and doesn't check > that s->s3 is valid before dereferencing it. This was actually already reported with the same patch last week. But I want to look in the whole error handling of SSL_new(). PS: Are you using some tool to try and find those issues? Kurt From rt at openssl.org Thu Oct 29 01:21:38 2015 From: rt at openssl.org (Willy TARREAU via RT) Date: Thu, 29 Oct 2015 01:21:38 +0000 Subject: [openssl-dev] [openssl.org #4111] [PATCH] fix ssl3_free NULL dereference on out of memory condition In-Reply-To: <20151029012128.GC12220@haproxy.com> References: <20151027200952.GK21257@haproxy.com> <20151028223302.GA12023@roeckx.be> <20151029012128.GC12220@haproxy.com> Message-ID: Hello, On Wed, Oct 28, 2015 at 10:33:11PM +0000, Kurt Roeckx via RT wrote: > On Wed, Oct 28, 2015 at 12:58:09AM +0000, Willy TARREAU via RT wrote: > > This patch fixes a NULL dereference issue when SSL_new() fails due to a > > low memory condition. Here it is possible that ssl3_new() fails, but > > despite this ssl3_free() is called along the error path and doesn't check > > that s->s3 is valid before dereferencing it. > > This was actually already reported with the same patch last week. Ah cool! > But I want to look in the whole error handling of SSL_new(). For sure! The other patch touches SSL_new() as well and... it's not the best place to be when an error occurs! But that's the problem with any constructor, it's hard to perform the cleanup after things are half-initialized. > PS: Are you using some tool to try and find those issues? No, just a customer with production traffic reporting a crash every 5 minutes :-) We enabled core dumps and found the two locations for which I proposed a patch. At least these patches have fixed all the issues in the lab, I'll wait for the customer's feedback. I'm still having a doubt since the customer faced one segfault in libcrypto which I have not reproduced, but since there were a lot of fixes in this area between 1.0.1p and 1.0.1-stable, I picked all the pending patches to see if they're enough to fix this issue for the customer. That's all the information I can bring at the moment. Best regards, Willy From rt at openssl.org Thu Oct 29 07:23:37 2015 From: rt at openssl.org (Willy TARREAU via RT) Date: Thu, 29 Oct 2015 07:23:37 +0000 Subject: [openssl-dev] [openssl.org #4111] [PATCH] fix ssl3_free NULL dereference on out of memory condition In-Reply-To: <20151029072335.GA5978@haproxy.com> References: <20151029072335.GA5978@haproxy.com> Message-ID: Kurt, you're probably aware of this already, but quite frankly, dealing with bug reports using closed lists is really not the most efficient way to work towards easy exchanges leading to problem resolution :-/ You may possibly have to manually forward my message to the other list if that's of interest on this list. Best regards, Willy On Thu, Oct 29, 2015 at 01:54:43AM +0000, openssl-dev-owner at openssl.org wrote: > You are not allowed to post to this mailing list, and your message has > been automatically rejected. If you think that your messages are > being rejected in error, contact the mailing list owner at > openssl-dev-owner at openssl.org. (...) From rt at openssl.org Thu Oct 29 14:00:51 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Thu, 29 Oct 2015 14:00:51 +0000 Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken In-Reply-To: <2967819.dUliAttKOr@pintsize.usersys.redhat.com> References: <562D5D30.9060909@openssl.org> <2967819.dUliAttKOr@pintsize.usersys.redhat.com> Message-ID: On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote: > On 25/10/15 11:12, Albe Laurenz via RT wrote: > > Matt Caswell wrote: > >> On 23/10/15 15:33, Albe Laurenz wrote: > >>> Matt Caswell wrote: > >>>> Imagine an attacker who is able to eavesdrop on messages between > >>>> a > >>>> legitimate client who presents a client certificate to the server > >>>> during the initial handshake. As it is during the initial > >>>> handshake this happens in the clear, including the server > >>>> responding with a session id. > >>>> > >>>> Ordinarily knowing the session id does not help very much because > >>>> the > >>>> attacker does not know the associated keys so any attempt to > >>>> reuse that session id will fail. However with the proposed patch > >>>> in place the attacker can first establish a connection to the > >>>> server anonymously. Then they send a new ClientHello, but this > >>>> time provide the eavesdropped session id. The server updates the > >>>> s->session value from the session cache which *includes* the > >>>> peer certificate. The exploit can then proceed as before. The > >>>> attacker does not continue the renegotiation handshake but > >>>> instead sends application data attempting a privileged operation > >>>> and the server application successfully verifies the identity.>>> > >>> Do you mean that the attacker pretends to be the legitimate client > >>> and initiates renegotiation on their behalf? > >>> > >>> I thought that the ClientHello would have to be encrypted in that > >>> case, something which the attacker couldn't do. > >> > >> No, that's not what I meant. The attacker eavesdrops on the initial > >> handshake between a legitimate client (where that client has > >> presented a certificate) and the server and makes a note of the > >> session id. > >> > >> The attacker then creates a completely new anonymous connection > >> (they > >> don't use the session id yet). Then they initiate a renegotiation, > >> but this time present the stolen session id. Before they complete > >> the reneg handshake they start sending application data. That > >> application data will be processed by the server application in > >> the context of the certificate associated with the stolen session, > >> but before the CCS has been processed. > > > > I think I get you - you are talking of an "abbreviated handshake" to > > duplicate an existing session. > > > > But RFC 5246 writes: > > When the client and server decide to resume a previous session or > > duplicate an existing session (instead of negotiating new > > security > > parameters), the message flow is as follows: > > > > The client sends a ClientHello using the Session ID of the > > session to > > be resumed. The server then checks its session cache for a > > match. > > If a match is found, and the server is willing to re-establish > > the > > connection under the specified session state, it will send a > > ServerHello with the same Session ID value. At this point, both > > client and server MUST send ChangeCipherSpec messages and proceed > > directly to Finished messages. Once the re-establishment is > > complete, the client and server MAY begin to exchange application > > layer data. > > > > That seems to spell out in pretty uncertain terms that no > > application data may be exchanged until the handshake is complete, > > so OpenSSL should just error out in that case. > > I don't think that it does say that. At least not the way I read it. > The Client does not know that its request to reuse a session has been > accepted by the server until it processes the ServerHello. I see > nothing in the above which says a client is not allowed to send > application data after it has sent its ClientHello but before it has > processed the ServerHello. +1 > From a server perspective if it receives ApplicationData after it has > sent the ServerHello it would have to assume that it is "in transit" > application data sent from the client before it has processed the > ServerHello. exactly > My concern though is broader than this specific case. I have given two > *examples* of exploits that we may open ourselves up to if we attempt > to process this application data without some fairly significant > refactoring of the code to separate out state currently in the > process of being negotiated from state for the current epoch. We > could probably patch things up to work around these two specific > examples but I worry that without the more significant refactoring > work, we may open ourselves up to other attacks that we haven't > thought of. unfortunately I have to agree. Those two examples show in rather clear terms that openssl as it is now in stable branches, can't be easily patched up to handle even specific situations of interleaved app data with handshake data in renegotiated handshakes. So breaking such connections is a safer option. That being said, Java behaviour is dangerous only if they expose to the application the "in negotiation" context instead of the "currently active" context. Not exactly easy to test. -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rsalz at akamai.com Thu Oct 29 14:58:21 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 29 Oct 2015 14:58:21 +0000 Subject: [openssl-dev] Code of conduct Message-ID: This note is to let the community know that we have adopted the following Code of Conduct, which you can find at https://www.openssl.org/community/conduct.html --------------------------------------------- The OpenSSL community consists primarily, although not solely, of its online presence in mailing lists and activities such as the blog postings and comments, the GitHub repository, and so on. These outlets are managed by the OpenSSL development team, whose members are listed here: https://www.openssl.org/community/team.html We strive to be an open and inclusive community where anyone can contribute. Contributions should be judged on their own merits; we don't care about your gender identity, race, political beliefs, age, or similar attributes. If we see that one or more members of the community are generally abusive, harassing others, or seem to be trying to intimidate them into leaving the community, we will first ask those who are doing so to take a break from participation for a while. If you see any evidence of such activity, please let us know by sending email to conduct at openssl.org. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From rt at openssl.org Thu Oct 29 18:46:37 2015 From: rt at openssl.org (Michal Bozon via RT) Date: Thu, 29 Oct 2015 18:46:37 +0000 Subject: [openssl-dev] [openssl.org #4112] GH458: Fix "primarility" typo In-Reply-To: References: Message-ID: https://github.com/openssl/openssl/pull/458 regards, Michal Bozon _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Thu Oct 29 19:44:18 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 29 Oct 2015 19:44:18 +0000 Subject: [openssl-dev] [openssl.org #4107] [PATCH] null pointer dereference: bn_wexpand return code not checked in bn_g2fm.c In-Reply-To: <20151029194416.GA25653@roeckx.be> References: <9CB36B86-4526-40CD-A546-2F7E69D21781@trust-in-soft.com> <20151029194416.GA25653@roeckx.be> Message-ID: On Mon, Oct 26, 2015 at 10:29:43AM +0000, Pascal Cuoq via RT wrote: > If the calls to bn_wexpand() are guarded as in the attached patch, the null pointer dereferences no longer occur. The patch has been applied. Kurt From rt at openssl.org Fri Oct 30 18:35:39 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Fri, 30 Oct 2015 18:35:39 +0000 Subject: [openssl-dev] [openssl.org #4080] Malformed Client Hello messages are accepted (session_id length) In-Reply-To: <20151030183525.GA10533@kronk.local> References: <3339734.5GVbOz5xNp@pintsize.usersys.redhat.com> <20151008171902.GA4825@kronk.local> <20151008195713.GA8667@kronk.local> <20151009170235.GA32172@kronk.local> <20151030183525.GA10533@kronk.local> Message-ID: On Fri, Oct 09, 2015 at 05:02:47pm +0000, Alessandro Ghedini via RT wrote: > On Thu, Oct 08, 2015 at 07:57:21pm +0000, Alessandro Ghedini via RT wrote: > > FYI, I just pushed another patch that does the above (moving the check and > > sending an alert) which I think is the best option (although, as Hubert pointed > > out, sending the decode_error alert is not a MUST). If that's ok with you, I > > can squash the two commits together and give them a better message, otherwise > > just ignore the second patch. > > So, I went ahead and squashed all the commits into one [0] and also added the > SSLv2 check as well. Can someone please have a look? Ping? FYI I just rebased my patch at [0] on top of the state machine rewrite commits in master (in fact I've rebased all my patches on master). Cheers [0] https://github.com/openssl/openssl/pull/437 From raysatiro at yahoo.com Sat Oct 31 05:55:57 2015 From: raysatiro at yahoo.com (Ray Satiro) Date: Sat, 31 Oct 2015 01:55:57 -0400 Subject: [openssl-dev] mingw: pkg-config --libs outputs gdi32 before crypto In-Reply-To: <20151024.174131.477311541507665559.richard@levitte.org> References: <5626EAC3.3060202@yahoo.com> <20151024.174131.477311541507665559.richard@levitte.org> Message-ID: <563457ED.9020007@yahoo.com> On 10/24/2015 11:41 AM, Richard Levitte wrote: > This is quite odd. Just for comparison, I tried the same on my laptop > (running Debian): > > : ; pkg-config --static --libs-only-l openssl > -lssl -ldl -lcrypto -ldl Thanks for checking Richard. I installed pkg-config .29 and that solved the problem so I guess it was a bug in pkg-config. Now I get the same pattern, ie -lssl -lcrypto $ pkg-config --static --libs-only-l openssl -lssl -lws2_32 -lgdi32 -lcrypt32 -lcrypto -lws2_32 -lgdi32 -lcrypt32 Side note for anyone who needs to install the latest pkg-config in mingw32, these are the steps I followed: Get the latest version at http://pkgconfig.freedesktop.org/releases/?C=M;O=D Since mingw32 doesn't have MemoryBarrier() I used mfence: CFLAGS="-g -O2 -DMemoryBarrier\\(\\)=asm\\(\\\"mfence\\;\\\"\\)" ./configure --with-internal-glib >config.out 2>&1 make V=1 >make.out 2>&1 make install So pkg.m4 can be found add /usr/local/share/aclocal to the aclocal dirlist if it's not there already: grep -E "^/usr/local/share/aclocal$" /mingw/share/aclocal/dirlist 2>/dev/null if [[ $? -ne 0 ]]; then echo /usr/local/share/aclocal >> /mingw/share/aclocal/dirlist; fi From rt at openssl.org Sat Oct 31 12:20:00 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 31 Oct 2015 12:20:00 +0000 Subject: [openssl-dev] [openssl.org #4113] [PATCH] Cleanup and update README In-Reply-To: <20151031121945.GA11316@kronk.local> References: <20151031121945.GA11316@kronk.local> Message-ID: Hi, the current README in master contains a lot of outdated information and some weird wording, so I prepared a patch to fix it. See the following GitHub pull request: https://github.com/openssl/openssl/pull/457 Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Oct 31 12:22:15 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 31 Oct 2015 12:22:15 +0000 Subject: [openssl-dev] [openssl.org #4114] Continuous integration for Windows In-Reply-To: <20151031122205.GB11316@kronk.local> References: <20151031122205.GB11316@kronk.local> Message-ID: Hi, the current Travis CI setup lacks support for proper Windows support, so I prepared a patch to add configuration for the AppVeyor service [0] which provides continuous integration on Windows. See the following GitHub pull request: https://github.com/openssl/openssl/pull/456 Cheers [0] http://www.appveyor.com/ _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Oct 31 12:26:51 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 31 Oct 2015 12:26:51 +0000 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <20151031122641.GA11750@kronk.local> References: <20151031122641.GA11750@kronk.local> Message-ID: Hi, I don't know what your intentions are with FIPS support in master, but after the removal of most if the fips/ code, several bits and pieces of now broken code have remained in the codebase. IMO it'd be better to just remove it for now. See the following GitHub pull request: https://github.com/openssl/openssl/pull/449 Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From marquess at openssl.com Sat Oct 31 12:34:33 2015 From: marquess at openssl.com (Steve Marquess) Date: Sat, 31 Oct 2015 08:34:33 -0400 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: References: <20151031122641.GA11750@kronk.local> Message-ID: <5634B559.1020401@openssl.com> On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote: > Hi, > > I don't know what your intentions are with FIPS support in master, ... We would like to continue to provide a FIPS validated module for the 1.1 (and subsequent) releases. Unfortunately the current module ("OpenSSL FIPS Object Module 2.0") designed for compatibility with the 1.0 releases won't be compatible with 1.1. That means we need to obtain a new validation for a new module, an endeavor fraught with many difficulties (none of them technical). I do expect the stars will align for that eventually, as they have for the five previous open source based validations. In the interim, since the FIPS module is shaped almost entirely by policy and metaphysical considerations, we should not include any incomplete FIPS specific code in 1.1 -- code that even if complete in some speculative sense would also be unusable absent a matching FIPS 140-2 validation. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From levitte at openssl.org Sat Oct 31 13:01:44 2015 From: levitte at openssl.org (Richard Levitte) Date: Sat, 31 Oct 2015 14:01:44 +0100 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <5634B559.1020401@openssl.com> References: <20151031122641.GA11750@kronk.local> <5634B559.1020401@openssl.com> Message-ID: <52A5B60E-77A7-4D5C-A10F-B8E7CE40FA76@openssl.org> Can't recall previous discussions on this, but would it be possible to have a FIPS engine? Cheers Richard Steve Marquess skrev: (31 oktober 2015 13:34:33 CET) >On 10/31/2015 08:26 AM, Alessandro Ghedini via RT wrote: >> Hi, >> >> I don't know what your intentions are with FIPS support in master, >... > >We would like to continue to provide a FIPS validated module for the >1.1 >(and subsequent) releases. Unfortunately the current module ("OpenSSL >FIPS Object Module 2.0") designed for compatibility with the 1.0 >releases won't be compatible with 1.1. That means we need to obtain a >new validation for a new module, an endeavor fraught with many >difficulties (none of them technical). > >I do expect the stars will align for that eventually, as they have for >the five previous open source based validations. In the interim, since >the FIPS module is shaped almost entirely by policy and metaphysical >considerations, we should not include any incomplete FIPS specific code >in 1.1 -- code that even if complete in some speculative sense would >also be unusable absent a matching FIPS 140-2 validation. > >-Steve M. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From rt at openssl.org Sat Oct 31 13:05:36 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 31 Oct 2015 13:05:36 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151031130526.GA11805@kronk.local> References: <20151031130526.GA11805@kronk.local> Message-ID: Hi, the current platform-generic implementation of OPENSSL_cleanse() is very weird and IMO overly complex (its initial intent was to cleanse with values other than 0, but AFAICT none of the asm implementations do it), so I reimplemented it in a simpler way. I was also wondering whether it would make sense to just drop the asm implementations. Does the speed-up justify the added complexity? See the following GitHub pull request: https://github.com/openssl/openssl/pull/455 Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From rt at openssl.org Sat Oct 31 13:09:37 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 31 Oct 2015 13:09:37 +0000 Subject: [openssl-dev] [openssl.org #4117] [PATCH] Remove useless locking code In-Reply-To: <20151031130932.GA13588@kronk.local> References: <20151031130932.GA13588@kronk.local> Message-ID: Hi, in commit 070c233 I didn't notice that the CRYPTO_w_lock()/CRYPTO_w_unlock() calls are now useless, so I made a patch to fix that. See the following GitHub pull request: https://github.com/openssl/openssl/pull/454 Cheers _______________________________________________ openssl-bugs-mod mailing list openssl-bugs-mod at openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod From marquess at openssl.com Sat Oct 31 13:09:50 2015 From: marquess at openssl.com (Steve Marquess) Date: Sat, 31 Oct 2015 09:09:50 -0400 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <52A5B60E-77A7-4D5C-A10F-B8E7CE40FA76@openssl.org> References: <20151031122641.GA11750@kronk.local> <5634B559.1020401@openssl.com> <52A5B60E-77A7-4D5C-A10F-B8E7CE40FA76@openssl.org> Message-ID: <5634BD9E.90405@openssl.com> On 10/31/2015 09:01 AM, Richard Levitte wrote: > Can't recall previous discussions on this, but would it be possible to have a FIPS engine? Of a sort, yes. I'll let Steve Henson speak to the details, but it is his hope (and mine) that FIPS module support for 1.1 and beyond would be modular so the FIPS module and OpenSSL releases would no longer be so tightly coupled. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From levitte at openssl.org Sat Oct 31 14:45:26 2015 From: levitte at openssl.org (Richard Levitte) Date: Sat, 31 Oct 2015 15:45:26 +0100 Subject: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code In-Reply-To: <5634BD9E.90405@openssl.com> References: <20151031122641.GA11750@kronk.local> <5634B559.1020401@openssl.com> <52A5B60E-77A7-4D5C-A10F-B8E7CE40FA76@openssl.org> <5634BD9E.90405@openssl.com> Message-ID: On October 31, 2015 2:09:50 PM GMT+01:00, Steve Marquess wrote: >On 10/31/2015 09:01 AM, Richard Levitte wrote: >> Can't recall previous discussions on this, but would it be possible >to have a FIPS engine? > >Of a sort, yes. I'll let Steve Henson speak to the details, but it is >his hope (and mine) that FIPS module support for 1.1 and beyond would >be >modular so the FIPS module and OpenSSL releases would no longer be so >tightly coupled. > >-Steve M. I'm most certainly interested in such an effort. -- levitte at openssl.org From brian at briansmith.org Sat Oct 31 19:58:50 2015 From: brian at briansmith.org (Brian Smith) Date: Sat, 31 Oct 2015 09:58:50 -1000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: References: <20151031130526.GA11805@kronk.local> Message-ID: Alessandro Ghedini via RT wrote: > I was also wondering whether it would make sense to just drop the asm > implementations. Does the speed-up justify the added complexity? > IMO, it should work like this: * memset_s when memset_s is available. * Otherwise, SecureZeroMemory, when SecureZeroMemory is available. * Otherwise, if a flag OPENSSL_REQUIRE_SECURE_ZERO is set, fail. * Otherwise, use an assembly language implementation, if available. * Otherwise, emit a warning and use the C implementation. Note in particular that the C compiler is allowed to completely defeat the purpose of the function unless SecureZeroMemory or memset_s is used, even if you use "volatile" or other tricks. The primary purpose of the assembly language implementations is to reduce the possibility that the C compiler will do the weird things that C compilers love to do. Cheers, Brian -- https://briansmith.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Oct 31 19:59:03 2015 From: rt at openssl.org (Brian Smith via RT) Date: Sat, 31 Oct 2015 19:59:03 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: References: <20151031130526.GA11805@kronk.local> Message-ID: Alessandro Ghedini via RT wrote: > I was also wondering whether it would make sense to just drop the asm > implementations. Does the speed-up justify the added complexity? > IMO, it should work like this: * memset_s when memset_s is available. * Otherwise, SecureZeroMemory, when SecureZeroMemory is available. * Otherwise, if a flag OPENSSL_REQUIRE_SECURE_ZERO is set, fail. * Otherwise, use an assembly language implementation, if available. * Otherwise, emit a warning and use the C implementation. Note in particular that the C compiler is allowed to completely defeat the purpose of the function unless SecureZeroMemory or memset_s is used, even if you use "volatile" or other tricks. The primary purpose of the assembly language implementations is to reduce the possibility that the C compiler will do the weird things that C compilers love to do. Cheers, Brian -- https://briansmith.org/ From rt at openssl.org Sat Oct 31 21:50:31 2015 From: rt at openssl.org (Alessandro Ghedini via RT) Date: Sat, 31 Oct 2015 21:50:31 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151031215017.GA2962@kronk.local> References: <20151031130526.GA11805@kronk.local> <20151031215017.GA2962@kronk.local> Message-ID: On Sat, Oct 31, 2015 at 07:59:03PM +0000, Brian Smith via RT wrote: > Alessandro Ghedini via RT wrote: > > > I was also wondering whether it would make sense to just drop the asm > > implementations. Does the speed-up justify the added complexity? > > > > IMO, it should work like this: > * memset_s when memset_s is available. Given the current OpenSSL build system, there's no way to detect if memset_s is available at build time (unless it's defined as a macro). In any case memset_s is not available anywhere anyway, so that doesn't really matter. > * Otherwise, SecureZeroMemory, when SecureZeroMemory is available. > * Otherwise, if a flag OPENSSL_REQUIRE_SECURE_ZERO is set, fail. In 99% of the cases (e.g. Linux with glibc or any *BSD) that would fail, so I don't see the point in that. > * Otherwise, use an assembly language implementation, if available. > * Otherwise, emit a warning and use the C implementation. > > Note in particular that the C compiler is allowed to completely defeat the > purpose of the function unless SecureZeroMemory or memset_s is used, even > if you use "volatile" or other tricks. I don't think that is true (regarding the volatile pointer). But assuming that a broken compiler decided to optimize that call away, what's stopping it to optimize the call to the asm implementation as well? Also, such broken compiler probably wouldn't know about C11 either, so even if memset_s() was available it could optimize that as well. I don't know how compilers are supposed to treat memset_s(), but if I define a memset_s() function which just calls memset() internally, GCC (v5.2.1 20151028) optimizes that away just as it does with plain memset(), so libc implementations would probably need to adopt "tricks" to avoid the optimization as well. FWIW OpenSSH implements the portable explicit_bzero() using the volatile pointer as well (unless memset_s() is detected at build time). On OpenBSD it just uses OpenBSD's explicit_bzero() which is implemented using memset() and a weak function pointer. But that (as used in LibreSSL) seems to have problems in relation to LTO, unless optimizations are specifically disabled: https://github.com/libressl-portable/openbsd/issues/5 On the other hand BoringSSL uses memset() with an explicit memory barrier implemented as inline assembly, which is possibly better than the volatile implementation because GCC (and probably other compilers) can inline the memset() call. But if OPENSSL_NO_ASM is defined, the barrier is omitted and memset() is optimized away, so that's potentially dangerous. The above is just to give an overview on how other projects solved this problem. Notably none of them uses full assembly implementations like OpenSSL does. > The primary purpose of the assembly language implementations is to reduce the > possibility that the C compiler will do the weird things that C compilers love > to do. According to the changelog and git log, the primary purpose of the asm implementations was to improve performance (see commit b2dba9b). Using the volatile pointer implementation would IMO make these optimizations useless, hence the proposal to drop them and make things simpler. Cheers From rt at openssl.org Sat Oct 31 22:24:43 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sat, 31 Oct 2015 22:24:43 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: <20151031222435.GA29000@roeckx.be> References: <20151031130526.GA11805@kronk.local> <20151031222435.GA29000@roeckx.be> Message-ID: On Sat, Oct 31, 2015 at 09:58:50AM -1000, Brian Smith wrote: > Alessandro Ghedini via RT wrote: > > > I was also wondering whether it would make sense to just drop the asm > > implementations. Does the speed-up justify the added complexity? > > > > IMO, it should work like this: > * memset_s when memset_s is available. > * Otherwise, SecureZeroMemory, when SecureZeroMemory is available. > * Otherwise, if a flag OPENSSL_REQUIRE_SECURE_ZERO is set, fail. I guess you mean here that if neither of those two is available, we really can't guarantee anything. > * Otherwise, use an assembly language implementation, if available. > * Otherwise, emit a warning and use the C implementation. > > Note in particular that the C compiler is allowed to completely defeat the > purpose of the function unless SecureZeroMemory or memset_s is used, even > if you use "volatile" or other tricks. The primary purpose of the assembly > language implementations is to reduce the possibility that the C compiler > will do the weird things that C compilers love to do. It's my understanding that the compiler can still try to outsmart us and remove things unless it has explicit support for something like memset_s(). Which is also why explicit_bzero() can be optimized away. This is what BoringSSL currently uses: void OPENSSL_cleanse(void *ptr, size_t len) { #if defined(OPENSSL_WINDOWS) SecureZeroMemory(ptr, len); #else memset(ptr, 0, len); #if !defined(OPENSSL_NO_ASM) /* As best as we can tell, this is sufficient to break any optimisations that might try to eliminate "superfluous" memsets. If there's an easy way to detect memset_s, it would be better to use that. */ __asm__ __volatile__("" : : "r"(ptr) : "memory"); #endif #endif /* !OPENSSL_NO_ASM */ } (The /* !OPENSSL_NO_ASM */ is at the wrong line.) I find the "#if !defined(OPENSSL_NO_ASM)" a little annoying there, building with no-asm might suddenly optimize it away. I'm also not sure we can actually use it like that, this is probably going to cause issues on some platforms. Kurt From rt at openssl.org Sat Oct 31 23:01:22 2015 From: rt at openssl.org (Brian Smith via RT) Date: Sat, 31 Oct 2015 23:01:22 +0000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: References: <20151031130526.GA11805@kronk.local> <20151031215017.GA2962@kronk.local> Message-ID: On Sat, Oct 31, 2015 at 11:50 AM, Alessandro Ghedini via RT wrote: > In any case memset_s is not available anywhere anyway, so that doesn't > really > matter. > Is it available in some places, e.g. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/memset_s.3.html . > > * Otherwise, SecureZeroMemory, when SecureZeroMemory is available. > > * Otherwise, if a flag OPENSSL_REQUIRE_SECURE_ZERO is set, fail. > > In 99% of the cases (e.g. Linux with glibc or any *BSD) that would fail, > so I > don't see the point in that. > The point is to let the person building OPENSSL say "I want the build to fail if there isn't a secure way to zero memory, because I'm expecting there to always be one in my configuration." Alternatively, there could be an OPENSSL_USE_MEMSET_S flag that says "always use memset_s and never anything else." > > Note in particular that the C compiler is allowed to completely defeat > the > > purpose of the function unless SecureZeroMemory or memset_s is used, even > > if you use "volatile" or other tricks. > > I don't think that is true (regarding the volatile pointer). But assuming > that > a broken compiler decided to optimize that call away, what's stopping it to > optimize the call to the asm implementation as well? Also, such broken > compiler > probably wouldn't know about C11 either, so even if memset_s() was > available it > could optimize that as well. > Such optimizations are legal. Otherwise, C11 wouldn't have defined |memset_s|. And, the entire purpose of |memset_s| is to disable such optimizations. > I don't know how compilers are supposed to treat memset_s(), but if I > define a > memset_s() function which just calls memset() internally, GCC (v5.2.1 > 20151028) > optimizes that away just as it does with plain memset(), so libc > implementations would probably need to adopt "tricks" to avoid the > optimization > as well. > Right. It has to be built into the compiler. > FWIW OpenSSH implements the portable explicit_bzero() using the volatile > pointer as well (unless memset_s() is detected at build time). That is similar to what I'm suggesting. > On OpenBSD it > just uses OpenBSD's explicit_bzero() which is implemented using memset() > and a > weak function pointer. It is a good idea to detect OpenBSD at compile time and use |explicit_bzero|, just like for |SecureZeroMemory| on Windows. Don't pay much attention to what tricks OpenBSD's |explicit_bzero| uses. Those tricks are not guaranteed to work for anything other than that one function on OpenBSD. > But that (as used in LibreSSL) seems to have problems in > relation to LTO, unless optimizations are specifically disabled: > https://github.com/libressl-portable/openbsd/issues/5 Right, this is more evidence that the only correct implementation is to use a compiler-provided |memset_s|, |explicit_bzero|, |SecureZeroMemory|. It is not possible to implement your own in a way that is guaranteed to work. If you need to implement your own. > On the other hand BoringSSL uses memset() with an explicit memory barrier > The explicit memory barrier is bad for performance. And, it also isn't guaranteed to work. I don't speak for the BoringSSL team, but in correspondence with them, they don't seem to care much if OpenSSL_cleanse works or if it is used. > > The primary purpose of the assembly language implementations is to > reduce the > > possibility that the C compiler will do the weird things that C > compilers love > > to do. > > According to the changelog and git log, the primary purpose of the asm > implementations was to improve performance (see commit b2dba9b). Using the > volatile pointer implementation would IMO make these optimizations useless, > hence the proposal to drop them and make things simpler. Sorry. Instead of "primary purpose" (which implies intent), I should have said 'primary advantage". An assembly language implementation is more likely to work than a C implementation because the C compiler generally won't analyze externally-assembled code, so it has to assume that the externally-assembled code has side effects, so it must call the externally-assembled code. In theory, it is possible for the assembler, C compiler, and the linker to work together during LTO and figure out that the assembly language implementation doesn't have any side effects other than zeroing memory, but that seems unlikely--much less likely than the C compiler subverting any trick. Note that sometimes I notice places that OpenSSL doesn't call OPENSSL_cleanse when it seems like it would be warranted to be consistent with other code. ecdh_compute_key [1] is one example. Generally, I don't expect OpenSSL to (securely) zero memory, so it doesn't matter much to me. But, if it matters to others, then this is something that would require an substantial amount of auditing and fixing. [1] https://github.com/openssl/openssl/blob/965a1cb92e4774ca2f74dad9e060aa7b2d80c77d/crypto/ecdh/ech_ossl.c#L82 Cheers, Brian -- https://briansmith.org/ From brian at briansmith.org Sat Oct 31 23:01:16 2015 From: brian at briansmith.org (Brian Smith) Date: Sat, 31 Oct 2015 13:01:16 -1000 Subject: [openssl-dev] [openssl.org #4116] [PATCH] Reimplement non-asm OPENSSL_cleanse() In-Reply-To: References: <20151031130526.GA11805@kronk.local> <20151031215017.GA2962@kronk.local> Message-ID: On Sat, Oct 31, 2015 at 11:50 AM, Alessandro Ghedini via RT wrote: > In any case memset_s is not available anywhere anyway, so that doesn't > really > matter. > Is it available in some places, e.g. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man3/memset_s.3.html . > > * Otherwise, SecureZeroMemory, when SecureZeroMemory is available. > > * Otherwise, if a flag OPENSSL_REQUIRE_SECURE_ZERO is set, fail. > > In 99% of the cases (e.g. Linux with glibc or any *BSD) that would fail, > so I > don't see the point in that. > The point is to let the person building OPENSSL say "I want the build to fail if there isn't a secure way to zero memory, because I'm expecting there to always be one in my configuration." Alternatively, there could be an OPENSSL_USE_MEMSET_S flag that says "always use memset_s and never anything else." > > Note in particular that the C compiler is allowed to completely defeat > the > > purpose of the function unless SecureZeroMemory or memset_s is used, even > > if you use "volatile" or other tricks. > > I don't think that is true (regarding the volatile pointer). But assuming > that > a broken compiler decided to optimize that call away, what's stopping it to > optimize the call to the asm implementation as well? Also, such broken > compiler > probably wouldn't know about C11 either, so even if memset_s() was > available it > could optimize that as well. > Such optimizations are legal. Otherwise, C11 wouldn't have defined |memset_s|. And, the entire purpose of |memset_s| is to disable such optimizations. > I don't know how compilers are supposed to treat memset_s(), but if I > define a > memset_s() function which just calls memset() internally, GCC (v5.2.1 > 20151028) > optimizes that away just as it does with plain memset(), so libc > implementations would probably need to adopt "tricks" to avoid the > optimization > as well. > Right. It has to be built into the compiler. > FWIW OpenSSH implements the portable explicit_bzero() using the volatile > pointer as well (unless memset_s() is detected at build time). That is similar to what I'm suggesting. > On OpenBSD it > just uses OpenBSD's explicit_bzero() which is implemented using memset() > and a > weak function pointer. It is a good idea to detect OpenBSD at compile time and use |explicit_bzero|, just like for |SecureZeroMemory| on Windows. Don't pay much attention to what tricks OpenBSD's |explicit_bzero| uses. Those tricks are not guaranteed to work for anything other than that one function on OpenBSD. > But that (as used in LibreSSL) seems to have problems in > relation to LTO, unless optimizations are specifically disabled: > https://github.com/libressl-portable/openbsd/issues/5 Right, this is more evidence that the only correct implementation is to use a compiler-provided |memset_s|, |explicit_bzero|, |SecureZeroMemory|. It is not possible to implement your own in a way that is guaranteed to work. If you need to implement your own. > On the other hand BoringSSL uses memset() with an explicit memory barrier > The explicit memory barrier is bad for performance. And, it also isn't guaranteed to work. I don't speak for the BoringSSL team, but in correspondence with them, they don't seem to care much if OpenSSL_cleanse works or if it is used. > > The primary purpose of the assembly language implementations is to > reduce the > > possibility that the C compiler will do the weird things that C > compilers love > > to do. > > According to the changelog and git log, the primary purpose of the asm > implementations was to improve performance (see commit b2dba9b). Using the > volatile pointer implementation would IMO make these optimizations useless, > hence the proposal to drop them and make things simpler. Sorry. Instead of "primary purpose" (which implies intent), I should have said 'primary advantage". An assembly language implementation is more likely to work than a C implementation because the C compiler generally won't analyze externally-assembled code, so it has to assume that the externally-assembled code has side effects, so it must call the externally-assembled code. In theory, it is possible for the assembler, C compiler, and the linker to work together during LTO and figure out that the assembly language implementation doesn't have any side effects other than zeroing memory, but that seems unlikely--much less likely than the C compiler subverting any trick. Note that sometimes I notice places that OpenSSL doesn't call OPENSSL_cleanse when it seems like it would be warranted to be consistent with other code. ecdh_compute_key [1] is one example. Generally, I don't expect OpenSSL to (securely) zero memory, so it doesn't matter much to me. But, if it matters to others, then this is something that would require an substantial amount of auditing and fixing. [1] https://github.com/openssl/openssl/blob/965a1cb92e4774ca2f74dad9e060aa7b2d80c77d/crypto/ecdh/ech_ossl.c#L82 Cheers, Brian -- https://briansmith.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: