stunnel 5.06 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Users, I have released version 5.06 of stunnel. This is a security bugfix release. Update is recommended. The ChangeLog entry: Version 5.06, 2014.10.15, urgency: HIGH: * Security bugfixes - OpenSSL DLLs updated to version 1.0.1j. https://www.openssl.org/news/secadv_20141015.txt - The insecure SSLv2 protocol is now disabled by default. It can be enabled with options = -NO_SSLv2. - The insecure SSLv3 protocol is now disabled by default. It can be enabled with options = -NO_SSLv3. - Default sslVersion changed to all (also in FIPS mode) to autonegotiate the highest supported TLS version. * New features - Added missing SSL options to match OpenSSL 1.0.1j. - New -options commandline option to display the list of supported SSL options. * Bugfixes - Fixed FORK threading build regression bug. - Fixed missing periodic Win32 GUI log updates. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 098c2b6db0793ea4fa5b6767ce6ef1853e9f6cc2f32133024be55f6a460b1a40 stunnel-5.06.tar.gz 55afb3013406da1afcc1ab7ccc25bb1c66605ca3e004636a6b49cac555cb4d09 stunnel-5.06-installer.exe a1741eb8bb050d3d29515ddef46a0a6828372a991f2658995dee1e06af8c05c8 stunnel-5.06-android.zip Best regards, Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlQ+4v4ACgkQ/NU+nXTHMtFwNwCgvZyndOwkAQqmsWnuL7DcRAPq lSIAnig726aVMrFzFAoQzKXxxmWo/Qo9 =ok3p -END PGP SIGNATURE- __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Compiling OpenSSL 1.0.0o
I downloaded the OpenSSL 1.0.0o source but I am running into a new problem when trying to compile it. The 'make depend' step fails with: s3_lib.c:2507:4: error: #error Code needs update for SSLv23_method() support beyond TLS1_VERSION. d1_lib.c:273:4: error: #error Code needs update for DTLS_method() support beyond DTLS1_VERSION. make[1]: *** [depend] Error 1 I have tracked this down to makedepend (and probably gcc) are using the header files (openssl/tls1.h) from the tool chain usr/include/openssl directory, rather than the header files from the source directory (the tool chain contains the header files from 1.0.0n). I confirmed that makedepend is being passed CFLAG= -I../crypto -I.. -I../include, but I suspect that the tool chain header file search path is being searched first. Any suggestions on how to resolve this? Jay __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
compile prob with xlc/aix 0.9.8zc
Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various versions on xlc Aix 7.1 has xlc 11.1 Aix 6.1 has xlc 9 Both fail given these steps: ./config shared threads Compiles for aix-cc making all in crypto/rsa... gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa' cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_eay.o rsa_eay.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_gen.o rsa_gen.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_lib.o rsa_lib.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_sign.o rsa_sign.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_saos.o rsa_saos.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_err.o rsa_err.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible missing ';' or ','? gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/san/dev/ssl/0.9.8/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/san/dev/ssl/0.9.8/crypto' gmake: *** [build_crypto] Error 1 gmake error the err thrown, syntax err on line 84, is an inline function. This is a new header which doesn't exist in prior 098 vers, so it seems to me (098zb version compiles clean on aix, this offending header is not there). Hpux/solaris/linux have not see any compile errs with zc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On 10/15/2014 01:46 AM, Bodo Moeller wrote: Here's a patch for the OpenSSL 1.0.1 branch that adds support for TLS_FALLBACK_SCSV, which can be used to counter the POODLE attack (CVE-2014-3566; https://www.openssl.org/~bodo/ssl-poodle.pdf). Note that the CVE identifier was assigned to the SSL 3.0 protocol issue related to CBC padding. The new SCSV does not help with that at all. But that's not a problem: when both parties support TLS, OpenSSL is not vulnerable even if both sides still enable SSL 3.0 for interoperability reasons with other peers. MITRE has not issued a CVE for the broken fallback behavior because it is not a security vulnerability—it works as designed. This means that the TLS_FALLBACK_SCSV patch currently has no CVE associated with it. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Is it possible to disable SSLv3 for all openssl-enabled applications via settings in openssl.cnf?
Would you like all your OpenSSL-enabled applications to be configured all the same, with the same protocols and same ciphersuites? -- Erwann ABALEA Le 15/10/2014 23:56, Todd Pfaff a écrit : I'd like to be able to disable SSLv3 for all openssl-enabled applications in a single configuration file if possible, so that this doesn't have to be done for each application. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Patch to mitigate CVE-2014-3566 (POODLE)
On 10/16/2014 10:41 AM, Salz, Rich wrote: Note that the CVE identifier was assigned to the SSL 3.0 protocol issue related to CBC padding. The new SCSV does not help with that at all. What? It prevents silently falling back to the broken protocol. Perhaps we can keep this battle-thread just in the TLS WG mail? It's unrelated to the TLS WG discussion. MITRE has assigned the CVE name to the SSL 3.0 protocol issue, specifically: “The SSL protocol 3.0, as used in OpenSSL through 1.0.1i and other products, uses nondeterministic CBC padding, which makes it easier for man-in-the-middle attackers to obtain cleartext data via a padding-oracle attack, aka the POODLE issue.” http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-3566 Securing fallback is a workaround, but does not address the issue. You are still vulnerable if you use SSL 3.0 directly (because one of the peers supports only that), even if both peers implement SCSV. The proper fix comes with TLS 1.0+, and OpenSSL has implemented a transparent protocol upgrade for a long time. Don't be shy—you fixed POODLE before it was discovered, which is great! I had already asked for assignment of a separate CVE for the insecure browser fallback, but I was told that MITRE does not consider *that* a vulnerability because it is expected, documented behavior. This means that fallback-SCSV-related patches do not fix any CVE-named vulnerability, and certainly not CVE-2014-3566. Again, this is not related to the question whether the fallback SCSV is a good idea. It is a procedural issue with CVE naming. Curiously, we recently had the same problem with the bash prefix/suffix patch, which did not fix any concrete CVE-named vulnerability, either. It is confusing, and I think it shows a limitation of the CVE authority file in the light of its current applications. -- Florian Weimer / Red Hat Product Security __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Is it possible to disable SSLv3 for all openssl-enabled applications via settings in openssl.cnf?
Does the openssl library not read the config file thereby enforcing what is available to all applications that use the openssl library? Or am I being too optimistic? What behaviour exists within the openssl library when it is built and configured with options to disable certain protocols or ciphers that could not be duplicated with runtime configuration options? I realize that those runtime configuration options may not yet exist - they do not according to Rich's response to my previous email - but that is what I was hoping for when I asked my question yesterday. If this behaviour is not possible in openssl, I'm now wondering how feasible it would be to interpose a library to intercept openssl calls and modify application requests for protocols or ciphers. tp On Thu, 16 Oct 2014, Dmitry Belyavsky wrote: Hello Rich, Unfortunately not all applications read the openssl config file... On Thu, Oct 16, 2014 at 2:53 AM, Salz, Rich rs...@akamai.com wrote: I'd like to be able to disable SSLv3 for all openssl-enabled applications in a single configuration file if possible, so that this doesn't have to be done for each application. No it's not possible. Not enhancement idea, tho. AARGH. Nice enhancement idea. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org -- SY, Dmitry Belyavsky __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-users] Is it possible to disable SSLv3 for all openssl-enabled applications via settings in openssl.cnf?
On Thu, 16 Oct 2014, Erwann Abalea wrote: Would you like all your OpenSSL-enabled applications to be configured all the same, with the same protocols and same ciphersuites? No. I was just wondering whether it was possible to exclude support for SSLv3 at runtime in one place for all openssl-enabled applications, rather than having to rebuild openssl from source to achieve this same result. tp __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Is it possible to disable SSLv3 for all openssl-enabled applications via settings in openssl.cnf?
Does the openssl library not read the config file thereby enforcing what is available to all applications that use the openssl library? No it does not. What behaviour exists within the openssl library when it is built and configured with options to disable certain protocols or ciphers that could not be duplicated with runtime configuration options? Many things. Making a list of be an interesting and useful exercise, but nobody's ever done it. If this behaviour is not possible in openssl, I'm now wondering how feasible it would be to interpose a library to intercept openssl calls and modify application requests for protocols or ciphers. It would be highly platform specific, but it is fairly feasible. It won't catch everything. For example, an application could set the mode bits directly (we've seen it), rather than call SSL_ctrl(). The safest code is that which doesn't exist. #ifdef is a better defense, if you can afford it (some can't use it because they need runtime behavior control). -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Patch to mitigate CVE-2014-3566 (POODLE)
Again, this is not related to the question whether the fallback SCSV is a good idea. It is a procedural issue with CVE naming. Then take it up with the CVE folks. Not here. :) -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: stunnel 5.06 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Mike, Latest build seems to be broken for me on OS X 10.10. If it matters here, since the error is SSL related, I'm building against OpenSSL 1.0.1j which is configured without ssl2 ciphers but with ssl3 ciphers enabled. This is the error: libtool: link: clang -pthread -fstack-protector -fPIE -g -O2 -Wall - -Wextra -Wno-long-long -pedantic -o stunnel stunnel-str.o stunnel-file.o stunnel-client.o stunnel-log.o stunnel-options.o stunnel-protocol.o stunnel-network.o stunnel-resolver.o stunnel-ssl.o stunnel-ctx.o stunnel-verify.o stunnel-sthreads.o stunnel-fd.o stunnel-stunnel.o stunnel-pty.o stunnel-libwrap.o stunnel-ui_unix.o - -L/usr/local/opt/openssl/lib64 -L/usr/local/opt/openssl/lib -lssl - -lcrypto -lz -lpthread -pthread Undefined symbols for architecture x86_64: _SSLv2_client_method, referenced from: _parse_service_option in stunnel-options.o _SSLv2_server_method, referenced from: _parse_service_option in stunnel-options.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[1]: *** [stunnel] Error 1 make[1]: *** Waiting for unfinished jobs libtool: link: ( cd .libs rm -f libstunnel.la ln -s ../libstunnel.la libstunnel.la ) make: *** [install-recursive] Error 1 Hope that's useful. Let me know if you need more. Dom Sent from Thunderbird for OS X. My PGP public key is automatically attached to this email. On 15/10/2014 22:11, Michal Trojnara wrote: Dear Users, I have released version 5.06 of stunnel. This is a security bugfix release. Update is recommended. The ChangeLog entry: Version 5.06, 2014.10.15, urgency: HIGH: * Security bugfixes - OpenSSL DLLs updated to version 1.0.1j. https://www.openssl.org/news/secadv_20141015.txt - The insecure SSLv2 protocol is now disabled by default. It can be enabled with options = -NO_SSLv2. - The insecure SSLv3 protocol is now disabled by default. It can be enabled with options = -NO_SSLv3. - Default sslVersion changed to all (also in FIPS mode) to autonegotiate the highest supported TLS version. * New features - Added missing SSL options to match OpenSSL 1.0.1j. - New -options commandline option to display the list of supported SSL options. * Bugfixes - Fixed FORK threading build regression bug. - Fixed missing periodic Win32 GUI log updates. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 098c2b6db0793ea4fa5b6767ce6ef1853e9f6cc2f32133024be55f6a460b1a40 stunnel-5.06.tar.gz 55afb3013406da1afcc1ab7ccc25bb1c66605ca3e004636a6b49cac555cb4d09 stunnel-5.06-installer.exe a1741eb8bb050d3d29515ddef46a0a6828372a991f2658995dee1e06af8c05c8 stunnel-5.06-android.zip Best regards, Mike __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUP8q4AAoJEIclJNuddDJsj/MP/04xoTfsFvWOM1bCv0K3ujcr 2/FiFwzhhIntm0UH/UdEv8M8PxdMnYAAwRBYY2oB4r349IJWyZf9w/NCfW/PwJit 1Tpu86i7cn+qjVyYTp88R6/LdU26UuSawrlg1I8mQgYaUePgcWtqpeLu8cHlqvgj uwJjrdGMJcd37wG8M+i4CPg3RyaY4ymKij4LUFTMlu2jVT5XvJdguDpxraAJ9eX6 7nfW1eTmX0VI5+BfHgEkwLGzB8fT9f+PD6RKNzU2HCsDzpmxjrVWXk/ewV0BTGLU spUldlBmG6JK14xQje2Gy3teS9ixU76gnKPgY2FlH5pvdehN9Ho0c9dT3d/Bxih2 34kO72yIhhS0oyUv34CHG/4VzHhwyJ3lEaYkU46W2gXHUlsLh7ujidmWekwFpAbR +J/r2RU6tsBLHYFFHqgTDYnVmPo7x8NrCzDNzCTdB2zyhmujfMH2ei+2+90ZUYyf vf+o/fcd3g5rZfOMB8RAV45qrDAy+P6AoX3lrS0w1VVa587HAD+E5U4fNnMuind6 00nkUxmhpPjzlApd0Jr01ibeKAGd6/Dro7qOlkBG+2JSyIRZQSNiA8SlUXcsruos +x0KdNxSgtldgSwchWZ2UkbyatmC2MEl71DigQpIff79w1vptSbIoHBjpa2OVvBZ IqXlUM9UnxqgacJoLzi4 =zQAn -END PGP SIGNATURE- 0x9D74326C.asc Description: application/pgp-keys 0x9D74326C.asc.sig Description: Binary data
Segfault in 1.0.1j BIO_reset() compiled with no-ssl2 no-ssl3
Hi, I get the following segfault when trying to send an SSLv3 request to the reverse proxy pound, running on openssl-1.0.1j with SSLv2/3 disabled: Program received signal SIGSEGV, Segmentation fault. [Switching to LWP 14548] 0xb77498fa in ssl_ctrl (b=0xb7001010, cmd=1, num=0, ptr=0x0) at bio_ssl.c:312 312 if (ssl-handshake_func == ssl-method-ssl_connect) (gdb) bt #0 0xb77498fa in ssl_ctrl (b=0xb7001010, cmd=1, num=0, ptr=0x0) at bio_ssl.c:312 #1 0xb75f8bf2 in BIO_ctrl (b=0xb7001010, cmd=1, larg=0, parg=0x0) at bio_lib.c:370 #2 0x0804e942 in do_http (arg=0x807ced0) at http.c:656 #3 0x080538d6 in thr_http_single (dummy=0x807ced0) at http.c:1793 #4 0xb74ee99b in ?? () from /lib/libpthread.so.0 #5 0xb745747e in clone () from /lib/libc.so.6 The problem is that ssl-method is NULL: (gdb) printf %p\n, ((SSL*) ((BIO_SSL *)b-ptr)-ssl)-method (nil) The segfault does not occur if I additionally disable SSLv2/3 in the application: SSL_CTX_set_options(p-ctx, SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3); For your reference, here's the corresponding application code. Segfault occurs in BIO_reset() on line 641 (I'm using some patches, so line numbering from my backtrace is slightly off): https://github.com/goochjj/pound/blob/stage_for_upstream/v2.7b/http.c#L641 Maybe someone could take a look... Thanks, Frank __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
openssl support for ALPN
Hi, Do we have a patch for ALPN extension ? Thanks, Jayadev
Re: FIPS 1.2.4 and OpenSSL 0.9.8zc Fails 'make test'
On Wed, Oct 15, 2014, Russell Selph wrote: Apologies if this is a duplicate post. I tried first via Google Groups, but apparently it's read-only. ;-) Has anyone else built 0.9.8zc with FIPS 1.2.4? I've been unable to get a build that passes the 'make test' phase. I'm using build scripts that worked for 0.9.8.zb. (More details on the scripts below.) This is happening on Linux RHEL5 (gcc 4.1.2), Mac OS X 10.9.5 (Xcode 6.0.1), as well as Windows 7 (VS 2010). Off hand, it seems like this kind of failure could be accounted for by something fundamental, such as an incompatible API change in libcrypto, or a word size mismatch between the FIPS and the libssl builds. I'm about to start digging through the diffs to get a handle on this, but I was wondering if I'm alone in having this problem. Any information about experiences positive or negative would be very helpful. The cause is a sanity check in exptest that x ** 0 mod 1 == 0. The BN library in OpenSSL itself was fixed to cover this case but the FIPS capable OpenSSL uses the BN library in the 1.2.x FIPS module which can't be fixed. See commit: 45d129511ff0b43be9a4271133c9ee22658ff07e This doesn't affect the normal operation of the FIPS modules so it can be ignored. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: Compiling OpenSSL 1.0.0o
On 10/15/2014 3:01 PM, Jay Foster wrote: I downloaded the OpenSSL 1.0.0o source but I am running into a new problem when trying to compile it. The 'make depend' step fails with: s3_lib.c:2507:4: error: #error Code needs update for SSLv23_method() support beyond TLS1_VERSION. d1_lib.c:273:4: error: #error Code needs update for DTLS_method() support beyond DTLS1_VERSION. make[1]: *** [depend] Error 1 I have tracked this down to makedepend (and probably gcc) are using the header files (openssl/tls1.h) from the tool chain usr/include/openssl directory, rather than the header files from the source directory (the tool chain contains the header files from 1.0.0n). I confirmed that makedepend is being passed CFLAG= -I../crypto -I.. -I../include, but I suspect that the tool chain header file search path is being searched first. Any suggestions on how to resolve this? Jay __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org I have resolved my problem. There was a --nostdinc option along with some -Ipath options to the tool chain include paths, so these were getting searched before the -Ipaths specified by the OpenSSL source. These did not show up on the makedepend output (where it was failing), but did on the gcc output when compiling. Ref https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html. Jay __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: compile prob with xlc/aix 0.9.8zc
Does applying the following two patches fix your build? http://git.openssl.org/gitweb/?p=openssl.gita=commith=8202802fadf7f70c656b92f3697da39c9c4271d7 http://git.openssl.org/gitweb/?p=openssl.gita=commith=e2e5326e5b068411999f62b4ba67835d64764ca5 These are build fixes that we appear to have missed out in 0.9.8. Emilia On Thu, Oct 16, 2014 at 5:58 AM, Kyle Chapman kyle.chap...@pb.com wrote: Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various versions on xlc Aix 7.1 has xlc 11.1 Aix 6.1 has xlc 9 Both fail given these steps: ./config shared threads Compiles for aix-cc making all in crypto/rsa... gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa' cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_eay.o rsa_eay.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_gen.o rsa_gen.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_lib.o rsa_lib.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_sign.o rsa_sign.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_saos.o rsa_saos.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_err.o rsa_err.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible missing ';' or ','? gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/san/dev/ssl/0.9.8/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/san/dev/ssl/0.9.8/crypto' gmake: *** [build_crypto] Error 1 gmake error the err thrown, syntax err on line 84, is an inline function. This is a new header which doesn't exist in prior 098 vers, so it seems to me (098zb version compiles clean on aix, this offending header is not there). Hpux/solaris/linux have not see any compile errs with zc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS 1.2.4 and OpenSSL 0.9.8zc Fails 'make test'
On Thu, Oct 16, 2014, Russell Selph wrote: Thanks. We're going ahead with patching 0.9.8zc to ignore this test. I'm not sure if it's the right solution, but given that 0.9.8 is EOL, and therefore FIPS 1.2.4 is VERY unlikely to ever be updated, would it be reasonable to have 0.9.8 disable this test when doing a FIPS build? It will never be updated. Fixing it would at least require a change letter for obsolete code and I suspect the labs wouldn't be able to approve a change to something that old. Changing BN might be considered security sensitive which would mean even that ridiculously unlikely route would be impossible. I only ask this because our customers are not generally comfortable with statements like You can't have FIPS any more, or It passes all the tests but one. I'd be happy to put together the patch to accomplish this, if it could be incorporated into the trunk for 0.9.8. No need. I'm looking into it. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: compile prob with xlc/aix 0.9.8zc
Thanks for the reply… Applied both sets of patches (on aix 71./xlc 11.1). I added –qlanglvl=extc99… even without this it fails with the original error cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -qlanglvl=extc99 -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 135.28: 1506-343 (S) Redeclaration of constant_time_lt differs from previous declaration on line 84 of ../constant_time_locl.h. ../constant_time_locl.h, line 135.28: 1506-050 (I) Return type unsigned int in redeclaration is not compatible with the previous return type int. gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/work/openssl-0.9.8zc/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/work/openssl-0.9.8zc/crypto' gmake: *** [build_crypto] Error 1 I was wrong in my original note, this fails at the same spot on hpux parisc and ia64, 11iv1 to v3 From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Emilia Käsper Sent: Thursday, October 16, 2014 12:37 PM To: openssl-users@openssl.org Subject: Re: compile prob with xlc/aix 0.9.8zc Does applying the following two patches fix your build? http://git.openssl.org/gitweb/?p=openssl.gita=commith=8202802fadf7f70c656b92f3697da39c9c4271d7 http://git.openssl.org/gitweb/?p=openssl.gita=commith=e2e5326e5b068411999f62b4ba67835d64764ca5 These are build fixes that we appear to have missed out in 0.9.8. Emilia On Thu, Oct 16, 2014 at 5:58 AM, Kyle Chapman kyle.chap...@pb.commailto:kyle.chap...@pb.com wrote: Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various versions on xlc Aix 7.1 has xlc 11.1 Aix 6.1 has xlc 9 Both fail given these steps: ./config shared threads Compiles for aix-cc making all in crypto/rsa... gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa' cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_eay.o rsa_eay.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_gen.o rsa_gen.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_lib.o rsa_lib.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_sign.o rsa_sign.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_saos.o rsa_saos.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_err.o rsa_err.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible missing ';' or ','? gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/san/dev/ssl/0.9.8/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/san/dev/ssl/0.9.8/crypto' gmake: *** [build_crypto] Error 1 gmake error the err thrown, syntax err on line 84, is an inline function. This is a new header which doesn't exist in prior 098 vers, so it seems to me (098zb version compiles clean on aix, this offending header is not there). Hpux/solaris/linux have not see any compile errs with zc. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.orgmailto:openssl-users@openssl.org Automated List Manager majord...@openssl.orgmailto:majord...@openssl.org
Re: compile prob with xlc/aix 0.9.8zc
That is a different error, but it seems to suggest you haven't applied the patches cleanly - you shouldn't be seeing ../constant_time_locl.h in the errors anymore as the first patch does -#include ../constant_time_locl.h +#include constant_time_locl.h On Thu, Oct 16, 2014 at 7:02 PM, Kyle Chapman kyle.chap...@pb.com wrote: Thanks for the reply… Applied both sets of patches (on aix 71./xlc 11.1). I added –qlanglvl=extc99… even without this it fails with the original error cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -qlanglvl=extc99 -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 135.28: 1506-343 (S) Redeclaration of constant_time_lt differs from previous declaration on line 84 of ../constant_time_locl.h. ../constant_time_locl.h, line 135.28: 1506-050 (I) Return type unsigned int in redeclaration is not compatible with the previous return type int. gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/work/openssl-0.9.8zc/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/work/openssl-0.9.8zc/crypto' gmake: *** [build_crypto] Error 1 I was wrong in my original note, this fails at the same spot on hpux parisc and ia64, 11iv1 to v3 *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Emilia Käsper *Sent:* Thursday, October 16, 2014 12:37 PM *To:* openssl-users@openssl.org *Subject:* Re: compile prob with xlc/aix 0.9.8zc Does applying the following two patches fix your build? http://git.openssl.org/gitweb/?p=openssl.gita=commith=8202802fadf7f70c656b92f3697da39c9c4271d7 http://git.openssl.org/gitweb/?p=openssl.gita=commith=e2e5326e5b068411999f62b4ba67835d64764ca5 These are build fixes that we appear to have missed out in 0.9.8. Emilia On Thu, Oct 16, 2014 at 5:58 AM, Kyle Chapman kyle.chap...@pb.com wrote: Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various versions on xlc Aix 7.1 has xlc 11.1 Aix 6.1 has xlc 9 Both fail given these steps: ./config shared threads Compiles for aix-cc making all in crypto/rsa... gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa' cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_eay.o rsa_eay.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_gen.o rsa_gen.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_lib.o rsa_lib.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_sign.o rsa_sign.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_saos.o rsa_saos.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_err.o rsa_err.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible missing ';' or ','? gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/san/dev/ssl/0.9.8/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/san/dev/ssl/0.9.8/crypto' gmake: *** [build_crypto] Error 1 gmake error the err thrown, syntax err on line 84, is an inline function. This is a new header which doesn't exist in prior 098 vers, so it seems to me (098zb version compiles clean on aix, this offending header is not there). Hpux/solaris/linux have not see any compile errs with zc. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org --
RE: compile prob with xlc/aix 0.9.8zc
Configured on aix 7.1 with:./config shared threads –qkeyword=inline And at least it compiles ok and make test works… running through some more options on aix and will see what compiler option may work on hpux From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Emilia Käsper Sent: Thursday, October 16, 2014 12:37 PM To: openssl-users@openssl.org Subject: Re: compile prob with xlc/aix 0.9.8zc Does applying the following two patches fix your build? http://git.openssl.org/gitweb/?p=openssl.gita=commith=8202802fadf7f70c656b92f3697da39c9c4271d7 http://git.openssl.org/gitweb/?p=openssl.gita=commith=e2e5326e5b068411999f62b4ba67835d64764ca5 These are build fixes that we appear to have missed out in 0.9.8. Emilia On Thu, Oct 16, 2014 at 5:58 AM, Kyle Chapman kyle.chap...@pb.commailto:kyle.chap...@pb.com wrote: Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various versions on xlc Aix 7.1 has xlc 11.1 Aix 6.1 has xlc 9 Both fail given these steps: ./config shared threads Compiles for aix-cc making all in crypto/rsa... gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa' cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_eay.o rsa_eay.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_gen.o rsa_gen.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_lib.o rsa_lib.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_sign.o rsa_sign.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_saos.o rsa_saos.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_err.o rsa_err.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible missing ';' or ','? gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/san/dev/ssl/0.9.8/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/san/dev/ssl/0.9.8/crypto' gmake: *** [build_crypto] Error 1 gmake error the err thrown, syntax err on line 84, is an inline function. This is a new header which doesn't exist in prior 098 vers, so it seems to me (098zb version compiles clean on aix, this offending header is not there). Hpux/solaris/linux have not see any compile errs with zc. __ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.orgmailto:openssl-users@openssl.org Automated List Manager majord...@openssl.orgmailto:majord...@openssl.org
RE: compile prob with xlc/aix 0.9.8zc
patches are in ok, the output is from the –I paths to the compiler. There was a local change to the header outside of the patches, which I reverted. Still didn’t change the build result until I changed the config options -- see incoming mail about that. Cut from the c file that fails first… * [including the GNU Public Licence.] */ #include constant_time_locl.h #include stdio.h #include cryptlib.h Basically… ./config shared threads results in: cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible missing ';' or ','? gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/work/openssl-0.9.8zc/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/work/openssl-0.9.8zc/crypto' gmake: *** [build_crypto] Error 1 ./config shared threads –qkeyword=inline Builds ok, make test works Trying this without the patches to see if it builds as well. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Emilia Käsper Sent: Thursday, October 16, 2014 1:39 PM To: openssl-users@openssl.org Subject: Re: compile prob with xlc/aix 0.9.8zc That is a different error, but it seems to suggest you haven't applied the patches cleanly - you shouldn't be seeing ../constant_time_locl.h in the errors anymore as the first patch does -#include ../constant_time_locl.h +#include constant_time_locl.h On Thu, Oct 16, 2014 at 7:02 PM, Kyle Chapman kyle.chap...@pb.commailto:kyle.chap...@pb.com wrote: Thanks for the reply… Applied both sets of patches (on aix 71./xlc 11.1). I added –qlanglvl=extc99… even without this it fails with the original error cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -qlanglvl=extc99 -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 135.28: 1506-343 (S) Redeclaration of constant_time_lt differs from previous declaration on line 84 of ../constant_time_locl.h. ../constant_time_locl.h, line 135.28: 1506-050 (I) Return type unsigned int in redeclaration is not compatible with the previous return type int. gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/work/openssl-0.9.8zc/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/work/openssl-0.9.8zc/crypto' gmake: *** [build_crypto] Error 1 I was wrong in my original note, this fails at the same spot on hpux parisc and ia64, 11iv1 to v3 From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org] On Behalf Of Emilia Käsper Sent: Thursday, October 16, 2014 12:37 PM To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Subject: Re: compile prob with xlc/aix 0.9.8zc Does applying the following two patches fix your build? http://git.openssl.org/gitweb/?p=openssl.gita=commith=8202802fadf7f70c656b92f3697da39c9c4271d7 http://git.openssl.org/gitweb/?p=openssl.gita=commith=e2e5326e5b068411999f62b4ba67835d64764ca5 These are build fixes that we appear to have missed out in 0.9.8. Emilia On Thu, Oct 16, 2014 at 5:58 AM, Kyle Chapman kyle.chap...@pb.commailto:kyle.chap...@pb.com wrote: Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various versions on xlc Aix 7.1 has xlc 11.1 Aix 6.1 has xlc 9 Both fail given these steps: ./config shared threads Compiles for aix-cc making all in crypto/rsa... gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa' cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_eay.o rsa_eay.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_gen.o rsa_gen.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_lib.o rsa_lib.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_sign.o rsa_sign.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_saos.o rsa_saos.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro
Re: compile prob with xlc/aix 0.9.8zc
Ah yes, I misread the first error log. This is about the 'inline' keyword. We've hopefully fixed this problem in the master branch as well, see commits 40155f408985aff2e9f1b61b7cb04a3e518633a1 and 55c7a4cf112bf154ed405ee05a6b7924b6b1ba92 They should essentially achieve the same as -qkeyword=inline, and I'll look into putting them to older branches. Emilia On Thu, Oct 16, 2014 at 7:53 PM, Kyle Chapman kyle.chap...@pb.com wrote: patches are in ok, the output is from the –I paths to the compiler. There was a local change to the header outside of the patches, which I reverted. Still didn’t change the build result until I changed the config options -- see incoming mail about that. Cut from the c file that fails first… * [including the GNU Public Licence.] */ #include constant_time_locl.h #include stdio.h #include cryptlib.h Basically… ./config shared threads results in: cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible missing ';' or ','? gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/work/openssl-0.9.8zc/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/work/openssl-0.9.8zc/crypto' gmake: *** [build_crypto] Error 1 ./config shared threads –qkeyword=inline Builds ok, make test works Trying this without the patches to see if it builds as well. *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Emilia Käsper *Sent:* Thursday, October 16, 2014 1:39 PM *To:* openssl-users@openssl.org *Subject:* Re: compile prob with xlc/aix 0.9.8zc That is a different error, but it seems to suggest you haven't applied the patches cleanly - you shouldn't be seeing ../constant_time_locl.h in the errors anymore as the first patch does -#include ../constant_time_locl.h +#include constant_time_locl.h On Thu, Oct 16, 2014 at 7:02 PM, Kyle Chapman kyle.chap...@pb.com wrote: Thanks for the reply… Applied both sets of patches (on aix 71./xlc 11.1). I added –qlanglvl=extc99… even without this it fails with the original error cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -qlanglvl=extc99 -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 135.28: 1506-343 (S) Redeclaration of constant_time_lt differs from previous declaration on line 84 of ../constant_time_locl.h. ../constant_time_locl.h, line 135.28: 1506-050 (I) Return type unsigned int in redeclaration is not compatible with the previous return type int. gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/work/openssl-0.9.8zc/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/work/openssl-0.9.8zc/crypto' gmake: *** [build_crypto] Error 1 I was wrong in my original note, this fails at the same spot on hpux parisc and ia64, 11iv1 to v3 *From:* owner-openssl-us...@openssl.org [mailto: owner-openssl-us...@openssl.org] *On Behalf Of *Emilia Käsper *Sent:* Thursday, October 16, 2014 12:37 PM *To:* openssl-users@openssl.org *Subject:* Re: compile prob with xlc/aix 0.9.8zc Does applying the following two patches fix your build? http://git.openssl.org/gitweb/?p=openssl.gita=commith=8202802fadf7f70c656b92f3697da39c9c4271d7 http://git.openssl.org/gitweb/?p=openssl.gita=commith=e2e5326e5b068411999f62b4ba67835d64764ca5 These are build fixes that we appear to have missed out in 0.9.8. Emilia On Thu, Oct 16, 2014 at 5:58 AM, Kyle Chapman kyle.chap...@pb.com wrote: Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various versions on xlc Aix 7.1 has xlc 11.1 Aix 6.1 has xlc 9 Both fail given these steps: ./config shared threads Compiles for aix-cc making all in crypto/rsa... gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa' cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_eay.o rsa_eay.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_gen.o rsa_gen.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_lib.o rsa_lib.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include
RE: compile prob with xlc/aix 0.9.8zc
Applied the patch to e_os.h Hp now builds without any hacks, and aix no longer requires -qlanglvl=extc99 or –qkeyword=inline From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Emilia Käsper Sent: Thursday, October 16, 2014 3:09 PM To: openssl-users@openssl.org Subject: Re: compile prob with xlc/aix 0.9.8zc Ah yes, I misread the first error log. This is about the 'inline' keyword. We've hopefully fixed this problem in the master branch as well, see commits 40155f408985aff2e9f1b61b7cb04a3e518633a1 and 55c7a4cf112bf154ed405ee05a6b7924b6b1ba92 They should essentially achieve the same as -qkeyword=inline, and I'll look into putting them to older branches. Emilia On Thu, Oct 16, 2014 at 7:53 PM, Kyle Chapman kyle.chap...@pb.commailto:kyle.chap...@pb.com wrote: patches are in ok, the output is from the –I paths to the compiler. There was a local change to the header outside of the patches, which I reverted. Still didn’t change the build result until I changed the config options -- see incoming mail about that. Cut from the c file that fails first… * [including the GNU Public Licence.] */ #include constant_time_locl.h #include stdio.h #include cryptlib.h Basically… ./config shared threads results in: cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 84.15: 1506-277 (S) Syntax error: possible missing ';' or ','? gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/work/openssl-0.9.8zc/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/work/openssl-0.9.8zc/crypto' gmake: *** [build_crypto] Error 1 ./config shared threads –qkeyword=inline Builds ok, make test works Trying this without the patches to see if it builds as well. From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org] On Behalf Of Emilia Käsper Sent: Thursday, October 16, 2014 1:39 PM To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Subject: Re: compile prob with xlc/aix 0.9.8zc That is a different error, but it seems to suggest you haven't applied the patches cleanly - you shouldn't be seeing ../constant_time_locl.h in the errors anymore as the first patch does -#include ../constant_time_locl.h +#include constant_time_locl.h On Thu, Oct 16, 2014 at 7:02 PM, Kyle Chapman kyle.chap...@pb.commailto:kyle.chap...@pb.com wrote: Thanks for the reply… Applied both sets of patches (on aix 71./xlc 11.1). I added –qlanglvl=extc99… even without this it fails with the original error cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -qlanglvl=extc99 -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -c -o rsa_pk1.o rsa_pk1.c ../constant_time_locl.h, line 135.28: 1506-343 (S) Redeclaration of constant_time_lt differs from previous declaration on line 84 of ../constant_time_locl.h. ../constant_time_locl.h, line 135.28: 1506-050 (I) Return type unsigned int in redeclaration is not compatible with the previous return type int. gmake[2]: *** [rsa_pk1.o] Error 1 gmake[2]: Leaving directory `/work/openssl-0.9.8zc/crypto/rsa' gmake[1]: *** [subdirs] Error 1 gmake[1]: Leaving directory `/work/openssl-0.9.8zc/crypto' gmake: *** [build_crypto] Error 1 I was wrong in my original note, this fails at the same spot on hpux parisc and ia64, 11iv1 to v3 From: owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.orgmailto:owner-openssl-us...@openssl.org] On Behalf Of Emilia Käsper Sent: Thursday, October 16, 2014 12:37 PM To: openssl-users@openssl.orgmailto:openssl-users@openssl.org Subject: Re: compile prob with xlc/aix 0.9.8zc Does applying the following two patches fix your build? http://git.openssl.org/gitweb/?p=openssl.gita=commith=8202802fadf7f70c656b92f3697da39c9c4271d7 http://git.openssl.org/gitweb/?p=openssl.gita=commith=e2e5326e5b068411999f62b4ba67835d64764ca5 These are build fixes that we appear to have missed out in 0.9.8. Emilia On Thu, Oct 16, 2014 at 5:58 AM, Kyle Chapman kyle.chap...@pb.commailto:kyle.chap...@pb.com wrote: Greetings folks. trying to compile 0.9.8zc on aix 7.1 (and 6.1) with various versions on xlc Aix 7.1 has xlc 11.1 Aix 6.1 has xlc 9 Both fail given these steps: ./config shared threads Compiles for aix-cc making all in crypto/rsa... gmake[2]: Entering directory `/san/dev/ssl/0.9.8/crypto/rsa' cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -I/usr/local/include -I/usr/local/ssl/include -c -o rsa_eay.o rsa_eay.c cc -I.. -I../.. -I../../include -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -q32 -O -DB_ENDIAN
Re: Context options and SSL_MODE_SEND_FALLBACK_SCSV
Hi, Il 16/10/2014 00:01, Salz, Rich ha scritto: I recommend that you always set that flag. Do I need to detect which OpenSSL version I have before setting that flag (otherwise it would break the application) or can I always safely set it on a SSL context? In other words: I'd like to do something like #ifndef SSL_MODE_SEND_FALLBACK_SCSV #define SSL_MODE_SEND_FALLBACK_SCSV 0x0080L #endif SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV) in order to have my app always do the right thing, without adding a bunch of intricate version checks, and having it working automagically when the system OpenSSL libraries get updated. Is it a good idea? Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME
Use of TLS_FALLBACK_SCSV
A few short (simple) questions about the use of TLS_FALLBACK_SCSV since we’re currently upgrading to the latest openssl releases. We don’t establish sessions with any other products than our own clients and servers. We’ve already disabled the use of SSLv3 in both our client and server releases going forward, is there any advantage in also using TLS_FALLBACK_SCSV – i.e. will there be any benefit in connecting to our already deployed clients and servers? (I actually don’t think that we’re vulnerable to POODLE since we don’t use anything like encrypted cookies or repeated messages that could be used to exploit padding changes to “peel off” decoded chunks. Is there any other mechanism to exploit this would make us vulnerable?) Where in the session establishment is TLS_FALLBACK_SCSV used and how would we incorporate it? I think a lot of folks will probably have these or similar questions, is there a FAQ somewhere to address this? Thanks in advance … N
Re: Use of TLS_FALLBACK_SCSV
On Thu, Oct 16, 2014 at 4:42 PM, Nou Dadoun ndad...@teradici.com wrote: ... We’ve already disabled the use of SSLv3 in both our client and server releases going forward, is there any advantage in also using TLS_FALLBACK_SCSV – i.e. will there be any benefit in connecting to our already deployed clients and servers? I can only help with this question. See Salz's answer at http://groups.google.com/d/msg/mailing.openssl.users/GTUVm-nFz2o/sxyB2bG3ZjwJ Jeff __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Context options and SSL_MODE_SEND_FALLBACK_SCSV
#ifndef SSL_MODE_SEND_FALLBACK_SCSV #define SSL_MODE_SEND_FALLBACK_SCSV 0x0080L #endif That will not work. You can do this: #ifdef SSL_MODE_SEND_FALLBACK_SCSV SSL_CTX_set_mode(ctx, SSL_MODE_SEND_FALLBACK_SCSV) #endif But that is not the same thing. You cannot just slip SCSV into an application without code changes to the application and to openssl. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.me Twitter: RichSalz
RE: Use of TLS_FALLBACK_SCSV
It does not matter who you talk to. With a POODLE attack, your content can be decrypted. Cookies, etc., were just used as an example. Disabling ssl3 is a good thing. But set the fallback because silently dropping from tls 1.2 to tls 1.1 is bad. It’s done during the handshake process as part of the cipher negotiation. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
RE: Use of TLS_FALLBACK_SCSV
But my understanding is that it requires the same content to be submitted repeatedly within a single session with manipulations to the padding to incrementally decrypt the content; we use ssl to protect our session establishment - think of a SIP call, SIP INVITE (offer) in one direction and SIP ACK (accept/refuse) in the other to establish session parameters and then the ssl connection is torn down and a different (non-ssl) encryption mechanism is used to protect the actual media stream. Any attempt to retransmit either INVITE or ACK will abort the session and in any case, no further sensitive material is sent subsequently to the ACK in the ssl session (there’s the equivalent of a BYE/BYE ACK). We plan to disable sslv3 anyway because we want to avoid being at risk in the future (and you point out a good argument for disabling the fallback in general) but within our controlled scenario, I don’t think we’re vulnerable to a POODLE attack unless there’s something I’m missing … N From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Salz, Rich Sent: October-16-14 4:24 PM To: openssl-users@openssl.org Subject: RE: Use of TLS_FALLBACK_SCSV It does not matter who you talk to. With a POODLE attack, your content can be decrypted. Cookies, etc., were just used as an example. Disabling ssl3 is a good thing. But set the fallback because silently dropping from tls 1.2 to tls 1.1 is bad. It’s done during the handshake process as part of the cipher negotiation. -- Principal Security Engineer, Akamai Technologies IM: rs...@jabber.memailto:rs...@jabber.me Twitter: RichSalz
