Hanno Boeck via RT | 21 Apr 09:00 2015

[openssl.org #3816] Call of memcmp with null pointers in obj_cmp()

The function obj_cmp() (file crypto/objects/obj_dat.c) can in some
situations call memcmp() with a null pointer and a zero length.

This is invalid behaviour. When compiling openssl with undefined
behaviour sanitizer (add -fsanitize=undefined to compile flags) this
can be seen. One example that triggers this behaviour is the pkcs7
command (but there are others, e.g. I've seen it with the timestamp
apps/openssl pkcs7 -in test/testp7.pem

What happens is that obj_cmp takes objects of the type ASN1_OBJECT and
passes their ->data pointer to memcmp. Zero-sized ASN1_OBJECT
structures can have a null pointer as data.

Attached patch will check for zero-sized objects and won't call memcmp
on them.

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Palak Agarwal via RT | 21 Apr 09:00 2015

[openssl.org #3815] Issue with X509_NAME_hash in 0.9.8zb

The return value of X509_NAME_hash() has changed from 0.9.8zb onwards. 

I have written a sample program to verify the value return of X509_NAME_hash(). I linked the same program
with four different version of crypto library. The output is as below:

(Linux)(snapper53-64)progs{85} ./X509_NAME_hash_test.t
(Linux)(snapper53-64)progs{86} ./X509_NAME_hash_test.y
(Linux)(snapper53-64)progs{87} ./X509_NAME_hash_test.zb
(Linux)(snapper53-64)progs{88} ./X509_NAME_hash_test.zc

The extension in the binary name is the version of the openSSL. Below is the sample program:

  1 #include <stdio.h>
  2 #include <ctype.h>
  3 #include <string.h>
  4 #include "openssl/asn1.h"
  5 #include "openssl/objects.h"
  6 #include "openssl/x509.h"
  7 #include "openssl/x509v3.h"
  9 int add_entry_to_X509_NAME( X509_NAME* name,
 10                             const char* id,
 11                             const char* value)
(Continue reading)

noloader@gmail.com via RT | 20 Apr 19:01 2015

[openssl.org #3814] make dclean breaks build and tests

It appears `make dclean` still whacks a bunch of test files in Master.
It looks like at east 39 files are deleted:

$ git status | grep delete | wc -l


If the test/ directory is deleted, then that means its not possible to
test the library after a build. You might as well delete all the
source files and package what remains :)

It would probably be a better strategy to have `make dcean` put the
sources in a pristine state without deleting the test/ directory. This
way, those building the library can do so without extraneous cruft
from the development process. And they can test the library after


$ make clean && make dclean
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

(Continue reading)

Dmitry Belyavsky via RT | 20 Apr 19:00 2015

[openssl.org #3813] Fwd: Error building openssl on SUSE

Hello openssl-dev,

I got a problem building openssl 1.0.2a on SUSE.

>uname -a

Linux b-sles11-64 #1 SMP 2009-02-28 04:40:21 +0100
x86_64 x86_64 x86_64 GNU/Linux


> gcc -v
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3
--enable-ssp --disable-libssp --with-bugurl=
 --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap
--with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch
--enable-version-specific-runtime-libs --program-suffix=-4.3
--enable-linux-futex --without-system-libunwind --with-cpu=generic
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)

(Continue reading)

Bill Cox | 20 Apr 17:36 2015

Enhance Extended Master Secret to conform to new MUST requirements in spec

Hi.  I'm looking into extended master secret (EMS) support in OpenSSL.  It works on my machine correctly, except for session resumption.  From the latest EMS spec:

"If a server receives a ClientHello for an abbreviated handshake
   offering to resume a previous session, it behaves as follows.
o  If the original session did not use an extended master secret but
      the new ClientHello does contain the "extended_master_secret"
      extension, the server MUST NOT perform the abbreviated handshake.
      Instead, it SHOULD continue with a full handshake to negotiate a
      new session."

The threat here is that in a Triple Handshake attack, the attacker A down-grades both initial connections to client C and server S to not support EMS.  In the second step, the session resumption step, he re-enables EMS on both connections, causing the handshake logs to agree, which allows the third connection (the renegotiation step) to complete with EMS enabled for any client accepting a server cert change.  At this point C accepts the connection to A as actually a connection to S, thwarting TLS authentication.

Emilia suggested that I develop a patch for this by forking master on github and submitting a pull request.  If I understand correctly, you guys prefer an email like this before starting work on patches.  Is that right?

There is also a bit of related behavior that I would also like to fix.  As described in the spec:

"If a client receives a ServerHello that accepts an abbreviated
   handshake, it behaves as follows.

   o  If the original session did not use an extended master secret but
      the new ServerHello does contain the "extended_master_secret"
      extension, the client MUST abort the handshake."

In this case, the client has detected a bug in the server's EMS implementation, and if the client continues, it is subject to the full TH downgrade attack as above.

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Dmitry Belyavsky | 20 Apr 12:16 2015

Error building openssl on SUSE

Hello openssl-dev,

I got a problem building openssl 1.0.2a on SUSE.

>uname -a

Linux b-sles11-64 #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux


> gcc -v      
Using built-in specs.
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)

Error message:

gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -m64 -DL_ENDIAN -O3 -Wall -D
M -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o ghash-x86_64.o ghash-x86_64.s
ghash-x86_64.s: Assembler messages:
ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq $17,%xmm2,%xmm0,%xmm1'
ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq $0,%xmm2,%xmm0,%xmm0'
ghash-x86_64.s:1283: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm3,%xmm3'
ghash-x86_64.s:1312: Error: no such instruction: `vpclmulqdq $17,%xmm2,%xmm0,%xmm1'
ghash-x86_64.s:1313: Error: no such instruction: `vpclmulqdq $0,%xmm2,%xmm0,%xmm0'
ghash-x86_64.s:1314: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm3,%xmm3'
ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm14,%xmm0'

Thank you!

SY, Dmitry Belyavsky
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Richard Moore | 19 Apr 22:57 2015

Missing API features

Hi All,

Continuing with the problems of making structs opaque, currently the API for querying the information about ciphers is quite weak. Only SSL_CIPHER_description provides access to data such as the key exchange method, and parsing a string to obtain this information seems daft. We're missing API for:
key exchange, authentication method, encryption algorithm, MAC and the export flag. It's also worth noting that SSL_CIPHER_get_version and SSL_CIPHER_description should probably be returning const char * not char *.



openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Hanno Boeck via RT | 18 Apr 18:05 2015

[openssl.org #3812] asn1parse -genconf may cause access to uninitialized variable

When calling asn1parse -genconf with a nonexistent file this will cause
an access to an uninitialized variable.

valgrind -q openssl asn1parse -genconf nonexistingfile

The reason is this code in asn1pars.c:

    if (errline > 0)
        BIO_printf(bio, "Error on line %ld of config file '%s'\n",
                   errline, genconf);
        BIO_printf(bio, "Error loading config file '%s'\n", genconf);

It assumes that if errline wasn't set it's zero. While on most systems
it's true that uninitialized variables are zero, this is not something
that should be relied upon.

Pre-initializing the variable with zero fixes this. See patch (for
current git code) and valgrind output attached. Please apply.

WARNING: can't open config file: /usr/local/ssl/openssl.cnf
==30382== Conditional jump or move depends on uninitialised value(s)
==30382==    at 0x4073C5: do_generate (asn1pars.c:439)
==30382==    by 0x4073C5: asn1parse_main (asn1pars.c:273)
==30382==    by 0x405320: do_cmd (openssl.c:470)
==30382==    by 0x404FEA: main (openssl.c:366)
==30382== Conditional jump or move depends on uninitialised value(s)
==30382==    at 0x528598: fmtint (b_print.c:479)
==30382==    by 0x52A157: _dopr (b_print.c:374)
==30382==    by 0x52A157: BIO_vprintf (b_print.c:774)
==30382==    by 0x52AE63: BIO_printf (b_print.c:754)
==30382==    by 0x4073DC: do_generate (asn1pars.c:440)
==30382==    by 0x4073DC: asn1parse_main (asn1pars.c:273)
==30382==    by 0x405320: do_cmd (openssl.c:470)
==30382==    by 0x404FEA: main (openssl.c:366)
==30382== Use of uninitialised value of size 8
==30382==    at 0x52860C: fmtint (b_print.c:496)
==30382==    by 0x52A157: _dopr (b_print.c:374)
==30382==    by 0x52A157: BIO_vprintf (b_print.c:774)
==30382==    by 0x52AE63: BIO_printf (b_print.c:754)
==30382==    by 0x4073DC: do_generate (asn1pars.c:440)
==30382==    by 0x4073DC: asn1parse_main (asn1pars.c:273)
==30382==    by 0x405320: do_cmd (openssl.c:470)
==30382==    by 0x404FEA: main (openssl.c:366)
==30382== Conditional jump or move depends on uninitialised value(s)
==30382==    at 0x528622: fmtint (b_print.c:499)
==30382==    by 0x52A157: _dopr (b_print.c:374)
==30382==    by 0x52A157: BIO_vprintf (b_print.c:774)
==30382==    by 0x52AE63: BIO_printf (b_print.c:754)
==30382==    by 0x4073DC: do_generate (asn1pars.c:440)
==30382==    by 0x4073DC: asn1parse_main (asn1pars.c:273)
==30382==    by 0x405320: do_cmd (openssl.c:470)
==30382==    by 0x404FEA: main (openssl.c:366)
Error on line 69349704 of config file 'nonexistentfile'
67417424:error:02001002:system library:fopen:No such file or directory:bss_file.c:168:fopen('nonexistentfile','rb')
67417424:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:171:
67417424:error:0E078072:configuration file routines:DEF_LOAD:no such file:conf_def.c:195:
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

[openssl.org #3811] [BUG REPORT] - Missing register name in aes-x86_64.s

The suggested fix for #3759: [PATCH] crypto: use bigint in x86-64 perl addresses some issues but not all
issues with the generation of the asm from the perl scripts.  Using the provided patch, one still fails with:

/usr/bin/perl asm/aes-x86_64.pl macosx > aes-x86_64.s
/opt/local/bin/gcc-apple-4.2 -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC
-DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c  -o aes-x86_64.o aes-x86_64.s
aes-x86_64.s:1383:missing or invalid immediate expression `' taken as 0
aes-x86_64.s:1383:suffix or operands invalid for `mov'
aes-x86_64.s:1544:missing or invalid immediate expression `' taken as 0
aes-x86_64.s:1544:suffix or operands invalid for `mov'

        movq    %r15,%rsi
        leaq    80(%rsp),%rdi
        leaq    80(%rsp),%r15
        movl    $,%ecx           # Line 1383
.long   0x90A548F3
        movl    %eax,(%rdi)


.p2align        2
        cmpl    $0,80+240(%rsp)
        leaq    80(%rsp),%rdi
        je      L$cbc_exit
        movl    $,%ecx           # Line 1544
        xorq    %rax,%rax
.long   0x90AB48F3

        jmp     L$cbc_exit

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Dominyk Tiller | 18 Apr 15:16 2015

OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report)

Apologies that this is kinda badly written. Detailed bug reports aren't
my forte. Feel free to ping back questions if detail isn't clear/useful/etc.

OS X 10.10.3’s release changed some certs in the Keychain. There’s a
full list of changes here:

This has caused some chaos with OpenSSL and LibreSSL, in things built
against them, using a .pem generated from OS X’s Keychains. The biggest,
most popular affected sites are the whole range of Google domains.

Google cross-sign their GeoTrust root with an old Equifax root (Equifax
Secure Certificate Authority) because a lot of the older clients don’t
have the GeoTrust root on their system and would just error out. Have
emailed with Adam Langley on the cert errors and essentially Google
aren’t going to be able to stop that cross-signing any time soon.

According to Adam most SSL clients should go through the cert chain of
the domain and hit the GeoTrust cert and verify at that point, if the
GeoTrust root exists in a .pem file OpenSSL can find and use, which does
exist when generating a PEM from the system Keychains. It’s not supposed
to carry on to the Equifax root, but it is, and this is causing breakage
on OS X 10.10.3 onwards.

This problem only exists in OpenSSL and LibreSSL as far as testing goes.
It isn’t reproducible with Apple’s Security Framework, or GnuTLS.

Interestingly, Apple have done something to their shipped OpenSSL 0.9.8x
to fix the problem - If I build OpenSSL 0.9.8x from source and use it,
failure, but if I use the one Apple installs the connection verifies and
succeeds. Here’s hoping they’ve punted whatever those changes were
upstream to you.

This is the error you get:

—2015-04-10 16:58:58—  https://google.com/
Resolving google.com…, 2a00:1450:4009:800::200e
Connecting to google.com||:443… connected.
ERROR: cannot verify google.com’s certificate, issued by ‘CN=Google
Internet Authority G2,O=Google Inc,C=US’:
  Unable to locally verify the issuer’s authority.
To connect to google.com insecurely, use `—no-check-certificate’.

How to reproduce:

* Install OpenSSL on OS X 10.10.3 or above. I have it installed to
/usr/local/opt/openssl - With the sysconfdir in /usr/local/etc.

* Generate a PEM file from OS X’s Security Keychain:
	* security find-certificate -a -p /Library/Keychains/System.keychain >>
	* security find-certificate -a -p
/System/Library/Keychains/SystemRootCertificates.keychain >> sysroot.pem
	* cat sys.pem >> sysroot.pem
	* mv sysroot.pem /usr/local/etc/openssl

* Download and install cURL:
	* Pass “—with-ssl=/path/to/openssl/dir” and
“--with-ca-bundle=/path/to/sysconfdir/openssl/sysroot.pem” to configure.

* Run “/path/to/your/installed/curl -I https://google.com”

It reproduces with wget, mutt, various other tools. If you put the
Equifax certificate back, and then rehash, you can make the connection.
But the Equifax cert is old, and weak, and Apple aren’t likely to return
it to the Keychain. So this problem connecting to Google will persist
until the reason for not stopping at and verifying on the GeoTrust root
are narrowed down and hopefully fixed.

Mozilla are also pressing ahead with removing that Equifax root from
their certs, so it’s not a simple case of working around it by switching


Sent from OS X. If you wish to communicate more securely my PGP Public
Key is 0x872524db9d74326c.

openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Gueron, Shay via RT | 17 Apr 22:09 2015

[openssl.org #3810] [PATCH] Improved P256 ECC performance by means of a dedicated function for modular inversion modulo the P256 group order

Hello all,

This patch is a contribution to OpenSSL.

It concerns the P256 ECC implementation.

The patch improves upon our previous submission, by providing a dedicated function to perform modular
inversion modulo the P256 group order.

The performance improvements, for single threaded applications, compared to the current (development)
version of OpenSSL are as follows.

(measured by "openssl speed" utility)

On Architecture Codename Haswell:
ECDSA sign: 1.28X
ECDSA verify: 1.10X

On Architecture  Broadwell:
ECDSA sign: 1.42X
ECDSA verify: 1.18X

We license the whole submission under BSD license.

Developers and authors:
Shay Gueron (1, 2), and Vlad Krasnov (3)
(1) University of Haifa, Israel
(2) Intel Corporation, Israel Development Center, Haifa, Israel
(3) CloudFlare, Inc.

Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Attachment (nistz256_inv_ord.patch): application/octet-stream, 50 KiB
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev