Arpadffy Zoltan | 1 Dec 12:56 2010
Picon

VMS upgrades and OpenSSL

Hello,

this is a very much VMS related question.

I have recently noticed that a VMS executable is sensitive to VMS upgrade if statically linked with an
OpenSSL library.

OpenSSL (0.9.8.h) is build under VMS 7.3-2 and statically linked with an executable.
This runs perfect on a VMS 7.3-2 system.

When the VMS is upgraded to VMS 8.3 the very same executable fails with

SSL error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt

error message in the function SSL_CTX_use_PrivateKey_file(ctx, serverKey, SSL_FILETYPE_PEM)

Does anybody have any experience eventually a suggestion that could lead to a solution?

Thank you in advance.

Regards,
Z

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev <at> openssl.org
Automated List Manager                           majordomo <at> openssl.org

Kumaran Moodley via RT | 1 Dec 15:03 2010
Picon

RE: [openssl.org #2371] Openssl mingw build error.

Thanks Andy.

I have updated to  openssl-1.0.0b and also had a problem building the code however there is a patch available
to fix the mingw compilation issue. I tried this patch and I have had no issues. Thanks for the help.  

On another note I found a bug on the openssl EVP_PKEY_verify(3) documentation
(http://www.openssl.org/docs/crypto/EVP_PKEY_verify.html). In the synopsis the API is defined as 

int EVP_PKEY_verify(EVP_PKEY_CTX *ctx,
                        const unsigned char *sig, size_t siglen,
                        const unsigned char *tbs, size_t tbslen);

However in the example section, 

/* Perform operation */
 ret = EVP_PKEY_verify(ctx, md, mdlen, sig, siglen);

Which shows that the message digest variables and the signature variables have been swapped around. I had
some signature failures due to that however everything is fine now when I put them correctly. The
documentation should be updated though. Thanks.  

Kind regards
Kumaran M

-----Original Message-----
From: Andy Polyakov via RT [mailto:rt <at> openssl.org] 
Sent: 19 November 2010 12:57 AM
To: Kumaran Moodley
Cc: openssl-dev <at> openssl.org
Subject: Re: [openssl.org #2371] Openssl mingw build error.
(Continue reading)

Doug Kaufman | 2 Dec 07:03 2010
Picon
Picon

Re: [openssl.org #2382] Win98 mingw problem with openssl head

On Wed, 1 Dec 2010, Andy Polyakov via RT wrote:

(I said:)
> > I thought that unicows had to be linked as the first library, so I
> > manually added -lunicows at the beginning of the LIBRARIES variable in
> > apps/Makefile, after Configure had completed.
> 
> ...
>
> >> 	else /*if (GetLastError()==ERROR_NO_UNICODE_TRANSLATION)*/
> >>
> >> I'm not suggesting this a fix, just trying to understand what happens
> >> exactly.
> > 
> > This seems to make the problems go away. With this commented out, the
> > application doesn't crash. Linking with libunicows does not appear
> > necessary. For openssl.exe version -a, see the attached file
> > "version.good".
> 
> I don't quite understand what happens if you do *not* uncomment and do
> *not* link with unicows? As mentioned I'm not comfortable with removing
> the above mentioned if clause, I'd rather adjust it. The fact that it
> works is proof enough that it's actually MultiByteToWideChar that
> returned 1004 and not wfopen. So could you test
> 
> 	else if ((ret=GetLastError())==ERROR_NO_UNICODE_TRANSLATION
> 		|| ret==ERROR_INVALID_FLAGS)
> 
> You'd have to add 'DWORD ret;' declaration after #ifdef _WIN32 in the
> beginning of function. A.
(Continue reading)

dkaufman@rahul.net via RT | 2 Dec 07:08 2010
Picon

Re: [openssl.org #2382] Win98 mingw problem with openssl head

On Wed, 1 Dec 2010, Andy Polyakov via RT wrote:

(I said:)
> > I thought that unicows had to be linked as the first library, so I
> > manually added -lunicows at the beginning of the LIBRARIES variable in
> > apps/Makefile, after Configure had completed.
> 
> ...
>
> >> 	else /*if (GetLastError()==ERROR_NO_UNICODE_TRANSLATION)*/
> >>
> >> I'm not suggesting this a fix, just trying to understand what happens
> >> exactly.
> > 
> > This seems to make the problems go away. With this commented out, the
> > application doesn't crash. Linking with libunicows does not appear
> > necessary. For openssl.exe version -a, see the attached file
> > "version.good".
> 
> I don't quite understand what happens if you do *not* uncomment and do
> *not* link with unicows? As mentioned I'm not comfortable with removing
> the above mentioned if clause, I'd rather adjust it. The fact that it
> works is proof enough that it's actually MultiByteToWideChar that
> returned 1004 and not wfopen. So could you test
> 
> 	else if ((ret=GetLastError())==ERROR_NO_UNICODE_TRANSLATION
> 		|| ret==ERROR_INVALID_FLAGS)
> 
> You'd have to add 'DWORD ret;' declaration after #ifdef _WIN32 in the
> beginning of function. A.
(Continue reading)

Stefan Birrer via RT | 2 Dec 16:34 2010
Picon

[openssl.org #2386] Bug Report and Patch: Incompatible types in SKM_ASN1_SET_OF_d2i

Hi OpenSSL Devs,

I have found the following bug in crypto/stack/safestack.h:

The macro SKM_ASN1_SET_OF_d2i (crypto/stack/safestack.h: 181ff) expects a pointer to a
STACK_OF(type) as the second argument. A pointer to a pointer
to a STACK_OF(type) would be appropriate though. Consequently, the compiler reports an error if you call
one of the d2i_ASN1_SET_OF_≤TYPE> macros with
a pointer to a pointer to a STACK_OF(type).

The applied patch fixes this bug.

Cheers,
Stefan Birrer

--

-- 

 AdNovum Informatik AG
 Stefan Birrer, Software Engineer
 Dipl. Informatik-Ing. ETH

 Roentgenstrasse 22, CH-8005 Zurich
 mailto:stefan.birrer <at> adnovum.ch
 phone: +41 44 272 6111, fax: +41 44 272 6312
 http://www.adnovum.ch

 AdNovum Offices: Bern, Budapest, Singapore, Zurich (HQ)

(Continue reading)

Stefan Birrer via RT | 2 Dec 17:24 2010
Picon

ERRATA [openssl.org #2386] AutoReply: Bug Report and Patch: Incompatible types in SKM_ASN1_SET_OF_d2i

The suggested patch in my previous message was incorrect. Please find the corrected version attached.

Kind regards,
Stefan Birrer

On 2010-12-02 16:34, The default queue via RT wrote:
> 
> Greetings,
> 
> This message has been automatically generated in response to the
> creation of a trouble ticket regarding:
> 	"Bug Report and Patch: Incompatible types in SKM_ASN1_SET_OF_d2i", 
> a summary of which appears below.
> 
> There is no need to reply to this message right now.  Your ticket has been
> assigned an ID of [openssl.org #2386].
> 
> Please include the string:
> 
>          [openssl.org #2386]
> 
> in the subject line of all future correspondence about this issue. To do so, 
> you may reply to this message.
> 
>                         Thank you,
>                         rt <at> openssl.org
> 
> -------------------------------------------------------------------------
> Hi OpenSSL Devs,
> 
(Continue reading)

Arpadffy Zoltan | 2 Dec 17:45 2010
Picon

RE: VMS upgrades and OpenSSL

Hello,

Meanwhile the problem is solved... all this is caused by the new C-RTL that handles wrong programming
habits on a different way, like non initialized variables are not memsetted etc.
In one word: this is not an OpenSSL issue.

However, what is interesting that using session cache caused also problems in the multithreaded (AST)
network application running under VMS 8.3, therefore it was needed to turn off (SSL_SESS_CACHE_OFF)

Regards,
Z

-----Original Message-----
From: Arpadffy Zoltan [mailto:Zoltan.Arpadffy <at> scientificgames.se]
Sent: den 1 december 2010 12:56
To: openssl-dev <at> openssl.org
Subject: VMS upgrades and OpenSSL

Hello,

this is a very much VMS related question.

I have recently noticed that a VMS executable is sensitive to VMS upgrade if statically linked with an
OpenSSL library.

OpenSSL (0.9.8.h) is build under VMS 7.3-2 and statically linked with an executable.
This runs perfect on a VMS 7.3-2 system.

When the VMS is upgraded to VMS 8.3 the very same executable fails with

(Continue reading)

OpenSSL | 2 Dec 20:17 2010
Picon

OpenSSL 1.0.0c released


   OpenSSL version 1.0.0c released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 1.0.0c of our open source toolkit for SSL/TLS. This new
   OpenSSL version is a security and bugfix release. For a complete
   list of changes, please see

       http://www.openssl.org/source/exp/CHANGES.

   The most significant changes are:

      o Fix for security issue CVE-2010-4180
      o Fix for CVE-2010-4252
      o Fix mishandling of absent EC point format extension.
      o Fix various platform compilation issues.
      o Corrected fix for security issue CVE-2010-3864.

   We consider OpenSSL 1.0.0c to be the best version of OpenSSL
   available and we strongly recommend that users of older versions
   upgrade as soon as possible. OpenSSL 1.0.0c is available for
   download via HTTP and FTP from the following master locations (you
   can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

     * http://www.openssl.org/source/
(Continue reading)

OpenSSL | 2 Dec 20:18 2010
Picon

OpenSSL security advisory


OpenSSL Security Advisory [2 December 2010]

OpenSSL Ciphersuite Downgrade Attack
=====================================

A flaw has been found in the OpenSSL SSL/TLS server code where an old bug
workaround allows malicous clients to modify the stored session cache
ciphersuite. In some cases the ciphersuite can be downgraded to a weaker one
on subsequent connections.

The OpenSSL security team would like to thank Martin Rex for reporting this
issue.

This vulnerability is tracked as CVE-2010-4180

OpenSSL JPAKE validation error
===============================

Sebastian Martini found an error in OpenSSL's J-PAKE implementation
which could lead to successful validation by someone with no knowledge
of the shared secret. This error is fixed in 1.0.0c. Details of the
problem can be found here:

http://seb.dbzteam.org/crypto/jpake-session-key-retrieval.pdf

Note that the OpenSSL Team still consider our implementation of J-PAKE
to be experimental and is not compiled by default.

This issue is tracked as CVE-2010-4252 
(Continue reading)

OpenSSL | 2 Dec 20:17 2010
Picon

OpenSSL 0.9.8q released


   OpenSSL version 0.9.8q released
   ===============================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   The OpenSSL project team is pleased to announce the release of
   version 0.9.8q of our open source toolkit for SSL/TLS. This new
   OpenSSL version is a security and bugfix release. For a complete
   list of changes, please see

       http://www.openssl.org/source/exp/CHANGES.

   The most significant changes are:

      o Fix for security issue CVE-2010-4180
      o Fix for CVE-2010-4252

   We consider OpenSSL 0.9.8q to be the best version of OpenSSL
   available and we strongly recommend that users of older versions
   upgrade as soon as possible. OpenSSL 0.9.8q is available for
   download via HTTP and FTP from the following master locations (you
   can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

     * http://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:
(Continue reading)


Gmane