From rt at openssl.org  Sun Feb  1 11:50:28 2015
From: rt at openssl.org (Brian Carpenter via RT)
Date: Sun, 1 Feb 2015 12:50:28 +0100
Subject: [openssl-dev] [openssl.org #3683] checking malformed private key
	via command line segfaults openssl
In-Reply-To: <CANMVOuwpBNfAQLaUaiiEODHuzY1yH4BCNemoQ1we2My-Yk-pqQ@mail.gmail.com>
References: <RT-Ticket-3683@openssl.org>
 <CANMVOuwpBNfAQLaUaiiEODHuzY1yH4BCNemoQ1we2My-Yk-pqQ@mail.gmail.com>
Message-ID: <rt-4.0.4-1514-1422791428-549.3683-21-0@openssl.org>

Good evening. I'm reporting a segfault in openssl via the command line
"openssl rsa -in testcase -check" using a malformed private key. I'm using
american fuzzy lop (http://lcamtuf.coredump.cx/afl/) to fuzz openssl.

The testcase, which I've attached to this email, is a mutation of a valid
private ssl key. Doesn't appear to be exploitable according to CERTs
exploitable plugin (https://github.com/jfoote/exploitable) for GDB, but
there are smarter people than I out there in the world.

I compiled openssl with the afl-gcc included with american fuzzy lop for
instrumenting binaries:
CC=/path/to/afl-gcc ./config
AFL_HARDEN=1 make

Here is the output from GDB and Valgrind:

Program received signal SIGSEGV, Segmentation fault.
0x00000000009899ff in pkey_cb (pval=0x7fffffffd6f0, operation=<optimized
out>,
    it=<optimized out>, exarg=<optimized out>) at p8_pkey.c:72
72        if (key->pkey->value.octet_string)

(gdb) exploitable
Description: Access violation near NULL on source operand
Short description: SourceAvNearNull (16/22)
Hash: 589e66012e1218a63f994739c4ec4083.0007be4bb08747c7f86854a2a873ea7a
Exploitability Classification: PROBABLY_NOT_EXPLOITABLE
Explanation: The target crashed on an access violation at an address
matching the source operand of the current instruction. This likely
indicates a read access violation, which may mean the application crashed
on a simple NULL dereference to data structure that has no immediate effect
on control of the processor.
Other tags: AccessViolation (21/22)

(gdb) bt
#0  0x00000000009899ff in pkey_cb (pval=0x7fffffffd6f0,
    operation=<optimized out>, it=<optimized out>, exarg=<optimized out>)
    at p8_pkey.c:72
#1  pkey_cb (operation=2, pval=0x7fffffffd6f0, it=<optimized out>,
exarg=0x0)
    at p8_pkey.c:66
#2  0x0000000000951fa8 in asn1_item_combine_free (pval=0x7fffffffd6f0,
    it=0xd09e40, combine=0) at tasn_fre.c:149
#3  0x000000000095e64b in ASN1_item_ex_d2i (pval=pval at entry=0x7fffffffd6f0,
    in=<optimized out>, len=1196, it=0xd09e40, tag=<optimized out>,
    tag at entry=-1, aclass=<optimized out>, aclass at entry=0,
    opt=opt at entry=0 '\000', ctx=ctx at entry=0x7fffffffd700) at tasn_dec.c:484
#4  0x0000000000960bd9 in ASN1_item_d2i (pval=<optimized out>,
    in=<optimized out>, len=<optimized out>, it=<optimized out>)
    at tasn_dec.c:146
#5  0x00000000009a17b9 in PEM_read_bio_PrivateKey (bp=<optimized out>,
x=0x0,
    cb=0x4d0510 <password_callback>, u=0x7fffffffdbf0) at pem_pkey.c:94
#6  0x00000000004d7a6c in load_key (err=0xf88010,
    file=0x7fffffffe60e "./id:000016,sig:11,src:000000,op:havoc,rep:2",
    format=3, maybe_stdin=1, pass=<optimized out>, e=<optimized out>,
    key_descrip=0xcc01c6 "Private Key") at apps.c:989
#7  0x0000000000458af4 in rsa_main (argc=<optimized out>, argv=<optimized
out>)
    at rsa.c:291
#8  0x000000000040c3e8 in do_cmd (prog=prog at entry=0xfa47a0, argc=4,
    argv=argv at entry=0x7fffffffe370) at openssl.c:472
---Type <return> to continue, or q <return> to quit---
#9  0x000000000040b63c in main (Argc=<optimized out>, Argv=0x7fffffffe370)
    at openssl.c:366
#10 0x00007ffff786bead in __libc_start_main (main=<optimized out>,
    argc=<optimized out>, ubp_av=<optimized out>, init=<optimized out>,
    fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffe358)
    at libc-start.c:244
#11 0x000000000040bbd1 in _start ()

(gdb) i r
rax            0xfa5d20 16407840
rbx            0xd09e40 13672000
rcx            0x0 0
rdx            0x0 0
rsi            0x7fffffffd6f0 140737488344816
rdi            0x2 2
rbp            0x7fffffffd6f0 0x7fffffffd6f0
rsp            0x7fffffffd550 0x7fffffffd550
r8             0x4 4
r9             0x4 4
r10            0x0 0
r11            0x1 1
r12            0xd09e40 13672000
r13            0x7fffffffd6f0 140737488344816
r14            0xfa6136 16408886
r15            0x9898d0 10000592
rip            0x9899ff 0x9899ff <pkey_cb+247>
eflags         0x10246 [ PF ZF IF RF ]
cs             0x33 51
ss             0x2b 43
ds             0x0 0
es             0x0 0
fs             0x0 0
gs             0x0 0

Regards,

Brian 'geeknik' Carpenter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: opensslkeycrash.gz
Type: application/x-gzip
Size: 981 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150201/faf9ec26/attachment.bin>

From rt at openssl.org  Mon Feb  2 06:49:14 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Mon, 2 Feb 2015 07:49:14 +0100
Subject: [openssl-dev] [openssl.org #3684] Missing <stddef.h> for source
	files using offsetof
In-Reply-To: <CAH8yC8kg+NQT7sh5ouTf=1Qqaup1=PWkuYWRDFO1fWj5FEBPQg@mail.gmail.com>
References: <RT-Ticket-3684@openssl.org>
 <CAH8yC8kg+NQT7sh5ouTf=1Qqaup1=PWkuYWRDFO1fWj5FEBPQg@mail.gmail.com>
Message-ID: <rt-4.0.4-20680-1422859754-294.3684-21-0@openssl.org>

It appears a couple of source files are using the offsetof macro
defined in <staddef.h>. However, those files are *not* including
<stddef.h>, which is causing intermittent compile problems. For
example, http://stackoverflow.com/q/28246642/608639.

Please add "#include <stddef.h> to the following files:

    crypto/asn1/asn1t.h
    crypto/rand/rand_egd.c

**********

In addition, rand_egd.c should probably have its own definition of
offsetof removed since its not quite right (its not using GCC
__builtin_offsetof for GCC 3.5 and above).

If the project wants to include a definition (which appears to be
unneeded), then may be something like the following should be used:

#if defined(__GNUC__) && (__GNUC__ == 3 && __GNUC_MINOR__ >= 5 || __GNUC__ > 3)
#  ifndef __offsetof
#    define __offsetof(type, field) __builtin_offsetof(type, field)
#  endif
#  define offsetof(type, field) __builtin_offsetof(type, field)
#else /* ! (gcc >= 3.5) */
#  ifndef __offsetof
#    define __offsetof(type, field) ((size_t)(&((type *)0)->field))
#  endif
#  define offsetof(type, field) ((size_t)(&((type *)0)->field))
#endif



From de.techno at gmail.com  Mon Feb  2 14:48:03 2015
From: de.techno at gmail.com (dE)
Date: Mon, 02 Feb 2015 20:18:03 +0530
Subject: [openssl-dev] sftp buggy put command
In-Reply-To: <54CC9425.2090100@gmail.com>
References: <54CC8632.1010602@gmail.com> <54CC9425.2090100@gmail.com>
Message-ID: <54CF8E23.8050306@gmail.com>

On 01/31/15 14:06, Aaron Jones wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 31/01/15 07:37, dE wrote:
>> Hi!
>>
>> I was tying out the put command with version 6.7_p1 of OpenSSH.
>>
>> If I use recursive copying, sftp expects the last directory in the
>> <source> exists in the destination (on the server), otherwise
>> ?Couldn't canonicalize: No such file or directory?.
>>
>> I would've taken this to be the expected behavior, but get command
>> does not have this problem. It makes the destination directory in
>> the client like with cp.
>>
>> So kindly take a look at this.
> This is the OpenSSL development mailing list.
>
> OpenSSL and OpenSSH are unrelated.
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.15 (GNU/Linux)
>
> iQIcBAEBCAAGBQJUzJQXAAoJEG6FTA+q1M6k548P+wfb5N2im7E1hMwzT7FNxjIr
> brLmhqp7ImxvyIBkOyOUFA9ECTlRyNK9scVzR5pBq3Arwgc1lAe8krBqS6jkXZJG
> k6pTvHmxGqfYYHn+LiUvamS73YwaitdOltuCy83d1v/VSVMqCbSFij+nOcbhIA5M
> lG9PoG1ow0BXQep0i9O42ZG20oaPAqyt9NjC9MlN0BK4wyBCJF75T8eAHQl8WCBC
> RfFG8y9O5CAET7jP4AOavejIzCRMzm8apoMtoYZPnXjeBMHD0JJKSO1mEEL5JxLL
> tdKhT7VRev99rF+zCWUJysCJdNCh/OpqQv8qIJE1Vphx9hg/QWa8OaOHIZzTyAWC
> PuaFdh4FEnA7lF3a7XfbcoujcKW9XxSyxeKfZKWopGrps7fo2YAkT3VpkQPe4W66
> CrUF0HgPnMy7yiNXkg4jxRjiZulnLGovInlHEcWOmdAzkh9fQCv+dQJN8DTz74Gs
> YAndLV1vxzly/+P3RFb+g4xv2P7tDZCh8+IP29yEwdbxATP0q06LyAgT1VjAI/SG
> rbKco7NkMn35LjNgPuuAfnuJ/vyN3f+08yBbziu9Hdrhdxwlml3pGLeAFgamqDYR
> MLAs5S89akjhCJh11gpa2Q/tbswgr9iX7ERQhO889gzGhUFsvdsqlda835aozivw
> qt58eFvqWu+afVP9lca2
> =dBBe
> -----END PGP SIGNATURE-----
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

OH GOD DAMMED! THIS'S THE BIGGEST BLUNDER I'VE DONE IN RECENT DAYS!!

From rt at openssl.org  Mon Feb  2 23:47:40 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 3 Feb 2015 00:47:40 +0100
Subject: [openssl-dev] [openssl.org #1290] [PATCH] Convert destest.c to use
	DES_* functions.
In-Reply-To: <20060313202927.GA2912@roeckx.be>
References: <RT-Ticket-1290@openssl.org> <20060313202927.GA2912@roeckx.be>
Message-ID: <rt-4.0.4-28967-1422920860-994.1290-6-0@openssl.org>

commit 24956ca00f014a917fb181a8abc39b349f3f316f
Author: Rich Salz <rsalz at openssl.org>
Date: Mon Feb 2 18:46:01 2015 -0500

Remove old DES API

Includes VMS fixes from Richard.
Includes Kurt's destest fixes (RT 1290).
Closes tickets 1290 and 1291

Reviewed-by: Kurt Roeckx <kurt at openssl.org>
Reviewed-by: Richard Levitte <levitte at openssl.org>


From rt at openssl.org  Mon Feb  2 23:47:59 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 3 Feb 2015 00:47:59 +0100
Subject: [openssl-dev] [openssl.org #1291] [PATCH] Remove old libdes support?
In-Reply-To: <20060313211436.GA2965@roeckx.be>
References: <RT-Ticket-1291@openssl.org> <20060313211436.GA2965@roeckx.be>
Message-ID: <rt-4.0.4-26905-1422920879-83.1291-6-0@openssl.org>

commit 24956ca00f014a917fb181a8abc39b349f3f316f
Author: Rich Salz <rsalz at openssl.org>
Date: Mon Feb 2 18:46:01 2015 -0500

Remove old DES API

Includes VMS fixes from Richard.
Includes Kurt's destest fixes (RT 1290).
Closes tickets 1290 and 1291

Reviewed-by: Kurt Roeckx <kurt at openssl.org>
Reviewed-by: Richard Levitte <levitte at openssl.org>


From foleyj at cisco.com  Tue Feb  3 01:07:40 2015
From: foleyj at cisco.com (John Foley (foleyj))
Date: Tue, 3 Feb 2015 01:07:40 +0000
Subject: [openssl-dev] Fwd: Build failed in Jenkins: master_windows #32
In-Reply-To: <1686473218.0.1422922344837.JavaMail.jenkins@openssl-sanity.novalocal>
References: <1686473218.0.1422922344837.JavaMail.jenkins@openssl-sanity.novalocal>
Message-ID: <A9036501-274B-4518-90CE-CAB97A16EAA2@cisco.com>

It appears the Windows build is broken on master with the recent commit to the DES code.  Please see the error message at the bottom of this message...


Begin forwarded message:

From: <openssl.sanity at gmail.com<mailto:openssl.sanity at gmail.com>>
Date: February 2, 2015 at 7:12:24 PM EST
To: <foleyj at cisco.com<mailto:foleyj at cisco.com>>
Subject: Build failed in Jenkins: master_windows #32
Reply-To: <openssl.sanity at gmail.com<mailto:openssl.sanity at gmail.com>>

See <http://173.39.238.160:8080/job/master_windows/32/changes>

Changes:

[rsalz] Remove old DES API

------------------------------------------
Started by upstream project "master_basic" build number 100
originally caused by:
Started by an SCM change
Building remotely on windows-slave in workspace <http://173.39.238.160:8080/job/master_windows/ws/>
git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
git config remote.origin.url https://github.com/openssl/openssl.git # timeout=10
Cleaning workspace
git rev-parse --verify HEAD # timeout=10
Resetting working tree
git reset --hard # timeout=10
git clean -fdx # timeout=10
Fetching upstream changes from https://github.com/openssl/openssl.git
git --version # timeout=10
git -c core.askpass=true fetch --tags --progress https://github.com/openssl/openssl.git +refs/heads/*:refs/remotes/origin/*
git rev-parse "refs/remotes/origin/master^{commit}" # timeout=10
git rev-parse "refs/remotes/origin/origin/master^{commit}" # timeout=10
Checking out Revision 24956ca00f014a917fb181a8abc39b349f3f316f (refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f 24956ca00f014a917fb181a8abc39b349f3f316f
git rev-list fd22ab9edf497ad7d98897377ee798953845d022 # timeout=10
[master_windows] $ cmd /c call C:\Users\ADMINI~1\AppData\Local\Temp\1\hudson5369467623327537492.bat

<http://173.39.238.160:8080/job/master_windows/ws/>call> "c:\program files (x86)\microsoft visual studio 12.0\vc\bin\vcvars32.bat"

<http://173.39.238.160:8080/job/master_windows/ws/>set> PROCESSOR_ARCHITECTURE=x86

<http://173.39.238.160:8080/job/master_windows/ws/>perl> Configure VC-WIN32
Configuring for VC-WIN32
   no-deprecated   [default]  OPENSSL_NO_DEPRECATED (skip dir)
   no-ec_nistp_64_gcc_128 [default]  OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir)
   no-gmp          [default]  OPENSSL_NO_GMP (skip dir)
   no-jpake        [experimental] OPENSSL_NO_JPAKE (skip dir)
   no-krb5         [krb5-flavor not specified] OPENSSL_NO_KRB5
   no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
   no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
   no-rfc3779      [default]  OPENSSL_NO_RFC3779 (skip dir)
   no-sctp         [default]  OPENSSL_NO_SCTP (skip dir)
   no-shared       [default]
   no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE (skip dir)
   no-store        [experimental] OPENSSL_NO_STORE (skip dir)
   no-unit-test    [default]  OPENSSL_NO_UNIT_TEST (skip dir)
   no-zlib         [default]
   no-zlib-dynamic [default]
IsMK1MF=1
CC            =cl
CFLAG         =-DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
EX_LIBS       =
CPUID_OBJ     =x86cpuid.o
BN_ASM        =bn-586.o co-586.o x86-mont.o x86-gf2m.o
EC_ASM        =
DES_ENC       =des-586.o crypt586.o
AES_ENC       =aes-586.o vpaes-x86.o aesni-x86.o
BF_ENC        =bf-586.o
CAST_ENC      =cast-586.o
RC4_ENC       =rc4-586.o
RC5_ENC       =rc5-586.o
MD5_OBJ_ASM   =md5-586.o
SHA1_OBJ_ASM  =sha1-586.o sha256-586.o sha512-586.o
RMD160_OBJ_ASM=rmd-586.o
CMLL_ENC      =cmll-x86.o
MODES_OBJ     =ghash-x86.o
ENGINES_OBJ   =e_padlock-x86.o
PROCESSOR     =
RANLIB        =true
ARFLAGS       =
PERL          =perl
THIRTY_TWO_BIT mode
BN_LLONG mode
RC4_INDEX mode
RC4_CHUNK is undefined

Configured for VC-WIN32.

<http://173.39.238.160:8080/job/master_windows/ws/>ms\do_nasm.bat>

<http://173.39.238.160:8080/job/master_windows/ws/>perl> util\mkfiles.pl  1>MINFO

<http://173.39.238.160:8080/job/master_windows/ws/>perl> util\mk1mf.pl nasm VC-WIN32  1>ms\nt.mak

<http://173.39.238.160:8080/job/master_windows/ws/>perl> util\mk1mf.pl dll nasm VC-WIN32  1>ms\ntdll.mak

<http://173.39.238.160:8080/job/master_windows/ws/>perl> util\mk1mf.pl nasm BC-NT  1>ms\bcb.mak

<http://173.39.238.160:8080/job/master_windows/ws/>perl> util\mkdef.pl 32 libeay  1>ms\libeay32.def
unable to open crypto/des/des_old.h:No such file or directory

<http://173.39.238.160:8080/job/master_windows/ws/>perl> util\mkdef.pl 32 ssleay  1>ms\ssleay32.def
unable to open crypto/des/des_old.h:No such file or directory
Build step 'Execute Windows batch command' marked build as failure
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150203/bba55cec/attachment.html>

From rsalz at akamai.com  Tue Feb  3 03:21:10 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Feb 2015 03:21:10 +0000
Subject: [openssl-dev] Build failed in Jenkins: master_windows #32
In-Reply-To: <A9036501-274B-4518-90CE-CAB97A16EAA2@cisco.com>
References: <1686473218.0.1422922344837.JavaMail.jenkins@openssl-sanity.novalocal>
 <A9036501-274B-4518-90CE-CAB97A16EAA2@cisco.com>
Message-ID: <f0b57dc4e5df4319bcf714475af0784b@usma1ex-dag1mb2.msg.corp.akamai.com>

Does this patch fix it?

diff --git a/util/mkdef.pl b/util/mkdef.pl
index 03fbf20..be7dd42 100755
--- a/util/mkdef.pl
+++ b/util/mkdef.pl
@@ -281,7 +281,7 @@ my $crypto ="crypto/crypto.h";
 $crypto.=" crypto/cryptlib.h";
 $crypto.=" crypto/o_dir.h";
 $crypto.=" crypto/o_str.h";
-$crypto.=" crypto/des/des.h crypto/des/des_old.h" ; # unless $no_des;
+$crypto.=" crypto/des/des.h" ; # unless $no_des;
 $crypto.=" crypto/idea/idea.h" ; # unless $no_idea;
 $crypto.=" crypto/rc4/rc4.h" ; # unless $no_rc4;
 $crypto.=" crypto/rc5/rc5.h" ; # unless $no_rc5;



From rsalz at akamai.com  Tue Feb  3 03:27:08 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 3 Feb 2015 03:27:08 +0000
Subject: [openssl-dev] Build failed in Jenkins: master_windows #32
In-Reply-To: <f0b57dc4e5df4319bcf714475af0784b@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <1686473218.0.1422922344837.JavaMail.jenkins@openssl-sanity.novalocal>
 <A9036501-274B-4518-90CE-CAB97A16EAA2@cisco.com>
 <f0b57dc4e5df4319bcf714475af0784b@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <64d754712bd14a74aabaa62d5905278f@usma1ex-dag1mb2.msg.corp.akamai.com>

Yuk.  Perhaps if you could read it :)

Edit util/mkdef.pl and remove "des_old.h from like 283 or so.



From kurt at x64architecture.com  Tue Feb  3 03:34:24 2015
From: kurt at x64architecture.com (Kurt Cancemi)
Date: Mon, 2 Feb 2015 22:34:24 -0500
Subject: [openssl-dev] Build failed in Jenkins: master_windows #32
In-Reply-To: <64d754712bd14a74aabaa62d5905278f@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <1686473218.0.1422922344837.JavaMail.jenkins@openssl-sanity.novalocal>
 <A9036501-274B-4518-90CE-CAB97A16EAA2@cisco.com>
 <f0b57dc4e5df4319bcf714475af0784b@usma1ex-dag1mb2.msg.corp.akamai.com>
 <64d754712bd14a74aabaa62d5905278f@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CADujJWW4F8YKTaQLVzoMokrA+0TwuueEo5Ou-PssSv9Z_wmcFQ@mail.gmail.com>

I can confirm the patch works.

Though it throws some unrelated warnings:


*WARNING: mkdef.pl <http://mkdef.pl> doesn't know the following
algorithms:        RMD160        APPLINK*

---
Kurt Cancemi
https://www.x64architecture.com

On Mon, Feb 2, 2015 at 10:27 PM, Salz, Rich <rsalz at akamai.com> wrote:

> Yuk.  Perhaps if you could read it :)
>
> Edit util/mkdef.pl and remove "des_old.h from like 283 or so.
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150202/9d98b741/attachment-0001.html>

From leith at mapbox.com  Tue Feb  3 10:59:36 2015
From: leith at mapbox.com (Leith Bade)
Date: Tue, 3 Feb 2015 21:59:36 +1100
Subject: [openssl-dev] Android 64-bit configure targets
Message-ID: <CAKPVpuhCOA-w9KwHC2TKs_OBwBS-r-zp3BTcxs6JrzRwvSFQKw@mail.gmail.com>

Hi,

I am currently building OpenSSL for Android with current NDK r10d.

I notice the configure script only has targets for the 32bit Android ABIs.

Are there plans to add the 64bit ABIs (arm64, x86-64 and mips64)?

I am currently using the generic Android target which works OK for
arm64 and mips64, but not for x86-64.

Thanks,
Leith Bade
leith at mapbox.com

From foleyj at cisco.com  Tue Feb  3 13:40:35 2015
From: foleyj at cisco.com (John Foley)
Date: Tue, 03 Feb 2015 08:40:35 -0500
Subject: [openssl-dev] Build failed in Jenkins: master_windows #32
In-Reply-To: <CADujJWW4F8YKTaQLVzoMokrA+0TwuueEo5Ou-PssSv9Z_wmcFQ@mail.gmail.com>
References: <1686473218.0.1422922344837.JavaMail.jenkins@openssl-sanity.novalocal>
 <A9036501-274B-4518-90CE-CAB97A16EAA2@cisco.com>
 <f0b57dc4e5df4319bcf714475af0784b@usma1ex-dag1mb2.msg.corp.akamai.com>
 <64d754712bd14a74aabaa62d5905278f@usma1ex-dag1mb2.msg.corp.akamai.com>
 <CADujJWW4F8YKTaQLVzoMokrA+0TwuueEo5Ou-PssSv9Z_wmcFQ@mail.gmail.com>
Message-ID: <54D0CFD3.7050405@cisco.com>

It looks like libeay.num and ssleay.num need updated too...

c:\nightly\workspace\master_windows>perl util\mkdef.pl 32 libeay  1>ms\libeay32.def 
WARNING: mkdef.pl doesn't know the following algorithms:
	APPLINK
	RMD160
Warning: RSA_padding_chk_PKCS1_OAEP_mgf1 does not have a number assigned
Warning: int does not have a number assigned
Warning: long does not have a number assigned
Warning: void does not have a number assigned

c:\nightly\workspace\master_windows>perl util\mkdef.pl 32 ssleay  1>ms\ssleay32.def 
WARNING: mkdef.pl doesn't know the following algorithms:
	RMD160
	APPLINK
Warning: SSL_COMP_free_compr_methods does not have a number assigned
Warning: SSL_COMP_set0_compr_methods does not have a number assigned




On 02/02/2015 10:34 PM, Kurt Cancemi wrote:
> I can confirm the patch works.
>
> Though it throws some unrelated warnings:
> /WARNING: mkdef.pl <http://mkdef.pl> doesn't know the following
> algorithms:
>         RMD160
>         APPLINK/
>
> ---
> Kurt Cancemi
> https://www.x64architecture.com
>
> On Mon, Feb 2, 2015 at 10:27 PM, Salz, Rich <rsalz at akamai.com
> <mailto:rsalz at akamai.com>> wrote:
>
>     Yuk.  Perhaps if you could read it :)
>
>     Edit util/mkdef.pl <http://mkdef.pl> and remove "des_old.h from
>     like 283 or so.
>
>
>     _______________________________________________
>     openssl-dev mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150203/a1e5c3db/attachment.html>

From rt at openssl.org  Tue Feb  3 14:05:15 2015
From: rt at openssl.org (Stephen Henson via RT)
Date: Tue, 3 Feb 2015 15:05:15 +0100
Subject: [openssl-dev] [openssl.org #3683] checking malformed private key
	via command line segfaults openssl
In-Reply-To: <CANMVOuwpBNfAQLaUaiiEODHuzY1yH4BCNemoQ1we2My-Yk-pqQ@mail.gmail.com>
References: <RT-Ticket-3683@openssl.org>
 <CANMVOuwpBNfAQLaUaiiEODHuzY1yH4BCNemoQ1we2My-Yk-pqQ@mail.gmail.com>
Message-ID: <rt-4.0.4-13141-1422972315-719.3683-6-0@openssl.org>

Now fixed. Thanks for the report.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


From rt at openssl.org  Tue Feb  3 14:13:16 2015
From: rt at openssl.org (Nathan Royce via RT)
Date: Tue, 3 Feb 2015 15:13:16 +0100
Subject: [openssl-dev] [openssl.org #3686] doc/openssl-shared.txt - "No such
	file"
In-Reply-To: <COL126-W33CBCE799149CEB1483CD2A23D0@phx.gbl>
References: <RT-Ticket-3686@openssl.org>
 <COL126-W33CBCE799149CEB1483CD2A23D0@phx.gbl>
Message-ID: <rt-4.0.4-13141-1422972796-184.3686-21-0@openssl.org>

bug reportcommit c303d4d8686b9b46b5d85acdd94ec896433b813fDate:   Mon Feb 2 22:40:36 2015 -0500
*****make[1]: Leaving directory '/home/user/Desktop/openssl/tools'installing libcrypto.ainstalling libssl.ainstalling libcrypto.so.1.1.0installing libssl.so.1.1.0make[1]: Entering directory '/home/user/Desktop/CLFS/cross-tools/lib'make[2]: Entering directory '/home/user/Desktop/CLFS/cross-tools/lib'make[2]: Leaving directory '/home/user/Desktop/CLFS/cross-tools/lib'make[2]: Entering directory '/home/user/Desktop/CLFS/cross-tools/lib'make[2]: Leaving directory '/home/user/Desktop/CLFS/cross-tools/lib'make[1]: Leaving directory '/home/user/Desktop/CLFS/cross-tools/lib'OpenSSL shared libraries have been installed in:  /cross-tools
sed: can't read doc/openssl-shared.txt: No such file or directoryMakefile:635: recipe for target 'install_sw' failedmake: *** [install_sw] Error 2***** 		 	   		  

From rt at openssl.org  Tue Feb  3 14:13:43 2015
From: rt at openssl.org (Ulrich Windl via RT)
Date: Tue, 3 Feb 2015 15:13:43 +0100
Subject: [openssl-dev] [openssl.org #3687] openssl-0.9.8j: attribute
	"signingTime": unable to print attribute
In-Reply-To: <54D0C731020000A100019024@gwsmtp1.uni-regensburg.de>
References: <RT-Ticket-3687@openssl.org>
 <54D0C731020000A100019024@gwsmtp1.uni-regensburg.de>
Message-ID: <rt-4.0.4-13141-1422972823-1652.3687-21-0@openssl.org>

Hello!

I found this problem in SUSE's SLES 11 SP3 with openssl-0.9.8j-0.68.1 and a certificate sign request created by Symantecs PGP Desktop 10.2.1:
It seems the CSR contains an attribute signing time that openssl does not understand:

        Attributes:
            signingTime              :unable to print attribute
        Requested Extensions:
            1.3.6.1.4.1.3401.8.1.1:
150203113156Z   .

I guess the above means 2015-02-03_11:31:56 UTC.  Would be nice if openssl could know about that. Here's the (dummy) CSR for reference:
-----BEGIN CERTIFICATE REQUEST-----
MIIC5zCCAc8CAQAwMTERMA8GA1UEAxMId2l1MDk1MjQxHDAaBgkqhkiG9w0BCQEM
DXRlc3RAdXNlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCy
eE6RjgCGPDizXQ1+UoPF7QnB7TVxpLq3bfRA0pUC0CDNL35XCm2bhl8CLpqwjde0
jeGfC2IYpgbjBRaupPC4eJAuMbToiD0c3zLfyljZX5c6CsMPCYnj0z9xubAczuGO
WaNHnl9zZOdND1lWxgUYCcz3HXmDKp32D6CUn5O5LmGXTBE8r/7mbUzYhnrkC67T
V7yTWUtHd+bZtuJNaPxwC23SwLdn94xKkzlacRIG8PfqX1ACbjES1tRXUob7RWdV
5XQmn9jPU5vEgX0WmVEUonf2aTwErdZaco2Lra0Csax/kioPx62t3UEN7m7yrfpy
/YxMNMnwXoH6YuHCu+gjAgMBAAGgcTAcBgkqhkiG9w0BCQUxDxcNMTUwMjAzMTEz
NDE5WjBRBgkqhkiG9w0BCQ4xRDBCMB0GCisGAQQBmkkIAQEEDxcNMTUwMjAzMTEz
MTU2WjAOBgNVHQ8BAf8EBAMCAMEwEQYDVR0OBAoECMN57CKCkiq1MA0GCSqGSIb3
DQEBBQUAA4IBAQBcw5vxG0ceVHAbudRvgcbSdKHwBEbG0jrrhvDiPw4cV9oL2SEU
RoYdNbmEy8gUvpotDKLEsPYMn5Y0B/5AHtKA+S70EGVqyHtpH2yBpG98wcmttxGt
xBj9bBCwnB9JI4hBX6dS3ns+tAatMbXo6VFd7EoMFyXp+EtHfgvfz6gQf51QLj4R
aICldknfriipiNuaxHtmrFjgtVs6tFDYa3RgcaDtf53E/yfKr3BPtkTFcYmoMFSn
LRgIFiU6vKu9TJD9IFxdqeVe5mmoH/nASPtvJgXixG03WwVosTcQU430d5XDOs9D
a9duSvYcRxB0OmWc8aPz1aUbCSPZ91AMibtD
-----END CERTIFICATE REQUEST-----

Regards,
Ulrich




From notdatoneguy at gmail.com  Tue Feb  3 21:00:10 2015
From: notdatoneguy at gmail.com (Colin Lacina)
Date: Tue, 3 Feb 2015 15:00:10 -0600
Subject: [openssl-dev] Adding a message digest algorithm.
Message-ID: <CAJJsNHsBUtZCXgrG5BCrRa4vkxYKM57ytRtHwMMNhDS53jmm_A@mail.gmail.com>

Hey, I would like to add a particular message digest algorithm to OpenSSL
but I am not sure what files I need to change to do this. I obviously want
to add a folder under /openssl/crypto but I am not sure what to do besides
that. I also have come code optimized for SIMD for the algo and I am not
sure how to include that.

Thank you all!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150203/69cbb9c5/attachment.html>

From rsalz at openssl.org  Tue Feb  3 22:02:31 2015
From: rsalz at openssl.org (Rich Salz)
Date: Tue, 3 Feb 2015 17:02:31 -0500
Subject: [openssl-dev] The evolution of the 'master' branch
Message-ID: <20150203220231.GA12587@openssl.org>

As we've already said, we are moving to making most OpenSSL data
structures opaque. We deliberately used a non-specific term. :)
As of Matt's commit of the other day, this is starting to happen
now.  We know this will inconvenience people as some applications
no longer build.  We want to work with maintainers to help them
migrate, as we head down this path.

We have a wiki page to discuss this effort.  It will eventually include
tips on migration, application and code updates, and anything else the
community finds useful.  Please visit:

	http://wiki.openssl.org/index.php/1.1_API_Changes

Thanks.

From timo.teras at iki.fi  Wed Feb  4 06:51:20 2015
From: timo.teras at iki.fi (Timo Teras)
Date: Wed, 4 Feb 2015 08:51:20 +0200
Subject: [openssl-dev] The evolution of the 'master' branch
In-Reply-To: <20150203220231.GA12587@openssl.org>
References: <20150203220231.GA12587@openssl.org>
Message-ID: <20150204085120.61c8883e@vostro>

On Tue, 3 Feb 2015 17:02:31 -0500
Rich Salz <rsalz at openssl.org> wrote:

> As we've already said, we are moving to making most OpenSSL data
> structures opaque. We deliberately used a non-specific term. :)
> As of Matt's commit of the other day, this is starting to happen
> now.  We know this will inconvenience people as some applications
> no longer build.  We want to work with maintainers to help them
> migrate, as we head down this path.
> 
> We have a wiki page to discuss this effort.  It will eventually
> include tips on migration, application and code updates, and anything
> else the community finds useful.  Please visit:
> 
> 	http://wiki.openssl.org/index.php/1.1_API_Changes

Not sure if my questions are already answered. But I'll go ahead and
ask them...

Which structures this includes? I'm thinking application level
extensibility.

If I have a custom cipher implementation, and it requires shipping
EVP_CIPHER (which is basically virtual ops table). Is that planned to
be opaque too? Or it gets a set of accessors?

How would off-tree engine modules be implemented? Or is their
integration possibilities limited?

Or would there be the "public headers" for applications? And than the
"private headers" for version bound extensions that need to access the
internals?

Thanks,
Timo

From matt at openssl.org  Wed Feb  4 09:19:34 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 04 Feb 2015 09:19:34 +0000
Subject: [openssl-dev] The evolution of the 'master' branch
In-Reply-To: <20150204085120.61c8883e@vostro>
References: <20150203220231.GA12587@openssl.org>
 <20150204085120.61c8883e@vostro>
Message-ID: <54D1E426.7070401@openssl.org>



On 04/02/15 06:51, Timo Teras wrote:
> On Tue, 3 Feb 2015 17:02:31 -0500
> Rich Salz <rsalz at openssl.org> wrote:
> 
>> As we've already said, we are moving to making most OpenSSL data
>> structures opaque. We deliberately used a non-specific term. :)
>> As of Matt's commit of the other day, this is starting to happen
>> now.  We know this will inconvenience people as some applications
>> no longer build.  We want to work with maintainers to help them
>> migrate, as we head down this path.
>>
>> We have a wiki page to discuss this effort.  It will eventually
>> include tips on migration, application and code updates, and anything
>> else the community finds useful.  Please visit:
>>
>> 	http://wiki.openssl.org/index.php/1.1_API_Changes
> 
> Not sure if my questions are already answered. But I'll go ahead and
> ask them...
> 
> Which structures this includes? I'm thinking application level
> extensibility.

At the moment in master this includes all libssl structures, and bn
structures in libcrypto. My expectation is that this will be extended to
"most" structures in libcrypto too.

> 
> If I have a custom cipher implementation, and it requires shipping
> EVP_CIPHER (which is basically virtual ops table). Is that planned to
> be opaque too? Or it gets a set of accessors?
> 
> How would off-tree engine modules be implemented? Or is their
> integration possibilities limited?
> 
> Or would there be the "public headers" for applications? And than the
> "private headers" for version bound extensions that need to access the
> internals?

The general approach is to make structures opaque and provide accessors
where they don't already exist. For the examples you have cited,
unfortunately, that comes under the category of TBD. We haven't yet
decided how that will be done - so I'm happy to hear any opinions on how
it should be tackled.

Matt


From aixtools at gmail.com  Wed Feb  4 09:50:52 2015
From: aixtools at gmail.com (aixtools)
Date: Wed, 04 Feb 2015 10:50:52 +0100
Subject: [openssl-dev] Creating libssl.so and libcrypto.so for AIX
Message-ID: <54D1EB7C.8050007@gmail.com>

Hi,

To be compatible with the way IBM distributes openssl in 
/usr/lib/libssl.a and /usr/lib/libcrypto.a I would like to make the .so 
"archives" as well.

Actually, these are archives in the 'ar' command sense, but become 
members of the archive.

I have been trying to understand how Makefile.shared works, and under 
the target
syslink.aix I have not been able to establish what

SYMLINK_SOD=    \
         if [ -n "$$INHIBIT_SYMLINKS" ]; then (print true) ; else \
                 print $$SHLIB - $$SHLIB_SOVER - $$SHLIB_SUFFIX; \
                 print   " - " "$$SHLIB_COMPAT"; \
         (print false); fi;

SYMLINK_SO=     \
         if [ -n "$$INHIBIT_SYMLINKS" ]; then :; else \
                 prev=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \
                 if [ -n "$$SHLIB_COMPAT" ]; then \
                         for x in $$SHLIB_COMPAT; do \
                                 ( $(SET_X); rm -f 
$$SHLIB$$x$$SHLIB_SUFFIX; \
                                   ln -s $$prev $$SHLIB$$x$$SHLIB_SUFFIX 
); \
                                 prev=$$SHLIB$$x$$SHLIB_SUFFIX; \
                         done; \
                 fi; \
                 if [ -n "$$SHLIB_SOVER" ]; then \
                         ( $(SET_X); rm -f $$SHLIB$$SHLIB_SUFFIX; \
                           ln -s $$prev $$SHLIB$$SHLIB_SUFFIX ); \
                 fi; \
         fi

# Targets to build symbolic links when needed
symlink.gnu symlink.solaris symlink.svr3 symlink.svr5 symlink.irix \
symlink.aix symlink.reliantunix:
         $(CALC_VERSIONS); \
         SHLIB=lib$(LIBNAME).so; \
         $(SYMLINK_SOD)
         $(SYMLINK_SO)

# (the SYMLINK_SOD is my way to print the variables used by SYSLINK_SO)

Make with debug info

michael at x071:[/data/prj/openssl/openssl-1.0.2]make --debug=bj link-shared
GNU Make 3.82
Built for powerpc-ibm-aix5.3.0.0
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating goal targets....
  File `link-shared' does not exist.
Must remake target `link-shared'.
Invoking recipe from Makefile:338 to update target `link-shared'.
GNU Make 3.82
Built for powerpc-ibm-aix5.3.0.0
Copyright (C) 2010  Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating goal targets....
  File `symlink.aix-shared' does not exist.
    File `symlink.aix' does not exist.
   Must remake target `symlink.aix'.
Invoking recipe from Makefile.shared:588 to update target `symlink.aix'.
make[1]: Entering directory `/data/prj/openssl/openssl-1.0.2'
SHLIB_COMPAT=; SHLIB_SOVER=; if [ -n "1.0.0;" ]; then prev=""; for v in 
`echo "1.0.0 ;" | cut -d';' -f1`; do SHLIB_SOVER_NODOT=$v; 
SHLIB_SOVER=.$v; if [ -n "$prev" ]; then SHLIB_COMPAT="$SHLIB_COMPAT 
.$prev"; fi; prev=$v; done; fi; \
SHLIB=libcrypto.so; \
if [ -n "$INHIBIT_SYMLINKS" ]; then (print true) ; else print $SHLIB - 
$SHLIB_SOVER - $SHLIB_SUFFIX; print   " - " "$SHLIB_COMPAT"; (print 
false); fi;
libcrypto.so - .1.0.0 -
  -
false

Any help with understanding how to create a libcrypto.so and libssl.so 
(similiar to what libz does! is appreciated)

Info: libz does this

xlc -G -O -qmaxmem=8192 -D_LARGEFILE64_SOURCE=1 -o libz.so.1.2.8 
adler32.lo crc32.lo deflate.lo infback.lo inffast.lo inflate.lo 
inftrees.lo trees.lo zutil.lo compress.lo uncompr.lo gzclose.lo gzlib.lo 
gzread.lo gzwrite.lo  -lc

I am puzzled that it is not made because openssl Makefile knows about 
the -G argument, but does not apply it to create a 'member' with the 
combined .o files.

I am hoping that someone is willing to think about an elegant solution - 
compared to any (unstable) hack I might come up with.

I have tried, with no success, to just make libssl.so, libssl.so.1.0.2

However, when I tried to make libssl.so.1.0.0 I did get a lot of 
'activity' (called AIX cc/xlc with no arguments and I get the man page 
... this prefixes it

michael at x071:[/data/prj/openssl/openssl-1.0.2]make libssl.so.1.0.0
[ -z "" ] || cc -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN 
-DHAVE_DLFCN_H -q64 -O2 -DB_ENDIAN -qmaxmem=16384 -qro -qroconst 
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM 
-DVPAES_ASM -Iinclude \
         -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso  \
         fips_premain.c fipscanister.o \
         libcrypto.a
make[1]: Entering directory `/data/prj/openssl/openssl-1.0.2'
make[2]: Entering directory `/data/prj/openssl/openssl-1.0.2'
SHLIB_COMPAT=; SHLIB_SOVER=; if [ -n "1.0.0;" ]; then prev=""; for v in 
`echo "1.0.0 ;" | cut -d';' -f1`; do SHLIB_SOVER_NODOT=$v; 
SHLIB_SOVER=.$v; if [ -n "$prev" ]; then SHLIB_COMPAT="$SHLIB_COMPAT 
.$prev"; fi; prev=$v; done; fi; \
OBJECT_MODE=`expr "x-q64 -G" : 'x\-[a-z]*\(64\)'` || : ; \
OBJECT_MODE=${OBJECT_MODE:-32}; export OBJECT_MODE; \
SHLIB=libcrypto.so; \
SHLIB_SUFFIX=; \
ALLSYMSFLAGS='-bnogc'; \
NOALLSYMSFLAGS=''; \
SHAREDFLAGS='-DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN 
-DHAVE_DLFCN_H -q64 -O2 -DB_ENDIAN -qmaxmem=16384 -qro -qroconst 
-DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM 
-DVPAES_ASM -q64 -G -Wl,-bexpall,-bnolibpath,-bM:SRE'; \
echo SHOBJECTS=libcrypto.o; ALL=$ALLSYMSFLAGS; ALLSYMSFLAGS=; 
NOALLSYMSFLAGS=; ( :; ld  -r -o libcrypto.o $ALL libcrypto.a  ); ( :; 
LIBDEPS="${LIBDEPS:--L.  }"; SHAREDCMD="${SHAREDCMD:-cc}"; 
SHAREDFLAGS="${SHAREDFLAGS:--DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE 
-DDSO_DLFCN -DHAVE_DLFCN_H -q64 -O2 -DB_ENDIAN -qmaxmem=16384 -qro 
-qroconst -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DAES_ASM -DVPAES_ASM -q64 -G}"; LIBPATH=`for x in $LIBDEPS; do echo $x; 
done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed 
-e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${SHAREDCMD} 
${SHAREDFLAGS} -o $SHLIB$SHLIB_SOVER$SHLIB_SUFFIX $ALLSYMSFLAGS 
$SHOBJECTS $NOALLSYMSFLAGS $LIBDEPS ) && if [ -n "$INHIBIT_SYMLINKS" ]; 
then :; else prev=$SHLIB$SHLIB_SOVER$SHLIB_SUFFIX; if [ -n 
"$SHLIB_COMPAT" ]; then for x in $SHLIB_COMPAT; do ( :; rm -f 
$SHLIB$x$SHLIB_SUFFIX; ln -s $prev $SHLIB$x$SHLIB_SUFFIX ); 
prev=$SHLIB$x$SHLIB_SUFFIX; done; fi; if [ -n "$SHLIB_SOVER" ]; then ( 
:; rm -f $SHLIB$SHLIB_SUFFIX; ln -s $prev $SHLIB$SHLIB_SUFFIX ); fi; fi 
&& rm -f libcrypto.o
SHOBJECTS=libcrypto.o



   xlc(1)                     IBM (2010)                      xlc(1)
...

Signed (Sincerely Lost :p),
Michael


From appro at openssl.org  Wed Feb  4 11:08:43 2015
From: appro at openssl.org (Andy Polyakov)
Date: Wed, 04 Feb 2015 12:08:43 +0100
Subject: [openssl-dev] Android 64-bit configure targets
In-Reply-To: <CAKPVpuhCOA-w9KwHC2TKs_OBwBS-r-zp3BTcxs6JrzRwvSFQKw@mail.gmail.com>
References: <CAKPVpuhCOA-w9KwHC2TKs_OBwBS-r-zp3BTcxs6JrzRwvSFQKw@mail.gmail.com>
Message-ID: <54D1FDBB.1000107@openssl.org>

Hi,

> I am currently building OpenSSL for Android with current NDK r10d.
> 
> I notice the configure script only has targets for the 32bit Android ABIs.
> 
> Are there plans to add the 64bit ABIs (arm64, x86-64 and mips64)?

Yes. Currently plan is to have generic android64 and then specific for
aarch64 and x86_64. I wish there was virtual machine image for x86_64...

> I am currently using the generic Android target which works OK for
> arm64 and mips64, but not for x86-64.

I wonder what does it mean. I mean I'd like to hear more in order to
avoid possible pitfalls upon introduction.



From rsalz at akamai.com  Wed Feb  4 14:28:24 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 4 Feb 2015 14:28:24 +0000
Subject: [openssl-dev] The evolution of the 'master' branch
In-Reply-To: <20150204085120.61c8883e@vostro>
References: <20150203220231.GA12587@openssl.org>
 <20150204085120.61c8883e@vostro>
Message-ID: <18dd2570501c433491fc3a1bc7ee0263@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Not sure if my questions are already answered. But I'll go ahead and ask
> them...

All excellent questions.  As Matt said, we don't know yet. 

> Or would there be the "public headers" for applications? And than the
> "private headers" for version bound extensions that need to access the
> internals?

Yes, a service-provider interface is common.  I would be surprised if we get something that covers all desired extensibility points in the first release. I would think ENGINE is the most likely first one.  Yes, this means that adding new algorithms, etc., might become harder or even not possible without source code, at first. But that is just my opinion and maybe I'll be proven wrong.

What extensibility points are most needed?
 

From rt at openssl.org  Wed Feb  4 16:11:48 2015
From: rt at openssl.org (=?UTF-8?B?R8O2cmFuIEhhbW1hcmLDpGNr?= via RT)
Date: Wed, 4 Feb 2015 17:11:48 +0100
Subject: [openssl-dev] [openssl.org #3688] Bug report; OpenSSL 1.0.2;
	Solaris 11.0; Sparc T4; evp_test core dumps
In-Reply-To: <1423036028.19595.115.camel@rydra.dev.top>
References: <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
Message-ID: <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>

Hello,

I am building openssl 1.0.2 on a number of platforms, and I am having
problems on a virtual Solaris 11.0 machine running on a Sparc T4.
The code builds fine, but the evp_test core dumps. Here are the last
lines of output from the command (test/evp_test test/evptests.txt):

Testing cipher id-aes256-CCM(encrypt/decrypt)
Key
0000 1b de 32 51 d4 1a 8b 5e a0 13 c1 95 ae 12 8b 21
0010 8b 3e 03 06 37 63 57 07 7e f1 c1 c7 85 48 b9 2e
IV
0000 5b 8e 40 74 6f 6b 98 e0 0f 1d 13 ff 41
Plaintext
0000 53 bd 72 a9 70 89 e3 12 42 2b f7 2e 24 23 77 b3
0010 c6 ee 3e 20 75 38 9b 99 9c 4e f7 f2 8b d2 b8 0a
Ciphertext
0000 9a 5f cc cd b4 cf 04 e7 29 3d 27 75 cc 76 a4 88
0010 f0 42 38 2d 94 9b 43 b7 d6 bb 2b 98 64 78 67 26
AAD
0000 c1 7a 32 51 4e b6 10 3f 32 49 e0 76 d4 c8 71 dc
0010 97 e0 4b 28 66 99 e5 44 91 dc 18 f6 d7 34 d4 c0
Tag
0000 20 24 93 1d 73 bc a4 80 c2 4a 24 ec e6 b6 c2 bf
zsh: segmentation fault (core dumped)  ./test/evp_test test/evptests.txt

pstack:
sol11b% pstack core
core 'core' of 19831:   ./test/evp_test test/evptests.txt
 00000b80 ???????? (6bb20, ffbfec80, ffbfd240, 20, b80, 1)
 ff20c3c4 aes_ccm_cipher (ffbfe240, ffbfd240, ffbfec80, 20, ff20c220,
ff2d8894) + 1a4
 ff205e90 EVP_EncryptUpdate (ffbfe240, ffbfd240, ffbfd22c, ffbfec80, 20,
1) + 110
 00011afc test1    (ff2d8894, ffbfec24, ffffec00, ffbfe2d0, d, 0) + 33c
 00012ed8 main     (ffbfe394, ffffe76c, ffffffff, ffbfe398, ffffe768,
ffffe794) + 658
 0001161c _start   (0, 0, 0, 0, 0, 0) + 5c

If I comment out the aes-256-ccm line in evptests.txt, all other tests
run fine. When I run the same binary on a virtual machine on a Sparc T2,
it works fine. I also tried building the code on the T2, but it still
fails on the T4. ldd on evp_test shows that it is using the correct
1.0.2 versions of libssl.so and libcrypto.so.

I also tried with the openssl-1.0.2-stable-SNAP-20150202 snapshot but
got the same result.

If I build with no-asm, it works.

Regards,

G?ran Hammarb?ck




From rex at kalos-inc.com  Wed Feb  4 16:29:12 2015
From: rex at kalos-inc.com (Rex Bloom)
Date: Wed, 4 Feb 2015 10:29:12 -0600
Subject: [openssl-dev] FIPS compliant digital signature
Message-ID: <71570E7AB2E42D41A10FC97E532B699D014198462E96@MAILSERVER.KalosInc.local>

Can someone help me understand what type of digital signature I can use for FIPS compliance.

I used this command:



openssl genrsa -aes128 -passout pass:mypassphrase -out privkey.pem 2048



to generate a pem file but when I tried to load this as follows:



RSA *rkey = PEM_read_bio_RSAPrivateKey( bio, 0, 0, (void*)"mypassphrase");



I receive this error



error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips'.



Can you point to anything I am doing wrong here?



The main reason I ask is because if I leave the passphrase off then everything works but obviously that is not ideal !



Thank you,

Rex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150204/4ebe9b64/attachment.html>

From uri at ll.mit.edu  Wed Feb  4 17:09:01 2015
From: uri at ll.mit.edu (Blumenthal, Uri - 0558 - MITLL)
Date: Wed, 4 Feb 2015 17:09:01 +0000
Subject: [openssl-dev] FW: AlgorithmIdentifier validation issue and PATCH
 openssl 1.0.1k 1.0.1l 1.0.2
Message-ID: <D0F7BBDE.2093B%uri@ll.mit.edu>

On 1/29/15, 16:20 , "Blumenthal, Uri - 0558 - MITLL" <uri at ll.mit.edu>
wrote:

>Certificates that are semantically correct but encoded by ?obtuse? CA
>(Apple in particular) fail to validate because they encode
>AlgorithmIdentifier in two legal but slightly different ways.
>
>Until 1.0.1k OpenSSL code did not bother to check whether signature
>algorithm that is present in two places is the same. The check introduced
>in 1.0.1k breaks valid certificates that use ?absent? for parameter list
>rather than encoding it as ASN.1 NULL.
>
>Leaving alone whether it is legal (it appears so from the relevant RFCs)
>or smart (it probably isn?t, but I can?t make Apple to change their
>software) to do so, here?s a patch (submitted through RT as well) that
>addresses this issue. It also fixes the problem when two
>AlgorithmIdentifier objects fail to compare if both have parameter list
>?absent?. This patch applies to (work with) versions 1.0.1k, 1.0.1l and
>1.0.2.
>Referred to in http://rt.openssl.org/Ticket/Display.html?id=3665
>
>Thanks!
>
>
>--- crypto/asn1/a_type.c.~1~ 2015-01-15 09:43:14.000000000 -0500
>+++ crypto/asn1/a_type.c 2015-01-20 22:57:48.000000000 -0500
>@@ -117,6 +117,8 @@
>{
>int result = -1;
>
>+ if (!a && !b) return 0; /* both null-pointers => both absent/equal */
>+
>if (!a || !b || a->type != b->type) return -1;
>
>switch (a->type)
>--- crypto/asn1/x_algor.c.~1~ 2015-01-15 09:43:14.000000000 -0500
>+++ crypto/asn1/x_algor.c 2015-01-20 23:00:54.000000000 -0500
>@@ -151,5 +151,12 @@
>return rv;
>if (!a->parameter && !b->parameter)
>return 0;
>+ if ((!a->parameter && b->parameter
>+ && b->parameter->type == V_ASN1_NULL)
>+ ||
>+ (!b->parameter && a->parameter
>+ && a->parameter->type == V_ASN1_NULL)
>+ )
>+ return 0;
>return ASN1_TYPE_cmp(a->parameter, b->parameter);
>}
>
>
>-- 
>Regards,
>Uri Blumenthal                               Voice: (781) 981-1638

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-null-absent.diff
Type: application/octet-stream
Size: 783 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150204/bd0b34b8/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150204/bd0b34b8/attachment-0001.bin>

From steve at openssl.org  Wed Feb  4 19:21:19 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 4 Feb 2015 19:21:19 +0000
Subject: [openssl-dev] FIPS compliant digital signature
In-Reply-To: <71570E7AB2E42D41A10FC97E532B699D014198462E96@MAILSERVER.KalosInc.local>
References: <71570E7AB2E42D41A10FC97E532B699D014198462E96@MAILSERVER.KalosInc.local>
Message-ID: <20150204192119.GA15897@openssl.org>

On Wed, Feb 04, 2015, Rex Bloom wrote:

> Can someone help me understand what type of digital signature I can use for FIPS compliance.
> 
> I used this command:
> 
> openssl genrsa -aes128 -passout pass:mypassphrase -out privkey.pem 2048
> 
> to generate a pem file but when I tried to load this as follows:
> 
> RSA *rkey = PEM_read_bio_RSAPrivateKey( bio, 0, 0, (void*)"mypassphrase");
> 
> I receive this error
> 
> error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips'.
> 
> Can you point to anything I am doing wrong here?
> 

This is an openssl-users question not openssl-dev.

You need to be in FIPS mode when you create the key. So if you do:

OPENSSL_FIPS=1 openssl genrsa ...

It should work.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rex at kalos-inc.com  Wed Feb  4 19:30:29 2015
From: rex at kalos-inc.com (Rex Bloom)
Date: Wed, 4 Feb 2015 13:30:29 -0600
Subject: [openssl-dev] FIPS compliant digital signature
In-Reply-To: <20150204192119.GA15897@openssl.org>
References: <71570E7AB2E42D41A10FC97E532B699D014198462E96@MAILSERVER.KalosInc.local>
 <20150204192119.GA15897@openssl.org>
Message-ID: <71570E7AB2E42D41A10FC97E532B699D014198591F3C@MAILSERVER.KalosInc.local>

Thank you!!  Worked perfectly and was exactly what I was missing.

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Wednesday, February 4, 2015 1:21 PM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] FIPS compliant digital signature

On Wed, Feb 04, 2015, Rex Bloom wrote:

> Can someone help me understand what type of digital signature I can use for FIPS compliance.
> 
> I used this command:
> 
> openssl genrsa -aes128 -passout pass:mypassphrase -out privkey.pem 
> 2048
> 
> to generate a pem file but when I tried to load this as follows:
> 
> RSA *rkey = PEM_read_bio_RSAPrivateKey( bio, 0, 0, 
> (void*)"mypassphrase");
> 
> I receive this error
> 
> error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips'.
> 
> Can you point to anything I am doing wrong here?
> 

This is an openssl-users question not openssl-dev.

You need to be in FIPS mode when you create the key. So if you do:

OPENSSL_FIPS=1 openssl genrsa ...

It should work.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org _______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From foleyj at cisco.com  Wed Feb  4 21:34:28 2015
From: foleyj at cisco.com (John Foley)
Date: Wed, 04 Feb 2015 16:34:28 -0500
Subject: [openssl-dev] ms\version32.rc(47) : fatal error RC1004: unexpected
 end of file found
Message-ID: <54D29064.2000906@cisco.com>

Is anyone seeing the following error when building master on Windows?

ms\version32.rc(47) : fatal error RC1004: unexpected end of file found

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.EXE"' : return code '0x1'
Stop.



The full build log is located here: 
http://openssl-sanity.cisco.com:8080/job/master_windows/42/console

The contents of version32.rc, which is a generated file, are located
here:
http://openssl-sanity.cisco.com:8080/job/master_windows/ws/ms/version32.rc/*view*/

From matt at openssl.org  Wed Feb  4 23:40:08 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 04 Feb 2015 23:40:08 +0000
Subject: [openssl-dev] ms\version32.rc(47) : fatal error RC1004:
 unexpected end of file found
In-Reply-To: <54D29064.2000906@cisco.com>
References: <54D29064.2000906@cisco.com>
Message-ID: <54D2ADD8.4040809@openssl.org>



On 04/02/15 21:34, John Foley wrote:
> Is anyone seeing the following error when building master on Windows?
> 
> ms\version32.rc(47) : fatal error RC1004: unexpected end of file found
> 
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.EXE"' : return code '0x1'
> Stop.
> 

I think Steve just fixed this.

Matt


From foleyj at cisco.com  Wed Feb  4 23:46:20 2015
From: foleyj at cisco.com (John Foley (foleyj))
Date: Wed, 4 Feb 2015 23:46:20 +0000
Subject: [openssl-dev] ms\version32.rc(47) : fatal error RC1004:
 unexpected end of file found
In-Reply-To: <54D2ADD8.4040809@openssl.org>
References: <54D29064.2000906@cisco.com>,<54D2ADD8.4040809@openssl.org>
Message-ID: <7AC5B494-63B2-4E6B-B7F6-2AA5924AF701@cisco.com>

Yes, it's working now.  Thanks.

Are you interested in receiving the build failure notification directly from our Jenkins server?  Or would you rather I continue to forward the failures to Openssl-dev?


> On Feb 4, 2015, at 6:40 PM, "Matt Caswell" <matt at openssl.org> wrote:
> 
> 
> 
>> On 04/02/15 21:34, John Foley wrote:
>> Is anyone seeing the following error when building master on Windows?
>> 
>> ms\version32.rc(47) : fatal error RC1004: unexpected end of file found
>> 
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.EXE"' : return code '0x1'
>> Stop.
> 
> I think Steve just fixed this.
> 
> Matt
> 
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

From rt at openssl.org  Wed Feb  4 23:52:06 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 5 Feb 2015 00:52:06 +0100
Subject: [openssl-dev] [openssl.org #3686] doc/openssl-shared.txt - "No such
	file"
In-Reply-To: <COL126-W33CBCE799149CEB1483CD2A23D0@phx.gbl>
References: <RT-Ticket-3686@openssl.org>
 <COL126-W33CBCE799149CEB1483CD2A23D0@phx.gbl>
Message-ID: <rt-4.0.4-25406-1423093926-60.3686-6-0@openssl.org>

Thanks, fixed.

commit 1f7103b6ebd1579e4ead17405f89d44330386949
Author: Rich Salz <rsalz at openssl.org>
Date: Wed Feb 4 18:50:00 2015 -0500

Fix various build breaks

TABLE wasn't updated from a previous Configure change
Missed an RMD160/RIPE/RIPEMD unification in mkdef.pl
Makefile install_sw referenced file doc/openssl-shared.txt (RT3686)
Needed to run 'make update' because
- Various old code has been removed
- Varous old #ifdef tests were removed

Reviewed-by: Richard Levitte <levitte at openssl.org>

--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Thu Feb  5 04:50:24 2015
From: rt at openssl.org (Mark Andrews via RT)
Date: Thu, 5 Feb 2015 05:50:24 +0100
Subject: [openssl-dev] [openssl.org #3650] sha1-586.asm broken in
	1.0.2-stable for Windows builds
In-Reply-To: <20150205040253.EFE4528BC795@rock.dv.isc.org>
References: <RT-Ticket-3650@openssl.org>
 <20150205040253.EFE4528BC795@rock.dv.isc.org>
Message-ID: <rt-4.0.4-4053-1423111824-291.3650-6-0@openssl.org>


I am also having a issue this issue.  It is a 32 bit build issue
only.  The 64 bit build completes using the same development
environment.  The offending instruction is "movd".  Unfortunately
I am not a x86 assembler expert.

Mark

        perl crypto\sha\asm\sha1-586.pl win32 /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS
  -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_
MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL
_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -
DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH
_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KR
B5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE >tmp32dll\sha1-586.asm
        ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32dll\sha1-586.obj tmp32dll\sha1-5
86.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 11.0
\VC\BIN\ml.EXE"' : return code '0x1'
Stop.

$Lshaext_shortcut::
	mov	edi,DWORD PTR 20[esp]
	mov	ebx,esp
	mov	esi,DWORD PTR 24[esp]
	mov	ecx,DWORD PTR 28[esp]
	sub	esp,32
	movdqu	xmm0,XMMWORD PTR [edi]
	movd	xmm1,XMMWORD PTR 16[edi]		* 1432
	and	esp,-32
	movdqa	xmm3,XMMWORD PTR 80[ebp]
	movdqu	xmm4,XMMWORD PTR [esi]
	pshufd	xmm0,xmm0,27
	movdqu	xmm5,XMMWORD PTR 16[esi]
	pshufd	xmm1,xmm1,27
	movdqu	xmm6,XMMWORD PTR 32[esi]

DB	15,56,200,202
	paddd	xmm0,XMMWORD PTR 16[esp]
	jnz	$L004loop_shaext
	pshufd	xmm0,xmm0,27
	pshufd	xmm1,xmm1,27
	movdqu	XMMWORD PTR [edi],xmm0
	movd	XMMWORD PTR 16[edi],xmm1		* 1576
	mov	esp,ebx
	pop	edi
	pop	esi
	pop	ebx
	pop	ebp
	ret


-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: marka at isc.org



From rt at openssl.org  Thu Feb  5 08:09:28 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Thu, 5 Feb 2015 09:09:28 +0100
Subject: [openssl-dev] [openssl.org #3650] sha1-586.asm broken in
	1.0.2-stable for Windows builds
In-Reply-To: <54D32532.6060504@openssl.org>
References: <RT-Ticket-3650@openssl.org>
 <20150205040253.EFE4528BC795@rock.dv.isc.org>
 <rt-4.0.4-4053-1423111824-291.3650-6-0@openssl.org>
 <54D32532.6060504@openssl.org>
Message-ID: <rt-4.0.4-5491-1423123768-105.3650-6-0@openssl.org>

> I am also having a issue this issue.  It is a 32 bit build issue
> only.  The 64 bit build completes using the same development
> environment.  The offending instruction is "movd".  Unfortunately
> I am not a x86 assembler expert.
> 
> Mark
> 
>         perl crypto\sha\asm\sha1-586.pl win32 /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS
>   -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_
> MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL
> _IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -
> DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH
> _ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KR
> B5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE >tmp32dll\sha1-586.asm
>         ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32dll\sha1-586.obj tmp32dll\sha1-5
> 86.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 11.0
> \VC\BIN\ml.EXE"' : return code '0x1'
> Stop.
> 
> $Lshaext_shortcut::
> 	mov	edi,DWORD PTR 20[esp]
> 	mov	ebx,esp
> 	mov	esi,DWORD PTR 24[esp]
> 	mov	ecx,DWORD PTR 28[esp]
> 	sub	esp,32
> 	movdqu	xmm0,XMMWORD PTR [edi]
> 	movd	xmm1,XMMWORD PTR 16[edi]		* 1432

Ah! It should be DWORD, not XMMWORD... Devja vu! There was similar case
with movq elsewhere. See if attached fixes the problem.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: masm.diff
Type: text/x-patch
Size: 958 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150205/3a718a9e/attachment.bin>

From rt at openssl.org  Thu Feb  5 15:08:59 2015
From: rt at openssl.org (Neitzert, Greg A via RT)
Date: Thu, 5 Feb 2015 16:08:59 +0100
Subject: [openssl-dev] [openssl.org #3689] Bug report - OpenSSL 0.9.8ze with
	FIPS canister 1.2.4 big number test failure
In-Reply-To: <9e13e9aca86d4caa99cdd4681a542770@US-EXCH13-4.na.uis.unisys.com>
References: <RT-Ticket-3689@openssl.org>
 <9e13e9aca86d4caa99cdd4681a542770@US-EXCH13-4.na.uis.unisys.com>
Message-ID: <rt-4.0.4-14525-1423148938-1488.3689-21-0@openssl.org>

Summary: 'big number library' test fails during 'make test' phase of OpenSSL 0.9.8ze build when built with the FIPS canister.

NOTE:  I am not sure if this would qualify for support since 0.9.8 is in an end of life mode, but I am submitting in case it is, or at least a bug entry could be made if it won't be fixed.

Version: OpenSSL 0.9.8ze (also reproducible on 0.9.8zb, zc, zd) when built with FIPS canister inclusion.
Does NOT occur on OpenSSL 0.9.8za.

NOTE:  Problem ONLY occurs if you build the FIPS canister and build OpenSSL with the 'fips' and '-with-fipslibdir' option.  Problem does NOT occur if you build OpenSSL without the FIPS canister.  Note that the FIPS canister continues to build with no issues.  The failing build is the openssl 0.9.8ze build when FIPS canister is flagged for inclusion.

Operating system: SLES 11 SP1, SLES 11 SP3, RedHat Linux 6.5 (all x86_64)

Problem:
During the 'make test' phase of the build, the following error is generated:
starting big number library test, could take a while...
test BN_add
test BN_sub
test BN_lshift1
test BN_lshift (fixed)
test BN_lshift
test BN_rshift1
test BN_rshift
test BN_sqr
Square test failed: BN_sqr and BN_mul produce different results!
make[1]: *** [test_bn] Error 1

This error occurs on all of the operating systems listed above, using any version of OpenSSL 0.9.8 greater than 0.9.8za.
If you build with the same source without the 'fips' and '-with-fipslibdir' flags to 'config', the build including the 'make test' is successful.

The following are the configuration flags used for the build:

./config threads shared no-rc5 no-idea enable-camellia zlib fips no-ec --with-fipslibdir=/tmp/openssl-fips-1.2/build/BUILD/fips-1.2/openssl-fips-1.2.4/fips/ --prefix=/usr/local/ssl/fips-1.0 --libdir=lib --openssldir=/usr/local/ssl/fips-1.0 -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector -m64 -mtune=generic -std=gnu99 -Wa,--noexecstack -fomit-frame-pointer -DTERMIO -DPURIFY -DSSL_FORBID_ENULL -D_GNU_SOURCE -Wall -fstack-protector

NOTE:  The following option was also included in my generated config on SLES 11:
--param=ssp-buffer-size=4

This parameter did not work on RedHat and was omitted from the ./config phase.

The FIPS 1.2.4 canister was built prior to the OpenSSL build as required.
This has worked with all previous levels of OpenSSL through OpenSSL 0.9.8za.

Thanks,
Greg Neitzert
Unisys Corp







Greg Neitzert  |  Software Engineer |  Middleware Development | ESC | TCIS

Unisys | Home Based | Sioux Falls, SD 57106 USA | NET 279-9662 | 612-486-9662    [Description: cid:image001.gif at 01CAF35C.09F4CF20] <http://www.youtube.com/theunisyschannel>  [Description: cid:image002.gif at 01CAF35C.09F4CF20] <http://www.facebook.com/unisyscorp>  [Description: cid:image003.gif at 01CAF35C.09F4CF20] <http://www.linkedin.com/companies/unisys>  [Description: cid:image004.gif at 01CAF35C.09F4CF20] <http://www.twitter.com/unisyscorp>  [Description: cid:image005.gif at 01CAF35C.09F4CF20] <http://www.unisys.com/>


[cid:image008.gif at 01CD10E5.82765240]


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers.






-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 1192 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150205/06a7601b/attachment-0005.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 759 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150205/06a7601b/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.gif
Type: image/gif
Size: 1188 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150205/06a7601b/attachment-0007.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.gif
Type: image/gif
Size: 1195 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150205/06a7601b/attachment-0008.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 731 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150205/06a7601b/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image006.gif
Type: image/gif
Size: 2511 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150205/06a7601b/attachment-0009.gif>

From ho at cs.arizona.edu  Thu Feb  5 16:39:56 2015
From: ho at cs.arizona.edu (Hilarie Orman)
Date: Thu, 5 Feb 2015 09:39:56 -0700
Subject: [openssl-dev] Signing individual attachments?
Message-ID: <201502051639.t15Gdur3025875@sylvester.rhmr.com>

Does openssl have support for S/MIME signatures on individual attachments?
I would like to have attachment1 signed with identity1, attachment2 signed
with identity2, and the whole message signed with identity3.  Email readers
seem to get confused by this (but, I might have made a mistake in
constructing the test message).

I think I can use openssl command line options to deconstruct such a
message and verify the individual parts, but is there a single command
that would handle it?

Hilarie Orman

From openssl-users at dukhovni.org  Thu Feb  5 17:07:28 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 5 Feb 2015 17:07:28 +0000
Subject: [openssl-dev] Signing individual attachments?
In-Reply-To: <201502051639.t15Gdur3025875@sylvester.rhmr.com>
References: <201502051639.t15Gdur3025875@sylvester.rhmr.com>
Message-ID: <20150205170728.GN8034@mournblade.imrryr.org>

On Thu, Feb 05, 2015 at 09:39:56AM -0700, Hilarie Orman wrote:

> Does openssl have support for S/MIME signatures on individual attachments?
> I would like to have attachment1 signed with identity1, attachment2 signed
> with identity2, and the whole message signed with identity3.  Email readers
> seem to get confused by this (but, I might have made a mistake in
> constructing the test message).
> 
> I think I can use openssl command line options to deconstruct such a
> message and verify the individual parts, but is there a single command
> that would handle it?

A multipart signed or unsigned message can contain another multipart
signed or unsigned.  The OpenSSL S/MIME command can decrypt and/or
verify the outer multipart (message).  If that message contains
parts that are in turn S/MIME messages, you'd have to extract those
parts and apply the process recursively.  The command-line tool
cannot AFAIK do this in one step.

-- 
	Viktor.

From richmoore44 at gmail.com  Sat Feb  7 14:41:53 2015
From: richmoore44 at gmail.com (Richard Moore)
Date: Sat, 7 Feb 2015 14:41:53 +0000
Subject: [openssl-dev] The evolution of the 'master' branch
In-Reply-To: <20150203220231.GA12587@openssl.org>
References: <20150203220231.GA12587@openssl.org>
Message-ID: <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>

On 3 February 2015 at 22:02, Rich Salz <rsalz at openssl.org> wrote:

> As we've already said, we are moving to making most OpenSSL data
> structures opaque. We deliberately used a non-specific term. :)
> As of Matt's commit of the other day, this is starting to happen
> now.  We know this will inconvenience people as some applications
> no longer build.  We want to work with maintainers to help them
> migrate, as we head down this path.
>
> We have a wiki page to discuss this effort.  It will eventually include
> tips on migration, application and code updates, and anything else the
> community finds useful.  Please visit:
>
>         http://wiki.openssl.org/index.php/1.1_API_Changes


I've documented what got broken in Qt by the changes so far. I've listed
the functions I think we can use instead where they exist, and those where
there does not appear to be a replacement.

Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150207/cc7fa4b9/attachment.html>

From rt at openssl.org  Sat Feb  7 20:06:26 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Sat, 7 Feb 2015 21:06:26 +0100
Subject: [openssl-dev] [openssl.org #3688] Bug report; OpenSSL 1.0.2;
	Solaris 11.0; Sparc T4; evp_test core dumps
In-Reply-To: <54D67039.9060602@openssl.org>
References: <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54D67039.9060602@openssl.org>
Message-ID: <rt-4.0.4-16651-1423339586-348.3688-6-0@openssl.org>

Hi,

> I am building openssl 1.0.2 on a number of platforms, and I am having
> problems on a virtual Solaris 11.0 machine running on a Sparc T4.
> The code builds fine, but the evp_test core dumps. Here are the last
> lines of output from the command (test/evp_test test/evptests.txt):
> 
> Testing cipher id-aes256-CCM(encrypt/decrypt)
> ...
> zsh: segmentation fault (core dumped)  ./test/evp_test test/evptests.txt

It's rather incredible that this slipped through. I've run the test many
times and 1.0.2 actually passes the test at the moment of this writing.
Well, I'm running on Linux, but it's circumstantial that it worked.
Verify that attached patch solves the problem.

-------------- next part --------------
diff --git a/crypto/evp/e_aes.c b/crypto/evp/e_aes.c
index 41844bc..8161b26 100644
--- a/crypto/evp/e_aes.c
+++ b/crypto/evp/e_aes.c
@@ -790,6 +790,8 @@ static int aes_t4_ccm_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
         default:
             return 0;
         }
+#  else
+        cctx->str = NULL;
 #  endif
         cctx->key_set = 1;
     }

From openssl at roumenpetrov.info  Sun Feb  8 12:54:26 2015
From: openssl at roumenpetrov.info (Roumen Petrov)
Date: Sun, 08 Feb 2015 14:54:26 +0200
Subject: [openssl-dev] Seeking feedback on some #ifdef changes
In-Reply-To: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <54D75C82.7080606@roumenpetrov.info>

Hi Rich,

Salz, Rich wrote:
> Looking at just OPENSSL_NO_xxx, we have over 100 openssl #ifdef options and we are considering removing nearly a third of them.  Please reply soon if the following plan would cause problems. This will happen only in master, for post-1.0.2.
> We will remove the following options.  You could argue that the OPENSSL_NO_SHAxxx options be treated as crypto, but OpenSSL does not compile without SHA and SHA1 defined, and we have no interest in spending the time to fix it. So for consistency, we will remove all of them.

What about a) OPENSSL_NO_SSL2 and b) OPENSSL_NO_SSL3 and 
OPENSSL_NO_SSL3_METHOD ?
It seems to me master branch does not define #ifdef for those options in 
opensslconf.h .

Change log point that ssl v2 is removed. It is expected opensslconf.h to 
define unconditionally OPENSSL_NO_SSL2.

Please review ssl3. It seems to me b) is error in script.

>          [SNIP]
>          OPENSSL_NO_STORE
Also removing the code?


Regards,
Roumen Petrov


From rt at openssl.org  Sun Feb  8 16:37:07 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Sun, 8 Feb 2015 17:37:07 +0100
Subject: [openssl-dev] [openssl.org #3690] s_client.c and missing psk_key
	symbol
In-Reply-To: <CAH8yC8mci+uFaPDrM_wyC21xOJP_KK4qvSr1iuqPU5WHGykong@mail.gmail.com>
References: <RT-Ticket-3690@openssl.org>
 <CAH8yC8mci+uFaPDrM_wyC21xOJP_KK4qvSr1iuqPU5WHGykong@mail.gmail.com>
Message-ID: <rt-4.0.4-8930-1423413427-1394.3690-21-0@openssl.org>

Modifying and compiling s_client.c manually results in a compile failure:

  export OPENSSLDIR=/usr/local/ssl/darwin
  gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c apps.c
  gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c app_rand.c
  gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c s_cb.c
  gcc -DMONOLITH -I$OPENSSLDIR/include -I../ -c s_socket.c
  gcc -I$OPENSSLDIR/include -I../ app_rand.o apps.o s_cb.o s_socket.o \
    $OPENSSLDIR/lib/libssl.a $OPENSSLDIR/lib/libcrypto.a s_client.c -o
my_s_client.exe

  Undefined symbols for architecture x86_64:
    "_psk_key", referenced from:
      _main in s_client-7f5596.o
      _psk_client_cb in s_client-7f5596.o
  ld: symbol(s) not found for architecture x86_64
  clang: error: linker command failed with exit code 1 (use -v to see
invocation)

It appears psk_key was inadvertently commented out (from around line 225):

#ifndef OPENSSL_NO_PSK
/* Default PSK identity and key */
static char *psk_identity="Client_identity";
/*char *psk_key=NULL;  by default PSK is not used */
...



From rt at openssl.org  Mon Feb  9 02:09:11 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Mon, 9 Feb 2015 03:09:11 +0100
Subject: [openssl-dev] [openssl.org #3690] s_client.c and missing psk_key
	symbol
In-Reply-To: <CAH8yC8mci+uFaPDrM_wyC21xOJP_KK4qvSr1iuqPU5WHGykong@mail.gmail.com>
References: <RT-Ticket-3690@openssl.org>
 <CAH8yC8mci+uFaPDrM_wyC21xOJP_KK4qvSr1iuqPU5WHGykong@mail.gmail.com>
Message-ID: <rt-4.0.4-11736-1423447751-1068.3690-6-0@openssl.org>

Something seems strange; -DMONOLITH but it's trying to build a .exe?

At an rate, non-monolith has been broken for some time and isn't really
supported any more.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rsalz at akamai.com  Mon Feb  9 03:16:01 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 9 Feb 2015 03:16:01 +0000
Subject: [openssl-dev] Seeking feedback on some #ifdef changes
In-Reply-To: <54D75C82.7080606@roumenpetrov.info>
References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com>
 <54D75C82.7080606@roumenpetrov.info>
Message-ID: <03ba45bce5614c99a33c3192fb06a40d@ustx2ex-dag1mb2.msg.corp.akamai.com>

> What about a) OPENSSL_NO_SSL2 and b) OPENSSL_NO_SSL3 and
> OPENSSL_NO_SSL3_METHOD ?
> It seems to me master branch does not define #ifdef for those options in
> opensslconf.h .

Hm, maybe Kurt can comment on this.

> Change log point that ssl v2 is removed. It is expected opensslconf.h to
> define unconditionally OPENSSL_NO_SSL2.

Interesting idea.

> >          OPENSSL_NO_STORE
> Also removing the code?

The team member working on this wants to keep it in the tree for now, so we will.

From rt at openssl.org  Mon Feb  9 09:56:56 2015
From: rt at openssl.org (=?UTF-8?B?R8O2cmFuIEhhbW1hcmLDpGNr?= via RT)
Date: Mon, 9 Feb 2015 10:56:56 +0100
Subject: [openssl-dev] [openssl.org #3688] Bug report; OpenSSL 1.0.2;
	Solaris 11.0; Sparc T4; evp_test core dumps
In-Reply-To: <1423475793.19595.198.camel@rydra.dev.top>
References: <RT-Ticket-3688@openssl.org>
 <1423475793.19595.198.camel@rydra.dev.top>
Message-ID: <rt-4.0.4-10852-1423475816-256.3688-6-0@openssl.org>

> > I am building openssl 1.0.2 on a number of platforms, and I am
having
> > problems on a virtual Solaris 11.0 machine running on a Sparc T4.
> > The code builds fine, but the evp_test core dumps. Here are the last
> > lines of output from the command (test/evp_test test/evptests.txt):
> > 
> > Testing cipher id-aes256-CCM(encrypt/decrypt)
> > ...
> > zsh: segmentation fault (core dumped)  ./test/evp_test test/evptests.txt
> 
> It's rather incredible that this slipped through. I've run the test many
> times and 1.0.2 actually passes the test at the moment of this writing.
> Well, I'm running on Linux, but it's circumstantial that it worked.
> Verify that attached patch solves the problem.

Hello,

I applied the patch and rebuilt everything, and now all tests pass on
the T4 machine (and T2).

Thank you!

G?ran Hammarb?ck



From rt at openssl.org  Mon Feb  9 16:11:42 2015
From: rt at openssl.org (noloader@gmail.com via RT)
Date: Mon, 9 Feb 2015 17:11:42 +0100
Subject: [openssl-dev] [openssl.org #3691] Wishlist: separate strings for
	libcrypto and libssl
In-Reply-To: <CAH8yC8=4csuamrW+QaMOTOysQvG4Z0B=RQurPDqAPvOM0qv68Q@mail.gmail.com>
References: <RT-Ticket-3691@openssl.org>
 <CAH8yC8=4csuamrW+QaMOTOysQvG4Z0B=RQurPDqAPvOM0qv68Q@mail.gmail.com>
Message-ID: <rt-4.0.4-25065-1423498300-337.3691-21-0@openssl.org>

A while back, Google started flagging software in Google Play for
providing what it believed to be vulnerable versions of OpenSSL. See,
for example, "Security Alert: You are using a highly vulnerable
version of OpenSSL,"
https://groups.google.com/d/msg/android-security-discuss/o3ymXQjdQLI/3Ssoa47R_IYJ.

Google issued the notices based on the presence OpenSSL strings.
According to the folks on the Android Security team, they based it on
(https://groups.google.com/d/msg/android-security-discuss/o3ymXQjdQLI/KianK6PIIagJ):

    $ unzip -p YourApp.apk | strings | grep "OpenSSL"

I had software caught up in that because libssl and libcrypto do not
provide separate strings. That is, libssl was vulnerable, libcrypto
was OK, but there was no way to differentiate between use of of the
two libraries.

Please consider providing separate strings for libssl and libcrypto so
third party policing actions can be more surgical.



From rt at openssl.org  Mon Feb  9 16:33:54 2015
From: rt at openssl.org (Richard Levitte via RT)
Date: Mon, 9 Feb 2015 17:33:54 +0100
Subject: [openssl-dev] [openssl.org #3691] Wishlist: separate strings for
	libcrypto and libssl
In-Reply-To: <CAH8yC8=4csuamrW+QaMOTOysQvG4Z0B=RQurPDqAPvOM0qv68Q@mail.gmail.com>
References: <RT-Ticket-3691@openssl.org>
 <CAH8yC8=4csuamrW+QaMOTOysQvG4Z0B=RQurPDqAPvOM0qv68Q@mail.gmail.com>
Message-ID: <rt-4.0.4-30796-1423499634-463.3691-6-0@openssl.org>

On Mon Feb 09 17:11:39 2015, noloader at gmail.com wrote:
> Google issued the notices based on the presence OpenSSL strings.
> According to the folks on the Android Security team, they based it on
> (https://groups.google.com/d/msg/android-security-
> discuss/o3ymXQjdQLI/KianK6PIIagJ):
>
> $ unzip -p YourApp.apk | strings | grep "OpenSSL"

That's not what Eric Davis says in that thread, is it? What I'm reading is that
you can figure which of your applications uses OpenSSL by running that command.

> I had software caught up in that because libssl and libcrypto do not
> provide separate strings. That is, libssl was vulnerable, libcrypto
> was OK, but there was no way to differentiate between use of of the
> two libraries.
>
> Please consider providing separate strings for libssl and libcrypto so
> third party policing actions can be more surgical.

I have a question, why don't you follow Eric's advice? In the thread mentioned
above, he also says this:

Eric> (2) Please update all statically linked versions of OpenSSL to 1.0.1h,
1.0.0m, or 0.9.8za. Eric> (3) If you are using a 3rd party library that bundles
OpenSSL, please notify the 3rd party and work with them to address this.?

So either you or possible 3d party providers will have to upgrade OpenSSL,
that's what Eric is telling you.

If the OpenSSL you have and the OpenSSL that the 3rd party are upgraded to the
versions Eric mentions or later ones, then maybe that should be mentioned to
Google.

Asking us to change all strings to not include "OpenSSL" isn't reasonable.

--
Richard Levitte
levitte at openssl.org


From rt at openssl.org  Tue Feb 10 13:44:18 2015
From: rt at openssl.org (Cristi Fati via RT)
Date: Tue, 10 Feb 2015 14:44:18 +0100
Subject: [openssl-dev] [openssl.org #3692] OpenSSL bug(s) && patch
In-Reply-To: <CAO_BNyprccbOniCx0R=OEYiguQyfgCdkp5RGz2vgDoAgK81qJw@mail.gmail.com>
References: <RT-Ticket-3692@openssl.org>
 <CAO_BNyprccbOniCx0R=OEYiguQyfgCdkp5RGz2vgDoAgK81qJw@mail.gmail.com>
Message-ID: <rt-4.0.4-6406-1423575858-1572.3692-21-0@openssl.org>

Version: 1.0.2
Platform: Windows x86 (VC-WIN32)
Compiled with: openssl-fips-2.0.5

Hi all,
I browsed the open bug list for a little while, but i didn't find this.

I've got 3 compilation errors on OpenSSL (details above) on Windows 32bit.
I didn't test it yet, but the first 2 errors (*size_t* being undefined
because of include order) will be reproducible at least on other Windows
configurations, while the 3rd one (which i consider a typo) will be
reproducible on all platforms/archs.

I am attaching a patch which applied gave me a working version:

*c:\Work\Fati\WinBuild\openssl\install\openssl_fips\1.0.2\x86\bin>openssl.exe
version -a*
*OpenSSL 1.0.2-fips 22 Jan 2015*
*built on: reproducible build, date unspecified*
*VC-NT*
*options:  bn(64,32) rc4(idx,int) des(idx,cisc,2,long) blowfish(idx)*
*compiler: cl  /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -GF
-Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN
-D_CRT_SECURE_NO*
*_DEPRECATE -I$(FIPSDIR)/include -DOPENSSL_USE_APPLINK -I.
-DOPENSSL_NO_IDEA -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_MDC2
-DOPENSSL_NO_KRB5 -DOPENSSL_FIPS*
* -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE*
*OPENSSLDIR: "E:\WinOBT\1.0.0.0\openssl_fips\1.0.2\x86"*

*c:\Work\Fati\WinBuild\openssl\install\openssl_fips\1.0.2\x86\bin>openssl.exe
md5 libeay32.dll*
*MD5(libeay32.dll)= 0ffa4263442dd184199b1f293a8105ff*

*c:\Work\Fati\WinBuild\openssl\install\openssl_fips\1.0.2\x86\bin>openssl.exe
SHA1 libeay32.dll*
*SHA1(libeay32.dll)= a930a7c0ecfcdddd8dff2ddd112684fb702e317b*

*c:\Work\Fati\WinBuild\openssl\install\openssl_fips\1.0.2\x86\bin>set
OPENSSL_FIPS=1*

*c:\Work\Fati\WinBuild\openssl\install\openssl_fips\1.0.2\x86\bin>openssl.exe
md5 libeay32.dll*
*Error setting digest md5*
*20680:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled
for fips:.\fips\utl\fips_md.c:180:*

*c:\Work\Fati\WinBuild\openssl\install\openssl_fips\1.0.2\x86\bin>openssl.exe
SHA1 libeay32.dll*
*SHA1(libeay32.dll)= a930a7c0ecfcdddd8dff2ddd112684fb702e317b*

Regards,
Cristi Fati.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-1.0.2-bugs.patch
Type: application/octet-stream
Size: 1497 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150210/b1da11f6/attachment.obj>

From rt at openssl.org  Tue Feb 10 14:01:03 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 10 Feb 2015 15:01:03 +0100
Subject: [openssl-dev] [openssl.org #3692] OpenSSL bug(s) && patch
In-Reply-To: <CAO_BNyprccbOniCx0R=OEYiguQyfgCdkp5RGz2vgDoAgK81qJw@mail.gmail.com>
References: <RT-Ticket-3692@openssl.org>
 <CAO_BNyprccbOniCx0R=OEYiguQyfgCdkp5RGz2vgDoAgK81qJw@mail.gmail.com>
Message-ID: <rt-4.0.4-4691-1423576863-991.3692-6-0@openssl.org>

On Tue Feb 10 14:44:18 2015, cristifati0 at gmail.com wrote:
> Version: 1.0.2
> Platform: Windows x86 (VC-WIN32)
> Compiled with: openssl-fips-2.0.5
>
> Hi all,
> I browsed the open bug list for a little while, but i didn't find
> this.

This was raised in ticket 3673 and fixed by this commit:
6fa805f516f

Many thanks for your report,

Matt


From P at draigBrady.com  Tue Feb 10 15:35:15 2015
From: P at draigBrady.com (=?UTF-8?B?UMOhZHJhaWcgQnJhZHk=?=)
Date: Tue, 10 Feb 2015 15:35:15 +0000
Subject: [openssl-dev] EPIPE handling
Message-ID: <54DA2533.5050209@draigBrady.com>

I was trying to generate random numbers to a pipe yesterday,
and was surprised by the openssl command's handling of EPIPE.
Consider:

  strace openssl rand -base64 10000000 | head -n1

That will redundantly write all the data (ignoring the EPIPE error),
even when the pipe is closed.

For the enc command though, the EPIPE error is not ignored,
which is also problematic, resulting in an unwanted diagnostic:

  strace openssl enc -aes-256-ctr -pass pass:seed -nosalt </dev/zero | head -c1 >/dev/null

Both these issues could be avoided by not ignoring SIGPIPE, which I verified with:

diff --git a/apps/apps.h b/apps/apps.h
index 2e346f9..69bcbba 100644
--- a/apps/apps.h
+++ b/apps/apps.h
@@ -163,7 +163,7 @@ extern BIO *bio_err;
 #  include <signal.h>
 # endif

-# ifdef SIGPIPE
+# if defined SIGPIPE && defined IGNORE_SIGPIPE
 #  define do_pipe_sig()   signal(SIGPIPE,SIG_IGN)
 # else
 #  define do_pipe_sig()


What's the reason exactly that openssl is messing with SIGPIPE?
If this really needs to be controlled for some edge case,
could perhaps the default be changed; at least for the standalone apps?

thanks,
P?draig.

From rt at openssl.org  Tue Feb 10 19:13:11 2015
From: rt at openssl.org (Seth Grover via RT)
Date: Tue, 10 Feb 2015 20:13:11 +0100
Subject: [openssl-dev] [openssl.org #3693] crash in 32-bit OpenSSL
	(1.0.1j-fips) when external .so dynamically loads libcrypto.so
In-Reply-To: <CAD13zvTW+cYY4MS0MAxvDxaG=nO8ZzrEVEEaf5-ZKe-0NegJXg@mail.gmail.com>
References: <RT-Ticket-3693@openssl.org>
 <CAD13zvTW+cYY4MS0MAxvDxaG=nO8ZzrEVEEaf5-ZKe-0NegJXg@mail.gmail.com>
Message-ID: <rt-4.0.4-6825-1423595589-99.3693-21-0@openssl.org>

Greetings,

I have a reproducible crash in ssleay_rand_add (via SSL_library_init)
under the following scenario:

* x86_64 3.10.59 Linux kernel
* 32-bit OpenSSL 1.0.1j-fips
* C main program (compiled with gcc) linked against openssl libraries at
  compile-time
* Pascal (compiled with the Free Pascal compiler) shared object
  library loading openssl library dynamically at run time

This only occurs with a 32-bit executable (64-bit works fine both
with and withoug FIPS) and only when using the FIPS canister (32-bit
seems to work fine if not using FIPS).

Upon initialization of the .so, a segfault occurs with the following
backtrace beginning with SSL_library_init:

 #0 ssleay_rand_add at md_rand.c:320
 #1 RAND_add at rand_lib.c:158
 #2 RAND_poll at rand_unix.c:393
 #3 ssleay_rand_bytes at md_rand.c:396
 #4 drbg_get_entropy at rand_lib.c:203
 #5 fips_get_entropy from /usr/lib/libcrypto.so.1.0.0
 #6 FIPS_drbg_instantiate from /usr/lib/libcrypto.so.1.0.0
 #7 RAND_init_fips at rand_lib.c:298
 #8 OPENSSL_init at o_init.c:76
 #9 EVP_add_cipher at names.c:71
 #10 SSL_library_init at ssl_algs.c:68
 #11 INITSSLINTERFACE at fpc/ssl_openssl_lib.pas:2054
 #12 P$FPCLIB_main at fpc/fpclib.lpr:12
 #13 SI_DLL__FPC_SHARED_LIB_START$LONGWORD$POINTER$POINTER from
./libfpclib.so
 #14 call_init at dl-init.c:69
 #15 call_init at dl-init.c:34
 #16 _dl_init at dl-init.c:133
 #17 _dl_start_user from /lib/ld-linux.so.2

I have attached a tarball containing the following:

* all of the source code (C and Pascal)
* a bash script which compiles and runs the sample program/library
* a gdb core file taken upon receipt of the SIGSEGV
* a text file with the backtrace and shared library information

Hopefully with everything in this tarball you will be able to reproduce
the crash.

Please let me know what you find or if there is any additional information
you need.

Thanks,

Seth Grover
sethdgrover at gmail.com

--
Seth Grover

????? ????

-------------- next part --------------
A non-text attachment was scrubbed...
Name: fpc_ssl_fips_32bit_init_crash.tar.gz
Type: application/x-gzip
Size: 460335 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150210/8cd7f660/attachment-0001.bin>

From rt at openssl.org  Tue Feb 10 19:16:21 2015
From: rt at openssl.org (Lior Gotian via RT)
Date: Tue, 10 Feb 2015 20:16:21 +0100
Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with FIPS
	2.0.8 - fingerprint does not match
In-Reply-To: <D59C04F34BE3D1479A34815B4737AB230FCE6C96@6V-MBX2.CRESTRON.CRESTRON.com>
References: <RT-Ticket-3694@openssl.org>
 <D59C04F34BE3D1479A34815B4737AB230FCE6C96@6V-MBX2.CRESTRON.CRESTRON.com>
Message-ID: <rt-4.0.4-6847-1423595781-907.3694-21-0@openssl.org>

I was successful at compiling the FIPS 2.0.8 module for Windows CE exactly as provided without any modifications.
Additionally, I built fips_algvs.exe to successfully validate the canister on the target system.

After tweaking some #ifdef directives in the openSSL 1.0.1L, I was able to get it to successfully build for WinCE.

The build appears to complete successfully.  However, at run-time, entering FIPS mode fails with an error messages:
FIPS_check_incore_fingerprint:fingerprint does not match

I have reviewed the build instructions carefully and believe all the build instructions have been adhered to.  What needs to be changed for the signature to be properly embedded?

Thank you for your assistance.

Best regards,
Lior Gotian



This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited.


From rt at openssl.org  Tue Feb 10 19:16:38 2015
From: rt at openssl.org (sanchit arora via RT)
Date: Tue, 10 Feb 2015 20:16:38 +0100
Subject: [openssl-dev] [openssl.org #3695] DTLS Handshake issue
	(openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash
In-Reply-To: <CAGgXGhKMSAzS+AuNDgNML7rATit1e-HX5PE2bct+zsa5A+o0gQ@mail.gmail.com>
References: <RT-Ticket-3695@openssl.org>
 <CAGgXGhKMSAzS+AuNDgNML7rATit1e-HX5PE2bct+zsa5A+o0gQ@mail.gmail.com>
Message-ID: <rt-4.0.4-6847-1423595798-1360.3695-21-0@openssl.org>

Bug report

OS: Red hat enterprise Linux 6.5

OpenSSL Version: 1.0.1e-30

While doing DTLS testing with openssl-1.0.1e-30 Version and patches
for RT3327, RT3470 and RT3483 on top of that, we are facing an issue
where our process is crashing during the duration run of 24 hours.

Use Case:
*        There are 125 DTLS Server Connections and 125 DTLS Client Connections.
*        Connection Attempts towards Server connections are also being
made every 1 second.
*        Client Connections are initiating connection attempts every 1 second .
*        SSL Handshake is made to fail so that connection attempts
continues and there are no crashes observed.

During the above duration run, process is always crashing at the below
location always.

#4  <signal handler called>
#5  0x00007f61e97188e9 in sha1_block_data_order_ssse3 () from
/usr/lib64/libcrypto.so.10
#6  0xad89a0d6776026f6 in ?? ()
#7  0xf9e71fd74025dad7 in ?? ()
#8  0x2243d5d8167d7997 in ?? ()
#9  0x8bbb75d9b4efd5d8 in ?? ()
#10 0xea9689da4d4ac2cb in ?? ()
#11 0x7067bc5f5034983b in ?? ()
#12 0xe19f5aa4a5679ed0 in ?? ()
#13 0x8ecbf7e83d1d8ccd in ?? ()
#14 0x00007f61e9a827ce in state () from /usr/lib64/libcrypto.so.10
#15 0x00000000bc803cd0 in ?? ()
#16 0x0000000000000011 in ?? ()
#17 0x00007f61e9715de7 in SHA1_Update () from /usr/lib64/libcrypto.so.10
#18 0x00007f61e97899fd in ssleay_rand_add () from /usr/lib64/libcrypto.so.10
#19 0x00007f61e9ed92f9 in dtls1_accept () from /usr/lib64/libssl.so.10

When we tested with openssl-1.0.1e-16 Version and patches for RT3327,
RT3470 and RT3483 on top of that, the use case works fine.

On investigation, we found that there are 11 patches added between
openssl-1.0.1e-30 and openssl-1.0.1e-16 version out of which following
3 patches are related to DTLS.

openssl-1.0.1e-dtls-ecc-ext.
patch
openssl-1.0.1e-cve-2014-3513.
patch
openssl-1.0.1e-fallback-scsv.patch

We have narrowed down that when we use openssl-1.0.1e-30 Version with
the openssl-1.0.1e-dtls-ecc-ext.patch and patches for RT3327, RT3470
and RT3483 on top of that, process crashes with the above abterm
during the duration run of 24 hours.

When we excluded the openssl-1.0.1e-dtls-ecc-ext.patch from
openssl-1.0.1e-30 Version, we didn't see an abterm during the duration
run of 24  hours.

Therefore, it seems that the openssl-1.0.1e-dtls-ecc-ext.patch is
causing the abterm in the duration run.

Please let us know if there could be issues with the
openssl-1.0.1e-dtls-ecc-ext.patch?

Patch Details:

https://bugzilla.redhat.com/show_bug.cgi?id=1119800


Regards,
Sanchit Arora



From rainer.jung at kippdata.de  Tue Feb 10 19:23:45 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Tue, 10 Feb 2015 20:23:45 +0100
Subject: [openssl-dev] Submitting new bugs to rt via mail broken?
Message-ID: <54DA5AC1.7000306@kippdata.de>

Hello everyone,

I sent a mail to rt at openssl.org 3 days ago, subject "OpenSSL 1.0.2 "make 
test" bus error in evp_test (Solaris 10 Sparc, sun4u)".

The mail didn't create a new ticket in RT, nor was it forwarded to the 
dev list.

Should I resend or simply be more patient?

Thanks and regards,

Rainer

From rsalz at akamai.com  Tue Feb 10 19:30:45 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Feb 2015 19:30:45 +0000
Subject: [openssl-dev] [openssl.org #3695] DTLS Handshake
	issue	(openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash
In-Reply-To: <rt-4.0.4-6847-1423595798-1360.3695-21-0@openssl.org>
References: <RT-Ticket-3695@openssl.org>
 <CAGgXGhKMSAzS+AuNDgNML7rATit1e-HX5PE2bct+zsa5A+o0gQ@mail.gmail.com>
 <rt-4.0.4-6847-1423595798-1360.3695-21-0@openssl.org>
Message-ID: <0129fae0e28844c39b2a9aa9510ca04b@ustx2ex-dag1mb2.msg.corp.akamai.com>

Matt tried to explain this before.

1.0.1e-30 is not a version that OpenSSL provides.  You will have to contact your vendor.

The backtrace information is not usable as there are no function names; you will have to build a debugging version.

We cannot help you.
--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz

From rt at openssl.org  Tue Feb 10 19:41:20 2015
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 10 Feb 2015 20:41:20 +0100
Subject: [openssl-dev] [openssl.org #3695] DTLS Handshake issue
	(openssl-1.0.1e-dtls-ecc-ext.patch) leads to process crash
In-Reply-To: <0129fae0e28844c39b2a9aa9510ca04b@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3695@openssl.org>
 <CAGgXGhKMSAzS+AuNDgNML7rATit1e-HX5PE2bct+zsa5A+o0gQ@mail.gmail.com>
 <rt-4.0.4-6847-1423595798-1360.3695-21-0@openssl.org>
 <0129fae0e28844c39b2a9aa9510ca04b@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <rt-4.0.4-18061-1423597280-142.3695-6-0@openssl.org>

Matt tried to explain this before.

1.0.1e-30 is not a version that OpenSSL provides.  You will have to contact your vendor.

The backtrace information is not usable as there are no function names; you will have to build a debugging version.

We cannot help you.
--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz



From matt at openssl.org  Tue Feb 10 20:30:50 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 10 Feb 2015 20:30:50 +0000
Subject: [openssl-dev] Submitting new bugs to rt via mail broken?
In-Reply-To: <54DA5AC1.7000306@kippdata.de>
References: <54DA5AC1.7000306@kippdata.de>
Message-ID: <54DA6A7A.9060106@openssl.org>



On 10/02/15 19:23, Rainer Jung wrote:
> Hello everyone,
> 
> I sent a mail to rt at openssl.org 3 days ago, subject "OpenSSL 1.0.2 "make
> test" bus error in evp_test (Solaris 10 Sparc, sun4u)".
> 
> The mail didn't create a new ticket in RT, nor was it forwarded to the
> dev list.
> 
> Should I resend or simply be more patient?

Email to rt is manually moderated by Lutz. Sometimes it can take a few
days to come through. Very occasionally a genuine email gets lost within
the swamp of spam. I would be a little more patient, but if it doesn't
arrive in a couple more days then try again.

Matt


From rsalz at akamai.com  Tue Feb 10 21:15:36 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Feb 2015 21:15:36 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
Message-ID: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>

I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2

Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW

Anything that was 40-bit encryption is removed:
/* Cipher 03 "EXP-RC4-MD5" removed */
/* Cipher 06 "EXP-RC2-CBC-MD5" removed */
/* Cipher 08 "EXP-DES-CBC-SHA" removed */
/* Cipher 0B "EXP-DH-DSS-DES-CBC-SHA" removed */
/* Cipher 0E "EXP-DH-RSA-DES-CBC-SHA" removed */
/* Cipher 11 "EXP-DHE-DSS-DES-CBC-SHA" removed */
/* Cipher 14 "EXP-DHE-RSA-DES-CBC-SHA" removed */
/* Cipher 17 "EXP-ADH-RC4-MD5" removed */
/* Cipher 19 "EXP-ADH-DES-CBC-SHA" removed */
/* Cipher 26 "EXP-KRB5-DES-CBC-SHA" removed */
/* Cipher 27 "EXP-KRB5-RC2-CBC-SHA" removed */
/* Cipher 28 "EXP-KRB5-RC4-SHA" removed */
/* Cipher 29 "EXP-KRB5-DES-CBC-MD5" removed */
/* Cipher 2A "EXP-KRB5-RC2-CBC-MD5" removed */
/* Cipher 2B "EXP-KRB5-RC4-MD5" removed */

The value of DEFAULT changes to this:
                ALL:!LOW:!EXPORT:!aNULL:!eNULL

The combination of the first and last changes means that anyone who wants or needs to use, say RC4 must explicitly say so.

Comments?

--
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me<mailto:rsalz at jabber.me> Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150210/d5e52303/attachment.html>

From hanno at hboeck.de  Tue Feb 10 21:38:01 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 10 Feb 2015 22:38:01 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150210223801.184d8688@pc>

On Tue, 10 Feb 2015 21:15:36 +0000
"Salz, Rich" <rsalz at akamai.com> wrote:

> Comments?

Sounds good.

I'd further suggest to move everything that's not PFS&AEAD
from HIGH to MEDIUM.


-- 
Hanno B?ck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150210/e5ac0ae1/attachment-0001.sig>

From openssl-users at dukhovni.org  Tue Feb 10 21:46:46 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 10 Feb 2015 21:46:46 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150210214646.GB12867@mournblade.imrryr.org>

On Tue, Feb 10, 2015 at 09:15:36PM +0000, Salz, Rich wrote:

> I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2
> 
> Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW

Note, that RC4 is already the only commonly used cipher-suite in MEDIUM.

Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
compatibility issues for opportunistic TLS (e.g. Postfix) where
RC4 is still required for interop and is better than cleartext.

I have no issues with changing "DEFAULT", but would strongly prefer
to not see RC4 demoted to LOW.  Just define:

    DEFAULT = ALL:!aNULL:!EXPORT:!LOW:!RC4:!MD5

Which leaves from MEDIUM just SEED and IDEA:

    $ openssl ciphers -v 'MEDIUM:!aNULL:!MD5:!RC4'
    DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
    DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
    DH-RSA-SEED-SHA         SSLv3 Kx=DH/RSA   Au=DH   Enc=SEED(128) Mac=SHA1
    DH-DSS-SEED-SHA         SSLv3 Kx=DH/DSS   Au=DH   Enc=SEED(128) Mac=SHA1
    SEED-SHA                SSLv3 Kx=RSA      Au=RSA  Enc=SEED(128) Mac=SHA1
    IDEA-CBC-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=SHA1

--
	Viktor.

From rsalz at akamai.com  Tue Feb 10 22:52:02 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 10 Feb 2015 22:52:02 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150210223801.184d8688@pc>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
Message-ID: <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Sounds good.

Thanks.
 
> I'd further suggest to move everything that's not PFS&AEAD from HIGH to
> MEDIUM.

I think it's a little early to do that.  But once TLS 1.3 is out, then yes :)

From brian at briansmith.org  Tue Feb 10 22:55:55 2015
From: brian at briansmith.org (Brian Smith)
Date: Tue, 10 Feb 2015 14:55:55 -0800
Subject: [openssl-dev] Seeking feedback on some #ifdef changes
In-Reply-To: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com>
References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAFewVt4=R1Jq-XLs0tEZEVJRy2M2xwC-Sgzur86osGVU4NJa=g@mail.gmail.com>

Salz, Rich <rsalz at akamai.com> wrote:
>         OPENSSL_NO_CHAIN_VERIFY
>         OPENSSL_NO_RFC3779
>         OPENSSL_NO_TLS
>         OPENSSL_NO_TLS1
>         OPENSSL_NO_TLS1_2_CLIENT
>         OPENSSL_NO_TLSEXT
>         OPENSSL_NO_X509
>         OPENSSL_NO_X509_VERIFY

Please continue to make it possible to build the crypto part of
OpenSSL, without the X.509 and SSL/TLS code. There are lots of uses of
OpenSSL that don't need that code.

Actually, I'd prefer if it were possible to build without any of the
ASN.1 code too, but I understand that is messy because the EVP
interface assumes the ASN.1 parser is available. But, building without
X.509 and SSl/TLS support should be easy to continue to support.

Cheers,
Brian

From matt at openssl.org  Tue Feb 10 23:01:31 2015
From: matt at openssl.org (Matt Caswell)
Date: Tue, 10 Feb 2015 23:01:31 +0000
Subject: [openssl-dev] The evolution of the 'master' branch
In-Reply-To: <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
Message-ID: <54DA8DCB.7090202@openssl.org>



On 07/02/15 14:41, Richard Moore wrote:
> 
> 
> On 3 February 2015 at 22:02, Rich Salz <rsalz at openssl.org
> <mailto:rsalz at openssl.org>> wrote:
> 
>     As we've already said, we are moving to making most OpenSSL data
>     structures opaque. We deliberately used a non-specific term. :)
>     As of Matt's commit of the other day, this is starting to happen
>     now.  We know this will inconvenience people as some applications
>     no longer build.  We want to work with maintainers to help them
>     migrate, as we head down this path.
> 
>     We have a wiki page to discuss this effort.  It will eventually include
>     tips on migration, application and code updates, and anything else the
>     community finds useful.  Please visit:
> 
>             http://wiki.openssl.org/index.php/1.1_API_Changes
> 
> 
> I've documented what got broken in Qt by the changes so far. I've listed
> the functions I think we can use instead where they exist, and those
> where there does not appear to be a replacement.

On the wiki you wrote:
"session->tlsext_tick_lifetime_hint - we were directly accessing the
lifetime hint of the session."

I have just pushed (along with some associated documentation) some new
ticket API functions, which should cover the above gap:

int SSL_SESSION_has_ticket(const SSL_SESSION *s);
unsigned long SSL_SESSION_get_ticket_lifetime_hint(const SSL_SESSION *s);
void SSL_SESSION_get0_ticket(const SSL_SESSION *s, unsigned char **tick,
                             size_t *len);


Matt


From openssl-users at dukhovni.org  Tue Feb 10 23:13:36 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 10 Feb 2015 23:13:36 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150210223801.184d8688@pc>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
Message-ID: <20150210231336.GC12867@mournblade.imrryr.org>

On Tue, Feb 10, 2015 at 10:38:01PM +0100, Hanno B?ck wrote:

> On Tue, 10 Feb 2015 21:15:36 +0000
> "Salz, Rich" <rsalz at akamai.com> wrote:
> 
> > Comments?
> 
> Sounds good.
> 
> I'd further suggest to move everything that's not PFS&AEAD
> from HIGH to MEDIUM.

Thus breaking applications that were previously using HIGH as a
reasonably interoperable setting.

You can introduce all kinds of new settings, promote their use,
even change the default, but incompatibly re-definining existing
interfaces is not a winning strategy.

-- 
	Viktor.

From dkg at fifthhorseman.net  Tue Feb 10 23:17:38 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 10 Feb 2015 18:17:38 -0500
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <87bnl1qru5.fsf@alice.fifthhorseman.net>

On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote:
> I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2
>
> Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW

yes, please!

> Anything that was 40-bit encryption is removed:
> /* Cipher 03 "EXP-RC4-MD5" removed */
> /* Cipher 06 "EXP-RC2-CBC-MD5" removed */
> /* Cipher 08 "EXP-DES-CBC-SHA" removed */
> /* Cipher 0B "EXP-DH-DSS-DES-CBC-SHA" removed */
> /* Cipher 0E "EXP-DH-RSA-DES-CBC-SHA" removed */
> /* Cipher 11 "EXP-DHE-DSS-DES-CBC-SHA" removed */
> /* Cipher 14 "EXP-DHE-RSA-DES-CBC-SHA" removed */
> /* Cipher 17 "EXP-ADH-RC4-MD5" removed */
> /* Cipher 19 "EXP-ADH-DES-CBC-SHA" removed */
> /* Cipher 26 "EXP-KRB5-DES-CBC-SHA" removed */
> /* Cipher 27 "EXP-KRB5-RC2-CBC-SHA" removed */
> /* Cipher 28 "EXP-KRB5-RC4-SHA" removed */
> /* Cipher 29 "EXP-KRB5-DES-CBC-MD5" removed */
> /* Cipher 2A "EXP-KRB5-RC2-CBC-MD5" removed */
> /* Cipher 2B "EXP-KRB5-RC4-MD5" removed */

when these are "removed", what will that do to a cipherstring that
specifies them by negation?

currently, this is an error:

0 dkg at alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
bash: !NO-SUCH-CIPHER: event not found
0 dkg at alice:~$ 

i wouldn't want ALL:!EXP-DHE-DSS-DES-CBC-SHA to be an error, though.

> The value of DEFAULT changes to this:
>                 ALL:!LOW:!EXPORT:!aNULL:!eNULL
>
> The combination of the first and last changes means that anyone who wants or needs to use, say RC4 must explicitly say so.

This looks good to me.

Hanno wrote:

>   I'd further suggest to move everything that's not PFS&AEAD from HIGH
>   to MEDIUM.

I agree with this as well.  It sets the stage for TLS 1.3.

Thanks for pushing on this, Rich.

       --dkg

From Gilles.Khouzam at microsoft.com  Tue Feb 10 23:15:37 2015
From: Gilles.Khouzam at microsoft.com (Gilles Khouzam)
Date: Tue, 10 Feb 2015 23:15:37 +0000
Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with
	FIPS	2.0.8 - fingerprint does not match
In-Reply-To: <rt-4.0.4-6847-1423595781-907.3694-21-0@openssl.org>
References: <RT-Ticket-3694@openssl.org>
 <D59C04F34BE3D1479A34815B4737AB230FCE6C96@6V-MBX2.CRESTRON.CRESTRON.com>
 <rt-4.0.4-6847-1423595781-907.3694-21-0@openssl.org>
Message-ID: <CY1PR0301MB071383DD867BBDACB065F95B98240@CY1PR0301MB0713.namprd03.prod.outlook.com>

Hi Lior,

One thing to try would be to try both ways of the define for __thumb. This can explain the fingerprint failure. 

In fips_canister.c around line 188

# if defined(__thumb__) || defined(__thumb)
    return (void *)((size_t)instruction_pointer&~1);
# else
    return (void *)instruction_pointer;
# endif

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Lior Gotian via RT
Sent: Tuesday, February 10, 2015 11:16
Cc: openssl-dev at openssl.org
Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with FIPS 2.0.8 - fingerprint does not match

I was successful at compiling the FIPS 2.0.8 module for Windows CE exactly as provided without any modifications.
Additionally, I built fips_algvs.exe to successfully validate the canister on the target system.

After tweaking some #ifdef directives in the openSSL 1.0.1L, I was able to get it to successfully build for WinCE.

The build appears to complete successfully.  However, at run-time, entering FIPS mode fails with an error messages:
FIPS_check_incore_fingerprint:fingerprint does not match

I have reviewed the build instructions carefully and believe all the build instructions have been adhered to.  What needs to be changed for the signature to be properly embedded?

Thank you for your assistance.

Best regards,
Lior Gotian



This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited.

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

From rt at openssl.org  Tue Feb 10 23:51:07 2015
From: rt at openssl.org (Gilles Khouzam via RT)
Date: Wed, 11 Feb 2015 00:51:07 +0100
Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with
	FIPS 2.0.8 - fingerprint does not match
In-Reply-To: <CY1PR0301MB071383DD867BBDACB065F95B98240@CY1PR0301MB0713.namprd03.prod.outlook.com>
References: <RT-Ticket-3694@openssl.org>
 <D59C04F34BE3D1479A34815B4737AB230FCE6C96@6V-MBX2.CRESTRON.CRESTRON.com>
 <rt-4.0.4-6847-1423595781-907.3694-21-0@openssl.org>
 <CY1PR0301MB071383DD867BBDACB065F95B98240@CY1PR0301MB0713.namprd03.prod.outlook.com>
Message-ID: <rt-4.0.4-26573-1423612266-1338.3694-6-0@openssl.org>

Hi Lior,

One thing to try would be to try both ways of the define for __thumb. This can explain the fingerprint failure. 

In fips_canister.c around line 188

# if defined(__thumb__) || defined(__thumb)
    return (void *)((size_t)instruction_pointer&~1);
# else
    return (void *)instruction_pointer;
# endif

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Lior Gotian via RT
Sent: Tuesday, February 10, 2015 11:16
Cc: openssl-dev at openssl.org
Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with FIPS 2.0.8 - fingerprint does not match

I was successful at compiling the FIPS 2.0.8 module for Windows CE exactly as provided without any modifications.
Additionally, I built fips_algvs.exe to successfully validate the canister on the target system.

After tweaking some #ifdef directives in the openSSL 1.0.1L, I was able to get it to successfully build for WinCE.

The build appears to complete successfully.  However, at run-time, entering FIPS mode fails with an error messages:
FIPS_check_incore_fingerprint:fingerprint does not match

I have reviewed the build instructions carefully and believe all the build instructions have been adhered to.  What needs to be changed for the signature to be properly embedded?

Thank you for your assistance.

Best regards,
Lior Gotian



This e-mail message and all attachments transmitted with it may contain legally privileged and confidential information intended solely for the use of the addressee. If you are not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, or other use of this message or its attachments is strictly prohibited.

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



From openssl-users at dukhovni.org  Tue Feb 10 23:52:04 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 10 Feb 2015 23:52:04 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150210235204.GE12867@mournblade.imrryr.org>

On Tue, Feb 10, 2015 at 10:52:02PM +0000, Salz, Rich wrote:

> > I'd further suggest to move everything that's not PFS&AEAD from HIGH to
> > MEDIUM.
> 
> I think it's a little early to do that.  But once TLS 1.3 is out, then yes :)

This is NOT a decision a library should be making on behalf of
applications.  So, NO, not even then, except that of course when
TLS 1.3 is negotiated, that's all you get, but that only happens
with TLS 1.3 peers, which is fine and does not break compatibility,
and does not require re-definition of the existing cipher-suite
classes.

We should also recall that the master branch has introduced "security
levels", which may still need some work to become production-ready,
but are likely a better mechanism for applications to move to more
secure settings than incompatible changes in existing interfaces.

Not all applications are browsers folks, and libraries need to
provide stable interfaces that mirror the application's intent
consistent with expected behaviour of existing interfaces.

Only new interfaces can freely shed compatibility baggage.

-- 
	Viktor.

From rsalz at akamai.com  Wed Feb 11 00:22:44 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 00:22:44 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <87bnl1qru5.fsf@alice.fifthhorseman.net>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
Message-ID: <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>


> currently, this is an error:
> 
> 0 dkg at alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
> bash: !NO-SUCH-CIPHER: event not found
> 0 dkg at alice:~$

Yeah, but that's coming from bash, not openssl :)
; openssl ciphers -v ALL | wc
    111     675    8403
; openssl ciphers -v ALL:!FOOBAR | wc
    111     675    8403

RC4 in LOW has a bit of pushback so far.  My cover for it is that the IETF says "don't use it."  So I think saying "if you want it, say so" is the way to go.

	/r$


From rsalz at akamai.com  Wed Feb 11 00:25:35 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 00:25:35 +0000
Subject: [openssl-dev] Seeking feedback on some #ifdef changes
In-Reply-To: <CAFewVt4=R1Jq-XLs0tEZEVJRy2M2xwC-Sgzur86osGVU4NJa=g@mail.gmail.com>
References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com>
 <CAFewVt4=R1Jq-XLs0tEZEVJRy2M2xwC-Sgzur86osGVU4NJa=g@mail.gmail.com>
Message-ID: <775c783c5fbe4855b5461ce51ad9b82e@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Please continue to make it possible to build the crypto part of OpenSSL,
> without the X.509 and SSL/TLS code. There are lots of uses of OpenSSL that
> don't need that code.

You can build crypto without ssl.  And the only place OPENSSL_NO_X509 appeared was, strangely, in ssl.  So crypto builds, which didn't really pay attention to OPENSLS_NO_x509 before, still don't.  :)

Hope this helps.


From openssl-users at dukhovni.org  Wed Feb 11 01:21:37 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 01:21:37 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <87bnl1qru5.fsf@alice.fifthhorseman.net>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
Message-ID: <20150211012137.GH12867@mournblade.imrryr.org>

On Tue, Feb 10, 2015 at 06:17:38PM -0500, Daniel Kahn Gillmor wrote:

> On Tue 2015-02-10 16:15:36 -0500, Salz, Rich wrote:
> > I would like to make the following changes in the cipher specs, in the master branch, which is planned for the next release after 1.0.2
> >
> > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
> 
> yes, please!

There are lots of ways to disable RC4:

    * You can do that in a browser, or any other application
    * The NCONF interface allows one to specify this in suitable
      configuration files.
    * Security levels can be similarly specified, ...
    * TLS 1.3 will not support RC4, ...

However, OpenSSL MUST NOT force this choice on applications or
require them to be explicitly modified to continue to support RC4.
It is NOT the library's job to set this policy.

> when these are "removed", what will that do to a cipherstring that
> specifies them by negation?
> 
> currently, this is an error:
> 
> 0 dkg at alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
> bash: !NO-SUCH-CIPHER: event not found

PBKAC:

    $ openssl ciphers -v 'RC4:!FOOBARXYZZY'
    ECDHE-RSA-RC4-SHA       SSLv3 Kx=ECDH     Au=RSA  Enc=RC4(128)  Mac=SHA1
    ECDHE-ECDSA-RC4-SHA     SSLv3 Kx=ECDH     Au=ECDSA Enc=RC4(128)  Mac=SHA1
    AECDH-RC4-SHA           SSLv3 Kx=ECDH     Au=None Enc=RC4(128)  Mac=SHA1
    ADH-RC4-MD5             SSLv3 Kx=DH       Au=None Enc=RC4(128)  Mac=MD5
    ECDH-RSA-RC4-SHA        SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128)  Mac=SHA1
    ECDH-ECDSA-RC4-SHA      SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128)  Mac=SHA1
    RC4-SHA                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=SHA1
    RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
    RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
    PSK-RC4-SHA             SSLv3 Kx=PSK      Au=PSK  Enc=RC4(128)  Mac=SHA1
    EXP-ADH-RC4-MD5         SSLv3 Kx=DH(512)  Au=None Enc=RC4(40)   Mac=MD5  export
    EXP-RC4-MD5             SSLv3 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export
    EXP-RC4-MD5             SSLv2 Kx=RSA(512) Au=RSA  Enc=RC4(40)   Mac=MD5  export

-- 
	Viktor.

From openssl-users at dukhovni.org  Wed Feb 11 02:00:50 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 02:00:50 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211020050.GI12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 12:22:44AM +0000, Salz, Rich wrote:

> RC4 in LOW has a bit of pushback so far.  My cover for it is that
> the IETF says "don't use it."  So I think saying "if you want it,
> say so" is the way to go.

By all means, don't use it, but it is not OpenSSL's choice to make
by breaking the meaning of existing interfaces.

If you put RC4 in LOW, one can no longer exclude LOW ciphers if
one still needs RC4.  Nobody uses single-DES, but enough peers
still use (only) RC4 to make disabling of RC4 a choice best made
by applications.

-- 
	Viktor.

From rsalz at akamai.com  Wed Feb 11 03:30:57 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 03:30:57 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150211020050.GI12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
Message-ID: <a396c0b540bc4af9a23eefdbc451550f@ustx2ex-dag1mb2.msg.corp.akamai.com>


> By all means, don't use it, but it is not OpenSSL's choice to make by breaking
> the meaning of existing interfaces.

Except that we've explicitly stated we're breaking things with this new release.

Those magic cipher keywords are point-in-time statements.  And time has moved on.

From rsalz at akamai.com  Wed Feb 11 03:33:03 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 03:33:03 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150210235204.GE12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
Message-ID: <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>


> Not all applications are browsers folks, and libraries need to provide stable
> interfaces that mirror the application's intent consistent with expected
> behaviour of existing interfaces.

Please point to where it is documented what the value of MEDIUM means and what interface is being broken?

I can't find anywhere that it says RC4 is by definition part of MEDIUM.

	/r$



From openssl-users at dukhovni.org  Wed Feb 11 03:49:53 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 03:49:53 +0000
Subject: [openssl-dev] [openssl-users] Proposed cipher changes for
 post-1.0.2
In-Reply-To: <a396c0b540bc4af9a23eefdbc451550f@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <a396c0b540bc4af9a23eefdbc451550f@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211034953.GP12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 03:30:57AM +0000, Salz, Rich wrote:

> > By all means, don't use it, but it is not OpenSSL's choice to make by breaking
> > the meaning of existing interfaces.
> 
> Except that we've explicitly stated we're breaking things with this new release.
> 
> Those magic cipher keywords are point-in-time statements.  And time has moved on.

Those categories had and continue to have sensible definitions to
which the proposed changes would do unwarranted violence.

It is OK to drop EXPORT ciphers entirely.  It is OK to drop LOW
ciphers entirely.  Nobody is using either.

The deprecation of RC4 is still aspirational, and reclassifying it
as LOW breaks configurations where it is still needed.

It is largely sufficient to drop RC4 from the "DEFAULT" cipherlist,
leaving applications that make more fine-grained choices to make
their own RC4 decisions.

The DEFAULT cipherlist is a point-in-time definition, but EXPORT,
LOW, MEDIUM and HIGH have more precise expected semantics.

Libraries should only break compatibility when there is no choice.
Here there are many alternatives.  Including the "security level"
features already in the master release, which address the issue
more systematically.  This, plus further work on documenting NCONF,
publishing reasonably complete best-practice sample client and
server programs will do a lot more good than needlessly breaking
non-browser opportunistic TLS applications.

-- 
	Viktor.

From brian at briansmith.org  Wed Feb 11 04:39:33 2015
From: brian at briansmith.org (Brian Smith)
Date: Tue, 10 Feb 2015 20:39:33 -0800
Subject: [openssl-dev] Seeking feedback on some #ifdef changes
In-Reply-To: <775c783c5fbe4855b5461ce51ad9b82e@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com>
 <CAFewVt4=R1Jq-XLs0tEZEVJRy2M2xwC-Sgzur86osGVU4NJa=g@mail.gmail.com>
 <775c783c5fbe4855b5461ce51ad9b82e@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <CAFewVt4un=khEOA9rQLYqJRhwtH9thKs_rmAxp7+QiYtZrMB1Q@mail.gmail.com>

On Tue, Feb 10, 2015 at 4:25 PM, Salz, Rich <rsalz at akamai.com> wrote:
>
>> Please continue to make it possible to build the crypto part of OpenSSL,
>> without the X.509 and SSL/TLS code. There are lots of uses of OpenSSL that
>> don't need that code.
>
> You can build crypto without ssl.  And the only place OPENSSL_NO_X509 appeared was, strangely, in ssl.  So crypto builds, which didn't really pay attention to OPENSLS_NO_x509 before, still don't.  :)

The X.509 code is in crypto, though.

Also, when I've had a use for libssl, I've usually wanted to use an
X.509 library other than OpenSSL's, for a variety of reasons. It would
be useful to remove all of libssl's dependencies on the X.509 code
during the time that the other compatibility-breaking changes are
being made.

Cheers,
Brian

From openssl-users at dukhovni.org  Wed Feb 11 06:11:08 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 06:11:08 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211061108.GQ12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 03:33:03AM +0000, Salz, Rich wrote:
> 
> > Not all applications are browsers folks, and libraries need to provide stable
> > interfaces that mirror the application's intent consistent with expected
> > behaviour of existing interfaces.
> 
> Please point to where it is documented what the value of MEDIUM means and what interface is being broken?

The ciphers(1) manpage has set consistent expectations since the
dawn of time (same meaning in 0.9.7, 0.9.8, 1.0.0 and 1.0.1):

       HIGH
           "high" encryption cipher suites. This currently means those with key lengths larger than 128 bits, and some
           cipher suites with 128-bit keys.

       MEDIUM
           "medium" encryption cipher suites, currently some of those using 128 bit encryption.

       LOW "low" encryption cipher suites, currently those using 64 or 56 bit encryption algorithms but excluding export
           cipher suites.

       EXP, EXPORT
           export encryption algorithms. Including 40 and 56 bits algorithms.

       EXPORT40
           40 bit export encryption algorithms

       EXPORT56
           56 bit export encryption algorithms. In OpenSSL 0.9.8c and later the set of 56 bit export ciphers is empty
           unless OpenSSL has been explicitly configured with support for experimental ciphers.

Those "currently's" have meant the same thing for a decade and a
half, the only change being a relaxation of HIGH to include AES128
in 2005 which introduces no interop issues.

    1.0.0 and later:

	commit 61094cf3dc1cc0086f8bcb70f73cc5822a53b2be
	Author: Dr. Stephen Henson <steve at openssl.org>
	Date:   Wed Sep 21 00:55:42 2005 +0000

	    128 bit AES ciphersuites should be classified as HIGH.

    0.9.8 backport:

	commit daa657fb78b517ebcddeef09e17e8a20624ac314
	Author: Dr. Stephen Henson <steve at openssl.org>
	Date:   Wed Sep 21 00:57:28 2005 +0000

    0.9.7 backport:

	commit 9f03d028e75c9376b3e4908dc666a8e75e03af61
	Author: Dr. Stephen Henson <steve at openssl.org>
	Date:   Wed Sep 21 00:58:48 2005 +0000

I think these definitions should stay the same, but I have no
objection to disabling RC4 in DEFAULT, or entirely removing
EXPORT/LOW.

-- 
	Viktor.

From openssl-users at dukhovni.org  Wed Feb 11 06:38:00 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 06:38:00 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150211061108.GQ12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
Message-ID: <20150211063759.GS12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 06:11:08AM +0000, Viktor Dukhovni wrote:

> I think these definitions should stay the same, but I have no
> objection to disabling RC4 in DEFAULT, or entirely removing
> EXPORT/LOW.

And also MD5 (which subsumes all SSLv2 cipher-suites).

Note that for most applications the correct approach to configuring
ciphersuites should be to start with DEFAULT and subtract what they
don't want.  The library is then responsible for a generally sensible
default order and default exclusions.

For example, the below yields a compact list of cipher-suites with
little legacy baggage:

    DEFAULT:!EXPORT:!LOW:!MD5:!RC4:!SRP:!PSK:!aDSS:!aDH:!SEED:!IDEA:!kECDHr:!kECDHe

A variant with RC4-SHA as a last resort would be:

    DEFAULT:!EXPORT:!LOW:!MD5:!SRP:!PSK:!aDSS:!aDH:!SEED:!IDEA:!kECDHr:!kECDHe:+RC4

-- 
	Viktor.

From dkg at fifthhorseman.net  Wed Feb 11 06:50:07 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 11 Feb 2015 01:50:07 -0500
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <87twytosbk.fsf@alice.fifthhorseman.net>

On Tue 2015-02-10 19:22:44 -0500, Salz, Rich wrote:
>> currently, this is an error:
>> 
>> 0 dkg at alice:~$ openssl ciphers -v ALL:!NO-SUCH-CIPHER
>> bash: !NO-SUCH-CIPHER: event not found
>> 0 dkg at alice:~$
>
> Yeah, but that's coming from bash, not openssl :)
> ; openssl ciphers -v ALL | wc
>     111     675    8403
> ; openssl ciphers -v ALL:!FOOBAR | wc
>     111     675    8403

d'oh!  of course, thanks. <headdesks>

> RC4 in LOW has a bit of pushback so far.  My cover for it is that the IETF says "don't use it."  So I think saying "if you want it, say so" is the way to go.

I think that's the correct position.  People who want to be able to
negotiate a deprecated cipher should need to explicitly state that
that's their intent.

  --dkg

From openssl-users at dukhovni.org  Wed Feb 11 07:13:46 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 07:13:46 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <87twytosbk.fsf@alice.fifthhorseman.net>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87twytosbk.fsf@alice.fifthhorseman.net>
Message-ID: <20150211071345.GT12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 01:50:07AM -0500, Daniel Kahn Gillmor wrote:

> > RC4 in LOW has a bit of pushback so far.  My cover for it is that the
> > IETF says "don't use it."  So I think saying "if you want it, say so" is
> > the way to go.
> 
> I think that's the correct position.  People who want to be able to
> negotiate a deprecated cipher should need to explicitly state that
> that's their intent.

I do:

	aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH

The proposal to now misclassify RC4 as LOW (lumped in with single
DES and similar) needlessly breaks this.

--
	Viktor.

From richard at levitte.org  Wed Feb 11 11:37:00 2015
From: richard at levitte.org (Richard Levitte)
Date: Wed, 11 Feb 2015 12:37:00 +0100 (CET)
Subject: [openssl-dev] Seeking feedback on some #ifdef changes
In-Reply-To: <775c783c5fbe4855b5461ce51ad9b82e@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <86f2e98515634754b9236972841d3db2@usma1ex-dag1mb2.msg.corp.akamai.com>
 <CAFewVt4=R1Jq-XLs0tEZEVJRy2M2xwC-Sgzur86osGVU4NJa=g@mail.gmail.com>
 <775c783c5fbe4855b5461ce51ad9b82e@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211.123700.841614895056516719.richard@levitte.org>

In message <775c783c5fbe4855b5461ce51ad9b82e at ustx2ex-dag1mb2.msg.corp.akamai.com> on Wed, 11 Feb 2015 00:25:35 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> 
rsalz> > Please continue to make it possible to build the crypto part of OpenSSL,
rsalz> > without the X.509 and SSL/TLS code. There are lots of uses of OpenSSL that
rsalz> > don't need that code.
rsalz> 
rsalz> You can build crypto without ssl.  And the only place OPENSSL_NO_X509 appeared was, strangely, in ssl.  So crypto builds, which didn't really pay attention to OPENSLS_NO_x509 before, still don't.  :)

But it will pay attention to './config no-x509 no-x509v3', since that
will remove the directories x509 and x509v3 from SDIRS.  That still
stands.

Cheers,
Richard

-- 
Richard Levitte                         richard at levitte.org
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish

From hkario at redhat.com  Wed Feb 11 11:59:22 2015
From: hkario at redhat.com (Hubert Kario)
Date: Wed, 11 Feb 2015 12:59:22 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150210214646.GB12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210214646.GB12867@mournblade.imrryr.org>
Message-ID: <1672004.gQCVnt9D6P@pintsize.usersys.redhat.com>

On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote:
> On Tue, Feb 10, 2015 at 09:15:36PM +0000, Salz, Rich wrote:
> > I would like to make the following changes in the cipher specs, in the
> > master branch, which is planned for the next release after 1.0.2
> > 
> > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
> 
> Note, that RC4 is already the only commonly used cipher-suite in MEDIUM.
> 
> Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
> compatibility issues for opportunistic TLS (e.g. Postfix) where
> RC4 is still required for interop and is better than cleartext.

Opportunistic TLS is a-typical use of TLS. One that is vulnerable to trivial 
MitM attacks by the very definition. Using "ALL", possibly "ALL:!aNULL", 
instead of "DEFAULT" doesn't make it much less secure.

-- 
Regards,
Hubert Kario

From hkario at redhat.com  Wed Feb 11 12:01:14 2015
From: hkario at redhat.com (Hubert Kario)
Date: Wed, 11 Feb 2015 13:01:14 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <3043055.sERXNt3CE5@pintsize.usersys.redhat.com>

On Tuesday 10 February 2015 21:15:36 Salz, Rich wrote:
> I would like to make the following changes in the cipher specs, in the
> master branch, which is planned for the next release after 1.0.2
> 
> Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
> 
> Anything that was 40-bit encryption is removed:
> /* Cipher 03 "EXP-RC4-MD5" removed */
> /* Cipher 06 "EXP-RC2-CBC-MD5" removed */
> /* Cipher 08 "EXP-DES-CBC-SHA" removed */
> /* Cipher 0B "EXP-DH-DSS-DES-CBC-SHA" removed */
> /* Cipher 0E "EXP-DH-RSA-DES-CBC-SHA" removed */
> /* Cipher 11 "EXP-DHE-DSS-DES-CBC-SHA" removed */
> /* Cipher 14 "EXP-DHE-RSA-DES-CBC-SHA" removed */
> /* Cipher 17 "EXP-ADH-RC4-MD5" removed */
> /* Cipher 19 "EXP-ADH-DES-CBC-SHA" removed */
> /* Cipher 26 "EXP-KRB5-DES-CBC-SHA" removed */
> /* Cipher 27 "EXP-KRB5-RC2-CBC-SHA" removed */
> /* Cipher 28 "EXP-KRB5-RC4-SHA" removed */
> /* Cipher 29 "EXP-KRB5-DES-CBC-MD5" removed */
> /* Cipher 2A "EXP-KRB5-RC2-CBC-MD5" removed */
> /* Cipher 2B "EXP-KRB5-RC4-MD5" removed */
> 
> The value of DEFAULT changes to this:
>                 ALL:!LOW:!EXPORT:!aNULL:!eNULL
> 
> The combination of the first and last changes means that anyone who wants or
> needs to use, say RC4 must explicitly say so.
> 
> Comments?

Maybe we should also move 3DES to MEDIUM? Given that this is effectively a 112 
bit cipher...

Also, what about changing order so that 128bit+ AEAD and PFS are preferred 
over other ciphers (including 256 bit ones)?

-- 
Regards,
Hubert Kario

From hkario at redhat.com  Wed Feb 11 12:10:48 2015
From: hkario at redhat.com (Hubert Kario)
Date: Wed, 11 Feb 2015 13:10:48 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150211020050.GI12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
Message-ID: <7396890.6xcG6KhT9Y@pintsize.usersys.redhat.com>

On Wednesday 11 February 2015 02:00:50 Viktor Dukhovni wrote:
> On Wed, Feb 11, 2015 at 12:22:44AM +0000, Salz, Rich wrote:
> > RC4 in LOW has a bit of pushback so far.  My cover for it is that
> > the IETF says "don't use it."  So I think saying "if you want it,
> > say so" is the way to go.
> 
> By all means, don't use it, but it is not OpenSSL's choice to make
> by breaking the meaning of existing interfaces.
> 
> If you put RC4 in LOW, one can no longer exclude LOW ciphers if
> one still needs RC4.  Nobody uses single-DES, but enough peers
> still use (only) RC4 to make disabling of RC4 a choice best made
> by applications.

if you upgrade to a new minor version of library and don't check configuration 
afterwards you're part of the problem

example? "ALL:!ADH" and variations of thereof


It *IS* the libraries duty to update the policies. Changing policies in the 
hundreds of applications that use it every time a cipher or protocol is broken 
is insanity.

All the keyword definitions in ciphers(1) use the word "currently".
-- 
Regards,
Hubert Kario

From kannanar at cisco.com  Wed Feb 11 12:21:58 2015
From: kannanar at cisco.com (Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco))
Date: Wed, 11 Feb 2015 12:21:58 +0000
Subject: [openssl-dev] Nesses shows poodle
Message-ID: <AF70C7F70D95C54BAF2FCD161BADF2EB2210BB6A@xmb-aln-x13.cisco.com>

Hi,

We have disabled -SSLv3 in httpd.conf file(Apache integrated with Openssl). The poodle.sh script shows not-vulnerable. But the nesses scan report still shows as vulnerable. Can you one suggest this is correct behavior or anything need to update in OS(Using Linux)

Thanks,
Kannan Narayanasamy.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150211/103dc8df/attachment.html>

From steve at openssl.org  Wed Feb 11 13:41:16 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 11 Feb 2015 13:41:16 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150210235204.GE12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
Message-ID: <20150211134116.GA19156@openssl.org>

On Tue, Feb 10, 2015, Viktor Dukhovni wrote:

> 
> We should also recall that the master branch has introduced "security
> levels", which may still need some work to become production-ready,
> but are likely a better mechanism for applications to move to more
> secure settings than incompatible changes in existing interfaces.
> 

I'd agree that the best approach is to use security levels. This covers
a far wider set of parameters than just ciphersuites.

For example on the master branch the default security level is 1:

           The security level corresponds to a minimum of 80 bits of security.
           Any parameters offering below 80 bits of security are excluded. As
           a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys
           shorter than 160 bits are prohibited. All export ciphersuites are
           prohibited since they all offer less than 80 bits of security. SSL
           version 2 is prohibited. Any ciphersuite using MD5 for the MAC is
           also prohibited.

This happens no matter what the cipher string is set to (unless it forcibly
lowers the security level). So an application setting ALL will get the
above conditions.

In the light of poodle this could be ammended to make SSLv3 disabled at level
1 or above.

Currently level 1 is the only real general purpose default (due to widespread
use of SHA1 in certificates which offer less than 80 bits of security).

The levels could be extended so there is more than one usable level.

Security levels can currently only completely disable ciphersuites: this
could be extended so they can prioritise them instead. For example that
would allow the use of PFS+AEAD ciphersuites first, PFS not AEAD second
and as a last resort RC4 at some levels.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From hanno at hboeck.de  Wed Feb 11 14:24:23 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Wed, 11 Feb 2015 15:24:23 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <3043055.sERXNt3CE5@pintsize.usersys.redhat.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <3043055.sERXNt3CE5@pintsize.usersys.redhat.com>
Message-ID: <20150211152423.2094cae2@pc>

On Wed, 11 Feb 2015 13:01:14 +0100
Hubert Kario <hkario at redhat.com> wrote:

> Also, what about changing order so that 128bit+ AEAD and PFS are
> preferred over other ciphers (including 256 bit ones)?

I sent in a patch for exactly that a while ago.
Unfortunately I got zero feedback...

https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html

-- 
Hanno B?ck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150211/b6f09c95/attachment.sig>

From richmoore44 at gmail.com  Wed Feb 11 14:40:18 2015
From: richmoore44 at gmail.com (Richard Moore)
Date: Wed, 11 Feb 2015 14:40:18 +0000
Subject: [openssl-dev] The evolution of the 'master' branch
In-Reply-To: <54DA8DCB.7090202@openssl.org>
References: <20150203220231.GA12587@openssl.org>
 <CAMp7mVvG5N_NLAqXjnyYXp8QwLSQwXD820D0SziJLUXZHdWN4Q@mail.gmail.com>
 <54DA8DCB.7090202@openssl.org>
Message-ID: <CAMp7mVvwvgO0dk1-7k69PPEo-aDEXyEM10w4E6wDNmb-GChC3w@mail.gmail.com>

On 10 February 2015 at 23:01, Matt Caswell <matt at openssl.org> wrote:

> On the wiki you wrote:
> "session->tlsext_tick_lifetime_hint - we were directly accessing the
> lifetime hint of the session."
>
> I have just pushed (along with some associated documentation) some new
> ticket API functions, which should cover the above gap:
>
> int SSL_SESSION_has_ticket(const SSL_SESSION *s);
> unsigned long SSL_SESSION_get_ticket_lifetime_hint(const SSL_SESSION *s);
> void SSL_SESSION_get0_ticket(const SSL_SESSION *s, unsigned char **tick,
>                              size_t *len);
>
>
Great - I'll port the code to use those when building against 1.1 then with
the fixes I've already made Qt dev branch should build fine against the
current master. I've also updated the wiki to note what got broken in curl
and wget BTW (only one breakage in each AFAIK).

Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150211/1ddbef83/attachment.html>

From hanno at hboeck.de  Wed Feb 11 14:47:57 2015
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Wed, 11 Feb 2015 15:47:57 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150210214646.GB12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210214646.GB12867@mournblade.imrryr.org>
Message-ID: <20150211154757.7f39f45f@pc>

Hi,

On Tue, 10 Feb 2015 21:46:46 +0000
Viktor Dukhovni <openssl-users at dukhovni.org> wrote:

> Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
> compatibility issues for opportunistic TLS (e.g. Postfix) where
> RC4 is still required for interop and is better than cleartext.

Let me add some infos that may change the picture of RC4.

From what I understand we talk about the next openssl version, which is
likely still many months away. Until then a couple of things will
likely happen:
* The IETF has a draft to deprecate and explicitely forbid RC4 which
  will probably be an RFC by that time [1]
* There are two yet unpublished new attacks on RC4 where only
  preliminary info is available [2] [3]

So by the time openssl 1.0.3 or 1.1.0 or whatever it'll be called will
be released we'll likely have an official document stating that using
RC4 violates the standard. And we'll probably have more attacks (of
course this point is a bit speculative, because they are unpublished
yet).

If anyone uses an RC4 only configuration then you should tell them to
stop doing so. Now.


Another thing people may find interesting: Chromium recently started to
declare everything not PFS/AEAD as obsolete crypto. I like that and I
hope Google (and others) will do more steps in that direction. Maybe
that'll also change the picture on what should be considered "HIGH".

The CBC modes are currently in a state that could be described at
"there are some attacks, they're not really that practical and we have
some mitigations in place". That's not super-worrying, but it's
really not the thing I'd call a "HIGH" security cipher.

[1] https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-01
[2] https://i.imgur.com/0myz7Zm.jpg
[3]
https://www.blackhat.com/asia-15/briefings.html#bar-mitzva-attack-breaking-ssl-with-13-year-old-rc4-weakness

cu,
-- 
Hanno B?ck
http://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150211/177dc206/attachment.sig>

From rsalz at akamai.com  Wed Feb 11 15:15:11 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 15:15:11 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150211063759.GS12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
Message-ID: <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>

> Note that for most applications the correct approach to configuring
> ciphersuites should be to start with DEFAULT and subtract what they don't
> want.  The library is then responsible for a generally sensible default order
> and default exclusions.

I strongly disagree.  Most applications should explicitly list the ciphers they DO want.  That is the only way an application can be sure of what it is getting, without consulting external parties or configuration.  Otherwise, when the next Crime or Poodle or NameOfTheWeek comes out, you have no idea if you are vulnerable or not unless you look at something like the OpenSSL source code.

For what it's worth, I believe that "security levels" make this problem much worse. 

	/r$


From rsalz at akamai.com  Wed Feb 11 15:16:54 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 15:16:54 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150211063759.GS12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
Message-ID: <ba50266056554719911a1f9a23d0b0e7@ustx2ex-dag1mb2.msg.corp.akamai.com>

> I think these definitions should stay the same, but I have no
> objection to disabling RC4 in DEFAULT, or entirely removing
> EXPORT/LOW.

That seems inconsistent with your view that RC4 must remain in MEDIUM, yet you are willing to drop other terms that other applications might be using. 

From rsalz at akamai.com  Wed Feb 11 15:37:35 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 15:37:35 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150211152423.2094cae2@pc>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <3043055.sERXNt3CE5@pintsize.usersys.redhat.com> <20150211152423.2094cae2@pc>
Message-ID: <fd27e82852904e708c9c1cd5062f02c6@ustx2ex-dag1mb2.msg.corp.akamai.com>

 
> > Also, what about changing order so that 128bit+ AEAD and PFS are
> > preferred over other ciphers (including 256 bit ones)?
> 
> I sent in a patch for exactly that a while ago.
> Unfortunately I got zero feedback...
> 
> https://mta.openssl.org/pipermail/openssl-dev/2015-January/000421.html

Sorry for the delay; it's been on my todo list.

I want to think about this more, but... yeah, probably.  Hope that helps.

From rsalz at akamai.com  Wed Feb 11 15:41:53 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 15:41:53 +0000
Subject: [openssl-dev] Nesses shows poodle
In-Reply-To: <AF70C7F70D95C54BAF2FCD161BADF2EB2210BB6A@xmb-aln-x13.cisco.com>
References: <AF70C7F70D95C54BAF2FCD161BADF2EB2210BB6A@xmb-aln-x13.cisco.com>
Message-ID: <6c4d4ab7a63645919b44ff5adddd1224@ustx2ex-dag1mb2.msg.corp.akamai.com>

Without knowing ANY details about how the Nessus POODLE scan works, it is hard to say.  If you have a recent version of OpenSSL installed, then you are protected from Poodle, regardless of what the scan claims.

If you want to check if you have completely disabled SSLv3, try this:
                openssl s_client -connect $HOSTNAME:443 -ssl3

--
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me<mailto:rsalz at jabber.me> Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150211/c8160033/attachment-0001.html>

From rsalz at akamai.com  Wed Feb 11 15:46:54 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 11 Feb 2015 15:46:54 +0000
Subject: [openssl-dev] [openssl-users] Proposed cipher
	changes	for	post-1.0.2
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
Message-ID: <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>

> I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it
> explicilty in DEFAULT) is a good one that maintains important backward
> compatibility while providing the desired removal of RC4 by default. There's
> no advantage to moving RC4 to LOW.

Sure there is:  it's an accurate description of the quality of protection provided by the algorithm. :)

It's also compatible with our documentation, which as was pointed out, always uses the word "currently" to describe the magic keywords.

And it's also planned for the next version which won't be available until near the end of the year.

And it's also compliant with the expected publication of the IETF RFC's that talk about TLS configuration and attacks.

Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4.


From meissner at suse.de  Wed Feb 11 16:09:22 2015
From: meissner at suse.de (Marcus Meissner)
Date: Wed, 11 Feb 2015 17:09:22 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211160922.GA21982@suse.de>

On Wed, Feb 11, 2015 at 03:15:11PM +0000, Salz, Rich wrote:
> > Note that for most applications the correct approach to configuring
> > ciphersuites should be to start with DEFAULT and subtract what they don't
> > want.  The library is then responsible for a generally sensible default order
> > and default exclusions.
> 
> I strongly disagree.  Most applications should explicitly list the ciphers they DO want.  That is the only way an application can be sure of what it is getting, without consulting external parties or configuration.  Otherwise, when the next Crime or Poodle or NameOfTheWeek comes out, you have no idea if you are vulnerable or not unless you look at something like the OpenSSL source code.
> 
> For what it's worth, I believe that "security levels" make this problem much worse. 

Our customers during the last SSL exploits were hoping for a global configuration
file actually to change cipher preferences.

Something that is present in 1.0.2 although I have not checked it deeply yet.

Ciao, Marcus

From dkg at fifthhorseman.net  Wed Feb 11 17:15:27 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 11 Feb 2015 12:15:27 -0500
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <87siecnzdc.fsf@alice.fifthhorseman.net>

On Wed 2015-02-11 10:15:11 -0500, Salz, Rich wrote:
>> Note that for most applications the correct approach to configuring
>> ciphersuites should be to start with DEFAULT and subtract what they don't
>> want.  The library is then responsible for a generally sensible default order
>> and default exclusions.
>
> I strongly disagree.  Most applications should explicitly list the
> ciphers they DO want.  That is the only way an application can be sure
> of what it is getting, without consulting external parties or
> configuration.  Otherwise, when the next Crime or Poodle or
> NameOfTheWeek comes out, you have no idea if you are vulnerable or not
> unless you look at something like the OpenSSL source code.
>
> For what it's worth, I believe that "security levels" make this
> problem much worse.

I disagree with you here, Rich.  There is ongoing evolution of our
understanding of TLS best practices, including standards, cryptanalysis,
and interoperability.  This dynamic situation seems unlikely to be come
static at any point in the future (changes in standards, cryptanalysis,
and the state of the network will continue to occur).  Even those of us
who spend a lot of time thinking about these matters have a hard time
keeping up.

As a larger ecosystem, we have maybe three main options to manage this
dynamism:

  0) every adminstrator of every TLS-using network service and every
     user of every TLS-using client needs to fiddle with TLS parameter
     selection as changes happen.

  1) every developer of every TLS-using tool (client or server) needs to
     fiddle with TLS parameter selection as changes happen.

  2) every library that implements TLS needs to fiddle with TLS
     parameter selection as changes happen.

Situation (0) is clearly untenable (it's also what we are valiantly
attempting today, e.g. https://bettercrypto.org/, because the other
things haven't happened effectively).

And situation (1) is just plain unlikely to happen.  Most software
developers *want* TLS to be "magic sauce" that they can sprinkle on and
have it Just Work.  They do not want to keep track of which parameters
are considered a bad idea this month, and they certainly don't want to
release new versions of their software just because someone says "hey,
you need to update your cipherstring".

On the other hand, the people who are experts in this situation and who
understand the dynamics best are going to be the folks tapped for the
work in (2).  This is why these kinds of things should be done by
default in the TLS implementations.

That doesn't mean that integer-based "security levels" is the right
approach (is there documentation on what the OpenSSL semantics should be
for these other than doc/ssl/SSL_CTX_set_security_level.pod?) -- it's
possible that "common use cases" would be better.  Then there could be
an "opportunistic" use case that meets Viktor's goals, and a "standard"
use case that hews closer to TLS BCP.

    --dkg

From rt at openssl.org  Wed Feb 11 17:48:23 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Wed, 11 Feb 2015 18:48:23 +0100
Subject: [openssl-dev] [openssl.org #799] extending openssl config to add
	X509v3 extension support
In-Reply-To: <Pine.NEB.4.53.0312172145240.231@neverwinter.home-net.icnt.net>
References: <RT-Ticket-799@openssl.org>
 <Pine.NEB.4.53.0310251256460.1012@neverwinter.home-net.icnt.net>
 <Pine.NEB.4.53.0312172145240.231@neverwinter.home-net.icnt.net>
Message-ID: <rt-4.0.4-25158-1423676903-32.799-6-0@openssl.org>

It's been more than 10 years, not going to happen.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Wed Feb 11 19:00:29 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Wed, 11 Feb 2015 20:00:29 +0100
Subject: [openssl-dev] [openssl.org #3687] openssl-0.9.8j: attribute
	"signingTime": unable to print attribute
In-Reply-To: <54D0C731020000A100019024@gwsmtp1.uni-regensburg.de>
References: <RT-Ticket-3687@openssl.org>
 <54D0C731020000A100019024@gwsmtp1.uni-regensburg.de>
Message-ID: <rt-4.0.4-25158-1423681229-1773.3687-6-0@openssl.org>

current versions of openssl know about this attribute, going back at least to
1.0.1
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Wed Feb 11 19:09:27 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Wed, 11 Feb 2015 20:09:27 +0100
Subject: [openssl-dev] [openssl.org #3672] About bug processing talked in
	your article
In-Reply-To: <332806168.48666.1421912397185.JavaMail.administrator@mtom.nabble.com>
References: <RT-Ticket-3672@openssl.org>
 <332806168.48666.1421912397185.JavaMail.administrator@mtom.nabble.com>
Message-ID: <rt-4.0.4-26561-1423681767-261.3672-6-0@openssl.org>

Looking at the link in the original ticket, this is apparently an Asterisk bug
that is causing openssl to crash. Nothing to do, closing ticket.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From openssl-users at dukhovni.org  Wed Feb 11 19:47:11 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 19:47:11 +0000
Subject: [openssl-dev] [openssl-users] Proposed cipher
	changes	for	post-1.0.2
In-Reply-To: <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87bnl1qru5.fsf@alice.fifthhorseman.net>
 <a9b7cd5312654de59321117c227b8e97@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211020050.GI12867@mournblade.imrryr.org>
 <B550B44BF8AF314BB00C4E2AC1C1808801344A7F17@Rock-Exchange1.microfocus.com>
 <240867ca3376443fae0aa6ef966b8552@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <20150211194711.GX12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 03:46:54PM +0000, Salz, Rich wrote:

> > I agree with Viktor. His suggestion (keep RC4 in MEDIUM, suppress it
> > explicitly in DEFAULT) is a good one that maintains important backward
> > compatibility while providing the desired removal of RC4 by default. There's
> > no advantage to moving RC4 to LOW.
> 
> Sure there is:  it's an accurate description of the quality of protection provided by the algorithm. :)

Except that it is not.  There are off-the-shelf key recovery attacks
on 56-bit DES (essentially the only LOW cipher anyone might actually
use, though nobody does anymore).  The known attacks on RC4 are
only effective when a great many plaintexts includes the same
sensitive content at a fixed position in the data stream.  While
this does mean we should stop using RC4 as soon as practical, it
is far from equating the security of RC4 with single-DES.


> It's also compatible with our documentation, which as was pointed
> out, always uses the word "currently" to describe the magic keywords.

Sure, there's some rope there, it does not mean we need to hang
ourselves.  The basic ciphersuite primitives by now have well
understood meanings that should only be changed with great care if
at all.

> Postfix can work lay the groundwork to be future-compliant by changing its default configuration to be HIGH:MEDIUM:RC4.

Except that "RC4" includes export-grade RC4, so that would be wrong.
Also Postfix defines a more usable user-interface of cipher "grades":
	
	smtp_tls_cipher_grade = null | export | low | medium | high

where "export" is EXPORT and up, "low" is "LOW" and up, "medium"
is "MEDIUM" and up, with the underlying definitions also configurable
but most users are encouraged to stay well clear of those:

	tls_null_cipherlist = eNULL:!aNULL
	tls_export_cipherlist = aNULL:-aNULL:ALL:+RC4:@STRENGTH
	tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:+RC4:@STRENGTH
	tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH
	tls_high_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:!MEDIUM:+RC4:@STRENGTH

instead users choose a grade, and may also specify exclusions:

    smtp_tls_exclude_ciphers = RC4, PSK, aDSS, ...

this provides enough flexibility to allow emergency tweaks to be
applied by users to deal with future issues, without requiring
users to be experts in OpenSSL cipherlists.

It is important to remember that all the moving pieces are part of
an ecosystem:

    * The OpenSSL project provides a foundation library to application
      developers (like myself with Postfix) AND to O/S release
      engineering teams that take upstream Postfix and upstream
      OpenSSL and package these into integrated systems.

    * The Postfix developers create a Postfix release with sensible
      backwards-compatible and reasonably future-proof cipherlist
      settings.

    * Postfix is built from source by the O/S release engineering
      team against some OpenSSL library available at the time of
      the build.

    * Users deploy systems with some Postfix version and some
      OpenSSL version.  They expect Postfix to be reasonably
      interoperable and backwards-compatible out of the box.

I am not sympathetic to the view that libraries should set application
policy because application developers are lazy.  I am not lazy,
and take the time to give users carefully chosen cipher settings.

These setting use documented primitives that avoid being too
specific, so that Postfix will take advantage of new ciphers (not
block progress) as these become available, and prioritizes these
appropriately.

If some developers do nothing and just want the library to be magic
security pixie-dust, then they benefit or get hurt by the "DEFAULT"
ciphersuite.  If developers or users do make more fine-grained
choices, those ought not change capriciously.

-- 
	Viktor.

From rt at openssl.org  Wed Feb 11 19:56:02 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Wed, 11 Feb 2015 20:56:02 +0100
Subject: [openssl-dev] [openssl.org #3640] Bug report: PKCS7_decrypt memory
	leak
In-Reply-To: <A52C10E5F0F0E84AA365FED766F9C6A3FED9121F@SUNAMSEXM01.AMERICAS.ROOT.PRI>
References: <RT-Ticket-3640@openssl.org>
 <A52C10E5F0F0E84AA365FED766F9C6A3FED9121F@SUNAMSEXM01.AMERICAS.ROOT.PRI>
Message-ID: <rt-4.0.4-26561-1423684562-1465.3640-6-0@openssl.org>

On Tue Dec 23 09:14:09 2014, Luis.Garcia at csr.com wrote:
> When using PKCS7_decrypt with the following parameters:
>
> BIO *bio = BIO_new(BIOS_s_mem());
>
> PKCS7 pointer, EVP_PKEY pointer, X509 pointer, bio, 0.
>
> I am getting a memory leak of 568 bytes.

Can you post a sample program? Or perhaps some kind of diagnostic that shows
WHERE the leak is occuring? (e.g,. valgrind on linux). Right now there's not
enough information to reproduce or analyze the problem.


From openssl-users at dukhovni.org  Wed Feb 11 20:21:37 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 11 Feb 2015 20:21:37 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <1672004.gQCVnt9D6P@pintsize.usersys.redhat.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210214646.GB12867@mournblade.imrryr.org>
 <1672004.gQCVnt9D6P@pintsize.usersys.redhat.com>
Message-ID: <20150211202137.GY12867@mournblade.imrryr.org>

On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote:

> On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote:
> > On Tue, Feb 10, 2015 at 09:15:36PM +0000, Salz, Rich wrote:
> > > I would like to make the following changes in the cipher specs, in the
> > > master branch, which is planned for the next release after 1.0.2
> > > 
> > > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
> > 
> > Note, that RC4 is already the only commonly used cipher-suite in MEDIUM.
> > 
> > Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
> > compatibility issues for opportunistic TLS (e.g. Postfix) where
> > RC4 is still required for interop and is better than cleartext.
> 
> Opportunistic TLS is a-typical use of TLS. One that is vulnerable to trivial 
> MitM attacks by the very definition. Using "ALL", possibly "ALL:!aNULL", 
> instead of "DEFAULT" doesn't make it much less secure.

Yeah, right, 70-90% of the world's email using opportunistic TLS
is "atypical".  XMPP server-to-server using opportunistic TLS is
"atypical", sorry the browser use-case is not the sole use of TLS.

As for vulnerable to MiTM, opportunistic TLS is less vulnerable
than cleartext.  (I'll believe that you actually care that
opportunistic TLS is not secure enough when Redhat deploys DNSSEC
and DANE TLSA RRs for its MX hosts).

-- 
	Viktor.

From rt at openssl.org  Wed Feb 11 21:09:08 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Wed, 11 Feb 2015 22:09:08 +0100
Subject: [openssl-dev] [openssl.org #3650] sha1-586.asm broken in
	1.0.2-stable for Windows builds
In-Reply-To: <54DBC445.7020501@openssl.org>
References: <RT-Ticket-3650@openssl.org>
 <20150205040253.EFE4528BC795@rock.dv.isc.org>
 <rt-4.0.4-4053-1423111824-291.3650-6-0@openssl.org>
 <54D32532.6060504@openssl.org>
 <rt-4.0.4-5491-1423123768-105.3650-6-0@openssl.org>
 <54DBC445.7020501@openssl.org>
Message-ID: <rt-4.0.4-4392-1423688948-1520.3650-6-0@openssl.org>

>> I am also having a issue this issue.  It is a 32 bit build issue
>> only.  The 64 bit build completes using the same development
>> environment.  The offending instruction is "movd".  Unfortunately
>> I am not a x86 assembler expert.
>>
>> Mark
>>
>>         perl crypto\sha\asm\sha1-586.pl win32 /MD /Ox /O2 /Ob2 -DOPENSSL_THREADS
>>   -DDSO_WIN32 -W3 -Gs0 -GF -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_
>> MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL
>> _IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -
>> DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH
>> _ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KR
>> B5 -DOPENSSL_NO_JPAKE -DOPENSSL_NO_DYNAMIC_ENGINE >tmp32dll\sha1-586.asm
>>         ml /nologo /Cp /coff /c /Cx /Zi /Fotmp32dll\sha1-586.obj tmp32dll\sha1-5
>> 86.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 11.0
>> \VC\BIN\ml.EXE"' : return code '0x1'
>> Stop.
>>
>> $Lshaext_shortcut::
>> 	mov	edi,DWORD PTR 20[esp]
>> 	mov	ebx,esp
>> 	mov	esi,DWORD PTR 24[esp]
>> 	mov	ecx,DWORD PTR 28[esp]
>> 	sub	esp,32
>> 	movdqu	xmm0,XMMWORD PTR [edi]
>> 	movd	xmm1,XMMWORD PTR 16[edi]		* 1432
> 
> Ah! It should be DWORD, not XMMWORD... Devja vu! There was similar case
> with movq elsewhere. See if attached fixes the problem.

It was brought to my attention that proposed patch creates other
problems. Attached one addresses those, as well as incorporates part of
solution suggested by Steve Kneizys. However! Even if x86masm.pl is
confirmed to work and is committed to repository, it will not make masm
supported. It will be available on don't-ask-in-case-of-doubt-use-nasm
basis. There are too many variables with masm while upgrading it is not
an option (because it's not available as separate packet). I mean since
we can't suggest to upgrade it, we would have to keep track of versions
and capabilities (instruction set and safeseh support), and it's not
exactly productive. One of concerns risen was that one would have to
answer question "why does one need to use something besides visual
studio". Well, you already use something besides visual studio, perl, so
how nasm is different? As for suggested workarounds, how using nasm is
different from writing custom program that pretends to be nasm but calls
masm, or providing extra script? I mean aren't they as "bad" as just
using nasm?

On side note. nasm is preferred option even in 64-bit context. Even
though we attempt to keep track of ml64 versions, using recent nasm
guarantees that you use all processor extensions, even when visual
studio doesn't.

-------------- next part --------------
diff --git a/crypto/perlasm/x86masm.pl b/crypto/perlasm/x86masm.pl
index 1741342..917d0f8 100644
--- a/crypto/perlasm/x86masm.pl
+++ b/crypto/perlasm/x86masm.pl
@@ -18,10 +18,10 @@ sub ::generic
 
     if ($opcode =~ /lea/ && @arg[1] =~ s/.*PTR\s+(\(.*\))$/OFFSET $1/)	# no []
     {	$opcode="mov";	}
-    elsif ($opcode !~ /movq/)
+    elsif ($opcode !~ /mov[dq]$/)
     {	# fix xmm references
-	$arg[0] =~ s/\b[A-Z]+WORD\s+PTR/XMMWORD PTR/i if ($arg[1]=~/\bxmm[0-7]\b/i);
-	$arg[1] =~ s/\b[A-Z]+WORD\s+PTR/XMMWORD PTR/i if ($arg[0]=~/\bxmm[0-7]\b/i);
+	$arg[0] =~ s/\b[A-Z]+WORD\s+PTR/XMMWORD PTR/i if ($arg[-1]=~/\bxmm[0-7]\b/i);
+	$arg[-1] =~ s/\b[A-Z]+WORD\s+PTR/XMMWORD PTR/i if ($arg[0]=~/\bxmm[0-7]\b/i);
     }
 
     &::emit($opcode, at arg);
@@ -160,13 +160,13 @@ sub ::public_label
 {   push(@out,"PUBLIC\t".&::LABEL($_[0],$nmdecor.$_[0])."\n");   }
 
 sub ::data_byte
-{   push(@out,("DB\t").join(',', at _)."\n");	}
+{   push(@out,("DB\t").join(',',splice(@_,0,16))."\n") while(@_);	}
 
 sub ::data_short
-{   push(@out,("DW\t").join(',', at _)."\n");	}
+{   push(@out,("DW\t").join(',',splice(@_,0,8))."\n") while(@_);	}
 
 sub ::data_word
-{   push(@out,("DD\t").join(',', at _)."\n");	}
+{   push(@out,("DD\t").join(',',splice(@_,0,4))."\n") while(@_);	}
 
 sub ::align
 {   push(@out,"ALIGN\t$_[0]\n");	}
diff --git a/crypto/sha/asm/sha1-586.pl b/crypto/sha/asm/sha1-586.pl
index 8377299..4895eb3 100644
--- a/crypto/sha/asm/sha1-586.pl
+++ b/crypto/sha/asm/sha1-586.pl
@@ -450,7 +450,7 @@ sub sha1msg2	{ sha1op38(0xca, at _); }
 	&sub	("esp",32);
 
 	&movdqu	($ABCD,&QWP(0,$ctx));
-	&movd	($E,&QWP(16,$ctx));
+	&movd	($E,&DWP(16,$ctx));
 	&and	("esp",-32);
 	&movdqa	($BSWAP,&QWP(0x50,$tmp1));	# byte-n-word swap
 

From rt at openssl.org  Wed Feb 11 22:40:12 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Wed, 11 Feb 2015 23:40:12 +0100
Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with
	FIPS 2.0.8 - fingerprint does not match
In-Reply-To: <54DBD9DD.7040800@openssl.org>
References: <RT-Ticket-3694@openssl.org>
 <D59C04F34BE3D1479A34815B4737AB230FCE6C96@6V-MBX2.CRESTRON.CRESTRON.com>
 <rt-4.0.4-6847-1423595781-907.3694-21-0@openssl.org>
 <CY1PR0301MB071383DD867BBDACB065F95B98240@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <rt-4.0.4-26573-1423612266-1338.3694-6-0@openssl.org>
 <54DBD9DD.7040800@openssl.org>
Message-ID: <rt-4.0.4-26561-1423694412-1015.3694-6-0@openssl.org>

> One thing to try would be to try both ways of the define for __thumb. This can explain the fingerprint failure. 
> 
> In fips_canister.c around line 188
> 
> # if defined(__thumb__) || defined(__thumb)
>     return (void *)((size_t)instruction_pointer&~1);
> # else
>     return (void *)instruction_pointer;
> # endif

Well, procedure is build fipscanister.obj, build fips_algvs.exe, use
fipscanister.obj *binary* with application. So that that whatever thumb
definition was it worked, in fips_algvs.exe context. Besides, that mask
is more of an optimization thing. I mean it should work in either case,
just that without masking the bit all memory references will be
unaligned. In other words, problem ought to be elsewhere...

> -----Original Message-----
> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Lior Gotian via RT
> Sent: Tuesday, February 10, 2015 11:16
> Cc: openssl-dev at openssl.org
> Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with FIPS 2.0.8 - fingerprint does not match
> 
> I was successful at compiling the FIPS 2.0.8 module for Windows CE exactly as provided without any modifications.
> Additionally, I built fips_algvs.exe to successfully validate the canister on the target system.
> 
> After tweaking some #ifdef directives in the openSSL 1.0.1L, I was able to get it to successfully build for WinCE.
> 
> The build appears to complete successfully.  However, at run-time, entering FIPS mode fails with an error messages:
> FIPS_check_incore_fingerprint:fingerprint does not match
> 
> I have reviewed the build instructions carefully and believe all the build instructions have been adhered to.  What needs to be changed for the signature to be properly embedded?

Well, this is not exactly fair question. I mean how can one tell
something without knowing something more specific than "some tweaking"
and "appears successful" :-) Well, tweaking probably is as important as
how you link your application, or rather how is the procedure different
from fips_algvs.exe. Can you confirm that msincore was actually
executed? What happens if you run it manually? Does application have
relocations? See with dumpbin /relocations. What's preferred load
address? See with dumpbin /headers. Is application loaded on preferred
address? This you should be able to see with debugger by comparing e.g.
main's address in debugger with one collected with dumpbin /symbols...



From james at jtaylor.id.au  Thu Feb 12 16:00:20 2015
From: james at jtaylor.id.au (James Taylor)
Date: Thu, 12 Feb 2015 16:00:20 +0000
Subject: [openssl-dev] Replace TERMIO with TERMIOS
Message-ID: <54DCCE14.2090502@jtaylor.id.au>

Hi,

I've been talking with some of the devs from the musl project, and
they're of the opinion that TERMIOS should be used in favour of
TERMIO... which appears to still work under GLIBC.

The #ifdef's that control whether each are used appear to intentionally
break systems that don't implement TERMIO, which I don't feel is
appropriate.

The main culprit is
#if defined(linux) && !defined(TERMIO)
# undef TERMIOS
# define TERMIO
# undef SGTTY
#endif

---
James Taylor
Keybase (https://keybase.io/jamestr)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150212/41e2f86b/attachment.sig>

From rt at openssl.org  Thu Feb 12 08:30:41 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Thu, 12 Feb 2015 09:30:41 +0100
Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with
	FIPS 2.0.8 - fingerprint does not match
In-Reply-To: <54DC649E.6070307@openssl.org>
References: <RT-Ticket-3694@openssl.org>
 <D59C04F34BE3D1479A34815B4737AB230FCE6C96@6V-MBX2.CRESTRON.CRESTRON.com>
 <rt-4.0.4-6847-1423595781-907.3694-21-0@openssl.org>
 <CY1PR0301MB071383DD867BBDACB065F95B98240@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <rt-4.0.4-26573-1423612266-1338.3694-6-0@openssl.org>
 <54DBD9DD.7040800@openssl.org>
 <rt-4.0.4-26561-1423694412-1015.3694-6-0@openssl.org>
 <54DC649E.6070307@openssl.org>
Message-ID: <rt-4.0.4-7337-1423729840-1730.3694-6-0@openssl.org>

>> I was successful at compiling the FIPS 2.0.8 module for Windows CE exactly as provided without any modifications.
>> Additionally, I built fips_algvs.exe to successfully validate the canister on the target system.
>>
>> After tweaking some #ifdef directives in the openSSL 1.0.1L, I was able to get it to successfully build for WinCE.
>>
>> The build appears to complete successfully.  However, at run-time, entering FIPS mode fails with an error messages:
>> FIPS_check_incore_fingerprint:fingerprint does not match
>>
>> I have reviewed the build instructions carefully and believe all the build instructions have been adhered to.  What needs to be changed for the signature to be properly embedded?
> 
> Well, this is not exactly fair question. I mean how can one tell
> something without knowing something more specific than "some tweaking"
> and "appears successful" :-) Well, tweaking probably is as important as
> how you link your application,

It should read "tweaking probably is *not* as important as how you link
your application." But this is exclusively in respect to fingerprint
verification. I mean tweaking in wrong place can have fatal overall
effect, but it's not inappropriate to dissect the problem and solve it
in steps. Therefore focus on fingerprint.

> or rather how is the procedure different
> from fips_algvs.exe. Can you confirm that msincore was actually
> executed? What happens if you run it manually? Does application have
> relocations? See with dumpbin /relocations. What's preferred load
> address? See with dumpbin /headers. Is application loaded on preferred
> address? This you should be able to see with debugger by comparing e.g.
> main's address in debugger with one collected with dumpbin /symbols...



From hkario at redhat.com  Thu Feb 12 10:09:39 2015
From: hkario at redhat.com (Hubert Kario)
Date: Thu, 12 Feb 2015 11:09:39 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150211202137.GY12867@mournblade.imrryr.org>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <1672004.gQCVnt9D6P@pintsize.usersys.redhat.com>
 <20150211202137.GY12867@mournblade.imrryr.org>
Message-ID: <2076295.SkGvTOTl9j@pintsize.usersys.redhat.com>

On Wednesday 11 February 2015 20:21:37 Viktor Dukhovni wrote:
> On Wed, Feb 11, 2015 at 12:59:22PM +0100, Hubert Kario wrote:
> > On Tuesday 10 February 2015 21:46:46 Viktor Dukhovni wrote:
> > > On Tue, Feb 10, 2015 at 09:15:36PM +0000, Salz, Rich wrote:
> > > > I would like to make the following changes in the cipher specs, in the
> > > > master branch, which is planned for the next release after 1.0.2
> > > > 
> > > > Anything that uses RC4 or MD5 what was in MEDIUM is now moved to LOW
> > > 
> > > Note, that RC4 is already the only commonly used cipher-suite in MEDIUM.
> > > 
> > > Changing the definitions of EXPOR, LOW, MEDIUM introduces significant
> > > compatibility issues for opportunistic TLS (e.g. Postfix) where
> > > RC4 is still required for interop and is better than cleartext.
> > 
> > Opportunistic TLS is a-typical use of TLS. One that is vulnerable to
> > trivial MitM attacks by the very definition. Using "ALL", possibly
> > "ALL:!aNULL", instead of "DEFAULT" doesn't make it much less secure.
> 
> Yeah, right, 70-90% of the world's email using opportunistic TLS
> is "atypical".  XMPP server-to-server using opportunistic TLS is
> "atypical", sorry the browser use-case is not the sole use of TLS.

yes, when the encryption is implemented using post-it note with "please don't 
enter" on it it is atypical

especially if you look at the amount of traffic that email and xmpp generate 
compared to HTTP...

I'd like it to be different, but the reality is as it is.
 
> As for vulnerable to MiTM, opportunistic TLS is less vulnerable
> than cleartext. 

yes, point is that as long as you don't do verification of identity of peer 
they are only infinitesimally better from each other.

The library should be "secure by default", you have different need, which is 
"interoperable by default". We can't have both.

> (I'll believe that you actually care that
> opportunistic TLS is not secure enough when Redhat deploys DNSSEC
> and DANE TLSA RRs for its MX hosts).

What I say are not official Redhat statements, I argue arguments, not sides, 
and I don't work in IT so I have minimal impact on what our MXs do.
-- 
Regards,
Hubert Kario

From matt at openssl.org  Thu Feb 12 10:15:53 2015
From: matt at openssl.org (Matt Caswell)
Date: Thu, 12 Feb 2015 10:15:53 +0000
Subject: [openssl-dev] Code Reformat blog post
Message-ID: <54DC7D59.9010603@openssl.org>

I have posted a new blog article covering the recent reformat activity:
https://www.openssl.org/blog/blog/2015/02/11/code-reformat-finished/

It's basically a review of what we did, how we did it and the problems
we encountered. It also discusses the various tags that we've created in
the repo, and outlines how you might go about reformatting patches that
you maintain.

Matt

From rainer.jung at kippdata.de  Thu Feb 12 10:51:57 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Thu, 12 Feb 2015 11:51:57 +0100
Subject: [openssl-dev] [openssl-commits] [openssl] master update ("Add
 Camellia CTR mode", dda8199922f9d52087d2c41b22a61eb4f9671385)
In-Reply-To: <20150211193042.B70771DF1AB@butler.localdomain>
References: <20150211193042.B70771DF1AB@butler.localdomain>
Message-ID: <54DC85CD.2020207@kippdata.de>

Am 11.02.2015 um 20:30 schrieb Andy Polyakov:
> The branch master has been updated
>         via  dda8199922f9d52087d2c41b22a61eb4f9671385 (commit)
>         via  c79e17731f462d6d42b917027a7085c0f59a2214 (commit)
>        from  b7c9187b32a14b5b4a850161aed5c044d2130d5a (commit)
>
>
> - Log -----------------------------------------------------------------
> commit dda8199922f9d52087d2c41b22a61eb4f9671385
> Author: Andy Polyakov <appro at openssl.org>
> Date:   Wed Feb 11 20:30:13 2015 +0100
>
>      Add Camellia CTR mode.
>
>      Reviewed-by: Rich Salz <rsalz at openssl.org>
>

...

> -----------------------------------------------------------------------
>
> Summary of changes:
>   crypto/evp/c_allc.c        |    3 ++
>   crypto/evp/e_camellia.c    |    9 ++---
>   crypto/evp/evptests.txt    |   64 ++++++++++++++++++++++++++++++++++
>   crypto/objects/obj_dat.h   |   82 +++++++++++++++++++++++++++++++++++++++++---
>   crypto/objects/obj_mac.h   |   60 ++++++++++++++++++++++++++++++++
>   crypto/objects/obj_mac.num |   12 +++++++
>   crypto/objects/objects.txt |   12 +++++++
>   7 files changed, 231 insertions(+), 11 deletions(-)
>
> diff --git a/crypto/evp/c_allc.c b/crypto/evp/c_allc.c
> index 174a419..7ae36d7 100644
> --- a/crypto/evp/c_allc.c
> +++ b/crypto/evp/c_allc.c
> @@ -245,5 +245,8 @@ void OpenSSL_add_all_ciphers(void)
>       EVP_add_cipher(EVP_camellia_256_ofb());
>       EVP_add_cipher_alias(SN_camellia_256_cbc, "CAMELLIA256");
>       EVP_add_cipher_alias(SN_camellia_256_cbc, "camellia256");
> +    EVP_add_cipher(EVP_camellia_128_ctr());
> +    EVP_add_cipher(EVP_camellia_192_ctr());
> +    EVP_add_cipher(EVP_camellia_256_ctr());
>   #endif
>   }

We get build warnings and crashes during run in EVP_add_cipher(). It 
seems EVP_camellia_128_ctr(), EVP_camellia_192_ctr() and 
EVP_camellia_256_ctr() are missing from crypto/evp/evp.h:

c_allc.c:248:5: warning: implicit declaration of function 
"EVP_camellia_128_ctr" [-Wimplicit-function-declaration]
      EVP_add_cipher(EVP_camellia_128_ctr());
etc.

Thanks,

Rainer


From richard at levitte.org  Thu Feb 12 10:56:04 2015
From: richard at levitte.org (Richard Levitte)
Date: Thu, 12 Feb 2015 11:56:04 +0100 (CET)
Subject: [openssl-dev] Replace TERMIO with TERMIOS
In-Reply-To: <54DCCE14.2090502@jtaylor.id.au>
References: <54DCCE14.2090502@jtaylor.id.au>
Message-ID: <20150212.115604.191952553995574508.richard@levitte.org>

In message <54DCCE14.2090502 at jtaylor.id.au> on Thu, 12 Feb 2015 16:00:20 +0000, James Taylor <james at jtaylor.id.au> said:

james> Hi,
james> 
james> I've been talking with some of the devs from the musl project, and
james> they're of the opinion that TERMIOS should be used in favour of
james> TERMIO... which appears to still work under GLIBC.
james> 
james> The #ifdef's that control whether each are used appear to intentionally
james> break systems that don't implement TERMIO, which I don't feel is
james> appropriate.
james> 
james> The main culprit is
james> #if defined(linux) && !defined(TERMIO)
james> # undef TERMIOS
james> # define TERMIO
james> # undef SGTTY
james> #endif

Saw this on github a few days ago.  I just applied that fix, it will
show up in not too long.

Cheers,
Richard

-- 
Richard Levitte                         richard at levitte.org
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish

From appro at openssl.org  Thu Feb 12 11:00:01 2015
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 12 Feb 2015 12:00:01 +0100
Subject: [openssl-dev] [openssl-commits] [openssl] master update ("Add
 Camellia CTR mode", dda8199922f9d52087d2c41b22a61eb4f9671385)
In-Reply-To: <54DC85CD.2020207@kippdata.de>
References: <20150211193042.B70771DF1AB@butler.localdomain>
 <54DC85CD.2020207@kippdata.de>
Message-ID: <54DC87B1.6030801@openssl.org>

>> diff --git a/crypto/evp/c_allc.c b/crypto/evp/c_allc.c
>> index 174a419..7ae36d7 100644
>> --- a/crypto/evp/c_allc.c
>> +++ b/crypto/evp/c_allc.c
>> @@ -245,5 +245,8 @@ void OpenSSL_add_all_ciphers(void)
>>       EVP_add_cipher(EVP_camellia_256_ofb());
>>       EVP_add_cipher_alias(SN_camellia_256_cbc, "CAMELLIA256");
>>       EVP_add_cipher_alias(SN_camellia_256_cbc, "camellia256");
>> +    EVP_add_cipher(EVP_camellia_128_ctr());
>> +    EVP_add_cipher(EVP_camellia_192_ctr());
>> +    EVP_add_cipher(EVP_camellia_256_ctr());
>>   #endif
>>   }
> 
> We get build warnings and crashes during run in EVP_add_cipher().

Thanks. I'm on it. Out of curiosity, with which config do you get
crashes? I don't mean that this doesn't need fixing, I only want to have
a reference.


From rainer.jung at kippdata.de  Thu Feb 12 11:49:05 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Thu, 12 Feb 2015 12:49:05 +0100
Subject: [openssl-dev] [openssl-commits] [openssl] master update ("Add
 Camellia CTR mode", dda8199922f9d52087d2c41b22a61eb4f9671385)
In-Reply-To: <54DC87B1.6030801@openssl.org>
References: <20150211193042.B70771DF1AB@butler.localdomain>
 <54DC85CD.2020207@kippdata.de> <54DC87B1.6030801@openssl.org>
Message-ID: <54DC9331.2020409@kippdata.de>

Am 12.02.2015 um 12:00 schrieb Andy Polyakov:
>>> diff --git a/crypto/evp/c_allc.c b/crypto/evp/c_allc.c
>>> index 174a419..7ae36d7 100644
>>> --- a/crypto/evp/c_allc.c
>>> +++ b/crypto/evp/c_allc.c
>>> @@ -245,5 +245,8 @@ void OpenSSL_add_all_ciphers(void)
>>>        EVP_add_cipher(EVP_camellia_256_ofb());
>>>        EVP_add_cipher_alias(SN_camellia_256_cbc, "CAMELLIA256");
>>>        EVP_add_cipher_alias(SN_camellia_256_cbc, "camellia256");
>>> +    EVP_add_cipher(EVP_camellia_128_ctr());
>>> +    EVP_add_cipher(EVP_camellia_192_ctr());
>>> +    EVP_add_cipher(EVP_camellia_256_ctr());
>>>    #endif
>>>    }
>>
>> We get build warnings and crashes during run in EVP_add_cipher().
>
> Thanks. I'm on it. Out of curiosity, with which config do you get
> crashes? I don't mean that this doesn't need fixing, I only want to have
> a reference.

Thanks to you.

The crash occurred while using it during a CI build for Tomcat plus 
Tomcat native connector (tcnative) which in turn uses OpenSSL.

OpenSSL was build with "config --prefix=... shared enable-deprecated".

I don't have a full stack available. The Java HS-Error file says:

     [junit] #
     [junit] # A fatal error has been detected by the Java Runtime 
Environment:
     [junit] #
     [junit] #  SIGSEGV (0xb) at pc=0x00007fb882f66ef9, pid=32437, 
tid=140431064893184
     [junit] #
     [junit] # JRE version: Java(TM) SE Runtime Environment (8.0_25-b17) 
(build 1.8.0_25-b17)
     [junit] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.25-b02 
mixed mode linux-amd64 compressed oops)
     [junit] # Problematic frame:
     [junit] # C  [libcrypto.so.1.1.0+0x14fef9]  EVP_add_cipher+0x9
     [junit] #

Regards,

Rainer

From appro at openssl.org  Thu Feb 12 12:06:48 2015
From: appro at openssl.org (Andy Polyakov)
Date: Thu, 12 Feb 2015 13:06:48 +0100
Subject: [openssl-dev] [openssl-commits] [openssl] master update ("Add
 Camellia CTR mode", dda8199922f9d52087d2c41b22a61eb4f9671385)
In-Reply-To: <54DC9331.2020409@kippdata.de>
References: <20150211193042.B70771DF1AB@butler.localdomain>
 <54DC85CD.2020207@kippdata.de> <54DC87B1.6030801@openssl.org>
 <54DC9331.2020409@kippdata.de>
Message-ID: <54DC9758.7040002@openssl.org>

On 02/12/15 12:49, Rainer Jung wrote:
> Am 12.02.2015 um 12:00 schrieb Andy Polyakov:
>>>> diff --git a/crypto/evp/c_allc.c b/crypto/evp/c_allc.c
>>>> index 174a419..7ae36d7 100644
>>>> --- a/crypto/evp/c_allc.c
>>>> +++ b/crypto/evp/c_allc.c
>>>> @@ -245,5 +245,8 @@ void OpenSSL_add_all_ciphers(void)
>>>>        EVP_add_cipher(EVP_camellia_256_ofb());
>>>>        EVP_add_cipher_alias(SN_camellia_256_cbc, "CAMELLIA256");
>>>>        EVP_add_cipher_alias(SN_camellia_256_cbc, "camellia256");
>>>> +    EVP_add_cipher(EVP_camellia_128_ctr());
>>>> +    EVP_add_cipher(EVP_camellia_192_ctr());
>>>> +    EVP_add_cipher(EVP_camellia_256_ctr());
>>>>    #endif
>>>>    }
>>>
>>> We get build warnings and crashes during run in EVP_add_cipher().
>>
>> Thanks. I'm on it. Out of curiosity, with which config do you get
>> crashes? I don't mean that this doesn't need fixing, I only want to have
>> a reference.
> 
> Thanks to you.
> 
> The crash occurred while using it during a CI build for Tomcat plus
> Tomcat native connector (tcnative) which in turn uses OpenSSL.

Question was rather about OS. The question I seek answer to is how did
it evade the usual test and/or what is so special about your environment.

> OpenSSL was build with "config --prefix=... shared enable-deprecated".
> 
> I don't have a full stack available. The Java HS-Error file says:
> 
>     [junit] #
>     [junit] # A fatal error has been detected by the Java Runtime
> Environment:
>     [junit] #
>     [junit] #  SIGSEGV (0xb) at pc=0x00007fb882f66ef9, pid=32437,
> tid=140431064893184

Ah! Keyword is likely to be that it was shared build. I mean implicit
cast can slip through in non-shared case, because in such case code is
loaded in lower 2GB, while shared libraries tend to be mapped far above
4GB. Thanks.


From james at jtaylor.id.au  Thu Feb 12 23:21:29 2015
From: james at jtaylor.id.au (James Taylor)
Date: Thu, 12 Feb 2015 23:21:29 +0000
Subject: [openssl-dev] Replace TERMIO with TERMIOS
In-Reply-To: <20150212.115604.191952553995574508.richard@levitte.org>
References: <54DCCE14.2090502@jtaylor.id.au>
 <20150212.115604.191952553995574508.richard@levitte.org>
Message-ID: <54DD3579.1020103@jtaylor.id.au>

On 12/02/15 10:56, Richard Levitte wrote:
> Saw this on github a few days ago.  I just applied that fix, it will
> show up in not too long.

Well that was quick ;) Yeah, I spotted it there too. Thought it would be
worth asking on the ML anyway.

Thanks,

James Taylor
-- 
James Taylor
Keybase (https://keybase.io/jamestr)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150212/53e026cf/attachment.sig>

From richard at levitte.org  Thu Feb 12 14:12:17 2015
From: richard at levitte.org (Richard Levitte)
Date: Thu, 12 Feb 2015 15:12:17 +0100 (CET)
Subject: [openssl-dev] Replace TERMIO with TERMIOS
In-Reply-To: <54DD3579.1020103@jtaylor.id.au>
References: <54DCCE14.2090502@jtaylor.id.au>
 <20150212.115604.191952553995574508.richard@levitte.org>
 <54DD3579.1020103@jtaylor.id.au>
Message-ID: <20150212.151217.89907775681522070.richard@levitte.org>

In message <54DD3579.1020103 at jtaylor.id.au> on Thu, 12 Feb 2015 23:21:29 +0000, James Taylor <james at jtaylor.id.au> said:

james> On 12/02/15 10:56, Richard Levitte wrote:
james> > Saw this on github a few days ago.  I just applied that fix, it will
james> > show up in not too long.
james> 
james> Well that was quick ;) Yeah, I spotted it there too. Thought it would be
james> worth asking on the ML anyway.

Pure luck, really.  It might also have gotten lost in the flow of
emails.  The most recommended way to report a bug is on our request
tracker (see http://openssl.org/support/rt.html).

Cheers,
Richard

-- 
Richard Levitte                         richard at levitte.org
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish

From rt at openssl.org  Thu Feb 12 16:17:00 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 Feb 2015 17:17:00 +0100
Subject: [openssl-dev] [openssl.org #1541] quick patch in ssl/t1_enc.c
In-Reply-To: <148C743DBF70354A9E62CAB431C7F6EE0538E26B@CORPUSMX30A.corp.emc.com>
References: <RT-Ticket-1541@openssl.org>
 <148C743DBF70354A9E62CAB431C7F6EE0538E26B@CORPUSMX30A.corp.emc.com>
Message-ID: <rt-4.0.4-19916-1423757820-1539.1541-6-0@openssl.org>

OpenSSL_1_0_1-stable a1331af Missing OPENSSL_free on error path.
OpenSSL_1_0_2-stable 62bfff2 Missing OPENSSL_free on error path.
master 1d2932d Missing OPENSSL_free on error path.

Author: Eric Dequin <Dequin_Eric at emc.com>
Date: Thu Feb 12 10:44:30 2015 -0500

Missing OPENSSL_free on error path.

Reviewed-by: Andy Polyakov <appro at openssl.org>
Reviewed-by: Richard Levitte <levitte at openssl.org>
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From sdaoden at yandex.com  Thu Feb 12 17:39:49 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Thu, 12 Feb 2015 18:39:49 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <87siecnzdc.fsf@alice.fifthhorseman.net>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87siecnzdc.fsf@alice.fifthhorseman.net>
Message-ID: <20150212173949.ekcyYngd%sdaoden@yandex.com>

Oh, this thread is about the OpenSSL configuration package that
Rich Salz promised!..

Daniel Kahn Gillmor <dkg at fifthhorseman.net> wrote:
 |On Wed 2015-02-11 10:15:11 -0500, Salz, Rich wrote:
 |>> Note that for most applications the correct approach to configuring
 |>> ciphersuites should be to start with DEFAULT and subtract what they don't
 |>> want.  The library is then responsible for a generally \
 |>> sensible default order
 |>> and default exclusions.
 |>
 |> I strongly disagree.  Most applications should explicitly list the
 |> ciphers they DO want.  That is the only way an application can be sure
 |> of what it is getting, without consulting external parties or
 |> configuration.  Otherwise, when the next Crime or Poodle or
 |> NameOfTheWeek comes out, you have no idea if you are vulnerable or not
 |> unless you look at something like the OpenSSL source code.
 |>
 |> For what it's worth, I believe that "security levels" make this
 |> problem much worse.
 |
 |I disagree with you here, Rich.  There is ongoing evolution of our

I do, too.

 |understanding of TLS best practices, including standards, cryptanalysis,
 |and interoperability.  This dynamic situation seems unlikely to be come
 |static at any point in the future (changes in standards, cryptanalysis,
 |and the state of the network will continue to occur).  Even those of us
 |who spend a lot of time thinking about these matters have a hard time
 |keeping up.
 |
 |As a larger ecosystem, we have maybe three main options to manage this
 |dynamism:
 |
 |  0) every adminstrator of every TLS-using network service and every
 |     user of every TLS-using client needs to fiddle with TLS parameter
 |     selection as changes happen.
 |
 |  1) every developer of every TLS-using tool (client or server) needs to
 |     fiddle with TLS parameter selection as changes happen.
 |
 |  2) every library that implements TLS needs to fiddle with TLS
 |     parameter selection as changes happen.
 |
 |Situation (0) is clearly untenable (it's also what we are valiantly
 |attempting today, e.g. https://bettercrypto.org/, because the other
 |things haven't happened effectively).
 |
 |And situation (1) is just plain unlikely to happen.  Most software
 |developers *want* TLS to be "magic sauce" that they can sprinkle on and
 |have it Just Work.  They do not want to keep track of which parameters
 |are considered a bad idea this month, and they certainly don't want to
 |release new versions of their software just because someone says "hey,
 |you need to update your cipherstring".
 |
 |On the other hand, the people who are experts in this situation and who
 |understand the dynamics best are going to be the folks tapped for the
 |work in (2).  This is why these kinds of things should be done by
 |default in the TLS implementations.

I absolutely support all statements of Daniel Kahn Gillmore, but
especially that dynamism must be handled at a place that can be
adjusted without the necessity for any recompilation.
And i want to point to OPENSSL_config(3) which states for a longer
time duration:

       It is strongly recommended that all new applications call
       OPENSSL_config() or the more sophisticated functions such as
       CONF_modules_load() during initialization (that is before starting any
       threads). By doing this an application does not need to keep track of
       all configuration options and some new functionality can be supported
       automatically.

and so this finally appears to me as a natural place for such
things.  (The next version of the MUA i maintain will, also
finally, add support for this, for example.)

I think it was a bug report (sigh; btw., is the new EVP test still
broken regarding "evp_test(33743) malloc: pointer being freed was
not allocated"?) where i've expressed my own personal feelings
about that topic, in that i think the best would be if the
configuration file would be extended to offer the necessary
possibilities, yet i would dramatically change the current
semantics, for example regarding $OPENSSL_CONF, but there also
should be an option to enable the usual Unix configuration file
chain way of doing things ("global configuration file", "$HOME
configuration file"), and an administrator should have the option
to fixate some settings, possibly via a new "!" prefix to
a variable option, as in

  # /etc/openssl.rc
  [ciphers]
  DEFAULT=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
  !ALL=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384

so that a user could do

  # ~/.openssl.rc
  [ciphers]
  DEFAULT=ECDHE-RSA-AES256-GCM-SHA384

but not

  # ~/.openssl.rc
  [ciphers]
  ALL=ECDHE-RSA-AES256-GCM-SHA384

because the administrator cramped the possibilities.
The good thing about that approach is definitely that necessary
changes after revealed protocol or cipher insecurities could be
applied immediately by anybody after reading an announcement mail,
without the need for any recompilation or even a library release.
Of course OpenSSL could provide a "conf" package that would
distribute the necessary changes officially, and so could to
distributions, too.

Even more so if three files would be used (OpenSSL, system-global,
per-user).  Like that the OpenSSL one could be packaged separately
and administrators could adjust the system-global template.
Of course a mechanism like rc.conf and rc.local could also be used
instead, yet i think having that possibility as such would be
great.

Of course there need to be more flags (e.g., "don't load user
file") and some utility should gain the possibility to perform
syntax checking.
But the mechanism as such is worth thinking about, imho.

--steffen

From rt at openssl.org  Thu Feb 12 18:03:28 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 Feb 2015 19:03:28 +0100
Subject: [openssl-dev] [openssl.org #3670] Bug in str_copy in conf_def.c
	[PATCH]
In-Reply-To: <6378BFFB8601BD438AD9AF3CA610548E56CAC584@DEWDFEMB16B.global.corp.sap>
References: <RT-Ticket-3670@openssl.org>
 <6378BFFB8601BD438AD9AF3CA610548E56CAC584@DEWDFEMB16B.global.corp.sap>
Message-ID: <rt-4.0.4-29960-1423764208-1567.3670-6-0@openssl.org>

Fixed, thanks.
OpenSSL_1_0_1-stable bb14c2c RT3670: Check return from BUF_MEM_grow_clean
OpenSSL_1_0_2-stable ee1ccd0 RT3670: Check return from BUF_MEM_grow_clean
master b0333e6 RT3670: Check return from BUF_MEM_grow_clean

Author: Graeme Perrow <graeme.perrow at sap.com>
Date: Thu Feb 12 13:00:42 2015 -0500

RT3670: Check return from BUF_MEM_grow_clean

Reviewed-by: Richard Levitte <levitte at openssl.org>
;
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Thu Feb 12 19:26:10 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 Feb 2015 20:26:10 +0100
Subject: [openssl-dev] [openssl.org #3684] Missing <stddef.h> for source
	files using offsetof
In-Reply-To: <CAH8yC8kg+NQT7sh5ouTf=1Qqaup1=PWkuYWRDFO1fWj5FEBPQg@mail.gmail.com>
References: <RT-Ticket-3684@openssl.org>
 <CAH8yC8kg+NQT7sh5ouTf=1Qqaup1=PWkuYWRDFO1fWj5FEBPQg@mail.gmail.com>
Message-ID: <rt-4.0.4-29960-1423769170-572.3684-6-0@openssl.org>

Fixed.

OpenSSL_1_0_1-stable a9ea906 RT3684: rand_egd needs stddef.h
OpenSSL_1_0_2-stable 872f91c RT3684: rand_egd needs stddef.h
master 5006c32 RT3684: rand_egd needs stddef.h

And on master, I removed the offsetof definition; kept it on the backport just
to avoid possible build-breakage.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Thu Feb 12 19:41:15 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 Feb 2015 20:41:15 +0100
Subject: [openssl-dev] [openssl.org #937] uid
In-Reply-To: <4121AF2B.3060303@cms.hu-berlin.de>
References: <RT-Ticket-937@openssl.org> <4121AF2B.3060303@cms.hu-berlin.de>
Message-ID: <rt-4.0.4-21817-1423770075-1275.937-6-0@openssl.org>

Only fixing this on master.

commit c81f425eaa09dcf3f1f55a008c0486d7b742f20d
Author: Rich Salz <rsalz at openssl.org>
Date: Thu Feb 12 14:38:31 2015 -0500

RT937: Enable pilotAttributeType uniqueIdentifier

Reviewed-by: Richard Levitte <levitte at openssl.org>

--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Thu Feb 12 19:49:32 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 Feb 2015 20:49:32 +0100
Subject: [openssl-dev] [openssl.org #2426] [PATCH] fix Borland C++ 5.5
	compilation
In-Reply-To: <4D2C4A7B.2080402@gknw.net>
References: <RT-Ticket-2426@openssl.org> <4D2C4A7B.2080402@gknw.net>
Message-ID: <rt-4.0.4-29025-1423770572-1580.2426-6-0@openssl.org>

_ftime isn't used in bss_dgram.c any more, not sure when it was fixed, closing
this.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Thu Feb 12 19:50:58 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 Feb 2015 20:50:58 +0100
Subject: [openssl-dev] [openssl.org #2427] [PATCH] fix Borland C++ 5.5
	redefine
In-Reply-To: <4D2C6C7C.9020106@gknw.net>
References: <RT-Ticket-2427@openssl.org> <4D2C6C7C.9020106@gknw.net>
Message-ID: <rt-4.0.4-29025-1423770658-79.2427-6-0@openssl.org>

please re-open if this is still an issue for Borland C
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Thu Feb 12 19:52:25 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 Feb 2015 20:52:25 +0100
Subject: [openssl-dev] [openssl.org #2428] [PATCH] fix Borland C++ 5.5
	compilation /2
In-Reply-To: <4D2C77AE.7030409@gknw.net>
References: <RT-Ticket-2428@openssl.org> <4D2C77AE.7030409@gknw.net>
Message-ID: <rt-4.0.4-29960-1423770745-1096.2428-6-0@openssl.org>

Is this still an issue? RE-open if so. Not sure if it's a borland bug claiming
_WIN32 and not supporting that API ...
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Thu Feb 12 19:53:15 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Thu, 12 Feb 2015 20:53:15 +0100
Subject: [openssl-dev] [openssl.org #2429] [PATCH] fix Borland C++ 5.5
	compilation /3
In-Reply-To: <4D2C8571.1010101@gknw.net>
References: <RT-Ticket-2429@openssl.org> <4D2C8571.1010101@gknw.net>
Message-ID: <rt-4.0.4-29960-1423770795-205.2429-6-0@openssl.org>

evp_test had been fixed.
the compiler still broke? re-open.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From rt at openssl.org  Thu Feb 12 22:54:20 2015
From: rt at openssl.org (Richard Levitte via RT)
Date: Thu, 12 Feb 2015 23:54:20 +0100
Subject: [openssl-dev] [openssl.org #3526] [Patch] Removed the dependency on
	the obsolete TERMIO.h for linux 32 and 64bits.
In-Reply-To: <5410bdd4.yDDjsXWFJYblVNZd%nik_89@xroutine.net>
References: <RT-Ticket-3526@openssl.org>
 <5410bdd4.yDDjsXWFJYblVNZd%nik_89@xroutine.net>
Message-ID: <rt-4.0.4-29960-1423781660-978.3526-6-0@openssl.org>

Hi,

sorry for taking half a year to respond...

I'm looking at this change, and it occurs to me that there are some Linux
configuration lines that you didn't affect. linux-ppc, linux-alpha-gcc and a
few more. Was that on purpose or was it a mistake? If it was a mistake, I
assume -DTERMIO should change to -DTERMIOS on them as well.

On Thu Sep 11 11:59:24 2014, nik_89 at xroutine.net wrote:
>
> Operating System : Linux 32 and 64bits.
> Version of OpenSSL : 1.0.1i
>
>
> TERMIO is an obsolete header file that is not even in vanilla glibc
> anymore. The TERMIOS header file is fully backward compatible with the
> TERMIO struct so it is safe to use that instead. This prevents systems
> that dropped altogether the termio.h "glue" header from having nasty
> errors when compiling.
> ---
> Configure | 24 ++++++++++++------------
> crypto/ui/ui_openssl.c | 2 --
> 2 files changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/Configure b/Configure
> index 36844b7..7b2d5d7 100755
> --- a/Configure
> +++ b/Configure
> @@ -345,23 +345,23 @@ my %table=(
> ####
> # *-generic* is endian-neutral target, but ./config is free to
> # throw in -D[BL]_ENDIAN, whichever appropriate...
> -"linux-generic32","gcc:-DTERMIO -O3 -fomit-frame-pointer
> -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
> DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-generic32","gcc:-DTERMIOS -O3 -fomit-frame-pointer
> -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
> DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> "linux-ppc", "gcc:-DB_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_RISC1
> DES_UNROLL:${ppc32_asm}:linux32:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> # It's believed that majority of ARM toolchains predefine appropriate
> -march.
> # If you compiler does not, do complement config command line with
> one!
> -"linux-armv4", "gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG
> RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
> BF_PTR:${armv4_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-armv4", "gcc:-DTERMIOS -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG
> RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
> BF_PTR:${armv4_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> #### IA-32 targets...
> -"linux-ia32-icc", "icc:-DL_ENDIAN -DTERMIO -O2
> -no_cpprt::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-
> KPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-elf", "gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer
> -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-aout", "gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer
> -march=i486 -Wall::(unknown):::BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_asm}:a.out",
> +"linux-ia32-icc", "icc:-DL_ENDIAN -DTERMIOS -O2
> -no_cpprt::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-
> KPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-elf", "gcc:-DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer
> -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-aout", "gcc:-DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer
> -march=i486 -Wall::(unknown):::BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_asm}:a.out",
> ####
> -"linux-generic64","gcc:-DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-ppc64", "gcc:-m64 -DB_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_RISC1 DES_UNROLL:${ppc64_asm}:linux64:dlfcn:linux-shared:-
> fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> -"linux-ia64", "gcc:-DL_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL
> DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-ia64-ecc","ecc:-DL_ENDIAN -DTERMIO -O2 -Wall
> -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
> DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-ia64-icc","icc:-DL_ENDIAN -DTERMIO -O2 -Wall
> -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
> DES_RISC1 DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-x86_64", "gcc:-m64 -DL_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
> DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-
> m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> -"linux64-s390x", "gcc:-m64 -DB_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_INT DES_UNROLL:${s390x_asm}:64:dlfcn:linux-shared:-fPIC:-
> m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> +"linux-generic64","gcc:-DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-ppc64", "gcc:-m64 -DB_ENDIAN -DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_RISC1 DES_UNROLL:${ppc64_asm}:linux64:dlfcn:linux-shared:-
> fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> +"linux-ia64", "gcc:-DL_ENDIAN -DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL
> DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-ia64-ecc","ecc:-DL_ENDIAN -DTERMIOS -O2 -Wall
> -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
> DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-ia64-icc","icc:-DL_ENDIAN -DTERMIOS -O2 -Wall
> -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
> DES_RISC1 DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-x86_64", "gcc:-m64 -DL_ENDIAN -DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
> DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-
> m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> +"linux64-s390x", "gcc:-m64 -DB_ENDIAN -DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_INT DES_UNROLL:${s390x_asm}:64:dlfcn:linux-shared:-fPIC:-
> m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> #### So called "highgprs" target for z/Architecture CPUs
> # "Highgprs" is kernel feature first implemented in Linux 2.6.32, see
> # /proc/cpuinfo. The idea is to preserve most significant bits of
> diff --git a/crypto/ui/ui_openssl.c b/crypto/ui/ui_openssl.c
> index a38c758..91e1ae0 100644
> --- a/crypto/ui/ui_openssl.c
> +++ b/crypto/ui/ui_openssl.c
> @@ -191,8 +191,6 @@
> #endif
>
> #if defined(linux) && !defined(TERMIO)
> -# undef TERMIOS
> -# define TERMIO
> # undef SGTTY
> #endif
>


--
Richard Levitte
levitte at openssl.org


From nmav at redhat.com  Fri Feb 13 08:09:01 2015
From: nmav at redhat.com (Nikos Mavrogiannopoulos)
Date: Fri, 13 Feb 2015 09:09:01 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150212173949.ekcyYngd%sdaoden@yandex.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87siecnzdc.fsf@alice.fifthhorseman.net>
 <20150212173949.ekcyYngd%sdaoden@yandex.com>
Message-ID: <1423814941.2423.8.camel@redhat.com>

On Thu, 2015-02-12 at 18:39 +0100, Steffen Nurpmeso wrote:

> I absolutely support all statements of Daniel Kahn Gillmore, but
> especially that dynamism must be handled at a place that can be
> adjusted without the necessity for any recompilation.
> And i want to point to OPENSSL_config(3) which states for a longer
> time duration:
> 
>        It is strongly recommended that all new applications call
>        OPENSSL_config() or the more sophisticated functions such as
>        CONF_modules_load() during initialization (that is before starting any
>        threads). By doing this an application does not need to keep track of
>        all configuration options and some new functionality can be supported
>        automatically.
> 
> and so this finally appears to me as a natural place for such
> things.  (The next version of the MUA i maintain will, also
> finally, add support for this, for example.)
> 
> I think it was a bug report (sigh; btw., is the new EVP test still
> broken regarding "evp_test(33743) malloc: pointer being freed was
> not allocated"?) where i've expressed my own personal feelings
> about that topic, in that i think the best would be if the
> configuration file would be extended to offer the necessary
> possibilities, yet i would dramatically change the current
> semantics, for example regarding $OPENSSL_CONF, but there also
> should be an option to enable the usual Unix configuration file
> chain way of doing things ("global configuration file", "$HOME
> configuration file"), and an administrator should have the option
> to fixate some settings, possibly via a new "!" prefix to
> a variable option, as in
> 
>   # /etc/openssl.rc
>   [ciphers]
>   DEFAULT=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
>   !ALL=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
> 
> so that a user could do
> 
>   # ~/.openssl.rc
>   [ciphers]
>   DEFAULT=ECDHE-RSA-AES256-GCM-SHA384

Some time ago, I had submitted a patch which allows administrators, but
most importantly OS distributors to set their own strings in the
configuration file, which software can then rely on, to provide a
consistent security level: https://github.com/openssl/openssl/pull/192

regards,
Nikos



From rsalz at akamai.com  Fri Feb 13 11:59:13 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 13 Feb 2015 11:59:13 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <1423814941.2423.8.camel@redhat.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87siecnzdc.fsf@alice.fifthhorseman.net>
 <20150212173949.ekcyYngd%sdaoden@yandex.com>
 <1423814941.2423.8.camel@redhat.com>
Message-ID: <42d93f316ef54ae5a13e1f0e5c9a41db@ustx2ex-dag1mb4.msg.corp.akamai.com>


> Some time ago, I had submitted a patch which allows administrators, but
> most importantly OS distributors to set their own strings in the configuration
> file, which software can then rely on, to provide a consistent security level:
> https://github.com/openssl/openssl/pull/192

And my intent is to pull this into master pretty soon.

From sdaoden at yandex.com  Fri Feb 13 13:02:27 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Fri, 13 Feb 2015 14:02:27 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <1423814941.2423.8.camel@redhat.com>
References: <8f03875f82be44f2894e7c7ac29fdd04@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210223801.184d8688@pc>
 <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87siecnzdc.fsf@alice.fifthhorseman.net>
 <20150212173949.ekcyYngd%sdaoden@yandex.com>
 <1423814941.2423.8.camel@redhat.com>
Message-ID: <20150213130227.xu_oHZdQ%sdaoden@yandex.com>

Hello,

Nikos Mavrogiannopoulos <nmav at redhat.com> wrote:
 |On Thu, 2015-02-12 at 18:39 +0100, Steffen Nurpmeso wrote:

 |> And i want to point to OPENSSL_config(3) which states for a longer
 |> time duration:
 |> 
 |>        It is strongly recommended that all new applications call
 |>        OPENSSL_config() or the more sophisticated functions such as
 |>        CONF_modules_load() during initialization (that is \
 |>        before starting any

 |>   # /etc/openssl.rc
 |>   [ciphers]
 |>   DEFAULT=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
 |>   !ALL=ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384
 |> 
 |> so that a user could do
 |> 
 |>   # ~/.openssl.rc
 |>   [ciphers]
 |>   DEFAULT=ECDHE-RSA-AES256-GCM-SHA384
 |
 |Some time ago, I had submitted a patch which allows administrators, but
 |most importantly OS distributors to set their own strings in the
 |configuration file, which software can then rely on, to provide a
 |consistent security level: https://github.com/openssl/openssl/pull/192

sorry, i haven't seen that yet.  Of course, definining their very
own profile in a special namespace is i think also a great option
for users.

--steffen

From rt at openssl.org  Fri Feb 13 14:06:33 2015
From: rt at openssl.org (Tomas Zahradnicky via RT)
Date: Fri, 13 Feb 2015 15:06:33 +0100
Subject: [openssl-dev] [openssl.org #3696] openssl 1.0.1k s_client app bug?
In-Reply-To: <1423674868.1930.15.camel@fit.cvut.cz>
References: <RT-Ticket-3696@openssl.org> <1423674868.1930.15.camel@fit.cvut.cz>
Message-ID: <rt-4.0.4-24414-1423836393-195.3696-21-0@openssl.org>

Dear OpenSSL-dev list members,

there might be a bug in the OpenSSL s_client app. The s_client app does
not verify against root CA certificates in the store, unless either
-CAfile or -CApath is present (even with a bogus value). The problem
seems to be on apps/s_client.c:1187:

        if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
                (!SSL_CTX_set_default_verify_paths(ctx)))
                {
                /* BIO_printf(bio_err,"error setting default verify
locations\n"); */
                ERR_print_errors(bio_err);
                /* goto end; */
                }

SSL_CTX_load_verify_locations returns 0 if both CAfile and CApath
parameters are NULL, and, as a consequence,
SSL_CTX_set_default_verify_paths is not called since the || operator is
already true because of the first !0. If an argument such as
"-CApath /dev/null" is present, SSL_CTX_load_verify_locations returns 1
and SSL_CTX_load_verify_locations is called as expected. The logical or
operator appears to be wrong in this case.

Fix proposal: Change || to &&.

Is this a known problem?

Cheers,
Tomas Zahradnicky




From rt at openssl.org  Fri Feb 13 14:07:08 2015
From: rt at openssl.org (Pertti Karppinen via RT)
Date: Fri, 13 Feb 2015 15:07:08 +0100
Subject: [openssl-dev] [openssl.org #3697] Bug in s_client with loading of
	default certificates
In-Reply-To: <20150212112908.GA32765@henni.solutions.fi>
References: <RT-Ticket-3697@openssl.org>
 <20150212112908.GA32765@henni.solutions.fi>
Message-ID: <rt-4.0.4-24414-1423836428-148.3697-21-0@openssl.org>

In apps/s_client.c there is an invalid if-clause:

if ((!SSL_CTX_load_verify_locations(ctx, CAfile, CApath)) ||
    (!SSL_CTX_set_default_verify_paths(ctx))) {
  /*
   * BIO_printf(bio_err,"error setting default
   verify locations\n");
   */
  ERR_print_errors(bio_err);
  /* goto end; */
}
		   
Function SSL_CTX_set_default_verify_paths is never called if both CAfile and
CApath are NULL, because in file crypto/x509/x509_d2.c the function
X509_STORE_load_locations returns 0 in such case.
		   
There seems to be something odd with the X509_STORE_load_locations function,
as everywhere else where it is called (it has wrapper
SSL_CTX_load_verify_locations), both the path and file are checked, so they
are never both NULL, but still that condition is checked inside the function.
		   
-- 
Pertti Karppinen
Email pertti.karppinen at online.fi

Online Solutions Oy - http://www.online.fi/



From rt at openssl.org  Fri Feb 13 14:07:28 2015
From: rt at openssl.org (Narendra Meka via RT)
Date: Fri, 13 Feb 2015 15:07:28 +0100
Subject: [openssl-dev] [openssl.org #3698] Bug: Ref count issue in SSL_new
	may cause a crash in SSL_free if REF_CHECK is defined
In-Reply-To: <95EAF4ED0C018A4695944138C621F56A060C6B8F@xmb-rcd-x03.cisco.com>
References: <RT-Ticket-3698@openssl.org>
 <95EAF4ED0C018A4695944138C621F56A060C6B8F@xmb-rcd-x03.cisco.com>
Message-ID: <rt-4.0.4-24414-1423836448-725.3698-21-0@openssl.org>

In SSL_new, s->references is set to 1 AFTER ssl_new successfully completes. If it errors out, SSL_free() is called which decrements it but since it was never set to 1, it will cause a crash if REF_CHECK is defined since i will be less than zero. There are also a few other "goto err" cases in SSL_new before the s->references is set to 1.

SSL_new Code:
if (!s->method->ssl_new(s))
goto err;

s->references=1;

Error handling:
err:
if (s != NULL)
SSL_free(s);
SSLerr(SSL_F_SSL_NEW,ERR_R_MALLOC_FAILURE);
return(NULL);

SSL_Free code:
if(s == NULL)
   return;

i=CRYPTO_add(&s->references,-1,CRYPTO_LOCK_SSL);
#ifdef REF_PRINT
REF_PRINT("SSL",s);
#endif
if (i > 0) return;
#ifdef REF_CHECK
if (i < 0)
{
fprintf(stderr,"SSL_free, bad reference count\n");
abort(); /* ok */
}
#endif

Thanks
Narendra Meka
Cisco Systems



From rt at openssl.org  Fri Feb 13 14:07:46 2015
From: rt at openssl.org (Stuart Kemp via RT)
Date: Fri, 13 Feb 2015 15:07:46 +0100
Subject: [openssl-dev] [openssl.org #3699] openssl-1.0.2,
	fips sparc multiply defined _sparcv9_vis1_instrument_bus,
	_sparcv9_vis1_instrument_bus2
In-Reply-To: <54DC8E6A0200002800011D4C@prv-mh.provo.novell.com>
References: <RT-Ticket-3699@openssl.org>
 <54DC8E6A0200002800011D4C@prv-mh.provo.novell.com>
Message-ID: <rt-4.0.4-24414-1423836466-981.3699-21-0@openssl.org>


Trying to build FIPS capable OpenSSL on sparc.

Using openssl-fips-2.0.9.tar.gz and openssl-1.0.2.tar.gz.

Building per the UserGuide-2.0.pdf (although it does not say that 1.0.2 can be used ... "Any 1.0.1 release can be
used for this purpose". Except that 1.0.1j still has a sparc assembly error as reported in http://rt.openssl.org/Ticket/Display.html?id=2689#txn-48029
 so was trying latest)

OpenSSL configured as:

./config fips threads shared no-ec2m no-idea no-mdc2 no-rc5 

Get following error(s) when trying to build fips_premain_dso

ld: fatal: symbol '_sparcv9_vis1_instrument_bus2' is multiply-defined:
        (file /XXX/fips-2.0/lib/fipscanister.o type=FUNC; file libcrypto.a(sparccpuid.o) type=FUNC);
ld: fatal: symbol '_sparcv9_vis1_instrument_bus' is multiply-defined:
        (file /XXX/fips-2.0/lib/fipscanister.o type=FUNC; file libcrypto.a(sparccpuid.o) type=FUNC);
ld: fatal: file processing errors. No output written to fips_premain_dso

Comparing the sparccpuid.S code from 1.0.1j and 1.0.2, these functions were not there in 1.0.1j


Thanks,

-Stuart Kemp



From rt at openssl.org  Fri Feb 13 14:08:12 2015
From: rt at openssl.org (=?UTF-8?B?Q3Jpc3RpYW4gUm9kcsOtZ3Vleg==?= via RT)
Date: Fri, 13 Feb 2015 15:08:12 +0100
Subject: [openssl-dev] [openssl.org #3700] [PATCH] remove CRYPTO_strdup,
	switch callers to BUF_strdup
In-Reply-To: <1423798111-29957-1-git-send-email-crrodriguez@opensuse.org>
References: <RT-Ticket-3700@openssl.org>
 <1423798111-29957-1-git-send-email-crrodriguez@opensuse.org>
Message-ID: <rt-4.0.4-2538-1423836491-1938.3700-21-0@openssl.org>

No need to a keep a duplicate API.
---
 crypto/crypto.h      | 1 -
 crypto/jpake/jpake.c | 5 +++--
 crypto/mem.c         | 8 --------
 3 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/crypto/crypto.h b/crypto/crypto.h
index 9762398..7dd2223 100644
--- a/crypto/crypto.h
+++ b/crypto/crypto.h
@@ -366,7 +366,6 @@ int CRYPTO_is_mem_check_on(void);
 # define is_MemCheck_on() CRYPTO_is_mem_check_on()
 
 # define OPENSSL_malloc(num)     CRYPTO_malloc((int)num,__FILE__,__LINE__)
-# define OPENSSL_strdup(str)     CRYPTO_strdup((str),__FILE__,__LINE__)
 # define OPENSSL_realloc(addr,num) \
         CRYPTO_realloc((char *)addr,(int)num,__FILE__,__LINE__)
 # define OPENSSL_realloc_clean(addr,old_num,num) \
diff --git a/crypto/jpake/jpake.c b/crypto/jpake/jpake.c
index eb6654d..2492c1d 100644
--- a/crypto/jpake/jpake.c
+++ b/crypto/jpake/jpake.c
@@ -2,6 +2,7 @@
 #include <openssl/crypto.h>
 #include <openssl/sha.h>
 #include <openssl/err.h>
+#include <openssl/buffer.h>
 #include <memory.h>
 #include <string.h>
 
@@ -74,8 +75,8 @@ static void JPAKE_CTX_init(JPAKE_CTX *ctx, const char *name,
                            const BIGNUM *g, const BIGNUM *q,
                            const BIGNUM *secret)
 {
-    ctx->p.name = OPENSSL_strdup(name);
-    ctx->p.peer_name = OPENSSL_strdup(peer_name);
+    ctx->p.name = BUF_strdup(name);
+    ctx->p.peer_name = BUF_strdup(peer_name);
     ctx->p.p = BN_dup(p);
     ctx->p.g = BN_dup(g);
     ctx->p.q = BN_dup(q);
diff --git a/crypto/mem.c b/crypto/mem.c
index d059362..5173098 100644
--- a/crypto/mem.c
+++ b/crypto/mem.c
@@ -360,14 +360,6 @@ void *CRYPTO_malloc(int num, const char *file, int line)
     return ret;
 }
 
-char *CRYPTO_strdup(const char *str, const char *file, int line)
-{
-    char *ret = CRYPTO_malloc(strlen(str) + 1, file, line);
-
-    strcpy(ret, str);
-    return ret;
-}
-
 void *CRYPTO_realloc(void *str, int num, const char *file, int line)
 {
     void *ret = NULL;
-- 
2.2.2



From rt at openssl.org  Fri Feb 13 14:08:13 2015
From: rt at openssl.org (=?UTF-8?B?Q3Jpc3RpYW4gUm9kcsOtZ3Vleg==?= via RT)
Date: Fri, 13 Feb 2015 15:08:13 +0100
Subject: [openssl-dev] [openssl.org #3701] [PATCH] Use BUF_memdup where
	appropiate
In-Reply-To: <1423809277-3391-1-git-send-email-crrodriguez@opensuse.org>
References: <RT-Ticket-3701@openssl.org>
 <1423809277-3391-1-git-send-email-crrodriguez@opensuse.org>
Message-ID: <rt-4.0.4-2538-1423836493-1391.3701-21-0@openssl.org>

---
 crypto/asn1/tasn_utl.c        |  4 ++--
 crypto/cms/cms_enc.c          |  4 ++--
 crypto/ec/ec_mult.c           |  4 ++--
 crypto/engine/eng_cryptodev.c |  4 ++--
 crypto/evp/e_aes.c            |  4 ++--
 crypto/evp/evp_enc.c          |  4 ++--
 engines/ccgost/gost_pmeth.c   |  7 +++----
 ssl/s3_clnt.c                 |  3 +--
 ssl/s3_lib.c                  |  4 ++--
 ssl/s3_srvr.c                 |  3 +--
 ssl/ssl_cert.c                | 13 ++++++-------
 ssl/ssl_lib.c                 | 13 +++++--------
 ssl/t1_lib.c                  | 10 ++++------
 13 files changed, 34 insertions(+), 43 deletions(-)

diff --git a/crypto/asn1/tasn_utl.c b/crypto/asn1/tasn_utl.c
index 2e14c2f..ce1b998 100644
--- a/crypto/asn1/tasn_utl.c
+++ b/crypto/asn1/tasn_utl.c
@@ -63,6 +63,7 @@
 #include <openssl/asn1t.h>
 #include <openssl/objects.h>
 #include <openssl/err.h>
+#include <openssl/buffer.h>
 
 /* Utility functions for manipulating fields and offsets */
 
@@ -171,10 +172,9 @@ int asn1_enc_save(ASN1_VALUE **pval, const unsigned char *in, int inlen,
 
     if (enc->enc)
         OPENSSL_free(enc->enc);
-    enc->enc = OPENSSL_malloc(inlen);
+    enc->enc = BUF_memdup(in, inlen);
     if (!enc->enc)
         return 0;
-    memcpy(enc->enc, in, inlen);
     enc->len = inlen;
     enc->modified = 0;
 
diff --git a/crypto/cms/cms_enc.c b/crypto/cms/cms_enc.c
index 85ae928..a2b3848 100644
--- a/crypto/cms/cms_enc.c
+++ b/crypto/cms/cms_enc.c
@@ -59,6 +59,7 @@
 #include <openssl/err.h>
 #include <openssl/cms.h>
 #include <openssl/rand.h>
+#include <openssl/buffer.h>
 #include "cms_lcl.h"
 
 /* CMS EncryptedData Utilities */
@@ -216,10 +217,9 @@ int cms_EncryptedContent_init(CMS_EncryptedContentInfo *ec,
 {
     ec->cipher = cipher;
     if (key) {
-        ec->key = OPENSSL_malloc(keylen);
+        ec->key = BUF_memdup(key, keylen);
         if (!ec->key)
             return 0;
-        memcpy(ec->key, key, keylen);
     }
     ec->keylen = keylen;
     if (cipher)
diff --git a/crypto/ec/ec_mult.c b/crypto/ec/ec_mult.c
index 16b37db..81583a1 100644
--- a/crypto/ec/ec_mult.c
+++ b/crypto/ec/ec_mult.c
@@ -63,6 +63,7 @@
 
 #include <string.h>
 #include <openssl/err.h>
+#include <openssl/buffer.h>
 
 #include "internal/bn_int.h"
 #include "ec_lcl.h"
@@ -414,13 +415,12 @@ int ec_wNAF_mul(const EC_GROUP *group, EC_POINT *r, const BIGNUM *scalar,
                         wNAF_len[i] = tmp_len;
 
                     wNAF[i + 1] = NULL;
-                    wNAF[i] = OPENSSL_malloc(wNAF_len[i]);
+                    wNAF[i] = BUF_memdup(pp, wNAF_len[i]);
                     if (wNAF[i] == NULL) {
                         ECerr(EC_F_EC_WNAF_MUL, ERR_R_MALLOC_FAILURE);
                         OPENSSL_free(tmp_wNAF);
                         goto err;
                     }
-                    memcpy(wNAF[i], pp, wNAF_len[i]);
                     if (wNAF_len[i] > max_len)
                         max_len = wNAF_len[i];
 
diff --git a/crypto/engine/eng_cryptodev.c b/crypto/engine/eng_cryptodev.c
index 65efc81..3ccc337 100644
--- a/crypto/engine/eng_cryptodev.c
+++ b/crypto/engine/eng_cryptodev.c
@@ -30,6 +30,7 @@
 #include <openssl/engine.h>
 #include <openssl/evp.h>
 #include <openssl/bn.h>
+#include <openssl/buffer.h>
 #include "../bn/bn_lcl.h"
 
 #if (defined(__unix__) || defined(unix)) && !defined(USG) && \
@@ -939,12 +940,11 @@ static int cryptodev_digest_copy(EVP_MD_CTX *to, const EVP_MD_CTX *from)
 
     if (fstate->mac_len != 0) {
         if (fstate->mac_data != NULL) {
-            dstate->mac_data = OPENSSL_malloc(fstate->mac_len);
+            dstate->mac_data = BUF_memdup(fstate->mac_data, fstate->mac_len);
             if (dstate->mac_data == NULL) {
                 printf("cryptodev_digest_copy: mac_data allocation failed\n");
                 return (0);
             }
-            memcpy(dstate->mac_data, fstate->mac_data, fstate->mac_len);
             dstate->mac_len = fstate->mac_len;
         }
     }
diff --git a/crypto/evp/e_aes.c b/crypto/evp/e_aes.c
index 4fab21b..84117a0 100644
--- a/crypto/evp/e_aes.c
+++ b/crypto/evp/e_aes.c
@@ -58,6 +58,7 @@
 # include "evp_locl.h"
 # include "modes_lcl.h"
 # include <openssl/rand.h>
+# include <openssl/buffer.h>
 
 typedef struct {
     union {
@@ -1353,10 +1354,9 @@ static int aes_gcm_ctrl(EVP_CIPHER_CTX *c, int type, int arg, void *ptr)
             if (gctx->iv == c->iv)
                 gctx_out->iv = out->iv;
             else {
-                gctx_out->iv = OPENSSL_malloc(gctx->ivlen);
+                gctx_out->iv = BUF_memdup(gctx->iv, gctx->ivlen);
                 if (!gctx_out->iv)
                     return 0;
-                memcpy(gctx_out->iv, gctx->iv, gctx->ivlen);
             }
             return 1;
         }
diff --git a/crypto/evp/evp_enc.c b/crypto/evp/evp_enc.c
index 3d40b04..e9b84db 100644
--- a/crypto/evp/evp_enc.c
+++ b/crypto/evp/evp_enc.c
@@ -61,6 +61,7 @@
 #include <openssl/evp.h>
 #include <openssl/err.h>
 #include <openssl/rand.h>
+#include <openssl/buffer.h>
 #ifndef OPENSSL_NO_ENGINE
 # include <openssl/engine.h>
 #endif
@@ -623,12 +624,11 @@ int EVP_CIPHER_CTX_copy(EVP_CIPHER_CTX *out, const EVP_CIPHER_CTX *in)
     memcpy(out, in, sizeof *out);
 
     if (in->cipher_data && in->cipher->ctx_size) {
-        out->cipher_data = OPENSSL_malloc(in->cipher->ctx_size);
+        out->cipher_data = BUF_memdup(in->cipher_data, in->cipher->ctx_size);
         if (!out->cipher_data) {
             EVPerr(EVP_F_EVP_CIPHER_CTX_COPY, ERR_R_MALLOC_FAILURE);
             return 0;
         }
-        memcpy(out->cipher_data, in->cipher_data, in->cipher->ctx_size);
     }
 
     if (in->cipher->flags & EVP_CIPH_CUSTOM_COPY)
diff --git a/engines/ccgost/gost_pmeth.c b/engines/ccgost/gost_pmeth.c
index f1220e8..6ff8f1d 100644
--- a/engines/ccgost/gost_pmeth.c
+++ b/engines/ccgost/gost_pmeth.c
@@ -12,6 +12,7 @@
 #include <openssl/ec.h>
 #include <openssl/err.h>
 #include <openssl/x509v3.h>     /* For string_to_hex */
+#include <openssl/buffer.h>
 #include <stdlib.h>
 #include <string.h>
 #include <ctype.h>
@@ -106,12 +107,11 @@ static int pkey_gost_ctrl(EVP_PKEY_CTX *ctx, int type, int p1, void *p2)
         pctx->sign_param_nid = (int)p1;
         return 1;
     case EVP_PKEY_CTRL_SET_IV:
-        pctx->shared_ukm = OPENSSL_malloc((int)p1);
+        pctx->shared_ukm = BUF_memdup(p2, (int)p1);
         if (pctx->shared_ukm == NULL) {
             GOSTerr(GOST_F_PKEY_GOST_CTRL, ERR_R_MALLOC_FAILURE);
             return 0;
         }
-        memcpy(pctx->shared_ukm, p2, (int)p1);
         return 1;
     case EVP_PKEY_CTRL_PEER_KEY:
         if (p1 == 0 || p1 == 1) /* call from EVP_PKEY_derive_set_peer */
@@ -531,10 +531,9 @@ static int pkey_gost_mac_keygen(EVP_PKEY_CTX *ctx, EVP_PKEY *pkey)
         GOSTerr(GOST_F_PKEY_GOST_MAC_KEYGEN, GOST_R_MAC_KEY_NOT_SET);
         return 0;
     }
-    keydata = OPENSSL_malloc(32);
+    keydata = BUF_memdup(data->key, 32);
     if (keydata == NULL)
         return 0;
-    memcpy(keydata, data->key, 32);
     EVP_PKEY_assign(pkey, NID_id_Gost28147_89_MAC, keydata);
     return 1;
 }
diff --git a/ssl/s3_clnt.c b/ssl/s3_clnt.c
index 1e437b2..51f95dc 100644
--- a/ssl/s3_clnt.c
+++ b/ssl/s3_clnt.c
@@ -2173,12 +2173,11 @@ int ssl3_get_new_session_ticket(SSL *s)
         OPENSSL_free(s->session->tlsext_tick);
         s->session->tlsext_ticklen = 0;
     }
-    s->session->tlsext_tick = OPENSSL_malloc(ticklen);
+    s->session->tlsext_tick = BUF_memdup(p, ticklen);
     if (!s->session->tlsext_tick) {
         SSLerr(SSL_F_SSL3_GET_NEW_SESSION_TICKET, ERR_R_MALLOC_FAILURE);
         goto err;
     }
-    memcpy(s->session->tlsext_tick, p, ticklen);
     s->session->tlsext_ticklen = ticklen;
     /*
      * There are two ways to detect a resumed ticket session. One is to set
diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index ab19eeb..9bf8867 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -156,6 +156,7 @@
 #ifndef OPENSSL_NO_DH
 # include <openssl/dh.h>
 #endif
+#include <openssl/buffer.h>
 
 const char ssl3_version_str[] = "SSLv3" OPENSSL_VERSION_PTEXT;
 
@@ -4460,10 +4461,9 @@ static int ssl3_set_req_cert_type(CERT *c, const unsigned char *p, size_t len)
         return 1;
     if (len > 0xff)
         return 0;
-    c->ctypes = OPENSSL_malloc(len);
+    c->ctypes = BUF_memdup(p, len);
     if (!c->ctypes)
         return 0;
-    memcpy(c->ctypes, p, len);
     c->ctype_num = len;
     return 1;
 }
diff --git a/ssl/s3_srvr.c b/ssl/s3_srvr.c
index 8819fed..ca6a0b0 100644
--- a/ssl/s3_srvr.c
+++ b/ssl/s3_srvr.c
@@ -3519,12 +3519,11 @@ int ssl3_get_next_proto(SSL *s)
     if (proto_len + padding_len + 2 != s->init_num)
         return 0;
 
-    s->next_proto_negotiated = OPENSSL_malloc(proto_len);
+    s->next_proto_negotiated = BUF_memdup(p + 1, proto_len);
     if (!s->next_proto_negotiated) {
         SSLerr(SSL_F_SSL3_GET_NEXT_PROTO, ERR_R_MALLOC_FAILURE);
         return 0;
     }
-    memcpy(s->next_proto_negotiated, p + 1, proto_len);
     s->next_proto_negotiated_len = proto_len;
 
     return 1;
diff --git a/ssl/ssl_cert.c b/ssl/ssl_cert.c
index 9742599..3116c9e 100644
--- a/ssl/ssl_cert.c
+++ b/ssl/ssl_cert.c
@@ -132,6 +132,7 @@
 # include <openssl/dh.h>
 #endif
 #include <openssl/bn.h>
+#include <openssl/buffer.h>
 #include "ssl_locl.h"
 
 static int ssl_security_default_callback(SSL *s, SSL_CTX *ctx, int op,
@@ -324,20 +325,19 @@ CERT *ssl_cert_dup(CERT *cert)
     /* Configured sigalgs however we copy across */
 
     if (cert->conf_sigalgs) {
-        ret->conf_sigalgs = OPENSSL_malloc(cert->conf_sigalgslen);
+        ret->conf_sigalgs = BUF_memdup(cert->conf_sigalgs,
+                                       cert->conf_sigalgslen);
         if (!ret->conf_sigalgs)
             goto err;
-        memcpy(ret->conf_sigalgs, cert->conf_sigalgs, cert->conf_sigalgslen);
         ret->conf_sigalgslen = cert->conf_sigalgslen;
     } else
         ret->conf_sigalgs = NULL;
 
     if (cert->client_sigalgs) {
-        ret->client_sigalgs = OPENSSL_malloc(cert->client_sigalgslen);
+        ret->client_sigalgs = BUF_memdup(cert->client_sigalgs,
+                                         cert->client_sigalgslen);
         if (!ret->client_sigalgs)
             goto err;
-        memcpy(ret->client_sigalgs, cert->client_sigalgs,
-               cert->client_sigalgslen);
         ret->client_sigalgslen = cert->client_sigalgslen;
     } else
         ret->client_sigalgs = NULL;
@@ -345,10 +345,9 @@ CERT *ssl_cert_dup(CERT *cert)
     ret->shared_sigalgs = NULL;
     /* Copy any custom client certificate types */
     if (cert->ctypes) {
-        ret->ctypes = OPENSSL_malloc(cert->ctype_num);
+        ret->ctypes = BUF_memdup(cert->ctypes, cert->ctype_num);
         if (!ret->ctypes)
             goto err;
-        memcpy(ret->ctypes, cert->ctypes, cert->ctype_num);
         ret->ctype_num = cert->ctype_num;
     }
 
diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index c535a42..7f672cb 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -159,6 +159,7 @@
 #ifndef OPENSSL_NO_ENGINE
 # include <openssl/engine.h>
 #endif
+#include <openssl/buffer.h>
 
 const char *SSL_version_str = OPENSSL_VERSION_TEXT;
 
@@ -362,12 +363,10 @@ SSL *SSL_new(SSL_CTX *ctx)
 # endif
 
     if (s->ctx->alpn_client_proto_list) {
-        s->alpn_client_proto_list =
-            OPENSSL_malloc(s->ctx->alpn_client_proto_list_len);
+        s->alpn_client_proto_list = BUF_memdup(s->ctx->alpn_client_proto_list,
+                                               s->ctx->alpn_client_proto_list_len);
         if (s->alpn_client_proto_list == NULL)
             goto err;
-        memcpy(s->alpn_client_proto_list, s->ctx->alpn_client_proto_list,
-               s->ctx->alpn_client_proto_list_len);
         s->alpn_client_proto_list_len = s->ctx->alpn_client_proto_list_len;
     }
 #endif
@@ -1742,10 +1741,9 @@ int SSL_CTX_set_alpn_protos(SSL_CTX *ctx, const unsigned char *protos,
     if (ctx->alpn_client_proto_list)
         OPENSSL_free(ctx->alpn_client_proto_list);
 
-    ctx->alpn_client_proto_list = OPENSSL_malloc(protos_len);
+    ctx->alpn_client_proto_list = BUF_memdup(protos, protos_len);
     if (!ctx->alpn_client_proto_list)
         return 1;
-    memcpy(ctx->alpn_client_proto_list, protos, protos_len);
     ctx->alpn_client_proto_list_len = protos_len;
 
     return 0;
@@ -1762,10 +1760,9 @@ int SSL_set_alpn_protos(SSL *ssl, const unsigned char *protos,
     if (ssl->alpn_client_proto_list)
         OPENSSL_free(ssl->alpn_client_proto_list);
 
-    ssl->alpn_client_proto_list = OPENSSL_malloc(protos_len);
+    ssl->alpn_client_proto_list = BUF_memdup(protos, protos_len);
     if (!ssl->alpn_client_proto_list)
         return 1;
-    memcpy(ssl->alpn_client_proto_list, protos, protos_len);
     ssl->alpn_client_proto_list_len = protos_len;
 
     return 0;
diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index c91b761..02da497 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -119,6 +119,7 @@
 # include <openssl/dh.h>
 # include <openssl/bn.h>
 #endif
+#include <openssl/buffer.h>
 #include "ssl_locl.h"
 
 const char tls1_version_str[] = "TLSv1" OPENSSL_VERSION_PTEXT;
@@ -1765,12 +1766,11 @@ static int tls1_alpn_handle_client_hello(SSL *s, const unsigned char *data,
     if (r == SSL_TLSEXT_ERR_OK) {
         if (s->s3->alpn_selected)
             OPENSSL_free(s->s3->alpn_selected);
-        s->s3->alpn_selected = OPENSSL_malloc(selected_len);
+        s->s3->alpn_selected = BUF_memdup(selected, selected_len);
         if (!s->s3->alpn_selected) {
             *al = SSL_AD_INTERNAL_ERROR;
             return -1;
         }
-        memcpy(s->s3->alpn_selected, selected, selected_len);
         s->s3->alpn_selected_len = selected_len;
     }
     return 0;
@@ -2494,12 +2494,11 @@ static int ssl_scan_serverhello_tlsext(SSL *s, unsigned char **p,
                 *al = TLS1_AD_INTERNAL_ERROR;
                 return 0;
             }
-            s->next_proto_negotiated = OPENSSL_malloc(selected_len);
+            s->next_proto_negotiated = BUF_memdup(selected, selected_len);
             if (!s->next_proto_negotiated) {
                 *al = TLS1_AD_INTERNAL_ERROR;
                 return 0;
             }
-            memcpy(s->next_proto_negotiated, selected, selected_len);
             s->next_proto_negotiated_len = selected_len;
             s->s3->next_proto_neg_seen = 1;
         }
@@ -2537,12 +2536,11 @@ static int ssl_scan_serverhello_tlsext(SSL *s, unsigned char **p,
             }
             if (s->s3->alpn_selected)
                 OPENSSL_free(s->s3->alpn_selected);
-            s->s3->alpn_selected = OPENSSL_malloc(len);
+            s->s3->alpn_selected = BUF_memdup(data + 3, len);
             if (!s->s3->alpn_selected) {
                 *al = TLS1_AD_INTERNAL_ERROR;
                 return 0;
             }
-            memcpy(s->s3->alpn_selected, data + 3, len);
             s->s3->alpn_selected_len = len;
         }
 # ifndef OPENSSL_NO_HEARTBEATS
-- 
2.2.2



From openssl-users at dukhovni.org  Fri Feb 13 14:52:23 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Feb 2015 14:52:23 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <42d93f316ef54ae5a13e1f0e5c9a41db@ustx2ex-dag1mb4.msg.corp.akamai.com>
References: <8615ae11aa154256a7370a5cee8ae091@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87siecnzdc.fsf@alice.fifthhorseman.net>
 <20150212173949.ekcyYngd%sdaoden@yandex.com>
 <1423814941.2423.8.camel@redhat.com>
 <42d93f316ef54ae5a13e1f0e5c9a41db@ustx2ex-dag1mb4.msg.corp.akamai.com>
Message-ID: <20150213145222.GA1260@mournblade.imrryr.org>

On Fri, Feb 13, 2015 at 11:59:13AM +0000, Salz, Rich wrote:

> > Some time ago, I had submitted a patch which allows administrators, but
> > most importantly OS distributors to set their own strings in the configuration
> > file, which software can then rely on, to provide a consistent security level:
> > https://github.com/openssl/openssl/pull/192
> 
> And my intent is to pull this into master pretty soon.

And applications would need to opt-in to having this new profile
apply, or more usefully need to be able to choose which
application-specific file contains the desired profile.  there's
no such thing as a universal profile that works for all software.

We may not need a patch for this, I thought we were about to deprecate
OpenSSL_config() with its void return status and encourage folks
to use the NCONF API, which should be able to handle this, or be close
in any case.

-- 
	Viktor.

From tshort at akamai.com  Fri Feb 13 15:05:53 2015
From: tshort at akamai.com (Short, Todd)
Date: Fri, 13 Feb 2015 09:05:53 -0600
Subject: [openssl-dev] OpenSSL patches and enhancements from Akamai
References: <8DC096B3-7D12-4C75-9342-2ABEB1942C05@akamai.com>
Message-ID: <3F2B91A2-F3CD-4F59-BD86-9AF55B332E00@akamai.com>

Hello openssl-dev:

We at Akamai have a number of enhancements and fixes for OpenSSL that we would like to contribute. Before I inundate rt at openssl.org<mailto:rt at openssl.org> and openssl-dev mailing lists, I am asking if there?s a desire to provide the changes as one large patch file, or as separate patch files. These have yet to be merged into the latest branch and still have to be formatted to the new coding standards, so they aren?t going to be posted immediately.

A brief description of some of the patches:
* More flexible configuration stanza handling
* Limit memory consumption of secure BNs
* Adding "struct iovec" variants to ssl IO (configurable, disabled by default)
* IPv6 support in s_client/s_server
* Increment ssl session miss counter properly
* Add convenience method to set preferred cipher list
* Add lookups of client sessions from a cache, if so configured
* Rebranding of SSL_ERROR_WANT_X509_LOOKUP as SSL_ERROR_WANT_EVENT, making event type to wait for visible in SSL->rwstate, letting TLS_SRP have its own event type instead of piggybacking on SSL_X509_LOOKUP.
* Add task for decryption of client key exchange response
* Add task for generating client certificate verify message
* Add task for signing of server key exchange message
* Async handling of tlsext servername callback
* Simplify (and improve) the X509 name parsing routine.
* Add short name "Email" to "emailAddress" object (crypto/object*)
* Check x509 store ref counter on free
* Add --preserve-dates option to x509 app
* Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer

Rich Salz (and other Akamai employees) had his hand in a number of these changes.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150213/a9b7901f/attachment.html>

From steve at openssl.org  Fri Feb 13 15:54:50 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 13 Feb 2015 15:54:50 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150213145222.GA1260@mournblade.imrryr.org>
References: <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87siecnzdc.fsf@alice.fifthhorseman.net>
 <20150212173949.ekcyYngd%sdaoden@yandex.com>
 <1423814941.2423.8.camel@redhat.com>
 <42d93f316ef54ae5a13e1f0e5c9a41db@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <20150213145222.GA1260@mournblade.imrryr.org>
Message-ID: <20150213155450.GA15391@openssl.org>

On Fri, Feb 13, 2015, Viktor Dukhovni wrote:

> On Fri, Feb 13, 2015 at 11:59:13AM +0000, Salz, Rich wrote:
> 
> > > Some time ago, I had submitted a patch which allows administrators, but
> > > most importantly OS distributors to set their own strings in the configuration
> > > file, which software can then rely on, to provide a consistent security level:
> > > https://github.com/openssl/openssl/pull/192
> > 
> > And my intent is to pull this into master pretty soon.
> 
> And applications would need to opt-in to having this new profile
> apply, or more usefully need to be able to choose which
> application-specific file contains the desired profile.  there's
> no such thing as a universal profile that works for all software.
> 
> We may not need a patch for this, I thought we were about to deprecate
> OpenSSL_config() with its void return status and encourage folks
> to use the NCONF API, which should be able to handle this, or be close
> in any case.
> 

Just clarification. The initialisation we're recommending I normally refer
to as "config modules". NCONF is a more general API for configuration files.

Config modules were intended to be used for application setup so would
be a good place to add a system cipher string instead of a whole new mechanism.
The only problem is that it would only work with application that supported
config modules.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From openssl-users at dukhovni.org  Fri Feb 13 16:39:18 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 13 Feb 2015 16:39:18 +0000
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150213155450.GA15391@openssl.org>
References: <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87siecnzdc.fsf@alice.fifthhorseman.net>
 <20150212173949.ekcyYngd%sdaoden@yandex.com>
 <1423814941.2423.8.camel@redhat.com>
 <42d93f316ef54ae5a13e1f0e5c9a41db@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <20150213145222.GA1260@mournblade.imrryr.org>
 <20150213155450.GA15391@openssl.org>
Message-ID: <20150213163918.GK1260@mournblade.imrryr.org>

On Fri, Feb 13, 2015 at 03:54:50PM +0000, Dr. Stephen Henson wrote:

> Config modules were intended to be used for application setup so would
> be a good place to add a system cipher string instead of a whole new mechanism.
> The only problem is that it would only work with application that supported
> config modules.

I don't think that's a "problem".  This is a good thing.  We just
need to encourage applications to adopt the use of appropriate
config modules (if that's the right interface).

-- 
	Viktor.

From rt at openssl.org  Fri Feb 13 16:43:09 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Fri, 13 Feb 2015 17:43:09 +0100
Subject: [openssl-dev] [openssl.org #2213] Unable to read Class 3 type CA
	certificates properly using EVP_EncodeUpdate &
	EVP_EncodeFinal functions.
In-Reply-To: <F304558670F8B0439A2804F6920EE23896E6297225@EXCHANGE.persistent.co.in>
References: <RT-Ticket-2213@openssl.org>
 <F304558670F8B0439A2804F6920EE23896E6297225@EXCHANGE.persistent.co.in>
Message-ID: <rt-4.0.4-15204-1423845789-1991.2213-6-0@openssl.org>

Old ticket, cannot reproduce. Please post the code if this is still an issue.
--
Rich Salz, OpenSSL dev team; rsalz at openssl.org


From brian at briansmith.org  Fri Feb 13 17:54:24 2015
From: brian at briansmith.org (Brian Smith)
Date: Fri, 13 Feb 2015 09:54:24 -0800
Subject: [openssl-dev] OpenSSL patches and enhancements from Akamai
In-Reply-To: <3F2B91A2-F3CD-4F59-BD86-9AF55B332E00@akamai.com>
References: <8DC096B3-7D12-4C75-9342-2ABEB1942C05@akamai.com>
 <3F2B91A2-F3CD-4F59-BD86-9AF55B332E00@akamai.com>
Message-ID: <CAFewVt74SYaj2USMvWkFepdVDUGbB6CVD9vtnj1C6pZQmKsuOw@mail.gmail.com>

Very cool.

Short, Todd <tshort at akamai.com> wrote:
> * Check that in matching issuer/subject certs, that a self-signed subject
> also has a self-signed issuer

Could you explain this one? It isn't necessarily the case that a
self-signed subject has a self-signed issuer in PKIX, if I am
understanding you correctly.

Cheers,
Brian

From tortoisesvn at gmail.com  Fri Feb 13 18:20:44 2015
From: tortoisesvn at gmail.com (Stefan Kueng)
Date: Fri, 13 Feb 2015 19:20:44 +0100
Subject: [openssl-dev] [patch] fix allocation in e_capi
Message-ID: <54DE407C.6020903@gmail.com>

Hi,

There's a memory allocation on the stack in engines/e_capi.c which 
allocates only half of the required memory.
This then leads to stack corruption.
Attached a simple and small patch that fixes this.

Stefan
-------------- next part --------------
Index: e_capi.c
===================================================================
--- e_capi.c	(revision 26275)
+++ e_capi.c	(working copy)
@@ -1189,7 +1189,7 @@
         return 0;
     }
     if (sizeof(TCHAR) != sizeof(char))
-        name = alloca(len);
+        name = alloca(len * sizeof(WCHAR));
     else
         name = OPENSSL_malloc(len);
     if (!CryptEnumProviders(idx, NULL, 0, ptype, name, &len)) {

From tortoisesvn at gmail.com  Fri Feb 13 18:31:19 2015
From: tortoisesvn at gmail.com (=?UTF-8?B?U3RlZmFuIEvDvG5n?=)
Date: Fri, 13 Feb 2015 19:31:19 +0100
Subject: [openssl-dev] [patch] fix allocation in e_capi
In-Reply-To: <54DE407C.6020903@gmail.com>
References: <54DE407C.6020903@gmail.com>
Message-ID: <CAH=6jSYe+oUkvGz+m1DzmkV8Vtdo6a-K9W-ObkkeRX2g6OOqOA@mail.gmail.com>

>
> Hi,
>
> There's a memory allocation on the stack in engines/e_capi.c which
> allocates only half of the required memory.
> This then leads to stack corruption.
> Attached a simple and small patch that fixes this.


Sorry, false alarm.
'len' is already in bytes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150213/2bc4e9a9/attachment-0001.html>

From rt at openssl.org  Fri Feb 13 19:01:20 2015
From: rt at openssl.org (Dmitry Belyavsky via RT)
Date: Fri, 13 Feb 2015 20:01:20 +0100
Subject: [openssl-dev] [openssl.org #3702] openssl verify improvement
In-Reply-To: <CADqLbz+pX91ZppvNeztwrnSD11prUHxUUO5B+hx6nJOA2BC-7w@mail.gmail.com>
References: <RT-Ticket-3702@openssl.org>
 <CADqLbz+pX91ZppvNeztwrnSD11prUHxUUO5B+hx6nJOA2BC-7w@mail.gmail.com>
Message-ID: <rt-4.0.4-30081-1423854080-1586.3702-21-0@openssl.org>

Hello openssl team,

here is the patch providing -nameopt option to the openssl verify command.
It makes possible to print certificate subject correctly in case of error.

Thank you.

-- 
SY, Dmitry Belyavsky

-------------- next part --------------
--- ../openssl-1.0.1i/apps/verify.c	2014-08-07 01:10:56.000000000 +0400
+++ apps/verify.c	2015-02-13 20:53:00.202406546 +0300
@@ -74,6 +74,7 @@
 		STACK_OF(X509) *uchain, STACK_OF(X509) *tchain,
 		STACK_OF(X509_CRL) *crls, ENGINE *e);
 static int v_verbose=0, vflags = 0;
+static unsigned long nmflag = 0;
 
 int MAIN(int, char **);
 
@@ -145,6 +146,11 @@
 				if (argc-- < 1) goto end;
 				crlfile= *(++argv);
 				}
+			else if (strcmp(*argv,"-nameopt") == 0)
+				{
+				if (--argc < 1) goto end;
+				if (!set_name_ex(&nmflag, *(++argv))) goto end;
+				}
 #ifndef OPENSSL_NO_ENGINE
 			else if (strcmp(*argv,"-engine") == 0)
 				{
@@ -317,9 +323,10 @@
 		{
 		if (current_cert)
 			{
+			nmflag = nmflag ? nmflag : XN_FLAG_ONELINE;
 			X509_NAME_print_ex_fp(stdout,
 				X509_get_subject_name(current_cert),
-				0, XN_FLAG_ONELINE);
+				0, nmflag);
 			printf("\n");
 			}
 		printf("%serror %d at %d depth lookup:%s\n",

From rsalz at akamai.com  Fri Feb 13 21:11:25 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 13 Feb 2015 21:11:25 +0000
Subject: [openssl-dev] Akamai is hiring
Message-ID: <c85defc1e1d04d1a88274fa6a98ef63b@ustx2ex-dag1mb4.msg.corp.akamai.com>

We're looking for one or two full-time OpenSSL developers.  One job must be in Cambridge, MA; the other has more flexibility.

If you are interested, contact me off-list.

--
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me<mailto:rsalz at jabber.me> Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150213/1e300477/attachment.html>

From BenBE at geshi.org  Sat Feb 14 12:05:48 2015
From: BenBE at geshi.org (Benny Baumann)
Date: Sat, 14 Feb 2015 13:05:48 +0100
Subject: [openssl-dev] Fwd: Problem with encoding a CRL's signing algorithm
In-Reply-To: <54DB2525.3000300@dogcraft.de>
References: <54DB2525.3000300@dogcraft.de>
Message-ID: <54DF3A1C.8010106@geshi.org>

Hi,

I think there is somewhat strange behaviour in OpenSSL that causes
interesting bugs to happen when trying to encode CRLs based on deltas.
More information about the issue (causing a segfault under certain
conditions) is in the attached mail by Felix who discovered it.

Regards,
BenBE.
-------------- next part --------------
An embedded message was scrubbed...
From: =?UTF-8?B?RmVsaXggRMO2cnJl?= <felix at dogcraft.de>
Subject: Problem with encoding a CRL's signing algorithm
Date: Wed, 11 Feb 2015 10:47:17 +0100
Size: 5922
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150214/fa3b2b27/attachment.eml>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150214/fa3b2b27/attachment.sig>

From kurt at roeckx.be  Sat Feb 14 15:04:24 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 14 Feb 2015 16:04:24 +0100
Subject: [openssl-dev] OpenSSL patches and enhancements from Akamai
In-Reply-To: <3F2B91A2-F3CD-4F59-BD86-9AF55B332E00@akamai.com>
References: <8DC096B3-7D12-4C75-9342-2ABEB1942C05@akamai.com>
 <3F2B91A2-F3CD-4F59-BD86-9AF55B332E00@akamai.com>
Message-ID: <20150214150424.GA10526@roeckx.be>

On Fri, Feb 13, 2015 at 09:05:53AM -0600, Short, Todd wrote:
> Hello openssl-dev:
> 
> We at Akamai have a number of enhancements and fixes for OpenSSL that we would like to contribute. Before I inundate rt at openssl.org<mailto:rt at openssl.org> and openssl-dev mailing lists, I am asking if there's a desire to provide the changes as one large patch file, or as separate patch files. These have yet to be merged into the latest branch and still have to be formatted to the new coding standards, so they aren't going to be posted immediately.

Do not send 1 large patch.  I suggest an RT ticket per issue.  But
you might think about spreading that out over time.

> * IPv6 support in s_client/s_server

No need to submit this, there are already a few of those and I'm
working on something more general for IPv6 support.

> * Add task for decryption of client key exchange response
> * Add task for generating client certificate verify message
> * Add task for signing of server key exchange message

Can you explain this a little more?


Kurt


From rsalz at akamai.com  Sat Feb 14 16:17:17 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 14 Feb 2015 16:17:17 +0000
Subject: [openssl-dev] OpenSSL patches and enhancements from Akamai
In-Reply-To: <20150214150424.GA10526@roeckx.be>
References: <8DC096B3-7D12-4C75-9342-2ABEB1942C05@akamai.com>
 <3F2B91A2-F3CD-4F59-BD86-9AF55B332E00@akamai.com>
 <20150214150424.GA10526@roeckx.be>
Message-ID: <1b6d95db1f174117a5606f0b289dfc97@ustx2ex-dag1mb4.msg.corp.akamai.com>


> > * Add task for decryption of client key exchange response
> > * Add task for generating client certificate verify message
> > * Add task for signing of server key exchange message
> 
> Can you explain this a little more?

I can.  I mentioned this on the -team mailing list.  The idea is that an application can register callbacks so that CPU-intensive intructions, RSA and ECC ops for now, can get spun off into a separate thread.  The top-level SSL_accept/connect return a new error code "not ready yet" and then can poll or wait for the background processor to tell the main thread it's ready, etc.

Again referring to internal knowledge, this might be moot.  But it might be a quick win for some of downstream distro's ...

From sdaoden at yandex.com  Sat Feb 14 21:00:29 2015
From: sdaoden at yandex.com (Steffen Nurpmeso)
Date: Sat, 14 Feb 2015 22:00:29 +0100
Subject: [openssl-dev] Proposed cipher changes for post-1.0.2
In-Reply-To: <20150213155450.GA15391@openssl.org>
References: <20150210235204.GE12867@mournblade.imrryr.org>
 <c89fa16ac68f4d9eb404ccd8db49b4f7@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <20150211061108.GQ12867@mournblade.imrryr.org>
 <20150211063759.GS12867@mournblade.imrryr.org>
 <608b4da834594213913fab51883bab00@ustx2ex-dag1mb2.msg.corp.akamai.com>
 <87siecnzdc.fsf@alice.fifthhorseman.net>
 <20150212173949.ekcyYngd%sdaoden@yandex.com>
 <1423814941.2423.8.camel@redhat.com>
 <42d93f316ef54ae5a13e1f0e5c9a41db@ustx2ex-dag1mb4.msg.corp.akamai.com>
 <20150213145222.GA1260@mournblade.imrryr.org>
 <20150213155450.GA15391@openssl.org>
Message-ID: <20150214210029.xvyPk5gc%sdaoden@yandex.com>

Hello,

"Dr. Stephen Henson" <steve at openssl.org> wrote:
 |On Fri, Feb 13, 2015, Viktor Dukhovni wrote:
 |> On Fri, Feb 13, 2015 at 11:59:13AM +0000, Salz, Rich wrote:
 |>>> Some time ago, I had submitted a patch which allows administrators, but
 |>>> most importantly OS distributors to set their own strings \
 |>>> in the configuration

 |>> And my intent is to pull this into master pretty soon.

 |> We may not need a patch for this, I thought we were about to deprecate
 |> OpenSSL_config() with its void return status and encourage folks

 |Just clarification. The initialisation we're recommending I normally refer
 |to as "config modules". NCONF is a more general API for configuration files.

I think an interesting question would be wether that configuration
API will eventually obsolete the direct function interface?

 |Config modules were intended to be used for application setup so would
 |be a good place to add a system cipher string instead of a \
 |whole new mechanism.
 |The only problem is that it would only work with application that supported
 |config modules.

So break API compatibility and extend the mandatory
SSL_library_init() to incorporate the functionality of
CONF_modules_load_file(), introducing a SSL_library_free()
counterpart?
Or don't break compatibility and let SSL_library_init() internally
do OPENSSL_config() unless OPENSSL_INIT_DONT_LOAD_CONF is defined?
Or ditto but introduce a new SSL_library_init_with_conf() with an
SSL_library_free_with_conf(), too.
It will be very interesting to see how you will overcome that
deadlocked situation.
Have a nice weekend.

--steffen

From normw at gknw.net  Sat Feb 14 22:57:58 2015
From: normw at gknw.net (NormW)
Date: Sun, 15 Feb 2015 09:57:58 +1100
Subject: [openssl-dev] ossl-1.0.2 needs a tweak for CodeWarrior4
Message-ID: <54DFD2F6.7090000@gknw.net>

G/Morning,
Found 1.0.2\crypto\rand\rand_nw.c needs a tweak for CW4 to compile:

--- rand_nw.c.orig	2015-01-23 01:58:32.000000000 +1100
+++ rand_nw.c	2015-01-28 14:33:04.187500000 +1100
@@ -155,8 +155,11 @@

      for (i = 2; i < ENTROPY_NEEDED; i++) {
  # ifdef __MWERKS__
-        asm {
-        rdtsc mov tsc, eax}
+      asm
+      {
+         rdtsc
+         mov tsc, eax
+      }
  # elif defined(__GNUC__) && __GNUC__>=2 && !defined(OPENSSL_NO_ASM) &&
!defined(OPENSSL_NO_INLINE_ASM)
          asm volatile ("rdtsc":"=a" (tsc)::"edx");
  # endif

The acceptable format is the same as 1.0.1l, so no idea where the 1.0.2
version came from, unless done by hand. Otherwise 1.0.2 builds without
issue.

Norm



From dwmw2 at infradead.org  Mon Feb 16 10:28:17 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 16 Feb 2015 10:28:17 +0000
Subject: [openssl-dev] 1.0.2 regression with Cisco DTLS_BAD_VER
Message-ID: <1424082497.1804.26.camel@infradead.org>

Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
from dtls1_buffer_message() which was needed to distinguish between DTLS
1.x and Cisco's pre-standard version of DTLS.

$DEITY knows why Cisco haven't moved to the standard version of DTLS by
now. The RFC was published in 2006, and since you can tell the
difference on the wire it's *trivial* to have the server accept both and
upgrade the clients piecemeal. The ocserv server manages this.

But it isn't our place to marvel at Cisco's incompetence (like the fact
that their DTLS implementation is still dropping out-of-order received
packets, 6? years after I fixed RT#1752). Our place is to try to be
compatible with it. And this commit broke that, causing the OpenConnect
VPN client to abort:

Connected vpntest0 as 192.168.1.13, using SSL
d1_both.c(1112): OpenSSL internal error, assertion failed: s->d1->w_msg_hdr.msg_len + DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num
Aborted (core dumped)

---
The patch below fixes it. Tested in 1.0.2, but I haven't tested with
HEAD yet because I need to work out how to set up the DTLS session to be
"resumed" ? none of this compiles any more...

../dtls.c: In function 'start_dtls_handshake':
../dtls.c:141:24: error: dereferencing pointer to incomplete type
   vpninfo->dtls_session->ssl_version = 0x0100; /* DTLS1_BAD_VER */
                        ^
../dtls.c:145:23: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->master_key_length = sizeof(vpninfo->dtls_secret);
                       ^
../dtls.c:146:30: error: dereferencing pointer to incomplete type
  memcpy(vpninfo->dtls_session->master_key, vpninfo->dtls_secret,
                              ^
../dtls.c:149:23: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->session_id_length = sizeof(vpninfo->dtls_session_id);
                       ^
../dtls.c:150:30: error: dereferencing pointer to incomplete type
  memcpy(vpninfo->dtls_session->session_id, vpninfo->dtls_session_id,
                              ^
../dtls.c:170:23: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->cipher = dtls_cipher;
                       ^
../dtls.c:171:23: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->cipher_id = dtls_cipher->id;
                       ^
../dtls.c:171:48: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->cipher_id = dtls_cipher->id;

diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index 2553c3d..1116416 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -1108,8 +1108,9 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
     memcpy(frag->fragment, s->init_buf->data, s->init_num);
 
     if (is_ccs) {
+	/* For DTLS_BAD_VER the header length is non-standard */
         OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
-                       DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num);
+                       ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s->init_num);
     } else {
         OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
                        DTLS1_HM_HEADER_LENGTH == (unsigned int)s->init_num);


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150216/a693c8b3/attachment.bin>

From dwmw2 at infradead.org  Mon Feb 16 12:45:41 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 16 Feb 2015 12:45:41 +0000
Subject: [openssl-dev] OpenSSL HEAD breaks OpenConnect VPN client
Message-ID: <1424090741.1804.39.camel@infradead.org>

The Cisco AnyConnect VPN protocol establishes a connection over HTTPS
and negotiates parameters (cipher, master secret & session ID) for a
DTLS connection which is then "resumed".

The OpenConnect VPN client handles this by using SSL_SESSION_new(),
manually setting the appropriate fields in the structure, and then using
SSL_set_session(). This code can be seen at
http://git.infradead.org/users/dwmw2/openconnect.git/blob/fa5cea08:/dtls.c#l147

Commit b6ba401497 in OpenSSL broke this, because the SSL_SESSION became
opaque ? with no alternative method that I can see to do what's needed.

I played with manually creating the ASN.1 representation of a session
and feeding it to d2i_SSL_SESSION() but that fails because ssl_version
is 0x100 (DTLS1_BAD_VER) and d2i_SSL_SESSION() only works if the SSL
version major is >= SSL3_VERSION_MAJOR.

So I'm going to need to fix *something* in OpenSSL HEAD to make this
work again. Should I do the minimal "fix" to make d2i_SSL_SESSION() work
for DTLS1_BAD_VER, or introduce a new API for setting the fields we need
to fake a session resume?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150216/d81c5d91/attachment.bin>

From matt at openssl.org  Mon Feb 16 13:25:08 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Feb 2015 13:25:08 +0000
Subject: [openssl-dev] OpenSSL HEAD breaks OpenConnect VPN client
In-Reply-To: <1424090741.1804.39.camel@infradead.org>
References: <1424090741.1804.39.camel@infradead.org>
Message-ID: <54E1EFB4.2060403@openssl.org>



On 16/02/15 12:45, David Woodhouse wrote:
> The Cisco AnyConnect VPN protocol establishes a connection over HTTPS
> and negotiates parameters (cipher, master secret & session ID) for a
> DTLS connection which is then "resumed".
> 
> The OpenConnect VPN client handles this by using SSL_SESSION_new(),
> manually setting the appropriate fields in the structure, and then using
> SSL_set_session(). This code can be seen at
> http://git.infradead.org/users/dwmw2/openconnect.git/blob/fa5cea08:/dtls.c#l147
> 
> Commit b6ba401497 in OpenSSL broke this, because the SSL_SESSION became
> opaque ? with no alternative method that I can see to do what's needed.
> 
> I played with manually creating the ASN.1 representation of a session
> and feeding it to d2i_SSL_SESSION() but that fails because ssl_version
> is 0x100 (DTLS1_BAD_VER) and d2i_SSL_SESSION() only works if the SSL
> version major is >= SSL3_VERSION_MAJOR.

That sounds like a bug. I can't think of a reason why this should
exclude DTLS.

> 
> So I'm going to need to fix *something* in OpenSSL HEAD to make this
> work again. Should I do the minimal "fix" to make d2i_SSL_SESSION() work
> for DTLS1_BAD_VER, or introduce a new API for setting the fields we need
> to fake a session resume?
> 

What fields do you need access to? It would be good if you could
document them on the wiki page here:
https://wiki.openssl.org/index.php/1.1_API_Changes

Send an email to wiki-admin at opensslfoundation.com with your preferred
username and I can set you up with access.

Matt



From foleyj at cisco.com  Mon Feb 16 13:39:53 2015
From: foleyj at cisco.com (John Foley)
Date: Mon, 16 Feb 2015 08:39:53 -0500
Subject: [openssl-dev] 1.0.2 regression with Cisco DTLS_BAD_VER
In-Reply-To: <1424082497.1804.26.camel@infradead.org>
References: <1424082497.1804.26.camel@infradead.org>
Message-ID: <54E1F329.8080909@cisco.com>

Which Cisco product are you using, the ASA?  What version of software do
you have on the product?  While I can't speak for all Cisco products, I
can confirm that many Cisco products are using OpenSSL 1.0.1, which
implies support for DTLS 1.0. If you care to share more details, I can
try to engage the product team to better understand this.



On 02/16/2015 05:28 AM, David Woodhouse wrote:
> Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
> from dtls1_buffer_message() which was needed to distinguish between DTLS
> 1.x and Cisco's pre-standard version of DTLS.
>
> $DEITY knows why Cisco haven't moved to the standard version of DTLS by
> now. The RFC was published in 2006, and since you can tell the
> difference on the wire it's *trivial* to have the server accept both and
> upgrade the clients piecemeal. The ocserv server manages this.
>
> But it isn't our place to marvel at Cisco's incompetence (like the fact
> that their DTLS implementation is still dropping out-of-order received
> packets, 6? years after I fixed RT#1752). Our place is to try to be
> compatible with it. And this commit broke that, causing the OpenConnect
> VPN client to abort:
>
> Connected vpntest0 as 192.168.1.13, using SSL
> d1_both.c(1112): OpenSSL internal error, assertion failed: s->d1->w_msg_hdr.msg_len + DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num
> Aborted (core dumped)
>
> ---
> The patch below fixes it. Tested in 1.0.2, but I haven't tested with
> HEAD yet because I need to work out how to set up the DTLS session to be
> "resumed" ? none of this compiles any more...
>
> ../dtls.c: In function 'start_dtls_handshake':
> ../dtls.c:141:24: error: dereferencing pointer to incomplete type
>    vpninfo->dtls_session->ssl_version = 0x0100; /* DTLS1_BAD_VER */
>                         ^
> ../dtls.c:145:23: error: dereferencing pointer to incomplete type
>   vpninfo->dtls_session->master_key_length = sizeof(vpninfo->dtls_secret);
>                        ^
> ../dtls.c:146:30: error: dereferencing pointer to incomplete type
>   memcpy(vpninfo->dtls_session->master_key, vpninfo->dtls_secret,
>                               ^
> ../dtls.c:149:23: error: dereferencing pointer to incomplete type
>   vpninfo->dtls_session->session_id_length = sizeof(vpninfo->dtls_session_id);
>                        ^
> ../dtls.c:150:30: error: dereferencing pointer to incomplete type
>   memcpy(vpninfo->dtls_session->session_id, vpninfo->dtls_session_id,
>                               ^
> ../dtls.c:170:23: error: dereferencing pointer to incomplete type
>   vpninfo->dtls_session->cipher = dtls_cipher;
>                        ^
> ../dtls.c:171:23: error: dereferencing pointer to incomplete type
>   vpninfo->dtls_session->cipher_id = dtls_cipher->id;
>                        ^
> ../dtls.c:171:48: error: dereferencing pointer to incomplete type
>   vpninfo->dtls_session->cipher_id = dtls_cipher->id;
>
> diff --git a/ssl/d1_both.c b/ssl/d1_both.c
> index 2553c3d..1116416 100644
> --- a/ssl/d1_both.c
> +++ b/ssl/d1_both.c
> @@ -1108,8 +1108,9 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
>      memcpy(frag->fragment, s->init_buf->data, s->init_num);
>  
>      if (is_ccs) {
> +	/* For DTLS_BAD_VER the header length is non-standard */
>          OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
> -                       DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num);
> +                       ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s->init_num);
>      } else {
>          OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
>                         DTLS1_HM_HEADER_LENGTH == (unsigned int)s->init_num);
>
>
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150216/2845b9bf/attachment.html>

From dwmw2 at infradead.org  Mon Feb 16 14:16:15 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 16 Feb 2015 14:16:15 -0000
Subject: [openssl-dev] OpenSSL HEAD breaks OpenConnect VPN client
In-Reply-To: <54E1EFB4.2060403@openssl.org>
References: <1424090741.1804.39.camel@infradead.org>
 <54E1EFB4.2060403@openssl.org>
Message-ID: <9bdfc71673f09f0e35d7eb6819d1d0b7.squirrel@twosheds.infradead.org>


>> I played with manually creating the ASN.1 representation of a session
>> and feeding it to d2i_SSL_SESSION() but that fails because ssl_version
>> is 0x100 (DTLS1_BAD_VER) and d2i_SSL_SESSION() only works if the SSL
>> version major is >= SSL3_VERSION_MAJOR.
>
> That sounds like a bug. I can't think of a reason why this should
> exclude DTLS.

Note it accepts DTLS, just not Cisco's DTLS1_BAD_VER abomination.

>>
>> So I'm going to need to fix *something* in OpenSSL HEAD to make this
>> work again. Should I do the minimal "fix" to make d2i_SSL_SESSION() work
>> for DTLS1_BAD_VER, or introduce a new API for setting the fields we need
>> to fake a session resume?
>>
>
> What fields do you need access to?

Basically just SSL version, cipher, master secret and session ID. Enough
to fake "resuming" a session that never really existed.

-- 
dwmw2


From openssl-users at dukhovni.org  Mon Feb 16 15:29:35 2015
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 16 Feb 2015 15:29:35 +0000
Subject: [openssl-dev] OpenSSL HEAD breaks OpenConnect VPN client
In-Reply-To: <9bdfc71673f09f0e35d7eb6819d1d0b7.squirrel@twosheds.infradead.org>
References: <1424090741.1804.39.camel@infradead.org>
 <54E1EFB4.2060403@openssl.org>
 <9bdfc71673f09f0e35d7eb6819d1d0b7.squirrel@twosheds.infradead.org>
Message-ID: <20150216152935.GO1260@mournblade.imrryr.org>

On Mon, Feb 16, 2015 at 02:16:15PM -0000, David Woodhouse wrote:

> > What fields do you need access to?
> 
> Basically just SSL version, cipher, master secret and session ID. Enough
> to fake "resuming" a session that never really existed.

Does the constructed DTLS session re-use the parameters of the
original TLS session from HTTPS?  If so, it might suffice to run
i2d_SSL_SESSION on the TLS session, later thaw it with d2i_SSL_SESSION
and then change just enough to turn that into a DTLS session (is
just changing s->version enough?).

Constructing everything by hand seems like too much work, and
likely too much for the API to expose.

-- 
	Viktor.

From dwmw2 at infradead.org  Mon Feb 16 15:39:49 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 16 Feb 2015 15:39:49 -0000
Subject: [openssl-dev] OpenSSL HEAD breaks OpenConnect VPN client
In-Reply-To: <20150216152935.GO1260@mournblade.imrryr.org>
References: <1424090741.1804.39.camel@infradead.org>
 <54E1EFB4.2060403@openssl.org>
 <9bdfc71673f09f0e35d7eb6819d1d0b7.squirrel@twosheds.infradead.org>
 <20150216152935.GO1260@mournblade.imrryr.org>
Message-ID: <fa5095d73b94df5c2fcc143948c638bc.squirrel@twosheds.infradead.org>


> On Mon, Feb 16, 2015 at 02:16:15PM -0000, David Woodhouse wrote:
>
>> > What fields do you need access to?
>>
>> Basically just SSL version, cipher, master secret and session ID. Enough
>> to fake "resuming" a session that never really existed.
>
> Does the constructed DTLS session re-use the parameters of the
> original TLS session from HTTPS?  If so, it might suffice to run
> i2d_SSL_SESSION on the TLS session, later thaw it with d2i_SSL_SESSION
> and then change just enough to turn that into a DTLS session (is
> just changing s->version enough?).

No. The parameters for the DTLS session are entirely separate. I could
relatively easily construct the corresponding ASN.1 if I fix the fact that
d2i_SSL_SESSION() breaks on the ssl_version I need. If that's considered
to be a reasonable (ab)use of the API.


-- 
dwmw2


From krzysiek at leeds.pl  Mon Feb 16 15:29:36 2015
From: krzysiek at leeds.pl (Krzysztof Kwiatkowski)
Date: Mon, 16 Feb 2015 16:29:36 +0100
Subject: [openssl-dev] =?utf-8?q?Constness_in_SSL=5FCTX=5Fset=5Fsrp=5Fuser?=
 =?utf-8?q?name_and_SSL=5FCTX=5Fset=5Fsrp=5Fpassword_functions?=
In-Reply-To: <9bdfc71673f09f0e35d7eb6819d1d0b7.squirrel@twosheds.infradead.org>
References: <1424090741.1804.39.camel@infradead.org>
 <54E1EFB4.2060403@openssl.org>
 <9bdfc71673f09f0e35d7eb6819d1d0b7.squirrel@twosheds.infradead.org>
Message-ID: <ac418786dd0abe404fe183db0bcd535a@flogreenserver.dyndns.org>

Hi,

Currently SSL_CTX_set_srp_username/password functions take char* 
argument for username/password value. In an application level code those 
values are very often const (user provided data). In such cases, when 
passing those values to OpenSSL library either dirty cast needs to be 
performed to remove constness, or const value needs to be copied to 
temporary location (which for SSL_CTX_set_srp_username is useless as 
this function copies again username value in ssl3_ctx_ctrl function).

I've submitted pull request https://github.com/openssl/openssl/pull/227 
, when I try to cleanup API, so that const values also can be passed to 
functions. Please integrate if interested.

Kris


From kurt at roeckx.be  Mon Feb 16 17:26:47 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Mon, 16 Feb 2015 18:26:47 +0100
Subject: [openssl-dev] Constness in SSL_CTX_set_srp_username and
 SSL_CTX_set_srp_password functions
In-Reply-To: <ac418786dd0abe404fe183db0bcd535a@flogreenserver.dyndns.org>
References: <1424090741.1804.39.camel@infradead.org>
 <54E1EFB4.2060403@openssl.org>
 <9bdfc71673f09f0e35d7eb6819d1d0b7.squirrel@twosheds.infradead.org>
 <ac418786dd0abe404fe183db0bcd535a@flogreenserver.dyndns.org>
Message-ID: <20150216172647.GB12508@roeckx.be>

On Mon, Feb 16, 2015 at 04:29:36PM +0100, Krzysztof Kwiatkowski wrote:
> Hi,
> 
> Currently SSL_CTX_set_srp_username/password functions take char* argument
> for username/password value. In an application level code those values are
> very often const (user provided data). In such cases, when passing those
> values to OpenSSL library either dirty cast needs to be performed to remove
> constness, or const value needs to be copied to temporary location (which
> for SSL_CTX_set_srp_username is useless as this function copies again
> username value in ssl3_ctx_ctrl function).
> 
> I've submitted pull request https://github.com/openssl/openssl/pull/227 ,
> when I try to cleanup API, so that const values also can be passed to
> functions. Please integrate if interested.

Please send this to rt at openssl.org so that we can keep track of
it.


Kurt


From dwmw2 at infradead.org  Mon Feb 16 17:33:15 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 16 Feb 2015 17:33:15 +0000
Subject: [openssl-dev] OpenSSL HEAD breaks OpenConnect VPN client
In-Reply-To: <54E1EFB4.2060403@openssl.org>
References: <1424090741.1804.39.camel@infradead.org>
 <54E1EFB4.2060403@openssl.org>
Message-ID: <1424107995.1804.46.camel@infradead.org>

On Mon, 2015-02-16 at 13:25 +0000, Matt Caswell wrote:
> That sounds like a bug. I can't think of a reason why this should
> exclude DTLS.

This fixes it to work with DTLS1_BAD_VER too:

diff --git a/ssl/ssl_asn1.c b/ssl/ssl_asn1.c
index 3eaee1d..6e20a1f 100644
--- a/ssl/ssl_asn1.c
+++ b/ssl/ssl_asn1.c
@@ -396,7 +396,8 @@ SSL_SESSION *d2i_SSL_SESSION(SSL_SESSION **a, const unsigned char **pp,
     os.data = NULL;
     os.length = 0;
     M_ASN1_D2I_get_x(ASN1_OCTET_STRING, osp, d2i_ASN1_OCTET_STRING);
-    if ((ssl_version >> 8) >= SSL3_VERSION_MAJOR) {
+    if ((ssl_version >> 8) >= SSL3_VERSION_MAJOR ||
+	ssl_version == DTLS1_BAD_VER) {
         if (os.length != 2) {
             c.error = SSL_R_CIPHER_CODE_WRONG_LENGTH;
             c.line = __LINE__;

> > So I'm going to need to fix *something* in OpenSSL HEAD to make this
> > work again. Should I do the minimal "fix" to make d2i_SSL_SESSION() work
> > for DTLS1_BAD_VER, or introduce a new API for setting the fields we need
> > to fake a session resume?
> > 
> 
> What fields do you need access to? It would be good if you could
> document them on the wiki page here:
> https://wiki.openssl.org/index.php/1.1_API_Changes

I've updated
https://wiki.openssl.org/index.php/1.1_API_Changes#Things_that_Broke_in_OpenConnect

I can either update my code to create the ASN.1 for itself and use
d2i_SSL_SESSION() relying on the patch above, or I can implement the
'alternative' new function if that's preferred.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150216/a175c960/attachment-0001.bin>

From matt at openssl.org  Mon Feb 16 20:23:50 2015
From: matt at openssl.org (Matt Caswell)
Date: Mon, 16 Feb 2015 20:23:50 +0000
Subject: [openssl-dev] OpenSSL HEAD breaks OpenConnect VPN client
In-Reply-To: <1424107995.1804.46.camel@infradead.org>
References: <1424090741.1804.39.camel@infradead.org>	
 <54E1EFB4.2060403@openssl.org> <1424107995.1804.46.camel@infradead.org>
Message-ID: <54E251D6.1060305@openssl.org>



On 16/02/15 17:33, David Woodhouse wrote:
> On Mon, 2015-02-16 at 13:25 +0000, Matt Caswell wrote:
>> That sounds like a bug. I can't think of a reason why this should
>> exclude DTLS.
> 
> This fixes it to work with DTLS1_BAD_VER too:
> 
> diff --git a/ssl/ssl_asn1.c b/ssl/ssl_asn1.c
> index 3eaee1d..6e20a1f 100644
> --- a/ssl/ssl_asn1.c
> +++ b/ssl/ssl_asn1.c
> @@ -396,7 +396,8 @@ SSL_SESSION *d2i_SSL_SESSION(SSL_SESSION **a, const unsigned char **pp,
>      os.data = NULL;
>      os.length = 0;
>      M_ASN1_D2I_get_x(ASN1_OCTET_STRING, osp, d2i_ASN1_OCTET_STRING);
> -    if ((ssl_version >> 8) >= SSL3_VERSION_MAJOR) {
> +    if ((ssl_version >> 8) >= SSL3_VERSION_MAJOR ||
> +	ssl_version == DTLS1_BAD_VER) {
>          if (os.length != 2) {
>              c.error = SSL_R_CIPHER_CODE_WRONG_LENGTH;
>              c.line = __LINE__;
> 
>>> So I'm going to need to fix *something* in OpenSSL HEAD to make this
>>> work again. Should I do the minimal "fix" to make d2i_SSL_SESSION() work
>>> for DTLS1_BAD_VER, or introduce a new API for setting the fields we need
>>> to fake a session resume?
>>>
>>
>> What fields do you need access to? It would be good if you could
>> document them on the wiki page here:
>> https://wiki.openssl.org/index.php/1.1_API_Changes
> 
> I've updated
> https://wiki.openssl.org/index.php/1.1_API_Changes#Things_that_Broke_in_OpenConnect
> 
> I can either update my code to create the ASN.1 for itself and use
> d2i_SSL_SESSION() relying on the patch above, or I can implement the
> 'alternative' new function if that's preferred.
> 

Ok. Thanks. I'll take a look at this and see what can be done.

Matt

From tshort at akamai.com  Tue Feb 17 15:09:26 2015
From: tshort at akamai.com (Short, Todd)
Date: Tue, 17 Feb 2015 09:09:26 -0600
Subject: [openssl-dev] OpenSSL patches and enhancements from Akamai
In-Reply-To: <CAFewVt74SYaj2USMvWkFepdVDUGbB6CVD9vtnj1C6pZQmKsuOw@mail.gmail.com>
References: <8DC096B3-7D12-4C75-9342-2ABEB1942C05@akamai.com>
 <3F2B91A2-F3CD-4F59-BD86-9AF55B332E00@akamai.com>
 <CAFewVt74SYaj2USMvWkFepdVDUGbB6CVD9vtnj1C6pZQmKsuOw@mail.gmail.com>
Message-ID: <93387191-B1AB-4A0E-970C-1F36E2DE1DE3@akamai.com>

Hi Brian:

Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

On Feb 13, 2015, at 12:54 PM, Brian Smith <brian at briansmith.org<mailto:brian at briansmith.org>> wrote:

Very cool.

Short, Todd <tshort at akamai.com<mailto:tshort at akamai.com>> wrote:
* Check that in matching issuer/subject certs, that a self-signed subject
also has a self-signed issuer

Could you explain this one? It isn't necessarily the case that a
self-signed subject has a self-signed issuer in PKIX, if I am
understanding you correctly.

Cheers,
Brian
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/daa2724b/attachment.html>

From dwmw2 at infradead.org  Tue Feb 17 16:21:45 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 17 Feb 2015 16:21:45 +0000
Subject: [openssl-dev] 1.0.2 regression with Cisco DTLS_BAD_VER
In-Reply-To: <1424082497.1804.26.camel@infradead.org>
References: <1424082497.1804.26.camel@infradead.org>
Message-ID: <1424190105.2444.54.camel@infradead.org>

(Dropping rt@ from Cc as it doesn't seem to be working any more).

On Mon, 2015-02-16 at 10:28 +0000, David Woodhouse wrote:
> Connected vpntest0 as 192.168.1.13, using SSL
> d1_both.c(1112): OpenSSL internal error, assertion failed:
> s->d1->w_msg_hdr.msg_len + DTLS1_CCS_HEADER_LENGTH == (unsigned
> int)s->init_num
> Aborted (core dumped)
> 
> ---
> The patch below fixes it. Tested in 1.0.2,

Hm, that was tested against ocserv?, not an actual Cisco ASA. That uses
GnuTLS, which doesn't care too much about the version number in the
ClientHello when it's told to use Cisco DTLS compatibility mode.

The Cisco ASA, on the other hand, is offended by a change in commit
741c9959. In switching from dtls1_client_hello() to the more generic
ssl3_client_hello() we now end up putting ssl->client_version on the
wire instead of ssl->version.

This fixes it for OpenSSL 1.0.2 and HEAD, but I'm not sure if it's
entirely correct. And if it is, do we need to be setting
s->client_version in any of the other cases too?

diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 2845757..1f10054 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -270,7 +270,7 @@ void dtls1_clear(SSL *s)
 
     ssl3_clear(s);
     if (s->options & SSL_OP_CISCO_ANYCONNECT)
-        s->version = DTLS1_BAD_VER;
+        s->client_version = s->version = DTLS1_BAD_VER;
     else if (s->method->version == DTLS_ANY_VERSION)
         s->version = DTLS1_2_VERSION;
     else


-- 
dwmw2
? http://www.infradead.org/ocserv/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/b0d2bf95/attachment.bin>

From dwmw2 at infradead.org  Tue Feb 17 16:35:24 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 17 Feb 2015 16:35:24 +0000
Subject: [openssl-dev] 1.0.2 regression with Cisco DTLS_BAD_VER
In-Reply-To: <54E1F329.8080909@cisco.com>
References: <1424082497.1804.26.camel@infradead.org>
 <54E1F329.8080909@cisco.com>
Message-ID: <1424190924.2444.66.camel@infradead.org>

(A more complete response than my initial mobile reply yesterday)

On Mon, 2015-02-16 at 08:39 -0500, John Foley wrote:
> Which Cisco product are you using, the ASA?  What version of software
> do you have on the product?  While I can't speak for all Cisco
> products, I can confirm that many Cisco products are using OpenSSL
> 1.0.1, which implies support for DTLS 1.0. If you care to share more
> details, I can try to engage the product team to better understand
> this.

The so-called DTLS1_BAD_VER that AnyConnect still uses is actually a
snapshot of the DTLS protocol from around OpenSSL 0.9.8e before it was
standardised ? with *some* but not all of the later modifications
backported.

Even new versions of OpenSSL still support it, to a certain extent. So
just because you've updated to OpenSSL 1.0.1, that doesn't necessarily
mean you've updated to DTLS 1.0. You *could*, but as far I can tell you
haven't.

I really wish you *would*, because the old protocol has a tendency to
break when people don't really account for it while "cleaning up" the
code. Hence RT#2984 when it broke in various previous releases of
OpenSSL, and the three patches I've just sent to fix 1.0.2 and HEAD:
https://mta.openssl.org/pipermail/openssl-dev/2015-February/000698.html
https://mta.openssl.org/pipermail/openssl-dev/2015-February/000710.html
https://mta.openssl.org/pipermail/openssl-dev/2015-February/000707.html

It would be really nice to be able to use the real DTLS protocol, and
for the client not to suffer such frequent breakage with new versions of
OpenSSL. I'm sure your VPN client team must also find similar issues,
since they do use OpenSSL. Although they don't seem to be very visible
around here ? it was *me* who made OpenSSL support DTLS1_BAD_VER as a
client again, when that support had been dropped. And it was me who
submitted all the above fixes. So maybe they don't find issues because
I've fixed them all by the time they update? :)

(I also wish you'd support AES-GCM, FWIW. With ocserv that goes nice and
fast on modern hardware. AES-SHA is all we get with the ASA, and it's a
lot more cpu-intensive.)

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/a6f90639/attachment-0001.bin>

From dwmw2 at infradead.org  Tue Feb 17 21:12:49 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 17 Feb 2015 21:12:49 +0000
Subject: [openssl-dev] OpenSSL HEAD breaks OpenConnect VPN client
In-Reply-To: <54E251D6.1060305@openssl.org>
References: <1424090741.1804.39.camel@infradead.org>
 <54E1EFB4.2060403@openssl.org> <1424107995.1804.46.camel@infradead.org>
 <54E251D6.1060305@openssl.org>
Message-ID: <1424207569.24248.8.camel@infradead.org>

On Mon, 2015-02-16 at 20:23 +0000, Matt Caswell wrote:
> 
> > I've updated
> >
> https://wiki.openssl.org/index.php/1.1_API_Changes#Things_that_Broke_in_OpenConnect
> > 
> > I can either update my code to create the ASN.1 for itself and use
> > d2i_SSL_SESSION() relying on the patch above, or I can implement the
> > 'alternative' new function if that's preferred.
> > 
> 
> Ok. Thanks. I'll take a look at this and see what can be done.

Thanks. FWIW I've updated the above wiki section again, having "fixed"
it in OpenConnect to use d2i_SSL_SESSION(). Of course, it won't work
until d2i_SSL_SESSION() is fixed using the patch I sent before... but
then again, DTLS1_BAD_VER in HEAD and 1.0.2 is utterly hosed anyway, so
I'm not going to lose much sleep over that for now.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/71c8bfef/attachment.bin>

From rt at openssl.org  Tue Feb 17 21:48:34 2015
From: rt at openssl.org (David Woodhouse via RT)
Date: Tue, 17 Feb 2015 22:48:34 +0100
Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with Cisco
	DTLS_BAD_VER
In-Reply-To: <1424082497.1804.26.camel@infradead.org>
References: <RT-Ticket-3703@openssl.org>
 <1424082497.1804.26.camel@infradead.org>
Message-ID: <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>

Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
from dtls1_buffer_message() which was needed to distinguish between DTLS
1.x and Cisco's pre-standard version of DTLS.

$DEITY knows why Cisco haven't moved to the standard version of DTLS by
now. The RFC was published in 2006, and since you can tell the
difference on the wire it's *trivial* to have the server accept both and
upgrade the clients piecemeal. The ocserv server manages this.

But it isn't our place to marvel at Cisco's incompetence (like the fact
that their DTLS implementation is still dropping out-of-order received
packets, 6? years after I fixed RT#1752). Our place is to try to be
compatible with it. And this commit broke that, causing the OpenConnect
VPN client to abort:

Connected vpntest0 as 192.168.1.13, using SSL
d1_both.c(1112): OpenSSL internal error, assertion failed: s->d1->w_msg_hdr.msg_len + DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num
Aborted (core dumped)

---
The patch below fixes it. Tested in 1.0.2, but I haven't tested with
HEAD yet because I need to work out how to set up the DTLS session to be
"resumed" ? none of this compiles any more...

../dtls.c: In function 'start_dtls_handshake':
../dtls.c:141:24: error: dereferencing pointer to incomplete type
   vpninfo->dtls_session->ssl_version = 0x0100; /* DTLS1_BAD_VER */
                        ^
../dtls.c:145:23: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->master_key_length = sizeof(vpninfo->dtls_secret);
                       ^
../dtls.c:146:30: error: dereferencing pointer to incomplete type
  memcpy(vpninfo->dtls_session->master_key, vpninfo->dtls_secret,
                              ^
../dtls.c:149:23: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->session_id_length = sizeof(vpninfo->dtls_session_id);
                       ^
../dtls.c:150:30: error: dereferencing pointer to incomplete type
  memcpy(vpninfo->dtls_session->session_id, vpninfo->dtls_session_id,
                              ^
../dtls.c:170:23: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->cipher = dtls_cipher;
                       ^
../dtls.c:171:23: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->cipher_id = dtls_cipher->id;
                       ^
../dtls.c:171:48: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->cipher_id = dtls_cipher->id;

diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index 2553c3d..1116416 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -1108,8 +1108,9 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
     memcpy(frag->fragment, s->init_buf->data, s->init_num);
 
     if (is_ccs) {
+	/* For DTLS_BAD_VER the header length is non-standard */
         OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
-                       DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num);
+                       ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s->init_num);
     } else {
         OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
                        DTLS1_HM_HEADER_LENGTH == (unsigned int)s->init_num);


-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/de249ba9/attachment.bin>

From rt at openssl.org  Tue Feb 17 21:48:45 2015
From: rt at openssl.org (David Woodhouse via RT)
Date: Tue, 17 Feb 2015 22:48:45 +0100
Subject: [openssl-dev] [openssl.org #3704] OpenSSL HEAD breaks OpenConnect
	VPN client
In-Reply-To: <1424090741.1804.39.camel@infradead.org>
References: <RT-Ticket-3704@openssl.org>
 <1424090741.1804.39.camel@infradead.org>
Message-ID: <rt-4.0.4-32641-1424209725-1352.3704-21-0@openssl.org>

The Cisco AnyConnect VPN protocol establishes a connection over HTTPS
and negotiates parameters (cipher, master secret & session ID) for a
DTLS connection which is then "resumed".

The OpenConnect VPN client handles this by using SSL_SESSION_new(),
manually setting the appropriate fields in the structure, and then using
SSL_set_session(). This code can be seen at
http://git.infradead.org/users/dwmw2/openconnect.git/blob/fa5cea08:/dtls.c#l147

Commit b6ba401497 in OpenSSL broke this, because the SSL_SESSION became
opaque ? with no alternative method that I can see to do what's needed.

I played with manually creating the ASN.1 representation of a session
and feeding it to d2i_SSL_SESSION() but that fails because ssl_version
is 0x100 (DTLS1_BAD_VER) and d2i_SSL_SESSION() only works if the SSL
version major is >= SSL3_VERSION_MAJOR.

So I'm going to need to fix *something* in OpenSSL HEAD to make this
work again. Should I do the minimal "fix" to make d2i_SSL_SESSION() work
for DTLS1_BAD_VER, or introduce a new API for setting the fields we need
to fake a session resume?

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/c4dcb2a7/attachment-0001.bin>

From rt at openssl.org  Tue Feb 17 21:48:54 2015
From: rt at openssl.org (Krzysztof Kwiatkowski via RT)
Date: Tue, 17 Feb 2015 22:48:54 +0100
Subject: [openssl-dev] [openssl.org #3705] Constness in
	SSL_CTX_set_srp_username and SSL_CTX_set_srp_password functions
In-Reply-To: <54E22FAD.9010800@leeds.pl>
References: <RT-Ticket-3705@openssl.org> <20150216172647.GB12508@roeckx.be>
 <54E22FAD.9010800@leeds.pl>
Message-ID: <rt-4.0.4-17206-1424209734-558.3705-21-0@openssl.org>

  Currently SSL_CTX_set_srp_username/password functions take char* argument
  for username/password value. In an application level code those values are
  very often const (user provided data). In such cases, when passing those
  values to OpenSSL library either dirty cast needs to be performed to remove
  constness, or const value needs to be copied to temporary location (which
  for SSL_CTX_set_srp_username is useless as this function copies again
  username value in ssl3_ctx_ctrl function).

In this patch I try to cleanup API, so that const values also can be passed
to functions. Please integrate if interested.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: PR227.diff
Type: text/x-patch
Size: 5287 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/889a665f/attachment.bin>

From rt at openssl.org  Tue Feb 17 21:49:28 2015
From: rt at openssl.org (Carl Jackson via RT)
Date: Tue, 17 Feb 2015 22:49:28 +0100
Subject: [openssl-dev] [openssl.org #3706] [patch] Regression in
	ASN1_UTCTIME_cmp_time_t in v1.0.2
In-Reply-To: <CAJx9eL32U=a+SaF=mkcXjdGLf1nf=q0LNYkGTNcYuqegskYqTQ@mail.gmail.com>
References: <RT-Ticket-3706@openssl.org>
 <CAJx9eL32U=a+SaF=mkcXjdGLf1nf=q0LNYkGTNcYuqegskYqTQ@mail.gmail.com>
Message-ID: <rt-4.0.4-32641-1424209768-319.3706-21-0@openssl.org>

OpenSSL v1.0.2 introduced a regression in the ASN1_UTCTIME_cmp_time_t
function. I've written more about this and included a patch on this GitHub
pull request:

https://github.com/openssl/openssl/pull/218
(direct link to patch: https://github.com/openssl/openssl/pull/218.patch)


From rt at openssl.org  Tue Feb 17 21:49:59 2015
From: rt at openssl.org (Brian Carpenter via RT)
Date: Tue, 17 Feb 2015 22:49:59 +0100
Subject: [openssl-dev] [openssl.org #3708] segfault while generating a
	certificate signing request based on a malformed certificate
In-Reply-To: <CANMVOuy6QaZ5DCYhpa5-KvCb1b7SfjibuxX++kdPp4HAs6_KqQ@mail.gmail.com>
References: <RT-Ticket-3708@openssl.org>
 <CANMVOuy6QaZ5DCYhpa5-KvCb1b7SfjibuxX++kdPp4HAs6_KqQ@mail.gmail.com>
Message-ID: <rt-4.0.4-5441-1424209799-179.3708-21-0@openssl.org>

Good morning. I'm reporting a segfault in openssl via the command line
"openssl x509 -x509toreq -in testcase -out /dev/null -signkey test.key"
using a malformed certificate. I'm using american fuzzy lop (
http://lcamtuf.coredump.cx/afl/) to fuzz openssl.

The testcase, which I've attached to this email, is a mutation of a valid
ssl certificate. Doesn't appear to be exploitable according to CERTs
exploitable plugin (https://github.com/jfoote/exploitable) for GDB, but
there are smarter people than I out there in the world.

I compiled openssl with the afl-gcc included with american fuzzy lop for
instrumenting binaries:
CC=/path/to/afl-gcc ./config
AFL_HARDEN=1 make -j8

OpenSSL 1.1.0-dev xx XXX xxxx

Here is the output from GDB:
Getting request Private Key
Generating certificate request

Program received signal SIGSEGV, Segmentation fault.
[----------------------------------registers-----------------------------------]
RAX: 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a -->
0x7372004645444e55 ('UNDEF')
RBX: 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a -->
0x7372004645444e55 ('UNDEF')
RCX: 0x0
RDX: 0x0
RSI: 0x7fffffffd7a0 --> 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a
--> 0x7372004645444e55 ('UNDEF')
RDI: 0x1
RBP: 0x1016bf8 --> 0x10165b0 --> 0x1016f00 --> 0xd230c0 --> 0xd1c02a -->
0x7372004645444e55 ('UNDEF')
RSP: 0x7fffffffd7f0 --> 0x10170e0 --> 0x1016410 --> 0x1017380 -->
0x200000001
RIP: 0x93bbd0 (<X509_PUBKEY_set+240>: mov    rax,QWORD PTR [r12+0x10])
R8 : 0x1019170 --> 0x6e4135700000000d ('\r')
R9 : 0x0
R10: 0xa ('\n')
R11: 0x7ffff78d0556 (<__memset_sse2+230>: mov    QWORD PTR [rdi-0x10],rdx)
R12: 0x0
R13: 0x0
R14: 0x1016f60 --> 0x600000006
R15: 0x0
EFLAGS: 0x10206 (carry PARITY adjust zero sign trap INTERRUPT direction
overflow)
[-------------------------------------code-------------------------------------]
   0x93bbbe <X509_PUBKEY_set+222>: mov    rcx,QWORD PTR [rsp+0x8]
   0x93bbc3 <X509_PUBKEY_set+227>: mov    rax,QWORD PTR [rsp+0x10]
   0x93bbc8 <X509_PUBKEY_set+232>: lea    rsp,[rsp+0x98]
=> 0x93bbd0 <X509_PUBKEY_set+240>: mov    rax,QWORD PTR [r12+0x10]
   0x93bbd5 <X509_PUBKEY_set+245>: test   rax,rax
   0x93bbd8 <X509_PUBKEY_set+248>: je     0x93beb8 <X509_PUBKEY_set+984>
   0x93bbde <X509_PUBKEY_set+254>: xchg   ax,ax
   0x93bbe0 <X509_PUBKEY_set+256>: lea    rsp,[rsp-0x98]
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffd7f0 --> 0x10170e0 --> 0x1016410 --> 0x1017380 -->
0x200000001
0008| 0x7fffffffd7f8 --> 0x7bd4d239a33a7400
0016| 0x7fffffffd800 --> 0x1016580 --> 0x1016bd0 --> 0x0
0024| 0x7fffffffd808 --> 0x1016bd0 --> 0x0
0032| 0x7fffffffd810 --> 0x1018b10 --> 0x200000001
0040| 0x7fffffffd818 --> 0x9e9cee (<X509_to_X509_REQ+398>: mov    rdi,r13)
0048| 0x7fffffffd820 --> 0x7fffffffd840 --> 0x10170e0 --> 0x1016410 -->
0x1017380 --> 0x200000001
0056| 0x7fffffffd828 --> 0x7bd4d239a33a7400
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x000000000093bbd0 in X509_PUBKEY_set ()
gdb-peda$ exploit
Description: Access violation near NULL on source operand
Short description: SourceAvNearNull (16/22)
Hash: edf4ff3908740b6c9ac6ab3fe1b764d4.edf4ff3908740b6c9ac6ab3fe1b764d4
Exploitability Classification: PROBABLY_NOT_EXPLOITABLE
Explanation: The target crashed on an access violation at an address
matching the source operand of the current instruction. This likely
indicates a read access violation, which may mean the application crashed
on a simple NULL dereference to data structure that has no immediate effect
on control of the processor.
Other tags: AccessViolation (21/22)

and Valgrind:
Getting request Private Key
Generating certificate request
==59041== Invalid read of size 8
==59041==    at 0x93BBD0: X509_PUBKEY_set (x_pubkey.c:99)
==59041==    by 0x9E9CED: X509_to_X509_REQ (x509_req.c:95)
==59041==    by 0x46F925: x509_main (x509.c:941)
==59041==    by 0x40C377: do_cmd (openssl.c:472)
==59041==    by 0x40B78D: main (openssl.c:366)
==59041==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==59041==
==59041==
==59041== Process terminating with default action of signal 11 (SIGSEGV)
==59041==  Access not within mapped region at address 0x10
==59041==    at 0x93BBD0: X509_PUBKEY_set (x_pubkey.c:99)
==59041==    by 0x9E9CED: X509_to_X509_REQ (x509_req.c:95)
==59041==    by 0x46F925: x509_main (x509.c:941)
==59041==    by 0x40C377: do_cmd (openssl.c:472)
==59041==    by 0x40B78D: main (openssl.c:366)
==59041==  If you believe this happened as a result of a stack
==59041==  overflow in your program's main thread (unlikely but
==59041==  possible), you can try to increase the size of the
==59041==  main thread stack using the --main-stacksize= flag.
==59041==  The main thread stack size used in this run was 8388608.
Segmentation fault

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test76crash.gz
Type: application/x-gzip
Size: 1317 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/b269e35e/attachment.bin>

From rt at openssl.org  Tue Feb 17 21:49:41 2015
From: rt at openssl.org (Krzysztof Kwiatkowski via RT)
Date: Tue, 17 Feb 2015 22:49:41 +0100
Subject: [openssl-dev] [openssl.org #3707] [PATCH] Constness in
	SSL_CTX_set_srp_username and SSL_CTX_set_srp_password functions
In-Reply-To: <cc8f7b674596a03e7b7b5cd20680f03f@flogreenserver.dyndns.org>
References: <RT-Ticket-3707@openssl.org>
 <cc8f7b674596a03e7b7b5cd20680f03f@flogreenserver.dyndns.org>
Message-ID: <rt-4.0.4-5441-1424209781-748.3707-21-0@openssl.org>

  Currently SSL_CTX_set_srp_username/password functions take char* 
argument for username/password value. In an application level code those 
values are very often const (user provided data). In such cases, when 
passing those values to OpenSSL library either dirty cast needs to be 
performed to remove  constness, or const value needs to be copied to 
temporary location (which for SSL_CTX_set_srp_username is useless as 
this function copies again username value in ssl3_ctx_ctrl function).

In this patch I try to cleanup API, so that const values also can be 
passed to functions. Please integrate if interested.

The diff is available as PR in github: 
https://github.com/openssl/openssl/pull/227

Operating system: ALL
Versions: ALL


diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index ab19eeb..a464199 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -4007,7 +4007,7 @@ long ssl3_ctx_ctrl(SSL_CTX *ctx, int cmd, long 
larg, void *parg)
              SSLerr(SSL_F_SSL3_CTX_CTRL, SSL_R_INVALID_SRP_USERNAME);
              return 0;
          }
-        if ((ctx->srp_ctx.login = BUF_strdup((char *)parg)) == NULL) {
+        if ((ctx->srp_ctx.login = (char *)parg) == NULL) {
              SSLerr(SSL_F_SSL3_CTX_CTRL, ERR_R_INTERNAL_ERROR);
              return 0;
          }
@@ -4015,6 +4015,8 @@ long ssl3_ctx_ctrl(SSL_CTX *ctx, int cmd, long 
larg, void *parg)
      case SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD:
          ctx->srp_ctx.SRP_give_srp_client_pwd_callback =
              srp_password_from_info_cb;
+        if(ctx->srp_ctx.info != NULL)
+          OPENSSL_free(ctx->srp_ctx.info);
          ctx->srp_ctx.info = parg;
          break;
      case SSL_CTRL_SET_SRP_ARG:
diff --git a/ssl/ssl.h b/ssl/ssl.h
index 13fb053..cf0c5ab 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -1545,8 +1545,8 @@ X509_VERIFY_PARAM *SSL_CTX_get0_param(SSL_CTX 
*ctx);
  X509_VERIFY_PARAM *SSL_get0_param(SSL *ssl);

  # ifndef OPENSSL_NO_SRP
-int SSL_CTX_set_srp_username(SSL_CTX *ctx, char *name);
-int SSL_CTX_set_srp_password(SSL_CTX *ctx, char *password);
+int SSL_CTX_set_srp_username(SSL_CTX *ctx, const char *name);
+int SSL_CTX_set_srp_password(SSL_CTX *ctx, const char *password);
  int SSL_CTX_set_srp_strength(SSL_CTX *ctx, int strength);
  int SSL_CTX_set_srp_client_pwd_callback(SSL_CTX *ctx,
                                          char *(*cb) (SSL *, void *));
@@ -1557,7 +1557,7 @@ int SSL_CTX_set_srp_username_callback(SSL_CTX 
*ctx,
  int SSL_CTX_set_srp_cb_arg(SSL_CTX *ctx, void *arg);

  int SSL_set_srp_server_param(SSL *s, const BIGNUM *N, const BIGNUM *g,
-                             BIGNUM *sa, BIGNUM *v, char *info);
+                             BIGNUM *sa, BIGNUM *v, const char *info);
  int SSL_set_srp_server_param_pw(SSL *s, const char *user, const char 
*pass,
                                  const char *grp);

diff --git a/ssl/tls_srp.c b/ssl/tls_srp.c
index 33d398f..a054b70 100644
--- a/ssl/tls_srp.c
+++ b/ssl/tls_srp.c
@@ -71,6 +71,7 @@ int SSL_CTX_SRP_CTX_free(struct ssl_ctx_st *ctx)
      if (ctx == NULL)
          return 0;
      OPENSSL_free(ctx->srp_ctx.login);
+    OPENSSL_free(ctx->srp_ctx.info);
      BN_free(ctx->srp_ctx.N);
      BN_free(ctx->srp_ctx.g);
      BN_free(ctx->srp_ctx.s);
@@ -103,6 +104,7 @@ int SSL_SRP_CTX_free(struct ssl_st *s)
      if (s == NULL)
          return 0;
      OPENSSL_free(s->srp_ctx.login);
+    OPENSSL_free(s->srp_ctx.info);
      BN_free(s->srp_ctx.N);
      BN_free(s->srp_ctx.g);
      BN_free(s->srp_ctx.s);
@@ -156,7 +158,6 @@ int SSL_SRP_CTX_init(struct ssl_st *s)
      s->srp_ctx.b = NULL;
      s->srp_ctx.v = NULL;
      s->srp_ctx.login = NULL;
-    s->srp_ctx.info = ctx->srp_ctx.info;
      s->srp_ctx.strength = ctx->srp_ctx.strength;

      if (((ctx->srp_ctx.N != NULL) &&
@@ -183,11 +184,18 @@ int SSL_SRP_CTX_init(struct ssl_st *s)
          SSLerr(SSL_F_SSL_SRP_CTX_INIT, ERR_R_INTERNAL_ERROR);
          goto err;
      }
+    if ((ctx->srp_ctx.info != NULL) &&
+        ((s->srp_ctx.info = BUF_strdup(ctx->srp_ctx.info)) == NULL)) {
+        SSLerr(SSL_F_SSL_SRP_CTX_INIT, ERR_R_INTERNAL_ERROR);
+        goto err;
+    }
+
      s->srp_ctx.srp_Mask = ctx->srp_ctx.srp_Mask;

      return (1);
   err:
      OPENSSL_free(s->srp_ctx.login);
+    OPENSSL_free(s->srp_ctx.info);
      BN_free(s->srp_ctx.N);
      BN_free(s->srp_ctx.g);
      BN_free(s->srp_ctx.s);
@@ -289,7 +297,7 @@ int SSL_set_srp_server_param_pw(SSL *s, const char 
*user, const char *pass,
  }

  int SSL_set_srp_server_param(SSL *s, const BIGNUM *N, const BIGNUM *g,
-                             BIGNUM *sa, BIGNUM *v, char *info)
+                             BIGNUM *sa, BIGNUM *v, const char *info)
  {
      if (N != NULL) {
          if (s->srp_ctx.N != NULL) {
@@ -327,7 +335,12 @@ int SSL_set_srp_server_param(SSL *s, const BIGNUM 
*N, const BIGNUM *g,
          } else
              s->srp_ctx.v = BN_dup(v);
      }
-    s->srp_ctx.info = info;
+    if(info!=NULL) {
+        if(s->srp_ctx.info != NULL )
+            OPENSSL_free(s->srp_ctx.info);
+        if((s->srp_ctx.info = BUF_strdup(info)) == NULL)
+            return -1;
+    }

      if (!(s->srp_ctx.N) ||
          !(s->srp_ctx.g) || !(s->srp_ctx.s) || !(s->srp_ctx.v))
@@ -499,14 +512,16 @@ char *SSL_get_srp_userinfo(SSL *s)
  # define tls1_ctx_ctrl ssl3_ctx_ctrl
  # define tls1_ctx_callback_ctrl ssl3_ctx_callback_ctrl

-int SSL_CTX_set_srp_username(SSL_CTX *ctx, char *name)
+int SSL_CTX_set_srp_username(SSL_CTX *ctx, const char *name)
  {
-    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_USERNAME, 0, 
name);
+    char* name_tmp = BUF_strdup(name);
+    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_USERNAME, 0, 
name_tmp);
  }

-int SSL_CTX_set_srp_password(SSL_CTX *ctx, char *password)
+int SSL_CTX_set_srp_password(SSL_CTX *ctx, const char *password)
  {
-    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD, 0, 
password);
+    char* pass_tmp = BUF_strdup(password);
+    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD, 0, 
pass_tmp);
  }

  int SSL_CTX_set_srp_strength(SSL_CTX *ctx, int strength)



From rt at openssl.org  Tue Feb 17 21:50:08 2015
From: rt at openssl.org (Henry Dorsett Case via RT)
Date: Tue, 17 Feb 2015 22:50:08 +0100
Subject: [openssl-dev] [openssl.org #3709] [PATCH] Constness in
	SSL_CTX_set_srp_username and SSL_CTX_set_srp_password functions
In-Reply-To: <CALsq8txi9T0GjcLdaKHgjt6Az01SJT-JFDLchAT2ueLuQONMdA@mail.gmail.com>
References: <RT-Ticket-3709@openssl.org>
 <CALsq8txi9T0GjcLdaKHgjt6Az01SJT-JFDLchAT2ueLuQONMdA@mail.gmail.com>
Message-ID: <rt-4.0.4-5441-1424209808-1502.3709-21-0@openssl.org>

Currently SSL_CTX_set_srp_username/password functions take char*
argument for username/password value. In an application level code
those values are very often const (user provided data). In such cases,
when passing those values to OpenSSL library either dirty cast needs
to be performed to remove  constness, or const value needs to be
copied to temporary location (which for SSL_CTX_set_srp_username is
useless as this function copies again username value in ssl3_ctx_ctrl
function).

In this patch I try to cleanup API, so that const values also can be
passed to functions. Please integrate if interested.

The diff is available as PR in github:
https://github.com/openssl/openssl/pull/227

Operating system: ALL
Versions: ALL


diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
index ab19eeb..a464199 100644
--- a/ssl/s3_lib.c
+++ b/ssl/s3_lib.c
@@ -4007,7 +4007,7 @@ long ssl3_ctx_ctrl(SSL_CTX *ctx, int cmd, long
larg, void *parg)
             SSLerr(SSL_F_SSL3_CTX_CTRL, SSL_R_INVALID_SRP_USERNAME);
             return 0;
         }
-        if ((ctx->srp_ctx.login = BUF_strdup((char *)parg)) == NULL) {
+        if ((ctx->srp_ctx.login = (char *)parg) == NULL) {
             SSLerr(SSL_F_SSL3_CTX_CTRL, ERR_R_INTERNAL_ERROR);
             return 0;
         }
@@ -4015,6 +4015,8 @@ long ssl3_ctx_ctrl(SSL_CTX *ctx, int cmd, long
larg, void *parg)
     case SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD:
         ctx->srp_ctx.SRP_give_srp_client_pwd_callback =
             srp_password_from_info_cb;
+        if(ctx->srp_ctx.info != NULL)
+          OPENSSL_free(ctx->srp_ctx.info);
         ctx->srp_ctx.info = parg;
         break;
     case SSL_CTRL_SET_SRP_ARG:
diff --git a/ssl/ssl.h b/ssl/ssl.h
index 13fb053..cf0c5ab 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -1545,8 +1545,8 @@ X509_VERIFY_PARAM *SSL_CTX_get0_param(SSL_CTX *ctx);
 X509_VERIFY_PARAM *SSL_get0_param(SSL *ssl);

 # ifndef OPENSSL_NO_SRP
-int SSL_CTX_set_srp_username(SSL_CTX *ctx, char *name);
-int SSL_CTX_set_srp_password(SSL_CTX *ctx, char *password);
+int SSL_CTX_set_srp_username(SSL_CTX *ctx, const char *name);
+int SSL_CTX_set_srp_password(SSL_CTX *ctx, const char *password);
 int SSL_CTX_set_srp_strength(SSL_CTX *ctx, int strength);
 int SSL_CTX_set_srp_client_pwd_callback(SSL_CTX *ctx,
                                         char *(*cb) (SSL *, void *));
@@ -1557,7 +1557,7 @@ int SSL_CTX_set_srp_username_callback(SSL_CTX *ctx,
 int SSL_CTX_set_srp_cb_arg(SSL_CTX *ctx, void *arg);

 int SSL_set_srp_server_param(SSL *s, const BIGNUM *N, const BIGNUM *g,
-                             BIGNUM *sa, BIGNUM *v, char *info);
+                             BIGNUM *sa, BIGNUM *v, const char *info);
 int SSL_set_srp_server_param_pw(SSL *s, const char *user, const char *pass,
                                 const char *grp);

diff --git a/ssl/tls_srp.c b/ssl/tls_srp.c
index 33d398f..a054b70 100644
--- a/ssl/tls_srp.c
+++ b/ssl/tls_srp.c
@@ -71,6 +71,7 @@ int SSL_CTX_SRP_CTX_free(struct ssl_ctx_st *ctx)
     if (ctx == NULL)
         return 0;
     OPENSSL_free(ctx->srp_ctx.login);
+    OPENSSL_free(ctx->srp_ctx.info);
     BN_free(ctx->srp_ctx.N);
     BN_free(ctx->srp_ctx.g);
     BN_free(ctx->srp_ctx.s);
@@ -103,6 +104,7 @@ int SSL_SRP_CTX_free(struct ssl_st *s)
     if (s == NULL)
         return 0;
     OPENSSL_free(s->srp_ctx.login);
+    OPENSSL_free(s->srp_ctx.info);
     BN_free(s->srp_ctx.N);
     BN_free(s->srp_ctx.g);
     BN_free(s->srp_ctx.s);
@@ -156,7 +158,6 @@ int SSL_SRP_CTX_init(struct ssl_st *s)
     s->srp_ctx.b = NULL;
     s->srp_ctx.v = NULL;
     s->srp_ctx.login = NULL;
-    s->srp_ctx.info = ctx->srp_ctx.info;
     s->srp_ctx.strength = ctx->srp_ctx.strength;

     if (((ctx->srp_ctx.N != NULL) &&
@@ -183,11 +184,18 @@ int SSL_SRP_CTX_init(struct ssl_st *s)
         SSLerr(SSL_F_SSL_SRP_CTX_INIT, ERR_R_INTERNAL_ERROR);
         goto err;
     }
+    if ((ctx->srp_ctx.info != NULL) &&
+        ((s->srp_ctx.info = BUF_strdup(ctx->srp_ctx.info)) == NULL)) {
+        SSLerr(SSL_F_SSL_SRP_CTX_INIT, ERR_R_INTERNAL_ERROR);
+        goto err;
+    }
+
     s->srp_ctx.srp_Mask = ctx->srp_ctx.srp_Mask;

     return (1);
  err:
     OPENSSL_free(s->srp_ctx.login);
+    OPENSSL_free(s->srp_ctx.info);
     BN_free(s->srp_ctx.N);
     BN_free(s->srp_ctx.g);
     BN_free(s->srp_ctx.s);
@@ -289,7 +297,7 @@ int SSL_set_srp_server_param_pw(SSL *s, const char
*user, const char *pass,
 }

 int SSL_set_srp_server_param(SSL *s, const BIGNUM *N, const BIGNUM *g,
-                             BIGNUM *sa, BIGNUM *v, char *info)
+                             BIGNUM *sa, BIGNUM *v, const char *info)
 {
     if (N != NULL) {
         if (s->srp_ctx.N != NULL) {
@@ -327,7 +335,12 @@ int SSL_set_srp_server_param(SSL *s, const BIGNUM
*N, const BIGNUM *g,
         } else
             s->srp_ctx.v = BN_dup(v);
     }
-    s->srp_ctx.info = info;
+    if(info!=NULL) {
+        if(s->srp_ctx.info != NULL )
+            OPENSSL_free(s->srp_ctx.info);
+        if((s->srp_ctx.info = BUF_strdup(info)) == NULL)
+            return -1;
+    }

     if (!(s->srp_ctx.N) ||
         !(s->srp_ctx.g) || !(s->srp_ctx.s) || !(s->srp_ctx.v))
@@ -499,14 +512,16 @@ char *SSL_get_srp_userinfo(SSL *s)
 # define tls1_ctx_ctrl ssl3_ctx_ctrl
 # define tls1_ctx_callback_ctrl ssl3_ctx_callback_ctrl

-int SSL_CTX_set_srp_username(SSL_CTX *ctx, char *name)
+int SSL_CTX_set_srp_username(SSL_CTX *ctx, const char *name)
 {
-    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_USERNAME, 0, name);
+    char* name_tmp = BUF_strdup(name);
+    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_USERNAME, 0, name_tmp);
 }

-int SSL_CTX_set_srp_password(SSL_CTX *ctx, char *password)
+int SSL_CTX_set_srp_password(SSL_CTX *ctx, const char *password)
 {
-    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD, 0, password);
+    char* pass_tmp = BUF_strdup(password);
+    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD, 0, pass_tmp);
 }

 int SSL_CTX_set_srp_strength(SSL_CTX *ctx, int strength)


From rt at openssl.org  Tue Feb 17 21:50:35 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Tue, 17 Feb 2015 22:50:35 +0100
Subject: [openssl-dev] [openssl.org #3710] New EX_DATA indices should start
	at 1
In-Reply-To: <A6DB9EC0-A0D2-4C99-B631-8BD4568D74CE@akamai.com>
References: <RT-Ticket-3710@openssl.org>
 <A6DB9EC0-A0D2-4C99-B631-8BD4568D74CE@akamai.com>
Message-ID: <rt-4.0.4-5441-1424209835-1089.3710-21-0@openssl.org>


As written now, CRYPTO_get_ex_new_index() will return 0 as an index the first time it is called. When called, CRYPTO_get_ex_new_index() adds a new, dup and free function for the index.

This conflicts with the common use of ?app_data? (e.g. SSL_set_app_data(), BIO_set_app_data()) which uses index 0, and does not explicitly reserve it. This can lead to invalid memory frees and/or leaked memory.

Having the indices returned by CRYPTO_get_ex_new_index() start at 1 avoids this.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."



From rt at openssl.org  Tue Feb 17 22:46:07 2015
From: rt at openssl.org (David Woodhouse via RT)
Date: Tue, 17 Feb 2015 23:46:07 +0100
Subject: [openssl-dev] [openssl.org #3704] OpenSSL HEAD breaks
	OpenConnect VPN client
In-Reply-To: <1424213011.24248.13.camel@infradead.org>
References: <RT-Ticket-3704@openssl.org>
 <1424090741.1804.39.camel@infradead.org>
 <rt-4.0.4-32641-1424209725-1352.3704-21-0@openssl.org>
 <1424213011.24248.13.camel@infradead.org>
Message-ID: <rt-4.0.4-5441-1424213167-141.3704-6-0@openssl.org>

This is the minimal fix to make d2i_SSL_SESSION() work. I've already
fixed OpenConnect to use it:
http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/5abb133f

diff --git a/ssl/ssl_asn1.c b/ssl/ssl_asn1.c
index 63fe17f..cb526cf 100644
--- a/ssl/ssl_asn1.c
+++ b/ssl/ssl_asn1.c
@@ -410,7 +410,8 @@ SSL_SESSION *d2i_SSL_SESSION(SSL_SESSION **a, const unsigned char **pp,
     os.data = NULL;
     os.length = 0;
     M_ASN1_D2I_get_x(ASN1_OCTET_STRING, osp, d2i_ASN1_OCTET_STRING);
-    if ((ssl_version >> 8) >= SSL3_VERSION_MAJOR) {
+    if ((ssl_version >> 8) >= SSL3_VERSION_MAJOR ||
+	ssl_version == DTLS1_BAD_VER) {
         if (os.length != 2) {
             c.error = SSL_R_CIPHER_CODE_WRONG_LENGTH;
             c.line = __LINE__;

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150217/f52be1a1/attachment.bin>

From rt at openssl.org  Wed Feb 18 08:01:29 2015
From: rt at openssl.org (David Woodhouse via RT)
Date: Wed, 18 Feb 2015 09:01:29 +0100
Subject: [openssl-dev] [openssl.org #3711] [RFC PATCH] 1.0.2 regresssion:
	Wrong SSL version in DTLS_BAD_VER ClientHello
In-Reply-To: <1424220216.24248.47.camel@infradead.org>
References: <RT-Ticket-3711@openssl.org>
 <1424220216.24248.47.camel@infradead.org>
Message-ID: <rt-4.0.4-17206-1424246488-130.3711-21-0@openssl.org>

Since commit 741c9959 ("DTLS revision."), we put the wrong protocol
version into our ClientHello and potentially other packets. The old DTLS
code which used ssl->version was replaced by the more generic SSL3 code
which uses ssl->client_version. The Cisco ASA no longer likes our
ClientHello.

A patch which fixes this is below. I think it's correct not to set
s->client_version in any of the other adjacent cases, as it would be
redundant. In the s->method->version==DTLS_ANY_VERSION case seen in the
context of the patch, we know that s->client_version is going to be set
in ssl3_client_hello(). And in the 'else' case that is just off the end
of the context of the patch, we're setting it to s->method->version
which is what SSL_clear() already did anyway. In fact, I think those
other cases are *entirely* redundant; even the setting of s->version.

diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c
index 4ca6bb3..626cecb 100644
--- a/ssl/d1_lib.c
+++ b/ssl/d1_lib.c
@@ -273,7 +273,7 @@ void dtls1_clear(SSL *s)
 
     ssl3_clear(s);
     if (s->options & SSL_OP_CISCO_ANYCONNECT)
-        s->version = DTLS1_BAD_VER;
+        s->client_version = s->version = DTLS1_BAD_VER;
     else if (s->method->version == DTLS_ANY_VERSION)
         s->version = DTLS1_2_VERSION;
     else

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/7218c1a9/attachment.bin>

From rt at openssl.org  Wed Feb 18 10:26:12 2015
From: rt at openssl.org (David Woodhouse via RT)
Date: Wed, 18 Feb 2015 11:26:12 +0100
Subject: [openssl-dev] [openssl.org #3711] [RFC PATCH] 1.0.2
	regresssion: Wrong SSL version in DTLS_BAD_VER ClientHello
In-Reply-To: <1424255144.24248.72.camel@infradead.org>
References: <RT-Ticket-3711@openssl.org>
 <1424220216.24248.47.camel@infradead.org>
 <rt-4.0.4-17206-1424246488-130.3711-21-0@openssl.org>
 <1424255144.24248.72.camel@infradead.org>
Message-ID: <rt-4.0.4-17206-1424255172-433.3711-6-0@openssl.org>

Or maybe we should deprecate SSL_OP_CISCO_ANYCONNECT. It would be
cleaner to support it this way instead:

diff --git a/ssl/d1_clnt.c b/ssl/d1_clnt.c
index 151dd47..d4a2d15 100644
--- a/ssl/d1_clnt.c
+++ b/ssl/d1_clnt.c
@@ -133,7 +133,9 @@ static int dtls1_get_hello_verify(SSL *s);
 
 static const SSL_METHOD *dtls1_get_client_method(int ver)
 {
-    if (ver == DTLS1_VERSION || ver == DTLS1_BAD_VER)
+    if (ver == DTLS1_BAD_VER)
+        return (DTLSv0_9_client_method());
+    else if (ver == DTLS1_VERSION)
         return (DTLSv1_client_method());
     else if (ver == DTLS1_2_VERSION)
         return (DTLSv1_2_client_method());
@@ -141,6 +143,12 @@ static const SSL_METHOD *dtls1_get_client_method(int ver)
         return (NULL);
 }
 
+IMPLEMENT_dtls1_meth_func(DTLS1_BAD_VER,
+                          DTLSv0_9_client_method,
+                          ssl_undefined_function,
+                          dtls1_connect,
+                          dtls1_get_client_method, DTLSv1_enc_data)
+
 IMPLEMENT_dtls1_meth_func(DTLS1_VERSION,
                           DTLSv1_client_method,
                           ssl_undefined_function,
diff --git a/ssl/ssl.h b/ssl/ssl.h
index 13fb053..6a559b7 100644
--- a/ssl/ssl.h
+++ b/ssl/ssl.h
@@ -1611,6 +1611,11 @@ const SSL_METHOD *TLSv1_2_method(void); /* TLSv1.2 */
 const SSL_METHOD *TLSv1_2_server_method(void); /* TLSv1.2 */
 const SSL_METHOD *TLSv1_2_client_method(void); /* TLSv1.2 */
 
+/* For reasons not entirely clear to anyone, Cisco still uses this
+ * in their AnyConnect VPN and haven't managed to update even to
+ * DTLS v1.0. So we still need to support it for compatibility */
+const SSL_METHOD *DTLSv0_9_client_method(void); /* pre-OpenSSL 0.9.8f */
+
 const SSL_METHOD *DTLSv1_method(void); /* DTLSv1.0 */
 const SSL_METHOD *DTLSv1_server_method(void); /* DTLSv1.0 */
 const SSL_METHOD *DTLSv1_client_method(void); /* DTLSv1.0 */

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/00087bfd/attachment-0001.bin>

From dwmw2 at infradead.org  Wed Feb 18 11:34:43 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 18 Feb 2015 11:34:43 +0000
Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with Cisco
 DTLS_BAD_VER
In-Reply-To: <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
References: <RT-Ticket-3703@openssl.org>
 <1424082497.1804.26.camel@infradead.org>
 <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
Message-ID: <1424259283.24248.80.camel@infradead.org>

On Tue, 2015-02-17 at 22:48 +0100, David Woodhouse via RT wrote:
> Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
> from dtls1_buffer_message() which was needed to distinguish between DTLS
> 1.x and Cisco's pre-standard version of DTLS.

Further testing shows that simply reverting the offending commit isn't
sufficient ? as the commit comment hinted. We need to treat DTLS v1.2
the same as DTLS v1.0. So invert it to check explicitly for
DTLS1_BAD_VER instead. And in fact we might as well clean it up a little
to look like this:

diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index 7d48cc4..0216d14 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -1072,6 +1072,7 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
     pitem *item;
     hm_fragment *frag;
     unsigned char seq64be[8];
+    unsigned int expected_hdr_len;
 
     /*
      * this function is called immediately after a message has been
@@ -1085,13 +1086,15 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
 
     memcpy(frag->fragment, s->init_buf->data, s->init_num);
 
-    if (is_ccs) {
-        OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
-                       DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num);
-    } else {
-        OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
-                       DTLS1_HM_HEADER_LENGTH == (unsigned int)s->init_num);
-    }
+    if (!is_ccs)
+        expected_hdr_len = DTLS1_HM_HEADER_LENGTH;
+    else if (s->version == DTLS1_BAD_VER)
+        expected_hdr_len = 3;
+    else
+        expected_hdr_len = DTLS1_CCS_HEADER_LENGTH;
+
+    OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
+                   expected_hdr_len == (unsigned int)s->init_num);
 
     frag->msg_header.msg_len = s->d1->w_msg_hdr.msg_len;
     frag->msg_header.seq = s->d1->w_msg_hdr.seq;


-- 
dwmw2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/bcda3625/attachment.bin>

From rt at openssl.org  Wed Feb 18 11:35:58 2015
From: rt at openssl.org (David Woodhouse via RT)
Date: Wed, 18 Feb 2015 12:35:58 +0100
Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with Cisco
	DTLS_BAD_VER
In-Reply-To: <1424259283.24248.80.camel@infradead.org>
References: <RT-Ticket-3703@openssl.org>
 <1424082497.1804.26.camel@infradead.org>
 <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
 <1424259283.24248.80.camel@infradead.org>
Message-ID: <rt-4.0.4-6293-1424259358-1220.3703-6-0@openssl.org>

On Tue, 2015-02-17 at 22:48 +0100, David Woodhouse via RT wrote:
> Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
> from dtls1_buffer_message() which was needed to distinguish between DTLS
> 1.x and Cisco's pre-standard version of DTLS.

Further testing shows that simply reverting the offending commit isn't
sufficient ? as the commit comment hinted. We need to treat DTLS v1.2
the same as DTLS v1.0. So invert it to check explicitly for
DTLS1_BAD_VER instead. And in fact we might as well clean it up a little
to look like this:

diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index 7d48cc4..0216d14 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -1072,6 +1072,7 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
     pitem *item;
     hm_fragment *frag;
     unsigned char seq64be[8];
+    unsigned int expected_hdr_len;
 
     /*
      * this function is called immediately after a message has been
@@ -1085,13 +1086,15 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
 
     memcpy(frag->fragment, s->init_buf->data, s->init_num);
 
-    if (is_ccs) {
-        OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
-                       DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num);
-    } else {
-        OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
-                       DTLS1_HM_HEADER_LENGTH == (unsigned int)s->init_num);
-    }
+    if (!is_ccs)
+        expected_hdr_len = DTLS1_HM_HEADER_LENGTH;
+    else if (s->version == DTLS1_BAD_VER)
+        expected_hdr_len = 3;
+    else
+        expected_hdr_len = DTLS1_CCS_HEADER_LENGTH;
+
+    OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
+                   expected_hdr_len == (unsigned int)s->init_num);
 
     frag->msg_header.msg_len = s->d1->w_msg_hdr.msg_len;
     frag->msg_header.seq = s->d1->w_msg_hdr.seq;


-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/64f5c150/attachment.bin>

From rt at openssl.org  Wed Feb 18 14:19:07 2015
From: rt at openssl.org (Tomas Mraz via RT)
Date: Wed, 18 Feb 2015 15:19:07 +0100
Subject: [openssl-dev] [openssl.org #3675] Fix key wrapping mode with
	padding to conform to RFC 5649
In-Reply-To: <1424269112.2698.16.camel@redhat.com>
References: <RT-Ticket-3675@openssl.org> <54C646B0.5050001@redhat.com>
 <rt-4.0.4-10042-1422295381-1709.3675-21-0@openssl.org>
 <1424269112.2698.16.camel@redhat.com>
Message-ID: <rt-4.0.4-6293-1424269146-1405.3675-6-0@openssl.org>

Hello OpenSSL developers,
can you please include this fix which although a trivial code change
nevertheless does have big impact on the encrypted key-wrapped data.

-- 
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)




From tshort at akamai.com  Wed Feb 18 16:43:46 2015
From: tshort at akamai.com (Short, Todd)
Date: Wed, 18 Feb 2015 10:43:46 -0600
Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with
	Cisco	DTLS_BAD_VER
In-Reply-To: <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
References: <RT-Ticket-3703@openssl.org>
 <1424082497.1804.26.camel@infradead.org>
 <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
Message-ID: <2BC13784-61A1-4C98-8E55-1096AE82DE41@akamai.com>

The Cisco ASA uses hardware-assist for IPSec/TLS/SSL/DTLS, and most of that work was done before DTLS was standardized. This is also the reason why Cisco ASA support for TLSv1.1/v1.2 is a long time coming. The Cisco ASA VPN team is very small, and they?ve lost people on the VPN team recently.

The Cisco ASA has recently updated to OpenSSL 1.0.1 (right before Heartbleed broke out), so it really depends on what version of the ASA code you are running.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

On Feb 17, 2015, at 4:48 PM, David Woodhouse via RT <rt at openssl.org<mailto:rt at openssl.org>> wrote:

Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
from dtls1_buffer_message() which was needed to distinguish between DTLS
1.x and Cisco's pre-standard version of DTLS.

$DEITY knows why Cisco haven't moved to the standard version of DTLS by
now. The RFC was published in 2006, and since you can tell the
difference on the wire it's *trivial* to have the server accept both and
upgrade the clients piecemeal. The ocserv server manages this.

But it isn't our place to marvel at Cisco's incompetence (like the fact
that their DTLS implementation is still dropping out-of-order received
packets, 6? years after I fixed RT#1752). Our place is to try to be
compatible with it. And this commit broke that, causing the OpenConnect
VPN client to abort:

Connected vpntest0 as 192.168.1.13, using SSL
d1_both.c(1112): OpenSSL internal error, assertion failed: s->d1->w_msg_hdr.msg_len + DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num
Aborted (core dumped)

---
The patch below fixes it. Tested in 1.0.2, but I haven't tested with
HEAD yet because I need to work out how to set up the DTLS session to be
"resumed" ? none of this compiles any more...

../dtls.c: In function 'start_dtls_handshake':
../dtls.c:141:24: error: dereferencing pointer to incomplete type
  vpninfo->dtls_session->ssl_version = 0x0100; /* DTLS1_BAD_VER */
                       ^
../dtls.c:145:23: error: dereferencing pointer to incomplete type
 vpninfo->dtls_session->master_key_length = sizeof(vpninfo->dtls_secret);
                      ^
../dtls.c:146:30: error: dereferencing pointer to incomplete type
 memcpy(vpninfo->dtls_session->master_key, vpninfo->dtls_secret,
                             ^
../dtls.c:149:23: error: dereferencing pointer to incomplete type
 vpninfo->dtls_session->session_id_length = sizeof(vpninfo->dtls_session_id);
                      ^
../dtls.c:150:30: error: dereferencing pointer to incomplete type
 memcpy(vpninfo->dtls_session->session_id, vpninfo->dtls_session_id,
                             ^
../dtls.c:170:23: error: dereferencing pointer to incomplete type
 vpninfo->dtls_session->cipher = dtls_cipher;
                      ^
../dtls.c:171:23: error: dereferencing pointer to incomplete type
 vpninfo->dtls_session->cipher_id = dtls_cipher->id;
                      ^
../dtls.c:171:48: error: dereferencing pointer to incomplete type
 vpninfo->dtls_session->cipher_id = dtls_cipher->id;

diff --git a/ssl/d1_both.c b/ssl/d1_both.c
index 2553c3d..1116416 100644
--- a/ssl/d1_both.c
+++ b/ssl/d1_both.c
@@ -1108,8 +1108,9 @@ int dtls1_buffer_message(SSL *s, int is_ccs)
    memcpy(frag->fragment, s->init_buf->data, s->init_num);

    if (is_ccs) {
+ /* For DTLS_BAD_VER the header length is non-standard */
        OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
-                       DTLS1_CCS_HEADER_LENGTH == (unsigned int)s->init_num);
+                       ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s->init_num);
    } else {
        OPENSSL_assert(s->d1->w_msg_hdr.msg_len +
                       DTLS1_HM_HEADER_LENGTH == (unsigned int)s->init_num);


--
dwmw2

<smime.p7s>_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/840ac366/attachment-0001.html>

From rt at openssl.org  Wed Feb 18 17:09:34 2015
From: rt at openssl.org (Kurt Roeckx via RT)
Date: Wed, 18 Feb 2015 18:09:34 +0100
Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with Cisco
	DTLS_BAD_VER
In-Reply-To: <20150218170554.GA23118@roeckx.be>
References: <RT-Ticket-3703@openssl.org>
 <1424082497.1804.26.camel@infradead.org>
 <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
 <1424259283.24248.80.camel@infradead.org> <20150218170554.GA23118@roeckx.be>
Message-ID: <rt-4.0.4-27755-1424279374-1178.3703-6-0@openssl.org>

On Wed, Feb 18, 2015 at 11:34:43AM +0000, David Woodhouse wrote:
> On Tue, 2015-02-17 at 22:48 +0100, David Woodhouse via RT wrote:
> > Commit 9cf0f187 in HEAD, and 68039af3 in 1.0.2, removed a version check
> > from dtls1_buffer_message() which was needed to distinguish between DTLS
> > 1.x and Cisco's pre-standard version of DTLS.
> 
> Further testing shows that simply reverting the offending commit isn't
> sufficient -- as the commit comment hinted. We need to treat DTLS v1.2
> the same as DTLS v1.0. So invert it to check explicitly for
> DTLS1_BAD_VER instead. And in fact we might as well clean it up a little
> to look like this:

I previously mailed something to that effect to rt@, but that
seems to not have made it.

Anyway, I'm wondering about that assert.  Is this something a the
other side could potentionally trigger, and so be a remote DoS?  I
think you showed that you ran into it.  If that's the case
wouldn't it be better to generate an error instead?


Kurt



From dwmw2 at infradead.org  Wed Feb 18 17:17:50 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 18 Feb 2015 17:17:50 +0000
Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with Cisco
 DTLS_BAD_VER
In-Reply-To: <rt-4.0.4-27755-1424279374-1178.3703-6-0@openssl.org>
References: <RT-Ticket-3703@openssl.org>
 <1424082497.1804.26.camel@infradead.org>
 <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
 <1424259283.24248.80.camel@infradead.org>
 <20150218170554.GA23118@roeckx.be>
 <rt-4.0.4-27755-1424279374-1178.3703-6-0@openssl.org>
Message-ID: <1424279870.24248.122.camel@infradead.org>

On Wed, 2015-02-18 at 18:09 +0100, Kurt Roeckx via RT wrote:
> 
> Anyway, I'm wondering about that assert.  Is this something a the
> other side could potentionally trigger, and so be a remote DoS?  I
> think you showed that you ran into it.  If that's the case
> wouldn't it be better to generate an error instead?

This is just a sanity check on our own output; it doesn't see incoming
packets.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/7a2b80ec/attachment.bin>

From rt at openssl.org  Wed Feb 18 17:18:41 2015
From: rt at openssl.org (David Woodhouse via RT)
Date: Wed, 18 Feb 2015 18:18:41 +0100
Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with Cisco
	DTLS_BAD_VER
In-Reply-To: <1424279870.24248.122.camel@infradead.org>
References: <RT-Ticket-3703@openssl.org>
 <1424082497.1804.26.camel@infradead.org>
 <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
 <1424259283.24248.80.camel@infradead.org> <20150218170554.GA23118@roeckx.be>
 <rt-4.0.4-27755-1424279374-1178.3703-6-0@openssl.org>
 <1424279870.24248.122.camel@infradead.org>
Message-ID: <rt-4.0.4-27786-1424279921-451.3703-6-0@openssl.org>

On Wed, 2015-02-18 at 18:09 +0100, Kurt Roeckx via RT wrote:
> 
> Anyway, I'm wondering about that assert.  Is this something a the
> other side could potentionally trigger, and so be a remote DoS?  I
> think you showed that you ran into it.  If that's the case
> wouldn't it be better to generate an error instead?

This is just a sanity check on our own output; it doesn't see incoming
packets.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/6fde60e0/attachment.bin>

From dwmw2 at infradead.org  Wed Feb 18 17:24:15 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Wed, 18 Feb 2015 17:24:15 +0000
Subject: [openssl-dev] [openssl.org #3703] 1.0.2 regression with
	Cisco	DTLS_BAD_VER
In-Reply-To: <2BC13784-61A1-4C98-8E55-1096AE82DE41@akamai.com>
References: <RT-Ticket-3703@openssl.org>
 <1424082497.1804.26.camel@infradead.org>
 <rt-4.0.4-32641-1424209711-1338.3703-21-0@openssl.org>
 <2BC13784-61A1-4C98-8E55-1096AE82DE41@akamai.com>
Message-ID: <1424280255.24248.127.camel@infradead.org>

On Wed, 2015-02-18 at 10:43 -0600, Short, Todd wrote:
> The Cisco ASA uses hardware-assist for IPSec/TLS/SSL/DTLS, and most of
> that work was done before DTLS was standardized. This is also the
> reason why Cisco ASA support for TLSv1.1/v1.2 is a long time coming.
> The Cisco ASA VPN team is very small, and they?ve lost people on the
> VPN team recently.

It might be interesting to see if that kind of offload is still
worthwhile, given the rate at which modern CPUs can do AES-GCM.

> The Cisco ASA has recently updated to OpenSSL 1.0.1 (right before
> Heartbleed broke out), so it really depends on what version of the ASA
> code you are running.

I still haven't seen any version of the ASA using anything but
DTLS1_BAD_VER so far.

We do use DTLS1.2 and AES-GCM with ocserv, but not the Cisco ASA.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/47673b1f/attachment-0001.bin>

From rt at openssl.org  Wed Feb 18 20:12:09 2015
From: rt at openssl.org (Albe Laurenz via RT)
Date: Wed, 18 Feb 2015 21:12:09 +0100
Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is
	broken
In-Reply-To: <A737B7A37273E048B164557ADEF4A58B3659C8F4@ntex2010i.host.magwien.gv.at>
References: <RT-Ticket-3712@openssl.org>
 <A737B7A37273E048B164557ADEF4A58B3659C8F4@ntex2010i.host.magwien.gv.at>
Message-ID: <rt-4.0.4-27786-1424290329-1354.3712-21-0@openssl.org>

I ran into this problem while connecting to a PostgreSQL server (PostgreSQL uses OpenSSL
for SSL support) with a Java client using the PostgreSQL JDBC driver (which uses
the Java Secure Socket Extension which is part of Oracle's Java Runtime Environment).

Since database connections are potentially long-lived, the PostgreSQL server will
trigger a renegotiation after a certain amount of data has been exchanged via the
TLS channel; this amount is configurable with the parameter "ssl_renegotiation_limit".

This renegotiation is always aborted by OpenSSL with the error "unexpected record".
I could reproduce the problem with OpenSSL 1.0.1e on Linux and OpenSSL 1.0.1j on
Windows using Oracle JRE 1.7.0_71 and 1.7.0_75 on the client side.
The protocol version in effect is TLS 1.2 (0x303).

I will describe the problem in more detail below, but my conclusion is that OpenSSL
violates RFC 5246 (TLS 1.2) and RFC 4346 (TLS 1.1) since it chokes on an "Application
Data" record received right after it has sent a "Server Hello Done" record.
At this point OpenSSL waits for a "Client Certificate" or a "Client Key Exchange" record
and is not ready to receive application data.

However, RFC 5246 and RFC 4346 state at the end of chapter 6.2.1:

   Note: Data of different TLS Record layer content types MAY be
   interleaved.  Application data is generally of lower precedence for
   transmission than other content types.  However, records MUST be
   delivered to the network in the same order as they are protected by
   the record layer.  Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.

The last sentence clearly puts the blame on OpenSSL.
This seems to be an addition in TLS 1.1 since it cannot be found in RFC 2246.

The problem is likely not restricted to PostgreSQL, but a generic problem that
will affect all renegotiations between JSSE and OpenSSL.
The only workaround is to disable renegotiation, but that will reduce the
security of the communication.

Yours,
Laurenz Albe



Detailed analysis using OpenSSL 1.0.1e on RedHat Enterprise Linux 6:

The OpenSSL error is thrown in this part of the code:
https://github.com/openssl/openssl/blob/master/ssl/s3_pkt.c#L1601
(the code does not seem to have changed substantially since 1.0.1e).

The stack trace at the time is like this:
#0  ssl3_read_bytes (s=0x228d6a0, type=22, buf=0x231ee20 "\016", len=4, peek=0) at s3_pkt.c:1421
#1  0x00000039d402dac2 in ssl3_get_message (s=0x228d6a0, st1=8576, stn=8577, mt=-1, max=102400, ok=0x7fffe6bcfe1c) at s3_both.c:457
#2  0x00000039d401e36a in ssl3_check_client_hello (s=0x228d6a0) at s3_srvr.c:873
#3  0x00000039d40219db in ssl3_accept (s=0x228d6a0) at s3_srvr.c:572
#4  0x00000039d402c9a8 in ssl3_read_bytes (s=0x228d6a0, type=23, buf=0xd9b4e0 "P", len=8192, peek=0) at s3_pkt.c:1342
#5  0x00000039d4027ec0 in ssl3_read_internal (s=0x228d6a0, buf=0xd9b4e0, len=8192, peek=0) at s3_lib.c:4273
#6  0x0000000000698df1 in be_tls_read (port=0x228d490, ptr=0xd9b4e0, len=8192) at be-secure-openssl.c:572
#7  0x00000000006880d3 in secure_read (port=0x228d490, ptr=0xd9b4e0, len=8192) at be-secure.c:135
[...]

s->version is 0x301 (TLS 1.2), and s->state is 0x2180 (SSL3_ST_SR_CERT_A).

I put SSL_CTX_set_info_callback and SSL_CTX_set_msg_callback into the PostgreSQL source,
and the output looks as follows:

info_callback: SSL_accept:SSL renegotiate ciphers
msg_callback: write 0x303 handshake 00...
info_callback: SSL_accept:SSLv3 write hello request A
info_callback: SSL_accept:SSLv3 flush data
info_callback: SSL_accept:SSLv3 write hello request C
info_callback: SSL_accept:before accept initialization
msg_callback: read 0x303 handshake 01...
info_callback: SSL_accept:SSLv3 read client hello A
msg_callback: write 0x303 handshake 02...
info_callback: SSL_accept:SSLv3 write server hello A
msg_callback: write 0x303 handshake 0B...
info_callback: SSL_accept:SSLv3 write certificate A
msg_callback: write 0x303 handshake 0C...
info_callback: SSL_accept:SSLv3 write key exchange A
msg_callback: write 0x303 handshake 0E...
info_callback: SSL_accept:SSLv3 write server done A
info_callback: SSL_accept:SSLv3 flush data
msg_callback: write 0x303 alert 02...
info_callback: SSL3 alert write:fatal:unexpected_message
info_callback: SSL_accept:error in SSLv3 read client certificate A

I used Wireshark to capture the network communication, and the result
looks like this (the offending "Application Data" record must be number 44):

No.  Source           Destination      Protocol Length Info
28   Java client      OpenSSL server   TLSv1.2  203    Application Data
29   OpenSSL server   Java client      TLSv1.2  235    Application Data
30   OpenSSL server   Java client      TLSv1.2  219    Application Data
31   Java client      OpenSSL server   TCP      54     49860?5432 [ACK] Seq=1199 Ack=3272 Win=65536 Len=0
32   OpenSSL server   Java client      TCP      1514   [TCP segment of a reassembled PDU]
33   OpenSSL server   Java client      TCP      1514   [TCP segment of a reassembled PDU]
34   Java client      OpenSSL server   TCP      54     49860?5432 [ACK] Seq=1199 Ack=6192 Win=65536 Len=0
35   OpenSSL server   Java client      TCP      1514   [TCP segment of a reassembled PDU]
36   OpenSSL server   Java client      TCP      1514   [TCP segment of a reassembled PDU]
37   OpenSSL server   Java client      TCP      1514   [TCP segment of a reassembled PDU]
38   OpenSSL server   Java client      TLSv1.2  1031   Application Data
39   Java client      OpenSSL server   TCP      54     49860?5432 [ACK] Seq=1199 Ack=11549 Win=65536 Len=0
40   OpenSSL server   Java client      TLSv1.2  139    Encrypted Handshake Message
41   OpenSSL server   Java client      TLSv1.2  1003   Application Data
42   Java client      OpenSSL server   TCP      54     49860?5432 [ACK] Seq=1199 Ack=12583 Win=64512 Len=0
43   Java client      OpenSSL server   TLSv1.2  443    Encrypted Handshake Message
44   Java client      OpenSSL server   TLSv1.2  203    Application Data
45   OpenSSL server   Java client      TCP      60     5432?49860 [ACK] Seq=12583 Ack=1737 Win=22144 Len=0
46   OpenSSL server   Java client      TLSv1.2  1514   Encrypted Handshake Message, Encrypted Handshake Message
47   OpenSSL server   Java client      TLSv1.2  342    Encrypted Handshake Message
48   OpenSSL server   Java client      TLSv1.2  139    Encrypted Alert
49   Java client      OpenSSL server   TCP      54     49860?5432 [ACK] Seq=1737 Ack=14416 Win=65536 Len=0
50   OpenSSL server   Java client      TCP      60     5432?49860 [FIN, ACK] Seq=14416 Ack=1737 Win=22144 Len=0
51   Java client      OpenSSL server   TCP      54     49860?5432 [ACK] Seq=1737 Ack=14417 Win=65536 Len=0
52   Java client      OpenSSL server   TLSv1.2  203    Encrypted Handshake Message
53   OpenSSL server   Java client      TCP      60     5432?49860 [RST] Seq=14417 Win=0 Len=0

This is the Java program I use to reproduce the problem:

public class PGConn {
    public static void main(String[] args) throws ClassNotFoundException, java.sql.SQLException, java.io.IOException {
        Class.forName("org.postgresql.Driver");
        java.sql.Connection conn = java.sql.DriverManager.getConnection(
            "jdbc:postgresql://hostname/dbname?user=username&password=pwd&ssl&sslfactory=org.postgresql.ssl.NonValidatingFactory");
        java.sql.Statement stmt = conn.createStatement();
        stmt.execute("SET ssl_renegotiation_limit='3kB'");
        stmt.executeQuery("SELECT repeat('0123456789', 900)").close();
        stmt.executeQuery("SELECT repeat('0123456789', 900)").close();
        conn.close();
    }
}


From rt at openssl.org  Wed Feb 18 20:12:22 2015
From: rt at openssl.org (Stuart Kemp via RT)
Date: Wed, 18 Feb 2015 21:12:22 +0100
Subject: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS,
	HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td"
In-Reply-To: <54E457700200002800011EFF@prv-mh.provo.novell.com>
References: <RT-Ticket-3713@openssl.org>
 <54E457700200002800011EFF@prv-mh.provo.novell.com>
Message-ID: <rt-4.0.4-27786-1424290342-1051.3713-21-0@openssl.org>


Trying to build FIPS capable OpenSSL on HP-UX ia64

Using openssl-fips-2.0.9.tar.gz and openssl-1.0.1l.tar.gz.

Building per the UserGuide-2.0.pdf

OS:
  HP-UX B.11.31 U ia64

Compiler:
  # cc -V
  cc: HP C/aC++ B3910B A.06.28.01 [Aug 09 2014]

Environment  sets FIPSDIR=/tmp/myssl/fips-2.0
FIPS part configured as:
  ./config

Builds OK, and then do "make install"

OpenSSL configured as:
./config fips threads shared no-ec2m no-idea no-mdc2 no-rc5 

Run:
  make depend
  make

Get following errors with duplicate symbols when building OpenSSL:

[ -z "libcrypto" ] || cc +Z -DOPENSSL_PIC -DOPENSSL_THREADS  -DDSO_DLFCN -DHAVE_DLFCN_H -D_REENTRANT -Ae +DD64 +O3 +Olit=all -z -DB_ENDIAN -D_REENTRANT -DOPENSSL_BN_ASM_MONT -I/tmp/myssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -Iinclude \
        -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso  \
        /tmp/myssl/fips-2.0/lib/fips_premain.c /tmp/myssl/fips-2.0/lib/fipscanister.o \
        libcrypto.a -ldl

ld: Duplicate symbol "AES_Te" in files /tmp/myssl/fips-2.0/lib/fipscanister.o and libcrypto.a[aes-ia64.o]
ld: Duplicate symbol "AES_Td" in files /tmp/myssl/fips-2.0/lib/fipscanister.o and libcrypto.a[aes-ia64.o]

# nm fipscanister.o|grep AES_T
[708]    |                603840|    2304|OBJT |GLOB |0|   .text|AES_Td
[709]    |                601536|    2304|OBJT |GLOB |0|   .text|AES_Te


# nm openssl-1.0.1l/crypto/aes/aes-ia64.o | grep AES_T
[10]     |                  5632|    2304|OBJT |GLOB |0|   .text|AES_Td
[9]      |                  3328|    2304|OBJT |GLOB |0|   .text|AES_Te


Looks like the symbols "AES_decrypt" and "AES_encrypt" were renamed to "fips_aes_decrypt" and "fips_aes_encrypt" respectively, but "AES_Td" and "AES_Te" were forgotten.

# nm openssl-fips-ecp-2.0.9/crypto/aes/aes-ia64.o | grep GL
OB
[10]     |                  5632|    2304|OBJT |GLOB |0|   .text|AES_Td
[9]      |                  3328|    2304|OBJT |GLOB |0|   .text|AES_Te
[8]      |                  2624|     704|FUNC |GLOB |0|   .text|fips_aes_decrypt
[7]      |                   960|     704|FUNC |GLOB |0|   .text|fips_aes_encrypt



# nm openssl-1.0.1l/crypto/aes/aes-ia64.o | grep GLOB
[10]     |                  5632|    2304|OBJT |GLOB |0|   .text|AES_Td
[9]      |                  3328|    2304|OBJT |GLOB |0|   .text|AES_Te
[8]      |                  2624|     704|FUNC |GLOB |0|   .text|AES_decrypt
[7]      |                   960|     704|FUNC |GLOB |0|   .text|AES_encrypt

Thanks,

-Stuart Kemp


<The HTML signature 'New Signature' does not contain any text>



From krzysiek at leeds.pl  Wed Feb 18 21:00:05 2015
From: krzysiek at leeds.pl (Krzysztof Kwiatkowski)
Date: Wed, 18 Feb 2015 22:00:05 +0100
Subject: [openssl-dev] [openssl.org #3707] [PATCH] Constness in
 SSL_CTX_set_srp_username and SSL_CTX_set_srp_password functions
In-Reply-To: <rt-4.0.4-5441-1424209781-748.3707-21-0@openssl.org>
References: <RT-Ticket-3707@openssl.org>
 <cc8f7b674596a03e7b7b5cd20680f03f@flogreenserver.dyndns.org>
 <rt-4.0.4-5441-1424209781-748.3707-21-0@openssl.org>
Message-ID: <54E4FD55.9070806@leeds.pl>

Hi Guys,

Tickets #3705 and #3709 can be closed as they are exactly same as this one.
I've sent same mail few times. Sorry for inconvenience.

Kris

On 02/17/2015 10:49 PM, Krzysztof Kwiatkowski via RT wrote:
>    Currently SSL_CTX_set_srp_username/password functions take char*
> argument for username/password value. In an application level code those
> values are very often const (user provided data). In such cases, when
> passing those values to OpenSSL library either dirty cast needs to be
> performed to remove  constness, or const value needs to be copied to
> temporary location (which for SSL_CTX_set_srp_username is useless as
> this function copies again username value in ssl3_ctx_ctrl function).
>
> In this patch I try to cleanup API, so that const values also can be
> passed to functions. Please integrate if interested.
>
> The diff is available as PR in github:
> https://github.com/openssl/openssl/pull/227
>
> Operating system: ALL
> Versions: ALL
>
>
> diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> index ab19eeb..a464199 100644
> --- a/ssl/s3_lib.c
> +++ b/ssl/s3_lib.c
> @@ -4007,7 +4007,7 @@ long ssl3_ctx_ctrl(SSL_CTX *ctx, int cmd, long
> larg, void *parg)
>                SSLerr(SSL_F_SSL3_CTX_CTRL, SSL_R_INVALID_SRP_USERNAME);
>                return 0;
>            }
> -        if ((ctx->srp_ctx.login = BUF_strdup((char *)parg)) == NULL) {
> +        if ((ctx->srp_ctx.login = (char *)parg) == NULL) {
>                SSLerr(SSL_F_SSL3_CTX_CTRL, ERR_R_INTERNAL_ERROR);
>                return 0;
>            }
> @@ -4015,6 +4015,8 @@ long ssl3_ctx_ctrl(SSL_CTX *ctx, int cmd, long
> larg, void *parg)
>        case SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD:
>            ctx->srp_ctx.SRP_give_srp_client_pwd_callback =
>                srp_password_from_info_cb;
> +        if(ctx->srp_ctx.info != NULL)
> +          OPENSSL_free(ctx->srp_ctx.info);
>            ctx->srp_ctx.info = parg;
>            break;
>        case SSL_CTRL_SET_SRP_ARG:
> diff --git a/ssl/ssl.h b/ssl/ssl.h
> index 13fb053..cf0c5ab 100644
> --- a/ssl/ssl.h
> +++ b/ssl/ssl.h
> @@ -1545,8 +1545,8 @@ X509_VERIFY_PARAM *SSL_CTX_get0_param(SSL_CTX
> *ctx);
>    X509_VERIFY_PARAM *SSL_get0_param(SSL *ssl);
>
>    # ifndef OPENSSL_NO_SRP
> -int SSL_CTX_set_srp_username(SSL_CTX *ctx, char *name);
> -int SSL_CTX_set_srp_password(SSL_CTX *ctx, char *password);
> +int SSL_CTX_set_srp_username(SSL_CTX *ctx, const char *name);
> +int SSL_CTX_set_srp_password(SSL_CTX *ctx, const char *password);
>    int SSL_CTX_set_srp_strength(SSL_CTX *ctx, int strength);
>    int SSL_CTX_set_srp_client_pwd_callback(SSL_CTX *ctx,
>                                            char *(*cb) (SSL *, void *));
> @@ -1557,7 +1557,7 @@ int SSL_CTX_set_srp_username_callback(SSL_CTX
> *ctx,
>    int SSL_CTX_set_srp_cb_arg(SSL_CTX *ctx, void *arg);
>
>    int SSL_set_srp_server_param(SSL *s, const BIGNUM *N, const BIGNUM *g,
> -                             BIGNUM *sa, BIGNUM *v, char *info);
> +                             BIGNUM *sa, BIGNUM *v, const char *info);
>    int SSL_set_srp_server_param_pw(SSL *s, const char *user, const char
> *pass,
>                                    const char *grp);
>
> diff --git a/ssl/tls_srp.c b/ssl/tls_srp.c
> index 33d398f..a054b70 100644
> --- a/ssl/tls_srp.c
> +++ b/ssl/tls_srp.c
> @@ -71,6 +71,7 @@ int SSL_CTX_SRP_CTX_free(struct ssl_ctx_st *ctx)
>        if (ctx == NULL)
>            return 0;
>        OPENSSL_free(ctx->srp_ctx.login);
> +    OPENSSL_free(ctx->srp_ctx.info);
>        BN_free(ctx->srp_ctx.N);
>        BN_free(ctx->srp_ctx.g);
>        BN_free(ctx->srp_ctx.s);
> @@ -103,6 +104,7 @@ int SSL_SRP_CTX_free(struct ssl_st *s)
>        if (s == NULL)
>            return 0;
>        OPENSSL_free(s->srp_ctx.login);
> +    OPENSSL_free(s->srp_ctx.info);
>        BN_free(s->srp_ctx.N);
>        BN_free(s->srp_ctx.g);
>        BN_free(s->srp_ctx.s);
> @@ -156,7 +158,6 @@ int SSL_SRP_CTX_init(struct ssl_st *s)
>        s->srp_ctx.b = NULL;
>        s->srp_ctx.v = NULL;
>        s->srp_ctx.login = NULL;
> -    s->srp_ctx.info = ctx->srp_ctx.info;
>        s->srp_ctx.strength = ctx->srp_ctx.strength;
>
>        if (((ctx->srp_ctx.N != NULL) &&
> @@ -183,11 +184,18 @@ int SSL_SRP_CTX_init(struct ssl_st *s)
>            SSLerr(SSL_F_SSL_SRP_CTX_INIT, ERR_R_INTERNAL_ERROR);
>            goto err;
>        }
> +    if ((ctx->srp_ctx.info != NULL) &&
> +        ((s->srp_ctx.info = BUF_strdup(ctx->srp_ctx.info)) == NULL)) {
> +        SSLerr(SSL_F_SSL_SRP_CTX_INIT, ERR_R_INTERNAL_ERROR);
> +        goto err;
> +    }
> +
>        s->srp_ctx.srp_Mask = ctx->srp_ctx.srp_Mask;
>
>        return (1);
>     err:
>        OPENSSL_free(s->srp_ctx.login);
> +    OPENSSL_free(s->srp_ctx.info);
>        BN_free(s->srp_ctx.N);
>        BN_free(s->srp_ctx.g);
>        BN_free(s->srp_ctx.s);
> @@ -289,7 +297,7 @@ int SSL_set_srp_server_param_pw(SSL *s, const char
> *user, const char *pass,
>    }
>
>    int SSL_set_srp_server_param(SSL *s, const BIGNUM *N, const BIGNUM *g,
> -                             BIGNUM *sa, BIGNUM *v, char *info)
> +                             BIGNUM *sa, BIGNUM *v, const char *info)
>    {
>        if (N != NULL) {
>            if (s->srp_ctx.N != NULL) {
> @@ -327,7 +335,12 @@ int SSL_set_srp_server_param(SSL *s, const BIGNUM
> *N, const BIGNUM *g,
>            } else
>                s->srp_ctx.v = BN_dup(v);
>        }
> -    s->srp_ctx.info = info;
> +    if(info!=NULL) {
> +        if(s->srp_ctx.info != NULL )
> +            OPENSSL_free(s->srp_ctx.info);
> +        if((s->srp_ctx.info = BUF_strdup(info)) == NULL)
> +            return -1;
> +    }
>
>        if (!(s->srp_ctx.N) ||
>            !(s->srp_ctx.g) || !(s->srp_ctx.s) || !(s->srp_ctx.v))
> @@ -499,14 +512,16 @@ char *SSL_get_srp_userinfo(SSL *s)
>    # define tls1_ctx_ctrl ssl3_ctx_ctrl
>    # define tls1_ctx_callback_ctrl ssl3_ctx_callback_ctrl
>
> -int SSL_CTX_set_srp_username(SSL_CTX *ctx, char *name)
> +int SSL_CTX_set_srp_username(SSL_CTX *ctx, const char *name)
>    {
> -    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_USERNAME, 0,
> name);
> +    char* name_tmp = BUF_strdup(name);
> +    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_USERNAME, 0,
> name_tmp);
>    }
>
> -int SSL_CTX_set_srp_password(SSL_CTX *ctx, char *password)
> +int SSL_CTX_set_srp_password(SSL_CTX *ctx, const char *password)
>    {
> -    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD, 0,
> password);
> +    char* pass_tmp = BUF_strdup(password);
> +    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD, 0,
> pass_tmp);
>    }
>
>    int SSL_CTX_set_srp_strength(SSL_CTX *ctx, int strength)
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>


From rt at openssl.org  Wed Feb 18 21:03:02 2015
From: rt at openssl.org (Krzysztof Kwiatkowski via RT)
Date: Wed, 18 Feb 2015 22:03:02 +0100
Subject: [openssl-dev] [openssl.org #3707] [PATCH] Constness in
	SSL_CTX_set_srp_username and SSL_CTX_set_srp_password functions
In-Reply-To: <54E4FD55.9070806@leeds.pl>
References: <RT-Ticket-3707@openssl.org>
 <cc8f7b674596a03e7b7b5cd20680f03f@flogreenserver.dyndns.org>
 <rt-4.0.4-5441-1424209781-748.3707-21-0@openssl.org>
 <54E4FD55.9070806@leeds.pl>
Message-ID: <rt-4.0.4-27755-1424293382-1951.3707-6-0@openssl.org>

Hi Guys,

Tickets #3705 and #3709 can be closed as they are exactly same as this one.
I've sent same mail few times. Sorry for inconvenience.

Kris

On 02/17/2015 10:49 PM, Krzysztof Kwiatkowski via RT wrote:
>    Currently SSL_CTX_set_srp_username/password functions take char*
> argument for username/password value. In an application level code those
> values are very often const (user provided data). In such cases, when
> passing those values to OpenSSL library either dirty cast needs to be
> performed to remove  constness, or const value needs to be copied to
> temporary location (which for SSL_CTX_set_srp_username is useless as
> this function copies again username value in ssl3_ctx_ctrl function).
>
> In this patch I try to cleanup API, so that const values also can be
> passed to functions. Please integrate if interested.
>
> The diff is available as PR in github:
> https://github.com/openssl/openssl/pull/227
>
> Operating system: ALL
> Versions: ALL
>
>
> diff --git a/ssl/s3_lib.c b/ssl/s3_lib.c
> index ab19eeb..a464199 100644
> --- a/ssl/s3_lib.c
> +++ b/ssl/s3_lib.c
> @@ -4007,7 +4007,7 @@ long ssl3_ctx_ctrl(SSL_CTX *ctx, int cmd, long
> larg, void *parg)
>                SSLerr(SSL_F_SSL3_CTX_CTRL, SSL_R_INVALID_SRP_USERNAME);
>                return 0;
>            }
> -        if ((ctx->srp_ctx.login = BUF_strdup((char *)parg)) == NULL) {
> +        if ((ctx->srp_ctx.login = (char *)parg) == NULL) {
>                SSLerr(SSL_F_SSL3_CTX_CTRL, ERR_R_INTERNAL_ERROR);
>                return 0;
>            }
> @@ -4015,6 +4015,8 @@ long ssl3_ctx_ctrl(SSL_CTX *ctx, int cmd, long
> larg, void *parg)
>        case SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD:
>            ctx->srp_ctx.SRP_give_srp_client_pwd_callback =
>                srp_password_from_info_cb;
> +        if(ctx->srp_ctx.info != NULL)
> +          OPENSSL_free(ctx->srp_ctx.info);
>            ctx->srp_ctx.info = parg;
>            break;
>        case SSL_CTRL_SET_SRP_ARG:
> diff --git a/ssl/ssl.h b/ssl/ssl.h
> index 13fb053..cf0c5ab 100644
> --- a/ssl/ssl.h
> +++ b/ssl/ssl.h
> @@ -1545,8 +1545,8 @@ X509_VERIFY_PARAM *SSL_CTX_get0_param(SSL_CTX
> *ctx);
>    X509_VERIFY_PARAM *SSL_get0_param(SSL *ssl);
>
>    # ifndef OPENSSL_NO_SRP
> -int SSL_CTX_set_srp_username(SSL_CTX *ctx, char *name);
> -int SSL_CTX_set_srp_password(SSL_CTX *ctx, char *password);
> +int SSL_CTX_set_srp_username(SSL_CTX *ctx, const char *name);
> +int SSL_CTX_set_srp_password(SSL_CTX *ctx, const char *password);
>    int SSL_CTX_set_srp_strength(SSL_CTX *ctx, int strength);
>    int SSL_CTX_set_srp_client_pwd_callback(SSL_CTX *ctx,
>                                            char *(*cb) (SSL *, void *));
> @@ -1557,7 +1557,7 @@ int SSL_CTX_set_srp_username_callback(SSL_CTX
> *ctx,
>    int SSL_CTX_set_srp_cb_arg(SSL_CTX *ctx, void *arg);
>
>    int SSL_set_srp_server_param(SSL *s, const BIGNUM *N, const BIGNUM *g,
> -                             BIGNUM *sa, BIGNUM *v, char *info);
> +                             BIGNUM *sa, BIGNUM *v, const char *info);
>    int SSL_set_srp_server_param_pw(SSL *s, const char *user, const char
> *pass,
>                                    const char *grp);
>
> diff --git a/ssl/tls_srp.c b/ssl/tls_srp.c
> index 33d398f..a054b70 100644
> --- a/ssl/tls_srp.c
> +++ b/ssl/tls_srp.c
> @@ -71,6 +71,7 @@ int SSL_CTX_SRP_CTX_free(struct ssl_ctx_st *ctx)
>        if (ctx == NULL)
>            return 0;
>        OPENSSL_free(ctx->srp_ctx.login);
> +    OPENSSL_free(ctx->srp_ctx.info);
>        BN_free(ctx->srp_ctx.N);
>        BN_free(ctx->srp_ctx.g);
>        BN_free(ctx->srp_ctx.s);
> @@ -103,6 +104,7 @@ int SSL_SRP_CTX_free(struct ssl_st *s)
>        if (s == NULL)
>            return 0;
>        OPENSSL_free(s->srp_ctx.login);
> +    OPENSSL_free(s->srp_ctx.info);
>        BN_free(s->srp_ctx.N);
>        BN_free(s->srp_ctx.g);
>        BN_free(s->srp_ctx.s);
> @@ -156,7 +158,6 @@ int SSL_SRP_CTX_init(struct ssl_st *s)
>        s->srp_ctx.b = NULL;
>        s->srp_ctx.v = NULL;
>        s->srp_ctx.login = NULL;
> -    s->srp_ctx.info = ctx->srp_ctx.info;
>        s->srp_ctx.strength = ctx->srp_ctx.strength;
>
>        if (((ctx->srp_ctx.N != NULL) &&
> @@ -183,11 +184,18 @@ int SSL_SRP_CTX_init(struct ssl_st *s)
>            SSLerr(SSL_F_SSL_SRP_CTX_INIT, ERR_R_INTERNAL_ERROR);
>            goto err;
>        }
> +    if ((ctx->srp_ctx.info != NULL) &&
> +        ((s->srp_ctx.info = BUF_strdup(ctx->srp_ctx.info)) == NULL)) {
> +        SSLerr(SSL_F_SSL_SRP_CTX_INIT, ERR_R_INTERNAL_ERROR);
> +        goto err;
> +    }
> +
>        s->srp_ctx.srp_Mask = ctx->srp_ctx.srp_Mask;
>
>        return (1);
>     err:
>        OPENSSL_free(s->srp_ctx.login);
> +    OPENSSL_free(s->srp_ctx.info);
>        BN_free(s->srp_ctx.N);
>        BN_free(s->srp_ctx.g);
>        BN_free(s->srp_ctx.s);
> @@ -289,7 +297,7 @@ int SSL_set_srp_server_param_pw(SSL *s, const char
> *user, const char *pass,
>    }
>
>    int SSL_set_srp_server_param(SSL *s, const BIGNUM *N, const BIGNUM *g,
> -                             BIGNUM *sa, BIGNUM *v, char *info)
> +                             BIGNUM *sa, BIGNUM *v, const char *info)
>    {
>        if (N != NULL) {
>            if (s->srp_ctx.N != NULL) {
> @@ -327,7 +335,12 @@ int SSL_set_srp_server_param(SSL *s, const BIGNUM
> *N, const BIGNUM *g,
>            } else
>                s->srp_ctx.v = BN_dup(v);
>        }
> -    s->srp_ctx.info = info;
> +    if(info!=NULL) {
> +        if(s->srp_ctx.info != NULL )
> +            OPENSSL_free(s->srp_ctx.info);
> +        if((s->srp_ctx.info = BUF_strdup(info)) == NULL)
> +            return -1;
> +    }
>
>        if (!(s->srp_ctx.N) ||
>            !(s->srp_ctx.g) || !(s->srp_ctx.s) || !(s->srp_ctx.v))
> @@ -499,14 +512,16 @@ char *SSL_get_srp_userinfo(SSL *s)
>    # define tls1_ctx_ctrl ssl3_ctx_ctrl
>    # define tls1_ctx_callback_ctrl ssl3_ctx_callback_ctrl
>
> -int SSL_CTX_set_srp_username(SSL_CTX *ctx, char *name)
> +int SSL_CTX_set_srp_username(SSL_CTX *ctx, const char *name)
>    {
> -    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_USERNAME, 0,
> name);
> +    char* name_tmp = BUF_strdup(name);
> +    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_USERNAME, 0,
> name_tmp);
>    }
>
> -int SSL_CTX_set_srp_password(SSL_CTX *ctx, char *password)
> +int SSL_CTX_set_srp_password(SSL_CTX *ctx, const char *password)
>    {
> -    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD, 0,
> password);
> +    char* pass_tmp = BUF_strdup(password);
> +    return tls1_ctx_ctrl(ctx, SSL_CTRL_SET_TLS_EXT_SRP_PASSWORD, 0,
> pass_tmp);
>    }
>
>    int SSL_CTX_set_srp_strength(SSL_CTX *ctx, int strength)
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>



From rt at openssl.org  Wed Feb 18 22:44:10 2015
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 18 Feb 2015 23:44:10 +0100
Subject: [openssl-dev] [openssl.org #3713] Bug: openssl-1.0.1l, FIPS,
	HP-UX ia64, Duplicate Symbol "AES_Te" and "AES_Td"
In-Reply-To: <54E457700200002800011EFF@prv-mh.provo.novell.com>
References: <RT-Ticket-3713@openssl.org>
 <54E457700200002800011EFF@prv-mh.provo.novell.com>
Message-ID: <rt-4.0.4-27755-1424299450-1918.3713-6-0@openssl.org>

On Wed Feb 18 21:12:22 2015, Stuart.Kemp at netiq.com wrote:
>
> Trying to build FIPS capable OpenSSL on HP-UX ia64
>
> Using openssl-fips-2.0.9.tar.gz and openssl-1.0.1l.tar.gz.
>
>
> Looks like the symbols "AES_decrypt" and "AES_encrypt" were renamed to
> "fips_aes_decrypt" and "fips_aes_encrypt" respectively, but
> "AES_Td" and "AES_Te" were forgotten.
>
> # nm openssl-fips-ecp-2.0.9/crypto/aes/aes-ia64.o | grep GL
> OB
> [10] | 5632| 2304|OBJT |GLOB |0|
> .text|AES_Td
> [9] | 3328| 2304|OBJT |GLOB |0|
> .text|AES_Te
> [8] | 2624| 704|FUNC |GLOB |0|
> .text|fips_aes_decrypt
> [7] | 960| 704|FUNC |GLOB |0|
> .text|fips_aes_encrypt
>
>
> # nm openssl-1.0.1l/crypto/aes/aes-ia64.o | grep GLOB
> [10] | 5632| 2304|OBJT |GLOB |0|
> .text|AES_Td
> [9] | 3328| 2304|OBJT |GLOB |0|
> .text|AES_Te
> [8] | 2624| 704|FUNC |GLOB |0|
> .text|AES_decrypt
> [7] | 960| 704|FUNC |GLOB |0|
> .text|AES_encrypt
>

We can't rename the FIPS symbols without a change letter so that can't happen
immediately.

As a workaround I'd suggest you rename the symbols in OpenSSL instead so they
no longer clash with the FIPS module.

If that works and you can send us a patch it will be included in future
versions of OpenSSL.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


From rt at openssl.org  Wed Feb 18 22:49:39 2015
From: rt at openssl.org (Stephen Henson via RT)
Date: Wed, 18 Feb 2015 23:49:39 +0100
Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is
	broken
In-Reply-To: <A737B7A37273E048B164557ADEF4A58B3659C8F4@ntex2010i.host.magwien.gv.at>
References: <RT-Ticket-3712@openssl.org>
 <A737B7A37273E048B164557ADEF4A58B3659C8F4@ntex2010i.host.magwien.gv.at>
Message-ID: <rt-4.0.4-27755-1424299779-1048.3712-6-0@openssl.org>

On Wed Feb 18 21:12:09 2015, laurenz.albe at wien.gv.at wrote:
> I ran into this problem while connecting to a PostgreSQL server
> (PostgreSQL uses OpenSSL
> for SSL support) with a Java client using
> the PostgreSQL JDBC driver (which uses
> the Java Secure Socket
> Extension which is part of Oracle's Java Runtime Environment).
> Since database connections are potentially long-lived, the PostgreSQL
> server will
> trigger a renegotiation after a certain amount of data
> has been exchanged via the
> TLS channel; this amount is configurable
> with the parameter "ssl_renegotiation_limit".
>
> This renegotiation is
> always aborted by OpenSSL with the error "unexpected record".
> I could
> reproduce the problem with OpenSSL 1.0.1e on Linux and OpenSSL 1.0.1j
> on
> Windows using Oracle JRE 1.7.0_71 and 1.7.0_75 on the client side.
> The protocol version in effect is TLS 1.2 (0x303).
>

There were some fixes related to renegotiation handling in OpenSSL which first
appeared in 1.0.1k. Can you see if this problem still happens in the latest
version of OpenSSL?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org


From rsalz at akamai.com  Thu Feb 19 02:45:52 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 19 Feb 2015 02:45:52 +0000
Subject: [openssl-dev] FW: RFC 7465 on Prohibiting RC4 Cipher Suites
In-Reply-To: <20150218230314.19E6A181D1F@rfc-editor.org>
References: <20150218230314.19E6A181D1F@rfc-editor.org>
Message-ID: <adbc66defc8c4d87836cd5cb30a9887a@ustx2ex-dag1mb4.msg.corp.akamai.com>

Part of my reasoning for wanting to move RC4 to LOW in master, which will not be released until the end of 2015.

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz


-----Original Message-----
From: rfc-editor at rfc-editor.org [mailto:rfc-editor at rfc-editor.org] 
Sent: Wednesday, February 18, 2015 6:03 PM
To: ietf-announce at ietf.org; rfc-dist at rfc-editor.org
Cc: drafts-update-ref at iana.org; tls at ietf.org; rfc-editor at rfc-editor.org
Subject: RFC 7465 on Prohibiting RC4 Cipher Suites

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7465

        Title:      Prohibiting RC4 Cipher Suites 
        Author:     A. Popov
        Status:     Standards Track
        Stream:     IETF
        Date:       February 2015
        Mailbox:    andreipo at microsoft.com
        Pages:      6
        Characters: 8397
        Updates:    RFC 5246, RFC 4346, RFC 2246

        I-D Tag:    draft-ietf-tls-prohibiting-rc4-01.txt

        URL:        https://www.rfc-editor.org/info/rfc7465

This document requires that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections.  This applies to all TLS versions.  This document updates RFCs 5246, 4346, and 2246.

This document is a product of the Transport Layer Security Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements.  Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html

Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor at rfc-editor.org.  Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From kurt at x64architecture.com  Thu Feb 19 04:16:42 2015
From: kurt at x64architecture.com (Kurt Cancemi)
Date: Wed, 18 Feb 2015 23:16:42 -0500
Subject: [openssl-dev] [openssl.org #3708] segfault while generating a
	certificate signing request based on a malformed certificate
In-Reply-To: <rt-4.0.4-5441-1424209799-179.3708-21-0@openssl.org>
References: <RT-Ticket-3708@openssl.org>
 <CANMVOuy6QaZ5DCYhpa5-KvCb1b7SfjibuxX++kdPp4HAs6_KqQ@mail.gmail.com>
 <rt-4.0.4-5441-1424209799-179.3708-21-0@openssl.org>
Message-ID: <7287F6B8-778C-4153-B425-72C879454D12@x64architecture.com>

The problem appears to be a NULL pointer dereference in X509_PUBKEY_set() when pkey is NULL, I attached a patch that fixes the issue.

After patch output (openssl x509 -x509toreq -in test76crash -out /dev/null -signkey test.key):

Getting request Private Key
Generating certificate request
140735115264848:error:0D078095:asn1 encoding routines:ASN1_ITEM_EX_D2I:sequence not constructed:tasn_dec.c:376:Type=RSA
140735115264848:error:0408B004:rsa routines:RSA_PUB_DECODE:RSA lib:rsa_ameth.c:99:
140735115264848:error:0B07707D:x509 certificate routines:X509_PUBKEY_get:public key decode error:x_pubkey.c:154:

Kurt Cancemi
https://www.x64architecture.com <https://www.x64architecture.com/>


> On Feb 17, 2015, at 4:49 PM, Brian Carpenter via RT <rt at openssl.org> wrote:
> 
> Good morning. I'm reporting a segfault in openssl via the command line
> "openssl x509 -x509toreq -in testcase -out /dev/null -signkey test.key"
> using a malformed certificate. I'm using american fuzzy lop (
> http://lcamtuf.coredump.cx/afl/) to fuzz openssl.
> 
> The testcase, which I've attached to this email, is a mutation of a valid
> ssl certificate. Doesn't appear to be exploitable according to CERTs
> exploitable plugin (https://github.com/jfoote/exploitable) for GDB, but
> there are smarter people than I out there in the world.
> 
> I compiled openssl with the afl-gcc included with american fuzzy lop for
> instrumenting binaries:
> CC=/path/to/afl-gcc ./config
> AFL_HARDEN=1 make -j8
> 
> OpenSSL 1.1.0-dev xx XXX xxxx
> 
> Here is the output from GDB:
> Getting request Private Key
> Generating certificate request
> 
> Program received signal SIGSEGV, Segmentation fault.
> [----------------------------------registers-----------------------------------]
> RAX: 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a -->
> 0x7372004645444e55 ('UNDEF')
> RBX: 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a -->
> 0x7372004645444e55 ('UNDEF')
> RCX: 0x0
> RDX: 0x0
> RSI: 0x7fffffffd7a0 --> 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a
> --> 0x7372004645444e55 ('UNDEF')
> RDI: 0x1
> RBP: 0x1016bf8 --> 0x10165b0 --> 0x1016f00 --> 0xd230c0 --> 0xd1c02a -->
> 0x7372004645444e55 ('UNDEF')
> RSP: 0x7fffffffd7f0 --> 0x10170e0 --> 0x1016410 --> 0x1017380 -->
> 0x200000001
> RIP: 0x93bbd0 (<X509_PUBKEY_set+240>: mov    rax,QWORD PTR [r12+0x10])
> R8 : 0x1019170 --> 0x6e4135700000000d ('\r')
> R9 : 0x0
> R10: 0xa ('\n')
> R11: 0x7ffff78d0556 (<__memset_sse2+230>: mov    QWORD PTR [rdi-0x10],rdx)
> R12: 0x0
> R13: 0x0
> R14: 0x1016f60 --> 0x600000006
> R15: 0x0
> EFLAGS: 0x10206 (carry PARITY adjust zero sign trap INTERRUPT direction
> overflow)
> [-------------------------------------code-------------------------------------]
>   0x93bbbe <X509_PUBKEY_set+222>: mov    rcx,QWORD PTR [rsp+0x8]
>   0x93bbc3 <X509_PUBKEY_set+227>: mov    rax,QWORD PTR [rsp+0x10]
>   0x93bbc8 <X509_PUBKEY_set+232>: lea    rsp,[rsp+0x98]
> => 0x93bbd0 <X509_PUBKEY_set+240>: mov    rax,QWORD PTR [r12+0x10]
>   0x93bbd5 <X509_PUBKEY_set+245>: test   rax,rax
>   0x93bbd8 <X509_PUBKEY_set+248>: je     0x93beb8 <X509_PUBKEY_set+984>
>   0x93bbde <X509_PUBKEY_set+254>: xchg   ax,ax
>   0x93bbe0 <X509_PUBKEY_set+256>: lea    rsp,[rsp-0x98]
> [------------------------------------stack-------------------------------------]
> 0000| 0x7fffffffd7f0 --> 0x10170e0 --> 0x1016410 --> 0x1017380 -->
> 0x200000001
> 0008| 0x7fffffffd7f8 --> 0x7bd4d239a33a7400
> 0016| 0x7fffffffd800 --> 0x1016580 --> 0x1016bd0 --> 0x0
> 0024| 0x7fffffffd808 --> 0x1016bd0 --> 0x0
> 0032| 0x7fffffffd810 --> 0x1018b10 --> 0x200000001
> 0040| 0x7fffffffd818 --> 0x9e9cee (<X509_to_X509_REQ+398>: mov    rdi,r13)
> 0048| 0x7fffffffd820 --> 0x7fffffffd840 --> 0x10170e0 --> 0x1016410 -->
> 0x1017380 --> 0x200000001
> 0056| 0x7fffffffd828 --> 0x7bd4d239a33a7400
> [------------------------------------------------------------------------------]
> Legend: code, data, rodata, value
> Stopped reason: SIGSEGV
> 0x000000000093bbd0 in X509_PUBKEY_set ()
> gdb-peda$ exploit
> Description: Access violation near NULL on source operand
> Short description: SourceAvNearNull (16/22)
> Hash: edf4ff3908740b6c9ac6ab3fe1b764d4.edf4ff3908740b6c9ac6ab3fe1b764d4
> Exploitability Classification: PROBABLY_NOT_EXPLOITABLE
> Explanation: The target crashed on an access violation at an address
> matching the source operand of the current instruction. This likely
> indicates a read access violation, which may mean the application crashed
> on a simple NULL dereference to data structure that has no immediate effect
> on control of the processor.
> Other tags: AccessViolation (21/22)
> 
> and Valgrind:
> Getting request Private Key
> Generating certificate request
> ==59041== Invalid read of size 8
> ==59041==    at 0x93BBD0: X509_PUBKEY_set (x_pubkey.c:99)
> ==59041==    by 0x9E9CED: X509_to_X509_REQ (x509_req.c:95)
> ==59041==    by 0x46F925: x509_main (x509.c:941)
> ==59041==    by 0x40C377: do_cmd (openssl.c:472)
> ==59041==    by 0x40B78D: main (openssl.c:366)
> ==59041==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==59041==
> ==59041==
> ==59041== Process terminating with default action of signal 11 (SIGSEGV)
> ==59041==  Access not within mapped region at address 0x10
> ==59041==    at 0x93BBD0: X509_PUBKEY_set (x_pubkey.c:99)
> ==59041==    by 0x9E9CED: X509_to_X509_REQ (x509_req.c:95)
> ==59041==    by 0x46F925: x509_main (x509.c:941)
> ==59041==    by 0x40C377: do_cmd (openssl.c:472)
> ==59041==    by 0x40B78D: main (openssl.c:366)
> ==59041==  If you believe this happened as a result of a stack
> ==59041==  overflow in your program's main thread (unlikely but
> ==59041==  possible), you can try to increase the size of the
> ==59041==  main thread stack using the --main-stacksize= flag.
> ==59041==  The main thread stack size used in this run was 8388608.
> Segmentation fault
> 
> <test76crash.gz>_______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/66ff3c68/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-NULL-pointer-dereference-in-X509_PUBKEY_set.patch
Type: application/octet-stream
Size: 708 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/66ff3c68/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150218/66ff3c68/attachment-0003.html>

From rt at openssl.org  Thu Feb 19 04:17:17 2015
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Thu, 19 Feb 2015 05:17:17 +0100
Subject: [openssl-dev] [openssl.org #3708] segfault while generating a
	certificate signing request based on a malformed certificate
In-Reply-To: <7287F6B8-778C-4153-B425-72C879454D12@x64architecture.com>
References: <RT-Ticket-3708@openssl.org>
 <CANMVOuy6QaZ5DCYhpa5-KvCb1b7SfjibuxX++kdPp4HAs6_KqQ@mail.gmail.com>
 <rt-4.0.4-5441-1424209799-179.3708-21-0@openssl.org>
 <7287F6B8-778C-4153-B425-72C879454D12@x64architecture.com>
Message-ID: <rt-4.0.4-27755-1424319437-550.3708-6-0@openssl.org>

The problem appears to be a NULL pointer dereference in X509_PUBKEY_set() when pkey is NULL, I attached a patch that fixes the issue.

After patch output (openssl x509 -x509toreq -in test76crash -out /dev/null -signkey test.key):

Getting request Private Key
Generating certificate request
140735115264848:error:0D078095:asn1 encoding routines:ASN1_ITEM_EX_D2I:sequence not constructed:tasn_dec.c:376:Type=RSA
140735115264848:error:0408B004:rsa routines:RSA_PUB_DECODE:RSA lib:rsa_ameth.c:99:
140735115264848:error:0B07707D:x509 certificate routines:X509_PUBKEY_get:public key decode error:x_pubkey.c:154:

Kurt Cancemi
https://www.x64architecture.com <https://www.x64architecture.com/>


> On Feb 17, 2015, at 4:49 PM, Brian Carpenter via RT <rt at openssl.org> wrote:
> 
> Good morning. I'm reporting a segfault in openssl via the command line
> "openssl x509 -x509toreq -in testcase -out /dev/null -signkey test.key"
> using a malformed certificate. I'm using american fuzzy lop (
> http://lcamtuf.coredump.cx/afl/) to fuzz openssl.
> 
> The testcase, which I've attached to this email, is a mutation of a valid
> ssl certificate. Doesn't appear to be exploitable according to CERTs
> exploitable plugin (https://github.com/jfoote/exploitable) for GDB, but
> there are smarter people than I out there in the world.
> 
> I compiled openssl with the afl-gcc included with american fuzzy lop for
> instrumenting binaries:
> CC=/path/to/afl-gcc ./config
> AFL_HARDEN=1 make -j8
> 
> OpenSSL 1.1.0-dev xx XXX xxxx
> 
> Here is the output from GDB:
> Getting request Private Key
> Generating certificate request
> 
> Program received signal SIGSEGV, Segmentation fault.
> [----------------------------------registers-----------------------------------]
> RAX: 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a -->
> 0x7372004645444e55 ('UNDEF')
> RBX: 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a -->
> 0x7372004645444e55 ('UNDEF')
> RCX: 0x0
> RDX: 0x0
> RSI: 0x7fffffffd7a0 --> 0x10165f0 --> 0x1019110 --> 0xd230c0 --> 0xd1c02a
> --> 0x7372004645444e55 ('UNDEF')
> RDI: 0x1
> RBP: 0x1016bf8 --> 0x10165b0 --> 0x1016f00 --> 0xd230c0 --> 0xd1c02a -->
> 0x7372004645444e55 ('UNDEF')
> RSP: 0x7fffffffd7f0 --> 0x10170e0 --> 0x1016410 --> 0x1017380 -->
> 0x200000001
> RIP: 0x93bbd0 (<X509_PUBKEY_set+240>: mov    rax,QWORD PTR [r12+0x10])
> R8 : 0x1019170 --> 0x6e4135700000000d ('\r')
> R9 : 0x0
> R10: 0xa ('\n')
> R11: 0x7ffff78d0556 (<__memset_sse2+230>: mov    QWORD PTR [rdi-0x10],rdx)
> R12: 0x0
> R13: 0x0
> R14: 0x1016f60 --> 0x600000006
> R15: 0x0
> EFLAGS: 0x10206 (carry PARITY adjust zero sign trap INTERRUPT direction
> overflow)
> [-------------------------------------code-------------------------------------]
>   0x93bbbe <X509_PUBKEY_set+222>: mov    rcx,QWORD PTR [rsp+0x8]
>   0x93bbc3 <X509_PUBKEY_set+227>: mov    rax,QWORD PTR [rsp+0x10]
>   0x93bbc8 <X509_PUBKEY_set+232>: lea    rsp,[rsp+0x98]
> => 0x93bbd0 <X509_PUBKEY_set+240>: mov    rax,QWORD PTR [r12+0x10]
>   0x93bbd5 <X509_PUBKEY_set+245>: test   rax,rax
>   0x93bbd8 <X509_PUBKEY_set+248>: je     0x93beb8 <X509_PUBKEY_set+984>
>   0x93bbde <X509_PUBKEY_set+254>: xchg   ax,ax
>   0x93bbe0 <X509_PUBKEY_set+256>: lea    rsp,[rsp-0x98]
> [------------------------------------stack-------------------------------------]
> 0000| 0x7fffffffd7f0 --> 0x10170e0 --> 0x1016410 --> 0x1017380 -->
> 0x200000001
> 0008| 0x7fffffffd7f8 --> 0x7bd4d239a33a7400
> 0016| 0x7fffffffd800 --> 0x1016580 --> 0x1016bd0 --> 0x0
> 0024| 0x7fffffffd808 --> 0x1016bd0 --> 0x0
> 0032| 0x7fffffffd810 --> 0x1018b10 --> 0x200000001
> 0040| 0x7fffffffd818 --> 0x9e9cee (<X509_to_X509_REQ+398>: mov    rdi,r13)
> 0048| 0x7fffffffd820 --> 0x7fffffffd840 --> 0x10170e0 --> 0x1016410 -->
> 0x1017380 --> 0x200000001
> 0056| 0x7fffffffd828 --> 0x7bd4d239a33a7400
> [------------------------------------------------------------------------------]
> Legend: code, data, rodata, value
> Stopped reason: SIGSEGV
> 0x000000000093bbd0 in X509_PUBKEY_set ()
> gdb-peda$ exploit
> Description: Access violation near NULL on source operand
> Short description: SourceAvNearNull (16/22)
> Hash: edf4ff3908740b6c9ac6ab3fe1b764d4.edf4ff3908740b6c9ac6ab3fe1b764d4
> Exploitability Classification: PROBABLY_NOT_EXPLOITABLE
> Explanation: The target crashed on an access violation at an address
> matching the source operand of the current instruction. This likely
> indicates a read access violation, which may mean the application crashed
> on a simple NULL dereference to data structure that has no immediate effect
> on control of the processor.
> Other tags: AccessViolation (21/22)
> 
> and Valgrind:
> Getting request Private Key
> Generating certificate request
> ==59041== Invalid read of size 8
> ==59041==    at 0x93BBD0: X509_PUBKEY_set (x_pubkey.c:99)
> ==59041==    by 0x9E9CED: X509_to_X509_REQ (x509_req.c:95)
> ==59041==    by 0x46F925: x509_main (x509.c:941)
> ==59041==    by 0x40C377: do_cmd (openssl.c:472)
> ==59041==    by 0x40B78D: main (openssl.c:366)
> ==59041==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
> ==59041==
> ==59041==
> ==59041== Process terminating with default action of signal 11 (SIGSEGV)
> ==59041==  Access not within mapped region at address 0x10
> ==59041==    at 0x93BBD0: X509_PUBKEY_set (x_pubkey.c:99)
> ==59041==    by 0x9E9CED: X509_to_X509_REQ (x509_req.c:95)
> ==59041==    by 0x46F925: x509_main (x509.c:941)
> ==59041==    by 0x40C377: do_cmd (openssl.c:472)
> ==59041==    by 0x40B78D: main (openssl.c:366)
> ==59041==  If you believe this happened as a result of a stack
> ==59041==  overflow in your program's main thread (unlikely but
> ==59041==  possible), you can try to increase the size of the
> ==59041==  main thread stack using the --main-stacksize= flag.
> ==59041==  The main thread stack size used in this run was 8388608.
> Segmentation fault
> 
> <test76crash.gz>_______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150219/6ee9d2ac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-NULL-pointer-dereference-in-X509_PUBKEY_set.patch
Type: application/octet-stream
Size: 708 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150219/6ee9d2ac/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150219/6ee9d2ac/attachment-0001.html>

From rt at openssl.org  Thu Feb 19 12:51:53 2015
From: rt at openssl.org (Hubert Kario via RT)
Date: Thu, 19 Feb 2015 13:51:53 +0100
Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java
	is broken
In-Reply-To: <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com>
References: <RT-Ticket-3712@openssl.org>
 <A737B7A37273E048B164557ADEF4A58B3659C8F4@ntex2010i.host.magwien.gv.at>
 <rt-4.0.4-27755-1424299779-1048.3712-6-0@openssl.org>
 <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.4-31794-1424350312-338.3712-6-0@openssl.org>

On Wednesday 18 February 2015 23:49:39 Stephen Henson via RT wrote:
> On Wed Feb 18 21:12:09 2015, laurenz.albe at wien.gv.at wrote:
> > I ran into this problem while connecting to a PostgreSQL server
> > (PostgreSQL uses OpenSSL
> > for SSL support) with a Java client using
> > the PostgreSQL JDBC driver (which uses
> > the Java Secure Socket
> > Extension which is part of Oracle's Java Runtime Environment).
> > Since database connections are potentially long-lived, the PostgreSQL
> > server will
> > trigger a renegotiation after a certain amount of data
> > has been exchanged via the
> > TLS channel; this amount is configurable
> > with the parameter "ssl_renegotiation_limit".
> > 
> > This renegotiation is
> > always aborted by OpenSSL with the error "unexpected record".
> > I could
> > reproduce the problem with OpenSSL 1.0.1e on Linux and OpenSSL 1.0.1j
> > on
> > Windows using Oracle JRE 1.7.0_71 and 1.7.0_75 on the client side.
> > The protocol version in effect is TLS 1.2 (0x303).
> 
> There were some fixes related to renegotiation handling in OpenSSL which
> first appeared in 1.0.1k. Can you see if this problem still happens in the
> latest version of OpenSSL?

I was able to reproduce this issue on master, OpenSSL_1_0_2-stable and 
OpenSSL_1_0_1-stable branches as of *now* (2015-02-19).

I have a standalone (python - tlsfuzzer/tlslite) reproducer for that, but the 
code is pre-alpha quality, I'll try to publish it anyway.

I've done it with server running in -legacy_renegotiation mode, but I'm not 
sure if this can have any impact on it.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic



From rt at openssl.org  Thu Feb 19 13:45:52 2015
From: rt at openssl.org (Hubert Kario via RT)
Date: Thu, 19 Feb 2015 14:45:52 +0100
Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java
	is broken
In-Reply-To: <1996101.RmxkL7RUPH@pintsize.usersys.redhat.com>
References: <RT-Ticket-3712@openssl.org>
 <rt-4.0.4-27755-1424299779-1048.3712-6-0@openssl.org>
 <4762915.9PjvlYH3hO@pintsize.usersys.redhat.com>
 <1996101.RmxkL7RUPH@pintsize.usersys.redhat.com>
Message-ID: <rt-4.0.4-21985-1424353552-428.3712-6-0@openssl.org>

On Thursday 19 February 2015 13:48:43 Hubert Kario wrote:
> On Wednesday 18 February 2015 23:49:39 Stephen Henson via RT wrote:
> > On Wed Feb 18 21:12:09 2015, laurenz.albe at wien.gv.at wrote:
> > > I ran into this problem while connecting to a PostgreSQL server
> > > (PostgreSQL uses OpenSSL
> > > for SSL support) with a Java client using
> > > the PostgreSQL JDBC driver (which uses
> > > the Java Secure Socket
> > > Extension which is part of Oracle's Java Runtime Environment).
> > > Since database connections are potentially long-lived, the PostgreSQL
> > > server will
> > > trigger a renegotiation after a certain amount of data
> > > has been exchanged via the
> > > TLS channel; this amount is configurable
> > > with the parameter "ssl_renegotiation_limit".
> > > 
> > > This renegotiation is
> > > always aborted by OpenSSL with the error "unexpected record".
> > > I could
> > > reproduce the problem with OpenSSL 1.0.1e on Linux and OpenSSL 1.0.1j
> > > on
> > > Windows using Oracle JRE 1.7.0_71 and 1.7.0_75 on the client side.
> > > The protocol version in effect is TLS 1.2 (0x303).
> > 
> > There were some fixes related to renegotiation handling in OpenSSL which
> > first appeared in 1.0.1k. Can you see if this problem still happens in the
> > latest version of OpenSSL?
> 
> I was able to reproduce this issue on master, OpenSSL_1_0_2-stable and
> OpenSSL_1_0_1-stable branches as of *now* (2015-02-19).
> 
> I have a standalone (python - tlsfuzzer/tlslite) reproducer for that, but
> the code is pre-alpha quality, I'll try to publish it anyway.
> 
> I've done it with server running in -legacy_renegotiation mode, but I'm not
> sure if this can have any impact on it.

Ok, the reproducer is available:
openssl req -x509 -newkey rsa:1024 -keyout localhost.key -out localhost.crt \
-subj /CN=localhost -nodes -batch -sha1
openssl s_server -key /tmp/localhost.key -cert /tmp/localhost.crt \
-legacy_renegotiation

In another console:
git clone https://github.com/tomato42/tlslite-1.git --branch ort-3712
git clone https://github.com/tomato42/tlsfuzzer.git
cd tlsfuzzer
PYTHONPATH=.:../tlslite-1/ python scripts/test-tls-server.py

That will cause the openssl process to report:
140090260403872:error:140940F5:SSL routines:ssl3_read_bytes:unexpected 
record:s3_pkt.c:1610:

You'll need python 2.6, 3.2 or later (though I haven't verified if this exact 
reproducer works on 2.6, so 2.7 is recommended)
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic



From wilfredsmith at me.com  Fri Feb 20 00:05:12 2015
From: wilfredsmith at me.com (W Smith)
Date: Fri, 20 Feb 2015 00:05:12 +0000 (GMT)
Subject: [openssl-dev] Need Help with BIO callback and/or BIO filter chain
Message-ID: <a6d948e3-fc2a-44d3-acfa-86f6336ab7cd@me.com>

Hi,

I've been tasked with wrapping OpenSSL encrypted traffic in another protocol (HTTP).

I'm able to intrude on the data stream with the BIO callback feature (BIO_set_callback), and have also created a BIO filter to play with. My problem is that the BIO I have access to seems to be the BIO pair above encryption. I need to insert plain text/unencrypted data into the stream, which suggests I need to locate the ultimate source/sink.

All I have access to is the SSL context (SSL*) and the BIO*. The actual code is exceptionally convoluted/fragile, so it would be great to put my modifications only in the BIO callback or in a BIO filter.

Any comment on how that can be done or whether I should take another approach would be appreciated.

Thanks in advance,

W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150220/2f8bf169/attachment-0001.html>

From rsalz at akamai.com  Fri Feb 20 02:47:25 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 20 Feb 2015 02:47:25 +0000
Subject: [openssl-dev] Need Help with BIO callback and/or BIO filter
 chain
In-Reply-To: <a6d948e3-fc2a-44d3-acfa-86f6336ab7cd@me.com>
References: <a6d948e3-fc2a-44d3-acfa-86f6336ab7cd@me.com>
Message-ID: <9359ea1ec126414c852367635df5fdc3@ustx2ex-dag1mb4.msg.corp.akamai.com>

> I've been tasked with wrapping OpenSSL encrypted traffic in another protocol (HTTP).

That's going to be a bit tricky, and require some pretty detailed knowledge of the protocol.  For example, the initial setup -- the hello messages -- will require a couple of POST and reply messages.  Even if you are only ever sending encrypted application data from A to B, you need bidirectional exchanges between the two parties.

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz



From wilfredsmith at me.com  Fri Feb 20 03:32:24 2015
From: wilfredsmith at me.com (W Smith)
Date: Fri, 20 Feb 2015 03:32:24 +0000 (GMT)
Subject: [openssl-dev]
 =?utf-8?q?Need_Help_with_BIO_callback_and/or_BIO_fi?=
 =?utf-8?q?lter_chain?=
Message-ID: <06ea1869-2c1c-45ac-9d1c-5e7b0d0da532@me.com>

Rich,

Yeah, I have industrial strength Tylenol standing by. I'm expecting this to be painful, but not insurmountable for the handshake. If I'm unable to even get at the ultimate source/sink, I can't get anywhere.

I can deal with the HTTP side and the plethora of application-specific and threading issues, but I'm lost on the BIO part. I'll take any pointers or suggestions you can offer.

Thanks for responding and, hopefully, for responding again soon...

W

On Feb 19, 2015, at 06:52 PM, "Salz, Rich" <rsalz at akamai.com> wrote:

I've been tasked with wrapping OpenSSL encrypted traffic in another protocol (HTTP).

That's going to be a bit tricky, and require some pretty detailed knowledge of the protocol. For example, the initial setup -- the hello messages -- will require a couple of POST and reply messages. Even if you are only ever sending encrypted application data from A to B, you need bidirectional exchanges between the two parties.

-- 
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150220/603c25a9/attachment.html>

From rsalz at akamai.com  Fri Feb 20 16:13:06 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 20 Feb 2015 16:13:06 +0000
Subject: [openssl-dev] Need Help with BIO callback and/or BIO filter
 chain
In-Reply-To: <06ea1869-2c1c-45ac-9d1c-5e7b0d0da532@me.com>
References: <06ea1869-2c1c-45ac-9d1c-5e7b0d0da532@me.com>
Message-ID: <ea73eb0f1d9d48c5bb5d6e1ba6b69570@ustx2ex-dag1mb4.msg.corp.akamai.com>

> I can deal with the HTTP side and the plethora of application-specific and threading issues, but I'm lost on the BIO part. I'll take any pointers or suggestions you can offer.

Only to look at SSL_set_bio.

Good luck.

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz



From wilfredsmith at me.com  Fri Feb 20 18:25:39 2015
From: wilfredsmith at me.com (W Smith)
Date: Fri, 20 Feb 2015 18:25:39 +0000 (GMT)
Subject: [openssl-dev]
 =?utf-8?q?Need_Help_with_BIO_callback_and/or_BIO_fi?=
 =?utf-8?q?lter_chain?=
Message-ID: <0d57d9b1-9339-4074-bc46-3707a575789c@me.com>

Thanks, Rich.

Does anyone know how to walk through a BIO stack that includes a "BIO pair" and get to the ultimate source/sink BIO? If I can get that, I'll be in good shape. Anybody?

On Feb 20, 2015, at 08:18 AM, "Salz, Rich" <rsalz at akamai.com> wrote:

I can deal with the HTTP side and the plethora of application-specific and threading issues, but I'm lost on the BIO part. I'll take any pointers or suggestions you can offer.

Only to look at SSL_set_bio.

Good luck.

-- 
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150220/10c660aa/attachment.html>

From steve at openssl.org  Fri Feb 20 18:50:03 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 20 Feb 2015 18:50:03 +0000
Subject: [openssl-dev] Need Help with BIO callback and/or BIO filter
	chain
In-Reply-To: <06ea1869-2c1c-45ac-9d1c-5e7b0d0da532@me.com>
References: <06ea1869-2c1c-45ac-9d1c-5e7b0d0da532@me.com>
Message-ID: <20150220185003.GA8845@openssl.org>

On Fri, Feb 20, 2015, W Smith wrote:

> Rich,
> 
> Yeah, I have industrial strength Tylenol standing by. I'm expecting this to be painful, but not insurmountable for the handshake. If I'm unable to even get at the ultimate source/sink, I can't get anywhere.
> 
> I can deal with the HTTP side and the plethora of application-specific and threading issues, but I'm lost on the BIO part. I'll take any pointers or suggestions you can offer.
> 

If I understand what you're trying to do I can see a couple of options.

One is to write your own BIO which looks like an "ordinary" BIO to the TLS
library but does all the translation under the hood. You could start with the
socket BIO and adapt it to your needs, making sure you handle non-blocking I/O
correctly.

The other is a BIO pair where this I/O can be handled at an application level
but you have to be careful to get everything right so there aren't any
deadlocks. You mentioned a BIO pair in the other message though. Are you
already using a BIO pair?

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From steve at openssl.org  Fri Feb 20 22:21:48 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 20 Feb 2015 22:21:48 +0000
Subject: [openssl-dev] Need Help with BIO callback and/or BIO filter
	chain
In-Reply-To: <0d57d9b1-9339-4074-bc46-3707a575789c@me.com>
References: <0d57d9b1-9339-4074-bc46-3707a575789c@me.com>
Message-ID: <20150220222148.GA22477@openssl.org>

On Fri, Feb 20, 2015, W Smith wrote:

> Thanks, Rich.
> 
> Does anyone know how to walk through a BIO stack that includes a "BIO pair" and get to the ultimate source/sink BIO? If I can get that, I'll be in good shape. Anybody?
> 

Not sure I follow you. A BIO pair is the ultimate source/sink BIO. The data
read from or written to the BIO may come from another BIO (or any source
whatsoever) but that depends on application code and the BIO pair doesn't
contain any information about where its data comes from.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From p.mrunal at gmail.com  Mon Feb 23 09:36:13 2015
From: p.mrunal at gmail.com (Mrunal Nerpawar)
Date: Mon, 23 Feb 2015 15:06:13 +0530
Subject: [openssl-dev] FIPSLD 2.0.5 (HP-UX AI64 11.23) fails to link with
	pthread error
Message-ID: <CAF5AerH_+p_Fo0tb3o6Yh2V1Heqx3vxw=hgUY4sRHtEdihnzJQ@mail.gmail.com>

Details
======
Fips 2.0.5 configured with no-asm and threads.
Openssl 1.0.1H configured with shared, fips, threads no-asm (many alogos
omitted)
compiler -  using aCC 6.25 on HPUX-IA64 11.23.

bash-2.05$ aCC --version
aCC: HP C/aC++ B3910B A.06.25.02 [Nov 25 2010]
bash-2.05$

product linking with fipsld fails with error ...
=================================
:DLFCN_LOAD:could not load the shared
library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):
Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it
contains thread specific data.

Options tried
==========
* Compiling Cxx sources with -mt.
* Linking with -lpthread,
* setting LD_PRELOAD.
None worked effectively. with LD_PRELOAD option, ended up getting error -
undefined symbol Ztil, etc.

complete error is as follows.
=====================

Building shared library
objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
FIPSLD_CC=aCC FIPSLD_LINK=aCC
/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/fipsld
+Z -b -g -O2 -AA -Wl,+s +tls=dynamic -o
objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
objs/HP-UX-B.11.23-ia64-64/stdafx.o objs/HP-UX-B.11.23-ia64-64/UserUtil.o
objs/HP-UX-B.11.23-ia64-64/LSSpawner.o
objs/HP-UX-B.11.23-ia64-64/LSFilter.o
objs/HP-UX-B.11.23-ia64-64/LSCmdOutputParser.o
objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor.o
objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_1.o
objs/HP-UX-B.11.23-ia64-64/LSBuilderAndProcessor_2.o
objs/HP-UX-B.11.23-ia64-64/GroupUtil.o
objs/HP-UX-B.11.23-ia64-64/ShadowHelper.o
objs/HP-UX-B.11.23-ia64-64/BlockedFiles.o
objs/HP-UX-B.11.23-ia64-64/NISUtil.o objs/HP-UX-B.11.23-ia64-64/Utilities.o
objs/HP-UX-B.11.23-ia64-64/MachineUtil.o
objs/HP-UX-B.11.23-ia64-64/BvNetworkInfo.o
objs/HP-UX-B.11.23-ia64-64/NSSwitch.o
objs/HP-UX-B.11.23-ia64-64/FileUtil_1.o
objs/HP-UX-B.11.23-ia64-64/FileUtil_2.o
objs/HP-UX-B.11.23-ia64-64/SecurityThreatCheck.o
objs/HP-UX-B.11.23-ia64-64/UserEnumerator.o
objs/HP-UX-B.11.23-ia64-64/LocalUserEnumerator.o
objs/HP-UX-B.11.23-ia64-64/UnixUserEnumerator.o
objs/HP-UX-B.11.23-ia64-64/WinUserEnumerator.o
objs/HP-UX-B.11.23-ia64-64/GetEntHandler.o
objs/HP-UX-B.11.23-ia64-64/UnixShadowReader.o
objs/HP-UX-B.11.23-ia64-64/EtcShadowReader.o
objs/HP-UX-B.11.23-ia64-64/UnixEtcShadowReader.o
objs/HP-UX-B.11.23-ia64-64/AIXShadowHelper.o
objs/HP-UX-B.11.23-ia64-64/HPLoginsShadowHelper.o
objs/HP-UX-B.11.23-ia64-64/HPTcbShadowHelper.o
objs/HP-UX-B.11.23-ia64-64/UnixHPShadowReader.o
objs/HP-UX-B.11.23-ia64-64/ProcessUtil.o
objs/HP-UX-B.11.23-ia64-64/FieldUtils.o
objs/HP-UX-B.11.23-ia64-64/LoggedInUserInfo.o
objs/HP-UX-B.11.23-ia64-64/TcpdRulesParser.o
objs/HP-UX-B.11.23-ia64-64/DirectoryUtil.o
objs/HP-UX-B.11.23-ia64-64/Timestamp.o
objs/HP-UX-B.11.23-ia64-64/Timespan.o
objs/HP-UX-B.11.23-ia64-64/NumberFormatter.o
objs/HP-UX-B.11.23-ia64-64/DateTimeParser.o
objs/HP-UX-B.11.23-ia64-64/DateTimeFormatter.o
objs/HP-UX-B.11.23-ia64-64/DateTimeFormat.o
objs/HP-UX-B.11.23-ia64-64/DateTime.o objs/HP-UX-B.11.23-ia64-64/Timezone.o
objs/HP-UX-B.11.23-ia64-64/LocalDateTime.o
objs/HP-UX-B.11.23-ia64-64/RFUtilities.o
objs/HP-UX-B.11.23-ia64-64/OpenPortUtil.o
objs/HP-UX-B.11.23-ia64-64/AIXStanzaReader.o
objs/HP-UX-B.11.23-ia64-64/Bugcheck.o objs/HP-UX-B.11.23-ia64-64/DateTime.o
objs/HP-UX-B.11.23-ia64-64/Debugger.o
objs/HP-UX-B.11.23-ia64-64/Exception.o
objs/HP-UX-B.11.23-ia64-64/GroupEnumerator.o
objs/HP-UX-B.11.23-ia64-64/UnixGroupEnumerator.o
objs/HP-UX-B.11.23-ia64-64/FileInfoFetcher.o
objs/HP-UX-B.11.23-ia64-64/UnixFileInfoAccessor.o
objs/HP-UX-B.11.23-ia64-64/FileStatSysCallProcessor.o
objs/HP-UX-B.11.23-ia64-64/StatSysCallFileInfoFetcherImpl.o
objs/HP-UX-B.11.23-ia64-64/FileInfoAccessor.o
objs/HP-UX-B.11.23-ia64-64/FileProcessorObjectFactory.o
objs/HP-UX-B.11.23-ia64-64/UUID.o objs/HP-UX-B.11.23-ia64-64/RandomStream.o
objs/HP-UX-B.11.23-ia64-64/Random.o objs/HP-UX-B.11.23-ia64-64/SHA1Engine.o
objs/HP-UX-B.11.23-ia64-64/DigestEngine.o
objs/HP-UX-B.11.23-ia64-64/FileDescriptorUtil.o
objs/HP-UX-B.11.23-ia64-64/PasswordInfo.o
objs/HP-UX-B.11.23-ia64-64/DictionaryReader.o
objs/HP-UX-B.11.23-ia64-64/PasswordCracker.o
objs/HP-UX-B.11.23-ia64-64/md5crypt.o
-L/unixhome/user/workspace/ontrolShared/UnixReusableClasses/lib/HP-UX-B.11.23-ia64-64
-lReCpp -lReCommon
-L/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/lib -lcrypto
-L/unixhome/user/workspace/product/lib/HP-UX-B.11.23-ia64-64 -lAgentCommon
-lReCoreClasses -lCommonLib  -lsec
fipsld:
THERE=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/..
fipsld: TARGET=./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0
fipsld:
CANISTER_O=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fipscanister.o
fipsld:
PREMAIN_C=/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c
fipsld: PREMAIN_O=objs/HP-UX-B.11.23-ia64-64/fips_premain.o
fipsld: FIPSLIBDIR=
fipsld: FIPSLD_CC=aCC
fipsld: FIPSLD_LINK=aCC
fipsld: Linking shared library file.
fipsld: Compiling
"/unixhome/user/workspace/product/../3rdPt/Unix/HP-UX/ia64/OpenSource/ssl-1.0.1h/bin/../lib/fips_premain.c".
fipsld: Linking "./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0"
with FIPS libaries.
2130621380:error:25066067:DSO support routines:DLFCN_LOAD:could not load
the shared
library:dso_dlfcn.c:187:filename(./objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0):
Cannot dlopen load module '/usr/lib/hpux32/libpthread.so.1' because it
contains thread specific data.
2130621380:error:25070067:DSO support routines:DSO_load:could not load the
shared library:dso_lib.c:244:
/unixhome/user/workspace/product/Packages/BuildScripts/Makefiles/Make.inc.shlib.rules:73:
recipe for target 'objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0'
failed
gmake: *** [objs/HP-UX-B.11.23-ia64-64/libDataSourceImpl.so.10.0.0] Error 1
bash-2.05$


We are running short of time. If anybody has any solutions/suggestions
help, would be appreciated.

Thanks in advance.

Best regards,
Mrunal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150223/49bf200f/attachment-0001.html>

From rainer.jung at kippdata.de  Mon Feb 23 10:53:17 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Mon, 23 Feb 2015 11:53:17 +0100
Subject: [openssl-dev] Submitting new bugs to rt via mail broken?
In-Reply-To: <54DA6A7A.9060106@openssl.org>
References: <54DA5AC1.7000306@kippdata.de> <54DA6A7A.9060106@openssl.org>
Message-ID: <54EB069D.5060603@kippdata.de>

Am 10.02.2015 um 21:30 schrieb Matt Caswell:

> On 10/02/15 19:23, Rainer Jung wrote:
>> Hello everyone,
>>
>> I sent a mail to rt at openssl.org 3 days ago, subject "OpenSSL 1.0.2 "make
>> test" bus error in evp_test (Solaris 10 Sparc, sun4u)".
>>
>> The mail didn't create a new ticket in RT, nor was it forwarded to the
>> dev list.
>>
>> Should I resend or simply be more patient?
>
> Email to rt is manually moderated by Lutz. Sometimes it can take a few
> days to come through. Very occasionally a genuine email gets lost within
> the swamp of spam. I would be a little more patient, but if it doesn't
> arrive in a couple more days then try again.

I tried again on Feb 14, about a week ago. Still nothing shows up in RT 
or on mailing lists. Other mails on the dev list also indicate problems 
with stalled RT communication.

If it helps, I can send the original mail via PM or to this list here.

Regards,

Rainer


From rt at openssl.org  Mon Feb 23 12:49:09 2015
From: rt at openssl.org (Albe Laurenz via RT)
Date: Mon, 23 Feb 2015 13:49:09 +0100
Subject: [openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is
	broken
In-Reply-To: <A737B7A37273E048B164557ADEF4A58B3659F1D4@ntex2010i.host.magwien.gv.at>
References: <RT-Ticket-3712@openssl.org>
 <A737B7A37273E048B164557ADEF4A58B3659F1D4@ntex2010i.host.magwien.gv.at>
Message-ID: <rt-4.0.4-11142-1424695749-1147.3712-6-0@openssl.org>

Thanks for looking into this, and thanks for providing a reproducer.

I just tried with the current git HEAD from 2015-02-23 (1.1.0) and was
able to reproduce the bug with PostgreSQL.

I just saw that there is bug #2481 which is probably the same problem.
This bug was created in 2011 and is still unresolved.

Yours,
Laurenz Albe


From dwmw2 at infradead.org  Mon Feb 23 14:34:09 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Mon, 23 Feb 2015 14:34:09 +0000
Subject: [openssl-dev] DTLS_BAD_VER regression fixes for 1.0.2 and HEAD
Message-ID: <1424702049.5437.222.camel@infradead.org>

I have created pull requests on Github for HEAD and 1.0.2:
https://github.com/openssl/openssl/pull/228 (master)
https://github.com/openssl/openssl/pull/229 (OpenSSL_1_0_2-stable)

These contain the fixes I have already filed in RT#3703, RT#3704 and
RT#3711.

For master, it also introduces DTLSv0_9_client_method() as discussed? in
RT#3711. I didn't do that for 1.0.2 but perhaps we could.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

? OK, 'discussed' is a strong word...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150223/4e67668e/attachment.bin>

From rt at openssl.org  Mon Feb 23 15:13:33 2015
From: rt at openssl.org (Rainer Jung via RT)
Date: Mon, 23 Feb 2015 16:13:33 +0100
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
	error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <54DF6AB4.7090403@kippdata.de>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
Message-ID: <rt-4.0.4-6511-1424704413-608.3714-21-0@openssl.org>

2nd attempt. First sent on Feb 7th.

I get a failure for 1.0.2 running make test on Solaris 10.

It might be related to #3688, but I don't think so.

Mine is a sun4u machine, so neither T2 nor T4.
Compilation done with gcc 4.9.1 with v9 target.

Failure is a bus error in evp_test.

gdb shows the following details:

(gdb) bt full
#0  CRYPTO_ccm128_decrypt (ctx=0x6cbd0, inp=0xffbfd091 
"\232_...230dxg&f042382d949b43b7d6bb2b9864786726",
     out=0xffbfdfe8 "...", len=32) at ccm128.c:300
         temp = <optimized out>
         n = 32
         i = <optimized out>
         L = 1
         flags0 = 121 'y'
         block = 0xff1ee3c0 <AES_encrypt>
         key = 0x6cac0
         scratch = {u = {14547399086359111669, 7716584104704463675}, c = 
"..."}
#1  0xff26d774 in aes_ccm_cipher (ctx=0xffbfcf5c, out=0xffbfdfe8 "...",
     in=0xffbfd091 "...", len=32) at e_aes.c:1893
         rv = -1
         cctx = 0x6cac0
         ccm = 0x6cbd0
#2  0xff267f6c in EVP_DecryptUpdate (ctx=ctx at entry=0xffbfcf5c, 
out=out at entry=0xffbfdfe8 "...", outl=outl at entry=0xffbfcf40,
     in=in at entry=0xffbfd091 "...", inl=inl at entry=32) at evp_enc.c:437
         fix_len = <optimized out>
         b = <optimized out>
#3  0x0001301c in test1 (encdec=<optimized out>, tn=16, tag=<optimized 
out>, an=<optimized out>, aad=<optimized out>, cn=32,
     ciphertext=0xffbfd091 "...", pn=32,
     plaintext=0xffbfd050 "...", in=<optimized out>,
     iv=0xffbfd035 "...", kn=<optimized out>, key=<optimized out>, 
c=0xff342150) at evp_test.c:346
         ctx = {cipher = 0xff342150, engine = 0x0, encrypt = 0, buf_len 
= 0, oiv = '\000' <repeats 15 times>, iv = "...",
           buf = "...", '\000' <repeats 15 times>, num = 0, app_data = 
0x0, key_len = 32, flags = 257, cipher_data = 0x6cac0, final_used = 0,
           block_mask = 0, final = '\000' <repeats 31 times>}
         outl = 32
         out = "..."...
         outl2 = 0
         mode = <optimized out>
#4  test_cipher (encdec=<optimized out>, tn=16, tag=<optimized out>, 
an=<optimized out>, aad=<optimized out>, cn=32,
     ciphertext=0xffbfd091 "...", pn=32,
     plaintext=0xffbfd050 "...", in=<optimized out>,
     iv=0xffbfd035 "...", kn=<optimized out>, key=<optimized out>, 
cipher=<optimized out>) at evp_test.c:390
         c = 0x13920
#5  main (argc=<optimized out>, argv=<optimized out>) at evp_test.c:546
         line = "aes-256-ccm..."...
         encdec = <optimized out>
         tag = <optimized out>
         an = <optimized out>
         tn = 16
         p = <optimized out>
         aad = <optimized out>
         szTestFile = <optimized out>
         f = <optimized out>


Funny is, that a bus error on Sparc often is due to an alignment 
problem, and line 300 where it crashes is:

    289      while (len >= 16) {
    290  #if defined(STRICT_ALIGNMENT)
    291          union {
    292              u64 u[2];
    293              u8 c[16];
    294          } temp;
    295  #endif
    296          (*block) (ctx->nonce.c, scratch.c, key);
    297          ctr64_inc(ctx->nonce.c);
    298  #if defined(STRICT_ALIGNMENT)
    299          memcpy(temp.c, inp, 16);
    300          ctx->cmac.u[0] ^= (scratch.u[0] ^= temp.u[0]);
    301          ctx->cmac.u[1] ^= (scratch.u[1] ^= temp.u[1]);
    302          memcpy(out, scratch.c, 16);
    303  #else
    304          ctx->cmac.u[0] ^= (((u64 *)out)[0] = scratch.u[0] ^ 
((u64 *)inp)[0]);
    305          ctx->cmac.u[1] ^= (((u64 *)out)[1] = scratch.u[1] ^ 
((u64 *)inp)[1]);
    306  #endif
    307          (*block) (ctx->cmac.c, ctx->cmac.c, key);
    308
    309          inp += 16;
    310          out += 16;
    311          len -= 16;
    312      }

so inside a "STRICT_ALIGNMENT" block ...

Now ctx->cmac.u[0] and scratch.u[0] seem to be aligned correct to me:

(gdb) print &ctx->cmac.u[0]
$10 = (u64 *) 0x6cbe0
(gdb) print &scratch.u[0]
$12 = (u64 *) 0xffbfcdd0

but temp is not available in gdb:

(gdb) print temp.u[0]
value has been optimized out

It is defined as

    290  #if defined(STRICT_ALIGNMENT)
    291          union {
    292              u64 u[2];
    293              u8 c[16];
    294          } temp;
    295  #endif


gdb command "info registers" says:

g0             0x0      0
g1             0x2      2
g2             0x6c     108
g3             0x4d0000 5046272
g4             0xb0009600       -1342138880
g5             0x3b     59
g6             0x0      0
g7             0xff392a00       -13030912
o0             0xffbfdfe8       -4202520
o1             0xffbfcdd0       -4207152
o2             0x10     16
o3             0x41     65
o4             0x0      0
o5             0x4      4
sp             0xffbfcd60       0xffbfcd60
o7             0xff208064       -14647196
l0             0xffbfcdd0       -4207152
l1             0xff1ee3c0       -14752832
l2             0x6cac0  445120
l3             0x10     16
l4             0xffbfdff8       -4202504
l5             0x6cbe0  445408
l6             0x1      1
l7             0xff338dd8       -13398568
i0             0xffffffff       -1
i1             0xffbfd091       -4206447
i2             0xffbfdfe8       -4202520
i3             0x20     32
i4             0xffbfd091       -4206447
i5             0x6cbd0  445392
fp             0xffbfcde0       0xffbfcde0
i7             0xff26d76c       -14231700
y              0x0      0
psr            0xfe001001       [ #0 EF #25 #26 #27 #28 #29 #30 #31 ]
wim            *value not available*
tbr            *value not available*
pc             0xff208114       0xff208114 <CRYPTO_ccm128_decrypt+532>
npc            0xff208118       0xff208118 <CRYPTO_ccm128_decrypt+536>
fsr            0x0      [ ]
csr            *value not available*

So the addresses of ctx->cmac.u[0] (0x6cbe0) and scratch.u[0] 
(0xffbfcdd0) are in registers l5 resp. l0.


Looking at disassembly around CRYPTO_ccm128_decrypt+532 (decimal 532 = 
0x214):

     CRYPTO_ccm128_decrypt+0x1d8: 12 40 00 0f  bne,pn    %icc, +0x3c 
<CRYPTO_ccm128_decrypt+0x214>
     CRYPTO_ccm128_decrypt+0x1dc: c2 2f 60 0b  stb       %g1, [%i5 + 0xb]
     CRYPTO_ccm128_decrypt+0x1e0: c2 0f 60 0a  ldub      [%i5 + 0xa], %g1
     CRYPTO_ccm128_decrypt+0x1e4: 82 00 60 01  add       %g1, 0x1, %g1
     CRYPTO_ccm128_decrypt+0x1e8: 80 88 60 ff  btst      0xff, %g1
     CRYPTO_ccm128_decrypt+0x1ec: 12 40 00 0a  bne,pn    %icc, +0x28 
<CRYPTO_ccm128_decrypt+0x214>
     CRYPTO_ccm128_decrypt+0x1f0: c2 2f 60 0a  stb       %g1, [%i5 + 0xa]
     CRYPTO_ccm128_decrypt+0x1f4: c2 0f 60 09  ldub      [%i5 + 0x9], %g1
     CRYPTO_ccm128_decrypt+0x1f8: 82 00 60 01  add       %g1, 0x1, %g1
     CRYPTO_ccm128_decrypt+0x1fc: 80 88 60 ff  btst      0xff, %g1
     CRYPTO_ccm128_decrypt+0x200: 12 40 00 05  bne,pn    %icc, +0x14 
<CRYPTO_ccm128_decrypt+0x214>
     CRYPTO_ccm128_decrypt+0x204: c2 2f 60 09  stb       %g1, [%i5 + 0x9]
     CRYPTO_ccm128_decrypt+0x208: c2 0f 60 08  ldub      [%i5 + 0x8], %g1
     CRYPTO_ccm128_decrypt+0x20c: 82 00 60 01  add       %g1, 0x1, %g1
     CRYPTO_ccm128_decrypt+0x210: c2 2f 60 08  stb       %g1, [%i5 + 0x8]
     CRYPTO_ccm128_decrypt+0x214: f4 1f 00 00  ldd       [%i4], %i2
     CRYPTO_ccm128_decrypt+0x218: b8 07 20 10  add       %i4, 0x10, %i4
     CRYPTO_ccm128_decrypt+0x21c: c4 1f bf f0  ldd       [%fp - 0x10], %g2
     CRYPTO_ccm128_decrypt+0x220: d8 1f 3f f8  ldd       [%i4 - 0x8], %o4
     CRYPTO_ccm128_decrypt+0x224: b0 1e 80 02  xor       %i2, %g2, %i0
     CRYPTO_ccm128_decrypt+0x228: b2 1e c0 03  xor       %i3, %g3, %i1
     CRYPTO_ccm128_decrypt+0x22c: c4 1f bf f8  ldd       [%fp - 0x8], %g2
     CRYPTO_ccm128_decrypt+0x230: f0 3f bf f0  std       %i0, [%fp - 0x10]
     CRYPTO_ccm128_decrypt+0x234: 84 1b 00 02  xor       %o4, %g2, %g2
     CRYPTO_ccm128_decrypt+0x238: 86 1b 40 03  xor       %o5, %g3, %g3
     CRYPTO_ccm128_decrypt+0x23c: d8 1f 60 10  ldd       [%i5 + 0x10], %o4
     CRYPTO_ccm128_decrypt+0x240: c4 3f bf f8  std       %g2, [%fp - 0x8]
     CRYPTO_ccm128_decrypt+0x244: b4 1b 00 18  xor       %o4, %i0, %i2
     CRYPTO_ccm128_decrypt+0x248: b6 1b 40 19  xor       %o5, %i1, %i3
     CRYPTO_ccm128_decrypt+0x24c: d8 1f 60 18  ldd       [%i5 + 0x18], %o4
     CRYPTO_ccm128_decrypt+0x250: f4 3f 60 10  std       %i2, [%i5 + 0x10]
     CRYPTO_ccm128_decrypt+0x254: b4 1b 00 02  xor       %o4, %g2, %i2
     CRYPTO_ccm128_decrypt+0x258: b6 1b 40 03  xor       %o5, %g3, %i3
     CRYPTO_ccm128_decrypt+0x25c: 40 04 c3 3a  call      +0x130ce8 
<0x1b8e44>

If the 0x214 address is correct, then the statement would be:

     CRYPTO_ccm128_decrypt+0x214: f4 1f 00 00  ldd       [%i4], %i2

Content of %i4 is 0xffbfd091, which is an odd number, so probably not a 
good address to load a double word from.

That's all I can see. I hope Adny has a better idea of what's happening 
here.

If there is need, I can provide more data and test (debug) patches.

Thanks a bunch!

Rainer



From jaenicke at openssl.org  Mon Feb 23 15:15:14 2015
From: jaenicke at openssl.org (Lutz Jaenicke)
Date: Mon, 23 Feb 2015 15:15:14 +0000
Subject: [openssl-dev] Submitting new bugs to rt via mail broken?
In-Reply-To: <54EB069D.5060603@kippdata.de>
References: <54DA5AC1.7000306@kippdata.de> <54DA6A7A.9060106@openssl.org>
 <54EB069D.5060603@kippdata.de>
Message-ID: <20150223151514.GB20043@openssl.org>

On Mon, Feb 23, 2015 at 11:53:17AM +0100, Rainer Jung wrote:
> Am 10.02.2015 um 21:30 schrieb Matt Caswell:
> 
> >On 10/02/15 19:23, Rainer Jung wrote:
> >>Hello everyone,
> >>
> >>I sent a mail to rt at openssl.org 3 days ago, subject "OpenSSL 1.0.2 "make
> >>test" bus error in evp_test (Solaris 10 Sparc, sun4u)".
> >>
> >>The mail didn't create a new ticket in RT, nor was it forwarded to the
> >>dev list.
> >>
> >>Should I resend or simply be more patient?
> >
> >Email to rt is manually moderated by Lutz. Sometimes it can take a few
> >days to come through. Very occasionally a genuine email gets lost within
> >the swamp of spam. I would be a little more patient, but if it doesn't
> >arrive in a couple more days then try again.
> 
> I tried again on Feb 14, about a week ago. Still nothing shows up in
> RT or on mailing lists. Other mails on the dev list also indicate
> problems with stalled RT communication.

Please don't send your original submissions as replies to other emails.
It just was sorted into the thread and I hence missed it.

Sorry,
	Lutz

From rt at openssl.org  Mon Feb 23 15:16:02 2015
From: rt at openssl.org (Tobias Firnges via RT)
Date: Mon, 23 Feb 2015 16:16:02 +0100
Subject: [openssl-dev] [openssl.org #3715] Possible bug in openssl 64 bit
	version
In-Reply-To: <DUB109-W48545F31D9E46CC6BBA083F0290@phx.gbl>
References: <RT-Ticket-3715@openssl.org>
 <DUB109-W48545F31D9E46CC6BBA083F0290@phx.gbl>
Message-ID: <rt-4.0.4-6511-1424704562-581.3715-21-0@openssl.org>

Hello,

I would like you to verify the following issue:

You can find the version information in the attached screenshot.

- OS: Windows 8.1 64 bit
- Hardware: Hyper-V on a Dell T110 II as well as a HP ProBook 470 G2
- I used the version of openssl from http://slproweb.com/products/Win32OpenSSL.html
- Compiler: Visual Studio 2013 and also tested with codeblocks.org software <-- Same result
- Detailed description of the error here:

I have tested the following code with Win32 OpenSSL v1.0.1L and Win64 OpenSSL:
----------------------------------
#define _CRT_SECURE_NO_WARNINGS

#include <iostream> 
#include <sstream> 
#include <string> 
#include <iomanip> 
#include <stdio.h> 
#include <openssl/sha.h>

using namespace std;

string sha256(const string str)
{
    unsigned char hash[SHA256_DIGEST_LENGTH];
    SHA256_CTX sha256;
    SHA256_Init(&sha256);
    SHA256_Update(&sha256, str.c_str(), str.size());

    SHA256_Final(hash, &sha256);

    stringstream ss;
    for (int i = 0; i < SHA256_DIGEST_LENGTH; i++)
    {
        ss << hex << std::setw(2) << setfill('0') << (int)hash[i];
    }

    return ss.str();
}

void sha256_hash_string(unsigned char hash[SHA256_DIGEST_LENGTH], char outputBuffer[65])
{
    int i = 0;

    for (i = 0; i < SHA256_DIGEST_LENGTH; i++)
    {
        sprintf(outputBuffer + (i * 2), "%02x", hash[i]);
    }

    outputBuffer[64] = 0;
}

int sha256_file(char* path, char output[65])
{
    FILE *file = fopen(path, "rb");
    if (!file) return -1;

    unsigned char hash[SHA256_DIGEST_LENGTH];
    SHA256_CTX sha256;
    SHA256_Init(&sha256);
    const int bufSize = 32768;
    char *buffer = new char[bufSize];
    int bytesRead = 0;
    if (!buffer) return -1;
    while ((bytesRead = (int)fread(buffer, 1, bufSize, file)))
    {
        SHA256_Update(&sha256, buffer, bytesRead);
    }
    SHA256_Final(hash, &sha256);

    sha256_hash_string(hash, output);
    fclose(file);
    delete[] buffer;
    return 0;
}

int main()
{

    // hash a string 
    std::cout << "SHA-256 hash of \"Sample String\" text:" << std::endl;
    std::cout << sha256("Sample String") << std::endl << std::endl;

    // hash a file 
    cout << "SHA-256 hash of file cmd.exe:" << std::endl;
    char calc_hash[65];
    sha256_file("C:\\Windows\\System32\\cmd.exe", calc_hash);
    cout << calc_hash << std::endl;
    cout << "SHA-256 hash of file NETSTAT.exe:" << std::endl;
    sha256_file("C:\\Windows\\System32\\NETSTAT.exe", calc_hash);
    cout << calc_hash << std::endl;
    cout << "SHA-256 hash of file eula.1028.txt:" << std::endl;
    sha256_file("C:\\eula.1028.txt", calc_hash);
    cout << calc_hash << std::endl;

    cin.clear();
    cin.ignore(255, '\n');
    cin.get();

    return 0;
}
----------------------------------
The code worked fine with Win32 OpenSSL v1.0.1L, however, when I tried the code with Win64 OpenSSL v1.0.1L, I get a wrong result.

In my test I did the following:

1. On a 64 bit Windows 8.1 machine, I first tested Win32 OpenSSL v1.0.1L. The results were correct
2. I then changed to Win64 OpenSSL v1.0.1.L (inculuding the 64 bit Visual C++ redistributables). The result was correct for Strings and for the txt file, but for exe files the hash is not correct. (See attached screenshot)
3. I then compiled the same code on a 32 bit Windows 7 machine with Win32 OpenSSL v1.0.1L and copied the file to the 64 bit machine. Now the String, txt file and exe file hash show the right value.

For compiling I used Visual Studio 2013 and do compare, if the compiler was the issue, I used the latest version of the codeblocks.org software to compile. I always got the same result. All hashs created with Win32 OpenSSL were correct, the hash of exe files created with Win64 OpenSSL was wrong.


And my target is to get the correct hash of each file I check in the 32 bit, as well as in the 64 bit environment.

Note: I double checked all the files I tested in online hash calculators. And there I could see, the value for the exe files created with Win64 OpenSSL v1.0.1L were wrong.

Can you please confirm my result. Maybe you find an error in my code. If the error is in Win64 OpenSSL v1.0.1L, please help to release a new version of the tool with the issue fixed.

Note: I first sent the issue to Shining Light Production where I got the following answer:
-------------------------
Even if there is a problem, there's nothing I can do.  I just build the 
upstream source code into binaries using the officially published 
directions for building OpenSSL.
 
You need to take this upstream to the openssl-users mailing list. 
However, you are the first person to have this issue (or I'd see a LOT 
more yelling about it), so I'd wager that there is something wrong with 
your code rather than with OpenSSL.  Still, there are people there who 
can look at your code and evaluate it for accuracy and correctness.
-------------------------


Thank you for your answer in advance.


Best regards
Tobias 		 	   		  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssl-version.jpg
Type: image/jpeg
Size: 76310 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150223/e731aa9d/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hash_x86.jpg
Type: image/jpeg
Size: 55436 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150223/e731aa9d/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hash_x64.jpg
Type: image/jpeg
Size: 59625 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150223/e731aa9d/attachment-0005.jpg>

From rainer.jung at kippdata.de  Mon Feb 23 15:59:11 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Mon, 23 Feb 2015 16:59:11 +0100
Subject: [openssl-dev] Submitting new bugs to rt via mail broken?
In-Reply-To: <20150223151514.GB20043@openssl.org>
References: <54DA5AC1.7000306@kippdata.de> <54DA6A7A.9060106@openssl.org>
 <54EB069D.5060603@kippdata.de> <20150223151514.GB20043@openssl.org>
Message-ID: <54EB4E4F.2010009@kippdata.de>

Am 23.02.2015 um 16:15 schrieb Lutz Jaenicke:
> On Mon, Feb 23, 2015 at 11:53:17AM +0100, Rainer Jung wrote:
>> Am 10.02.2015 um 21:30 schrieb Matt Caswell:
>>
>>> On 10/02/15 19:23, Rainer Jung wrote:
>>>> Hello everyone,
>>>>
>>>> I sent a mail to rt at openssl.org 3 days ago, subject "OpenSSL 1.0.2 "make
>>>> test" bus error in evp_test (Solaris 10 Sparc, sun4u)".
>>>>
>>>> The mail didn't create a new ticket in RT, nor was it forwarded to the
>>>> dev list.
>>>>
>>>> Should I resend or simply be more patient?
>>>
>>> Email to rt is manually moderated by Lutz. Sometimes it can take a few
>>> days to come through. Very occasionally a genuine email gets lost within
>>> the swamp of spam. I would be a little more patient, but if it doesn't
>>> arrive in a couple more days then try again.
>>
>> I tried again on Feb 14, about a week ago. Still nothing shows up in
>> RT or on mailing lists. Other mails on the dev list also indicate
>> problems with stalled RT communication.
>
> Please don't send your original submissions as replies to other emails.
> It just was sorted into the thread and I hence missed it.

Oups, then it was my bad. I'm sorry about that!

Regards,

Rainer


From rt at openssl.org  Mon Feb 23 18:54:00 2015
From: rt at openssl.org (Rainer Jung via RT)
Date: Mon, 23 Feb 2015 19:54:00 +0100
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
	error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <54EB7723.4020903@kippdata.de>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
 <rt-4.0.4-6511-1424704413-608.3714-21-0@openssl.org>
 <54EB7723.4020903@kippdata.de>
Message-ID: <rt-4.0.4-26171-1424717640-785.3714-6-0@openssl.org>

I updated gcc from 4.9.1 to 4.9.2 and the crash is gone.

Details maybe useful to others running into this problem:

It does not occur with gcc 4.8.4, but it occurs every time with gcc 4.9.1.

The crash also does not occur as soon as I add a debug fprintf() for the 
ctx->cmac, scratch and temp variable addresses.

The crash does not occur, if I compile ccm128.c without gcc -O flag or 
with -O0. It does always occur with O1, O2 and O3 (combined with gcc 4.9.1).

gcc flags:

gcc
-I..
-I../..
-I../modes
-I../asn1
-I../evp
-I../../include
-fPIC
-DOPENSSL_PIC
-DOPENSSL_THREADS
-D_REENTRANT
-DDSO_DLFCN
-DHAVE_DLFCN_H
-fPIC
-mcpu=v9
-g
-Wall
-fno-strict-aliasing
-m32
-mcpu=ultrasparc
-O3
-fomit-frame-pointer
-Wall
-DB_ENDIAN
-DBN_DIV2W
-DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_GF2m
-DSHA1_ASM
-DSHA256_ASM
-DSHA512_ASM
-DMD5_ASM
-DAES_ASM
-DGHASH_ASM
-c
-o
ccm128.o
ccm128.c

The u64 type seems to get correctly translated into unsigned long long.

Somehow the temp variable is not aligned correctly if kept in registers 
only.

The assembler diff between 4.9.1 and 4.9.2 around the suspect code is:

         ldub    [%i5+8], %g1
         add     %g1, 1, %g1
         stb     %g1, [%i5+8]
-       ldd     [%i4], %i2
+       ldub    [%i4+12], %g1
         add     %i4, 16, %i4
+       ldub    [%i4-3], %g4
+       sll     %g1, 24, %i1
+       ldub    [%i4-12], %g3
+       ldub    [%i4-11], %g2
+       sll     %g4, 16, %g1
+       ldub    [%i4-7], %i0
+       sll     %g3, 24, %o7
+       or      %g1, %i1, %g1
+       ldub    [%i4-2], %g4
+       sll     %g2, 16, %g2
+       ldub    [%i4-8], %i1
+       sll     %i0, 16, %i0
+       or      %g2, %o7, %g3
+       ldub    [%i4-10], %g2
+       sll     %g4, 8, %g4
+       sll     %i1, 24, %i1
+       or      %g4, %g1, %g4
+       ldub    [%i4-16], %o7
+       ldub    [%i4-15], %g1
+       sll     %g2, 8, %g2
+       or      %i0, %i1, %i0
+       ldub    [%i4-6], %i1
+       sll     %o7, 24, %o7
+       or      %g2, %g3, %g2
+       ldub    [%i4-14], %g3
+       sll     %g1, 16, %g1
+       sll     %i1, 8, %i1
+       or      %g1, %o7, %g1
+       ldub    [%i4-1], %o3
+       sll     %g3, 8, %g3
+       or      %i1, %i0, %i1
+       ldub    [%i4-5], %i0
+       ldub    [%i4-9], %o7
+       or      %g3, %g1, %g1
+       or      %o3, %g4, %o5
+       ldub    [%i4-13], %g3
+       or      %i0, %i1, %o4
+       ldd     [%fp-8], %i0
+       or      %o7, %g2, %i3
+       or      %g3, %g1, %i2
         ldd     [%fp-16], %g2
-       ldd     [%i4-8], %o4
-       xor     %i2, %g2, %i0
-       xor     %i3, %g3, %i1
-       ldd     [%fp-8], %g2
-       std     %i0, [%fp-16]
-       xor     %o4, %g2, %g2
-       xor     %o5, %g3, %g3
+       xor     %o4, %i0, %i0
+       xor     %o5, %i1, %i1
         ldd     [%i5+16], %o4
-       std     %g2, [%fp-8]
-       xor     %o4, %i0, %i2
-       xor     %o5, %i1, %i3
-       ldd     [%i5+24], %o4
-       std     %i2, [%i5+16]
+       xor     %i2, %g2, %g2
+       xor     %i3, %g3, %g3
+       std     %i0, [%fp-8]
         xor     %o4, %g2, %i2
         xor     %o5, %g3, %i3
+       ldd     [%i5+24], %o4
+       std     %i2, [%i5+16]
+       xor     %o4, %i0, %i2
+       xor     %o5, %i1, %i3
+       std     %i2, [%i5+24]
         call    memcpy, 0
-        std    %i2, [%i5+24]
+        std    %g2, [%fp-16]
         mov     %l5, %o0
         mov     %l5, %o1
         call    %l1, 0

I didn't find a corresponding fix in the 4.9.2 changelog. I think you 
can nevertheless close this issue here, because it is very likely a gcc 
bug introduced in the latest gcc branch and already fixed in the latest 
gcc release.

Sorry for the noise.

Regards,

Rainer



From rt at openssl.org  Mon Feb 23 22:20:31 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Mon, 23 Feb 2015 23:20:31 +0100
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
	error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <54DF6AB4.7090403@kippdata.de>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
Message-ID: <rt-4.0.4-31502-1424730031-1924.3714-6-0@openssl.org>

Thanks Rainer.

Closing this as a gcc bug.

Matt


From support at go-forward.net  Tue Feb 24 03:52:41 2015
From: support at go-forward.net (Peter Mosmans)
Date: Tue, 24 Feb 2015 13:52:41 +1000
Subject: [openssl-dev] [openssl.org #3715] Possible bug in openssl 64
 bit version
In-Reply-To: <rt-4.0.4-6511-1424704562-581.3715-21-0@openssl.org>
References: <RT-Ticket-3715@openssl.org>
 <DUB109-W48545F31D9E46CC6BBA083F0290@phx.gbl>
 <rt-4.0.4-6511-1424704562-581.3715-21-0@openssl.org>
Message-ID: <54EBF589.8050500@go-forward.net>


Hi,

Are you aware of the file system redirector on Windows for running 32
bit applications on a 64 bit OS ?
The issue could be that you're testing two completely different
binaries, one 32 bit and one 64 bit, hence the different result. Try to
test text-only files.
Please see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx
for more information.

Cheers,


Peter Mosmans

On 24-02-2015 01:16, Tobias Firnges via RT wrote:
> Hello,
>
> I would like you to verify the following issue:
>
> You can find the version information in the attached screenshot.
>
> - OS: Windows 8.1 64 bit
> - Hardware: Hyper-V on a Dell T110 II as well as a HP ProBook 470 G2
> - I used the version of openssl from http://slproweb.com/products/Win32OpenSSL.html
> - Compiler: Visual Studio 2013 and also tested with codeblocks.org software <-- Same result
> - Detailed description of the error here:
>
> I have tested the following code with Win32 OpenSSL v1.0.1L and Win64 OpenSSL:
> ----------------------------------
> #define _CRT_SECURE_NO_WARNINGS
>
> #include <iostream> 
> #include <sstream> 
> #include <string> 
> #include <iomanip> 
> #include <stdio.h> 
> #include <openssl/sha.h>
>
> using namespace std;
>
> string sha256(const string str)
> {
>     unsigned char hash[SHA256_DIGEST_LENGTH];
>     SHA256_CTX sha256;
>     SHA256_Init(&sha256);
>     SHA256_Update(&sha256, str.c_str(), str.size());
>
>     SHA256_Final(hash, &sha256);
>
>     stringstream ss;
>     for (int i = 0; i < SHA256_DIGEST_LENGTH; i++)
>     {
>         ss << hex << std::setw(2) << setfill('0') << (int)hash[i];
>     }
>
>     return ss.str();
> }
>
> void sha256_hash_string(unsigned char hash[SHA256_DIGEST_LENGTH], char outputBuffer[65])
> {
>     int i = 0;
>
>     for (i = 0; i < SHA256_DIGEST_LENGTH; i++)
>     {
>         sprintf(outputBuffer + (i * 2), "%02x", hash[i]);
>     }
>
>     outputBuffer[64] = 0;
> }
>
> int sha256_file(char* path, char output[65])
> {
>     FILE *file = fopen(path, "rb");
>     if (!file) return -1;
>
>     unsigned char hash[SHA256_DIGEST_LENGTH];
>     SHA256_CTX sha256;
>     SHA256_Init(&sha256);
>     const int bufSize = 32768;
>     char *buffer = new char[bufSize];
>     int bytesRead = 0;
>     if (!buffer) return -1;
>     while ((bytesRead = (int)fread(buffer, 1, bufSize, file)))
>     {
>         SHA256_Update(&sha256, buffer, bytesRead);
>     }
>     SHA256_Final(hash, &sha256);
>
>     sha256_hash_string(hash, output);
>     fclose(file);
>     delete[] buffer;
>     return 0;
> }
>
> int main()
> {
>
>     // hash a string 
>     std::cout << "SHA-256 hash of \"Sample String\" text:" << std::endl;
>     std::cout << sha256("Sample String") << std::endl << std::endl;
>
>     // hash a file 
>     cout << "SHA-256 hash of file cmd.exe:" << std::endl;
>     char calc_hash[65];
>     sha256_file("C:\\Windows\\System32\\cmd.exe", calc_hash);
>     cout << calc_hash << std::endl;
>     cout << "SHA-256 hash of file NETSTAT.exe:" << std::endl;
>     sha256_file("C:\\Windows\\System32\\NETSTAT.exe", calc_hash);
>     cout << calc_hash << std::endl;
>     cout << "SHA-256 hash of file eula.1028.txt:" << std::endl;
>     sha256_file("C:\\eula.1028.txt", calc_hash);
>     cout << calc_hash << std::endl;
>
>     cin.clear();
>     cin.ignore(255, '\n');
>     cin.get();
>
>     return 0;
> }
> ----------------------------------
> The code worked fine with Win32 OpenSSL v1.0.1L, however, when I tried the code with Win64 OpenSSL v1.0.1L, I get a wrong result.
>
> In my test I did the following:
>
> 1. On a 64 bit Windows 8.1 machine, I first tested Win32 OpenSSL v1.0.1L. The results were correct
> 2. I then changed to Win64 OpenSSL v1.0.1.L (inculuding the 64 bit Visual C++ redistributables). The result was correct for Strings and for the txt file, but for exe files the hash is not correct. (See attached screenshot)
> 3. I then compiled the same code on a 32 bit Windows 7 machine with Win32 OpenSSL v1.0.1L and copied the file to the 64 bit machine. Now the String, txt file and exe file hash show the right value.
>
> For compiling I used Visual Studio 2013 and do compare, if the compiler was the issue, I used the latest version of the codeblocks.org software to compile. I always got the same result. All hashs created with Win32 OpenSSL were correct, the hash of exe files created with Win64 OpenSSL was wrong.
>
>
> And my target is to get the correct hash of each file I check in the 32 bit, as well as in the 64 bit environment.
>
> Note: I double checked all the files I tested in online hash calculators. And there I could see, the value for the exe files created with Win64 OpenSSL v1.0.1L were wrong.
>
> Can you please confirm my result. Maybe you find an error in my code. If the error is in Win64 OpenSSL v1.0.1L, please help to release a new version of the tool with the issue fixed.
>
> Note: I first sent the issue to Shining Light Production where I got the following answer:
> -------------------------
> Even if there is a problem, there's nothing I can do.  I just build the 
> upstream source code into binaries using the officially published 
> directions for building OpenSSL.
>  
> You need to take this upstream to the openssl-users mailing list. 
> However, you are the first person to have this issue (or I'd see a LOT 
> more yelling about it), so I'd wager that there is something wrong with 
> your code rather than with OpenSSL.  Still, there are people there who 
> can look at your code and evaluate it for accuracy and correctness.
> -------------------------
>
>
> Thank you for your answer in advance.
>
>
> Best regards
> Tobias 		 	   		  
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150224/5aa05b04/attachment.html>

From rt at openssl.org  Tue Feb 24 03:53:35 2015
From: rt at openssl.org (Support via RT)
Date: Tue, 24 Feb 2015 04:53:35 +0100
Subject: [openssl-dev] [openssl.org #3715] Possible bug in openssl 64
	bit version
In-Reply-To: <54EBF589.8050500@go-forward.net>
References: <RT-Ticket-3715@openssl.org>
 <DUB109-W48545F31D9E46CC6BBA083F0290@phx.gbl>
 <rt-4.0.4-6511-1424704562-581.3715-21-0@openssl.org>
 <54EBF589.8050500@go-forward.net>
Message-ID: <rt-4.0.4-26171-1424750015-358.3715-6-0@openssl.org>


Hi,

Are you aware of the file system redirector on Windows for running 32
bit applications on a 64 bit OS ?
The issue could be that you're testing two completely different
binaries, one 32 bit and one 64 bit, hence the different result. Try to
test text-only files.
Please see
https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx
for more information.

Cheers,


Peter Mosmans

On 24-02-2015 01:16, Tobias Firnges via RT wrote:
> Hello,
>
> I would like you to verify the following issue:
>
> You can find the version information in the attached screenshot.
>
> - OS: Windows 8.1 64 bit
> - Hardware: Hyper-V on a Dell T110 II as well as a HP ProBook 470 G2
> - I used the version of openssl from http://slproweb.com/products/Win32OpenSSL.html
> - Compiler: Visual Studio 2013 and also tested with codeblocks.org software <-- Same result
> - Detailed description of the error here:
>
> I have tested the following code with Win32 OpenSSL v1.0.1L and Win64 OpenSSL:
> ----------------------------------
> #define _CRT_SECURE_NO_WARNINGS
>
> #include <iostream> 
> #include <sstream> 
> #include <string> 
> #include <iomanip> 
> #include <stdio.h> 
> #include <openssl/sha.h>
>
> using namespace std;
>
> string sha256(const string str)
> {
>     unsigned char hash[SHA256_DIGEST_LENGTH];
>     SHA256_CTX sha256;
>     SHA256_Init(&sha256);
>     SHA256_Update(&sha256, str.c_str(), str.size());
>
>     SHA256_Final(hash, &sha256);
>
>     stringstream ss;
>     for (int i = 0; i < SHA256_DIGEST_LENGTH; i++)
>     {
>         ss << hex << std::setw(2) << setfill('0') << (int)hash[i];
>     }
>
>     return ss.str();
> }
>
> void sha256_hash_string(unsigned char hash[SHA256_DIGEST_LENGTH], char outputBuffer[65])
> {
>     int i = 0;
>
>     for (i = 0; i < SHA256_DIGEST_LENGTH; i++)
>     {
>         sprintf(outputBuffer + (i * 2), "%02x", hash[i]);
>     }
>
>     outputBuffer[64] = 0;
> }
>
> int sha256_file(char* path, char output[65])
> {
>     FILE *file = fopen(path, "rb");
>     if (!file) return -1;
>
>     unsigned char hash[SHA256_DIGEST_LENGTH];
>     SHA256_CTX sha256;
>     SHA256_Init(&sha256);
>     const int bufSize = 32768;
>     char *buffer = new char[bufSize];
>     int bytesRead = 0;
>     if (!buffer) return -1;
>     while ((bytesRead = (int)fread(buffer, 1, bufSize, file)))
>     {
>         SHA256_Update(&sha256, buffer, bytesRead);
>     }
>     SHA256_Final(hash, &sha256);
>
>     sha256_hash_string(hash, output);
>     fclose(file);
>     delete[] buffer;
>     return 0;
> }
>
> int main()
> {
>
>     // hash a string 
>     std::cout << "SHA-256 hash of \"Sample String\" text:" << std::endl;
>     std::cout << sha256("Sample String") << std::endl << std::endl;
>
>     // hash a file 
>     cout << "SHA-256 hash of file cmd.exe:" << std::endl;
>     char calc_hash[65];
>     sha256_file("C:\\Windows\\System32\\cmd.exe", calc_hash);
>     cout << calc_hash << std::endl;
>     cout << "SHA-256 hash of file NETSTAT.exe:" << std::endl;
>     sha256_file("C:\\Windows\\System32\\NETSTAT.exe", calc_hash);
>     cout << calc_hash << std::endl;
>     cout << "SHA-256 hash of file eula.1028.txt:" << std::endl;
>     sha256_file("C:\\eula.1028.txt", calc_hash);
>     cout << calc_hash << std::endl;
>
>     cin.clear();
>     cin.ignore(255, '\n');
>     cin.get();
>
>     return 0;
> }
> ----------------------------------
> The code worked fine with Win32 OpenSSL v1.0.1L, however, when I tried the code with Win64 OpenSSL v1.0.1L, I get a wrong result.
>
> In my test I did the following:
>
> 1. On a 64 bit Windows 8.1 machine, I first tested Win32 OpenSSL v1.0.1L. The results were correct
> 2. I then changed to Win64 OpenSSL v1.0.1.L (inculuding the 64 bit Visual C++ redistributables). The result was correct for Strings and for the txt file, but for exe files the hash is not correct. (See attached screenshot)
> 3. I then compiled the same code on a 32 bit Windows 7 machine with Win32 OpenSSL v1.0.1L and copied the file to the 64 bit machine. Now the String, txt file and exe file hash show the right value.
>
> For compiling I used Visual Studio 2013 and do compare, if the compiler was the issue, I used the latest version of the codeblocks.org software to compile. I always got the same result. All hashs created with Win32 OpenSSL were correct, the hash of exe files created with Win64 OpenSSL was wrong.
>
>
> And my target is to get the correct hash of each file I check in the 32 bit, as well as in the 64 bit environment.
>
> Note: I double checked all the files I tested in online hash calculators. And there I could see, the value for the exe files created with Win64 OpenSSL v1.0.1L were wrong.
>
> Can you please confirm my result. Maybe you find an error in my code. If the error is in Win64 OpenSSL v1.0.1L, please help to release a new version of the tool with the issue fixed.
>
> Note: I first sent the issue to Shining Light Production where I got the following answer:
> -------------------------
> Even if there is a problem, there's nothing I can do.  I just build the 
> upstream source code into binaries using the officially published 
> directions for building OpenSSL.
>  
> You need to take this upstream to the openssl-users mailing list. 
> However, you are the first person to have this issue (or I'd see a LOT 
> more yelling about it), so I'd wager that there is something wrong with 
> your code rather than with OpenSSL.  Still, there are people there who 
> can look at your code and evaluate it for accuracy and correctness.
> -------------------------
>
>
> Thank you for your answer in advance.
>
>
> Best regards
> Tobias 		 	   		  
>
>
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



From rt at openssl.org  Tue Feb 24 09:42:38 2015
From: rt at openssl.org (Richard Levitte via RT)
Date: Tue, 24 Feb 2015 10:42:38 +0100
Subject: [openssl-dev] [openssl.org #3526] [Patch] Removed the dependency on
	the obsolete TERMIO.h for linux 32 and 64bits.
In-Reply-To: <5410bdd4.yDDjsXWFJYblVNZd%nik_89@xroutine.net>
References: <RT-Ticket-3526@openssl.org>
 <5410bdd4.yDDjsXWFJYblVNZd%nik_89@xroutine.net>
Message-ID: <rt-4.0.4-23979-1424770958-893.3526-6-0@openssl.org>

I took this a bit further and made TERMIOS the default if nothing else is said.
It means that I've removed -DTERMIOS on all platforms except the Unix-like
environments on Windows (such as Cygwin), and removed -DTERMIO on all Linux
platforms (TERMIOS is POSIX and has been for a long time, the rationale is that
Linux on all hardwares must have caught up by now).

This has been updated in the master branch as well as the 1.0.2 and 1.0.1
branches.

On Thu Sep 11 11:59:24 2014, nik_89 at xroutine.net wrote:
>
> Operating System : Linux 32 and 64bits.
> Version of OpenSSL : 1.0.1i
>
>
> TERMIO is an obsolete header file that is not even in vanilla glibc
> anymore. The TERMIOS header file is fully backward compatible with the
> TERMIO struct so it is safe to use that instead. This prevents systems
> that dropped altogether the termio.h "glue" header from having nasty
> errors when compiling.
> ---
> Configure | 24 ++++++++++++------------
> crypto/ui/ui_openssl.c | 2 --
> 2 files changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/Configure b/Configure
> index 36844b7..7b2d5d7 100755
> --- a/Configure
> +++ b/Configure
> @@ -345,23 +345,23 @@ my %table=(
> ####
> # *-generic* is endian-neutral target, but ./config is free to
> # throw in -D[BL]_ENDIAN, whichever appropriate...
> -"linux-generic32","gcc:-DTERMIO -O3 -fomit-frame-pointer
> -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
> DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-generic32","gcc:-DTERMIOS -O3 -fomit-frame-pointer
> -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT
> DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> "linux-ppc", "gcc:-DB_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_RISC1
> DES_UNROLL:${ppc32_asm}:linux32:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> # It's believed that majority of ARM toolchains predefine appropriate
> -march.
> # If you compiler does not, do complement config command line with
> one!
> -"linux-armv4", "gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG
> RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
> BF_PTR:${armv4_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-armv4", "gcc:-DTERMIOS -O3 -Wall::-D_REENTRANT::-ldl:BN_LLONG
> RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL
> BF_PTR:${armv4_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> #### IA-32 targets...
> -"linux-ia32-icc", "icc:-DL_ENDIAN -DTERMIO -O2
> -no_cpprt::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-
> KPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-elf", "gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer
> -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-aout", "gcc:-DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer
> -march=i486 -Wall::(unknown):::BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_asm}:a.out",
> +"linux-ia32-icc", "icc:-DL_ENDIAN -DTERMIOS -O2
> -no_cpprt::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-
> KPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-elf", "gcc:-DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer
> -Wall::-D_REENTRANT::-ldl:BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-aout", "gcc:-DL_ENDIAN -DTERMIOS -O3 -fomit-frame-pointer
> -march=i486 -Wall::(unknown):::BN_LLONG ${x86_gcc_des}
> ${x86_gcc_opts}:${x86_asm}:a.out",
> ####
> -"linux-generic64","gcc:-DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-ppc64", "gcc:-m64 -DB_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_RISC1 DES_UNROLL:${ppc64_asm}:linux64:dlfcn:linux-shared:-
> fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> -"linux-ia64", "gcc:-DL_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL
> DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-ia64-ecc","ecc:-DL_ENDIAN -DTERMIO -O2 -Wall
> -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
> DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-ia64-icc","icc:-DL_ENDIAN -DTERMIO -O2 -Wall
> -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
> DES_RISC1 DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> -"linux-x86_64", "gcc:-m64 -DL_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
> DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-
> m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> -"linux64-s390x", "gcc:-m64 -DB_ENDIAN -DTERMIO -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_INT DES_UNROLL:${s390x_asm}:64:dlfcn:linux-shared:-fPIC:-
> m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> +"linux-generic64","gcc:-DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-ppc64", "gcc:-m64 -DB_ENDIAN -DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_RISC1 DES_UNROLL:${ppc64_asm}:linux64:dlfcn:linux-shared:-
> fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> +"linux-ia64", "gcc:-DL_ENDIAN -DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_UNROLL
> DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-ia64-ecc","ecc:-DL_ENDIAN -DTERMIOS -O2 -Wall
> -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
> DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-ia64-icc","icc:-DL_ENDIAN -DTERMIOS -O2 -Wall
> -no_cpprt::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK
> DES_RISC1 DES_INT:${ia64_asm}:dlfcn:linux-shared:-
> fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)",
> +"linux-x86_64", "gcc:-m64 -DL_ENDIAN -DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT
> DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-
> m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> +"linux64-s390x", "gcc:-m64 -DB_ENDIAN -DTERMIOS -O3
> -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK
> DES_INT DES_UNROLL:${s390x_asm}:64:dlfcn:linux-shared:-fPIC:-
> m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64",
> #### So called "highgprs" target for z/Architecture CPUs
> # "Highgprs" is kernel feature first implemented in Linux 2.6.32, see
> # /proc/cpuinfo. The idea is to preserve most significant bits of
> diff --git a/crypto/ui/ui_openssl.c b/crypto/ui/ui_openssl.c
> index a38c758..91e1ae0 100644
> --- a/crypto/ui/ui_openssl.c
> +++ b/crypto/ui/ui_openssl.c
> @@ -191,8 +191,6 @@
> #endif
>
> #if defined(linux) && !defined(TERMIO)
> -# undef TERMIOS
> -# define TERMIO
> # undef SGTTY
> #endif
>


--
Richard Levitte
levitte at openssl.org


From dwmw2 at infradead.org  Tue Feb 24 11:19:43 2015
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 24 Feb 2015 11:19:43 +0000
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
 error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <rt-4.0.4-31502-1424730031-1924.3714-6-0@openssl.org>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
 <rt-4.0.4-31502-1424730031-1924.3714-6-0@openssl.org>
Message-ID: <1424776783.5437.235.camel@infradead.org>

On Mon, 2015-02-23 at 23:20 +0100, Matt Caswell via RT wrote:
> Thanks Rainer.
> 
> Closing this as a gcc bug.

Such a statement should always be associated with a *link* to the
relevant bug, in this case in gcc.gnu.org/bugzilla.

Given that the 4.9.2 changelog doesn't mention it, and I can't see
anything obviously relevant in
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&list_id=110629&resolution=FIXED&target_milestone=4.9.2 it's possible that this is *accidentally* fixed rather than deliberately so, and that there isn't a test case in place for it. And thus that it might recur.

It's worth filing a new GCC bug even if there's a possibility that it
might turn out to be a duplicate.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150224/bd14ab84/attachment.bin>

From rt at openssl.org  Tue Feb 24 11:20:21 2015
From: rt at openssl.org (David Woodhouse via RT)
Date: Tue, 24 Feb 2015 12:20:21 +0100
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
	error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <1424776783.5437.235.camel@infradead.org>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
 <rt-4.0.4-31502-1424730031-1924.3714-6-0@openssl.org>
 <1424776783.5437.235.camel@infradead.org>
Message-ID: <rt-4.0.4-8116-1424776820-858.3714-6-0@openssl.org>

On Mon, 2015-02-23 at 23:20 +0100, Matt Caswell via RT wrote:
> Thanks Rainer.
> 
> Closing this as a gcc bug.

Such a statement should always be associated with a *link* to the
relevant bug, in this case in gcc.gnu.org/bugzilla.

Given that the 4.9.2 changelog doesn't mention it, and I can't see
anything obviously relevant in
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&list_id=110629&resolution=FIXED&target_milestone=4.9.2 it's possible that this is *accidentally* fixed rather than deliberately so, and that there isn't a test case in place for it. And thus that it might recur.

It's worth filing a new GCC bug even if there's a possibility that it
might turn out to be a duplicate.

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse at intel.com                              Intel Corporation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5745 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150224/1220ac35/attachment-0001.bin>

From rt at openssl.org  Tue Feb 24 11:32:07 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Tue, 24 Feb 2015 12:32:07 +0100
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
	error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <rt-4.0.4-8116-1424776820-1184.3714-6-0@openssl.org>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
 <rt-4.0.4-31502-1424730031-1924.3714-6-0@openssl.org>
 <1424776783.5437.235.camel@infradead.org>
 <rt-4.0.4-8116-1424776820-1184.3714-6-0@openssl.org>
Message-ID: <rt-4.0.4-5987-1424777527-1574.3714-6-0@openssl.org>

On Tue Feb 24 12:20:20 2015, dwmw2 at infradead.org wrote:
> On Mon, 2015-02-23 at 23:20 +0100, Matt Caswell via RT wrote:
> > Thanks Rainer.
> >
> > Closing this as a gcc bug.
>
> Such a statement should always be associated with a *link* to the
> relevant bug, in this case in gcc.gnu.org/bugzilla.

I have no access to the Solaris environment or gcc versions concerned to verify
that this is a gcc bug. Since Rainer raised this defect and has requested that
we close it as he is of the view that it is a gcc bug then that is sufficient
for me to close this ticket. If Rainer wishes to file the bug then I am more
than happy to have the reference associated with this ticket - but I will leave
that to Rainer to decide.

Matt


From foleyj at cisco.com  Tue Feb 24 12:54:31 2015
From: foleyj at cisco.com (John Foley)
Date: Tue, 24 Feb 2015 07:54:31 -0500
Subject: [openssl-dev] Unused value in s3_srvr.c
Message-ID: <54EC7487.9020709@cisco.com>

In the 1.0.2 stable branch, the following code in s3_srvr.c sets the
return value twice (line# 380).  Should the return value be
SSL_TLSEXT_ERR_ALERT_FATAL, or -1?


if (ret != SSL_ERROR_NONE) {
    ssl3_send_alert(s, SSL3_AL_FATAL, al);
    /*
     * This is not really an error but the only means to for
     * a client to detect whether srp is supported.
    */
    if (al != TLS1_AD_UNKNOWN_PSK_IDENTITY)
        SSLerr(SSL_F_SSL3_ACCEPT, SSL_R_CLIENTHELLO_TLSEXT);
    ret = SSL_TLSEXT_ERR_ALERT_FATAL;
    ret = -1;
    goto end;
}

From rsalz at akamai.com  Tue Feb 24 15:04:05 2015
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 24 Feb 2015 15:04:05 +0000
Subject: [openssl-dev] [openssl.org #3526] [Patch] Removed the
 dependency on	the obsolete TERMIO.h for linux 32 and 64bits.
In-Reply-To: <rt-4.0.4-23979-1424770958-893.3526-6-0@openssl.org>
References: <RT-Ticket-3526@openssl.org>
 <5410bdd4.yDDjsXWFJYblVNZd%nik_89@xroutine.net>
 <rt-4.0.4-23979-1424770958-893.3526-6-0@openssl.org>
Message-ID: <cd956d8f090b4e84ae5740105e5433b4@ustx2ex-dag1mb2.msg.corp.akamai.com>

> I took this a bit further and made TERMIOS the default if nothing else is said.

YEA!

From rt at openssl.org  Tue Feb 24 15:06:52 2015
From: rt at openssl.org (Salz, Rich via RT)
Date: Tue, 24 Feb 2015 16:06:52 +0100
Subject: [openssl-dev] [openssl.org #3526] [Patch] Removed the
	dependency on the obsolete TERMIO.h for linux 32 and 64bits.
In-Reply-To: <cd956d8f090b4e84ae5740105e5433b4@ustx2ex-dag1mb2.msg.corp.akamai.com>
References: <RT-Ticket-3526@openssl.org>
 <5410bdd4.yDDjsXWFJYblVNZd%nik_89@xroutine.net>
 <rt-4.0.4-23979-1424770958-893.3526-6-0@openssl.org>
 <cd956d8f090b4e84ae5740105e5433b4@ustx2ex-dag1mb2.msg.corp.akamai.com>
Message-ID: <rt-4.0.4-13825-1424790412-1227.3526-6-0@openssl.org>

> I took this a bit further and made TERMIOS the default if nothing else is said.

YEA!



From rt at openssl.org  Tue Feb 24 16:21:17 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Tue, 24 Feb 2015 17:21:17 +0100
Subject: [openssl-dev] [openssl.org #3716] Patch for setting preferred
	cipher list
In-Reply-To: <5CB97CA4-EABF-4C31-884D-82C30B93E396@akamai.com>
References: <RT-Ticket-3716@openssl.org>
 <5CB97CA4-EABF-4C31-884D-82C30B93E396@akamai.com>
Message-ID: <rt-4.0.4-4340-1424794877-1524.3716-21-0@openssl.org>

Hello OpenSSL Org:

This is a change that Akamai has made to it?s implementation of OpenSSL.

Description: Adds connivence methods to set preferred cipher list

This adds two wrappers:
* SSL_CTX_set_ciphers_ex() sets the cipher list and sets the SSL_OP_CIPHER flags.
* SSL_CTX_set_preferred_ciphers() sets the cipher list via SSL_CTX_set_ciphers_ex() and turns on SSL_OP_CIPHER_SERVER_PREFERENCE

GitHub Link:
https://github.com/akamai/openssl/commit/86a216938e4c9381973f537352e01ba392e5688e
And attachment.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Adds-convenience-method-to-set-preferred-cipher-list.patch
Type: application/octet-stream
Size: 4647 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150224/464409f4/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150224/464409f4/attachment.htm>

From rt at openssl.org  Tue Feb 24 16:21:20 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Tue, 24 Feb 2015 17:21:20 +0100
Subject: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in
	s_client/s_server
In-Reply-To: <B4C413E9-67BB-429D-B77B-526D8E3A2901@akamai.com>
References: <RT-Ticket-3717@openssl.org>
 <B4C413E9-67BB-429D-B77B-526D8E3A2901@akamai.com>
Message-ID: <rt-4.0.4-4340-1424794880-1767.3717-21-0@openssl.org>

Hello OpenSSL Org:

This is a change that Akamai has made to it?s implementation of OpenSSL.

Version: master branch
Description: Adds IPv6 support in s_client/s_server

This adds two options, -4 and -6, to specify the address family to connect with. In addition, the address field on the command line is parsed via getaddrinfo().

GitHub Link:
https://github.com/akamai/openssl/commit/6878f747167f2cba82316d5f664c2bac88554cb3

And attachment.

Thank you:
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Provides-IPv6-support-in-s_client-s_server-Patch-ipv.patch
Type: application/octet-stream
Size: 18126 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150224/47133d9d/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150224/47133d9d/attachment-0001.htm>

From rt at openssl.org  Tue Feb 24 16:21:34 2015
From: rt at openssl.org (Rainer Jung via RT)
Date: Tue, 24 Feb 2015 17:21:34 +0100
Subject: [openssl-dev] [openssl.org #3718] Broken NAME header in
	doc/crypto/d2i_ECPKParameters.pod (master and 1.0.2)
In-Reply-To: <54EBA3BE.4050702@kippdata.de>
References: <RT-Ticket-3718@openssl.org> <54EBA3BE.4050702@kippdata.de>
Message-ID: <rt-4.0.4-4340-1424794894-1206.3718-21-0@openssl.org>

File doc/crypto/d2i_ECPKParameters.pod starts with

=pod

=head1 NAME

d2i_ECPKParameters, i2d_ECPKParameters, d2i_ECPKParameters_bio, 
i2d_ECPKParameters_bio, d2i_ECPKParameters_fp, 
i2d_ECPKParameters_fp(fp,x), ECPKParameters_print, 
ECPKParameters_print_fp - Functions for decoding and encoding ASN1 
representations of elliptic curve entities

=head1 SYNOPSIS


The argument syntax (fp,x) breaks util/extract-names.pl which is used in 
the Makefile to determine which symlinks to create in the man pages 
directory:

% perl util/extract-names.pl < doc/crypto/d2i_ECPKParameters.pod
d2i_ECPKParameters
i2d_ECPKParameters
d2i_ECPKParameters_bio
i2d_ECPKParameters_bio
d2i_ECPKParameters_fp
i2d_ECPKParameters_fp(fp
x)
ECPKParameters_print
ECPKParameters_print_fp

After installation there are broken symlinks:

lrwxrwxrwx   ... i2d_ECPKParameters_fp(fp.3 -> d2i_ECPKParameters.3
lrwxrwxrwx   ... x).3 -> d2i_ECPKParameters.3

The script util/extract-names.pl is unchanged since 11 years (master and 
1.0.2 branch), the pod file doc/crypto/d2i_ECPKParameters.pod is new in 
1.0.2 and contains the broken syntax in 1.0.2 and master.

Solution: drop "(fp,x)" in the NAME header:

--- doc/crypto/d2i_ECPKParameters.pod      2014-08-07 06:28:31.000000000 
+0200
+++ doc/crypto/d2i_ECPKParameters.pod   2015-02-23 23:02:57.481128000 +0100
@@ -2,7 +2,7 @@

  =head1 NAME

-d2i_ECPKParameters, i2d_ECPKParameters, d2i_ECPKParameters_bio, 
i2d_ECPKParameters_bio, d2i_ECPKParameters_fp, 
i2d_ECPKParameters_fp(fp,x), ECPKParameters_print, 
ECPKParameters_print_fp - Functions for decoding and encoding ASN1 
representations of elliptic curve entities
+d2i_ECPKParameters, i2d_ECPKParameters, d2i_ECPKParameters_bio, 
i2d_ECPKParameters_bio, d2i_ECPKParameters_fp, i2d_ECPKParameters_fp, 
ECPKParameters_print, ECPKParameters_print_fp - Functions for decoding 
and encoding ASN1 representations of elliptic curve entities

  =head1 SYNOPSIS


Thanks!

Rainer



From rt at openssl.org  Tue Feb 24 16:22:19 2015
From: rt at openssl.org (=?UTF-8?B?U3RlcGhhbiBNw7xobHN0cmFzc2Vy?= via RT)
Date: Tue, 24 Feb 2015 17:22:19 +0100
Subject: [openssl-dev] [openssl.org #3719] Bug report: Documentation for
	-no_explicit option of "openssl ocsp" missing
In-Reply-To: <54EC9BD5.8010302@pdflib.com>
References: <RT-Ticket-3719@openssl.org> <54EC9BD5.8010302@pdflib.com>
Message-ID: <rt-4.0.4-5282-1424794939-883.3719-21-0@openssl.org>

There's no documentation available for the -no_explicit option of 
"openssl ocsp":

https://www.openssl.org/docs/apps/ocsp.html

Dr. Henson explained the meaning of the option and of the corresponding 
flag OCSP_NOEXPLICIT for OCSP_basic_verify() like this on the 
openssl-users list:

> If the responder root CA is set to be trusted for OCSP signing then it can be
> used to sign OCSP responses for any certificate (aka a global responder). This
> comes under:
>
>    1. Matches a local configuration of OCSP signing authority for the
>    certificate in question
>
> or alternatively:
>
>    Additional acceptance or rejection criteria may apply to either the
>    response itself or to the certificate used to validate the signature
>    on the response.
>
> from RFC2560 et al.
>
> If the -no_explicit flag is set or OCSP_NOEXPLICIT is set then this behaviour
> is disabled.


--
Stephan



From rt at openssl.org  Tue Feb 24 19:36:39 2015
From: rt at openssl.org (Devchandra L Meetei via RT)
Date: Tue, 24 Feb 2015 20:36:39 +0100
Subject: [openssl-dev] [openssl.org #3678] Correct the BIO_new_bio_pair
	example in man page
In-Reply-To: <CAKmFMKcinNG6ZSzQpK4mj3yMgoHvHHJed2EHcrLZAwHd=ykA_A@mail.gmail.com>
References: <RT-Ticket-3678@openssl.org>
 <CAKmFMKcinNG6ZSzQpK4mj3yMgoHvHHJed2EHcrLZAwHd=ykA_A@mail.gmail.com>
Message-ID: <rt-4.0.4-27698-1424806599-1247.3678-6-0@openssl.org>

Is anybody interested to have a look at 3678. It has a patch attached also.


--


From appro at openssl.org  Tue Feb 24 21:14:04 2015
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 24 Feb 2015 22:14:04 +0100
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
 error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <rt-4.0.4-6511-1424704413-608.3714-21-0@openssl.org>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
 <rt-4.0.4-6511-1424704413-608.3714-21-0@openssl.org>
Message-ID: <54ECE99C.50203@openssl.org>

Basically I just want to say "good analysis" and confirm that yes,
everything points at compiler bug. I also don't sent this to rt, but to
openssl-dev, in order to prevent case reopen.

> Looking at disassembly around CRYPTO_ccm128_decrypt+532 (decimal 532 = 
> 0x214):
> 
>      CRYPTO_ccm128_decrypt+0x214: f4 1f 00 00  ldd       [%i4], %i2
>      CRYPTO_ccm128_decrypt+0x218: b8 07 20 10  add       %i4, 0x10, %i4

I want to point out instruction that follows the ldd. If %i4 was temp,
then why would compiler have to increment it? Actually, if it was temp,
which can only be stack-based, then compiler would address it through
%fp, just like it addresses scratch in next instruction below. Also note
that %i4 value is the same as inp in your stack backtrace presented in
original message. Bottom line here is that compiler optimized away
memcpy by assuming that input is aligned, despite the fact that it's
declared char. That's compiler bug.

>      CRYPTO_ccm128_decrypt+0x21c: c4 1f bf f0  ldd       [%fp - 0x10], %g2
>      CRYPTO_ccm128_decrypt+0x220: d8 1f 3f f8  ldd       [%i4 - 0x8], %o4
>      CRYPTO_ccm128_decrypt+0x224: b0 1e 80 02  xor       %i2, %g2, %i0
>      CRYPTO_ccm128_decrypt+0x228: b2 1e c0 03  xor       %i3, %g3, %i1

If you still have 4.9.1 lying around, I wonder if it would help to
declare temp as volatile? It's really just a wonder, so don't feel
obligated to answer if you don't have time or energy.


From rt at openssl.org  Tue Feb 24 21:28:18 2015
From: rt at openssl.org (nagle@sitetruth.com via RT)
Date: Tue, 24 Feb 2015 22:28:18 +0100
Subject: [openssl-dev] [openssl.org #2634] Cross-signed certs rejected by
	OpenSSL because root cert not base of chain
In-Reply-To: <54ECE9D7.30704@sitetruth.com>
References: <RT-Ticket-2634@openssl.org> <54ECE9D7.30704@sitetruth.com>
Message-ID: <rt-4.0.4-9468-1424813297-1743.2634-6-0@openssl.org>

This is an old bug from 2011, generated originally by someone who put a
self-signed cert in their cert chain.  Until now, it's been ignored.
It's become a big problem now that Verisign cross-signed one of their
major root certs (VeriSign Class 3 Public Primary Certification
Authority - G5). Their root cert is thus no longer the base of a
chain, and is rejected by OpenSSL. This bug now comes up if you use
Mozilla's root cert store with Python. It's affecting some major
web sites and systems which use OpenSSL are struggling to deal
with this defect.

I reported the bug for Python:
http://bugs.python.org/issue23476
and the Python developers blame this OpenSSL bug. There's code
there to reproduce the bug.

Ubuntu has a workaround:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1014640
which involves modifying the cert file.  (The order of the
certificates in the cert file may be significant.  Not sure
about this.)

The developers of the "request" add-on for Python's HTTP client
have a different workaround, also involving using a different
certificate bundle.
https://github.com/kennethreitz/requests/issues/2455

See also this proposed patch from 2012:
http://rt.openssl.org/Ticket/Display.html?id=2732
"2634: Fail to verify server with a trusted CA root in the middle of the
chain".

The problem can be reproduced with the OpenSSL command line client,
but only on some platforms. See the comments in the Python bug report:

"I have determined that s_client is buggy. It will always load the
system certs *if and only if* you also pass it a valid custom CA cert
(which is the reverse of what's expected)."

"Antione closed this, as a not python error, as
if you do not pass a valid certificate to openssl s_client
it will not read the system certificates, which is clearly
utterly surprising and nuts."

So three different development teams now agree it's an OpenSSL bug.

 John Nagle




From rt at openssl.org  Tue Feb 24 21:36:17 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Tue, 24 Feb 2015 22:36:17 +0100
Subject: [openssl-dev] [openssl.org #3715] Possible bug in openssl 64
	bit version
In-Reply-To: <54ECEDFE.9070706@openssl.org>
References: <RT-Ticket-3715@openssl.org>
 <DUB109-W48545F31D9E46CC6BBA083F0290@phx.gbl>
 <rt-4.0.4-6511-1424704562-581.3715-21-0@openssl.org>
 <54EBF589.8050500@go-forward.net>
 <rt-4.0.4-26171-1424750015-358.3715-6-0@openssl.org>
 <54ECEDFE.9070706@openssl.org>
Message-ID: <rt-4.0.4-9468-1424813777-1645.3715-6-0@openssl.org>

Hi,

> Are you aware of the file system redirector on Windows for running 32
> bit applications on a 64 bit OS ?
> The issue could be that you're testing two completely different
> binaries, one 32 bit and one 64 bit, hence the different result.

I would actually put as "the issue *is*", as opposite to "could be" that is.

> Try to test text-only files.

Well, this can be a little bit misleading advice. Because problem
obviously is not with content of the files, but their location. Indeed,
if you copy a file from system32 to some other location that is not
redirected, say %TEMP%, then you will observe consistent results if you
try to hash it with either binary.

> Please see
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx
> for more information.

Correct.



From rainer.jung at kippdata.de  Tue Feb 24 21:54:00 2015
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Tue, 24 Feb 2015 22:54:00 +0100
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
 error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <54ECE99C.50203@openssl.org>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
 <rt-4.0.4-6511-1424704413-608.3714-21-0@openssl.org>
 <54ECE99C.50203@openssl.org>
Message-ID: <54ECF2F8.9090605@kippdata.de>

Am 24.02.2015 um 22:14 schrieb Andy Polyakov:
> Basically I just want to say "good analysis" and confirm that yes,
> everything points at compiler bug. I also don't sent this to rt, but to
> openssl-dev, in order to prevent case reopen.
>
>> Looking at disassembly around CRYPTO_ccm128_decrypt+532 (decimal 532 =
>> 0x214):
>>
>>       CRYPTO_ccm128_decrypt+0x214: f4 1f 00 00  ldd       [%i4], %i2
>>       CRYPTO_ccm128_decrypt+0x218: b8 07 20 10  add       %i4, 0x10, %i4
>
> I want to point out instruction that follows the ldd. If %i4 was temp,
> then why would compiler have to increment it? Actually, if it was temp,
> which can only be stack-based, then compiler would address it through
> %fp, just like it addresses scratch in next instruction below. Also note
> that %i4 value is the same as inp in your stack backtrace presented in
> original message. Bottom line here is that compiler optimized away
> memcpy by assuming that input is aligned, despite the fact that it's
> declared char. That's compiler bug.
>
>>       CRYPTO_ccm128_decrypt+0x21c: c4 1f bf f0  ldd       [%fp - 0x10], %g2
>>       CRYPTO_ccm128_decrypt+0x220: d8 1f 3f f8  ldd       [%i4 - 0x8], %o4
>>       CRYPTO_ccm128_decrypt+0x224: b0 1e 80 02  xor       %i2, %g2, %i0
>>       CRYPTO_ccm128_decrypt+0x228: b2 1e c0 03  xor       %i3, %g3, %i1
>
> If you still have 4.9.1 lying around, I wonder if it would help to
> declare temp as volatile? It's really just a wonder, so don't feel
> obligated to answer if you don't have time or energy.

Thanks for looking into it. I have everything in place for experiments.

Adding volatile first results in new compiler warnings:

ccm128.c: In function 'CRYPTO_ccm128_decrypt':
ccm128.c:300:9: warning: passing argument 1 of 'memcpy' discards 
'volatile' qualifier from pointer target type
          memcpy(temp.c, inp, 16);
          ^
In file included from /usr/include/string.h:18:0,
                  from ccm128.c:53:
/usr/include/iso/string_iso.h:60:14: note: expected 'void *' but 
argument is of type 'volatile u8 *'
  extern void *memcpy(void *_RESTRICT_KYWD, const void *_RESTRICT_KYWD, 
size_t);
               ^


And then it also changes the resulting code:

-       ldd     [%i4], %i2
+       call    memcpy, 0
^^^ that's probably the memcpy() that was optimized away before
+        nop
+       ldd     [%fp-16], %i2
+       ldd     [%fp-32], %g2
+       add     %l6, %i4, %o0
+       mov     %l0, %o1
+       ldd     [%fp-8], %i0
+       mov     16, %o2
         add     %i4, 16, %i4
-       ldd     [%fp-16], %g2
-       ldd     [%i4-8], %o4
-       xor     %i2, %g2, %i0
-       xor     %i3, %g3, %i1
-       ldd     [%fp-8], %g2
-       std     %i0, [%fp-16]
-       xor     %o4, %g2, %g2
-       xor     %o5, %g3, %g3
         ldd     [%i5+16], %o4
-       std     %g2, [%fp-8]
-       xor     %o4, %i0, %i2
-       xor     %o5, %i1, %i3
+       xor     %i2, %g2, %i2
+       xor     %i3, %g3, %i3
+       ldd     [%fp-24], %g2
+       std     %i2, [%fp-32]
+       xor     %i0, %g2, %g2
+       xor     %i1, %g3, %g3
+       std     %g2, [%fp-24]
+       xor     %o4, %i2, %i0
+       xor     %o5, %i3, %i1
         ldd     [%i5+24], %o4
-       std     %i2, [%i5+16]
-       xor     %o4, %g2, %i2
-       xor     %o5, %g3, %i3
+       std     %i0, [%i5+16]
+       xor     %o4, %g2, %i0
+       xor     %o5, %g3, %i1
         call    memcpy, 0
-        std    %i2, [%i5+24]
-       mov     %l5, %o0
-       mov     %l5, %o1
+        std    %i0, [%i5+24]
+       mov     %l3, %o0
+       mov     %l3, %o1
         call    %l1, 0
          mov    %l2, %o2

And yes, with volatile the test no longer crashes even when compiled 
with the broken gcc 4.9.1 and -O3.

Regards,

Rainer

From appro at openssl.org  Tue Feb 24 22:27:50 2015
From: appro at openssl.org (Andy Polyakov)
Date: Tue, 24 Feb 2015 23:27:50 +0100
Subject: [openssl-dev] [openssl.org #3714] OpenSSL 1.0.2 "make test" bus
 error in evp_test (Solaris 10 Sparc, sun4u)
In-Reply-To: <54ECF2F8.9090605@kippdata.de>
References: <RT-Ticket-3714@openssl.org> <RT-Ticket-3688@openssl.org>
 <1423036028.19595.115.camel@rydra.dev.top>
 <rt-4.0.4-23375-1423066308-639.3688-21-0@openssl.org>
 <54DF6AB4.7090403@kippdata.de>
 <rt-4.0.4-6511-1424704413-608.3714-21-0@openssl.org>
 <54ECE99C.50203@openssl.org> <54ECF2F8.9090605@kippdata.de>
Message-ID: <54ECFAE6.1030406@openssl.org>

> Adding volatile first results in new compiler warnings:

The purpose of exercise was not to find a solution, but to simply see
how compiler reacts at volatile. Thanks for taking time.

> ccm128.c: In function 'CRYPTO_ccm128_decrypt':
> ccm128.c:300:9: warning: passing argument 1 of 'memcpy' discards
> 'volatile' qualifier from pointer target type
>          memcpy(temp.c, inp, 16);
>          ^
> 
> And then it also changes the resulting code:
> 
> -       ldd     [%i4], %i2
> +       call    memcpy, 0
> ^^^ that's probably the memcpy() that was optimized away before

Yes, obviously volatile prevented compiler from optimizing memcpy
altogether. Which kind of contradicts the warning. I mean doesn't
warning say "I'm going to go ahead and ignore qualifier", but it didn't.
Anyway, the hope was that compiler would still inline memcpy, but would
be forced to actually write value to temp, that would have to be
aligned. Once again, it was really just a wonder...

> And yes, with volatile the test no longer crashes even when compiled
> with the broken gcc 4.9.1 and -O3.

Naturally, because real memcpy is perfectly capable of handling
misaligned data in any combination. Thanks again.


From rt at openssl.org  Tue Feb 24 22:44:03 2015
From: rt at openssl.org (Rich Salz via RT)
Date: Tue, 24 Feb 2015 23:44:03 +0100
Subject: [openssl-dev] [openssl.org #3563] remove team-member specific
	targets from Configure
In-Reply-To: <rt-4.0.4-5126-1413210675-1798.3563-6-0@openssl.org>
References: <RT-Ticket-3563@openssl.org>
 <rt-4.0.4-5126-1413210675-1798.3563-6-0@openssl.org>
Message-ID: <rt-4.0.4-24165-1424817843-1713.3563-6-0@openssl.org>

master f09e7ca Move build config table to separate files.

Author: Rich Salz <rsalz at openssl.org>
Date: Tue Feb 24 17:40:22 2015 -0500

Move build config table to separate files.

Move the build configuration table into separate files. The Configurations
file is standard configs, and Configurations.team is for openssl-team
members. Any other file, Configurations*, found in the same directory
as the Configure script, is loaded.

To add another file, use --config=FILE flags (which should probably be
an absolute path).

Written by Stefen Eissing <stefan.eissing at greenbytes.de> and Rich Salz
<rsalz at openssl.org>, contributed by Akamai Technologies.

Reviewed-by: Richard Levitte <levitte at openssl.org>


From rt at openssl.org  Wed Feb 25 09:23:19 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 25 Feb 2015 10:23:19 +0100
Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal,
	ignore unnecessary intermediate CAs in SSL/TLS handshake by default
In-Reply-To: <1417696415.31613.83.camel@kuix.de>
References: <RT-Ticket-3621@openssl.org> <1417696415.31613.83.camel@kuix.de>
Message-ID: <rt-4.0.4-20244-1424856198-1180.3621-6-0@openssl.org>

Please see the following commits to master in relation to this issue:

da084a5ec6
15dba5be6a
25690b7f5f
fa7b01115b

The behaviour is now that openssl will attempt to build a trust chain as it did
previously. If that fails, it will then look to see if there is an alternative
chain that can be constructed that does succeed. This behaviour can be
suppressed using the X509_V_FLAG_NO_ALT_CHAINS flag - this will make openssl
behave as it does now.

Closing this ticket.

Matt


From rt at openssl.org  Wed Feb 25 09:25:37 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 25 Feb 2015 10:25:37 +0100
Subject: [openssl-dev] [openssl.org #3637] [PATCH] x509: skip certs if in
	alternative cert chain
In-Reply-To: <CAEv2VfJhH-frdtJLrT0zWjjzCiSyAM2rSc5b=5+XNnYoPCx8Vg@mail.gmail.com>
References: <RT-Ticket-3637@openssl.org>
 <CAEv2VfJhH-frdtJLrT0zWjjzCiSyAM2rSc5b=5+XNnYoPCx8Vg@mail.gmail.com>
Message-ID: <rt-4.0.4-13323-1424856337-631.3637-6-0@openssl.org>

The patch I mentioned previously has now been applied to master in the
following commits:

da084a5ec6
15dba5be6a
25690b7f5f
fa7b01115b

The behaviour is now that openssl will attempt to build a trust chain as it did
previously. If that fails, it will then look to see if there is an alternative
chain that can be constructed that does succeed. This behaviour can be
suppressed using the X509_V_FLAG_NO_ALT_CHAINS flag - this will make openssl
behave as it does now.

Closing this ticket.

Matt


From matt at openssl.org  Wed Feb 25 13:18:23 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 25 Feb 2015 13:18:23 +0000
Subject: [openssl-dev] [openssl.org #2634] Cross-signed certs rejected
 by OpenSSL because root cert not base of chain
In-Reply-To: <rt-4.0.4-9468-1424813297-1743.2634-6-0@openssl.org>
References: <RT-Ticket-2634@openssl.org> <54ECE9D7.30704@sitetruth.com>
 <rt-4.0.4-9468-1424813297-1743.2634-6-0@openssl.org>
Message-ID: <54EDCB9F.9010309@openssl.org>



On 24/02/15 21:28, nagle at sitetruth.com via RT wrote:
> This is an old bug from 2011, generated originally by someone who put a
> self-signed cert in their cert chain.  Until now, it's been ignored.
> It's become a big problem now that Verisign cross-signed one of their
> major root certs (VeriSign Class 3 Public Primary Certification
> Authority - G5). Their root cert is thus no longer the base of a
> chain, and is rejected by OpenSSL. This bug now comes up if you use
> Mozilla's root cert store with Python. It's affecting some major
> web sites and systems which use OpenSSL are struggling to deal
> with this defect.

Your description of this issue isn't quite right I think. There are
actually two different certificates for "VeriSign Class 3 Public Primary
Certification Authority - G5" - an old one and a new one. I've attached
them both. If you look at each certificate you will notice that the
modulus/SubjectKeyIdentifier/Subject are the same in both. In other
words the private/public keys are the same and the certificate is issued
to the same Subject. However the issuers are different. For the old one:

Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification
Authority

and the new one:

Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006
VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public
Primary Certification Authority - G5

For the new one, the issuer is the same as the subject - this is as self
signed certificate and is a true root in its own right. Its not the case
that suddenly the "root cert is no longer the base of the chain".
Because both certificates have the same subject and have the same keys -
both can be used to form valid certificate chains. The difference is
that before, normally, there would only ever be one way to make a chain.
Now, with CAs issuing certs like this, there is more than one way.

OpenSSL only supports one way of making a chain (its only ever needed
one way). The algorithm works something like this:

Take the certificate provided by the remote peer. Try and build as long
a chain as possible from the untrusted certificates provided by that
remote peer.

If we can build a full chain (all the way back to a self-signed root)
from untrusted certificates, look to see if we have the same root in our
trust store. If so, replace the untrusted root, with our trusted root.
We have a complete (and trusted) chain.

If we can't build a full chain from the peer provided certs, see if we
can add certs from our trust store. Keep adding them until we get to a
root. If we successfully end up with a trusted root then we have a
complete (and trusted) chain.

Anything else means we don't have a trusted chain.

Where servers provide all the certs up to and including the cert in
verisign-old.pem, then OpenSSL will will try to complete that chain by
looking in its trust store for the issuer of that cert, i.e.

Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification
Authority

If it doesn't find it then it has failed to build the chain and stops.

However there is an alternative chain that could be built, i.e. if we
modified the behaviour so that OpenSSL starts knocking off certs off the
top of the chain provided by the peer, we could look to see if we have
an alternative cert for that issuer in our store. If we find one then we
have found an alternative chain.

I have today pushed to the master branch in git a series of commits that
do just that. See commits:
da084a5ec6
15dba5be6a
25690b7f5f
fa7b01115b

You may also wish to look at RT tickets 3621 and 3637 which are relevant
here.

This is not a bug as such in OpenSSL but an addition to the existing
verify algorithm. As such this won't be backported to released versions
(which only receive bug fixes). It will however be in OpenSSL 1.1.0.


> The problem can be reproduced with the OpenSSL command line client,
> but only on some platforms. See the comments in the Python bug report:
> 
> "I have determined that s_client is buggy. It will always load the
> system certs *if and only if* you also pass it a valid custom CA cert
> (which is the reverse of what's expected)."
> 
> "Antione closed this, as a not python error, as
> if you do not pass a valid certificate to openssl s_client
> it will not read the system certificates, which is clearly
> utterly surprising and nuts."
> 
> So three different development teams now agree it's an OpenSSL bug.

This is a completely separate issue and *is* a bug in s_client. I have
just pulled together a fix for this which is going through review at the
moment. This will be applied to master, 1.0.2 and 1.0.1.

I will close RT 2634, as I think it is largely addressed by the latest
commits in master.

Matt


-------------- next part --------------
A non-text attachment was scrubbed...
Name: verisign-new.pem
Type: application/x-x509-ca-cert
Size: 1758 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150225/f7fd5dbe/attachment.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: verisign-old.pem
Type: application/x-x509-ca-cert
Size: 1716 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150225/f7fd5dbe/attachment-0001.crt>

From rt at openssl.org  Wed Feb 25 13:18:48 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 25 Feb 2015 14:18:48 +0100
Subject: [openssl-dev] [openssl.org #2634] Cross-signed certs rejected
	by OpenSSL because root cert not base of chain
In-Reply-To: <54EDCB9F.9010309@openssl.org>
References: <RT-Ticket-2634@openssl.org> <54ECE9D7.30704@sitetruth.com>
 <rt-4.0.4-9468-1424813297-1743.2634-6-0@openssl.org>
 <54EDCB9F.9010309@openssl.org>
Message-ID: <rt-4.0.4-6607-1424870328-352.2634-6-0@openssl.org>



On 24/02/15 21:28, nagle at sitetruth.com via RT wrote:
> This is an old bug from 2011, generated originally by someone who put a
> self-signed cert in their cert chain.  Until now, it's been ignored.
> It's become a big problem now that Verisign cross-signed one of their
> major root certs (VeriSign Class 3 Public Primary Certification
> Authority - G5). Their root cert is thus no longer the base of a
> chain, and is rejected by OpenSSL. This bug now comes up if you use
> Mozilla's root cert store with Python. It's affecting some major
> web sites and systems which use OpenSSL are struggling to deal
> with this defect.

Your description of this issue isn't quite right I think. There are
actually two different certificates for "VeriSign Class 3 Public Primary
Certification Authority - G5" - an old one and a new one. I've attached
them both. If you look at each certificate you will notice that the
modulus/SubjectKeyIdentifier/Subject are the same in both. In other
words the private/public keys are the same and the certificate is issued
to the same Subject. However the issuers are different. For the old one:

Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification
Authority

and the new one:

Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=(c) 2006
VeriSign, Inc. - For authorized use only, CN=VeriSign Class 3 Public
Primary Certification Authority - G5

For the new one, the issuer is the same as the subject - this is as self
signed certificate and is a true root in its own right. Its not the case
that suddenly the "root cert is no longer the base of the chain".
Because both certificates have the same subject and have the same keys -
both can be used to form valid certificate chains. The difference is
that before, normally, there would only ever be one way to make a chain.
Now, with CAs issuing certs like this, there is more than one way.

OpenSSL only supports one way of making a chain (its only ever needed
one way). The algorithm works something like this:

Take the certificate provided by the remote peer. Try and build as long
a chain as possible from the untrusted certificates provided by that
remote peer.

If we can build a full chain (all the way back to a self-signed root)
from untrusted certificates, look to see if we have the same root in our
trust store. If so, replace the untrusted root, with our trusted root.
We have a complete (and trusted) chain.

If we can't build a full chain from the peer provided certs, see if we
can add certs from our trust store. Keep adding them until we get to a
root. If we successfully end up with a trusted root then we have a
complete (and trusted) chain.

Anything else means we don't have a trusted chain.

Where servers provide all the certs up to and including the cert in
verisign-old.pem, then OpenSSL will will try to complete that chain by
looking in its trust store for the issuer of that cert, i.e.

Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification
Authority

If it doesn't find it then it has failed to build the chain and stops.

However there is an alternative chain that could be built, i.e. if we
modified the behaviour so that OpenSSL starts knocking off certs off the
top of the chain provided by the peer, we could look to see if we have
an alternative cert for that issuer in our store. If we find one then we
have found an alternative chain.

I have today pushed to the master branch in git a series of commits that
do just that. See commits:
da084a5ec6
15dba5be6a
25690b7f5f
fa7b01115b

You may also wish to look at RT tickets 3621 and 3637 which are relevant
here.

This is not a bug as such in OpenSSL but an addition to the existing
verify algorithm. As such this won't be backported to released versions
(which only receive bug fixes). It will however be in OpenSSL 1.1.0.


> The problem can be reproduced with the OpenSSL command line client,
> but only on some platforms. See the comments in the Python bug report:
> 
> "I have determined that s_client is buggy. It will always load the
> system certs *if and only if* you also pass it a valid custom CA cert
> (which is the reverse of what's expected)."
> 
> "Antione closed this, as a not python error, as
> if you do not pass a valid certificate to openssl s_client
> it will not read the system certificates, which is clearly
> utterly surprising and nuts."
> 
> So three different development teams now agree it's an OpenSSL bug.

This is a completely separate issue and *is* a bug in s_client. I have
just pulled together a fix for this which is going through review at the
moment. This will be applied to master, 1.0.2 and 1.0.1.

I will close RT 2634, as I think it is largely addressed by the latest
commits in master.

Matt



-------------- next part --------------
A non-text attachment was scrubbed...
Name: verisign-new.pem
Type: application/x-x509-ca-cert
Size: 1758 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150225/c04a42fa/attachment.crt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: verisign-old.pem
Type: application/x-x509-ca-cert
Size: 1716 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150225/c04a42fa/attachment-0001.crt>

From rt at openssl.org  Wed Feb 25 13:24:35 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 25 Feb 2015 14:24:35 +0100
Subject: [openssl-dev] [openssl.org #2634] Fail to verify server with a
	trusted CA root in the middle of the chain
In-Reply-To: <CAGCathzWmLzP1x=Ahy49LD8JnrpX-uaVD5hpM-s1FfA1WwRq+g@mail.gmail.com>
References: <RT-Ticket-2634@openssl.org>
 <CAGCathzWmLzP1x=Ahy49LD8JnrpX-uaVD5hpM-s1FfA1WwRq+g@mail.gmail.com>
Message-ID: <rt-4.0.4-6607-1424870675-919.2634-6-0@openssl.org>

Closing this ticket, as per my previous comments.

Matt


From matt at openssl.org  Wed Feb 25 13:30:42 2015
From: matt at openssl.org (Matt Caswell)
Date: Wed, 25 Feb 2015 13:30:42 +0000
Subject: [openssl-dev] [openssl.org #2634] Cross-signed certs rejected
 by OpenSSL because root cert not base of chain
In-Reply-To: <54EDCB9F.9010309@openssl.org>
References: <RT-Ticket-2634@openssl.org> <54ECE9D7.30704@sitetruth.com>
 <rt-4.0.4-9468-1424813297-1743.2634-6-0@openssl.org>
 <54EDCB9F.9010309@openssl.org>
Message-ID: <54EDCE82.30808@openssl.org>



On 25/02/15 13:18, Matt Caswell wrote:
> This is not a bug as such in OpenSSL but an addition to the existing
> verify algorithm. As such this won't be backported to released versions
> (which only receive bug fixes). It will however be in OpenSSL 1.1.0.

I should add that OpenSSL 1.0.2 does already have the
X509_V_FLAG_TRUSTED_FIRST flag (-trusted_first option to s_client) that
does a very similar job in a slightly different way. However, it is not
the default like the new commits.

Matt


From rt at openssl.org  Wed Feb 25 20:49:30 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 25 Feb 2015 21:49:30 +0100
Subject: [openssl-dev] [openssl.org #3718] Broken NAME header in
	doc/crypto/d2i_ECPKParameters.pod (master and 1.0.2)
In-Reply-To: <54EBA3BE.4050702@kippdata.de>
References: <RT-Ticket-3718@openssl.org> <54EBA3BE.4050702@kippdata.de>
Message-ID: <rt-4.0.4-27624-1424897369-318.3718-6-0@openssl.org>

Patch applied. Many thanks.

Matt


From rt at openssl.org  Wed Feb 25 20:50:14 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Wed, 25 Feb 2015 21:50:14 +0100
Subject: [openssl-dev] [openssl.org #3719] Bug report: Documentation for
	-no_explicit option of "openssl ocsp" missing
In-Reply-To: <54EC9BD5.8010302@pdflib.com>
References: <RT-Ticket-3719@openssl.org> <54EC9BD5.8010302@pdflib.com>
Message-ID: <rt-4.0.4-26410-1424897413-1258.3719-6-0@openssl.org>

Steve has added documentation for this. Closing ticket.

Matt


From rt at openssl.org  Thu Feb 26 19:43:56 2015
From: rt at openssl.org (Andy Polyakov via RT)
Date: Thu, 26 Feb 2015 20:43:56 +0100
Subject: [openssl-dev] [openssl.org #3694] WinCE openSSL 1.0.1L with
	FIPS 2.0.8 - fingerprint does not match
In-Reply-To: <54EF7763.9030002@openssl.org>
References: <RT-Ticket-3694@openssl.org>
 <D59C04F34BE3D1479A34815B4737AB230FCE6C96@6V-MBX2.CRESTRON.CRESTRON.com>
 <rt-4.0.4-6847-1423595781-907.3694-21-0@openssl.org>
 <CY1PR0301MB071383DD867BBDACB065F95B98240@CY1PR0301MB0713.namprd03.prod.outlook.com>
 <rt-4.0.4-26573-1423612266-1338.3694-6-0@openssl.org>
 <54DBD9DD.7040800@openssl.org>
 <rt-4.0.4-26561-1423694412-1015.3694-6-0@openssl.org>
 <54EF7763.9030002@openssl.org>
Message-ID: <rt-4.0.4-28814-1424979836-1791.3694-6-0@openssl.org>

>> One thing to try would be to try both ways of the define for __thumb. This can explain the fingerprint failure. 
>>
>> In fips_canister.c around line 188
>>
>> # if defined(__thumb__) || defined(__thumb)
>>     return (void *)((size_t)instruction_pointer&~1);
>> # else
>>     return (void *)instruction_pointer;
>> # endif
> 
> Well, procedure is build fipscanister.obj, build fips_algvs.exe, use
> fipscanister.obj *binary* with application. So that that whatever thumb
> definition was it worked, in fips_algvs.exe context. Besides, that mask
> is more of an optimization thing. I mean it should work in either case,
> just that without masking the bit all memory references will be
> unaligned. In other words, problem ought to be elsewhere...

There is an inaccuracy in what I said. Specifically the "besides, that
mask is more of an optimization thing" is wrong. Depending on how binary
code is fingerprinted, it might be absolutely crucial to mask the least
significant bit for reasons totally unrelated to optimization. However,
it should be noted that on Windows, be it regular Windows or CE,
fingerprinting does *not* rely on value in question and it does not
matter if the bit in question is masked or not.



From hongcho at gmail.com  Fri Feb 27 17:33:01 2015
From: hongcho at gmail.com (Hong Cho)
Date: Fri, 27 Feb 2015 09:33:01 -0800
Subject: [openssl-dev] FIPS / RSA / ENGINE bug?
Message-ID: <CAEgJZtzCSu_nwhq2k1cyiKJaqX0tbrYJpPZ4zD0NyedN16nSTg@mail.gmail.com>

Hi,

I generated OpenSSL libcrypto (1.0.1l) with the OpenSSL FIPS crypto module
(2.0.8) on FreeBSD 8.4 amd64.

It seems to build fine, and with OPENSSL_FIPS, it seems to behave correctly
(e.g., MD5 is refused, DH with 512-bit key is refused, etc.).

However, genrsa(1) is failing with the following message.

------
# /usr/bin/openssl genrsa -out rsa1 2048
Generating RSA private key, 2048 bit long modulus
34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
method:[...]/openssl/crypto/rsa/rsa_gen.c:88:
------

So, I put some debugging printf's, and this is what I found.

------
# /usr/bin/openssl genrsa -out rsa1 2048
XXX MAIN: engine = 0x0
Generating RSA private key, 2048 bit long modulus
XXX MAIN: e = 0x0
XXX RSA_get_default_method: returning FIPS_rsa_pkcs1_ssleay()
XXX RSA_new_method: ret->meth = 0x800b4a7e0
XXX RSA_new_method: engine = 0x0
XXX RSA_new_method: ret->engine = 0x800e28100
XXX RSA_new_method: ret->meth = 0x800b2ee40
XXX MAIN: rsa->meth = 0x800b2ee40
XXX RSA_generate_key_ex: rsa->meth = 0x800b2ee40
34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
method:/usr/home/hongch/ns_depot/TOT/usr.src/crypto/openssl/crypto/rsa/rsa_gen.c:88:
------

?So, it seems like the FIPS RSA_METHOD gets overridden by the default
ENGINE (the machine does not have any hardware crypto module), which does
not have? the RSA_FLAG_FIPS_METHOD flag set.

I understand that I can rebuild the library with "./config no-engine", but
I haven't seen this mentioned in the FIPS guide.

Is this the right way to do it? Or can the interaction between FIPS and
(the default) ENGINE be better?

Thanks.

Hong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/7b4739d8/attachment.html>

From steve at openssl.org  Fri Feb 27 18:16:47 2015
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 27 Feb 2015 18:16:47 +0000
Subject: [openssl-dev] FIPS / RSA / ENGINE bug?
In-Reply-To: <CAEgJZtzCSu_nwhq2k1cyiKJaqX0tbrYJpPZ4zD0NyedN16nSTg@mail.gmail.com>
References: <CAEgJZtzCSu_nwhq2k1cyiKJaqX0tbrYJpPZ4zD0NyedN16nSTg@mail.gmail.com>
Message-ID: <20150227181647.GA17999@openssl.org>

On Fri, Feb 27, 2015, Hong Cho wrote:

> Hi,
> 
> I generated OpenSSL libcrypto (1.0.1l) with the OpenSSL FIPS crypto module
> (2.0.8) on FreeBSD 8.4 amd64.
> 
> It seems to build fine, and with OPENSSL_FIPS, it seems to behave correctly
> (e.g., MD5 is refused, DH with 512-bit key is refused, etc.).
> 
> However, genrsa(1) is failing with the following message.
> 
> ------
> # /usr/bin/openssl genrsa -out rsa1 2048
> Generating RSA private key, 2048 bit long modulus
> 34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
> method:[...]/openssl/crypto/rsa/rsa_gen.c:88:
> ------
> 
> So, I put some debugging printf's, and this is what I found.
> 
> ------
> # /usr/bin/openssl genrsa -out rsa1 2048
> XXX MAIN: engine = 0x0
> Generating RSA private key, 2048 bit long modulus
> XXX MAIN: e = 0x0
> XXX RSA_get_default_method: returning FIPS_rsa_pkcs1_ssleay()
> XXX RSA_new_method: ret->meth = 0x800b4a7e0
> XXX RSA_new_method: engine = 0x0
> XXX RSA_new_method: ret->engine = 0x800e28100
> XXX RSA_new_method: ret->meth = 0x800b2ee40
> XXX MAIN: rsa->meth = 0x800b2ee40
> XXX RSA_generate_key_ex: rsa->meth = 0x800b2ee40
> 34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
> method:/usr/home/hongch/ns_depot/TOT/usr.src/crypto/openssl/crypto/rsa/rsa_gen.c:88:
> ------
> 
> ???So, it seems like the FIPS RSA_METHOD gets overridden by the default
> ENGINE (the machine does not have any hardware crypto module), which does
> not have??? the RSA_FLAG_FIPS_METHOD flag set.
> 
> I understand that I can rebuild the library with "./config no-engine", but
> I haven't seen this mentioned in the FIPS guide.
> 
> Is this the right way to do it? Or can the interaction between FIPS and
> (the default) ENGINE be better?
> 

Can you work out which ENGINE it is that is doing that? If you print out
ENGINE_get_id(engine) that will show it. I'm guessing it's the cryptodev
ENGINE?

Using no-engine is the only way I can immediately think of to address this
without modifying OpenSSL or making some API calls to disable the ENGINE.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org

From rt at openssl.org  Fri Feb 27 20:14:08 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Fri, 27 Feb 2015 21:14:08 +0100
Subject: [openssl-dev] [openssl.org #3720] Patch for "Increment SSL session
	miss counter appropriately"
In-Reply-To: <AC252449-0686-4120-BDD3-717F4F5C40A5@akamai.com>
References: <RT-Ticket-3720@openssl.org>
 <AC252449-0686-4120-BDD3-717F4F5C40A5@akamai.com>
Message-ID: <rt-4.0.4-4846-1425068047-1793.3720-21-0@openssl.org>

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Increment SSL session miss counter appropriately

There is a missing increment of ctx->stats.sess_miss.

Github link:
https://github.com/akamai/openssl/commit/794af05da2ff8dc40083ad0c5f7ba9ee6e6fa723

And attachment.

--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-Increment-ssl-session-miss-counter-properly.patch
Type: application/octet-stream
Size: 716 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/bec22218/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/bec22218/attachment-0001.htm>

From rt at openssl.org  Fri Feb 27 20:14:08 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Fri, 27 Feb 2015 21:14:08 +0100
Subject: [openssl-dev] [openssl.org #3721] Patch for additional checking of
	self-signed certificates
In-Reply-To: <761813D4-0DE6-4726-A987-FF943C152041@akamai.com>
References: <RT-Ticket-3721@openssl.org>
 <761813D4-0DE6-4726-A987-FF943C152041@akamai.com>
Message-ID: <rt-4.0.4-26948-1425068047-1202.3721-21-0@openssl.org>

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Additional checking of self-signed certificates.

Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer.
Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that.

Github link:
https://github.com/akamai/openssl/commit/faff94b732472616828fe724e09053f134ebb88b

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-Check-that-in-matching-issuer-subject-certs-that-a-s.patch
Type: application/octet-stream
Size: 1579 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/cedd7da1/attachment-0001.obj>

From rt at openssl.org  Fri Feb 27 20:14:18 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Fri, 27 Feb 2015 21:14:18 +0100
Subject: [openssl-dev] [openssl.org #3723] Patch to add short name "Email"
	to "emailAddress" object
In-Reply-To: <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com>
References: <RT-Ticket-3723@openssl.org>
 <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com>
Message-ID: <rt-4.0.4-26948-1425068058-314.3723-21-0@openssl.org>

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add short name "Email" to "emailAddress" object (crypto/object*)

Provides ?Email? as a short name for ?emailAddress?.

Github link:
https://github.com/akamai/openssl/commit/f4fad8d9eadac5e997395eeac5a101796663a8a7

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-Add-short-name-Email-to-emailAddress-object-crypto-o.patch
Type: application/octet-stream
Size: 1947 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/4c47feab/attachment.obj>

From rt at openssl.org  Fri Feb 27 20:14:15 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Fri, 27 Feb 2015 21:14:15 +0100
Subject: [openssl-dev] [openssl.org #3722] Patch to add -preserve_dates
	option to x509 app
In-Reply-To: <6E812714-8E5A-48FD-9506-E258A3EB28B0@akamai.com>
References: <RT-Ticket-3722@openssl.org>
 <6E812714-8E5A-48FD-9506-E258A3EB28B0@akamai.com>
Message-ID: <rt-4.0.4-26948-1425068055-744.3722-21-0@openssl.org>

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Add -preserve_dates option to x509 app

If -preserve_dates is passed to the x509 app, any changes to the certificate will not change the validity dates.

Github link:
https://github.com/akamai/openssl/commit/b11e6b59e802f9fab0675126018529db7f2259e0

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// ?One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-Add-preserve-dates-to-x509-app.patch
Type: application/octet-stream
Size: 6482 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/17b5425a/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/17b5425a/attachment.htm>

From rt at openssl.org  Fri Feb 27 20:14:26 2015
From: rt at openssl.org (Short, Todd via RT)
Date: Fri, 27 Feb 2015 21:14:26 +0100
Subject: [openssl-dev] [openssl.org #3724] Patch/Feature to add asynchronous
	processing for some operations
In-Reply-To: <81070344-6715-47E7-9BE6-F007FE307535@akamai.com>
References: <RT-Ticket-3724@openssl.org>
 <81070344-6715-47E7-9BE6-F007FE307535@akamai.com>
Message-ID: <rt-4.0.4-21159-1425068066-641.3724-21-0@openssl.org>

Hello OpenSSL Org:

This is a change that Akamai has made to its implementation of OpenSSL.

Version: master branch
Description: Patch/Feature to add asynchronous processing for some operations

This change rebrands SSL_ERROR_WANT_X509_LOOKUP to be SSL_ERROR_WANT_EVENT, making an event type to wait for visible in SSL->rwstate and letting TLS_SRP have its own event type instead of piggybacking on SSL_X509_LOOKUP. This also adds events for for decryption of client key exchange response, generating client certificate verify message and signing of server key exchange message. these typically long-duration RSA operations. The events are:

# define SSL_MIN_EVENT                    1000
/* client is deciding which cert to present - doesn't follow MIN */
# define SSL_EVENT_X509_LOOKUP            SSL_X509_LOOKUP
/* server is processing TLS SRP client hello */
# define SSL_EVENT_SRP_CLIENTHELLO        1000
/* server is waiting for decryption of key */
# define SSL_EVENT_KEY_EXCH_DECRYPT_DONE  1001
/* client is waiting for cert verify setup */
# define SSL_EVENT_SETUP_CERT_VRFY_DONE   1002
/* server is siging the message for key exchange */

New APIs:
void SSL_CTX_set_schedule_task_cb(SSL_CTX *ctx, SSL_schedule_task_cb cb);
int SSL_signal_event(const SSL *ssl, int event, int retcode);
int SSL_signal_event_err(const SSL *ssl, int event, int func, int reason, const char *file, int line);
int SSL_want_event(const SSL *ssl);

Github link:
https://github.com/akamai/openssl/commit/e4fa5107524bb5e6e4c79953d436b7e59ee6c5e2

And attachment.

Thank you.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, three if by the Internet."

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Rebranding-of-SSL_ERROR_WANT_X509_LOOKUP-as-SSL_ERRO.patch
Type: application/octet-stream
Size: 97280 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/85e5f01f/attachment-0001.obj>

From hongcho at gmail.com  Fri Feb 27 20:56:05 2015
From: hongcho at gmail.com (Hong Cho)
Date: Fri, 27 Feb 2015 12:56:05 -0800
Subject: [openssl-dev] FIPS / RSA / ENGINE bug?
In-Reply-To: <20150227181647.GA17999@openssl.org>
References: <CAEgJZtzCSu_nwhq2k1cyiKJaqX0tbrYJpPZ4zD0NyedN16nSTg@mail.gmail.com>
 <20150227181647.GA17999@openssl.org>
Message-ID: <CAEgJZtwbHQuON9sWnevzveAjajf5jY-71BS-OeJ1fK3YifmVgg@mail.gmail.com>

Steve,

Thank you for the response.

Here is what ENGINE_get_id() is saying.

------
XXX RSA_new_method: ret->engine = 0x800e28100
XXX RSA_new_method: ENGINE_get_id(ret->engine) = rsax
XXX RSA_new_method: ret->meth = 0x800b2ee40
------

Hong.

On Fri, Feb 27, 2015 at 10:16 AM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Fri, Feb 27, 2015, Hong Cho wrote:
>
> > Hi,
> >
> > I generated OpenSSL libcrypto (1.0.1l) with the OpenSSL FIPS crypto
> module
> > (2.0.8) on FreeBSD 8.4 amd64.
> >
> > It seems to build fine, and with OPENSSL_FIPS, it seems to behave
> correctly
> > (e.g., MD5 is refused, DH with 512-bit key is refused, etc.).
> >
> > However, genrsa(1) is failing with the following message.
> >
> > ------
> > # /usr/bin/openssl genrsa -out rsa1 2048
> > Generating RSA private key, 2048 bit long modulus
> > 34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
> > method:[...]/openssl/crypto/rsa/rsa_gen.c:88:
> > ------
> >
> > So, I put some debugging printf's, and this is what I found.
> >
> > ------
> > # /usr/bin/openssl genrsa -out rsa1 2048
> > XXX MAIN: engine = 0x0
> > Generating RSA private key, 2048 bit long modulus
> > XXX MAIN: e = 0x0
> > XXX RSA_get_default_method: returning FIPS_rsa_pkcs1_ssleay()
> > XXX RSA_new_method: ret->meth = 0x800b4a7e0
> > XXX RSA_new_method: engine = 0x0
> > XXX RSA_new_method: ret->engine = 0x800e28100
> > XXX RSA_new_method: ret->meth = 0x800b2ee40
> > XXX MAIN: rsa->meth = 0x800b2ee40
> > XXX RSA_generate_key_ex: rsa->meth = 0x800b2ee40
> > 34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
> >
> method:/usr/home/hongch/ns_depot/TOT/usr.src/crypto/openssl/crypto/rsa/rsa_gen.c:88:
> > ------
> >
> > ???So, it seems like the FIPS RSA_METHOD gets overridden by the default
> > ENGINE (the machine does not have any hardware crypto module), which does
> > not have??? the RSA_FLAG_FIPS_METHOD flag set.
> >
> > I understand that I can rebuild the library with "./config no-engine",
> but
> > I haven't seen this mentioned in the FIPS guide.
> >
> > Is this the right way to do it? Or can the interaction between FIPS and
> > (the default) ENGINE be better?
> >
>
> Can you work out which ENGINE it is that is doing that? If you print out
> ENGINE_get_id(engine) that will show it. I'm guessing it's the cryptodev
> ENGINE?
>
> Using no-engine is the only way I can immediately think of to address this
> without modifying OpenSSL or making some API calls to disable the ENGINE.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/2dc7643d/attachment.html>

From brian at briansmith.org  Fri Feb 27 22:31:34 2015
From: brian at briansmith.org (Brian Smith)
Date: Fri, 27 Feb 2015 14:31:34 -0800
Subject: [openssl-dev] [openssl.org #3721] Patch for additional checking
 of self-signed certificates
In-Reply-To: <rt-4.0.4-26948-1425068047-1202.3721-21-0@openssl.org>
References: <RT-Ticket-3721@openssl.org>
 <761813D4-0DE6-4726-A987-FF943C152041@akamai.com>
 <rt-4.0.4-26948-1425068047-1202.3721-21-0@openssl.org>
Message-ID: <CAFewVt58HJgroRito47i0A59X+TJdOLrnxX=TmwwMqvznafxiA@mail.gmail.com>

Short, Todd via RT <rt at openssl.org> wrote:
> Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer.
> Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that.
>
> Github link:
> https://github.com/akamai/openssl/commit/faff94b732472616828fe724e09053f134ebb88b

Could you explain this more?

In your patch, there is a comment that says "Input certificate
(subject) is self signed." But, the test is that the issuer name
equals the subject name. That means the certificate is self-*issued*,
not self-*signed*.

Consider this chain:

{ Subject=Foo, Issuer=Foo, Key=Key1, Signed by Key2 }
{ Subject=Foo, Issuer=Foo, Key=Key2, Signed by Key3 }
{ Subject=Foo, Issuer=Foo, Key=Key3, Signed by Key3, Trust Anchor }

All three certificates are self-issued. The issuer of the first
certificate is not self-signed but it is self-issued. But, it being
self-issued doesn't matter because it isn't a trust anchor.

Consider this chain:

{ Subject=Foo, Issuer=Foo, Key=Key1, Signed by Key1 }
{ Subject=Foo, Issuer=Bar, Key=Key1, Signed by Key2 }
{ Subject=Bar, Issuer=Bar, Key=Key2, Signed by Key2, Trust Anchor }

The first certificate is self-signed and self-issued. It's issuer is
not self-signed or self-issued, so your patch would reject this chain.
But, this is a valid chain.

Cheers,
Brian

From rt at openssl.org  Fri Feb 27 22:35:32 2015
From: rt at openssl.org (Brian Smith via RT)
Date: Fri, 27 Feb 2015 23:35:32 +0100
Subject: [openssl-dev] [openssl.org #3721] Patch for additional checking
	of self-signed certificates
In-Reply-To: <CAFewVt58HJgroRito47i0A59X+TJdOLrnxX=TmwwMqvznafxiA@mail.gmail.com>
References: <RT-Ticket-3721@openssl.org>
 <761813D4-0DE6-4726-A987-FF943C152041@akamai.com>
 <rt-4.0.4-26948-1425068047-1202.3721-21-0@openssl.org>
 <CAFewVt58HJgroRito47i0A59X+TJdOLrnxX=TmwwMqvznafxiA@mail.gmail.com>
Message-ID: <rt-4.0.4-21159-1425076532-1264.3721-6-0@openssl.org>

Short, Todd via RT <rt at openssl.org> wrote:
> Check that in matching issuer/subject certs, that a self-signed subject also has a self-signed issuer.
> Given that the subject certificate is self-signed, it means that the issuer and the subject are the same certificate. This change verifies that.
>
> Github link:
> https://github.com/akamai/openssl/commit/faff94b732472616828fe724e09053f134ebb88b

Could you explain this more?

In your patch, there is a comment that says "Input certificate
(subject) is self signed." But, the test is that the issuer name
equals the subject name. That means the certificate is self-*issued*,
not self-*signed*.

Consider this chain:

{ Subject=Foo, Issuer=Foo, Key=Key1, Signed by Key2 }
{ Subject=Foo, Issuer=Foo, Key=Key2, Signed by Key3 }
{ Subject=Foo, Issuer=Foo, Key=Key3, Signed by Key3, Trust Anchor }

All three certificates are self-issued. The issuer of the first
certificate is not self-signed but it is self-issued. But, it being
self-issued doesn't matter because it isn't a trust anchor.

Consider this chain:

{ Subject=Foo, Issuer=Foo, Key=Key1, Signed by Key1 }
{ Subject=Foo, Issuer=Bar, Key=Key1, Signed by Key2 }
{ Subject=Bar, Issuer=Bar, Key=Key2, Signed by Key2, Trust Anchor }

The first certificate is self-signed and self-issued. It's issuer is
not self-signed or self-issued, so your patch would reject this chain.
But, this is a valid chain.

Cheers,
Brian



From hongcho at gmail.com  Fri Feb 27 22:49:38 2015
From: hongcho at gmail.com (Hong Cho)
Date: Fri, 27 Feb 2015 14:49:38 -0800
Subject: [openssl-dev] FIPS / RSA / ENGINE bug?
In-Reply-To: <CAEgJZtwbHQuON9sWnevzveAjajf5jY-71BS-OeJ1fK3YifmVgg@mail.gmail.com>
References: <CAEgJZtzCSu_nwhq2k1cyiKJaqX0tbrYJpPZ4zD0NyedN16nSTg@mail.gmail.com>
 <20150227181647.GA17999@openssl.org>
 <CAEgJZtwbHQuON9sWnevzveAjajf5jY-71BS-OeJ1fK3YifmVgg@mail.gmail.com>
Message-ID: <CAEgJZty7OtiKg6srif52LDajE0HVm_BihOMY2HyqmpJ4OJBMpw@mail.gmail.com>

?FYI, I played with "no-rsax" without "no-engine", and it ?works.

Without RSAX, the engine is NULL, and the default method (in this case,
FIPS) weren't getting overridden in RSA_new_method().

I think I will go with this.

Hong.

On Fri, Feb 27, 2015 at 12:56 PM, Hong Cho <hongcho at gmail.com> wrote:

> Steve,
>
> Thank you for the response.
>
> Here is what ENGINE_get_id() is saying.
>
> ------
> XXX RSA_new_method: ret->engine = 0x800e28100
> XXX RSA_new_method: ENGINE_get_id(ret->engine) = rsax
> XXX RSA_new_method: ret->meth = 0x800b2ee40
> ------
>
> Hong.
>
> On Fri, Feb 27, 2015 at 10:16 AM, Dr. Stephen Henson <steve at openssl.org>
> wrote:
>
>> On Fri, Feb 27, 2015, Hong Cho wrote:
>>
>> > Hi,
>> >
>> > I generated OpenSSL libcrypto (1.0.1l) with the OpenSSL FIPS crypto
>> module
>> > (2.0.8) on FreeBSD 8.4 amd64.
>> >
>> > It seems to build fine, and with OPENSSL_FIPS, it seems to behave
>> correctly
>> > (e.g., MD5 is refused, DH with 512-bit key is refused, etc.).
>> >
>> > However, genrsa(1) is failing with the following message.
>> >
>> > ------
>> > # /usr/bin/openssl genrsa -out rsa1 2048
>> > Generating RSA private key, 2048 bit long modulus
>> > 34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
>> > method:[...]/openssl/crypto/rsa/rsa_gen.c:88:
>> > ------
>> >
>> > So, I put some debugging printf's, and this is what I found.
>> >
>> > ------
>> > # /usr/bin/openssl genrsa -out rsa1 2048
>> > XXX MAIN: engine = 0x0
>> > Generating RSA private key, 2048 bit long modulus
>> > XXX MAIN: e = 0x0
>> > XXX RSA_get_default_method: returning FIPS_rsa_pkcs1_ssleay()
>> > XXX RSA_new_method: ret->meth = 0x800b4a7e0
>> > XXX RSA_new_method: engine = 0x0
>> > XXX RSA_new_method: ret->engine = 0x800e28100
>> > XXX RSA_new_method: ret->meth = 0x800b2ee40
>> > XXX MAIN: rsa->meth = 0x800b2ee40
>> > XXX RSA_generate_key_ex: rsa->meth = 0x800b2ee40
>> > 34374116264:error:0409B09D:rsa routines:RSA_generate_key_ex:non fips rsa
>> >
>> method:/usr/home/hongch/ns_depot/TOT/usr.src/crypto/openssl/crypto/rsa/rsa_gen.c:88:
>> > ------
>> >
>> > ???So, it seems like the FIPS RSA_METHOD gets overridden by the default
>> > ENGINE (the machine does not have any hardware crypto module), which
>> does
>> > not have??? the RSA_FLAG_FIPS_METHOD flag set.
>> >
>> > I understand that I can rebuild the library with "./config no-engine",
>> but
>> > I haven't seen this mentioned in the FIPS guide.
>> >
>> > Is this the right way to do it? Or can the interaction between FIPS and
>> > (the default) ENGINE be better?
>> >
>>
>> Can you work out which ENGINE it is that is doing that? If you print out
>> ENGINE_get_id(engine) that will show it. I'm guessing it's the cryptodev
>> ENGINE?
>>
>> Using no-engine is the only way I can immediately think of to address this
>> without modifying OpenSSL or making some API calls to disable the ENGINE.
>>
>> Steve.
>> --
>> Dr Stephen N. Henson. OpenSSL project core developer.
>> Commercial tech support now available see: http://www.openssl.org
>> _______________________________________________
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150227/f5ed402e/attachment.html>

From rt at openssl.org  Fri Feb 27 22:57:49 2015
From: rt at openssl.org (Matt Caswell via RT)
Date: Fri, 27 Feb 2015 23:57:49 +0100
Subject: [openssl-dev] [openssl.org #3704] OpenSSL HEAD breaks OpenConnect
	VPN client
In-Reply-To: <1424090741.1804.39.camel@infradead.org>
References: <RT-Ticket-3704@openssl.org>
 <1424090741.1804.39.camel@infradead.org>
Message-ID: <rt-4.0.4-4846-1425077869-1268.3704-6-0@openssl.org>

Hi David,

I've just pushed a slightly amended version of this patch to
master/1.0.2/1.0.1.

Closing this ticket.

Matt


From erik at efca.com  Sat Feb 28 06:53:05 2015
From: erik at efca.com (Erik Forsberg)
Date: Fri, 27 Feb 2015 22:53:05 -0800
Subject: [openssl-dev] Suspicious crash in 1.0.2
Message-ID: <Ra1xSMi7lGlWgr-@srv.efca.com>

Hi.
I seem to have run into a really hard to pin down issue in
OpenSSL 1.0.2. Normally, it simply causes an EFAULT during
a write syscall, which makes me close the connection, but
to investigate, I added a core dump at that time. This is what I see

(dbx) where
current thread: t at 6
  [1] __lwp_sigqueue(0x6, 0x6, 0xffffc1c01c5fb7e0, 0xffffffff, 0x0, 0xffff80ffbf05cbb0), at 0xffff80ffbf27e70a 
  [2] thr_kill(), at 0xffff80ffbf272ec8 
  [3] raise(), at 0xffff80ffbf22291d 
  [4] abort(), at 0xffff80ffbf1f7ff2 
  [5] sock_write(b = 0x4f53d0, in = 0xc1e8 "<bad address 0x000000000000c1e8>", inl = 14060), line 156 in "bss_sock.c"
  [6] BIO_write(b = 0x4f53d0, in = 0xc1e8, inl = 14060), line 243 in "bio_lib.c"
=>[7] ssl3_write_pending(s = 0x9ab1d0, type = 23, buf = 0xcc2010 "HTTP/1.1 200 OK^M\nContent-Type: image/jpeg^M\nContent-Disposition: attachment; filename="photo.JPG"^M\nCache-Control: no-cache,private^M\nPragma: no-cache^M\nDate: Sat, 28 Feb 2015 03:55:43 GMT^M\nTransfer-Encoding: chunked^M\nContent-Encoding: gzip^M\n^M\n4000^M\n^_\x8b^H", len = 63488U), line 1091 in "s3_pkt.c"
  [8] ssl3_write_bytes(s = 0x9ab1d0, type = 23, buf_ = 0xcc2010, len = 65536), line 668 in "s3_pkt.c"
  [9] ssl3_write(s = 0x9ab1d0, buf = 0xcc2010, len = 65536), line 4400 in "s3_lib.c"
  [10] SSL_write(s = 0x9ab1d0, buf = 0xcc2010, num = 65536), line 1046 in "ssl_lib.c"
  [11] spr_tls_nonblock_write(so = 24, s = 0x9ab1d0, buffer = 0xcc2010, length = 129916, error = 0xffff80ffbf05cf2c), line 1351 in "spr_tls.c"
  [12] http_sender(con = 0xb06010), line 425 in "http.c"
  [13] wsd_worker(arg = 0xb06010), line 941 in "server.c"
  [14] worker_thread(arg = 0x523c10), line 382 in "spr_thrpool.c"
  [15] _thrp_setup(), at 0xffff80ffbf2751cd 
  [16] _lwp_start(), at 0xffff80ffbf275470 
(dbx) up
Current function is ssl3_write_bytes
  668           i = ssl3_write_pending(s, type, &buf[tot], s->s3->wpend_tot);
(dbx) p *wb
*wb = {
    buf    = (nil)
    len    = 63700U
    offset = 49640
    left   = 14060
}

The EFAULT error is clearly due to wb->buf == NULL.
As far as I can see, setting wb->buf to NULL is done in the
fairly new MULTIBLOCK code. What lead up to this is quite complex
but the following points seems relevant.

What my web server is trying to do, is sending a reasonable large image/jpeg
in response to a GET call. The entire image is sent in one large SSL_write() call
(in non-blocking mode) so I can see that first call to SS_write returns 0 bytes
written, WANT_WRITE error returned, when I retry the SSL_write call I get this error.

If I limit the size of each call to SSL_write() to 16KB, all works well.
It only fails when the browser is Firefox (NSS), works fine with IE 11.

Not sure if this behaviour was introduced by OpenSSL 1.0.2 or Firefox 35 (both
occured very close to each other).

My platform is Solaris 11.2, compiler SunStudio 12.4
configured like
perl Configure solaris64-x86_64-cc --prefix=/usr/local/ssl --openssldir=/usr/local/ssl --libdir=lib/amd64 enable-ssl-trace shared threads zl
ib-dynamic

nothing special there

any ideas how to further narrow down this ?

From rt at openssl.org  Sat Feb 28 07:21:33 2015
From: rt at openssl.org (Kurt Cancemi via RT)
Date: Sat, 28 Feb 2015 08:21:33 +0100
Subject: [openssl-dev] [openssl.org #3725] [PATCH] Use warning/fatal
	constants instead of numbers with comments
In-Reply-To: <CADujJWWLEZsc5_HwbcWs2Mf6HvvVWQA+Ox9OphU=24SU9Vo_8A@mail.gmail.com>
References: <RT-Ticket-3725@openssl.org>
 <CADujJWWLEZsc5_HwbcWs2Mf6HvvVWQA+Ox9OphU=24SU9Vo_8A@mail.gmail.com>
Message-ID: <rt-4.0.4-26948-1425108093-697.3725-21-0@openssl.org>

The attached patch uses warning/fatal constants instead of numbers with
comments for warning/alerts in d1_pkt.c and s3_pkt.c

---
Kurt Cancemi
https://www.x64architecture.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-warning-fatal-constants-instead-of-numbers-with-.patch
Type: text/x-patch
Size: 2032 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150228/92f1e487/attachment.bin>

From kurt at roeckx.be  Sat Feb 28 11:00:35 2015
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 28 Feb 2015 12:00:35 +0100
Subject: [openssl-dev] Suspicious crash in 1.0.2
In-Reply-To: <Ra1xSMi7lGlWgr-@srv.efca.com>
References: <Ra1xSMi7lGlWgr-@srv.efca.com>
Message-ID: <20150228110035.GA30368@roeckx.be>

On Fri, Feb 27, 2015 at 10:53:05PM -0800, Erik Forsberg wrote:
> Hi.
> I seem to have run into a really hard to pin down issue in
> OpenSSL 1.0.2. Normally, it simply causes an EFAULT during
> a write syscall, which makes me close the connection, but
> to investigate, I added a core dump at that time. This is what I see

Do you get an EAGAIN just before the EFAULT?


Kurt


From erik at efca.com  Sat Feb 28 17:47:29 2015
From: erik at efca.com (Erik Forsberg)
Date: Sat, 28 Feb 2015 09:47:29 -0800
Subject: [openssl-dev] Suspicious crash in 1.0.2
Message-ID: <4ou0sgEkeq9hS35@srv.efca.com>

I suspect that happens in the previous call to SSL_write.
It returns WANT_WRITE, then next call to SSL_write gives the EFAULT
I see that from my app server logs.

>-- Original Message --
>
>On Fri, Feb 27, 2015 at 10:53:05PM -0800, Erik Forsberg wrote:
>> Hi.
>> I seem to have run into a really hard to pin down issue in
>> OpenSSL 1.0.2. Normally, it simply causes an EFAULT during
>> a write syscall, which makes me close the connection, but
>> to investigate, I added a core dump at that time. This is what I see
>
>Do you get an EAGAIN just before the EFAULT?
>
>
>Kurt
>
>_______________________________________________
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


From erik at efca.com  Sat Feb 28 23:23:00 2015
From: erik at efca.com (Erik Forsberg)
Date: Sat, 28 Feb 2015 15:23:00 -0800
Subject: [openssl-dev] Suspicious crash in 1.0.2
Message-ID: <Yx44p1L4T4GL4YE@srv.efca.com>

Its definitively in the MULTIBLOCK code.
Works fine if building 1.0.2 with NO_MULTIBLOCK

>-- Original Message --
>
>I suspect that happens in the previous call to SSL_write.
>It returns WANT_WRITE, then next call to SSL_write gives the EFAULT
>I see that from my app server logs.
>
>>-- Original Message --
>>
>>On Fri, Feb 27, 2015 at 10:53:05PM -0800, Erik Forsberg wrote:
>>> Hi.
>>> I seem to have run into a really hard to pin down issue in
>>> OpenSSL 1.0.2. Normally, it simply causes an EFAULT during
>>> a write syscall, which makes me close the connection, but
>>> to investigate, I added a core dump at that time. This is what I see
>>
>>Do you get an EAGAIN just before the EFAULT?
>>
>>
>>Kurt
>>
>>_______________________________________________
>>openssl-dev mailing list
>>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>
>_______________________________________________
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev