From nounou.dadoun at avigilon.com  Tue Mar  1 00:38:20 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Tue, 1 Mar 2016 00:38:20 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160229234659.GA7477@roeckx.be>
References: <20160228125750.GA29658@openssl.org>
 <8149AB08BCB1F54F92680ED6104891A0E18DB3@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>
 <20160229234659.GA7477@roeckx.be>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E18F06@mbx027-w1-ca-4.exch027.domain.local>

Is it sufficient to change -O3 to -O2 it in the Configure file or is there somewhere else it needs to be changed?


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
Sent: Monday, February 29, 2016 3:47 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Mon, Feb 29, 2016 at 10:48:22PM +0000, Nounou Dadoun wrote:
> But this demonstrates that my headaches have been coming from the fact that sha384 and sha512 are broken in our build somehow.  The no-asm configure directive didn't make a difference so maybe a compiler bug or something?

I'm assuming you build using -O3.  Can you try different levels?
I don't know of any problems on Debian using -O2.

From atulthosar at gmail.com  Tue Mar  1 04:12:45 2016
From: atulthosar at gmail.com (Atul Thosar)
Date: Tue, 1 Mar 2016 09:42:45 +0530
Subject: [openssl-users] OpenSSL 1.0.2f build issue - unresolved
	external symbol
In-Reply-To: <CAKT7MpohhOCctKUA4av_BVgiOudMCQHKQAuaN3BFRq=6QZea8A@mail.gmail.com>
References: <CAKT7MpohhOCctKUA4av_BVgiOudMCQHKQAuaN3BFRq=6QZea8A@mail.gmail.com>
Message-ID: <CAKT7MprD7e=PB0=gzyjFowJmkrj12JzqMcA7ek+826Ai5i5AZA@mail.gmail.com>

Any thoughts/pointers?
Including openssl-users group in hope if any one aware of this issue.


--
?BR
,
Atul Thosar


On 29 February 2016 at 00:15, Atul Thosar <atulthosar at gmail.com> wrote:

> Hi All,
> I am building OpenSSL v1.0.2f for Win32 platform, but compilation failed
> w/ following errors. I googled a bit, but could not locate the exact
> cause. Appreciate if anyone could help. Thanks in Advance.
>
> rc /fo"tmp32dll\libeay32.res" /d CRYPTO ms\version32.rc
> link /nologo /subsystem:console /opt:ref /debug /dll
> /out:out32dll\libeay32.dll /def:ms/LIBEAY32.def
> @C:\Users\athosar\AppData\Local\Temp\nm43EB.tmp
> Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp
> cryptlib.obj : error LNK2001: unresolved external symbol _OPENSSL_ia32cap_P
> cryptlib.obj : error LNK2019: unresolved external symbol
> _OPENSSL_ia32_cpuid referenced in function _OPENSSL_cpuid_setup
> md5_dgst.obj : error LNK2019: unresolved external symbol
> _md5_block_asm_data_order referenced in function _MD5_Update
> sha1dgst.obj : error LNK2019: unresolved external symbol
> _sha1_block_data_order referenced in function _SHA1_Update
> sha256.obj : error LNK2019: unresolved external symbol
> _sha256_block_data_order referenced in function _SHA256_Update
> sha512.obj : error LNK2019: unresolved external symbol
> _sha512_block_data_order referenced in function _SHA512_Final
>
> out32dll\libeay32.dll : fatal error LNK1120: 6 unresolved externals
> NMAKE : fatal error U1077: '"c:\Program Files (x86)\Microsoft Visual
> Studio 8\VC\BIN\link.EXE"' : return code '0x460'
> Stop.
>
>
> Build machine configurations are -
>
> OS: Windows 7, 64 bit
> Compiler: Visual Studio 2005
> Active Perl Version: v5.16.3
>
> Initial commands given to configure OpenSSL are -
>
> perl Configure VC-WIN32 no-asm --prefix=<Path to bin directory>
> ms\do_ms
> nmake -f ms\ntdll.mak
>
>
> --
> ?BR,
> Atul Thosar
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160301/332749a9/attachment.html>

From kurt at roeckx.be  Tue Mar  1 08:16:29 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 1 Mar 2016 09:16:29 +0100
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E18F06@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>
 <20160229234659.GA7477@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18F06@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160301081628.GA15024@roeckx.be>

On Tue, Mar 01, 2016 at 12:38:20AM +0000, Nounou Dadoun wrote:
> Is it sufficient to change -O3 to -O2 it in the Configure file or is there somewhere else it needs to be changed?

Yes, in Configure should be enough.


Kurt


From openssl at openssl.org  Tue Mar  1 14:03:02 2016
From: openssl at openssl.org (OpenSSL)
Date: Tue, 1 Mar 2016 14:03:02 +0000
Subject: [openssl-users] OpenSSL version 1.0.1s published
Message-ID: <20160301140302.GA6668@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.1s 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.1s of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.1-notes.html

   OpenSSL 1.0.1s 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:

    o openssl-1.0.1s.tar.gz
      Size: 4551210
      SHA1 checksum: d027e1a00c26da7fede7d537d5c7718c3cdb4653
      SHA256 checksum: e7e81d82f3cd538ab0cdba494006d44aab9dd96b7f6233ce9971fb7c7916d511

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.1s.tar.gz
    openssl sha256 openssl-1.0.1s.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJW1ZviAAoJENnE0m0OYESRVY8H/javcOAnFG3l1uzYuSrcgHrA
52x/A5gqFOW7rx5KE4jUjahSFePpNahqaR+A9m8dte2pvAJIySSk73z1IChhrtkF
14CALui+okl0KolF098sULmBy/GKoRQmiGMqQHxukXZZ8ihiqtfiEX1yCf0CiH8U
crE4fHw50hBRV8BeT8KEE6A29Cpi9LQ0b0I3pPl5k/q0DtkdyNYMRcA7JKrSsI72
X/tyJcHaoAEZaBoVCqdlj/G1qOA/YlDtNfa9lkMZQaLz8wFLlZTo8/obuonVmaPH
uJRj3oylvVkGWYIOpq+7jTJxjHlJweRrKbU8+W//rCSPNfbPBvAAQS7q9lKz/SA=
=3wfG
-----END PGP SIGNATURE-----

From openssl at openssl.org  Tue Mar  1 14:03:14 2016
From: openssl at openssl.org (OpenSSL)
Date: Tue, 1 Mar 2016 14:03:14 +0000
Subject: [openssl-users] OpenSSL version 1.0.2g published
Message-ID: <20160301140314.GA6870@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.0.2g 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.2g of our open source toolkit for SSL/TLS. For details
   of changes and known issues see the release notes at:

        http://www.openssl.org/news/openssl-1.0.2-notes.html

   OpenSSL 1.0.2g 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:

    o openssl-1.0.2g.tar.gz
      Size: 5266102
      SHA1 checksum: 36af23887402a5ea4ebef91df8e61654906f58f2
      SHA256 checksum: b784b1b3907ce39abf4098702dade6365522a253ad1552e267a9a0e89594aa33

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.0.2g.tar.gz
    openssl sha256 openssl-1.0.2g.tar.gz

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJW1Zr6AAoJENnE0m0OYESRegcH/RzJkSQo2TT7wl55DKd5/7a2
3PaUxlNQOxA7E1Z7DAs9rfhox0+GbqaIOASBP+yVyP1+yHafMPuM3mpIQNg1fwT8
Oaxfh84a3XpfNO76xVWoKrgp62jYOaug2kfpnJ53uQuBqbhkjCW48KCxBELQZr9Q
CsMy3SHtVwNfQQbOTDEsTjPFRpJ4UYO0EUtLV11Q78Gq4cxwWmOB0UCKJ/ucpUcl
K8750Ijz27tWUK2cLOjJPAKQBaz1Rol8k0hZC0/Gtgiq/u+IFlx17HU3Yc2ZjLWu
Op4KQ95vNu1icTxKUxfz4af3f/XEvC4ZjEC/2dMfUxy/zktLR4yRoG//xi7v8bg=
=ovbL
-----END PGP SIGNATURE-----

From openssl at openssl.org  Tue Mar  1 14:05:39 2016
From: openssl at openssl.org (OpenSSL)
Date: Tue, 1 Mar 2016 14:05:39 +0000
Subject: [openssl-users] OpenSSL Security Advisory
Message-ID: <20160301140539.GA9602@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenSSL Security Advisory [1st March 2016]
=========================================

NOTE: With this update, OpenSSL is disabling the SSLv2 protocol by default, as
well as removing SSLv2 EXPORT ciphers.  We strongly advise against the use of
SSLv2 due not only to the issues described below, but to the other known
deficiencies in the protocol as described at
https://tools.ietf.org/html/rfc6176


Cross-protocol attack on TLS using SSLv2 (DROWN) (CVE-2016-0800)
================================================================

Severity: High

A cross-protocol attack was discovered that could lead to decryption of TLS
sessions by using a server supporting SSLv2 and EXPORT cipher suites as a
Bleichenbacher RSA padding oracle.  Note that traffic between clients and
non-vulnerable servers can be decrypted provided another server supporting
SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or
POP) shares the RSA keys of the non-vulnerable server. This vulnerability is
known as DROWN (CVE-2016-0800).

Recovering one session key requires the attacker to perform approximately 2^50
computation, as well as thousands of connections to the affected server. A more
efficient variant of the DROWN attack exists against unpatched OpenSSL servers
using versions that predate 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf released on
19/Mar/2015 (see CVE-2016-0703 below).

Users can avoid this issue by disabling the SSLv2 protocol in all their SSL/TLS
servers, if they've not done so already. Disabling all SSLv2 ciphers is also
sufficient, provided the patches for CVE-2015-3197 (fixed in OpenSSL 1.0.1r and
1.0.2f) have been deployed.  Servers that have not disabled the SSLv2 protocol,
and are not patched for CVE-2015-3197 are vulnerable to DROWN even if all SSLv2
ciphers are nominally disabled, because malicious clients can force the use of
SSLv2 with EXPORT ciphers.

OpenSSL 1.0.2g and 1.0.1s deploy the following mitigation against DROWN:

SSLv2 is now by default disabled at build-time.  Builds that are not configured
with "enable-ssl2" will not support SSLv2.  Even if "enable-ssl2" is used,
users who want to negotiate SSLv2 via the version-flexible SSLv23_method() will
need to explicitly call either of:

   SSL_CTX_clear_options(ctx, SSL_OP_NO_SSLv2);
   or
   SSL_clear_options(ssl, SSL_OP_NO_SSLv2);

as appropriate.  Even if either of those is used, or the application explicitly
uses the version-specific SSLv2_method() or its client or server variants,
SSLv2 ciphers vulnerable to exhaustive search key recovery have been removed.
Specifically, the SSLv2 40-bit EXPORT ciphers, and SSLv2 56-bit DES are no
longer available.

In addition, weak ciphers in SSLv3 and up are now disabled in default builds of
OpenSSL.  Builds that are not configured with "enable-weak-ssl-ciphers" will
not provide any "EXPORT" or "LOW" strength ciphers.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on December 29th 2015 by Nimrod Aviram and
Sebastian Schinzel. The fix was developed by Viktor Dukhovni and Matt Caswell
of OpenSSL.


Double-free in DSA code (CVE-2016-0705)
=======================================

Severity: Low

A double free bug was discovered when OpenSSL parses malformed DSA private keys
and could lead to a DoS attack or memory corruption for applications that
receive DSA private keys from untrusted sources.  This scenario is considered
rare.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on February 7th 2016 by Adam Langley
(Google/BoringSSL) using libFuzzer. The fix was developed by Dr Stephen Henson
of OpenSSL.


Memory leak in SRP database lookups (CVE-2016-0798)
===================================================

Severity: Low

The SRP user database lookup method SRP_VBASE_get_by_user had
confusing memory management semantics; the returned pointer was sometimes newly
allocated, and sometimes owned by the callee. The calling code has no way of
distinguishing these two cases.

Specifically, SRP servers that configure a secret seed to hide valid
login information are vulnerable to a memory leak: an attacker
connecting with an invalid username can cause a memory leak of around
300 bytes per connection.  Servers that do not configure SRP, or
configure SRP but do not configure a seed are not vulnerable.

In Apache, the seed directive is known as SSLSRPUnknownUserSeed.

To mitigate the memory leak, the seed handling in
SRP_VBASE_get_by_user is now disabled even if the user has configured
a seed.  Applications are advised to migrate to
SRP_VBASE_get1_by_user. However, note that OpenSSL makes no strong
guarantees about the indistinguishability of valid and invalid
logins. In particular, computations are currently not carried out in
constant time.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was discovered on February 23rd 2016 by Emilia K??sper of
the OpenSSL development team. Emilia K??sper also developed the fix.


BN_hex2bn/BN_dec2bn NULL pointer deref/heap corruption (CVE-2016-0797)
======================================================================

Severity: Low

In the BN_hex2bn function the number of hex digits is calculated using an int
value |i|. Later |bn_expand| is called with a value of |i * 4|. For large values
of |i| this can result in |bn_expand| not allocating any memory because |i * 4|
is negative. This can leave the internal BIGNUM data field as NULL leading to a
subsequent NULL ptr deref. For very large values of |i|, the calculation |i * 4|
could be a positive value smaller than |i|. In this case memory is allocated to
the internal BIGNUM data field, but it is insufficiently sized leading to heap
corruption. A similar issue exists in BN_dec2bn. This could have security
consequences if BN_hex2bn/BN_dec2bn is ever called by user applications with
very large untrusted hex/dec data. This is anticipated to be a rare occurrence.

All OpenSSL internal usage of these functions use data that is not expected to
be untrusted, e.g. config file data or application command line arguments. If
user developed applications generate config file data based on untrusted data
then it is possible that this could also lead to security consequences. This is
also anticipated to be rare.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on February 19th 2016 by Guido Vranken.  The
fix was developed by Matt Caswell of the OpenSSL development team.

Fix memory issues in BIO_*printf functions (CVE-2016-0799)
==========================================================

Severity: Low

The internal |fmtstr| function used in processing a "%s" format string in the
BIO_*printf functions could overflow while calculating the length of a string
and cause an OOB read when printing very long strings.

Additionally the internal |doapr_outch| function can attempt to write to an OOB
memory location (at an offset from the NULL pointer) in the event of a memory
allocation failure. In 1.0.2 and below this could be caused where the size of a
buffer to be allocated is greater than INT_MAX. E.g. this could be in processing
a very long "%s" format string. Memory leaks can also occur.

The first issue may mask the second issue dependent on compiler behaviour.
These problems could enable attacks where large amounts of untrusted data is
passed to the BIO_*printf functions. If applications use these functions in this
way then they could be vulnerable. OpenSSL itself uses these functions when
printing out human-readable dumps of ASN.1 data. Therefore applications that
print this data could be vulnerable if the data is from untrusted sources.
OpenSSL command line applications could also be vulnerable where they print out
ASN.1 data, or if untrusted data is passed as command line arguments.

Libssl is not considered directly vulnerable. Additionally certificates etc
received via remote connections via libssl are also unlikely to be able to
trigger these issues because of message size limits enforced within libssl.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on February 23rd by Guido Vranken.  The
fix was developed by Matt Caswell of the OpenSSL development team.

Side channel attack on modular exponentiation (CVE-2016-0702)
=============================================================

Severity: Low

A side-channel attack was found which makes use of cache-bank conflicts on the
Intel Sandy-Bridge microarchitecture which could lead to the recovery of RSA
keys.  The ability to exploit this issue is limited as it relies on an attacker
who has control of code in a thread running on the same hyper-threaded core as
the victim thread which is performing decryptions.

This issue affects OpenSSL versions 1.0.2 and 1.0.1.

OpenSSL 1.0.2 users should upgrade to 1.0.2g
OpenSSL 1.0.1 users should upgrade to 1.0.1s

This issue was reported to OpenSSL on Jan 8th 2016 by Yuval Yarom, The
University of Adelaide and NICTA, Daniel Genkin, Technion and Tel Aviv
University, and Nadia Heninger, University of Pennsylvania with more
information at http://cachebleed.info.  The fix was developed by Andy Polyakov
of OpenSSL.


Divide-and-conquer session key recovery in SSLv2 (CVE-2016-0703)
================================================================

Severity: High

This issue only affected versions of OpenSSL prior to March 19th 2015 at which
time the code was refactored to address vulnerability CVE-2015-0293.

s2_srvr.c did not enforce that clear-key-length is 0 for non-export ciphers. If
clear-key bytes are present for these ciphers, they *displace* encrypted-key
bytes. This leads to an efficient divide-and-conquer key recovery attack: if an
eavesdropper has intercepted an SSLv2 handshake, they can use the server as an
oracle to determine the SSLv2 master-key, using only 16 connections to the
server and negligible computation.

More importantly, this leads to a more efficient version of DROWN that is
effective against non-export ciphersuites, and requires no significant
computation.

This issue affected OpenSSL versions 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze and all
earlier versions.  It was fixed in OpenSSL 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf
(released March 19th 2015).

This issue was reported to OpenSSL on February 10th 2016 by David Adrian and J.
Alex Halderman of the University of Michigan.  The underlying defect had by
then already been fixed by Emilia K??sper of OpenSSL on March 4th 2015.  The fix
for this issue can be identified by commits ae50d827 (1.0.2a), cd56a08d
(1.0.1m), 1a08063 (1.0.0r) and 65c588c (0.9.8zf).


Bleichenbacher oracle in SSLv2 (CVE-2016-0704)
==============================================

Severity: Moderate

This issue only affected versions of OpenSSL prior to March 19th 2015 at which
time the code was refactored to address the vulnerability CVE-2015-0293.

s2_srvr.c overwrite the wrong bytes in the master-key when applying
Bleichenbacher protection for export cipher suites.  This provides a
Bleichenbacher oracle, and could potentially allow more efficient variants of
the DROWN attack.

This issue affected OpenSSL versions 1.0.2, 1.0.1l, 1.0.0q, 0.9.8ze and all
earlier versions.  It was fixed in OpenSSL 1.0.2a, 1.0.1m, 1.0.0r and 0.9.8zf
(released March 19th 2015).

This issue was reported to OpenSSL on February 10th 2016 by David Adrian and J.
Alex Halderman of the University of Michigan.  The underlying defect had by
then already been fixed by Emilia K??sper of OpenSSL on March 4th 2015.  The fix
for this issue can be identified by commits ae50d827 (1.0.2a), cd56a08d
(1.0.1m), 1a08063 (1.0.0r) and 65c588c (0.9.8zf).

Note
====

As per our previous announcements and our Release Strategy
(https://www.openssl.org/policies/releasestrat.html), support for OpenSSL
version 1.0.1 will cease on 31st December 2016. No security updates for that
version will be provided after that date. Users of 1.0.1 are advised to
upgrade.

Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those
versions are no longer receiving security updates.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20160301.txt

Note: the online version of the advisory may be updated with additional details
over time.

For details of OpenSSL severity classifications please see:
https://www.openssl.org/policies/secpolicy.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJW1Z3XAAoJENnE0m0OYESRFCgH/1UW63/q8J2eApcMxOd7oYcD
y0yRRD1SNpbTalYTNRGK2e4VY4iq7ux8ps3Bw9ieTYcRlMqqcHOPjsPEht0oVyZJ
nYBfqwkISjRPYDn4mcV+DUsqLqNhakLZsMbkm0DY6GXq/pxolYlNN07NfsKP7WaQ
1Ff9OkVxhuXYZ+6RmbOAt4+61+CggPIpnBNS8B9U6howG9xOLEWo7ELjXlbBHGny
W8Jfmc3z4/UlY/f9iod9qYxo1ljNAhQ8Jd+IcNUuOXea15+S8g35AJR42vLVVzyo
jQH7vxNqmwqxrQNUHkAVgXNTLsSMJ4vQ4gCHZEe2CAU9xUt8ifeJrIOjxgjAFvI=
=7baS
-----END PGP SIGNATURE-----

From Michal.Trojnara at stunnel.org  Tue Mar  1 16:23:33 2016
From: Michal.Trojnara at stunnel.org (Michal Trojnara)
Date: Tue, 1 Mar 2016 17:23:33 +0100
Subject: [openssl-users] stunnel 5.31 released
Message-ID: <56D5C205.5030409@stunnel.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear Users,

I have released version 5.31 of stunnel.

The ChangeLog entry:

Version 5.31, 2016.03.01, urgency: HIGH
* Security bugfixes
  - OpenSSL DLLs updated to version 1.0.2g.
    https://www.openssl.org/news/secadv_20160301.txt
* New features
  - Added logging the list of client CAs requested by the server.
  - Improved compatibility with the current OpenSSL 1.1.0-dev tree.
* Bugfixes
  - Only reset the watchdog if some data was actually transferred.
  - A workaround implemented for the unexpected exceptfds set by
    select() on WinCE 6.0 (thx to Richard Kraemer).

Home page: https://www.stunnel.org/
Download:  https://www.stunnel.org/downloads.html

SHA-256 hashes:
a746b71ab3dc6c23eacb0daf7342467870e43ac933430905eb1b1d050bbae0b7
stunnel-5.31.tar.gz
c662fc1254f22ce5ac3f6e09bf643b3a0a99a884b6414f55cc8ab22d7c680fd5
stunnel-5.31-installer.exe
f14d7c9cf23a25bdcef8480f9d35c66233bb9e64f82098f1867edf4b038b41c4
stunnel-5.31-android.zip

Best regards,
    Mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJW1cIFAAoJEC78f/DUFuAU998P/1LpUY+B/Q4E7XWCctK1XspG
zcFi8U5UhaMek9eTPlY0mJWUGihX4qQOeQi+9MV9LqvzLLfWbgMzWSv/rAiWxCzx
NbHw7yASK5+xfnGBGoSenvdbvmL6s4RPxM0Qf3lrVj9kpha75JS9aHPnDhq90aLG
YXle0uTj/dvDC3aG2UY0TYFQMvvubrx87JyoiTbf9i2f6q85iM76DaeP15mMZSXZ
eq+9bP37OVG6RDFrlFSoSSHxOWHA5ebftwvf4MjedrziXld6pzYSzwIJ7eJhZO7Y
ob+hRO3D86chiGfynYj1WWws51Q+TE4hg2NQ7vWPEi7HuN+/62CMZg3q1h/LAIT+
2qzjVFIoVwwl8B3RZ94aJ8AzsFnhWOp5AZJ7nOBFbF69cRAuIT6DQL+GwcJoB+RJ
+sxlJAyhu+3/RuAPbZYXzSzr7Lsp4/fhWIxVRW5rBqHSJCBZU+QqSOTu9GP06F9i
7FaUq9p7RxajVjtqn+QmzDpVTgBymkYvc3F1+ATSUZZNLU8KPWG+aYTtSYKKEDQS
VBtQJ3BRR0Ne/TqBXStdK3PdG8t8r7hoYhPSAE1IX59F0/4MaKHcAoyDEAH5aKQx
rK1Iowb5DUNF/Rcota3CXzLFBfp/ePmZFbjpQd9YcGtMXnMGFk9/Lnc+8If+vHGk
p66Kx7ZYLNzkIPf0y8wn
=WkNw
-----END PGP SIGNATURE-----

From nounou.dadoun at avigilon.com  Tue Mar  1 18:07:23 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Tue, 1 Mar 2016 18:07:23 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160301081628.GA15024@roeckx.be>
References: <8149AB08BCB1F54F92680ED6104891A0E18DCA@mbx027-w1-ca-4.exch027.domain.local>
 <20160229202327.GA29289@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>
 <20160229234659.GA7477@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18F06@mbx027-w1-ca-4.exch027.domain.local>
 <20160301081628.GA15024@roeckx.be>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E19039@mbx027-w1-ca-4.exch027.domain.local>

I changed it to -O2 and got exactly the same result for the sha512t test ... N

Nou Dadoun
Senior Firmware Developer, Security Specialist

Office: 604.629.5182 ext 2632 
Support: 888.281.5182 ?|? avigilon.com

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
Sent: Tuesday, March 01, 2016 12:16 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Tue, Mar 01, 2016 at 12:38:20AM +0000, Nounou Dadoun wrote:
> Is it sufficient to change -O3 to -O2 it in the Configure file or is there somewhere else it needs to be changed?

Yes, in Configure should be enough.

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

From Andrew_Porter at bmc.com  Tue Mar  1 18:03:14 2016
From: Andrew_Porter at bmc.com (Porter, Andrew)
Date: Tue, 1 Mar 2016 18:03:14 +0000
Subject: [openssl-users] OpenSSL 1.0.1s-fips tests failing
Message-ID: <2fa7f59eef054498becd8af064074e4d@phx-exmbprd-02.adprod.bmc.com>

Building today's 1.0.1s release with FIPS 2.0.8 failed tests for me at the test_ssl step with a not-surprising "test ssl2 is forbidden in FIPS mode". Tests ran fine for 1.0.1r a couple of weeks ago.

Is there a simple way for me to fix this?

Andrew

From Andrew_Porter at bmc.com  Tue Mar  1 18:50:28 2016
From: Andrew_Porter at bmc.com (Porter, Andrew)
Date: Tue, 1 Mar 2016 18:50:28 +0000
Subject: [openssl-users] OpenSSL 1.0.1s-fips build failing in tests step
Message-ID: <ef4a4cee8eb442daa3316d7f339203f0@phx-exmbprd-02.adprod.bmc.com>

I'm building today's 1.0.1s release with FIPS 2.0.8 and "make test" is failing at the test_ssl step, it correctly says "test ssl3 is forbidden in FIPS mode" but then stops testing with the output

47323521796064:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1720:
47323521796064:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in fips mode:ssl_lib.c:1720:
test ssl2 is forbidden in FIPS mode
Testing was requested for a disabled protocol. Skipping tests.
make[1]: *** [test_ssl] Error 1

The previous 1.0.1r release passed tests just fine, is there an easy way for me to fix this?

Thanks,

Andrew

From kurt at roeckx.be  Tue Mar  1 18:57:41 2016
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 1 Mar 2016 19:57:41 +0100
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E19039@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E18DED@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>
 <20160229234659.GA7477@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18F06@mbx027-w1-ca-4.exch027.domain.local>
 <20160301081628.GA15024@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E19039@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <20160301185740.GA1530@roeckx.be>

And using -O0?

Which version of openssl are you using?


Kurt

On Tue, Mar 01, 2016 at 06:07:23PM +0000, Nounou Dadoun wrote:
> I changed it to -O2 and got exactly the same result for the sha512t test ... N
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist
> 
> Office: 604.629.5182 ext 2632 
> Support: 888.281.5182 ?|? avigilon.com
> 
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Kurt Roeckx
> Sent: Tuesday, March 01, 2016 12:16 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature
> 
> On Tue, Mar 01, 2016 at 12:38:20AM +0000, Nounou Dadoun wrote:
> > Is it sufficient to change -O3 to -O2 it in the Configure file or is there somewhere else it needs to be changed?
> 
> Yes, in Configure should be enough.
> 
> Kurt
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 

From openssl-users at dukhovni.org  Tue Mar  1 19:45:02 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 1 Mar 2016 19:45:02 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160301185740.GA1530@roeckx.be>
References: <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>
 <20160229234659.GA7477@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18F06@mbx027-w1-ca-4.exch027.domain.local>
 <20160301081628.GA15024@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E19039@mbx027-w1-ca-4.exch027.domain.local>
 <20160301185740.GA1530@roeckx.be>
Message-ID: <20160301194501.GM12869@mournblade.imrryr.org>

On Tue, Mar 01, 2016 at 07:57:41PM +0100, Kurt Roeckx wrote:

> And using -O0?
> 
> Which version of openssl are you using?

IIRC the upthread posts said 1.0.2d on the server.  Check the list
archive.

-- 
	Viktor.

From nounou.dadoun at avigilon.com  Tue Mar  1 20:16:48 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Tue, 1 Mar 2016 20:16:48 +0000
Subject: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with
 error 67702888--bad signature
In-Reply-To: <20160301194501.GM12869@mournblade.imrryr.org>
References: <8149AB08BCB1F54F92680ED6104891A0E18E02@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18E46@mbx027-w1-ca-4.exch027.domain.local>
 <20160229213505.GA4202@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18E6D@mbx027-w1-ca-4.exch027.domain.local>
 <8149AB08BCB1F54F92680ED6104891A0E18EB2@mbx027-w1-ca-4.exch027.domain.local>
 <20160229234659.GA7477@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E18F06@mbx027-w1-ca-4.exch027.domain.local>
 <20160301081628.GA15024@roeckx.be>
 <8149AB08BCB1F54F92680ED6104891A0E19039@mbx027-w1-ca-4.exch027.domain.local>
 <20160301185740.GA1530@roeckx.be>
 <20160301194501.GM12869@mournblade.imrryr.org>
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E19126@mbx027-w1-ca-4.exch027.domain.local>

Exactly the same results, failed as before.  Viktor is correct - 1.0.2d

Thanks; let me know if a dump trace would be useful .. N


Nou Dadoun
Senior Firmware Developer, Security Specialist


Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni
Sent: Tuesday, March 01, 2016 11:45 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Failed TLSv1.2 handshake with error 67702888--bad signature

On Tue, Mar 01, 2016 at 07:57:41PM +0100, Kurt Roeckx wrote:

> And using -O0?
> 
> Which version of openssl are you using?

IIRC the upthread posts said 1.0.2d on the server.  Check the list archive.

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

From jlbrown at bordo.com.au  Wed Mar  2 03:01:58 2016
From: jlbrown at bordo.com.au (James Brown)
Date: Wed, 2 Mar 2016 14:01:58 +1100
Subject: [openssl-users] OpenSSL 1.0.2g compile fails on OS X 10.11.3 - make
	depend: Command not found
Message-ID: <9B7ACD5D-D520-4718-BE4E-7321C835F410@bordo.com.au>

Had no problems compiling on earlier versions of OS X, but on 10.11 I get:


Configured for darwin64-x86_64-cc.

*** Because of configuration changes, you MUST do the following before
*** building:

	make depend
Web-Server:openssl-1.0.2g jlbrown$ make depend
making depend in crypto...
../util/domd: line 31: makedepend: command not found
mv: Makefile.new: No such file or directory
make[1]: *** [local_depend] Error 127
make: *** [depend] Error 1

after running:

./Configure --prefix=/usr/local shared darwin64-x86_64-cc enable-ec_nistp_64_gcc_128 no-ssl2


Shall I follow the recommendation at:

http://comments.gmane.org/gmane.comp.encryption.openssl.user/47242

and change the MAKEDEPPROG=makedepend to MAKEDEPPROG=$(CC) -M

?

Thanks,

James.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160302/a2f64eb2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3630 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160302/a2f64eb2/attachment-0001.bin>

From thirumalkumarkanakurthi at bel.co.in  Wed Mar  2 08:36:56 2016
From: thirumalkumarkanakurthi at bel.co.in (thirumalkumarkanakurthi at bel.co.in)
Date: Wed, 2 Mar 2016 14:06:56 +0530
Subject: [openssl-users] Developing CA with Openssl library
Message-ID: <c9b32ed6993fefd9bb9de8a23b545709.squirrel@mail.bel.co.in>




Dear users,
?I want to develop my own CA with openssl
library with all the CA functionalities like Key generation,Certificate
creation,Certificate Revocation List creation,Certificate revocation and
certificate verification.in Order to do so i am struct with the following
questions

1. currently i am using openssl_1_0_1 stable version.
With this version is it possible to perform the above operations.
2.
Will above mentioned version provide full CA CRL functionalities.
?please help me? with your valuable suggestions and solutions.
Thanks in advance.

Regards
Thirumal Kumar Kanakurthi
Member (Research Staff)/NWS Group
Central Research
Laboratory(BEL).
Bangalore.
Mobile:+918050469976


Every Sheets of paper is made from a tree.. Save trees... Conserve Trees.... Go Green .... Don't print this email or any Files unless you really need to!!!!  
Confidentiality Notice 
The information contained in this electronic message and any attachments to this 
message are intended for the exclusive use of the addressee(s) and may contain 
confidential or privileged information. If  you are not the intended recipient, 
 please notify the sender at Bharat Electronics  or support at bel.co.in 
immediately and destroy all copies of this message and any attachments. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160302/4d310ed0/attachment.html>

From michel.sales at free.fr  Wed Mar  2 10:06:26 2016
From: michel.sales at free.fr (Michel)
Date: Wed, 2 Mar 2016 11:06:26 +0100
Subject: [openssl-users] Developing CA with Openssl library
In-Reply-To: <c9b32ed6993fefd9bb9de8a23b545709.squirrel@mail.bel.co.in>
References: <c9b32ed6993fefd9bb9de8a23b545709.squirrel@mail.bel.co.in>
Message-ID: <002101d1746b$2f131f00$8d395d00$@sales@free.fr>

Hi,

 

Just a suggestion : did you see XCA : http://xca.sourceforge.net/ ?

 

Regards,

 

Michel

 

De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de thirumalkumarkanakurthi at bel.co.in
Envoy? : mercredi 2 mars 2016 09:37
? : openssl-users at openssl.org
Objet : [openssl-users] Developing CA with Openssl library

 


Dear users,
I want to develop my own CA with openssl library ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160302/2d9da9f6/attachment.html>

From norm.green at gemtalksystems.com  Wed Mar  2 15:49:46 2016
From: norm.green at gemtalksystems.com (Norm Green)
Date: Wed, 2 Mar 2016 07:49:46 -0800
Subject: [openssl-users] 1.0.2g build fails on Windows
Message-ID: <56D70B9A.60602@gemtalksystems.com>

Building with MS Studio 2012 on Windows 7 fails with 1.0.2g during a 
link step.  Note that 1.0.2f builds fine.  Looks like we crossed some 
sort of command line length threshold with 1.0.2g.

Error:

NMAKE : fatal error U1095: expanded command line

Excerpt:
     link /nologo /subsystem:console /opt:ref /debug /dll 
/out:out32dll.dbg\gost.dll  @C:\cygwin64\tmp\nmFE55.tmp
    Creating library out32dll.dbg\gost.lib and object out32dll.dbg\gost.exp
     IF EXIST out32dll.dbg\gost.dll.manifest mt -nologo -manifest 
out32dll.dbg\gost.dll.manifest -outputresource:out32dll.dbg\gost.dll;2


I am going to try modifying the make file to use shorter directory names 
to try to get the link line back under the max length threshold.

Any other suggestions?

Norm Green


From scott_n at xypro.com  Wed Mar  2 18:04:37 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 2 Mar 2016 18:04:37 +0000
Subject: [openssl-users] DROWN (CVE-2016-0800)
Message-ID: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>

Hi,

I've got a question about DROWN.   Is the vulnerability due to a specific coding error in OpenSSL,
or is it something that other SSL implementations may be vulnerable to?  Which commit fixed this,
so that I can see the changes?

Thanks,

ScottN


From rsalz at akamai.com  Wed Mar  2 18:21:41 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 2 Mar 2016 18:21:41 +0000
Subject: [openssl-users] DROWN (CVE-2016-0800)
In-Reply-To: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <52781b82c4964df7bd8d76b691299785@usma1ex-dag1mb1.msg.corp.akamai.com>

Other implementations MAY be susceptible.  It's a protocol flaw.

The fix is to completely remove SSLv2.  See the blog post:  https://www.openssl.org/blog/blog/2016/03/01/an-openssl-users-guide-to-drown/

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz



From pdrotter at us.ibm.com  Wed Mar  2 17:27:48 2016
From: pdrotter at us.ibm.com (Neptune)
Date: Wed, 2 Mar 2016 10:27:48 -0700 (MST)
Subject: [openssl-users] Guidance on proper usage of OpenSSL_add_all_digests
Message-ID: <1456939668236-64243.post@n7.nabble.com>

Using OpenSSL 1.0.1l

I just learned the painful way that OpenSSL_add_all_digests() is not a
thread-safe function. I had been calling this in the constructor of a class
providing hash functions for multiple threads. My question is, how do I know
if a thread instantiating my class has called OpenSSL_add_all_digests() or
not? Is there a way to query OpenSSL for the state of the table? Perhaps
more importantly, is it a requirement to call this function at all? My test
application seems quite happy to do SHA1 hashes without calling any of the
*add_all* functions :-/

Google searches bring back about a dozen different "proper" ways of
initializing, so I am asking for some expert guidance.

Thanks!



--
View this message in context: http://openssl.6102.n7.nabble.com/Guidance-on-proper-usage-of-OpenSSL-add-all-digests-tp64243.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From noloader at gmail.com  Wed Mar  2 18:48:38 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 2 Mar 2016 13:48:38 -0500
Subject: [openssl-users] Guidance on proper usage of
	OpenSSL_add_all_digests
In-Reply-To: <1456939668236-64243.post@n7.nabble.com>
References: <1456939668236-64243.post@n7.nabble.com>
Message-ID: <CAH8yC8kLQz2zY7NDcmTG8VK3G9LtsYmFfdHu8=BceKcgwmqWnw@mail.gmail.com>

On Wed, Mar 2, 2016 at 12:27 PM, Neptune <pdrotter at us.ibm.com> wrote:
> Using OpenSSL 1.0.1l
>
> I just learned the painful way that OpenSSL_add_all_digests() is not a
> thread-safe function. I had been calling this in the constructor of a class
> providing hash functions for multiple threads. My question is, how do I know
> if a thread instantiating my class has called OpenSSL_add_all_digests() or
> not? Is there a way to query OpenSSL for the state of the table? Perhaps
> more importantly, is it a requirement to call this function at all? My test
> application seems quite happy to do SHA1 hashes without calling any of the
> *add_all* functions :-/
>

Generally you want to provide initialization on the primary thread
during program startup. That's when you do things like installing the
locks, too. OpenSSL 1.1.0 adds OPENSSL_init_ssl, but its not clear to
me if it allows you to query subsystem initialization.

You can perform initialization in a static C++ ctor, but it can be
tricky because the C++ committee has never addressed the problem of
initialization order across translation units. Also see What's the
"static initialization order fiasco"?
(http://www.parashift.com/c++-faq/static-init-order.html).

Because of gaps in the C++ language, I usually do it in a c++ class
ctor, but the object resides in main(). On the occasions that the C++
class is instantiated as a static object, I use two techniques to
ensure the order of initialization. The first is object file ordering.
The second is compiler attributes, like "__attribute__ ((init_priority
(250)))" (with Clang/GCC/ICC) and "#pragma init_seg({user | lib})"
(with MSVC).

Unfortunately, there is no reasonable way to audit c++ static
constructor order for quality assurance purposes. Also see How to
verify init_priorty for C++ static object initialization order?
(http://sourceware.org/ml/binutils/2015-09/msg00173.html) on the
Binutils mailing list.

Regardless of how you do it, this is what you want to do:
https://wiki.openssl.org/index.php/Library_Initialization. The short
of this is call the following two functions:

  * SSL_library_init()
  * SSL_load_error_strings()

Finally, for the crypto components, like SHA... I don't believe they
need explicit initialization unless you are doing something like
changing the default implementation from software to an engine. The
SSL part of the library allows you to explicitly add selected
algorithms to control what algorithms are used in that portion of the
library.

Jeff

From noloader at gmail.com  Wed Mar  2 19:10:15 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 2 Mar 2016 14:10:15 -0500
Subject: [openssl-users] Guidance on proper usage of
	OpenSSL_add_all_digests
In-Reply-To: <CAH8yC8kLQz2zY7NDcmTG8VK3G9LtsYmFfdHu8=BceKcgwmqWnw@mail.gmail.com>
References: <1456939668236-64243.post@n7.nabble.com>
 <CAH8yC8kLQz2zY7NDcmTG8VK3G9LtsYmFfdHu8=BceKcgwmqWnw@mail.gmail.com>
Message-ID: <CAH8yC8mMKPjEsBy5AJtvRhGd+EgUGTcP4PFwj8U0XK_knENB0g@mail.gmail.com>

> Finally, for the crypto components, like SHA... I don't believe they
> need explicit initialization unless you are doing something like
> changing the default implementation from software to an engine. The
> SSL part of the library allows you to explicitly add selected
> algorithms to control what algorithms are used in that portion of the
> library.

My bad.. "Library Initialization | libcrypto Initialization"
(http://wiki.openssl.org/index.php/Library_Initialization#libcrypto_Initialization)
sates you can use either OpenSSL_add_all_ciphers,
OPENSSL_add_all_algorithms_noconf, or you can pick what you want when
initializing crypto portion of the library.

For picking what you want:

    void MyLIB_init_crypto(void)
    {
        EVP_add_cipher(EVP_sha1());
    }

The earlier still holds true. Initialize and install lock on the
primary thread. And take care when using static C++ objects.

Jeff

From scott_n at xypro.com  Wed Mar  2 19:10:43 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 2 Mar 2016 19:10:43 +0000
Subject: [openssl-users] DROWN (CVE-2016-0800)
In-Reply-To: <52781b82c4964df7bd8d76b691299785@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>
 <52781b82c4964df7bd8d76b691299785@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>

>From the linked document:

"All client sessions are vulnerable if the target server still supports SSLv2 today, irrespective of whether the client ever supported it"

I'm trying to understand this.  I am using a custom build of OpenSSL as a client, which was configured no-ssl2 and no-ssl3.  My code is
client-only.  So I am still vulnerable to this if my customer's server is not up to date?



-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich
Sent: Wednesday, March 02, 2016 10:22 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] DROWN (CVE-2016-0800)

Other implementations MAY be susceptible.  It's a protocol flaw.

The fix is to completely remove SSLv2.  See the blog post:  https://www.openssl.org/blog/blog/2016/03/01/an-openssl-users-guide-to-drown/

--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz


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

From openssl-users at dukhovni.org  Wed Mar  2 19:24:07 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 2 Mar 2016 19:24:07 +0000
Subject: [openssl-users] DROWN (CVE-2016-0800)
In-Reply-To: <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>
 <52781b82c4964df7bd8d76b691299785@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <20160302192407.GK10917@mournblade.imrryr.org>

On Wed, Mar 02, 2016 at 07:10:43PM +0000, Scott Neugroschl wrote:

> From the linked document:
> 
> "All client sessions are vulnerable if the target server still supports
> SSLv2 today, irrespective of whether the client ever supported it"

The SSLv2 protocol need only be used between the attacker and the
vulnerable server.  The client can use any SSL/TLS protocol, provided
that RSA key transport was used for key agreement and not DHE or
ECDHE.

With servers not patched since 19/Mar/2015, an MiTM attacker may
be able to perform a real-time downgrade to RSA key exchange.

> I'm trying to understand this.  I am using a custom build of OpenSSL as
> a client, which was configured no-ssl2 and no-ssl3.  My code is
> client-only.  So I am still vulnerable to this if my customer's server is
> not up to date?

Yes.  Sessions with vulnerable servers are vulnerable, unless the
client never uses RSA key transport.  If you have a dedicated
application that is sure to only communicate with servers that can
do forward-secret DHE/ECDHE handshakes, you can disable RSA key
transport on the client side.  This is not practical for most users.

For example, the client-side cipherstring:

	DEFAULT:!kRSA:!EXPORT:!LOW

is sufficient, if not generally practical.

-- 
	Viktor.

From Michael.Wojcik at microfocus.com  Wed Mar  2 19:38:18 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 2 Mar 2016 19:38:18 +0000
Subject: [openssl-users] DROWN (CVE-2016-0800)
In-Reply-To: <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>
 <52781b82c4964df7bd8d76b691299785@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DC8CA3F@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Scott Neugroschl
> Sent: Wednesday, March 02, 2016 14:11
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] DROWN (CVE-2016-0800)
> 
> From the linked document:
> 
> "All client sessions are vulnerable if the target server still supports SSLv2
> today, irrespective of whether the client ever supported it"
> 
> I'm trying to understand this.  I am using a custom build of OpenSSL as a
> client, which was configured no-ssl2 and no-ssl3.  My code is
> client-only.  So I am still vulnerable to this if my customer's server is not up to
> date?

*You* are not vulnerable. The *server* may be vulnerable. Sessions between your client and a vulnerable server are vulnerable.

DROWN is an attack on servers that use RSA keys and support SSLv2.

The client cannot prevent this attack - it has to be mitigated at the server end.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



From scott_n at xypro.com  Wed Mar  2 19:43:05 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 2 Mar 2016 19:43:05 +0000
Subject: [openssl-users] DROWN (CVE-2016-0800)
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015DC8CA3F@Rock-Exchange1.microfocus.com>
References: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>
 <52781b82c4964df7bd8d76b691299785@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>
 <B550B44BF8AF314BB00C4E2AC1C18088015DC8CA3F@Rock-Exchange1.microfocus.com>
Message-ID: <D358E5B1511A314F8160ADC6F37549873438A53C@XYSVEX02.XYPRO-23.LOCAL>

Thank you Michael and Victor for your explanation.

It's much appreciated.

ScottN

---
Scott Neugroschl | XYPRO Technology Corporation
4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |





From swall at redcom.com  Wed Mar  2 19:57:13 2016
From: swall at redcom.com (Wall, Stephen)
Date: Wed, 2 Mar 2016 14:57:13 -0500
Subject: [openssl-users] recommended build options
Message-ID: <401084E5E73F4241A44F3C9E6FD794280368802450@exch-01>

Is there a set of recommended build options for openssl?  For instance, "no-ssl2 no-comp -DOPENSSL_NO_HEARTBEATS no-md4 ..."

Thanks

-- 
Stephen P. Wall
Stephen_Wall at redcom.com
(585) 924-7550
REDCOM Laboratories, Inc.
One Redcom Center
Victor, NY 14564 USA



From thomas.francis.jr at pobox.com  Wed Mar  2 20:02:53 2016
From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.)
Date: Wed, 2 Mar 2016 15:02:53 -0500
Subject: [openssl-users] Guidance on proper usage of
	OpenSSL_add_all_digests
In-Reply-To: <1456939668236-64243.post@n7.nabble.com>
References: <1456939668236-64243.post@n7.nabble.com>
Message-ID: <E8400774-5671-46B5-B7E0-5678994A98CE@pobox.com>


> On Mar 2, 2016, at 12:27 PM, Neptune <pdrotter at us.ibm.com> wrote:
> 
> Using OpenSSL 1.0.1l
> 
> I just learned the painful way that OpenSSL_add_all_digests() is not a
> thread-safe function. I had been calling this in the constructor of a class
> providing hash functions for multiple threads. My question is, how do I know
> if a thread instantiating my class has called OpenSSL_add_all_digests() or
> not? Is there a way to query OpenSSL for the state of the table? Perhaps
> more importantly, is it a requirement to call this function at all? My test
> application seems quite happy to do SHA1 hashes without calling any of the
> *add_all* functions :-/

You should initialize OpenSSL prior to starting any threads.  Likewise, you should then de-initialize it only after all threads (except your main thread, of course) have finished.  If you absolutely have to do it inside some secondary thread, then initialize a value to tell you if you?ve initialized OpenSSL or not and look at it.  If you?re using pthreads, you could put your OpenSSL initialization in a single function, and then in each thread, invoke it with pthread_once().  That way it?ll never be called more than once.  That still leaves you with the issue of cleanup, but that might not matter, depending on how you use it.

This is changing with OpenSSL 1.1, but for the better.  IIUC, most users won?t need to bother with initialization at all.


> Google searches bring back about a dozen different "proper" ways of
> initializing, so I am asking for some expert guidance.

A lot of the differences come down to personal preference.  You don?t have to call OpenSSL_add_all_digests(), depending on what you?re doing, but I?d recommend either calling it, or calling EVP_add_digest() for each digest you intend to use.  I?d also suggest that if it?s working without either call, then perhaps you?re not doing it right. :)  Avoid using any functions like SHA1_Init(); use EVP_DigestInit(), instead.  The EVP interfaces are superior, especially when you eventually need to change which hashing algorithm to use.

TOM

> Thanks!
> 
> 
> 
> --
> View this message in context: http://openssl.6102.n7.nabble.com/Guidance-on-proper-usage-of-OpenSSL-add-all-digests-tp64243.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 


From openssl-users at dukhovni.org  Wed Mar  2 20:11:58 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 2 Mar 2016 20:11:58 +0000
Subject: [openssl-users] recommended build options
In-Reply-To: <401084E5E73F4241A44F3C9E6FD794280368802450@exch-01>
References: <401084E5E73F4241A44F3C9E6FD794280368802450@exch-01>
Message-ID: <20160302201158.GR10917@mournblade.imrryr.org>

On Wed, Mar 02, 2016 at 02:57:13PM -0500, Wall, Stephen wrote:

> Is there a set of recommended build options for openssl?  For instance,
> "no-ssl2 no-comp -DOPENSSL_NO_HEARTBEATS no-md4 ..."

By and large what should be off by default eventually or already
is, but there can be some delay for backwards compatibility.

The below non-experimental features are disabled by default in
OpenSSL 1.0.2s:

    my %disabled = ( # "what"         => "comment" [or special keyword "experimental "]
                 "ec_nistp_64_gcc_128" => "default",
                 "gmp"            => "default",
                 "md2"            => "default",
                 "rc5"            => "default",
                 "rfc3779"        => "default",
                 "sctp"           => "default",
                 "shared"         => "default",
                 "ssl-trace"      => "default",
                 "ssl2"           => "default",
                 "unit-test"      => "default",
                 "weak-ssl-ciphers" => "default",
                 "zlib"           => "default",
                 "zlib-dynamic"   => "default"
               );

With these you're covered for no-ssl2 no-comp and no weak ciphers.

In most cases you'll want shared libraries, but this requires
"Configure shared ...".  Some might choose to disable SSLv3 as well
with "no-ssl3".  It may also be reasonable to disable "idea", "seed"
and "rc2".

-- 
	Viktor.

From chris.gray at kiffer.be  Wed Mar  2 19:41:00 2016
From: chris.gray at kiffer.be (chris.gray at kiffer.be)
Date: Wed, 2 Mar 2016 19:41:00 -0000
Subject: [openssl-users] Guidance on proper usage of
 OpenSSL_add_all_digests
In-Reply-To: <CAH8yC8kLQz2zY7NDcmTG8VK3G9LtsYmFfdHu8=BceKcgwmqWnw@mail.gmail.com>
References: <1456939668236-64243.post@n7.nabble.com>
 <CAH8yC8kLQz2zY7NDcmTG8VK3G9LtsYmFfdHu8=BceKcgwmqWnw@mail.gmail.com>
Message-ID: <3da637e7c81b1a7c1066b3295736d287.squirrel@k-embedded-java.com>

> On Wed, Mar 2, 2016 at 12:27 PM, Neptune <pdrotter at us.ibm.com> wrote:
> [...]
> You can perform initialization in a static C++ ctor, but it can be
> tricky because the C++ committee has never addressed the problem of
> initialization order across translation units. Also see What's the
> "static initialization order fiasco"?
> (http://www.parashift.com/c++-faq/static-init-order.html).

So static initialisation in Java is not the most capricious and
error-prone mechanism ever invented?  My faith in mankind takes yet
another knock.



From rsalz at akamai.com  Wed Mar  2 20:38:30 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 2 Mar 2016 20:38:30 +0000
Subject: [openssl-users] DROWN (CVE-2016-0800)
In-Reply-To: <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>
 <52781b82c4964df7bd8d76b691299785@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <6a4fc695a5fe48a38ace86ff0aa3d23a@usma1ex-dag1mb1.msg.corp.akamai.com>

> am [I] still vulnerable to this if my customer's server is not up to date?

Yes, maybe.

If you use SSL3/TLS without PFS ciphers, then someone who has captured the traffic can send SSLv2 messages to the server and decrypt your traffic.

From noloader at gmail.com  Wed Mar  2 20:50:43 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 2 Mar 2016 15:50:43 -0500
Subject: [openssl-users] DROWN (CVE-2016-0800)
In-Reply-To: <6a4fc695a5fe48a38ace86ff0aa3d23a@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <D358E5B1511A314F8160ADC6F37549873438A438@XYSVEX02.XYPRO-23.LOCAL>
 <52781b82c4964df7bd8d76b691299785@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D358E5B1511A314F8160ADC6F37549873438A50C@XYSVEX02.XYPRO-23.LOCAL>
 <6a4fc695a5fe48a38ace86ff0aa3d23a@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAH8yC8k=ynn7=5iF--qnnQiAYPADVmmpV3M97emCD0OWhUPTjg@mail.gmail.com>

On Wed, Mar 2, 2016 at 3:38 PM, Salz, Rich <rsalz at akamai.com> wrote:
>> am [I] still vulnerable to this if my customer's server is not up to date?
>
> Yes, maybe.
>
> If you use SSL3/TLS without PFS ciphers, then someone who has captured the traffic can send SSLv2 messages to the server and decrypt your traffic.

Its probably worth mentioning since "interception is a valid use case"
has permeated both the W3C (browsers) and the IETF (Internet at
large)... Interception and proxy middleware could be contributing
significant risk. Its not readily apparent since the client is
believed to be well configured and the end server appears to be well
configured. Also see "Transitive Trust: SSL/TLS Interception Proxies",
https://www.secureworks.com/research/transitive-trust.

Jeff

From lists at rustichelli.net  Thu Mar  3 06:24:06 2016
From: lists at rustichelli.net (lists)
Date: Thu, 3 Mar 2016 07:24:06 +0100
Subject: [openssl-users] Developing CA with Openssl library
In-Reply-To: <c9b32ed6993fefd9bb9de8a23b545709.squirrel@mail.bel.co.in>
References: <c9b32ed6993fefd9bb9de8a23b545709.squirrel@mail.bel.co.in>
Message-ID: <56D7D886.5030705@rustichelli.net>

On 03/02/2016 09:36 AM, thirumalkumarkanakurthi at bel.co.in wrote:
>
> Dear users,
>  I want to develop my own CA with openssl library with all the CA 
> functionalities like Key generation,Certificate creation,Certificate 
> Revocation List creation,Certificate revocation and certificate 
> verification.in Order to do so i am struct with the following questions
>
> 1. currently i am using openssl_1_0_1 stable version. With this 
> version is it possible to perform the above operations.

Yes, but it's a lot of code to write if you plan to use the library.

> 2. Will above mentioned version provide full CA CRL functionalities.
>  please help me  with your valuable suggestions and solutions. Thanks 
> in advance.
>

For what I know, all of it is there, too.
But really consider using OpenSSL-based open source products or at least 
openssl command line tools where possible, otherwise it is just as 
answer (1): there is a lot to do!

> Regards
> Thirumal Kumar Kanakurthi
> Member (Research Staff)/NWS Group
> Central Research Laboratory(BEL).
> Bangalore.
> Mobile:+918050469976


From swall at redcom.com  Thu Mar  3 13:13:36 2016
From: swall at redcom.com (Wall, Stephen)
Date: Thu, 3 Mar 2016 08:13:36 -0500
Subject: [openssl-users] recommended build options
In-Reply-To: <20160302201158.GR10917@mournblade.imrryr.org>
References: <401084E5E73F4241A44F3C9E6FD794280368802450@exch-01>
 <20160302201158.GR10917@mournblade.imrryr.org>
Message-ID: <401084E5E73F4241A44F3C9E6FD79428036880254D@exch-01>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Viktor Dukhovni
> 
> By and large what should be off by default eventually or already
> is, but there can be some delay for backwards compatibility.
...
> With these you're covered for no-ssl2 no-comp and no weak ciphers.

We are using 1.0.2f, no-ssl2 and no-comp do not appear to be defaults in that version.  Should heartbeats be turned off, or have recent version of OpenSSL taken care of any potential weaknesses there?

> It may also be reasonable to disable "idea", "seed" and "rc2".

We provide config settings to disable ssl3, idea, and seed, though I think it'd probably be safe to drop idea and seed altogether.  I believe heimdal uses rc2, which precludes disabling that one.

Thanks
-spw

From medulla_oblongata at outlook.com  Thu Mar  3 16:07:56 2016
From: medulla_oblongata at outlook.com (Medulla Oblongata)
Date: Thu, 3 Mar 2016 16:07:56 +0000
Subject: [openssl-users] Need some information about TLS with AES-GCM
Message-ID: <BLU178-W19B36C51DB5028EA5181488BD0@phx.gbl>

Hello,
I'm running server and client and they communicate using DTLS over UDP and cipher suite in use is AES-GCM-SHA384.
What i want to do here is to decrypt the packets which are sent by the client but i keep failing to do so.
To do this i obviously need the clients write key, nonce, the actual encrypted data and the additional data like it's specified here https://tools.ietf.org/html/rfc5246 in section 6.2.3.3.
The key is the easy part, that i can get from the client. 
Next part is the nonce, which to my understanding and according to this https://tools.ietf.org/html/rfc5116 document is built from 2 parts, the explicit part which is the first 8 bytes after the UDP header just before the ciphertext and the 4 byte salt which is negotiated during the handshake, those two are then concatenated (salt + 8bytes of data) and this is then used as a 12 byte initialization vector.
Then there is the additional data which according to this https://tools.ietf.org/html/rfc5246 (section 6.2.3.3) is:seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length
Now, what i would like to do is to use https://raw.githubusercontent.com/openssl/openssl/master/demos/evp/aesgcm.c this as a template and decrypt the data that's in the packet but when i plug in the encrypted data, key, aad and IV it just fails.
The only problem here is with the tag which is used in the example after the data is decrypted and before the EVP_DecryptFinal_ex function is called. I assume that it is appended to the data before encryption and i have to get it after the data is decrypted, is this correct?
So question is, what im doing wrong? Do i derive the IV and additional data correctly? 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160303/ead718b9/attachment.html>

From bgiles at coyotesong.com  Thu Mar  3 17:17:45 2016
From: bgiles at coyotesong.com (Bear Giles)
Date: Thu, 3 Mar 2016 10:17:45 -0700
Subject: [openssl-users] Developing CA with Openssl library
In-Reply-To: <56D7D886.5030705@rustichelli.net>
References: <c9b32ed6993fefd9bb9de8a23b545709.squirrel@mail.bel.co.in>
 <56D7D886.5030705@rustichelli.net>
Message-ID: <CALBNtw4HFitWjYHOOrKPNrcQ9zfF13i9-8qAV1_Dxv7HqLwdkA@mail.gmail.com>

I've written big chunks of a CA in both openssl and java (BouncyCastle). It
has definite benefits since it can be tightly integrated into an existing
infrastructure but does require a fairly deep understanding of both
concepts and implementation details. The actual key management is not that
hard to write once you have that basic knowledge.

However a CA is a lot more than just signing keys and that can be a lot of
work but I think that will be true regardless of whether you're doing new
development with the libraries or using scripts with the command line
program. The command line is fine for small needs but I would definitely
rather use the libraries (C or java) if I had it sitting behind a web or
microservice.

Finally I should point out that Amazon has just released an X.509 key
management system as part of Amazon Web Services. I haven't had a chance to
look at it but it might be easier to implement a front end to it.

Bear

On Wed, Mar 2, 2016 at 11:24 PM, lists <lists at rustichelli.net> wrote:

> On 03/02/2016 09:36 AM, thirumalkumarkanakurthi at bel.co.in wrote:
>
>>
>> Dear users,
>>  I want to develop my own CA with openssl library with all the CA
>> functionalities like Key generation,Certificate creation,Certificate
>> Revocation List creation,Certificate revocation and certificate
>> verification.in Order to do so i am struct with the following questions
>>
>> 1. currently i am using openssl_1_0_1 stable version. With this version
>> is it possible to perform the above operations.
>>
>
> Yes, but it's a lot of code to write if you plan to use the library.
>
> 2. Will above mentioned version provide full CA CRL functionalities.
>>  please help me  with your valuable suggestions and solutions. Thanks in
>> advance.
>>
>>
> For what I know, all of it is there, too.
> But really consider using OpenSSL-based open source products or at least
> openssl command line tools where possible, otherwise it is just as answer
> (1): there is a lot to do!
>
>
> Regards
>> Thirumal Kumar Kanakurthi
>> Member (Research Staff)/NWS Group
>> Central Research Laboratory(BEL).
>> Bangalore.
>> Mobile:+918050469976
>>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160303/2f8ba3b3/attachment-0001.html>

From openssl-users at dukhovni.org  Thu Mar  3 18:49:59 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 3 Mar 2016 18:49:59 +0000
Subject: [openssl-users] recommended build options
In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428036880254D@exch-01>
References: <401084E5E73F4241A44F3C9E6FD794280368802450@exch-01>
 <20160302201158.GR10917@mournblade.imrryr.org>
 <401084E5E73F4241A44F3C9E6FD79428036880254D@exch-01>
Message-ID: <20160303184958.GI10917@mournblade.imrryr.org>

On Thu, Mar 03, 2016 at 08:13:36AM -0500, Wall, Stephen wrote:

> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> > Behalf Of Viktor Dukhovni
> > 
> > By and large what should be off by default eventually or already
> > is, but there can be some delay for backwards compatibility.
> ...
> > With these you're covered for no-ssl2 no-comp and no weak ciphers.
> 
> We are using 1.0.2f, no-ssl2 and no-comp do not appear to be defaults in
> that version.  Should heartbeats be turned off, or have recent version of
> OpenSSL taken care of any potential weaknesses there?

Yes, you do need to disable "ssl2" in releases prior to 1.0.1s
and 1.0.2g.

Note that "no-comp" is a consequence of "zlib" and "zlib-dynamic"
not being enabled.  You have to choose to turn compression on IIRC
by enabling one of these.

-- 
	Viktor.

From noloader at gmail.com  Thu Mar  3 19:00:31 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 3 Mar 2016 14:00:31 -0500
Subject: [openssl-users] recommended build options
In-Reply-To: <20160303184958.GI10917@mournblade.imrryr.org>
References: <401084E5E73F4241A44F3C9E6FD794280368802450@exch-01>
 <20160302201158.GR10917@mournblade.imrryr.org>
 <401084E5E73F4241A44F3C9E6FD79428036880254D@exch-01>
 <20160303184958.GI10917@mournblade.imrryr.org>
Message-ID: <CAH8yC8=8aGrzsLomvzYg9+0mOME7S-_A1qN-zEMNgPMfJzi5YQ@mail.gmail.com>

>> > By and large what should be off by default eventually or already
>> > is, but there can be some delay for backwards compatibility.
>> ...
>> > With these you're covered for no-ssl2 no-comp and no weak ciphers.
>>
>> We are using 1.0.2f, no-ssl2 and no-comp do not appear to be defaults in
>> that version.  Should heartbeats be turned off, or have recent version of
>> OpenSSL taken care of any potential weaknesses there?
>
> Yes, you do need to disable "ssl2" in releases prior to 1.0.1s
> and 1.0.2g.
>
> Note that "no-comp" is a consequence of "zlib" and "zlib-dynamic"
> not being enabled.  You have to choose to turn compression on IIRC
> by enabling one of these.

no-comp disables compression independent of zlib. OPENSSL_NO_COMP will
be defined in the OpenSSL headers.

Also see https://wiki.openssl.org/index.php/Compilation_and_Installation#Configure_Options.
As interesting ones show up and team members comment on them, they get
added to the list.

Jeff

From openssl-users at dukhovni.org  Thu Mar  3 19:08:52 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 3 Mar 2016 19:08:52 +0000
Subject: [openssl-users] recommended build options
In-Reply-To: <CAH8yC8=8aGrzsLomvzYg9+0mOME7S-_A1qN-zEMNgPMfJzi5YQ@mail.gmail.com>
References: <401084E5E73F4241A44F3C9E6FD794280368802450@exch-01>
 <20160302201158.GR10917@mournblade.imrryr.org>
 <401084E5E73F4241A44F3C9E6FD79428036880254D@exch-01>
 <20160303184958.GI10917@mournblade.imrryr.org>
 <CAH8yC8=8aGrzsLomvzYg9+0mOME7S-_A1qN-zEMNgPMfJzi5YQ@mail.gmail.com>
Message-ID: <20160303190851.GK10917@mournblade.imrryr.org>

On Thu, Mar 03, 2016 at 02:00:31PM -0500, Jeffrey Walton wrote:

> > Note that "no-comp" is a consequence of "zlib" and "zlib-dynamic"
> > not being enabled.  You have to choose to turn compression on IIRC
> > by enabling one of these.
> 
> no-comp disables compression independent of zlib. OPENSSL_NO_COMP will
> be defined in the OpenSSL headers.

Yes, it overrides these, and I was forgetting that there can perhaps
be additional compression methods in play.  So "no-comp" is reasonably
sensible, unless you're supportting some application where TLS
compression is both safe and required.

-- 
	Viktor.

From sanumesh at in.ibm.com  Fri Mar  4 06:04:12 2016
From: sanumesh at in.ibm.com (Sandeep Umesh)
Date: Fri, 4 Mar 2016 11:34:12 +0530
Subject: [openssl-users] test for DROWN CVE
Message-ID: <201603040714.u247ESxW58720404@d28relay05.in.ibm.com>

Hello

How can anyone test if the server is susceptible to DROWN CVE? 

Possibly one of the methods is to check at https://drownattack.com/#check

Apart from this, will be below command also be useful to verify for the 
impact? - 
$ openssl s_client -connect <hostname>:<port> -ssl2 


Regards
Sandeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160304/10cd9fed/attachment.html>

From nounou.dadoun at avigilon.com  Fri Mar  4 17:36:48 2016
From: nounou.dadoun at avigilon.com (Nounou Dadoun)
Date: Fri, 4 Mar 2016 17:36:48 +0000
Subject: [openssl-users] test for DROWN CVE
Message-ID: <8149AB08BCB1F54F92680ED6104891A0E19B39@mbx027-w1-ca-4.exch027.domain.local>

There was a suite of test scripts posted to the dev list (I set them up and used them very quickly), see below ....

Nou Dadoun
Senior Firmware Developer, Security Specialist

Office: 604.629.5182 ext 2632 

-----Original Message-----
From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Hubert Kario
Sent: Tuesday, March 01, 2016 7:22 AM
To: openssl-dev at openssl.org
Subject: Re: [openssl-dev] OpenSSL Security Advisory

Scripts to verify that a server is not vulnerable to DROWN.

Two scripts are provided to verify that SSLv2 and all of its ciphers are 
disabled and that export grade SSLv2 are disabled and can't be forced by 
client.

Reproducer requires Python 2.6 or 3.2 or later, you will also need git 
to download the sources

# Download the reproducer:
git clone https://github.com/tomato42/tlsfuzzer
cd tlsfuzzer
git checkout ssl2

# Download the reproducer dependencies
git clone https://github.com/tomato42/tlslite-ng .tlslite-ng
ln -s .tlslite-ng/tlslite tlslite
pushd .tlslite-ng
# likely won't be necessary in near future, code will be merged soon
git checkout sslv2
popd
git clone https://github.com/warner/python-ecdsa .python-ecdsa
ln -s .python-ecdsa/ecdsa ecdsa


To verify that an https server at example.com does not support SSLv2 at 
all, use the following command:

PYTHONPATH=. python scripts/test-sslv2-force-export-cipher.py \
-h example.com -p 443

To only verify that the server does not support export grade SSLv2 
ciphers, use the following command:

PYTHONPATH=. python scripts/test-sslv2-force-cipher.py -h example.com \
-p 443

(note, the first script is a superset of the second one)

In both cases all the individual tests in the scripts should print "OK" 
status if the specific cipher is not supported and report "failed: 0" 
together with exit status of 0 if you want to automate it.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.asc
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160304/d5435685/attachment.sig>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001.txt
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160304/d5435685/attachment.txt>

From angel at tls.16bits.net  Fri Mar  4 21:25:57 2016
From: angel at tls.16bits.net (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Fri, 04 Mar 2016 22:25:57 +0100
Subject: [openssl-users] test for DROWN CVE
In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E19B39@mbx027-w1-ca-4.exch027.domain.local>
References: <8149AB08BCB1F54F92680ED6104891A0E19B39@mbx027-w1-ca-4.exch027.domain.local>
Message-ID: <1457126757.5211.14.camel@tls.16bits.net>

Nounou Dadoun wrote:
> There was a suite of test scripts posted to the dev list (I set them
> up and used them very quickly), see below ....
> 
> Nou Dadoun
> Senior Firmware Developer, Security Specialist


Do note that there command lines were exchanged on the email describing
the scripts, though:

To verify that an https server at example.com does not support SSLv2
at all you should use?test-sslv2-force-cipher.py, not?test-sslv2-force-
export-cipher.py.
test-sslv2-force-export-cipher.py should be used to to only verify that
the server does not support export grade SSLv2 ciphers.

And thus, it's?test-sslv2-force-cipher.py the one who is a superset of
the test-sslv2-force-export-cipher.py


Additionally, I'd like to point out the undocumented feature that
instead of using -p port, they also support -h host:port, which is
handy when dealing with lists of servers and ports.

Regards

From ls00722 at yahoo.com  Sat Mar  5 01:35:00 2016
From: ls00722 at yahoo.com (Lei Sun)
Date: Sat, 5 Mar 2016 01:35:00 +0000 (UTC)
Subject: [openssl-users] verify certificate chain (in memory)
References: <2142965995.3057559.1457141700756.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <2142965995.3057559.1457141700756.JavaMail.yahoo@mail.yahoo.com>

Hi:
  In my project I need to verify certificate chain sent from server. The chain has root->inter mediate -> server, 3 level chain. The server certificate files can be verified by "openssl verify" command:

openssl verify -CAfile root.crt server.crt
OK.

But I had to combine the root cert and intermediate cert into single file, to verify the whole chain via command line.

I wrote a test program to verify it with C program:
Note that I have converted the PEM cert file into DER binary, to minic exactly what server sent me.


The core part of the code in bellow:

int main(void)
{
    FILE *fp = NULL;
    size_t r_size, i_size, s_size;
    unsigned char *r, *i, *s;
    X509 *root, *inter, *server;
    X509_STORE *store;

    X509_STORE_CTX *store_ctx;
       int ret;



        if ((r = malloc(1024)) == NULL ||
        (i = malloc(1204)) == NULL ||
               (s = malloc(1024)) == NULL)
            return -1;

        /* read certs into buffer */
        r_size = read_cert("root.bin", r, 1024);
        i_size = read_cert("inter.bin", i, 1024);
     s_size = read_cert("server.bin", s, 1024);

root = d2i_X509(NULL, &r, r_size);
if (root == NULL)
            fprintf(stderr, "failed to convert root cert\n");
inter = d2i_X509(NULL, &i, i_size);
if (inter == NULL)
            fprintf(stderr, "failed to convert inter cert\n");
server = d2i_X509(NULL, &s, s_size);
if (server == NULL)
            fprintf(stderr, "failed to convert server cert\n");


store = X509_STORE_new();
X509_STORE_add_cert(store, root);
store_ctx = X509_STORE_CTX_new();

X509_STORE_CTX_init(store_ctx, store, inter, NULL);


ret = X509_verify_cert(store_ctx);

fprintf(stdout, "ret=%d\n", ret);
if (ret <= 0) {
ret = X509_STORE_CTX_get_error(store_ctx);
fprintf(stderr, "%d: %s\n", ret, X509_verify_cert_error_string(ret));
}


The above code gives me "certificate signature failure" error, I was only trying to verify intermediate cert with root cert.  Since I don't know how to verify the whole chain in memory.

Can anybody shed some lights on me? I googled around for a day with no luck. 


Thanks
chris

From angel at tls.16bits.net  Sat Mar  5 16:44:09 2016
From: angel at tls.16bits.net (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 05 Mar 2016 17:44:09 +0100
Subject: [openssl-users] verify certificate chain (in memory)
In-Reply-To: <2142965995.3057559.1457141700756.JavaMail.yahoo@mail.yahoo.com>
References: <2142965995.3057559.1457141700756.JavaMail.yahoo.ref@mail.yahoo.com>
 <2142965995.3057559.1457141700756.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <1457196249.2334.2.camel@tls.16bits.net>

Lei Sun wrote:
> Hi:
> ? In my project I need to verify certificate chain sent from server.
> The chain has root->inter mediate -> server, 3 level chain. The
> server certificate files can be verified by "openssl verify" command:
> 
> openssl verify -CAfile root.crt server.crt
> OK.
> 
> But I had to combine the root cert and intermediate cert into single
> file, to verify the whole chain via command line.

Have you tried combining the intermediate and the server cert into a
single file? That should work, and is more akin to the actual behavior
(the server sends its certificate plus any ?intermediates, and the
client should only need the root).

Kind regards


From ls00722 at yahoo.com  Sun Mar  6 00:56:03 2016
From: ls00722 at yahoo.com (Lei Sun)
Date: Sun, 6 Mar 2016 00:56:03 +0000 (UTC)
Subject: [openssl-users] verify certificate chain (in memory)
In-Reply-To: <1457196249.2334.2.camel@tls.16bits.net>
References: <1457196249.2334.2.camel@tls.16bits.net>
Message-ID: <776079348.3341670.1457225763793.JavaMail.yahoo@mail.yahoo.com>

Hi :
  I haven't tried that. In the command line:

openssl verify -CAfile root.cert inter.crt 
OK.
That means intermediate cert can be verified with root cert, so as a first step i try to perform this two level verify with C program. but it failed. 

If I combine the server's cert and intermediate into single file, and use d2i_X509(), would it return a china of certificates then?

I will try it. But I still concern why intermediate cert verification would fail. 

Thanks
Lei 


----- Original Message -----
From: ?ngel Gonz?lez <angel at tls.16bits.net>
To: openssl-users at openssl.org
Sent: Saturday, March 5, 2016 8:44 AM
Subject: Re: [openssl-users] verify certificate chain (in memory)

Lei Sun wrote:

> Hi:
>   In my project I need to verify certificate chain sent from server.
> The chain has root->inter mediate -> server, 3 level chain. The
> server certificate files can be verified by "openssl verify" command:
> 
> openssl verify -CAfile root.crt server.crt
> OK.
> 
> But I had to combine the root cert and intermediate cert into single
> file, to verify the whole chain via command line.

Have you tried combining the intermediate and the server cert into a
single file? That should work, and is more akin to the actual behavior
(the server sends its certificate plus any  intermediates, and the
client should only need the root).

Kind regards

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

From ls00722 at yahoo.com  Sun Mar  6 01:19:52 2016
From: ls00722 at yahoo.com (Lei Sun)
Date: Sun, 6 Mar 2016 01:19:52 +0000 (UTC)
Subject: [openssl-users] verify certificate chain (in memory)
In-Reply-To: <1457196249.2334.2.camel@tls.16bits.net>
References: <1457196249.2334.2.camel@tls.16bits.net>
Message-ID: <1956428237.3294649.1457227192965.JavaMail.yahoo@mail.yahoo.com>

I just tried combine root and intermediate into single file. 
I got "unable to get local issuer certificate" error.

I guess my code is wrong since I am not able to find a complete example on how to verify a in-memory certificate.
All examples are based on the fact that certificate is a file (thus use LOOK_UP API, etc).

Any references?

Thanks
chris


----- Original Message -----
From: ?ngel Gonz?lez <angel at tls.16bits.net>
To: openssl-users at openssl.org
Sent: Saturday, March 5, 2016 8:44 AM
Subject: Re: [openssl-users] verify certificate chain (in memory)

Lei Sun wrote:

> Hi:
>   In my project I need to verify certificate chain sent from server.
> The chain has root->inter mediate -> server, 3 level chain. The
> server certificate files can be verified by "openssl verify" command:
> 
> openssl verify -CAfile root.crt server.crt
> OK.
> 
> But I had to combine the root cert and intermediate cert into single
> file, to verify the whole chain via command line.

Have you tried combining the intermediate and the server cert into a
single file? That should work, and is more akin to the actual behavior
(the server sends its certificate plus any  intermediates, and the
client should only need the root).

Kind regards

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

From steve at openssl.org  Sun Mar  6 02:55:10 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sun, 6 Mar 2016 02:55:10 +0000
Subject: [openssl-users] verify certificate chain (in memory)
In-Reply-To: <2142965995.3057559.1457141700756.JavaMail.yahoo@mail.yahoo.com>
References: <2142965995.3057559.1457141700756.JavaMail.yahoo.ref@mail.yahoo.com>
 <2142965995.3057559.1457141700756.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <20160306025510.GA7991@openssl.org>

On Sat, Mar 05, 2016, Lei Sun wrote:

> Hi:
>   In my project I need to verify certificate chain sent from server. The chain has root->inter mediate -> server, 3 level chain. The server certificate files can be verified by "openssl verify" command:
> 
> openssl verify -CAfile root.crt server.crt
> OK.
> 
> But I had to combine the root cert and intermediate cert into single file, to verify the whole chain via command line.
> 

You should pass the intermediate certificate in a separate file usine the
-untrusted option.

> I wrote a test program to verify it with C program:
> Note that I have converted the PEM cert file into DER binary, to minic exactly what server sent me.
> 
> 
> The core part of the code in bellow:
> 
> int main(void)
> {
>     FILE *fp = NULL;
>     size_t r_size, i_size, s_size;
>     unsigned char *r, *i, *s;
>     X509 *root, *inter, *server;
>     X509_STORE *store;
> 
>     X509_STORE_CTX *store_ctx;
>        int ret;
> 
> 
> 
>         if ((r = malloc(1024)) == NULL ||
>         (i = malloc(1204)) == NULL ||
>                (s = malloc(1024)) == NULL)
>             return -1;
> 
>         /* read certs into buffer */
>         r_size = read_cert("root.bin", r, 1024);
>         i_size = read_cert("inter.bin", i, 1024);
>      s_size = read_cert("server.bin", s, 1024);
> 
> root = d2i_X509(NULL, &r, r_size);
> if (root == NULL)
>             fprintf(stderr, "failed to convert root cert\n");
> inter = d2i_X509(NULL, &i, i_size);
> if (inter == NULL)
>             fprintf(stderr, "failed to convert inter cert\n");
> server = d2i_X509(NULL, &s, s_size);
> if (server == NULL)
>             fprintf(stderr, "failed to convert server cert\n");
> 
> 
> store = X509_STORE_new();
> X509_STORE_add_cert(store, root);
> store_ctx = X509_STORE_CTX_new();
> 
> X509_STORE_CTX_init(store_ctx, store, inter, NULL);
> 
> 
> ret = X509_verify_cert(store_ctx);
> 
> fprintf(stdout, "ret=%d\n", ret);
> if (ret <= 0) {
> ret = X509_STORE_CTX_get_error(store_ctx);
> fprintf(stderr, "%d: %s\n", ret, X509_verify_cert_error_string(ret));
> }
> 
> 
> The above code gives me "certificate signature failure" error, I was only trying to verify intermediate cert with root cert.  Since I don't know how to verify the whole chain in memory.
> 
> Can anybody shed some lights on me? I googled around for a day with no luck. 
> 

Probably missing OpenSSL_add_all_algorithms().

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

From ls00722 at yahoo.com  Sun Mar  6 04:47:14 2016
From: ls00722 at yahoo.com (Lei Sun)
Date: Sun, 6 Mar 2016 04:47:14 +0000 (UTC)
Subject: [openssl-users] verify certificate chain (in memory)
In-Reply-To: <20160306025510.GA7991@openssl.org>
References: <20160306025510.GA7991@openssl.org>
Message-ID: <1185376559.3354385.1457239634933.JavaMail.yahoo@mail.yahoo.com>

Hi Dr. Stephen:
  Thanks for the comment, yes giving "untrusted" for intermediate file did solved the problem. 

openssl verify -CAfile root.crt -untrusted inter.crt server.crt
OK

I do have  OpenSSL_add_all_algorithms() in my code, i stripped it out and only posted the core part of the code.

Thanks
chris


----- Original Message -----
From: Dr. Stephen Henson <steve at openssl.org>
To: Lei Sun <ls00722 at yahoo.com>; openssl-users at openssl.org
Sent: Saturday, March 5, 2016 6:55 PM
Subject: Re: [openssl-users] verify certificate chain (in memory)

On Sat, Mar 05, 2016, Lei Sun wrote:

> Hi:
>   In my project I need to verify certificate chain sent from server. The chain has root->inter mediate -> server, 3 level chain. The server certificate files can be verified by "openssl verify" command:
> 
> openssl verify -CAfile root.crt server.crt
> OK.
> 
> But I had to combine the root cert and intermediate cert into single file, to verify the whole chain via command line.
> 

You should pass the intermediate certificate in a separate file usine the
-untrusted option.


> I wrote a test program to verify it with C program:
> Note that I have converted the PEM cert file into DER binary, to minic exactly what server sent me.
> 
> 
> The core part of the code in bellow:
> 
> int main(void)
> {
>     FILE *fp = NULL;
>     size_t r_size, i_size, s_size;
>     unsigned char *r, *i, *s;
>     X509 *root, *inter, *server;
>     X509_STORE *store;
> 
>     X509_STORE_CTX *store_ctx;
>        int ret;
> 
> 
> 
>         if ((r = malloc(1024)) == NULL ||
>         (i = malloc(1204)) == NULL ||
>                (s = malloc(1024)) == NULL)
>             return -1;
> 
>         /* read certs into buffer */
>         r_size = read_cert("root.bin", r, 1024);
>         i_size = read_cert("inter.bin", i, 1024);
>      s_size = read_cert("server.bin", s, 1024);
> 
> root = d2i_X509(NULL, &r, r_size);
> if (root == NULL)
>             fprintf(stderr, "failed to convert root cert\n");
> inter = d2i_X509(NULL, &i, i_size);
> if (inter == NULL)
>             fprintf(stderr, "failed to convert inter cert\n");
> server = d2i_X509(NULL, &s, s_size);
> if (server == NULL)
>             fprintf(stderr, "failed to convert server cert\n");
> 
> 
> store = X509_STORE_new();
> X509_STORE_add_cert(store, root);
> store_ctx = X509_STORE_CTX_new();
> 
> X509_STORE_CTX_init(store_ctx, store, inter, NULL);
> 
> 
> ret = X509_verify_cert(store_ctx);
> 
> fprintf(stdout, "ret=%d\n", ret);
> if (ret <= 0) {
> ret = X509_STORE_CTX_get_error(store_ctx);
> fprintf(stderr, "%d: %s\n", ret, X509_verify_cert_error_string(ret));
> }
> 
> 
> The above code gives me "certificate signature failure" error, I was only trying to verify intermediate cert with root cert.  Since I don't know how to verify the whole chain in memory.
> 
> Can anybody shed some lights on me? I googled around for a day with no luck. 
> 

Probably missing OpenSSL_add_all_algorithms().

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

From noloader at gmail.com  Mon Mar  7 00:04:09 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 6 Mar 2016 19:04:09 -0500
Subject: [openssl-users] no-weak-ssl-ciphers and OPENSSL_NO_WEAK_SSL_CIPHERS?
Message-ID: <CAH8yC8kKDB+w2UetQ45Psrkcinv+DvVR9FaB95zCJfq84UFMyw@mail.gmail.com>

I noticed a new option no-weak-ssl-ciphers. It defines
OPENSSL_NO_WEAK_SSL_CIPHERS.

>From a grep it looks like OPENSSL_NO_WEAK_SSL_CIPHERS is used by
s3_lib.c. Inspecting the hits, it appears the define disables cipher
suites with RC4.

I also noticed there is some use of MD5 which is not guarded by
OPENSSL_NO_WEAK_SSL_CIPHERS. I mention it because of the browser's
Obsolete Cryptography warning
(http://security.stackexchange.com/q/83831 and
https://codereview.chromium.org/703143003).

So my question is, does OPENSSL_NO_WEAK_SSL_CIPHERS do anything more
than remove RC4?

From openssl-users at dukhovni.org  Mon Mar  7 00:13:56 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 6 Mar 2016 19:13:56 -0500
Subject: [openssl-users] no-weak-ssl-ciphers and
	OPENSSL_NO_WEAK_SSL_CIPHERS?
In-Reply-To: <CAH8yC8kKDB+w2UetQ45Psrkcinv+DvVR9FaB95zCJfq84UFMyw@mail.gmail.com>
References: <CAH8yC8kKDB+w2UetQ45Psrkcinv+DvVR9FaB95zCJfq84UFMyw@mail.gmail.com>
Message-ID: <D7D51C64-EC41-44F6-ADB8-D212B06CFA3D@dukhovni.org>


> On Mar 6, 2016, at 7:04 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> 
> So my question is, does OPENSSL_NO_WEAK_SSL_CIPHERS do anything more
> than remove RC4?

In master, at present, that's it.  This may change.

-- 
	Viktor.


From openssl-users at dukhovni.org  Mon Mar  7 00:38:27 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 6 Mar 2016 19:38:27 -0500
Subject: [openssl-users] no-weak-ssl-ciphers and
	OPENSSL_NO_WEAK_SSL_CIPHERS?
In-Reply-To: <D7D51C64-EC41-44F6-ADB8-D212B06CFA3D@dukhovni.org>
References: <CAH8yC8kKDB+w2UetQ45Psrkcinv+DvVR9FaB95zCJfq84UFMyw@mail.gmail.com>
 <D7D51C64-EC41-44F6-ADB8-D212B06CFA3D@dukhovni.org>
Message-ID: <1E3D35A2-0712-404D-883A-BBC1F636A487@dukhovni.org>


> On Mar 6, 2016, at 7:13 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> 
>> On Mar 6, 2016, at 7:04 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>> 
>> So my question is, does OPENSSL_NO_WEAK_SSL_CIPHERS do anything more
>> than remove RC4?
> 
> In master, at present, that's it.  This may change.

The only remaining use of MD5 I could find was:

  NULL-MD5                SSLv3 Kx=RSA      Au=RSA  Enc=None      Mac=MD5 

which is a NULL cipher, so you're not getting much security anyway,
but perhaps users of this still want strong data integrity, so we
could easily add this cipher to the 'weak' list...

-- 
	Viktor.


From openssl at wuerfelmail.de  Mon Mar  7 15:05:51 2016
From: openssl at wuerfelmail.de (Anton Wuerfel)
Date: Mon, 07 Mar 2016 16:05:51 +0100
Subject: [openssl-users] Extracting certificate from RFC3161 time stamp
	response
Message-ID: <89d87d112708cf3a70a7f4f2aeba279f@wuerfelmail.de>

Hello,

for an university project I am implementing RFC3161 time stamps into 
git.
when creating a TSQ it is possible to force the TSA server to include 
its signing certificate in the TSR. However, I was wondering how to 
extract this certificate at the client side, as neither 'openssl ts 
-reply' nor 'openssl ts -verify' seemed to offer an appropriate 
functionality. As the TSA field in TST_INFO is optional according to 
RFC3161 and might be unspecified, it is not a reliable way to determine 
the issuer of the timestamp signature. I would like to display the 
issuers name to the user if verification of the timestamp failed or the 
corresponding public key was not found in the user's certificate store.

Is there any built-in way to extract the issuer's certificate from a 
TSR?

Regards,
Anton Wuerfel

From BYan at visa.com  Tue Mar  8 01:04:50 2016
From: BYan at visa.com (Yan, Bob)
Date: Tue, 8 Mar 2016 01:04:50 +0000
Subject: [openssl-users] SSL_accept error code
Message-ID: <95aecac2232c4815a305a996d8a14fd4@SW550EXP003.visa.com>

Hi All,

I have a SSL server application which use SSL_accept to accept the connections from client, see the code below:

      int retcode = SSL_accept(mSsl);
      unsigned long error = SSL_get_error(mSsl, retcode);
      ERR_error_string_n(error, errmsg, sizeof(errmsg));
      
When something went wrong, for example Client connect server with ssl3 protocol (disabled), I get the error like this "error:00000001:lib(0):func(0):reason(1)". Could somebody tell me that is there any way to have more detailed debug messages from openssl?

Thanks
Bob

 

From jtakahashi2 at lenovo.com  Tue Mar  8 00:58:56 2016
From: jtakahashi2 at lenovo.com (James M Takahashi)
Date: Tue, 8 Mar 2016 00:58:56 +0000
Subject: [openssl-users] FIPS Performance Question
Message-ID: <FC47B9691934DA4FB4EB6210BDC44C7224BF3B67@AEMAILMBX03.lenovo.com>

https://www.openssl.org/docs/fipsnotes.html mentions the following:

      As a result of the POST performance issue we revisited the KAT (Known Answer Test) requirements in the POST process that were burning up most of those cycle. In consultation with a CMVP test lab we determined that it should be possible to substantially reduce that performance penalty in a new validation.

Can you please elaborate a bit on what this means?

Thanks in advance for any light you can shed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160308/a85726b2/attachment.html>

From jb-openssl at wisemo.com  Tue Mar  8 06:46:57 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 8 Mar 2016 07:46:57 +0100
Subject: [openssl-users] Extracting certificate from RFC3161 time stamp
 response
In-Reply-To: <89d87d112708cf3a70a7f4f2aeba279f@wuerfelmail.de>
References: <89d87d112708cf3a70a7f4f2aeba279f@wuerfelmail.de>
Message-ID: <56DE7561.4040803@wisemo.com>

On 07/03/2016 16:05, Anton Wuerfel wrote:
> Hello,
>
> for an university project I am implementing RFC3161 time stamps into git.
> when creating a TSQ it is possible to force the TSA server to include
> its signing certificate in the TSR. However, I was wondering how to
> extract this certificate at the client side, as neither 'openssl ts
> -reply' nor 'openssl ts -verify' seemed to offer an appropriate
> functionality. As the TSA field in TST_INFO is optional according to
> RFC3161 and might be unspecified, it is not a reliable way to
> determine the issuer of the timestamp signature. I would like to
> display the issuers name to the user if verification of the timestamp
> failed or the corresponding public key was not found in the user's
> certificate store.
>
> Is there any built-in way to extract the issuer's certificate from a TSR?
>
> Regards,
> Anton Wuerfel
IMHO that extra copy of the TSA server cert inside the TSR
is a complete and utter waste of bandwidth, not just for
the TSA communication, but for all the places where the
complete timestamp is subsequently carried around and/or
stored (in this case, the ever-growing git repository).

The obvious way to find this info is to not look inside
the TSR structure, but to look at the surrounding
SignedData (PKCS#7/CMS) structure.  This is the same as
for most other CMS signatures and includes signer
identification and certificate chain in the usual way.

Of cause, if a git repository contains many RFC3161 time
stamps from the same TSAs, it may pay off to define the
format as storing a (reversibly) transformed form where
all the common stuff is in a separate part of the file
format.  The sizes are large enough that a method such
as deflate/zip/gzip/zlib will have trouble eliminating
the redundancy efficiently on its own, while larger
size algorithms such as bzip2 or lzma should handle it
nicely if the time stamps are stored close together.

Another option, if the git format has a binary delta
algorithm already is to store the timestamps as
patches/deltas from prior timestamps, and letting the
delta algorithm recognize the large sequences of identical
bytes.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

From matt at openssl.org  Tue Mar  8 09:29:12 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 8 Mar 2016 09:29:12 +0000
Subject: [openssl-users] SSL_accept error code
In-Reply-To: <95aecac2232c4815a305a996d8a14fd4@SW550EXP003.visa.com>
References: <95aecac2232c4815a305a996d8a14fd4@SW550EXP003.visa.com>
Message-ID: <56DE9B68.9020106@openssl.org>



On 08/03/16 01:04, Yan, Bob wrote:
> Hi All,
> 
> I have a SSL server application which use SSL_accept to accept the
> connections from client, see the code below:
> 
> int retcode = SSL_accept(mSsl);
> unsigned long error =  SSL_get_error(mSsl, retcode);
> ERR_error_string_n(error, errmsg, sizeof(errmsg));
> 
> When something went wrong, for example Client connect server with
> ssl3 protocol (disabled), I get the error like this
> "error:00000001:lib(0):func(0):reason(1)". Could somebody tell me
> that is there any way to have more detailed debug messages from
> openssl?

You're not doing it right.

SSL_get_error() will give a return code to tell you the type of error
that was received, e.g. SSL_ERROR_WANT_READ, SSL_ERROR_SYSCALL,
SSL_ERROR_SSL, etc.

If error == SSL_ERROR_SSL then you can inspect the OpenSSL error queue
for more details. You *do not* pass SSL_ERROR_SSL to ERR_error_string_n!
Use a function such as ERR_print_errors(), ERR_print_errors_fp(),
ERR_get_error() etc See the man pages for those functions.

Matt

From lloydkl.tech at gmail.com  Tue Mar  8 13:34:52 2016
From: lloydkl.tech at gmail.com (Lloyd)
Date: Tue, 8 Mar 2016 19:04:52 +0530
Subject: [openssl-users] SSL_CTX_new fails some times
Message-ID: <CAA10ZTqjnibQzPt6NBAe7_x4C1gauVJo7PcpgwGLtAZsAXvzWw@mail.gmail.com>

Hi,

I am using boost asio for network programming, it in turn uses openSSL for
SSL based operations.

When asio library calls "SSL_CTX_new", it fails in some context. The
context is - (I am using Windows)

I have a "dll" plug-in which makes use of openssl functionalities
indirectly. In my application initialisation I call Windows "LoadLibrary"
function and also calls "GetProcAddress" to check if the plugin exposes
certain functionalities. Once this is done, it calls "FreeLibrary"
function. Once this function is called "SSL_CTX_new" fails.

I suspect that "Freelibrary" causes openssl libraries to be unloaded from
my process's context.

Is there any other reason for "SSL_CTX_new" to fail? The error i get is
"unable to load ssl2, md5 routines"


Any suggestion is greatly appreciated.

Thanks,
  Lloyd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160308/70485361/attachment.html>

From rsalz at akamai.com  Tue Mar  8 13:58:50 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 8 Mar 2016 13:58:50 +0000
Subject: [openssl-users] SSL_CTX_new fails some times
In-Reply-To: <CAA10ZTqjnibQzPt6NBAe7_x4C1gauVJo7PcpgwGLtAZsAXvzWw@mail.gmail.com>
References: <CAA10ZTqjnibQzPt6NBAe7_x4C1gauVJo7PcpgwGLtAZsAXvzWw@mail.gmail.com>
Message-ID: <13face936791450ea2c5fd681b5f7387@usma1ex-dag1mb1.msg.corp.akamai.com>


> I suspect that "Freelibrary" causes openssl libraries to be unloaded from my process's context.

Yes.  That's what it does.

From marquess at openssl.com  Tue Mar  8 14:16:50 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 8 Mar 2016 09:16:50 -0500
Subject: [openssl-users] FIPS Performance Question
In-Reply-To: <FC47B9691934DA4FB4EB6210BDC44C7224BF3B67@AEMAILMBX03.lenovo.com>
References: <FC47B9691934DA4FB4EB6210BDC44C7224BF3B67@AEMAILMBX03.lenovo.com>
Message-ID: <56DEDED2.8040200@openssl.com>

On 03/07/2016 07:58 PM, James M Takahashi wrote:
> _https://www.openssl.org/docs/fipsnotes.html_ mentions the following:
>  
> As a result of the POST performance issue we revisited the KAT (Known
> Answer Test) requirements in the POST process that were burning up most
> of those cycle. In consultation with a CMVP test lab we determined that
> it should be possible to substantially reduce that performance penalty
> in a new validation.
>  
> Can you please elaborate a bit on what this means?
>  
> Thanks in advance for any light you can shed.

The answer to that mostly concerns the historical origins of the OpenSSL
FIPS Object Module. The text you are quoting dates from the time we were
beginning work on the most recent module (which is now confusingly
covered by three validations, #1747, #2398, #2473).

As the only source code based module -- one distributed in source code
form -- and available under a no-cost open source license no less, these
validations have been subjected to an extraordinary amount of scrutiny.

Many of the FIPS 140-2 requirements are less than crystal clear, at
least from the outsider perspective of the software engineer. So in
coding the initial versions of the OpenSSL FIPS module we tried to be
conservative in satisfying the POST requirements as we understood them.
For instance, we checked multiple variations of different algorithms for
the KATs.

The resulting performance hit was substantial on low powered hardware;
as bad as tens of seconds for some embedded systems. So for the #1747
validation we took a close look, in consultation with the accredited
test lab, at what we could do to minimize that performance penalty. The
conclusion was that we could safely streamline or eliminate many of the
KATs. That conclusion was confirmed by the CMVP when they approved the
#1747 validation[1].

The POST performance penalty for the current OpenSSL FIPS module is now
tolerably low on all but the most severely underpowered hardware.

Note that the POST is also optional, in that an application that is
using the "FIPS capable" OpenSSL (OpenSSL proper built with the "fips"
buildtime option in the presence of a FIPS module) incurs no POST
performance penalty at all until FIPS mode is enabled by the calling
application via FIPS_mode_set().

However, the requirements were changed after the #1747 (et. al.)
validation(s) were awarded (I.G. 9.10) so that new modules are now
forced to execute the POST unconditionally, even if FIPS mode isn't
desired. It's my understanding that the upcoming FIPS 140-4 again
permits a conditional POST, though.

-Steve M.

[1] Note it can be difficult to get specific answers to hypothetical
questions from the CMVP. Test labs may say "well, we're not sure", or
different labs may give diametrically different answers. Sometimes the
best way to answer such questions is to submit a formal validation
action to elicit a definitive response.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From ohaya at yahoo.com  Tue Mar  8 19:24:52 2016
From: ohaya at yahoo.com (o haya)
Date: Tue, 8 Mar 2016 19:24:52 +0000 (UTC)
Subject: [openssl-users] Something causing "Error 12"/Expired CRL during CRL
	processing
References: <557630337.3821732.1457465092133.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <557630337.3821732.1457465092133.JavaMail.yahoo@mail.yahoo.com>

Hi,

I wasn't sure which mailing list would be most appropriate, so I had posted about this originally on the Apache mailing list earlier.  I haven't gotten any feedback on that, so I'm posting here in the hopes that someone might have some idea about what might be causing the problems we're seeing.



Anyway, we are upgrading some of our Apache instances to 2.4.16 (on Redhat) and OpenSSL from 0.9.8x to 1.0.1e, at the same time, mostly because we want to enable TLS, and we are encountering a strange problem with SSL and CRLs.



Our websites are configured for SSL client authentication with CRLs in a directory pointed to by SSLCACertificateRevocationPath and SSLCARevocationCheck set to "chain".  We then place our CRLs in the directory and create the hashes for them using an app or script that we wrote.  I think that this essentially does something like:

ln -s ca.crl `openssl crl -hash -noout -in ca.crl`.r0

However, when we did a test upgrade one of our production instances the requests are failing and, in the error logs, we are seeing the following messages:


[ssl.debug] [pid 4866] ssl_engine_kernel.c: [client 10.10.10.10-xxxx] Certificate Verification, depth 1, CRL checking mode: chain [subject: CN=CA4,OU=branch,.... / issuer: CN=Root 3,OU=branch,... / serial: 86 / notbefore: Aug 1 00:00:00 2013 GMT / notafter: Aug 1 00:00:00 2021 GMT] 

[ssl.info] [pid 4866] [client 10.10.10.10-xxxx] Certificate Verification: Error (12): CRL has expired [subject: CN=CA4,OU=branch,... / issuer: CN=Root 3,... / serial: 86 / notbefore: Aug 1 00:00:00 2013 GMT / notafter: Aug 1 00:00:00 2021 GMT] 



We checked all of the CRL files and they all appear to be within their validity periods, so we are really puzzled as to what is causing this problem.

Also, I should mention a couple of additional pieces of info:

- After the Apache upgrade, we explicitly re-generated the CRL hashes using openssl 1.0.1x.
- We did another set of tests, where instead of using the Apache SSLCARevocationPath directive and the CRLs and hashes in the directoryl, we glommed all of the CRLs together into a big PEM file and used SSLCARevocationFile directory, and when we did that that, we did not get the "Error 12"/Expired errors.  




The thing is that we have not been able to replicate this problem in our test environment, when we try to re-create a similar PKI heirarchy, so we (or I) suspect that there may be something going on with either the CRLs or cert files themselves that we are getting from the CAs (but recall that these same CRLs worked with older Apache.  

So I was wondering: If there is any known situations (e.g., some combination of constraints, etc., maybe some difference in versions or something in the CRL formats) that Apache/openssl to think that the CRL was expired and cause "Error 12" to be logged, but where the problem was being cause by something other than the CRL files actually being expired?


As I said, I wasn't quite sure where to post this, but I'm hoping that someone here might have some clue about what is causing this problem.


Thanks in advance,
Jim

From BYan at visa.com  Tue Mar  8 19:36:52 2016
From: BYan at visa.com (Yan, Bob)
Date: Tue, 8 Mar 2016 19:36:52 +0000
Subject: [openssl-users] SSL_accept error code
In-Reply-To: <56DE9B68.9020106@openssl.org>
References: <95aecac2232c4815a305a996d8a14fd4@SW550EXP003.visa.com>
 <56DE9B68.9020106@openssl.org>
Message-ID: <c6965f6d602e43639bb4661087888c57@SW550EXP003.visa.com>

Matt, thank you very much! It works after I use ERR_get_error() to get the error code.


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
Sent: Tuesday, March 08, 2016 1:29 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] SSL_accept error code



On 08/03/16 01:04, Yan, Bob wrote:
> Hi All,
> 
> I have a SSL server application which use SSL_accept to accept the 
> connections from client, see the code below:
> 
> int retcode = SSL_accept(mSsl);
> unsigned long error =  SSL_get_error(mSsl, retcode); 
> ERR_error_string_n(error, errmsg, sizeof(errmsg));
> 
> When something went wrong, for example Client connect server with
> ssl3 protocol (disabled), I get the error like this 
> "error:00000001:lib(0):func(0):reason(1)". Could somebody tell me that 
> is there any way to have more detailed debug messages from openssl?

You're not doing it right.

SSL_get_error() will give a return code to tell you the type of error that was received, e.g. SSL_ERROR_WANT_READ, SSL_ERROR_SYSCALL, SSL_ERROR_SSL, etc.

If error == SSL_ERROR_SSL then you can inspect the OpenSSL error queue for more details. You *do not* pass SSL_ERROR_SSL to ERR_error_string_n!
Use a function such as ERR_print_errors(), ERR_print_errors_fp(),
ERR_get_error() etc See the man pages for those functions.

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


From steve at openssl.org  Tue Mar  8 19:46:05 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 8 Mar 2016 19:46:05 +0000
Subject: [openssl-users] Something causing "Error 12"/Expired CRL during
 CRL processing
In-Reply-To: <557630337.3821732.1457465092133.JavaMail.yahoo@mail.yahoo.com>
References: <557630337.3821732.1457465092133.JavaMail.yahoo.ref@mail.yahoo.com>
 <557630337.3821732.1457465092133.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <20160308194605.GA16131@openssl.org>

On Tue, Mar 08, 2016, o haya wrote:

> 
> Our websites are configured for SSL client authentication with CRLs in a directory pointed to by SSLCACertificateRevocationPath and SSLCARevocationCheck set to "chain".  We then place our CRLs in the directory and create the hashes for them using an app or script that we wrote.  I think that this essentially does something like:
> 
> ln -s ca.crl `openssl crl -hash -noout -in ca.crl`.r0
> 
> However, when we did a test upgrade one of our production instances the requests are failing and, in the error logs, we are seeing the following messages:
> 
> 

A couple of possibilities. One is that the time isn't properly set on the
machine which has this problem. Another is that there may be multiple CRLs
with the same hash: have you checked for that? If there are you need to use
the form .r1, .r2 etc.

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

From ohaya at yahoo.com  Tue Mar  8 22:33:49 2016
From: ohaya at yahoo.com (o haya)
Date: Tue, 8 Mar 2016 22:33:49 +0000 (UTC)
Subject: [openssl-users] Something causing "Error 12"/Expired CRL during
 CRL processing
References: <714409060.4891710.1457476429038.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <714409060.4891710.1457476429038.JavaMail.yahoo@mail.yahoo.com>

Hello Dr. Henson,

It's been a very long time since I've been on this list... it's great that you're still here :)!!!


We were kind of wondering about the hashes (we couldn't find how they were calculated, etc.).

Can you clarify what you mean by "multiple CRLs with the same hash"?  Do you mean a situation where we have several of the CRL files (for different CAs) where the result of the "openssl hash" gives an identical number/string?

I'm not on our production site yet, so I'll ask someone who is.  I'm pretty sure that they didn't check for that as they have an automated task or something that they run under a cron job to re-calculate the hashes when they are downloaded.


Re. the "time":  I'm pretty sure the system time is correct, but will have them check, BUT if the time was wrong, how would it be able to work when we put the CRLs into a big PEM file instead of as individual files with the hashes?  In other words, if the system time was wrong, wouldn't that also cause the CRL verify to fail when the CRLs were all in one big PEM file?



A couple of more questions:  

1) Re. what I said about about HOW the hashes are calculated:  The docs say "based on the Issuer name".  Is that mean literally, i.e., the hash is only a hash of the Issuer name inside the CRL and the other contents of the CRL, like signatures, etc. don't affect the value of the hash that openssl calculates??

In other words, assuming that the Issuer names in the CRLs don't change, can we just download update CRL files and NOT re-calculate the hashes in the CRL directory?


2) When you said "A couple of possibilities": Would the duplicate hashes cause an "Error 12"/Expired CRL error?  That seems like an incorrect error?


Thanks,
Jim




--------------------------------------------
On Tue, 3/8/16, Dr. Stephen Henson <steve at openssl.org> wrote:

 Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
 To: "o haya" <ohaya at yahoo.com>, openssl-users at openssl.org
 Date: Tuesday, March 8, 2016, 2:46 PM
 
 On Tue, Mar 08, 2016, o
 haya wrote:
 
 > 
 > Our
 websites are configured for SSL client authentication with
 CRLs in a directory pointed to by
 SSLCACertificateRevocationPath and SSLCARevocationCheck set
 to "chain".? We then place our CRLs in the
 directory and create the hashes for them using an app or
 script that we wrote.? I think that this essentially does
 something like:
 > 
 >
 ln -s ca.crl `openssl crl -hash -noout -in ca.crl`.r0
 > 
 > However, when we did
 a test upgrade one of our production instances the requests
 are failing and, in the error logs, we are seeing the
 following messages:
 > 
 > 
 
 A couple
 of possibilities. One is that the time isn't properly
 set on the
 machine which has this problem.
 Another is that there may be multiple CRLs
 with the same hash: have you checked for that?
 If there are you need to use
 the form .r1,
 .r2 etc.
 
 Steve.
 --
 Dr Stephen N. Henson.
 OpenSSL project core developer.
 Commercial
 tech support now available see: http://www.openssl.org

From steve at openssl.org  Tue Mar  8 23:35:18 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 8 Mar 2016 23:35:18 +0000
Subject: [openssl-users] Something causing "Error 12"/Expired CRL during
 CRL processing
In-Reply-To: <714409060.4891710.1457476429038.JavaMail.yahoo@mail.yahoo.com>
References: <714409060.4891710.1457476429038.JavaMail.yahoo.ref@mail.yahoo.com>
 <714409060.4891710.1457476429038.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <20160308233518.GA24862@openssl.org>

On Tue, Mar 08, 2016, o haya wrote:

> 
> Can you clarify what you mean by "multiple CRLs with the same hash"?  Do you
> mean a situation where we have several of the CRL files (for different CAs)
> where the result of the "openssl hash" gives an identical number/string?
> 

The hash depends on the CRL issuer name only. It is first converted to a
canonical form and then a hash taken of the encoding. That guarantees that
identical issuer names will produce the same hash. Equivalent (i.e. equal but
not having the same encoding) issuer names *should* produce the same hash. The
hash is only 8 hex digits so there are only 2^32 possible hashes which gives a
1 in 2^16 chance of a collision: but you'd get a different error in that case.

> 
> Re. the "time":  I'm pretty sure the system time is correct, but will have
> them check, BUT if the time was wrong, how would it be able to work when we
> put the CRLs into a big PEM file instead of as individual files with the
> hashes?  In other words, if the system time was wrong, wouldn't that also
> cause the CRL verify to fail when the CRLs were all in one big PEM file?
> 

If the CRLs are in a big file then the duplicate hash issue wont affect this.
What this might be is if you have two CRLs with identical issuer name one of
which has a nextUpdate after the current time (which is what causes the error)
and one before. In the case of the hashes in a directory calling everytyhing
.r0 only one CRL would be downloaded. In a big file the valid CRL would be
selected of the two.

A question back: is the CRL set fixed when you start the server or are you
trying to update them in real time?

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

From ohaya at yahoo.com  Wed Mar  9 00:09:43 2016
From: ohaya at yahoo.com (o haya)
Date: Wed, 9 Mar 2016 00:09:43 +0000 (UTC)
Subject: [openssl-users] Something causing "Error 12"/Expired CRL during
 CRL processing
References: <852880861.4881890.1457482184004.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <852880861.4881890.1457482184004.JavaMail.yahoo@mail.yahoo.com>

I'm not sure about the answer to your last question, but I will check tomorrow.

I do know that the set of CAs is configured by us, and then they have either an app or script that gets run to re-download each of the CRLs intermittently.

What I don't know is whether they restart/reload the Apache, but I'm guessing that that they do do that.  I'll confirm tomorrow.


Based on what you said, and assuming we use individual files per CRL and with the hashes, and assuming that we just happen to have more than one CRL file that resulted in the same hash string, would that account for an Error 12/Expired CRL error?


I guess the thing that still bothers me is that they've been using this scheme/approach for awhile with the earlier Apache and with openssl 0.9.8 until this upgrade attempt recently, and it's hard to believe that they'd all of sudden be encountering hash collisions and just at the time of upgrading the Apache 2.4.16 and openssl 1.0.1e?  Talk about bad luck :)!!


I will post back tomorrow.

Thanks,
Jim



--------------------------------------------
On Tue, 3/8/16, Dr. Stephen Henson <steve at openssl.org> wrote:

 Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
 To: "o haya" <ohaya at yahoo.com>
 Cc: openssl-users at openssl.org
 Date: Tuesday, March 8, 2016, 6:35 PM
 
 On Tue, Mar 08, 2016, o
 haya wrote:
 
 > 
 > Can you clarify what you mean by
 "multiple CRLs with the same hash"?? Do you
 > mean a situation where we have several of
 the CRL files (for different CAs)
 > where
 the result of the "openssl hash" gives an
 identical number/string?
 > 
 
 The hash depends on the CRL
 issuer name only. It is first converted to a
 canonical form and then a hash taken of the
 encoding. That guarantees that
 identical
 issuer names will produce the same hash. Equivalent (i.e.
 equal but
 not having the same encoding)
 issuer names *should* produce the same hash. The
 hash is only 8 hex digits so there are only
 2^32 possible hashes which gives a
 1 in 2^16
 chance of a collision: but you'd get a different error
 in that case.
 
 > 
 > Re. the "time":? I'm pretty
 sure the system time is correct, but will have
 > them check, BUT if the time was wrong, how
 would it be able to work when we
 > put
 the CRLs into a big PEM file instead of as individual files
 with the
 > hashes?? In other words, if
 the system time was wrong, wouldn't that also
 > cause the CRL verify to fail when the CRLs
 were all in one big PEM file?
 > 
 
 If the CRLs are in a big file
 then the duplicate hash issue wont affect this.
 What this might be is if you have two CRLs with
 identical issuer name one of
 which has a
 nextUpdate after the current time (which is what causes the
 error)
 and one before. In the case of the
 hashes in a directory calling everytyhing
 .r0 only one CRL would be downloaded. In a big
 file the valid CRL would be
 selected of the
 two.
 
 A question back: is
 the CRL set fixed when you start the server or are you
 trying to update them in real time?
 
 Steve.
 --
 Dr
 Stephen N. Henson. OpenSSL project core developer.
 Commercial tech support now available see: http://www.openssl.org

From sahib.jakhar at gmail.com  Wed Mar  9 12:51:01 2016
From: sahib.jakhar at gmail.com (Sahib Jakhar)
Date: Wed, 9 Mar 2016 18:21:01 +0530
Subject: [openssl-users] SSL_accept returning error
Message-ID: <CAE+y=w4DkRKBovsygDmb=ZahU_7agi4qbceQjuL33UvTBWk2+Q@mail.gmail.com>

Hi,

I am getting the following error while doing SSL_accept on the server
side. It comes once in many tries. The error seems to come only on
windows, Linux and other platforms seem to do well.

The error is:

.\ssl\s3_pkt.c:1146 error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3
alert unexpected message


I just checked the code from s3_pkt.c, which is as follows:

        } else if (alert_level == 2) { /* fatal */
            char tmp[16];

            s->rwstate = SSL_NOTHING;
            s->s3->fatal_alert = alert_descr;
            SSLerr(SSL_F_SSL3_READ_BYTES, SSL_AD_REASON_OFFSET +
alert_descr);                                     // line 1146
            BIO_snprintf(tmp, sizeof tmp, "%d", alert_descr);
            ERR_add_error_data(2, "SSL alert number ", tmp);
            s->shutdown |= SSL_RECEIVED_SHUTDOWN;
            SSL_CTX_remove_session(s->ctx, s->session);
            return (0);
        } else {


Can somebody help me understand what could be the problem? It is more
baffling since it seems only to happen in customer environment only.


Thanks,
SJ

From stm at pdflib.com  Wed Mar  9 13:10:23 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Wed, 9 Mar 2016 14:10:23 +0100
Subject: [openssl-users] OpenSSL cannot decrypt RC4-encrypted CMS object
Message-ID: <56E020BF.9050907@pdflib.com>

Hi,

I create a self-signed certificate, encrypt some data as a CMS message 
with "-rc4", and try to decrypt it. This fails with an error message 
(tested with OpenSSL 1.0.2):

$ echo "abcdefg" >data.txt
$ openssl req -x509 -newkey rsa:2048 -keyout key.pem -nodes -out 
cert.pem -days 100 -subj "/CN=RC4 SMIME Test"
WARNING: can't open config file: /usr/local/ssl/openssl.cnf
Generating a 2048 bit RSA private key
....................................+++
.......................+++
writing new private key to 'key.pem'
-----
$ openssl cms -rc4 -encrypt -binary -in data.txt -out data.txt.cms 
-outform DER cert.pem
$ openssl cms -decrypt -in data.txt.cms -inform DER -out data2.txt 
-inkey key.pem -recip cert.pem
Error decrypting CMS structure
140735291474768:error:2E078066:CMS 
routines:cms_EncryptedContent_init_bio:cipher parameter initialisation 
error:cms_enc.c:128:

With other encryption algorithms this works as expected. Is there 
something special about RC4 and PKCS#7/CMS objects? Is this a bug?

-- 
Stephan

From weber at infotech.de  Wed Mar  9 14:13:06 2016
From: weber at infotech.de (weber at infotech.de)
Date: Wed, 9 Mar 2016 15:13:06 +0100
Subject: [openssl-users] smime -sign changes?
Message-ID: <56E02F72.3020307@infotech.de>

Dear openssl users,

we're using openssl since quite a longer time. For code signing we're 
still using separate p2s files.
Hence, in our development environment, we integrated code signing by 
commandline (batch):

     openssl smime -sign -in %1 -out %1.p7s -outform der -signer 
integritycert.cert.pem -inkey integritycert.key.pem -binary -noattr

We found newer (detached) signatures being not successfully verifiable 
within our (and by other)
applications since migration from version 1.0.1h to 1.0.2d. It seems 
like the signatures were broken.

We noticed, that the default digest algorithm has changed from sha1 to 
sha256, which is currently
documented differently. The commandline tool's usage output says nothing 
about the implemented
-md option.

Within our application we call:
     int p7flags = PKCS7_BINARY | PKCS7_NOSMIMECAP | PKCS7_NOVERIFY | 
PKCS7_NOCHAIN | PKCS7_NOSIGS;
     int rc = PKCS7_verify(p7, 0, 0, indata, out, p7flags);

and get back 0 instead of 1 while the error stack stays empty.

Surely current (and probably future) applications should use the (newer) 
cms variant, but the
older smime should still work.

Neither we found a report concerning this issue within the users mailing 
list nor we traced down
the issue itself.

Heard about this issue before? Any idea?

Thanks in advance
--
Christian Weber


From ohaya at yahoo.com  Wed Mar  9 15:09:31 2016
From: ohaya at yahoo.com (o haya)
Date: Wed, 9 Mar 2016 15:09:31 +0000 (UTC)
Subject: [openssl-users] Something causing "Error 12"/Expired CRL during
 CRL processing
References: <711241336.5212484.1457536171185.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <711241336.5212484.1457536171185.JavaMail.yahoo@mail.yahoo.com>

Dr. Henson,

It turns out that the app apparently makes copies of the old CRL files before downloading new ones, i.e., so there were multiple copies of CRL files for the same CA.

They cleaned out the directory and left only one CA CRL and the ROOT CA CRL and then it worked.

Question:  What exactly is determines the ORDER in which the CRLs would be selected?

In other words, say there were two CRL files (the previous one and the current one) but one hash (only .r0) pointing to the current CRL file.  The reason for my question is that we're (or I) am still trying to understand why we'd get the Error 12/Expired CRL?  

In this case, there'd be only one hash/soft link, pointing to one of the CRL files, and no softlink pointing to the other CRL file.

So how does OpenSSL (or Apache?) decide which of the CRLs to work with?

Thanks,
Jim

--------------------------------------------
On Tue, 3/8/16, o haya <ohaya at yahoo.com> wrote:

 Subject: Re: [openssl-users] Something causing "Error 12"/Expired CRL during CRL processing
 To: "o haya" <ohaya at yahoo.com>, "Dr. Stephen Henson" <steve at openssl.org>
 Cc: openssl-users at openssl.org
 Date: Tuesday, March 8, 2016, 7:09 PM
 
 I'm not sure about the answer to your
 last question, but I will check tomorrow.
 
 I do know that the set of CAs is configured by us, and then
 they have either an app or script that gets run to
 re-download each of the CRLs intermittently.
 
 What I don't know is whether they restart/reload the Apache,
 but I'm guessing that that they do do that.? I'll
 confirm tomorrow.
 
 
 Based on what you said, and assuming we use individual files
 per CRL and with the hashes, and assuming that we just
 happen to have more than one CRL file that resulted in the
 same hash string, would that account for an Error 12/Expired
 CRL error?
 
 
 I guess the thing that still bothers me is that they've been
 using this scheme/approach for awhile with the earlier
 Apache and with openssl 0.9.8 until this upgrade attempt
 recently, and it's hard to believe that they'd all of sudden
 be encountering hash collisions and just at the time of
 upgrading the Apache 2.4.16 and openssl 1.0.1e?? Talk
 about bad luck :)!!
 
 
 I will post back tomorrow.
 
 Thanks,
 Jim
 
 
 
 --------------------------------------------
 On Tue, 3/8/16, Dr. Stephen Henson <steve at openssl.org>
 wrote:
 
  Subject: Re: [openssl-users] Something causing "Error
 12"/Expired CRL during CRL processing
  To: "o haya" <ohaya at yahoo.com>
  Cc: openssl-users at openssl.org
  Date: Tuesday, March 8, 2016, 6:35 PM
  
  On Tue, Mar 08, 2016, o
  haya wrote:
  
  > 
  > Can you clarify what you mean by
  "multiple CRLs with the same hash"?? Do you
  > mean a situation where we have several of
  the CRL files (for different CAs)
  > where
  the result of the "openssl hash" gives an
  identical number/string?
  > 
  
  The hash depends on the CRL
  issuer name only. It is first converted to a
  canonical form and then a hash taken of the
  encoding. That guarantees that
  identical
  issuer names will produce the same hash. Equivalent (i.e.
  equal but
  not having the same encoding)
  issuer names *should* produce the same hash. The
  hash is only 8 hex digits so there are only
  2^32 possible hashes which gives a
  1 in 2^16
  chance of a collision: but you'd get a different error
  in that case.
  
  > 
  > Re. the "time":? I'm pretty
  sure the system time is correct, but will have
  > them check, BUT if the time was wrong, how
  would it be able to work when we
  > put
  the CRLs into a big PEM file instead of as individual
 files
  with the
  > hashes?? In other words, if
  the system time was wrong, wouldn't that also
  > cause the CRL verify to fail when the CRLs
  were all in one big PEM file?
  > 
  
  If the CRLs are in a big file
  then the duplicate hash issue wont affect this.
  What this might be is if you have two CRLs with
  identical issuer name one of
  which has a
  nextUpdate after the current time (which is what causes
 the
  error)
  and one before. In the case of the
  hashes in a directory calling everytyhing
  .r0 only one CRL would be downloaded. In a big
  file the valid CRL would be
  selected of the
  two.
  
  A question back: is
  the CRL set fixed when you start the server or are you
  trying to update them in real time?
  
  Steve.
  --
  Dr
  Stephen N. Henson. OpenSSL project core developer.
  Commercial tech support now available see: http://www.openssl.org

From weber at infotech.de  Wed Mar  9 15:10:53 2016
From: weber at infotech.de (weber at infotech.de)
Date: Wed, 9 Mar 2016 16:10:53 +0100
Subject: [openssl-users] smime -sign changes?
In-Reply-To: <56E02F72.3020307@infotech.de>
References: <56E02F72.3020307@infotech.de>
Message-ID: <56E03CFD.1070706@infotech.de>

Sorry, my fault. The file to de signed couldn't be hashed correctly due 
to an error while applying a patch
to the original sources.

Please ignore the issue.

--
Christian Weber

Am 09.03.2016 um 15:13 schrieb weber at infotech.de:
> Dear openssl users,
>
> we're using openssl since quite a longer time. For code signing we're 
> still using separate p2s files.
> Hence, in our development environment, we integrated code signing by 
> commandline (batch):
>
>     openssl smime -sign -in %1 -out %1.p7s -outform der -signer 
> integritycert.cert.pem -inkey integritycert.key.pem -binary -noattr
>
> We found newer (detached) signatures being not successfully verifiable 
> within our (and by other)
> applications since migration from version 1.0.1h to 1.0.2d. It seems 
> like the signatures were broken.
>
> We noticed, that the default digest algorithm has changed from sha1 to 
> sha256, which is currently
> documented differently. The commandline tool's usage output says 
> nothing about the implemented
> -md option.
>
> Within our application we call:
>     int p7flags = PKCS7_BINARY | PKCS7_NOSMIMECAP | PKCS7_NOVERIFY | 
> PKCS7_NOCHAIN | PKCS7_NOSIGS;
>     int rc = PKCS7_verify(p7, 0, 0, indata, out, p7flags);
>
> and get back 0 instead of 1 while the error stack stays empty.
>
> Surely current (and probably future) applications should use the 
> (newer) cms variant, but the
> older smime should still work.
>
> Neither we found a report concerning this issue within the users 
> mailing list nor we traced down
> the issue itself.
>
> Heard about this issue before? Any idea?
>
> Thanks in advance
> -- 
> Christian Weber

From matt at openssl.org  Wed Mar  9 15:51:43 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 9 Mar 2016 15:51:43 +0000
Subject: [openssl-users] SSL_accept returning error
In-Reply-To: <CAE+y=w4DkRKBovsygDmb=ZahU_7agi4qbceQjuL33UvTBWk2+Q@mail.gmail.com>
References: <CAE+y=w4DkRKBovsygDmb=ZahU_7agi4qbceQjuL33UvTBWk2+Q@mail.gmail.com>
Message-ID: <56E0468F.3020508@openssl.org>



On 09/03/16 12:51, Sahib Jakhar wrote:
> Hi,
> 
> I am getting the following error while doing SSL_accept on the server
> side. It comes once in many tries. The error seems to come only on
> windows, Linux and other platforms seem to do well.
> 
> The error is:
> 
> .\ssl\s3_pkt.c:1146 error:140943F2:SSL routines:SSL3_READ_BYTES:sslv3
> alert unexpected message
> 
> 
> I just checked the code from s3_pkt.c, which is as follows:
> 
>         } else if (alert_level == 2) { /* fatal */
>             char tmp[16];
> 
>             s->rwstate = SSL_NOTHING;
>             s->s3->fatal_alert = alert_descr;
>             SSLerr(SSL_F_SSL3_READ_BYTES, SSL_AD_REASON_OFFSET +
> alert_descr);                                     // line 1146
>             BIO_snprintf(tmp, sizeof tmp, "%d", alert_descr);
>             ERR_add_error_data(2, "SSL alert number ", tmp);
>             s->shutdown |= SSL_RECEIVED_SHUTDOWN;
>             SSL_CTX_remove_session(s->ctx, s->session);
>             return (0);
>         } else {
> 
> 
> Can somebody help me understand what could be the problem? It is more
> baffling since it seems only to happen in customer environment only.

The problem is caused by the client complaining that the server has sent
it an unexpected message. What is the client here? Is that OpenSSL too?
Are there any errors reported client side that might pin point what it
is complaining about?

What OpenSSL version are you running?

Matt

From steve at openssl.org  Wed Mar  9 19:01:38 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 9 Mar 2016 19:01:38 +0000
Subject: [openssl-users] Something causing "Error 12"/Expired CRL during
 CRL processing
In-Reply-To: <711241336.5212484.1457536171185.JavaMail.yahoo@mail.yahoo.com>
References: <711241336.5212484.1457536171185.JavaMail.yahoo.ref@mail.yahoo.com>
 <711241336.5212484.1457536171185.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <20160309190138.GA31568@openssl.org>

On Wed, Mar 09, 2016, o haya wrote:

> 
> Question:  What exactly is determines the ORDER in which the CRLs would be selected?
> 
> In other words, say there were two CRL files (the previous one and the current one) but one hash (only .r0) pointing to the current CRL file.  The reason for my question is that we're (or I) am still trying to understand why we'd get the Error 12/Expired CRL?  
> 
> In this case, there'd be only one hash/soft link, pointing to one of the CRL files, and no softlink pointing to the other CRL file.
> 
> So how does OpenSSL (or Apache?) decide which of the CRLs to work with?
> 

If you only have one CRL in the the form <hash>.r0 then that will get loaded.
What may have happened in your case was that there were two CRLs with the
same issuer name and the hash file only pointed to the one which was not up to
date. So OpenSSL would only load that one case and you'd get that error.

If you had CRLs of the form .r0, .r1 etc then it should've loaded both and
used the more recent one.

When you have CRLs bundled in a file they all get loaded so it will see both
and use the appropriate case.

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

From rhermann at centurioncares.com  Tue Mar  1 14:33:10 2016
From: rhermann at centurioncares.com (Rob Hermann)
Date: Tue, 1 Mar 2016 08:33:10 -0600
Subject: [openssl-users] Build OpenSSL-Release on Linux: "make tests"
 problems with certificates
Message-ID: <56D5A826.6040508@centurioncares.com>


My linux environment is linux-elf. I'm logged in as su.

When I run "make tests"  from the command line,   at the tail end of  
the tests I get some errors about expired certificates:

testing pkcs7 conversions
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
testing pkcs7 conversions (2)
p -> d
p -> p
d -> d
p -> d
d -> p
p -> p
The following command should have some OK's and some failures
There are definitly a few expired certificates
../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo 
../certs/demo/*.pem
../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty 
Ltd, CN = Test CA (1024 bit)
error 20 at 0 depth lookup:unable to get local issuer certificate
../certs/demo/dsa-ca.pem: C = AU, ST = Some-State, O = Internet Widgits 
Pty Ltd, CN = CA
error 20 at 0 depth lookup:unable to get local issuer certificate
3077822616:error:0B06E06B:x509 certificate 
routines:X509_get_pubkey_parameters:unable to find parameters in 
chain:x509_vfy.c:1966:
../certs/demo/dsa-pca.pem: C = AU, ST = Some-State, O = Internet Widgits 
Pty Ltd, CN = PCA
error 18 at 0 depth lookup:self signed certificate
C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = PCA
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/pca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty 
Ltd, CN = Test PCA (1024 bit)
error 18 at 0 depth lookup:self signed certificate
C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK
_make[1]: *** [test_verify] Error 2__
__make[1]: Leaving directory `/home/rhermann/src/OpenSSLWork/test'__
__make: *** [tests] Error 2__
_[root at rhlinuxdev OpenSSLWork]#

what do the underlined statements mean ? is there an expired certificate 
that needs to get updated ?

Rob Hermann

-- 
*Rob Hermann *
Senior Software Engineer
Centurion, Inc.
rhermann at centurioncares.com <mailto:rhermann at centurioncares.com>

www.centurioncares.com <http://www.centurioncares.com>

*Confidentiality Statement
* This email and/or any attached files are intended solely for the 
individual or entity to whom they are addressed. If you have received 
this message in error, please notify us by sending a reply email to the 
sender and remove this message and any associated attachments from your 
computer system(s). Unauthorized use, distribution, or disclosure of 
such messages may be a violation of the law. Centurion would like to 
remind you to refrain from sending private or personal information, such 
as account numbers, social security numbers, passwords, or any other 
confidential financial, credit card or business information via email or 
email attachments. For your security, you are encouraged to contact us 
via phone with any sensitive information rather than use email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160301/c4af4af4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Centurion-CARES-Email-Logo.jpg
Type: image/jpeg
Size: 102049 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160301/c4af4af4/attachment-0001.jpg>

From openssl-users at dukhovni.org  Thu Mar 10 01:50:24 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 9 Mar 2016 20:50:24 -0500
Subject: [openssl-users] Trouble compiling in version 0.9.8h
In-Reply-To: <D358E5B1511A314F8160ADC6F375498720598B85@XYSVEX02.XYPRO-23.LOCAL>
References: <CALs4rLQHfdFSCtTnHf2OQvQRG83+EYVwr4XtT7o34zwTZW5BTA@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498720598B85@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <8F3DC69A-73A2-4AB1-A448-B6F47BDCA5CC@dukhovni.org>


> On Jan 7, 2016, at 12:51 PM, Scott Neugroschl <scott_n at xypro.com> wrote:
> 
> 0.9.8h?. REALLY???? The latest is 0.9.8zh.  And on top of that 0.9.8 got EOL?ed as of the beginning of the year.
> Can you update to 1.0.1?  (Latest is 1.0.1q).

Latest is 1.0.1s from 01/Mar/2016 (you also missed 1.0.1r from 28/Jan/2016).
However, if updating better to use 1.0.2g.

-- 
	Viktor.


From sahib.jakhar at gmail.com  Thu Mar 10 04:43:36 2016
From: sahib.jakhar at gmail.com (Sahib Jakhar)
Date: Thu, 10 Mar 2016 10:13:36 +0530
Subject: [openssl-users] SSL_accept returning error
In-Reply-To: <56E0468F.3020508@openssl.org>
References: <CAE+y=w4DkRKBovsygDmb=ZahU_7agi4qbceQjuL33UvTBWk2+Q@mail.gmail.com>
 <56E0468F.3020508@openssl.org>
Message-ID: <CAE+y=w6fQwsr5440KQwitx=jyerT7F1zFE14cZh31bW7ucDLJw@mail.gmail.com>

On Wed, Mar 9, 2016 at 9:21 PM, Matt Caswell <matt at openssl.org> wrote:
>
> The problem is caused by the client complaining that the server has sent
> it an unexpected message. What is the client here? Is that OpenSSL too?

Yes the client is OpenSSL too.

> Are there any errors reported client side that might pin point what it
> is complaining about?
>

I will try to find out what error client is giving.

> What OpenSSL version are you running?

It is 0.9.8zg-fips. That is older version of our product. I have a
lingering doubt that it has something to do with session resumption we
have introduced. Earlier the same code used to work.

From googleersatz at oliverniebuhr.de  Thu Mar 10 04:42:36 2016
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Thu, 10 Mar 2016 05:42:36 +0100
Subject: [openssl-users] [Question] What are the current secure Configure
	Parameter?
Message-ID: <56E0FB3C.6040306@oliverniebuhr.de>

Hello.

I am using OpenSSL from within the Qt Project / QtWebEngine.

The Qt Wiki says, the following Parameters are minimum recommended:
no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5

Since 1.0.2g, SSL2 has been removed completely. So no-ssl2 is not needed
anymore.

My Questions are:
1.) Are there any other Parameters that should be used?
2.) What are the Parameters for a 'Paranoid' build aka absolute Security
without any comprimises?

Use Case:
OpenSSL get invoked by QtWebEngine automatically. There is no direct use
from my side - yet.

The QtWebEngine based Browser Widget is part of something like a
"Software Suite": It will not replace Standard Browser like Firefox.

Everything older than TLS 1.0 should not be supported.

This Software Suite is used 99 Percent on private PCs and not in a
Enterprise Environment.

But it must still be secure as possible to transceive Personal Data
(i.e. Database Entries), Chat etc.

Project is in "Alpha" State - there is no VServer or something similar
yet to concentrate Communication etc.

The (OpenSSL)Server Setup will be based on what you Experts have to say.

Environment:
Under Windows 7 to Windows 10: CygWin / MSVC 2015 (compilation done
under Win10).

Under Antergos Linux (KDE): GCC 4.9.2 (not tested yet if Qt can be built
with GCC >=5.x as the Qt Framework is 4.9.x based).

Thank You for your Time!
And please forgive me my horrible english :)
Oliver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160310/009f7538/attachment.sig>

From matt at openssl.org  Thu Mar 10 09:51:24 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 10 Mar 2016 09:51:24 +0000
Subject: [openssl-users] SSL_accept returning error
In-Reply-To: <CAE+y=w6fQwsr5440KQwitx=jyerT7F1zFE14cZh31bW7ucDLJw@mail.gmail.com>
References: <CAE+y=w4DkRKBovsygDmb=ZahU_7agi4qbceQjuL33UvTBWk2+Q@mail.gmail.com>
 <56E0468F.3020508@openssl.org>
 <CAE+y=w6fQwsr5440KQwitx=jyerT7F1zFE14cZh31bW7ucDLJw@mail.gmail.com>
Message-ID: <56E1439C.4000307@openssl.org>



On 10/03/16 04:43, Sahib Jakhar wrote:
> On Wed, Mar 9, 2016 at 9:21 PM, Matt Caswell <matt at openssl.org> wrote:
>>
>> The problem is caused by the client complaining that the server has sent
>> it an unexpected message. What is the client here? Is that OpenSSL too?
> 
> Yes the client is OpenSSL too.
> 

Is the client version 0.9.8 too?

>> Are there any errors reported client side that might pin point what it
>> is complaining about?
>>
> 
> I will try to find out what error client is giving.

Please do, it will likely be more informative as to the real source of
the problem.

> 
>> What OpenSSL version are you running?
> 
> It is 0.9.8zg-fips. That is older version of our product. I have a
> lingering doubt that it has something to do with session resumption we
> have introduced. Earlier the same code used to work.
> 

You realise that version 0.9.8 is out of support and is no longer
receiving security fixes?

Matt

From michel.sales at free.fr  Thu Mar 10 10:52:00 2016
From: michel.sales at free.fr (Michel)
Date: Thu, 10 Mar 2016 11:52:00 +0100
Subject: [openssl-users] enc oddities, bad decrypt, bad magig, too bad
Message-ID: <001b01d17aba$dfc54c10$9f4fe430$@sales@free.fr>

Hi,

 

I had to write a small program which at some point need to encrypt a piece
of 

data that I intended to be able to decrypt later (at least) using OpenSLL.

So I started to review the doc about the enc command.

I saw that it was possible to use salt, key, IV and/or a passphrase.

Though I believed naively it will be a simple task ... but it was not so
easy.

 

First I tried : 

openssl enc    -aes-128-cbc -iv ... -K ... -in ... -out ...

openssl enc -d -aes-128-cbc -iv ... -K ... -in ... 

It works as expected.

 

I checked it was possible to retrieve the key and IV given the salt :

openssl enc -aes-128-cbc -S ... -P

salt=...

key=...

iv =...

It also works as expected.

 

I checked [unfortunately] with a passphrase :

openssl enc    -aes-128-cbc -S ... -in ... -out ...  

openssl enc -d -aes-128-cbc -S ... -in ... 

It works as expected.

 

I was happy with that and confident enouth to start working.

Then I tried :

openssl enc -d -aes-128-cbc -iv ... -K ... -in ... 

But it fails with "bad decrypt"

So I search for errors in my code.

 

Then trying desperately anything and everything I was surprised that :

openssl enc -d -aes-128-cbc -in ... 

Succeeded ?

I started to understand that the salt was stored with the data.

Happy again (not for long), I tried :

openssl enc    -aes-128-cbc -iv ... -K ... -in ... -out ...

openssl enc -d -aes-128-cbc -in ... 

But this time got 'bad magic number'.

:-(

It was late and I felt down as I didn't see any 'magic', just curse !

 

Now the reason :

Yes the salt is stored with the encrypting data. But not always.

And not only when it is not supplied (therefore generated).

It is stored when no key is given.

And when stored, even good IV and key fails to decrypt. 

You must enter the password (but are NOT prompted for).

 

In the hope it will save some time to others,

 

Michel.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160310/54bcb606/attachment.html>

From swall at redcom.com  Thu Mar 10 13:49:17 2016
From: swall at redcom.com (Wall, Stephen)
Date: Thu, 10 Mar 2016 08:49:17 -0500
Subject: [openssl-users] [Question] What are the current secure
 Configure	Parameter?
In-Reply-To: <56E0FB3C.6040306@oliverniebuhr.de>
References: <56E0FB3C.6040306@oliverniebuhr.de>
Message-ID: <401084E5E73F4241A44F3C9E6FD79428036889C546@exch-01>


> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Oliver Niebuhr
> 
> The Qt Wiki says, the following Parameters are minimum recommended:
> no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
> 
> My Questions are:
> 1.) Are there any other Parameters that should be used?

I also add no-comp -DOPENSSL_NO_HEARTBEAT no-md2.

no-md2 might be a default.

Check Configure Options at https://wiki.openssl.org/index.php/Compilation_and_Installation for some other things you might not need, like no-srp no-psk no-dtls no-npn no-krb5 etc.  If this is a dedicated library for your application, I suggest you disable all features and ciphers you won't be using, for example, no-bf no-sha1 no-md5 no-seed etc....

If you control both ends, you could even distill it down to a single protocol cipher suite, like ECDHE-ECDSA-AES128-GCM-SHA256 with TLS1.2.

From pgnet.dev at gmail.com  Thu Mar 10 14:52:14 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Thu, 10 Mar 2016 06:52:14 -0800
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need and
	correct usage
Message-ID: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>

I'm building openssl 1.0.2g on linux64.

After

	./configure ...

I'm prompted

	Since you've disabled or enabled at least one algorithm, you need to do
	the following before building:

		make depend

Exec'ing the 'make depend' stage returns lots of warnings,

	make depend
		making depend in crypto...
		make[1]: Entering directory '/usr/local/src/openssl/openssl-1.0.2g/crypto'
		makedepend: warning:  cryptlib.c (reading /usr/include/stdlib.h, line 
32): cannot find include file "stddef.h"
		        not in ./stddef.h
		        not in ../stddef.h
		        not in ../include/stddef.h
		        not in /usr/include/stddef.h
		makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
		Already have
		        /usr/include/bits/types.h
		makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
		Already have
		        /usr/include/bits/types.h
		makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
		Already have
		        /usr/include/bits/types.h
		makedepend: warning:  cryptlib.c (reading /usr/include/sys/types.h, 
line 146): cannot find include file "stddef.h"
		        not in ./stddef.h
		        not in ../stddef.h
		        not in ../include/stddef.h
		        not in /usr/include/stddef.h
		makedepend: warning:  cryptlib.c (reading /usr/include/alloca.h, line 
24): cannot find include file "stddef.h"
		        not in ./stddef.h
		        not in ../stddef.h
		        not in ../include/stddef.h
		        not in /usr/include/stddef.h
		...

On the distro, stddef.h is available at

	/usr/include/linux/stddef.h
	/usr/lib64/gcc/x86_64-suse-linux/4.8/include/stddef.h
	/usr/lib64/gcc/x86_64-suse-linux/5/include/stddef.h


Reading wiki & reports at openssl, there's confusing, if not 
conflicting, advice.

Must use it,

	(1) https://wiki.openssl.org/index.php/Compilation_and_Installation
		Dependencies

		If you are prompted to run make depend, then you must do so. Its not 
just for developers who are updating sources. Its required to update the 
standard distribution once configuration options change.

Don't need it

	(2) https://wiki.openssl.org/index.php/Compilation_and_Installation
		Compilation
			After configuring the library, you should run make. If prompted, 
there's usually no need to make depend since you are building from a 
clean download.

	(3) 
https://rt.openssl.org/Ticket/Display.html?id=3566&user=guest&pass=guest
			"Obviously this needs fixing but as a workaround: if you're building 
from scratch (or after "make clean") it should compile fine with without 
doing "make depend".

			Steve.
			--
			Dr Stephen N. Henson. OpenSSL project core developer."


Re: 'makedepend',

	https://en.wikipedia.org/wiki/Makedepend
		makedepend was developed as part of MIT's Project Athena. It was used 
extensively in building X11 and ancillary packages, but has since become 
superseded by the dependency generation facilities of various compilers, 
and is now used primarily as a worst-case fallback, e.g. by depcomp and 
GNU Automake.

Further, a quick check (https://www.google.com/search?q=makedepend+stddef
) shows that there's a long history (unresolved?) re: not finding the 
sys's stddef.h

Digging around some more, I find that virtually the same issue was 
raised on openssl-dev in Apr 2015,

	https://mta.openssl.org/pipermail/openssl-dev/2015-April/001263.html
	[openssl-dev] `make depend`, advised by ./config, fails to find 
stddef.h in system/compiler path. old bug (#3566) says don't bother with 
`make depend`? true, or another bug?

with no reply at all.

What, then, IS the current need for 'makedepend' in openssl, and what, 
exactly, is the correct/recommended usage for its use in an openssl build?

From pgnet.dev at gmail.com  Thu Mar 10 15:03:39 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Thu, 10 Mar 2016 07:03:39 -0800
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
	and correct usage
In-Reply-To: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
Message-ID: <a887ea9c-b327-5269-4144-0db5a9aec10b@gmail.com>

Actually, the actual admonition is more emphatic

> I'm prompted
>
>     Since you've disabled or enabled at least one algorithm, you need to do
>     the following before building:
>
>         make depend

"
Configured for linux-x86_64.

*** Because of configuration changes, you MUST do the following before
*** building:

         make depend
"

From rwelty at nwtime.org  Thu Mar 10 15:57:37 2016
From: rwelty at nwtime.org (Richard Welty)
Date: Thu, 10 Mar 2016 10:57:37 -0500
Subject: [openssl-users] OpenSSL in unit tests - setup/teardown issue
Message-ID: <56E19971.7060206@nwtime.org>

i'm working on unit tests for the new NTS stuff for NTP and am having
some issues with setup & teardown for OpenSSL; there may be an actual
bug here; i'm looking for some guidance.

NTP is currently using the Unity test framework, which is a fairly
standard unit testing package. i have two tests for NTS, one is for
a group of wrappers around some CMS calls, and the second exercises
a higher level set of functions.

the CMS wrapper tests complete successfully, but second set of tests
goes into an infinite loop inside a call to X509_ALGOR_new()
i have disabled all the actual tests in the CMS test section and
i have trimmed back the setup and teardown to the following, but
X509_ALGOR_new() is still going into an infinite loop in the setup
for the second batch of tests:


void setUp()
{
  OpenSSL_add_all_algorithms();
  ERR_load_crypto_strings();

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160310/2d076b66/attachment.sig>

From pgnet.dev at gmail.com  Thu Mar 10 17:04:00 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Thu, 10 Mar 2016 09:04:00 -0800
Subject: [openssl-users] openssl 1.0.2g build fails with 'no-comp' or
 'no-comp no-bio' configure options?
Message-ID: <87c5aa8c-2877-c643-f85c-015b66af24ce@gmail.com>

I'm building openssl 1.0.2g on linux64

With my usual

	./config ...

I end up with a successful build/install

	openssl version
		OpenSSL 1.0.2g  1 Mar 2016

If I add

	./config no-comp ...

subsequent 'make' fails

	make
		...
		make[1]: Leaving directory '/usr/local/src/openssl/openssl-1.0.2g/ssl'
		making all in apps...
		make[1]: Entering directory '/usr/local/src/openssl/openssl-1.0.2g/apps'
		rm -f openssl
		shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then \
		        shlib_target="linux-shared"; \
		elif [ -n "" ]; then \
		  FIPSLD_CC="/usr/bin/gcc-5"; CC=/usr/local/ssl/fips-2.0/bin/fipsld; 
export CC FIPSLD_CC; \
		fi; \
		LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \
		make -f ../Makefile.shared -e \
		        APPNAME=openssl OBJECTS="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 rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o 
genrsa.o gendsa.o genpkey.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 pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o 
rand.o engine.o ocsp.o prime.o ts.o srp.o" \
		        LIBDEPS=" $LIBRARIES -Wl,-z,relro,-z,now -ldl -lz" \
		        link_app.${shlib_target}
		make[2]: Entering directory '/usr/local/src/openssl/openssl-1.0.2g/apps'
		enc.o: In function `enc_main':
		enc.c:(.text+0x1253): undefined reference to `BIO_f_zlib'
		collect2: error: ld returned 1 exit status
		../Makefile.shared:171: recipe for target 'link_app.gnu' failed
		make[2]: *** [link_app.gnu] Error 1
		make[2]: Leaving directory '/usr/local/src/openssl/openssl-1.0.2g/apps'
		Makefile:156: recipe for target 'openssl' failed
		make[1]: *** [openssl] Error 2
		make[1]: Leaving directory '/usr/local/src/openssl/openssl-1.0.2g/apps'
		Makefile:292: recipe for target 'build_apps' failed
		make: *** [build_apps] Error 1

Adding further

	./config no-comp no-bio ...

'make' fails again, differently

	make
		...
		making all in crypto...
		make[1]: Entering directory '/usr/local/src/openssl/openssl-1.0.2g/crypto'
		/usr/bin/gcc-5 -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_GNU_SOURCE 
-DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEAT -DPURIFY 
-DSSL_FORBID_ENULL -DTERMIO -Wa,--noexecstack -Wall -fno-common 
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-DCHAPOLY_x86_64_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -O3 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector 
-funwind-tables -fasynchronous-unwind-tables -fmessage-length=0 
-grecord-gcc-switches -march=x86-64 -mtune=nocona  -c -o cpt_err.o cpt_err.c
		In file included from cpt_err.c:63:0:
		../include/openssl/err.h:149:5: error: unknown type name 'CRYPTO_THREADID'
		     CRYPTO_THREADID tid;
		     ^
		../include/openssl/err.h:355:36: error: unknown type name 
'CRYPTO_THREADID'
		 void ERR_remove_thread_state(const CRYPTO_THREADID *tid);
		                                    ^
		<builtin>: recipe for target 'cpt_err.o' failed
		make[1]: *** [cpt_err.o] Error 1
		make[1]: Leaving directory '/usr/local/src/openssl/openssl-1.0.2g/crypto'
		Makefile:286: recipe for target 'build_crypto' failed
		make: *** [build_crypto] Error 1


Are additional/different config options required to enable/support the 
'no-comp' & 'no-bio' options?


From pgnet.dev at gmail.com  Thu Mar 10 17:23:05 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Thu, 10 Mar 2016 09:23:05 -0800
Subject: [openssl-users] openssl 1.0.2g build linking to wrong libs --
 'system' instead of 'own'. How to correct?
Message-ID: <f61d6b8d-da9d-153b-e785-50d21e672e85@gmail.com>

I'm building 1.0.2g on linux64.

I'm trying to get a self-consistent build, linked to the right libs.

Building

	cd ./openssl-1.0.2g
	./config \
	 --openssldir=/home/dev/ssl --libdir=lib64 \
	 threads shared zlib -D_GNU_SOURCE -DPURIFY -DTERMIO \
	 -Wa,--noexecstack -Wl,-z,relro,-z,now -Wall -fno-common

	make depend
	make
	make install

Then checking

	ldd /home/dev/ssl/lib64/*.so* | egrep "ssl|crypto"
		/home/dev/ssl/lib64/libcrypto.so:
		/home/dev/ssl/lib64/libcrypto.so.1.0.0:
		/home/dev/ssl/lib64/libssl.so:
		        libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 
(0x00007f6154f37000)
		/home/dev/ssl/lib64/libssl.so.1.0.0:
		        libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 
(0x00007fd60fbbc000)

Why are these libs linked to SYSTEM libs, not the just-built libs, in 
the specified $openssldir/$libdir ?

It can be fixed after the fact,

	patchelf --set-rpath "/home/dev/ssl/lib64" --force-rpath 
/home/dev/ssl/lib64/libssl.so.1.0.0
	ldd /home/dev/ssl/lib64/libssl.so | egrep "ssl|crypto"
		libcrypto.so.1.0.0 => /home/dev/ssl/lib64/libcrypto.so.1.0.0 
(0x00007ff7f06fa000)

but that shouldn't be required.

What's the correct config+build procedure for ending up with 
self-consistent linking?


From jeremy.farrell at oracle.com  Thu Mar 10 17:33:51 2016
From: jeremy.farrell at oracle.com (Jeremy Farrell)
Date: Thu, 10 Mar 2016 17:33:51 +0000
Subject: [openssl-users] openssl 1.0.2g build fails with 'no-comp' or
 'no-comp no-bio' configure options?
In-Reply-To: <87c5aa8c-2877-c643-f85c-015b66af24ce@gmail.com>
References: <87c5aa8c-2877-c643-f85c-015b66af24ce@gmail.com>
Message-ID: <56E1AFFF.4050801@oracle.com>

On 10/03/2016 17:04, PGNet Dev wrote:
> I'm building openssl 1.0.2g on linux64
>
> With my usual
>
>     ./config ...
>
> I end up with a successful build/install
> ...
> If I add
>
>     ./config no-comp ...
>
> subsequent 'make' fails
>
>     make
>         ...
>         enc.c:(.text+0x1253): undefined reference to `BIO_f_zlib'

Adding one or both of no-zlib no-zlib-dynamic should handle that.

> Adding further
>
>     ./config no-comp no-bio ...
>
> 'make' fails again, differently
> ...
> Are additional/different config options required to enable/support the 
> 'no-comp' & 'no-bio' options?
>

I've not built with no-bio, suspect it is much more intimately entangled 
and may not be practical in 1.0.2g; there's been a lot of work done in 
master to clean up various optional exclusions, I think no-bio is 
expected to be working there.

-- 
J. J. Farrell
Not speaking for Oracle.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160310/eeb73b32/attachment.html>

From pgnet.dev at gmail.com  Thu Mar 10 18:44:23 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Thu, 10 Mar 2016 10:44:23 -0800
Subject: [openssl-users] openssl 1.0.2g build fails with 'no-comp' or
 'no-comp no-bio' configure options?
In-Reply-To: <CAHv26Dj83O9=b_Y5OzuCGv-d0ANL+c5yFRu8R-RMbqDeC+C9UA@mail.gmail.com>
References: <87c5aa8c-2877-c643-f85c-015b66af24ce@gmail.com>
 <56E1AFFF.4050801@oracle.com>
 <CAHv26Dj83O9=b_Y5OzuCGv-d0ANL+c5yFRu8R-RMbqDeC+C9UA@mail.gmail.com>
Message-ID: <f4a60916-09ad-1953-7ab1-7a782214b039@gmail.com>

On 03/10/2016 10:19 AM, PGNetwork Dev wrote:
>>         ./config no-comp ...
>>
>>     subsequent 'make' fails
>>
>>         make
>>             ...
>>             enc.c:(.text+0x1253): undefined reference to `BIO_f_zlib'
>
>     Adding one or both of no-zlib no-zlib-dynamic should handle that.

My read of

	"no-comp 	Disables compression independent of zlib. OPENSSL_NO_COMP 
will be defined in the OpenSSL headers."

is that this disables compression methods OTHER than zlib.

Is the intent, instead, that it disables ALL compression, REGARDLESS of 
the presence/setting of zlib?

>     I've not built with no-bio, suspect it is much more intimately
>     entangled and may not be practical in 1.0.2g; there's been a lot of
>     work done in master to clean up various optional exclusions, I think
>     no-bio is expected to be working there.

Ah, I see the diffs in the 1.0.2 -> 1.1.0 changelog at

   https://www.openssl.org/news/changelog.html


From noloader at gmail.com  Thu Mar 10 18:50:57 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 10 Mar 2016 13:50:57 -0500
Subject: [openssl-users] openssl 1.0.2g build fails with 'no-comp' or
 'no-comp no-bio' configure options?
In-Reply-To: <87c5aa8c-2877-c643-f85c-015b66af24ce@gmail.com>
References: <87c5aa8c-2877-c643-f85c-015b66af24ce@gmail.com>
Message-ID: <CAH8yC8mMHwN97QE3v1Wn8zChK9gh4sg1B5+RT0X+pEMXd2PDow@mail.gmail.com>

On Thu, Mar 10, 2016 at 12:04 PM, PGNet Dev <pgnet.dev at gmail.com> wrote:
> I'm building openssl 1.0.2g on linux64
>
> With my usual
>
>         ./config ...
>
> I end up with a successful build/install
>
>         openssl version
>                 OpenSSL 1.0.2g  1 Mar 2016
>
> If I add
>
>         ./config no-comp ...
>
> subsequent 'make' fails
>
>         make
>                 ...
>                 make[1]: Leaving directory
> '/usr/local/src/openssl/openssl-1.0.2g/ssl'
>                 making all in apps...
>                 make[1]: Entering directory
> '/usr/local/src/openssl/openssl-1.0.2g/apps'
>                 rm -f openssl
>                 shlib_target=; if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0"
> ]; then \
>                         shlib_target="linux-shared"; \
>                 elif [ -n "" ]; then \
>                   FIPSLD_CC="/usr/bin/gcc-5";
> CC=/usr/local/ssl/fips-2.0/bin/fipsld; export CC FIPSLD_CC; \
>                 fi; \
>                 LIBRARIES="-L.. -lssl  -L.. -lcrypto" ; \
>                 make -f ../Makefile.shared -e \
>                         APPNAME=openssl OBJECTS="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 rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o
> genrsa.o gendsa.o genpkey.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 pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o
> ocsp.o prime.o ts.o srp.o" \
>                         LIBDEPS=" $LIBRARIES -Wl,-z,relro,-z,now -ldl -lz" \
>                         link_app.${shlib_target}
>                 make[2]: Entering directory
> '/usr/local/src/openssl/openssl-1.0.2g/apps'
>                 enc.o: In function `enc_main':
>                 enc.c:(.text+0x1253): undefined reference to `BIO_f_zlib'
>                 collect2: error: ld returned 1 exit status
>                 ../Makefile.shared:171: recipe for target 'link_app.gnu'
> failed
>                 make[2]: *** [link_app.gnu] Error 1
>                 make[2]: Leaving directory
> '/usr/local/src/openssl/openssl-1.0.2g/apps'
>                 Makefile:156: recipe for target 'openssl' failed
>                 make[1]: *** [openssl] Error 2
>                 make[1]: Leaving directory
> '/usr/local/src/openssl/openssl-1.0.2g/apps'
>                 Makefile:292: recipe for target 'build_apps' failed
>                 make: *** [build_apps] Error 1
> ...
>
> Are additional/different config options required to enable/support the
> 'no-comp' & 'no-bio' options?

That appears to be a regression. You should consider filing a bug
report. Also see http://www.openssl.org/docs/faq.html#BUILD17.

Jeff

From noloader at gmail.com  Thu Mar 10 19:07:22 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 10 Mar 2016 14:07:22 -0500
Subject: [openssl-users] openssl 1.0.2g build linking to wrong libs --
 'system' instead of 'own'. How to correct?
In-Reply-To: <f61d6b8d-da9d-153b-e785-50d21e672e85@gmail.com>
References: <f61d6b8d-da9d-153b-e785-50d21e672e85@gmail.com>
Message-ID: <CAH8yC8mzGmqdL2WLcnNTJfCyiKxuH+mtwniALhPb4QHLJr7-sQ@mail.gmail.com>

On Thu, Mar 10, 2016 at 12:23 PM, PGNet Dev <pgnet.dev at gmail.com> wrote:
> I'm building 1.0.2g on linux64.
>
> I'm trying to get a self-consistent build, linked to the right libs.
>
> Building
>
>         cd ./openssl-1.0.2g
>         ./config \
>          --openssldir=/home/dev/ssl --libdir=lib64 \
>          threads shared zlib -D_GNU_SOURCE -DPURIFY -DTERMIO \
>          -Wa,--noexecstack -Wl,-z,relro,-z,now -Wall -fno-common
>
>         make depend
>         make
>         make install
>
> Then checking
>
>         ldd /home/dev/ssl/lib64/*.so* | egrep "ssl|crypto"
>                 /home/dev/ssl/lib64/libcrypto.so:
>                 /home/dev/ssl/lib64/libcrypto.so.1.0.0:
>                 /home/dev/ssl/lib64/libssl.so:
>                         libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0
> (0x00007f6154f37000)
>                 /home/dev/ssl/lib64/libssl.so.1.0.0:
>                         libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0
> (0x00007fd60fbbc000)
>
> Why are these libs linked to SYSTEM libs, not the just-built libs, in the
> specified $openssldir/$libdir ?
>
> It can be fixed after the fact,
>
>         patchelf --set-rpath "/home/dev/ssl/lib64" --force-rpath
> /home/dev/ssl/lib64/libssl.so.1.0.0
>         ldd /home/dev/ssl/lib64/libssl.so | egrep "ssl|crypto"
>                 libcrypto.so.1.0.0 => /home/dev/ssl/lib64/libcrypto.so.1.0.0
> (0x00007ff7f06fa000)
>
> but that shouldn't be required.
>
> What's the correct config+build procedure for ending up with self-consistent
> linking?

https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs

Jeff

From michael at secure-mail.biz  Thu Mar 10 19:11:18 2016
From: michael at secure-mail.biz (michael at secure-mail.biz)
Date: Thu, 10 Mar 2016 20:11:18 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
	intermediate/subordinate ca
Message-ID: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160310/8d1256a2/attachment.html>

From jb-openssl at wisemo.com  Thu Mar 10 21:41:28 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 10 Mar 2016 22:41:28 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
Message-ID: <56E1EA08.1070409@wisemo.com>

On 10/03/2016 20:11, michael at secure-mail.biz wrote:
> Hey openssl users,
>
> I am testing with revoking certificates.
>
> My PKI has a root and 2 intermediates, which then sign server and 
> client certificates
> My test environment consists of a s_client and a s_server referencing 
> the corresponding files and a verifydir with c_rehased files.
> TLS connections work fine from s_client to s_server, chain is exposed 
> and recognized properly.
>
> I successfully revoked server-certificates with the intermediate ca crl.
> When trying to connect using the s_client "-crl_check" arg the 
> "certificate revoked" notification shows up correctly.
>
> I also successfully created a crl with the root ca, that revokes one 
> of the intermediates.
> The serialnumber of the revoked intermediate is shown correctly in the 
> crl and the crl is c_rehashed in the verify dir of the client.
> But no matter what i try, the s_client does NOT show the "certificate 
> revoked" when I connect to the corresponding s_server using the 
> certificate signed by the revoked intermediate.
>
> Any ideas what i could be doing wrong?

Make sure the intermediary is not included in the "CA storage"
(hashed or single file) used by the client.  Anything in that
storage is considered valid and not checked for revocation or
validity.

>
> I am on version OpenSSL 1.0.1f 6 Jan 2014
>
That's a bit old.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From openssl-users at dukhovni.org  Thu Mar 10 22:06:22 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Mar 2016 22:06:22 +0000
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <56E1EA08.1070409@wisemo.com>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com>
Message-ID: <20160310220622.GH10917@mournblade.imrryr.org>

On Thu, Mar 10, 2016 at 10:41:28PM +0100, Jakob Bohm wrote:

> >Any ideas what i could be doing wrong?
> 
> Make sure the intermediary is not included in the "CA storage"
> (hashed or single file) used by the client.  Anything in that
> storage is considered valid and not checked for revocation or
> validity.

This is changing in OpenSSL 1.1.0, and may yet change in a future
OpenSSL 1.0.2 update.  Only the trust-anchor (top-most certificate
from the trust-store) is not checked for expiration or revocation
in OpenSSL 1.1.0.

Intermediate certificates are checked, whether they are from the
trust-store, or acquired from the peer.  To get previous behaviour,
one needs to set the X509_V_FLAG_PARTIAL_CHAIN flag so that the
first certificate found in the trust store becomes the trust-anchor,
and chain construction stops there.

Another way (in OpenSSL 1.1.0) to get an intermediate certificate
to terminate the chain is to decorate it with explicit auxiliary
trust EKUs via the "-trustout" and "-addtrust" options of "openssl
x509", and then add the decorated certificate to the trust store.

-- 
	Viktor.

From jb-openssl at wisemo.com  Thu Mar 10 22:29:12 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 10 Mar 2016 23:29:12 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <20160310220622.GH10917@mournblade.imrryr.org>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com> <20160310220622.GH10917@mournblade.imrryr.org>
Message-ID: <56E1F538.5000400@wisemo.com>

On 10/03/2016 23:06, Viktor Dukhovni wrote:
> On Thu, Mar 10, 2016 at 10:41:28PM +0100, Jakob Bohm wrote:
>
>>> Any ideas what i could be doing wrong?
>> Make sure the intermediary is not included in the "CA storage"
>> (hashed or single file) used by the client.  Anything in that
>> storage is considered valid and not checked for revocation or
>> validity.
> This is changing in OpenSSL 1.1.0, and may yet change in a future
> OpenSSL 1.0.2 update.  Only the trust-anchor (top-most certificate
> from the trust-store) is not checked for expiration or revocation
> in OpenSSL 1.1.0.
>
> Intermediate certificates are checked, whether they are from the
> trust-store, or acquired from the peer.  To get previous behaviour,
> one needs to set the X509_V_FLAG_PARTIAL_CHAIN flag so that the
> first certificate found in the trust store becomes the trust-anchor,
> and chain construction stops there.
>
> Another way (in OpenSSL 1.1.0) to get an intermediate certificate
> to terminate the chain is to decorate it with explicit auxiliary
> trust EKUs via the "-trustout" and "-addtrust" options of "openssl
> x509", and then add the decorated certificate to the trust store.
>
This will cause a lot of grief when both OpenSSL versions
are used on the same system, (since 1.1.0 is not a drop in
replacement for OpenSSL 1.0.x), with the same default trust
store directory.

It would have been much better to use a separate directory
for untrusted chain-building intermediary certificates, just
like some other libraries do.

This is unlike the hash algorithm change between 0.9.8 and 1.0.x,
since double hashing the shared trust store solved that issue
completely.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160310/41101bc8/attachment-0001.html>

From openssl-users at dukhovni.org  Thu Mar 10 22:41:32 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Mar 2016 22:41:32 +0000
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <56E1F538.5000400@wisemo.com>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com>
 <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com>
Message-ID: <20160310224132.GI10917@mournblade.imrryr.org>

On Thu, Mar 10, 2016 at 11:29:12PM +0100, Jakob Bohm wrote:

> >This is changing in OpenSSL 1.1.0, and may yet change in a future
> >OpenSSL 1.0.2 update.  Only the trust-anchor (top-most certificate
> >from the trust-store) is not checked for expiration or revocation
> >in OpenSSL 1.1.0.
> >
> >Intermediate certificates are checked, whether they are from the
> >trust-store, or acquired from the peer.  To get previous behaviour,
> >one needs to set the X509_V_FLAG_PARTIAL_CHAIN flag so that the
> >first certificate found in the trust store becomes the trust-anchor,
> >and chain construction stops there.
> >
> >Another way (in OpenSSL 1.1.0) to get an intermediate certificate
> >to terminate the chain is to decorate it with explicit auxiliary
> >trust EKUs via the "-trustout" and "-addtrust" options of "openssl
> >x509", and then add the decorated certificate to the trust store.
>
> This will cause a lot of grief when both OpenSSL versions
> are used on the same system, (since 1.1.0 is not a drop in
> replacement for OpenSSL 1.0.x), with the same default trust
> store directory.

I am not sure why there would be a lot of grief, by default the
partial chain flag is not set, and intermediate certificates are
not decorated with trust settings, as a result of which the only
user-visible change is that intermediate certificates that come
from the trust store will be checked in the same way as they would
had they arrived from the peer.  This fixes inconsistency of
behaviour.

The behaviour is *only* different if:

  * The trust store actually includes some intermediate certificates.
    Usually it contains just the root CAs.

AND either:

  * The application requests partial chains or the intermediate
    certificates have auxiliary trust EKUs.

    OR

  * Some of the trust-store intermediate CAs are expired or
    invalid.  (Don't do that).

> It would have been much better to use a separate directory
> for untrusted chain-building intermediary certificates, just
> like some other libraries do.

Intermediate certificates in the trust store are effectively
untrusted, unless decorated with auxiliary trust settings.  Only
the "partial chain" flag makes them trusted, applications should
not generally set that flag.

-- 
	Viktor.

From pgnet.dev at gmail.com  Thu Mar 10 23:06:44 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Thu, 10 Mar 2016 15:06:44 -0800
Subject: [openssl-users] openssl 1.0.2g build linking to wrong libs --
 'system' instead of 'own'. How to correct?
In-Reply-To: <CAH8yC8mzGmqdL2WLcnNTJfCyiKxuH+mtwniALhPb4QHLJr7-sQ@mail.gmail.com>
References: <f61d6b8d-da9d-153b-e785-50d21e672e85@gmail.com>
 <CAH8yC8mzGmqdL2WLcnNTJfCyiKxuH+mtwniALhPb4QHLJr7-sQ@mail.gmail.com>
Message-ID: <648f795f-29ae-2e0d-ddfc-0d7461dbdddd@gmail.com>

On 03/10/2016 11:07 AM, Jeffrey Walton wrote:
>> What's the correct config+build procedure for ending up with self-consistent
>> linking?
>
> https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs

Didn't realize that I'd need to rpath a package within its own build. 
Appears libssl & libcrypto are functionally separate builds, and the 
rpath's needed.

Not sure why you wouldn't want the rpath as default, so as to link using 
the libs you "just built".

In any case, works as advertised.

Thanks.

From pgnet.dev at gmail.com  Thu Mar 10 23:20:04 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Thu, 10 Mar 2016 15:20:04 -0800
Subject: [openssl-users] openssl 1.0.2g build fails with 'no-comp' or
 'no-comp no-bio' configure options?
In-Reply-To: <f4a60916-09ad-1953-7ab1-7a782214b039@gmail.com>
References: <87c5aa8c-2877-c643-f85c-015b66af24ce@gmail.com>
 <56E1AFFF.4050801@oracle.com>
 <CAHv26Dj83O9=b_Y5OzuCGv-d0ANL+c5yFRu8R-RMbqDeC+C9UA@mail.gmail.com>
 <f4a60916-09ad-1953-7ab1-7a782214b039@gmail.com>
Message-ID: <61279790-11b4-57b1-c0a5-2b68f1d3f71f@gmail.com>

> My read of
>
>     "no-comp     Disables compression independent of zlib.
> OPENSSL_NO_COMP will be defined in the OpenSSL headers."
>
> is that this disables compression methods OTHER than zlib.
>
> Is the intent, instead, that it disables ALL compression, REGARDLESS of
> the presence/setting of zlib?

This was helpful

  "When do I need zlib in OpenSSL?"
 
http://stackoverflow.com/questions/23772816/when-do-i-need-zlib-in-openssl

'no-comp' disables ALL compression, including any zlib comp; seems 
that's the recommendation there.

I ended up with

   ./config ... no-comp no-zlib no-zlib-dynamic ...

leaving out 'no-bio' until at least v1.1.0 release.

No errors/warnings on the build.  Other than the 'make depend' noise; 
that's another thread.

Thanks.




From jb-openssl at wisemo.com  Thu Mar 10 23:56:04 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 11 Mar 2016 00:56:04 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <20160310224132.GI10917@mournblade.imrryr.org>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com> <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com> <20160310224132.GI10917@mournblade.imrryr.org>
Message-ID: <56E20994.1080000@wisemo.com>

On 10/03/2016 23:41, Viktor Dukhovni wrote:
> On Thu, Mar 10, 2016 at 11:29:12PM +0100, Jakob Bohm wrote:
>
>>> This is changing in OpenSSL 1.1.0, and may yet change in a future
>>> OpenSSL 1.0.2 update.  Only the trust-anchor (top-most certificate
>> >from the trust-store) is not checked for expiration or revocation
>>> in OpenSSL 1.1.0.
>>>
>>> Intermediate certificates are checked, whether they are from the
>>> trust-store, or acquired from the peer.  To get previous behaviour,
>>> one needs to set the X509_V_FLAG_PARTIAL_CHAIN flag so that the
>>> first certificate found in the trust store becomes the trust-anchor,
>>> and chain construction stops there.
>>>
>>> Another way (in OpenSSL 1.1.0) to get an intermediate certificate
>>> to terminate the chain is to decorate it with explicit auxiliary
>>> trust EKUs via the "-trustout" and "-addtrust" options of "openssl
>>> x509", and then add the decorated certificate to the trust store.
>> This will cause a lot of grief when both OpenSSL versions
>> are used on the same system, (since 1.1.0 is not a drop in
>> replacement for OpenSSL 1.0.x), with the same default trust
>> store directory.
Your reply below is a perfect illustration of the expected confusion.

Try repeating it, this time stating /for each point/ if you are
describing 1.0.2 or 1.1.0 behavior, then how those would differ
in the various situations.  It gets really complicated to explain,
especially when not knowing if the application accessing the store
was linked to 1.0.2 or 1.1.0 .
> I am not sure why there would be a lot of grief, by default the
> partial chain flag is not set, and intermediate certificates are
> not decorated with trust settings, as a result of which the only
> user-visible change is that intermediate certificates that come
> from the trust store will be checked in the same way as they would
> had they arrived from the peer.  This fixes inconsistency of
> behaviour.
>
> The behaviour is *only* different if:
>
>    * The trust store actually includes some intermediate certificates.
>      Usually it contains just the root CAs.
>
> AND either:
>
>    * The application requests partial chains or the intermediate
>      certificates have auxiliary trust EKUs.
>
>      OR
>
>    * Some of the trust-store intermediate CAs are expired or
>      invalid.  (Don't do that).
Note that this discussion started with a situation where an
intermediate CA was *revoked* after being placed in the store.
Outside of testing, a trusting party cannot know that in
advance.
>> It would have been much better to use a separate directory
>> for untrusted chain-building intermediary certificates, just
>> like some other libraries do.
> Intermediate certificates in the trust store are effectively
> untrusted, unless decorated with auxiliary trust settings.  Only
> the "partial chain" flag makes them trusted, applications should
> not generally set that flag.
>


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From openssl-users at dukhovni.org  Fri Mar 11 00:18:27 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 11 Mar 2016 00:18:27 +0000
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <56E20994.1080000@wisemo.com>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com>
 <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com>
 <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com>
Message-ID: <20160311001827.GK10917@mournblade.imrryr.org>

On Fri, Mar 11, 2016 at 12:56:04AM +0100, Jakob Bohm wrote:

> Your reply below is a perfect illustration of the expected confusion.

Sorry, I disagree.  The 1.1.0 changes fix various shortcomings that
may well also be addressed in a future 1.0.2 update.

The net effect is more consistent behaviour that is the same whether
intermediate certificates are found in the trust-store or obtained
from the peer.  The few applications that enable partial chain
support and the likely zero users who've created "decorated"
intermediate certs in the OpenSSL trust store might notice some
change.

If you strongly feel that the behaviour should be the same for all
users, that sounds like support for backporting the changes, which
is something I will be proposing soon.

-- 
	Viktor.

From jb-openssl at wisemo.com  Fri Mar 11 00:51:32 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 11 Mar 2016 01:51:32 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <20160311001827.GK10917@mournblade.imrryr.org>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com> <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com> <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com> <20160311001827.GK10917@mournblade.imrryr.org>
Message-ID: <56E21694.10202@wisemo.com>

On 11/03/2016 01:18, Viktor Dukhovni wrote:
> On Fri, Mar 11, 2016 at 12:56:04AM +0100, Jakob Bohm wrote:
>
>> Your reply below is a perfect illustration of the expected confusion.
> Sorry, I disagree.  The 1.1.0 changes fix various shortcomings that
> may well also be addressed in a future 1.0.2 update.
>
> The net effect is more consistent behaviour that is the same whether
> intermediate certificates are found in the trust-store or obtained
> from the peer.  The few applications that enable partial chain
> support and the likely zero users who've created "decorated"
> intermediate certs in the OpenSSL trust store might notice some
> change.
>
> If you strongly feel that the behaviour should be the same for all
> users, that sounds like support for backporting the changes, which
> is something I will be proposing soon.
>
You misunderstand completely.

I am arguing that:

  - 1.0.x behavior should not be changed, as it would violate the
   principle of least surprise for a "security update" to change
   semantics.

  - 1.1.0 behavior is better, if it was the only OpenSSL version
   ever to exist, but it isn't.

  - Therefore the 1.1.0 behavior should use the CA directory shared
   with 1.0.x in a way consistent with how 1.0.x uses that directory
   (as a repository for trust anchors only, as far as I understand
   your non-replies), while 1.1.0 should store untrusted intermediary
   certificates in a different directory where they don't affect
   1.0.x instances running on the same machine.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160311/314594fc/attachment-0001.html>

From openssl-users at dukhovni.org  Fri Mar 11 01:23:25 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 11 Mar 2016 01:23:25 +0000
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <56E21694.10202@wisemo.com>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com>
 <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com>
 <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com>
 <20160311001827.GK10917@mournblade.imrryr.org>
 <56E21694.10202@wisemo.com>
Message-ID: <20160311012325.GL10917@mournblade.imrryr.org>

On Fri, Mar 11, 2016 at 01:51:32AM +0100, Jakob Bohm wrote:

> I am arguing that:
> 
>  - 1.0.x behavior should not be changed, as it would violate the
>   principle of least surprise for a "security update" to change
>   semantics.

The odd 1.0.x behaviour leads to periodic email to openssl-security,
in which it is typically suggested that the 1.0.x behaviour violates
user expectations.  Changing the 1.0.x behaviour addresses some
corner-case behaviour, and would not be inappropriate for a future
1.0.2 release.  Keep in mind that 1.0.2 (unlike 1.0.1) gets bug
fixes not just security fixes.  I have no plans to backport the
changes to 1.0.1 (EOL this December, security fixes only).

>  - Therefore the 1.1.0 behavior should use the CA directory shared
>   with 1.0.x in a way consistent with how 1.0.x uses that directory
>   (as a repository for trust anchors only, as far as I understand
>   your non-replies), while 1.1.0 should store untrusted intermediary
>   certificates in a different directory where they don't affect
>   1.0.x instances running on the same machine.

Well, no, 1.0.2 uses the trust store not only for trust-anchors,
but also as a capricious source of intermediate certificates, whose
behaviour varies depending on whether the peer supplied same said
certificates on the wire or not.  I expect to improve the capricious
behaviour.

 * The treatment of untrusted intermediates (not decorated with
   explicit auxiliary EKUs) will be same regardless of origin.

 * CRL checks, expiration checks, and EKU restrictions will apply
   to all chain elements below the trust anchor (principle of least
   surprise) regardless of origin (wire or trust store).  This
   avoids violating the principle of least surprise.

 * Partial chains (when enabled) will not extend beyond "intermediate"
   CAs that have been "decorated" with auxiliary EKUs.

Yes, there is not in either 1.1.0 or 1.0.x a separate store of
intermediate certificates, that is just a local cache of certificates
erroneously left out of the peer's chain.

Such a thing could be added to whatever release follows 1.1.0 if
there is sufficient demand or someone donates an implementation
that looks like a sufficiently compelling and well documented
feature.

My instinct is that giving administrators a new intermediate-CAfile
and intermediate-CApath to manage (to keep mostly empty) would not
prove especially popular.  Placing undecorated intermediate certs
in the trust store is much simpler.

-- 
	Viktor.

From jb-openssl at wisemo.com  Fri Mar 11 01:44:59 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 11 Mar 2016 02:44:59 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <20160311012325.GL10917@mournblade.imrryr.org>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com> <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com> <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com> <20160311001827.GK10917@mournblade.imrryr.org>
 <56E21694.10202@wisemo.com> <20160311012325.GL10917@mournblade.imrryr.org>
Message-ID: <56E2231B.7080103@wisemo.com>

On 11/03/2016 02:23, Viktor Dukhovni wrote:
> On Fri, Mar 11, 2016 at 01:51:32AM +0100, Jakob Bohm wrote:
>
>> I am arguing that:
>>
>>   - 1.0.x behavior should not be changed, as it would violate the
>>    principle of least surprise for a "security update" to change
>>    semantics.
> The odd 1.0.x behaviour leads to periodic email to openssl-security,
> in which it is typically suggested that the 1.0.x behaviour violates
> user expectations.  Changing the 1.0.x behaviour addresses some
> corner-case behaviour, and would not be inappropriate for a future
> 1.0.2 release.  Keep in mind that 1.0.2 (unlike 1.0.1) gets bug
> fixes not just security fixes.  I have no plans to backport the
> changes to 1.0.1 (EOL this December, security fixes only).
>
>>   - Therefore the 1.1.0 behavior should use the CA directory shared
>>    with 1.0.x in a way consistent with how 1.0.x uses that directory
>>    (as a repository for trust anchors only, as far as I understand
>>    your non-replies), while 1.1.0 should store untrusted intermediary
>>    certificates in a different directory where they don't affect
>>    1.0.x instances running on the same machine.
> Well, no, 1.0.2 uses the trust store not only for trust-anchors,
> but also as a capricious source of intermediate certificates, whose
> behaviour varies depending on whether the peer supplied same said
> certificates on the wire or not.  I expect to improve the capricious
> behaviour.
You keep dodging the question: Does 1.0.2g trust or not
trust intermediary certs found in the "CA" store?
>
>   * The treatment of untrusted intermediates (not decorated with
>     explicit auxiliary EKUs) will be same regardless of origin.
>
>   * CRL checks, expiration checks, and EKU restrictions will apply
>     to all chain elements below the trust anchor (principle of least
>     surprise) regardless of origin (wire or trust store).  This
>     avoids violating the principle of least surprise.
And just to beat a dead horse again: Why skip those
checks for the trust anchor too?  A trust anchor can
expire, be revoked or have insufficient EKUs just like
any other cert.
>
>   * Partial chains (when enabled) will not extend beyond "intermediate"
>     CAs that have been "decorated" with auxiliary EKUs.
>
> Yes, there is not in either 1.1.0 or 1.0.x a separate store of
> intermediate certificates, that is just a local cache of certificates
> erroneously left out of the peer's chain.
Point is that if 1.1.0 introduces code that can load a
certificate from the trust store without trusting it,
then that new code should not be reusing a store which
other software treats as a store of trust anchors.
>
> Such a thing could be added to whatever release follows 1.1.0 if
> there is sufficient demand or someone donates an implementation
> that looks like a sufficiently compelling and well documented
> feature.
>
> My instinct is that giving administrators a new intermediate-CAfile
> and intermediate-CApath to manage (to keep mostly empty) would not
> prove especially popular.  Placing undecorated intermediate certs
> in the trust store is much simpler.
An intermediate-CApath store would typically act as a
growing cache of encountered intermediaries, needing a
lot less security considerations than a trusted-CApath.

This is especially useful with protocols and protocol
variants where the convention is to not send the full
certificate chain at all, but rather to expect the
opposing end to request (and cache) any missing
intermediaries as necessary.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160311/ddf49782/attachment.html>

From openssl-users at dukhovni.org  Fri Mar 11 02:27:57 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 11 Mar 2016 02:27:57 +0000
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <56E2231B.7080103@wisemo.com>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com>
 <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com>
 <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com>
 <20160311001827.GK10917@mournblade.imrryr.org>
 <56E21694.10202@wisemo.com>
 <20160311012325.GL10917@mournblade.imrryr.org>
 <56E2231B.7080103@wisemo.com>
Message-ID: <20160311022757.GM10917@mournblade.imrryr.org>

On Fri, Mar 11, 2016 at 02:44:59AM +0100, Jakob Bohm wrote:

> >Well, no, 1.0.2 uses the trust store not only for trust-anchors,
> >but also as a capricious source of intermediate certificates, whose
> >behaviour varies depending on whether the peer supplied same said
> >certificates on the wire or not.  I expect to improve the capricious
> >behaviour.
>
> You keep dodging the question: Does 1.0.2g trust or not
> trust intermediary certs found in the "CA" store?

They are not trust-anchors, so absent an issuer higher up, they
are not sufficient to establish a "chain of trust", unless the
application enables "partial chain" support.

However, in 1.0.x (more bug than feature) basic constraints, key
usage constraints and EKU constraints, which are applied to
intermediate certificates provided by the peer, are not applied
when the intermediate certificates happen to originate from the
trust store.

As for CRL checks, these apply to either just the leaf certificate
(flags & X509_V_FLAG_CRL_CHECK) or all certificates in the chain
(flags & X509_V_FLAG_CRL_CHECK_ALL).   Perhaps the OP's application
is only setting the first flag and not the second.

> >  * CRL checks, expiration checks, and EKU restrictions will apply
> >    to all chain elements below the trust anchor (principle of least
> >    surprise) regardless of origin (wire or trust store).  This
> >    avoids violating the principle of least surprise.

Sorry, I was wrong about CRL checks, these do not depend on CA
provenance.

> And just to beat a dead horse again: Why skip those
> checks for the trust anchor too?  A trust anchor can
> expire, be revoked or have insufficient EKUs just like
> any other cert.

When the trust-anchor is not self-signed, it is not possible to
check its revocation, because the issue is missing.  The expiration
dates and self-signatures of trust-anchors are not checked by
yedefault.  I've not checked whether a trust-anchor can revoke
itself via a CRL, I'm not proposing changing CRL processing, just
chain construction (trusted-first by default) an extension processing
(EKUs, basic constraints, ...).

> >Yes, there is not in either 1.1.0 or 1.0.x a separate store of
> >intermediate certificates, that is just a local cache of certificates
> >erroneously left out of the peer's chain.
>
> Point is that if 1.1.0 introduces code that can load a
> certificate from the trust store without trusting it,
> then that new code should not be reusing a store which
> other software treats as a store of trust anchors.

That code has existed well before 1.0.x, and continues to be present
in 1.0.x, the difference from 1.1.0 is that in 1.0.x, such certs
are subjected to less validation than they deserve.  The proposed
changes are to apply all the expected checks.

> >My instinct is that giving administrators a new intermediate-CAfile
> >and intermediate-CApath to manage (to keep mostly empty) would not
> >prove especially popular.  Placing undecorated intermediate certs
> >in the trust store is much simpler.
>
> An intermediate-CApath store would typically act as a
> growing cache of encountered intermediaries, needing a
> lot less security considerations than a trusted-CApath.
> 
> This is especially useful with protocols and protocol
> variants where the convention is to not send the full
> certificate chain at all, but rather to expect the
> opposing end to request (and cache) any missing
> intermediaries as necessary.

Fine for browsers, not so practical for OpenSSL which does not go
around downloading certificates on the fly.

Anyway, I think we're no longer making anything more clear, so
we should stop.

-- 
	Viktor.

From noloader at gmail.com  Fri Mar 11 04:14:12 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 10 Mar 2016 23:14:12 -0500
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <20160311022757.GM10917@mournblade.imrryr.org>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com>
 <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com>
 <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com>
 <20160311001827.GK10917@mournblade.imrryr.org>
 <56E21694.10202@wisemo.com>
 <20160311012325.GL10917@mournblade.imrryr.org>
 <56E2231B.7080103@wisemo.com>
 <20160311022757.GM10917@mournblade.imrryr.org>
Message-ID: <CAH8yC8kknTaTUDDe2vUnLjNYgN5XM3NoGpNXGVbVhA7LoVFePA@mail.gmail.com>

>> >Well, no, 1.0.2 uses the trust store not only for trust-anchors,
>> >but also as a capricious source of intermediate certificates, whose
>> >behaviour varies depending on whether the peer supplied same said
>> >certificates on the wire or not.  I expect to improve the capricious
>> >behaviour.
>> ...
>
> They are not trust-anchors, so absent an issuer higher up, they
> are not sufficient to establish a "chain of trust", unless the
> application enables "partial chain" support.
>
> However, in 1.0.x (more bug than feature) basic constraints, key
> usage constraints and EKU constraints, which are applied to
> intermediate certificates provided by the peer, are not applied
> when the intermediate certificates happen to originate from the
> trust store.

This seems like its a tricky area... The IETF and CA/B have different
issuing and usage policies, and there's no way to determine under what
policy a certificate was issued. You can kind of find CA/B sometimes
if they have one of those Extended Validation certificates based on
the cornucopia of OIDs. But IETF is Persian Bazaar because they lack a
way to denote policy.

If its a certificate issued under the IETF, then key usage expands
with the EKU of an intermediate. Under the CA/B, the EKU of an
intermediate contracts or constrains key usage.

Jeff

From openssl-users at dukhovni.org  Fri Mar 11 04:45:00 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 11 Mar 2016 04:45:00 +0000
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <CAH8yC8kknTaTUDDe2vUnLjNYgN5XM3NoGpNXGVbVhA7LoVFePA@mail.gmail.com>
References: <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com>
 <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com>
 <20160311001827.GK10917@mournblade.imrryr.org>
 <56E21694.10202@wisemo.com>
 <20160311012325.GL10917@mournblade.imrryr.org>
 <56E2231B.7080103@wisemo.com>
 <20160311022757.GM10917@mournblade.imrryr.org>
 <CAH8yC8kknTaTUDDe2vUnLjNYgN5XM3NoGpNXGVbVhA7LoVFePA@mail.gmail.com>
Message-ID: <20160311044500.GN10917@mournblade.imrryr.org>

On Thu, Mar 10, 2016 at 11:14:12PM -0500, Jeffrey Walton wrote:

> > However, in 1.0.x (more bug than feature) basic constraints, key
> > usage constraints and EKU constraints, which are applied to
> > intermediate certificates provided by the peer, are not applied
> > when the intermediate certificates happen to originate from the
> > trust store.
> 
> This seems like its a tricky area...

Note that in 1.1.0 and in the likely backport, the actual policy
mechanisms largely stayed the same.  The real change is removal of
inconsistency in how the mechanisms were applied.

Previously policy on intermediate certificates was inconsistently
applied, now the behaviour is predictable.  Whether found in the
trust store, or on the wire the processing is the same.

Please test the chain validation in 1.1.0, and if you find any
issues, please post here or to openssl-security at openssl.org as
appropriate.

The 1.1.0 code passes internal tests and the NIST PKITS tests.
Contributions of new tests that exercise more corner cases appreciated.
If a clear need for a separate "untrusted" store is identified that
can be added, with the key difficulty being a sane admin interface,
usable API and clear documentation.  The implementation is easy,
most of the code is there already, since untrusted certs are already
processed from the peer chain and any application provided "untrusted
stack", generalizing that stack to a store is easy enough.

-- 
	Viktor.

From jb-openssl at wisemo.com  Fri Mar 11 05:16:45 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 11 Mar 2016 06:16:45 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <20160311022757.GM10917@mournblade.imrryr.org>
References: <a163699916542d002ecbb35d38652601@mail.secure-mail.biz>
 <56E1EA08.1070409@wisemo.com> <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com> <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com> <20160311001827.GK10917@mournblade.imrryr.org>
 <56E21694.10202@wisemo.com> <20160311012325.GL10917@mournblade.imrryr.org>
 <56E2231B.7080103@wisemo.com> <20160311022757.GM10917@mournblade.imrryr.org>
Message-ID: <56E254BD.5040000@wisemo.com>

On 11/03/2016 03:27, Viktor Dukhovni wrote:
> On Fri, Mar 11, 2016 at 02:44:59AM +0100, Jakob Bohm wrote:
>
>>> Well, no, 1.0.2 uses the trust store not only for trust-anchors,
>>> but also as a capricious source of intermediate certificates, whose
>>> behaviour varies depending on whether the peer supplied same said
>>> certificates on the wire or not.  I expect to improve the capricious
>>> behaviour.
>> You keep dodging the question: Does 1.0.2g trust or not
>> trust intermediary certs found in the "CA" store?
> They are not trust-anchors, so absent an issuer higher up, they
> are not sufficient to establish a "chain of trust", unless the
> application enables "partial chain" support.
Ok, that reverses the fundamental assumption behind all my
previous posts (including post #2 in this thread).  Why didn't
you state this earlier.

> ...
>
>
>> An intermediate-CApath store would typically act as a
>> growing cache of encountered intermediaries, needing a
>> lot less security considerations than a trusted-CApath.
>>
>> This is especially useful with protocols and protocol
>> variants where the convention is to not send the full
>> certificate chain at all, but rather to expect the
>> opposing end to request (and cache) any missing
>> intermediaries as necessary.
> Fine for browsers, not so practical for OpenSSL which does not go
> around downloading certificates on the fly.
Actually, I have only seen this done in non-browser
use of TLS (and only by Microsoft).


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160311/e6a40102/attachment.html>

From openssl-users at dukhovni.org  Fri Mar 11 05:54:57 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 11 Mar 2016 05:54:57 +0000
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <56E254BD.5040000@wisemo.com>
References: <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com>
 <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com>
 <20160311001827.GK10917@mournblade.imrryr.org>
 <56E21694.10202@wisemo.com>
 <20160311012325.GL10917@mournblade.imrryr.org>
 <56E2231B.7080103@wisemo.com>
 <20160311022757.GM10917@mournblade.imrryr.org>
 <56E254BD.5040000@wisemo.com>
Message-ID: <20160311055457.GO10917@mournblade.imrryr.org>

On Fri, Mar 11, 2016 at 06:16:45AM +0100, Jakob Bohm wrote:

> >They are not trust-anchors, so absent an issuer higher up, they
> >are not sufficient to establish a "chain of trust", unless the
> >application enables "partial chain" support.
>
> Ok, that reverses the fundamental assumption behind all my
> previous posts (including post #2 in this thread).  Why didn't
> you state this earlier.

I thought I did, but miscommunication by email is all too easy.
Sorry about that.  Intermediate certificates in the trust store
are only fully trusted if either:

    * The application enables partial-chain support, which is
      not advisable in most cases.

    * The intermediate certificate is augmented (decorated)
      with auxiliary trust OIDs that match the required "purpose".

Absent augmentation as a "trusted certificate" for a given purpose,
and with the application not enabling "partial chain" semantics,
intermediate certs from the store just augment missing certificates
from the wire, and should be verified in the same manner.  The
changes I want to backport from 1.1.0 ensure identical treatment
of untrusted intermediates regardless of provenance.

-- 
	Viktor.

From mihertz at gmx.de  Fri Mar 11 09:38:19 2016
From: mihertz at gmx.de (mihertz at gmx.de)
Date: Fri, 11 Mar 2016 10:38:19 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
Message-ID: <56E2920B.5020602@gmx.de>

 >I am testing with revoking certificates.
 >
 >My PKI has a root and 2 intermediates, which then sign server and 
client certificates
 >My test environment consists of a s_client and a s_server referencing 
the corresponding files and a verifydir with c_rehased files.
 >TLS connections work fine from s_client to s_server, chain is exposed 
and recognized properly.
 >
 >I successfully revoked server-certificates with the intermediate ca crl.
 >When trying to connect using the s_client "-crl_check" arg the 
"certificate revoked" notification shows up correctly.
 >
 >I also successfully created a crl with the root ca, that revokes one 
of the intermediates.
 >The serialnumber of the revoked intermediate is shown correctly in the 
crl and the crl is c_rehashed in the verify dir of the client.
 >But no matter what i try, the s_client does NOT show the "certificate 
revoked" when I connect to the corresponding s_server using the 
certificate signed by the revoked intermediate.
 >
 >Any ideas what i could be doing wrong?
 >
 >I am on version OpenSSL 1.0.1f 6 Jan 2014

Thanks for the answers and the time spend.
Sorry, did not mean to trigger a debate of principles :-)

In further tracking down the cause i was trying to use "openssl verify" 
commands.
When I issue the "openssl verify -CApath verifydir -crl_check 
revokedIntermediate.crt" the intermediate cert is correctly shown as 
revoked, so the content of the verifydir is fine I think.

Somehow s_client does not recognize that, when connecting to the 
corresponding s_server.





From openssl-users at dukhovni.org  Fri Mar 11 15:36:38 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 11 Mar 2016 15:36:38 +0000
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <56E2920B.5020602@gmx.de>
References: <56E2920B.5020602@gmx.de>
Message-ID: <20160311153638.GU10917@mournblade.imrryr.org>

On Fri, Mar 11, 2016 at 10:38:19AM +0100, mihertz at gmx.de wrote:

> In further tracking down the cause i was trying to use "openssl verify"
> commands.
> When I issue the "openssl verify -CApath verifydir -crl_check
> revokedIntermediate.crt" the intermediate cert is correctly shown as
> revoked, so the content of the verifydir is fine I think.

This is not a check of the intermediate certificate as an actual
intermediate in a chain, this only checks it as a leaf certificate.
Your entire chain is just:

    root ---> revokedIntermediate

> Somehow s_client does not recognize that, when connecting to the
> corresponding s_server.

Try:

    openssl s_client -crl_check_all ...

-- 
	Viktor.

From openssl-users at dukhovni.org  Sat Mar 12 19:20:37 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 12 Mar 2016 19:20:37 +0000
Subject: [openssl-users] Question: Make X509_V_FLAG_TRUSTED_FIRST default in
	1.0.2?
In-Reply-To: <20160311055457.GO10917@mournblade.imrryr.org>
References: <56E1F538.5000400@wisemo.com>
 <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com>
 <20160311001827.GK10917@mournblade.imrryr.org>
 <56E21694.10202@wisemo.com>
 <20160311012325.GL10917@mournblade.imrryr.org>
 <56E2231B.7080103@wisemo.com>
 <20160311022757.GM10917@mournblade.imrryr.org>
 <56E254BD.5040000@wisemo.com>
 <20160311055457.GO10917@mournblade.imrryr.org>
Message-ID: <20160312192037.GH10917@mournblade.imrryr.org>

On Fri, Mar 11, 2016 at 05:54:57AM +0000, Viktor Dukhovni wrote:

> Absent augmentation as a "trusted certificate" for a given purpose,
> and with the application not enabling "partial chain" semantics,
> intermediate certs from the store just augment missing certificates
> from the wire, and should be verified in the same manner.  The
> changes I want to backport from 1.1.0 ensure identical treatment
> of untrusted intermediates regardless of provenance.

I have an important question for the list.  At present the pending
patches to backport from 1.1.0 to 1.0.2 do not change the default
chain construction strategy to X509_V_FLAG_TRUSTED_FIRST

    commit ca9051b136284a96ea6c10ac4efd355cfc4716a0
    Author: Viktor Dukhovni <openssl-users at dukhovni.org>
    Date:   Thu Feb 4 01:04:02 2016 -0500

    Check chain extensions also for trusted certificates

    This includes basic constraints, key usages, issuer EKUs and
    auxiliary trust OIDs (given a trust suitably related to the
    intended purpose).

    Note, for this to work consistently, the X509_V_FLAG_TRUSTED_FIRST
    flag must be set.  This is the default in 1.1.0-dev, but is likely
    too big a change for the 1.0.2 stable release.

    (Backport from 1.1.0-dev)

What this means is that treatment of auxiliary trust "decorations"
for intermediate CAs is not predictable unless that flag is explicitly
set by the application.  IIRC some people have been asking for this
flag to become the default (or at least requested its creation).

So I'd like to hear whether the above mentioned (pending) commit
is the right judgement call, or whether I should go ahead and update
X509_V_FLAG_TRUSTED_FIRST to be the default also in the next 1.0.2
release.

-- 
	Viktor.

From uri at ll.mit.edu  Sun Mar 13 01:22:13 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Sun, 13 Mar 2016 01:22:13 +0000
Subject: [openssl-users] [openssl-dev] Question: Make
 X509_V_FLAG_TRUSTED_FIRST default in	1.0.2?
Message-ID: <20160313012221.18296912.29254.57221@ll.mit.edu>

I may later regret saying this, but I think back-porting that change from 1.1.0 to 1.0.2 would be the right thing to do.

Maybe after back-porting we could ?give a "waiting period" to let users collect experience with it, and either leave it in, or if the complaints are too multiple and too bitter - remove it?

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Viktor Dukhovni
Sent: Saturday, March 12, 2016 14:21
To: openssl-users at openssl.org
Reply To: openssl-users at openssl.org
Cc: openssl-dev at openssl.org
Subject: [openssl-dev] Question: Make X509_V_FLAG_TRUSTED_FIRST default in	1.0.2?

On Fri, Mar 11, 2016 at 05:54:57AM +0000, Viktor Dukhovni wrote:

> Absent augmentation as a "trusted certificate" for a given purpose,
> and with the application not enabling "partial chain" semantics,
> intermediate certs from the store just augment missing certificates
> from the wire, and should be verified in the same manner. The
> changes I want to backport from 1.1.0 ensure identical treatment
> of untrusted intermediates regardless of provenance.

I have an important question for the list. At present the pending
patches to backport from 1.1.0 to 1.0.2 do not change the default
chain construction strategy to X509_V_FLAG_TRUSTED_FIRST

commit ca9051b136284a96ea6c10ac4efd355cfc4716a0
Author: Viktor Dukhovni <openssl-users at dukhovni.org>
Date: Thu Feb 4 01:04:02 2016 -0500

Check chain extensions also for trusted certificates

This includes basic constraints, key usages, issuer EKUs and
auxiliary trust OIDs (given a trust suitably related to the
intended purpose).

Note, for this to work consistently, the X509_V_FLAG_TRUSTED_FIRST
flag must be set. This is the default in 1.1.0-dev, but is likely
too big a change for the 1.0.2 stable release.

(Backport from 1.1.0-dev)

What this means is that treatment of auxiliary trust "decorations"
for intermediate CAs is not predictable unless that flag is explicitly
set by the application. IIRC some people have been asking for this
flag to become the default (or at least requested its creation).

So I'd like to hear whether the above mentioned (pending) commit
is the right judgement call, or whether I should go ahead and update
X509_V_FLAG_TRUSTED_FIRST to be the default also in the next 1.0.2
release.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160313/687c79b4/attachment-0001.bin>

From angel at tls.16bits.net  Sun Mar 13 23:14:39 2016
From: angel at tls.16bits.net (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Mon, 14 Mar 2016 00:14:39 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <20160311044500.GN10917@mournblade.imrryr.org>
References: <20160310220622.GH10917@mournblade.imrryr.org>
 <56E1F538.5000400@wisemo.com>
 <20160310224132.GI10917@mournblade.imrryr.org>
 <56E20994.1080000@wisemo.com>
 <20160311001827.GK10917@mournblade.imrryr.org> <56E21694.10202@wisemo.com>
 <20160311012325.GL10917@mournblade.imrryr.org>
 <56E2231B.7080103@wisemo.com>
 <20160311022757.GM10917@mournblade.imrryr.org>
 <CAH8yC8kknTaTUDDe2vUnLjNYgN5XM3NoGpNXGVbVhA7LoVFePA@mail.gmail.com>
 <20160311044500.GN10917@mournblade.imrryr.org>
Message-ID: <1457910879.8392.7.camel@tls.16bits.net>

I am a bit wary that someone started adding certificates to the trust
store based on this new behavior not realizing that some is using it
with a different semantic. Maybe a note ("other software may not do the
same") would be appropiate.

I can't find the entry for this in CHANGES, though.



PS:?sed -i 's/reported to OpenSSL Guido/reported to OpenSSL by Guido/;s/Langley(/Langley (/' CHANGES

From mihertz at gmx.de  Mon Mar 14 06:47:46 2016
From: mihertz at gmx.de (Michael)
Date: Mon, 14 Mar 2016 07:47:46 +0100
Subject: [openssl-users] problems with s_client recognizing revoked
 intermediate/subordinate ca
In-Reply-To: <20160311153638.GU10917@mournblade.imrryr.org>
References: <56E2920B.5020602@gmx.de>
 <20160311153638.GU10917@mournblade.imrryr.org>
Message-ID: <56E65E92.2050601@gmx.de>

> This is not a check of the intermediate certificate as an actual
> intermediate in a chain, this only checks it as a leaf certificate.
> Your entire chain is just:

>    root ---> revokedIntermediate

Yes - as a leaf of root, using the roots crl to see if any root-signed certs are revoked.

> Try:
>    openssl s_client -crl_check_all ...

Works! Great, thanks for the hint Viktor.
Just recognized, that the manpage lists the "crl_check_all" options right after the "crl_check", which i used... >_<

Using the crl_check_all it also complains about a missing crl now, when I remove the root's crl from the store.
This wasnt the case when using crl_check, which also wondered me a bit before.
Not it all makes sense :-)

Thanks again!



From lists at rustichelli.net  Mon Mar 14 15:24:10 2016
From: lists at rustichelli.net (lists)
Date: Mon, 14 Mar 2016 16:24:10 +0100
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
Message-ID: <56E6D79A.6070109@rustichelli.net>

On 03/10/2016 03:52 PM, PGNet Dev wrote:
> I'm building openssl 1.0.2g on linux64.
>
> After
>
>     ./configure ...
>

Did you mean "./config ..."?

> I'm prompted
>
>     Since you've disabled or enabled at least one algorithm, you need 
> to do
>     the following before building:
>
>         make depend
>
> Exec'ing the 'make depend' stage returns lots of warnings,
>
>     make depend
>         making depend in crypto...
>         make[1]: Entering directory 
> '/usr/local/src/openssl/openssl-1.0.2g/crypto'
>         makedepend: warning:  cryptlib.c (reading 
> /usr/include/stdlib.h, line 32): cannot find include file "stddef.h"
>                 not in ./stddef.h
>   [...]
>
> On the distro, stddef.h is available at
>
>     /usr/include/linux/stddef.h
>     /usr/lib64/gcc/x86_64-suse-linux/4.8/include/stddef.h
>     /usr/lib64/gcc/x86_64-suse-linux/5/include/stddef.h
>
>
> Reading wiki & reports at openssl, there's confusing, if not 
> conflicting, advice.
>
> Must use it,
>
>     (1) https://wiki.openssl.org/index.php/Compilation_and_Installation
>         Dependencies
>
>         If you are prompted to run make depend, then you must do so. 
> Its not just for developers who are updating sources. Its required to 
> update the standard distribution once configuration options change.
>

In your specific case, it seems that you have disabled a protocol or 
cipher or whatever, in other words you have changed the default options.
I guess the "..." in your command means just that you are omitting some 
options.
So in such case you need "make depend". What is said in point (1) is 
correct.
For instance, if you compile some not-latest OpenSSL with -nossl2 (this 
is the current hype), compilation will fail unless you issue "make depend".
Sorry but I don't exactly understand how you are quoting the rest, so I 
cannot see exactly what is that you find confusing.

> Don't need it
>
>     (2) https://wiki.openssl.org/index.php/Compilation_and_Installation
>         Compilation
>             After configuring the library, you should run make. If 
> prompted, there's usually no need to make depend since you are 
> building from a clean download.
>
>     (3) 
> https://rt.openssl.org/Ticket/Display.html?id=3566&user=guest&pass=guest
>             "Obviously this needs fixing but as a workaround: if 
> you're building from scratch (or after "make clean") it should compile 
> fine with without doing "make depend".
>
>
>
> Re: 'makedepend',
>
>     https://en.wikipedia.org/wiki/Makedepend
>         makedepend was developed as part of MIT's Project Athena. It 
> was used extensively in building X11 and ancillary packages, but has 
> since become superseded by the dependency generation facilities of 
> various compilers, and is now used primarily as a worst-case fallback, 
> e.g. by depcomp and GNU Automake.
>
> Further, a quick check (https://www.google.com/search?q=makedepend+stddef
> ) shows that there's a long history (unresolved?) re: not finding the 
> sys's stddef.h
>
> Digging around some more, I find that virtually the same issue was 
> raised on openssl-dev in Apr 2015,
>
>     https://mta.openssl.org/pipermail/openssl-dev/2015-April/001263.html
>     [openssl-dev] `make depend`, advised by ./config, fails to find 
> stddef.h in system/compiler path. old bug (#3566) says don't bother 
> with `make depend`? true, or another bug?
>
> with no reply at all.
>
> What, then, IS the current need for 'makedepend' in openssl, and what, 
> exactly, is the correct/recommended usage for its use in an openssl 
> build?





From pgnet.dev at gmail.com  Mon Mar 14 15:26:17 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Mon, 14 Mar 2016 08:26:17 -0700
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <56E6D79A.6070109@rustichelli.net>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
 <56E6D79A.6070109@rustichelli.net>
Message-ID: <7815d0d4-15f9-963e-ffd9-c0b065d412f4@gmail.com>

On 03/14/2016 08:24 AM, lists wrote:
> Did you mean "./config ..."?

yep.

>> Must use it,
>>
>>     (1) https://wiki.openssl.org/index.php/Compilation_and_Installation
>>         Dependencies
>>
>>         If you are prompted to run make depend, then you must do so.

Which I currently attempt to do, but get the reported errors about not 
finding the stddef.h include etc.

> I cannot see exactly what is that you find confusing.

That the wiki says you don't need to,

"Compilation

  After configuring the library, you should run make. If prompted, 
there's usually no need to make depend since you are building from a 
clean download."
 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


From pgnet.dev at gmail.com  Mon Mar 14 15:58:33 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Mon, 14 Mar 2016 08:58:33 -0700
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <7815d0d4-15f9-963e-ffd9-c0b065d412f4@gmail.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
 <56E6D79A.6070109@rustichelli.net>
 <7815d0d4-15f9-963e-ffd9-c0b065d412f4@gmail.com>
Message-ID: <b93f92f0-6e57-08d6-4319-78c44f582ab2@gmail.com>

On 03/14/2016 08:26 AM, PGNet Dev wrote:
> Which I currently attempt to do, but get the reported errors about not finding the stddef.h include etc.

Specifically,

cd test
rm -rf *
wget https://www.openssl.org/source/openssl-1.0.2g.tar.gz
tar zxvf openssl-1.0.2g.tar.gz
cd openssl-1.0.2g

./config --openssldir=/home/work/sslTEST --libdir=lib64 \
  threads shared -D_GNU_SOURCE -DPURIFY -DTERMIO -fno-common 
-Wl,-rpath=/home/work/sslTEST/lib64 -Wa,--noexecstack 
-Wl,-z,relro,-z,now -Wall

	...
	Configured for linux-x86_64.

	*** Because of configuration changes, you MUST do the following before
	*** building:

	        make depend

make depend
	making depend in crypto...
	make[1]: Entering directory 
'/home/work/openssl-1.0.2g/test/openssl-1.0.2g/crypto'
	makedepend: warning:  cryptlib.c (reading /usr/include/stdlib.h, line 
32): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  cryptlib.c (reading /usr/include/sys/types.h, 
line 146): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/alloca.h, line 
24): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/string.h, line 
32): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/unistd.h, line 
226): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/stdio.h, line 
33): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/_G_config.h, 
line 15): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/wchar.h, line 
51): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading /usr/include/libio.h, line 
49): cannot find include file "stdarg.h"
	        not in ./stdarg.h
	        not in ../stdarg.h
	        not in ../include/stdarg.h
	        not in /usr/include/stdarg.h
	makedepend: warning:  cryptlib.c (reading ../include/openssl/buffer.h, 
line 68): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  cryptlib.c (reading ../include/openssl/bio.h, 
line 67): cannot find include file "stdarg.h"
	        not in ./stdarg.h
	        not in ../stdarg.h
	        not in ../include/stdarg.h
	        not in /usr/include/stdarg.h
	makedepend: warning:  o_str.c (reading o_str.h, line 63): cannot find 
include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_str.c (reading /usr/include/strings.h, line 
28): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_dir.c (reading LPdir_unix.c, line 31): cannot 
find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_dir.c (reading /usr/include/limits.h, line 
123): cannot find include file "limits.h"
	makedepend: warning:  /usr/include/dirent.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/features.h
	        /usr/include/bits/types.h
	        /usr/include/bits/dirent.h
	makedepend: warning:  o_dir.c (reading /usr/include/dirent.h, line 
244): cannot find include file "stddef.h"
	        not in ./stddef.h
	        not in ../stddef.h
	        not in ../include/stddef.h
	        not in /usr/include/stddef.h
	making depend in crypto/objects...
	make[2]: Entering directory 
'/home/work/openssl-1.0.2g/test/openssl-1.0.2g/crypto/objects'
	../../util/domd ../.. -MD makedepend -- -fPIC -DOPENSSL_PIC 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_GNU_SOURCE 
-DPURIFY -DTERMIO -fno-common -Wa,--noexecstack -Wall -Wa,--noexecstack 
-m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -I.. -I../.. -I../modes -I../asn1 
-I../evp -I../../include  -DOPENSSL_NO_DEPRECATED 
-DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE 
-DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -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 --  o_names.c obj_dat.c obj_lib.c 
obj_err.c obj_xref.c
	makedepend: warning:  o_names.c (reading /usr/include/stdio.h, line 
33): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_names.c (reading /usr/include/_G_config.h, line 
15): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_names.c (reading /usr/include/wchar.h, line 
51): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_names.c (reading /usr/include/libio.h, line 
49): cannot find include file "stdarg.h"
	        not in ../stdarg.h
	        not in ../../stdarg.h
	        not in ../modes/stdarg.h
	        not in ../asn1/stdarg.h
	        not in ../evp/stdarg.h
	        not in ../../include/stdarg.h
	        not in /usr/include/stdarg.h
	makedepend: warning:  o_names.c (reading /usr/include/stdlib.h, line 
32): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  o_names.c (reading /usr/include/sys/types.h, line 
146): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_names.c (reading /usr/include/alloca.h, line 
24): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_names.c (reading /usr/include/string.h, line 
32): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  o_names.c (reading ../../include/openssl/bio.h, 
line 67): cannot find include file "stdarg.h"
	        not in ../stdarg.h
	        not in ../../stdarg.h
	        not in ../modes/stdarg.h
	        not in ../asn1/stdarg.h
	        not in ../evp/stdarg.h
	        not in ../../include/stdarg.h
	        not in /usr/include/stdarg.h
	makedepend: warning:  obj_dat.c (reading /usr/include/limits.h, line 
123): cannot find include file "limits.h"
	makedepend: warning:  obj_dat.c (reading /usr/include/unistd.h, line 
226): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  obj_dat.c (reading 
../../include/openssl/buffer.h, line 68): cannot find include file 
"stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	make[2]: Leaving directory 
'/home/work/openssl-1.0.2g/test/openssl-1.0.2g/crypto/objects'
	making depend in crypto/md4...
	make[2]: Entering directory 
'/home/work/openssl-1.0.2g/test/openssl-1.0.2g/crypto/md4'
	../../util/domd ../.. -MD makedepend -- -fPIC -DOPENSSL_PIC 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_GNU_SOURCE 
-DPURIFY -DTERMIO -fno-common -Wa,--noexecstack -Wall -Wa,--noexecstack 
-m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM 
-DGHASH_ASM -DECP_NISTZ256_ASM -I.. -I../.. -I../modes -I../asn1 
-I../evp -I../../include  -DOPENSSL_NO_DEPRECATED 
-DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE 
-DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -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 --  md4_dgst.c md4_one.c
	makedepend: warning:  md4_dgst.c (reading /usr/include/stdio.h, line 
33): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  md4_dgst.c (reading /usr/include/_G_config.h, 
line 15): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  md4_dgst.c (reading /usr/include/wchar.h, line 
51): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  md4_dgst.c (reading /usr/include/libio.h, line 
49): cannot find include file "stdarg.h"
	        not in ../stdarg.h
	        not in ../../stdarg.h
	        not in ../modes/stdarg.h
	        not in ../asn1/stdarg.h
	        not in ../evp/stdarg.h
	        not in ../../include/stdarg.h
	        not in /usr/include/stdarg.h
	makedepend: warning:  md4_dgst.c (reading /usr/include/stdlib.h, line 
32): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  /usr/include/time.h includes 
/usr/include/bits/types.h more than once!
	Already have
	        /usr/include/bits/types.h
	makedepend: warning:  md4_dgst.c (reading /usr/include/sys/types.h, 
line 146): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  md4_dgst.c (reading /usr/include/alloca.h, line 
24): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  md4_dgst.c (reading /usr/include/string.h, line 
32): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	makedepend: warning:  md4_dgst.c (reading ../../include/openssl/md4.h, 
line 63): cannot find include file "stddef.h"
	        not in ../stddef.h
	        not in ../../stddef.h
	        not in ../modes/stddef.h
	        not in ../asn1/stddef.h
	        not in ../evp/stddef.h
	        not in ../../include/stddef.h
	        not in /usr/include/stddef.h
	make[2]: Leaving directory 
'/home/work/openssl-1.0.2g/test/openssl-1.0.2g/crypto/md4'
	making depend in crypto/md5...
	make[2]: Entering directory 
'/home/work/openssl-1.0.2g/test/openssl-1.0.2g/crypto/md5'
	...



From pgnet.dev at gmail.com  Mon Mar 14 16:44:48 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Mon, 14 Mar 2016 09:44:48 -0700
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <b93f92f0-6e57-08d6-4319-78c44f582ab2@gmail.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
 <56E6D79A.6070109@rustichelli.net>
 <7815d0d4-15f9-963e-ffd9-c0b065d412f4@gmail.com>
 <b93f92f0-6e57-08d6-4319-78c44f582ab2@gmail.com>
Message-ID: <f80b5d5b-501f-2f86-9f93-b23f3bf562a7@gmail.com>

On 03/14/2016 08:58 AM, PGNet Dev wrote:
> On 03/14/2016 08:26 AM, PGNet Dev wrote:
>> Which I currently attempt to do, but get the reported errors about not
>> finding the stddef.h include etc.

Here,

   https://rt.openssl.org/Ticket/Display.html?id=4169&user=guest&pass=guest

it simply says

   "fixed in 1.1"

There's no indication what the fix is -- use make depend, or don't use it?

And, no idea how we're _supposed_ to get to a successful/reliable build 
in 1.0.2x series.

From jetson23 at hotmail.com  Mon Mar 14 17:32:36 2016
From: jetson23 at hotmail.com (Jason Schultz)
Date: Mon, 14 Mar 2016 17:32:36 +0000
Subject: [openssl-users] Build of 1.0.1g fails
Message-ID: <BLUPR10MB0724AB926CD3BDE77657D380C7880@BLUPR10MB0724.namprd10.prod.outlook.com>

Greetings. I'm having problems building OpenSSL, starting with 1.0.1g. The scenario is as follows.

I'm not sure when the problem was introduced; however, with the compiling-out of SSLv2 *by default* in -1.0.2g, that change has exacerbated this problem.  (That is, instead of affecting only those who selected "no-ssl2", it now affects everyone *except* those that explicitly select "ssl2".)

First, the existing package runs a self-test during the package build process.  One of those tests verifies SSL (ssl/ssltest.c), and another verifies SSL usage when FIPS is active (test/testfipsssl).  The code in ssl/ssltest.c has a section that detects if the requested encryption mechanism has been disabled at build time ("compiled out").  If this situation is detected, an "OK" status is returned so that the test driver can determine what to do.  When FIPS is compiled, configured, and enabled, calling the SSL verification from test/testfipsssl to verify SSLv2 or SSLv3 support should result in a "Fail" status since neither SSLv2 nor SSLv3 is supported with FIPS.  However, when the "no-sslv2" and/or "no-sslv3" build options are selected, neither mechanism gets compiled in, so the SSL verification test detects this and immediately returns "OK" status.  Since FIPS is compiled, configured, and enabled, a "Fail" status is expected by test/testfipsssl instead, so the "OK" status that is received because the ciphers are not present is handled as a test failure thereby aborting the build.

To make the package build correctly with "no-sslv2" or "no-sslv3" specified, I had to add the following:

Index: ssl/ssltest.c
===================================================================
--- ssl/ssltest.c (revision 4068)
+++ ssl/ssltest.c (working copy)
@@ -1203,8 +1203,20 @@
     if (no_protocol) {
         fprintf(stderr, "Testing was requested for a disabled protocol. "
                 "Skipping tests.\n");
+#ifdef OPENSSL_FIPS
+        /*
+         * If FIPS is enabled, then neither SSLv2 nor SSLv3 are permitted anyway.
+         * In this case, the fact that one or both are compiled-out is a good thing,
+         * so we continue onward to return the expected error status instead.
+         */
+        if (!fips_mode || !FIPS_mode_set(1) || !(ssl2 || ssl3)) {
+            ret = 0;
+            goto end;
+        }
+#else
         ret = 0;
         goto end;
+#endif
     }

     if (!ssl2 && !ssl3 && !tls1 && !dtls1 && !dtls12 && number > 1 && !reuse && !force) {

Is this a known problem? Is there a solution available?

Thanks in advance.


From jetson23 at hotmail.com  Mon Mar 14 17:42:39 2016
From: jetson23 at hotmail.com (Jason Schultz)
Date: Mon, 14 Mar 2016 17:42:39 +0000
Subject: [openssl-users] Building 1.0.1g with "no-idea"
Message-ID: <BLUPR10MB072430426CEDB81059F9CE53C7880@BLUPR10MB0724.namprd10.prod.outlook.com>

I have another question that was encountered at the same time as my previous one, but I believe it is two separate issues, so I created a different thread.

When building 1.0.2g and attempting to remove some ciphers at build time ("no-idea"), I discovered that the Make scripting was attempting to build some of its files anyway:

[...]
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -g -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -std=gnu99 -Wa,--noexecstack -fomit-frame-pointer -DTERMIO -DPURIFY -DSSL_FORBID_ENULL -D_GNU_SOURCE -fstack-protector -Wall -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM   -c -o e_bf.o e_bf.c
make[2]: *** No rule to make target `../../include/openssl/idea.h', needed by `e_idea.o'.  Stop.
make[2]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto/evp'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto'
make: *** [build_crypto] Error 1

It looks as though the "no-idea" removes some of the header files from the build, but then the make tries to compile the .c files anyway.

Has anyone else encountered this problem?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160314/e2d1f374/attachment.html>

From googleersatz at oliverniebuhr.de  Mon Mar 14 19:03:05 2016
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Mon, 14 Mar 2016 20:03:05 +0100
Subject: [openssl-users] [Question] What are the current secure
 Configure Parameter?
In-Reply-To: <401084E5E73F4241A44F3C9E6FD79428036889C546@exch-01>
References: <56E0FB3C.6040306@oliverniebuhr.de>
 <401084E5E73F4241A44F3C9E6FD79428036889C546@exch-01>
Message-ID: <56E70AE9.5000208@oliverniebuhr.de>

Am 10.03.2016 um 14:49 schrieb Wall, Stephen:
> 
>> -----Original Message-----
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Oliver Niebuhr
>>
>> The Qt Wiki says, the following Parameters are minimum recommended:
>> no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
>>
>> My Questions are:
>> 1.) Are there any other Parameters that should be used?
> 
> I also add no-comp -DOPENSSL_NO_HEARTBEAT no-md2.
> 
> no-md2 might be a default.
> 
> Check Configure Options at https://wiki.openssl.org/index.php/Compilation_and_Installation for some other things you might not need, like no-srp no-psk no-dtls no-npn no-krb5 etc.  If this is a dedicated library for your application, I suggest you disable all features and ciphers you won't be using, for example, no-bf no-sha1 no-md5 no-seed etc....
> 
> If you control both ends, you could even distill it down to a single protocol cipher suite, like ECDHE-ECDSA-AES128-GCM-SHA256 with TLS1.2.
> 
Thanks. I will take a look at it.

Oliver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160314/f219c4c4/attachment.sig>

From rich at kde.org  Mon Mar 14 20:43:39 2016
From: rich at kde.org (Richard Moore)
Date: Mon, 14 Mar 2016 20:43:39 +0000
Subject: [openssl-users] [Question] What are the current secure
	Configure Parameter?
In-Reply-To: <56E0FB3C.6040306@oliverniebuhr.de>
References: <56E0FB3C.6040306@oliverniebuhr.de>
Message-ID: <CAMp7mVtb4ZtEwJcyvbk+naiWqh4jLG8EVQDaOTe4RPTb+u=c+g@mail.gmail.com>

On 10 March 2016 at 04:42, Oliver Niebuhr <googleersatz at oliverniebuhr.de>
wrote:

> Hello.
>
> I am using OpenSSL from within the Qt Project / QtWebEngine.
>
> The Qt Wiki says, the following Parameters are minimum recommended:
> no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
>

?Please could you provide a link since these options are a bit dubious, and
don't match what I'd expect as the qtnetwork maintainer. I've looked on the
wiki myself and I don't see them.

Cheers

Rich.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160314/3a662a99/attachment-0001.html>

From googleersatz at oliverniebuhr.de  Mon Mar 14 21:19:01 2016
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Mon, 14 Mar 2016 22:19:01 +0100
Subject: [openssl-users] [Question] What are the current secure
 Configure Parameter?
In-Reply-To: <CAMp7mVtb4ZtEwJcyvbk+naiWqh4jLG8EVQDaOTe4RPTb+u=c+g@mail.gmail.com>
References: <56E0FB3C.6040306@oliverniebuhr.de>
 <CAMp7mVtb4ZtEwJcyvbk+naiWqh4jLG8EVQDaOTe4RPTb+u=c+g@mail.gmail.com>
Message-ID: <56E72AC5.7070304@oliverniebuhr.de>

Am 14.03.2016 um 21:43 schrieb Richard Moore:
> 
> 
> On 10 March 2016 at 04:42, Oliver Niebuhr <googleersatz at oliverniebuhr.de
> <mailto:googleersatz at oliverniebuhr.de>> wrote:
> 
>     Hello.
> 
>     I am using OpenSSL from within the Qt Project / QtWebEngine.
> 
>     The Qt Wiki says, the following Parameters are minimum recommended:
>     no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
> 
> 
> ?Please could you provide a link since these options are a bit dubious,
> and don't match what I'd expect as the qtnetwork maintainer. I've looked
> on the wiki myself and I don't see them.
> 
> Cheers
> 
> Rich.

Evening.

The following Link
https://wiki.qt.io/Compiling_OpenSSL_with_MinGW

(relatively outdated)
under Section "How to Build" mentions not the no-ssl$ stuff.

But there was another Link which I can not find anymore - the last time
I saw it, was around late of Summer 2015. It most likely got deleted
during one of the "Wiki Cleanup Weeks".

It was definitely not from the Nokia times and it was from a Digia
Member - sorry my schizophrenic Brain is bad with Names.

Greetings
Oliver

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160314/0d79635a/attachment.sig>

From richmoore44 at gmail.com  Mon Mar 14 22:16:43 2016
From: richmoore44 at gmail.com (Richard Moore)
Date: Mon, 14 Mar 2016 22:16:43 +0000
Subject: [openssl-users] [Question] What are the current secure
	Configure Parameter?
In-Reply-To: <56E72AC5.7070304@oliverniebuhr.de>
References: <56E0FB3C.6040306@oliverniebuhr.de>
 <CAMp7mVtb4ZtEwJcyvbk+naiWqh4jLG8EVQDaOTe4RPTb+u=c+g@mail.gmail.com>
 <56E72AC5.7070304@oliverniebuhr.de>
Message-ID: <CAMp7mVvQwAJfwbVUEReDcgY57o8+9SJfiba7ptAv+9AJE2oDbw@mail.gmail.com>

On 14 March 2016 at 21:19, Oliver Niebuhr <googleersatz at oliverniebuhr.de>
wrote:

> Am 14.03.2016 um 21:43 schrieb Richard Moore:
> > On 10 March 2016 at 04:42, Oliver Niebuhr <googleersatz at oliverniebuhr.de
> > <mailto:googleersatz at oliverniebuhr.de>> wrote:
> ??
> >     I am using OpenSSL from within the Qt Project / QtWebEngine.
> >
> >     The Qt Wiki says, the following Parameters are minimum recommended:
> >     no-ssl2 no-ssl3 no-idea no-mdc2 no-rc5
> >
> >
> > ?Please could you provide a link since these options are a bit dubious,
> > and don't match what I'd expect as the qtnetwork maintainer. I've looked
> > on the wiki myself and I don't see them.
> >
> > Cheers
> >
> > Rich.
>
> Evening.
>
> The following Link
> https://wiki.qt.io/Compiling_OpenSSL_with_MinGW
>
> (relatively outdated)
> under Section "How to Build" mentions not the no-ssl$ stuff.
>
>
?Yes, the no-ssl2 is fine, but the no-ssl3 seems unlikely to work with many
sites. Also Qt Web Engine uses the chromium network stack so the
requirements are different. I've asked the qtwebengine guys what the score
is.?



> But there was another Link which I can not find anymore - the last time
> I saw it, was around late of Summer 2015. It most likely got deleted
> during one of the "Wiki Cleanup Weeks".
>
> It was definitely not from the Nokia times and it was from a Digia
> Member - sorry my schizophrenic Brain is bad with Names.
>

?I'm afraid without more info I can't look into it - the wiki records the
history but I have to know what to look for.

Never mind.

Rich.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160314/cbf087fb/attachment.html>

From satya at attivonetworks.com  Tue Mar 15 00:30:56 2016
From: satya at attivonetworks.com (Satya Das)
Date: Tue, 15 Mar 2016 00:30:56 +0000
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what is
 embedded in libcrypto.so
Message-ID: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>

Hello,

I have a simple problem I am trying to solve. I have built a fips capable openssl shared object (.so). I also have the sha1 hash of the fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In order to make sure the build is good, I want to make sure that the .so was indeed built with these versions of fipscanister.o and fips_premain.

Is there a way to do this ? I am on centos 6.6 x86_64 and linking to object module 2.0.11 from openssl 1.0.1e with patches.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/8d902a41/attachment.html>

From ethan.rahn at gmail.com  Tue Mar 15 01:10:49 2016
From: ethan.rahn at gmail.com (Ethan Rahn)
Date: Mon, 14 Mar 2016 18:10:49 -0700
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <CAEW9rAg7RpyOpm3JiZfSiWDzSyCAiU5v9gMr2Ytnp5X+OQdubg@mail.gmail.com>

Is there a reason why you cannot build it from a controlled build
environment and record the hash of the final .so?

It seems that it would be pretty non-trivial if not impossible to pull a .o
file from a .so in the exact same format that it went in, such that you
could check the hash. Being able to check if a .c file is in the same state
in the .so afterwards seems pretty much impossible given all the things
that would change in the code with compiling and linking in between the .c
state and the final .so state.

On Mon, Mar 14, 2016 at 5:30 PM, Satya Das <satya at attivonetworks.com> wrote:

> Hello,
>
>
>
> I have a simple problem I am trying to solve. I have built a fips capable
> openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1
> hash of fips_premain.c in a file called fips_premain.c.sha1. In order to
> make sure the build is good, I want to make sure that the .so was indeed
> built with these versions of fipscanister.o and fips_premain.
>
>
>
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.
>
>
>
> Thanks
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160314/5665c793/attachment.html>

From satya at attivonetworks.com  Tue Mar 15 04:26:54 2016
From: satya at attivonetworks.com (Satya Das)
Date: Tue, 15 Mar 2016 04:26:54 +0000
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <CAEW9rAg7RpyOpm3JiZfSiWDzSyCAiU5v9gMr2Ytnp5X+OQdubg@mail.gmail.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>,
 <CAEW9rAg7RpyOpm3JiZfSiWDzSyCAiU5v9gMr2Ytnp5X+OQdubg@mail.gmail.com>
Message-ID: <947A39F18FC1E665.1-a94b04c6-0a05-4e98-b35d-0da2d3bff24a@mail.outlook.com>

Hello Ethan,

I am tweaking the centos rpmspec to use my fips object module.  That seems to be downloading source tar ball, patching etc.

Please note that the sha1 of the so is not so interesting as the embedded sha1 check inside so (when one calls FIPS_mode_set). Essentially if I can get the embedded sha1in the so, I can compare that with the sha1 I have as part of the object module I have built. I am assuming the embedded sha1 is that of fipscanister.o.

Hope that makes sense ?

Thanks.



From: Ethan Rahn
Sent: Monday, March 14, 6:11 PM
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so
To: openssl-users at openssl.org

Is there a reason why you cannot build it from a controlled build environment and record the hash of the final .so?

It seems that it would be pretty non-trivial if not impossible to pull a .o file from a .so in the exact same format that it went in, such that you could check the hash. Being able to check if a .c file is in the same state in the .so afterwards seems pretty much impossible given all the things that would change in the code with compiling and linking in between the .c state and the final .so state.

On Mon, Mar 14, 2016 at 5:30 PM, Satya Das <satya at attivonetworks.com<mailto:satya at attivonetworks.com>> wrote:

Hello,



I have a simple problem I am trying to solve. I have built a fips capable openssl shared object (.so). I also have the sha1 hash of the fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In order to make sure the build is good, I want to make sure that the .so was indeed built with these versions of fipscanister.o and fips_premain.



Is there a way to do this ? I am on centos 6.6 x86_64 and linking to object module 2.0.11 from openssl 1.0.1e with patches.



Thanks

--
openssl-users mailing list
To unsubscribe: https<https://mta.openssl.org/mailman/listinfo/openssl-users>://<https://mta.openssl.org/mailman/listinfo/openssl-users>mta.openssl.org<https://mta.openssl.org/mailman/listinfo/openssl-users>/mailman/<https://mta.openssl.org/mailman/listinfo/openssl-users>listinfo<https://mta.openssl.org/mailman/listinfo/openssl-users>/<https://mta.openssl.org/mailman/listinfo/openssl-users>openssl-users<https://mta.openssl.org/mailman/listinfo/openssl-users>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/f3b2cd0b/attachment-0001.html>

From akihana at gmail.com  Tue Mar 15 05:08:59 2016
From: akihana at gmail.com (Mike Mohr)
Date: Mon, 14 Mar 2016 22:08:59 -0700
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <947A39F18FC1E665.1-a94b04c6-0a05-4e98-b35d-0da2d3bff24a@mail.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <CAEW9rAg7RpyOpm3JiZfSiWDzSyCAiU5v9gMr2Ytnp5X+OQdubg@mail.gmail.com>
 <947A39F18FC1E665.1-a94b04c6-0a05-4e98-b35d-0da2d3bff24a@mail.outlook.com>
Message-ID: <CAJe-LUi2Lv9yhhG1aixFmHovfacOyyyYwQp3+b7gV52hT4DBmA@mail.gmail.com>

During the final linking stage, when the shared object is built, the
compiler is free to insert functions from compiled object files anywhere it
sees fit in the final shared object's code segment.  The object file is
fundamentally transformed by this process; information which was present in
the original object file may or may not end up in the resulting shared
object.  Although the machine code in the subroutines should be copied into
the final shared object unmodified, the original object file is effectively
gone and cannot be recovered.  Without the original object file, we cannot
calculate its cryptographic hash.

"As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance."

Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6,
page 163). Carbondale, IL: Southern Illinois University Press.

On Mon, Mar 14, 2016 at 9:26 PM, Satya Das <satya at attivonetworks.com> wrote:

> Hello Ethan,
>
> I am tweaking the centos rpmspec to use my fips object module.  That seems
> to be downloading source tar ball, patching etc.
>
> Please note that the sha1 of the so is not so interesting as the embedded
> sha1 check inside so (when one calls FIPS_mode_set). Essentially if I can
> get the embedded sha1in the so, I can compare that with the sha1 I have as
> part of the object module I have built. I am assuming the embedded sha1 is
> that of fipscanister.o.
>
> Hope that makes sense ?
>
> Thanks.
>
>
> From: Ethan Rahn
> Sent: Monday, March 14, 6:11 PM
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
> To: openssl-users at openssl.org
>
> Is there a reason why you cannot build it from a controlled build
> environment and record the hash of the final .so?
>
> It seems that it would be pretty non-trivial if not impossible to pull a
> .o file from a .so in the exact same format that it went in, such that you
> could check the hash. Being able to check if a .c file is in the same state
> in the .so afterwards seems pretty much impossible given all the things
> that would change in the code with compiling and linking in between the .c
> state and the final .so state.
>
> On Mon, Mar 14, 2016 at 5:30 PM, Satya Das <satya at attivonetworks.com>
> wrote:
>
> Hello,
>
>
>
> I have a simple problem I am trying to solve. I have built a fips capable
> openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the sha1
> hash of fips_premain.c in a file called fips_premain.c.sha1. In order to
> make sure the build is good, I want to make sure that the .so was indeed
> built with these versions of fipscanister.o and fips_premain.
>
>
>
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.
>
>
>
> Thanks
>
> --
> openssl-users mailing list
> To unsubscribe: https
> <https://mta.openssl.org/mailman/listinfo/openssl-users>://
> <https://mta.openssl.org/mailman/listinfo/openssl-users>mta.openssl.org
> <https://mta.openssl.org/mailman/listinfo/openssl-users>/mailman/
> <https://mta.openssl.org/mailman/listinfo/openssl-users>listinfo
> <https://mta.openssl.org/mailman/listinfo/openssl-users>/
> <https://mta.openssl.org/mailman/listinfo/openssl-users>openssl-users
> <https://mta.openssl.org/mailman/listinfo/openssl-users>
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160314/9ee764b0/attachment.html>

From jb-openssl at wisemo.com  Tue Mar 15 05:38:49 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 15 Mar 2016 06:38:49 +0100
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <947A39F18FC1E665.1-a94b04c6-0a05-4e98-b35d-0da2d3bff24a@mail.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <CAEW9rAg7RpyOpm3JiZfSiWDzSyCAiU5v9gMr2Ytnp5X+OQdubg@mail.gmail.com>
 <947A39F18FC1E665.1-a94b04c6-0a05-4e98-b35d-0da2d3bff24a@mail.outlook.com>
Message-ID: <56E79FE9.8070902@wisemo.com>

Let me explain this a bit more clearly:

The fipscanister.o file (like any other .o file) contains
two things:

1. The actual code and constant data (if any) that needs
   to go in the final .so or program file.  This is what
   will eventually be hashed to produce the embedded sha1
   check.

2. Relocation information on how the linker should adjust
   the code to indicate its location in the .so file (and
   in memory on some platforms) and how other parts of the
   .so file shall be adjusted to indicate the location of
   the code in fipscanister.o.  This data is used and
   removed when creating the copy of the fips canister in
   the .so or program file.

Therefore an sha-1 sum of the fipscanister.o file will
include more (and different) bytes than the fips canister
inside the final .so file, and will thus not match the
sha-1 sum that needs to be embedded inside that .so file.

Also for some build targets, the fips canister inside
the final .so file will similarly not match the in-
memory fips canister in the running program, which is
what the embedded sha-1 sum must match.

Using a 3rd party build script which downloads the source
code from somewhere beyond your control cannot be used as
a secure way to build anything supposedly secure.  Such
build scripts are fundamentally insecure and should not
be used.

On 15/03/2016 05:26, Satya Das wrote:
>
> Hello Ethan,
>
> I am tweaking the centos rpmspec to use my fips object module.  That 
> seems to be downloading source tar ball, patching etc.
>
> Please note that the sha1 of the so is not so interesting as the 
> embedded sha1 check inside so (when one calls FIPS_mode_set). 
> Essentially if I can get the embedded sha1in the so, I can compare 
> that with the sha1 I have as part of the object module I have built. I 
> am assuming the embedded sha1 is that of fipscanister.o.
>
> Hope that makes sense ?
>
> Thanks.
>
>
> From: Ethan Rahn
> Sent: Monday, March 14, 6:11 PM
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with 
> what is embedded in libcrypto.so
> To: openssl-users at openssl.org
>
> Is there a reason why you cannot build it from a controlled build 
> environment and record the hash of the final .so?
>
> It seems that it would be pretty non-trivial if not impossible to pull 
> a .o file from a .so in the exact same format that it went in, such 
> that you could check the hash. Being able to check if a .c file is in 
> the same state in the .so afterwards seems pretty much impossible 
> given all the things that would change in the code with compiling and 
> linking in between the .c state and the final .so state.
>
> On Mon, Mar 14, 2016 at 5:30 PM, Satya Das <satya at attivonetworks.com 
> <mailto:satya at attivonetworks.com>> wrote:
>
>> Hello,
>>
>> I have a simple problem I am trying to solve. I have built a fips 
>> capable openssl shared object (.so). I also have the sha1 hash of the 
>> fipscanister.o in a file called fipscanister.o.sha1. I also have the 
>> sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In 
>> order to make sure the build is good, I want to make sure that the 
>> .so was indeed built with these versions of fipscanister.o and 
>> fips_premain.
>>
>> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to 
>> object module 2.0.11 from openssl 1.0.1e with patches.
>>
>>

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From satya at attivonetworks.com  Tue Mar 15 06:07:02 2016
From: satya at attivonetworks.com (Satya Das)
Date: Tue, 15 Mar 2016 06:07:02 +0000
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <56E79FE9.8070902@wisemo.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <CAEW9rAg7RpyOpm3JiZfSiWDzSyCAiU5v9gMr2Ytnp5X+OQdubg@mail.gmail.com>
 <947A39F18FC1E665.1-a94b04c6-0a05-4e98-b35d-0da2d3bff24a@mail.outlook.com>,
 <56E79FE9.8070902@wisemo.com>
Message-ID: <BL2PR07MB240488CB87FC20E87E95D608D7890@BL2PR07MB2404.namprd07.prod.outlook.com>

Hello Jakob,

Thank you for the information. So what you are saying is the object module build that generated the SHA1s are not the ones that are embedded. That makes sense.

So then what would be the best way to validate the build to have consumed the right object files ? Is there a way to generate the embedded sha1 sum from a given fipscanister.o (or other artefacts from object module build process) ? 

Also how do I locate the embedded sha1 in so ? Is it a symbol I should look for in gdb ?

Thanks.

________________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Jakob Bohm <jb-openssl at wisemo.com>
Sent: Monday, March 14, 2016 10:38 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

Let me explain this a bit more clearly:

The fipscanister.o file (like any other .o file) contains
two things:

1. The actual code and constant data (if any) that needs
   to go in the final .so or program file.  This is what
   will eventually be hashed to produce the embedded sha1
   check.

2. Relocation information on how the linker should adjust
   the code to indicate its location in the .so file (and
   in memory on some platforms) and how other parts of the
   .so file shall be adjusted to indicate the location of
   the code in fipscanister.o.  This data is used and
   removed when creating the copy of the fips canister in
   the .so or program file.

Therefore an sha-1 sum of the fipscanister.o file will
include more (and different) bytes than the fips canister
inside the final .so file, and will thus not match the
sha-1 sum that needs to be embedded inside that .so file.

Also for some build targets, the fips canister inside
the final .so file will similarly not match the in-
memory fips canister in the running program, which is
what the embedded sha-1 sum must match.

Using a 3rd party build script which downloads the source
code from somewhere beyond your control cannot be used as
a secure way to build anything supposedly secure.  Such
build scripts are fundamentally insecure and should not
be used.

On 15/03/2016 05:26, Satya Das wrote:
>
> Hello Ethan,
>
> I am tweaking the centos rpmspec to use my fips object module.  That
> seems to be downloading source tar ball, patching etc.
>
> Please note that the sha1 of the so is not so interesting as the
> embedded sha1 check inside so (when one calls FIPS_mode_set).
> Essentially if I can get the embedded sha1in the so, I can compare
> that with the sha1 I have as part of the object module I have built. I
> am assuming the embedded sha1 is that of fipscanister.o.
>
> Hope that makes sense ?
>
> Thanks.
>
>
> From: Ethan Rahn
> Sent: Monday, March 14, 6:11 PM
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
> To: openssl-users at openssl.org
>
> Is there a reason why you cannot build it from a controlled build
> environment and record the hash of the final .so?
>
> It seems that it would be pretty non-trivial if not impossible to pull
> a .o file from a .so in the exact same format that it went in, such
> that you could check the hash. Being able to check if a .c file is in
> the same state in the .so afterwards seems pretty much impossible
> given all the things that would change in the code with compiling and
> linking in between the .c state and the final .so state.
>
> On Mon, Mar 14, 2016 at 5:30 PM, Satya Das <satya at attivonetworks.com
> <mailto:satya at attivonetworks.com>> wrote:
>
>> Hello,
>>
>> I have a simple problem I am trying to solve. I have built a fips
>> capable openssl shared object (.so). I also have the sha1 hash of the
>> fipscanister.o in a file called fipscanister.o.sha1. I also have the
>> sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In
>> order to make sure the build is good, I want to make sure that the
>> .so was indeed built with these versions of fipscanister.o and
>> fips_premain.
>>
>> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
>> object module 2.0.11 from openssl 1.0.1e with patches.
>>
>>

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

From michel.sales at free.fr  Tue Mar 15 11:12:57 2016
From: michel.sales at free.fr (Michel)
Date: Tue, 15 Mar 2016 12:12:57 +0100
Subject: [openssl-users] Questions about OCB and Wrap modes
Message-ID: <001b01d17eab$a148df70$e3da9e50$@sales@free.fr>

Hi,

 

As there was some discussion about AEAD, I am still curious to know why OCB
mode isn't flagged as one of them :

assert( EVP_CIPHER_flags( EVP_aes_128_ocb() ) & EVP_CIPH_FLAG_AEAD_CIPHER );
failed ?

 

Can someone please explain this to me ?

 

And by the way, I would also be happy to understand why the wrap modes have
to be 'allowed'. 

I  am asking because at the moment, I am doing something like :

if( EVP_CIPHER_mode( pCipher ) == EVP_CIPH_WRAP_MODE )
EVP_CIPHER_CTX_set_flags( pCtx, EVP_CIPHER_CTX_FLAG_WRAP_ALLOW);

But I suspect it might not be the best strategy, because if it was so easy,
it could have been done automatically /transparently no ?

 

Regards,

 

Michel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/fa29b640/attachment-0001.html>

From marquess at openssl.com  Tue Mar 15 13:02:25 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 15 Mar 2016 09:02:25 -0400
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <56E807E1.7040303@openssl.com>

On 03/14/2016 08:30 PM, Satya Das wrote:
> Hello,
> 
>  
> 
> I have a simple problem I am trying to solve. I have built a fips
> capable openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the
> sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In
> order to make sure the build is good, I want to make sure that the .so
> was indeed built with these versions of fipscanister.o and fips_premain.
> 
>  
> 
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.

Hmmmm.  Several comments:

1) Please read the OpenSSL FIPS User Guide,
https://openssl.org/docs/fips/UserGuide-2.0.pdf. It answers most (I
would even say all) of your questions. Yes, it's a long dull slog to
read but then open source FIPS 140-2 is a horribly convoluted topic.

2) The libcrypto shared library is just an application in the context of
FIPS 140-2, and in general you're not going to be able to reconstruct an
object module file (foo.o) from an executable binary image that was
built from it. Nor is there any FIPS 140-2 related requirement to do so.

3) The fipscanister.o file is a little bit more (and less) that your
typical object module ("module" in the usual software engineering sense.
It is discussed in the OpenSSL FIPS User Guide, in particular section 2.3.2.

Note the SHA1 digest of the libcrypto shared library file, or of any
other application, is completely irrelevant to FIPS 140-2. In fact the
CMVP specifically disallowed any integrity test that contained such
"extraneous" data (see section 2.3.1). We were told at the time that was
because of the risk of SHA1 digest collision.

3) The "file integrity chain" (section 2.4) requires that the interim
files created from the official source distribution tarball be verified
using SHA1 hashes. Somewhat oddly, given the rather intense focus on
ideological righteousness elsewhere, you're allowed to do this with an
un-sanctified SHA1 implementation. Notice for instance that the stock
build process uses an interim utility ("./fips/fips_standalone_sha1")
built from the same code as used in the FIPS module.

Also note that this is first and foremost a procedural or paperwork
chain. You can have two software products that claim to use FIPS 140-2
validated crypto, and those can be bit-for bit identical, yet with one
satisfying the FIPS 140-2 validation requirements and one not; no
conceivable technical test can distinguish them (we call this difference
FIPS "magical pixie dust").

4) The canonical FIPS module integrity test, common to all FIPS modules,
takes the form of the "incore integrity test" for the OpenSSL FIPS
module (discussed in detail in -- you guessed it -- the User Guide).
Note that this incore integrity test does *not* include all of the
contents of the fipscanister.o object file.

5) As Jakob has correctly noted, there is no point in trying to automate
the FIPS module build-from-source; you'll lose the FIPS 140-2 magical
pixie dust of righteousness which is the whole, entire, and only point
of using the FIPS module. Section 5.5 has some recommendations, which I
often summarize by suggesting the module ("fipscanister.o" et. al.) be
built once in a solemn candle-lit ceremony and only those resulting
install targets preserved (no point in keeping the source, it can't be
changed and can't even be transferred via the usual common sense means).
At a minimum you'll need an official CD (section 6.6; yup, snail mail is
a "trusted path"). We're still sending those out for free, in spite of
the significant financial losses the OpenSSL FIPS business sustained
last year.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From sharad.tekale at zebra.com  Tue Mar 15 12:15:51 2016
From: sharad.tekale at zebra.com (Tekale, Sharad)
Date: Tue, 15 Mar 2016 12:15:51 +0000
Subject: [openssl-users] openssl 1.0.1p PEM_write_bio_RSAPrivateKey fail.
 error: ASN1_get_object:too long
Message-ID: <BL2PR03MB164FB8006DF0F108306B061EA890@BL2PR03MB164.namprd03.prod.outlook.com>

Hi Folks,



Need help.



I'm not able to encrypt a key using passphrase, below is the error message.

*"error:0D07209B:asn1 encoding routines:ASN1_get_object:too long"*



Have already googled for error but couldn't got much info





Snippet of my code:



unsigned char pass[] = "123456";

BIO *priv_bio = BIO_new( BIO_s_mem() );

RSA *rsa = RSA_generate_key( 2048, 65537, NULL, NULL )
ret = PEM_write_bio_RSAPrivateKey( priv_bio, rsa, EVP_aes_256_cbc(), pass, 64, NULL, NULL );



if(!ret) {

    ERR_error_string(ERR_get_error(), buffer);

    printf(buffer);

}





The same piece of code is working on openssl-0.9.8zg.



Can I know what's missing or any further debug steps to check this issue?



Thanks,
Sharad.








________________________________
- CONFIDENTIAL-

This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/c1aae62b/attachment.html>

From satya at attivonetworks.com  Tue Mar 15 18:22:10 2016
From: satya at attivonetworks.com (Satya Das)
Date: Tue, 15 Mar 2016 18:22:10 +0000
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <56E807E1.7040303@openssl.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>,
 <56E807E1.7040303@openssl.com>
Message-ID: <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>

Hello Steve,

Thank you for your comments.

Is there a way to verify that the correct version of object module (fipscanister.o) was assimilated into the libcrypto.so ? 
I just need some surefire way to run an engineering check on the build. Essentially what my question boils down to, is 
that there is code in there somewhere that comes up with the run time hash and compares with the embedded hash.
Is there a way to use those code pieces to somehow double check that the embedded hash matches the object module that
libcrypto should have been linked to ?

Please note that I am not automating the build, which has been discouraged in the User Guide 
(yes I have read probably around 40% of it). However because of the complex build flow I want
to have a post build manual check before using the openssl rpm in rest of the product.

Thanks

________________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Steve Marquess <marquess at openssl.com>
Sent: Tuesday, March 15, 2016 6:02 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

On 03/14/2016 08:30 PM, Satya Das wrote:
> Hello,
>
>
>
> I have a simple problem I am trying to solve. I have built a fips
> capable openssl shared object (.so). I also have the sha1 hash of the
> fipscanister.o in a file called fipscanister.o.sha1. I also have the
> sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In
> order to make sure the build is good, I want to make sure that the .so
> was indeed built with these versions of fipscanister.o and fips_premain.
>
>
>
> Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> object module 2.0.11 from openssl 1.0.1e with patches.

Hmmmm.  Several comments:

1) Please read the OpenSSL FIPS User Guide,
https://openssl.org/docs/fips/UserGuide-2.0.pdf. It answers most (I
would even say all) of your questions. Yes, it's a long dull slog to
read but then open source FIPS 140-2 is a horribly convoluted topic.

2) The libcrypto shared library is just an application in the context of
FIPS 140-2, and in general you're not going to be able to reconstruct an
object module file (foo.o) from an executable binary image that was
built from it. Nor is there any FIPS 140-2 related requirement to do so.

3) The fipscanister.o file is a little bit more (and less) that your
typical object module ("module" in the usual software engineering sense.
It is discussed in the OpenSSL FIPS User Guide, in particular section 2.3.2.

Note the SHA1 digest of the libcrypto shared library file, or of any
other application, is completely irrelevant to FIPS 140-2. In fact the
CMVP specifically disallowed any integrity test that contained such
"extraneous" data (see section 2.3.1). We were told at the time that was
because of the risk of SHA1 digest collision.

3) The "file integrity chain" (section 2.4) requires that the interim
files created from the official source distribution tarball be verified
using SHA1 hashes. Somewhat oddly, given the rather intense focus on
ideological righteousness elsewhere, you're allowed to do this with an
un-sanctified SHA1 implementation. Notice for instance that the stock
build process uses an interim utility ("./fips/fips_standalone_sha1")
built from the same code as used in the FIPS module.

Also note that this is first and foremost a procedural or paperwork
chain. You can have two software products that claim to use FIPS 140-2
validated crypto, and those can be bit-for bit identical, yet with one
satisfying the FIPS 140-2 validation requirements and one not; no
conceivable technical test can distinguish them (we call this difference
FIPS "magical pixie dust").

4) The canonical FIPS module integrity test, common to all FIPS modules,
takes the form of the "incore integrity test" for the OpenSSL FIPS
module (discussed in detail in -- you guessed it -- the User Guide).
Note that this incore integrity test does *not* include all of the
contents of the fipscanister.o object file.

5) As Jakob has correctly noted, there is no point in trying to automate
the FIPS module build-from-source; you'll lose the FIPS 140-2 magical
pixie dust of righteousness which is the whole, entire, and only point
of using the FIPS module. Section 5.5 has some recommendations, which I
often summarize by suggesting the module ("fipscanister.o" et. al.) be
built once in a solemn candle-lit ceremony and only those resulting
install targets preserved (no point in keeping the source, it can't be
changed and can't even be transferred via the usual common sense means).
At a minimum you'll need an official CD (section 6.6; yup, snail mail is
a "trusted path"). We're still sending those out for free, in spite of
the significant financial losses the OpenSSL FIPS business sustained
last year.

-Steve M.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From marquess at openssl.com  Tue Mar 15 19:30:18 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 15 Mar 2016 15:30:18 -0400
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <56E862CA.9050605@openssl.com>

On 03/15/2016 02:22 PM, Satya Das wrote:
> Hello Steve,
> 
> Thank you for your comments.
> 
> Is there a way to verify that the correct version of object module (fipscanister.o) was assimilated into the libcrypto.so ? 
> I just need some surefire way to run an engineering check on the build. Essentially what my question boils down to, is 
> that there is code in there somewhere that comes up with the run time hash and compares with the embedded hash.
> Is there a way to use those code pieces to somehow double check that the embedded hash matches the object module that
> libcrypto should have been linked to ?
> 
> ...

In a word, no. In principle a utility could be written, for most
platforms, based on the "incore" utilities used for cross-compilation
(some of which are included in the FIPS module tarball). To my knowledge
that has not been done, and would be moot anyway because as noted in my
original response *no* technical test of *any* kind can determine the
absence of the procedural "pixie dust".

Let me elaborate on that a bit as I didn't get the point across the
first time. If I build the OpenSSL FIPS module and fail to follow the
mandated build process exactly, the result is not validated. So for
instance any of the following failures:

a) I download openssl-fips-2.0.N.tar.gz instead of getting the official
snail-mailed CD;

b) Neglect to check the tarball digest against the value in Appendix B
of the Security Policy;

c) Build with "./Configure ..." instead of "./config", even though the
build options are identical;

d) Edit the README in the ./openssl-fips-2.0.N/ workarea created from
the tarball;

...mean the result is not validated, even though it may be *exactly*
bit-for-bit identical with one built without those procedural errors. No
technical test can verify the presence of the magical pixie dust of FIPS
140-2 righteousness!

Keep in mind that this issue - how do I tell if application X is using
FIPS module Y -- is the same for *all* FIPS validated cryptography. Most
of which is proprietary with the content of the module and the digests
unknown.

If you ask the CMVP this question they will say "get a letter from the
vendor". That is a sensible answer; the letter will be the CYA you need
for any audit or assessment. While you may be able to prove a product
does *not* use FIPS validated crypto; you can never prove a product
contains a righteous FIPS 140-2 validated module other than with such
documentation.

An aside of historical interest: I started getting sucked down the FIPS
140-2 rabbit hole nearly two decades ago, when I had just such a vendor
letter in hand. But, that vendor kept shipping software that clearly did
*not* use FIPS validated cryptography (I could get it to use non-allowed
algorithms). After I complained repeatedly that vendor finally confessed
"our product version that uses the FIPS crypto is very old, you don't
want that". Well yes I did (i.e. my client did) and insisted on getting
the righteous product. So the vendor ended up sending us a hand-labeled
CD :-(.

The moral of that story is that you should get the vendor letter (or in
the OpenSSL FIPS module case do the section 5.5 documentation thing) and
move on; I didn't and was condemned to an eternity of tilting at the
FIPS 140-2 windmill...

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From akihana at gmail.com  Tue Mar 15 20:58:04 2016
From: akihana at gmail.com (Mike Mohr)
Date: Tue, 15 Mar 2016 13:58:04 -0700
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <CAJe-LUj2wYBcyBfPbFuztuoMqSZ=j+1RPNfuBybGynFqvgyfbw@mail.gmail.com>

During the linking process, parts of fipscanister.o are removed (discarded)
by the linker. Also, jumps and call instructions have their operands
changed (addresses are filled in or relocation information is added) and
the machine code is fundamentally altered.

Imagine the linking process as something analogous to baking a cheese
quiche with tomatoes. The can of tomatoes you use (i.e., the fipscanister.o
file) is opened. The metal can is discarded along with any liquid inside
the can. Then the tomatoes are placed into the quiche and baked. Melting
cheese seeps into the tomatoes and the tomatoes are physically deformed and
soften. At the end you have a delicious quiche. Can you get the original
can of tomatoes back, in its unmodified form, at this point? Can you
identify exactly which can of tomatoes was used to make this quiche, given
only photos of all the cans prior to opening them?
On Mar 15, 2016 11:22 AM, "Satya Das" <satya at attivonetworks.com> wrote:

> Hello Steve,
>
> Thank you for your comments.
>
> Is there a way to verify that the correct version of object module
> (fipscanister.o) was assimilated into the libcrypto.so ?
> I just need some surefire way to run an engineering check on the build.
> Essentially what my question boils down to, is
> that there is code in there somewhere that comes up with the run time hash
> and compares with the embedded hash.
> Is there a way to use those code pieces to somehow double check that the
> embedded hash matches the object module that
> libcrypto should have been linked to ?
>
> Please note that I am not automating the build, which has been discouraged
> in the User Guide
> (yes I have read probably around 40% of it). However because of the
> complex build flow I want
> to have a post build manual check before using the openssl rpm in rest of
> the product.
>
> Thanks
>
> ________________________________________
> From: openssl-users <openssl-users-bounces at openssl.org> on behalf of
> Steve Marquess <marquess at openssl.com>
> Sent: Tuesday, March 15, 2016 6:02 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
>
> On 03/14/2016 08:30 PM, Satya Das wrote:
> > Hello,
> >
> >
> >
> > I have a simple problem I am trying to solve. I have built a fips
> > capable openssl shared object (.so). I also have the sha1 hash of the
> > fipscanister.o in a file called fipscanister.o.sha1. I also have the
> > sha1 hash of fips_premain.c in a file called fips_premain.c.sha1. In
> > order to make sure the build is good, I want to make sure that the .so
> > was indeed built with these versions of fipscanister.o and fips_premain.
> >
> >
> >
> > Is there a way to do this ? I am on centos 6.6 x86_64 and linking to
> > object module 2.0.11 from openssl 1.0.1e with patches.
>
> Hmmmm.  Several comments:
>
> 1) Please read the OpenSSL FIPS User Guide,
> https://openssl.org/docs/fips/UserGuide-2.0.pdf. It answers most (I
> would even say all) of your questions. Yes, it's a long dull slog to
> read but then open source FIPS 140-2 is a horribly convoluted topic.
>
> 2) The libcrypto shared library is just an application in the context of
> FIPS 140-2, and in general you're not going to be able to reconstruct an
> object module file (foo.o) from an executable binary image that was
> built from it. Nor is there any FIPS 140-2 related requirement to do so.
>
> 3) The fipscanister.o file is a little bit more (and less) that your
> typical object module ("module" in the usual software engineering sense.
> It is discussed in the OpenSSL FIPS User Guide, in particular section
> 2.3.2.
>
> Note the SHA1 digest of the libcrypto shared library file, or of any
> other application, is completely irrelevant to FIPS 140-2. In fact the
> CMVP specifically disallowed any integrity test that contained such
> "extraneous" data (see section 2.3.1). We were told at the time that was
> because of the risk of SHA1 digest collision.
>
> 3) The "file integrity chain" (section 2.4) requires that the interim
> files created from the official source distribution tarball be verified
> using SHA1 hashes. Somewhat oddly, given the rather intense focus on
> ideological righteousness elsewhere, you're allowed to do this with an
> un-sanctified SHA1 implementation. Notice for instance that the stock
> build process uses an interim utility ("./fips/fips_standalone_sha1")
> built from the same code as used in the FIPS module.
>
> Also note that this is first and foremost a procedural or paperwork
> chain. You can have two software products that claim to use FIPS 140-2
> validated crypto, and those can be bit-for bit identical, yet with one
> satisfying the FIPS 140-2 validation requirements and one not; no
> conceivable technical test can distinguish them (we call this difference
> FIPS "magical pixie dust").
>
> 4) The canonical FIPS module integrity test, common to all FIPS modules,
> takes the form of the "incore integrity test" for the OpenSSL FIPS
> module (discussed in detail in -- you guessed it -- the User Guide).
> Note that this incore integrity test does *not* include all of the
> contents of the fipscanister.o object file.
>
> 5) As Jakob has correctly noted, there is no point in trying to automate
> the FIPS module build-from-source; you'll lose the FIPS 140-2 magical
> pixie dust of righteousness which is the whole, entire, and only point
> of using the FIPS module. Section 5.5 has some recommendations, which I
> often summarize by suggesting the module ("fipscanister.o" et. al.) be
> built once in a solemn candle-lit ceremony and only those resulting
> install targets preserved (no point in keeping the source, it can't be
> changed and can't even be transferred via the usual common sense means).
> At a minimum you'll need an official CD (section 6.6; yup, snail mail is
> a "trusted path"). We're still sending those out for free, in spite of
> the significant financial losses the OpenSSL FIPS business sustained
> last year.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/8c1f4344/attachment.html>

From satya at attivonetworks.com  Tue Mar 15 21:24:13 2016
From: satya at attivonetworks.com (Satya Das)
Date: Tue, 15 Mar 2016 21:24:13 +0000
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <56E862CA.9050605@openssl.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E862CA.9050605@openssl.com>
Message-ID: <BL2PR07MB2404733E46065F0FE413B52AD7890@BL2PR07MB2404.namprd07.prod.outlook.com>

Hello Steve,

Even if a vendor letter is good for CMVP, how is the vendor supposed to know ? 

I would say openssl should give such a tool so that vendor and the testing Lab can know such things. It is more than critical that the applications link to the intended crypto module. This convoluted and complex object module linking etc. with 207 page user guide is specific to openssl's approach to FIPS, and therefore should be addressed by the project. It should not come down to some vendor document written in good faith.

Thanks again for your comments.


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess
Sent: Tuesday, March 15, 2016 12:30 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

In a word, no. In principle a utility could be written, for most platforms, based on the "incore" utilities used for cross-compilation (some of which are included in the FIPS module tarball). To my knowledge that has not been done, and would be moot anyway because as noted in my original response *no* technical test of *any* kind can determine the absence of the procedural "pixie dust".

Let me elaborate on that a bit as I didn't get the point across the first time. If I build the OpenSSL FIPS module and fail to follow the mandated build process exactly, the result is not validated. So for instance any of the following failures:

a) I download openssl-fips-2.0.N.tar.gz instead of getting the official snail-mailed CD;

b) Neglect to check the tarball digest against the value in Appendix B of the Security Policy;

c) Build with "./Configure ..." instead of "./config", even though the build options are identical;

d) Edit the README in the ./openssl-fips-2.0.N/ workarea created from the tarball;

...mean the result is not validated, even though it may be *exactly* bit-for-bit identical with one built without those procedural errors. No technical test can verify the presence of the magical pixie dust of FIPS
140-2 righteousness!

Keep in mind that this issue - how do I tell if application X is using FIPS module Y -- is the same for *all* FIPS validated cryptography. Most of which is proprietary with the content of the module and the digests unknown.

If you ask the CMVP this question they will say "get a letter from the vendor". That is a sensible answer; the letter will be the CYA you need for any audit or assessment. While you may be able to prove a product does *not* use FIPS validated crypto; you can never prove a product contains a righteous FIPS 140-2 validated module other than with such documentation.

An aside of historical interest: I started getting sucked down the FIPS
140-2 rabbit hole nearly two decades ago, when I had just such a vendor letter in hand. But, that vendor kept shipping software that clearly did
*not* use FIPS validated cryptography (I could get it to use non-allowed algorithms). After I complained repeatedly that vendor finally confessed "our product version that uses the FIPS crypto is very old, you don't want that". Well yes I did (i.e. my client did) and insisted on getting the righteous product. So the vendor ended up sending us a hand-labeled CD :-(.

The moral of that story is that you should get the vendor letter (or in the OpenSSL FIPS module case do the section 5.5 documentation thing) and move on; I didn't and was condemned to an eternity of tilting at the FIPS 140-2 windmill...

-Steve M.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From marquess at openssl.com  Tue Mar 15 22:54:23 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 15 Mar 2016 18:54:23 -0400
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <BL2PR07MB2404733E46065F0FE413B52AD7890@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E862CA.9050605@openssl.com>
 <BL2PR07MB2404733E46065F0FE413B52AD7890@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <56E8929F.6050301@openssl.com>

On 03/15/2016 05:24 PM, Satya Das wrote:
> Hello Steve,
> 
> Even if a vendor letter is good for CMVP, how is the vendor supposed
> to know ?

Ummm, because the vendor is the one who created the validated module.
Only that vendor can know for sure how the module was created, because
the FIPS 140-2 requirements have non-technical procedural elements
(think of those as ideological or spiritual elements).

Note that in this context "vendor" refers to the entity that created the
validated module and submitted it for FIPS 140-2 validation. The company
that uses the FIPS module in their product is a "user", not a "vendor",
with respect to the validated module.

> I would say openssl should give such a tool so that vendor and the
> testing Lab can know such things. It is more than critical that the
> applications link to the intended crypto module. This convoluted and
> complex object module linking etc. with 207 page user guide is
> specific to openssl's approach to FIPS, and therefore should be
> addressed by the project. It should not come down to some vendor
> document written in good faith.

But it necessarily always comes down to a vendor document, for *any*
validated module, not just the OpenSSL FIPS module. I've tried and
failed now several times to articulate why that is so and can't think of
any new way to present it, but it is simply not possible to do what you
want; there is no such thing as a magical pixie dust detector. We cannot
make one; no one can.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From marquess at openssl.com  Tue Mar 15 23:05:34 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 15 Mar 2016 19:05:34 -0400
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <CAJe-LUj2wYBcyBfPbFuztuoMqSZ=j+1RPNfuBybGynFqvgyfbw@mail.gmail.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <CAJe-LUj2wYBcyBfPbFuztuoMqSZ=j+1RPNfuBybGynFqvgyfbw@mail.gmail.com>
Message-ID: <56E8953E.30100@openssl.com>

On 03/15/2016 04:58 PM, Mike Mohr wrote:
> During the linking process, parts of fipscanister.o are removed
> (discarded) by the linker. Also, jumps and call instructions have their
> operands changed (addresses are filled in or relocation information is
> added) and the machine code is fundamentally altered.
> 
> Imagine the linking process as something analogous to baking a cheese
> quiche with tomatoes. The can of tomatoes you use (i.e., the
> fipscanister.o file) is opened. The metal can is discarded along with
> any liquid inside the can. Then the tomatoes are placed into the quiche
> and baked. Melting cheese seeps into the tomatoes and the tomatoes are
> physically deformed and soften. At the end you have a delicious quiche.
> Can you get the original can of tomatoes back, in its unmodified form,
> at this point? Can you identify exactly which can of tomatoes was used
> to make this quiche, given only photos of all the cans prior to opening
> them?

To a rough first approximation this is true for object code, but the
story is a little more nuanced for the OpenSSL FIPS Object Module. We
create that in a way (the "monolithic" object module) that prevents the
application link process from scrambling what would otherwise have been
an assortment of object modules (in the software engineering sense, not
FIPS-speak).

The premain (native compilation) process, the "incore" utilities
(cross-compilation), and the run-time POST integrity test all calculate
exactly the same digest over exactly the same bits (in our case, the
TEXT and RODATA segments). If the application link process rearranged
any of that TEXT or RODATA then the runtime integrity test would fail.

So very technically speaking the FIPS module is not fipscanister.o, but
the TEXT and RODATA data within it.

To use your analogy, the fipscanister.o "can" contains only one tomato
which is an indigestible and indivisible blob that appears intact in the
baked quiche. Bon App?tit.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From jeremy.farrell at oracle.com  Tue Mar 15 23:37:21 2016
From: jeremy.farrell at oracle.com (Jeremy Farrell)
Date: Tue, 15 Mar 2016 23:37:21 +0000
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <BL2PR07MB2404733E46065F0FE413B52AD7890@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E862CA.9050605@openssl.com>
 <BL2PR07MB2404733E46065F0FE413B52AD7890@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <56E89CB1.90700@oracle.com>

On 15/03/2016 21:24, Satya Das wrote:
> Even if a vendor letter is good for CMVP, how is the vendor supposed to know ?

By remembering whether or not he followed the required procedure; it's 
the only way for him to know.

> I would say openssl should give such a tool so that vendor and the testing Lab can know such things. It is more than critical that the applications link to the intended crypto module.

You miss the point. It is no more or less critical that 'the application 
link to the intended crypto module' than countless other things. Many of 
the other things cannot be checked by running a tool. How would a tool 
check that the vendor had executed 'make' at the appropriate stage as 
opposed to (say) '/usr/bin/make'? How would a tool check that the vendor 
had got the original tar file from the OSF CD rather than by downloading it?

> This convoluted and complex object module linking etc. with 207 page user guide is specific to openssl's approach to FIPS, and therefore should be addressed by the project. It should not come down to some vendor document written in good faith.

How can it come down to anything else? What other possible means are 
there for a customer to know that an OpenSSL-based product is FIPS 140-2 
validated?

-- 
J. J. Farrell
Not speaking for Oracle.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/9378caa8/attachment.html>

From satya at attivonetworks.com  Wed Mar 16 00:38:39 2016
From: satya at attivonetworks.com (Satya Das)
Date: Wed, 16 Mar 2016 00:38:39 +0000
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <56E8929F.6050301@openssl.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E862CA.9050605@openssl.com>
 <BL2PR07MB2404733E46065F0FE413B52AD7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E8929F.6050301@openssl.com>
Message-ID: <BL2PR07MB24047327C36CFFEA5BC19BEED78A0@BL2PR07MB2404.namprd07.prod.outlook.com>

Steve,

How does one get a hold of the embedded signature in libcrypto.so ? 

Thanks

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess
Sent: Tuesday, March 15, 2016 3:54 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

On 03/15/2016 05:24 PM, Satya Das wrote:
> Hello Steve,
> 
> Even if a vendor letter is good for CMVP, how is the vendor supposed 
> to know ?

Ummm, because the vendor is the one who created the validated module.
Only that vendor can know for sure how the module was created, because the FIPS 140-2 requirements have non-technical procedural elements (think of those as ideological or spiritual elements).

Note that in this context "vendor" refers to the entity that created the validated module and submitted it for FIPS 140-2 validation. The company that uses the FIPS module in their product is a "user", not a "vendor", with respect to the validated module.

> I would say openssl should give such a tool so that vendor and the 
> testing Lab can know such things. It is more than critical that the 
> applications link to the intended crypto module. This convoluted and 
> complex object module linking etc. with 207 page user guide is 
> specific to openssl's approach to FIPS, and therefore should be 
> addressed by the project. It should not come down to some vendor 
> document written in good faith.

But it necessarily always comes down to a vendor document, for *any* validated module, not just the OpenSSL FIPS module. I've tried and failed now several times to articulate why that is so and can't think of any new way to present it, but it is simply not possible to do what you want; there is no such thing as a magical pixie dust detector. We cannot make one; no one can.

-Steve M.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From akihana at gmail.com  Wed Mar 16 03:48:36 2016
From: akihana at gmail.com (Mike Mohr)
Date: Tue, 15 Mar 2016 20:48:36 -0700
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <BL2PR07MB24047327C36CFFEA5BC19BEED78A0@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E862CA.9050605@openssl.com>
 <BL2PR07MB2404733E46065F0FE413B52AD7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E8929F.6050301@openssl.com>
 <BL2PR07MB24047327C36CFFEA5BC19BEED78A0@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <CAJe-LUgN7ucT4St_L=ok_HHEDPYP+jqcVRiV3vLVS=buwUSSNg@mail.gmail.com>

There isn't necessarily any embedded signature in a shared object.  In many
cases, there won't be one.  If your shared object was built with a new
enough version of GCC, hasn't been fully stripped, and its note section has
not been removed during the build process, you can get a SHA-1 checksum
from the binary like this:
michael at osiris:~$ readelf -n /usr/lib/x86_64-linux-gnu/libcrypto.so

Displaying notes found at file offset 0x000001c8 with length 0x00000024:
  Owner                 Data size Description
  GNU                  0x00000014 NT_GNU_BUILD_ID (unique build ID
bitstring)
    Build ID: 1e5fca06588d1d7c0f8f4b16c82611e6be697fb2

The GNU linker generates this value, but for the details of how it is
calculated you'd probably have to refer to the gcc source code.  Depending
on what is being hashed, you may or may not be able to re-calculate that
value at a later time.

Caveat emptor: the build id was likely not designed to prove that the
executable code is unmodified.  Its stated goal is to identify repeatable
builds on the same host with the same tools.

"As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance."

Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6,
page 163). Carbondale, IL: Southern Illinois University Press.

On Tue, Mar 15, 2016 at 5:38 PM, Satya Das <satya at attivonetworks.com> wrote:

> Steve,
>
> How does one get a hold of the embedded signature in libcrypto.so ?
>
> Thanks
>
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Steve Marquess
> Sent: Tuesday, March 15, 2016 3:54 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
>
> On 03/15/2016 05:24 PM, Satya Das wrote:
> > Hello Steve,
> >
> > Even if a vendor letter is good for CMVP, how is the vendor supposed
> > to know ?
>
> Ummm, because the vendor is the one who created the validated module.
> Only that vendor can know for sure how the module was created, because the
> FIPS 140-2 requirements have non-technical procedural elements (think of
> those as ideological or spiritual elements).
>
> Note that in this context "vendor" refers to the entity that created the
> validated module and submitted it for FIPS 140-2 validation. The company
> that uses the FIPS module in their product is a "user", not a "vendor",
> with respect to the validated module.
>
> > I would say openssl should give such a tool so that vendor and the
> > testing Lab can know such things. It is more than critical that the
> > applications link to the intended crypto module. This convoluted and
> > complex object module linking etc. with 207 page user guide is
> > specific to openssl's approach to FIPS, and therefore should be
> > addressed by the project. It should not come down to some vendor
> > document written in good faith.
>
> But it necessarily always comes down to a vendor document, for *any*
> validated module, not just the OpenSSL FIPS module. I've tried and failed
> now several times to articulate why that is so and can't think of any new
> way to present it, but it is simply not possible to do what you want; there
> is no such thing as a magical pixie dust detector. We cannot make one; no
> one can.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/1f301ce5/attachment-0001.html>

From rajesh_seetharam at thbs.com  Wed Mar 16 03:53:52 2016
From: rajesh_seetharam at thbs.com (rajesh_seetharam at thbs.com)
Date: Wed, 16 Mar 2016 09:23:52 +0530 (IST)
Subject: [openssl-users] openssl-users Digest, Vol 16, Issue 26
In-Reply-To: <mailman.7497.1458100121.1747.openssl-users@openssl.org>
References: <mailman.7497.1458100121.1747.openssl-users@openssl.org>
Message-ID: <1458100432.81045479@webmail.thbs.com>

I want to unsubscribe, please tell me how to go about it

my mailbox is flooded with your openssl mails

-----Original Message-----
From: openssl-users-request at openssl.org
Sent: Wednesday, March 16, 2016 9:18am
To: openssl-users at openssl.org
Subject: openssl-users Digest, Vol 16, Issue 26

Send openssl-users mailing list submissions to
	openssl-users at openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
	openssl-users-request at openssl.org

You can reach the person managing the list at
	openssl-users-owner at openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Verifying the sha1 of fipscanister.o with what is
      embedded in libcrypto.so (Steve Marquess)
   2. Re: Verifying the sha1 of fipscanister.o with what is
      embedded in libcrypto.so (Jeremy Farrell)
   3. Re: Verifying the sha1 of fipscanister.o with what is
      embedded in libcrypto.so (Satya Das)
   4. Re: Verifying the sha1 of fipscanister.o with what is
      embedded in libcrypto.so (Mike Mohr)


----------------------------------------------------------------------

Message: 1
Date: Tue, 15 Mar 2016 19:05:34 -0400
From: Steve Marquess <marquess at openssl.com>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
	what is embedded in libcrypto.so
Message-ID: <56E8953E.30100 at openssl.com>
Content-Type: text/plain; charset=windows-1252

On 03/15/2016 04:58 PM, Mike Mohr wrote:
> During the linking process, parts of fipscanister.o are removed
> (discarded) by the linker. Also, jumps and call instructions have their
> operands changed (addresses are filled in or relocation information is
> added) and the machine code is fundamentally altered.
> 
> Imagine the linking process as something analogous to baking a cheese
> quiche with tomatoes. The can of tomatoes you use (i.e., the
> fipscanister.o file) is opened. The metal can is discarded along with
> any liquid inside the can. Then the tomatoes are placed into the quiche
> and baked. Melting cheese seeps into the tomatoes and the tomatoes are
> physically deformed and soften. At the end you have a delicious quiche.
> Can you get the original can of tomatoes back, in its unmodified form,
> at this point? Can you identify exactly which can of tomatoes was used
> to make this quiche, given only photos of all the cans prior to opening
> them?

To a rough first approximation this is true for object code, but the
story is a little more nuanced for the OpenSSL FIPS Object Module. We
create that in a way (the "monolithic" object module) that prevents the
application link process from scrambling what would otherwise have been
an assortment of object modules (in the software engineering sense, not
FIPS-speak).

The premain (native compilation) process, the "incore" utilities
(cross-compilation), and the run-time POST integrity test all calculate
exactly the same digest over exactly the same bits (in our case, the
TEXT and RODATA segments). If the application link process rearranged
any of that TEXT or RODATA then the runtime integrity test would fail.

So very technically speaking the FIPS module is not fipscanister.o, but
the TEXT and RODATA data within it.

To use your analogy, the fipscanister.o "can" contains only one tomato
which is an indigestible and indivisible blob that appears intact in the
baked quiche. Bon App?tit..

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc


------------------------------

Message: 2
Date: Tue, 15 Mar 2016 23:37:21 +0000
From: Jeremy Farrell <jeremy.farrell at oracle.com>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
	what is embedded in libcrypto.so
Message-ID: <56E89CB1.90700 at oracle.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

On 15/03/2016 21:24, Satya Das wrote:
> Even if a vendor letter is good for CMVP, how is the vendor supposed to know ?

By remembering whether or not he followed the required procedure; it's 
the only way for him to know.

> I would say openssl should give such a tool so that vendor and the testing Lab can know such things. It is more than critical that the applications link to the intended crypto module.

You miss the point. It is no more or less critical that 'the application 
link to the intended crypto module' than countless other things. Many of 
the other things cannot be checked by running a tool. How would a tool 
check that the vendor had executed 'make' at the appropriate stage as 
opposed to (say) '/usr/bin/make'? How would a tool check that the vendor 
had got the original tar file from the OSF CD rather than by downloading it?

> This convoluted and complex object module linking etc. with 207 page user guide is specific to openssl's approach to FIPS, and therefore should be addressed by the project. It should not come down to some vendor document written in good faith.

How can it come down to anything else? What other possible means are 
there for a customer to know that an OpenSSL-based product is FIPS 140-2 
validated?

-- 
J. J. Farrell
Not speaking for Oracle.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/9378caa8/attachment-0001.html>

------------------------------

Message: 3
Date: Wed, 16 Mar 2016 00:38:39 +0000
From: Satya Das <satya at attivonetworks.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
	what is embedded in libcrypto.so
Message-ID:
	<BL2PR07MB24047327C36CFFEA5BC19BEED78A0 at BL2PR07MB2404.namprd07.prod.outlook.com>
	
Content-Type: text/plain; charset="us-ascii"

Steve,

How does one get a hold of the embedded signature in libcrypto.so ? 

Thanks

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess
Sent: Tuesday, March 15, 2016 3:54 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so

On 03/15/2016 05:24 PM, Satya Das wrote:
> Hello Steve,
> 
> Even if a vendor letter is good for CMVP, how is the vendor supposed 
> to know ?

Ummm, because the vendor is the one who created the validated module.
Only that vendor can know for sure how the module was created, because the FIPS 140-2 requirements have non-technical procedural elements (think of those as ideological or spiritual elements).

Note that in this context "vendor" refers to the entity that created the validated module and submitted it for FIPS 140-2 validation. The company that uses the FIPS module in their product is a "user", not a "vendor", with respect to the validated module.

> I would say openssl should give such a tool so that vendor and the 
> testing Lab can know such things. It is more than critical that the 
> applications link to the intended crypto module. This convoluted and 
> complex object module linking etc. with 207 page user guide is 
> specific to openssl's approach to FIPS, and therefore should be 
> addressed by the project. It should not come down to some vendor 
> document written in good faith.

But it necessarily always comes down to a vendor document, for *any* validated module, not just the OpenSSL FIPS module.. I've tried and failed now several times to articulate why that is so and can't think of any new way to present it, but it is simply not possible to do what you want; there is no such thing as a magical pixie dust detector. We cannot make one; no one can.

-Steve M.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

Message: 4
Date: Tue, 15 Mar 2016 20:48:36 -0700
From: Mike Mohr <akihana at gmail.com>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
	what is embedded in libcrypto.so
Message-ID:
	<CAJe-LUgN7ucT4St_L=ok_HHEDPYP+jqcVRiV3vLVS=buwUSSNg at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

There isn't necessarily any embedded signature in a shared object.  In many
cases, there won't be one.  If your shared object was built with a new
enough version of GCC, hasn't been fully stripped, and its note section has
not been removed during the build process, you can get a SHA-1 checksum
from the binary like this:
michael at osiris:~$ readelf -n /usr/lib/x86_64-linux-gnu/libcrypto.so

Displaying notes found at file offset 0x000001c8 with length 0x00000024:
  Owner                 Data size Description
  GNU                  0x00000014 NT_GNU_BUILD_ID (unique build ID
bitstring)
    Build ID: 1e5fca06588d1d7c0f8f4b16c82611e6be697fb2

The GNU linker generates this value, but for the details of how it is
calculated you'd probably have to refer to the gcc source code.  Depending
on what is being hashed, you may or may not be able to re-calculate that
value at a later time.

Caveat emptor: the build id was likely not designed to prove that the
executable code is unmodified.  Its stated goal is to identify repeatable
builds on the same host with the same tools.

"As long as politics is the shadow cast on society by big business, the
attenuation of the shadow will not change the substance."

Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6,
page 163). Carbondale, IL: Southern Illinois University Press.

On Tue, Mar 15, 2016 at 5:38 PM, Satya Das <satya at attivonetworks.com> wrote:

> Steve,
>
> How does one get a hold of the embedded signature in libcrypto.so ?
>
> Thanks
>
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Steve Marquess
> Sent: Tuesday, March 15, 2016 3:54 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
> what is embedded in libcrypto.so
>
> On 03/15/2016 05:24 PM, Satya Das wrote:
> > Hello Steve,
> >
> > Even if a vendor letter is good for CMVP, how is the vendor supposed
> > to know ?
>
> Ummm, because the vendor is the one who created the validated module.
> Only that vendor can know for sure how the module was created, because the
> FIPS 140-2 requirements have non-technical procedural elements (think of
> those as ideological or spiritual elements).
>
> Note that in this context "vendor" refers to the entity that created the
> validated module and submitted it for FIPS 140-2 validation. The company
> that uses the FIPS module in their product is a "user", not a "vendor",
> with respect to the validated module.
>
> > I would say openssl should give such a tool so that vendor and the
> > testing Lab can know such things. It is more than critical that the
> > applications link to the intended crypto module. This convoluted and
> > complex object module linking etc. with 207 page user guide is
> > specific to openssl's approach to FIPS, and therefore should be
> > addressed by the project. It should not come down to some vendor
> > document written in good faith.
>
> But it necessarily always comes down to a vendor document, for *any*
> validated module, not just the OpenSSL FIPS module. I've tried and failed
> now several times to articulate why that is so and can't think of any new
> way to present it, but it is simply not possible to do what you want; there
> is no such thing as a magical pixie dust detector. We cannot make one; no
> one can.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/1f301ce5/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
openssl-users at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 16, Issue 26
*********************************************



******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail.  The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address********



******* DISCLAIMER: This email and any files transmitted with it are privileged and confidential information and intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, please notify the sender by e-mail and delete the original message. Further, you are not to copy, disclose, or distribute this e-mail or its contents to any other person and any such actions are unlawful. This e-mail may contain viruses. Torry Harris Business Solutions has taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain as a result of any virus in this e-mail.  The recipient should check this email and any attachments for the presence of viruses. THBS reserves the right to monitor and review the content of all messages sent to or from this e-mail address.********



From noloader at gmail.com  Wed Mar 16 04:31:44 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 16 Mar 2016 00:31:44 -0400
Subject: [openssl-users] openssl-users Digest, Vol 16, Issue 26
In-Reply-To: <1458100432.81045479@webmail.thbs.com>
References: <mailman.7497.1458100121.1747.openssl-users@openssl.org>
 <1458100432.81045479@webmail.thbs.com>
Message-ID: <CAH8yC8kFFOZvBV4taHXU+58v_RaLOYEgeShobd9U_atCit1tYA@mail.gmail.com>

> my mailbox is flooded with your openssl mails

Yeah, those unexpected result can occur when you subscribe to a mailing list.

> I want to unsubscribe, please tell me how to go about it

Check at the bottom of each message where it says:

   openssl-users mailing list
   To unsubscribe: ...

Or, for the general instructions,
http://lmgtfy.com/?q=how+to+unsubscribe+from+a+mailing+list

On Tue, Mar 15, 2016 at 11:53 PM,  <rajesh_seetharam at thbs.com> wrote:
> I want to unsubscribe, please tell me how to go about it
>
> my mailbox is flooded with your openssl mails
>
> -----Original Message-----
> From: openssl-users-request at openssl.org
> Sent: Wednesday, March 16, 2016 9:18am
> To: openssl-users at openssl.org
> Subject: openssl-users Digest, Vol 16, Issue 26
>
> Send openssl-users mailing list submissions to
>         openssl-users at openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
>         openssl-users-request at openssl.org
>
> You can reach the person managing the list at
>         openssl-users-owner at openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Verifying the sha1 of fipscanister.o with what is
>       embedded in libcrypto.so (Steve Marquess)
>    2. Re: Verifying the sha1 of fipscanister.o with what is
>       embedded in libcrypto.so (Jeremy Farrell)
>    3. Re: Verifying the sha1 of fipscanister.o with what is
>       embedded in libcrypto.so (Satya Das)
>    4. Re: Verifying the sha1 of fipscanister.o with what is
>       embedded in libcrypto.so (Mike Mohr)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Mar 2016 19:05:34 -0400
> From: Steve Marquess <marquess at openssl.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
>         what is embedded in libcrypto.so
> Message-ID: <56E8953E.30100 at openssl.com>
> Content-Type: text/plain; charset=windows-1252
>
> On 03/15/2016 04:58 PM, Mike Mohr wrote:
>> During the linking process, parts of fipscanister.o are removed
>> (discarded) by the linker. Also, jumps and call instructions have their
>> operands changed (addresses are filled in or relocation information is
>> added) and the machine code is fundamentally altered.
>>
>> Imagine the linking process as something analogous to baking a cheese
>> quiche with tomatoes. The can of tomatoes you use (i.e., the
>> fipscanister.o file) is opened. The metal can is discarded along with
>> any liquid inside the can. Then the tomatoes are placed into the quiche
>> and baked. Melting cheese seeps into the tomatoes and the tomatoes are
>> physically deformed and soften. At the end you have a delicious quiche.
>> Can you get the original can of tomatoes back, in its unmodified form,
>> at this point? Can you identify exactly which can of tomatoes was used
>> to make this quiche, given only photos of all the cans prior to opening
>> them?
>
> To a rough first approximation this is true for object code, but the
> story is a little more nuanced for the OpenSSL FIPS Object Module. We
> create that in a way (the "monolithic" object module) that prevents the
> application link process from scrambling what would otherwise have been
> an assortment of object modules (in the software engineering sense, not
> FIPS-speak).
>
> The premain (native compilation) process, the "incore" utilities
> (cross-compilation), and the run-time POST integrity test all calculate
> exactly the same digest over exactly the same bits (in our case, the
> TEXT and RODATA segments). If the application link process rearranged
> any of that TEXT or RODATA then the runtime integrity test would fail.
>
> So very technically speaking the FIPS module is not fipscanister.o, but
> the TEXT and RODATA data within it.
>
> To use your analogy, the fipscanister.o "can" contains only one tomato
> which is an indigestible and indivisible blob that appears intact in the
> baked quiche. Bon App?tit..
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Mar 2016 23:37:21 +0000
> From: Jeremy Farrell <jeremy.farrell at oracle.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
>         what is embedded in libcrypto.so
> Message-ID: <56E89CB1.90700 at oracle.com>
> Content-Type: text/plain; charset="windows-1252"; Format="flowed"
>
> On 15/03/2016 21:24, Satya Das wrote:
>> Even if a vendor letter is good for CMVP, how is the vendor supposed to know ?
>
> By remembering whether or not he followed the required procedure; it's
> the only way for him to know.
>
>> I would say openssl should give such a tool so that vendor and the testing Lab can know such things. It is more than critical that the applications link to the intended crypto module.
>
> You miss the point. It is no more or less critical that 'the application
> link to the intended crypto module' than countless other things. Many of
> the other things cannot be checked by running a tool. How would a tool
> check that the vendor had executed 'make' at the appropriate stage as
> opposed to (say) '/usr/bin/make'? How would a tool check that the vendor
> had got the original tar file from the OSF CD rather than by downloading it?
>
>> This convoluted and complex object module linking etc. with 207 page user guide is specific to openssl's approach to FIPS, and therefore should be addressed by the project. It should not come down to some vendor document written in good faith.
>
> How can it come down to anything else? What other possible means are
> there for a customer to know that an OpenSSL-based product is FIPS 140-2
> validated?
>
> --
> J. J. Farrell
> Not speaking for Oracle.
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/9378caa8/attachment-0001.html>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 16 Mar 2016 00:38:39 +0000
> From: Satya Das <satya at attivonetworks.com>
> To: "openssl-users at openssl.org" <openssl-users at openssl.org>
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
>         what is embedded in libcrypto.so
> Message-ID:
>         <BL2PR07MB24047327C36CFFEA5BC19BEED78A0 at BL2PR07MB2404.namprd07.prod.outlook.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Steve,
>
> How does one get a hold of the embedded signature in libcrypto.so ?
>
> Thanks
>
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess
> Sent: Tuesday, March 15, 2016 3:54 PM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with what is embedded in libcrypto.so
>
> On 03/15/2016 05:24 PM, Satya Das wrote:
>> Hello Steve,
>>
>> Even if a vendor letter is good for CMVP, how is the vendor supposed
>> to know ?
>
> Ummm, because the vendor is the one who created the validated module.
> Only that vendor can know for sure how the module was created, because the FIPS 140-2 requirements have non-technical procedural elements (think of those as ideological or spiritual elements).
>
> Note that in this context "vendor" refers to the entity that created the validated module and submitted it for FIPS 140-2 validation. The company that uses the FIPS module in their product is a "user", not a "vendor", with respect to the validated module.
>
>> I would say openssl should give such a tool so that vendor and the
>> testing Lab can know such things. It is more than critical that the
>> applications link to the intended crypto module. This convoluted and
>> complex object module linking etc. with 207 page user guide is
>> specific to openssl's approach to FIPS, and therefore should be
>> addressed by the project. It should not come down to some vendor
>> document written in good faith.
>
> But it necessarily always comes down to a vendor document, for *any* validated module, not just the OpenSSL FIPS module.. I've tried and failed now several times to articulate why that is so and can't think of any new way to present it, but it is simply not possible to do what you want; there is no such thing as a magical pixie dust detector. We cannot make one; no one can.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 15 Mar 2016 20:48:36 -0700
> From: Mike Mohr <akihana at gmail.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
>         what is embedded in libcrypto.so
> Message-ID:
>         <CAJe-LUgN7ucT4St_L=ok_HHEDPYP+jqcVRiV3vLVS=buwUSSNg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> There isn't necessarily any embedded signature in a shared object.  In many
> cases, there won't be one.  If your shared object was built with a new
> enough version of GCC, hasn't been fully stripped, and its note section has
> not been removed during the build process, you can get a SHA-1 checksum
> from the binary like this:
> michael at osiris:~$ readelf -n /usr/lib/x86_64-linux-gnu/libcrypto.so
>
> Displaying notes found at file offset 0x000001c8 with length 0x00000024:
>   Owner                 Data size Description
>   GNU                  0x00000014 NT_GNU_BUILD_ID (unique build ID
> bitstring)
>     Build ID: 1e5fca06588d1d7c0f8f4b16c82611e6be697fb2
>
> The GNU linker generates this value, but for the details of how it is
> calculated you'd probably have to refer to the gcc source code.  Depending
> on what is being hashed, you may or may not be able to re-calculate that
> value at a later time.
>
> Caveat emptor: the build id was likely not designed to prove that the
> executable code is unmodified.  Its stated goal is to identify repeatable
> builds on the same host with the same tools.
>
> "As long as politics is the shadow cast on society by big business, the
> attenuation of the shadow will not change the substance."
>
> Dewey, J. (2008). *The later works of John Dewey, 1925 - 1953* (Volume 6,
> page 163). Carbondale, IL: Southern Illinois University Press.
>
> On Tue, Mar 15, 2016 at 5:38 PM, Satya Das <satya at attivonetworks.com> wrote:
>
>> Steve,
>>
>> How does one get a hold of the embedded signature in libcrypto.so ?
>>
>> Thanks
>>
>> -----Original Message-----
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Steve Marquess
>> Sent: Tuesday, March 15, 2016 3:54 PM
>> To: openssl-users at openssl.org
>> Subject: Re: [openssl-users] Verifying the sha1 of fipscanister.o with
>> what is embedded in libcrypto.so
>>
>> On 03/15/2016 05:24 PM, Satya Das wrote:
>> > Hello Steve,
>> >
>> > Even if a vendor letter is good for CMVP, how is the vendor supposed
>> > to know ?
>>
>> Ummm, because the vendor is the one who created the validated module.
>> Only that vendor can know for sure how the module was created, because the
>> FIPS 140-2 requirements have non-technical procedural elements (think of
>> those as ideological or spiritual elements).
>>
>> Note that in this context "vendor" refers to the entity that created the
>> validated module and submitted it for FIPS 140-2 validation. The company
>> that uses the FIPS module in their product is a "user", not a "vendor",
>> with respect to the validated module.
>>
>> > I would say openssl should give such a tool so that vendor and the
>> > testing Lab can know such things. It is more than critical that the
>> > applications link to the intended crypto module. This convoluted and
>> > complex object module linking etc. with 207 page user guide is
>> > specific to openssl's approach to FIPS, and therefore should be
>> > addressed by the project. It should not come down to some vendor
>> > document written in good faith.
>>
>> But it necessarily always comes down to a vendor document, for *any*
>> validated module, not just the OpenSSL FIPS module. I've tried and failed
>> now several times to articulate why that is so and can't think of any new
>> way to present it, but it is simply not possible to do what you want; there
>> is no such thing as a magical pixie dust detector. We cannot make one; no
>> one can.
>>
>> -Steve M.
>>
>> --
>> Steve Marquess
>> OpenSSL Validation Services, Inc.
>> 1829 Mount Ephraim Road
>> Adamstown, MD  21710
>> USA
>> +1 877 673 6775 s/b
>> +1 301 874 2571 direct
>> marquess at openssl.com
>> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160315/1f301ce5/attachment.html>
>

From marquess at openssl.com  Wed Mar 16 11:39:01 2016
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 16 Mar 2016 07:39:01 -0400
Subject: [openssl-users] Verifying the sha1 of fipscanister.o with what
 is embedded in libcrypto.so
In-Reply-To: <BL2PR07MB24047327C36CFFEA5BC19BEED78A0@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24041B781CE047AA0FE83088D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E807E1.7040303@openssl.com>
 <BL2PR07MB24041D0AEE7233B04ED3A9F1D7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E862CA.9050605@openssl.com>
 <BL2PR07MB2404733E46065F0FE413B52AD7890@BL2PR07MB2404.namprd07.prod.outlook.com>
 <56E8929F.6050301@openssl.com>
 <BL2PR07MB24047327C36CFFEA5BC19BEED78A0@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <56E945D5.9080805@openssl.com>

On 03/15/2016 08:38 PM, Satya Das wrote:
> Steve,
> 
> How does one get a hold of the embedded signature in libcrypto.so ? 

I assume you're referring to the known-good FIPS 140-2 integrity check
digest that is used for the runtime integrity check in the POST.

Several people have already tried to explain that finding that digest
DOES NOT repeat NOT prove that the application runtime binary is using a
FIPS 140-2 validated module. The digest was inserted when the
application was (correctly) linked to the FIPS module, and I've already
told you a way it could be located, but having such a tool gains you
nothing.

The magical pixie dust that distinguishes a validated module from a
bit-for-bit identical non-validated module is undetectable by any kind
of software, thus it is impossible -- even blue-sky theoretically -- to
develop a technical tool or utility of any kind that will suffice as
proof a product is using a validated cryptographic module. It is even
less possible than the "secure backdoor" in FBI/DoJ fantasies.

-Steve M.

-- 
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From lists at rustichelli.net  Wed Mar 16 17:54:15 2016
From: lists at rustichelli.net (lists)
Date: Wed, 16 Mar 2016 18:54:15 +0100
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <7815d0d4-15f9-963e-ffd9-c0b065d412f4@gmail.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
 <56E6D79A.6070109@rustichelli.net>
 <7815d0d4-15f9-963e-ffd9-c0b065d412f4@gmail.com>
Message-ID: <56E99DC7.8050101@rustichelli.net>

On 03/14/2016 04:26 PM, PGNet Dev wrote:
>
>>> Must use it,
>>>
>>>     (1) https://wiki.openssl.org/index.php/Compilation_and_Installation
>>>         Dependencies
>>>
>>>         If you are prompted to run make depend, then you must do so.
>
> Which I currently attempt to do, but get the reported errors about not 
> finding the stddef.h include etc.
>
>> I cannot see exactly what is that you find confusing.
>
> That the wiki says you don't need to,
>
> "Compilation
>
>  After configuring the library, you should run make. If prompted, 
> there's usually no need to make depend since you are building from a 
> clean download."
>
IMHO the Wiki is wrong, also the phrase is not crystal clear to me: "If 
prompted" meaning? "Even if prompted to do so" or "If _not_ prompted"?
Anyway, the header-file-not-found issue is a bug, of course, apart from 
the necessity of running "make depend" or not. I doubt that without 
running "make depend" you'd do better.


From openssl at openssl.org  Wed Mar 16 17:50:15 2016
From: openssl at openssl.org (OpenSSL)
Date: Wed, 16 Mar 2016 17:50:15 +0000
Subject: [openssl-users] OpenSSL version 1.1.0 pre release 4 published
Message-ID: <20160316175015.GA18842@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


   OpenSSL version 1.1.0 pre release 4 (beta)
   ===========================================

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

   OpenSSL 1.1.0 is currently in beta. OpenSSL 1.1.0 pre release 4 has now
   been made available. For details of changes and known issues see the
   release notes at:

        http://www.openssl.org/news/openssl-1.1.0-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release 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:

    o openssl-1.1.0-pre4.tar.gz
      Size: 5325012
      SHA1 checksum: 58119f6c784055a50622afc75b5b817eeae2a365
      SHA256 checksum: a2fe0bd293cdedde193ff0377cab75cbd042a9c20c11622d6b350890855a0a69

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0-pre4.tar.gz
    openssl sha256 openssl-1.1.0-pre4.tar.gz

   Please download and check this beta release as soon as possible.
   Bug reports should go to rt at openssl.org. Please check the release
   notes and mailing lists to avoid duplicate reports of known issues.

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJW6ZYnAAoJENXp5D99+e6MLLEP/jqfZLP8ziXZ/LwOCvtIwe7x
aCyYmRff8lsNfFbgb6IWFoUqA5oEwq2nAUSeJ5FWX4hhsIdvLrBskT5o47cDo+fA
8CQBXYfEcEq9Qvdezw20242TPpCpBDFBFh7L972yVElbvwGgsV0OaiJ5oGss7u1A
ZWXhrnpiYBr04Ovx5CtN5QedtV4U5ZEhQOumKpM+BgWD3lt2AlYGRrc9f3DytdQ/
cIVW5p2NlixQkKp2qqcsa5tXMtPoPz1IwJi3BpBR5ViBWCqzlSWAUqxuHL8t0piH
AQZr1dN+ABiSoM9B7wa1PHUZWNlUlK4aF8t6o4sg0deaaHOZbi/skitKgPhbuYtW
Zs4/et2SA7lctNODKPjwYL80KVCrvx+Hk3rUf6tLWhcCyfcAIIR0Bg8o86nD9SNU
fJ5fEoe6HpADWdF/RcoWVsWkLJbqq33VouXYuOlOrQTJ+11bxVyraMdwoC0NmnBm
4PdHkjVcfH3t1GwKp02aRw33VL/xa6x6gTT3OtTkVhwXXF0q5nDtxbUf421lVPvo
ZMB2UHnhnaNZhDO9X6m2ZBkizzjLMooqeMuAIiAXdwQZ4+Tee/Gcrf4wMP34pa6j
FvDqEBTa19BC6joLhC+mmfHgmQTTQWg7GiZ0a9VAjmnom9CxUNBzYVAdL4SYrk4z
jf78Hj1qn1w+4dVLo/o1
=O2sR
-----END PGP SIGNATURE-----

From jb-openssl at wisemo.com  Wed Mar 16 18:04:57 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 16 Mar 2016 19:04:57 +0100
Subject: [openssl-users] OpenSSL version 1.1.0 pre release 4 published
In-Reply-To: <20160316175015.GA18842@openssl.org>
References: <20160316175015.GA18842@openssl.org>
Message-ID: <56E9A049.6040500@wisemo.com>

Any particular reasone why the links in these announcements
are http links and not https links?

On 16/03/2016 18:50, OpenSSL wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>     OpenSSL version 1.1.0 pre release 4 (beta)
>     ===========================================
>
>     OpenSSL - The Open Source toolkit for SSL/TLS
>     http://www.openssl.org/
>
>     OpenSSL 1.1.0 is currently in beta. OpenSSL 1.1.0 pre release 4 has now
>     been made available. For details of changes and known issues see the
>     release notes at:
>
>          http://www.openssl.org/news/openssl-1.1.0-notes.html
>
>     Note: This OpenSSL pre-release has been provided for testing ONLY.
>     It should NOT be used for security critical purposes.
>
>     The beta release 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:
>
>      o openssl-1.1.0-pre4.tar.gz
>        Size: 5325012
>        SHA1 checksum: 58119f6c784055a50622afc75b5b817eeae2a365
>        SHA256 checksum: a2fe0bd293cdedde193ff0377cab75cbd042a9c20c11622d6b350890855a0a69
>
>     The checksums were calculated using the following commands:
>
>      openssl sha1 openssl-1.1.0-pre4.tar.gz
>      openssl sha256 openssl-1.1.0-pre4.tar.gz
>
>     Please download and check this beta release as soon as possible.
>     Bug reports should go to rt at openssl.org. Please check the release
>     notes and mailing lists to avoid duplicate reports of known issues.
>
>     Yours,
>
>     The OpenSSL Project Team.
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJW6ZYnAAoJENXp5D99+e6MLLEP/jqfZLP8ziXZ/LwOCvtIwe7x
> aCyYmRff8lsNfFbgb6IWFoUqA5oEwq2nAUSeJ5FWX4hhsIdvLrBskT5o47cDo+fA
> 8CQBXYfEcEq9Qvdezw20242TPpCpBDFBFh7L972yVElbvwGgsV0OaiJ5oGss7u1A
> ZWXhrnpiYBr04Ovx5CtN5QedtV4U5ZEhQOumKpM+BgWD3lt2AlYGRrc9f3DytdQ/
> cIVW5p2NlixQkKp2qqcsa5tXMtPoPz1IwJi3BpBR5ViBWCqzlSWAUqxuHL8t0piH
> AQZr1dN+ABiSoM9B7wa1PHUZWNlUlK4aF8t6o4sg0deaaHOZbi/skitKgPhbuYtW
> Zs4/et2SA7lctNODKPjwYL80KVCrvx+Hk3rUf6tLWhcCyfcAIIR0Bg8o86nD9SNU
> fJ5fEoe6HpADWdF/RcoWVsWkLJbqq33VouXYuOlOrQTJ+11bxVyraMdwoC0NmnBm
> 4PdHkjVcfH3t1GwKp02aRw33VL/xa6x6gTT3OtTkVhwXXF0q5nDtxbUf421lVPvo
> ZMB2UHnhnaNZhDO9X6m2ZBkizzjLMooqeMuAIiAXdwQZ4+Tee/Gcrf4wMP34pa6j
> FvDqEBTa19BC6joLhC+mmfHgmQTTQWg7GiZ0a9VAjmnom9CxUNBzYVAdL4SYrk4z
> jf78Hj1qn1w+4dVLo/o1
> =O2sR
> -----END PGP SIGNATURE-----


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From krzysztof.modras at gmail.com  Wed Mar 16 21:37:35 2016
From: krzysztof.modras at gmail.com (Krzysztof Modras)
Date: Wed, 16 Mar 2016 22:37:35 +0100
Subject: [openssl-users] 0.9.8 - 1.0.0 DER format breaking change
Message-ID: <CAEhBw01Y6aNx-bOMAZ2C8+zyM56xXvYb6ALn8Sh_KP8d7eVouQ@mail.gmail.com>

Hello,

I'm new to the group, so please excuse me if I'm describing my issue
incorrectly.

I've originally posted this github issue:
https://github.com/openssl/openssl/issues/883

As it may not exactly be a openssl problem (both old and new behaviour meet
the specification?), I will try to reformulate the report.

Is there a way to ensure the order of certificates in output of `openssl
smime -sign`?

I know that order from certfile will be maintained, but what about signer
certificated? Two possible options are to put it before or after CA chain.

Thank for all support,
-- 
Krzysztof Modras
E-mail: krzysztof.modras at gmail.com
Mob (PL): +48 733970700
Twitter: @chrmod <https://twitter.com/#%21/chrmod>
Skype: krzysztof.modras

Please consider your environmental responsibility before printing this
e-mail.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160316/90114eb2/attachment.html>

From noloader at gmail.com  Wed Mar 16 21:52:08 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 16 Mar 2016 17:52:08 -0400
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
Message-ID: <CAH8yC8=jhDQxso8c6ME6wATgi8RO_XvB3ZiYRRPytRFFJed8uQ@mail.gmail.com>

> After
>
>         ./configure ...
>
> I'm prompted
>
>         Since you've disabled or enabled at least one algorithm, you need to
> do
>         the following before building:
>
>                 make depend
>
> Exec'ing the 'make depend' stage returns lots of warnings,
>
> ....

I'm not sure what's going on here. A lot has changed recently, and
something could have been knocked loose.

> Reading wiki & reports at openssl, there's confusing, if not conflicting,
> advice.
>

OK, so the issue here is... Painting with a broad brush, there are
three OpenSSL distros - 1.0.1, 1.0.2 and 1.1.0 (and even 0.9.8). There
are also two build systems - the classic one from 1.0.1/1.0.2 (and
even 0.9.8) and the new unified one from 1.1.0.

Our task is to come up with one rule that "just works" everywhere to
teach users. We want "one rule to rule them all" because its easiest
on users. We don't want multiple rules. Its the reason 1.1.0 accepts a
config of "./config no-ssl2 ..." even though SSLv2 has been removed.
Its the rule we've been pounding into people's head's.

The rule I've been following/practicing is the following. I do it
regardless of whether I am prompted or not (because I like one simple
rule to follow):

     make depend && make clean && make

    - 'make depend' gets the dependencies right
    - 'make clean' gets rid of old/dated artifacts (with dependencies
accounted for)
    - 'make' builds under a "good" state (since depend and clean have executed)

************

Regarding this from the wiki:

    After configuring the library, you should run make. If prompted,
    there's usually no need to make depend since you are building
    from a clean download."

We should probably remove that statement and replace it with the one
rule. Sadly, I'm probably the guy who put it there. I'll get that
fixed later today.

************

If I can ask.... as a user, if I say do this _all the time_, then
would it be easiest on you?

    make depend && make clean && make

Or is there something else you would recommend?

************

As far as not configuring because stddef.h, that sounds like a bug.

Jeff

From pgnet.dev at gmail.com  Wed Mar 16 22:06:13 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Wed, 16 Mar 2016 15:06:13 -0700
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <CAH8yC8=jhDQxso8c6ME6wATgi8RO_XvB3ZiYRRPytRFFJed8uQ@mail.gmail.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
 <CAH8yC8=jhDQxso8c6ME6wATgi8RO_XvB3ZiYRRPytRFFJed8uQ@mail.gmail.com>
Message-ID: <4817a185-ce1f-b275-f46d-4c9d90fb10eb@gmail.com>

On 03/16/2016 02:52 PM, Jeffrey Walton wrote:
> If I can ask.... as a user, if I say do this _all the time_, then
> would it be easiest on you?
>
>     make depend && make clean && make
>
> Or is there something else you would recommend?

If it were up to _me_, I'd move to a cmake build system, with clear & 
completely documented params in config files.

Since that's not likely going to happen any time soon, if at all, to 
answer your question ... TBH, I don't really mind one way or the other.

Any working build process is frankly fine with me ... as long as it's 
consistently & thoroughly documented, and, if followed, doesn't generate 
K's of warnings/errors.

> As far as not configuring because stddef.h, that sounds like a bug.

Which sounds like it will/should go away in 1.1.0, as the use of 'make 
depend' is going away?

From jb-openssl at wisemo.com  Wed Mar 16 22:10:33 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 16 Mar 2016 23:10:33 +0100
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <CAH8yC8=jhDQxso8c6ME6wATgi8RO_XvB3ZiYRRPytRFFJed8uQ@mail.gmail.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
 <CAH8yC8=jhDQxso8c6ME6wATgi8RO_XvB3ZiYRRPytRFFJed8uQ@mail.gmail.com>
Message-ID: <56E9D9D9.1020003@wisemo.com>

On 16/03/2016 22:52, Jeffrey Walton wrote:
>> After
>>
>>          ./configure ...
>>
>> I'm prompted
>>
>>          Since you've disabled or enabled at least one algorithm, you need to
>> do
>>          the following before building:
>>
>>                  make depend
>>
>> Exec'ing the 'make depend' stage returns lots of warnings,
>>
>> ....
> I'm not sure what's going on here. A lot has changed recently, and
> something could have been knocked loose.
>
>> Reading wiki & reports at openssl, there's confusing, if not conflicting,
>> advice.
>>
> OK, so the issue here is... Painting with a broad brush, there are
> three OpenSSL distros - 1.0.1, 1.0.2 and 1.1.0 (and even 0.9.8). There
> are also two build systems - the classic one from 1.0.1/1.0.2 (and
> even 0.9.8) and the new unified one from 1.1.0.
>
> Our task is to come up with one rule that "just works" everywhere to
> teach users. We want "one rule to rule them all" because its easiest
> on users. We don't want multiple rules. Its the reason 1.1.0 accepts a
> config of "./config no-ssl2 ..." even though SSLv2 has been removed.
> Its the rule we've been pounding into people's head's.
Wait, are you saying that OpenSSL 1.1.0 no longer implements
all the known SSL/TLS versions (some of which are disabled by
default because of security)?

That would mean it is no longer a full featured TLS and SSL
toolkit?

> The rule I've been following/practicing is the following. I do it
> regardless of whether I am prompted or not (because I like one simple
> rule to follow):
>
>       make depend && make clean && make
>
>      - 'make depend' gets the dependencies right
>      - 'make clean' gets rid of old/dated artifacts (with dependencies
> accounted for)
>      - 'make' builds under a "good" state (since depend and clean have executed)
>
> ************
>
> Regarding this from the wiki:
>
>      After configuring the library, you should run make. If prompted,
>      there's usually no need to make depend since you are building
>      from a clean download."
>
> We should probably remove that statement and replace it with the one
> rule. Sadly, I'm probably the guy who put it there. I'll get that
> fixed later today.
>
> ************
>
> If I can ask.... as a user, if I say do this _all the time_, then
> would it be easiest on you?
>
>      make depend && make clean && make
>
> Or is there something else you would recommend?
>
> ************
>
> As far as not configuring because stddef.h, that sounds like a bug.
>
> Jeff


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160316/2d088885/attachment.html>

From michel.sales at free.fr  Wed Mar 16 22:32:28 2016
From: michel.sales at free.fr (Michel)
Date: Wed, 16 Mar 2016 23:32:28 +0100
Subject: [openssl-users] About no-ssl2
Message-ID: <003d01d17fd3$b8f0f080$2ad2d180$@sales@free.fr>

Hi,

 

IMHO, whether SSL2 is completly removed or disabled, I would have expected
opensslconf.h to reflect the situation to applications.

But now, it just contains : 

#ifndef OPENSSL_NO_SSL3

# define OPENSSL_NO_SSL3

#endif

 

Was it really intended ?

 

Regards,

 

Michel.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160316/5838fcb6/attachment.html>

From openssl-users at dukhovni.org  Wed Mar 16 22:39:55 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 16 Mar 2016 22:39:55 +0000
Subject: [openssl-users] About no-ssl2
In-Reply-To: <003d01d17fd3$b8f0f080$2ad2d180$@sales@free.fr>
References: <003d01d17fd3$b8f0f080$2ad2d180$@sales@free.fr>
Message-ID: <20160316223954.GP6602@mournblade.imrryr.org>

On Wed, Mar 16, 2016 at 11:32:28PM +0100, Michel wrote:

> IMHO, whether SSL2 is completly removed or disabled, I would have expected
> opensslconf.h to reflect the situation to applications.

In what release?

> But now, it just contains : 
> 
> #ifndef OPENSSL_NO_SSL3
> 
> # define OPENSSL_NO_SSL3
> 
> #endif
> 
> Was it really intended ?

OpenSSL 1.1.0 has no vestigial SSLv2 code, and so nothing to disable
with OPENSSL_NO_SSL2.  The "OPENSSL_NO_..." macros specify disabled
features, not deleted code.

-- 
	Viktor.

From openssl-users at dukhovni.org  Wed Mar 16 22:52:34 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 16 Mar 2016 22:52:34 +0000
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <56E9D9D9.1020003@wisemo.com>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
 <CAH8yC8=jhDQxso8c6ME6wATgi8RO_XvB3ZiYRRPytRFFJed8uQ@mail.gmail.com>
 <56E9D9D9.1020003@wisemo.com>
Message-ID: <20160316225234.GR6602@mournblade.imrryr.org>

On Wed, Mar 16, 2016 at 11:10:33PM +0100, Jakob Bohm wrote:

> Wait, are you saying that OpenSSL 1.1.0 no longer implements
> all the known SSL/TLS versions (some of which are disabled by
> default because of security)?
> 
> That would mean it is no longer a full featured TLS and SSL
> toolkit?

Well, SSLv2 is no longer a feature.  While OpenSSL 1.1.0 not
bug-compatible with some earlier releases it is fully-featured.

-- 
	Viktor.

From richmoore44 at gmail.com  Wed Mar 16 22:52:39 2016
From: richmoore44 at gmail.com (Richard Moore)
Date: Wed, 16 Mar 2016 22:52:39 +0000
Subject: [openssl-users] About no-ssl2
In-Reply-To: <20160316223954.GP6602@mournblade.imrryr.org>
References: <20160316223954.GP6602@mournblade.imrryr.org>
Message-ID: <CAMp7mVu1i8SyOr9PQTtyPeA3oF_8_9qFBVZcTTkyQX06Ct8APQ@mail.gmail.com>

On 16 March 2016 at 22:39, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Wed, Mar 16, 2016 at 11:32:28PM +0100, Michel wrote:
> OpenSSL 1.1.0 has no vestigial SSLv2 code, and so nothing to disable
> with OPENSSL_NO_SSL2.  The "OPENSSL_NO_..." macros specify disabled
> features, not deleted code.
>

?That's the major flaw of the current design of flagging when features are
disabled rather than when they're present. I'm sure you'll get plenty more
reports like this.

Rich.
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160316/07bd5553/attachment.html>

From openssl-users at dukhovni.org  Wed Mar 16 22:58:56 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 16 Mar 2016 22:58:56 +0000
Subject: [openssl-users] About no-ssl2
In-Reply-To: <CAMp7mVu1i8SyOr9PQTtyPeA3oF_8_9qFBVZcTTkyQX06Ct8APQ@mail.gmail.com>
References: <20160316223954.GP6602@mournblade.imrryr.org>
 <CAMp7mVu1i8SyOr9PQTtyPeA3oF_8_9qFBVZcTTkyQX06Ct8APQ@mail.gmail.com>
Message-ID: <20160316225856.GS6602@mournblade.imrryr.org>

On Wed, Mar 16, 2016 at 10:52:39PM +0000, Richard Moore wrote:

> On 16 March 2016 at 22:39, Viktor Dukhovni <openssl-users at dukhovni.org>
> wrote:
> 
> > On Wed, Mar 16, 2016 at 11:32:28PM +0100, Michel wrote:
> > OpenSSL 1.1.0 has no vestigial SSLv2 code, and so nothing to disable
> > with OPENSSL_NO_SSL2.  The "OPENSSL_NO_..." macros specify disabled
> > features, not deleted code.
> >
> 
> ?That's the major flaw of the current design of flagging when features are
> disabled rather than when they're present. I'm sure you'll get plenty more
> reports like this.

Use feature probing via autoconf, or just:

    #if OPENSSL_VERSION_NUMBER < 0x10100000L && !defined(OPENSSL_NO_SSL2)
    /* SSLv2 available */
    #else
    /* SSLv2 not available */
    #endif

Better yet, drop support for SSLv2, and then you don't care whether OpenSSL
provides it or not.

-- 
	Viktor.

From steve at openssl.org  Wed Mar 16 23:03:22 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 16 Mar 2016 23:03:22 +0000
Subject: [openssl-users] 0.9.8 - 1.0.0 DER format breaking change
In-Reply-To: <CAEhBw01Y6aNx-bOMAZ2C8+zyM56xXvYb6ALn8Sh_KP8d7eVouQ@mail.gmail.com>
References: <CAEhBw01Y6aNx-bOMAZ2C8+zyM56xXvYb6ALn8Sh_KP8d7eVouQ@mail.gmail.com>
Message-ID: <20160316230322.GA24844@openssl.org>

On Wed, Mar 16, 2016, Krzysztof Modras wrote:

> Hello,
> 
> I'm new to the group, so please excuse me if I'm describing my issue
> incorrectly.
> 
> I've originally posted this github issue:
> https://github.com/openssl/openssl/issues/883
> 
> As it may not exactly be a openssl problem (both old and new behaviour meet
> the specification?), I will try to reformulate the report.
> 
> Is there a way to ensure the order of certificates in output of `openssl
> smime -sign`?
> 
> I know that order from certfile will be maintained, but what about signer
> certificated? Two possible options are to put it before or after CA chain.
> 

As has been mentioned the order shouldn't matter but there is a way to manage
this using the smime utility or the cms utility in some versions of OpenSSL.

If you use the option -nocerts the signing certificate will not be
automatically added to the output. You can then include the signing
certificate in the -certfile option in whatever position you want. This
functionality was added to some versions of OpenSSL to workaround this
problem where some implementations depend on the order.

Whether this works in practice for the smime utility will depend on the
version of OpenSSL: some versions interpret -nocerts to exclude all
certificates so you get none at all in the output. For 1.0.2 and master
you should be fine. 

If you use the cms utility instead of smime it should work in any version of
OpenSSL.

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

From michel.sales at free.fr  Wed Mar 16 23:05:52 2016
From: michel.sales at free.fr (Michel)
Date: Thu, 17 Mar 2016 00:05:52 +0100
Subject: [openssl-users] About no-ssl2
In-Reply-To: <20160316223954.GP6602@mournblade.imrryr.org>
References: <003d01d17fd3$b8f0f080$2ad2d180$@sales@free.fr>
 <20160316223954.GP6602@mournblade.imrryr.org>
Message-ID: <005401d17fd8$638fb180$2aaf1480$@sales@free.fr>



-----Message d'origine-----
De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Viktor Dukhovni
Envoy??: mercredi 16 mars 2016 23:40
??: openssl-users at openssl.org
Objet?: Re: [openssl-users] About no-ssl2

...

> In what release?

Sorry, I forgot to mention : current release 1.1.0 (pre 4)

> The "OPENSSL_NO_..." macros specify disabled features, not deleted code.

Yes I understand this point, but I was thinking it was also used more
generally to inform about [un]available functionalities.

Anyway,

Thanks for your answer Viktor.

Michel.


From richmoore44 at gmail.com  Wed Mar 16 23:21:10 2016
From: richmoore44 at gmail.com (Richard Moore)
Date: Wed, 16 Mar 2016 23:21:10 +0000
Subject: [openssl-users] About no-ssl2
In-Reply-To: <20160316225856.GS6602@mournblade.imrryr.org>
References: <20160316223954.GP6602@mournblade.imrryr.org>
 <CAMp7mVu1i8SyOr9PQTtyPeA3oF_8_9qFBVZcTTkyQX06Ct8APQ@mail.gmail.com>
 <20160316225856.GS6602@mournblade.imrryr.org>
Message-ID: <CAMp7mVskR+=xPPeCPB5XeQVg5hdNM2c6Q6X4LR-JDwGgpov2ng@mail.gmail.com>

On 16 March 2016 at 22:58, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Wed, Mar 16, 2016 at 10:52:39PM +0000, Richard Moore wrote:
>
> > On 16 March 2016 at 22:39, Viktor Dukhovni <openssl-users at dukhovni.org>
> > wrote:
> >
> > > On Wed, Mar 16, 2016 at 11:32:28PM +0100, Michel wrote:
> > > OpenSSL 1.1.0 has no vestigial SSLv2 code, and so nothing to disable
> > > with OPENSSL_NO_SSL2.  The "OPENSSL_NO_..." macros specify disabled
> > > features, not deleted code.
> > >
> >
> > ?That's the major flaw of the current design of flagging when features
> are
> > disabled rather than when they're present. I'm sure you'll get plenty
> more
> > reports like this.
>
> Use feature probing via autoconf, or just:
>
>     #if OPENSSL_VERSION_NUMBER < 0x10100000L && !defined(OPENSSL_NO_SSL2)
>     /* SSLv2 available */
>     #else
>     /* SSLv2 not available */
>     #endif
>
> Better yet, drop support for SSLv2, and then you don't care whether OpenSSL
> provides it or not.
>
>
?SSL2 is simply an example of this issue, the same applies to others eg. it
will no doubt occur in future for NPN since ALPN has replaced it. ?

?The problem is the concept itself since it will require every app to have
coded into it when a given feature was removed should it attempt to support
it when present.

Rich.?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160316/5dbfdb07/attachment.html>

From rsalz at akamai.com  Thu Mar 17 00:41:48 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Mar 2016 00:41:48 +0000
Subject: [openssl-users] 'makedepend' in openssl builds: clarify need
 and correct usage
In-Reply-To: <20160316225234.GR6602@mournblade.imrryr.org>
References: <0d1196ed-8bcb-9fa3-8834-abce07e0a042@gmail.com>
 <CAH8yC8=jhDQxso8c6ME6wATgi8RO_XvB3ZiYRRPytRFFJed8uQ@mail.gmail.com>
 <56E9D9D9.1020003@wisemo.com> <20160316225234.GR6602@mournblade.imrryr.org>
Message-ID: <fb7775a2df1748dfa24adcfd231e5706@usma1ex-dag1mb1.msg.corp.akamai.com>


> > Wait, are you saying that OpenSSL 1.1.0 no longer implements all the
> > known SSL/TLS versions (some of which are disabled by default because
> > of security)?
> >
> > That would mean it is no longer a full featured TLS and SSL toolkit?

SSlv2 is a bug, not a feature :)

Perhaps less flippantly, OpenSSL 1.0.2 is a long-term supported release and fully supports SSLv2 if configured to do so.

So OpenSSL can still claim to be a full-featured TLS and SSL toolkit with a straight face.

From rsalz at akamai.com  Thu Mar 17 00:41:47 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Mar 2016 00:41:47 +0000
Subject: [openssl-users] About no-ssl2
In-Reply-To: <CAMp7mVskR+=xPPeCPB5XeQVg5hdNM2c6Q6X4LR-JDwGgpov2ng@mail.gmail.com>
References: <20160316223954.GP6602@mournblade.imrryr.org>
 <CAMp7mVu1i8SyOr9PQTtyPeA3oF_8_9qFBVZcTTkyQX06Ct8APQ@mail.gmail.com>
 <20160316225856.GS6602@mournblade.imrryr.org>
 <CAMp7mVskR+=xPPeCPB5XeQVg5hdNM2c6Q6X4LR-JDwGgpov2ng@mail.gmail.com>
Message-ID: <b89b1d8f86b0419ca51e398d5e704933@usma1ex-dag1mb1.msg.corp.akamai.com>

>?The problem is the concept itself since it will require every app to have coded into it when a given feature was removed should it attempt to support it when present.

Yes.

It dates back to the very early days (when SSLeay was developed on clay tablets), when the default was "get it all" and specific define's were used to turn off small specific things.

In the 20 years since then, the world has moved to "safe by default" which is different.

Oh well.

From rsalz at akamai.com  Thu Mar 17 18:36:08 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Mar 2016 18:36:08 +0000
Subject: [openssl-users] Removing some systems
Message-ID: <8f77f2d4452446c8825cc70057624690@usma1ex-dag1mb1.msg.corp.akamai.com>

We are planning on removing the following systems from OpenSSL 1.1:

Netware

OS/2



There are a few reasons for this.  In no particular order they include: these platforms are no longer supported by the vendor; the configurations and builds have not been testable by the team for years and might not even work; nobody on the team has access to any of these.



As a hopefully mediating factor, please note that they are still part of 1.0.2, which we have said is an LTS release with support until 2019.



People interested in supporting any of these systems should look at building their own configuration with the template system; post on the openssl-dev list for help.  Reducing the footprint and tangle of #ifdef's is also very important.



We are also looking at others that are in a similar (although perhaps not identical) reason and will post here about them.

--
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at<mailto:richsalz at jabber.at> Twitter: RichSalz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160317/a1191c71/attachment.html>

From Ian_Jones at cable.comcast.com  Thu Mar 17 19:30:48 2016
From: Ian_Jones at cable.comcast.com (Jones, Ian)
Date: Thu, 17 Mar 2016 19:30:48 +0000
Subject: [openssl-users] Help with CRL stuff
Message-ID: <D31053F9.4BDA%ian_jones@cable.comcast.com>

Hey guys!  I have a quick question that I can't seem to find the answer to anywhere: I know how to add a "fullname" CRL distribution point extension, but how does one add nameRelativeToCRLIssuer?  The RFC says that it's a 'choice' element in x509 CRL extensions, but when I try to replace "fullname" with "nameRelativeToCRLIssuer" in my extfile.cnf, the distribution point is generated without any URL included.

Thank you in advance for any help you can provide, if you are able!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160317/07a25db4/attachment-0001.html>

From jeremy.farrell at oracle.com  Thu Mar 17 19:55:13 2016
From: jeremy.farrell at oracle.com (Jeremy Farrell)
Date: Thu, 17 Mar 2016 19:55:13 +0000
Subject: [openssl-users] [openssl-dev] openssl 1.0.1p
 PEM_write_bio_RSAPrivateKey fail. error: ASN1_get_object:too long
In-Reply-To: <CADjKrEXzK1NEVjNEDG9Q7fu2Yty2HBFOyc52VG7ahLeACN0Eqw@mail.gmail.com>
References: <CADjKrEXzK1NEVjNEDG9Q7fu2Yty2HBFOyc52VG7ahLeACN0Eqw@mail.gmail.com>
Message-ID: <56EB0BA1.1030901@oracle.com>

On 17/03/2016 06:32, Ranjith Kumar A. wrote:
> > Need help.
This is a question about using the OpenSSL libraries, further discussion 
should be on openssl-users; I've set 'reply-to' appropriately, but I 
don't know what the mailing list will do with it.

> I?m not able to encrypt a key using passphrase, below is the error  > message. > > **"error:0D07209B:asn1 encoding 
routines:ASN1_get_object:too long"** > > Have already googled for error 
but couldn't got much info > > unsigned char pass[] = "123456"; > > BIO 
*priv_bio = BIO_new( BIO_s_mem() ); > > RSA *rsa = RSA_generate_key( 
2048, 65537, NULL, NULL ) ret = > PEM_write_bio_RSAPrivateKey( priv_bio, 
rsa, EVP_aes_256_cbc(), pass, 64, NULL, NULL );
I don't know if or how it's related to your problem, but you have 
defined a 7 byte array as the passphrase then told the function to use 
64 bytes at that location. There's no saying what values the other 57 
bytes of the passphrase will have, assuming they're accessible at all.

> ...  > The same piece of code is working on openssl-0.9.8zg.
More luck than good judgement I suspect.

> ...
-- 
J. J. Farrell
Not speaking for Oracle.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160317/a788dce2/attachment.html>

From uri at ll.mit.edu  Thu Mar 17 21:17:39 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 17 Mar 2016 21:17:39 +0000
Subject: [openssl-users] Naive: how to generate EC public key from EC
	private key?
Message-ID: <D310972F.28F06%uri@ll.mit.edu>

I?ve an extremely na?ve question. I am generating ephemeral EC keys for
ECDH, following the example in
https://wiki.openssl.org/index.php/EVP_Key_and_Parameter_Generation

But it looks like the example ends on generation of the private key:
/* Generate the key */
if (!EVP_PKEY_keygen(kctx, &key)) goto err;

The next step must be obvious, but somehow I can?t figure it out. So my
question is: from having EVP_PKEY *privateECKey how do I get EVP_PKEY
*publicECKey?

Thanks!

P.S. The same question applies to RSA as well.
-- 
Regards,
Uri Blumenthal


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160317/4a9b6e5e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160317/4a9b6e5e/attachment.bin>

From openssl-users at dukhovni.org  Thu Mar 17 21:57:03 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 17 Mar 2016 17:57:03 -0400
Subject: [openssl-users] Naive: how to generate EC public key from EC
	private key?
In-Reply-To: <D310972F.28F06%uri@ll.mit.edu>
References: <D310972F.28F06%uri@ll.mit.edu>
Message-ID: <F8441015-D903-4CC6-A4CD-4302B4FD0377@dukhovni.org>


> On Mar 17, 2016, at 5:17 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> 
> I?ve an extremely na?ve question. I am generating ephemeral EC keys for ECDH, following the example in https://wiki.openssl.org/index.php/EVP_Key_and_Parameter_Generation
> 
> But it looks like the example ends on generation of the private key:
> /* Generate the key */
> if (!EVP_PKEY_keygen(kctx, &key)) goto err;
> 
> 
> The next step must be obvious, but somehow I can?t figure it out. So my question is: from having EVP_PKEY *privateECKey how do I get EVP_PKEY *publicECKey?

The public key is always there.  You either have both the public and private keys
or just the public key.  So the same EVP_PKEY object holds both.  What you do
next depends on what you want to do with the public key...

-- 
	Viktor.


From uri at ll.mit.edu  Thu Mar 17 22:09:13 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 17 Mar 2016 22:09:13 +0000
Subject: [openssl-users] Naive: how to generate EC public key from
	EC	private key?
Message-ID: <20160317220921.18296912.51331.58267@ll.mit.edu>

Great! Say, I want to extract the public key and make it available to another entity or module? Possibly DER-encoded, though I'd like to learn how to do both: extract ?ASN.1-encoded and raw (assuming it is possible).?

Thanks!

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Viktor Dukhovni
Sent: Thursday, March 17, 2016 17:57
To: openssl-users at openssl.org
Reply To: openssl-users at openssl.org
Subject: Re: [openssl-users] Naive: how to generate EC public key from EC	private key?


> On Mar 17, 2016, at 5:17 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> 
> I?ve an extremely na?ve question. I am generating ephemeral EC keys for ECDH, following the example in https://wiki.openssl.org/index.php/EVP_Key_and_Parameter_Generation
> 
> But it looks like the example ends on generation of the private key:
> /* Generate the key */
> if (!EVP_PKEY_keygen(kctx, &key)) goto err;
> 
> 
> The next step must be obvious, but somehow I can?t figure it out. So my question is: from having EVP_PKEY *privateECKey how do I get EVP_PKEY *publicECKey?

The public key is always there. You either have both the public and private keys
or just the public key. So the same EVP_PKEY object holds both. What you do
next depends on what you want to do with the public key...

-- 
Viktor.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160317/307104b3/attachment-0001.bin>

From uri at ll.mit.edu  Thu Mar 17 22:32:16 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 17 Mar 2016 22:32:16 +0000
Subject: [openssl-users] Naive: how to generate EC public key
	from	EC	private key?
Message-ID: <20160317223224.18296912.57162.58318@ll.mit.edu>

Oh, and I'd much prefer to stay at the EVP level, rather than invoke BIO primitives for this task.

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Blumenthal, Uri - 0553 - MITLL
Sent: Thursday, March 17, 2016 18:09
To: Viktor Dukhovni; openssl-users at openssl.org
Reply To: openssl-users at openssl.org
Subject: Re: [openssl-users] Naive: how to generate EC public key from	EC	private key?

Great! Say, I want to extract the public key and make it available to another entity or module? Possibly DER-encoded, though I'd like to learn how to do both: extract ?ASN.1-encoded and raw (assuming it is possible).?

Thanks!

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Viktor Dukhovni
Sent: Thursday, March 17, 2016 17:57
To: openssl-users at openssl.org
Reply To: openssl-users at openssl.org
Subject: Re: [openssl-users] Naive: how to generate EC public key from EC	private key?


> On Mar 17, 2016, at 5:17 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> 
> I?ve an extremely na?ve question. I am generating ephemeral EC keys for ECDH, following the example in https://wiki.openssl.org/index.php/EVP_Key_and_Parameter_Generation
> 
> But it looks like the example ends on generation of the private key:
> /* Generate the key */
> if (!EVP_PKEY_keygen(kctx, &key)) goto err;
> 
> 
> The next step must be obvious, but somehow I can?t figure it out. So my question is: from having EVP_PKEY *privateECKey how do I get EVP_PKEY *publicECKey?

The public key is always there. You either have both the public and private keys
or just the public key. So the same EVP_PKEY object holds both. What you do
next depends on what you want to do with the public key...

-- 
Viktor.

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160317/ab58e573/attachment.bin>

From openssl-users at dukhovni.org  Thu Mar 17 23:00:34 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 17 Mar 2016 19:00:34 -0400
Subject: [openssl-users] Naive: how to generate EC public key
	from	EC	private key?
In-Reply-To: <20160317223224.18296912.57162.58318@ll.mit.edu>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
Message-ID: <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>


> On Mar 17, 2016, at 6:32 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> 
> Oh, and I'd much prefer to stay at the EVP level, rather than invoke BIO primitives for this task.

Well you can work with http://openssl.org/docs/manmaster/crypto/EC_KEY_key2buf.html
to extract EC public key octets.  If you want an ASN.1 encoded "SPKI" object (i.e. an
X509_PUBKEY in OpenSSL) then you can use

	X509_PUBKEY *pk = NULL;
	unsigned char *buf = NULL;
	EVP_PKEY *key;

	key = ... ; /* Get a keypair */

	if (X509_PUBKEY_set(&pk, key) <= 0) {
		/* error */
	}

	len = i2d_X509_PUBKEY(pk, &buf);
	if (len < 0 || buf == NULL) {
		/* error */
	}
	
	/* buf contains ASN.1-encoded SPKI, use it */

	OPENSSL_free(buf);
	X509_PUBKEY_free(pk);
	EVP_PKEY_free(key); /* If no longer needed */

A shorter version of the above is possible via i2d_PUBKEY() which
handles the creation, encoding and destruction of the intermediate
X509_PUBKEY:

  int i2d_PUBKEY(EVP_PKEY *a, unsigned char **pp)
  {
    X509_PUBKEY *xpk = NULL;
    int ret;
    if (!a)
        return 0;
    if (!X509_PUBKEY_set(&xpk, a))
        return 0;
    ret = i2d_X509_PUBKEY(xpk, pp);
    X509_PUBKEY_free(xpk);
    return ret;
  }


Looks like we need documentation for X509_PUBKEY_set() and friends...
Any volunteers?

X509_PUBKEY_free();
X509_PUBKEY_get();
X509_PUBKEY_get0();
X509_PUBKEY_get0_param();
X509_PUBKEY_new();
X509_PUBKEY_set();
X509_PUBKEY_set0_param();
d2i_DSA_PUBKEY_bio();
d2i_DSA_PUBKEY_fp();
d2i_EC_PUBKEY_bio();
d2i_EC_PUBKEY_fp();
d2i_PUBKEY_bio();
d2i_PUBKEY_fp();
d2i_RSA_PUBKEY_bio();
d2i_RSA_PUBKEY_fp();
i2d_DSA_PUBKEY_bio();
i2d_DSA_PUBKEY_fp();
i2d_EC_PUBKEY_bio();
i2d_EC_PUBKEY_fp();
i2d_PUBKEY_bio();
i2d_PUBKEY_fp();
i2d_RSA_PUBKEY_bio();
i2d_RSA_PUBKEY_fp();

-- 
	Viktor.

From steve at openssl.org  Thu Mar 17 23:45:38 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 17 Mar 2016 23:45:38 +0000
Subject: [openssl-users] Naive: how to generate EC public key
	from	EC	private key?
In-Reply-To: <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
Message-ID: <20160317234538.GA26084@openssl.org>

On Thu, Mar 17, 2016, Viktor Dukhovni wrote:

> 
> > On Mar 17, 2016, at 6:32 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> > 
> > Oh, and I'd much prefer to stay at the EVP level, rather than invoke BIO primitives for this task.
> 
> Well you can work with http://openssl.org/docs/manmaster/crypto/EC_KEY_key2buf.html
> to extract EC public key octets.

That's only available in the master branch, only encodes the key value and not
its parameters and of course it only works for EC.

> If you want an ASN.1 encoded "SPKI" object (i.e. an
> X509_PUBKEY in OpenSSL) then you can use
> 
> 	X509_PUBKEY *pk = NULL;
> 	unsigned char *buf = NULL;
> 	EVP_PKEY *key;
> 
> 	key = ... ; /* Get a keypair */
> 
> 	if (X509_PUBKEY_set(&pk, key) <= 0) {
> 		/* error */
> 	}
> 
> 	len = i2d_X509_PUBKEY(pk, &buf);
> 	if (len < 0 || buf == NULL) {
> 		/* error */
> 	}
> 	
> 	/* buf contains ASN.1-encoded SPKI, use it */
> 
> 	OPENSSL_free(buf);
> 	X509_PUBKEY_free(pk);
> 	EVP_PKEY_free(key); /* If no longer needed */
> 
> A shorter version of the above is possible via i2d_PUBKEY() which
> handles the creation, encoding and destruction of the intermediate
> X509_PUBKEY:
> 
>   int i2d_PUBKEY(EVP_PKEY *a, unsigned char **pp)
>   {
>     X509_PUBKEY *xpk = NULL;
>     int ret;
>     if (!a)
>         return 0;
>     if (!X509_PUBKEY_set(&xpk, a))
>         return 0;
>     ret = i2d_X509_PUBKEY(xpk, pp);
>     X509_PUBKEY_free(xpk);
>     return ret;
>   }
> 
> 

That's the preferred route as it uses the standard SubjectPublicKeyInfo
format and works with any supported public key type.

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

From sharad.tekale at zebra.com  Fri Mar 18 06:14:17 2016
From: sharad.tekale at zebra.com (Tekale, Sharad)
Date: Fri, 18 Mar 2016 06:14:17 +0000
Subject: [openssl-users] [openssl-dev] openssl 1.0.1p
 PEM_write_bio_RSAPrivateKey fail. error: ASN1_get_object:too long
In-Reply-To: <56EB0BA1.1030901@oracle.com>
References: <CADjKrEXzK1NEVjNEDG9Q7fu2Yty2HBFOyc52VG7ahLeACN0Eqw@mail.gmail.com>
 <56EB0BA1.1030901@oracle.com>
Message-ID: <BN1PR03MB17101812F0E529A52C1D5B0EA8C0@BN1PR03MB171.namprd03.prod.outlook.com>

Hi Farrell,


Thanks a lot for your reply.

I've actually used password of 64 characters in my program, for simplicity I've showcased as 6 byte password in below example.

Looks like there is some other issue or some stringent check that is added in 1.0.1p as the same code works fine in 0.9.8zg version.

Can you please give us pointers to debug this issue.

Thanks,
Sharad.


From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Jeremy Farrell
Sent: Friday, March 18, 2016 1:25 AM
To: openssl-users at openssl.org
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] openssl 1.0.1p PEM_write_bio_RSAPrivateKey fail. error: ASN1_get_object:too long

On 17/03/2016 06:32, Ranjith Kumar A. wrote:
>
> Need help.

This is a question about using the OpenSSL libraries, further discussion should be on openssl-users; I've set 'reply-to' appropriately, but I don't know what the mailing list will do with it.

> I'm not able to encrypt a key using passphrase, below is the error
> message.
>
> **"error:0D07209B:asn1 encoding routines:ASN1_get_object:too long"**
>
> Have already googled for error but couldn't got much info
>
> unsigned char pass[] = "123456";
>
> BIO *priv_bio = BIO_new( BIO_s_mem() );
>
> RSA *rsa = RSA_generate_key( 2048, 65537, NULL, NULL ) ret =
> PEM_write_bio_RSAPrivateKey( priv_bio, rsa, EVP_aes_256_cbc(), pass, 64, NULL, NULL );

I don't know if or how it's related to your problem, but you have defined a 7 byte array as the passphrase then told the function to use 64 bytes at that location. There's no saying what values the other 57 bytes of the passphrase will have, assuming they're accessible at all.

> ...
> The same piece of code is working on openssl-0.9.8zg.

More luck than good judgement I suspect.

> ...

--
J. J. Farrell
Not speaking for Oracle.


________________________________
- CONFIDENTIAL-

This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160318/67dabba6/attachment-0001.html>

From openssl-users at dukhovni.org  Fri Mar 18 07:36:13 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 18 Mar 2016 03:36:13 -0400
Subject: [openssl-users] openssl 1.0.1p PEM_write_bio_RSAPrivateKey
	fail. error: ASN1_get_object:too long
In-Reply-To: <BN1PR03MB17101812F0E529A52C1D5B0EA8C0@BN1PR03MB171.namprd03.prod.outlook.com>
References: <CADjKrEXzK1NEVjNEDG9Q7fu2Yty2HBFOyc52VG7ahLeACN0Eqw@mail.gmail.com>
 <56EB0BA1.1030901@oracle.com>
 <BN1PR03MB17101812F0E529A52C1D5B0EA8C0@BN1PR03MB171.namprd03.prod.outlook.com>
Message-ID: <CE9A43D1-3467-4367-A207-3D658CA3CE99@dukhovni.org>


> On Mar 18, 2016, at 2:14 AM, Tekale, Sharad <sharad.tekale at zebra.com> wrote:
> 
> Thanks a lot for your reply.
>  
> I've actually used password of 64 characters in my program, for simplicity I've showcased as 6 byte password in below example.
>  
> Looks like there is some other issue or some stringent check that is added in 1.0.1p as the same code works fine in 0.9.8zg version.
>  
> Can you please give us pointers to debug this issue.

There's not much to debug.  The code fragment you posted works fine with 1.0.1.
You've not posted a complete program, nor how what steps you take to compile it,
or any compiler warnings, ..., so it is difficult to help you.

For comparison, this is what I get: 

$ OSSL=/.../OpenSSL_1_0_1

$ ${OSSL}/bin/openssl version -a
OpenSSL 1.0.1s-dev  xx XXX xxxx
built on: Fri Feb 12 23:23:01 2016
platform: darwin64-x86_64-cc
options:  bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) idea(int) blowfish(idx) 
compiler: cc -I. -I.. -I../include  -fPIC -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/.../OpenSSL_1_0_1/ssl"

$ cc -I${OSSL}/include -L${OSSL}/lib -lssl -lcrypto -o foo foo.c

$ ./foo
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,C87AA39820A10CA005471EA1E17E3CFD

yaoT0FSlhKY77KC1GNlWYN/0Gfk3L9hCl9AKiTqJ1NibvpwuemXYld7OmybHW9ZO
m7lSnApS91GDqsQGXOlhcKD0WgPf+YFbza7/RATxq5A+rs+CohEa7cg8C6eEgdqC
v2f8+AaSl7hdjtNaRFMcxp4ySq6oZPAsmXbbB/4l/AYK/7q//snqOgPbmGp4nLI9
J7gmJvf8igT0LjmC6IIiUgzb2wqHt/U/pFXj+9mm13tNlZtBVKInQMR3wfHqly4p
p2x3UD1xG982rfPvbefU80Zi8l5UnPAgd3jcYVxuZdCmABWqr30Wc/DuiRXzRhJe
LGKEIl+atfjfjH2cnytShkLvSDo/Ml2xKpnP3PQD7OrmCQpPWcFxphPCjHCsIRPz
c3kbx5LE2NArHT7FuOX8e4h422OIuqbxJc2KM8dLKvuoSB6ZWK8kcd1sesMcXu6p
/Q24EBSPCKd/MaRSqo2m41wVTrtnHHJ1R3MxzjtFLLXTWasT0qDbjj+45jyLzJHd
Xt/fhZJaK2mjmDCoLQFXNeaBqj7vN8ts8AI383hTcACeINzvsIirbKzWkH+els4e
ifrrge5mFvn7vvlAycIx73tlkTqI3o0CImXfIXp+necgEYkAAIwrTQxmYBz6jxhh
UcWN3sr1klrGLNakznnu4FWMFzPnE/Hjz1nRdMcXdS1j4k3gM48Zy3zXtBeQIAex
Fb+vpALzV7sk7H6wKpIjMTcNr66Z1WM+Vu3b4pQr/RnBtOjpHUt6uupr0gR6B61F
W7S0pztQXGI0tT4wL6KHa94XvPTNOJwvsPQyRId/I2J9iTMuPxm/xwx5nwL6nVwo
UPcbKbP4S4PWQpkCEL+CG6hLOWV1rkbpC7Rbk8RuB53CBmXJrMBVLpQe5T08OtEr
DXFuWs0Q00Z4y0U6nfjNzpPzevkTJN/ywjxufsri1J9U50zOLseOCauNzkSsEcoK
2kS1FiaxrGKWpCtd1H0klGoIbV2DtFsSMeyqMWfouMbT6dtw2fRZQcypB9nqgVD1
EUmhyPEk1QgRQKmFZ1VyU7gOygJ5RmEwNgy4gGIlXHT+Z7v/lKPyQfFrlqV3qskv
VDsjWp4GplzqIufwU7KHQj1yz3TM5k7BGDUf8DtP3UEioa9k0LdN5byc1Omk8Wgn
mX+sNXiOf5droA6QfAvZky/TCp/bptiEeabIRyyAL0gvQClf78vIrRUlBQ3wMYUF
wNS/XIZVU5szkIqPO7elJEhX149phcln7BvOLVHtUmSo0vzbFuQ+6gmfhAbU6Ozl
cIupo0flQ9Mz5TvE5HTi2Oe0Hg2DeRAYa8KzTYOkaGVnjXJKqVOvjW2fnen9kJOe
X5vjEvHnZIJ1L7z/YhGU4xKF4uSseV0AUgnyLItIa+Vd6iMu/l7Qxuqby+M1dLft
UQhrnJmo98Xr8zrE7Q9++CwH2O+v8/8vDkopLaZrmyktgr6yfbGuQcuT9/tByEVu
D2vbBCZWybwYmbiwS1i+tbl3sg/JvruCUXZ8HTu5JV2NLIPBGf+i4XmF5ZTuXSAU
ba0l8XIAHYGLADvdnDlhew99bvpmU3fUEUHC1PF0C09r9pSkDDHtedmRwxVZCOUp
-----END RSA PRIVATE KEY-----

$ echo $?
0

$ cat foo.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#include <openssl/rsa.h>
#include <openssl/evp.h>
#include <openssl/pem.h>
#include <openssl/bio.h>

int main(int argc, char *argv[])
{   
    char *pass = "abcdef";
    size_t passlen;
    int len;
    int ret;
    RSA *rsa;
    BIO *bio = BIO_new_fp(stdout, BIO_NOCLOSE);
    BIO *priv_bio = BIO_new(BIO_s_mem());
    char buf[4096];

    if (argc > 1)
        pass = argv[1];
    passlen = strlen(pass);

    OpenSSL_add_all_algorithms();
    rsa = RSA_generate_key(2048, 65537, NULL, NULL);
    ret = PEM_write_bio_RSAPrivateKey(priv_bio, rsa, EVP_aes_256_cbc(),
                                      (unsigned char *)pass, (int)passlen,
                                      NULL, NULL);
    while((len = BIO_gets(priv_bio, buf, sizeof(buf))) > 0)
        BIO_write(bio, buf, len);
    BIO_free(priv_bio);
    BIO_free(bio);
    exit(!ret);
}

-- 
	Viktor.

From matt at openssl.org  Fri Mar 18 12:08:12 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 18 Mar 2016 12:08:12 +0000
Subject: [openssl-users] Questions about OCB and Wrap modes
In-Reply-To: <001b01d17eab$a148df70$e3da9e50$@sales@free.fr>
References: <001b01d17eab$a148df70$e3da9e50$@sales@free.fr>
Message-ID: <56EBEFAC.2080803@openssl.org>



On 15/03/16 11:12, Michel wrote:
> Hi,
> 
>  
> 
> As there was some discussion about AEAD, I am still curious to know why
> OCB mode isn't flagged as one of them :
> 
> assert( EVP_CIPHER_flags( EVP_aes_128_ocb() ) &
> EVP_CIPH_FLAG_AEAD_CIPHER );    failed ?
> 
>  
> 
> Can someone please explain this to me ?

Yes. It's a bug! :-)

Now fixed in git.

Matt

From michel.sales at free.fr  Fri Mar 18 13:52:40 2016
From: michel.sales at free.fr (Michel)
Date: Fri, 18 Mar 2016 14:52:40 +0100
Subject: [openssl-users] Questions about OCB and Wrap modes
In-Reply-To: <56EBEFAC.2080803@openssl.org>
References: <001b01d17eab$a148df70$e3da9e50$@sales@free.fr>
 <56EBEFAC.2080803@openssl.org>
Message-ID: <002f01d1811d$70906140$51b123c0$@sales@free.fr>

Thank you again and again Matt, 

Regards,

Michel.

-----Message d'origine-----
De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Matt Caswell
Envoy??: vendredi 18 mars 2016 13:08
??: openssl-users at openssl.org
Objet?: Re: [openssl-users] Questions about OCB and Wrap modes



On 15/03/16 11:12, Michel wrote:
> Hi,
> 
>  
> 
> As there was some discussion about AEAD, I am still curious to know 
> why OCB mode isn't flagged as one of them :
> 
> assert( EVP_CIPHER_flags( EVP_aes_128_ocb() ) &
> EVP_CIPH_FLAG_AEAD_CIPHER );    failed ?
> 
>  
> 
> Can someone please explain this to me ?

Yes. It's a bug! :-)

Now fixed in git.

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


From uri at ll.mit.edu  Fri Mar 18 18:57:38 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 18 Mar 2016 18:57:38 +0000
Subject: [openssl-users] Naive: how to generate EC public key from EC
 private key?
In-Reply-To: <20160317234538.GA26084@openssl.org>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
 <20160317234538.GA26084@openssl.org>
Message-ID: <D311C659.2900E%uri@ll.mit.edu>

First, Stephen and Viktor - thank you!

On 3/17/16, 19:45 , "openssl-users on behalf of Dr. Stephen Henson"
<openssl-users-bounces at openssl.org on behalf of steve at openssl.org> wrote:

>On Thu, Mar 17, 2016, Viktor Dukhovni wrote:
>> 
>>Well you can work with
>>http://openssl.org/docs/manmaster/crypto/EC_KEY_key2buf.html
>> to extract EC public key octets.
>
>That's only available in the master branch, only encodes the key value
>and not
>its parameters and of course it only works for EC.

Got it. I?ll not use it, as it?s too specific.

>>If you want an ASN.1 encoded "SPKI" object (i.e. an
>> X509_PUBKEY in OpenSSL) then you can use...

Yes, that?s PRECISELY what I want, thank you!

>>A shorter version of the above is possible via i2d_PUBKEY() which
>> handles the creation, encoding and destruction of the intermediate
>> X509_PUBKEY: . . .
>That's the preferred route as it uses the standard SubjectPublicKeyInfo
>format and works with any supported public key type.

Thank you!  The main disadvantage of the shorter version is that it does
not provide me with the length of the buffer it created. So for now I?ll
use the longer one - unless I?m missing something very obvious, and
there?s a trivial way to correctly tell the size of the returned buffer.

Along the same line - I am trying to generate ECDH key pair that would be
on the same curve that the keys on my hardware token. The tokens I?m
dealing with can have keys on either P-256 or P-384 curve.

My problem: I seem unable to figure out what curve the token keys belong
to. Here?s how the public key gets loaded:

	pubkey = ENGINE_load_public_key(*e, "id_03", NULL, NULL);
	if (pubkey == NULL) {
		fprintf(stderr, "wrap: failed to retrieve pubkey id_03\n");
		ERR_print_errors_fp(stderr);
		goto end;
	}

	*bitsize = EVP_PKEY_size(pubkey);
	printf("wrap: ECC pubkey size is %1lu\n", *bitsize);


The problem with the above code is that it (apparently) gives me the size
of the EVP_PKEY object, while I mean to ask a different question.

How do I determine what curve the above key is on?

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160318/48fab9f4/attachment.bin>

From uri at ll.mit.edu  Fri Mar 18 18:59:36 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 18 Mar 2016 18:59:36 +0000
Subject: [openssl-users] Naive: how to generate EC public key from EC
 private key?
In-Reply-To: <D311C659.2900E%uri@ll.mit.edu>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
 <20160317234538.GA26084@openssl.org> <D311C659.2900E%uri@ll.mit.edu>
Message-ID: <D311C83C.29011%uri@ll.mit.edu>

Answered my own question: should use EVP_PKEY_bits(pkey) instead.
-- 
Regards,
Uri Blumenthal





On 3/18/16, 14:57 , "openssl-users on behalf of Blumenthal, Uri - 0553 -
MITLL" <openssl-users-bounces at openssl.org on behalf of uri at ll.mit.edu>
wrote:

>First, Stephen and Viktor - thank you!
>
>On 3/17/16, 19:45 , "openssl-users on behalf of Dr. Stephen Henson"
><openssl-users-bounces at openssl.org on behalf of steve at openssl.org> wrote:
>
>>On Thu, Mar 17, 2016, Viktor Dukhovni wrote:
>>> 
>>>Well you can work with
>>>http://openssl.org/docs/manmaster/crypto/EC_KEY_key2buf.html
>>> to extract EC public key octets.
>>
>>That's only available in the master branch, only encodes the key value
>>and not
>>its parameters and of course it only works for EC.
>
>Got it. I?ll not use it, as it?s too specific.
>
>>>If you want an ASN.1 encoded "SPKI" object (i.e. an
>>> X509_PUBKEY in OpenSSL) then you can use...
>
>Yes, that?s PRECISELY what I want, thank you!
>
>>>A shorter version of the above is possible via i2d_PUBKEY() which
>>> handles the creation, encoding and destruction of the intermediate
>>> X509_PUBKEY: . . .
>>That's the preferred route as it uses the standard SubjectPublicKeyInfo
>>format and works with any supported public key type.
>
>Thank you!  The main disadvantage of the shorter version is that it does
>not provide me with the length of the buffer it created. So for now I?ll
>use the longer one - unless I?m missing something very obvious, and
>there?s a trivial way to correctly tell the size of the returned buffer.
>
>Along the same line - I am trying to generate ECDH key pair that would be
>on the same curve that the keys on my hardware token. The tokens I?m
>dealing with can have keys on either P-256 or P-384 curve.
>
>My problem: I seem unable to figure out what curve the token keys belong
>to. Here?s how the public key gets loaded:
>
>	pubkey = ENGINE_load_public_key(*e, "id_03", NULL, NULL);
>	if (pubkey == NULL) {
>		fprintf(stderr, "wrap: failed to retrieve pubkey id_03\n");
>		ERR_print_errors_fp(stderr);
>		goto end;
>	}
>
>	*bitsize = EVP_PKEY_size(pubkey);
>	printf("wrap: ECC pubkey size is %1lu\n", *bitsize);
>
>
>The problem with the above code is that it (apparently) gives me the size
>of the EVP_PKEY object, while I mean to ask a different question.
>
>How do I determine what curve the above key is on?
>
>Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160318/142de8eb/attachment-0001.bin>

From openssl-users at dukhovni.org  Fri Mar 18 20:17:24 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 18 Mar 2016 20:17:24 +0000
Subject: [openssl-users] Naive: how to generate EC public key from EC
 private key?
In-Reply-To: <D311C83C.29011%uri@ll.mit.edu>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
 <20160317234538.GA26084@openssl.org>
 <D311C659.2900E%uri@ll.mit.edu> <D311C83C.29011%uri@ll.mit.edu>
Message-ID: <20160318201724.GW6602@mournblade.imrryr.org>

On Fri, Mar 18, 2016 at 06:59:36PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> Answered my own question: should use EVP_PKEY_bits(pkey) instead.

That's not the right way to determine the curve id.

> >How do I determine what curve the above key is on?

For that you need to determine the EVP_PKEY algorithm type:

	int type = EVP_PKEY_base_id(pkey);

	if (type == EVP_PKEY_EC) {
	    EC_KEY *key = EVP_PKEY_get0_EC_KEY(pkey);
	    EC_GROUP *group = EC_KEY_get0_group(key);

	    /* Use that group to generate more points */
	}

So you don't need code to specifically identify the group, but if
you want to constrain the supported groups:

	switch (EC_GROUP_get_curve_name(group)) {
	case NID_undef:
	default:
	    /* Unknown or not named group */

	case NID_X9_62_prime256v1:
	    /* P-256 */
	    ...

	case NID_secp384r1:
	    /* P-384 */

	    ...
	}

-- 
	Viktor.

From jqian at tibco.com  Fri Mar 18 20:19:14 2016
From: jqian at tibco.com (Jason Qian)
Date: Fri, 18 Mar 2016 16:19:14 -0400
Subject: [openssl-users] help on des_cblock
Message-ID: <CAGxzrjap7WB7emqdr_wwcGcvGQQ2npCkpheS+TyFotawiqEnsA@mail.gmail.com>

I am new on openSSl and run  into a issue need some help.


In our application, the client and server perform a Diffie Hellman Key
exchange and then encrypt the data  The client is written in C++(using
openSSL), and server is in java.

 Most of time, it is running correctly, but occasionally the server(java)
throw a  "Given final block not properly padded" exception.

I added more log on the both side. When the exception happen,  the keys are
offset by one(for the working case, they are the same)


Server -- java  get from getEncoded()

DES Key  size (8)    (1,-83,-113,-74,-77,109,84,88)

Client -- openSSL  get from des_cblock struct

DES Key  size (8)   (-83,-113,-74,-77,109,84,88,8)


Thanks
Jason

Here is the C++ code

void DiffieHellmanCipher::init(const std::string &Y){
    if (Y.length() == 0) {
        return;
    }
    if (m_DH == NULL) {
        return;
    }

    // convert the Y to BIGNUM
    BIGNUM *bnY = NULL;
    // Memory for bnY is allocated in BN_dec2bn call.
    if (!BN_dec2bn(&bnY, Y.c_str())) {
        if (bnY)
            BN_free(bnY);
        printf("Could not convert Diffie-Hellman Y value to BIGNUM");
    }

    // compute the secret key
    int dhSize = DH_size(m_DH);
    unsigned char *secretKey = (unsigned char*) new char[dhSize + 1];
    int secretKeyLen = DH_compute_key(secretKey, bnY, m_DH);
    BN_free(bnY);

    if (secretKeyLen < 8) {
        delete [] secretKey;
        printf("Error computing secret key: key length is too short");
    }

    // convert from raw form to odd parity DES key
    des_cblock desKey;
    memcpy(desKey, secretKey, 8);
    delete [] secretKey;
    DES_set_odd_parity(&desKey);

      //just print out des_cblock
    secretKeyString="(";
    char ch[10]="\0";
    for(int i=0;i<8;i++){
        sprintf(ch,"%d",(char)desKey[i]);
      secretKeyString+=ch;
      if(i != 7){
        secretKeyString+=",";
      }
    }
    secretKeyString+=")";


    int skRet;
    if ((skRet = DES_set_key(&desKey, &m_DESKey)) != 0) {
        delete [] secretKey;
        printf("Error computing secret key: generated key is weak");
    }

    m_bInited = true;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160318/7df334f6/attachment.html>

From scott_n at xypro.com  Fri Mar 18 20:23:37 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Fri, 18 Mar 2016 20:23:37 +0000
Subject: [openssl-users] help on des_cblock
In-Reply-To: <CAGxzrjap7WB7emqdr_wwcGcvGQQ2npCkpheS+TyFotawiqEnsA@mail.gmail.com>
References: <CAGxzrjap7WB7emqdr_wwcGcvGQQ2npCkpheS+TyFotawiqEnsA@mail.gmail.com>
Message-ID: <D358E5B1511A314F8160ADC6F375498734396F1C@XYSVEX01.XYPRO-23.LOCAL>

I suspect the use of std::string and c_str().  Use a std::vector<char> instead.

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jason Qian
Sent: Friday, March 18, 2016 1:19 PM
To: openssl-users at openssl.org
Subject: [openssl-users] help on des_cblock

I am new on openSSl and run  into a issue need some help.


In our application, the client and server perform a Diffie Hellman Key exchange and then encrypt the data  The client is written in C++(using openSSL), and server is in java.

 Most of time, it is running correctly, but occasionally the server(java) throw a  "Given final block not properly padded" exception.

I added more log on the both side. When the exception happen,  the keys are offset by one(for the working case, they are the same)


Server -- java  get from getEncoded()

DES Key  size (8)    (1,-83,-113,-74,-77,109,84,88)

Client -- openSSL  get from des_cblock struct

DES Key  size (8)   (-83,-113,-74,-77,109,84,88,8)

Thanks
Jason

Here is the C++ code

void DiffieHellmanCipher::init(const std::string &Y){
    if (Y.length() == 0) {
        return;
    }
    if (m_DH == NULL) {
        return;
    }

    // convert the Y to BIGNUM
    BIGNUM *bnY = NULL;
    // Memory for bnY is allocated in BN_dec2bn call.
    if (!BN_dec2bn(&bnY, Y.c_str())) {
        if (bnY)
            BN_free(bnY);
        printf("Could not convert Diffie-Hellman Y value to BIGNUM");
    }

    // compute the secret key
    int dhSize = DH_size(m_DH);
    unsigned char *secretKey = (unsigned char*) new char[dhSize + 1];
    int secretKeyLen = DH_compute_key(secretKey, bnY, m_DH);
    BN_free(bnY);

    if (secretKeyLen < 8) {
        delete [] secretKey;
        printf("Error computing secret key: key length is too short");
    }

    // convert from raw form to odd parity DES key
    des_cblock desKey;
    memcpy(desKey, secretKey, 8);
    delete [] secretKey;
    DES_set_odd_parity(&desKey);

      //just print out des_cblock
    secretKeyString="(";
    char ch[10]="\0";
    for(int i=0;i<8;i++){
        sprintf(ch,"%d",(char)desKey[i]);
      secretKeyString+=ch;
      if(i != 7){
        secretKeyString+=",";
      }
    }
    secretKeyString+=")";


    int skRet;
    if ((skRet = DES_set_key(&desKey, &m_DESKey)) != 0) {
        delete [] secretKey;
        printf("Error computing secret key: generated key is weak");
    }

    m_bInited = true;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160318/776a3e96/attachment.html>

From jqian at tibco.com  Fri Mar 18 21:34:01 2016
From: jqian at tibco.com (Jason Qian)
Date: Fri, 18 Mar 2016 17:34:01 -0400
Subject: [openssl-users] help on des_cblock
In-Reply-To: <D358E5B1511A314F8160ADC6F375498734396F1C@XYSVEX01.XYPRO-23.LOCAL>
References: <CAGxzrjap7WB7emqdr_wwcGcvGQQ2npCkpheS+TyFotawiqEnsA@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498734396F1C@XYSVEX01.XYPRO-23.LOCAL>
Message-ID: <CAGxzrjZPh7XbZQwC6x2zD11RYCbx3xcSgm=-UYriq73ezC10bQ@mail.gmail.com>

Thanks,
Jason

On Fri, Mar 18, 2016 at 4:23 PM, Scott Neugroschl <scott_n at xypro.com> wrote:

> I suspect the use of std::string and c_str().  Use a std::vector<char>
> instead.
>
>
>
> *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On
> Behalf Of *Jason Qian
> *Sent:* Friday, March 18, 2016 1:19 PM
> *To:* openssl-users at openssl.org
> *Subject:* [openssl-users] help on des_cblock
>
>
>
> I am new on openSSl and run  into a issue need some help.
>
>
> In our application, the client and server perform a Diffie Hellman Key
> exchange and then encrypt the data  The client is written in C++(using
> openSSL), and server is in java.
>
>  Most of time, it is running correctly, but occasionally the server(java)
> throw a  "Given final block not properly padded" exception.
>
> I added more log on the both side. When the exception happen,  the keys
> are offset by one(for the working case, they are the same)
>
>
> Server -- java  get from getEncoded()
>
> DES Key  size (8)    (1,-83,-113,-74,-77,109,84,88)
>
> Client -- openSSL  get from des_cblock struct
>
> DES Key  size (8)   (-83,-113,-74,-77,109,84,88,8)
>
> Thanks
>
> Jason
>
>
> Here is the C++ code
>
> void DiffieHellmanCipher::init(const std::string &Y){
>     if (Y.length() == 0) {
>         return;
>     }
>     if (m_DH == NULL) {
>         return;
>     }
>
>     // convert the Y to BIGNUM
>     BIGNUM *bnY = NULL;
>     // Memory for bnY is allocated in BN_dec2bn call.
>     if (!BN_dec2bn(&bnY, Y.c_str())) {
>         if (bnY)
>             BN_free(bnY);
>         printf("Could not convert Diffie-Hellman Y value to BIGNUM");
>     }
>
>     // compute the secret key
>     int dhSize = DH_size(m_DH);
>     unsigned char *secretKey = (unsigned char*) new char[dhSize + 1];
>     int secretKeyLen = DH_compute_key(secretKey, bnY, m_DH);
>     BN_free(bnY);
>
>     if (secretKeyLen < 8) {
>         delete [] secretKey;
>         printf("Error computing secret key: key length is too short");
>     }
>
>     // convert from raw form to odd parity DES key
>     des_cblock desKey;
>     memcpy(desKey, secretKey, 8);
>     delete [] secretKey;
>     DES_set_odd_parity(&desKey);
>
>       //just print out des_cblock
>     secretKeyString="(";
>     char ch[10]="\0";
>     for(int i=0;i<8;i++){
>         sprintf(ch,"%d",(char)desKey[i]);
>       secretKeyString+=ch;
>       if(i != 7){
>         secretKeyString+=",";
>       }
>     }
>     secretKeyString+=")";
>
>
>     int skRet;
>     if ((skRet = DES_set_key(&desKey, &m_DESKey)) != 0) {
>         delete [] secretKey;
>         printf("Error computing secret key: generated key is weak");
>     }
>
>     m_bInited = true;
> }
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160318/1c9ed490/attachment-0001.html>

From scott_n at xypro.com  Fri Mar 18 21:59:26 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Fri, 18 Mar 2016 21:59:26 +0000
Subject: [openssl-users] help on des_cblock
In-Reply-To: <CAGxzrjZPh7XbZQwC6x2zD11RYCbx3xcSgm=-UYriq73ezC10bQ@mail.gmail.com>
References: <CAGxzrjap7WB7emqdr_wwcGcvGQQ2npCkpheS+TyFotawiqEnsA@mail.gmail.com>
 <D358E5B1511A314F8160ADC6F375498734396F1C@XYSVEX01.XYPRO-23.LOCAL>
 <CAGxzrjZPh7XbZQwC6x2zD11RYCbx3xcSgm=-UYriq73ezC10bQ@mail.gmail.com>
Message-ID: <D358E5B1511A314F8160ADC6F375498734396F5E@XYSVEX01.XYPRO-23.LOCAL>

My mistake.  I was reading the calls backwards.  The use of c_str() there is fine.  Ignore my previous comment.

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jason Qian
Sent: Friday, March 18, 2016 2:34 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] help on des_cblock

Thanks,
Jason

On Fri, Mar 18, 2016 at 4:23 PM, Scott Neugroschl <scott_n at xypro.com<mailto:scott_n at xypro.com>> wrote:
I suspect the use of std::string and c_str().  Use a std::vector<char> instead.

From: openssl-users [mailto:openssl-users-bounces at openssl.org<mailto:openssl-users-bounces at openssl.org>] On Behalf Of Jason Qian
Sent: Friday, March 18, 2016 1:19 PM
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: [openssl-users] help on des_cblock

I am new on openSSl and run  into a issue need some help.


In our application, the client and server perform a Diffie Hellman Key exchange and then encrypt the data  The client is written in C++(using openSSL), and server is in java.

 Most of time, it is running correctly, but occasionally the server(java) throw a  "Given final block not properly padded" exception.

I added more log on the both side. When the exception happen,  the keys are offset by one(for the working case, they are the same)


Server -- java  get from getEncoded()

DES Key  size (8)    (1,-83,-113,-74,-77,109,84,88)

Client -- openSSL  get from des_cblock struct

DES Key  size (8)   (-83,-113,-74,-77,109,84,88,8)
Thanks
Jason

Here is the C++ code

void DiffieHellmanCipher::init(const std::string &Y){
    if (Y.length() == 0) {
        return;
    }
    if (m_DH == NULL) {
        return;
    }

    // convert the Y to BIGNUM
    BIGNUM *bnY = NULL;
    // Memory for bnY is allocated in BN_dec2bn call.
    if (!BN_dec2bn(&bnY, Y.c_str())) {
        if (bnY)
            BN_free(bnY);
        printf("Could not convert Diffie-Hellman Y value to BIGNUM");
    }

    // compute the secret key
    int dhSize = DH_size(m_DH);
    unsigned char *secretKey = (unsigned char*) new char[dhSize + 1];
    int secretKeyLen = DH_compute_key(secretKey, bnY, m_DH);
    BN_free(bnY);

    if (secretKeyLen < 8) {
        delete [] secretKey;
        printf("Error computing secret key: key length is too short");
    }

    // convert from raw form to odd parity DES key
    des_cblock desKey;
    memcpy(desKey, secretKey, 8);
    delete [] secretKey;
    DES_set_odd_parity(&desKey);

      //just print out des_cblock
    secretKeyString="(";
    char ch[10]="\0";
    for(int i=0;i<8;i++){
        sprintf(ch,"%d",(char)desKey[i]);
      secretKeyString+=ch;
      if(i != 7){
        secretKeyString+=",";
      }
    }
    secretKeyString+=")";


    int skRet;
    if ((skRet = DES_set_key(&desKey, &m_DESKey)) != 0) {
        delete [] secretKey;
        printf("Error computing secret key: generated key is weak");
    }

    m_bInited = true;
}

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160318/e16dfd84/attachment.html>

From steve at openssl.org  Sat Mar 19 01:11:05 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 19 Mar 2016 01:11:05 +0000
Subject: [openssl-users] Naive: how to generate EC public key from EC
 private key?
In-Reply-To: <20160318201724.GW6602@mournblade.imrryr.org>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
 <20160317234538.GA26084@openssl.org>
 <D311C659.2900E%uri@ll.mit.edu> <D311C83C.29011%uri@ll.mit.edu>
 <20160318201724.GW6602@mournblade.imrryr.org>
Message-ID: <20160319011104.GA23202@openssl.org>

On Fri, Mar 18, 2016, Viktor Dukhovni wrote:

> On Fri, Mar 18, 2016 at 06:59:36PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> 
> > Answered my own question: should use EVP_PKEY_bits(pkey) instead.
> 
> That's not the right way to determine the curve id.
> 
> > >How do I determine what curve the above key is on?
> 
> For that you need to determine the EVP_PKEY algorithm type:
> 
> 	int type = EVP_PKEY_base_id(pkey);
> 
> 	if (type == EVP_PKEY_EC) {
> 	    EC_KEY *key = EVP_PKEY_get0_EC_KEY(pkey);
> 	    EC_GROUP *group = EC_KEY_get0_group(key);
> 
> 	    /* Use that group to generate more points */
> 	}
> 
> So you don't need code to specifically identify the group, but if
> you want to constrain the supported groups:
> 
> 	switch (EC_GROUP_get_curve_name(group)) {
> 	case NID_undef:
> 	default:
> 	    /* Unknown or not named group */
> 
> 	case NID_X9_62_prime256v1:
> 	    /* P-256 */
> 	    ...
> 
> 	case NID_secp384r1:
> 	    /* P-384 */
> 
> 	    ...
> 	}
> 

There is another way too. An EVP_PKEY can also be used to contain parameters
and it is permissible to pass a private or public key as a set of parameters.

In outline you call:

 EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new(privkey, NULL);
 EVP_PKEY_keygen_init(pctx);
 EVP_PKEY_keygen(pctx, &newkey);
 EVP_PKEY_CTX_free(pctx);

This works with other algorithms like DSA/DH too so you'll probably want to
check the key is of the correct type first.

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

From noloader at gmail.com  Sat Mar 19 23:06:07 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 19 Mar 2016 19:06:07 -0400
Subject: [openssl-users] How to configure without OPENSSL_die?
Message-ID: <CAH8yC8=Qo4k40Sumv=dWcBs-iG2EKZ4jSYAfF9o0NfxV7pZ2-w@mail.gmail.com>

openssl/crypto.h has the following:

/* die if we have to */
# if OPENSSL_API_COMPAT < 0x10100000L
#  define OpenSSLDie(f,l,a) OPENSSL_die((a),(f),(l))
# endif
void OPENSSL_die(const char *assertion, const char *file, int line);
# define OPENSSL_assert(e) \
    (void)((e) ? 0 : (OPENSSL_die("assertion failed: " #e, OPENSSL_FILE, OPENSS\
L_LINE), 1))

And:

void OPENSSL_die(const char *message, const char *file, int line)
{
    OPENSSL_showfatal("%s:%d: OpenSSL internal error: %s\n",
                      file, line, message);
#if !defined(_WIN32) || defined(__CYGWIN__)
    abort();
#else
    /*
     * Win32 abort() customarily shows a dialog, but we just did that...
     */
# if !defined(_WIN32_WCE)
    raise(SIGABRT);
# endif
    _exit(3);
#endif
}

How do we configure without OPENSSL_die?

From rsalz at akamai.com  Sun Mar 20 00:21:30 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 20 Mar 2016 00:21:30 +0000
Subject: [openssl-users] How to configure without OPENSSL_die?
In-Reply-To: <CAH8yC8=Qo4k40Sumv=dWcBs-iG2EKZ4jSYAfF9o0NfxV7pZ2-w@mail.gmail.com>
References: <CAH8yC8=Qo4k40Sumv=dWcBs-iG2EKZ4jSYAfF9o0NfxV7pZ2-w@mail.gmail.com>
Message-ID: <4fcb2a5cf1f341939a7b65ea9f919b3f@usma1ex-dag1mb1.msg.corp.akamai.com>

> How do we configure without OPENSSL_die?

You can't.  you can replace the function with something that does something better for your needs.  But the times you get there, a catastrophic error has happened and the library cannot proceed.  It would be great to fix those things; start by picking an OPENSSL_assert call and fixing it.

Once possibility to work-around is to do a setjmp() in main and then longjmp in openssl_die.

From msteve at columbus.rr.com  Sun Mar 20 01:06:23 2016
From: msteve at columbus.rr.com (Michael Steve)
Date: Sat, 19 Mar 2016 21:06:23 -0400
Subject: [openssl-users] OpenVMS modifications to build scripts
Message-ID: <91CFB8F10C4F4778AA2D02627637869F@Unimatrix1>

I?m currently working on additions to the openVMS build scripts. My goal is to modify the scripts so that they can easily build (when requested) the libraries in a case sensitive linkage. I have successfully created and tested the SSL libraries built in this fashion with cUrl but with cannibalized build scripts and options files.

I?m looking for resources in the VMS community for review of my plan and work before submitting the changes.

Michael Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160319/1c9c52ea/attachment.html>

From noloader at gmail.com  Sun Mar 20 02:07:00 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 19 Mar 2016 22:07:00 -0400
Subject: [openssl-users] How to get verbose output from 'make test'
Message-ID: <CAH8yC8kwYo9LK96ZqTLvMmD570AJEjWwLFvuajiEaNh8UrBuuA@mail.gmail.com>

Hi Everyone,

I'm working with OpenSSL 1.1.0. I think I'm seeing a hang in:

    ../test/recipes/80-test_ssl.t ............. {5|6}/47

It seems like its timing out, and then the tests march on with:

    ../test/recipes/80-test_ssl.t ............. ok

I tried to get a verbose output with 'make test V=1', but it was a
guess that did not work.

How can I get verbose output from 'make test'?

Thanks in advance.

From ajrpayne at gmail.com  Sun Mar 20 03:15:18 2016
From: ajrpayne at gmail.com (Andrew Payne)
Date: Sat, 19 Mar 2016 20:15:18 -0700
Subject: [openssl-users] Increased memory consumption noticed when upgrading
 from openssl 1.0.1 to openssl 1.0.2
Message-ID: <CAAfNiqrNg2_9ZMi8OedJfHjXAXGBxAHsmFTFvgp5DKyMhQcoYw@mail.gmail.com>

Hello,

My company is in the process of upgrading from openssl 1.0.1 to openssl
1.0.2. We noticed that when we use any version of openssl 1.0.2 we have an
extremely high increase in memory usage. Around 15 or more gigs of memory
 extra are consumed.

My questions are as follows:

Are there any settings we should be adjusting to decrease openssl 1.0.2
memory consumption?

Has anything changed between openssl 1.0.1 and openssl 1.0.2 that would
account for this increase?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160319/cd41c540/attachment.html>

From openssl-users at dukhovni.org  Sun Mar 20 04:53:23 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 20 Mar 2016 00:53:23 -0400
Subject: [openssl-users] How to get verbose output from 'make test'
In-Reply-To: <CAH8yC8kwYo9LK96ZqTLvMmD570AJEjWwLFvuajiEaNh8UrBuuA@mail.gmail.com>
References: <CAH8yC8kwYo9LK96ZqTLvMmD570AJEjWwLFvuajiEaNh8UrBuuA@mail.gmail.com>
Message-ID: <70897772-2142-4DAE-B247-DA9C584D6E1F@dukhovni.org>


> On Mar 19, 2016, at 10:07 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> 
> Hi Everyone,
> 
> I'm working with OpenSSL 1.1.0. I think I'm seeing a hang in:
> 
>    ../test/recipes/80-test_ssl.t ............. {5|6}/47
> 
> It seems like its timing out, and then the tests march on with:
> 
>    ../test/recipes/80-test_ssl.t ............. ok
> 
> I tried to get a verbose output with 'make test V=1', but it was a
> guess that did not work.
> 
> How can I get verbose output from 'make test'?

There are a lot of combinatorial tests there.  If you're testing a
slow CPU, they could take some time...

-- 
	Viktor.


From rainer.jung at kippdata.de  Sun Mar 20 17:07:12 2016
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Sun, 20 Mar 2016 18:07:12 +0100
Subject: [openssl-users] How to get verbose output from 'make test'
In-Reply-To: <CAH8yC8kwYo9LK96ZqTLvMmD570AJEjWwLFvuajiEaNh8UrBuuA@mail.gmail.com>
References: <CAH8yC8kwYo9LK96ZqTLvMmD570AJEjWwLFvuajiEaNh8UrBuuA@mail.gmail.com>
Message-ID: <56EED8C0.2080704@kippdata.de>

Am 20.03.2016 um 03:07 schrieb Jeffrey Walton:
> Hi Everyone,
>
> I'm working with OpenSSL 1.1.0. I think I'm seeing a hang in:
>
>      ../test/recipes/80-test_ssl.t ............. {5|6}/47
>
> It seems like its timing out, and then the tests march on with:
>
>      ../test/recipes/80-test_ssl.t ............. ok
>
> I tried to get a verbose output with 'make test V=1', but it was a
> guess that did not work.
>
> How can I get verbose output from 'make test'?

Te INSTALL file tells us:

   HARNESS_VERBOSE=yes make test

Regards,

Rainer


From noloader at gmail.com  Mon Mar 21 01:53:34 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 20 Mar 2016 21:53:34 -0400
Subject: [openssl-users] How to get verbose output from 'make test'
In-Reply-To: <56EED8C0.2080704@kippdata.de>
References: <CAH8yC8kwYo9LK96ZqTLvMmD570AJEjWwLFvuajiEaNh8UrBuuA@mail.gmail.com>
 <56EED8C0.2080704@kippdata.de>
Message-ID: <CAH8yC8mro+=Kexo-fbByiyRExHG+jPJA4B-8e1v4ErEZXzm6Lg@mail.gmail.com>

On Sun, Mar 20, 2016 at 1:07 PM, Rainer Jung <rainer.jung at kippdata.de> wrote:
> Am 20.03.2016 um 03:07 schrieb Jeffrey Walton:
>>
>> Hi Everyone,
>>
>> I'm working with OpenSSL 1.1.0. I think I'm seeing a hang in:
>>
>>      ../test/recipes/80-test_ssl.t ............. {5|6}/47
>>
>> It seems like its timing out, and then the tests march on with:
>>
>>      ../test/recipes/80-test_ssl.t ............. ok
>>
>> I tried to get a verbose output with 'make test V=1', but it was a
>> guess that did not work.
>>
>> How can I get verbose output from 'make test'?
>
>
> Te INSTALL file tells us:
>
>   HARNESS_VERBOSE=yes make test

Ah, thanks.

There's a few build systems that can hide output from users; for
example, kbuild, cmake and autotools. Usually the way to enable the
output is "V=1" (kbuild and autotools) and "VERBOSE=1" (cmake).

Perhpas something more standard should be used to keep the
questions/noise to a minimum. Or maybe, use both the OpenSSL way and
the other ways for minimum disruption to current workflows.

Jeff

From uri at ll.mit.edu  Mon Mar 21 02:32:35 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 21 Mar 2016 02:32:35 +0000
Subject: [openssl-users] Naive: how to generate EC public key from EC
 private key?
In-Reply-To: <20160319011104.GA23202@openssl.org>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
 <20160317234538.GA26084@openssl.org> <D311C659.2900E%uri@ll.mit.edu>
 <D311C83C.29011%uri@ll.mit.edu>
 <20160318201724.GW6602@mournblade.imrryr.org>
 <20160319011104.GA23202@openssl.org>
Message-ID: <D31462B0.26238%uri@ll.mit.edu>

Thank you!!

Now the code works (using the outline Stephen suggested, as it is simpler
:)!

I still have a few questions/issues.

1. EVP_PKEY_get0_EC_KEY(key) is only defined for 1.1. I had to use
EVP_PKEY_get1_EC_KEY(key) with 1.0.2g. (this is not a problem - just a
remark)

2. For some reason the following code does not work - subsequent requests
that involve pub key fail:

 dup_ekey = EVP_PKEY_get1_EC_KEY(pubkey);
 group = (EC_GROUP*) EC_KEY_get0_group(dup_ekey);
 nid = EC_GROUP_get_curve_name(group);
 printf("wrap: Deriving ECC keys over curve \"%s\"\n",
EC_curve_nid2nist(nid));
 EC_GROUP_free(group);

 EC_KEY_free(dup_ekey);

But if I move the two XXX_free() calls to the end of the function -
everything is fine. So in my working version of the code these lines are
just before the return, after everything has been done. But I don?t
understand why it behaves that way, given the man pages here:
https://www.openssl.org/docs/man1.0.2/crypto/EVP_PKEY_set1_RSA.html

3. If in the above fragment I try

  dup_ekey = EVP_PKEY_assign_EC_KEY(pubkey);


Then the entire fragment does not work.

Thanks again for your help (as I said, with your guidance the code now
works), and I?d appreciate some light on the above peculiarities.
--
Regards,
Uri Blumenthal




On 3/18/16, 21:11, "openssl-users on behalf of Dr. Stephen Henson"
<openssl-users-bounces at openssl.org on behalf of steve at openssl.org> wrote:

>On Fri, Mar 18, 2016, Viktor Dukhovni wrote:
>
>> On Fri, Mar 18, 2016 at 06:59:36PM +0000, Blumenthal, Uri - 0553 -
>>MITLL wrote:
>> 
>> > Answered my own question: should use EVP_PKEY_bits(pkey) instead.
>> 
>> That's not the right way to determine the curve id.
>> 
>> > >How do I determine what curve the above key is on?
>> 
>> For that you need to determine the EVP_PKEY algorithm type:
>> 
>> 	int type = EVP_PKEY_base_id(pkey);
>> 
>> 	if (type == EVP_PKEY_EC) {
>> 	    EC_KEY *key = EVP_PKEY_get0_EC_KEY(pkey);
>> 	    EC_GROUP *group = EC_KEY_get0_group(key);
>> 
>> 	    /* Use that group to generate more points */
>> 	}
>> 
>> So you don't need code to specifically identify the group, but if
>> you want to constrain the supported groups:
>> 
>> 	switch (EC_GROUP_get_curve_name(group)) {
>> 	case NID_undef:
>> 	default:
>> 	    /* Unknown or not named group */
>> 
>> 	case NID_X9_62_prime256v1:
>> 	    /* P-256 */
>> 	    ...
>> 
>> 	case NID_secp384r1:
>> 	    /* P-384 */
>> 
>> 	    ...
>> 	}
>> 
>
>There is another way too. An EVP_PKEY can also be used to contain
>parameters
>and it is permissible to pass a private or public key as a set of
>parameters.
>
>In outline you call:
>
> EVP_PKEY_CTX *pctx = EVP_PKEY_CTX_new(privkey, NULL);
> EVP_PKEY_keygen_init(pctx);
> EVP_PKEY_keygen(pctx, &newkey);
> EVP_PKEY_CTX_free(pctx);
>
>This works with other algorithms like DSA/DH too so you'll probably want
>to
>check the key is of the correct type first.
>
>Steve.
>--
>Dr Stephen N. Henson. OpenSSL project core developer.
>Commercial tech support now available see: http://www.openssl.org
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From noloader at gmail.com  Mon Mar 21 02:37:27 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sun, 20 Mar 2016 22:37:27 -0400
Subject: [openssl-users] Naive: how to generate EC public key from EC
 private key?
In-Reply-To: <D31462B0.26238%uri@ll.mit.edu>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
 <20160317234538.GA26084@openssl.org>
 <D311C659.2900E%uri@ll.mit.edu> <D311C83C.29011%uri@ll.mit.edu>
 <20160318201724.GW6602@mournblade.imrryr.org>
 <20160319011104.GA23202@openssl.org>
 <D31462B0.26238%uri@ll.mit.edu>
Message-ID: <CAH8yC8mmGzpBgeLiSuzCTVwdwpFYpWcWZP67Dj+5aGesrc7wXg@mail.gmail.com>

> 2. For some reason the following code does not work - subsequent requests
> that involve pub key fail:
>
>  dup_ekey = EVP_PKEY_get1_EC_KEY(pubkey);
>  group = (EC_GROUP*) EC_KEY_get0_group(dup_ekey);
>  nid = EC_GROUP_get_curve_name(group);
>  printf("wrap: Deriving ECC keys over curve \"%s\"\n",
> EC_curve_nid2nist(nid));
>  EC_GROUP_free(group);
>
>  EC_KEY_free(dup_ekey);
>
> But if I move the two XXX_free() calls to the end of the function -
> everything is fine. So in my working version of the code these lines are
> just before the return, after everything has been done. But I don?t
> understand why it behaves that way, given the man pages here:
> https://www.openssl.org/docs/man1.0.2/crypto/EVP_PKEY_set1_RSA.html

get0 means the reference count was _not_ bumped, so the object should
not be free'd.

get1 means the reference count was incremented, and it needs an
accompanying free on the object.

I think the call to `EC_GROUP_free(group)` is superfluous and causing
memory corruption/double free.

Jeff

From openssl-users at dukhovni.org  Mon Mar 21 02:38:47 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 20 Mar 2016 22:38:47 -0400
Subject: [openssl-users] Naive: how to generate EC public key from EC
	private key?
In-Reply-To: <D31462B0.26238%uri@ll.mit.edu>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
 <20160317234538.GA26084@openssl.org> <D311C659.2900E%uri@ll.mit.edu>
 <D311C83C.29011%uri@ll.mit.edu> <20160318201724.GW6602@mournblade.imrryr.org>
 <20160319011104.GA23202@openssl.org> <D31462B0.26238%uri@ll.mit.edu>
Message-ID: <F6C86287-CDF5-4A21-BDA3-A80681B3977F@dukhovni.org>


> On Mar 20, 2016, at 10:32 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> 
> dup_ekey = EVP_PKEY_get1_EC_KEY(pubkey);
> group = (EC_GROUP*) EC_KEY_get0_group(dup_ekey);

Declare the group as:

	const EC_GROUP *group;

Then:

	group = EC_KEY_get0_group();

> nid = EC_GROUP_get_curve_name(group);
> printf("wrap: Deriving ECC keys over curve \"%s\"\n",
> EC_curve_nid2nist(nid));

This is fine.


> EC_GROUP_free(group);

This is very wrong.  You're not supposed to free the group.
Note the "get0_group", you're not getting a copy...

-- 
	Viktor.


From uri at ll.mit.edu  Mon Mar 21 03:01:16 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 21 Mar 2016 03:01:16 +0000
Subject: [openssl-users] Naive: how to generate EC public key from EC
 private key?
In-Reply-To: <F6C86287-CDF5-4A21-BDA3-A80681B3977F@dukhovni.org>
References: <20160317223224.18296912.57162.58318@ll.mit.edu>
 <7555E413-4B17-4274-BA9A-2935BF68D261@dukhovni.org>
 <20160317234538.GA26084@openssl.org> <D311C659.2900E%uri@ll.mit.edu>
 <D311C83C.29011%uri@ll.mit.edu>
 <20160318201724.GW6602@mournblade.imrryr.org>
 <20160319011104.GA23202@openssl.org> <D31462B0.26238%uri@ll.mit.edu>
 <F6C86287-CDF5-4A21-BDA3-A80681B3977F@dukhovni.org>
Message-ID: <D314DBEF.26614%uri@ll.mit.edu>

Viktor and Jeffrey,

Thank you! Now I understand. And it works. ;)
--
Regards,
Uri Blumenthal




On 3/20/16, 22:38, "openssl-users on behalf of Viktor Dukhovni"
<openssl-users-bounces at openssl.org on behalf of
openssl-users at dukhovni.org> wrote:

>
>> On Mar 20, 2016, at 10:32 PM, Blumenthal, Uri - 0553 - MITLL
>><uri at ll.mit.edu> wrote:
>> 
>> dup_ekey = EVP_PKEY_get1_EC_KEY(pubkey);
>> group = (EC_GROUP*) EC_KEY_get0_group(dup_ekey);
>
>Declare the group as:
>
>	const EC_GROUP *group;
>
>Then:
>
>	group = EC_KEY_get0_group();
>
>> nid = EC_GROUP_get_curve_name(group);
>> printf("wrap: Deriving ECC keys over curve \"%s\"\n",
>> EC_curve_nid2nist(nid));
>
>This is fine.
>
>
>> EC_GROUP_free(group);
>
>This is very wrong.  You're not supposed to free the group.
>Note the "get0_group", you're not getting a copy...
>
>-- 
>	Viktor.
>
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From noloader at gmail.com  Mon Mar 21 06:32:18 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 21 Mar 2016 02:32:18 -0400
Subject: [openssl-users] Disable session resumption at compile time (compile
	equivalent to SSL_OP_NO_TICKET)
Message-ID: <CAH8yC8mezm1DDC-od2GXVwZaTVRDZ0c3Luq7WUx5Os_9h5D+6w@mail.gmail.com>

How do we disable session resumption at compile time (compile
equivalent to SSL_OP_NO_TICKET)?

From sharad.tekale at zebra.com  Mon Mar 21 07:02:39 2016
From: sharad.tekale at zebra.com (Tekale, Sharad)
Date: Mon, 21 Mar 2016 07:02:39 +0000
Subject: [openssl-users] openssl 1.0.1p PEM_write_bio_RSAPrivateKey
 fail. error: ASN1_get_object:too long
In-Reply-To: <CE9A43D1-3467-4367-A207-3D658CA3CE99@dukhovni.org>
References: <CADjKrEXzK1NEVjNEDG9Q7fu2Yty2HBFOyc52VG7ahLeACN0Eqw@mail.gmail.com>
 <56EB0BA1.1030901@oracle.com>
 <BN1PR03MB17101812F0E529A52C1D5B0EA8C0@BN1PR03MB171.namprd03.prod.outlook.com>
 <CE9A43D1-3467-4367-A207-3D658CA3CE99@dukhovni.org>
Message-ID: <BL2PR03MB164B6642C822BFA20AD40C5EA8F0@BL2PR03MB164.namprd03.prod.outlook.com>

Hi Viktor,

Thank you for your reply, here are compilation flags:

$ ${OSSL}/bin/openssl version -a
OpenSSL 1.0.1p 9 Jul 2015
built on: Thu Mar 17 00:43:45 2016
platform: linux-generic32
options:  bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) idea(int) blowfish(ptr)
compiler: /opt/wios/gcc-4.2.2-uClibc-0.9.30.2-p5/mips-u24kc-linux-gnu/bin/mips-u24kc-linux-gnu-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -mabi=32 -msoft-float -march=mips32r2 -Os -O3 -O3 -fomit-frame-pointer -Wall
OPENSSLDIR: "/usr/ssl"


>>You've not posted a complete program, nor how what steps you take to compile it, or any compiler warnings, ..., so it is difficult to help you.
a. The Program I've used is very much similar to what I've showed in below snippet.
b. Above command shows the compiler flags, please let me know if you what any further info.
c. There are no compiler warnings.

I've put logs in evp_key.c and observed that it failed in line number 148? I'm not sure what went wrong?

PEM_write_bio_RSAPrivateKey()  -> PEM_ASN1_write_bio() -> EVP_BytesToKey():

Filename: crypto/evp/evp_key.c

119 int EVP_BytesToKey(const EVP_CIPHER *type, const EVP_MD *md,
120                    const unsigned char *salt, const unsigned char *data,
121                    int datal, int count, unsigned char *key,
122                    unsigned char *iv)
                ...
138     for (;;) {
139         if (!EVP_DigestInit_ex(&c, md, NULL))
140             return 0;
141         if (addmd++)
142             if (!EVP_DigestUpdate(&c, &(md_buf[0]), mds))
143                 goto err;
144         if (!EVP_DigestUpdate(&c, data, datal))
145             goto err;
146         if (salt != NULL)
147             if (!EVP_DigestUpdate(&c, salt, PKCS5_SALT_LEN))
148                 goto err;



Any inputs would greatly help.

Thanks,
Sharad.



-----Original Message-----
From: Viktor Dukhovni [mailto:openssl-users at dukhovni.org]
Sent: Friday, March 18, 2016 1:06 PM
To: openssl-users at openssl.org
Cc: Tekale, Sharad
Subject: Re: [openssl-users] openssl 1.0.1p PEM_write_bio_RSAPrivateKey fail. error: ASN1_get_object:too long


> On Mar 18, 2016, at 2:14 AM, Tekale, Sharad <sharad.tekale at zebra.com> wrote:
>
> Thanks a lot for your reply.
>
> I've actually used password of 64 characters in my program, for simplicity I've showcased as 6 byte password in below example.
>
> Looks like there is some other issue or some stringent check that is added in 1.0.1p as the same code works fine in 0.9.8zg version.
>
> Can you please give us pointers to debug this issue.

There's not much to debug.  The code fragment you posted works fine with 1.0.1.
You've not posted a complete program, nor how what steps you take to compile it, or any compiler warnings, ..., so it is difficult to help you.

For comparison, this is what I get:

$ OSSL=/.../OpenSSL_1_0_1

$ ${OSSL}/bin/openssl version -a
OpenSSL 1.0.1s-dev  xx XXX xxxx
built on: Fri Feb 12 23:23:01 2016
platform: darwin64-x86_64-cc
options:  bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: cc -I. -I.. -I../include  -fPIC -fno-common -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/.../OpenSSL_1_0_1/ssl"

$ cc -I${OSSL}/include -L${OSSL}/lib -lssl -lcrypto -o foo foo.c

$ ./foo
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-256-CBC,C87AA39820A10CA005471EA1E17E3CFD

yaoT0FSlhKY77KC1GNlWYN/0Gfk3L9hCl9AKiTqJ1NibvpwuemXYld7OmybHW9ZO
m7lSnApS91GDqsQGXOlhcKD0WgPf+YFbza7/RATxq5A+rs+CohEa7cg8C6eEgdqC
v2f8+AaSl7hdjtNaRFMcxp4ySq6oZPAsmXbbB/4l/AYK/7q//snqOgPbmGp4nLI9
J7gmJvf8igT0LjmC6IIiUgzb2wqHt/U/pFXj+9mm13tNlZtBVKInQMR3wfHqly4p
p2x3UD1xG982rfPvbefU80Zi8l5UnPAgd3jcYVxuZdCmABWqr30Wc/DuiRXzRhJe
LGKEIl+atfjfjH2cnytShkLvSDo/Ml2xKpnP3PQD7OrmCQpPWcFxphPCjHCsIRPz
c3kbx5LE2NArHT7FuOX8e4h422OIuqbxJc2KM8dLKvuoSB6ZWK8kcd1sesMcXu6p
/Q24EBSPCKd/MaRSqo2m41wVTrtnHHJ1R3MxzjtFLLXTWasT0qDbjj+45jyLzJHd
Xt/fhZJaK2mjmDCoLQFXNeaBqj7vN8ts8AI383hTcACeINzvsIirbKzWkH+els4e
ifrrge5mFvn7vvlAycIx73tlkTqI3o0CImXfIXp+necgEYkAAIwrTQxmYBz6jxhh
UcWN3sr1klrGLNakznnu4FWMFzPnE/Hjz1nRdMcXdS1j4k3gM48Zy3zXtBeQIAex
Fb+vpALzV7sk7H6wKpIjMTcNr66Z1WM+Vu3b4pQr/RnBtOjpHUt6uupr0gR6B61F
W7S0pztQXGI0tT4wL6KHa94XvPTNOJwvsPQyRId/I2J9iTMuPxm/xwx5nwL6nVwo
UPcbKbP4S4PWQpkCEL+CG6hLOWV1rkbpC7Rbk8RuB53CBmXJrMBVLpQe5T08OtEr
DXFuWs0Q00Z4y0U6nfjNzpPzevkTJN/ywjxufsri1J9U50zOLseOCauNzkSsEcoK
2kS1FiaxrGKWpCtd1H0klGoIbV2DtFsSMeyqMWfouMbT6dtw2fRZQcypB9nqgVD1
EUmhyPEk1QgRQKmFZ1VyU7gOygJ5RmEwNgy4gGIlXHT+Z7v/lKPyQfFrlqV3qskv
VDsjWp4GplzqIufwU7KHQj1yz3TM5k7BGDUf8DtP3UEioa9k0LdN5byc1Omk8Wgn
mX+sNXiOf5droA6QfAvZky/TCp/bptiEeabIRyyAL0gvQClf78vIrRUlBQ3wMYUF
wNS/XIZVU5szkIqPO7elJEhX149phcln7BvOLVHtUmSo0vzbFuQ+6gmfhAbU6Ozl
cIupo0flQ9Mz5TvE5HTi2Oe0Hg2DeRAYa8KzTYOkaGVnjXJKqVOvjW2fnen9kJOe
X5vjEvHnZIJ1L7z/YhGU4xKF4uSseV0AUgnyLItIa+Vd6iMu/l7Qxuqby+M1dLft
UQhrnJmo98Xr8zrE7Q9++CwH2O+v8/8vDkopLaZrmyktgr6yfbGuQcuT9/tByEVu
D2vbBCZWybwYmbiwS1i+tbl3sg/JvruCUXZ8HTu5JV2NLIPBGf+i4XmF5ZTuXSAU
ba0l8XIAHYGLADvdnDlhew99bvpmU3fUEUHC1PF0C09r9pSkDDHtedmRwxVZCOUp
-----END RSA PRIVATE KEY-----

$ echo $?
0

$ cat foo.c
#include <stdio.h>
#include <string.h>
#include <stdlib.h>

#include <openssl/rsa.h>
#include <openssl/evp.h>
#include <openssl/pem.h>
#include <openssl/bio.h>

int main(int argc, char *argv[])
{
    char *pass = "abcdef";
    size_t passlen;
    int len;
    int ret;
    RSA *rsa;
    BIO *bio = BIO_new_fp(stdout, BIO_NOCLOSE);
    BIO *priv_bio = BIO_new(BIO_s_mem());
    char buf[4096];

    if (argc > 1)
        pass = argv[1];
    passlen = strlen(pass);

    OpenSSL_add_all_algorithms();
    rsa = RSA_generate_key(2048, 65537, NULL, NULL);
    ret = PEM_write_bio_RSAPrivateKey(priv_bio, rsa, EVP_aes_256_cbc(),
                                      (unsigned char *)pass, (int)passlen,
                                      NULL, NULL);
    while((len = BIO_gets(priv_bio, buf, sizeof(buf))) > 0)
        BIO_write(bio, buf, len);
    BIO_free(priv_bio);
    BIO_free(bio);
    exit(!ret);
}

--
Viktor.


________________________________
- CONFIDENTIAL-

This email and any files transmitted with it are confidential, and may also be legally privileged. If you are not the intended recipient, you may not review, use, copy, or distribute this message. If you receive this email in error, please notify the sender immediately by reply email and then delete this email.

From matt at openssl.org  Mon Mar 21 10:04:30 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 21 Mar 2016 10:04:30 +0000
Subject: [openssl-users] Increased memory consumption noticed when
 upgrading from openssl 1.0.1 to openssl 1.0.2
In-Reply-To: <CAAfNiqrNg2_9ZMi8OedJfHjXAXGBxAHsmFTFvgp5DKyMhQcoYw@mail.gmail.com>
References: <CAAfNiqrNg2_9ZMi8OedJfHjXAXGBxAHsmFTFvgp5DKyMhQcoYw@mail.gmail.com>
Message-ID: <56EFC72E.60508@openssl.org>



On 20/03/16 03:15, Andrew Payne wrote:
> Hello,
> 
> My company is in the process of upgrading from openssl 1.0.1 to openssl
> 1.0.2. We noticed that when we use any version of openssl 1.0.2 we have
> an extremely high increase in memory usage. Around 15 or more gigs of
> memory  extra are consumed.
> 
> My questions are as follows:
> 
> Are there any settings we should be adjusting to decrease openssl 1.0.2
> memory consumption?
> 
> Has anything changed between openssl 1.0.1 and openssl 1.0.2 that would
> account for this increase?

Not that I can think of, and I don't recall this issue coming up before
which would suggest its not a widespread problem. Any clues as to what
the application is doing at the time you see this?

Matt


From openssl-users at dukhovni.org  Mon Mar 21 14:15:50 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 21 Mar 2016 10:15:50 -0400
Subject: [openssl-users] Disable session resumption at compile time
	(compile equivalent to SSL_OP_NO_TICKET)
In-Reply-To: <CAH8yC8mezm1DDC-od2GXVwZaTVRDZ0c3Luq7WUx5Os_9h5D+6w@mail.gmail.com>
References: <CAH8yC8mezm1DDC-od2GXVwZaTVRDZ0c3Luq7WUx5Os_9h5D+6w@mail.gmail.com>
Message-ID: <BB2F1608-8875-4B5C-9084-957847DC3868@dukhovni.org>


> On Mar 21, 2016, at 2:32 AM, Jeffrey Walton <noloader at gmail.com> wrote:
> 
> How do we disable session resumption at compile time (compile
> equivalent to SSL_OP_NO_TICKET)?

There is no such compile-time feature.  However you can disable the
session cache at run-time.

Note, SSL_OP_NO_TICKET just disables session tickets, it does not disable
server-side caching.

See:

	SSL_CTX_set_session_cache_mode()

-- 
	Viktor.


From alfonso at coscione.it  Mon Mar 21 14:23:21 2016
From: alfonso at coscione.it (Alfonso Coscione)
Date: Mon, 21 Mar 2016 15:23:21 +0100
Subject: [openssl-users] Info about size
Message-ID: <911bc3d307106ef25ecb56e7e47d5052@coscione.it>

Hi OpenSSL Staff,

sorry for disturb.
I'm an italian young engineer and I'm working on new software project
that wuold want to use yours openssl library to realize an
encryption/decryption protocol to use for downloading updates from a
server.
I try to find on web some informations, but i'm not able to understand
about the sizes.
I explain better.
I've to know, more exactly, how to calculate the dimension of an
encrypted text after an encryption with a private key with an RSA
protocol.. and so, also the dimension of a decrypted text after an
decryption with a public key.
I don't know if you can help me.. I would appreciate any help or
suggestion.

Sorry for disturb and thanks for all your work.



--
Alfonso Coscione
-------------------------------------------------------------------------------------------
"before giving good advice, we must give good examples..in life it takes
consistency .. !!"
-------------------------------------------------------------------------------------------
- Please respect the environment before printing this email unless
absolutely necessary. -

From thomas.francis.jr at pobox.com  Mon Mar 21 16:29:31 2016
From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.)
Date: Mon, 21 Mar 2016 12:29:31 -0400
Subject: [openssl-users] Info about size
In-Reply-To: <911bc3d307106ef25ecb56e7e47d5052@coscione.it>
References: <911bc3d307106ef25ecb56e7e47d5052@coscione.it>
Message-ID: <1166BC02-3160-4707-9BBB-34E634F6857A@pobox.com>


> On Mar 21, 2016, at 10:23 AM, Alfonso Coscione <alfonso at coscione.it> wrote:
> 
> Hi OpenSSL Staff,
> 
> sorry for disturb.
> I'm an italian young engineer and I'm working on new software project
> that wuold want to use yours openssl library to realize an
> encryption/decryption protocol to use for downloading updates from a
> server.
> I try to find on web some informations, but i'm not able to understand
> about the sizes.
> I explain better.
> I've to know, more exactly, how to calculate the dimension of an
> encrypted text after an encryption with a private key with an RSA
> protocol..

Well, with RSA, the input size and output size will match the size of your key.  For example, if you have a 2048-bit RSA key, then the output and input sizes must be exactly 2048 bits.  You can encrypt/decrypt multiple times, in order to get larger amounts of data, but that?s almost certainly not what you want to do.

Instead, you should choose a symmetric cipher (e.g. AES) for encrypting your data.  You can then encrypt the symmetric key with your RSA key (along with appropriate padding, since your symmetric key should be smaller than your RSA key ? there?s lots of good advice on the 'net for choosing appropriate sizes for these).

It next depends on the algorithm you chose.  If a streaming cipher, the input and output sizes will be the same.  If a block cipher (like AES), it depends then on which mode you choose for predicting the size of your encrypted output.  If you chose CBC, e.g., the output size will be a multiple of the block size, either the size of your plaintext rounded up to the nearest multiple of block size, or the size of your plaintext + the block size.  For AEAD modes, like GCM, the output size will match your input size, but you?ll also have an additional value to store.

Then, on top of all that, you probably need to include the encrypted key, so the receiving end can decrypt.

Finally, I would note that you probably want to include some kind of structure around all this.  CMS might serve you very well.  At the least, it?s a good, relatively easy starting point.

> and so, also the dimension of a decrypted text after an
> decryption with a public key.
> I don't know if you can help me.. I would appreciate any help or
> suggestion.

It depends on how you decide to format your data, but when this information is critical, but not likely to tell an attacker anything useful, one would usually just store the size of the decrypted data, so the receiver can just read it directly.  However, it?s often not critical to know the size before you start decrypting, and a successful decryption will not return any excess data (such as padding), so you can track the size as you decrypt, and know as soon as it?s finished.

Just to be sure it?s clear, but you usually don?t want to encrypt data with the private key ? doing so means that just anyone can decrypt it.  You want to encrypt using the public key, so that only the person who has the private key can decrypt it.  And if you?re doing some sort of update, this kind of encryption is probably a bad idea, unless you?re encrypting updates for each customer.  Unless there?s something super-super-secret about the update, I?d recommend delivering the update via TLS, and only sign the data, so that each customer has the public key, and only you have the private key, and each customer can be certain the update came from you, not some malicious user or system (and if it is that secret, I?d consider delivering updates only in person, and you can just avoid any automation entirely :) ).

When creating signatures, you do encrypt with the private key, but we don?t usually use that terminology, in order to avoid confusion.  When signing data, you would typically route all the data through a hash method (e.g. SHA-256), and encrypt the resulting hash along with info about the hash method to get a valid signature.  Again, you?d need some structure to indicate what data was signed, and what the signature is, and again, CMS would be a good starting point.  I think once you?ve decided exactly what you?ll be doing and how, you?ll be able to predict your final sizes.

TOM

<snip>


From michel.sales at free.fr  Mon Mar 21 16:36:30 2016
From: michel.sales at free.fr (Michel)
Date: Mon, 21 Mar 2016 17:36:30 +0100
Subject: [openssl-users] Info about size
In-Reply-To: <911bc3d307106ef25ecb56e7e47d5052@coscione.it>
References: <911bc3d307106ef25ecb56e7e47d5052@coscione.it>
Message-ID: <00ad01d1838f$d30e8080$792b8180$@sales@free.fr>

Hi Alphonso,

Did you see that :
https://wiki.openssl.org/index.php/EVP_Asymmetric_Encryption_and_Decryption_
of_an_Envelope

Hope this helps,

Regards,

Michel.
 
-----Message d'origine-----
De?: openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de
Alfonso Coscione
Envoy??: lundi 21 mars 2016 15:23
??: openssl-users at openssl.org
Objet?: [openssl-users] Info about size

Hi OpenSSL Staff,

sorry for disturb.
I'm an italian young engineer and I'm working on new software project that
wuold want to use yours openssl library to realize an encryption/decryption
protocol to use for downloading updates from a server.
I try to find on web some informations, but i'm not able to understand about
the sizes.
I explain better.
I've to know, more exactly, how to calculate the dimension of an encrypted
text after an encryption with a private key with an RSA protocol.. and so,
also the dimension of a decrypted text after an decryption with a public
key.
I don't know if you can help me.. I would appreciate any help or suggestion.

Sorry for disturb and thanks for all your work.

--
Alfonso Coscione
----------------------------------------------------------------------------
---------------
"before giving good advice, we must give good examples..in life it takes
consistency .. !!"
----------------------------------------------------------------------------
---------------
- Please respect the environment before printing this email unless
absolutely necessary. -
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From ajrpayne at gmail.com  Mon Mar 21 18:51:28 2016
From: ajrpayne at gmail.com (Andrew Payne)
Date: Mon, 21 Mar 2016 11:51:28 -0700
Subject: [openssl-users] Increased memory consumption noticed when
 upgrading from openssl 1.0.1 to openssl 1.0.2
In-Reply-To: <56EFC72E.60508@openssl.org>
References: <CAAfNiqrNg2_9ZMi8OedJfHjXAXGBxAHsmFTFvgp5DKyMhQcoYw@mail.gmail.com>
 <56EFC72E.60508@openssl.org>
Message-ID: <CAAfNiqpQyOahpOfYG7u-NW+gV7n3e-qw_pp+bsSO9kyMjSedwg@mail.gmail.com>

Hi,

Thanks for the reply.

We are using the openssl library with nginx to serve traffic in a
multi-tenanted reverse proxy environment. We made no changes to our nginx
config/build outside of upgrading to openssl 1.0.2.

Currently, all servers are running openssl 1.0.1p except for a couple of
servers which are running openssl 1.0.2g.

During normal operation the servers on average use about 10 gigs of memory,
but when running 1.0.2 an extra 25 gigs of memory is being consumed.

When we do an nginx reload, we see massive 50-60 gig dips in available
memory when running openssl 1.0.2.

On Mon, Mar 21, 2016 at 3:04 AM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 20/03/16 03:15, Andrew Payne wrote:
> > Hello,
> >
> > My company is in the process of upgrading from openssl 1.0.1 to openssl
> > 1.0.2. We noticed that when we use any version of openssl 1.0.2 we have
> > an extremely high increase in memory usage. Around 15 or more gigs of
> > memory  extra are consumed.
> >
> > My questions are as follows:
> >
> > Are there any settings we should be adjusting to decrease openssl 1.0.2
> > memory consumption?
> >
> > Has anything changed between openssl 1.0.1 and openssl 1.0.2 that would
> > account for this increase?
>
> Not that I can think of, and I don't recall this issue coming up before
> which would suggest its not a widespread problem. Any clues as to what
> the application is doing at the time you see this?
>
> Matt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160321/94b52848/attachment.html>

From uri at ll.mit.edu  Tue Mar 22 22:49:49 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 22 Mar 2016 22:49:49 +0000
Subject: [openssl-users] Naive: how to generate EC public key from
	EC	private key?
Message-ID: <20160322224955.18296912.33783.59276@ll.mit.edu>

One more hurdle passed. The code is working perfect, AFAIK.
?
Now one small question: how do I ensure that ?RAND_engine (and therefore Intel RDRAND output) is being used for the key generation in
? ?EVP_PKEY_keygen(ctx, &newkey);

Is just loading RAND_engine enough for that??
?
Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Viktor Dukhovni?
Sent: Sunday, March 20, 2016 22:39?
To: openssl-users at openssl.org
Reply To: openssl-users at openssl.org
Subject: Re: [openssl-users] Naive: how to generate EC public key from EC	private key?


> On Mar 20, 2016, at 10:32 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> 
> dup_ekey = EVP_PKEY_get1_EC_KEY(pubkey);
> group = (EC_GROUP*) EC_KEY_get0_group(dup_ekey);

Declare the group as:

const EC_GROUP *group;

Then:

group = EC_KEY_get0_group();

> nid = EC_GROUP_get_curve_name(group);
> printf("wrap: Deriving ECC keys over curve \"%s\"\n",
> EC_curve_nid2nist(nid));
?
This is fine.


> EC_GROUP_free(group);

This is very wrong. You're not supposed to free the group.
Note the "get0_group", you're not getting a copy...

-- 
Viktor.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160322/0fd24ce3/attachment.bin>

From noloader at gmail.com  Tue Mar 22 22:54:21 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 22 Mar 2016 18:54:21 -0400
Subject: [openssl-users] RDRAND and engine (was: how to generate EC public
	key from EC private key)
Message-ID: <CAH8yC8n3uk39J1-f1E_2sSYGScOGW-5AXmvqzAWCrQXYcHtyCw@mail.gmail.com>

> Now one small question: how do I ensure that ?RAND_engine (and therefore Intel RDRAND output) is being used for the key generation in
>    EVP_PKEY_keygen(ctx, &newkey);
>
> Is just loading RAND_engine enough for that??
> ?

To verify it, I think you need to inspect the default RAND method. Its
going to look something like:

  RAND_METHOD* rm = RAND_get_rand_method();
  if(rm == RAND_SSLeay())
  {
      printf("Using default generator\n");
  }

Also see https://wiki.openssl.org/index.php/Random_Numbers#Generators.
RDRAND is discussed there, too. But I don't recall how much detail is
provided.

Jeff

From wrowe at rowe-clan.net  Tue Mar 22 23:06:09 2016
From: wrowe at rowe-clan.net (William A Rowe Jr)
Date: Tue, 22 Mar 2016 18:06:09 -0500
Subject: [openssl-users] Removing some systems
In-Reply-To: <8f77f2d4452446c8825cc70057624690@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <8f77f2d4452446c8825cc70057624690@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CACsi252O5VTBDrJpccrWovhsbPZ+EcrmnTsB70YCcCWWDkcwWg@mail.gmail.com>

Just FTR...
http://www.osnews.com/story/28933/Blue_Lion_new_OS_2_distribution_due_2016

Not that I'd take that as a mandate to preserve support... We are having
the same internal dialog at the ASF httpd project and coming to the same
conclusions.
On Mar 17, 2016 1:36 PM, "Salz, Rich" <rsalz at akamai.com> wrote:

> We are planning on removing the following systems from OpenSSL 1.1:
>
> Netware
>
> OS/2
>
>
>
> There are a few reasons for this.  In no particular order they include:
> these platforms are no longer supported by the vendor; the configurations
> and builds have not been testable by the team for years and might not even
> work; nobody on the team has access to any of these.
>
>
>
> As a hopefully mediating factor, please note that they are still part of
> 1.0.2, which we have said is an LTS release with support until 2019.
>
>
>
> People interested in supporting any of these systems should look at
> building their own configuration with the template system; post on the
> openssl-dev list for help.  Reducing the footprint and tangle of #ifdef?s
> is also very important.
>
>
>
> We are also looking at others that are in a similar (although perhaps not
> identical) reason and will post here about them.
>
>
>
> --
>
> Senior Architect, Akamai Technologies
>
> IM: richsalz at jabber.at Twitter: RichSalz
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160322/2f8c8485/attachment.html>

From noloader at gmail.com  Wed Mar 23 00:11:07 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 22 Mar 2016 20:11:07 -0400
Subject: [openssl-users] RDRAND and engine (was: how to generate EC
 public key from EC private key)
In-Reply-To: <CAH8yC8n3uk39J1-f1E_2sSYGScOGW-5AXmvqzAWCrQXYcHtyCw@mail.gmail.com>
References: <CAH8yC8n3uk39J1-f1E_2sSYGScOGW-5AXmvqzAWCrQXYcHtyCw@mail.gmail.com>
Message-ID: <CAH8yC8mnS2wSei+1EqG_3_m-GTTyiD2eYPuu30TQo8KP9nZJfQ@mail.gmail.com>

On Tue, Mar 22, 2016 at 6:54 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>> Now one small question: how do I ensure that ?RAND_engine (and therefore Intel RDRAND output) is being used for the key generation in
>>    EVP_PKEY_keygen(ctx, &newkey);
>>
>> Is just loading RAND_engine enough for that??
>> ?
>
> To verify it, I think you need to inspect the default RAND method. Its
> going to look something like:
>
>   RAND_METHOD* rm = RAND_get_rand_method();
>   if(rm == RAND_SSLeay())
>   {
>       printf("Using default generator\n");
>   }
>
> Also see https://wiki.openssl.org/index.php/Random_Numbers#Generators.
> RDRAND is discussed there, too. But I don't recall how much detail is
> provided.

Ah, its right there. I should have checked earlier
(http://wiki.openssl.org/index.php/Random_Numbers#Hardware):

To ensure RAND_bytes uses the [RDRAND] hardware engine, you must
perform three steps:

   * load the rdrand engine
   * acquire a handle to the engine
   * set the default RAND_method to the engine

It also provides the sample code.

Jeff

From jetson23 at hotmail.com  Wed Mar 23 15:07:46 2016
From: jetson23 at hotmail.com (Jason Schultz)
Date: Wed, 23 Mar 2016 15:07:46 +0000
Subject: [openssl-users] Build of 1.0.2g fails
Message-ID: <BLUPR10MB0724660E0CE170B65F0B7D7BC7810@BLUPR10MB0724.namprd10.prod.outlook.com>

Greetings. I am re-posing this message (as well as another message) to the list as I was having problems with my list membership when it was posted, and I also made a mistake in the subject line, which may have deterred some responses.

I'm having problems building OpenSSL, starting with 1.0.1g. The 
scenario is as follows.

I'm not sure when the problem was introduced; however, with the compiling-out 
of SSLv2 *by default* in -1.0.2g, that change has exacerbated this problem.  
(That is, instead of affecting only those who selected "no-ssl2", it now 
affects everyone *except* those that explicitly select "ssl2".)

First, the existing package runs a self-test during the package build process.  
One of those tests verifies SSL (ssl/ssltest.c), and another verifies SSL usage 
when FIPS is active (test/testfipsssl).  The code in ssl/ssltest.c has a 
section that detects if the requested encryption mechanism has been disabled at 
build time ("compiled out").  If this situation is detected, an "OK" status is 
returned so that the test driver can determine what to do.  When FIPS is 
compiled, configured, and enabled, calling the SSL verification from 
test/testfipsssl to verify SSLv2 or SSLv3 support should result in a "Fail" 
status since neither SSLv2 nor SSLv3 is supported with FIPS.  However, when the 
"no-sslv2" and/or "no-sslv3" build options are selected, neither mechanism gets 
compiled in, so the SSL verification test detects this and immediately returns 
"OK" status.  Since FIPS is compiled, configured, and enabled, a "Fail" status 
is expected by test/testfipsssl instead, so the "OK" status that is re
 ceived because the ciphers are not present is handled as a test failure 
thereby aborting the build.

To make the package build correctly with "no-sslv2" or "no-sslv3" specified, I 
had to add the following:

Index: ssl/ssltest.c
===================================================================
--- ssl/ssltest.c (revision 4068)
+++ ssl/ssltest.c (working copy)
@@ -1203,8 +1203,20 @@
     if (no_protocol) {
         fprintf(stderr, "Testing was requested for a disabled protocol. "
                 "Skipping tests.\n");
+#ifdef OPENSSL_FIPS
+        /*
+         * If FIPS is enabled, then neither SSLv2 nor SSLv3 are permitted 
anyway.
+         * In this case, the fact that one or both are compiled-out is a good 
thing,
+         * so we continue onward to return the expected error status instead.
+         */
+        if (!fips_mode || !FIPS_mode_set(1) || !(ssl2 || ssl3)) {
+            ret = 0;
+            goto end;
+        }
+#else
         ret = 0;
         goto end;
+#endif
     }

     if (!ssl2 && !ssl3 && !tls1 && !dtls1 && !dtls12 && number > 1 && !reuse 
&& !force) {

Is this a known problem? Is there a solution available?

Thanks in advance.


From jetson23 at hotmail.com  Wed Mar 23 15:09:16 2016
From: jetson23 at hotmail.com (Jason Schultz)
Date: Wed, 23 Mar 2016 15:09:16 +0000
Subject: [openssl-users] Building 1.0.2g with "no-idea"
Message-ID: <BLUPR10MB07241F3AB681A3A0C37DA466C7810@BLUPR10MB0724.namprd10.prod.outlook.com>

I am re-posting this (and another) message to the list as I was having email issues with the list and I posted an erroneous subject line, which may have deterred responses.

I have another question that was encountered at the same time as my previous 
one, but I believe it is two separate issues, so I created a different thread.

When building 1.0.2g and attempting to remove some ciphers at build time 
("no-idea"), I discovered that the Make scripting was attempting to build some 
of its files anyway:

[...]
gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
-DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -g 
-m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
-fasynchronous-unwind-tables -std=gnu99 -Wa,--noexecstack -fomit-frame-pointer 
-DTERMIO -DPURIFY -DSSL_FORBID_ENULL -D_GNU_SOURCE -fstack-protector -Wall 
-Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
-I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
-DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM   -c -o e_bf.o e_bf.c
make[2]: *** No rule to make target `../../include/openssl/idea.h', needed by 
`e_idea.o'.  Stop.
make[2]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto/evp'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto'
make: *** [build_crypto] Error 1

It looks as though the "no-idea" removes some of the header files from the 
build, but then the make tries to compile the .c files anyway.

Has anyone else encountered this problem?

From matt at openssl.org  Wed Mar 23 15:19:29 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 23 Mar 2016 15:19:29 +0000
Subject: [openssl-users] Building 1.0.2g with "no-idea"
In-Reply-To: <BLUPR10MB07241F3AB681A3A0C37DA466C7810@BLUPR10MB0724.namprd10.prod.outlook.com>
References: <BLUPR10MB07241F3AB681A3A0C37DA466C7810@BLUPR10MB0724.namprd10.prod.outlook.com>
Message-ID: <56F2B401.5050306@openssl.org>



On 23/03/16 15:09, Jason Schultz wrote:
> I am re-posting this (and another) message to the list as I was having email issues with the list and I posted an erroneous subject line, which may have deterred responses.
> 
> I have another question that was encountered at the same time as my previous 
> one, but I believe it is two separate issues, so I created a different thread.
> 
> When building 1.0.2g and attempting to remove some ciphers at build time 
> ("no-idea"), I discovered that the Make scripting was attempting to build some 
> of its files anyway:
> 
> [...]
> gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
> -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O2 -g 
> -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables 
> -fasynchronous-unwind-tables -std=gnu99 -Wa,--noexecstack -fomit-frame-pointer 
> -DTERMIO -DPURIFY -DSSL_FORBID_ENULL -D_GNU_SOURCE -fstack-protector -Wall 
> -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
> -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM 
> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM 
> -DECP_NISTZ256_ASM   -c -o e_bf.o e_bf.c
> make[2]: *** No rule to make target `../../include/openssl/idea.h', needed by 
> `e_idea.o'.  Stop.
> make[2]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto/evp'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto'
> make: *** [build_crypto] Error 1
> 
> It looks as though the "no-idea" removes some of the header files from the 
> build, but then the make tries to compile the .c files anyway.
> 
> Has anyone else encountered this problem?
> 

Make sure you have run "make depend", i.e.

$ ./config no-idea
$ make depend
$ make
$ make test

Matt

From jeremy.farrell at oracle.com  Wed Mar 23 19:48:29 2016
From: jeremy.farrell at oracle.com (Jeremy Farrell)
Date: Wed, 23 Mar 2016 19:48:29 +0000
Subject: [openssl-users] [openssl-dev] Low level API call to digest SHA1
 forbidden in FIPS mode - within openssl code
In-Reply-To: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
References: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
Message-ID: <56F2F30D.6060207@oracle.com>

This is a question about using the OpenSSL libraries; should be in 
openssl-users, copied and reply-to'd.

On 23/03/2016 17:25, Glen Matthews wrote:
>
> We?re receiving this assertion at the start of negotiating an SSL 
> connection:
>
> c:\s\15\src\openssl\build\openssl-1.0.2f\crypto\sha\sha_locl.h(128): 
> OpenSSL internal error, assertion failed: Low level API call to digest 
> SHA1 forbidden in FIPS mode!
>

I notice the assertion message mentions a header from what looks like a 
1.0.2f tree, but the references below are all to a 1.0.2g tree. I've no 
idea if this is relevant to the problem, but I wonder if this is a 
self-consistent build of the libraries.

> The last 2 lines of this stack trace shows that we are performing a 
> BIO_read at this point.
>
> How can we work around this issue? We?re using the self-validated FIPS 
> module and openssl 1.0.2g.
>
> glen
>
> user32!ZwUserWaitMessage+0xa
>
>  user32!DialogBox2+0x212
>
>  user32!InternalDialogBox+0x132
>
>  user32!SoftModalMessageBox+0xee1
>
>  user32!MessageBoxWorker+0x2eb
>
>  user32!MessageBoxTimeoutW+0xba
>
>  user32!MessageBoxW+0x4e
>
>  libeay32f!OPENSSL_showfatal+0x25e 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\cryptlib.c @ 979]
>
>  libeay32f!OpenSSLDie+0x22 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\cryptlib.c @ 1008]
>
>  libeay32f!SHA1_Init+0x33 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\sha\sha_locl.h @ 128]
>
>  libeay32f!EVP_DigestInit_ex+0x269 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\evp\digest.c @ 241]
>
>  libeay32f!EVP_Digest+0x7a 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\evp\digest.c @ 359]
>
>  libeay32f!ASN1_item_digest+0x6a 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\asn1\a_digest.c @ 107]
>
>  libeay32f!X509_digest+0x44 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\x509\x_all.c @ 414]
>
>  libeay32f!x509v3_cache_extensions+0x43 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\x509v3\v3_purp.c @ 407]
>
>  libeay32f!X509_check_purpose+0x47 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\x509v3\v3_purp.c @ 134]
>
>  libeay32f!X509_verify_cert+0x180 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\x509\x509_vfy.c @ 249]
>
>  ssleay32f!ssl_verify_cert_chain+0x14a 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\ssl_cert.c @ 759]
>
>  ssleay32f!ssl3_get_server_certificate+0x1bb 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s3_clnt.c @ 1255]
>
>  ssleay32f!ssl3_connect+0x258 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s3_clnt.c @ 345]
>
>  ssleay32f!ssl23_get_server_hello+0x44a 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s23_clnt.c @ 799]
>
>  ssleay32f!ssl23_connect+0x1f2 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s23_clnt.c @ 228]
>
>  ssleay32f!ssl23_read+0x44 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s23_lib.c @ 134]
>
>  ssleay32f!ssl_read+0x5e 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\bio_ssl.c @ 167]
>
>  libeay32f!BIO_read+0xbf 
> [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\bio\bio_lib.c @ 212]
>
>  hclftpx!CAsyncSslSocketLayer::OnReceive+0x1a8 
> [c:\s\15\src\montreal\inc\asyncsslsocketlayer.cpp @ 357]
>
-- 
J. J. Farrell
Not speaking for Oracle.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160323/3b2f8748/attachment-0001.html>

From glenm at opentext.com  Wed Mar 23 20:11:34 2016
From: glenm at opentext.com (Glen Matthews)
Date: Wed, 23 Mar 2016 20:11:34 +0000
Subject: [openssl-users] [openssl-dev] Low level API call to digest SHA1
 forbidden in FIPS mode - within openssl code
In-Reply-To: <56F2F30D.6060207@oracle.com>
References: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
 <56F2F30D.6060207@oracle.com>
Message-ID: <6D4F4080B6BD2B4F9F5955C645671A1FA98AE1A0@otwlxg23.opentext.net>

Hi

Right, sorry about the wrong posting - and thanks.

The message is correct - we got this in the 1.0.2f tree and are still getting in in the 1.0.2g tree.

I notice that in crypto\x509v3\v3_purp.c there is this:

    if (x->ex_flags & EXFLAG_SET)
        return;
#ifndef OPENSSL_NO_SHA
    X509_digest(x, EVP_sha1(), x->sha1_hash, NULL);
#endif

We haven't disabled SHA1 because we need it for our ssh implementation. From what I've been reading, the code should not be calling with EVP_sha1().

glen

From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Jeremy Farrell
Sent: Wednesday, March 23, 2016 3:48 PM
To: openssl-users at openssl.org
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] Low level API call to digest SHA1 forbidden in FIPS mode - within openssl code

This is a question about using the OpenSSL libraries; should be in openssl-users, copied and reply-to'd.
On 23/03/2016 17:25, Glen Matthews wrote:
We're receiving this assertion at the start of negotiating an SSL connection:

c:\s\15\src\openssl\build\openssl-1.0.2f\crypto\sha\sha_locl.h(128): OpenSSL internal error, assertion failed: Low level API call to digest SHA1 forbidden in FIPS mode!

I notice the assertion message mentions a header from what looks like a 1.0.2f tree, but the references below are all to a 1.0.2g tree. I've no idea if this is relevant to the problem, but I wonder if this is a self-consistent build of the libraries.


The last 2 lines of this stack trace shows that we are performing a BIO_read at this point.

How can we work around this issue? We're using the self-validated FIPS module and openssl 1.0.2g.

glen

user32!ZwUserWaitMessage+0xa
 user32!DialogBox2+0x212
 user32!InternalDialogBox+0x132
 user32!SoftModalMessageBox+0xee1
 user32!MessageBoxWorker+0x2eb
 user32!MessageBoxTimeoutW+0xba
 user32!MessageBoxW+0x4e
 libeay32f!OPENSSL_showfatal+0x25e [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\cryptlib.c @ 979]
 libeay32f!OpenSSLDie+0x22 [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\cryptlib.c @ 1008]
 libeay32f!SHA1_Init+0x33 [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\sha\sha_locl.h @ 128]
 libeay32f!EVP_DigestInit_ex+0x269 [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\evp\digest.c @ 241]
 libeay32f!EVP_Digest+0x7a [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\evp\digest.c @ 359]
 libeay32f!ASN1_item_digest+0x6a [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\asn1\a_digest.c @ 107]
 libeay32f!X509_digest+0x44 [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\x509\x_all.c @ 414]
 libeay32f!x509v3_cache_extensions+0x43 [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\x509v3\v3_purp.c @ 407]
 libeay32f!X509_check_purpose+0x47 [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\x509v3\v3_purp.c @ 134]
 libeay32f!X509_verify_cert+0x180 [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\x509\x509_vfy.c @ 249]
 ssleay32f!ssl_verify_cert_chain+0x14a [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\ssl_cert.c @ 759]
 ssleay32f!ssl3_get_server_certificate+0x1bb [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s3_clnt.c @ 1255]
 ssleay32f!ssl3_connect+0x258 [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s3_clnt.c @ 345]
 ssleay32f!ssl23_get_server_hello+0x44a [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s23_clnt.c @ 799]
 ssleay32f!ssl23_connect+0x1f2 [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s23_clnt.c @ 228]
 ssleay32f!ssl23_read+0x44 [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\s23_lib.c @ 134]
 ssleay32f!ssl_read+0x5e [c:\s\15\src\openssl\build\openssl-1.0.2g\ssl\bio_ssl.c @ 167]
 libeay32f!BIO_read+0xbf [c:\s\15\src\openssl\build\openssl-1.0.2g\crypto\bio\bio_lib.c @ 212]
 hclftpx!CAsyncSslSocketLayer::OnReceive+0x1a8 [c:\s\15\src\montreal\inc\asyncsslsocketlayer.cpp @ 357]

--

J. J. Farrell

Not speaking for Oracle.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160323/f86f5196/attachment.html>

From thomas_floodeenjr at mentor.com  Wed Mar 23 21:53:36 2016
From: thomas_floodeenjr at mentor.com (Floodeenjr, Thomas)
Date: Wed, 23 Mar 2016 21:53:36 +0000
Subject: [openssl-users] Building 1.0.2g with "no-idea"
In-Reply-To: <56F2B401.5050306@openssl.org>
References: <BLUPR10MB07241F3AB681A3A0C37DA466C7810@BLUPR10MB0724.namprd10.prod.outlook.com>
 <56F2B401.5050306@openssl.org>
Message-ID: <C58E97D22BD22F448150018085826C5101A859B7F8@NA-MBX-01.mgc.mentorg.com>

I have this problem too, and tried the "make depend" step. It still fails to build.

make[2]: *** No rule to make target `../../include/openssl/rc4.h', needed by `eng_openssl.o'.  Stop.

I worked around it by stubbing in all of the missing headers I did not need:

# Stub in some missing header files since the configure appears to be broken.
touch ${BUILD_DIR}/include/openssl/rc4.h
touch ${BUILD_DIR}/include/openssl/blowfish.h
touch ${BUILD_DIR}/include/openssl/idea.h
touch ${BUILD_DIR}/include/openssl/camellia.h
touch ${BUILD_DIR}/include/openssl/seed.h
touch ${BUILD_DIR}/include/openssl/rc2.h
touch ${BUILD_DIR}/include/openssl/cast.h
touch ${BUILD_DIR}/include/openssl/md4.h
touch ${BUILD_DIR}/include/openssl/mdc2.h

This works for me.

Regards,
-Tom

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
Sent: Wednesday, March 23, 2016 9:19 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Building 1.0.2g with "no-idea"



On 23/03/16 15:09, Jason Schultz wrote:
> I am re-posting this (and another) message to the list as I was having email issues with the list and I posted an erroneous subject line, which may have deterred responses.
> 
> I have another question that was encountered at the same time as my 
> previous one, but I believe it is two separate issues, so I created a different thread.
> 
> When building 1.0.2g and attempting to remove some ciphers at build 
> time ("no-idea"), I discovered that the Make scripting was attempting 
> to build some of its files anyway:
> 
> [...]
> gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC 
> -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN 
> -DHAVE_DLFCN_H -O2 -g
> -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector 
> -funwind-tables -fasynchronous-unwind-tables -std=gnu99 
> -Wa,--noexecstack -fomit-frame-pointer -DTERMIO -DPURIFY 
> -DSSL_FORBID_ENULL -D_GNU_SOURCE -fstack-protector -Wall 
> -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m 
> -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM   -c -o e_bf.o e_bf.c
> make[2]: *** No rule to make target `../../include/openssl/idea.h', 
> needed by `e_idea.o'.  Stop.
> make[2]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto/evp'
> make[1]: *** [subdirs] Error 1
> make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto'
> make: *** [build_crypto] Error 1
> 
> It looks as though the "no-idea" removes some of the header files from 
> the build, but then the make tries to compile the .c files anyway.
> 
> Has anyone else encountered this problem?
> 

Make sure you have run "make depend", i.e.

$ ./config no-idea
$ make depend
$ make
$ make test

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

From winer632 at qq.com  Thu Mar 24 04:37:16 2016
From: winer632 at qq.com (=?gb18030?B?d2luZXI2MzI=?=)
Date: Thu, 24 Mar 2016 12:37:16 +0800
Subject: [openssl-users] undefined symbol: SSL_SESSION_hash
Message-ID: <tencent_359A707216DF50C35F8C45DD@qq.com>

Hello ?

I am using openssl in OpenImsCore project to enable tls feature. But when I run pcscf I met this problem  "undefined symbol: SSL_SESSION_hash".

More information is here:

[root at iZ23djkgcm2Z wangxx]# cat /etc/redhat-release 
CentOS Linux release 7.2.1511 (Core) 
[root at iZ23djkgcm2Z wangxx]#

[root at iZ23djkgcm2Z wangxx]# tar -xzvf openssl-OpenSSL_1_0_1s.tar.gz
[root at iZ23djkgcm2Z wangxx]# cd /home/wangxx/openssl-OpenSSL_1_0_1s
[root at iZ23djkgcm2Z wangxx]# ./config shared --prefix=/usr/local --openssldir=/usr/local/openssl && make && make install

There is no symbol SSL_SESSION_hash in openssl-1.0.* however SSL_SESSION_hash exists in openssl-0.9.8*. See below.

[root at iZ23djkgcm2Z tls]# nm /home/wangxx/openssl-OpenSSL_1_0_1s/libssl.so.1.0.0 | grep SSL_SESSION_hash
[root at iZ23djkgcm2Z tls]#

[root at iZ23djkgcm2Z tls]# nm /home/wangxx/openssl-OpenSSL_0_9_8e/libssl.so.0.9.8 | grep SSL_SESSION_hash
000000000002e450 T SSL_SESSION_hash
000000000002e480 t SSL_SESSION_hash_LHASH_HASH
[root at iZ23djkgcm2Z tls]#

Is the method SSL_SESSION_hash depricated? If so what method should I use to replace it?

The code is like this:

/**

get TLS Session Hash
@param msg - sip msg received over a TLS secure connection
@returns session_hash or 0 in case of error
/
unsigned long get_tls_session_hash(struct sip_msg msg, char str1, char str2)
{
struct tcp_connection c;
struct tls_extra_data extra;
SSL_SESSION *ssl_ses;
unsigned long ses_hash;

if (msg->rcv.proto != PROTO_TLS) {
ERR("get_tls_session_hash: No TLS connection !\n");
return 0;
}
c = tcpconn_get(msg->rcv.proto_reserved1, 0, 0, tls_con_lifetime);
if (c && c->type != PROTO_TLS) {
ERR("get_tls_session_hash: Connection found but is not TLS !\n");
tcpconn_put(c);
return 0;
}

if (!c || !c->extra_data) {
ERR("get_tls_session_hash: Unable to extract SSL data from TLS connection!\n");
return 0;
}
extra = (struct tls_extra_data*)c->extra_data;

ssl_ses = SSL_get_session(extra->ssl) ;
if (!ssl_ses)
{
ERR("get_tls_session_hash: No ssl session found !\n");
tcpconn_put(c);
return 0;
}
ses_hash = SSL_SESSION_hash(ssl_ses);

tcpconn_put(c);
return ses_hash;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160324/fa97354d/attachment-0001.html>

From zj at zakjan.cz  Thu Mar 24 06:43:47 2016
From: zj at zakjan.cz (=?UTF-8?B?SmFuIMW9w6Fr?=)
Date: Thu, 24 Mar 2016 10:43:47 +0400
Subject: [openssl-users] Master thesis: implementation of a new ciphersuite
 into OpenSSL -- feedback wanted
Message-ID: <CAGCqA4sE1Pmmeo15xa9giPZPGjXany24b8_GfDtULmSZ2VvyhQ@mail.gmail.com>

Hi,

Last year I successfully finished my Master studies at Czech Technical
University by a thesis defense about implementing a new CAESAR ciphersuite
(specifically with NORX, but not restricted to it) into OpenSSL. I was
supervised by prof. Wu Hongjun from Nangyang Technological University,
Singapore, a member of CAESAR comitee.

https://dl.dropboxusercontent.com/u/433404/DP_Zak_Jan_2015.pdf

I'd be really grateful for a feedback from any member of this mailing list.


Sincerely,

Jan Zak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160324/c2f8de8f/attachment.html>

From noloader at gmail.com  Thu Mar 24 06:49:53 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 24 Mar 2016 02:49:53 -0400
Subject: [openssl-users] Master thesis: implementation of a new
 ciphersuite into OpenSSL -- feedback wanted
In-Reply-To: <CAGCqA4sE1Pmmeo15xa9giPZPGjXany24b8_GfDtULmSZ2VvyhQ@mail.gmail.com>
References: <CAGCqA4sE1Pmmeo15xa9giPZPGjXany24b8_GfDtULmSZ2VvyhQ@mail.gmail.com>
Message-ID: <CAH8yC8=6R9_q=aA-_fq4C07Z9y7DUPgjeQCm-Quo1LXxkZWOsg@mail.gmail.com>

> Last year I successfully finished my Master studies at Czech Technical
> University by a thesis defense about implementing a new CAESAR ciphersuite
> (specifically with NORX, but not restricted to it) into OpenSSL. I was
> supervised by prof. Wu Hongjun from Nangyang Technological University,
> Singapore, a member of CAESAR comitee.

Congratulations. That's quite an accomplishment.

> https://dl.dropboxusercontent.com/u/433404/DP_Zak_Jan_2015.pdf
>
> I'd be really grateful for a feedback from any member of this mailing list.

What type of feedback are you looking for?

Jeff

From zj at zakjan.cz  Thu Mar 24 07:09:03 2016
From: zj at zakjan.cz (=?UTF-8?B?SmFuIMW9w6Fr?=)
Date: Thu, 24 Mar 2016 11:09:03 +0400
Subject: [openssl-users] Master thesis: implementation of a new
 ciphersuite into OpenSSL -- feedback wanted
In-Reply-To: <CAH8yC8=6R9_q=aA-_fq4C07Z9y7DUPgjeQCm-Quo1LXxkZWOsg@mail.gmail.com>
References: <CAGCqA4sE1Pmmeo15xa9giPZPGjXany24b8_GfDtULmSZ2VvyhQ@mail.gmail.com>
 <CAH8yC8=6R9_q=aA-_fq4C07Z9y7DUPgjeQCm-Quo1LXxkZWOsg@mail.gmail.com>
Message-ID: <CAGCqA4vtcy4UE_cW-ynJY0O+ok-0OxbzA=1zpp_+Mdf7tOPJwA@mail.gmail.com>

> What type of feedback are you looking for?

If I understood and used the OpenSSL API correctly, with respect to crypto
development best practices (e.g. constant time operations).

I have generic C programming experience, but crypto was new for me. The
important pieces of the new code is there in the text. I can provide the
complete source code diff. I just do not want to publish it, because it was
just my learning exercise, and it is not suitable for production use at all.

Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160324/84fc969f/attachment.html>

From mydexterid at gmail.com  Thu Mar 24 08:21:48 2016
From: mydexterid at gmail.com (DEXTER)
Date: Thu, 24 Mar 2016 09:21:48 +0100
Subject: [openssl-users] X509_verify_cert cannot be called twice
Message-ID: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>

Hi!

So this patch:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b3b1eb5735c5b3d566a9fc3bf745bf716a29afa0

magically made itself into ubuntu trusty's version of openssl in a
security update.

My question is:

What is the recommended way now to call X509_verify_cert twice or
unlimited times from SSL_CTX_set_cert_verify_callback callback.
(This is where the ctx is already initialized by openssl and not by the user)

Thanks.

From mydexterid at gmail.com  Thu Mar 24 08:21:48 2016
From: mydexterid at gmail.com (DEXTER)
Date: Thu, 24 Mar 2016 09:21:48 +0100
Subject: [openssl-users] X509_verify_cert cannot be called twice
Message-ID: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>

Hi!

So this patch:
https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b3b1eb5735c5b3d566a9fc3bf745bf716a29afa0

magically made itself into ubuntu trusty's version of openssl in a
security update.

My question is:

What is the recommended way now to call X509_verify_cert twice or
unlimited times from SSL_CTX_set_cert_verify_callback callback.
(This is where the ctx is already initialized by openssl and not by the user)

Thanks.

From alex at zadarastorage.com  Thu Mar 24 12:20:19 2016
From: alex at zadarastorage.com (Alex Lyakas)
Date: Thu, 24 Mar 2016 14:20:19 +0200
Subject: [openssl-users] SHA1_Update() call leads to segfault
Message-ID: <9EA47A19799A40C4A895E02A6E236633@alyakaslap>

Greetings openssl-users,

We had several segmentation faults, all starting from SHA1_Update() call.
See [1], [2] and [3].

Some details:

We are using libcurl to send HTTPS requests to Amazon S3 service. We are
using  "curl_multi" handles to submit and track these HTTPS requests.

The problem happens on a virtual machine running Ubuntu Precise 12.04
distribution, but with a different kernel (mainline 3.8.13). Versions of
relevant user-space packages are below:

ii  libgcrypt11                         1.5.0-3ubuntu0.4                LGPL
Crypto library - runtime library
ii  libgcrypt11-dev                     1.5.0-3ubuntu0.4                LGPL
Crypto library - development files
ii  libhcrypto4-heimdal                 1.6~git20120311.dfsg.1-2
Heimdal Kerberos - crypto library
ii  libk5crypto3                        1.10+dfsg~beta1-2ubuntu0.6      MIT
Kerberos runtime libraries - Crypto Library
ii  libgnutls-openssl27                 2.12.14-5ubuntu3.9              GNU
TLS library - OpenSSL wrapper
ii  libssl-dev                          1.0.1-4ubuntu5.31               SSL
development libraries, header files and documentation
ii  libssl1.0.0                         1.0.1-4ubuntu5.31               SSL
shared libraries
ii  libsslcommon2                       0.14-2
enterprise messaging system - common SSL libraries
ii  openssl                             1.0.1-4ubuntu5.31
Secure Socket Layer (SSL) binary and related cryptographic tools
ii  python-openssl                      0.12-1ubuntu2
Python wrapper around the OpenSSL library

We do not have a reliable reproducer for this issue. It happened once in our
lab, and three more times in the field, all during about 6 months that we
started using libcurl.

Is anybody perhaps familiar with such issue or can give a recommendation of
how to proceed?

Thanks,
Alex.

[1]
#0  0x00007f6b82cb14d0 in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1  0xca62c1d6ca62c1d6 in ?? ()
#2  0xca62c1d6ca62c1d6 in ?? ()
#3  0xca62c1d6ca62c1d6 in ?? ()
#4  0xca62c1d6ca62c1d6 in ?? ()
#5  0xca62c1d6ca62c1d6 in ?? ()
#6  0xca62c1d6ca62c1d6 in ?? ()
#7  0xca62c1d6ca62c1d6 in ?? ()
#8  0xca62c1d6ca62c1d6 in ?? ()
#9  0x00007f6b8301c929 in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#10 0x00007f6b341e8b30 in ?? ()
#11 0x0000000000000016 in ?? ()
#12 0x00007f6b82cad900 in SHA1_Update () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#13 0x00007f6b82d2fe0f in RAND_load_file () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#14 0x00007f6b85488a85 in curl_multi_perform () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#15 0x00000000007248db in __engine_run_requests (eng=0x7f6b54154310) at
common/lib/zobjstore_access.c:1816
#16 0x0000000000722b9b in engine_loop (arg=0x7f6b54154310) at
common/lib/zobjstore_access.c:1534
#17 0x00000000007101b9 in zthread_start_routine (arg=0x7f6b54154330) at
common/lib/zthread.c:118
#18 0x00007f6b85033e9a in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
#19 0x00007f6b8311338d in epoll_wait () from /lib/x86_64-linux-gnu/libc.so.6
#20 0x0000000000000000 in ?? ()

[2]
#0  0x00007f4a322284d0 in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1  0xca62c1d6ca62c1d6 in ?? ()
#2  0xca62c1d6ca62c1d6 in ?? ()
#3  0xca62c1d6ca62c1d6 in ?? ()
#4  0xca62c1d6ca62c1d6 in ?? ()
#5  0xca62c1d6ca62c1d6 in ?? ()
#6  0xca62c1d6ca62c1d6 in ?? ()
#7  0xca62c1d6ca62c1d6 in ?? ()
#8  0xca62c1d6ca62c1d6 in ?? ()
#9  0x00007f4a3259392a in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#10 0x00007f49e50988b0 in ?? ()
#11 0x0000000000000015 in ?? ()
#12 0x00007f4a32224900 in SHA1_Update () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#13 0x00007f4a322a6e0f in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#14 0x00007f4a31519a05 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#15 0x00007f4a3150f712 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#16 0x00007f4a3150fb04 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#17 0x00007f4a34a1998e in ossl_send () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#18 0x00007f4a349e38c2 in Curl_write () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#19 0x00007f4a349f9a3f in Curl_readwrite () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#20 0x00007f4a34a01ebc in multi_runsingle () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#21 0x00007f4a34a02c55 in curl_multi_perform () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4

[3]
#0  0x00007f4acc7af4d6 in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#1  0xca62c1d6ca62c1d6 in ?? ()
#2  0xca62c1d6ca62c1d6 in ?? ()
#3  0xca62c1d6ca62c1d6 in ?? ()
#4  0xca62c1d6ca62c1d6 in ?? ()
#5  0xca62c1d6ca62c1d6 in ?? ()
#6  0xca62c1d6ca62c1d6 in ?? ()
#7  0xca62c1d6ca62c1d6 in ?? ()
#8  0xca62c1d6ca62c1d6 in ?? ()
#9  0x00007f4accb1a920 in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#10 0x00007f4aa00ff5b0 in ?? ()
#11 0x000000000000001f in ?? ()
#12 0x00007f4acc7ab900 in SHA1_Update () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#13 0x00007f4acc82de0f in ?? () from
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
#14 0x00007f4acbaa0a05 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#15 0x00007f4acba96712 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#16 0x00007f4acba96b04 in ?? () from /lib/x86_64-linux-gnu/libssl.so.1.0.0
#17 0x00007f4acefa098e in ossl_send () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#18 0x00007f4acef6a8c2 in Curl_write () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#19 0x00007f4acef66e69 in Curl_add_buffer_send () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#20 0x00007f4acef68dc9 in Curl_http () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#21 0x00007f4acef7a56b in Curl_do () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#22 0x00007f4acef89501 in multi_runsingle () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4
#23 0x00007f4acef89c55 in curl_multi_perform () from
/usr/lib/x86_64-linux-gnu/libcurl.so.4


From openssl-users at dukhovni.org  Thu Mar 24 15:17:00 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 24 Mar 2016 11:17:00 -0400
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>
References: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>
Message-ID: <A801FADC-8823-42C6-92B3-90B369792754@dukhovni.org>


> On Mar 24, 2016, at 4:21 AM, DEXTER <mydexterid at gmail.com> wrote:
> 
> So this patch:
> https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b3b1eb5735c5b3d566a9fc3bf745bf716a29afa0
> 
> magically made itself into ubuntu trusty's version of openssl in a
> security update.
> 
> My question is:
> 
> What is the recommended way now to call X509_verify_cert twice or
> unlimited times from SSL_CTX_set_cert_verify_callback callback.
> (This is where the ctx is already initialized by openssl and not by the user)

I'm afraid multiple calls are not supported.
I'll consider updating the 1.1.0 code to make that possible,
but that won't help you with 1.0.[12]...

-- 
	Viktor.


From szilard.pfeiffer at balasys.hu  Thu Mar 24 17:09:17 2016
From: szilard.pfeiffer at balasys.hu (=?UTF-8?Q?Szil=c3=a1rd_Pfeiffer?=)
Date: Thu, 24 Mar 2016 18:09:17 +0100
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <A801FADC-8823-42C6-92B3-90B369792754@dukhovni.org>
References: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>
 <A801FADC-8823-42C6-92B3-90B369792754@dukhovni.org>
Message-ID: <56F41F3D.8090506@balasys.hu>

On 2016-03-24 16:17, openssl-users at dukhovni.org (Viktor Dukhovni) wrote:
>> On Mar 24, 2016, at 4:21 AM, DEXTER <mydexterid at gmail.com> wrote:
>>
>> So this patch:
>> https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b3b1eb5735c5b3d566a9fc3bf745bf716a29afa0
>>
>> magically made itself into ubuntu trusty's version of openssl in a
>> security update.
>>
>> My question is:
>>
>> What is the recommended way now to call X509_verify_cert twice or
>> unlimited times from SSL_CTX_set_cert_verify_callback callback.
>> (This is where the ctx is already initialized by openssl and not by the user)
> I'm afraid multiple calls are not supported.
> I'll consider updating the 1.1.0 code to make that possible,
> but that won't help you with 1.0.[12]...

I am afraid the patch causes a serious compatibility break. In practice,
after an OS upgrade (which upgrades OpenSSL to the patched version) each
and every application, which calls the X509_verify_cert function
multiple times without reinitialization, gets an error
(ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED) which may or may not be handled
properly. It leads to undefined behavior of the application.

According to the OpenSSL versioning scheme, a minor release should not
break the binary compatibility.

"After the release of OpenSSL 1.0.0 the versioning scheme changed.
Letter releases (e.g. 1.0.1a) can only contain bug and security fixes
and no new features. Minor releases change the last number (e.g. 1.0.2)
and can contain new features that retain binary compatibility."

IMHO the patch in question breaks the API implicitly, as it causes a
restriction which didn't exist at the time of development. Please
consider retaining the compatibility in version 1.0 to avoid the
possible problems mentioned above.

Best regards,
Szil?rd Pfeiffer


From openssl-users at dukhovni.org  Thu Mar 24 17:22:04 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 24 Mar 2016 13:22:04 -0400
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <56F41F3D.8090506@balasys.hu>
References: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>
 <A801FADC-8823-42C6-92B3-90B369792754@dukhovni.org>
 <56F41F3D.8090506@balasys.hu>
Message-ID: <5DA709FD-297A-4082-96BC-DC357EDD73CB@dukhovni.org>


> On Mar 24, 2016, at 1:09 PM, Szil?rd Pfeiffer <szilard.pfeiffer at balasys.hu> wrote:
> 
> I am afraid the patch causes a serious compatibility break. In practice,
> after an OS upgrade (which upgrades OpenSSL to the patched version) each
> and every application, which calls the X509_verify_cert function
> multiple times without reinitialization, gets an error
> (ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED) which may or may not be handled
> properly. It leads to undefined behavior of the application.

No the patch catches undefined behaviour, and returns an error.

-- 
	Viktor.


From uri at ll.mit.edu  Thu Mar 24 17:28:25 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 24 Mar 2016 17:28:25 +0000
Subject: [openssl-users] RDRAND and engine (was: how to generate EC
 public key from EC private key)
In-Reply-To: <CAH8yC8mnS2wSei+1EqG_3_m-GTTyiD2eYPuu30TQo8KP9nZJfQ@mail.gmail.com>
References: <CAH8yC8n3uk39J1-f1E_2sSYGScOGW-5AXmvqzAWCrQXYcHtyCw@mail.gmail.com>
 <CAH8yC8mnS2wSei+1EqG_3_m-GTTyiD2eYPuu30TQo8KP9nZJfQ@mail.gmail.com>
Message-ID: <D3199B26.29483%uri@ll.mit.edu>

Thank you - employing the pointers (no pun intended :) that you gave, the
code now is doing exactly what?s needed, and utilizes RDRAND (as required
by the specs I have, and my personal preferences as well).

>	set the default RAND_method to the engine


This is what I did not do originally - fixed now.

P.S. I wonder if there?s a way for the application (that did NOT set the
environment by itself - think a function or a module called by somebody
else) can verify that, e.g., RAND_METHOD is what it wants (say, RDRAND in
my case), rather than what it is NOT (e.g., not RAND_SSLeay()).
-- 
Regards,
Uri Blumenthal





On 3/22/16, 20:11 , "openssl-users on behalf of Jeffrey Walton"
<openssl-users-bounces at openssl.org on behalf of noloader at gmail.com> wrote:

>On Tue, Mar 22, 2016 at 6:54 PM, Jeffrey Walton <noloader at gmail.com>
>wrote:
>>> Now one small question: how do I ensure that ?RAND_engine (and
>>>therefore Intel RDRAND output) is being used for the key generation in
>>>    EVP_PKEY_keygen(ctx, &newkey);
>>>
>>> Is just loading RAND_engine enough for that??
>>> ?
>>
>> To verify it, I think you need to inspect the default RAND method. Its
>> going to look something like:
>>
>>   RAND_METHOD* rm = RAND_get_rand_method();
>>   if(rm == RAND_SSLeay())
>>   {
>>       printf("Using default generator\n");
>>   }
>>
>> Also see https://wiki.openssl.org/index.php/Random_Numbers#Generators.
>> RDRAND is discussed there, too. But I don't recall how much detail is
>> provided.
>
>Ah, its right there. I should have checked earlier
>(http://wiki.openssl.org/index.php/Random_Numbers#Hardware):
>
>To ensure RAND_bytes uses the [RDRAND] hardware engine, you must
>perform three steps:
>
>   * load the rdrand engine
>   * acquire a handle to the engine
>   * set the default RAND_method to the engine
>
>It also provides the sample code.
>
>Jeff
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160324/9d2abbae/attachment.bin>

From steve at openssl.org  Thu Mar 24 17:35:55 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Thu, 24 Mar 2016 17:35:55 +0000
Subject: [openssl-users] [openssl-dev] Low level API call to digest SHA1
 forbidden in FIPS mode - within openssl code
In-Reply-To: <6D4F4080B6BD2B4F9F5955C645671A1FA98AE1A0@otwlxg23.opentext.net>
References: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
 <56F2F30D.6060207@oracle.com>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98AE1A0@otwlxg23.opentext.net>
Message-ID: <20160324173555.GA8293@openssl.org>

On Wed, Mar 23, 2016, Glen Matthews wrote:

> Hi
> 
> Right, sorry about the wrong posting - and thanks.
> 
> The message is correct - we got this in the 1.0.2f tree and are still getting in in the 1.0.2g tree.
> 
> I notice that in crypto\x509v3\v3_purp.c there is this:
> 
>     if (x->ex_flags & EXFLAG_SET)
>         return;
> #ifndef OPENSSL_NO_SHA
>     X509_digest(x, EVP_sha1(), x->sha1_hash, NULL);
> #endif
> 
> We haven't disabled SHA1 because we need it for our ssh implementation. From what I've been reading, the code should not be calling with EVP_sha1().
> 

Is this a standard OpenSSL build or has it been modified in some way?

At what point do you enter FIPS mode?

The above call should be routed through to the SHA1 implementation in the
validated module. It's not clear why not at this point.

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

From glenm at opentext.com  Thu Mar 24 17:55:24 2016
From: glenm at opentext.com (Glen Matthews)
Date: Thu, 24 Mar 2016 17:55:24 +0000
Subject: [openssl-users] [openssl-dev] Low level API call to digest SHA1
 forbidden in FIPS mode - within openssl code
In-Reply-To: <20160324173555.GA8293@openssl.org>
References: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
 <56F2F30D.6060207@oracle.com>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98AE1A0@otwlxg23.opentext.net>
 <20160324173555.GA8293@openssl.org>
Message-ID: <6D4F4080B6BD2B4F9F5955C645671A1FA98BAE5A@otwlxg23.opentext.net>

Hi

Yes it's a standard build. FIPS 2.0 with openssl 1.0.2g - I took a dump when the dialog box was displayed, and that's how I got the call stack. 

    if (x->ex_flags & EXFLAG_SET)
        return;
#ifndef OPENSSL_NO_SHA
    X509_digest(x, EVP_sha1(), x->sha1_hash, NULL);
#endif

I inspected the values in x509v3_cache_extensions() - the code above is from the beginning of it - and the test fails, so we drop down into the digest call.

glen

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 24, 2016 1:36 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Low level API call to digest SHA1 forbidden in FIPS mode - within openssl code

On Wed, Mar 23, 2016, Glen Matthews wrote:

> Hi
> 
> Right, sorry about the wrong posting - and thanks.
> 
> The message is correct - we got this in the 1.0.2f tree and are still getting in in the 1.0.2g tree.
> 
> I notice that in crypto\x509v3\v3_purp.c there is this:
> 
>     if (x->ex_flags & EXFLAG_SET)
>         return;
> #ifndef OPENSSL_NO_SHA
>     X509_digest(x, EVP_sha1(), x->sha1_hash, NULL); #endif
> 
> We haven't disabled SHA1 because we need it for our ssh implementation. From what I've been reading, the code should not be calling with EVP_sha1().
> 

Is this a standard OpenSSL build or has it been modified in some way?

At what point do you enter FIPS mode?

The above call should be routed through to the SHA1 implementation in the validated module. It's not clear why not at this point.

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

From mydexterid at gmail.com  Thu Mar 24 18:02:27 2016
From: mydexterid at gmail.com (DEXTER)
Date: Thu, 24 Mar 2016 19:02:27 +0100
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <A801FADC-8823-42C6-92B3-90B369792754@dukhovni.org>
References: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>
 <A801FADC-8823-42C6-92B3-90B369792754@dukhovni.org>
Message-ID: <56F42BB3.5020105@gmail.com>

So let me get this straight.
If someone had a software where they called X509_verify_cert from
SSL_CTX_set_cert_verify_callback callback twice (to verify first with
crls, and maybe verify again without crls) and it worked as expected,
after this patch their software is broken.

Am I right?

And there is no solution to this after the patch for 1.0.[12]

Am I right?

On 2016.03.24. 16:17, Viktor Dukhovni wrote:
> 
>> On Mar 24, 2016, at 4:21 AM, DEXTER <mydexterid at gmail.com> wrote:
>>
>> So this patch:
>> https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=b3b1eb5735c5b3d566a9fc3bf745bf716a29afa0
>>
>> magically made itself into ubuntu trusty's version of openssl in a
>> security update.
>>
>> My question is:
>>
>> What is the recommended way now to call X509_verify_cert twice or
>> unlimited times from SSL_CTX_set_cert_verify_callback callback.
>> (This is where the ctx is already initialized by openssl and not by the user)
> 
> I'm afraid multiple calls are not supported.
> I'll consider updating the 1.1.0 code to make that possible,
> but that won't help you with 1.0.[12]...
> 

From openssl-users at dukhovni.org  Thu Mar 24 18:12:49 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 24 Mar 2016 14:12:49 -0400
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <56F42BB3.5020105@gmail.com>
References: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>
 <A801FADC-8823-42C6-92B3-90B369792754@dukhovni.org>
 <56F42BB3.5020105@gmail.com>
Message-ID: <C31C1580-746E-4DB0-B61A-E2F2CAB4ED23@dukhovni.org>


> On Mar 24, 2016, at 2:02 PM, DEXTER <mydexterid at gmail.com> wrote:
> 
> So let me get this straight.
> If someone had a software where they called X509_verify_cert from
> SSL_CTX_set_cert_verify_callback callback twice (to verify first with
> crls, and maybe verify again without crls) and it worked as expected,
> after this patch their software is broken.

If they re-used the same X509_STORE_CTX, yes their software depended
on undefined and likely insecure behaviour.  "Worked as expected" is
likely more along the lines of "did not appear to fail".  Verification
is not only expected to succeed for valid chains, but is also expected
to reliably fail for invalid chains.

-- 
	Viktor.


From glenm at opentext.com  Thu Mar 24 18:33:07 2016
From: glenm at opentext.com (Glen Matthews)
Date: Thu, 24 Mar 2016 18:33:07 +0000
Subject: [openssl-users] [openssl-dev] Low level API call to digest SHA1
 forbidden in FIPS mode - within openssl code
References: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
 <56F2F30D.6060207@oracle.com>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98AE1A0@otwlxg23.opentext.net>
 <20160324173555.GA8293@openssl.org> 
Message-ID: <6D4F4080B6BD2B4F9F5955C645671A1FA98BAFD3@otwlxg23.opentext.net>

When FIPS is enabled: missed that. We enable it when we load the modules - we're in a mode where we only have the FIPS libraries installed, and when we load them, we enable FIPS. In searching for a temporary work-around, I put different code at that place in x509v3_cache_extensions() - calculating another digest at that point - and the test for FIPS_mode() worked, so I think we are in FIPS mode all through that call stack.

glen

-----Original Message-----
From: Glen Matthews 
Sent: Thursday, March 24, 2016 1:55 PM
To: 'openssl-users at openssl.org'
Subject: RE: [openssl-users] [openssl-dev] Low level API call to digest SHA1 forbidden in FIPS mode - within openssl code

Hi

Yes it's a standard build. FIPS 2.0 with openssl 1.0.2g - I took a dump when the dialog box was displayed, and that's how I got the call stack. 

    if (x->ex_flags & EXFLAG_SET)
        return;
#ifndef OPENSSL_NO_SHA
    X509_digest(x, EVP_sha1(), x->sha1_hash, NULL); #endif

I inspected the values in x509v3_cache_extensions() - the code above is from the beginning of it - and the test fails, so we drop down into the digest call.

glen

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dr. Stephen Henson
Sent: Thursday, March 24, 2016 1:36 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] [openssl-dev] Low level API call to digest SHA1 forbidden in FIPS mode - within openssl code

On Wed, Mar 23, 2016, Glen Matthews wrote:

> Hi
> 
> Right, sorry about the wrong posting - and thanks.
> 
> The message is correct - we got this in the 1.0.2f tree and are still getting in in the 1.0.2g tree.
> 
> I notice that in crypto\x509v3\v3_purp.c there is this:
> 
>     if (x->ex_flags & EXFLAG_SET)
>         return;
> #ifndef OPENSSL_NO_SHA
>     X509_digest(x, EVP_sha1(), x->sha1_hash, NULL); #endif
> 
> We haven't disabled SHA1 because we need it for our ssh implementation. From what I've been reading, the code should not be calling with EVP_sha1().
> 

Is this a standard OpenSSL build or has it been modified in some way?

At what point do you enter FIPS mode?

The above call should be routed through to the SHA1 implementation in the validated module. It's not clear why not at this point.

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

From szilard.pfeiffer at balasys.hu  Thu Mar 24 20:21:41 2016
From: szilard.pfeiffer at balasys.hu (=?UTF-8?Q?Szil=C3=A1rd_Pfeiffer?=)
Date: Thu, 24 Mar 2016 21:21:41 +0100
Subject: [openssl-users]
 =?utf-8?q?X509=5Fverify=5Fcert_cannot_be_called_t?= =?utf-8?q?wice?=
In-Reply-To: <C31C1580-746E-4DB0-B61A-E2F2CAB4ED23@dukhovni.org>
References: <CAPPoDdrmntH3GqUKeg1Ke=NkYmLQxyvg57Q8Fhgd0tzv5=xJTA@mail.gmail.com>
 <A801FADC-8823-42C6-92B3-90B369792754@dukhovni.org>
 <56F42BB3.5020105@gmail.com>
 <C31C1580-746E-4DB0-B61A-E2F2CAB4ED23@dukhovni.org>
Message-ID: <9752c73c457cce60eb77613d4aaad99c@balasys.hu>

On 2016-03-24 19:12, Viktor Dukhovni wrote:
>> On Mar 24, 2016, at 2:02 PM, DEXTER <mydexterid at gmail.com> wrote:
>> 
>> So let me get this straight.
>> If someone had a software where they called X509_verify_cert from
>> SSL_CTX_set_cert_verify_callback callback twice (to verify first with
>> crls, and maybe verify again without crls) and it worked as expected,
>> after this patch their software is broken.
> 
> If they re-used the same X509_STORE_CTX, yes their software depended
> on undefined and likely insecure behaviour.  "Worked as expected" is
> likely more along the lines of "did not appear to fail".  Verification
> is not only expected to succeed for valid chains, but is also expected
> to reliably fail for invalid chains.
> 

You are absolutely right in your last sentence, but an application which 
should have expected (before the patch) that it does not get the error 
code ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED, as it was permitted (according 
to the documentation) to call the X509_verify_cert more than once. IMHO 
an API compatible fix (1.0.1p was a security update) should consider 
this, otherwise the undefined behavior shifted from the library to the 
application.

The problem what I try to explain is not just a theory. Consider the 
situation when a function in an application tries to verify a 
certificate by calling X509_verify_cert twice with different parameters 
(it is a questionable, but a permitted way) during the handshake. It 
works very well before the patch. After the patch the second call 
returns error, so the function also returns error and the SSL handshake 
fails. So a security update contains the patch breaks the application.

Szil?rd





From uri at ll.mit.edu  Thu Mar 24 20:36:34 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 24 Mar 2016 20:36:34 +0000
Subject: [openssl-users] X509_verify_cert cannot be called twice
Message-ID: <20160324203642.18296912.74642.59772@ll.mit.edu>

I'm sure I'm missing something obvious, but why isn't the operation XXX_verify_xxx() idempotent? It seems very weird that two subsequent calls to verify() wouldn't return exactly the same thing.

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Szil?rd Pfeiffer
Sent: Thursday, March 24, 2016 16:21
To: openssl-users at openssl.org
Reply To: openssl-users at openssl.org
Subject: Re: [openssl-users] X509_verify_cert cannot be called twice

On 2016-03-24 19:12, Viktor Dukhovni wrote:
>> On Mar 24, 2016, at 2:02 PM, DEXTER <mydexterid at gmail.com> wrote:
>> 
>> So let me get this straight.
>> If someone had a software where they called X509_verify_cert from
>> SSL_CTX_set_cert_verify_callback callback twice (to verify first with
>> crls, and maybe verify again without crls) and it worked as expected,
>> after this patch their software is broken.
> 
> If they re-used the same X509_STORE_CTX, yes their software depended
> on undefined and likely insecure behaviour. "Worked as expected" is
> likely more along the lines of "did not appear to fail". Verification
> is not only expected to succeed for valid chains, but is also expected
> to reliably fail for invalid chains.
> 

You are absolutely right in your last sentence, but an application which 
should have expected (before the patch) that it does not get the error 
code ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED, as it was permitted (according 
to the documentation) to call the X509_verify_cert more than once. IMHO 
an API compatible fix (1.0.1p was a security update) should consider 
this, otherwise the undefined behavior shifted from the library to the 
application.

The problem what I try to explain is not just a theory. Consider the 
situation when a function in an application tries to verify a 
certificate by calling X509_verify_cert twice with different parameters 
(it is a questionable, but a permitted way) during the handshake. It 
works very well before the patch. After the patch the second call 
returns error, so the function also returns error and the SSL handshake 
fails. So a security update contains the patch breaks the application.

Szil?rd




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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160324/d9b6ca65/attachment.bin>

From Michael.Wojcik at microfocus.com  Fri Mar 25 20:10:17 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 25 Mar 2016 20:10:17 +0000
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <20160324203642.18296912.74642.59772@ll.mit.edu>
References: <20160324203642.18296912.74642.59772@ll.mit.edu>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DC96958@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Blumenthal, Uri - 0553 - MITLL
> Sent: Thursday, March 24, 2016 16:37
> 
> I'm sure I'm missing something obvious, but why isn't the operation
> XXX_verify_xxx() idempotent? It seems very weird that two subsequent
> calls to verify() wouldn't return exactly the same thing.

Viktor already alluded to why it's not idempotent, and if you look through the relevant code for a bit I think you can see why. The short answer is that it uses the (verification) context to keep a lot of state. When it finishes, the context is no longer in a state that's suitable for restarting the verification process, as currently implemented.

It can be quite illuminating, if tiresome, to step through the verification of a non-trivial chain in the OpenSSL 1.0.1 code. (I haven't tried it in other versions; maybe it's more readable in 1.1.0, with more-meaningful identifier names and the like, but there's a limit to how much it could be streamlined.) It's been over a year since I last did this, but if memory serves, part of what it does is, as certificates are verified, it adds them to a "now trusted" list. Perhaps calling verify again could produce a false verify-OK because OpenSSL will stop checking when it hits one of those, and not find a verification failure further along the chain.

So while it might seem like verify *ought to* be idempotent, in fact it represents a substantial transformation on the context which the existing code cannot reverse. That doesn't actually strike me as all that strange, to be honest. The OpenSSL API in effect boils down to: prepare for verification, perform verification, clean up verification. I don't see anything that implies the middle step wouldn't irreversibly change state.

-- 
Michael Wojcik
Technology Specialist, Micro Focus


From uri at ll.mit.edu  Fri Mar 25 20:56:32 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Fri, 25 Mar 2016 20:56:32 +0000
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015DC96958@Rock-Exchange1.microfocus.com>
References: <20160324203642.18296912.74642.59772@ll.mit.edu>
 <B550B44BF8AF314BB00C4E2AC1C18088015DC96958@Rock-Exchange1.microfocus.com>
Message-ID: <D31B1636.295DD%uri@ll.mit.edu>

On 3/25/16, 16:10 , "openssl-users on behalf of Michael Wojcik"
<openssl-users-bounces at openssl.org on behalf of
Michael.Wojcik at microfocus.com> wrote:


>>I'm sure I'm missing something obvious, but why isn't the operation
>> XXX_verify_xxx() idempotent? It seems very weird that two subsequent
>> calls to verify() wouldn't return exactly the same thing.
>
>Viktor already alluded to why it's not idempotent, and if you look
>through the relevant code for a bit I think you can see why. The short
>answer is that it uses the (verification) context to keep a lot of state.
>When it finishes, the context is no longer in a state that's suitable for
>restarting the verification process, as currently implemented.

I think the keywords here are ?as currently implemented?. I have no
problem accepting Viktor?s and your answers why *the current
implementation* behaves the way it does. But why is it not re-implemented
in a friendlier way?

>...
>So while it might seem like verify *ought to* be idempotent, in fact it
>represents a substantial transformation on the context which the existing
>code cannot reverse. That doesn't actually strike me as all that strange,
>to be honest. The OpenSSL API in effect boils down to: prepare for
>verification, perform verification, clean up verification. I don't see
>anything that implies the middle step wouldn't irreversibly change state.

Perhaps these three stages could/should be wrapped into a single API that
*internally* does these three steps? Especially since it does not look
like any of those steps can be re-used on its own?

As for ?nothing implies..." - usually people assume that operations like
?read?, ?verify? (unlike ?write?, ?set?), do not change the state of the
object involved. 

If I ask ?if your passport valid?, I expect to be able to repeat this
question and (as long as this all is within a reasonably short time) get
exactly the same answer.

Although once the current state of the API is explained, I?m happy enough
to just use all the three steps if/when cert verification is needed.
Documentation seems reasonably clear:

The negative return value from X509_verify_cert() can only occur if no
certificate is set in ctx (due to a programming error); if
X509_verify_cert() twice without reinitialising ctx in between; or if a
retry operation is requested during internal lookups (which never happens
with standard lookup methods). It is however recommended that application
check for <= 0 return value on error.


But reference (URL) to ?verify? page
(https://www.openssl.org/docs/manmaster/crypto/verify.html) is broken:

The requested URL /docs/manmaster/crypto/verify.html was not found on this
server.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160325/86cd660e/attachment-0001.bin>

From openssl-users at dukhovni.org  Fri Mar 25 21:17:17 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 25 Mar 2016 21:17:17 +0000
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <D31B1636.295DD%uri@ll.mit.edu>
References: <20160324203642.18296912.74642.59772@ll.mit.edu>
 <B550B44BF8AF314BB00C4E2AC1C18088015DC96958@Rock-Exchange1.microfocus.com>
 <D31B1636.295DD%uri@ll.mit.edu>
Message-ID: <20160325211717.GU6602@mournblade.imrryr.org>

On Fri, Mar 25, 2016 at 08:56:32PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> If I ask ?if your passport valid?, I expect to be able to repeat this
> question and (as long as this all is within a reasonably short time) get
> exactly the same answer.

The result of X509_verify_cert() is not just a single error value.

    1.  It constructs the verified chain.
    2.  It determines a verified peername.
    3.  In master with DANE it determines the matching TLSA record and
	chain certificate.
    4.  It computes the policy tree and makes policy callbacks.
    5.  It calls application verify callbacks that may have side effects.

It you call X509_verify_cert() twice, and the first call succeeds,
but the second fails, the side-effects seen by the application
(especially the TLS layer) will not match the final outcome.  If
the second pass is always the valid one, what's the point of the
first?

Whatever is motivating the desire to call X509_verify_cert() twice
is likely some deficiency (whether actual or perceived) in the
current functionality, and we should probably address the underlying
problem and the not the superficial symptoms.

> Although once the current state of the API is explained, I?m happy enough
> to just use all the three steps if/when cert verification is needed.
> Documentation seems reasonably clear:

If you're doing this in the context of SSL, the SSL layer configures
the X509_STORE_CTX with various parameters beyond just
X509_STORE_CTX_init(), and using your own fresh context will not
work well.

-- 
	Viktor.

From satya at attivonetworks.com  Fri Mar 25 21:45:11 2016
From: satya at attivonetworks.com (Satya Das)
Date: Fri, 25 Mar 2016 21:45:11 +0000
Subject: [openssl-users] Binaries exit with signature bytes
Message-ID: <BL2PR07MB24046622F646EBA702705273D7830@BL2PR07MB2404.namprd07.prod.outlook.com>

Hello,

I am building a fips capable openssl package and running into a condition where all binaries exit with a signature in the stdout. As far as I can tell it is the incore hash. It seems FINGERPRINT_premain() is finding a ? in the FINGERPRINT_ascii_value and branching to exit(0).

What am I missing ?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160325/eb373f39/attachment.html>

From steve at openssl.org  Sat Mar 26 21:30:27 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 26 Mar 2016 21:30:27 +0000
Subject: [openssl-users] [openssl-dev] Low level API call to digest SHA1
 forbidden in FIPS mode - within openssl code
In-Reply-To: <6D4F4080B6BD2B4F9F5955C645671A1FA98BAE5A@otwlxg23.opentext.net>
References: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
 <56F2F30D.6060207@oracle.com>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98AE1A0@otwlxg23.opentext.net>
 <20160324173555.GA8293@openssl.org>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98BAE5A@otwlxg23.opentext.net>
Message-ID: <20160326213027.GA14197@openssl.org>

On Thu, Mar 24, 2016, Glen Matthews wrote:

> Hi
> 
> Yes it's a standard build. FIPS 2.0 with openssl 1.0.2g - I took a dump when the dialog box was displayed, and that's how I got the call stack. 
> 
>     if (x->ex_flags & EXFLAG_SET)
>         return;
> #ifndef OPENSSL_NO_SHA
>     X509_digest(x, EVP_sha1(), x->sha1_hash, NULL);
> #endif
> 
> I inspected the values in x509v3_cache_extensions() - the code above is from the beginning of it - and the test fails, so we drop down into the digest call.
> 

Something strange is going on and I'm not sure what yet. 

At he start of EVP_DigestInit_ex() the implementation should be switched to
the validated module version which then should never call the prohibited low
level calls.

When you say it's a standard build you've presumably followed the FIPS module
build instructions to the letter and produced the FIPS capable OpenSSL from
that? Is there anything unusual you are doing like using an ENGINE
for some operations?`

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

From glenm at opentext.com  Sat Mar 26 22:38:39 2016
From: glenm at opentext.com (Glen Matthews)
Date: Sat, 26 Mar 2016 22:38:39 +0000
Subject: [openssl-users] [openssl-dev] Low level API call to digest SHA1
 forbidden in FIPS mode - within openssl code
In-Reply-To: <20160326213027.GA14197@openssl.org>
References: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
 <56F2F30D.6060207@oracle.com>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98AE1A0@otwlxg23.opentext.net>
 <20160324173555.GA8293@openssl.org>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98BAE5A@otwlxg23.opentext.net>,
 <20160326213027.GA14197@openssl.org>
Message-ID: <10D1B2BC-6BB9-4AE0-BC36-137048DA050A@opentext.com>

No, nothing unusual. Is there anything from the build process that would be useful in demonstrating this yes or no? I'm not the person responsible for the build process but I'm pretty sure it was followed to the letter - however I'll check on that. Certainly no engines

I can check back in the dump and see where we are in the code in each method call

Sent from my iPhone

> On Mar 26, 2016, at 5:30 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> 
>> On Thu, Mar 24, 2016, Glen Matthews wrote:
>> 
>> Hi
>> 
>> Yes it's a standard build. FIPS 2.0 with openssl 1.0.2g - I took a dump when the dialog box was displayed, and that's how I got the call stack. 
>> 
>>    if (x->ex_flags & EXFLAG_SET)
>>        return;
>> #ifndef OPENSSL_NO_SHA
>>    X509_digest(x, EVP_sha1(), x->sha1_hash, NULL);
>> #endif
>> 
>> I inspected the values in x509v3_cache_extensions() - the code above is from the beginning of it - and the test fails, so we drop down into the digest call.
> 
> Something strange is going on and I'm not sure what yet. 
> 
> At he start of EVP_DigestInit_ex() the implementation should be switched to
> the validated module version which then should never call the prohibited low
> level calls.
> 
> When you say it's a standard build you've presumably followed the FIPS module
> build instructions to the letter and produced the FIPS capable OpenSSL from
> that? Is there anything unusual you are doing like using an ENGINE
> for some operations?`
> 
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From steve at openssl.org  Sun Mar 27 01:52:23 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sun, 27 Mar 2016 01:52:23 +0000
Subject: [openssl-users] [openssl-dev] Low level API call to digest SHA1
 forbidden in FIPS mode - within openssl code
In-Reply-To: <10D1B2BC-6BB9-4AE0-BC36-137048DA050A@opentext.com>
References: <6D4F4080B6BD2B4F9F5955C645671A1FA98ADCE4@otwlxg23.opentext.net>
 <56F2F30D.6060207@oracle.com>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98AE1A0@otwlxg23.opentext.net>
 <20160324173555.GA8293@openssl.org>
 <6D4F4080B6BD2B4F9F5955C645671A1FA98BAE5A@otwlxg23.opentext.net>
 <20160326213027.GA14197@openssl.org>
 <10D1B2BC-6BB9-4AE0-BC36-137048DA050A@opentext.com>
Message-ID: <20160327015223.GA17179@openssl.org>

On Sat, Mar 26, 2016, Glen Matthews wrote:

> No, nothing unusual. Is there anything from the build process that would be useful in demonstrating this yes or no? I'm not the person responsible for the build process but I'm pretty sure it was followed to the letter - however I'll check on that. Certainly no engines
> 
> I can check back in the dump and see where we are in the code in each method call
> 

What would be useful is tracing what happens in EVP_DigestInit_ex() during
the X509_digest() call. For example does it detect FIPS mode properly and if 
so does evp_get_fips_md() return a non-NULL value?

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

From steve at openssl.org  Sun Mar 27 01:54:01 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sun, 27 Mar 2016 01:54:01 +0000
Subject: [openssl-users] Binaries exit with signature bytes
In-Reply-To: <BL2PR07MB24046622F646EBA702705273D7830@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24046622F646EBA702705273D7830@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <20160327015401.GB17179@openssl.org>

On Fri, Mar 25, 2016, Satya Das wrote:

> 
> I am building a fips capable openssl package and running into a condition where all binaries exit with a signature in the stdout. As far as I can tell it is the incore hash. It seems FINGERPRINT_premain() is finding a ? in the FINGERPRINT_ascii_value and branching to exit(0).
> 

What platform are you building? Is it a native or cross compile?

You'd get that behaviour if fipsld isn't linking the binaries properly.

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

From jb-openssl at wisemo.com  Mon Mar 28 10:37:34 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 28 Mar 2016 12:37:34 +0200
Subject: [openssl-users] Building 1.0.2g with "no-idea"
In-Reply-To: <C58E97D22BD22F448150018085826C5101A859B7F8@NA-MBX-01.mgc.mentorg.com>
References: <BLUPR10MB07241F3AB681A3A0C37DA466C7810@BLUPR10MB0724.namprd10.prod.outlook.com>
 <56F2B401.5050306@openssl.org>
 <C58E97D22BD22F448150018085826C5101A859B7F8@NA-MBX-01.mgc.mentorg.com>
Message-ID: <56F9096E.5040008@wisemo.com>

In 1.0.2 and later, most of the files in ${BUILD_DIR}/include/openssl
are supposed to be copies/symlinks to file of the same name elsewhere
in the OpenSSL source, for instance the ones you mentions should be
links to files in subdirectories under ${BUILD_DIR}/crypt.

However in your case, I suspect the following sequence of events:

1. configure or make depend sees that you have disabled some ciphers
   and don't link header files for those ciphers.

2. Other parts of the OpenSSL source code blindly include those header
   files because they used to be present in ${BUILD_DIR}/include/openssl
   even when disabled, omitting them only (if at all) in the installed
   files under ${INSTALL_DIR}/include/openssl

If this theory holds, this would be a bug in the 1.0.2 tree, either
in the build scripts or in the source files that include headers for
disabled ciphers, whichever fix creates the smallest/simplest patch
should be applied.

On 23/03/2016 22:53, Floodeenjr, Thomas wrote:
> I have this problem too, and tried the "make depend" step. It still fails to build.
>
> make[2]: *** No rule to make target `../../include/openssl/rc4.h', needed by `eng_openssl.o'.  Stop.
>
> I worked around it by stubbing in all of the missing headers I did not need:
>
> # Stub in some missing header files since the configure appears to be broken.
> touch ${BUILD_DIR}/include/openssl/rc4.h
> touch ${BUILD_DIR}/include/openssl/blowfish.h
> touch ${BUILD_DIR}/include/openssl/idea.h
> touch ${BUILD_DIR}/include/openssl/camellia.h
> touch ${BUILD_DIR}/include/openssl/seed.h
> touch ${BUILD_DIR}/include/openssl/rc2.h
> touch ${BUILD_DIR}/include/openssl/cast.h
> touch ${BUILD_DIR}/include/openssl/md4.h
> touch ${BUILD_DIR}/include/openssl/mdc2.h
>
> This works for me.
>
> Regards,
> -Tom
>
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell
> Sent: Wednesday, March 23, 2016 9:19 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Building 1.0.2g with "no-idea"
>
>
>
> On 23/03/16 15:09, Jason Schultz wrote:
>> I am re-posting this (and another) message to the list as I was having email issues with the list and I posted an erroneous subject line, which may have deterred responses.
>>
>> I have another question that was encountered at the same time as my
>> previous one, but I believe it is two separate issues, so I created a different thread.
>>
>> When building 1.0.2g and attempting to remove some ciphers at build
>> time ("no-idea"), I discovered that the Make scripting was attempting
>> to build some of its files anyway:
>>
>> [...]
>> gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include  -fPIC
>> -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
>> -DHAVE_DLFCN_H -O2 -g
>> -m64 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector
>> -funwind-tables -fasynchronous-unwind-tables -std=gnu99
>> -Wa,--noexecstack -fomit-frame-pointer -DTERMIO -DPURIFY
>> -DSSL_FORBID_ENULL -D_GNU_SOURCE -fstack-protector -Wall
>> -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2
>> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
>> -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
>> -DECP_NISTZ256_ASM   -c -o e_bf.o e_bf.c
>> make[2]: *** No rule to make target `../../include/openssl/idea.h',
>> needed by `e_idea.o'.  Stop.
>> make[2]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto/evp'
>> make[1]: *** [subdirs] Error 1
>> make[1]: Leaving directory `/usr/src/packages/BUILD/openssl-1.0.2g/crypto'
>> make: *** [build_crypto] Error 1
>>
>> It looks as though the "no-idea" removes some of the header files from
>> the build, but then the make tries to compile the .c files anyway.
>>
>> Has anyone else encountered this problem?
>>
> Make sure you have run "make depend", i.e.
>
> $ ./config no-idea
> $ make depend
> $ make
> $ make test
>


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From uri at ll.mit.edu  Mon Mar 28 17:24:35 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 28 Mar 2016 17:24:35 +0000
Subject: [openssl-users] X509_verify_cert cannot be called twice
In-Reply-To: <20160325211717.GU6602@mournblade.imrryr.org>
References: <20160324203642.18296912.74642.59772@ll.mit.edu>
 <B550B44BF8AF314BB00C4E2AC1C18088015DC96958@Rock-Exchange1.microfocus.com>
 <D31B1636.295DD%uri@ll.mit.edu> <20160325211717.GU6602@mournblade.imrryr.org>
Message-ID: <D31EE028.296F0%uri@ll.mit.edu>

On 3/25/16, 17:17 , "openssl-users on behalf of Viktor Dukhovni"
<openssl-users-bounces at openssl.org on behalf of
openssl-users at dukhovni.org> wrote:


>>If I ask ?is your passport valid?, I expect to be able to repeat this
>> question and (as long as this all is within a reasonably short time) get
>> exactly the same answer.
>
>The result of X509_verify_cert() is not just a single error value...
>...
>Whatever is motivating the desire to call X509_verify_cert() twice
>is likely some deficiency (whether actual or perceived) in the
>current functionality, and we should probably address the underlying
>problem and the not the superficial symptoms.

I cannot comment or criticize here, because I?m not at that point (yet?).
I?m not using this functionality now, and when I do I?ll probably account
for this bit of wisdom (using the correct call sequence).

>If you're doing this in the context of SSL, the SSL layer configures
>the X509_STORE_CTX with various parameters beyond just
>X509_STORE_CTX_init(), and using your own fresh context will not
>work well.

Most likely, when I do need to use this it wouldn?t be in the context of
SSL. But I will remember this (not to use my own fresh context when using
SSL) too. ;)

Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160328/cd5326ac/attachment.bin>

From satya at attivonetworks.com  Tue Mar 29 00:47:39 2016
From: satya at attivonetworks.com (Satya Das)
Date: Tue, 29 Mar 2016 00:47:39 +0000
Subject: [openssl-users] Binaries exit with signature bytes
In-Reply-To: <20160327015401.GB17179@openssl.org>
References: <BL2PR07MB24046622F646EBA702705273D7830@BL2PR07MB2404.namprd07.prod.outlook.com>,
 <20160327015401.GB17179@openssl.org>
Message-ID: <BL2PR07MB24045F62BA7051E077F28A53D7870@BL2PR07MB2404.namprd07.prod.outlook.com>


>What platform are you building? Is it a native or cross compile?

>You'd get that behaviour if fipsld isn't linking the binaries properly.

Thanks Steve. I am on centos 6, native compile. I saw " /libcrypto.so is not cross-compiler aware." with fipsld linking until introducing -exe option to incore invocation. It builds fine with the modified fipsld but then I now have this run time error to deal with.

TIA.



From wangqun at alumni.nus.edu.sg  Tue Mar 29 02:24:11 2016
From: wangqun at alumni.nus.edu.sg (Aaron)
Date: Mon, 28 Mar 2016 19:24:11 -0700 (MST)
Subject: [openssl-users] OpenSSL FIPS test failure starting from version
	1.0.2g
Message-ID: <1459218251834-65320.post@n7.nabble.com>

Greetings. 

I am using OpenSSl 1.0.2f on various platforms including Solaris, Linux,
RS6000, ibmplinux, HPIA and Windows. Now I am going to upgrade to OpenSSL
1.0.2g. However I hit a test failure when building and tesing 1.0.2g. The
issue occurs on all my platforms except Windows which I haven't tested, so
it is likely a generic problem. The issue didn't occur when I built and
tested 1.0.2f, so it may be a regression in 1.0.2g.

It is very stratforward to repro the issue. Take platform linux_x86-64 as an
example, the repro steps are as follows. 

cd openssl-1.0.2g 
make clean 
./Configure no-idea no-mdc2 no-rc5 no-ec2m fips -m64 no-asm linux-x86_64 
make depend 
make 
make test    <--- Hit the issue here. 

Error message: 
test SSL protocol 
test ssl3 is forbidden in FIPS mode 
*** IN FIPS MODE *** 
Available compression methods: 
  NONE 
46912496310224:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in
fips mode:ssl_lib.c:1877: 
46912496310224:error:140A9129:SSL routines:SSL_CTX_new:only tls allowed in
fips mode:ssl_lib.c:1877: 
test ssl2 is forbidden in FIPS mode 
Testing was requested for a disabled protocol. Skipping tests. 
make[1]: *** [test_ssl] Error 1 
make[1]: Leaving directory
`/tzedek_ocsdev/qun/crs/797167/openssl_diff/openssl-1.0.2g.test/test' 
make: *** [tests] Error 2 

Anyone knows how to fix the issue please? 

Thanks in advance, 
Aaron 




--
View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-FIPS-test-failure-starting-from-version-1-0-2g-tp65320.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From openssl-users at dukhovni.org  Tue Mar 29 03:27:10 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 28 Mar 2016 23:27:10 -0400
Subject: [openssl-users] OpenSSL FIPS test failure starting from version
	1.0.2g
In-Reply-To: <1459218251834-65320.post@n7.nabble.com>
References: <1459218251834-65320.post@n7.nabble.com>
Message-ID: <21138BCA-FD4A-491B-8835-E98FAE9CCD5B@dukhovni.org>


> On Mar 28, 2016, at 10:24 PM, Aaron <wangqun at alumni.nus.edu.sg> wrote:
> 
> It is very stratforward to repro the issue. Take platform linux_x86-64 as an
> example, the repro steps are as follows. 
> 
> cd openssl-1.0.2g 
> make clean 
> ./Configure no-idea no-mdc2 no-rc5 no-ec2m fips -m64 no-asm linux-x86_64 
> make depend 
> make 
> make test    <--- Hit the issue here. 

https://github.com/openssl/openssl/commits/OpenSSL_1_0_2-stable

-- 
	Viktor.


From wangqun at alumni.nus.edu.sg  Tue Mar 29 08:08:50 2016
From: wangqun at alumni.nus.edu.sg (Aaron)
Date: Tue, 29 Mar 2016 01:08:50 -0700 (MST)
Subject: [openssl-users] OpenSSL FIPS test failure starting from version
	1.0.2g
In-Reply-To: <21138BCA-FD4A-491B-8835-E98FAE9CCD5B@dukhovni.org>
References: <1459218251834-65320.post@n7.nabble.com>
 <21138BCA-FD4A-491B-8835-E98FAE9CCD5B@dukhovni.org>
Message-ID: <1459238930414-65325.post@n7.nabble.com>

Thank you very much, Viktor. It works.

Regards,
Aaron



--
View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-FIPS-test-failure-starting-from-version-1-0-2g-tp65320p65325.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From jonetsu at teksavvy.com  Tue Mar 29 16:52:10 2016
From: jonetsu at teksavvy.com (jonetsu)
Date: Tue, 29 Mar 2016 09:52:10 -0700 (MST)
Subject: [openssl-users] TLS 1.0 in FIPS mode ?
Message-ID: <1459270330305-65343.post@n7.nabble.com>

Hello,

Does OpenSSL allows TLS 1.0 when running in FIPS mode ?

Thanks.



--
View this message in context: http://openssl.6102.n7.nabble.com/TLS-1-0-in-FIPS-mode-tp65343.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From warron.french at gmail.com  Thu Mar 31 15:16:10 2016
From: warron.french at gmail.com (warron.french)
Date: Thu, 31 Mar 2016 11:16:10 -0400
Subject: [openssl-users] Properly manage CA-signed certificates that have
	expired
Message-ID: <CAJdJdQmBBmwoc4unKMKYTo_51GxKfta7bTJh1y=rb=qHqZZKDQ@mail.gmail.com>

Hello, I had to build a Certificate Authority (CA) server for an isolated
network (I know, it seems silly).

Anyway, I figured out how to create the CA service doing a self-signed
certificate that will expire in 9 years, because it was a 10-year
certificate of which 9 years remains available.

I then created separate TLS keys and CSRs and had them signed by the CA
server.

The 2 certificates for the "servers" (its actually all the same 1 server
with different DNS-A-Record resolvable names) worked perfectly for the past
1 year; but I was kept busy working on other tasks; so this isolated
network got neglected.  The two (2) certificates for the servers expired
last month.

I documented how to build the CA, how to create the CSRs and get them
signed; but I didn't know how to write the documentation for maintaining
any certificates once they expired.

I want to properly, and gracefully, manage the CA server to do whatever is
appropriate.

I believe, but do not know for sure, that what I want to do is:
1.  Revoke the expired certificates (maybe that is not necessary or
appropriate?)
2.  Clean up the CA database (with the openssl ca -updatedb command?)
3.  Then create new server certificates for the 2 servers again.

I don't want to use the same 1 certificate for 2 services, because I have
one for TLS-securing the LDAP service making it an ldapS:// url, and the
other is for TLS-securing the AdminConsole of the same 389-ds
implementation.

Please help, I don't know what terminology I am looking for to properly
pursue what a Professional CA (like Verisign, or wherever) would do.



Thanks,
--------------------------
Warron French
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160331/150b621d/attachment-0001.html>

From jb-openssl at wisemo.com  Thu Mar 31 16:09:16 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 31 Mar 2016 18:09:16 +0200
Subject: [openssl-users] Properly manage CA-signed certificates that
 have expired
In-Reply-To: <CAJdJdQmBBmwoc4unKMKYTo_51GxKfta7bTJh1y=rb=qHqZZKDQ@mail.gmail.com>
References: <CAJdJdQmBBmwoc4unKMKYTo_51GxKfta7bTJh1y=rb=qHqZZKDQ@mail.gmail.com>
Message-ID: <56FD4BAC.1040602@wisemo.com>

On 31/03/2016 17:16, warron.french wrote:
> Hello, I had to build a Certificate Authority (CA) server for an 
> isolated network (I know, it seems silly).
>
> Anyway, I figured out how to create the CA service doing a self-signed 
> certificate that will expire in 9 years, because it was a 10-year 
> certificate of which 9 years remains available.
>
> I then created separate TLS keys and CSRs and had them signed by the 
> CA server.
>
> The 2 certificates for the "servers" (its actually all the same 1 
> server with different DNS-A-Record resolvable names) worked perfectly 
> for the past 1 year; but I was kept busy working on other tasks; so 
> this isolated network got neglected.  The two (2) certificates for the 
> servers expired last month.
>
> I documented how to build the CA, how to create the CSRs and get them 
> signed; but I didn't know how to write the documentation for 
> maintaining any certificates once they expired.
>
> I want to properly, and gracefully, manage the CA server to do 
> whatever is appropriate.
>
> I believe, but do not know for sure, that what I want to do is:
> 1.  Revoke the expired certificates (maybe that is not necessary or 
> appropriate?)

Not needed, only do this if the old private key compromised.
> 2.  Clean up the CA database (with the openssl ca -updatedb command?)
Not needed (I think, never used that command).
> 3.  Then create new server certificates for the 2 servers again.
>
Yep, and give the new ones a slightly different "full"
distinguished name (important for CRL and "ca" database).
My approach is to include the year-month as an extra OU e.g.

CN=foo.example.private,OU=isonetwork,OU=2016-03,O=YourCompany 
Inc,L=YourTown,C=XX

(This of cause need to be input when generating the new keys
and requests, then checked when signing them).

You should also set up a CRL generation and renewal process,
so you can revoke any compromised keys and tell the clients.
This would require logging on to the CA once a month to sign
an (updated but unchanged) CRL and copy it to some http or
ldap URL on the isolated network.  Professional CAs do this
daily, but that's too much work for a tiny company CA.






Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160331/3836eec0/attachment.html>

From rsalz at akamai.com  Thu Mar 31 16:11:26 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 31 Mar 2016 16:11:26 +0000
Subject: [openssl-users] Properly manage CA-signed certificates that
 have expired
In-Reply-To: <56FD4BAC.1040602@wisemo.com>
References: <CAJdJdQmBBmwoc4unKMKYTo_51GxKfta7bTJh1y=rb=qHqZZKDQ@mail.gmail.com>
 <56FD4BAC.1040602@wisemo.com>
Message-ID: <315442364e6643f8916f63fddce0d914@usma1ex-dag1mb1.msg.corp.akamai.com>



> Yep, and give the new ones a slightly different "full" 
> distinguished name (important for CRL and "ca" database).
> My approach is to include the year-month as an extra OU e.g.
>
>? CN=foo.example.private,OU=isonetwork,OU=2016-03,O=YourCompany Inc,L=YourTown,C=XX

Ooh, that's neat advice!


--  
Senior Architect, Akamai Technologies
IM: richsalz at jabber.at Twitter: RichSalz

From ben at an3k.de  Thu Mar 31 22:36:28 2016
From: ben at an3k.de (Ben Humpert)
Date: Fri, 1 Apr 2016 00:36:28 +0200
Subject: [openssl-users] Properly manage CA-signed certificates that
	have expired
In-Reply-To: <56FD4BAC.1040602@wisemo.com>
References: <CAJdJdQmBBmwoc4unKMKYTo_51GxKfta7bTJh1y=rb=qHqZZKDQ@mail.gmail.com>
 <56FD4BAC.1040602@wisemo.com>
Message-ID: <CAGbjqfEH8uviiBe6GcPj97Sg2vh3iaS_9gB0ArnMNRML9VDPjw@mail.gmail.com>

2016-03-31 18:09 GMT+02:00 Jakob Bohm <jb-openssl at wisemo.com>:
> On 31/03/2016 17:16, warron.french wrote:
> 3.  Then create new server certificates for the 2 servers again.
>
> Yep, and give the new ones a slightly different "full"
> distinguished name (important for CRL and "ca" database).
> My approach is to include the year-month as an extra OU e.g.
>
>   CN=foo.example.private,OU=isonetwork,OU=2016-03,O=YourCompany
> Inc,L=YourTown,C=XX

Why is this that important? Isn't the serial and/or keyid/hash enough
to differentiate between both certs? Or is it just another "layer of
security" for some not that correctly working clients out there?

Thanks!

From jb-openssl at wisemo.com  Thu Mar 31 23:01:54 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 1 Apr 2016 01:01:54 +0200
Subject: [openssl-users] Properly manage CA-signed certificates that
 have expired
In-Reply-To: <CAGbjqfEH8uviiBe6GcPj97Sg2vh3iaS_9gB0ArnMNRML9VDPjw@mail.gmail.com>
References: <CAJdJdQmBBmwoc4unKMKYTo_51GxKfta7bTJh1y=rb=qHqZZKDQ@mail.gmail.com>
 <56FD4BAC.1040602@wisemo.com>
 <CAGbjqfEH8uviiBe6GcPj97Sg2vh3iaS_9gB0ArnMNRML9VDPjw@mail.gmail.com>
Message-ID: <56FDAC62.6060206@wisemo.com>

On 01/04/2016 00:36, Ben Humpert wrote:
> 2016-03-31 18:09 GMT+02:00 Jakob Bohm <jb-openssl at wisemo.com>:
>> On 31/03/2016 17:16, warron.french wrote:
>> 3.  Then create new server certificates for the 2 servers again.
>>
>> Yep, and give the new ones a slightly different "full"
>> distinguished name (important for CRL and "ca" database).
>> My approach is to include the year-month as an extra OU e.g.
>>
>>    CN=foo.example.private,OU=isonetwork,OU=2016-03,O=YourCompany
>> Inc,L=YourTown,C=XX
> Why is this that important? Isn't the serial and/or keyid/hash enough
> to differentiate between both certs? Or is it just another "layer of
> security" for some not that correctly working clients out there?
Some protocols and data formats identify certificates
only by their issuer and subject distinguished names.

One of those is the default database format used by
the "openssl ca" utility (there is an option to avoid
this, but it must be set when initially creating the CA,
so cannot be assumed or suggested when someone already
has a running site CA of unknown configuration).

Adding this explicit date also makes it easier to
identify the correct certificate in various user
interfaces (it takes more brain time checking the
serial numbers or dates of each candidate
certificate when trying to pick the right one as
part of a server configuration etc.).

I seem to recall there was one other protocol that
relied solely on the DN, but I can't remember which
one right now.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded


From noloader at gmail.com  Thu Mar 31 23:10:08 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 31 Mar 2016 19:10:08 -0400
Subject: [openssl-users] Properly manage CA-signed certificates that
	have expired
In-Reply-To: <CAGbjqfEH8uviiBe6GcPj97Sg2vh3iaS_9gB0ArnMNRML9VDPjw@mail.gmail.com>
References: <CAJdJdQmBBmwoc4unKMKYTo_51GxKfta7bTJh1y=rb=qHqZZKDQ@mail.gmail.com>
 <56FD4BAC.1040602@wisemo.com>
 <CAGbjqfEH8uviiBe6GcPj97Sg2vh3iaS_9gB0ArnMNRML9VDPjw@mail.gmail.com>
Message-ID: <CAH8yC8m0TayUaaNWtZVwiWtagvgXuzxQO9iqSiaTXX1i8tC=cw@mail.gmail.com>

On Thu, Mar 31, 2016 at 6:36 PM, Ben Humpert <ben at an3k.de> wrote:
> 2016-03-31 18:09 GMT+02:00 Jakob Bohm <jb-openssl at wisemo.com>:
>> On 31/03/2016 17:16, warron.french wrote:
>> 3.  Then create new server certificates for the 2 servers again.
>>
>> Yep, and give the new ones a slightly different "full"
>> distinguished name (important for CRL and "ca" database).
>> My approach is to include the year-month as an extra OU e.g.
>>
>>   CN=foo.example.private,OU=isonetwork,OU=2016-03,O=YourCompany
>> Inc,L=YourTown,C=XX
>
> Why is this that important? Isn't the serial and/or keyid/hash enough
> to differentiate between both certs? Or is it just another "layer of
> security" for some not that correctly working clients out there?

It could depend when Path Building (RFC 4158,
https://tools.ietf.org/rfc/rfc4158.txt), modulo some other things.

The two ways to uniquely identify a certificate is (1) hash of the
issuer public key, which shows up as AKID in the subject; and (2) the
pair {distinguished name, serial number} in the subjects certificate.

Some user agents have had problems when CA re-certifying the same
public key on a roll over when (1) the DN stays the same, and (2) the
hash changes. I think OpenSSL had a pain point here for a while. I
think Viktor fixed it recently (within the last year or so).

Issuers are supposed to ensure serial numbers are unique, but....

Jeff