Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
On 11/25/2015 06:48 PM, Kurt Roeckx wrote: > On Wed, Nov 25, 2015 at 01:02:29PM +0100, Florian Weimer wrote: >> On 11/23/2015 11:08 PM, Kurt Roeckx wrote: >> >>> I think that we currently don't do any compile / link test to >>> detect features but that we instead explicitly say so for each >>> platform. >>> >>> Anyway, the gcc the documentation is here: >>> https://gcc.gnu.org/onlinedocs/gcc/Thread-Local.html >>> >>> TLS support clearly isn't supported everywhere. >> >> The most portable approach is to switch C++11, which provides you >> thread-local variables with destructors (and you also get portable >> atomics). There are simply no standards-based C solutions as long as >> you have to support the Microsoft compiler under Windows. > > Please note that we use C, not C++. But C11 has the same atomics > extentions as C++11. C++11 support is much more widespread than C11 support. You will have trouble finding reliable support for C11 atomics with the Microsoft toolchain. > We're also currently still targetting C89/C90 (with some minor > extentions), but I think we should try to use them if the platform > supports it. It is a lot of working getting the atomics right on all supported platforms. Florian ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4172] SRP VBASE stuff still leaking memory
Hi, Following my previous mail, here attached is an updated patch against 1.02e to fix the SRP VBASE memory leaks. I understand the VBASE stuff is not a TLS critical component, but it is part of the SRP command line tool. NB : it's a pity that the base64 encoding is not the same than the one use elsewhere by OpenSSL. Regards, Michel. De : openssl-dev [mailto:openssl-dev-boun...@openssl.org] De la part de Michel Envoyé : lundi 23 mars 2015 12:10 À : openssl-dev@openssl.org Objet : [openssl-dev] SRP memory leaks and more leaks Hi, Trying to use the 'SRP' code, I found two kinds of memory leaks in srp_vfy.c . 1) The first kind was due to bad use of OpenSSL 'stack' code and cumbersome / confusing names of structure / functions. In this case, leaks occurs when loading a verifier file containing 'index' lines. Two structures are used : SRP_gN and SRP_gN_cache. And unfortunatly, the SRP_gN_free function free a SRP_gN_cache structure. The SRP_VBASE_free() function, line 276, should call : sk_SRP_gN_cache_pop_free(vb->gN_cache, SRP_gN_cache_free); instead of : sk_SRP_gN_cache_free(vb->gN_cache); And consequently the SRP_gN_cache_free() function, lines 305-312, has to move before SRP_VBASE_free() The attached patch solve this kind of leaks. 2) When simulating a 'fake user' as per RFC 5054, § '2.5.1.3. Unknown SRP User Name', the SRP_VBASE_get_by_user() function returns a newly allocated SRP_user_pwd structure whose adress is not kept anywhere else. So, the caller should free it later, but from outside the function, there is no way to distinguish between 'fake users' and real ones which are managed and freed throught the use of the SRP_VBASE structure / functions. I am afraid there is no other solution than changing the SRP_VBASE_get_by_user() function prototype. It is better I do not share here my opinion about the comments below : /* need to check whether there are memory leaks */, s_server.c line 433 or : /* there may be still some leaks to fix, */ srp_vfy.c line 449 >:( Hope this will save time to other users, Michel. srp_vfy-1.0.2e.patch Description: Binary data ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4174] Support the TLS Feature (aka Must Staple) X.509v3 extension (RFC7633)
https://github.com/openssl/openssl/pull/495 -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4173] help to check whether handshake negociates SRP or PSK ciphersuite
Hi,
I believe it would be nice to have an efficient way to check if handshake
results in a SRP or PSK ciphersuite.
As I do not like to trick with OpenSSL internal structures, I suggest to add
the following to ssl_ciph.c :
int SSL_CIPHER_is_PSK(const SSL_CIPHER *c)
{
if (c != NULL && c->algorithm_auth == SSL_aPSK) return 1;
return 0;
}
int SSL_CIPHER_is_SRP(const SSL_CIPHER *c)
{
if (c != NULL && c->algorithm_auth == SSL_aSRP) return 1;
return 0;
}
Might be a better alternative ?
By the way, I do not see a reason why SSL_CIPHER_get_id() is not protected
against NULL pointer dereference of SSL_CIPHER *c as in
SSL_CIPHER_get_bits() or SSL_CIPHER_get_name().
A patch against 1.0.2e is attached, but need update of .def ordinals.
Thanks for your work,
Michel
ssl_ciph-1.0.2e.patch
Description: Binary data
___
openssl-bugs-mod mailing list
openssl-bugs-...@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4171] Compile failure on OS X 10.7 clang with OpenSSL 1.0.2e
https://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=301a6dcd4590fb2f69d08259577e215b4cc3caa3#patch5 added a check to see if it should use the ADDX instructions based on the clang version. Unfortunately, on older versions of clang on OS X this check incorrectly returns true and compilation then fails due to not knowing the instructions: x86_64-mont.s:966:2 error: invalid instruction mnemonic 'adcxq' adcxq %rax,%r12 ^ The version of the compiler in question is: `Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)` (On an ancient OS X 10.7 VM) This issue was also filed in Github (https://github.com/openssl/openssl/issues/494) ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Need CVE-2015-3193 impact explained
The description of CVE-2015-3193 in 2015-12-04 security advisory states that EC algorithms are not affected, but attacks against DH are considered feasible. Not being a cryptographer that leaves me a bit confused. Are applications supporting cipher suites with ECDHE- variants vulnerable? Thanks, /Leif ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Need CVE-2015-3193 impact explained
> The description of CVE-2015-3193 in 2015-12-04 security advisory > states that EC algorithms are not affected, but attacks against DH are > considered feasible. > Not being a cryptographer that leaves me a bit confused. > Are applications supporting cipher suites with ECDHE- variants vulnerable? *No* EC algorithms are affected. Advisory refers to non-EC DH key exchange. So that answer to specific question is no. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Need CVE-2015-3193 impact explained
On Mon, Dec 07, 2015 at 10:53:15AM +0100, Leif Thuresson wrote: > The description of CVE-2015-3193 in 2015-12-04 security advisory > states that EC algorithms are not affected, but attacks against DH are > considered feasible. DH as distinct from ECDH. The issue affects modular exponentiation which is used in RSA and (finite-field) DH, but not ECDSA or ECDH. > Not being a cryptographer that leaves me a bit confused. > Are applications supporting cipher suites with ECDHE- variants vulnerable? Only to the extent that they are already vulnerable as a result of using RSA certificates to sign the key exchange parameters. The key exchange itself is not. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Need CVE-2015-3193 impact explained
On 2015-12-07 10:59, Viktor Dukhovni wrote: On Mon, Dec 07, 2015 at 10:53:15AM +0100, Leif Thuresson wrote: The description of CVE-2015-3193 in 2015-12-04 security advisory states that EC algorithms are not affected, but attacks against DH are considered feasible. DH as distinct from ECDH. The issue affects modular exponentiation which is used in RSA and (finite-field) DH, but not ECDSA or ECDH. Not being a cryptographer that leaves me a bit confused. Are applications supporting cipher suites with ECDHE- variants vulnerable? Only to the extent that they are already vulnerable as a result of using RSA certificates to sign the key exchange parameters. The key exchange itself is not. Thanks for the quick response. That is what I needed to know. regards, /Leif ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4170] Illegal instruction in sha1-586.asm when building for win32 using Visual Studio 2015
> When building openss-1.0.2e for win32 using Visual Studio 2015 I get error > in the assembler code: > > ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32dll\sha1-586.obj > tmp32dll\sha1-586.asm > Assembling: tmp32dll\sha1-586.asm > tmp32dll\sha1-586.asm(1432) : error A2070:invalid instruction operands > tmp32dll\sha1-586.asm(1576) : error A2070:invalid instruction operands > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual > Studio 14.0\VC\BIN\ml.EXE"' : return code > '0x1' > Stop. > > When building for win64 it builds without any errors. Quoting INSTALL.W32: - you need ... - Netwide Assembler, a.k.a. NASM, available from http://nasm.sourceforge.net/ is required if you intend to utilize assembler modules. Note that NASM is now the only supported assembler. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
On Mon, Dec 07, 2015 at 02:41:35PM +0100, Florian Weimer wrote: > On 11/25/2015 06:48 PM, Kurt Roeckx wrote: > > Please note that we use C, not C++. But C11 has the same atomics > > extentions as C++11. > > C++11 support is much more widespread than C11 support. You will have > trouble finding reliable support for C11 atomics with the Microsoft > toolchain. > > [...] > > It is a lot of working getting the atomics right on all supported platforms. The MSFT toolchain has its own intrisics, as do GCC/clang. A variety of OSes have their own atomics libraries (e.g., Solaris/Illumos, FreeBSD, and others). Linux has several as well, but I am not sure that the licensing on those will be compatible to link against (much less to incorporate as source in OpenSSL). Some of the BSD or CDDL licensed libraries might be possible to incorporate as source into OpenSSL. It's a solvable problem, but yes, a lot of work :( Still, it seems worth doing. Nico -- ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-team] Discussion: design issue: async and -lpthread
Maybe http://trac.mpich.org/projects/openpa/ would fit the bill? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
