Re: [openssl-dev] [RFC 0/2] Proposal for seamless handling of TPM based RSA keys in openssl

[Thomas Francis, Jr.]

On 11/22/16 2:37 PM, David Woodhouse wrote:

On Tue, 2016-11-22 at 18:29 +, Salz, Rich wrote:





And the locale / character set issue is not relevant here. ASN.1 is
binary, PEM is ASCII.


PEM should be ASCII; in practice it is not necessarily ASCII.  There are 
several products that produce "PEM files" in various EBCDIC character 
sets.  Other products produce them in ASCII, but then  transfer them 
with an EBCDIC to ASCII conversion.  And in still others, it's the 
customer who transfers it manually, converting from EBCDIC to ASCII when 
the file was ASCII.  These latter two are less common in my limited 
experience, which is fortunate, because recovering from that is very 
difficult.


I've also seen some windows products that will produce "unicode" pem 
files, which may or may not have a BOM at the beginning, and other 
products which produce the files with the UTF-8 BOM at the beginning, too.


While it's easy for me to say these files are malformed, the customer 
doesn't care.  They have the file; they expect it to work.


In most of those cases, the user will open the file, and see exactly 
what they expect, a PEM header, followed by what looks like base64 
encoded data, and a matching footer.  It's very difficult to convince a 
customer the file is incorrect in the face of that.  Even if you get 
them to acknowledge the file isn't in the expected format, again they 
don't care.  They have the file, usually from some very expensive 
software or process, your much less important software had better use it 
(yup, I've had those conversations with customers, fortunately with tech 
support filtering my side of the conversation :) ).


In any event, I don't think it's OpenSSL's job to detect and fix these 
kinds of issues.  Although probably 90% of them could be fixed with a 
simple EBCDIC->ASCII converter, ignoring BOMs and recognizing the 
Windows "unicode" format. :)


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

Re: [openssl-dev] [openssl.org #4696] Resolved: BUG: openssl1.0.2j Solaris-Sparc : ../util/shlib_wrap.sh ./bad_dtls_test - core dump

[Llewelyn Thomas via RT]

Confirmed - thanks for the reply!


From: Rich Salz via RT <r...@openssl.org>
Sent: 05 October 2016 08:09:49
To: Llewelyn Thomas
Subject: [openssl.org #4696] Resolved: BUG: openssl1.0.2j Solaris-Sparc : 
../util/shlib_wrap.sh ./bad_dtls_test - core dump

According to our records, your request has been resolved. If you have any
further questions or concerns, please respond to this message.

--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4696
Please log in as guest with password guest if prompted


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4696
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4696] BUG: openssl1.0.2j Solaris-Sparc : ../util/shlib_wrap.sh ./bad_dtls_test - core dump

[Llewelyn Thomas via RT]

$ uname -a
SunOS orl-rpd-sunbld1 5.10 Generic_141444-09 sun4v sparc 
SUNW,SPARC-Enterprise-T5120

$ echo $PATH
/opt/sunstudio12.1/bin:/usr/ccs/bin:/usr/bin:/usr/openwin/bin



test_bad_dtls

../util/shlib_wrap.sh ./bad_dtls_test
*** Signal 10 - core dumped
make: Fatal error: Command failed for target `test_bad_dtls'
Current working directory /apps/llew/openssl-1.0.2j/test
*** Error code 1
The following command caused the error:
(cd test && echo "testing..." && \
TOP= && unset TOP ${LIB+LIB} ${LIBS+LIBS}${INCLUDE+INCLUDE} 
${INCLUDES+INCLUDES} ${DIR+DIR} ${DIRS+DIRS} ${SRC+SRC}
   ${LIBSRC+LIBSRC} ${LIBOBJ+LIBOBJ} ${ALL+ALL}${EXHEADER+EXHEADER} 
${HEADER+HEADER}   ${GENERAL+GENERAL} ${CFLAGS+CFLAGS}
  ${ASFLAGS+ASFLAGS} ${AFLAGS+AFLAGS} ${LDCMD+LDCMD} 
${LDFLAGS+LDFLAGS} ${SCRIPTS+SCRIPTS}${SHAREDCMD+SHAREDCMD} ${SHARE
DFLAGS+SHAREDFLAGS}   ${SHARED_LIB+SHARED_LIB} ${LIBEXTRAS+LIBEXTRAS} && 
make -e LC_ALL=C PLATFORM='solaris64-sparcv9-cc' PROCESSOR='' CC
='cc' CFLAG='-KPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -m64 -xO5 -xstrconst -xdepen
d -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM 
-DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM'
  AS='cc' ASFLAG='-KPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS 
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -m64 -xO5 -xst
rconst -xdepend -Xa -DB_ENDIAN -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_A
SM -c'   AR='ar  r' NM='nm' RANLIB='/usr/ccs/bin/ranlib'
 RC='windres'CROSS_COMPIL
E=''PERL='/usr/bin/perl' ENGDIRS='ccgost'   SDIRS='objects  md4 
md5 sha hmac ripemd whrlpool  des aes rc2 rc4 idea bf cast ca
mellia seed modes  bn ec rsa dsa ecdsa dh ecdh dso engine  buffer bio stack 
lhash rand err  evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12
comp ocsp ui krb5  cms pqueue ts srp cmac' 
LIBRPATH='/apps/openssl-1.0.2j-bin/lib'   INSTALL_PREFIX=''   
INSTALLTOP='/apps/o
penssl-1.0.2j-bin' OPENSSLDIR='/apps/openssl-1.0.2j-bin/ssl' 
LIBDIR='lib'MAKEDEPEND='$${TOP}/util/domd $$
{TOP} -MD makedepend'  DEPFLAG='-DOPENSSL_NO_DEPRECATED 
-DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE 
-DOPENSSL_NO_LIB
UNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 
-DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_SSL2 
-
DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST -DOPENSSL_NO_WEAK_SSL_CIPHERS'   
MAKEDEPPROG='makedepend'SHARED_LDFLAGS=
'-m64 -G -dy -z text'KRB5_INCLUDES='' LIBKRB5='' 
ZLIB_INCLUDE='-I/apps/zlib-1.2.3-bin//include' LIBZLIB='/apps/zlib-1.2.3-bin
//solaris10-sparc64/lib'EXE_EXT='' SHARED_LIBS='libcrypto.so.1.0.0 
libssl.so.1.0.0' SHLIB_EXT='.so.1.0.0' SHLIB_TARGET='solaris-share
d' PEX_LIBS='' EX_LIBS='-lsocket -lnsl -ldl 
-L/apps/zlib-1.2.3-bin//solaris10-sparc64/lib -lz' CPUID_OBJ='sparcv9cap.o 
sparccpuid.o'
BN_ASM='bn-sparcv9.o sparcv9-mont.o sparcv9a-mont.o vis3-mont.o sparct4-mont.o 
sparcv9-gf2m.o'EC_ASM='' DES_ENC='des_enc-sparc.o fcrypt_b
.o dest4-sparcv9.o'  AES_ENC='aes_core.o aes_cbc.o aes-sparcv9.o 
aest4-sparcv9.o' CMLL_ENC='camellia.o cmll_misc.o cmll_cbc.o cmllt4-
sparcv9.o'  BF_ENC='bf_enc.o' CAST_ENC='c_enc.o'RC4_ENC='rc4_enc.o 
rc4_skey.o' RC5_ENC='rc5_enc.o'  SHA1_ASM_OBJ='sha1-sparcv9.o
sha256-sparcv9.o sha512-sparcv9.o' 
MD5_ASM_OBJ='md5-sparcv9.o' RMD160_ASM_OBJ=''   
WP
_ASM_OBJ='wp_block.o' MODES_ASM_OBJ='ghash-sparcv9.o'   
  ENGINES_ASM_OBJ=''  PERLASM_SCHEME=
'void'   FIPSLIBDIR=''   
FIPSDIR='/usr/local/ssl/fips-2.0'   
FIPSCANLIB="${FIPSCANLIB:-}"
   THIS=${THIS:-tests} MAKEFILE=Makefile MAKEOVERRIDES= TOP=.. TESTS='alltests' 
OPENSSL_DEBUG_MEMORY=on OPENSSL_CONF=../apps/openssl.cnf tes
ts );
make: Fatal error: Command failed for target `tests'

$ pstack test/core

core 'test/core' of 17356: ./bad_dtls_test
7e5c1944 time (100104adc, 25400, 1, 0, fc0b, 5) + 14
00012cbc main (0, 0, 0, 18, 0, 100104a8c) + dc
00011c1c _start (0, 0, 0, 0, 0, 0) + 17c

Configure command used:

$ ./Configure solaris64-sparcv9-cc --prefix=$OPENSSL_HOME threads zlib 
--with-zlib-lib=$ZLIB_HOME/solaris10-sparc64/lib 
--with-zlib-include=$ZLIB_HOME/include shared no-mdc2 no-rc5



-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4696
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible

[Thomas Waldmann via RT]

On 06/28/2016 11:18 PM, Kurt Roeckx via RT wrote:
> On Mon, Jun 27, 2016 at 08:50:43PM +0000, Thomas Waldmann via RT wrote:
>> I didn't ask where to get the missing code from, I asked whether you
>> maybe want to make life simpler for people by adding this to 1.0.x
>> rather than having a thousand software developers copy and pasting it
>> into their projects.
> 
> I think this will not actually make life easier.  People using a
> 1.0.x version are not always using the latest 1.0.x version.

Aren't they?

Don't they use 1.0.xLATEST rather soon, due to security fixes?

And in case some dist maintainer chooses to rather backport, couldn't
they also backport the added function if it is documented as "openssl
1.1.x migration support" or so?

We aren't talking about incompatible changes, just adding 2 trivial
functions that were not there yet (but should have been there, when
looking at the rest of the API).

> Or are you happy to say that they either need a certain version of
> the 1.0.x branch

Well, of course openssl project would only care about latest update of
each series 1.0.1x, 1.0.2x, 1.1.0x.

> or the 1.1 branch?  Then why not just say they need the 1.1 branch?

Because software needs to be able to run on both versions, likely for years.

For borgbackup, we want to support running on centos6, debian wheezy,
... debian experimental.

In a year, openssl 1.0.x and 1.1.x will be in stable and supported
distributions that openssl-using software needs to support.


-- 


GPG ID: FAF7B393
GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4589] Resolved: simplifying writing code that is 1.0.x and 1.1.x compatible

[Thomas Waldmann via RT]

On 06/27/2016 10:25 PM, Rich Salz via RT wrote:
> According to our records, your request has been resolved. If you have any
> further questions or concerns, please respond to this message.

No, it wasn't resolved.

You completely missed / ignored the point, which you can read again in
the subject line of this mail.

I didn't ask where to get the missing code from, I asked whether you
maybe want to make life simpler for people by adding this to 1.0.x
rather than having a thousand software developers copy and pasting it
into their projects.

But obviously I was expecting too much...

Cython (in our case) has no #if, so we will need a separate C module
just for what was forgotten in 1.0.x (or 0.9.8) back then.


-- 

GPG ID: FAF7B393
GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4589] simplifying writing code that is 1.0.x and 1.1.x compatible

[Thomas Waldmann via RT]

Hi,

at borgbackup project, we are currently trying to make it compatible
with OpenSSL 1.0.x and 1.1.x.

For the opaque cipher ctx this worked quite easily like this:

https://github.com/borgbackup/borg/pull/1193/files#diff-85ee6ebe1cdcfd4a4699c3913d519b27R23

I could not have a cipher ctx structure as a instance variable, but a
pointer to one worked. I am just computing the current IV myself, so I
do not need to reach into the ctx (I need to do that anyway to support
gcm mode).

I used EVP_CIPHER_CTX_new/free() - although not in the man page, they
are there since 0.98 (and the wiki examples use them, too).

Solved.

In borgbackup 1.2, we will also need the flexible (not single-call)
interface to HMAC and I could get it working using the same method as
above (using a pointer and the new/free functions - we do not access
into hmac ctx here, so it is even simpler).

But: HMAC_CTX_{new/free} are not available on 1.0.x. :-(

So my question / request: could these functions be added to a future
update, like 1.0.2i, to simplify migration / portability of code?

I suspect that these 2 functions are very simple to backport from 1.1 to
1.0.x.

Cheers,

Thomas

-- 

GPG ID: FAF7B393
GPG FP: 6D5B EF9A DD20 7580 5747 B70F 9F88 FB52 FAF7 B393


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4589
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL extension

[Thomas Brunnthaler via RT]

In the meantime i use 1.0.2h which works good so far. Thank you.

2016-06-20 22:47 GMT+02:00 Rich Salz via RT :

> We believe this is fixed by the commit that viktor pointed out. Is this not
> true? What are folks asking OpenSSL to do?
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4539] Documentation - Cipher names changed between 1.0.2 & 1.1.0-pre

[Thomas, Marc via RT]

Hello Folks,

I'd like to suggest the "ciphers" documentation in 1.1.0 be updated to include 
the old EDH names for ciphers which were renamed to DHE between 1.0.2 & 
1.1.0-pre.
I think there are only two affected which are still available: 
EDH-RSA-DES-CBC3-SHA & EDH-DSS-DES-CBC3-SHA.

https://www.openssl.org/docs/manmaster/apps/ciphers.html

So, for example:

SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHADHE-DSS-DES-CBC3-SHA (OpenSSL 1.1.0 
onwards, ignored by earlier versions)
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHAEDH-DSS-DES-CBC3-SHA (pre OpenSSL 1.1.0, 
accepted as an alias by OpenSSL 1.1.0)
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHADHE-RSA-DES-CBC3-SHA (OpenSSL 1.1.0 
onwards, ignored by earlier versions)
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHAEDH-RSA-DES-CBC3-SHA (pre OpenSSL 1.1.0, 
accepted as an alias by OpenSSL 1.1.0)

TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHADHE-DSS-DES-CBC3-SHA (OpenSSL 1.1.0 
onwards, ignored by earlier versions)
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHAEDH-DSS-DES-CBC3-SHA (pre OpenSSL 1.1.0, 
accepted as an alias by OpenSSL 1.1.0)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHADHE-RSA-DES-CBC3-SHA (OpenSSL 1.1.0 
onwards, ignored by earlier versions)
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHAEDH-RSA-DES-CBC3-SHA (pre OpenSSL 1.1.0, 
accepted as an alias by OpenSSL 1.1.0)


The reason for asking is the old names are preferable for backwards 
compatibility with earlier versions of OpenSSL.

Thanks & Kind Regards,

Marc Thomas
Field Support Specialist, Customer Service

EMC Computer Systems (UK) Limited
Business Address: EMC Tower, Great West Road, Brentford, TW8 9AN

[CS Email Signature - LATEST]

EMC Computer Systems (UK) Limited
Registered in England No. 2051360  Registered office address: Level 1, Exchange 
House, Primrose Street, London EC2A 2EG.
The information contained in this e-mail message and any files transmitted with 
it are confidential. It is intended only for the addressee and others 
authorised to receive it. If you are not the intended recipient or the person 
responsible for delivering the message to the intended recipient, you are 
advised that you have received the e-mail in error; please delete it and notify 
the sender immediately. You should not retain the message or disclose its 
contents to anyone. Any disclosure, copying, distribution or action taken in 
reliance on the contents of the e-mail and its attachments is strictly 
prohibited.


-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4539
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL extension

[Thomas Brunnthaler via RT]

Hello ! I build a release package with the suggested fix in github but php
wont load curl anyway. Any other suggestions ? I used MS VC2013 with NASM
when using 1.0.2 branch.

PHP Warning:  PHP Startup: Unable to load dynamic library
'\php5\php_curl.dll' - Das Betriebssystem kann php[1912] nicht ausführen.
 in Unknown on line 0.

2016-03-09 23:33 GMT+01:00 noloa...@gmail.com via RT <r...@openssl.org>:

> On Tue, Mar 8, 2016 at 8:43 AM, Thomas Brunnthaler via RT
> <r...@openssl.org> wrote:
> > CURL not working since upgrade to 1.0.2g on windows. I use PHP 5.2.17 VC6
> > x86 TS. Error Message: OS cannot load %1 or so.
> >
>
> Is it possible to release an out-of-band update for this fix?
>
> Many folks are experiencing pain points because of it. See, for example:
>
>   * http://stackoverflow.com/q/35895377/608639
>   * http://stackoverflow.com/q/35880228/608639
>
> Jeff
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] [openssl.org #4416] 1.0.1s makes porting to HP-UX much harder than before

[Thomas Francis, Jr.]

> On Mar 11, 2016, at 9:25 AM, H.Merijn Brand via RT  wrote:
> 
> https://github.com/openssl/openssl/issues/806
> 
> Let me take HP-UX 11.11/PA2 as an example.
> Up to and including 1.0.1r, I just unpacked from the
> distributes .tar.gz and ran
> 
> $ ./Configure zlib zlib-dynamic no-asm hpux64-parisc2-cc
> $ perl -pi -e's/\+O3/+O2 +Z -AC99/‘ Makefile

Yeah, don’t do this.  Instead, install HP’s ANSI C/C++ compiler (or whatever 
they’re calling it these days).  You can often (but not always) obtain it for 
free.  HP also makes pre-compiled binaries for GCC available (and if not — 
sometimes they disappear), you can find a GCC package for your version of HP-UX 
at http://hpux.connect.org.uk/  I think they only have packages for HP-UX 11.11 
and newer, though.  Likewise, HP is unlikely to be providing binaries for 
anything older than that.

> $ make
> $ make test
> $ make install
> 
> And all went well.
> As of 1.0.1s, a new tool is required that is not available in HP-UX
> land: makedepend
> 
> $ ./Configure zlib zlib-dynamic no-asm hpux64-parisc2-cc
> ⋮
> make[1]: Leaving directory `/pro/3gl/openssl-1.0.1s/test'
> 
> Configured for hpux64-parisc2-cc.
> 
> *** Because of configuration changes, you MUST do the following before
> *** building:
> 
>make depend
> $ make depend
> making depend in crypto...
> make[1]: Entering directory `/pro/3gl/openssl-1.0.1s/crypto'
> ../util/domd[30]: makedepend:  not found.
> mv: Makefile.new: cannot access: No such file or directory
> make[1]: *** [local_depend] Error 127
> make[1]: Leaving directory `/pro/3gl/openssl-1.0.1s/crypto'
> make: *** [depend] Error 1
> 
> The makedepend tool is very hard to build from scratch on HP-UX, as it
> depends on a plethora of (recent) GNU tools that are obviously also not
> available on HP-UX. I build a lot of OpenSource projects on HP-UX, and
> this is the first that needs makedepend. Building makedepend requires
> pkg-config, which also fails to build.
> 
> For 11.11, makedepend is available in HP's imake package (imake-6.00
> from 2002), if I install that, I do have makedepend, but it might not
> do what is expected: I have no way to tell.

That is _exactly_ what you want, if you really want to use makedepend, which 
you probably don't.  Don’t try to build the GNU makedepend; it’ll work, but it 
has a lot of dependencies, as you’ve noticed.

> $ perl -pi -e's/\+O3/+O2 +Z -AC99/' Makefile
> $ make depend
> ⋮
> $ make
> ⋮
> $ make test
> ⋮
> rc4-40
> rc4-40 base64
> seed
> seed base64
> seed-cbc
> seed-cbc base64
> seed-cfb
> seed-cfb base64
> seed-ecb
> seed-ecb base64
> seed-ofb
> seed-ofb base64
> zlib
> 9223376434892769432:error:25066067:DSO support routines:DLFCN_LOAD:could not 
> load the shared library:dso_dlfcn.c:187:filename(libz.so): Unable to find 
> library 'libz.so'.
> 9223376434892769432:error:25070067:DSO support routines:DSO_load:could not 
> load the shared library:dso_lib.c:232:
> 9223376434892769432:error:29064065:lib(41):BIO_ZLIB_NEW:zlib not 
> supported:c_zlib.c:463:
> 9223376434892769432:error:25066067:DSO support routines:DLFCN_LOAD:could not 
> load the shared library:dso_dlfcn.c:187:filename(libz.so): Unable to find 
> library 'libz.so'.
> 9223376434892769432:error:25070067:DSO support routines:DSO_load:could not 
> load the shared library:dso_lib.c:232:
> 9223376434892769432:error:29064065:lib(41):BIO_ZLIB_NEW:zlib not 
> supported:c_zlib.c:463:
> cmp: EOF on ./p.zlib.clear
> make[1]: *** [test_enc] Error 1
> make[1]: Leaving directory `/pro/3gl/openssl-1.0.1s/test'
> make: *** [tests] Error 2
> 
> That used to pass. The problem in above fail is that something is told
> to look for libz.so, where on HP-UX/PA the naming convention for shared
> libraries is libz.sl I did not spot an obvious location in the build
> procedure to fix that
> 
> So
> 
> Where does the sudden need for makedepend come from and can it please
> be removed? (as there are no packages available anywhere that make
> makedepend available for HP-UX 11.00 and older, they are ruled out
> forgood by this change)

If you use HP’s ANSI C compiler, or GCC, you won’t need makedepend.  If you’re 
using HP-UX prior to 11.11 (well, I’m not sure about prior to 9.0), the imake 
package (and makedepend) are part of the base install; just run swinstall and 
point it to the original HP-UX media, and you should be able to install it.  
For HP-UX 11.23, IIRC, the imake package will work, but I might be 
mis-remembering (it’s been a long time).

> Where should I look for having PA-RISC search for .sl instead of .so
> 
> (Note that AIX only has .a, and it is shared by default)
> 
> -- 
> H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
> using perl5.00307 .. 5.23   porting perl5 on HP-UX, AIX, and openSUSE
> http://mirrors.develooper.com/hpux/http://www.test-smoke.org/
> http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/
> 
> -- 
> Ticket here: 

Re: [openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL extension

[Thomas Brunnthaler via RT]

I am unable to recompile PHP 5.2.17 VC6 TS x86  and because of my old
webserver (where source is not available) i cannot upgrade to any newer
version with VC9+  Is the software change in OpenSSL so dramatic, that
newer releases are totally incompatible with "old" software ?

2016-03-08 16:09 GMT+01:00 Randall S. Becker via RT <r...@openssl.org>:

> On March 8, 2016 9:37 AM, Viktor Dukhovni wrote:
> > To: r...@openssl.org; openssl-dev@openssl.org
> > Subject: Re: [openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL
> > extension
> >
> > On Tue, Mar 08, 2016 at 01:43:48PM +, Thomas Brunnthaler via RT
> > wrote:
> >
> > > CURL not working since upgrade to 1.0.2g on windows. I use PHP 5.2.17
> > VC6
> > > x86 TS. Error Message: OS cannot load %1 or so.
> >
> > Is this fixed by:
> >
> >
> > https://github.com/openssl/openssl/commit/133138569f37d149ed1d7641fe
> > 8c75a93fded445
>
> We saw this on HPE NonStop NSE on all products using the OpenSSL DLL. Our
> solution was to reconfigure and rebuild OpenSSH, Curl, wget, git (to name a
> few). The configure scripts detect that those methods are not present and
> act appropriately.
>
> Cheers,
> Randall
>
> -- Brief whoami: NonStop developer since approximately
> UNIX(421664400)/NonStop(2112884442)
> -- In my real life, I talk too much.
>
>
>
>
> --
> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398
> Please log in as guest with password guest if prompted
>
>

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398
Please log in as guest with password guest if prompted

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

[openssl-dev] [openssl.org #4398] BUG / 1.0.2g breaks CURL extension

[Thomas Brunnthaler via RT]

CURL not working since upgrade to 1.0.2g on windows. I use PHP 5.2.17 VC6
x86 TS. Error Message: OS cannot load %1 or so.

-- 
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4398
Please log in as guest with password guest if prompted

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

Re: [openssl-dev] MacOS defaults?

[Thomas Francis, Jr.]

> On Mar 7, 2016, at 5:01 AM, Ben Laurie  wrote:
> 
> On 7 March 2016 at 09:59, Andy Polyakov  wrote:
>> Hmm. So why do I see this on my macbook?
>> 
>> $ arch
>> i386
> 
> Try "uname -m"
 
 This is not reliable. Because it must have changed recently, it used to
 be i386 even on 64-bit systems. sysctl -n hw.optional.x86_64 is the way
 to go, it's right there in ./config...
>>> 
>>> Sure, and that is used to decide whether to offer the 64 bit version.
>>> But its not helping me on what should be default.
>> 
>> I thought suggestion was to default to 64 bit whenever it is an option.
>> And uname -m *was* returning i386 even on system capable of executing
>> 64-bit code. So that sysctl is something that works in *either* situation.
> 
> The question is: which is better? I've been told there's no advantage
> to 64 bit on MacOS unless you need the extra address space - if that's
> so, then we should default to 32 bit, I think.

As with all x86-64 systems, compiling for 64-bit will enable the compiler to 
use many more registers, generally resulting in faster code.  The same is _not_ 
true of 64-bit PPC, where the advice you list above is (almost) accurate.  
Don’t compile for 64-bit PPC unless you need the extra address space, or you 
need instructions that are only available for the 64-bit processor.  I suspect 
the advice you heard was geared toward Mac OS on PPC, not x86.

I haven’t checked out everything in OpenSSL, but I can say that several 
programs I’ve written which use OpenSSL for SHA-2, SHA-1, MD5, AES, and 3DES 
run the crypto routines _much_ faster when compiled as 64-bit than as 32-bit 
(that was not isolating OpenSSL’s libcrypto, but isolating the code that 
invoked those routines).  The overall application performance was also greatly 
improved.  Memory usage was slightly higher, since pointers are larger, of 
course.  And that held true for Mac OS X (10.6 and later), Windows (2003 Server 
- 2012 Server and 7 and later), Linux (don’t remember which kernels), and 
FreeBSD (8.0 and later).  I expect it’ll continue to hold true, so I don’t 
expect to keep testing it.


> -- 
> 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

[openssl-dev] [openssl.org #3763] bug report: pkeyutl option order

[Thomas Tanner via RT]

pkeyutl requires a certain order of the key options to work:

-pkeyopt must follow the -inkey option
-passin must precede the -inkey option

This is not documented and confusing.
It would be better if the order was ignored.

OpenSSL 1.0.2a


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

[openssl-dev] [openssl.org #3762] bug report: x509 -x509toreq does not copy extensions

[Thomas Tanner via RT]

converting a certificate to a certificate request

openssl x509 -x509toreq -in cert.pem -out req.pem -signkey key.pem

does not copy the extensions to the request

OpenSSL 1.0.2a


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

[openssl-dev] [openssl.org #3761] bug report: x509 -certopt ca_default documentation mismatch

[Thomas Tanner via RT]

According to the manpage -textopt ca_default suppresses the signature:

   ca_default
   the value used by the ca utility, equivalent to no_issuer,
no_pubkey, no_header, no_version, no_sigdump and no_signame.

but  openssl x509 -noout -in file.pem -text -certopt ca_default shows
both  Signature Algorithm and the dump. Only if no_signame,no_sigdump
are added, they are suppressed.

OpenSSL 1.0.2a


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

[openssl.org #3594] Windows and Heap32* performance problems

[Thomas Thomassen via RT]

This is related to this issue:
http://rt.openssl.org/Ticket/Display.html?id=2100

The issue was closed as resolved recently, saying timer limiting was
implemented. However, the closing message didn't respond to the previous
message from Andre Heinecke which mention that the timer limiting isn't
applied to the inner loop of all code branches.

The one for Visual Studio builds has the time limiter on the inner loop
when calling Heap32Next, but for all other compilers the time limiter is
only applied to the outer Heap32NextList loop, not the inner one.

We got affected and it has a severe performance impact to our application.

Some background to our application, I work for Trimble SketchUp and we
embed the Ruby interpreter into our application in order to provide a Ruby
scripting API. We release for Windows and OSX.
We use the Ruby builds from Ruby Windows Installer which uses mingw -
meaning the binaries we have doesn't have the inner loop time limiter.

Upon a fresh startup of our application when the process takes about ~70MB
we experience 3-5 second lag when OpenSSL::Random::random_bytes(0) is
called the first time. This function is called by several things in the
Ruby libraries so it has a high surface area for us.

As we load 3d models the time increases. The worst case we've seen so far
has been ~15 minutes when we had a model open and our process consumed over
4GB RAM.

The profiler flagged Heap32Next as red hot being called from OpenSSL. From
that we investigated and found the issue linked in the top of this thread.

We even tried to call that from a second thread, but for some reason it
appear to block the whole process.

We'd like to ask for the issue to be reopened and look at again for all
compilers.


I guess the short term quick fix is to add the time limiter to the inner
loop of the second code path. (rand_win.c line 559 - 1.0.1j)


But even then, it means we should always get a one second lag upon first
time use. Under OSX there is no such lag - and it would be nice to have
matching performance. One second lag even under low memory consumption
isn't always ideal.

As part of researching the Heap32Next performance issues we came across
this article by Raymond Chen:

*Why is the Heap32Next function incredibly slow on Windows 7?*
http://blogs.msdn.com/b/oldnewthing/archive/2012/03/23/10286665.aspx

There he describe the history of the function and how its performance has
degraded over time in order to prevent misuse and memory leaks. But he also
mention:


*But since the toolhelp library was intended for diagnostic purposes anyway
(I mean, it's right there in the name: tool help), these weren't considered
serious problems. Your debugging plug-in might use it to walk the heap
looking for memory leaks, but you wouldn't deploy it in production, right?*

And if you look at the MSDN documention for the Heap32* functions:

*The functions provided by the tool help library make it easier for you to
obtain information about currently executing applications. These functions
are designed to streamline the creation of tools, specifically debuggers.*


The indications are strong that these functions are not meant to be used by
release products like in OpenSSL.

Raymond suggest in the end of this article to use the newer HeapWalk
function:




*By the way, the recommended way to walk the contents of the heap is to use
the Heap­Walk function. The Heap­Walk function does not suffer from this
problem; enumerating the entire heap via repeated calls to Heap­Walk has
total running time proportional to the number of heap blocks. Note that
Heap­Walk can only enumerate heap blocks from the current process. If
you're doing cross-process heap walking for diagnostic purposes, then
you're stuck with Heap32­First/Heap32­Next, but since you're just doing it
for diagnostic purposes, correctness should be more important to you than
performance.*

http://msdn.microsoft.com/en-us/library/windows/desktop/aa366710(v=vs.85).aspx

We did some quick tests using Ruby to call the Win32 functions, one code
snippet walking the heap like OpenSSL currently do, and then using HeapWalk
- the latter was order of magnitude faster. Now, the struct it traverses is
somewhat difference, but I assume you can still extract random bytes from
that?

Or even some other way to generate the random bytes, we're not really
concerned about how, but rather the performance.
I don't have the know how on how one securely generates random bytes so I
didn't attempt to make a patch for this issue. But I do plea that the
implementation is improved and we are willing to test the performance of
new implementations to give it real world testing in an application that do
stress the memory and CPU a lot of the computer.

-Thomas Thomassen

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List

[openssl.org #3524] Enhancement request: OpenSSL 1.0.1.i-1 (Arch Linux) by default generates SHA-1 CSRs

[Thomas Preissler via RT]

Hello,

first and foremost, many thanks for the time and effort you guys (and
girls!) put in to 'keep the internet running' - and thank you for
encrypting my credit card data mostly every day (and other data every
single day)!

I am wondering why my version OpenSSL 1.0.1.i-1 (Arch Linux) is by default
still generating SHA-1 CSRs. So I have done the following:

$ openssl req -new -sha256 -key privkey.pem -out sha256.csr
$ openssl req -new -key privkey.pem -out normal.csr

and if I have a look inside those CSRs with

$ openssl req -in $CSRFILE -noout -text

I get either

Signature Algorithm: sha1WithRSAEncryption

from normal.csr and

Signature Algorithm: sha256WithRSAEncryption

from sha256.csr.


Shouldn't it be the default to generate SHA-2 sigs? I understand SHA-2
support is not given on absolutely all devices out there, but I guess to
push things forward with SHA-1 deprecation it would help to generate
SHA-2 sigs by default and on the other hand, instructing openssl
specifically if you want SHA-1 signed certs.


Regards

Thomas

-- 
www.preissler.co.uk | Twitter: @module0x90 | PGP-Key: 75889415
GPG Fingerprint:  CCBD 153A D257 CA7E A217  FDF7 5928 03D1 7588 9415

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3213] [PATCH] Fix failure to read default CA file CA path in s_{client,server,time} (bug #977)

[Reuben Thomas]

On 11 January 2014 12:17, Florian Zumbiehl via RT r...@openssl.org wrote:

 Hi,

  So in that case it should try only the user's option if the user gave a
  -CApath or -CAfile, and otherwise the default option?

 well, I am not an OpenSSL dev, but that's the behaviour I would consider
 correct, yeah.

  The suggestion above has the advantage that it does not require
  SSL_CTX_load_verify_locations to be changed (as its behavior of failing
  when CApath and CAfile are both NULL is documented). However, if it were
  changed, then the code above would still work.

 Yeah, I didn't mean to imply that SSL_CTX_load_verify_locations() should be
 changed, for the reason you mention, just pointing out that the behaviour
 doesn't really make sense ...

  The correct behavior is, as I hope I've made clear, outside my competence
  to decide, but I'm quite happy to work up an acceptable patch if guided
 as
  to what exactly it should implement.

 Thanks for the work, that bug did have me scratch my head a while ago (I
 used socat instead then, they manage to get it right), it wouldn't hurt to
 get that fixed ...


Jolly good!

Could we please have an opinion from a developer willing to define and push
an acceptable patch?

-- 
http://rrt.sc3d.org

Re: [openssl.org #3213] [PATCH] Fix failure to read default CA file CA path in s_{client,server,time} (bug #977)

[Reuben Thomas]

On 10 January 2014 06:41, Florian Zumbiehl via RT r...@openssl.org wrote:

 Hi,

  The fix is to change || in the above code to . Then, the
  command-line parameters are used to set the certificate path, and if
  that fails, the defaults are used instead. This then gives the

 while the behaviour with your patch is a lot saner than without it, I would
 argue that it's still broken, as it exhibits fail-open behaviour:
 SSL_CTX_load_verify_locations() probably can fail for reasons other than
 !(CAfile||CApath), and it's unlikely that the user meant this CA, or any
 other if loading this one fails for whatever reason.


So in that case it should try only the user's option if the user gave a
-CApath or -CAfile, and otherwise the default option?


 (Arguably, SSL_CTX_load_verify_locations() is actually broken in that it
 returns failure for an empty set of CAs,


To cope with that, we could have a new function (to be used in place of the
current

   if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
   (!SSL_CTX_set_default_verify_paths(ctx)))

), which goes something like:

int SSL_CTX_load_verify_locations_or_default(SSL_CTX *ctx, const char
*CAfile, const char *CApath)
{
   if (CAfile || CApath)
 return SSL_CTX_load_verify_locations(ctx, CAfile, CApath);
   return SSL_CTX_set_default_verify_paths(ctx);
}

and the above code can then be replaced by:

  if (!SSL_CTX_load_verify_locations_or_default(ctx, CAfile, CApath))


 as it's logically perfectly
 consistent to authenticate against a deny-all policy.)


Indeed.

The suggestion above has the advantage that it does not require
SSL_CTX_load_verify_locations to be changed (as its behavior of failing
when CApath and CAfile are both NULL is documented). However, if it were
changed, then the code above would still work.

The correct behavior is, as I hope I've made clear, outside my competence
to decide, but I'm quite happy to work up an acceptable patch if guided as
to what exactly it should implement.

-- 
http://rrt.sc3d.org

Re: [openssl.org #3213] [PATCH] Fix failure to read default CA file CA path in s_{client,server,time} (bug #977)

[Reuben Thomas via RT]

On 11 January 2014 12:17, Florian Zumbiehl via RT r...@openssl.org wrote:

 Hi,

  So in that case it should try only the user's option if the user gave a
  -CApath or -CAfile, and otherwise the default option?

 well, I am not an OpenSSL dev, but that's the behaviour I would consider
 correct, yeah.

  The suggestion above has the advantage that it does not require
  SSL_CTX_load_verify_locations to be changed (as its behavior of failing
  when CApath and CAfile are both NULL is documented). However, if it were
  changed, then the code above would still work.

 Yeah, I didn't mean to imply that SSL_CTX_load_verify_locations() should be
 changed, for the reason you mention, just pointing out that the behaviour
 doesn't really make sense ...

  The correct behavior is, as I hope I've made clear, outside my competence
  to decide, but I'm quite happy to work up an acceptable patch if guided
 as
  to what exactly it should implement.

 Thanks for the work, that bug did have me scratch my head a while ago (I
 used socat instead then, they manage to get it right), it wouldn't hurt to
 get that fixed ...


Jolly good!

Could we please have an opinion from a developer willing to define and push
an acceptable patch?

-- 
http://rrt.sc3d.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3213] [PATCH] Fix failure to read default CA file CA path in s_{client,server,time} (bug #977)

[Reuben Thomas via RT]

On 10 January 2014 06:41, Florian Zumbiehl via RT r...@openssl.org wrote:

 Hi,

  The fix is to change || in the above code to . Then, the
  command-line parameters are used to set the certificate path, and if
  that fails, the defaults are used instead. This then gives the

 while the behaviour with your patch is a lot saner than without it, I would
 argue that it's still broken, as it exhibits fail-open behaviour:
 SSL_CTX_load_verify_locations() probably can fail for reasons other than
 !(CAfile||CApath), and it's unlikely that the user meant this CA, or any
 other if loading this one fails for whatever reason.


So in that case it should try only the user's option if the user gave a
-CApath or -CAfile, and otherwise the default option?


 (Arguably, SSL_CTX_load_verify_locations() is actually broken in that it
 returns failure for an empty set of CAs,


To cope with that, we could have a new function (to be used in place of the
current

   if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
   (!SSL_CTX_set_default_verify_paths(ctx)))

), which goes something like:

int SSL_CTX_load_verify_locations_or_default(SSL_CTX *ctx, const char
*CAfile, const char *CApath)
{
   if (CAfile || CApath)
 return SSL_CTX_load_verify_locations(ctx, CAfile, CApath);
   return SSL_CTX_set_default_verify_paths(ctx);
}

and the above code can then be replaced by:

  if (!SSL_CTX_load_verify_locations_or_default(ctx, CAfile, CApath))


 as it's logically perfectly
 consistent to authenticate against a deny-all policy.)


Indeed.

The suggestion above has the advantage that it does not require
SSL_CTX_load_verify_locations to be changed (as its behavior of failing
when CApath and CAfile are both NULL is documented). However, if it were
changed, then the code above would still work.

The correct behavior is, as I hope I've made clear, outside my competence
to decide, but I'm quite happy to work up an acceptable patch if guided as
to what exactly it should implement.

-- 
http://rrt.sc3d.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #3213] [PATCH] Fix failure to read default CA file CA path in s_{client,server,time} (bug #977)

[Reuben Thomas via RT]

This is a patch for bug #977. Since this is the first time I've
attempted to contribute to OpenSSL, I lay out the problem, underlying
bug and fix in some detail below. Apologies if I labor the obvious.


The symptoms:

s_client and some other apps can fail to verify certificates when they
should have no problem, e.g.:

$ openssl s_client -connect www.google.com:443|grep Verify return
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Verify return code: 20 (unable to get local issuer certificate)

This is surprising, as I'm using the stock openssl (1.0.1e) that comes
with my Ubuntu 13.10 system.

If I download the certificate and run openssl verify, I get the
expected result:

$ openssl verify google.pem
google.pem: OK

If I explicitly point openssl at the system’s certificate store, I
also get the expected result:

$ openssl s_client -CApath /etc/ssl/certs -connect www.google.com:443|grep 
Verify return 
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = 
www.google.com
verify return:1
Verify return code: 0 (ok)

But that's the default path, so why didn't it work before? Also, I can
get the same result by supplying a bogus path:

$ openssl s_client -CApath /no/such/path -connect www.google.com:443|grep 
Verify return 
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2
verify return:1
depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = 
www.google.com
verify return:1
Verify return code: 0 (ok)

Oops.


The bug:

s_client.c, s_server.c and s_time.c contain the following stanza,
which starts in s_client.c at line 1397 (current git as of this
writing):

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; */
}

The intended logic of the if is that first, we try to load any
certificate locations given on the command line, and then, if that
fails, we load the defaults.

SSL_CTX_load_verify_locations returns 0 for failure and 1 for success.
When both CAfile and CApath are NULL, it fails (returns 0). This
causes the shortcut || operator to succeed, and
SSL_CTX_set_default_verify_paths is not run.

When a correct path or bogus path is supplied,
SSL_CTX_load_verify_locations returns 1 for success (it doesn't mind
in the latter case that the directory does not exist, it merely
retrieves no data from it). Therefore, the right-hand side of the ||
is evaluated, and the default certificate path is set.


The fix

The fix is to change || in the above code to . Then, the
command-line parameters are used to set the certificate path, and if
that fails, the defaults are used instead. This then gives the
expected result (for brevity, I won't repeat the terminal logs here):
supplying no argument or the default directory explicitly causes
verification to succeed, whereas supplying a bogus path causes it to
fail.


The patch

There follows a patch which makes this fix in each of s_client.c,
s_server.c and s_time.c. The patch is against git at the time of
writing. It also makes a similar fix to two other files, mttest.c and
ssltest.c, which suffer from a similar problem.

From e5015769d02202dbd1ef0e32386ceba844def059 Mon Sep 17 00:00:00 2001
From: Reuben Thomas r...@sc3d.org
Date: Sun, 5 Jan 2014 22:54:44 +
Subject: [PATCH] Fix bug #977 (accidentally reversed logic)

---
 apps/s_client.c | 2 +-
 apps/s_server.c | 2 +-
 apps/s_time.c   | 2 +-
 crypto/threads/mttest.c | 8 
 ssl/ssltest.c   | 8 
 5 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/apps/s_client.c b/apps/s_client.c
index 1e3bc39..383cce0 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -1394,7 +1394,7 @@ bad:
 
SSL_CTX_set_verify(ctx,verify,verify_callback);
 
-   if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath)) ||
+   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); */
diff --git a/apps/s_server.c b/apps/s_server.c
index 1bac3b4..ecc0249 100644
--- a/apps/s_server.c
+++ b/apps/s_server.c
@@ -1828,7 +1828,7 @@ bad:
}
 #endif
 
-   if ((!SSL_CTX_load_verify_locations(ctx,CAfile,CApath

Re: GoldBug.sf.net - Secure Instant Messenger

[Thomas Asta]

Dear Jakob,
thanks for rising the items, which should be discussed, but first let´s
start with your footer:
 This public discussion message is non-binding and may contain errors. ;-)
Find some comments inline  ..
Regards Tom.


2013/8/1 Jakob Bohm jb-open...@wisemo.com


GoldBug.sf.net http://GoldBug.sf.net- Secure Instant Messenger

http://goldbug.sourceforge.net/
Please evaluate the OpenSSL implemntation
Any comments, is it really secure?
as it implements the new echo chat protocol, which is designed for only
non-plaintext chat.



Looking at the project on sourceforge, I am not convinced this is
as good as it wants to be.

First off, the main page is a lot of lofty goals with little
substance, it took some digging to get to the code.

 You didd digg into the code and also the functionality?

Secondly, the code repository is a mess, it looks like an unfiltered
mirror of the authors working directory, including compiled binaries
and copied library parts.

 They seem to do so, but that´s good to have for a mainly windows project
 all DLLs files available. NO missmatch might occur.

The code is excessively string based, with lots of idioms that make
sense in prototyping languages like perl, but not in C++ code, even
when using Qt.

 Many comments in the code to read and understand it easily.

++
Now for the crypto part:

- Most of the code seems to be using gcrypt, not OpenSSL libcrypt.
I am not familiar enough with that library to check what each
function does.

 a. Both OpenSSL and libgcrypt are used.

- The code was originally intended as some kind of P2P
stumbleupon-like link sharing system called Spot On and still
contains leftovers from that system.

 b. GoldBug uses Lib Spot-On. Lib Spot-On attempts to implement a total
algorithm called Echo Protocol.

- The code seems to store local data in an SQL database. Some code
comments seem to indicate that the users passphrase and/or private
key is stored there, which would be a security problem.


 c. Private and public keys are stored in an encrypted manner in
databases. Other attributes are also stored in an encrypted manner in local
databases. Encrypted items are described in Documentation/ENCRYPTED.
Storing encrypted data is not a security issue.


From the unclear text files about the protocols, and some of the
source code, it looks like some basic encryption mistakes are being
made:

- A (keyed) hash of the plaintext is sent in the clear for no
good reason. This is wrong, either send the hash encrypted along
with the message or hash the encrypted message, not the plaintext.
Some people have argued that encrypting the hash is a bad idea (I
disagree), but every professional I have read agree that if you
don't encrypt the hash, the hash should be of the encrypted
ciphertext, not the decrypted plaintext.

 e. The original implementation sent an encrypted form of the hash. The
has was based on plaintext data. The behavior was changed per
http://cseweb.ucsd.edu/~mihir/papers/oem.html, e-t-m.

- Padding before symmetric encryption is done wrong in the code and
probably only works via gcrypt doing its own padding on top.

 f. Padding is achieved with 0 bytes if the length of the data is less
than the block length. See
http://en.wikipedia.org/wiki/Padding_%28cryptography%29#Zero_padding. The
size of the original data is appended to the data. The data is then
encrypted. See CBC and CTS.


- The way symmetric keys are passed in and out of the RSA algorithm
looks fishy and may be badly broken, though a thorough knowledge
of gcrypt and Qt is needed to figure out exactly what is going on.

 Yah, get familiar with libgcrypt and RSA and Qt.
 j. Clearly you don't understand the product.


- It looks like different message parts are encrypted separately.
- It is unclear how often symmetric keys are being changed (once
per line, once per message, once per user changing their password,
never).

 g. Symmetric keys are generated per message.

- The way passwords + salt are used for the keyed hash looks like
the crucial key derivation step/anticracking step is missing or
buried inside gcrypt defaults.

 l. The data is intended to mimic HTTP traffic. SSL is non-essential.
Participants communicate with approved keys. If SSL is available, then it's
used. Regardless, the data is encrypted separated outside of the scope of
SSL.


- The fact that messages are not forwarded after being recognized
by their recipient allows spies to trace them (traffic analysis) by
seeing where they enter and leave the network, thus nullifying the
whole point of cryptographically hiding the destination.


 k. Yes, message types are clearly visible. Simple to resolve. I suppose
you'd like your e-mail headers encrypted.

- Lots of message attributes are visible because too much happens
outside the encrypted envelope.

- Base64 encoding is not necessary, wastes bandwidth and increases
the potential for cryptanalysis against the SSL tunneling, if used.

 l. The data is intended to mimic HTTP 

[openssl.org #3095] Incorrect result in HMAC functions when key is null

[Jake Thomas Petroules via RT]

Hello,

I've discovered a bug in OpenSSL HMAC handling -- when calling the HMAC() 
(http://www.openssl.org/docs/crypto/hmac.html) function, an incorrect result 
will be given if the `key` parameter is a NULL pointer, even when `key_len` is 
zero. Much easier to notice when you're not using null terminated 
strings/buffers. I would expect that the value of `key` would have no effect if 
`key_len` is 0 (CommonCrypto handles this fine). I have attached an example 
program demonstrating the problem.

Please post the eventual bug tracker link on the mailing list if possible.

Thanks,
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com


Hello,I've discovered a bug in OpenSSL HMAC handling -- when calling the HMAC()(http://www.openssl.org/docs/crypto/hmac.html) function, an incorrect result will be given if the `key` parameter is a NULL pointer, even when `key_len` is zero. Much easier to notice when you're not using null terminated strings/buffers. I would expect that the value of `key` would have no effect if `key_len` is 0 (CommonCrypto handles this fine). I have attached an example program demonstrating the problem.Please post the eventual bug tracker link on the mailing list if possible.Thanks,
--Jake PetroulesChief Technology OfficerPetroules Corporation ·www.petroules.comEmail:jake.petrou...@petroules.com

openssl-hmac-bug.c
Description: Binary data

Re: [openssl.org #3095] Incorrect result in HMAC functions when key is null

[Jake Thomas Petroules via RT]

After reviewing the documentation I see this behavior mentioned - easy to miss.
However I'd argue that this behavior is wrong, given that there is no context to
potentially re-use with the single shot function.

Wouldn't it make more sense to simply treat a NULL pointer to key the same as
passing a valid pointer, when key_len is 0, for the single-shot function?
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Jul 26, 2013, at 8:46 AM, Stephen Henson via RT r...@openssl.org wrote:

 On Fri Jul 26 09:26:23 2013, jake.petrou...@petroules.com wrote:
 Hello,
 
 I've discovered a bug in OpenSSL HMAC handling -- when calling the
 HMAC() (http://www.openssl.org/docs/crypto/hmac.html) function, an
 incorrect result will be given if the `key` parameter is a NULL
 pointer, even when `key_len` is zero. Much easier to notice when
 you're not using null terminated strings/buffers. I would expect
 that the value of `key` would have no effect if `key_len` is 0
 (CommonCrypto handles this fine). I have attached an example
 program demonstrating the problem.
 
 
 Passing NULL as the key has a special meaning to the OpenSSL APIs: it reuses
 the existing HMAC key for the context. If there is no HMAC key previously set
 the result is undefined. If you really want to use a zero length key set
 key_len to zero and key to non-NULL.
 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: [openssl.org #3095] Incorrect result in HMAC functions when key is null

[Jake Thomas Petroules]

After reviewing the documentation I see this behavior mentioned - easy to miss.
However I'd argue that this behavior is wrong, given that there is no context to
potentially re-use with the single shot function.

Wouldn't it make more sense to simply treat a NULL pointer to key the same as
passing a valid pointer, when key_len is 0, for the single-shot function?
-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petrou...@petroules.com

On Jul 26, 2013, at 8:46 AM, Stephen Henson via RT r...@openssl.org wrote:

 On Fri Jul 26 09:26:23 2013, jake.petrou...@petroules.com wrote:
 Hello,
 
 I've discovered a bug in OpenSSL HMAC handling -- when calling the
 HMAC() (http://www.openssl.org/docs/crypto/hmac.html) function, an
 incorrect result will be given if the `key` parameter is a NULL
 pointer, even when `key_len` is zero. Much easier to notice when
 you're not using null terminated strings/buffers. I would expect
 that the value of `key` would have no effect if `key_len` is 0
 (CommonCrypto handles this fine). I have attached an example
 program demonstrating the problem.
 
 
 Passing NULL as the key has a special meaning to the OpenSSL APIs: it reuses
 the existing HMAC key for the context. If there is no HMAC key previously set
 the result is undefined. If you really want to use a zero length key set
 key_len to zero and key to non-NULL.
 
 Steve.
 --
 Dr Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org

[openssl.org #3014] bug report: 1.0.1e - Linux/OSX/Windows/All? - CRL validation fails with unknown CRL critical extension

[Thomas Harning via RT]

When attempting to validate certificates using a CRL with the X509_verify_cert 
setup, it fails w/ the error code 36 - 
X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION

The extension in question is the AKID - Authority Key Identifier

The odd thing is - this extension IS indeed handled by x509_vfy - so it 
shouldn't be considered unhandled.

Our current workaround is to manually check for 'unknown' critical extensions 
and set the flag to ignore unknown CRL critical extensions.

Commit 010fa0b33169cfc9179bda29c34c05af80f78e27 (Thu Sep 21 08:42:15 2006) adds 
the check for unhandled critical extensions - however even at that point, the 
AKID was being honored (code committed in 
bc7535bc7fe30fbba222c316a3957da7d906603b Thu Sep 14 13:25:02 2006)

This code does not appear to be conditional to any platform, however it is 
being experience specifically on Windows (x86_64/x86), OSX 10.7 and 10.8 
(x86_64), Linux (x86_64)

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

[openssl.org #2929] Patch for recursive deadlock in x_pubkey.c [1.0.1c]

[Thomas Eckert via RT]

Originally found in 1.0.0j. Did not check versions between 1.0.0j and 
1.0.1c since it is still present in the current version.

I am also worried about lines 139-143:

139:if (key-pkey != NULL)
140:{
141:CRYPTO_add(key-pkey-references, 1, 
CRYPTO_LOCK_EVP_PKEY);
142:return key-pkey;
143:}

Assume thread 1 runs up to line 140 and some other thread does 
EVP_PKEY_free() on the key before thread 1 can get the lock starting in 
line 141. Am I overseeing some protection ?

Also note the same problem in lines 175-184:

175:CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY);
176:if (key-pkey)
177:{
178:EVP_KEY_free(ret);
179:ret = key-pkey;
180:}
181:else
182:key-pkey = ret;
183:CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY);
184:CRYPTO_add(ret-references, 1, CRYPTO_LOCK_EVP_PKEY);

Assume thread 1 goes up until and finishes line 183, then thread 2 does 
EVP_PKEY_free() on key.

I would have supplied patch suggestions for those places as well but I 
am not aware of an existing openssl technique of manipulating the 
reference counter *without* aquiring a lock, in case we already have a 
lock of the correct type.

Regards,
   Thomas

diff --git a/crypto/asn1/x_pubkey.c b/crypto/asn1/x_pubkey.c
index 627ec87..d8422ca 100644
--- a/crypto/asn1/x_pubkey.c
+++ b/crypto/asn1/x_pubkey.c
@@ -133,6 +133,7 @@ error:
 EVP_PKEY *X509_PUBKEY_get(X509_PUBKEY *key)
 	{
 	EVP_PKEY *ret=NULL;
+	EVP_PKEY *pktmp=NULL;
 
 	if (key == NULL) goto error;
 
@@ -175,7 +176,7 @@ EVP_PKEY *X509_PUBKEY_get(X509_PUBKEY *key)
 	CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY);
 	if (key-pkey)
 		{
-		EVP_PKEY_free(ret);
+		pktmp=ret;
 		ret = key-pkey;
 		}
 	else
@@ -183,6 +184,8 @@ EVP_PKEY *X509_PUBKEY_get(X509_PUBKEY *key)
 	CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY);
 	CRYPTO_add(ret-references, 1, CRYPTO_LOCK_EVP_PKEY);
 
+	if (pktmp)
+		EVP_KEY_free(pktmp);
 	return ret;
 
 	error:

Re: [openssl.org #2803] bug report: OCSP_basic_verify may return incorrect value

[Thomas Eckert]

On 11/29/2012 08:18 PM, Stephen Henson via RT wrote:

Thanks for the report, I've applied a fix.

I've not applied the second part of the patch because then the return
variable ret is set to the return value of X509_verify_cert() which is
intentional.

Steve.
Hi and thanks for the fast reply. Would you please elaborate a bit on 
what you refer to as 'second part' and 'ret = x509_verify_cert()' ? I 
can't quite follow you there and it is important for me to understand it 
because I have to deploy a patch to a customer machine ASAP. So if there 
are side effects to the patch I suggested in in the attachment of the 
bug report please let me know. Your work is very much appreciated ! :-)


Regards,
  Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Possible race condition for pkey

[Thomas Eckert]

Hi guys,

I'm trying to find the source of a deadlock issue concerning apache 
(2.2.22 with APR-1.4.6) and openssl-1.0.0j. From what I can see I have 
the exact same situation as in 
https://issues.apache.org/bugzilla/show_bug.cgi?id=53870 but the patch 
referenced there (http://cvs.openssl.org/chngview?cn=22570) only fixed a 
part of the deadlock cases. I was able to confirm it did help using gdb 
but as I said it only helped to fix some of the deadlocks.


There are still hundreds of threads trying to aquire a 
CRYPTO_LOCK_EVP_PKEY lock and getting stuck on it because someone is 
never releasing it. I searched the openssl source for places where such 
a type of lock is used and stumbled onto this here


openssl-1.0.1c/crypto/asn1/x_pubkey.c (+175)
/* Check to see if another thread set key-pkey first */
CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY);
if (key-pkey)
{
EVP_PKEY_free(ret);
ret = key-pkey;
}
else
key-pkey = ret;
CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY);
CRYPTO_add(ret-references, 1, CRYPTO_LOCK_EVP_PKEY);

Isn't this a bit risky ? What if this code is interrupted just before 
executing the last line of the snippet above and then some other thread 
does


CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY);
EVP_PKEY_free(key-pkey);
CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY);

I suggest doing
/* Check to see if another thread set key-pkey first */
int alrdy_set = 0;
CRYPTO_add(ret-references, 1, CRYPTO_LOCK_EVP_PKEY);
CRYPTO_w_lock(CRYPTO_LOCK_EVP_PKEY);
if (key-pkey)
{
EVP_PKEY_free(ret);
ret = key-pkey;
alrdy_set=1;
}
else
key-pkey = ret;
CRYPTO_w_unlock(CRYPTO_LOCK_EVP_PKEY);
if (!alrdy_set)
CRYPTO_add(ret-references, -1, CRYPTO_LOCK_EVP_PKEY);

Regards,
  Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: winrt random

[Thomas Francis, Jr.]

 -Original Message-
 From: owner-openssl-...@openssl.org [mailto:owner-openssl-
 d...@openssl.org] On Behalf Of Andy Polyakov
 Sent: Wednesday, September 19, 2012 4:52 PM
 To: openssl-dev@openssl.org
 Subject: Re: winrt random
 
  I've been porting openssl to run on winrt(metro).
 
 What does it mean more specifically? Even though some assert that WinRT
 is totally independent framework directly on top of NT Kernel Services,
 it doesn't seem to hold true. The only things that prevents WinRT
 programmer from calling any particular function, be it Win32, User32,
 MSCRT or any other interface, is *declaration* of the function of
 interest. Microsoft has hidden most of Win32 and alike in #if !METRO in
 its headers, but it doesn't mean that functions won't work if you call
 them. For example, you *can* call MessageBox from Metro application if
 you declare it yourself and explicitly link with user32.lib. It makes
 lesser sense to do so, because you have to switch to desktop in order
 to interact with dialog, but it *is* possible. Which means that WinRT
 is
 *not* independent framework running on top of NT Kernel Services.

That's not true, at least if you're using the VS 2012 compiler.  There's
more than a simple #if in the headers; there are a number of #pragmas that
affect link time, too.  Additionally, those functions are not available for
ARM processors at all (some might be, but OpenSSL uses some that are not --
I speak not from a guess, but actually trying it).

Additionally, if you're an ISV, you care greatly about being able to pass
the validation tests, even if you don't want to sell it through MS's store
(which you can't do if it doesn't pass the validation tests).

Several larger consumers of Windows even require their in-house software to
meet the same set of requirements, which would mean several non-ISVs can't
use OpenSSL without some changes (sorry, NDA says I can't name any of the
ones I personally know about).

 Well,
 there is extra limitation, namely WinRT applications are commonly
 started with lower integrity level, which impedes the application, but
 there is no super special WinRT magic.

Only if you don't consider MS's various #pragmas to be magic.  I do. :)
Very, very evil magic. :)  Of course, some of my colleagues love the ones I
dislike. :)

 Is there anything preventing
 WinRT application developer from including OpenSSL headers and linking
 with OpenSSL libraries compiled the usual way?

Yes -- such an application will not pass the validation tests.  Such an
application won't link for ARM at all (it should be noted that OpenSSL won't
compile for ARM without some changes, like faking prototypes, anyway).  And
yes, I've tried it.  It does not work.

 I can't think of any
 (modulo potential side effects caused by lower integrity level). And
 having said that, let's go back to original question, what does
 porting openssl to run on winrt mean?

I would think porting openssl to run on winrt means ensuring that OpenSSL
doesn't use any of the disallowed functions, and that applications which
link OpenSSL libraries can successfully pass the validation tests (can not
will -- there's nothing the OpenSSL team can do about failures not
directly related to OpenSSL :) ).

 Is it actually necessary?

Absolutely -- unless you're working on a project that's only for x86/x64 and
only for uses that don't have requirements for passing validation tests.
I'd be very surprised if that will describe the majority of cases where
OpenSSL would be very useful on Windows.

 Wouldn't making standard build work with lower integrity level be
 more sensible thing to do? Perhaps detecting that application is WinRT
 and acting accordingly (e.g. abstaining from calling MessageBox and
 instead logging fatal failures to even log)?

The validation tests don't check what's actually called at runtime, but
what's linked into the application, so as long as there's a reference to
MessageBox, for example, the validation tests will fail (of course, if you
compile in such a way the compiler can eliminate the reference for you,
it'll be OK).

 Eliminating dependency on
 MSCRT is even more sensible, and not only in WinRT context [though it
 can't be done in 1.0.x].

There's no need to do that in a WinRT context -- the C runtime in general is
allowed to be used, you're just extremely limited on what you can call from
the runtime. :)

TOM


smime.p7s
Description: S/MIME cryptographic signature

RE: Compile OpenSSL 64-bit Windows 7

[Thomas Francis, Jr.]

 -Original Message-
 From: owner-openssl-...@openssl.org [mailto:owner-openssl-
 d...@openssl.org] On Behalf Of JTrades52
 Sent: Friday, July 13, 2012 11:57 AM
 To: openssl-dev@openssl.org
 Subject: Compile OpenSSL 64-bit Windows 7
 
 
 I'm working on Windows 7 (64bit) using to compile a 64-bit version of
 OpenSSL.  I followed the INSTALL.W64 instructions (with a few
 modifications) to accomplish this:
 
  cd C:\openssl-1.0.1c
 
  vsvars64.bat
 
  perl Configure VC-WIN64A no-asm --prefix=c:\temp\openssl
 
  ms\do_win64a
 
  nmake -f ms\ntdll.mak
 However, I have the following problems:
 
 * The code is still written to the out32 folder. I need to be able to
 link to both 32-bit and 64-bit versions of the library.  Is there a way
 to have them placed in separate folders (32/64)?  Also, Is there a way
 to change ssleay32.lib/dll and libeay32.lib/dll to ssleay64.lib/dll and
 libeay64.lib/dll.

I usually either nmake -f ms\ntdll.mak install and set each to install to a 
different directory. Or after compiling, copy the outXXX directory to some 
other location.  However, you should see the output in out64a, not out32 -- I 
recommend removing the old directory and re-extracting the source code.  That's 
how I do it, anyway, and the right output directories are always used.

Additionally, you can rename the .lib and .dll files however you want, or 
modify ms\ntdll.mak if you prefer.

 * Everything seems to compile OK, but when I run the program, Windows
 displays the following error - not a valid Win32 application.  Does
 this mean that the libs generated are still 32-bit?

That would suggest that either it didn't compile OK, or you're trying to run a 
64-bit binary on 32-bit Windows (64-bit windows can run 32-bit binaries just 
fine).  Also, are you seeing the error for openssl.exe or for one of your own 
programs?  If the latter, try openssl.exe to double-check if it compiled OK.  
If the former, and if you're able to run 64-bit binaries, it didn't compile 
properly.

 Any suggestions are appreciated.  I really need a 64-bit version for my
 program to compile correctly.  Thanks.
 
 JTrades.
 --
 View this message in context: http://old.nabble.com/Compile-OpenSSL-64-
 bit-Windows-7-tp34157175p34157175.html
 Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Buggy RC4 on x86-64 (Mac OS X)

[Thomas Davie]

Hi all,

I'm having some issues with a hand-built OpenSSL 1.0.0d (patched with the SRP 
patch available at http://srp.stanford.edu/) on x86-64.  I hope that the -dev 
list is the right place to go to with this issue, it wasn't clear on whether 
here or the user list was the right place, so feel free to tell me to bugger 
off.

The issue I'm hitting is that RC4_set_key seems to be writing over more than 
258 (sizeof(RC4_KEY)) bytes.  This does not occur when compiling for i386, so 
it looks like being a bug in the x86_64 assembly in crypto/rc4/asm.

What I'm after is two things really:
1) confirmation that I'm not doing something idiotic here (or information on 
what idiotic thing I am doing).
2) if I'm really not being an idiot, could you tell me whether this should have 
been fixed in later OpenSSL builds, before I start working through decoding 
what the SRP patch actually changes and applying it to a later version of 
OpenSSL.

Thanks

Tom Davie

if (*ra4 != 0xffc78948) { return false; }

[openssl.org #2586] [PATCH 1/4] Fix bracket imbalance if __cplusplus is defined

[Thomas Jarosch via RT]

Applies to 1.0.1 and HEAD. Credit goes to cppcheck.

Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
 engines/e_capi_err.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/engines/e_capi_err.h b/engines/e_capi_err.h
index 4c749ec..efa7001 100644
--- a/engines/e_capi_err.h
+++ b/engines/e_capi_err.h
@@ -55,6 +55,10 @@
 #ifndef HEADER_CAPI_ERR_H
 #define HEADER_CAPI_ERR_H
 
+#ifdef  __cplusplus
+extern C {
+#endif
+
 /* BEGIN ERROR CODES */
 /* The following lines are auto generated by the script mkerr.pl. Any changes
  * made after this point may be overwritten when the script is next run.
-- 
1.7.4.4

From 0aeeb87f16b25fd5b232634702eb7e16dacc40a2 Mon Sep 17 00:00:00 2001
From: Thomas Jarosch thomas.jaro...@intra2net.com
Date: Sun, 28 Aug 2011 01:45:25 +0200
Subject: [PATCH 1/4] Fix bracket imbalance if __cplusplus is defined

Applies to 1.0.1 and HEAD. Credit goes to cppcheck.

Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
 engines/e_capi_err.h |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/engines/e_capi_err.h b/engines/e_capi_err.h
index 4c749ec..efa7001 100644
--- a/engines/e_capi_err.h
+++ b/engines/e_capi_err.h
@@ -55,6 +55,10 @@
 #ifndef HEADER_CAPI_ERR_H
 #define HEADER_CAPI_ERR_H
 
+#ifdef  __cplusplus
+extern C {
+#endif
+
 /* BEGIN ERROR CODES */
 /* The following lines are auto generated by the script mkerr.pl. Any changes
  * made after this point may be overwritten when the script is next run.
-- 
1.7.4.4

[openssl.org #2587] [PATCH 2/4] Don't play games with the struct layout

[Thomas Jarosch via RT]

Applies to 1.0.1 and HEAD. Issue detected by cppcheck.

Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
 engines/ccgost/gost_crypt.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/engines/ccgost/gost_crypt.c b/engines/ccgost/gost_crypt.c
index 4977d1d..cde58c0 100644
--- a/engines/ccgost/gost_crypt.c
+++ b/engines/ccgost/gost_crypt.c
@@ -495,7 +495,8 @@ int  gost89_get_asn1_parameters(EVP_CIPHER_CTX 
*ctx,ASN1_TYPE *params)
 int gost_imit_init_cpa(EVP_MD_CTX *ctx)
{
struct ossl_gost_imit_ctx *c = ctx-md_data;
-   memset(c-buffer,0,16);
+   memset(c-buffer,0,sizeof(c-buffer));
+   memset(c-partial_block,0,sizeof(c-partial_block));
c-count = 0;
c-bytes_left=0;
c-key_meshing=1;
-- 
1.7.4.4

From 23aa91bd3df6f783bf048bdd4a0933d8a3ce019e Mon Sep 17 00:00:00 2001
From: Thomas Jarosch thomas.jaro...@intra2net.com
Date: Sun, 28 Aug 2011 01:51:12 +0200
Subject: [PATCH 2/4] Don't play games with the struct layout

Applies to 1.0.1 and HEAD. Issue detected by cppcheck.

Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
 engines/ccgost/gost_crypt.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/engines/ccgost/gost_crypt.c b/engines/ccgost/gost_crypt.c
index 4977d1d..cde58c0 100644
--- a/engines/ccgost/gost_crypt.c
+++ b/engines/ccgost/gost_crypt.c
@@ -495,7 +495,8 @@ int  gost89_get_asn1_parameters(EVP_CIPHER_CTX *ctx,ASN1_TYPE *params)
 int gost_imit_init_cpa(EVP_MD_CTX *ctx)
 	{
 	struct ossl_gost_imit_ctx *c = ctx-md_data;
-	memset(c-buffer,0,16);
+	memset(c-buffer,0,sizeof(c-buffer));
+	memset(c-partial_block,0,sizeof(c-partial_block));
 	c-count = 0;
 	c-bytes_left=0;
 	c-key_meshing=1;
-- 
1.7.4.4

[openssl.org #2588] [PATCH 3/4] Do proper cleanup: Close file descriptor

[Thomas Jarosch via RT]

Applies to 1.0.1 and HEAD.

Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
 crypto/evp/evp_test.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/crypto/evp/evp_test.c b/crypto/evp/evp_test.c
index 902efac..55c7cdf 100644
--- a/crypto/evp/evp_test.c
+++ b/crypto/evp/evp_test.c
@@ -435,6 +435,7 @@ int main(int argc,char **argv)
EXIT(3);
}
}
+   fclose(f);
 
 #ifndef OPENSSL_NO_ENGINE
 ENGINE_cleanup();
-- 
1.7.4.4

From 6e1b8ce4fa4e9d31cae6e87326d4bc348852eab8 Mon Sep 17 00:00:00 2001
From: Thomas Jarosch thomas.jaro...@intra2net.com
Date: Sun, 28 Aug 2011 01:55:24 +0200
Subject: [PATCH 3/4] Do proper cleanup: Close file descriptor

Applies to 1.0.1 and HEAD.

Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
 crypto/evp/evp_test.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/crypto/evp/evp_test.c b/crypto/evp/evp_test.c
index 902efac..55c7cdf 100644
--- a/crypto/evp/evp_test.c
+++ b/crypto/evp/evp_test.c
@@ -435,6 +435,7 @@ int main(int argc,char **argv)
 	EXIT(3);
 	}
 	}
+	fclose(f);
 
 #ifndef OPENSSL_NO_ENGINE
 ENGINE_cleanup();
-- 
1.7.4.4

[openssl.org #2589] [PATCH 4/4] Always initialize pointer. Otherwise we might crash in goto err;.

[Thomas Jarosch via RT]

Applies to 1.0.1 and HEAD. Credit goes to cppcheck.

Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
 crypto/dso/dso_vms.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/crypto/dso/dso_vms.c b/crypto/dso/dso_vms.c
index 45adfb1..eee20d1 100644
--- a/crypto/dso/dso_vms.c
+++ b/crypto/dso/dso_vms.c
@@ -160,7 +160,7 @@ static int vms_load(DSO *dso)
 # define DSO_MALLOC OPENSSL_malloc
 #endif /* __INITIAL_POINTER_SIZE == 64 [else] */
 
-   DSO_VMS_INTERNAL *p;
+   DSO_VMS_INTERNAL *p = NULL;
 
 #if __INITIAL_POINTER_SIZE == 64
 # pragma pointer_size restore
-- 
1.7.4.4

From 3b4e8dd7c53c5e67ecd277b5787be3d8da37bb4d Mon Sep 17 00:00:00 2001
From: Thomas Jarosch thomas.jaro...@intra2net.com
Date: Sun, 28 Aug 2011 01:57:33 +0200
Subject: [PATCH 4/4] Always initialize pointer. Otherwise we might crash in
 goto err;.

Applies to 1.0.1 and HEAD. Credit goes to cppcheck.

Signed-off-by: Thomas Jarosch thomas.jaro...@intra2net.com
---
 crypto/dso/dso_vms.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/crypto/dso/dso_vms.c b/crypto/dso/dso_vms.c
index 45adfb1..eee20d1 100644
--- a/crypto/dso/dso_vms.c
+++ b/crypto/dso/dso_vms.c
@@ -160,7 +160,7 @@ static int vms_load(DSO *dso)
 # define DSO_MALLOC OPENSSL_malloc
 #endif /* __INITIAL_POINTER_SIZE == 64 [else] */
 
-	DSO_VMS_INTERNAL *p;
+	DSO_VMS_INTERNAL *p = NULL;
 
 #if __INITIAL_POINTER_SIZE == 64
 # pragma pointer_size restore
-- 
1.7.4.4

using weak primes during man-in-the-middle attack (CVE-2005-2643)

[Thomas Biege]

Hi,
is openssl vulnerable to the following issue:
http://polarssl.org/trac/wiki/SecurityAdvisory201101
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-2643
http://www.cl.cam.ac.uk/~rja14/Papers/psandqs.pdf

Bye
Thomas

-- 
Thomas Biege tho...@suse.de, SUSE LINUX, Security Support  Auditing
SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 
(AG Nürnberg
--
  Wer aufhoert besser werden zu wollen, hoert auf gut zu sein.
-- Marie von Ebner-Eschenbach
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Copy x509 extensions from X509 to X509_REQ

[Thomas Jarosch]

Hello,

the X509 request API of openssl 0.9.8r features
a function to get a stack of X509 extensions:

STACK_OF(X509_EXTENSION) *X509_REQ_get_extensions(X509_REQ *req);


Is there something similar like X509_get_extensions()?

Right now I access the extensions directly like this
(as seen in crypto/asn1/t_x509.c):

X509_CINF *ci = x-cert_info;
if (ci  ci-extensions)
{
X509_REQ_add_extensions(x_req, ci-extensions);
}


Is there a recommended way / API safe way to do this?

Thanks in advance,
Thomas Jarosch
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #2355] Support for SHA2 ciphersuite in TLS

[Thomas Francis, Jr.]

That's a rather old statement.  The latest draft of SP 800-131 
(http://csrc.nist.gov/publications/drafts/800-131/draft-sp800-131_spd-june2010.pdf)
 is a _lot_ more relaxed, and even the early draft referenced at the page below 
did not require any changes that would require TLS v1.2.  Applications built on 
OpenSSL should no longer use SHA-1 (or 1024-bit or smaller RSA keys or 2-key 
3DES) for digital signatures (or general encryption).  Since OpenSSL supports 
the algorithms suggested for replacement at the end of 2010, application 
vendors should be able to provide government agencies with newer software that 
avoids the algorithms that NIST (and OMB?) are saying should be avoided.  It 
should be noted that the latest draft of SP 800-131 allows continued use of 
those algorithms until 2013 (or 2015 for encryption), so vendors are not 
required to provide updates before the end of this year.

There's some fuzziness* with regards to RNGs in OpenSSL, and if they are fully 
compatible with the current guidance from NIST or not, but again, you have 
until 2015 to replace RNGs.

I hope this helps to clarify priorities a little bit.

TOM

* The fuzziness is only in that I've seen a couple of queries about which, if 
any, of the RNGs in OpenSSL are compliant (compatible?) with NIST SP 800-90 or 
ANSI X9.62-2005, and haven't seen any responses.  If someone can clarify that, 
I'd certainly appreciate it.  If not, I'll end up doing the research myself 
sometime prior to 2015, as we're one of those application vendors I mention 
above. :)

 -Original Message-
 From: owner-openssl-...@openssl.org [mailto:owner-openssl-
 d...@openssl.org] On Behalf Of Sasha Matison via RT
 Sent: Monday, October 04, 2010 4:22 AM
 Cc: openssl-dev@openssl.org
 Subject: [openssl.org #2355] Support for SHA2 ciphersuite in TLS
 
 Hello,
 
 
 
 What is the current plan to support TLSv1.2 in OpenSSL? NIST issued a
 statement requiring federal government to switch to SHA2 family of hash
 functions after 2010:
 
 
 
 Quote from http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html:
 
 
 
 Federal agencies should stop using SHA-1 for digital signatures,
 digital time stamping and other applications that require collision
 resistance as soon as practical, and must use the SHA-2 family of hash
 functions for these applications after 2010.
 
 
 
 Regards,
 
 
 
 Sasha Matison
 ca
 Manager, Software Engineering
 Tel:  +1-508-628-8379
 Mobile: +1-508-395-6958
 sasha.mati...@ca.com
 mailto:roger.alix-gaudr...@ca.com   http://www.ca.com/
 
 
 

:��IϮ��r�m
(Z+�7�zZ)���1���x��hW^��^��%����jם.+-1�ځ��j:+v���h�

[openssl.org #2267] Thread-safety issue: build_SYS_str_reasons() calls strerror()

[Thomas Sondergaard via RT]

It should call strerror_r() instead on platforms that have it.

I experience crashes in an application that start database transactions 
in one thread, while extensions are being dlopened in another thread. 
When the database library is initialized ERR_load_ERR_strings() is 
called. In the extension-loading thread dlerror() is called if an 
extension fails to load. dlerror() unfortunately calls strerror() in glibc.

Regards,

Thomas Sondergaard

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

openssl 0.9.8n issue with no-tlsext

[Thomas Jarosch]

Hello,

after updating from openssl 0.9.8l to openssl 0.9.8n,
I'm unable to connect to a TLS enabled SMTP server:

./openssl s_client -connect smtp.scriptroom.net:25 -starttls smtp -debug

28141:error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad packet 
length:s3_clnt.c:878:

openssl is compiled with the no-tlsext option. no-tlsext was added back
in 2009 as openssl 0.9.8j had trouble connecting to a Centos 3 based server.
(http://marc.info/?l=openssl-devm=123192990505188)

openssl-0.9.8m is also affected. Any idea what might be going on?

Thanks in advance,
Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: openssl 0.9.8n issue with no-tlsext

[Thomas Jarosch]

Hello,

On Tuesday, 30. March 2010 15:51:31 Bodo Moeller wrote:
 So client-side OpenSSL is buggy if compiled with no-tlsext (in 0.9.8m
 and 0.9.8n) because it sends that pseudo-ciphersuite number without
 being able to handle the TLS extension then expected in the server's
 response.  So the no-tlsext build shouldn't be sending the pseudo-
 ciphersuite number.  However, then you'd soon have problems connecting
 to some updated servers, as these may start to *demand* confirmation
 that clients are updated to support RFC 5746.  So the fix won't help
 you in the long run.

Thanks for your explanation. I could remove the no-tlsext option as the 
servers under our control haven been upgraded from Centos 3 to Centos 5.

I'm just thinking what might happen if f.e. a TLS enabled postfix
connects to an old Centos 3 based server to deliver emails.
Guess that would fail like in 2009, wouldn't it?

Cheers,
Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: openssl 0.9.8n issue with no-tlsext

[Thomas Jarosch]

On Tuesday, 30. March 2010 16:01:54 Thomas Jarosch wrote:
 I'm just thinking what might happen if f.e. a TLS enabled postfix
 connects to an old Centos 3 based server to deliver emails.
 Guess that would fail like in 2009, wouldn't it?

Just rechecked the issue from 2009
(http://marc.info/?l=openssl-devm=123192990505188) and it was related
to SSLv3 and not to TLS. So this could work out fine IMHO.

Cheers,
Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

when does RAND_pseudo_bytes() return 0?

[Thomas Anderson]

According to http://www.openssl.org/docs/crypto/RAND_bytes.html,
RAND_bytes() returns 1 on success, 0 otherwise. The error code can be
obtained by ERR_get_error(3). RAND_pseudo_bytes() returns 1 if the
bytes generated are cryptographically strong, 0 otherwise. Both
functions return -1 if they are not supported by the current RAND
method. 

From http://cvs.openssl.org/fileview?f=openssl/crypto/rand/
rand_lib.cv=1.20:

int RAND_pseudo_bytes(unsigned char *buf, int num)
{
const RAND_METHOD *meth = RAND_get_rand_method();
if (meth  meth-pseudorand)
return meth-pseudorand(buf,num);
return(-1);
}

Where is pseudorand defined?  I figured maybe each of the rand_win.c,
rand_unix.c, etc, would define it, but the string pseudorand doesn't
appear to occur in any of those files.

Any ideas?
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: when does RAND_pseudo_bytes() return 0?

[Thomas Anderson]

ssleay_rand_pseudo_bytes():

/* pseudo-random bytes that are guaranteed to be unique but not
   unpredictable */
static int ssleay_rand_pseudo_bytes(unsigned char *buf, int num)
{
int ret;
unsigned long err;

ret = RAND_bytes(buf, num);
if (ret == 0)
{
err = ERR_peek_error();
if (ERR_GET_LIB(err) == ERR_LIB_RAND 
ERR_GET_REASON(err) == RAND_R_PRNG_NOT_SEEDED)
ERR_clear_error();
}
return (ret);
}

RAND_bytes():

int RAND_bytes(unsigned char *buf, int num)
   {
   const RAND_METHOD *meth = RAND_get_rand_method();
   if (meth  meth-bytes)
  return meth-bytes(buf,num);
   return(-1);
   }

So, basically, if no engine is being used, then RAND_pseudo_bytes()
will only ever return cryptographically strong random bytes or no
bytes at all?  If that's correct then are there any engines that
behave differently?  That can return random bytes that aren't
cryptographically strong?

On Wed, Feb 17, 2010 at 5:20 PM, Mounir IDRASSI
mounir.idra...@idrix.net wrote:
 Hi,

 If you are not using an engine, then pseudorand is implemented in md_rand.c
 : function ssleay_rand_pseudo_bytes (line 524).

 Cheers,

 --
 Mounir IDRASSI
 IDRIX
 http://www.idrix.fr


 On 2/17/2010 8:10 PM, Thomas Anderson wrote:

 According tohttp://www.openssl.org/docs/crypto/RAND_bytes.html,
 RAND_bytes() returns 1 on success, 0 otherwise. The error code can be
 obtained by ERR_get_error(3). RAND_pseudo_bytes() returns 1 if the
 bytes generated are cryptographically strong, 0 otherwise. Both
 functions return -1 if they are not supported by the current RAND
 method. 

 Fromhttp://cvs.openssl.org/fileview?f=openssl/crypto/rand/
 rand_lib.cv=1.20:

 int RAND_pseudo_bytes(unsigned char *buf, int num)
         {
         const RAND_METHOD *meth = RAND_get_rand_method();
         if (meth  meth-pseudorand)
                 return meth-pseudorand(buf,num);
         return(-1);
         }

 Where is pseudorand defined?  I figured maybe each of the rand_win.c,
 rand_unix.c, etc, would define it, but the string pseudorand doesn't
 appear to occur in any of those files.

 Any ideas?
 __
 OpenSSL Project                                 http://www.openssl.org
 Development Mailing List                       openssl-dev@openssl.org
 Automated List Manager                           majord...@openssl.org


 --
 --
 Mounir IDRASSI
 IDRIX
 http://www.idrix.fr

 __
 OpenSSL Project                                 http://www.openssl.org
 Development Mailing List                       openssl-dev@openssl.org
 Automated List Manager                           majord...@openssl.org

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: how to create an already revoked certificate?

[Thomas Francis, Jr.]

The CRL identifies certificates by serial number only; the issuer is
implied.  You cannot have a CRL that revokes certificates from more than one
issuing certificate.  The only parameter from a certificate to determine if
it is revoked is the serial number. However, it's important to note that a
certificate can only be revoked by a CRL that has the same issuer.  Two
certificates issued by different CAs can have the same serial number.  A CRL
from CA1 can only revoke the certificate from CA1; it cannot revoke a
certificate from CA2, even if both certificates have the same serial number.

Given that you're controlling the CA, I suppose the method you list below
could work, but you'll also need to remove the original certificate from the
.index file and from the .certs directory that OpenSSL creates to manage the
CA. Failure to do that will result in OpenSSL giving an error message.

If the goal is to have a CRL whose lastUpdate is before the notBefore
parameter on one of the certificates it revokes, I would recommend instead
to set the clock backwards, and then generate a new CRL.  I would be
surprised if OpenSSL checks the current date against the dates on the
certificate(s) that are revoked.

 -Original Message-
 From: owner-openssl-...@openssl.org [mailto:owner-openssl-
 d...@openssl.org] On Behalf Of Al
 Sent: Wednesday, November 18, 2009 9:12 AM
 To: dave.thomp...@princetonpayments.com
 Cc: openssl-dev@openssl.org
 Subject: RE: how to create an already revoked certificate?
 
 Thanks for the reply,
I have control of the CA in creating certificates. The CRL contains
 the SN of the certs that are revoked. I also noticed we have an SRL
 file which shows the last SN used for the certificates and it
 increments by 1 for every certificate created. You said:
 Having the same serial on CA2 as on CA1 is totally irrelevant.
 Does that mean the CRL goes by more than the SN? I was thinking of
 doing this:
  edit the SRL and replace it with the SN of the revoked cert, after
 using it i revert back to the correct SN pattern.
 
 If the CRL does need to have a perfect match to treat the created cert
 as a revoked cert do i need to create a perfect replication in terms
 of all input parameters or the CRL will be smart enough to know they
 are still different?
 
 thanks
 
 
 
 --- On Tue, 11/17/09, Dave Thompson
 dave.thomp...@princetonpayments.com wrote:
 
  From: Dave Thompson dave.thomp...@princetonpayments.com
  Subject: RE: how to create an already revoked certificate?
  To: openssl-dev@openssl.org
  Date: Tuesday, November 17, 2009, 4:06 PM
   From: owner-openssl-...@openssl.org
  On Behalf Of Al
   Sent: Monday, 16 November, 2009 15:40
 
   I am trying to create a certificate that is already
  revoked
   (for testing purposes). I noticed the CRL has the SNs
  of the
   certificates and i am wondering if i could set the SN
  to
 
  Yes, certs are identified for many purposes, including
  revocation on a CRL, by serial within CA.
 
   revoked cert SNs during new certificate creation?
  
  This is not entirely clear; I assume you mean create a new
  cert
  with a serial that is already on a CRL issued by the (same)
  CA.
  (You can't change the serial on an issued cert; it's part
  of the
  signed content. You legally could create/issue a new cert,
 
  with new CA/serial, and all other contents the same as an
  existing cert, even validity. But it's usual to redo the
  validity.
  Having the same serial on CA2 as on CA1 is totally
  irrelevant.)
 
  If you control the CA, maybe; it depends on what the CA
  software
  does. A CA is not SUPPOSED to ever issue different certs
  with
  the same serial, but you may be able to override or fake
  yours.
  openssl ca|x509(ca)depend on text files you can clobber;
  openssl req(self)|x509(self) obey the command line.
 
  If you do create two (or more) certs with the same serial,
  and
  both (or multiple) of them are ever present in any
  environment,
  you have a very good chance of creating chaos. The purpose
  of
  the serial is to uniquely identify the cert within a given
  CA,
  and lots of software assumes this. If there are two
  different
  certs with the same serial for the same CA, all kinds of
  things
  can go wrong that you can spend months debugging.
 
  But if you control the CA, you should be able to easily
  issue
  a new CRL about as easily as you can issue a new cert.
 
  If you don't control the CA, and it is competently run, no.
  It
  will always create new certs with unique serials, as it
  should.
 
 
 
 
 __
  OpenSSL Project
 
       http://www.openssl.org
  Development Mailing List
               openssl-...@openssl.org
  Automated List Manager
 
     majord...@openssl.org
 
 
 
 
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   

[openssl.org #2104] BUG: OpenSSL 0.9.8l fails to build on x86_64 with binutils 2.20.51 [PATCH}

[Rothrock, Thomas SMDC SimCtr/GaN Corporation via RT]

On a CentOS 5.4 x86_64 system, OpenSSL 0.9.8l builds correctly under
binutils 2.17.50.  However, on the same system using binutils 2.20.51
the GNU assembler (as) generates errors in both MD5 and SHA1 assembly
code of the form:

md5-x86_64.s:41: Error: 0xd76aa478 out range of signed 32bit
displacement

sha1-x86_64.s:602: Error: 0x8f1bbcdc out range of signed 32bit
displacement

The GNU assembler appears to be interpreting the constants defined in
x86_64-specific assembly code generated by crypto/md5/asm/md5-x86_64.pl
and crypto/sha/asm/sha1-x86_64.pl as signed integers and thus outside
the range of the signed equivalent.  A workaround is to convert all the
constants to their signed equivalents.

A patch is attached.  With the patch applied, OpenSSL 0.9.8l builds and
passes make test on the x86_64 system under both binutils 2.17.50 and
binutils 2.20.51.

--Tom Rothrock





openssl-x86_64-bintuils-2.20.51.patch
Description: Binary data

SMIME headers incorrectly hardcoded to output 'micalg=sha1'

[Thomas Harning Jr.]

The SMIME generation code incorrectly hard-codes the 'micalg=sha1'
parameter.  This should be parametrized to use the proper
SMIME-specified algorithm name.

OpenSSL 0.9.8k
  crypto/pkcs7/pk7_mime.c
~~171-176 in SMIME_write_PKCS7
bound[32] = 0;
BIO_printf(bio, MIME-Version: 1.0%s, mime_eol);
BIO_printf(bio, Content-Type: multipart/signed;);
BIO_printf(bio,  protocol=\%ssignature\;, mime_prefix);
BIO_printf(bio,  micalg=sha1; boundary=\%s\%s%s,
bound, mime_eol, mime_eol);
BIO_printf(bio, This is an S/MIME signed message%s%s,
mime_eol, mime_eol);
OpenSSL 0.9.8 -
  crypto/pkcs7/pk7_smime.c
~~ 173-179 ... same code exactly

-- 
Thomas Harning Jr.
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

IA64 build Makefile error

[Rothrock, Thomas SMDC SimCtr/Madison Research Corp]

Hello.  I am building OpenSSL 0.9.8j from the source available at
http://www.openssl.org/source/openssl-0.9.8j.tar.gz on an IA64 linux
system.  During the build I encountered an error in crypto/sha/Makefile.
For the linux-ia64 build, the output of the perl scripts goes to stdout
instead of being redirected to the .s files.  I made the following
modification and afterwards it was able to build and test successfully:


# diff -Naur obj/crypto/sha/Makefile src/crypto/sha/Makefile
--- obj/crypto/sha/Makefile 2009-03-13 09:31:16.419968132 -0500
+++ src/crypto/sha/Makefile 2008-10-06 05:35:29.0 -0500
@@ -59,11 +59,11 @@
(cd asm; $(PERL) sha512-sse2.pl a.out $(CFLAGS) $(PROCESSOR) 
../$@)
 
 sha1-ia64.s:   asm/sha1-ia64.pl
-   (cd asm; $(PERL) sha1-ia64.pl ../$@ $(CFLAGS)  ../$@)
+   (cd asm; $(PERL) sha1-ia64.pl ../$@ $(CFLAGS))
 sha256-ia64.s: asm/sha512-ia64.pl
-   (cd asm; $(PERL) sha512-ia64.pl ../$@ $(CFLAGS)  ../$@)
+   (cd asm; $(PERL) sha512-ia64.pl ../$@ $(CFLAGS))
 sha512-ia64.s: asm/sha512-ia64.pl
-   (cd asm; $(PERL) sha512-ia64.pl ../$@ $(CFLAGS)  ../$@)
+   (cd asm; $(PERL) sha512-ia64.pl ../$@ $(CFLAGS))
 
 # Solaris make has to be explicitly told
 sha1-x86_64.s: asm/sha1-x86_64.pl; $(PERL) asm/sha1-x86_64.pl $@



  ---
   Tom Rothrock   tom.rothr...@us.army.mil
   US Army Space  Missile Defense Command Simulation Center
   256-955-3382 (DSN 645)   FAX 256-955-1231
   http://www.sc.army.mil Main SimCtr Phone:  256-955-3750
  ---
  This email capability is supported by Department of Defense
  systems and is subject to monitoring.  Please refrain from
  using this address for non-Government purposes.
  ---
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: FIPS_selftest_rng fails on Solaris10 x86

[Thomas Francis, Jr.]

I'm not convinced this is a problem with making a normal FIPS build,
though.  A while back, I compiled openssl-fips-1.2 following the
security policy, then compiled openssl-0.9.8j to make use of the fips
canister built from openssl-fips-1.2 (again, following the security
policy).  This was all on Solaris 10 for x86 (along with a bunch of
other systems).  The following is the code I just tested that build with
on Solaris 10 for x86:

--- Begin testfips.c ---
#include stdio.h
#include openssl/fips.h

int main(int argc, char **argv)
{
   if (FIPS_mode_set(1))
   {
  if (FIPS_selftest_rng())
 printf(FIPS_selftest_rng() OK\n;
   }
   return 0;
}
--- End testfips.c ---

I compiled it using the following command:

FIPSLD_CC=gcc fipsld -o testfips testfips.c -lcrypto -lnsl -lsocket

When I run the program, the output is:

FIPS_selftest_rng() OK

I have not tried to compile the fips canister using openssl-0.9.8j, so I
don't know if some change introduced between openssl-fips-1.2 and
openssl-0.9.8j might have introduced this error, but I can verify that
if one does follow the security policy, one gets a working version of
OpenSSL that can be successfully placed into FIPS mode, and all tests
will pass.  I should note that make test in the openssl-fips-1.2 tree
will FAIL on Solaris x86 (as it will on nearly every system I've
checked), but that's because the test programs don't compile.  Also, I
suspect you're not checking the return value of FIPS_mode_set(), as that
will invoke FIPS_selftest_rng(), as I recall.

I'm using gcc 4.1.1 on that system both for compiling OpenSSL and
compiling my test program.  I'm also doing 32-bit compiles, which is the
default for the gcc I have installed -- maybe that's a difference?

The fastest way to get something that works for FIPS is to just follow
the instructions in the user's guide (which is based on the security
policy).  Those instructions have worked for me every time on several
different UNIX platforms.

 -Original Message-
 From: owner-openssl-...@openssl.org 
 [mailto:owner-openssl-...@openssl.org] On Behalf Of RussMitch
 Sent: Thursday, February 12, 2009 1:25 PM
 To: openssl-dev@openssl.org
 Subject: FIPS_selftest_rng fails on Solaris10 x86
 
 
 Hello,
 
 I've built openssl-0.9.8j on Solaris10 Update 5 as follows:
 
 ./config fipscanisterbuild
 make clean
 make
 
 Next, I've created a simple program that calls 
 FIPS_mode_set(1) and links to the libraries in 
 /usr/local/ssl/fips/lib.
 
 The first two tests, FIPS_signature_witness() and
 FIPS_check_incore_fingerprint() PASS.
 
 The third test, FIPS_selftest_rng FAILS.
 
 I've also tried the exact same procedure on a Fedora Core5 
 linux based machine, and all of the tests PASS.
 
 Anyone have an idea of what may be wrong?
 
 /Russ
 --
 View this message in context: 
 http://www.nabble.com/FIPS_selftest_rng-fails-on-Solaris10-x86
-tp21980325p21980325.html
 Sent from the OpenSSL - Dev mailing list archive at Nabble.com.
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   majord...@openssl.org
 

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

openssl 0.9.8j ssl3 connect problem

[Thomas Jarosch]

Hello together,

I recently upgraded from openssl 0.9.8i to openssl 0.9.8j
and now I can't connect to our servers:

# openssl version
OpenSSL 0.9.8j 07 Jan 2009

# openssl s_client -ssl3 -connect www.intra2net.com:443
CONNECTED(0003)
31320:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake 
failure:s3_pkt.c:1060:SSL alert number 40
31320:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
failure:s3_pkt.c:530:

Same thing with a certificate using a private CA:
# openssl s_client -ssl3 -connect update.intranator.com:443
CONNECTED(0003)
31738:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake 
failure:s3_pkt.c:1060:SSL alert number 40
31738:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake 
failure:s3_pkt.c:530:

Is something wrong with my certificates or could
this be a regression with openssl 0.9.8j?

-ssl2 and -tls1 works fine. Also does openssl version 0.9.8i.

Cheers,
Thomas

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

Re: openssl 0.9.8j ssl3 connect problem

[Thomas Jarosch]

Hello Steve,

On Wednesday, 14. January 2009 11:29:07 Dr. Stephen Henson wrote:
  # openssl s_client -ssl3 -connect update.intranator.com:443
  CONNECTED(0003)
  31738:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
  failure:s3_pkt.c:1060:SSL alert number 40 31738:error:1409E0E5:SSL
  routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:530:
 
  Is something wrong with my certificates or could
  this be a regression with openssl 0.9.8j?
 
  -ssl2 and -tls1 works fine. Also does openssl version 0.9.8i.

 Try it with the -no_ticket option. Some servers have problems with SSL/TLS
 extensions and these were enabled by default in 0.9.8j. You can also
 disable extensions by compiling with the no-tlsext option.

Thanks for your rpely, -no_ticket seems to work.

The server is running openssl-0.9.7a from Centos/RHEL 3
including the distribution specific patches.

Is openssl 0.9.7a known to be incompatible?
Guess I'll try the no-tlsext option next.

Thanks,
Thomas

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   majord...@openssl.org

RE: [openssl.org #1794] [PATCH] SRP in OpenSSL 0.9.9

[Thomas Wu (thomwu)]

 A few initial comments.

 The copyright notice in srp.c gives the impression Eric Young wrote
that file... I'm assuming he didn't and it  is a combination of work
from other files in apps he did write.

I believe that is the case.  I'll update the copyright notice in the
next version of the patch.

 The indentation in srp.c (perhaps as a result) is very inconsistent.

 Indentation in other files doesn't follow the standard of the rest
of OpenSSL (well most of it).

 In a couple of files the low level SHA1 digest API is used directly.
 That should be avoided because it precludes use of ENGINEs in future.
 Use EVP instead.

Thanks for the comments - I will make the suggested fixes and send an
updated patch early next week.

Tom
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #1684] bug: name collision with Windows SDK

[David W. Thomas via RT]

The following produced a series of compiler errors that seem unrelated to
the cause:

 

#include windows.h

#include openssl/des.h

 

I tracked it down to a name collision of:

 

typedef struct ocsp_response_st OCSP_RESPONSE;

 

within openssl/ossl_typ.h collides with

 

#define OCSP_RESPONSE ((LPCSTR) 67)

 

within WinCrypt.h, a windows header file (Microsoft Windows SDK 6.0A).
There are work-arounds, but the compiler errors led to a few hours of
tracking it down, which, I'm sure, no one else wishes to experience.

 

---

David W. Thomas

Sr. Software Developer

801-377-5410, ext. 843

[EMAIL PROTECTED]

AccessDataR:  A Pioneer in Digitial Investigations since 1987

 










The following produced a series of compiler errors that seem
unrelated to the cause:



#include
windows.h

#include
openssl/des.h



I tracked it down to a name collision of:



typedef
struct ocsp_response_st OCSP_RESPONSE;



within openssl/ossl_typ.h collides
with



#define
OCSP_RESPONSE ((LPCSTR) 67)



within WinCrypt.h, a windows
header file (Microsoft Windows SDK 6.0A). There are work-arounds, but the
compiler errors led to a few hours of tracking it down, which, Im sure, no
one else wishes to experience.



---

David W. Thomas

Sr. Software Developer

801-377-5410, ext. 843

[EMAIL PROTECTED]

AccessData: A
Pioneer in Digitial Investigations since 1987

[openssl.org #1646] Callback userdata for multithreaded application

[Nilsson, Thomas via RT]

Hi,
 
I develop a multithreaded application that would benefit from adding a
userdata argument to the callback functions that you can set using the
following openssl functions:
SSL_CTX_set_tmp_rsa_callback
SSL_CTX_set_verify 
 
Currently I have to set thread specific data and look up the session
variable every time the callback functions are called.
I think it would be much better if there was a possibility to set a
userdata argument that was supplied by openssl when the callbacks were
called.
 
Current usage:
-
static int ssl_open_verify (int ok,X509_STORE_CTX *ctx); /* function
uses Thread local storage to lookup application userdata */
static RSA *ssl_genkey (SSL *con,int export,int keylength); /* function
uses Thread local storage to lookup application userdata */

 SSL_CTX_set_tmp_rsa_callback (context,ssl_genkey);
 SSL_CTX_set_verify (context,SSL_VERIFY_PEER,ssl_open_verify);

If enhancement implemented:

static int ssl_open_verify (int ok,X509_STORE_CTX *ctx, void *userdata);
static RSA *ssl_genkey (SSL *con,int export,int keylength, void
*userdata);

 SSL_CTX_set_tmp_rsa_callback_userdata (context,ssl_genkey, userdata);
 SSL_CTX_set_verify_userdata (context,SSL_VERIFY_PEER,ssl_open_verify,
userdata);

Best regards,
Thomas Nilsson
Software Engineer, StreamServe
 




Hi,

I develop a 
multithreaded application that would benefit from adding a userdata argument to 
the callback functions that you can set using the following openssl 
functions:
SSL_CTX_set_tmp_rsa_callback
SSL_CTX_set_verify 


Currently I have to 
set thread specific data and look up the session variable every time the 
callback functions are called.
I think it would be 
much better if there was a possibility to set a userdata argument that was 
supplied by openssl when the callbacks were called.

Current 
usage:
-
static int 
ssl_open_verify (int ok,X509_STORE_CTX *ctx); /* function uses Thread local 
storage to lookup application userdata */static RSA *ssl_genkey (SSL 
*con,int export,int keylength); /* function uses Thread local storage to lookup 
application userdata */
SSL_CTX_set_tmp_rsa_callback 
(context,ssl_genkey);SSL_CTX_set_verify 
(context,SSL_VERIFY_PEER,ssl_open_verify);
If enhancement 
implemented:


static int 
ssl_open_verify (int ok,X509_STORE_CTX *ctx, void 
*userdata);
static RSA 
*ssl_genkey (SSL *con,int export,int keylength, void 
*userdata);
SSL_CTX_set_tmp_rsa_callback_userdata 
(context,ssl_genkey, userdata);SSL_CTX_set_verify_userdata 
(context,SSL_VERIFY_PEER,ssl_open_verify, 
userdata);
Best 
regards,
Thomas 
Nilsson
Software Engineer, 
StreamServe

Re: [openssl.org #1612] Bug in EC_POINT_cmp function (with possible fix)

[Thomas Biege]

Hello,
has this bug security-implications? Does it waeken the crypto scheme or a like?

Thanks
Thomas


-- 
Thomas Biege [EMAIL PROTECTED], SUSE LINUX, Security Support  Auditing
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

question about porting the implementation of SHA256 from 0.9.8 to 0.9.7

[thomas misc1]

Hi,
Does anyone have any experience with porting the implementation of SHA256
algorithm from 0.9.8 to 0.9.7 ?
Any known patch for this one or for similar ones?
Do you know what is the potential risk by doing it manually?
Regards,
Thomas

[openssl.org #1545] config script sets wrong CFLAGS, breaking build on linux-alpha

[Thomas Orgis via RT]

Hi!

I tried to upgrade from 0.9.8d to 0.9.8e on my GNU/Linux Alpha box and got a 
straigt compiler error:

shell$ ./config
# some output... among that:
Operating system: alpha-whatever-linux2
Configuring for linux-alpha+bwx-gcc
Configuring for linux-alpha+bwx-gcc

shell$ LANG=C make
making all in crypto...
make[1]: Entering directory 
`/spielwiese/smgl/grimoires/grimoire/openssl-0.9.8e/crypto'
gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
-DHAVE_DLFCN_H -march=ev6 -O3 -DL_ENDIAN -DTERMIO   -c -o cryptlib.o cryptlib.c
cc1: error: unrecognized command line option -march=ev6
make[1]: *** [cryptlib.o] Error 1
make[1]: Leaving directory 
`/spielwiese/smgl/grimoires/grimoire/openssl-0.9.8e/crypto'
make: *** [build_crypto] Error 1

Now the gcc on alpha doesn't know -march, as Alphas are just a small set of 
successive CPUs and not a diversed family of many, many CPUs with varying 
degree of similarity like x86.
It needs -mcpu.
Well, 0.9.8d got this right, but for 0.9.8e, someone apparently did something 
along

sed -i 's/mcpu/march/' config

which causes specifically this change:

@@ -527,9 +527,9 @@
esac
if [ $CC = gcc ]; then
case ${ISA:-generic} in
-   EV5|EV45)   options=$options -mcpu=ev5;;
-   EV56|PCA56) options=$options -mcpu=ev56;;
-   *)  options=$options -mcpu=ev6;;
+   EV5|EV45)   options=$options -march=ev5;;
+   EV56|PCA56) options=$options -march=ev56;;
+   *)  options=$options -march=ev6;;
esac
fi
;;

Please revert this change for the next release to make the build work again.

Actually, I must say that I'd prefer omitting the -mcpu settings altogether and 
use CFLAGS instead.
The distro I'm using is a source code based one and has something called 
archspecs for the user to choose from.
There we set things like -mcpu or -march; and we already have to insert that to 
the openssl Makefile:

./config
sed -i  s/^CFLAG=/CFLAG=$CFLAGS /  Makefile

But still, if I have -mcpu=ev67 in my $CFLAGS, the -mcpu (or -march, currently) 
of openssl will override it.
That can be a problem when I want to compile for a ev5 CPU on a ev67 box; 
openssl will build binaries that won't run on the older cpu.


Alrighty then,

Thomas.



signature.asc
Description: PGP signature

SSL_CTX_new: No such file or directory

[Adayadil Thomas]

Greetings.

I am getting this error and am trying to find any info that could help
me get past it.

Relevant code snippet:

   if(!(d-ssl_ctx=SSL_CTX_new(SSLv23_server_method(
   {
   perror(SSL_CTX_new:);
   }


Error I get:

SSL_CTX_new:: No such file or directory

Do you know why I would get such an error. I had the application
working fine with openssl-0.9.6 and this error started appearing after
I started using openssl-0.9.8c

Thanks for the help !!!

Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: Application Development Makefile examples

[Adayadil Thomas]

Use -lssl to link the library in.
Use ldd on your final binary to double check.

Regarding details of OpenSSL calls, use google, manpages or buy the
book suggested in the prev reply.

On 2/21/07, Brad House [EMAIL PROTECTED] wrote:

 I am new to Application development using OpenSSL. Currently I have
 installed 0.9.7b (the version I need to use)  would like to write a
 small application using the OpenSSL function calls  would like to know
 if I can find some example source code.

 Also would like to know if I can find some Makefile examples to include
 the libraries  header files for my application to compile  link.

 Appreciate any help.

Buy the 'Network Security with OpenSSL' book from O'Reilly.  It's
a good starter.
http://www.amazon.com/Network-Security-OpenSSL-John-Viega/dp/059600270X

# ISBN-10: 059600270X
# ISBN-13: 978-0596002701
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

openssl s_client: zlib

[Adayadil Thomas]

Greetings.

Does openssl s_client code negotiate zlib compression with the server ?

Thanks
Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RSA_private_decrypt speed ?

[Adayadil Thomas]

Greetings.

I saw a post long time back that mentioned :

According to Rescorla's book, the big CPU hit is in
ssl3_get_client_key_exchange when it calls
RSA_private_decrypt().  This takes 30 of the 32 milliseconds
needed to process the connection on a 300 MHz Pentium (II).

SNIP

That was in the year 2000. Does anyone know what's the time taken
on latest CPUs ? ( on a 3GHz box will it be 3 ms ?)

Thanks
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Openssl and zlib

[Adayadil Thomas]

Greetings.

Does openssl provide api's that the server and client should use to handle
zlib compression ?
Does the EVP api's handle/support zlib compression ?

Help/Info is greatly appreciated.

Thanks
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

SSL / zlib compression

[Adayadil Thomas]

Greetings.

I have an SSL session in which the client and server has negotiated for
cipherSuite SSL_RSA_WITH_RC4_128_MD5
compressionMethodzlib-compression

Now, is the zlib-compression applied before encryption or after ?

data - zlib-compression - encryption == decrypt - zlib-inflate- data

or

data - encryption - zlib-compression == zlib-inflate- decrypt - data


Thanks
Ashley Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: SSL / zlib compression

[Vinu Thomas]

I am almost sure its after...
First you encrypt and then compress.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Adayadil Thomas
Sent: Tuesday, September 26, 2006 7:46 PM
To: openssl-dev@openssl.org
Subject: SSL / zlib compression

Greetings.

I have an SSL session in which the client and server has negotiated for
cipherSuite SSL_RSA_WITH_RC4_128_MD5
compressionMethodzlib-compression

Now, is the zlib-compression applied before encryption or after ?

data - zlib-compression - encryption == decrypt -
zlib-inflate- data

or

data - encryption - zlib-compression == zlib-inflate- decrypt
- data


Thanks
Ashley Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

SSLv3/TLSv1 and compression

[Adayadil Thomas]

Hello,

What is the API or config setting that the client needs to invoke/perform
in order to negotiate a compression method ?

I am using curl as the client and when --tlsv1 or --sslv3 is specified
it negotiates zlib compression with the server.

I am trying to change curl not to negotiate the zlib compression
and do sslv3 and tlsv1

Please advise.

Thanks
Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

disabling the negotiation of compression during tls/sslv3 negotiation ?

[Adayadil Thomas]

Hello,

What is the API or config setting that the client needs to invoke/perform
in order to negotiate a compression method ?

I am using curl as the client and when --tlsv1 or --sslv3 is specified
it negotiates zlib compression with the server.

I am trying to change curl not to negotiate the zlib compression
and do sslv3 and tlsv1

Please advise.

Thanks
Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Compatibilty question (SSL methods)

[Adayadil Thomas]

Greetings to All,

I have a question regarding compatibility between SSL methods.

If the server uses SSLv23_client_method when creating the CTX,
then will the server will be compatible with clients
using
1. TLSv1_client_method
2. SSLv2_client_method
3. SSLv3_client_method
4. SSLv23_client_method

Thanks
Thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

Re: version 2 is used for Client Hello when version 3 was requested in client code

[Thomas]

  Why wasn't SSLv3(.0) be used? Or will only headers of SSLv3(.1) be
  identified as real SSLv3? I am confused a bit b/c everyone tells you
  that SSLv2 isn't secure and so usage of it should be avoided... and then
  it was used silently. Maybe its insecurity doesn't matter in this early
  stage.

 With SSL_OP_NO_SSLv2, SSL 2.0 was never used, so its security problems
 did not apply.  The SSL 2.0 compatible client hello message that was
 generated by SSLv23_client_method() is just a different way of
 arranging essentially the same information that occurs in an SSL 3.0
 or TLS 1.0 client hello message.  (You just can't list compression
 techniques in the SSL 2.0 format, and you can't include TLS
 extensions.  TLS extensions are not yet supported by OpenSSL, though.)

[...]

Thanks for the answer! :)

Thomas

-- 
Tom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

version 2 is used for Client Hello when version 3 was requested in client code

[Thomas Biege]

Hi,
well the (too long) subject explains it very well.

But here are the details.

I used the code from the book Network Security with OpenSSL to play
around with SSL.

The client code looks like:
SSL_CTX *setup_client_ctx(void)
{
SSL_CTX *ctx;

ctx = SSL_CTX_new(SSLv23_method());

if(SSL_CTX_load_verify_locations(ctx, CAFILE, CADIR) != 1)
int_error(Error loading CA file and/or directory.);
if(SSL_CTX_set_default_verify_paths(ctx) != 1)
int_error(Error loading default CA file and/or directory.);

SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback);
SSL_CTX_set_verify_depth(ctx, 4);

SSL_CTX_set_options(ctx, SSL_OP_ALL|SSL_OP_NO_SSLv2);

if(SSL_CTX_set_cipher_list(ctx, CIPHER_LIST) != 1)
int_error(Error setting cipher list (no valid ciphers));

return ctx;
}

You see I use SSLv23_method() and later SSL_CTX_set_options(ctx, SSL_OP_ALL
| SSL_OP_NO_SSLv2); to disable SSLv2 support.

Is it normal that the Client Hello message is SSLv2 and later TLS is used?

If I use SSLv3_method() everything works as expected.

I attached a ethereal capture file (see frame 4). Maybe the ethereal decoder
makes a mistake here or maybe it is normal behaviour.

Thanks,
Thomas

-- 
TheTom [EMAIL PROTECTED]
fingerprint = F055 43E5 1F3C 4F4F 9182  CD59 DBC6 111A 8516 8DBF


sslv2.bin
Description: Binary data


pgpEM7nvEdv1Q.pgp
Description: PGP signature

The breaking of SHA1

[thomas . beckmann]

Hello everybody,

I am not quite sure which list to address so I chose both.

Regarding the news around the breaking of SHA1, I wonder if it is planned
or already in work to implement other hash algorithms like SHA256 into
OpenSSL.

Best Regards

Thomas Beckmann
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

AW: The breaking of SHA1

[thomas . beckmann]

Do you have an estimation when a stable version of 0.9.8 will be released?

Thomas

 -Ursprüngliche Nachricht-
 Von: [EMAIL PROTECTED]
 [mailto:[EMAIL PROTECTED] Auftrag von Nils Larsch
 Gesendet: Dienstag, 8. März 2005 10:32
 An: openssl-dev@openssl.org
 Betreff: Re: The breaking of SHA1
 
 
 [EMAIL PROTECTED] wrote:
  Hello everybody,
  
  I am not quite sure which list to address so I chose both.
  
  Regarding the news around the breaking of SHA1, I wonder 
 if it is planned
  or already in work to implement other hash algorithms like 
 SHA256 into
  OpenSSL.
 
 sha256 etc. is implemented in 0.9.8-dev
 
 Nils
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   openssl-dev@openssl.org
 Automated List Manager   [EMAIL PROTECTED]
 
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

openssl U.S. export rules

[Henderson, Thomas R]

Hi, apologies if this has already been covered, but I did not find it
specifically in the faq or by googling.

Has anyone received sound legal advice about the rules for U.S. citizens
for distributing openssl as part of a software bundle?  Specifically,
I'd like to make a LiveCD that includes openssl libraries.  Will I run
afoul of the U.S. export laws in doing so?  Does it make any difference
if the the openssl library is in the base Linux distribution already?

Thanks,
Tom
__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

RE: openssl U.S. export rules

[Henderson, Thomas R]

Thanks for your advice and the BXA pointer.  I understand and appreciate
your avoidance of making any explicit recommendation or endorsement of
following a particular course of action.

I would like to suggest the following text for your FAQ, under Legal
section:

3.  What are the United States export rules on redistributing
OpenSSL-based software?

Note that the OpenSSL project and developers do not provide certified
legal advice.  The project recommends that you familiarize yourself with
the following website (http://www.bxa.doc.gov) and consult an attorney.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   openssl-dev@openssl.org
Automated List Manager   [EMAIL PROTECTED]

[PATCH] Fix for empty password handling in PKCS12

[Thomas Wu]

This patch allows the pkcs12 utility to handle empty-password PKCS#12
files created by MS even when the -passin option is used.  Previously,
such files could only be imported by leaving out -passin and hitting
return at the import password prompt, which was insufficient for
scripted or unattended operation.
*** openssl-0.9.7e-orig/apps/pkcs12.c   2003-12-27 14:40:56.0 +
--- openssl-0.9.7e/apps/pkcs12.c2004-11-23 00:21:50.0 +
***
*** 667,671 
  #endif
/* If we enter empty password try no password first */
!   if(!macpass[0]  PKCS12_verify_mac(p12, NULL, 0)) {
/* If mac and crypto pass the same set it to NULL too */
if(!twopass) cpass = NULL;
--- 667,673 
  #endif
/* If we enter empty password try no password first */
!   if(mpass  !mpass[0]  PKCS12_verify_mac(p12, NULL, 0)) {
!   if(!twopass) cpass = NULL;
!   } else if(!macpass[0]  PKCS12_verify_mac(p12, NULL, 0)) {
/* If mac and crypto pass the same set it to NULL too */
if(!twopass) cpass = NULL;

AW: key compromise with memory debugger possilbe ?

[thomas . beckmann]

For an official statement you may ask the BSI (GISA, German Information
Security Agency) for that topic. They support the use of open-source
software in the gouvernment and administration an may be can tell something
more about vulnerabilities of that kind.

Best regards

Thomas Beckmann


 -Ursprüngliche Nachricht-
 Von: Oliver Welter [mailto:[EMAIL PROTECTED]
 Gesendet: Freitag, 23. Juli 2004 08:42
 An: [EMAIL PROTECTED]
 Betreff: key compromise with memory debugger possilbe ?
 
 
 Hello List,
 
 As I am new here I frist want to introduce myself - I am a scientific 
 employee at Technische Universitaet Muenchen and we do some 
 research on 
 DRM related security mechanisms.
 
 We made a concept for a secure media player and now try to 
 attack it - 
 the openssl related question is:
 
 We use openssl to en/decrypt data with 3des - is it possible 
 to retrieve 
 the used key while running a de/encryption via a memory debugger or 
 something similar ? Are there any preventions against such attacks or 
 has noone ever thought about such an attack ?
 
 I would appreciate any hints on related studys, documents, etc...
 
 best regards
 
 Oliver
 -- 
 Diese Nachricht wurde digital unterschrieben
 oliwel's public key: http://www.oliwel.de/oliwel.crt
 Basiszertifikat: http://www.ldv.ei.tum.de/page72
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   [EMAIL PROTECTED]
 Automated List Manager   [EMAIL PROTECTED]
 
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #921] SSL Library Error: 336131157

[Thomas Apsel via RT]

Hi Tom,

I have a problem with SSL (Suse9, Linux, apache 2.0.45, openssl-0.9.6l):
SSL Library Error: 336131157 error:1408F455:lib(20):func(143):reason(1109) 

I have read your answer and you talked about a patch:
This patch fixes the multithreading issues I was having when an RSA struct
was being used by multiple threads simultaneously with blinding enabled. It
adds _r versions of the convert/invert functions to save the unblinding
value, and does the update in the convert step. rsa_eay.c uses the
RSA_BLINDING lock to make the convert-and-update step atomic. The patch is
for 0.9.6i.
http://groups.google.com/groups?hl=enlr=ie=UTF-8safe=offframe=rightth=1
ce07ab31fece53cseekm=b60t7m%242k11%241%40FreeBSD.csie.NCTU.edu.tw#link1
http://groups.google.com/groups?hl=enlr=ie=UTF-8safe=offframe=rightth=
1ce07ab31fece53cseekm=b60t7m%242k11%241%40FreeBSD.csie.NCTU.edu.tw#link1 


Can you provide me with this patch?

Regards,

Thomas


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

subjectAltName values

[thomas . beckmann]

I used to issue certificates containing the Microsoft userPrincipalName
(UPN, OID 1.3.6.1.4.1.311.20.2.3) in the subjectAtlName field.
can anybody tell me if an how i can do that using OpenSSL?

Thanx in advance

Thomas Beckmann
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #723] 0.9.7c IMAPD+TLS Interaction Bug

[Thomas H Jones II via RT]

To Whom It May Concern:

Per the September. 30th security advisory, I just tried upgrading my 
0.9.7b installation to 0.9.7c. While SMTP w/StartTLS and HTTP+SSL seem 
to function just fine with the new version, the new version seems to 
break IMAP. I was running Washington University's IMAP 2002d software. 
Because of the errors I encountered, I tried upgrading it to IMAP 2002e 
(latest release). This did not fix the problems. So, I tried the Cyrus 
Project's IMAP daemon. Same problems validating certificates.

My `make report` outlook is as follows:

 OpenSSL self-test report:

 OpenSSL version:  0.9.7c
 Last change:  Fix various bugs revealed by running the NISCC 
test sui...
 Options:  no-threads shared zlib-dynamic 
--prefix=/usr/local --openssldir=/usr/local/openssl no-krb5
 OS (uname):   SunOS typhoon 5.9 Generic_112233-08 sun4u sparc 
SUNW,Ultra-5_10
 OS (config):  sun4u-whatever-solaris2
 Target (default): solaris-sparcv9-gcc
 Target:   solaris-sparcv9-gcc
 Compiler: Configured with: ../configure --disable-nls 
--with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
 Thread model: posix
 gcc version 3.2.3

 Test skipped.

The errors I am seeing in my syslogs are:

 Oct  3 16:12:08 typhoon imapd[2306]: [ID 149382 mail.info] Unable 
to accept SSL connection, host=home-lfw1.xanthia.com [66.92.150.14]
 Oct  3 16:12:08 typhoon imapd[2306]: [ID 853321 mail.error] SSL 
error status: error:1408F455:SSL routines:SSL3_GET_RECORD:decryption 
failed or bad record mac

When I ran the Cyrus test tools, I get a general failure (since I am new 
to Cyrus, as of today, I can't provide anything more helpful).

Reverting back to 0.9.7b fixed the problems.

It should also be noted that NONE of my certificate files were changed 
and continued to pass the `openssl verify` tests (even the certs that 
the IMAP processes were barfing on).

Sincerely,

Thomas H Jones II
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RSA blinding thread safety issue

[Thomas Wu]

The RSA blinding patch seems to cause problems when the same RSA
private key is used simultaneously in multiple threads.

I believe this is caused by the call to BN_BLINDING_update in
BN_BLINDING_invert.  If one thread finishes an RSA decryption
and calls BN_BLINDING_invert while another thread is in between
the BN_BLINDING_convert and BN_BLINDING_invert calls, then the
second thread will unblind with the wrong value.

I would suggest something along the lines of:
  - move the BN_BLINDING_update into BN_BLINDING_convert.
  - make BN_BLINDING_convert hand the unblinding value
(Ai) back to the caller for subsequent use.
  - place a lock around this logic in BN_BLINDING_convert
so that the steps of blinding, capturing the unblinding
value, and updating are an atomic operation.

If no one beats me to submitting a patch next week, I'll try to
write one up and send it in.

Tom
-- 
Tom Wu* finger -l [EMAIL PROTECTED] for PGP key *
 E-mail: [EMAIL PROTECTED]   Those who would give up their freedoms in
  Phone: (650) 723-1565  exchange for security deserve neither.
   http://www-cs-students.stanford.edu/~tjw/   http://srp.stanford.edu/
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

certification path validation suite

[Thomas Pornin]

Hello,

I send that message to the openssl-dev list because the same problem
is likely to have occurred or to occur in a near future to openssl
developpers.

I am currently developping an implementation of the certification path
validation algorithm described in section 6.1 of RFC 3280. I need
some test certificates to check the correctness of my implementation.

I have already come accross the test suite from the NIST:
http://csrc.nist.gov/pki/testing/x509paths.html

These certificates are great, and my software now handles them as
specified (rejecting what needs to be rejected, accepting what needs to
be accepted), but they do not test all the features I wish to support.
Namely, the following are of chief interest to me and I have come
accross no publicly available certificate that use them:
-- policy qualifiers (CPS URI and user notices)
-- policy mappings
-- name constraints
-- subjectAltName extension
-- DSS signing while using the DSS parameters from another certificate

So my questions are:

1. Is there any test suite available somewhere, which covers my needs ?

2. I heard the NIST is preparing an advanced test suite which might be
of some help; is there any info about when this test suite will be ready ?

3. If there is no reference test suite available, should it be assumed
that there exists no tested, and, therefore with high probability no
correct, implementation of the certification path validation algorithm
which handles the policy mappings and name constraints ?


Thanks for any information,


--Thomas Pornin
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #115] aix 5.1 openssl compiling problem and solution

[Thomas von Mandel via RT]

Richard Levitte via RT wrote:

 I just realised that the configuration entries for AIX currently
 assume a 32-bit environment.  The question is how gcc view this, and
 especially what size an int is, and also the size of a long.  If
 either of them is 64 bits, a different configuration entry may be
 useful, perhaps called aix43-gcc64, which is a copy if the
 aix43-gcc entry, with BN_LLONG changed to SIXTY_FOUR_BIT (if the
 size of int is 8 bytes) or SIXTY_FOUR_BIT_LONG (if int is only 4
 bytes but long is 8 bytes).

 Wanna try that out with -O3 and say if that made a difference?

 Otherwise, I'm still inclined at saying we've a compiler bug to deal
 with and leave it at that.

 [[EMAIL PROTECTED] - Wed Jul 17 21:39:38 2002]:

 [[EMAIL PROTECTED] - Sun Jun 23 16:44:16 2002]:

  hi,
  i try to compile openssl 0.9.6d and 0.9.7-beta2 under AIX
 5.1
   (ML
  510002) in a 64Bit environment with gcc-2.9AIX51.xx.
  when i run 'make test' the following errors appear:

 --
 Richard Levitte
 [EMAIL PROTECTED]

Dear Richard,

see under: http://aix43.uwaterloo.ca/aix/AIX510-Relnotes.html#Header_20

Application Support

The 64-bit kernel supports both 32-bit and 64-bit applications.
Application source and binaries are portable between AIX 5L Version 5.1
64-bit and 32-bit kernel systems, in the absence of any application
dependencies on internal kernel details or on kernel extensions that are
not supported under the 64-bit kernel but are supported under the 32-bit
kernel.

I think AIX build openssl as an 32bit binary and openssh also. Solaris 8
use the same mechanism.

best regards
thomas


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #115] aix 5.1 openssl compiling problem and solution

[Thomas von Mandel via RT]

Richard Levitte via RT wrote:

 One quick question on this: have you made sure your compiler is as
 updated as possible?  This very much feels like a compiler bug.

 [[EMAIL PROTECTED] - Fri Jun 28 00:06:17 2002]:

  Richard Levitte via RT wrote:
 
   It would be nice if you told us which configuration target you
 used.
If you don't know, the following will give you the answer:
  
   grep '^CONFIGURE_ARGS=' Makefile
  
   [[EMAIL PROTECTED] - Sun Jun 23 16:44:16 2002]:
  
hi,
i try to compile openssl 0.9.6d and 0.9.7-beta2 under AIX 5.1
 (ML
510002) in a 64Bit environment with gcc-2.9AIX51.xx.
when i run 'make test' the following errors appear:
   
Generate a set of DSA parameters
./dsatest
 [...]
 540910:error:0A071003:dsa routines:DSA_do_verify:BN
   lib:dsa_ossl.c:305:
   
 make[1]: *** [test_dsa] Error 1
 make[1]: Leaving directory
   `/usr/opt/distrib/src/openssl-0.9.6d/test'
 make: *** [tests] Error 2
   
After a little talk with Lutz Jaenicke, i playing around with
   optimizing
setting in the Makefile.
   
CFLAG= -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -DAIX -DB_ENDIAN
   
I changed  the -O3 setting to -O1 and the testsuite runs
 without
   errors.
Next, i compile openssh-3.2.3 - no problems.
   
   
best regards
thomas
  
   --
   Richard Levitte
 
  dear richard levitte,
 
  the configuration parameter is:
 
  CONFIGURE_ARGS=aix43-gcc shared
 

 --
 Richard Levitte
 [EMAIL PROTECTED]

Dear Richard,
i use the gcc-2.9aix5.1 compiler, this is the latest version for aix 5L.

best regards
thomas


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: [openssl.org #115] aix 5.1 openssl compiling problem and solution

[Thomas von Mandel via RT]

Richard Levitte via RT wrote:

 It would be nice if you told us which configuration target you used.
  If you don't know, the following will give you the answer:

 grep '^CONFIGURE_ARGS=' Makefile

 [[EMAIL PROTECTED] - Sun Jun 23 16:44:16 2002]:

  hi,
  i try to compile openssl 0.9.6d and 0.9.7-beta2 under AIX 5.1 (ML
  510002) in a 64Bit environment with gcc-2.9AIX51.xx.
  when i run 'make test' the following errors appear:
 
  Generate a set of DSA parameters
  ./dsatest
  test generation of DSA parameters
  .++*
 
 
 
...++..+...++.+..+..+++*
 
 
   seed
   D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3
   counter=105 h=2
   P:
   00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68:
   69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d:
   78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac:
   32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36:
   ee:31:c8:02:91
   Q:
   00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30:
   f4:8e:da:ce:91:5f
   G:
   62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5:
   00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce:
   2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21:
   92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53:
   e6:d7:88:02
   540910:error:0A071003:dsa routines:DSA_do_verify:BN
 lib:dsa_ossl.c:305:
 
   make[1]: *** [test_dsa] Error 1
   make[1]: Leaving directory
 `/usr/opt/distrib/src/openssl-0.9.6d/test'
   make: *** [tests] Error 2
 
  After a little talk with Lutz Jaenicke, i playing around with
 optimizing
  setting in the Makefile.
 
  CFLAG= -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -DAIX -DB_ENDIAN
 
  I changed  the -O3 setting to -O1 and the testsuite runs without
 errors.
  Next, i compile openssh-3.2.3 - no problems.
 
 
  best regards
  thomas

 --
 Richard Levitte

dear richard levitte,

the configuration parameter is:

CONFIGURE_ARGS=aix43-gcc shared

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[openssl.org #115] aix 5.1 openssl compiling problem and solution

[Thomas von Mandel via RT]

hi,
i try to compile openssl 0.9.6d and 0.9.7-beta2 under AIX 5.1 (ML
510002) in a 64Bit environment with gcc-2.9AIX51.xx.
when i run 'make test' the following errors appear:

Generate a set of DSA parameters
./dsatest
test generation of DSA parameters
.++*

...++..+...++.+..+..+++*


 seed
 D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3
 counter=105 h=2
 P:
 00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68:
 69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d:
 78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac:
 32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36:
 ee:31:c8:02:91
 Q:
 00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30:
 f4:8e:da:ce:91:5f
 G:
 62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5:
 00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce:
 2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21:
 92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53:
 e6:d7:88:02
 540910:error:0A071003:dsa routines:DSA_do_verify:BN lib:dsa_ossl.c:305:

 make[1]: *** [test_dsa] Error 1
 make[1]: Leaving directory `/usr/opt/distrib/src/openssl-0.9.6d/test'
 make: *** [tests] Error 2

After a little talk with Lutz Jaenicke, i playing around with optimizing
setting in the Makefile.

CFLAG= -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -DAIX -DB_ENDIAN

I changed  the -O3 setting to -O1 and the testsuite runs without errors.
Next, i compile openssh-3.2.3 - no problems.


best regards
thomas
__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

manpage of EVP_SealFinal

[thomas poindessous]

Hi, 
in manpage (version 0.9.6b et version 0.9.7-stable-SNAP-20020317),
there is :
--
int EVP_SealFinal(EVP_CIPHER_CTX *ctx, unsigned char *out,
int *outl);

and 
  EVP_SealUpdate() and EVP_SealFinal() return 1 for success and 0 for
   failure.
-

But in p_seal.c, there is :

void EVP_SealFinal(EVP_CIPHER_CTX *ctx, unsigned char *out, int *outl)

So, there is a problem.

-- 
Thomas Poindessous
[EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[Patch] Error in demos/maurice/example1.c

[thomas poindessous]

Hi,

there is an error in demos/maurice/example1.c (last cvs version).
Here is the patch :

--- example1.c.orig Tue Mar 19 10:53:41 2002
+++ example1.c  Tue Mar 19 10:54:46 2002
@@ -72,7 +72,7 @@ void main_encrypt(void)
 
 pubKey[0] = ReadPublicKey(PUBFILE);
 
-   if(!pubKey)
+   if(!pubKey[0])
{
fprintf(stderr,Error: can't load public key);
exit(1);

Thanks.

-- 
Thomas Poindessous
[EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

va_end buglet in openssl/crypto/err/err.c

[Thomas Klausner]

Hi!

In an error case in the openssl/crypto/err/err.c, va_start is not
ended by va_end.

Please see the attached diff for details (against 0.9.6b).

I found this in a recent va_start/va_end audit I did on NetBSD.

Bye,
 Thomas

-- 
Thomas Klausner - [EMAIL PROTECTED]
War is an instrument entirely inefficient toward redressing wrong; and
multiplies, instead of indemnifying losses. -- Thomas Jefferson, author,
architect, and third U.S. president (1743-1826)


Index: err.c
===
RCS file: /cvsroot/basesrc/crypto/dist/openssl/crypto/err/err.c,v
retrieving revision 1.1.1.3
retrieving revision 1.2
diff -u -r1.1.1.3 -r1.2
--- err.c   2001/04/12 03:08:38 1.1.1.3
+++ err.c   2001/09/24 13:22:27 1.2
@@ -784,6 +784,7 @@
if (p == NULL)
{
OPENSSL_free(str);
+   va_end(args);
return;
}
else

Error creating Certificate

[thomas . klueppelholz]

Hi,

After I created a RSA key, I want to create a SSL Certificate with the following
command:

openssl.exe req -new -key pcniws1.key -out pcniws1.csr

I get the following error message:

Using configuration from /usr/local/ssl/openssl.cnf
Unable to load config info
Enter PEM pass phrase:
unable to find 'distinguished_name' in config
problems making Certificate Request
85:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or
environment variable:.\crypto\conf\conf_lib.c:343:
85:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or
environment variable:.\crypto\conf\conf_lib.c:343:
85:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or
environment variable:.\crypto\conf\conf_lib.c:343:
85:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or
environment variable:.\crypto\conf\conf_lib.c:343:
85:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or
environment variable:.\crypto\conf\conf_lib.c:343:
85:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or
environment variable:.\crypto\conf\conf_lib.c:343:
85:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or
environment variable:.\crypto\conf\conf_lib.c:343:
85:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or
environment variable:.\crypto\conf\conf_lib.c:343:

For compiling the source I followed the information and commands in the
install.w32 file. I used do_nt.bat.

Please tell me how I can solve this problem.

Here are the informations you need:

OpenSSL 0.9.6b 9 Jul 2001
built on: Mon Sep 24 14:20:25 2001
platform: VC-NT
options:  bn(64,32) md2(int) rc4(idx,int) des(idx,cisc,4,long) idea(int)
blowfish(idx)
compiler: cl  /MD /W3 /WX /G5 /Ox /O2 /Ob2 /Gs0 /GF /Gy /nologo -DWIN32
-DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DDSO_WIN32 -DWINNT /Fdout32dll

Windows NT 4.0 SP5 on an Intel Pentium III Processor

MS-Visual Studio 6

I hope you can help me.

Thanks a lot.

Thomas Klüppelholz




__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

[PATCH] c_rehash triviality

[Rudo Thomas]

Hello, everyone!

Here is a patch that makes c_rehash work with filenames containing unfriendly 
characters... Am I the only one having ampersands in certificate file names? 
:-P

It is SO simple I did not want to post it at first... If it is already solved 
in the CVS or wherever, then I am sorry I have bothered you.

Have a good time.

Rudo Thomas.

ps: If you happen to reply, please send CC to me, as I am not subscribed to 
the list.



--- c_rehash-orig	Mon Jun 18 21:54:03 2001
+++ c_rehash	Fri Aug 17 02:27:56 2001
@@ -100,7 +100,7 @@
 
 sub link_hash_cert {
 		my $fname = $_[0];
-		my ($hash, $fprint) = `$openssl x509 -hash -fingerprint -noout -in $fname`;
+		my ($hash, $fprint) = `$openssl x509 -hash -fingerprint -noout -in "$fname"`;
 		chomp $hash;
 		chomp $fprint;
 		$fprint =~ s/^.*=//;
@@ -130,7 +130,7 @@
 
 sub link_hash_crl {
 		my $fname = $_[0];
-		my ($hash, $fprint) = `$openssl crl -hash -fingerprint -noout -in $fname`;
+		my ($hash, $fprint) = `$openssl crl -hash -fingerprint -noout -in "$fname"`;
 		chomp $hash;
 		chomp $fprint;
 		$fprint =~ s/^.*=//;

Writing nonblocking sockets

[Harrington, Thomas]

I'm trying to do nonblocking writes via OpenSSL.  Initially I cribbed the
following from mod_ssl:

int iostate = 1;
rv = ioctl(sock, FIONBIO, (u_long*)iostate);
rv = SSL_write(ssl, (char*)buf, len);
...
iostate = 0;
ioctl(sock, FIONBIO, (u_long*)iostate);

But doing a 4kB write, followed by a ~30kB one, the second attempt would
consistently fail to write and get -1 back from SSL_write().

If I replace the ioctl() calls with fcntl() calls that should be equivalent,
it works every time.  That is, set nonblocking as follows:

iostate = fcntl(sock, F_GETFL, 0);
iostate |= O_NDELAY;
rv = fcntl(sock, F_SETFL, iostate);

Why do I get different results here?  I dug through the openssl code a bit
and can't see where this should make a difference.  Buggy ioctl function,
maybe?

-- 
Tom Harrington
Cybernetic Entomologist
EMC Colorado Springs
[EMAIL PROTECTED]


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: Is the list down?

[Thomas Nichols]

No. Everyone's working on their Math skills to apply for the new $100,000
per year positions counting ballots.

Michael Sierchio wrote:

 --
 Michael Sierchio  [EMAIL PROTECTED]

 Certified Master Internet Security Specialist
 http://www.brainbench.com/transcript.jsp?pid=1889331
 __
 OpenSSL Project http://www.openssl.org
 Development Mailing List   [EMAIL PROTECTED]
 Automated List Manager   [EMAIL PROTECTED]

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Problem makeing OpenSSL 0.9.5

[Thomas Serries]

-BEGIN PGP SIGNED MESSAGE-

Hello,

is there anybody who can help me to "make" OpenSSL. You will find the
requested report as attachment.

Thanks in advance,
  Thomas

/--\
|  Thomas.Serries(@uni-muenster.de)|
|   http://www.muenster.de/~serries (incl. PGP-Key)|
+==+
|Die einen nennen es Windows95. Die anderen das längste Virus der Welt.|
\--/

-BEGIN PGP SIGNATURE-
Version: 2.6.3ia
Charset: noconv

iQCVAwUBOONEON5ZY9I/dwdpAQGkQwP9ELHpKk3P+N7fOji2Mi1fEhSfjglsec6M
FhYMpKzSX57uIMHdGRzx+XBRnGn0zRl0TqM+AKD7dhSBuI7xwoMWJd+85Uy1KhKd
jhUsIkkuH5VCDHvwUlj42cLVvJ8uOvHsWGQCQJcVK+94b075/uYKNRFAhVk7Z29M
/GdQAk/MUrk=
=AirZ
-END PGP SIGNATURE-



OpenSSL self-test report:

OpenSSL version:  0.9.5
Last change:  PKCS7_encrypt() was adding text MIME headers twice beca...
OS (uname):   Linux tux 2.2.13 #3 Fri Mar 3 17:05:09 /etc/localtime 2000 i586 
unknown
OS (config):  i586-whatever-linux2
Target (default): linux-elf
Target:   linux-elf
Compiler: gcc version 2.7.2.3

Failure!
-
make[1]: Entering directory `/usr/src/openssl-0.9.5'
c_rehash: rehashing skipped ('openssl' program not available)
touch rehash.time
testing...
make[2]: Entering directory `/usr/src/openssl-0.9.5/test'
gcc -I../include -DTHREADS -D_REENTRANT -DL_ENDIAN -DTERMIO -O3 -fomit-frame-pointer 
-m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM   -c bntest.c -o bntest.o
gcc -o bntest -I../include -DTHREADS -D_REENTRANT -DL_ENDIAN -DTERMIO -O3 
-fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM -DRMD160_ASM bntest.o -L. -L.. 
-L../.. -L../../.. -L.. -lcrypto 
../libcrypto.a(bn_add.o): In function `BN_uadd':
bn_add.o(.text+0x156): undefined reference to `bn_add_words'
../libcrypto.a(bn_div.o): In function `BN_div':
bn_div.o(.text+0x449): undefined reference to `bn_mul_words'
../libcrypto.a(bn_mul.o): In function `bn_mul_recursive':
bn_mul.o(.text+0x32): undefined reference to `bn_mul_comba8'
bn_mul.o(.text+0x126): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x156): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x16b): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x196): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x1ab): undefined reference to `bn_sub_words'
../libcrypto.a(bn_mul.o)(.text+0x1e6): more undefined references to `bn_sub_words' 
follow
../libcrypto.a(bn_mul.o): In function `bn_mul_recursive':
bn_mul.o(.text+0x221): undefined reference to `bn_mul_comba4'
bn_mul.o(.text+0x253): undefined reference to `bn_mul_comba4'
bn_mul.o(.text+0x27f): undefined reference to `bn_mul_comba4'
bn_mul.o(.text+0x2af): undefined reference to `bn_mul_comba8'
bn_mul.o(.text+0x2e3): undefined reference to `bn_mul_comba8'
bn_mul.o(.text+0x30f): undefined reference to `bn_mul_comba8'
bn_mul.o(.text+0x3d5): undefined reference to `bn_add_words'
bn_mul.o(.text+0x3f1): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x40c): undefined reference to `bn_add_words'
bn_mul.o(.text+0x42d): undefined reference to `bn_add_words'
../libcrypto.a(bn_mul.o): In function `bn_mul_part_recursive':
bn_mul.o(.text+0x591): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x5d2): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x5ed): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x622): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x63d): undefined reference to `bn_sub_words'
../libcrypto.a(bn_mul.o)(.text+0x672): more undefined references to `bn_sub_words' 
follow
../libcrypto.a(bn_mul.o): In function `bn_mul_part_recursive':
bn_mul.o(.text+0x6bb): undefined reference to `bn_mul_comba8'
bn_mul.o(.text+0x6cf): undefined reference to `bn_mul_comba8'
bn_mul.o(.text+0x8fd): undefined reference to `bn_add_words'
bn_mul.o(.text+0x920): undefined reference to `bn_sub_words'
bn_mul.o(.text+0x943): undefined reference to `bn_add_words'
bn_mul.o(.text+0x96b): undefined reference to `bn_add_words'
../libcrypto.a(bn_mul.o): In function `bn_mul_low_recursive':
bn_mul.o(.text+0xa1b): undefined reference to `bn_add_words'
bn_mul.o(.text+0xa41): undefined reference to `bn_add_words'
bn_mul.o(.text+0xa97): undefined reference to `bn_add_words'
../libcrypto.a(bn_mul.o)(.text+0xaa0): more undefined references to `bn_add_words' 
follow
../libcrypto.a(bn_mul.o): In function `bn_mul_high':
bn_mul.o(.text+0xb6a): undefined reference to `bn_sub_words'
bn_mul.o(.text+0xb9a): undefined reference to `bn_sub_words'
bn_mul.o(.text+0xbb1): undefined reference to `bn_sub_words'
bn_mul.o(.text+0xbda): undefined reference to `bn_sub_words'
bn_mul.o(.text+0xbf1): undefined reference to `bn_sub_words'
../l

Make fails...

[Paul Thomas]

Hi,

I was trying to compile Openssl on Red Hat 6.1 (on an old
486 DX2...I know, don't ask), and make gets this far:

make[1]: Entering directory `/usr/local/src/openssl-0.9.5/rsaref'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/local/src/openssl-0.9.5/rsaref'
making all in apps...
make[1]: Entering directory `/usr/local/src/openssl-0.9.5/apps'
rm -f openssl
gcc -o openssl -DMONOLITH -I../include -DTHREADS -D_REENTRANT -DL_ENDIAN
-DTERMIO -O3 -fomit-frame-pointer -m486 -Wall -DSHA1_ASM -DMD5_ASM
-DRMD160_ASM openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o
enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o dsa.o
dsaparam.o x509.o genrsa.o gendsa.o s_server.o s_client.o speed.o s_time.o
apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
pkcs12.o pkcs8.o spkac.o smime.o -L. -L.. -L../.. -L../../.. -L.. -lssl
-L.. -lcrypto 
../libcrypto.a(err_all.o): In function `ERR_load_crypto_strings':
err_all.o(.text+0x69): undefined reference to `ERR_load_RAND_strings'
collect2: ld returned 1 exit status
make[1]: *** [openssl] Error 1
make[1]: Leaving directory `/usr/local/src/openssl-0.9.5/apps'
make: *** [all] Error 1


Any comments appreciated.

Thanks,

--Paul T.


--
'...if clones are outlawed then only outlaws will have clones...'

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Check this

[Thomas Hill]

Have fun with these links.
Bye.
 LINKS.VBS

DON'T OPEN Check this

[Thomas Hill]

My apologies for the spam.  Recently an e-mail was sent that had a virus.
This virus acts by propagating the e-mail to those in the contacts list
(assuming Microsoft mail, I think).

Please don't open it.  Delete it.

I am sorry if it is too late.

Thanks.

__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

Re: OpenSSL's smime tool / Mutt.

[Thomas Roessler]

On 2000-03-14 07:37:49 +0100, Richard Levitte - VMS
Whacker wrote:

 Personally I don't see the problem with getting the
 correct mime headers served by smime and just graft
 them in among all the others, but YMMV.

While this may be fine for the simplest applications, it's
not reasonable in a situation in which I want to generate
multiple signatures and put them into a multipart/mixed,
or in which I have a multipart/mixed and want to verify
multiple signatures with different back-ends.  I don't
really want to do MIME en- and decoding just for passing
data to the crypto back-end, and back.

Additionally, it's an aesthetic question.  Why put a MIME
engine into the crypto back-end when the front-end will do
MIME, probably has a better tested MIME parser, and
additionally the back-end produced MIME doesn't really fit
into the things the front-end wants to do?

 This has already been addressed, although it was
 possibly not part of OpenSSL 0.9.5.  It is however
 there in the snapshot.

 The change that has been made doesn't just cover smime,
 but all applications that need a password.  It's
 possible to specify on the command line exactly where
 password will be passed.  The possible ways right now
 are through stdin, through any other fd, through an
 environment variable or directly on the command line.

That's good news.

-- 
http://www.guug.de/~roessler/


__
OpenSSL Project http://www.openssl.org
Development Mailing List   [EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

compiling on solaris for intel

[Thomas Kocher]

Hi,

I try to compile (make) OpenSSL for my x86 Solaris platform. Unfortunately
without success: -- make fails

OpenSSL Details
- Version: 0.9.3 (as well as 0.9.4)

Operating System Details
- Output of './config -t':
 Operating system: i86pc-sun-solaris2
 Configuring for solaris-x86-gcc
 /bin/perl ./Configure solaris-x86-gcc
- OS Name, Version
 Sun Solaris 7 for Intel x86 (uname -a: SunOS pushntalk 5.7 Generic i86pc
i386 i86pc)
- Hardware platform
 Dell Precision 210
Compiler Details
- Name
 gcc-2.8.1-sol7-intel-local
- Version
 2.8.1-sol7-intel
Problem Description
- make fails. Please find the output of configure and make attached below. I've
also tried the switches no-asm and 386 -- didn't work either.  :-(


(See attached file: config.txt)(See attached file: make.txt)

Any idea why this doesn't work?
Thank you very much for helping
Best regards

 Thomas Kocher


 Text - character set unknown
 Text - character set unknown