Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389
On Sun, 2012-04-15 at 16:45 +0200, Andy Polyakov via RT wrote: Here is an experimental patch I wrote that implements the 1/n-1 record splitting technique for OpenSSL. I am sending it here for consideration by OpenSSL upstream developers. By default the 0/n split is used but in case the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first record with 1/n-1. What would you [and others] say about this alternative? Non-committed, relative to HEAD... The patch seems OK however it is not clear whether this change really brings much. The original experimental patch is not really usable as there are already known applications which are even broken by the 1/n-1 split. So for SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS the split cannot be done at all anyway. Your patch will improve the compatibility of the case where SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not used however I have not seen any reports, at least in our Bugzilla, that would ask for that. So it's just a matter of preference whether you want to change the 0/n split to 1/n-1 one. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389
Here is an experimental patch I wrote that implements the 1/n-1 record splitting technique for OpenSSL. I am sending it here for consideration by OpenSSL upstream developers. By default the 0/n split is used but in case the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first record with 1/n-1. What would you [and others] say about this alternative? Non-committed, relative to HEAD... The patch seems OK however it is not clear whether this change really brings much. The original experimental patch is not really usable as there are already known applications which are even broken by the 1/n-1 split. So for SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS the split cannot be done at all anyway. Your patch will improve the compatibility of the case where SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not used however I have not seen any reports, at least in our Bugzilla, that would ask for that. So it's just a matter of preference whether you want to change the 0/n split to 1/n-1 one. Have you heard of *clients* that suffer from 1/n-1 split? I mean if clients are tolerant to it, it might make sense to favor 1/n-1 on server side. Major obstacle for 0/n used to be Microsoft TLS or in more practical terms IE, and with 1/n-1 IE would work... As for client side, arguably it would make things worth. I mean if client plays smart and implements 1/n-1 split itself depending on situation, e.g. not when using POST, then such split in libssl would be counterproductive. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389
On Mon, 2012-04-16 at 11:49 +0200, Andy Polyakov via RT wrote: Here is an experimental patch I wrote that implements the 1/n-1 record splitting technique for OpenSSL. I am sending it here for consideration by OpenSSL upstream developers. By default the 0/n split is used but in case the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first record with 1/n-1. What would you [and others] say about this alternative? Non-committed, relative to HEAD... The patch seems OK however it is not clear whether this change really brings much. The original experimental patch is not really usable as there are already known applications which are even broken by the 1/n-1 split. So for SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS the split cannot be done at all anyway. Your patch will improve the compatibility of the case where SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is not used however I have not seen any reports, at least in our Bugzilla, that would ask for that. So it's just a matter of preference whether you want to change the 0/n split to 1/n-1 one. Have you heard of *clients* that suffer from 1/n-1 split? I mean if clients are tolerant to it, it might make sense to favor 1/n-1 on server side. Major obstacle for 0/n used to be Microsoft TLS or in more practical terms IE, and with 1/n-1 IE would work... I did not hear about any HTTPS clients that would be intolerant of the 1/n-1 split but other TLS usage (VPN, Jabber, ?) might be different in this respect. But I do not know of any concrete cases where the client is intolerant of the split. As for client side, arguably it would make things worth. I mean if client plays smart and implements 1/n-1 split itself depending on situation, e.g. not when using POST, then such split in libssl would be counterproductive. I do not know of any client that uses libssl as TLS backend that would do such 1/n-1 split on itself. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2790] [PATCH] Better compatibility with C++ compilers and MSDEV memory debugger
On Fri, 13 Apr 2012 17:02:07 +0200, Andy Polyakov via RT r...@openssl.org wrote: 2) Structure x509_lookup_method_st aka X509_LOOKUP_METHOD has a member called free. It conflicts with MS Visual Studio memory debugger. When memory debugger is enabled, it defines the following: #define free(p) _free_dbg(p, _NORMAL_BLOCK) And compilation fails. The patch renames free to free_item, analogous to new_item member in the same structure. Renaming structure members in released code is not desirable. How about --- crypto/x509/x509_lu.c 19 Feb 2010 18:27:07 - 1.34 +++ crypto/x509/x509_lu.c 13 Apr 2012 14:58:30 - @@ -87,7 +87,7 @@ if (ctx == NULL) return; if ((ctx-method != NULL) (ctx-method-free != NULL)) - ctx-method-free(ctx); + (*ctx-method-free)(ctx); OPENSSL_free(ctx); } instead? Yes, it seems to work. I couldn't check it with the MSDEV memory debugger, but I've made a simple testing patch (attached) and tried it. It compiled successfully both by GCC on Linux and by MSDEV on Windows. -- Alexei. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2790] [PATCH] Better compatibility with C++ compilers and MSDEV memory debugger
On Fri, 13 Apr 2012 17:02:07 +0200, Andy Polyakov via RT r...@openssl.org wrote: 2) Structure x509_lookup_method_st aka X509_LOOKUP_METHOD has a member called free. It conflicts with MS Visual Studio memory debugger. When memory debugger is enabled, it defines the following: #define free(p) _free_dbg(p, _NORMAL_BLOCK) And compilation fails. The patch renames free to free_item, analogous to new_item member in the same structure. Renaming structure members in released code is not desirable. How about --- crypto/x509/x509_lu.c 19 Feb 2010 18:27:07 - 1.34 +++ crypto/x509/x509_lu.c 13 Apr 2012 14:58:30 - @@ -87,7 +87,7 @@ if (ctx == NULL) return; if ((ctx-method != NULL) (ctx-method-free != NULL)) - ctx-method-free(ctx); + (*ctx-method-free)(ctx); OPENSSL_free(ctx); } instead? Yes, it seems to work. I couldn't check it with the MSDEV memory debugger, but I've made a simple testing patch (attached) and tried it. It compiled successfully both by GCC on Linux and by MSDEV on Windows. -- Alexei. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Hi
you should definitely give this a look http://www.panews15.net/biz/?employment=5423043 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
ENGINE reference leak using FIPS-capable OpenSSL
I've been investigating a memory leak in using a FIPS-capable OpenSSL in
non-FIPS mode.
For example, the following code does not seem to be correct in evp_enc.c:
int EVP_CipherInit_ex(EVP_CIPHER_CTX *ctx, const EVP_CIPHER *cipher, ENGINE
*impl,
...
#ifndef OPENSSL_NO_ENGINE
if(impl)
{
if (!ENGINE_init(impl))
{
EVPerr(EVP_F_EVP_CIPHERINIT_EX,
EVP_R_INITIALIZATION_ERROR);
return 0;
}
}
else
/* Ask if an ENGINE is reserved for this job */
impl = ENGINE_get_cipher_engine(cipher-nid);
if(impl)
{
/* There's an ENGINE for this job ... (apparently) */
const EVP_CIPHER *c = ENGINE_get_cipher(impl, cipher-nid);
if(!c)
{
/* One positive side-effect of US's export
* control history, is that we should at least
* be able to avoid using US mispellings of
* initialisation? */
EVPerr(EVP_F_EVP_CIPHERINIT_EX,
EVP_R_INITIALIZATION_ERROR);
return 0;
}
/* We'll use the ENGINE's private cipher definition */
cipher = c;
/* Store the ENGINE functional reference so we know
* 'cipher' came from an ENGINE and we need to release
* it when done. */
ctx-engine = impl;
}
else
ctx-engine = NULL;
#endif
#ifdef OPENSSL_FIPS
return FIPS_cipherinit(ctx, cipher, key, iv, enc);
#else
So the code goes through all the motions of honoring the engine that exists and
incrementing reference counts, etc, but then blindly calls FIPS_cipherinit(),
which ends up removing the engine pointer from the context. I see in some
cases this behaviour, yet in others the call is wrapped with a test for FIPS
mode. E.g.:
int EVP_DigestInit_ex(EVP_MD_CTX *ctx, const EVP_MD *type, ENGINE *impl)
...
#ifdef OPENSSL_FIPS
if (FIPS_mode())
{
if (FIPS_digestinit(ctx, type))
return 1;
OPENSSL_free(ctx-md_data);
ctx-md_data = NULL;
return 0;
}
#endif
return ctx-digest-init(ctx);
}
Note that the Update call however has:
int EVP_DigestUpdate(EVP_MD_CTX *ctx, const void *data, size_t count)
{
#ifdef OPENSSL_FIPS
return FIPS_digestupdate(ctx, data, count);
#else
return ctx-update(ctx,data,count);
#endif
}
Should *all* calls be protected with a test for FIPS_mode()? Or is it
documented that a FIPS-capable OpenSSL is not compatible with the usage of
engines, even in non-FIPS mode?
Erik Tkal
Juniper OAC/UAC/Pulse Development
Re: [openssl.org #2790] [PATCH] Better compatibility with C++ compilers and MSDEV memory debugger
On Mon, 16 Apr 2012 12:31:05 +0200, Alexei Khlebnikov via RT r...@openssl.org wrote: ... but I've made a simple testing patch (attached) ... Forgot to attach the testing patch! Attaching now. -- Alexei. redefined-free-testing.2012-04-16.patch Description: Binary data
Re: [openssl.org #2790] [PATCH] Better compatibility with C++ compilers and MSDEV memory debugger
On Mon, 16 Apr 2012 12:31:05 +0200, Alexei Khlebnikov via RT r...@openssl.org wrote: ... but I've made a simple testing patch (attached) ... Forgot to attach the testing patch! Attaching now. -- Alexei. redefined-free-testing.2012-04-16.patch Description: Binary data
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
It is still not working for me. I had tried all possible place to add /dynamicbase:NO and/or /fixed flag. I am wondering how it was working for Grant Averett. Where did you exactly add the /FIXED flag? Thanks, -Vimol On Sun, Apr 15, 2012 at 6:51 PM, Dr. Stephen Henson st...@openssl.orgwrote: On Sun, Apr 15, 2012, Vimol Kshetrimayum wrote: Andy Polyakov appro at openssl.org writes: I tested this on the x86 version of the DLL and I imagine it will fix the x64 DLL as well (they both reported the same error). It looks like this setting will need to be added for VS2010. As mentioned [in another reply], I was under impression that x64 code is always position-independent, i.e. I'd expect x64 to work even if relocated. Oh well... Closer look revealed that .text segment, code itself, *is* indeed position-independent, but not .rdata, which is also fingerprinted. In order for this to work it is implied that compiler moves relocatable data from .rdata segment. Unix compiler actually do that, but apparently not Windows A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev at openssl.org Automated List Manager majordomo at openssl.org I am facing same issue when I built x64 version of FIPS object module (1.2.3)and openSSL 0.9.8.u on Windows 7 with Visual Studio 2010. As suggested in this thread, I have edited the openssl-0.9.8u\ms\ntdll.mak and added /FIXED flag in LFLAGS as below. LFLAGS=/FIXED /nologo /subsystem:console /opt:ref Now, out32dll/fips_test_suite.exe running successfully after compiling with /FIXED linker option. However, my sample application which is linking dynamically with libeay32.dll is returning same finger print mismatch error.Sample application also links with /FIXED linker option. dumpbin shows no randomization code in DLL characteristics for both libeay32.dll and sample application. Here is the link lines for libeay32.dll: perl util\fipslink.pl /FIXED /nologo /subsystem:console /opt:ref /dll /map /base:0xFB0 /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def @C:\Users\VIMOL_~1\AppData\Local\Temp\nm9209.tmp Value of DLL characteristics from dumpbin: 100 DLL characteristics NX compatible Is the above value of link line and DLL characteristics correct? Or did I miss anything? Or is OS forcefully loading the libeay32.DLL at randomized address? Try adding: /fixed explicitly to the linker rule for libeay32.dll, it is the section beginning: $(O_CRYPTO): ... Alternatively you can add it to the MLFLAGS line in the makefile but that will affect ssleay32.dll too. If that doesn't work try /dynamicbase:no /fixed 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
It is still not working for me. I had tried all possible place to add /dynamicbase:NO and/or /fixed flag. Well, lack of dynamic base in DLL characteristics in dumpbin output is sufficient for knowing that /dynamicbase:no went down. As for /fixed, double-check if it has .reloc segment left. Without .reloc system really can't relocate .dll. If there is .reloc and it gets relocated, key question is why, run Process Explorer and look at dlls for your applications. Also verify if openssl.exe itself works with OPENSSL_FIPS environment variable set. If it does, question what is it *your* application does that makes fingerprinting fail. Submit .map file for ssleay32.dll. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: FIPS Module 1.2 build with Visual Studio 2010 fails self-tests
On Mon, Apr 16, 2012, Vimol Kshetrimayum wrote: It is still not working for me. I had tried all possible place to add /dynamicbase:NO and/or /fixed flag. I am wondering how it was working for Grant Averett. Where did you exactly add the /FIXED flag? That's weird. I can reproduce that issue with my setup and this fixes it: http://cvs.openssl.org/chngview?cn=22392 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 Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2790] [PATCH] Better compatibility with C++ compilers and MSDEV memory debugger
http://cvs.openssl.org/chngview?cn=22397 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2791] [PATCH] fix -DOPENSSL_NO_SOCK on sunos
Hi, This patch compiles out BIO_socket_nbio() and the body of BIO_new_ssl_connect() if OPENSSL_NO_SOCK is set. * BIO_socket_nbio() looks like its author forgot to put it in the #ifndef block. * BIO_new_ssl_connect() calls BIO_s_connect() which is compiled out by OPENSSL_NO_SOCK. It makes the linker on Solaris error out. http://cvs.openssl.org/chngview?cn=22401 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2635] 1/n-1 record splitting technique for CVE-2011-3389
On Mon, Oct 31, 2011 at 05:56:53PM +0100, Tomas Mraz via RT wrote: By default the 0/n split is used but in case the SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS flag is set, we split the first record with 1/n-1. There are terminators that also have a problem with this 1/n-1 splitting. You might want to read this for instance: http://www.imperialviolet.org/2012/01/15/beastfollowup.html So it would be nice to still have the option to not have either splitting, but I think we should default to 1/n-1. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2771] [BUG] Openssl 1.0.1 times out when connecting to Outlook Exchange 2007
On Sun, Apr 01, 2012 at 02:42:20PM +0200, Dr. Stephen Henson wrote: On Sun, Apr 01, 2012, Dr. Stephen Henson wrote: Did a quick hack modification setting header version to 0x3,0x0 and it now *will* connect to some sites it didn't before with a long client hello including paypal. It ends up negotiating TLS 1.2 anyway. I'll do some more tests to see what happens. SSLv3 or TLSv1 version in record header connects, anything higher hangs. So I'd say we set it to TLSv1 in header unless we only support SSLv3. That should retain compatibility with older versions of OpenSSL. Do you have a patch for this? Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
FIPS 2 mode with shared libs : Clarification needed .....
Dear all, ( On a Linux 2.6.32 x86_64 ) I'm trying to build a FIPS 2 openssl When I configure the fips code, config spits out as warning #cd openssl-fips-2.0-test-20120416 #./config Configured for linux-x86_64. WARNING: OpenSSL has been configured using unsupported option(s) to internally generate a fipscanister.o object module for TESTING PURPOSES ONLY; that compiled module is NOT FIPS 140-2 validated and CANNOT be used to replace the OpenSSL FIPS Object Module as identified by the CMVP (http://csrc.nist.gov/cryptval/) in any application requiring the use of FIPS 140-2 validated software. This is a test OpenSSL 2.0 FIPS module. See the file README.FIPS for details of how to build a test library. I *assume* that the warning is because we are using test software, rather than configuration problems ? And that the correct procedure is just ./config rather than ./config fipcanisteronly, which the README.FIPS suggests ? Secondly, once fipscansiter is built, ( and installed to /usr/local/ssl/fips-2.0 ), I should be using ... #cd openssl-1.0.1 #./config fips shared ( I want fipscanister in libcrypto.so.1 ) Is it ok to use fipscanister inside libcrypto this way ? Many thanks, Simon Convey __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
