From matt at openssl.org  Mon Oct  1 07:34:49 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 1 Oct 2018 08:34:49 +0100
Subject: [openssl-users] Two sessions in a single full handshake
In-Reply-To: <CAJbO6CSz5usmBqC-2iZD1gPovRScTkBB41Q0uuXTdjDbhnLLKg@mail.gmail.com>
References: <CAJbO6CRLC5ukTbVYoewUhWgwPqoTGYL=mEC7Wg+nNfegZcoRLg@mail.gmail.com>
 <8BD8B17B-B091-42D1-9AA4-FAEFE5C9AE5F@akamai.com>
 <CAJbO6CS=gW1V+on35BvA6F-i_6ULPb+9ru96y9t-DeDTxuj9Lw@mail.gmail.com>
 <20180930034645.GM19845@akamai.com>
 <CAJbO6CSz5usmBqC-2iZD1gPovRScTkBB41Q0uuXTdjDbhnLLKg@mail.gmail.com>
Message-ID: <c548e7aa-4603-ab2c-df4a-879a8b987989@openssl.org>



On 30/09/18 06:05, John Jiang wrote:
> Now that full handshake sends two sessions, does that mean option
> -sess_out saves both of the sessions to a local file?

The last session received is the one in the sess_out file.

Matt


> If so, when resume session via option -sess_in, which session will be
> resumed?
> 
> On Sun, Sep 30, 2018 at 11:47 AM Benjamin Kaduk via openssl-users
> <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
> 
>     s_client has -sess_out and -sess_in options that can be used
>     to save session information to a file and read it in for a subsequent
>     connection.? Neither is used by default.
> 
>     -Ben
> 
>     On Sun, Sep 30, 2018 at 11:06:14AM +0800, John Jiang wrote:
>     > Does s_client resume any session in the local session file?
>     >
>     > On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users <
>     > openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>     >
>     > >
>     > >? ? - The debug logs display two "SSL-Session" blocks in a full
>     handshake.
>     > >
>     > > Only one "SSL-Session" block is displayed in a resumption.
>     > >
>     > > Why does full handshake has two sessions?
>     > >
>     > >
>     > >
>     > > This is part of the TLS 1.3 standard.? A server can send back
>     multiple
>     > > sessions, so that a client may resume with a different session, and
>     > > therefore prevent an observer from ?linking? two different
>     activities.
>     > > --
>     > > 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
> 
>     -- 
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 

From lintamaria194 at gmail.com  Mon Oct  1 09:11:45 2018
From: lintamaria194 at gmail.com (Linta Maria)
Date: Mon, 1 Oct 2018 14:41:45 +0530
Subject: [openssl-users] Sign and verification using ECC 25519 curve-
	Bernstein
Message-ID: <CANzpxQcePx6WE_Xtg6TQaCV7V8n_GaChpHeEgTP7ePrh7GbDFQ@mail.gmail.com>

Hi all,

Does openssl supports sign and verification using ECC 25519 curve
Bernstein?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181001/a39c62db/attachment.html>

From matt at openssl.org  Mon Oct  1 10:11:04 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 1 Oct 2018 11:11:04 +0100
Subject: [openssl-users] Sign and verification using ECC 25519 curve-
 Bernstein
In-Reply-To: <CANzpxQcePx6WE_Xtg6TQaCV7V8n_GaChpHeEgTP7ePrh7GbDFQ@mail.gmail.com>
References: <CANzpxQcePx6WE_Xtg6TQaCV7V8n_GaChpHeEgTP7ePrh7GbDFQ@mail.gmail.com>
Message-ID: <b97ac78f-ceb6-adb6-3fd2-0dd9529d6574@openssl.org>



On 01/10/18 10:11, Linta Maria wrote:
> Hi all,
> 
> Does openssl supports sign and verification using ECC 25519 curve
> Bernstein??
> 
> 

Yes. See:

https://www.openssl.org/docs/man1.1.1/man7/Ed25519.html

Matt

From jan.burgmeier at unicon-software.com  Mon Oct  1 12:43:11 2018
From: jan.burgmeier at unicon-software.com (Jan Burgmeier)
Date: Mon, 01 Oct 2018 14:43:11 +0200
Subject: [openssl-users] Same dir with different type in
 X509_LOOKUP_hash_dir
In-Reply-To: <20180929.141352.865554983569125909.levitte@openssl.org>
References: <2e5a9e53712a0e0138eee7d07d7145194286024a.camel@unicon-software.com>
 <20180929.141352.865554983569125909.levitte@openssl.org>
Message-ID: <f22be2f2d71eced70ea9498a4bd94fea2dcca2fe.camel@unicon-software.com>

Performance wise it would also be possible to use the type parameter as
bit field. As 1 and 2 are the only used types at the moment this won't
break anything. Then the second type is only used if the first fails.
If a patch for this is wanted I can provide one.
The other way would be to convert all certificates to one type.

What is the preferred way to do this?
We are not interested in running a patched ssl.

Regards
Jan

On Sat, 2018-09-29 at 14:13 +0200, Richard Levitte wrote:
> Well, that will kinda sorta work, I think...  what you're basically
> doing there, albeit not entirely clearly, is making the type a part
> of
> the directory index, not just its name.  I haven't looked thoroughly
> enough to see if there are corner cases that will screw that up.
> 
> That being said, you will see an increase in processing time.  The
> type setting for a directory is applied to ALL hash-named files this
> code can find, so if you have two lookups, one with each file type
> setting, what will happen is that it will attempt through all the
> files, which will of course fail for those with the wrong
> format.  You
> won't notice, because the loading errors are simply ignored and there
> will be success as soon as a file could be loaded and matches your
> lookup criteium.
> 
> So in essence, that does look like a workable solution, but with bad
> optimization.
> 
> Cheers,
> Richard
> 
> In message <
> 2e5a9e53712a0e0138eee7d07d7145194286024a.camel at unicon-software.com>
> on Fri, 28 Sep 2018 13:11:25 +0200, Jan Burgmeier <
> jan.burgmeier at unicon-software.com> said:
> 
> > Hi,
> > 
> > during setup of my X509_STORE I use X509_LOOKUP_hash_dir with same
> > dir
> > but different type X509_FILETYPE_PEM and X509_FILETYPE_ASN1. But
> > only
> > certificates of the first type are looked up.
> > I dig into the code and made a little change to fix my problem, see
> > attached patched. Is this behavior by design and I am doing
> > anything
> > wrong or is this a bug?
> > 
> > Regards
> > Jan Burgmeier
> > 
> > --- a/crypto/x509/by_dir.c
> > +++ b/crypto/x509/by_dir.c
> > @@ -217,7 +217,8 @@
> >                  continue;
> >              for (j = 0; j < sk_BY_DIR_ENTRY_num(ctx->dirs); j++) {
> >                  ent = sk_BY_DIR_ENTRY_value(ctx->dirs, j);
> > -                if (strlen(ent->dir) == (size_t)len &&
> > +                if (type == ent->dir_type &&
> > +                    strlen(ent->dir) == (size_t)len &&
> >                      strncmp(ent->dir, ss, (unsigned int)len) == 0)
> >                      break;
> >              }
> > 
> > 


From aaron.friesen at non.keysight.com  Mon Oct  1 16:29:15 2018
From: aaron.friesen at non.keysight.com (aaron.friesen at non.keysight.com)
Date: Mon, 1 Oct 2018 16:29:15 +0000
Subject: [openssl-users] How to build libcrypto64*.lib and libssl64*.lib on
	Windows 64-bit?
Message-ID: <BYAPR17MB2150827BB4432C4B7EDAF69DDFEF0@BYAPR17MB2150.namprd17.prod.outlook.com>

A current project using Net-SNMP and OpenSSL require that these both are built locally (customer requirement).

I am attempting to build OpenSSL 1.1.1.

After building OpenSSL, "nmake test" succeeds.

However, the Net-SNMP build is looking for various .lib files that are in the pre-built package, but do not seem to be in what I build locally.

>From the pre-built package, in the lib/VC folder:
libcrypto64MD.lib
libcrypto64MDd.lib
libcrypto64MT.lib
libcrypto64MTd.lib
libssl64MD.lib
libssl64MDd.lib
libssl64MT.lib
libssl64MTd.lib

But the VC folder is not part of my locally built version.

What am I missing in order to get these .lib files to build locally?

Thank you for your assistance.

Best Regards,
Aaron Friesen

Contract Software Engineer of Aerotek on behalf of Keysight

Keysight Technologies, Inc.
970.679.5632 T

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181001/9835ba1d/attachment-0001.html>

From gdejin at gmail.com  Tue Oct  2 08:00:49 2018
From: gdejin at gmail.com (=?UTF-8?B?7J6l7KeE7ZmU?=)
Date: Tue, 2 Oct 2018 17:00:49 +0900
Subject: [openssl-users] How to get OCSP response in CMS through openssl
	library in C++
In-Reply-To: <44f04a8d-1f94-4306-8cd5-9c52c2ff1b68@googlegroups.com>
References: <44f04a8d-1f94-4306-8cd5-9c52c2ff1b68@googlegroups.com>
Message-ID: <CALypGV3cyU2A_+7B-7sNmMU_i17n3711fZK1=cy8EjSSiObfbA@mail.gmail.com>

> Hello,
>
> I've been developing some broadcast apps signing logic on a TV.
>
> Actually, I should receive and verify the signing information such as
> certificates and ocsp responses which are included in CMS signed data
> format.
> These application data are sent to TV with certain frequency without
> internet connection. And, CMS signed data is attached to SMIME.
>
> So, I succeeded to extract and use the certificates through
> "CMS_get1_certs" to use it on verification processes.
>
> But, in case of ocsp responses I do not know how to get it.
> I've tried to extract OCSP responses through
> "STACK_OF(CMS_RevocationInfoChoice) *crls;" ,
> "CMS_OtherRevocationInfoFormat *other;" and etc in CMS_Signed_data, but
> failed.
> Not only it's a private, but also Most of apis related to
> CMS_OtherRevocationInfoFormat are unaccessible.
>
> Could you help me to solve this problem??
>
> p.s. In contrast, as for crls there is an efficient api named
> "CMS_get1_crls".
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181002/81cea108/attachment.html>

From benjamin.dupalut at esiee.fr  Tue Oct  2 09:47:08 2018
From: benjamin.dupalut at esiee.fr (DUPALUT, Benjamin)
Date: Tue, 2 Oct 2018 11:47:08 +0200
Subject: [openssl-users] SubjectAltName syntax in openssl.cnf
In-Reply-To: <CAEqwmrjBQ1vdD+jKmLRGpick_FO-cKk23d5Btc0GQ+NJazNgGg@mail.gmail.com>
References: <CAEqwmrjBQ1vdD+jKmLRGpick_FO-cKk23d5Btc0GQ+NJazNgGg@mail.gmail.com>
Message-ID: <CAEqwmrhaW1nH8-Zrh-SDX31gFcRjYKvwiu1CN1+0PXzLCzN4bw@mail.gmail.com>

Hello,

Does anyone, please, have informations about my question ?

Thanks in advance.

Cordialement,

*Benjamin Dupalut*
Ing?nieur syst?me et r?seau
Service Informatique, T?l?communications, Audiovisuel et Reprographie
(SITAR)
ESIEE Paris
2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex
T : +33 1 45 92 66 17
benjamin.dupalut at esiee.fr
www.esiee.fr / www.cci-paris-idf.fr


Le ven. 28 sept. 2018 ? 18:00, DUPALUT, Benjamin <benjamin.dupalut at esiee.fr>
a ?crit :

> Hello,
>
> i Have to set a SubjectAltName for a server certificate but documentations
> on the web does not provide the same syntax.
>
> Is this syntax correct ?
>
> subjectAltName=DNS:test.example.com
>
> Also, does it belong in the [ usr_cert ] section ?
>
> Thank you for your help.
>
> Regards,
>
> *Benjamin Dupalut*
> Ing?nieur syst?me et r?seau
> Service Informatique, T?l?communications, Audiovisuel et Reprographie
> (SITAR)
> ESIEE Paris
> 2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex
> T : +33 1 45 92 66 17
> benjamin.dupalut at esiee.fr
> www.esiee.fr / www.cci-paris-idf.fr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181002/bcf633ff/attachment.html>

From dcoombs at carillon.ca  Tue Oct  2 13:11:46 2018
From: dcoombs at carillon.ca (Dave Coombs)
Date: Tue, 2 Oct 2018 09:11:46 -0400
Subject: [openssl-users] SubjectAltName syntax in openssl.cnf
In-Reply-To: <CAEqwmrhaW1nH8-Zrh-SDX31gFcRjYKvwiu1CN1+0PXzLCzN4bw@mail.gmail.com>
References: <CAEqwmrjBQ1vdD+jKmLRGpick_FO-cKk23d5Btc0GQ+NJazNgGg@mail.gmail.com>
 <CAEqwmrhaW1nH8-Zrh-SDX31gFcRjYKvwiu1CN1+0PXzLCzN4bw@mail.gmail.com>
Message-ID: <7C6D7985-82E1-47D0-AB1A-B3B2C031787D@carillon.ca>

Hello,

That syntax looks correct, yes.  It belongs in the [section] name you are passing to the "-extensions" argument on the "openssl ca" command when issuing the certificate.

I hope this helps.
  -Dave


> On Oct 2, 2018, at 05:47, DUPALUT, Benjamin <benjamin.dupalut at esiee.fr> wrote:
> 
> Hello,
> 
> Does anyone, please, have informations about my question ?
> 
> Thanks in advance.
> 
> Cordialement,
> 
> Benjamin Dupalut
> Ing?nieur syst?me et r?seau
> Service Informatique, T?l?communications, Audiovisuel et Reprographie (SITAR)
> ESIEE Paris
> 2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex
> T : +33 1 45 92 66 17
> benjamin.dupalut at esiee.fr <mailto:benjamin.dupalut at esiee.fr>
> www.esiee.fr <http://www.esiee.fr/> / www.cci-paris-idf.fr <http://www.cci-paris-idf.fr/>
> 
> 
> Le ven. 28 sept. 2018 ? 18:00, DUPALUT, Benjamin <benjamin.dupalut at esiee.fr <mailto:benjamin.dupalut at esiee.fr>> a ?crit :
> Hello,
> 
> i Have to set a SubjectAltName for a server certificate but documentations on the web does not provide the same syntax.
> 
> Is this syntax correct ?
> 
> subjectAltName=DNS:test.example.com <http://test.example.com/>
> 
> Also, does it belong in the [ usr_cert ] section ?
> 
> Thank you for your help.
> 
> Regards,
> 
> Benjamin Dupalut
> Ing?nieur syst?me et r?seau
> Service Informatique, T?l?communications, Audiovisuel et Reprographie (SITAR)
> ESIEE Paris
> 2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex
> T : +33 1 45 92 66 17
> benjamin.dupalut at esiee.fr <mailto:benjamin.dupalut at esiee.fr>
> www.esiee.fr <http://www.esiee.fr/> / www.cci-paris-idf.fr <http://www.cci-paris-idf.fr/>
> -- 
> 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/20181002/e19fec43/attachment.html>

From levitte at openssl.org  Tue Oct  2 15:59:12 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 02 Oct 2018 17:59:12 +0200 (CEST)
Subject: [openssl-users] How to build libcrypto64*.lib and libssl64*.lib
 on Windows 64-bit?
In-Reply-To: <BYAPR17MB2150827BB4432C4B7EDAF69DDFEF0@BYAPR17MB2150.namprd17.prod.outlook.com>
References: <BYAPR17MB2150827BB4432C4B7EDAF69DDFEF0@BYAPR17MB2150.namprd17.prod.outlook.com>
Message-ID: <20181002.175912.1353134730697848028.levitte@openssl.org>

Our scripts have *never*, as far as I know, produced libraries named
like that.  Don't those DLLs come from some specific packager that
produces binary install kits?

For 1.1.x, *our* naming is a bit more elaborate, you will see these
names:

    libcrypto-1_1.dll & libssl-1_1.dll           - VC-WIN32 build
    libcrypto-1_1-x64.dll & libssl-1_1-x64.dll   - VC-WIN64A build
    libcrypto-1_1-ia64.dll & libssl-1_1-ia64.dll - VC-WIN64I build

You will also see the corresponding import libraries: libcrypto.lib &
libssl.lib

Cheers,
Richard

In message <BYAPR17MB2150827BB4432C4B7EDAF69DDFEF0 at BYAPR17MB2150.namprd17.prod.outlook.com> on Mon, 1 Oct 2018 16:29:15 +0000, <aaron.friesen at non.keysight.com> said:

> A current project using Net-SNMP and OpenSSL require that these both are built locally (customer
> requirement).
> 
> I am attempting to build OpenSSL 1.1.1.
> 
> After building OpenSSL, ?nmake test? succeeds.
> 
> However, the Net-SNMP build is looking for various .lib files that are in the pre-built package, but
> do not seem to be in what I build locally.
> 
> From the pre-built package, in the lib/VC folder:
> 
> libcrypto64MD.lib
> 
> libcrypto64MDd.lib
> 
> libcrypto64MT.lib
> 
> libcrypto64MTd.lib
> 
> libssl64MD.lib
> 
> libssl64MDd.lib
> 
> libssl64MT.lib
> 
> libssl64MTd.lib
> 
> But the VC folder is not part of my locally built version.
> 
> What am I missing in order to get these .lib files to build locally?
> 
> Thank you for your assistance.
> 
> Best Regards,
> Aaron Friesen
> 
> Contract Software Engineer of Aerotek on behalf of Keysight
> 
> Keysight Technologies, Inc.
> 
> 970.679.5632 T
> 

From blaufish.public.email at gmail.com  Wed Oct  3 12:51:57 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Wed, 3 Oct 2018 14:51:57 +0200
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
Message-ID: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>

Hi,
It is my understanding "openssl verify" should raise
X509_V_ERR_PATH_LENGTH_EXCEEDED should be raised if pathlen=0
intermediate issues a new CA, but that does not seem to occur when I
test with a couple pf openssl versions.

I am not sure due to limited understanding of the code, but I am
wonder if there isn't an off-by-one or out-of-order increment error in
x509_vfy.c in this check: (plen > (x->ex_pathlen + proxy_path_length +
1))). if plen=1 and x->ex_pathlen=0, the check would become 1>1
(false) while it was expected to raise an error?

openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem evil.pem
evil.pem: OK

openssl x509 -text -in root.pem | egrep -a1 X509v3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5
--
--
                A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5
            X509v3 Authority Key Identifier:

keyid:A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5
--
--
            X509v3 Key Usage:
                Certificate Sign, CRL Sign
--
--
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:1


openssl x509 -text -in intermediate.pem | egrep -a1 X509v3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD
--
--
                B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD
            X509v3 Authority Key Identifier:

keyid:A5:70:7B:56:F1:93:E9:CC:FD:15:EF:FA:64:67:41:99:6F:40:DA:C5
--
--
            X509v3 Key Usage:
                Certificate Sign, CRL Sign
--
--
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0


openssl x509 -text -in evil.pem | egrep -a1 X509v3
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                81:3A:5A:BD:9E:6C:08:0F:C7:6A:31:A2:0D:0F:2A:02:62:BE:63:12
--
--
                81:3A:5A:BD:9E:6C:08:0F:C7:6A:31:A2:0D:0F:2A:02:62:BE:63:12
            X509v3 Authority Key Identifier:

keyid:B5:5A:8A:64:CE:A4:1E:51:6F:AB:E4:8E:E3:71:8D:EF:2D:42:A7:AD
--
--
            X509v3 Basic Constraints: critical
                CA:TRUE
--
--
                CA:TRUE
            X509v3 Key Usage:
                Certificate Sign, CRL Sign

From openssl-users at dukhovni.org  Wed Oct  3 14:51:01 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 3 Oct 2018 10:51:01 -0400
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
In-Reply-To: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
References: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
Message-ID: <20181003145101.GR3589@straasha.imrryr.org>

On Wed, Oct 03, 2018 at 02:51:57PM +0200, Peter Magnusson wrote:

> $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem evil.pem
> evil.pem: OK

This is expected to work when intermediate.pem has pathlen 0, because
you're verifying "evil.pem" as a *leaf* certificate, its CA:true
is irrelevant when it is the last (leaf) certificate in the chain.

An actually unexpected result would be:

    $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem -untrusted evil.pem badee.pem
    badee.pem: OK

where badee.pem is signed by evil.pem.  The path length constraint
is not a constraint against issuing EE certs with CA:true, it only
constraints the number additional intermediate (non-self-issued)
CAs in a valid path.  In your example that number is zero.

   https://tools.ietf.org/html/rfc5280#section-4.2.1.9

   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
   maximum number of non-self-issued intermediate certificates that may
   follow this certificate in a valid certification path.

-- 
	Viktor.

From benjamin.dupalut at esiee.fr  Wed Oct  3 15:36:44 2018
From: benjamin.dupalut at esiee.fr (DUPALUT, Benjamin)
Date: Wed, 3 Oct 2018 17:36:44 +0200
Subject: [openssl-users] SubjectAltName syntax in openssl.cnf
In-Reply-To: <7C6D7985-82E1-47D0-AB1A-B3B2C031787D@carillon.ca>
References: <CAEqwmrjBQ1vdD+jKmLRGpick_FO-cKk23d5Btc0GQ+NJazNgGg@mail.gmail.com>
 <CAEqwmrhaW1nH8-Zrh-SDX31gFcRjYKvwiu1CN1+0PXzLCzN4bw@mail.gmail.com>
 <7C6D7985-82E1-47D0-AB1A-B3B2C031787D@carillon.ca>
Message-ID: <CAEqwmrgTx5D-JAQdP1pzD=xpi-YsoM_yidixLYo7x8wv2BaJxg@mail.gmail.com>

Hi Dave,

Thank you for your answer.

Cordialement,

*Benjamin Dupalut*
Ing?nieur syst?me et r?seau
Service Informatique, T?l?communications, Audiovisuel et Reprographie
(SITAR)
ESIEE Paris
2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex
T : +33 1 45 92 66 17
benjamin.dupalut at esiee.fr
www.esiee.fr / www.cci-paris-idf.fr


Le mar. 2 oct. 2018 ? 15:12, Dave Coombs <dcoombs at carillon.ca> a ?crit :

> Hello,
>
> That syntax looks correct, yes.  It belongs in the [section] name you are
> passing to the "-extensions" argument on the "openssl ca" command when
> issuing the certificate.
>
> I hope this helps.
>   -Dave
>
>
> On Oct 2, 2018, at 05:47, DUPALUT, Benjamin <benjamin.dupalut at esiee.fr>
> wrote:
>
> Hello,
>
> Does anyone, please, have informations about my question ?
>
> Thanks in advance.
>
> Cordialement,
>
> *Benjamin Dupalut*
> Ing?nieur syst?me et r?seau
> Service Informatique, T?l?communications, Audiovisuel et Reprographie
> (SITAR)
> ESIEE Paris
> 2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex
> T : +33 1 45 92 66 17
> benjamin.dupalut at esiee.fr
> www.esiee.fr / www.cci-paris-idf.fr
>
>
> Le ven. 28 sept. 2018 ? 18:00, DUPALUT, Benjamin <
> benjamin.dupalut at esiee.fr> a ?crit :
>
>> Hello,
>>
>> i Have to set a SubjectAltName for a server certificate but
>> documentations on the web does not provide the same syntax.
>>
>> Is this syntax correct ?
>>
>> subjectAltName=DNS:test.example.com
>>
>> Also, does it belong in the [ usr_cert ] section ?
>>
>> Thank you for your help.
>>
>> Regards,
>>
>> *Benjamin Dupalut*
>> Ing?nieur syst?me et r?seau
>> Service Informatique, T?l?communications, Audiovisuel et Reprographie
>> (SITAR)
>> ESIEE Paris
>> 2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex
>> T : +33 1 45 92 66 17
>> benjamin.dupalut at esiee.fr
>> www.esiee.fr / www.cci-paris-idf.fr
>>
> --
> 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/20181003/88730f90/attachment.html>

From blaufish.public.email at gmail.com  Wed Oct  3 17:16:51 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Wed, 3 Oct 2018 19:16:51 +0200
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
In-Reply-To: <20181003145101.GR3589@straasha.imrryr.org>
References: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
 <20181003145101.GR3589@straasha.imrryr.org>
Message-ID: <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>

The following test case attempts to validates evilserver.pem, issued
by evilca.pem.

evil*.pem is violating:
1/ pathlen=0 constraint of the compromised intermediate.pem (issuer of
evilserver.pem)
2/ pathlen=1 constraint of the non-compromised root-ca.pem (issuer of
intermediate.pem)

The particular example execution is from Mac (LibreSSL) but same
behaviour observed with e.g. homebrew as well.

https://github.com/blaufish/openssl-pathlen

openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:1
openssl x509 -text -in intermediate.pem | grep -a1 "X509v3 Basic"
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"

            X509v3 Basic Constraints: critical
                CA:TRUE
openssl verify -verbose -CAfile root.pem -untrusted untrusted.pem evilserver.pem
evilserver.pem: OK


On Wed, Oct 3, 2018 at 4:51 PM Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
>
> On Wed, Oct 03, 2018 at 02:51:57PM +0200, Peter Magnusson wrote:
>
> > $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem evil.pem
> > evil.pem: OK
>
> This is expected to work when intermediate.pem has pathlen 0, because
> you're verifying "evil.pem" as a *leaf* certificate, its CA:true
> is irrelevant when it is the last (leaf) certificate in the chain.
>
> An actually unexpected result would be:
>
>     $ openssl verify -verbose -CAfile root.pem -untrusted intermediate.pem -untrusted evil.pem badee.pem
>     badee.pem: OK
>
> where badee.pem is signed by evil.pem.  The path length constraint
> is not a constraint against issuing EE certs with CA:true, it only
> constraints the number additional intermediate (non-self-issued)
> CAs in a valid path.  In your example that number is zero.
>
>    https://tools.ietf.org/html/rfc5280#section-4.2.1.9
>
>    The pathLenConstraint field is meaningful only if the cA boolean is
>    asserted and the key usage extension, if present, asserts the
>    keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
>    maximum number of non-self-issued intermediate certificates that may
>    follow this certificate in a valid certification path.
>
> --
>         Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From blaufish.public.email at gmail.com  Thu Oct  4 09:15:15 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Thu, 4 Oct 2018 11:15:15 +0200
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
In-Reply-To: <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>
References: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
 <20181003145101.GR3589@straasha.imrryr.org>
 <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>
Message-ID: <CANtcRX5VPFBTzqx1--+1eOiFXYPT7kRBac++-rRNRsSsY29bOQ@mail.gmail.com>

Is this expected?  (plen > (x->ex_pathlen + proxy_path_length + 1))
evaluates to false (constraint not violated) when checking constraint
0 against plen=1 (constraint violated as far as I can understand?).

Doesn't make much sense to me. Is there something I haven't understood
about how the constraint is supposed to work?

******* important variables *******
*** check_chain_extensions:523 i=0
*** check_chain_extensions:524 plen=0
*** check_chain_extensions:525 x->ex_pathlen=-1
******* if statement components *******
*** check_chain_extensions:527 i > 1=0
*** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:529 (x->ex_pathlen != -1)=0
*** check_chain_extensions:530 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:523 i=1
*** check_chain_extensions:524 plen=0
*** check_chain_extensions:525 x->ex_pathlen=-1
******* if statement components *******
*** check_chain_extensions:527 i > 1=0
*** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:529 (x->ex_pathlen != -1)=0
*** check_chain_extensions:530 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:523 i=2
*** check_chain_extensions:524 plen=1
*** check_chain_extensions:525 x->ex_pathlen=0
******* if statement components *******
*** check_chain_extensions:527 i > 1=1
*** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:529 (x->ex_pathlen != -1)=1
*** check_chain_extensions:530 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:523 i=3
*** check_chain_extensions:524 plen=2
*** check_chain_extensions:525 x->ex_pathlen=1
******* if statement components *******
*** check_chain_extensions:527 i > 1=1
*** check_chain_extensions:528 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:529 (x->ex_pathlen != -1)=1
*** check_chain_extensions:530 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0

From openssl-users at dukhovni.org  Thu Oct  4 10:25:48 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 4 Oct 2018 06:25:48 -0400
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
In-Reply-To: <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>
References: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
 <20181003145101.GR3589@straasha.imrryr.org>
 <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>
Message-ID: <20181004102548.GW3589@straasha.imrryr.org>

On Wed, Oct 03, 2018 at 07:16:51PM +0200, Peter Magnusson wrote:

> The following test case attempts to validates evilserver.pem, issued
> by evilca.pem.

More specifically, we see that in this test the leaf server certificate
has the same subject and issuer, so EXFLAG_SI is set for that
certificate, and it did not count in the path length:

    $ /usr/local/bin/openssl verify -show_chain -verbose -trusted root.pem -untrusted untrusted.pem evilserver.pem  
    evilserver.pem: OK
    Chain:
    depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = EvilServer, CN = EvilServer (untrusted)
    depth=1: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = EvilServer, CN = EvilServer (untrusted)
    depth=2: C = SE, ST = Intermediate, O = Intermediate, OU = Intermediate, CN = Intermediate (untrusted)
    depth=3: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root

but this corner-case is not correct, the concept of "self-issued"
only applies to CAs, so for the leaf to be skipped it would have
the be a self-issued CA.  Try the patch below:

-- 
	Viktor.

diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index 3a60d412da..77ca325d54 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -445,6 +445,7 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
     int i, must_be_ca, plen = 0;
     X509 *x;
     int proxy_path_length = 0;
+    int is_ca;
     int purpose;
     int allow_proxy_certs;
     int num = sk_X509_num(ctx->chain);
@@ -484,7 +485,7 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
                                 X509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED))
                 return 0;
         }
-        ret = X509_check_ca(x);
+        ret = is_ca = X509_check_ca(x);
         switch (must_be_ca) {
         case -1:
             if ((ctx->param->flags & X509_V_FLAG_X509_STRICT)
@@ -524,8 +525,8 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
             if (!verify_cb_cert(ctx, x, i, X509_V_ERR_PATH_LENGTH_EXCEEDED))
                 return 0;
         }
-        /* Increment path length if not self issued */
-        if (!(x->ex_flags & EXFLAG_SI))
+        /* Increment path length if not a self issued CA */
+        if (!(is_ca && x->ex_flags & EXFLAG_SI))
             plen++;
         /*
          * If this certificate is a proxy certificate, the next certificate

From blaufish.public.email at gmail.com  Thu Oct  4 12:07:55 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Thu, 4 Oct 2018 14:07:55 +0200
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
In-Reply-To: <20181004102548.GW3589@straasha.imrryr.org>
References: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
 <20181003145101.GR3589@straasha.imrryr.org>
 <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>
 <20181004102548.GW3589@straasha.imrryr.org>
Message-ID: <CANtcRX6sGadOLX1BiyGwungSuTQtpK3cX7==NZEfcmAWW5YiTw@mail.gmail.com>

Your patch does seem to resolve the test case.

II have maximised confusion by generating a CSR with the same textual
information for EvilCA as EvilServer.

I don't think the chain includes any self signed certificates except the root;
73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6 (root, self issued)
DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70 issued by
73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6.
17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0 issued by
DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70.
1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6 issued by
17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0.

Modulus of evilca.pem begins with 00:cd:ba:9f and modulus of
evilserver.pem begins with 00:af:83:6f, so they are different even if
both have  Subject: C=SE, ST=EvilServer, L=EvilServer, O=EvilServer,
OU=EvilServer, CN=EvilServer.

Funnily enough I don't trigger the edge case on regenerated files with
correct Subject information.

openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6
--
--
                73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6
            X509v3 Authority Key Identifier:

keyid:73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6
openssl x509 -text -in intermediate.pem | egrep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70
--
--
                DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70
            X509v3 Authority Key Identifier:

keyid:73:40:2A:49:4B:AA:69:06:CF:45:F3:24:A6:B6:76:6A:10:97:74:D6
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0
--
--
                17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0
            X509v3 Authority Key Identifier:

keyid:DC:99:4E:EE:8A:5C:75:D3:C7:5E:03:1E:73:57:F2:C4:C5:89:FD:70
openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
                TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6
--
--
                1F:95:2F:26:9D:E1:37:BD:1F:9C:B5:51:FC:28:9C:EA:9F:1E:C8:B6
            X509v3 Authority Key Identifier:

keyid:17:49:AA:01:F6:25:85:23:3F:A6:7A:43:D3:97:2A:F8:74:27:89:A0
On Thu, Oct 4, 2018 at 12:26 PM Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
>
> On Wed, Oct 03, 2018 at 07:16:51PM +0200, Peter Magnusson wrote:
>
> > The following test case attempts to validates evilserver.pem, issued
> > by evilca.pem.
>
> More specifically, we see that in this test the leaf server certificate
> has the same subject and issuer, so EXFLAG_SI is set for that
> certificate, and it did not count in the path length:
>
>     $ /usr/local/bin/openssl verify -show_chain -verbose -trusted root.pem -untrusted untrusted.pem evilserver.pem
>     evilserver.pem: OK
>     Chain:
>     depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = EvilServer, CN = EvilServer (untrusted)
>     depth=1: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU = EvilServer, CN = EvilServer (untrusted)
>     depth=2: C = SE, ST = Intermediate, O = Intermediate, OU = Intermediate, CN = Intermediate (untrusted)
>     depth=3: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
>
> but this corner-case is not correct, the concept of "self-issued"
> only applies to CAs, so for the leaf to be skipped it would have
> the be a self-issued CA.  Try the patch below:
>
> --
>         Viktor.
>
> diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
> index 3a60d412da..77ca325d54 100644
> --- a/crypto/x509/x509_vfy.c
> +++ b/crypto/x509/x509_vfy.c
> @@ -445,6 +445,7 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
>      int i, must_be_ca, plen = 0;
>      X509 *x;
>      int proxy_path_length = 0;
> +    int is_ca;
>      int purpose;
>      int allow_proxy_certs;
>      int num = sk_X509_num(ctx->chain);
> @@ -484,7 +485,7 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
>                                  X509_V_ERR_PROXY_CERTIFICATES_NOT_ALLOWED))
>                  return 0;
>          }
> -        ret = X509_check_ca(x);
> +        ret = is_ca = X509_check_ca(x);
>          switch (must_be_ca) {
>          case -1:
>              if ((ctx->param->flags & X509_V_FLAG_X509_STRICT)
> @@ -524,8 +525,8 @@ static int check_chain_extensions(X509_STORE_CTX *ctx)
>              if (!verify_cb_cert(ctx, x, i, X509_V_ERR_PATH_LENGTH_EXCEEDED))
>                  return 0;
>          }
> -        /* Increment path length if not self issued */
> -        if (!(x->ex_flags & EXFLAG_SI))
> +        /* Increment path length if not a self issued CA */
> +        if (!(is_ca && x->ex_flags & EXFLAG_SI))
>              plen++;
>          /*
>           * If this certificate is a proxy certificate, the next certificate
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From andres.traumann.01 at gmail.com  Thu Oct  4 14:49:02 2018
From: andres.traumann.01 at gmail.com (Andres Traumann)
Date: Thu, 4 Oct 2018 17:49:02 +0300
Subject: [openssl-users] Seeding before RSA key generation
Message-ID: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>

Hello,

In the documentation it is written: "The pseudo-random number generator 
must be seeded prior to calling RSA_generate_key_ex()".

After reading the documentation in 
https://wiki.openssl.org/index.php/Random_Numbers and investigating the 
source code, it seems that the seeding is in fact done automatically 
from /dev/random in systems that have it. Also, when examining the 
source code of apps/genrsa.c there does not seem to be any explicit 
seeding either.

Do I still need to explicitly seed before calling RSA_generate_key_ex?

Best
Andres


From rsalz at akamai.com  Thu Oct  4 15:14:38 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 4 Oct 2018 15:14:38 +0000
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
Message-ID: <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>

Which version of OpenSSL are you using?

1.0.2 and 1.1.0 have a bad random number generator and must be explicitly seeded.  1.1.1 has a good random number generator and auto-seeds.


From jb-openssl at wisemo.com  Thu Oct  4 15:33:41 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 4 Oct 2018 17:33:41 +0200
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
Message-ID: <393c0e6c-c189-60a6-f158-908055e90ee2@wisemo.com>

On 04/10/2018 17:14, Salz, Rich via openssl-users wrote:
> Which version of OpenSSL are you using?
>
> 1.0.2 and 1.1.0 have a bad random number generator and must be explicitly seeded.  1.1.1 has a good random number generator and auto-seeds.
>
What's supposedly bad about the 1.0.x/1.1.0 OpenSSL RNG other
than not being an NSA/NIST design?

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 rsalz at akamai.com  Thu Oct  4 15:38:48 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 4 Oct 2018 15:38:48 +0000
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <393c0e6c-c189-60a6-f158-908055e90ee2@wisemo.com>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
 <393c0e6c-c189-60a6-f158-908055e90ee2@wisemo.com>
Message-ID: <D8E223F8-0BF2-4148-A9BE-DDDC26FC6A6C@akamai.com>

>    What's supposedly bad about the 1.0.x/1.1.0 OpenSSL RNG other
    than not being an NSA/NIST design?
  
Poor locking; been known to crash.

Does not reseed.

Global across the process, rather than isolated for private-key generation or per-connection.

Mixes in getpid and time to get "better" random bytes.

Has a "pseudo-rand" feature.

Never was cryptographically evaluated.



From matt at openssl.org  Thu Oct  4 15:47:39 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 4 Oct 2018 16:47:39 +0100
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
Message-ID: <5dbbc1b1-3f3d-94a5-8f3b-46c030e9bbc9@openssl.org>



On 04/10/18 16:14, Salz, Rich via openssl-users wrote:
> Which version of OpenSSL are you using?
> 
> 1.0.2 and 1.1.0 have a bad random number generator and must be explicitly seeded.

This is not correct. The RNG in 1.0.2 and 1.1.0 automatically seeds.
There is no need to explicitly seed it. I also wouldn't describe it as
"bad". 1.1.1 has a much better RNG, but there is no reason not to trust
and use the 1.0.2 and 1.1.0 RNG.

>  1.1.1 has a good random number generator and auto-seeds.
> 

1.0.2 and 1.1.0 auto seed. 1.1.1 additionally auto-*re*seeds.

Matt

From openssl-users at dukhovni.org  Thu Oct  4 15:54:49 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 4 Oct 2018 11:54:49 -0400
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
In-Reply-To: <CANtcRX6sGadOLX1BiyGwungSuTQtpK3cX7==NZEfcmAWW5YiTw@mail.gmail.com>
References: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
 <20181003145101.GR3589@straasha.imrryr.org>
 <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>
 <20181004102548.GW3589@straasha.imrryr.org>
 <CANtcRX6sGadOLX1BiyGwungSuTQtpK3cX7==NZEfcmAWW5YiTw@mail.gmail.com>
Message-ID: <20181004155449.GY3589@straasha.imrryr.org>

On Thu, Oct 04, 2018 at 02:07:55PM +0200, Peter Magnusson wrote:

> Modulus of evilca.pem begins with 00:cd:ba:9f and modulus of
> evilserver.pem begins with 00:af:83:6f, so they are different even if
> both have  Subject: C=SE, ST=EvilServer, L=EvilServer, O=EvilServer,
> OU=EvilServer, CN=EvilServer.

That's the difference between self-signed and self-issued.  The
root CA is self-signed.  Your previous EE cert would have been
self-issued, had it been a CA.  But it had CA:FALSE, which makes
it not self-issued per RFC5280, as that classification applies only
to CAs.

> Funnily enough I don't trigger the edge case on regenerated files with
> correct Subject information.

That's not "funnily enough", that's expected, if my analysis of the
problem is correct, i.e. the problem is that the existing code
treats even non-CA leaf certs as self-issued provided the subject
and issuer match.  This throws the path length constraint checks off
by 1 in just the case of "self-issued but for the CA bit" EE certs.

The proposed patch is intended to resolve that issue.  If my analysis
is correct (please test any more interesting combinations you can
come up with), then the patch should be merged into the existing
OpenSSL supported releases and perhaps also related OpenSSL forks
(either or both of LibreSSL or BoringSSL that have not changed the
code in question).

-- 
	Viktor.

From jb-openssl at wisemo.com  Thu Oct  4 15:58:43 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 4 Oct 2018 17:58:43 +0200
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <D8E223F8-0BF2-4148-A9BE-DDDC26FC6A6C@akamai.com>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
 <393c0e6c-c189-60a6-f158-908055e90ee2@wisemo.com>
 <D8E223F8-0BF2-4148-A9BE-DDDC26FC6A6C@akamai.com>
Message-ID: <95d2501d-5a51-fc08-d7ae-00fc38efe7cd@wisemo.com>

On 04/10/2018 17:38, Salz, Rich wrote:
>>     What's supposedly bad about the 1.0.x/1.1.0 OpenSSL RNG other
>      than not being an NSA/NIST design?
>    
> Poor locking; been known to crash.

Simple bug, not a reason to change the algorithm.

> 
> Does not reseed.

But can be reseeded if so desired, subject to locking.

> 
> Global across the process, rather than isolated for private-key generation or per-connection.

This is good, not bad.

> 
> Mixes in getpid and time to get "better" random bytes.

This gives 2 to 5 extra bits on machines with little available entropy,
provided init is not done too early in the machine boot process.  There
seem to be much stronger sources loaded where available.

> 
> Has a "pseudo-rand" feature.

This is a clearly marked feature useful when the entropy sources are
significantly slower than the random bit need, such as on a busy TLS
server with a serial port (or slower) entropy source.

> 
> Never was cryptographically evaluated.
> 

By whom?, I would expect the very public OpenSSL RNG to have been
subjected to lots of 3rd party review outside the Foundation.

The new design is taken from a document that was insufficiently publicly
reviewed and was later found to contain a likely backdoor in one of its
other suggested RNG designs, making the entire document highly dubious.




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 rsalz at akamai.com  Thu Oct  4 16:05:46 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 4 Oct 2018 16:05:46 +0000
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <95d2501d-5a51-fc08-d7ae-00fc38efe7cd@wisemo.com>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
 <393c0e6c-c189-60a6-f158-908055e90ee2@wisemo.com>
 <D8E223F8-0BF2-4148-A9BE-DDDC26FC6A6C@akamai.com>
 <95d2501d-5a51-fc08-d7ae-00fc38efe7cd@wisemo.com>
Message-ID: <CD09BCE1-F738-47A1-9935-8C2EB80F84F8@akamai.com>

We disagree, and as I wrote the latest RNG code and docs, I'm biased (sic).  I'll leave on that weak pun.


From rsalz at akamai.com  Thu Oct  4 16:06:42 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 4 Oct 2018 16:06:42 +0000
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <5dbbc1b1-3f3d-94a5-8f3b-46c030e9bbc9@openssl.org>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
 <5dbbc1b1-3f3d-94a5-8f3b-46c030e9bbc9@openssl.org>
Message-ID: <BD6C8D29-508B-41DA-BA07-18DDAF0B83D3@akamai.com>

>    This is not correct.

Thanks for the corrections, Matt.


From andres.traumann.01 at gmail.com  Thu Oct  4 17:54:11 2018
From: andres.traumann.01 at gmail.com (Andres Traumann)
Date: Thu, 4 Oct 2018 20:54:11 +0300
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <5dbbc1b1-3f3d-94a5-8f3b-46c030e9bbc9@openssl.org>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
 <5dbbc1b1-3f3d-94a5-8f3b-46c030e9bbc9@openssl.org>
Message-ID: <33957bf2-be89-bd11-3002-f1a62dea4695@gmail.com>

Thank you for your help.

Andres

On 10/4/18 6:47 PM, Matt Caswell wrote:
>
> On 04/10/18 16:14, Salz, Rich via openssl-users wrote:
>> Which version of OpenSSL are you using?
>>
>> 1.0.2 and 1.1.0 have a bad random number generator and must be explicitly seeded.
> This is not correct. The RNG in 1.0.2 and 1.1.0 automatically seeds.
> There is no need to explicitly seed it. I also wouldn't describe it as
> "bad". 1.1.1 has a much better RNG, but there is no reason not to trust
> and use the 1.0.2 and 1.1.0 RNG.
>
>>   1.1.1 has a good random number generator and auto-seeds.
>>
> 1.0.2 and 1.1.0 auto seed. 1.1.1 additionally auto-*re*seeds.
>
> Matt

From paul.dale at oracle.com  Thu Oct  4 23:33:24 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Thu, 4 Oct 2018 23:33:24 +0000 (UTC)
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <33957bf2-be89-bd11-3002-f1a62dea4695@gmail.com>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
 <5dbbc1b1-3f3d-94a5-8f3b-46c030e9bbc9@openssl.org>
 <33957bf2-be89-bd11-3002-f1a62dea4695@gmail.com>
Message-ID: <61e07d1f-495c-46e7-9795-1c1941c9a4b4@default>

Not mentioned thus far is that if you are using 1.0.2 with FIPS support, the random number generator does not self-seed.


Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia


-----Original Message-----
From: Andres Traumann [mailto:andres.traumann.01 at gmail.com] 
Sent: Friday, 5 October 2018 3:54 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Seeding before RSA key generation

Thank you for your help.

Andres

On 10/4/18 6:47 PM, Matt Caswell wrote:
>
> On 04/10/18 16:14, Salz, Rich via openssl-users wrote:
>> Which version of OpenSSL are you using?
>>
>> 1.0.2 and 1.1.0 have a bad random number generator and must be explicitly seeded.
> This is not correct. The RNG in 1.0.2 and 1.1.0 automatically seeds.
> There is no need to explicitly seed it. I also wouldn't describe it as 
> "bad". 1.1.1 has a much better RNG, but there is no reason not to 
> trust and use the 1.0.2 and 1.1.0 RNG.
>
>>   1.1.1 has a good random number generator and auto-seeds.
>>
> 1.0.2 and 1.1.0 auto seed. 1.1.1 additionally auto-*re*seeds.
>
> Matt
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From openssl-users at dukhovni.org  Fri Oct  5 05:09:48 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 5 Oct 2018 01:09:48 -0400
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
In-Reply-To: <20181004102548.GW3589@straasha.imrryr.org>
References: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
 <20181003145101.GR3589@straasha.imrryr.org>
 <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>
 <20181004102548.GW3589@straasha.imrryr.org>
Message-ID: <C1B56B79-3C9F-4BAD-92FD-71DE94FC0DFB@dukhovni.org>



> On Oct 4, 2018, at 6:25 AM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
> but this corner-case is not correct, the concept of "self-issued"
> only applies to CAs, so for the leaf to be skipped it would have
> the be a self-issued CA.  Try the patch below:

I've simplified the patch in https://github.com/openssl/openssl/pull/7353
please take a look.

-- 
	Viktor.


From saimohangajula at gmail.com  Fri Oct  5 05:12:40 2018
From: saimohangajula at gmail.com (Saimohan Gajula)
Date: Fri, 5 Oct 2018 10:42:40 +0530
Subject: [openssl-users] Reg: [Crash inside SSL_CTX_free ()]
Message-ID: <CAMx7D=6=q4w2AuLv7YCAozh95fHq8qJ_ko=P9rkFgFwPTsxEDQ@mail.gmail.com>

Hi,

We are encountering the crash inside the SSL_CTX_free(). Any leads for the
solution will be greatly appreciated.

We are using openssl 1_0_2 and  libcrypto.so.1.0.0.

Please help us know if anyone else also faced this issue earlier.

Kindly find the Stack trace for your reference

Stack: #0 0x00007fc013fae51d in lh_insert () from
/lib/x86_64/libcrypto.so.1.0.0
#1 0x00007fc013ef74f9 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
#2 0x00007fc013ef7ed2 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
#3 0x00007fc013fdd879 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
#4 0x00007fc013fe2530 in asn1_item_combine_free () from
/lib/x86_64/libcrypto.so.1.0.0
#5 0x00007fc013fe27a4 in ASN1_item_free () from
/lib/x86_64/libcrypto.so.1.0.0
#6 0x00007fc0140063d1 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
#7 0x00007fc013fae001 in sk_pop_free () from /lib/x86_64/libcrypto.so.1.0.0
#8 0x00007fc0140068f4 in X509_STORE_free () from
/lib/x86_64/libcrypto.so.1.0.0
#9 0x00007fc01433ef12 in SSL_CTX_free () from /lib/x86_64/libssl.so.1.0.0

Thanks for your help!!!

Best Regards,
Sai.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181005/b4715a38/attachment.html>

From openssl-users at dukhovni.org  Fri Oct  5 05:21:05 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 5 Oct 2018 01:21:05 -0400
Subject: [openssl-users] Reg: [Crash inside SSL_CTX_free ()]
In-Reply-To: <CAMx7D=6=q4w2AuLv7YCAozh95fHq8qJ_ko=P9rkFgFwPTsxEDQ@mail.gmail.com>
References: <CAMx7D=6=q4w2AuLv7YCAozh95fHq8qJ_ko=P9rkFgFwPTsxEDQ@mail.gmail.com>
Message-ID: <2A9F84B6-4AE6-417C-BBC1-18633D392702@dukhovni.org>

You either have threading problems are sharing structures without
proper reference counting or other protections.  Perhaps the
X509_STORE used in the context was already freed by some other
caller?  Or something completely unrelated corrupted the heap.
The below is not sufficient for anyone else to help you, time
to get good at using a debugger, you probably want an SSL
library compiled with debugging symbols and not stripped.

> On Oct 5, 2018, at 1:12 AM, Saimohan Gajula <saimohangajula at gmail.com> wrote:
> 
> We are encountering the crash inside the SSL_CTX_free(). Any leads for the solution will be greatly appreciated.
> 
> We are using openssl 1_0_2 and  libcrypto.so.1.0.0.
> 
> Please help us know if anyone else also faced this issue earlier.
> 
> Kindly find the Stack trace for your reference
> 
> Stack: #0 0x00007fc013fae51d in lh_insert () from /lib/x86_64/libcrypto.so.1.0.0
> #1 0x00007fc013ef74f9 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
> #2 0x00007fc013ef7ed2 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
> #3 0x00007fc013fdd879 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
> #4 0x00007fc013fe2530 in asn1_item_combine_free () from /lib/x86_64/libcrypto.so.1.0.0
> #5 0x00007fc013fe27a4 in ASN1_item_free () from /lib/x86_64/libcrypto.so.1.0.0
> #6 0x00007fc0140063d1 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
> #7 0x00007fc013fae001 in sk_pop_free () from /lib/x86_64/libcrypto.so.1.0.0
> #8 0x00007fc0140068f4 in X509_STORE_free () from /lib/x86_64/libcrypto.so.1.0.0
> #9 0x00007fc01433ef12 in SSL_CTX_free () from /lib/x86_64/libssl.so.1.0.0

-- 
	Viktor.


From saimohangajula at gmail.com  Fri Oct  5 06:07:50 2018
From: saimohangajula at gmail.com (Saimohan Gajula)
Date: Fri, 5 Oct 2018 11:37:50 +0530
Subject: [openssl-users] Reg: [Crash inside SSL_CTX_free ()]
In-Reply-To: <2A9F84B6-4AE6-417C-BBC1-18633D392702@dukhovni.org>
References: <CAMx7D=6=q4w2AuLv7YCAozh95fHq8qJ_ko=P9rkFgFwPTsxEDQ@mail.gmail.com>
 <2A9F84B6-4AE6-417C-BBC1-18633D392702@dukhovni.org>
Message-ID: <CAMx7D=45CPzo2SJQUOCibD456xOPXW4_U=oWiK_b+D-KhWQt8Q@mail.gmail.com>

Hi Viktor,

Please find the stack trace with the debugging information .
Kindly check if it helps.

#0  0x00007fc013fae51d in lh_insert () from /lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#1  0x00007fc013ef74f9 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#2  0x00007fc013ef7ed2 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#3  0x00007fc013fdd879 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#4  0x00007fc013fe2530 in asn1_item_combine_free () from
/lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#5  0x00007fc013fe27a4 in ASN1_item_free () from /lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#6  0x00007fc0140063d1 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#7  0x00007fc013fae001 in sk_pop_free () from /lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#8  0x00007fc0140068f4 in X509_STORE_free () from /lib/x86_64/libcrypto.so.1.0.0
No symbol table info available.
#9  0x00007fc01433ef12 in SSL_CTX_free () from /lib/x86_64/libssl.so.1.0.0
No symbol table info available.
#10 0x00007fc0089b9a89 in bedrock::net::ContextEntry::~ContextEntry
(this=0x558451bc6730, __in_chrg=<optimized out>) at
src/libs/libjcore/src/bedrock/net/ssl/MultidomainCerts.hpp:63
No locals.
#11 bedrock::net::ContextEntry::~ContextEntry (this=0x558451bc6730,
__in_chrg=<optimized out>) at
src/libs/libjcore/src/bedrock/net/ssl/MultidomainCerts.hpp:66
No locals.
#12 bedrock::net::MultidomainCertContexts::~MultidomainCertContexts
(this=0x558451ba6778, __in_chrg=<optimized out>) at
src/libs/libjcore/src/bedrock/net/ssl/MultidomainCerts.cpp:368
        entry = 0x558451bc6730
        iter = {
          _M_node = 0x558451bbb7b0
        }
#13 0x00007fc0089b85cd in
bedrock::net::OpenSSL_SSLParams::~OpenSSL_SSLParams
(this=0x558451ba65e0, __in_chrg=<optimized out>) at
src/libs/libjcore/src/bedrock/net/ssl/OpenSSL_SSL.cpp:404
No locals.
#14 0x00007fc0089b86fc in
bedrock::net::OpenSSL_SSLParams::~OpenSSL_SSLParams
(this=0x558451ba65e0, __in_chrg=<optimized out>) at
src/libs/libjcore/src/bedrock/net/ssl/OpenSSL_SSL.cpp:453
No locals.
#15 0x00007fc014f137c7 in jax::JAXConnection::~JAXConnection
(this=0x558451b96f10, __in_chrg=<optimized out>) at
src/libs/libjcore/src/jax/JAXConnection.cpp:184
No locals.
#16 0x00007fc014f138dc in jax::JAXConnection::~JAXConnection
(this=0x558451b96f10, __in_chrg=<optimized out>) at
src/libs/libjcore/src/jax/JAXConnection.cpp:185
No locals.
#17 0x00007fc014f158e8 in jax::JAXConnection::_shutdown_cb
(this=0x558451b96f10) at
src/libs/libjcore/src/jax/JAXConnection.cpp:357
No locals.
#18 0x00007fc014ebee9c in bedrock::ThreadPool::Worker::run
(arg=0x558451ade050) at
src/libs/libjcore/src/bedrock/ThreadPool.cpp:379
        fh = 0x558451be4180
        worker = 0x558451ade050
#19 0x00007fc0126ac633 in start_thread (arg=0x7fc010024700) at
pthread_create.c:463
        pd = 0x7fc010024700
        now = <optimized out>
        unwind_buf = {
          cancel_jmp_buf =             {[0] = {
              jmp_buf =                 {[0] = 140462879033088,
                [1] = -4982464771670778168,
                [2] = 140729306381518,
                [3] = 140729306381519,
                [4] = 140729306381520,
                [5] = 0,
                [6] = 4997476835555696328,
                [7] = 4997480896125492936},
              mask_was_saved = 0
            }},
          priv = {
            pad =               {[0] = 0x0,
              [1] = 0x0,
              [2] = 0x0,
              [3] = 0x0},
            data = {
              prev = 0x0,
              cleanup = 0x0,
              canceltype = 0
            }
          }
        }
        not_first_call = <optimized out>
#20 0x00007fc0123df98f in clone () from /lib/x86_64/libc.so.6


Thanks & Regards,
Sai




On Fri, Oct 5, 2018 at 10:51 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> You either have threading problems are sharing structures without
> proper reference counting or other protections.  Perhaps the
> X509_STORE used in the context was already freed by some other
> caller?  Or something completely unrelated corrupted the heap.
> The below is not sufficient for anyone else to help you, time
> to get good at using a debugger, you probably want an SSL
> library compiled with debugging symbols and not stripped.
>
> > On Oct 5, 2018, at 1:12 AM, Saimohan Gajula <saimohangajula at gmail.com>
> wrote:
> >
> > We are encountering the crash inside the SSL_CTX_free(). Any leads for
> the solution will be greatly appreciated.
> >
> > We are using openssl 1_0_2 and  libcrypto.so.1.0.0.
> >
> > Please help us know if anyone else also faced this issue earlier.
> >
> > Kindly find the Stack trace for your reference
> >
> > Stack: #0 0x00007fc013fae51d in lh_insert () from
> /lib/x86_64/libcrypto.so.1.0.0
> > #1 0x00007fc013ef74f9 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
> > #2 0x00007fc013ef7ed2 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
> > #3 0x00007fc013fdd879 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
> > #4 0x00007fc013fe2530 in asn1_item_combine_free () from
> /lib/x86_64/libcrypto.so.1.0.0
> > #5 0x00007fc013fe27a4 in ASN1_item_free () from
> /lib/x86_64/libcrypto.so.1.0.0
> > #6 0x00007fc0140063d1 in ?? () from /lib/x86_64/libcrypto.so.1.0.0
> > #7 0x00007fc013fae001 in sk_pop_free () from
> /lib/x86_64/libcrypto.so.1.0.0
> > #8 0x00007fc0140068f4 in X509_STORE_free () from
> /lib/x86_64/libcrypto.so.1.0.0
> > #9 0x00007fc01433ef12 in SSL_CTX_free () from /lib/x86_64/libssl.so.1.0.0
>
> --
>         Viktor.
>
> --
> 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/20181005/69ac2c91/attachment-0001.html>

From openssl-users at dukhovni.org  Fri Oct  5 06:14:05 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 5 Oct 2018 02:14:05 -0400
Subject: [openssl-users] Reg: [Crash inside SSL_CTX_free ()]
In-Reply-To: <CAMx7D=45CPzo2SJQUOCibD456xOPXW4_U=oWiK_b+D-KhWQt8Q@mail.gmail.com>
References: <CAMx7D=6=q4w2AuLv7YCAozh95fHq8qJ_ko=P9rkFgFwPTsxEDQ@mail.gmail.com>
 <2A9F84B6-4AE6-417C-BBC1-18633D392702@dukhovni.org>
 <CAMx7D=45CPzo2SJQUOCibD456xOPXW4_U=oWiK_b+D-KhWQt8Q@mail.gmail.com>
Message-ID: <0643F14B-1661-4290-987D-708EC83419B8@dukhovni.org>



> On Oct 5, 2018, at 2:07 AM, Saimohan Gajula <saimohangajula at gmail.com> wrote:
> 
> Please find the stack trace with the debugging information .
> Kindly check if it helps.

No, this problem really is yours to debug I'm afraid...

-- 
	Viktor.


From Matthias.St.Pierre at ncp-e.com  Fri Oct  5 08:38:41 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Fri, 5 Oct 2018 08:38:41 +0000
Subject: [openssl-users] Seeding before RSA key generation
In-Reply-To: <61e07d1f-495c-46e7-9795-1c1941c9a4b4@default>
References: <f53da3dc-7e64-2b96-23ec-484bfee942eb@gmail.com>
 <50652E6F-6B8C-4333-8D39-EC1FFEEB933C@akamai.com>
 <5dbbc1b1-3f3d-94a5-8f3b-46c030e9bbc9@openssl.org>
 <33957bf2-be89-bd11-3002-f1a62dea4695@gmail.com>
 <61e07d1f-495c-46e7-9795-1c1941c9a4b4@default>
Message-ID: <db6e74809c9b4c3fb57fac89d28fc213@Ex13.ncp.local>


> -----Urspr?ngliche Nachricht-----
> Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Paul Dale
> Gesendet: Freitag, 5. Oktober 2018 01:33
> An: openssl-users at openssl.org
> Betreff: Re: [openssl-users] Seeding before RSA key generation
> 
> Not mentioned thus far is that if you are using 1.0.2 with FIPS support, the random number generator does not self-seed.

This is true, but it will be fixed in the next letter release 1.0.2q, see commit

https://github.com/openssl/openssl/commit/f58001c35f39c50cb4aabcbc234d871ac740c179

which has been added recently to the OpenSSL_1_0_2-stable branch.

Matthias


From lintamaria194 at gmail.com  Fri Oct  5 09:38:20 2018
From: lintamaria194 at gmail.com (Linta Maria)
Date: Fri, 5 Oct 2018 15:08:20 +0530
Subject: [openssl-users] Sign and verification using ECC 25519 curve-
	Bernstein
In-Reply-To: <b97ac78f-ceb6-adb6-3fd2-0dd9529d6574@openssl.org>
References: <CANzpxQcePx6WE_Xtg6TQaCV7V8n_GaChpHeEgTP7ePrh7GbDFQ@mail.gmail.com>
 <b97ac78f-ceb6-adb6-3fd2-0dd9529d6574@openssl.org>
Message-ID: <CANzpxQccoA-m6V4Kmg5QtiKXfRHiBizLQESKbDd7i+Jv7jqLtA@mail.gmail.com>

Hi,

I am using Qnx 7.0.0 which make use of openssl 1.0.2j.

Can you please confirm if I can use ECC related api from openssl which is
supported by openssl 1.1.0.




On Mon, 1 Oct 2018, 3:41 pm Matt Caswell, <matt at openssl.org> wrote:

>
>
> On 01/10/18 10:11, Linta Maria wrote:
> > Hi all,
> >
> > Does openssl supports sign and verification using ECC 25519 curve
> > Bernstein?
> >
> >
>
> Yes. See:
>
> https://www.openssl.org/docs/man1.1.1/man7/Ed25519.html
>
> 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/20181005/3bb23892/attachment.html>

From blaufish.public.email at gmail.com  Fri Oct  5 09:57:32 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Fri, 5 Oct 2018 11:57:32 +0200
Subject: [openssl-users] openssl verify accepting CA certs issued by
 intermediate with CA:TRUE, pathlen:0
In-Reply-To: <C1B56B79-3C9F-4BAD-92FD-71DE94FC0DFB@dukhovni.org>
References: <CANtcRX5kh_2zkaQWAGHwUmKfZw-+P=g=Cg4LfC1SMPD=qifsyQ@mail.gmail.com>
 <20181003145101.GR3589@straasha.imrryr.org>
 <CANtcRX6Rpeb57vykCSE2bY2Uq9E0xs=BWzL7gpw2PAFtn+iivg@mail.gmail.com>
 <20181004102548.GW3589@straasha.imrryr.org>
 <C1B56B79-3C9F-4BAD-92FD-71DE94FC0DFB@dukhovni.org>
Message-ID: <CANtcRX4HxQNY7HAH-GayDW2=4==fwL4BH63cqpuWG0GpA_Cfbg@mail.gmail.com>

Thanks, I provided some input regarding off by one calculation of plen
still present in the patch.

You are very much correct on the definition of self-issued; rfc5280,
"A certificate is self-issued if the same DN appears in the subject
and issuer fields (the two DNs are the same if they match according to
the rules specified in Section 7.1)." Effectively path length
constraint is useless for limiting impact of a temporary CA breach, as
attacker can just issue an intermediate authority with a DN that
matches the definition of self-issued. The feature simply doesn't
provide the functionality I presumed it was it core purpose of
providing. It was very lucky for me I messed up my DN's so I could
learn that, thank you *very* much for your input, that was very useful
to be aware of!

Best Regards
//P
On Fri, Oct 5, 2018 at 7:10 AM Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
>
>
>
> > On Oct 4, 2018, at 6:25 AM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> >
> > but this corner-case is not correct, the concept of "self-issued"
> > only applies to CAs, so for the leaf to be skipped it would have
> > the be a self-issued CA.  Try the patch below:
>
> I've simplified the patch in https://github.com/openssl/openssl/pull/7353
> please take a look.
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From matt at openssl.org  Fri Oct  5 10:07:57 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 5 Oct 2018 11:07:57 +0100
Subject: [openssl-users] Sign and verification using ECC 25519 curve-
 Bernstein
In-Reply-To: <CANzpxQccoA-m6V4Kmg5QtiKXfRHiBizLQESKbDd7i+Jv7jqLtA@mail.gmail.com>
References: <CANzpxQcePx6WE_Xtg6TQaCV7V8n_GaChpHeEgTP7ePrh7GbDFQ@mail.gmail.com>
 <b97ac78f-ceb6-adb6-3fd2-0dd9529d6574@openssl.org>
 <CANzpxQccoA-m6V4Kmg5QtiKXfRHiBizLQESKbDd7i+Jv7jqLtA@mail.gmail.com>
Message-ID: <da907c59-47f6-1e2a-0e10-ec35fce10e57@openssl.org>



On 05/10/18 10:38, Linta Maria wrote:
> Hi,
> 
> I am using Qnx 7.0.0 which make use of openssl 1.0.2j.
> 
> Can you please confirm if I can use ECC related api from openssl which
> is supported by openssl 1.1.0.

OpenSSL 1.1.0 does not support sign/verify using 25519 (i.e. Ed25519).
That is only available in OpenSSL 1.1.1.

Matt

> 
> 
> 
> 
> On Mon, 1 Oct 2018, 3:41 pm Matt Caswell, <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 01/10/18 10:11, Linta Maria wrote:
>     > Hi all,
>     >
>     > Does openssl supports sign and verification using ECC 25519 curve
>     > Bernstein??
>     >
>     >
> 
>     Yes. See:
> 
>     https://www.openssl.org/docs/man1.1.1/man7/Ed25519.html
> 
>     Matt
>     -- 
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 

From bbrumley at gmail.com  Sat Oct  6 13:15:13 2018
From: bbrumley at gmail.com (Billy Brumley)
Date: Sat, 6 Oct 2018 16:15:13 +0300
Subject: [openssl-users] Sign and verification using ECC 25519 curve-
	Bernstein
In-Reply-To: <da907c59-47f6-1e2a-0e10-ec35fce10e57@openssl.org>
References: <CANzpxQcePx6WE_Xtg6TQaCV7V8n_GaChpHeEgTP7ePrh7GbDFQ@mail.gmail.com>
 <b97ac78f-ceb6-adb6-3fd2-0dd9529d6574@openssl.org>
 <CANzpxQccoA-m6V4Kmg5QtiKXfRHiBizLQESKbDd7i+Jv7jqLtA@mail.gmail.com>
 <da907c59-47f6-1e2a-0e10-ec35fce10e57@openssl.org>
Message-ID: <CAFeDd5bDuBLbRjPtN_eLh4+J1bZ_ct43LhWf9-=wvR0pnfcnuQ@mail.gmail.com>

> > I am using Qnx 7.0.0 which make use of openssl 1.0.2j.
> >
> > Can you please confirm if I can use ECC related api from openssl which
> > is supported by openssl 1.1.0.
>
> OpenSSL 1.1.0 does not support sign/verify using 25519 (i.e. Ed25519).
> That is only available in OpenSSL 1.1.1.

Shameless self plug -- libsuola is an OpenSSL engine providing
curve25519 and ed25519 support for 1.0.2, 1.1.0, and 1.1.1:

https://github.com/romen/libsuola

With different "backends" including libsodium or formally verified HACL*.

BBB

From paul at zil.li  Sat Oct  6 20:48:01 2018
From: paul at zil.li (Paul Zillmann)
Date: Sat, 6 Oct 2018 22:48:01 +0200
Subject: [openssl-users] Wiki misleading Enc
Message-ID: <1df7e534-d4f0-7ac1-4de5-4cb8fb37d9e0@zil.li>

Hello,

the wiki page [1] is wrong about the pass parameter.
According to [2] the parameter for a keyfile is -pass file:path and not 
-pass pass:path

- Paul

1: https://wiki.openssl.org/index.php/Enc
2: https://www.openssl.org/docs/man1.0.2/apps/openssl.html

From john.hughes at secid.co.uk  Sun Oct  7 20:39:34 2018
From: john.hughes at secid.co.uk (John Hughes)
Date: Sun, 7 Oct 2018 21:39:34 +0100
Subject: [openssl-users] Incompatible Object error from EC_POINT_mul
Message-ID: <010701d45e7d$dbb7dd50$932797f0$@secid.co.uk>

I'm trying to generate a public key from a private key generated on a HSM
(and obtained by calling PKCS#11). Everything works fine until I call
EC_POINT_mul - at which point I get the error message:

       error:100BB065:elliptic curve routines:ec_wNAF_mul:incompatible
objects

I have checked the BIGNUM conversion - and that seems to be fine. The key
pair on the HSM is also generated using brainpoolP256r1.

The basis of the code can be found at the end of the email. I'm basically
trying to follow the example provided in:
	https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography.

I'm using openssl 1.10h

Any pointers or help would be appreciated.


John

---------------------------------------------------------------


	BN_CTX *ctx;
	ctx = BN_CTX_new();
	if(!ctx) {
		outputInfo("unable to create openssl BN_CTX");
		return;
	}

	EC_GROUP *curve;

	outputInfo("about to create EC_GROUP_new_by_curve_name");
	if(NULL == (curve =
EC_GROUP_new_by_curve_name(NID_brainpoolP256r1))) {
		outputERRORmess("unable to setup curve");
	}

	outputInfo("about to create EC_KEY_new_by_curve_name");
	EC_KEY *key;
	if(NULL == (key = EC_KEY_new_by_curve_name(NID_brainpoolP256r1))) {
		outputERRORmess("unable to setup EC_KEY");
	}

	// now get the private key contained in CKA_VALUE via PKCS#111 and
place in *attrPrivate.pValue 

		.......... (handle error)

	EC_POINT *pub;


	BIGNUM *prv = BN_bin2bn((unsigned char*)attrPrivate.pValue,
attrPrivate.ulValueLen, NULL);
	if (prv == NULL) {

	...... (handle error)
	}

	if (1 != EC_KEY_set_private_key(key, prv)) {

		........ (handle error)
	}

	if (1 != EC_POINT_mul(curve, pub, prv, NULL, NULL, ctx)) {
		outputInfo("unable to calculate the public key from the
HSM's private key using EC_POINT_mul");
		(handle error)

	}








From levitte at openssl.org  Mon Oct  8 05:03:34 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 08 Oct 2018 07:03:34 +0200 (CEST)
Subject: [openssl-users] Wiki misleading Enc
In-Reply-To: <1df7e534-d4f0-7ac1-4de5-4cb8fb37d9e0@zil.li>
References: <1df7e534-d4f0-7ac1-4de5-4cb8fb37d9e0@zil.li>
Message-ID: <20181008.070334.1188127225315146424.levitte@openssl.org>

Fixed.  Thanks.

In message <1df7e534-d4f0-7ac1-4de5-4cb8fb37d9e0 at zil.li> on Sat, 6 Oct 2018 22:48:01 +0200, Paul Zillmann <paul at zil.li> said:

> Hello,
> 
> the wiki page [1] is wrong about the pass parameter.
> According to [2] the parameter for a keyfile is -pass file:path and
> not -pass pass:path
> 
> - Paul
> 
> 1: https://wiki.openssl.org/index.php/Enc
> 2: https://www.openssl.org/docs/man1.0.2/apps/openssl.html
> 

From aakash.kumar at orange.com  Mon Oct  8 05:50:40 2018
From: aakash.kumar at orange.com (aakash.kumar at orange.com)
Date: Mon, 8 Oct 2018 05:50:40 +0000
Subject: [openssl-users] osf-contact Latest Openssl Issue with Bind
	9.12.2-P2 on RHEL 7.5
References: <16481_1538732473_5BB731B9_16481_434_1_1817b836-b685-4a91-8f34-48220e57495b@OPEXCSINM92.corporate.adroot.infra.ftgroup>
 <F88A928D-15C2-4FAB-B622-EF6D53EC5087@dukhovni.org> 
Message-ID: <14773_1538977844_5BBAF034_14773_368_1_D9E1007BEB274445807B4DF1046EDA271107638A@OPEXCSINM91.corporate.adroot.infra.ftgroup>

Hi Team,



Please find below error in text format.



[root at g3r1 ~]# systemctl status bind -l

? bind.service - LSB: DNS Daemon

   Loaded: loaded (/etc/rc.d/init.d/bind)

   Active: active (exited) since Fri 2018-10-05 13:31:09 CEST; 2 days ago

     Docs: man:systemd-sysv-generator(8)

  Process: 32417 ExecStop=/etc/rc.d/init.d/bind stop (code=exited, status=0/SUCCESS)

  Process: 32421 ExecStart=/etc/rc.d/init.d/bind start (code=exited, status=0/SUCCESS)



Oct 05 13:31:09 g3r1 named[32429]: ----------------------------------------------------

Oct 05 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to 1048576

Oct 05 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct 05 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct 05 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct 05 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct 05 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)

Oct 05 13:31:09 g3r1 named[32429]: exiting (due to fatal error in library)

Oct 05 13:31:09 g3r1 bind[32421]: [13B blob data]

Oct 05 13:31:09 g3r1 systemd[1]: Started LSB: DNS Daemon.





[root at g3r1 ~]# tail /var/log/message

Oct  5 13:31:09 g3r1 systemd: Starting LSB: DNS Daemon...

Oct  5 13:31:09 g3r1 bind: /etc/rc.d/init.d/bind: line 36: log_info_msg: command not found

Oct  5 13:31:09 g3r1 named[32429]: starting BIND 9.12.2-P2 <id:b2bf278>

Oct  5 13:31:09 g3r1 named[32429]: running on Linux x86_64 3.10.0-327.13.1.el7.x86_64 #1 SMP Mon Feb 29 13:22:02 EST 2016

Oct  5 13:31:09 g3r1 named[32429]: built with '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' 'mandir=/usr/share/man' '--enable-threads' '--with-libtool' '--with-openssl=/usr/local/ssl' '--disable-static' '--with-randomdev=/dev/urandom'

Oct  5 13:31:09 g3r1 named[32429]: running as: named -u named -t /srv/named -c /etc/named.conf

Oct  5 13:31:09 g3r1 named[32429]: compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-28)

Oct  5 13:31:09 g3r1 named[32429]: compiled with OpenSSL version: OpenSSL 1.0.2p  14 Aug 2018

Oct  5 13:31:09 g3r1 named[32429]: linked to OpenSSL version: OpenSSL 1.0.2p  14 Aug 2018

Oct  5 13:31:09 g3r1 named[32429]: compiled with zlib version: 1.2.7

Oct  5 13:31:09 g3r1 named[32429]: linked to zlib version: 1.2.7

Oct  5 13:31:09 g3r1 named[32429]: threads support is enabled

Oct  5 13:31:09 g3r1 named[32429]: ----------------------------------------------------

Oct  5 13:31:09 g3r1 named[32429]: BIND 9 is maintained by Internet Systems Consortium,

Oct  5 13:31:09 g3r1 named[32429]: Inc. (ISC), a non-profit 501(c)(3) public-benefit

Oct  5 13:31:09 g3r1 named[32429]: corporation.  Support and training for BIND 9 are

Oct  5 13:31:09 g3r1 named[32429]: available at https://www.isc.org/support

Oct  5 13:31:09 g3r1 named[32429]: ----------------------------------------------------

Oct  5 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to 1048576

Oct  5 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct  5 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct  5 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct  5 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct  5 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)





Thanks & Regards,



Aakash kumar

ITE - India

Tower B, 8th Floor, DLF Infinity Towers,

DLF Cyber City Phase - II

Gurgaon - 122002, Haryana, INDIA

Aakash.kumar at orange.com



  Mobile: +91-8527288977

  CVS: 7357 3706







-----Original Message-----
From: Viktor Dukhovni [mailto:openssl-users at dukhovni.org]
Sent: 05 October 2018 21:23
To: KUMAR Aakash IMT/OINIS
Cc: osf-contact at openssl.org; SRIVASTAVA Himanshu IMT/OINIS; VARSHNEY Praveen IMT/OINIS
Subject: Re: osf-contact Latest Openssl Issue with Bind 9.12.2-P2 on RHEL 7.5





Please try to send the text of error reports, not pictures.



> I am getting below error while starting the bind service.

>

> <image002.png>



If you ask on the openssl-users list, someone else may have seen

the same issue, and may have useful advice to share.



NOTE!!!:  I've set the Reply-To: address to <openssl-users at openssl.org>.

If you just hit "Reply", your answer may go to the list, though you'd

need to join the list first to be able to post...



Does the error still happen when you disable "chroot" in BIND?

Perhaps BIND is doing late initialization of the PRNG after

entering the chroot jail, and maybe trying to use "/dev/urandom",

which not be in the jail?  That's a wild guess.  You'd need to

trace system calls to see what it is actually doing...



--

                Viktor.



_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

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

From nic.tuv at gmail.com  Mon Oct  8 07:35:33 2018
From: nic.tuv at gmail.com (Nicola)
Date: Mon, 8 Oct 2018 10:35:33 +0300
Subject: [openssl-users] Incompatible Object error from EC_POINT_mul
In-Reply-To: <010701d45e7d$dbb7dd50$932797f0$@secid.co.uk>
References: <010701d45e7d$dbb7dd50$932797f0$@secid.co.uk>
Message-ID: <CANm5x_NZ7Xwtgy8sfWYWPjcEvYktFY6apBKXp=_222F7K7Qv9g@mail.gmail.com>

Hi,

I did not run this in the debugger, but one issue is that you are not
initializing `pub` before calling EC_POINT_mul : try adding

pub = EC_POINT_new(curve);
(and check for errors making sure pub is not null afterwards).

Hope this helps!


Best regards,

Nicola


On Mon, Oct 8, 2018, 00:31 John Hughes <john.hughes at secid.co.uk> wrote:

> I'm trying to generate a public key from a private key generated on a HSM
> (and obtained by calling PKCS#11). Everything works fine until I call
> EC_POINT_mul - at which point I get the error message:
>
>        error:100BB065:elliptic curve routines:ec_wNAF_mul:incompatible
> objects
>
> I have checked the BIGNUM conversion - and that seems to be fine. The key
> pair on the HSM is also generated using brainpoolP256r1.
>
> The basis of the code can be found at the end of the email. I'm basically
> trying to follow the example provided in:
>         https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography.
>
> I'm using openssl 1.10h
>
> Any pointers or help would be appreciated.
>
>
> John
>
> ---------------------------------------------------------------
>
>
>         BN_CTX *ctx;
>         ctx = BN_CTX_new();
>         if(!ctx) {
>                 outputInfo("unable to create openssl BN_CTX");
>                 return;
>         }
>
>         EC_GROUP *curve;
>
>         outputInfo("about to create EC_GROUP_new_by_curve_name");
>         if(NULL == (curve =
> EC_GROUP_new_by_curve_name(NID_brainpoolP256r1))) {
>                 outputERRORmess("unable to setup curve");
>         }
>
>         outputInfo("about to create EC_KEY_new_by_curve_name");
>         EC_KEY *key;
>         if(NULL == (key = EC_KEY_new_by_curve_name(NID_brainpoolP256r1))) {
>                 outputERRORmess("unable to setup EC_KEY");
>         }
>
>         // now get the private key contained in CKA_VALUE via PKCS#111 and
> place in *attrPrivate.pValue
>
>                 .......... (handle error)
>
>         EC_POINT *pub;
>
>
>         BIGNUM *prv = BN_bin2bn((unsigned char*)attrPrivate.pValue,
> attrPrivate.ulValueLen, NULL);
>         if (prv == NULL) {
>
>         ...... (handle error)
>         }
>
>         if (1 != EC_KEY_set_private_key(key, prv)) {
>
>                 ........ (handle error)
>         }
>
>         if (1 != EC_POINT_mul(curve, pub, prv, NULL, NULL, ctx)) {
>                 outputInfo("unable to calculate the public key from the
> HSM's private key using EC_POINT_mul");
>                 (handle error)
>
>         }
>
>
>
>
>
>
>
> --
> 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/20181008/bcd98715/attachment-0001.html>

From blaufish.public.email at gmail.com  Mon Oct  8 08:57:19 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Mon, 8 Oct 2018 10:57:19 +0200
Subject: [openssl-users] Path Length Constraint ignored for Root and any
	self-issued certificate
Message-ID: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>

One more logic confusion in the OpenSSL Path Length Constraint check.
Any Path Length Constraint set by Root (or any other Self-Issued
Certificate) is ignored.
Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
applied to the checker (i.e. the checker and the calculation logic
have been mixed up).

https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2

openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
                Certificate Sign, CRL Sign
            X509v3 Basic Constraints: critical
                CA:TRUE, pathlen:0
openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:FALSE
----
openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
--
--
                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
            X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
        X509v3 extensions:
            X509v3 Subject Key Identifier:
                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
--
--
                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
            X509v3 Authority Key Identifier:

keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
                TLS Web Server Authentication
            X509v3 Subject Key Identifier:
                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
--
--
                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
            X509v3 Authority Key Identifier:

keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
----
../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
root.pem -untrusted evilca.pem evilserver.pem
******* important variables *******
*** check_chain_extensions:524 i=0
*** check_chain_extensions:525 plen=0
*** check_chain_extensions:526 x->ex_pathlen=-1
******* if statement components *******
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=0
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:524 i=1
*** check_chain_extensions:525 plen=1
*** check_chain_extensions:526 x->ex_pathlen=0
******* if statement components *******
*** check_chain_extensions:528 i > 1=0
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=0
******* important variables *******
*** check_chain_extensions:524 i=2
*** check_chain_extensions:525 plen=2
*** check_chain_extensions:526 x->ex_pathlen=0
******* if statement components *******
*** check_chain_extensions:528 i > 1=1
*** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
*** check_chain_extensions:530 (x->ex_pathlen != -1)=1
*** check_chain_extensions:531 (plen > (x->ex_pathlen +
proxy_path_length + 1))=1
evilserver.pem: OK
Chain:
depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
EvilServer, CN = EvilServer (untrusted)
depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
= EvilCA (untrusted)
depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root

From d3ck0r at gmail.com  Mon Oct  8 11:27:10 2018
From: d3ck0r at gmail.com (J Decker)
Date: Mon, 8 Oct 2018 04:27:10 -0700
Subject: [openssl-users] Path Length Constraint ignored for Root and any
 self-issued certificate
In-Reply-To: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>
References: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>
Message-ID: <CAA2GJqVJahnQFg6QyptVLVWpBTixjecPE9PPwMwQywuoyr+emw@mail.gmail.com>

It was my interpretation that 0 pathlen on the root self signed meant
infinite.
The pathlen only applies on the certs between root and the leaf (which
obviously can be 0, and CA true or not, but bad form to say true I'd
imagine.)

On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <
blaufish.public.email at gmail.com> wrote:

> One more logic confusion in the OpenSSL Path Length Constraint check.
> Any Path Length Constraint set by Root (or any other Self-Issued
> Certificate) is ignored.
> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> applied to the checker (i.e. the checker and the calculation logic
> have been mixed up).
>
> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>
> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
>                 Certificate Sign, CRL Sign
>             X509v3 Basic Constraints: critical
>                 CA:TRUE, pathlen:0
> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
>                 Certificate Sign, CRL Sign
>             X509v3 Basic Constraints: critical
>                 CA:TRUE, pathlen:0
> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>         X509v3 extensions:
>             X509v3 Basic Constraints: critical
>                 CA:FALSE
> ----
> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>         X509v3 extensions:
>             X509v3 Subject Key Identifier:
>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> --
> --
>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>             X509v3 Authority Key Identifier:
>
> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>         X509v3 extensions:
>             X509v3 Subject Key Identifier:
>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> --
> --
>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>             X509v3 Authority Key Identifier:
>
> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key
> Identifier"
>                 TLS Web Server Authentication
>             X509v3 Subject Key Identifier:
>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> --
> --
>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>             X509v3 Authority Key Identifier:
>
> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> ----
> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
> root.pem -untrusted evilca.pem evilserver.pem
> ******* important variables *******
> *** check_chain_extensions:524 i=0
> *** check_chain_extensions:525 plen=0
> *** check_chain_extensions:526 x->ex_pathlen=-1
> ******* if statement components *******
> *** check_chain_extensions:528 i > 1=0
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=0
> ******* important variables *******
> *** check_chain_extensions:524 i=1
> *** check_chain_extensions:525 plen=1
> *** check_chain_extensions:526 x->ex_pathlen=0
> ******* if statement components *******
> *** check_chain_extensions:528 i > 1=0
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=0
> ******* important variables *******
> *** check_chain_extensions:524 i=2
> *** check_chain_extensions:525 plen=2
> *** check_chain_extensions:526 x->ex_pathlen=0
> ******* if statement components *******
> *** check_chain_extensions:528 i > 1=1
> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> proxy_path_length + 1))=1
> evilserver.pem: OK
> Chain:
> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
> EvilServer, CN = EvilServer (untrusted)
> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
> = EvilCA (untrusted)
> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
> --
> 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/20181008/13bdc938/attachment.html>

From blaufish.public.email at gmail.com  Mon Oct  8 12:47:53 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Mon, 8 Oct 2018 14:47:53 +0200
Subject: [openssl-users] Path Length Constraint ignored for Root and any
 self-issued certificate
In-Reply-To: <CAA2GJqVJahnQFg6QyptVLVWpBTixjecPE9PPwMwQywuoyr+emw@mail.gmail.com>
References: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>
 <CAA2GJqVJahnQFg6QyptVLVWpBTixjecPE9PPwMwQywuoyr+emw@mail.gmail.com>
Message-ID: <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>

That is not correct behaviour as far as I can understand.

RFC5280 Certification Path Validation algorithm process from root to
leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
Preparation for Certificate i+1 is expected to occur upon Root
certificate, i.e. the following should be expected behaviour:
* max_path_length=n (initialisation)
* max_path_length=n-1 (first decrement)
* max_path_length=0 (copied from root certificate constraint)
* VERIFY(max_path_length>0) error upon preparing transition from i=1
(Root) to i=2 (EvilCA).

OpenSSL does everything in a slightly different reverse algorithm, but
should perform the same controls and behaivor as the RFC imho.

And aside from the RFC algorithm checking for this condition, it is
also analog with the description of the expected behaviour:

   The pathLenConstraint field is meaningful only if the cA boolean is
   asserted and the key usage extension, if present, asserts the
   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
   maximum number of non-self-issued intermediate certificates that may
   follow this certificate in a valid certification path.  (Note: The
   last certificate in the certification path is not an intermediate
   certificate, and is not included in this limit.  Usually, the last
   certificate is an end entity certificate, but it can be a CA
   certificate.)  A pathLenConstraint of zero indicates that no non-
   self-issued intermediate CA certificates may follow in a valid
   certification path.  Where it appears, the pathLenConstraint field
   MUST be greater than or equal to zero.  Where pathLenConstraint does
   not appear, no limit is imposed.

So my understanding is that the OpenSSL algorithm is confused and
fails to perform a check that is applicable to self-issued
certificates. The decrement of max_path_length (aka plen++ in OpenSSL
implementation) should not occur for self issued certificates, but the
validation of max_path_length>0 (aka plen>(constraint+1)) should
occur.
On Mon, Oct 8, 2018 at 1:27 PM J Decker <d3ck0r at gmail.com> wrote:
>
> It was my interpretation that 0 pathlen on the root self signed meant infinite.
> The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
>
> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <blaufish.public.email at gmail.com> wrote:
>>
>> One more logic confusion in the OpenSSL Path Length Constraint check.
>> Any Path Length Constraint set by Root (or any other Self-Issued
>> Certificate) is ignored.
>> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
>> applied to the checker (i.e. the checker and the calculation logic
>> have been mixed up).
>>
>> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>>
>> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
>>                 Certificate Sign, CRL Sign
>>             X509v3 Basic Constraints: critical
>>                 CA:TRUE, pathlen:0
>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
>>                 Certificate Sign, CRL Sign
>>             X509v3 Basic Constraints: critical
>>                 CA:TRUE, pathlen:0
>> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>>         X509v3 extensions:
>>             X509v3 Basic Constraints: critical
>>                 CA:FALSE
>> ----
>> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>>         X509v3 extensions:
>>             X509v3 Subject Key Identifier:
>>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> --
>> --
>>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>             X509v3 Authority Key Identifier:
>>
>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>>         X509v3 extensions:
>>             X509v3 Subject Key Identifier:
>>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> --
>> --
>>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>             X509v3 Authority Key Identifier:
>>
>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
>>                 TLS Web Server Authentication
>>             X509v3 Subject Key Identifier:
>>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>> --
>> --
>>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>             X509v3 Authority Key Identifier:
>>
>> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>> ----
>> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
>> root.pem -untrusted evilca.pem evilserver.pem
>> ******* important variables *******
>> *** check_chain_extensions:524 i=0
>> *** check_chain_extensions:525 plen=0
>> *** check_chain_extensions:526 x->ex_pathlen=-1
>> ******* if statement components *******
>> *** check_chain_extensions:528 i > 1=0
>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>> proxy_path_length + 1))=0
>> ******* important variables *******
>> *** check_chain_extensions:524 i=1
>> *** check_chain_extensions:525 plen=1
>> *** check_chain_extensions:526 x->ex_pathlen=0
>> ******* if statement components *******
>> *** check_chain_extensions:528 i > 1=0
>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>> proxy_path_length + 1))=0
>> ******* important variables *******
>> *** check_chain_extensions:524 i=2
>> *** check_chain_extensions:525 plen=2
>> *** check_chain_extensions:526 x->ex_pathlen=0
>> ******* if statement components *******
>> *** check_chain_extensions:528 i > 1=1
>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>> proxy_path_length + 1))=1
>> evilserver.pem: OK
>> Chain:
>> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
>> EvilServer, CN = EvilServer (untrusted)
>> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
>> = EvilCA (untrusted)
>> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
>> --
>> 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 blaufish.public.email at gmail.com  Mon Oct  8 12:51:06 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Mon, 8 Oct 2018 14:51:06 +0200
Subject: [openssl-users] Path Length Constraint ignored for Root and any
 self-issued certificate
In-Reply-To: <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>
References: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>
 <CAA2GJqVJahnQFg6QyptVLVWpBTixjecPE9PPwMwQywuoyr+emw@mail.gmail.com>
 <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>
Message-ID: <CANtcRX4640ovAAnWp-ZUjgCFgjnVZxL5toAmD2HGiBMgrux+4A@mail.gmail.com>

sorry, typo on the verify line, this was what I should have written:
VERIFY(max_path_length>0) error upon preparing transition from i=2
(EvilCA) to i=2 (EvilServer).
On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
<blaufish.public.email at gmail.com> wrote:
>
> That is not correct behaviour as far as I can understand.
>
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).
>
> OpenSSL does everything in a slightly different reverse algorithm, but
> should perform the same controls and behaivor as the RFC imho.
>
> And aside from the RFC algorithm checking for this condition, it is
> also analog with the description of the expected behaviour:
>
>    The pathLenConstraint field is meaningful only if the cA boolean is
>    asserted and the key usage extension, if present, asserts the
>    keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
>    maximum number of non-self-issued intermediate certificates that may
>    follow this certificate in a valid certification path.  (Note: The
>    last certificate in the certification path is not an intermediate
>    certificate, and is not included in this limit.  Usually, the last
>    certificate is an end entity certificate, but it can be a CA
>    certificate.)  A pathLenConstraint of zero indicates that no non-
>    self-issued intermediate CA certificates may follow in a valid
>    certification path.  Where it appears, the pathLenConstraint field
>    MUST be greater than or equal to zero.  Where pathLenConstraint does
>    not appear, no limit is imposed.
>
> So my understanding is that the OpenSSL algorithm is confused and
> fails to perform a check that is applicable to self-issued
> certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> implementation) should not occur for self issued certificates, but the
> validation of max_path_length>0 (aka plen>(constraint+1)) should
> occur.
> On Mon, Oct 8, 2018 at 1:27 PM J Decker <d3ck0r at gmail.com> wrote:
> >
> > It was my interpretation that 0 pathlen on the root self signed meant infinite.
> > The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
> >
> > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <blaufish.public.email at gmail.com> wrote:
> >>
> >> One more logic confusion in the OpenSSL Path Length Constraint check.
> >> Any Path Length Constraint set by Root (or any other Self-Issued
> >> Certificate) is ignored.
> >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> >> applied to the checker (i.e. the checker and the calculation logic
> >> have been mixed up).
> >>
> >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
> >>
> >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
> >>                 Certificate Sign, CRL Sign
> >>             X509v3 Basic Constraints: critical
> >>                 CA:TRUE, pathlen:0
> >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
> >>                 Certificate Sign, CRL Sign
> >>             X509v3 Basic Constraints: critical
> >>                 CA:TRUE, pathlen:0
> >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> >>         X509v3 extensions:
> >>             X509v3 Basic Constraints: critical
> >>                 CA:FALSE
> >> ----
> >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> >>         X509v3 extensions:
> >>             X509v3 Subject Key Identifier:
> >>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> --
> >> --
> >>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >>             X509v3 Authority Key Identifier:
> >>
> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
> >>         X509v3 extensions:
> >>             X509v3 Subject Key Identifier:
> >>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> >> --
> >> --
> >>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> >>             X509v3 Authority Key Identifier:
> >>
> >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> >> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
> >>                 TLS Web Server Authentication
> >>             X509v3 Subject Key Identifier:
> >>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> >> --
> >> --
> >>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> >>             X509v3 Authority Key Identifier:
> >>
> >> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> >> ----
> >> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
> >> root.pem -untrusted evilca.pem evilserver.pem
> >> ******* important variables *******
> >> *** check_chain_extensions:524 i=0
> >> *** check_chain_extensions:525 plen=0
> >> *** check_chain_extensions:526 x->ex_pathlen=-1
> >> ******* if statement components *******
> >> *** check_chain_extensions:528 i > 1=0
> >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
> >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> >> proxy_path_length + 1))=0
> >> ******* important variables *******
> >> *** check_chain_extensions:524 i=1
> >> *** check_chain_extensions:525 plen=1
> >> *** check_chain_extensions:526 x->ex_pathlen=0
> >> ******* if statement components *******
> >> *** check_chain_extensions:528 i > 1=0
> >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> >> proxy_path_length + 1))=0
> >> ******* important variables *******
> >> *** check_chain_extensions:524 i=2
> >> *** check_chain_extensions:525 plen=2
> >> *** check_chain_extensions:526 x->ex_pathlen=0
> >> ******* if statement components *******
> >> *** check_chain_extensions:528 i > 1=1
> >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
> >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> >> proxy_path_length + 1))=1
> >> evilserver.pem: OK
> >> Chain:
> >> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
> >> EvilServer, CN = EvilServer (untrusted)
> >> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
> >> = EvilCA (untrusted)
> >> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
> >> --
> >> 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 tshort at akamai.com  Mon Oct  8 13:55:50 2018
From: tshort at akamai.com (Short, Todd)
Date: Mon, 8 Oct 2018 13:55:50 +0000
Subject: [openssl-users] How to build libcrypto64*.lib and libssl64*.lib
 on Windows 64-bit?
In-Reply-To: <20181002.175912.1353134730697848028.levitte@openssl.org>
References: <BYAPR17MB2150827BB4432C4B7EDAF69DDFEF0@BYAPR17MB2150.namprd17.prod.outlook.com>
 <20181002.175912.1353134730697848028.levitte@openssl.org>
Message-ID: <E8C0F8F6-97AD-4A1D-B07E-07146581DBDF@akamai.com>

Could that be LibreSSL? (Or some similar wrapper for OpenSSL?)

https://github.com/Ruzzz/LibreSSL

This above repo creates libraries in the named format below; to match how Microsoft provides multiple versions of libraries.

Looks to be debug (d) and multi-thread (MT?) versions of the libraries; not sure what MD stands for.

Also:
https://gitlab.kitware.com/cmake/cmake/commit/ed1758f8eb58a4e52acf0f3885f82403814f5ffd


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

On Oct 2, 2018, at 11:59 AM, Richard Levitte <levitte at openssl.org<mailto:levitte at openssl.org>> wrote:

Our scripts have *never*, as far as I know, produced libraries named
like that.  Don't those DLLs come from some specific packager that
produces binary install kits?

For 1.1.x, *our* naming is a bit more elaborate, you will see these
names:

   libcrypto-1_1.dll & libssl-1_1.dll           - VC-WIN32 build
   libcrypto-1_1-x64.dll & libssl-1_1-x64.dll   - VC-WIN64A build
   libcrypto-1_1-ia64.dll & libssl-1_1-ia64.dll - VC-WIN64I build

You will also see the corresponding import libraries: libcrypto.lib &
libssl.lib

Cheers,
Richard

In message <BYAPR17MB2150827BB4432C4B7EDAF69DDFEF0 at BYAPR17MB2150.namprd17.prod.outlook.com<mailto:BYAPR17MB2150827BB4432C4B7EDAF69DDFEF0 at BYAPR17MB2150.namprd17.prod.outlook.com>> on Mon, 1 Oct 2018 16:29:15 +0000, <aaron.friesen at non.keysight.com<mailto:aaron.friesen at non.keysight.com>> said:

A current project using Net-SNMP and OpenSSL require that these both are built locally (customer
requirement).

I am attempting to build OpenSSL 1.1.1.

After building OpenSSL, ?nmake test? succeeds.

However, the Net-SNMP build is looking for various .lib files that are in the pre-built package, but
do not seem to be in what I build locally.

From the pre-built package, in the lib/VC folder:

libcrypto64MD.lib

libcrypto64MDd.lib

libcrypto64MT.lib

libcrypto64MTd.lib

libssl64MD.lib

libssl64MDd.lib

libssl64MT.lib

libssl64MTd.lib

But the VC folder is not part of my locally built version.

What am I missing in order to get these .lib files to build locally?

Thank you for your assistance.

Best Regards,
Aaron Friesen

Contract Software Engineer of Aerotek on behalf of Keysight

Keysight Technologies, Inc.

970.679.5632 T

--
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/20181008/f9074998/attachment.html>

From blaufish.public.email at gmail.com  Mon Oct  8 14:47:46 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Mon, 8 Oct 2018 16:47:46 +0200
Subject: [openssl-users] Path Length Constraint ignored for Root and any
 self-issued certificate
In-Reply-To: <CANtcRX4640ovAAnWp-ZUjgCFgjnVZxL5toAmD2HGiBMgrux+4A@mail.gmail.com>
References: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>
 <CAA2GJqVJahnQFg6QyptVLVWpBTixjecPE9PPwMwQywuoyr+emw@mail.gmail.com>
 <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>
 <CANtcRX4640ovAAnWp-ZUjgCFgjnVZxL5toAmD2HGiBMgrux+4A@mail.gmail.com>
Message-ID: <CANtcRX52-hjDQbOriif18H5iW144PaqCVuzzjdNbnGLaEqyGAQ@mail.gmail.com>

Tested mbedtls to see how other code bases handle thus.

mbedtls rejects the EvilCA certificate when connecting to openssl
s_server (as opposed to openssl c_client -verify that accepts the
connection).

Verify requested for (Depth 1):
cert. version     : 3
serial number     : 10:00
issuer name       : C=SE, ST=Root, L=Root, O=Root, OU=Root, CN=Root
subject name      : C=SE, ST=EvilCA, L=EvilCA, O=EvilCA, OU=EvilCA, CN=EvilCA
issued  on        : 2018-10-08 08:20:21
expires on        : 2028-10-05 08:20:21
signed using      : RSA with SHA-256
RSA key size      : 4096 bits
basic constraints : CA=true, max_pathlen=0
key usage         : Key Cert Sign, CRL Sign
  ! The certificate is not correctly signed by the trusted CA

The handshake fails after this error, mbedtls_ssl_handshake returned -9984.
On Mon, Oct 8, 2018 at 2:51 PM Peter Magnusson
<blaufish.public.email at gmail.com> wrote:
>
> sorry, typo on the verify line, this was what I should have written:
> VERIFY(max_path_length>0) error upon preparing transition from i=2
> (EvilCA) to i=2 (EvilServer).
> On Mon, Oct 8, 2018 at 2:47 PM Peter Magnusson
> <blaufish.public.email at gmail.com> wrote:
> >
> > That is not correct behaviour as far as I can understand.
> >
> > RFC5280 Certification Path Validation algorithm process from root to
> > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> > Preparation for Certificate i+1 is expected to occur upon Root
> > certificate, i.e. the following should be expected behaviour:
> > * max_path_length=n (initialisation)
> > * max_path_length=n-1 (first decrement)
> > * max_path_length=0 (copied from root certificate constraint)
> > * VERIFY(max_path_length>0) error upon preparing transition from i=1
> > (Root) to i=2 (EvilCA).
> >
> > OpenSSL does everything in a slightly different reverse algorithm, but
> > should perform the same controls and behaivor as the RFC imho.
> >
> > And aside from the RFC algorithm checking for this condition, it is
> > also analog with the description of the expected behaviour:
> >
> >    The pathLenConstraint field is meaningful only if the cA boolean is
> >    asserted and the key usage extension, if present, asserts the
> >    keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
> >    maximum number of non-self-issued intermediate certificates that may
> >    follow this certificate in a valid certification path.  (Note: The
> >    last certificate in the certification path is not an intermediate
> >    certificate, and is not included in this limit.  Usually, the last
> >    certificate is an end entity certificate, but it can be a CA
> >    certificate.)  A pathLenConstraint of zero indicates that no non-
> >    self-issued intermediate CA certificates may follow in a valid
> >    certification path.  Where it appears, the pathLenConstraint field
> >    MUST be greater than or equal to zero.  Where pathLenConstraint does
> >    not appear, no limit is imposed.
> >
> > So my understanding is that the OpenSSL algorithm is confused and
> > fails to perform a check that is applicable to self-issued
> > certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> > implementation) should not occur for self issued certificates, but the
> > validation of max_path_length>0 (aka plen>(constraint+1)) should
> > occur.
> > On Mon, Oct 8, 2018 at 1:27 PM J Decker <d3ck0r at gmail.com> wrote:
> > >
> > > It was my interpretation that 0 pathlen on the root self signed meant infinite.
> > > The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
> > >
> > > On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <blaufish.public.email at gmail.com> wrote:
> > >>
> > >> One more logic confusion in the OpenSSL Path Length Constraint check.
> > >> Any Path Length Constraint set by Root (or any other Self-Issued
> > >> Certificate) is ignored.
> > >> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
> > >> applied to the checker (i.e. the checker and the calculation logic
> > >> have been mixed up).
> > >>
> > >> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
> > >>
> > >> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
> > >>                 Certificate Sign, CRL Sign
> > >>             X509v3 Basic Constraints: critical
> > >>                 CA:TRUE, pathlen:0
> > >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
> > >>                 Certificate Sign, CRL Sign
> > >>             X509v3 Basic Constraints: critical
> > >>                 CA:TRUE, pathlen:0
> > >> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
> > >>         X509v3 extensions:
> > >>             X509v3 Basic Constraints: critical
> > >>                 CA:FALSE
> > >> ----
> > >> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
> > >>         X509v3 extensions:
> > >>             X509v3 Subject Key Identifier:
> > >>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >> --
> > >> --
> > >>                 49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >>             X509v3 Authority Key Identifier:
> > >>
> > >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
> > >>         X509v3 extensions:
> > >>             X509v3 Subject Key Identifier:
> > >>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> > >> --
> > >> --
> > >>                 B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> > >>             X509v3 Authority Key Identifier:
> > >>
> > >> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
> > >> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
> > >>                 TLS Web Server Authentication
> > >>             X509v3 Subject Key Identifier:
> > >>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> > >> --
> > >> --
> > >>                 03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
> > >>             X509v3 Authority Key Identifier:
> > >>
> > >> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
> > >> ----
> > >> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
> > >> root.pem -untrusted evilca.pem evilserver.pem
> > >> ******* important variables *******
> > >> *** check_chain_extensions:524 i=0
> > >> *** check_chain_extensions:525 plen=0
> > >> *** check_chain_extensions:526 x->ex_pathlen=-1
> > >> ******* if statement components *******
> > >> *** check_chain_extensions:528 i > 1=0
> > >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> > >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
> > >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> > >> proxy_path_length + 1))=0
> > >> ******* important variables *******
> > >> *** check_chain_extensions:524 i=1
> > >> *** check_chain_extensions:525 plen=1
> > >> *** check_chain_extensions:526 x->ex_pathlen=0
> > >> ******* if statement components *******
> > >> *** check_chain_extensions:528 i > 1=0
> > >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
> > >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> > >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> > >> proxy_path_length + 1))=0
> > >> ******* important variables *******
> > >> *** check_chain_extensions:524 i=2
> > >> *** check_chain_extensions:525 plen=2
> > >> *** check_chain_extensions:526 x->ex_pathlen=0
> > >> ******* if statement components *******
> > >> *** check_chain_extensions:528 i > 1=1
> > >> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
> > >> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
> > >> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
> > >> proxy_path_length + 1))=1
> > >> evilserver.pem: OK
> > >> Chain:
> > >> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
> > >> EvilServer, CN = EvilServer (untrusted)
> > >> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
> > >> = EvilCA (untrusted)
> > >> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
> > >> --
> > >> 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 Andrew_Porter at bmc.com  Mon Oct  8 14:17:32 2018
From: Andrew_Porter at bmc.com (Porter, Andrew)
Date: Mon, 8 Oct 2018 14:17:32 +0000
Subject: [openssl-users] osf-contact Latest Openssl Issue with
	Bind	9.12.2-P2 on RHEL 7.5
In-Reply-To: <14773_1538977844_5BBAF034_14773_368_1_D9E1007BEB274445807B4DF1046EDA271107638A@OPEXCSINM91.corporate.adroot.infra.ftgroup>
References: <16481_1538732473_5BB731B9_16481_434_1_1817b836-b685-4a91-8f34-48220e57495b@OPEXCSINM92.corporate.adroot.infra.ftgroup>
 <F88A928D-15C2-4FAB-B622-EF6D53EC5087@dukhovni.org>
 <14773_1538977844_5BBAF034_14773_368_1_D9E1007BEB274445807B4DF1046EDA271107638A@OPEXCSINM91.corporate.adroot.infra.ftgroup>
Message-ID: <89a51b4e433049f382add74aab7eac8e@phx-exmbprd-02.adprod.bmc.com>

See the error message about looking at the FAQ? Here it is:

https://www.openssl.org/docs/faq.html#USER1

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of aakash.kumar at orange.com
Sent: Sunday, October 07, 2018 22:51
To: openssl-users at openssl.org
Cc: osf-contact at openssl.org
Subject: Re: [openssl-users] osf-contact Latest Openssl Issue with Bind 9.12.2-P2 on RHEL 7.5


Hi Team,



Please find below error in text format.



[root at g3r1 ~]# systemctl status bind -l

? bind.service - LSB: DNS Daemon

   Loaded: loaded (/etc/rc.d/init.d/bind)

   Active: active (exited) since Fri 2018-10-05 13:31:09 CEST; 2 days ago

     Docs: man:systemd-sysv-generator(8)

  Process: 32417 ExecStop=/etc/rc.d/init.d/bind stop (code=exited, status=0/SUCCESS)

  Process: 32421 ExecStart=/etc/rc.d/init.d/bind start (code=exited, status=0/SUCCESS)



Oct 05 13:31:09 g3r1 named[32429]: ----------------------------------------------------

Oct 05 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to 1048576

Oct 05 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct 05 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct 05 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct 05 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct 05 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)

Oct 05 13:31:09 g3r1 named[32429]: exiting (due to fatal error in library)

Oct 05 13:31:09 g3r1 bind[32421]: [13B blob data]

Oct 05 13:31:09 g3r1 systemd[1]: Started LSB: DNS Daemon.





[root at g3r1 ~]# tail /var/log/message

Oct  5 13:31:09 g3r1 systemd: Starting LSB: DNS Daemon...

Oct  5 13:31:09 g3r1 bind: /etc/rc.d/init.d/bind: line 36: log_info_msg: command not found

Oct  5 13:31:09 g3r1 named[32429]: starting BIND 9.12.2-P2 <id:b2bf278>

Oct  5 13:31:09 g3r1 named[32429]: running on Linux x86_64 3.10.0-327.13.1.el7.x86_64 #1 SMP Mon Feb 29 13:22:02 EST 2016

Oct  5 13:31:09 g3r1 named[32429]: built with '--prefix=/usr' '--sysconfdir=/etc' '--localstatedir=/var' 'mandir=/usr/share/man' '--enable-threads' '--with-libtool' '--with-openssl=/usr/local/ssl' '--disable-static' '--with-randomdev=/dev/urandom'

Oct  5 13:31:09 g3r1 named[32429]: running as: named -u named -t /srv/named -c /etc/named.conf

Oct  5 13:31:09 g3r1 named[32429]: compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-28)

Oct  5 13:31:09 g3r1 named[32429]: compiled with OpenSSL version: OpenSSL 1.0.2p  14 Aug 2018

Oct  5 13:31:09 g3r1 named[32429]: linked to OpenSSL version: OpenSSL 1.0.2p  14 Aug 2018

Oct  5 13:31:09 g3r1 named[32429]: compiled with zlib version: 1.2.7

Oct  5 13:31:09 g3r1 named[32429]: linked to zlib version: 1.2.7

Oct  5 13:31:09 g3r1 named[32429]: threads support is enabled

Oct  5 13:31:09 g3r1 named[32429]: ----------------------------------------------------

Oct  5 13:31:09 g3r1 named[32429]: BIND 9 is maintained by Internet Systems Consortium,

Oct  5 13:31:09 g3r1 named[32429]: Inc. (ISC), a non-profit 501(c)(3) public-benefit

Oct  5 13:31:09 g3r1 named[32429]: corporation.  Support and training for BIND 9 are

Oct  5 13:31:09 g3r1 named[32429]: available at https://www.isc.org/support

Oct  5 13:31:09 g3r1 named[32429]: ----------------------------------------------------

Oct  5 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to 1048576

Oct  5 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct  5 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct  5 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct  5 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct  5 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)





Thanks & Regards,



Aakash kumar

ITE - India

Tower B, 8th Floor, DLF Infinity Towers,

DLF Cyber City Phase - II

Gurgaon - 122002, Haryana, INDIA

Aakash.kumar at orange.com



  Mobile: +91-8527288977

  CVS: 7357 3706







-----Original Message-----
From: Viktor Dukhovni [mailto:openssl-users at dukhovni.org]
Sent: 05 October 2018 21:23
To: KUMAR Aakash IMT/OINIS
Cc: osf-contact at openssl.org; SRIVASTAVA Himanshu IMT/OINIS; VARSHNEY Praveen IMT/OINIS
Subject: Re: osf-contact Latest Openssl Issue with Bind 9.12.2-P2 on RHEL 7.5





Please try to send the text of error reports, not pictures.



> I am getting below error while starting the bind service.

>

> <image002.png>



If you ask on the openssl-users list, someone else may have seen

the same issue, and may have useful advice to share.



NOTE!!!:  I've set the Reply-To: address to <openssl-users at openssl.org>.

If you just hit "Reply", your answer may go to the list, though you'd

need to join the list first to be able to post...



Does the error still happen when you disable "chroot" in BIND?

Perhaps BIND is doing late initialization of the PRNG after

entering the chroot jail, and maybe trying to use "/dev/urandom",

which not be in the jail?  That's a wild guess.  You'd need to

trace system calls to see what it is actually doing...



--

                Viktor.



_________________________________________________________________________________________________________________________



Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181008/5bd35879/attachment.html>

From Michael.Wojcik at microfocus.com  Mon Oct  8 14:54:47 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 8 Oct 2018 14:54:47 +0000
Subject: [openssl-users] How to build libcrypto64*.lib and libssl64*.lib
 on Windows 64-bit?
In-Reply-To: <E8C0F8F6-97AD-4A1D-B07E-07146581DBDF@akamai.com>
References: <BYAPR17MB2150827BB4432C4B7EDAF69DDFEF0@BYAPR17MB2150.namprd17.prod.outlook.com>
 <20181002.175912.1353134730697848028.levitte@openssl.org>
 <E8C0F8F6-97AD-4A1D-B07E-07146581DBDF@akamai.com>
Message-ID: <MWHPR18MB1037BB02E7B039C018C50C0AF9E60@MWHPR18MB1037.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Short, Todd via openssl-users
> Sent: Monday, October 08, 2018 09:56

> Looks to be debug (d) and multi-thread (MT?) versions of the libraries; not sure what MD stands for.

It's Microsoft's naming convention for their C runtime. MT is multithreaded, statically linked; MD is multithreaded, dynamically linked. The "d" suffix is, as Todd guessed, the debug version.

This is important with Microsoft Visual C, because the various runtimes do not play together. Their heaps, iobs, etc are separate. So, for example, if you link your program with the MT runtime and with a library that was linked with the MD runtime, and your code tries to free memory allocated by the library, you'll get a heap exception (if you're lucky) or heap corruption.

You can get away with mixed runtimes if you're careful - if every module frees the storage it allocates, and you don't try to create a FILE* in one and use it in another, and so on. Nonetheless, it's a gaping architectural flaw, and some packages try to accommodate it by providing equivalent versions of their libraries.

Todd may well be correct that OP is looking at a LibreSSL package, not an OpenSSL one. (LibreSSL isn't "a wrapper for OpenSSL", but whatever.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From sglazier456 at gmail.com  Mon Oct  8 15:43:02 2018
From: sglazier456 at gmail.com (Sean Glazier)
Date: Mon, 8 Oct 2018 11:43:02 -0400
Subject: [openssl-users] Issue with using TLS
Message-ID: <CAG6o=P4iUHVk1=NuUCkrU6qNLSgTo1WBFyvD2Cx2OvgEEn9_yg@mail.gmail.com>

Hi,

I have an issue with using a TLS client-server set up.

on the client side I am using 32 open ssl library version 1.1 and the same
set on the server side in VA smalltalk. Both are on windows.

On the c side I set the SSL_CTX_new(TLS_client_method()) on the server I
restricted to TLS only as per our security policy.

I get through the hand shake and the client sends data over to the sever.
however upon reading the server gives and openSSL error as follows:
OpenSSLError
Error Code: 336130315
Error Object: ('wrong version number')
Error String: 'error:1408F10B:SSL routines:ssl3_get_record:wrong version
number'
Error Hint: 'ssl3_get_record:wrong version number'
AuxiliaryData: nil.

I have attempted to work around this by setting on the server side the
following option:  SSL_OP_TLS_ROLLBACK_BUG . I saw from forums that this
will tell the server to ignore this bug. However, I still get the same bug.

Does anyone know the workaround for this issue?

Kind Regards,

Sean Glazier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181008/1a84cb2e/attachment.html>

From openssl-users at dukhovni.org  Mon Oct  8 16:15:16 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 8 Oct 2018 12:15:16 -0400
Subject: [openssl-users] Path Length Constraint ignored for Root and any
 self-issued certificate
In-Reply-To: <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>
References: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>
 <CAA2GJqVJahnQFg6QyptVLVWpBTixjecPE9PPwMwQywuoyr+emw@mail.gmail.com>
 <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>
Message-ID: <FBF6D998-8A53-4E03-9C37-4D0DEC1B637D@dukhovni.org>

> On Oct 8, 2018, at 8:47 AM, Peter Magnusson <blaufish.public.email at gmail.com> wrote:
> 
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).

Well, strictly speaking, the trust-anchor is not part of the certificate
chain in RFC5280, it is a public key and an issuer name, not a certificate
in the chain.  However, when the trust-anchor is in the form of a self-signed
CA certificate, one might take the view that this is a self-issued certificate
to be included in the chain:

 trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)

in which case the "path lenth: 0" in the self-issed root CA cert precludes
the root from issuing any subsidiary CAs that can in turn issue further
EE certs.  That is perhaps reasonable, so I updated PR #7353 with
a further commit:

  https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3

Does that address your concerns?

-- 
	Viktor.


From matt at openssl.org  Mon Oct  8 17:08:58 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 8 Oct 2018 18:08:58 +0100
Subject: [openssl-users] Issue with using TLS
In-Reply-To: <CAG6o=P4iUHVk1=NuUCkrU6qNLSgTo1WBFyvD2Cx2OvgEEn9_yg@mail.gmail.com>
References: <CAG6o=P4iUHVk1=NuUCkrU6qNLSgTo1WBFyvD2Cx2OvgEEn9_yg@mail.gmail.com>
Message-ID: <8323ead9-cdb8-088d-827e-b137cb45f9a3@openssl.org>



On 08/10/18 16:43, Sean Glazier wrote:
> Hi,
> 
> I have an issue with using a TLS client-server?set up.
> 
> on the client side I am using 32 open ssl?library version 1.1 and the
> same set on the server side in VA smalltalk. Both are on windows.
> 
> On the c side I set the SSL_CTX_new(TLS_client_method()) on the server I
> restricted to TLS only as per our security policy.
> 
> I get through the hand shake and the client sends data over to the
> sever. however upon reading the server gives and openSSL?error as follows:
> OpenSSLError
> Error Code: 336130315
> Error Object: ('wrong version number')
> Error String: 'error:1408F10B:SSL routines:ssl3_get_record:wrong version
> number'
> Error Hint: 'ssl3_get_record:wrong version number'
> AuxiliaryData: nil. 

This usually occurs if the data that is received doesn't look like TLS,
either because it is corrupted or is some other protocol. The TLS record
version number is the first thing we check, so if you've got bad data
then this is the first error you hit.

> 
> I have attempted to work around this by setting on the server side the
> following option:??SSL_OP_TLS_ROLLBACK_BUG .?I saw from forums that this
> will tell the server to ignore this bug. However, I still get the same bug.

Don't do that. That option is an ancient client bug workaround that
should not be necessary in modern code.


> Does anyone know the workaround for this issue??

Send me a wireshark trace of a failing connection and I can take a look
at it.

Matt


> ?
> Kind Regards,
> ?
> Sean Glazier
> ?
> 
> 

From john.hughes at secid.co.uk  Mon Oct  8 17:21:53 2018
From: john.hughes at secid.co.uk (John Hughes)
Date: Mon, 8 Oct 2018 18:21:53 +0100
Subject: [openssl-users] Incompatible Object error from EC_POINT_mul
	(Nicola)
Message-ID: <014601d45f2b$684aec00$38e0c400$@secid.co.uk>

Nicola,

Brilliant - that sorted it. I have produced a public key this way and
successfully compared it with the public key in the original key pair.

You may want to update the wiki page to add that step into the sample code


Regards

John

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
openssl-users-request at openssl.org
Sent: 08 October 2018 08:36
To: openssl-users at openssl.org
Subject: openssl-users Digest, Vol 47, Issue 8

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: Wiki misleading Enc (Richard Levitte)
   2. Re: osf-contact Latest Openssl Issue with Bind	9.12.2-P2 on
      RHEL 7.5 (aakash.kumar at orange.com)
   3. Re: Incompatible Object error from EC_POINT_mul (Nicola)


----------------------------------------------------------------------

Message: 1
Date: Mon, 08 Oct 2018 07:03:34 +0200 (CEST)
From: Richard Levitte <levitte at openssl.org>
To: paul at zil.li
Cc: openssl-users at openssl.org
Subject: Re: [openssl-users] Wiki misleading Enc
Message-ID: <20181008.070334.1188127225315146424.levitte at openssl.org>
Content-Type: Text/Plain; charset=us-ascii

Fixed.  Thanks.

In message <1df7e534-d4f0-7ac1-4de5-4cb8fb37d9e0 at zil.li> on Sat, 6 Oct 2018
22:48:01 +0200, Paul Zillmann <paul at zil.li> said:

> Hello,
> 
> the wiki page [1] is wrong about the pass parameter.
> According to [2] the parameter for a keyfile is -pass file:path and 
> not -pass pass:path
> 
> - Paul
> 
> 1: https://wiki.openssl.org/index.php/Enc
> 2: https://www.openssl.org/docs/man1.0.2/apps/openssl.html
> 


------------------------------

Message: 2
Date: Mon, 8 Oct 2018 05:50:40 +0000
From: <aakash.kumar at orange.com>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Cc: "osf-contact at openssl.org" <osf-contact at openssl.org>
Subject: Re: [openssl-users] osf-contact Latest Openssl Issue with
	Bind	9.12.2-P2 on RHEL 7.5
Message-ID:
	
<14773_1538977844_5BBAF034_14773_368_1_D9E1007BEB274445807B4DF1046EDA2711076
38A at OPEXCSINM91.corporate.adroot.infra.ftgroup>
	
Content-Type: text/plain; charset="iso-2022-jp"

Hi Team,



Please find below error in text format.



[root at g3r1 ~]# systemctl status bind -l

? bind.service - LSB: DNS Daemon

   Loaded: loaded (/etc/rc.d/init.d/bind)

   Active: active (exited) since Fri 2018-10-05 13:31:09 CEST; 2 days ago

     Docs: man:systemd-sysv-generator(8)

  Process: 32417 ExecStop=/etc/rc.d/init.d/bind stop (code=exited,
status=0/SUCCESS)

  Process: 32421 ExecStart=/etc/rc.d/init.d/bind start (code=exited,
status=0/SUCCESS)



Oct 05 13:31:09 g3r1 named[32429]:
----------------------------------------------------

Oct 05 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to
1048576

Oct 05 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct 05 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct 05 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct 05 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct 05 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator
cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)

Oct 05 13:31:09 g3r1 named[32429]: exiting (due to fatal error in library)

Oct 05 13:31:09 g3r1 bind[32421]: [13B blob data]

Oct 05 13:31:09 g3r1 systemd[1]: Started LSB: DNS Daemon.





[root at g3r1 ~]# tail /var/log/message

Oct  5 13:31:09 g3r1 systemd: Starting LSB: DNS Daemon...

Oct  5 13:31:09 g3r1 bind: /etc/rc.d/init.d/bind: line 36: log_info_msg:
command not found

Oct  5 13:31:09 g3r1 named[32429]: starting BIND 9.12.2-P2 <id:b2bf278>

Oct  5 13:31:09 g3r1 named[32429]: running on Linux x86_64
3.10.0-327.13.1.el7.x86_64 #1 SMP Mon Feb 29 13:22:02 EST 2016

Oct  5 13:31:09 g3r1 named[32429]: built with '--prefix=/usr'
'--sysconfdir=/etc' '--localstatedir=/var' 'mandir=/usr/share/man'
'--enable-threads' '--with-libtool' '--with-openssl=/usr/local/ssl'
'--disable-static' '--with-randomdev=/dev/urandom'

Oct  5 13:31:09 g3r1 named[32429]: running as: named -u named -t /srv/named
-c /etc/named.conf

Oct  5 13:31:09 g3r1 named[32429]: compiled by GCC 4.8.5 20150623 (Red Hat
4.8.5-28)

Oct  5 13:31:09 g3r1 named[32429]: compiled with OpenSSL version: OpenSSL
1.0.2p  14 Aug 2018

Oct  5 13:31:09 g3r1 named[32429]: linked to OpenSSL version: OpenSSL 1.0.2p
14 Aug 2018

Oct  5 13:31:09 g3r1 named[32429]: compiled with zlib version: 1.2.7

Oct  5 13:31:09 g3r1 named[32429]: linked to zlib version: 1.2.7

Oct  5 13:31:09 g3r1 named[32429]: threads support is enabled

Oct  5 13:31:09 g3r1 named[32429]:
----------------------------------------------------

Oct  5 13:31:09 g3r1 named[32429]: BIND 9 is maintained by Internet Systems
Consortium,

Oct  5 13:31:09 g3r1 named[32429]: Inc. (ISC), a non-profit 501(c)(3)
public-benefit

Oct  5 13:31:09 g3r1 named[32429]: corporation.  Support and training for
BIND 9 are

Oct  5 13:31:09 g3r1 named[32429]: available at https://www.isc.org/support

Oct  5 13:31:09 g3r1 named[32429]:
----------------------------------------------------

Oct  5 13:31:09 g3r1 named[32429]: adjusted limit on open files from 4096 to
1048576

Oct  5 13:31:09 g3r1 named[32429]: found 1 CPU, using 1 worker thread

Oct  5 13:31:09 g3r1 named[32429]: using 1 UDP listener per interface

Oct  5 13:31:09 g3r1 named[32429]: using up to 4096 sockets

Oct  5 13:31:09 g3r1 named[32429]: openssl_link.c:296: fatal error:

Oct  5 13:31:09 g3r1 named[32429]: OpenSSL pseudorandom number generator
cannot be initialized (see the `PRNG not seeded' message in the OpenSSL FAQ)





Thanks & Regards,



Aakash kumar

ITE - India

Tower B, 8th Floor, DLF Infinity Towers,

DLF Cyber City Phase - II

Gurgaon - 122002, Haryana, INDIA

Aakash.kumar at orange.com



  Mobile: +91-8527288977

  CVS: 7357 3706







-----Original Message-----
From: Viktor Dukhovni [mailto:openssl-users at dukhovni.org]
Sent: 05 October 2018 21:23
To: KUMAR Aakash IMT/OINIS
Cc: osf-contact at openssl.org; SRIVASTAVA Himanshu IMT/OINIS; VARSHNEY Praveen
IMT/OINIS
Subject: Re: osf-contact Latest Openssl Issue with Bind 9.12.2-P2 on RHEL
7.5





Please try to send the text of error reports, not pictures.



> I am getting below error while starting the bind service.

>

> <image002.png>



If you ask on the openssl-users list, someone else may have seen

the same issue, and may have useful advice to share.



NOTE!!!:  I've set the Reply-To: address to <openssl-users at openssl.org>.

If you just hit "Reply", your answer may go to the list, though you'd

need to join the list first to be able to post...



Does the error still happen when you disable "chroot" in BIND?

Perhaps BIND is doing late initialization of the PRNG after

entering the chroot jail, and maybe trying to use "/dev/urandom",

which not be in the jail?  That's a wild guess.  You'd need to

trace system calls to see what it is actually doing...



--

                Viktor.



____________________________________________________________________________
_____________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc pas etre diffuses,
exploites ou copies sans autorisation. Si vous avez recu ce message par
erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les
pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law; they should not be distributed,
used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been
modified, changed or falsified.
Thank you.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mta.openssl.org/pipermail/openssl-users/attachments/20181008/9a4c315
f/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 8 Oct 2018 10:35:33 +0300
From: Nicola <nic.tuv at gmail.com>
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Incompatible Object error from
	EC_POINT_mul
Message-ID:
	<CANm5x_NZ7Xwtgy8sfWYWPjcEvYktFY6apBKXp=_222F7K7Qv9g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi,

I did not run this in the debugger, but one issue is that you are not
initializing `pub` before calling EC_POINT_mul : try adding

pub = EC_POINT_new(curve);
(and check for errors making sure pub is not null afterwards).

Hope this helps!


Best regards,

Nicola


On Mon, Oct 8, 2018, 00:31 John Hughes <john.hughes at secid.co.uk> wrote:

> I'm trying to generate a public key from a private key generated on a 
> HSM (and obtained by calling PKCS#11). Everything works fine until I 
> call EC_POINT_mul - at which point I get the error message:
>
>        error:100BB065:elliptic curve routines:ec_wNAF_mul:incompatible 
> objects
>
> I have checked the BIGNUM conversion - and that seems to be fine. The 
> key pair on the HSM is also generated using brainpoolP256r1.
>
> The basis of the code can be found at the end of the email. I'm 
> basically trying to follow the example provided in:
>         https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography.
>
> I'm using openssl 1.10h
>
> Any pointers or help would be appreciated.
>
>
> John
>
> ---------------------------------------------------------------
>
>
>         BN_CTX *ctx;
>         ctx = BN_CTX_new();
>         if(!ctx) {
>                 outputInfo("unable to create openssl BN_CTX");
>                 return;
>         }
>
>         EC_GROUP *curve;
>
>         outputInfo("about to create EC_GROUP_new_by_curve_name");
>         if(NULL == (curve =
> EC_GROUP_new_by_curve_name(NID_brainpoolP256r1))) {
>                 outputERRORmess("unable to setup curve");
>         }
>
>         outputInfo("about to create EC_KEY_new_by_curve_name");
>         EC_KEY *key;
>         if(NULL == (key = EC_KEY_new_by_curve_name(NID_brainpoolP256r1)))
{
>                 outputERRORmess("unable to setup EC_KEY");
>         }
>
>         // now get the private key contained in CKA_VALUE via PKCS#111 
> and place in *attrPrivate.pValue
>
>                 .......... (handle error)
>
>         EC_POINT *pub;
>
>
>         BIGNUM *prv = BN_bin2bn((unsigned char*)attrPrivate.pValue, 
> attrPrivate.ulValueLen, NULL);
>         if (prv == NULL) {
>
>         ...... (handle error)
>         }
>
>         if (1 != EC_KEY_set_private_key(key, prv)) {
>
>                 ........ (handle error)
>         }
>
>         if (1 != EC_POINT_mul(curve, pub, prv, NULL, NULL, ctx)) {
>                 outputInfo("unable to calculate the public key from 
> the HSM's private key using EC_POINT_mul");
>                 (handle error)
>
>         }
>
>
>
>
>
>
>
> --
> 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/20181008/bcd9871
5/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 47, Issue 8
********************************************


From Erwann.Abalea at docusign.com  Mon Oct  8 16:48:35 2018
From: Erwann.Abalea at docusign.com (Erwann Abalea)
Date: Mon, 8 Oct 2018 16:48:35 +0000
Subject: [openssl-users] Path Length Constraint ignored for Root and any
 self-issued certificate
In-Reply-To: <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>
References: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>
 <CAA2GJqVJahnQFg6QyptVLVWpBTixjecPE9PPwMwQywuoyr+emw@mail.gmail.com>
 <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>
Message-ID: <1F596F70-C94B-434F-A031-7BC7EC256B64@docusign.com>

Bonjour,

The prospective certification path excludes the Trust Anchor.
Therefore, the ? max_path_length=0 ? step is attained only when dealing with your EvilCA cert.

Cordialement,
Erwann Abalea

> Le 8 oct. 2018 ? 14:47, Peter Magnusson <blaufish.public.email at gmail.com> a ?crit :
> 
> That is not correct behaviour as far as I can understand.
> 
> RFC5280 Certification Path Validation algorithm process from root to
> leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> Preparation for Certificate i+1 is expected to occur upon Root
> certificate, i.e. the following should be expected behaviour:
> * max_path_length=n (initialisation)
> * max_path_length=n-1 (first decrement)
> * max_path_length=0 (copied from root certificate constraint)
> * VERIFY(max_path_length>0) error upon preparing transition from i=1
> (Root) to i=2 (EvilCA).
> 
> OpenSSL does everything in a slightly different reverse algorithm, but
> should perform the same controls and behaivor as the RFC imho.
> 
> And aside from the RFC algorithm checking for this condition, it is
> also analog with the description of the expected behaviour:
> 
>   The pathLenConstraint field is meaningful only if the cA boolean is
>   asserted and the key usage extension, if present, asserts the
>   keyCertSign bit (Section 4.2.1.3).  In this case, it gives the
>   maximum number of non-self-issued intermediate certificates that may
>   follow this certificate in a valid certification path.  (Note: The
>   last certificate in the certification path is not an intermediate
>   certificate, and is not included in this limit.  Usually, the last
>   certificate is an end entity certificate, but it can be a CA
>   certificate.)  A pathLenConstraint of zero indicates that no non-
>   self-issued intermediate CA certificates may follow in a valid
>   certification path.  Where it appears, the pathLenConstraint field
>   MUST be greater than or equal to zero.  Where pathLenConstraint does
>   not appear, no limit is imposed.
> 
> So my understanding is that the OpenSSL algorithm is confused and
> fails to perform a check that is applicable to self-issued
> certificates. The decrement of max_path_length (aka plen++ in OpenSSL
> implementation) should not occur for self issued certificates, but the
> validation of max_path_length>0 (aka plen>(constraint+1)) should
> occur.
> On Mon, Oct 8, 2018 at 1:27 PM J Decker <d3ck0r at gmail.com> wrote:
>> 
>> It was my interpretation that 0 pathlen on the root self signed meant infinite.
>> The pathlen only applies on the certs between root and the leaf (which obviously can be 0, and CA true or not, but bad form to say true I'd imagine.)
>> 
>> On Mon, Oct 8, 2018 at 1:57 AM Peter Magnusson <blaufish.public.email at gmail.com> wrote:
>>> 
>>> One more logic confusion in the OpenSSL Path Length Constraint check.
>>> Any Path Length Constraint set by Root (or any other Self-Issued
>>> Certificate) is ignored.
>>> Root cause appears to be !(x->ex_flags & EXFLAG_SI)=0 incorrectly
>>> applied to the checker (i.e. the checker and the calculation logic
>>> have been mixed up).
>>> 
>>> https://github.com/blaufish/openssl-pathlen/tree/master/testcase_2
>>> 
>>> openssl x509 -text -in root.pem | grep -a1 "X509v3 Basic"
>>>                Certificate Sign, CRL Sign
>>>            X509v3 Basic Constraints: critical
>>>                CA:TRUE, pathlen:0
>>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 Basic"
>>>                Certificate Sign, CRL Sign
>>>            X509v3 Basic Constraints: critical
>>>                CA:TRUE, pathlen:0
>>> openssl x509 -text -in evilserver.pem | grep -a1 "X509v3 Basic"
>>>        X509v3 extensions:
>>>            X509v3 Basic Constraints: critical
>>>                CA:FALSE
>>> ----
>>> openssl x509 -text -in root.pem | egrep -a1 "X509v3 .* Key Identifier"
>>>        X509v3 extensions:
>>>            X509v3 Subject Key Identifier:
>>>                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> --
>>> --
>>>                49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>>            X509v3 Authority Key Identifier:
>>> 
>>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> openssl x509 -text -in evilca.pem | grep -a1 "X509v3 .* Key Identifier"
>>>        X509v3 extensions:
>>>            X509v3 Subject Key Identifier:
>>>                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>> --
>>> --
>>>                B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>>            X509v3 Authority Key Identifier:
>>> 
>>> keyid:49:39:72:82:78:39:E8:60:AD:17:79:83:DB:65:B8:5C:E6:A7:84:B5
>>> openssl x509 -text -in evilserver.pem | egrep -a1 "X509v3 .* Key Identifier"
>>>                TLS Web Server Authentication
>>>            X509v3 Subject Key Identifier:
>>>                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>> --
>>> --
>>>                03:C6:48:91:09:73:F5:DF:EF:B5:9D:A4:66:00:16:C3:E9:DB:99:EE
>>>            X509v3 Authority Key Identifier:
>>> 
>>> keyid:B6:B4:75:66:18:B5:D2:4F:57:10:53:93:4F:CD:51:71:A4:27:84:7C
>>> ----
>>> ../openssl-1.1.1/apps/openssl verify -show_chain -verbose -CAfile
>>> root.pem -untrusted evilca.pem evilserver.pem
>>> ******* important variables *******
>>> *** check_chain_extensions:524 i=0
>>> *** check_chain_extensions:525 plen=0
>>> *** check_chain_extensions:526 x->ex_pathlen=-1
>>> ******* if statement components *******
>>> *** check_chain_extensions:528 i > 1=0
>>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
>>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=0
>>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>>> proxy_path_length + 1))=0
>>> ******* important variables *******
>>> *** check_chain_extensions:524 i=1
>>> *** check_chain_extensions:525 plen=1
>>> *** check_chain_extensions:526 x->ex_pathlen=0
>>> ******* if statement components *******
>>> *** check_chain_extensions:528 i > 1=0
>>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=1
>>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
>>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>>> proxy_path_length + 1))=0
>>> ******* important variables *******
>>> *** check_chain_extensions:524 i=2
>>> *** check_chain_extensions:525 plen=2
>>> *** check_chain_extensions:526 x->ex_pathlen=0
>>> ******* if statement components *******
>>> *** check_chain_extensions:528 i > 1=1
>>> *** check_chain_extensions:529 !(x->ex_flags & EXFLAG_SI)=0
>>> *** check_chain_extensions:530 (x->ex_pathlen != -1)=1
>>> *** check_chain_extensions:531 (plen > (x->ex_pathlen +
>>> proxy_path_length + 1))=1
>>> evilserver.pem: OK
>>> Chain:
>>> depth=0: C = SE, ST = EvilServer, L = EvilServer, O = EvilServer, OU =
>>> EvilServer, CN = EvilServer (untrusted)
>>> depth=1: C = SE, ST = EvilCA, L = EvilCA, O = EvilCA, OU = EvilCA, CN
>>> = EvilCA (untrusted)
>>> depth=2: C = SE, ST = Root, L = Root, O = Root, OU = Root, CN = Root
>>> --
>>> 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
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From bill.c.roberts at gmail.com  Mon Oct  8 17:44:52 2018
From: bill.c.roberts at gmail.com (William Roberts)
Date: Mon, 8 Oct 2018 10:44:52 -0700
Subject: [openssl-users] public version of encode_pkcs1
Message-ID: <CAFftDdqx4hwMnd3bcbDTDS9sTLmhsaSvqrXe4sx545uAbT0i1Q@mail.gmail.com>

I would like to use OpenSSL to compute the DigestInfo structure to
pass to a TPM for a TPM side RSA_Decrypt() operation when the TPM
doesn't support the digest algorithm.

I see in crypt/rsa_sign.c the routine encode_pkcs1() seems to do what
I want. Is their
a public version of this or a better way to do this?

I could just use the pre-computed ASN1 headers from the Notes section
in RFC3447 and concatenate the digest but my initial reaction to that
idea is don't do it.

Thoughts or ideas?

Bill

From blaufish.public.email at gmail.com  Tue Oct  9 07:42:18 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Tue, 9 Oct 2018 09:42:18 +0200
Subject: [openssl-users] Path Length Constraint ignored for Root and any
 self-issued certificate
In-Reply-To: <FBF6D998-8A53-4E03-9C37-4D0DEC1B637D@dukhovni.org>
References: <CANtcRX6Hg+bvpqkzBzjywZf82a8skU3R8pm1aWrpw7bwyw3LiA@mail.gmail.com>
 <CAA2GJqVJahnQFg6QyptVLVWpBTixjecPE9PPwMwQywuoyr+emw@mail.gmail.com>
 <CANtcRX5g53+Ou288_1DiG=7AAy+9QAk7UebhtLvtGdk2sux6hw@mail.gmail.com>
 <FBF6D998-8A53-4E03-9C37-4D0DEC1B637D@dukhovni.org>
Message-ID: <CANtcRX7OTCFcsE85PiPbVpMsyGZnY8L2skpdGv9JAs8mjhxmQQ@mail.gmail.com>

> trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)

Yes that seems to be aligned with how the intended the path validation
algorithm should be applied, i.e. first certificate processed is the
cert of the trust anchor.  But it could be clearer, and wording
"recommended" (lowercase) does seem to imply implementers SHOULD
process trust anchor cert rather than MUST process it.

"  In Section 6.1, the text describes basic path validation.  Valid
   paths begin with certificates issued by a trust anchor.  The
   algorithm requires the public key of the CA, the CA's name, and any
   constraints upon the set of paths that may be validated using this
   key."

...

" Where a CA distributes self-signed certificates to specify trust
   anchor information, certificate extensions can be used to specify
   recommended inputs to path validation.  For example, a policy
   constraints extension could be included in the self-signed
   certificate to indicate that paths beginning with this trust anchor
   should be trusted only for the specified policies."


> https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3
> Does that address your concerns?

I think so! I'll integrate it into my tests and try to do Q/A on the
change, see if I can figure out any other edge case.

Best Regards
//P
On Mon, Oct 8, 2018 at 6:15 PM Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
>
> > On Oct 8, 2018, at 8:47 AM, Peter Magnusson <blaufish.public.email at gmail.com> wrote:
> >
> > RFC5280 Certification Path Validation algorithm process from root to
> > leaf, i.e. (Root, EvilCA, EvilServer). 6.1.2 Initialization and 6.1.4
> > Preparation for Certificate i+1 is expected to occur upon Root
> > certificate, i.e. the following should be expected behaviour:
> > * max_path_length=n (initialisation)
> > * max_path_length=n-1 (first decrement)
> > * max_path_length=0 (copied from root certificate constraint)
> > * VERIFY(max_path_length>0) error upon preparing transition from i=1
> > (Root) to i=2 (EvilCA).
>
> Well, strictly speaking, the trust-anchor is not part of the certificate
> chain in RFC5280, it is a public key and an issuer name, not a certificate
> in the chain.  However, when the trust-anchor is in the form of a self-signed
> CA certificate, one might take the view that this is a self-issued certificate
> to be included in the chain:
>
>  trust anchor -> self-issued root CA cert (i = 1) -> ... -> EE (i = n)
>
> in which case the "path lenth: 0" in the self-issed root CA cert precludes
> the root from issuing any subsidiary CAs that can in turn issue further
> EE certs.  That is perhaps reasonable, so I updated PR #7353 with
> a further commit:
>
>   https://github.com/openssl/openssl/pull/7353/commits/02804dbd04180bdb87046bcd7581f9ba9cb2baf3
>
> Does that address your concerns?
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From satish.lvr at gmail.com  Tue Oct  9 09:43:38 2018
From: satish.lvr at gmail.com (Satish Lvr)
Date: Tue, 9 Oct 2018 15:13:38 +0530
Subject: [openssl-users] Backward compatibility for openSSL letter releases
	(openSSL 1.0.2 x)
Message-ID: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>

Hi All,

Can we assume that backward compatibility would be maintained between
letter releases of a version such as openSSL 1.0.2 (Eg: between openSSL
1.0.2a and openSSL 1.0.2p) unless there is security bug fix ?

Regards
Satish.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181009/00003626/attachment-0001.html>

From dustin.albright04 at gmail.com  Tue Oct  9 09:51:11 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Tue, 9 Oct 2018 05:51:11 -0400
Subject: [openssl-users] Backward compatibility for openSSL letter
 releases (openSSL 1.0.2 x)
In-Reply-To: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>
References: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>
Message-ID: <CAM4MkqfWZo+0A9BNX9CqzM0G18yoN0izqDVm479Ux=4PCYWPyQ@mail.gmail.com>

I am sorry

On Tue, Oct 9, 2018, 5:44 AM Satish Lvr <satish.lvr at gmail.com> wrote:

> Hi All,
>
> Can we assume that backward compatibility would be maintained between
> letter releases of a version such as openSSL 1.0.2 (Eg: between openSSL
> 1.0.2a and openSSL 1.0.2p) unless there is security bug fix ?
>
> Regards
> Satish.
>
> --
> 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/20181009/7062ff1e/attachment.html>

From mcr at sandelman.ca  Tue Oct  9 12:38:12 2018
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 09 Oct 2018 08:38:12 -0400
Subject: [openssl-users] Backward compatibility for openSSL letter
	releases (openSSL 1.0.2 x)
In-Reply-To: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>
References: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>
Message-ID: <29367.1539088692@localhost>


Satish Lvr <satish.lvr at gmail.com> wrote:
    > Can we assume that backward compatibility would be maintained between letter
    > releases of a version such as openSSL 1.0.2 (Eg: between openSSL 1.0.2a and
    > openSSL 1.0.2p) unless there is security bug fix ?

If one breaks backward (ABI) compatibility for a security bug fix, then
the old code needs to be recompiled, so you can't fix the bug with an update to
the .so.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181009/f2d7a373/attachment.sig>

From satish.lvr at gmail.com  Tue Oct  9 12:42:18 2018
From: satish.lvr at gmail.com (Satish Lvr)
Date: Tue, 9 Oct 2018 18:12:18 +0530
Subject: [openssl-users] Backward compatibility for openSSL letter
 releases (openSSL 1.0.2 x)
In-Reply-To: <29367.1539088692@localhost>
References: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>
 <29367.1539088692@localhost>
Message-ID: <CABp7qkf6A8x9MfqD_0gm8zp__YTZqd+cu_RKmYq_Mp1nGdGs8g@mail.gmail.com>

I am fine with recompilation. My question is more related to same
functional behavior between versions (say from 1.0.2a to 1.0.2b .....
1.0.2p) unless it is related to some security fix which breaks the old
behavior.

On Tue, Oct 9, 2018 at 6:08 PM Michael Richardson <mcr at sandelman.ca> wrote:

>
> Satish Lvr <satish.lvr at gmail.com> wrote:
>     > Can we assume that backward compatibility would be maintained
> between letter
>     > releases of a version such as openSSL 1.0.2 (Eg: between openSSL
> 1.0.2a and
>     > openSSL 1.0.2p) unless there is security bug fix ?
>
> If one breaks backward (ABI) compatibility for a security bug fix, then
> the old code needs to be recompiled, so you can't fix the bug with an
> update to
> the .so.
>
>
>
>
> --
> 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/20181009/0d35d58f/attachment.html>

From matt at openssl.org  Tue Oct  9 12:50:18 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 9 Oct 2018 13:50:18 +0100
Subject: [openssl-users] Backward compatibility for openSSL letter
 releases (openSSL 1.0.2 x)
In-Reply-To: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>
References: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>
Message-ID: <5ff90aa3-3e19-9b2b-df8f-7c3b4eaeec60@openssl.org>



On 09/10/18 10:43, Satish Lvr wrote:
> Hi All,
> 
> Can we assume that backward compatibility would be maintained between
> letter releases of a version such as openSSL 1.0.2 (Eg: between openSSL
> 1.0.2a and openSSL 1.0.2p) unless there is security bug fix ?

The OpenSSL policy on this is here (first para):

https://www.openssl.org/policies/releasestrat.html

Letter releases are backwards ABI and API compatible. There should be no
need to recompile your application to update to a later letter release.

Matt

From dustin.albright04 at gmail.com  Tue Oct  9 13:32:57 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Tue, 9 Oct 2018 09:32:57 -0400
Subject: [openssl-users] Backward compatibility for openSSL letter
 releases (openSSL 1.0.2 x)
In-Reply-To: <5ff90aa3-3e19-9b2b-df8f-7c3b4eaeec60@openssl.org>
References: <CABp7qkerDGVxaSbk5DqWXF_p_dMYWzpSQfHgzGF4BkR=qCd-+A@mail.gmail.com>
 <5ff90aa3-3e19-9b2b-df8f-7c3b4eaeec60@openssl.org>
Message-ID: <CAM4Mkqe06Zvs-veakbV4H1OR+AYSuonVvFc37YeKfKxUQie3_Q@mail.gmail.com>

Hey I tried I didn't know what was up


On Tue, Oct 9, 2018, 8:50 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 09/10/18 10:43, Satish Lvr wrote:
> > Hi All,
> >
> > Can we assume that backward compatibility would be maintained between
> > letter releases of a version such as openSSL 1.0.2 (Eg: between openSSL
> > 1.0.2a and openSSL 1.0.2p) unless there is security bug fix ?
>
> The OpenSSL policy on this is here (first para):
>
> https://www.openssl.org/policies/releasestrat.html
>
> Letter releases are backwards ABI and API compatible. There should be no
> need to recompile your application to update to a later letter release.
>
> 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/20181009/afabef46/attachment.html>

From jgh at wizmail.org  Tue Oct  9 21:27:14 2018
From: jgh at wizmail.org (Jeremy Harris)
Date: Tue, 9 Oct 2018 22:27:14 +0100
Subject: [openssl-users] client ignoring alert
Message-ID: <60975f52-7927-c7d7-5818-3222610cfff2@wizmail.org>

Hi,

	OpenSSL version 1.1.1 FIPS, on Fedora 29

(on both client and server)


I'm seeing a client not receiving, or ignoring, what
should be a fatal alert from the server during handshake.

The server is requiring a client-certificate, via:

SSL_CTX_set_verify(sctx,
  SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, ...)
...
server_ssl = SSL_new(server_ctx)
...
SSL_accept(server_ssl)

... and the client is not supplying one.  This is a deliberate
testcase.  The server debug output goes:
==============
21:31:54  8729 SMTP>> 220 TLS go ahead
21:31:54  8729 Calling SSL_accept
21:31:54  8729 SSL info: before SSL initialization
21:31:54  8729 SSL info: before SSL initialization
21:31:54  8729 SSL info: before SSL initialization
21:31:54  8729 SSL info: SSLv3/TLS read client hello
21:31:54  8729 SSL info: SSLv3/TLS write server hello
21:31:54  8729 SSL info: SSLv3/TLS write change cipher spec
21:31:54  8729 SSL info: TLSv1.3 write encrypted extensions
21:31:54  8729 SSL info: SSLv3/TLS write certificate request
21:31:54  8729 SSL info: SSLv3/TLS write certificate
21:31:54  8729 SSL info: TLSv1.3 write server certificate verify
21:31:54  8729 SSL info: SSLv3/TLS write finished
21:31:54  8729 SSL info: TLSv1.3 early data
21:31:54  8729 SSL info: TLSv1.3 early data
21:31:54  8729 SSL info: error
21:31:54  8729 SSL info: error
21:31:54  8729 LOG: MAIN
21:31:54  8729   TLS error on connection from (rhu.barb)
[192.168.122.94] (SSL_accept): error:1417C0C7:SSL
routines:tls_process_client_certificate:peer did not return a certificate
===================
So far so good.  The client however sees:
===================
<<< 220 TLS go ahead
Attempting to start TLS
SSL info: before SSL initialization
SSL info: before SSL initialization
SSL info: SSLv3/TLS write client hello
SSL info: SSLv3/TLS write client hello
SSL info: SSLv3/TLS read server hello
SSL info: TLSv1.3 read encrypted extensions
SSL info: SSLv3/TLS read server certificate request
SSL info: SSLv3/TLS read server certificate
SSL info: TLSv1.3 read server certificate verify
SSL info: SSLv3/TLS read finished
SSL info: SSLv3/TLS write change cipher spec
SSL info: SSLv3/TLS write client certificate
SSL info: SSLv3/TLS write finished
SSL info: SSL negotiation finished successfully
SSL info: SSL negotiation finished successfully
SSL connection using TLS_AES_256_GCM_SHA384
=================

The code running up to that last line indicates that
SSL_connect() returned without error:
----
rc = SSL_connect (*ssl);
alarm(0);

if (sigalrm_seen)
  {
  printf("SSL_connect timed out\n");
  return 0;
  }

if (rc <= 0)
  {
  ERR_print_errors_fp(stdout);
  return 0;
  }

printf("SSL connection using %s\n", SSL_get_cipher (*ssl));
----


What am I doing wrong?
-- 
Thanks,
  Jeremy

From dustin.albright04 at gmail.com  Tue Oct  9 22:06:13 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Tue, 9 Oct 2018 18:06:13 -0400
Subject: [openssl-users] client ignoring alert
In-Reply-To: <60975f52-7927-c7d7-5818-3222610cfff2@wizmail.org>
References: <60975f52-7927-c7d7-5818-3222610cfff2@wizmail.org>
Message-ID: <CAM4MkqeE+uLY4q=_jyCLEtA-2i-BoDyZ+9p0cTa8XMXvcsz-XQ@mail.gmail.com>

No had to bring in grocery  sorry about that

On Tue, Oct 9, 2018, 5:45 PM Jeremy Harris <jgh at wizmail.org> wrote:

> Hi,
>
>         OpenSSL version 1.1.1 FIPS, on Fedora 29
>
> (on both client and server)
>
>
> I'm seeing a client not receiving, or ignoring, what
> should be a fatal alert from the server during handshake.
>
> The server is requiring a client-certificate, via:
>
> SSL_CTX_set_verify(sctx,
>   SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, ...)
> ...
> server_ssl = SSL_new(server_ctx)
> ...
> SSL_accept(server_ssl)
>
> ... and the client is not supplying one.  This is a deliberate
> testcase.  The server debug output goes:
> ==============
> 21:31:54  8729 SMTP>> 220 TLS go ahead
> 21:31:54  8729 Calling SSL_accept
> 21:31:54  8729 SSL info: before SSL initialization
> 21:31:54  8729 SSL info: before SSL initialization
> 21:31:54  8729 SSL info: before SSL initialization
> 21:31:54  8729 SSL info: SSLv3/TLS read client hello
> 21:31:54  8729 SSL info: SSLv3/TLS write server hello
> 21:31:54  8729 SSL info: SSLv3/TLS write change cipher spec
> 21:31:54  8729 SSL info: TLSv1.3 write encrypted extensions
> 21:31:54  8729 SSL info: SSLv3/TLS write certificate request
> 21:31:54  8729 SSL info: SSLv3/TLS write certificate
> 21:31:54  8729 SSL info: TLSv1.3 write server certificate verify
> 21:31:54  8729 SSL info: SSLv3/TLS write finished
> 21:31:54  8729 SSL info: TLSv1.3 early data
> 21:31:54  8729 SSL info: TLSv1.3 early data
> 21:31:54  8729 SSL info: error
> 21:31:54  8729 SSL info: error
> 21:31:54  8729 LOG: MAIN
> 21:31:54  8729   TLS error on connection from (rhu.barb)
> [192.168.122.94] (SSL_accept): error:1417C0C7:SSL
> routines:tls_process_client_certificate:peer did not return a certificate
> ===================
> So far so good.  The client however sees:
> ===================
> <<< 220 TLS go ahead
> Attempting to start TLS
> SSL info: before SSL initialization
> SSL info: before SSL initialization
> SSL info: SSLv3/TLS write client hello
> SSL info: SSLv3/TLS write client hello
> SSL info: SSLv3/TLS read server hello
> SSL info: TLSv1.3 read encrypted extensions
> SSL info: SSLv3/TLS read server certificate request
> SSL info: SSLv3/TLS read server certificate
> SSL info: TLSv1.3 read server certificate verify
> SSL info: SSLv3/TLS read finished
> SSL info: SSLv3/TLS write change cipher spec
> SSL info: SSLv3/TLS write client certificate
> SSL info: SSLv3/TLS write finished
> SSL info: SSL negotiation finished successfully
> SSL info: SSL negotiation finished successfully
> SSL connection using TLS_AES_256_GCM_SHA384
> =================
>
> The code running up to that last line indicates that
> SSL_connect() returned without error:
> ----
> rc = SSL_connect (*ssl);
> alarm(0);
>
> if (sigalrm_seen)
>   {
>   printf("SSL_connect timed out\n");
>   return 0;
>   }
>
> if (rc <= 0)
>   {
>   ERR_print_errors_fp(stdout);
>   return 0;
>   }
>
> printf("SSL connection using %s\n", SSL_get_cipher (*ssl));
> ----
>
>
> What am I doing wrong?
> --
> Thanks,
>   Jeremy
> --
> 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/20181009/992e6674/attachment.html>

From dustin.albright04 at gmail.com  Tue Oct  9 22:08:32 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Tue, 9 Oct 2018 18:08:32 -0400
Subject: [openssl-users] client ignoring alert
In-Reply-To: <CAM4MkqeE+uLY4q=_jyCLEtA-2i-BoDyZ+9p0cTa8XMXvcsz-XQ@mail.gmail.com>
References: <60975f52-7927-c7d7-5818-3222610cfff2@wizmail.org>
 <CAM4MkqeE+uLY4q=_jyCLEtA-2i-BoDyZ+9p0cTa8XMXvcsz-XQ@mail.gmail.com>
Message-ID: <CAM4MkqfPXGC428S_cA0zhxfdtUJjPHR0AjE7amJrdg28DzYXTw@mail.gmail.com>

I don't want to I don't know how to do this

On Tue, Oct 9, 2018, 6:06 PM Dustin Albright <dustin.albright04 at gmail.com>
wrote:

> No had to bring in grocery  sorry about that
>
> On Tue, Oct 9, 2018, 5:45 PM Jeremy Harris <jgh at wizmail.org> wrote:
>
>> Hi,
>>
>>         OpenSSL version 1.1.1 FIPS, on Fedora 29
>>
>> (on both client and server)
>>
>>
>> I'm seeing a client not receiving, or ignoring, what
>> should be a fatal alert from the server during handshake.
>>
>> The server is requiring a client-certificate, via:
>>
>> SSL_CTX_set_verify(sctx,
>>   SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, ...)
>> ...
>> server_ssl = SSL_new(server_ctx)
>> ...
>> SSL_accept(server_ssl)
>>
>> ... and the client is not supplying one.  This is a deliberate
>> testcase.  The server debug output goes:
>> ==============
>> 21:31:54  8729 SMTP>> 220 TLS go ahead
>> 21:31:54  8729 Calling SSL_accept
>> 21:31:54  8729 SSL info: before SSL initialization
>> 21:31:54  8729 SSL info: before SSL initialization
>> 21:31:54  8729 SSL info: before SSL initialization
>> 21:31:54  8729 SSL info: SSLv3/TLS read client hello
>> 21:31:54  8729 SSL info: SSLv3/TLS write server hello
>> 21:31:54  8729 SSL info: SSLv3/TLS write change cipher spec
>> 21:31:54  8729 SSL info: TLSv1.3 write encrypted extensions
>> 21:31:54  8729 SSL info: SSLv3/TLS write certificate request
>> 21:31:54  8729 SSL info: SSLv3/TLS write certificate
>> 21:31:54  8729 SSL info: TLSv1.3 write server certificate verify
>> 21:31:54  8729 SSL info: SSLv3/TLS write finished
>> 21:31:54  8729 SSL info: TLSv1.3 early data
>> 21:31:54  8729 SSL info: TLSv1.3 early data
>> 21:31:54  8729 SSL info: error
>> 21:31:54  8729 SSL info: error
>> 21:31:54  8729 LOG: MAIN
>> 21:31:54  8729   TLS error on connection from (rhu.barb)
>> [192.168.122.94] (SSL_accept): error:1417C0C7:SSL
>> routines:tls_process_client_certificate:peer did not return a certificate
>> ===================
>> So far so good.  The client however sees:
>> ===================
>> <<< 220 TLS go ahead
>> Attempting to start TLS
>> SSL info: before SSL initialization
>> SSL info: before SSL initialization
>> SSL info: SSLv3/TLS write client hello
>> SSL info: SSLv3/TLS write client hello
>> SSL info: SSLv3/TLS read server hello
>> SSL info: TLSv1.3 read encrypted extensions
>> SSL info: SSLv3/TLS read server certificate request
>> SSL info: SSLv3/TLS read server certificate
>> SSL info: TLSv1.3 read server certificate verify
>> SSL info: SSLv3/TLS read finished
>> SSL info: SSLv3/TLS write change cipher spec
>> SSL info: SSLv3/TLS write client certificate
>> SSL info: SSLv3/TLS write finished
>> SSL info: SSL negotiation finished successfully
>> SSL info: SSL negotiation finished successfully
>> SSL connection using TLS_AES_256_GCM_SHA384
>> =================
>>
>> The code running up to that last line indicates that
>> SSL_connect() returned without error:
>> ----
>> rc = SSL_connect (*ssl);
>> alarm(0);
>>
>> if (sigalrm_seen)
>>   {
>>   printf("SSL_connect timed out\n");
>>   return 0;
>>   }
>>
>> if (rc <= 0)
>>   {
>>   ERR_print_errors_fp(stdout);
>>   return 0;
>>   }
>>
>> printf("SSL connection using %s\n", SSL_get_cipher (*ssl));
>> ----
>>
>>
>> What am I doing wrong?
>> --
>> Thanks,
>>   Jeremy
>> --
>> 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/20181009/6f3a5e03/attachment.html>

From dustin.albright04 at gmail.com  Tue Oct  9 22:11:58 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Tue, 9 Oct 2018 18:11:58 -0400
Subject: [openssl-users] client ignoring alert
In-Reply-To: <CAM4MkqfPXGC428S_cA0zhxfdtUJjPHR0AjE7amJrdg28DzYXTw@mail.gmail.com>
References: <60975f52-7927-c7d7-5818-3222610cfff2@wizmail.org>
 <CAM4MkqeE+uLY4q=_jyCLEtA-2i-BoDyZ+9p0cTa8XMXvcsz-XQ@mail.gmail.com>
 <CAM4MkqfPXGC428S_cA0zhxfdtUJjPHR0AjE7amJrdg28DzYXTw@mail.gmail.com>
Message-ID: <CAM4Mkqc9ZAUiQsmdCriGOoUUzzdGNVUB1TJ_pKSW4kddXWC1AQ@mail.gmail.com>

trying to get it open

On Tue, Oct 9, 2018, 6:08 PM Dustin Albright <dustin.albright04 at gmail.com>
wrote:

> I don't want to I don't know how to do this
>
> On Tue, Oct 9, 2018, 6:06 PM Dustin Albright <dustin.albright04 at gmail.com>
> wrote:
>
>> No had to bring in grocery  sorry about that
>>
>> On Tue, Oct 9, 2018, 5:45 PM Jeremy Harris <jgh at wizmail.org> wrote:
>>
>>> Hi,
>>>
>>>         OpenSSL version 1.1.1 FIPS, on Fedora 29
>>>
>>> (on both client and server)
>>>
>>>
>>> I'm seeing a client not receiving, or ignoring, what
>>> should be a fatal alert from the server during handshake.
>>>
>>> The server is requiring a client-certificate, via:
>>>
>>> SSL_CTX_set_verify(sctx,
>>>   SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, ...)
>>> ...
>>> server_ssl = SSL_new(server_ctx)
>>> ...
>>> SSL_accept(server_ssl)
>>>
>>> ... and the client is not supplying one.  This is a deliberate
>>> testcase.  The server debug output goes:
>>> ==============
>>> 21:31:54  8729 SMTP>> 220 TLS go ahead
>>> 21:31:54  8729 Calling SSL_accept
>>> 21:31:54  8729 SSL info: before SSL initialization
>>> 21:31:54  8729 SSL info: before SSL initialization
>>> 21:31:54  8729 SSL info: before SSL initialization
>>> 21:31:54  8729 SSL info: SSLv3/TLS read client hello
>>> 21:31:54  8729 SSL info: SSLv3/TLS write server hello
>>> 21:31:54  8729 SSL info: SSLv3/TLS write change cipher spec
>>> 21:31:54  8729 SSL info: TLSv1.3 write encrypted extensions
>>> 21:31:54  8729 SSL info: SSLv3/TLS write certificate request
>>> 21:31:54  8729 SSL info: SSLv3/TLS write certificate
>>> 21:31:54  8729 SSL info: TLSv1.3 write server certificate verify
>>> 21:31:54  8729 SSL info: SSLv3/TLS write finished
>>> 21:31:54  8729 SSL info: TLSv1.3 early data
>>> 21:31:54  8729 SSL info: TLSv1.3 early data
>>> 21:31:54  8729 SSL info: error
>>> 21:31:54  8729 SSL info: error
>>> 21:31:54  8729 LOG: MAIN
>>> 21:31:54  8729   TLS error on connection from (rhu.barb)
>>> [192.168.122.94] (SSL_accept): error:1417C0C7:SSL
>>> routines:tls_process_client_certificate:peer did not return a certificate
>>> ===================
>>> So far so good.  The client however sees:
>>> ===================
>>> <<< 220 TLS go ahead
>>> Attempting to start TLS
>>> SSL info: before SSL initialization
>>> SSL info: before SSL initialization
>>> SSL info: SSLv3/TLS write client hello
>>> SSL info: SSLv3/TLS write client hello
>>> SSL info: SSLv3/TLS read server hello
>>> SSL info: TLSv1.3 read encrypted extensions
>>> SSL info: SSLv3/TLS read server certificate request
>>> SSL info: SSLv3/TLS read server certificate
>>> SSL info: TLSv1.3 read server certificate verify
>>> SSL info: SSLv3/TLS read finished
>>> SSL info: SSLv3/TLS write change cipher spec
>>> SSL info: SSLv3/TLS write client certificate
>>> SSL info: SSLv3/TLS write finished
>>> SSL info: SSL negotiation finished successfully
>>> SSL info: SSL negotiation finished successfully
>>> SSL connection using TLS_AES_256_GCM_SHA384
>>> =================
>>>
>>> The code running up to that last line indicates that
>>> SSL_connect() returned without error:
>>> ----
>>> rc = SSL_connect (*ssl);
>>> alarm(0);
>>>
>>> if (sigalrm_seen)
>>>   {
>>>   printf("SSL_connect timed out\n");
>>>   return 0;
>>>   }
>>>
>>> if (rc <= 0)
>>>   {
>>>   ERR_print_errors_fp(stdout);
>>>   return 0;
>>>   }
>>>
>>> printf("SSL connection using %s\n", SSL_get_cipher (*ssl));
>>> ----
>>>
>>>
>>> What am I doing wrong?
>>> --
>>> Thanks,
>>>   Jeremy
>>> --
>>> 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/20181009/b350d4da/attachment-0001.html>

From dustin.albright04 at gmail.com  Tue Oct  9 22:24:19 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Tue, 9 Oct 2018 18:24:19 -0400
Subject: [openssl-users] client ignoring alert
In-Reply-To: <CAM4Mkqc9ZAUiQsmdCriGOoUUzzdGNVUB1TJ_pKSW4kddXWC1AQ@mail.gmail.com>
References: <60975f52-7927-c7d7-5818-3222610cfff2@wizmail.org>
 <CAM4MkqeE+uLY4q=_jyCLEtA-2i-BoDyZ+9p0cTa8XMXvcsz-XQ@mail.gmail.com>
 <CAM4MkqfPXGC428S_cA0zhxfdtUJjPHR0AjE7amJrdg28DzYXTw@mail.gmail.com>
 <CAM4Mkqc9ZAUiQsmdCriGOoUUzzdGNVUB1TJ_pKSW4kddXWC1AQ@mail.gmail.com>
Message-ID: <CAM4Mkqcj5fK3o6_hsfL_kHk-YeEQE5FBHaUw5=O2UT480w7YJQ@mail.gmail.com>

I'm trying to get on a open ss user I'm on a phone

On Tue, Oct 9, 2018, 6:11 PM Dustin Albright <dustin.albright04 at gmail.com>
wrote:

> trying to get it open
>
> On Tue, Oct 9, 2018, 6:08 PM Dustin Albright <dustin.albright04 at gmail.com>
> wrote:
>
>> I don't want to I don't know how to do this
>>
>> On Tue, Oct 9, 2018, 6:06 PM Dustin Albright <dustin.albright04 at gmail.com>
>> wrote:
>>
>>> No had to bring in grocery  sorry about that
>>>
>>> On Tue, Oct 9, 2018, 5:45 PM Jeremy Harris <jgh at wizmail.org> wrote:
>>>
>>>> Hi,
>>>>
>>>>         OpenSSL version 1.1.1 FIPS, on Fedora 29
>>>>
>>>> (on both client and server)
>>>>
>>>>
>>>> I'm seeing a client not receiving, or ignoring, what
>>>> should be a fatal alert from the server during handshake.
>>>>
>>>> The server is requiring a client-certificate, via:
>>>>
>>>> SSL_CTX_set_verify(sctx,
>>>>   SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, ...)
>>>> ...
>>>> server_ssl = SSL_new(server_ctx)
>>>> ...
>>>> SSL_accept(server_ssl)
>>>>
>>>> ... and the client is not supplying one.  This is a deliberate
>>>> testcase.  The server debug output goes:
>>>> ==============
>>>> 21:31:54  8729 SMTP>> 220 TLS go ahead
>>>> 21:31:54  8729 Calling SSL_accept
>>>> 21:31:54  8729 SSL info: before SSL initialization
>>>> 21:31:54  8729 SSL info: before SSL initialization
>>>> 21:31:54  8729 SSL info: before SSL initialization
>>>> 21:31:54  8729 SSL info: SSLv3/TLS read client hello
>>>> 21:31:54  8729 SSL info: SSLv3/TLS write server hello
>>>> 21:31:54  8729 SSL info: SSLv3/TLS write change cipher spec
>>>> 21:31:54  8729 SSL info: TLSv1.3 write encrypted extensions
>>>> 21:31:54  8729 SSL info: SSLv3/TLS write certificate request
>>>> 21:31:54  8729 SSL info: SSLv3/TLS write certificate
>>>> 21:31:54  8729 SSL info: TLSv1.3 write server certificate verify
>>>> 21:31:54  8729 SSL info: SSLv3/TLS write finished
>>>> 21:31:54  8729 SSL info: TLSv1.3 early data
>>>> 21:31:54  8729 SSL info: TLSv1.3 early data
>>>> 21:31:54  8729 SSL info: error
>>>> 21:31:54  8729 SSL info: error
>>>> 21:31:54  8729 LOG: MAIN
>>>> 21:31:54  8729   TLS error on connection from (rhu.barb)
>>>> [192.168.122.94] (SSL_accept): error:1417C0C7:SSL
>>>> routines:tls_process_client_certificate:peer did not return a
>>>> certificate
>>>> ===================
>>>> So far so good.  The client however sees:
>>>> ===================
>>>> <<< 220 TLS go ahead
>>>> Attempting to start TLS
>>>> SSL info: before SSL initialization
>>>> SSL info: before SSL initialization
>>>> SSL info: SSLv3/TLS write client hello
>>>> SSL info: SSLv3/TLS write client hello
>>>> SSL info: SSLv3/TLS read server hello
>>>> SSL info: TLSv1.3 read encrypted extensions
>>>> SSL info: SSLv3/TLS read server certificate request
>>>> SSL info: SSLv3/TLS read server certificate
>>>> SSL info: TLSv1.3 read server certificate verify
>>>> SSL info: SSLv3/TLS read finished
>>>> SSL info: SSLv3/TLS write change cipher spec
>>>> SSL info: SSLv3/TLS write client certificate
>>>> SSL info: SSLv3/TLS write finished
>>>> SSL info: SSL negotiation finished successfully
>>>> SSL info: SSL negotiation finished successfully
>>>> SSL connection using TLS_AES_256_GCM_SHA384
>>>> =================
>>>>
>>>> The code running up to that last line indicates that
>>>> SSL_connect() returned without error:
>>>> ----
>>>> rc = SSL_connect (*ssl);
>>>> alarm(0);
>>>>
>>>> if (sigalrm_seen)
>>>>   {
>>>>   printf("SSL_connect timed out\n");
>>>>   return 0;
>>>>   }
>>>>
>>>> if (rc <= 0)
>>>>   {
>>>>   ERR_print_errors_fp(stdout);
>>>>   return 0;
>>>>   }
>>>>
>>>> printf("SSL connection using %s\n", SSL_get_cipher (*ssl));
>>>> ----
>>>>
>>>>
>>>> What am I doing wrong?
>>>> --
>>>> Thanks,
>>>>   Jeremy
>>>> --
>>>> 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/20181009/c41cb1c7/attachment.html>

From matt at openssl.org  Tue Oct  9 22:53:54 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 9 Oct 2018 23:53:54 +0100
Subject: [openssl-users] client ignoring alert
In-Reply-To: <60975f52-7927-c7d7-5818-3222610cfff2@wizmail.org>
References: <60975f52-7927-c7d7-5818-3222610cfff2@wizmail.org>
Message-ID: <3ac44ea4-9720-040b-92d7-b9b54fdfe554@openssl.org>



On 09/10/18 22:27, Jeremy Harris wrote:
> Hi,
> 
> 	OpenSSL version 1.1.1 FIPS, on Fedora 29
> 
> (on both client and server)
> 
> 
> I'm seeing a client not receiving, or ignoring, what
> should be a fatal alert from the server during handshake.
> 
> The server is requiring a client-certificate, via:
> 
> SSL_CTX_set_verify(sctx,
>   SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, ...)
> ...
> server_ssl = SSL_new(server_ctx)
> ...
> SSL_accept(server_ssl)
> 
> ... and the client is not supplying one.  This is a deliberate
> testcase.  The server debug output goes:
> ==============
> 21:31:54  8729 SMTP>> 220 TLS go ahead
> 21:31:54  8729 Calling SSL_accept
> 21:31:54  8729 SSL info: before SSL initialization
> 21:31:54  8729 SSL info: before SSL initialization
> 21:31:54  8729 SSL info: before SSL initialization
> 21:31:54  8729 SSL info: SSLv3/TLS read client hello
> 21:31:54  8729 SSL info: SSLv3/TLS write server hello
> 21:31:54  8729 SSL info: SSLv3/TLS write change cipher spec
> 21:31:54  8729 SSL info: TLSv1.3 write encrypted extensions
> 21:31:54  8729 SSL info: SSLv3/TLS write certificate request
> 21:31:54  8729 SSL info: SSLv3/TLS write certificate
> 21:31:54  8729 SSL info: TLSv1.3 write server certificate verify
> 21:31:54  8729 SSL info: SSLv3/TLS write finished
> 21:31:54  8729 SSL info: TLSv1.3 early data
> 21:31:54  8729 SSL info: TLSv1.3 early data
> 21:31:54  8729 SSL info: error
> 21:31:54  8729 SSL info: error
> 21:31:54  8729 LOG: MAIN
> 21:31:54  8729   TLS error on connection from (rhu.barb)
> [192.168.122.94] (SSL_accept): error:1417C0C7:SSL
> routines:tls_process_client_certificate:peer did not return a certificate
> ===================
> So far so good.  The client however sees:
> ===================
> <<< 220 TLS go ahead
> Attempting to start TLS
> SSL info: before SSL initialization
> SSL info: before SSL initialization
> SSL info: SSLv3/TLS write client hello
> SSL info: SSLv3/TLS write client hello
> SSL info: SSLv3/TLS read server hello
> SSL info: TLSv1.3 read encrypted extensions
> SSL info: SSLv3/TLS read server certificate request
> SSL info: SSLv3/TLS read server certificate
> SSL info: TLSv1.3 read server certificate verify
> SSL info: SSLv3/TLS read finished
> SSL info: SSLv3/TLS write change cipher spec
> SSL info: SSLv3/TLS write client certificate
> SSL info: SSLv3/TLS write finished
> SSL info: SSL negotiation finished successfully
> SSL info: SSL negotiation finished successfully
> SSL connection using TLS_AES_256_GCM_SHA384
> =================
> 
> The code running up to that last line indicates that
> SSL_connect() returned without error:
> ----
> rc = SSL_connect (*ssl);
> alarm(0);
> 
> if (sigalrm_seen)
>   {
>   printf("SSL_connect timed out\n");
>   return 0;
>   }
> 
> if (rc <= 0)
>   {
>   ERR_print_errors_fp(stdout);
>   return 0;
>   }
> 
> printf("SSL connection using %s\n", SSL_get_cipher (*ssl));
> ----
> 
> 
> What am I doing wrong?
> 

Nothing. This is expected behaviour. The messages in this TLSv1.3
handshake are:

Client                 Server
------                 ------

ClientHello
                       ServerHello
                       EncryptedExtensions
                       CertificateRequest
                       Certificate
                       CertificateVerify
                       Finished
Certificate(empty)
Finished
                       Alert

Note that it is the client that sends the last flight of messages in the
handshake, and the (empty) Certificate message is part of that flight.
As far as the client is concerned it has sent all the messages it needs
to, to the complete the handshake. Therefore SSL_connect() completes
successfully. On the server side the handshake won't be complete until
it sees the client Finished - but before it gets that far it notices the
missing Certificate and sends the alert. From a client perspective this
will appear as if the handshake successfully completed but then the
server immediately aborts with a fatal alert.

Matt

From walter.h at mathemainzel.info  Wed Oct 10 06:12:45 2018
From: walter.h at mathemainzel.info (Walter H.)
Date: Wed, 10 Oct 2018 08:12:45 +0200
Subject: [openssl-users] Wildcard: how are they correct?
Message-ID: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>

Hello,

which of these possibilities is the correct one?

(a)  CN=*.example.com
     and subjectAltName = DNS:*.example.com, DNS:example.com

(b)  CN=example.com
     and subjectAltName = DNS:example.com, DNS:*.example.com

(c)  CN=example.com
     and subjectAltName = DNS:*.example.com, DNS:example.com

(d)  CN=hello world
     and subjectAltName = DNS:example.com, DNS:*.example.com

Thanks,
Walter


From dustin.albright04 at gmail.com  Wed Oct 10 06:23:59 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 02:23:59 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
Message-ID: <CAM4MkqfFvpH8Ss3S+T7ZW2MtgXMbNR4rWcnD99xV-0jzGxu9Lg@mail.gmail.com>

On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info> wrote:

> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> 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/20181010/e63f17f5/attachment.html>

From dustin.albright04 at gmail.com  Wed Oct 10 06:24:26 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 02:24:26 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
Message-ID: <CAM4MkqeKGgzg4O5LfuHskDoFpfGyyoO79kLrt_PHdAoYsHARYA@mail.gmail.com>

may we talk

On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info> wrote:

> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> 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/20181010/80a0f743/attachment-0001.html>

From dustin.albright04 at gmail.com  Wed Oct 10 06:37:44 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 02:37:44 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
Message-ID: <CAM4MkqdN0vwtwWQVeyor_C4qOXvCPY9Rbn6yDQ5Q++hERt54rw@mail.gmail.com>

so the way I'm take this it's pick and chose who walks right

On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info> wrote:

> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> 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/20181010/0e3a4388/attachment.html>

From dustin.albright04 at gmail.com  Wed Oct 10 06:40:45 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 02:40:45 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
Message-ID: <CAM4MkqfqJ-mVB+MfV7_OtP1DujNSgZBmKzNBxgfsa2Lg=FCkWg@mail.gmail.com>

I can pick any one of my own family old man's in the back me Lil man and
girl in liven room

On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info> wrote:

> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> 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/20181010/3242dde9/attachment.html>

From dustin.albright04 at gmail.com  Wed Oct 10 06:43:24 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 02:43:24 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
Message-ID: <CAM4MkqcrTsfCR0Z45Rk_uVdTwOVZyfb_DHP_+6mNvS98SWZ7dQ@mail.gmail.com>

I'm 25 Lil 18 old man in back the man in the back I'm not Goin to fight u I
know I have to give my phone to u and are willing to so the rest is up to u
and watch u diside

On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info> wrote:

> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> 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/20181010/7997e7d1/attachment.html>

From aerowolf at gmail.com  Wed Oct 10 06:54:55 2018
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Tue, 9 Oct 2018 23:54:55 -0700
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
Message-ID: <CAPMEXDb0UMUPV-n+vc2xqkd5k5jpfL5XtMZeFpwN8XQYpiuD6w@mail.gmail.com>

If subjectAltName exists, CN= is not evaluated.  All the given
examples should work.  (The only exceptions are validators that
haven't been current for more than 20 years.)  None of the examples is
correct.  CN= should not even be included in the certificate.  If it
is, (d) is the closest to correct, if "hello world" is replaced by
something meaningful to the identification or naming of the subject.

-Kyle H
On Tue, Oct 9, 2018 at 11:18 PM Walter H. <walter.h at mathemainzel.info> wrote:
>
> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From dustin.albright04 at gmail.com  Wed Oct 10 06:58:47 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 02:58:47 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <CAPMEXDb0UMUPV-n+vc2xqkd5k5jpfL5XtMZeFpwN8XQYpiuD6w@mail.gmail.com>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
 <CAPMEXDb0UMUPV-n+vc2xqkd5k5jpfL5XtMZeFpwN8XQYpiuD6w@mail.gmail.com>
Message-ID: <CAM4MkqcvrSPmqA=TvLq5tkuOq9hBnzga+1JQqFsyejuf2-D-cw@mail.gmail.com>

I'm Dustin Albright  I see what u r say thing there two listed so that's
old man in back and me inn liven room with Lil Lil man

On Wed, Oct 10, 2018, 2:55 AM Kyle Hamilton <aerowolf at gmail.com> wrote:

> If subjectAltName exists, CN= is not evaluated.  All the given
> examples should work.  (The only exceptions are validators that
> haven't been current for more than 20 years.)  None of the examples is
> correct.  CN= should not even be included in the certificate.  If it
> is, (d) is the closest to correct, if "hello world" is replaced by
> something meaningful to the identification or naming of the subject.
>
> -Kyle H
> On Tue, Oct 9, 2018 at 11:18 PM Walter H. <walter.h at mathemainzel.info>
> wrote:
> >
> > Hello,
> >
> > which of these possibilities is the correct one?
> >
> > (a)  CN=*.example.com
> >      and subjectAltName = DNS:*.example.com, DNS:example.com
> >
> > (b)  CN=example.com
> >      and subjectAltName = DNS:example.com, DNS:*.example.com
> >
> > (c)  CN=example.com
> >      and subjectAltName = DNS:*.example.com, DNS:example.com
> >
> > (d)  CN=hello world
> >      and subjectAltName = DNS:example.com, DNS:*.example.com
> >
> > Thanks,
> > Walter
> >
> > --
> > 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/20181010/f107ae43/attachment-0001.html>

From dustin.albright04 at gmail.com  Wed Oct 10 07:02:04 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 03:02:04 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
Message-ID: <CAM4Mkqf1Jqv7aM_KZvKwX7ET6u6W4BSYq46Ytyx0LwPxAdkOCw@mail.gmail.com>

if u would like to talk I will come talk with u because u divers the
respect

On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info> wrote:

> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> 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/20181010/3eb6d5df/attachment.html>

From dustin.albright04 at gmail.com  Wed Oct 10 07:02:50 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 03:02:50 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
Message-ID: <CAM4Mkqd=fG9UBK4dNUp7KSKc8Ki0bc7pK7kmX7D3JRz5t42H+Q@mail.gmail.com>

this really wasn't my intention  on all this not really sure how I don't it
eat her

On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info> wrote:

> Hello,
>
> which of these possibilities is the correct one?
>
> (a)  CN=*.example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (b)  CN=example.com
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> (c)  CN=example.com
>      and subjectAltName = DNS:*.example.com, DNS:example.com
>
> (d)  CN=hello world
>      and subjectAltName = DNS:example.com, DNS:*.example.com
>
> Thanks,
> Walter
>
> --
> 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/20181010/2caa2365/attachment.html>

From dustin.albright04 at gmail.com  Wed Oct 10 07:14:08 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 03:14:08 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <CAM4Mkqd=fG9UBK4dNUp7KSKc8Ki0bc7pK7kmX7D3JRz5t42H+Q@mail.gmail.com>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
 <CAM4Mkqd=fG9UBK4dNUp7KSKc8Ki0bc7pK7kmX7D3JRz5t42H+Q@mail.gmail.com>
Message-ID: <CAM4MkqcLUoHTkujERpwHPeSEy+bfkvH9L83OpHr=STf12BBBJw@mail.gmail.com>

I come out side on fruit porch the kid and dad's in side like I said I
can't pick I'd how I ended up doing this but I'm here on the porch u diseve
 the respece

On Wed, Oct 10, 2018, 3:02 AM Dustin Albright <dustin.albright04 at gmail.com>
wrote:

> this really wasn't my intention  on all this not really sure how I don't
> it eat her
>
> On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info>
> wrote:
>
>> Hello,
>>
>> which of these possibilities is the correct one?
>>
>> (a)  CN=*.example.com
>>      and subjectAltName = DNS:*.example.com, DNS:example.com
>>
>> (b)  CN=example.com
>>      and subjectAltName = DNS:example.com, DNS:*.example.com
>>
>> (c)  CN=example.com
>>      and subjectAltName = DNS:*.example.com, DNS:example.com
>>
>> (d)  CN=hello world
>>      and subjectAltName = DNS:example.com, DNS:*.example.com
>>
>> Thanks,
>> Walter
>>
>> --
>> 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/20181010/4ee86f3e/attachment.html>

From dustin.albright04 at gmail.com  Wed Oct 10 07:23:30 2018
From: dustin.albright04 at gmail.com (Dustin Albright)
Date: Wed, 10 Oct 2018 03:23:30 -0400
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <CAM4MkqcLUoHTkujERpwHPeSEy+bfkvH9L83OpHr=STf12BBBJw@mail.gmail.com>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
 <CAM4Mkqd=fG9UBK4dNUp7KSKc8Ki0bc7pK7kmX7D3JRz5t42H+Q@mail.gmail.com>
 <CAM4MkqcLUoHTkujERpwHPeSEy+bfkvH9L83OpHr=STf12BBBJw@mail.gmail.com>
Message-ID: <CAM4Mkqd3rUQrbg942+7UusWhWDNa7OPJPjP8HXoO5+QZ-Yc8yw@mail.gmail.com>

nothing don't need to happen to the kid and I can't pick any one so I just
come out side

On Wed, Oct 10, 2018, 3:14 AM Dustin Albright <dustin.albright04 at gmail.com>
wrote:

> I come out side on fruit porch the kid and dad's in side like I said I
> can't pick I'd how I ended up doing this but I'm here on the porch u diseve
>  the respece
>
> On Wed, Oct 10, 2018, 3:02 AM Dustin Albright <dustin.albright04 at gmail.com>
> wrote:
>
>> this really wasn't my intention  on all this not really sure how I don't
>> it eat her
>>
>> On Wed, Oct 10, 2018, 2:18 AM Walter H. <walter.h at mathemainzel.info>
>> wrote:
>>
>>> Hello,
>>>
>>> which of these possibilities is the correct one?
>>>
>>> (a)  CN=*.example.com
>>>      and subjectAltName = DNS:*.example.com, DNS:example.com
>>>
>>> (b)  CN=example.com
>>>      and subjectAltName = DNS:example.com, DNS:*.example.com
>>>
>>> (c)  CN=example.com
>>>      and subjectAltName = DNS:*.example.com, DNS:example.com
>>>
>>> (d)  CN=hello world
>>>      and subjectAltName = DNS:example.com, DNS:*.example.com
>>>
>>> Thanks,
>>> Walter
>>>
>>> --
>>> 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/20181010/7bb10069/attachment.html>

From jb-openssl at wisemo.com  Wed Oct 10 07:58:40 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 10 Oct 2018 09:58:40 +0200
Subject: [openssl-users] Wildcard: how are they correct?
In-Reply-To: <CAPMEXDb0UMUPV-n+vc2xqkd5k5jpfL5XtMZeFpwN8XQYpiuD6w@mail.gmail.com>
References: <1a1be1440e255de72d915c211ccbcc33.1539151965@squirrel.mail>
 <CAPMEXDb0UMUPV-n+vc2xqkd5k5jpfL5XtMZeFpwN8XQYpiuD6w@mail.gmail.com>
Message-ID: <450ad601-bb10-b54c-b90a-484e3ad1481e@wisemo.com>

Actually, for public CAs, the current standard (the CAB/F
Basic Requirements) require (a), (b) or (c), and prohibit
(d).

The prohibition on (d) is stated indirectly as a prohibition
against putting something that isn't the subjects validated
public DNS name in CN.

In practice, most public CAs use (a) for maximum backward
compatibility.

It should also be noted that it is a lot less than 20 years
since the popular GNU wget utility started looking at
subjectAltName.? Lesser known tools may have been even slower
to implement it.

On 10/10/2018 08:54, Kyle Hamilton wrote:
> If subjectAltName exists, CN= is not evaluated.  All the given
> examples should work.  (The only exceptions are validators that
> haven't been current for more than 20 years.)  None of the examples is
> correct.  CN= should not even be included in the certificate.  If it
> is, (d) is the closest to correct, if "hello world" is replaced by
> something meaningful to the identification or naming of the subject.
>
> -Kyle H
> On Tue, Oct 9, 2018 at 11:18 PM Walter H. <walter.h at mathemainzel.info> wrote:
>> Hello,
>>
>> which of these possibilities is the correct one?
>>
>> (a)  CN=*.example.com
>>       and subjectAltName = DNS:*.example.com, DNS:example.com
>>
>> (b)  CN=example.com
>>       and subjectAltName = DNS:example.com, DNS:*.example.com
>>
>> (c)  CN=example.com
>>       and subjectAltName = DNS:*.example.com, DNS:example.com
>>
>> (d)  CN=hello world
>>       and subjectAltName = DNS:example.com, DNS:*.example.com
>>
>> Thanks,
>> Walter
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


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 murugesh.pitchaiah at gmail.com  Wed Oct 10 11:36:49 2018
From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah)
Date: Wed, 10 Oct 2018 17:06:49 +0530
Subject: [openssl-users] Regarding Full PKI Authentication
Message-ID: <CAOu9RAcWvOoXP66PoOMoKu8PVk65K+ibywyz+qRRh0S+9N2BUg@mail.gmail.com>

Hi All,

I came across a term "Full PKI Authentication".
Please someone clarify, what the name "Full" suggests here ? Is there
any specific "Full PKI" version available ? Anay specific RFC
available for "Full" PKI  other than the following ?

https://tools.ietf.org/html/rfc5280.html


I could see something like "SPKI (simple)".


Thanks in advance.

Regards,
Murugesh P.

From rpo at compumatica.com  Wed Oct 10 11:55:05 2018
From: rpo at compumatica.com (RudyAC)
Date: Wed, 10 Oct 2018 04:55:05 -0700 (MST)
Subject: [openssl-users] CMS_verify provides empty output
Message-ID: <1539172505468-0.post@n7.nabble.com>

Hello,

when verifying  a signed email with CMS_verify() the verification failed.
That is not the main problem.
My problem is that the out data is empty. Using the library I got following
error:

OpenSSL Error code all:    <772382878d>
OpenSSL Error code lib:    <46d>
OpenSSL Error code func:   <154d>
OpenSSL Error code reason: <158d>
OpenSSL Error: error:2E09A09E:CMS
routines:CMS_SignerInfo_verify_content:verification failure

The mail body is base64 encoded. 

When verifying the email on console with "openssl cms -verify" there is no
message output, only the error 
message :

Verification failure
47883249174256:error:04091068:rsa routines:INT_RSA_VERIFY:bad
signature:rsa_sign.c:278:
47883249174256:error:2E09809E:CMS
routines:CMS_SignerInfo_verify:verification failure:cms_sd.c:775:

Any hints are welcome

Best regards
RudyAC




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

From jb-openssl at wisemo.com  Wed Oct 10 12:06:42 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 10 Oct 2018 14:06:42 +0200
Subject: [openssl-users] CMS_verify provides empty output
In-Reply-To: <1539172505468-0.post@n7.nabble.com>
References: <1539172505468-0.post@n7.nabble.com>
Message-ID: <8a594640-5278-c5f5-8cd4-0e4f4ad3a640@wisemo.com>

On 10/10/2018 13:55, RudyAC wrote:
> Hello,
>
> when verifying  a signed email with CMS_verify() the verification failed.
> That is not the main problem.
> My problem is that the out data is empty. Using the library I got following
> error:
>
> OpenSSL Error code all:    <772382878d>
> OpenSSL Error code lib:    <46d>
> OpenSSL Error code func:   <154d>
> OpenSSL Error code reason: <158d>
> OpenSSL Error: error:2E09A09E:CMS
> routines:CMS_SignerInfo_verify_content:verification failure
>
> The mail body is base64 encoded.
>
> When verifying the email on console with "openssl cms -verify" there is no
> message output, only the error
> message :
>
> Verification failure
> 47883249174256:error:04091068:rsa routines:INT_RSA_VERIFY:bad
> signature:rsa_sign.c:278:
> 47883249174256:error:2E09809E:CMS
> routines:CMS_SignerInfo_verify:verification failure:cms_sd.c:775:
>
> Any hints are welcome
The general assumption in OpenSSL is that if the signature is
invalid, the contents is probably fake,false or invalid, and
thus unwanted.

This is generally true in cryptography, but for actual e-mail
applications it may very well be desired to allow the user to
ignore signature verification failures.? If so, one could combine
allowing the mail software to access the MIME message normally (as
if the signature was some unknown MIME part) with a meaningful
(human readable) form of the actual error message from verification
(there is more than one way the verification can fail, and the
desired human response would often differ).

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 mythjill at gmail.com  Wed Oct 10 22:04:23 2018
From: mythjill at gmail.com (Dave Wang)
Date: Wed, 10 Oct 2018 15:04:23 -0700
Subject: [openssl-users] SSL_get_peer_certificate returns NULL in
 client_cert_cb after upgrade to openssl 1.1.1
Message-ID: <CAKvDEsXUxSPBqjvRS=mUD-6ir7fZarba=m6myNcOPe1cgu44iA@mail.gmail.com>

Hi there,

I have a client can talk with server, where the client certificate is
loaded in client_cert_cb  based on matching the server side certificate.

it works perfectly in openssl 1.1.0h, however it stops working after I
upgrade to openssl 1.1.1.

In client_cert_cb , when I call SSL_get_peer_certificate, it returns NULL,
which is different from openssl 1.1.0h.

I do set SSL_VERIFY_PEER on both sides.


any thoughts on this?

Regards,
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181010/1ac8fa85/attachment.html>

From paul at kinetic.com.au  Wed Oct 10 23:16:09 2018
From: paul at kinetic.com.au (Paul Chubb)
Date: Thu, 11 Oct 2018 10:16:09 +1100
Subject: [openssl-users] openssl commandline client use
Message-ID: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>

Hi,
      I am in the process of using the openssl suite for many things
including encrypting private information. There is a heap of information on
the internet suggesting using the openssl client for these sort of
purposes. However in a very few places there are also statements that the
client is only for testing the library and shouldn't be used in anger, that
it isn't secure or that only certain protocols are correctly implemented.
There isn't a statement in the documentation about this and we all know the
religiosity of some statements on the internet.

I am using aes-256-cbc to encrypt streamed data (a backup).

I am running OpenSSL 1.1.0g 2 Nov 2017

Any comments would be helpful.

many thanks in advance

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181011/49afa4d6/attachment.html>

From Michael.Wojcik at microfocus.com  Thu Oct 11 01:23:41 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 11 Oct 2018 01:23:41 +0000
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
Message-ID: <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Paul Chubb
> Sent: Wednesday, October 10, 2018 19:16

> I am in the process of using the openssl suite for many things including
> encrypting private information. There is a heap of information on the internet
> suggesting using the openssl client for these sort of purposes. However in a very few
> places there are also statements that the client is only for testing the library and
> shouldn't be used in anger, that it isn't secure or that only certain protocols are
> correctly implemented. ...

> I am using aes-256-cbc to encrypt streamed data (a backup).

You haven't explained your threat model.

If you're encrypting your diary so your kid sister can't read about your crush at school, then sure, use the openssl utility with aes-256-cbc.

If the data you're encrypting falls under a regulatory regime with potential stiff legal consequences, like HIPPA or GDPR, then this is a Bad Idea.

Here's the thing: Forget, for a moment, the question of whether you should script crypto using the openssl utility. The real issue, to my mind, is that cryptographic systems assembled by non-cryptographers are very often - probably almost often - fatally flawed. And AES is not a cryptosystem; it's a primitive. All the openssl utility is giving you there is a cipher, key length, and combining mode.

Some potential problems that are obvious right off the bat:

- No integrity protection over the data. You've run into the Moxie Marlinspike Cryptographic Doom Principle right off the bat.

- CBC has problems. *All* the block cipher combining modes have problems. Stream ciphers have problems. How are you avoiding those problems? (Note that experienced people make implementation mistakes in this area.)

- What are you doing about padding? Do you have predictable plaintext near the beginning? When do you re-key?

- How do you generate and manage your keys? Are you practicing good key hygiene?

- Data recovery from an encrypted backup is tough. With CBC, one bit goes astray and you've lost everything after that. (Well, you can brute-force a single-bit error, but it's going to be a tiresome exercise unless you automate it. Multi-bit errors will obviously be worse, and combinatorial explosion will bite you quickly.) ECC after encryption would be a good idea here, perhaps with an erasure code. Maybe you're storing to a suitable RAID mode or something; you haven't told us.

I can't really suggest alternatives, partly because this isn't an area I pay a lot of attention to, but mostly because you haven't explained your use case. "Data backup" doesn't mean much unless we have some idea of how much data, how often, what sort of data, what it's being backed up to, how sensitive it is, and so forth.

Sorry if this sounds overly negative, but in my opinion your question is severely underdetermined, and it sounds like you're potentially open to some rather serious failures. That may not be a concern - again, I don't know what your use case or threat model is.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From openssl-users at dukhovni.org  Thu Oct 11 03:12:17 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 10 Oct 2018 23:12:17 -0400
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
 <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
Message-ID: <20181011031216.GA3589@straasha.imrryr.org>

On Thu, Oct 11, 2018 at 01:23:41AM +0000, Michael Wojcik wrote:

> - Data recovery from an encrypted backup is tough. With CBC, one bit goes
> astray and you've lost everything after that.

No, a 1 bit error in CBC ciphertext breaks only the current block,
and introduces a 1 bit error into the plaintext of the next block.
After that, you're back in sync.

But yes, indeed "openssl enc" offers little integrity protection.
One should probably break the data into chunks and encrypt and MAC
each chunk with the MAC covering the chunk sequence number, and
whether it is the last chunk.

-- 
	Viktor.

From paul at kinetic.com.au  Thu Oct 11 04:44:56 2018
From: paul at kinetic.com.au (Paul Chubb)
Date: Thu, 11 Oct 2018 15:44:56 +1100
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <20181011031216.GA3589@straasha.imrryr.org>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
 <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
 <20181011031216.GA3589@straasha.imrryr.org>
Message-ID: <CAJQZn8bRoHMYpFeC73mnYR6J72KpzrmJANfaZPLEw3dSQmkntQ@mail.gmail.com>

Hi thanks for the responses. I try not to do crypto for the very reasons
you raise - i simply don't know enough and your (good) pointed questions
have demonstrated that.

 Context:

We are trying for GDPR and other privacy law compliance. We probably need
to meet GDPR, US requirements, Australian requirements, Japanese
requirements and UK requirements. The data is not hugely critical. It
contains names and exercise metrics. It doesn't contain credit card details
or anything above the level of names. I don't think it contains addresses
but probably does contain names of recognizable organisations which could
provide a tuple for identification purposes if the data was compromised.

A mysqldump of the db in production at present is around 170Gb however that
is text based and we are using a binary solution based on percola
xtrabackup so the final size should be smaller for the current time. The
documentation on this by the backup software provider is very simplistic
and simply pipes the stream of data through openssl and then gzip:

mariabackup --user=root --backup --stream=xbstream | gzip | openssl
enc -aes-256-cbc -k mypass > backup.xb.gz.enc

There are thousands of posts that do similar and in non-crypto circles it
is the accepted way of doing things. That was my starting point.

I am  not using a password but generating keys. The symetric key is
generated by "openssl rand -hex 32" which I have read is suitable. The
Nonce or IV is generated  by "openssl rand -hex 16". These values are used
once and then kept for decryption of that file. They in turn are encrypted
before storing - see below.

The two keys are held in ram while the backup occurs. They are applied to
openssl using the -K and -iv switches. They are then written out to disk.
encrypted with a list of public RSA keys and the original deleted from
disk. I then package it all up and delete the intervening encrypted files
leaving me with an archive with the encrypted backup and several copies of
the nonce and key each encrypted by different people's public keys.

The backup regime has not been decided as yet. I expect it will be
something like a full backup per week and then either incrementals or
differentials on the other days. I expect that the fulls will be kept for
30 days and the deltas for 14days. The database backups will sit on a
secured server disk which in turn will be backed up by the hosting provider
with whatever process and rotation they use.

I would expect that headers in the backup stream would be predictable,
whether they provide a good enough attack surface I don't know. In addition
the clients of course know their data that may also provide an attack
surface. Finally I have included an encrypted file with a known plain text
phrase. Based on your comments, this will probably not get into production
but provides an easy way for testing and debugging to check that things are
encrypted or not.

The kind of statements that prompted my question was:
https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup
whose comments suggest that openssl should never be used for production
purposes.Their suggestion was GnuPG which isn't suitable for this purpose
because it does password/key management that assumes a desktop/laptop
environment and manual process. I also looked at ccrypt and mcrypt but then
went back to openssl.

Cheers Paul






On Thu, Oct 11, 2018 at 2:12 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Thu, Oct 11, 2018 at 01:23:41AM +0000, Michael Wojcik wrote:
>
> > - Data recovery from an encrypted backup is tough. With CBC, one bit goes
> > astray and you've lost everything after that.
>
> No, a 1 bit error in CBC ciphertext breaks only the current block,
> and introduces a 1 bit error into the plaintext of the next block.
> After that, you're back in sync.
>
> But yes, indeed "openssl enc" offers little integrity protection.
> One should probably break the data into chunks and encrypt and MAC
> each chunk with the MAC covering the chunk sequence number, and
> whether it is the last chunk.
>
> --
>         Viktor.
> --
> 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/20181011/e5cb9537/attachment.html>

From blaufish.public.email at gmail.com  Thu Oct 11 08:47:34 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Thu, 11 Oct 2018 10:47:34 +0200
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <CAJQZn8bRoHMYpFeC73mnYR6J72KpzrmJANfaZPLEw3dSQmkntQ@mail.gmail.com>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
 <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
 <20181011031216.GA3589@straasha.imrryr.org>
 <CAJQZn8bRoHMYpFeC73mnYR6J72KpzrmJANfaZPLEw3dSQmkntQ@mail.gmail.com>
Message-ID: <CANtcRX64RnFrhuv3ZxWErOcWHm_3iE63tWMUYkzEd_PDFJ7DGA@mail.gmail.com>

You would be better off with AES-CCM or such for your backup, that
gives you the integrity check.
 i.e. you would be reasonably sure what you decrypt is encrypted with your key.

So the fist question would be why even consider AES-CBC? Somewhere in
the decision process you ought to go "Is the major goal to support
very strange extremely limited legacy embedded environment where
library developers claims CBC is the only option?" and if no: don't
consider CBC. Since you are using OpenSSL, you clearly does not have
any problem that would give you a compelling reason to use CBC.

Using CBC in anything new design does not make much sense.
- CBC is weak against oracle attacks (online interactions with a
decryption oracle)
- CBC has no protection against modifications. If decryption succeeds,
you don't know if the resulting plaintext originated from

However - Your use-case as explained ( openssl enc -aes-256-cbc -k
mypass > backup.xb.gz.enc ) might not be a use-case where the AES-CBC
vulnerabilities are most dangerous though, if the decryption process
is a slow manual process. E.g. Padding oracle attacks against CBC
requires on average 128 decryption to crack one byte, and need an
online oracle (such as e.g. a backup decryption/restore service) to be
executed. With a human entering the decryption key manually for each
attempt, you'd expect the human to get suspicious with thousands of
decryption requests.  But as soon as you want to automate restore
functions and remove the human, you might enable oracle style attacks.

On Thu, Oct 11, 2018 at 6:45 AM Paul Chubb <paul at kinetic.com.au> wrote:
>
> Hi thanks for the responses. I try not to do crypto for the very reasons you raise - i simply don't know enough and your (good) pointed questions have demonstrated that.
>
>  Context:
>
> We are trying for GDPR and other privacy law compliance. We probably need to meet GDPR, US requirements, Australian requirements, Japanese requirements and UK requirements. The data is not hugely critical. It contains names and exercise metrics. It doesn't contain credit card details or anything above the level of names. I don't think it contains addresses but probably does contain names of recognizable organisations which could provide a tuple for identification purposes if the data was compromised.
>
> A mysqldump of the db in production at present is around 170Gb however that is text based and we are using a binary solution based on percola xtrabackup so the final size should be smaller for the current time. The documentation on this by the backup software provider is very simplistic and simply pipes the stream of data through openssl and then gzip:
>
> mariabackup --user=root --backup --stream=xbstream | gzip | openssl  enc -aes-256-cbc -k mypass > backup.xb.gz.enc
>
> There are thousands of posts that do similar and in non-crypto circles it is the accepted way of doing things. That was my starting point.
>
> I am  not using a password but generating keys. The symetric key is generated by "openssl rand -hex 32" which I have read is suitable. The Nonce or IV is generated  by "openssl rand -hex 16". These values are used once and then kept for decryption of that file. They in turn are encrypted before storing - see below.
>
> The two keys are held in ram while the backup occurs. They are applied to openssl using the -K and -iv switches. They are then written out to disk. encrypted with a list of public RSA keys and the original deleted from disk. I then package it all up and delete the intervening encrypted files leaving me with an archive with the encrypted backup and several copies of the nonce and key each encrypted by different people's public keys.
>
> The backup regime has not been decided as yet. I expect it will be something like a full backup per week and then either incrementals or differentials on the other days. I expect that the fulls will be kept for 30 days and the deltas for 14days. The database backups will sit on a secured server disk which in turn will be backed up by the hosting provider with whatever process and rotation they use.
>
> I would expect that headers in the backup stream would be predictable, whether they provide a good enough attack surface I don't know. In addition the clients of course know their data that may also provide an attack surface. Finally I have included an encrypted file with a known plain text phrase. Based on your comments, this will probably not get into production but provides an easy way for testing and debugging to check that things are encrypted or not.
>
> The kind of statements that prompted my question was: https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup whose comments suggest that openssl should never be used for production purposes.Their suggestion was GnuPG which isn't suitable for this purpose because it does password/key management that assumes a desktop/laptop environment and manual process. I also looked at ccrypt and mcrypt but then went back to openssl.
>
> Cheers Paul
>
>
>
>
>
>
> On Thu, Oct 11, 2018 at 2:12 PM Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
>>
>> On Thu, Oct 11, 2018 at 01:23:41AM +0000, Michael Wojcik wrote:
>>
>> > - Data recovery from an encrypted backup is tough. With CBC, one bit goes
>> > astray and you've lost everything after that.
>>
>> No, a 1 bit error in CBC ciphertext breaks only the current block,
>> and introduces a 1 bit error into the plaintext of the next block.
>> After that, you're back in sync.
>>
>> But yes, indeed "openssl enc" offers little integrity protection.
>> One should probably break the data into chunks and encrypt and MAC
>> each chunk with the MAC covering the chunk sequence number, and
>> whether it is the last chunk.
>>
>> --
>>         Viktor.
>> --
>> 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 matt at openssl.org  Thu Oct 11 09:03:39 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Oct 2018 10:03:39 +0100
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <CANtcRX64RnFrhuv3ZxWErOcWHm_3iE63tWMUYkzEd_PDFJ7DGA@mail.gmail.com>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
 <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
 <20181011031216.GA3589@straasha.imrryr.org>
 <CAJQZn8bRoHMYpFeC73mnYR6J72KpzrmJANfaZPLEw3dSQmkntQ@mail.gmail.com>
 <CANtcRX64RnFrhuv3ZxWErOcWHm_3iE63tWMUYkzEd_PDFJ7DGA@mail.gmail.com>
Message-ID: <c696f34a-46e6-23b8-b548-a00d66a101dc@openssl.org>



On 11/10/18 09:47, Peter Magnusson wrote:
> You would be better off with AES-CCM or such for your backup, that
> gives you the integrity check.
>  i.e. you would be reasonably sure what you decrypt is encrypted with your key.

I'd just point out that CCM and other AEAD modes are not supported in
the openssl enc app.

Matt


> 
> So the fist question would be why even consider AES-CBC? Somewhere in
> the decision process you ought to go "Is the major goal to support
> very strange extremely limited legacy embedded environment where
> library developers claims CBC is the only option?" and if no: don't
> consider CBC. Since you are using OpenSSL, you clearly does not have
> any problem that would give you a compelling reason to use CBC.
> 
> Using CBC in anything new design does not make much sense.
> - CBC is weak against oracle attacks (online interactions with a
> decryption oracle)
> - CBC has no protection against modifications. If decryption succeeds,
> you don't know if the resulting plaintext originated from
> 
> However - Your use-case as explained ( openssl enc -aes-256-cbc -k
> mypass > backup.xb.gz.enc ) might not be a use-case where the AES-CBC
> vulnerabilities are most dangerous though, if the decryption process
> is a slow manual process. E.g. Padding oracle attacks against CBC
> requires on average 128 decryption to crack one byte, and need an
> online oracle (such as e.g. a backup decryption/restore service) to be
> executed. With a human entering the decryption key manually for each
> attempt, you'd expect the human to get suspicious with thousands of
> decryption requests.  But as soon as you want to automate restore
> functions and remove the human, you might enable oracle style attacks.
> 
> On Thu, Oct 11, 2018 at 6:45 AM Paul Chubb <paul at kinetic.com.au> wrote:
>>
>> Hi thanks for the responses. I try not to do crypto for the very reasons you raise - i simply don't know enough and your (good) pointed questions have demonstrated that.
>>
>>  Context:
>>
>> We are trying for GDPR and other privacy law compliance. We probably need to meet GDPR, US requirements, Australian requirements, Japanese requirements and UK requirements. The data is not hugely critical. It contains names and exercise metrics. It doesn't contain credit card details or anything above the level of names. I don't think it contains addresses but probably does contain names of recognizable organisations which could provide a tuple for identification purposes if the data was compromised.
>>
>> A mysqldump of the db in production at present is around 170Gb however that is text based and we are using a binary solution based on percola xtrabackup so the final size should be smaller for the current time. The documentation on this by the backup software provider is very simplistic and simply pipes the stream of data through openssl and then gzip:
>>
>> mariabackup --user=root --backup --stream=xbstream | gzip | openssl  enc -aes-256-cbc -k mypass > backup.xb.gz.enc
>>
>> There are thousands of posts that do similar and in non-crypto circles it is the accepted way of doing things. That was my starting point.
>>
>> I am  not using a password but generating keys. The symetric key is generated by "openssl rand -hex 32" which I have read is suitable. The Nonce or IV is generated  by "openssl rand -hex 16". These values are used once and then kept for decryption of that file. They in turn are encrypted before storing - see below.
>>
>> The two keys are held in ram while the backup occurs. They are applied to openssl using the -K and -iv switches. They are then written out to disk. encrypted with a list of public RSA keys and the original deleted from disk. I then package it all up and delete the intervening encrypted files leaving me with an archive with the encrypted backup and several copies of the nonce and key each encrypted by different people's public keys.
>>
>> The backup regime has not been decided as yet. I expect it will be something like a full backup per week and then either incrementals or differentials on the other days. I expect that the fulls will be kept for 30 days and the deltas for 14days. The database backups will sit on a secured server disk which in turn will be backed up by the hosting provider with whatever process and rotation they use.
>>
>> I would expect that headers in the backup stream would be predictable, whether they provide a good enough attack surface I don't know. In addition the clients of course know their data that may also provide an attack surface. Finally I have included an encrypted file with a known plain text phrase. Based on your comments, this will probably not get into production but provides an easy way for testing and debugging to check that things are encrypted or not.
>>
>> The kind of statements that prompted my question was: https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup whose comments suggest that openssl should never be used for production purposes.Their suggestion was GnuPG which isn't suitable for this purpose because it does password/key management that assumes a desktop/laptop environment and manual process. I also looked at ccrypt and mcrypt but then went back to openssl.
>>
>> Cheers Paul
>>
>>
>>
>>
>>
>>
>> On Thu, Oct 11, 2018 at 2:12 PM Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
>>>
>>> On Thu, Oct 11, 2018 at 01:23:41AM +0000, Michael Wojcik wrote:
>>>
>>>> - Data recovery from an encrypted backup is tough. With CBC, one bit goes
>>>> astray and you've lost everything after that.
>>>
>>> No, a 1 bit error in CBC ciphertext breaks only the current block,
>>> and introduces a 1 bit error into the plaintext of the next block.
>>> After that, you're back in sync.
>>>
>>> But yes, indeed "openssl enc" offers little integrity protection.
>>> One should probably break the data into chunks and encrypt and MAC
>>> each chunk with the MAC covering the chunk sequence number, and
>>> whether it is the last chunk.
>>>
>>> --
>>>         Viktor.
>>> --
>>> 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 matt at openssl.org  Thu Oct 11 09:25:22 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Oct 2018 10:25:22 +0100
Subject: [openssl-users] SSL_get_peer_certificate returns NULL in
 client_cert_cb after upgrade to openssl 1.1.1
In-Reply-To: <CAKvDEsXUxSPBqjvRS=mUD-6ir7fZarba=m6myNcOPe1cgu44iA@mail.gmail.com>
References: <CAKvDEsXUxSPBqjvRS=mUD-6ir7fZarba=m6myNcOPe1cgu44iA@mail.gmail.com>
Message-ID: <a64cdde7-38a4-645d-937b-cb7c1d729b1b@openssl.org>



On 10/10/18 23:04, Dave Wang wrote:
> Hi there,
> 
> I have a client can talk with server, where the client certificate is
> loaded in?client_cert_cb? based on matching the server side certificate.
> 
> it works perfectly in openssl 1.1.0h, however it stops working after I
> upgrade to openssl 1.1.1.
> 
> In client_cert_cb , when I call?SSL_get_peer_certificate, it returns
> NULL, which is different from openssl 1.1.0h.
> 
> I do set SSL_VERIFY_PEER on both sides.?
> 
> 
> any thoughts on this?

I assume this only happens with a TLSv1.3 handshake?

>From the documentation, the client_cert_cb is called: "when a client
certificate is requested by a server". In practice this means when we
have received the CertificateRequest message from the server.

In TLSv1.2 (and below) the server's first flight of messages for a
client-auth full handshake in response to a ClientHello looks like this:

ServerHello
Certificate
ServerKeyExchange
CertificateRequest
ServerHelloDone

In TLSv1.3 it looks like this:

ServerHello
EncryptedExtensions
CertificateRequest
Certificate
CertificateVerify
Finished

Note that in TLSv1.2 the CertificateRequest message comes *after* the
server has sent the Certificate but in TLSv1.3 it comes *before*. That
means of course that in TLSv1.3 the client_cert_cb gets called before we
have processed the server's certificate and hence
SSL_get_peer_certificate() returns NULL.

I'm wondering whether we should delay calling the client_cert_cb in
TLSv1.3 until after the CertificateVerify has been processed.

Matt

From matt at openssl.org  Thu Oct 11 09:36:28 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Oct 2018 10:36:28 +0100
Subject: [openssl-users] SSL_get_peer_certificate returns NULL in
 client_cert_cb after upgrade to openssl 1.1.1
In-Reply-To: <a64cdde7-38a4-645d-937b-cb7c1d729b1b@openssl.org>
References: <CAKvDEsXUxSPBqjvRS=mUD-6ir7fZarba=m6myNcOPe1cgu44iA@mail.gmail.com>
 <a64cdde7-38a4-645d-937b-cb7c1d729b1b@openssl.org>
Message-ID: <9eb95cdb-72c2-235d-f75a-f9c51982f14b@openssl.org>

I opened this issue to track this problem:

https://github.com/openssl/openssl/issues/7384

Matt


On 11/10/18 10:25, Matt Caswell wrote:
> 
> 
> On 10/10/18 23:04, Dave Wang wrote:
>> Hi there,
>>
>> I have a client can talk with server, where the client certificate is
>> loaded in?client_cert_cb? based on matching the server side certificate.
>>
>> it works perfectly in openssl 1.1.0h, however it stops working after I
>> upgrade to openssl 1.1.1.
>>
>> In client_cert_cb , when I call?SSL_get_peer_certificate, it returns
>> NULL, which is different from openssl 1.1.0h.
>>
>> I do set SSL_VERIFY_PEER on both sides.?
>>
>>
>> any thoughts on this?
> 
> I assume this only happens with a TLSv1.3 handshake?
> 
> From the documentation, the client_cert_cb is called: "when a client
> certificate is requested by a server". In practice this means when we
> have received the CertificateRequest message from the server.
> 
> In TLSv1.2 (and below) the server's first flight of messages for a
> client-auth full handshake in response to a ClientHello looks like this:
> 
> ServerHello
> Certificate
> ServerKeyExchange
> CertificateRequest
> ServerHelloDone
> 
> In TLSv1.3 it looks like this:
> 
> ServerHello
> EncryptedExtensions
> CertificateRequest
> Certificate
> CertificateVerify
> Finished
> 
> Note that in TLSv1.2 the CertificateRequest message comes *after* the
> server has sent the Certificate but in TLSv1.3 it comes *before*. That
> means of course that in TLSv1.3 the client_cert_cb gets called before we
> have processed the server's certificate and hence
> SSL_get_peer_certificate() returns NULL.
> 
> I'm wondering whether we should delay calling the client_cert_cb in
> TLSv1.3 until after the CertificateVerify has been processed.
> 
> Matt
> 

From uri at ll.mit.edu  Thu Oct 11 10:15:24 2018
From: uri at ll.mit.edu (Uri Blumenthal)
Date: Thu, 11 Oct 2018 06:15:24 -0400
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <c696f34a-46e6-23b8-b548-a00d66a101dc@openssl.org>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
 <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
 <20181011031216.GA3589@straasha.imrryr.org>
 <CAJQZn8bRoHMYpFeC73mnYR6J72KpzrmJANfaZPLEw3dSQmkntQ@mail.gmail.com>
 <CANtcRX64RnFrhuv3ZxWErOcWHm_3iE63tWMUYkzEd_PDFJ7DGA@mail.gmail.com>
 <c696f34a-46e6-23b8-b548-a00d66a101dc@openssl.org>
Message-ID: <E9455EB1-9F77-4114-9472-BFD53E2A55BE@ll.mit.edu>

On Oct 11, 2018, at 05:03, Matt Caswell <matt at openssl.org> wrote:
> On 11/10/18 09:47, Peter Magnusson wrote:
>> You would be better off with AES-CCM or such for your backup, that
>> gives you the integrity check.
>> i.e. you would be reasonably sure what you decrypt is encrypted with your key.
> 
> I'd just point out that CCM and other AEAD modes are not supported in
> the openssl enc app.

Yes, and many of us are eagerly waiting for this deficiency to be remedied! ;-)


>> Using CBC in anything new design does not make much sense.

This depends on the use case and the threat model.

>> - CBC is weak against oracle attacks (online interactions with a
>> decryption oracle)

Assuming decryption oracle is applicable in the given use case. Not everything is online, and not everything is a web service. ;-)

>> - CBC has no protection against modifications. If decryption succeeds,
>> you don't know if the resulting plaintext originated from

Which is why non-AE modes should be accompanied by MAC?ing the ciphertext. (Moxie Marlinspike?s principle ;) 

On the other hand, AEAD modes tend to fail catastrophically if key+nonce is reused. Unlike, e.g., CBC, which merely reveals that two cipher texts came from the same plaintext (?pick your poison"). 
Again, depends on the use case and the threat model. 



From Michael.Wojcik at microfocus.com  Thu Oct 11 12:42:30 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 11 Oct 2018 12:42:30 +0000
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <20181011031216.GA3589@straasha.imrryr.org>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
 <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
 <20181011031216.GA3589@straasha.imrryr.org>
Message-ID: <MWHPR18MB103797900CEEBC8D645FD3A1F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Wednesday, October 10, 2018 23:12
>
> On Thu, Oct 11, 2018 at 01:23:41AM +0000, Michael Wojcik wrote:
>
> > - Data recovery from an encrypted backup is tough. With CBC, one bit goes
> > astray and you've lost everything after that.
>
> No, a 1 bit error in CBC ciphertext breaks only the current block,
> and introduces a 1 bit error into the plaintext of the next block.
> After that, you're back in sync.

Right, right. Emailing at bedtime again... Still, this is trouble enough.

> But yes, indeed "openssl enc" offers little integrity protection.
> One should probably break the data into chunks and encrypt and MAC
> each chunk with the MAC covering the chunk sequence number, and
> whether it is the last chunk.

Clearly an improvement (and better than a single MAC over the entire message, for reasons we've discussed in the past on this list). But we're back to designing and implementing a cryptosystem, and that's fraught with dangers for non-experts (and for experts too, if we're honest).

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From Michael.Wojcik at microfocus.com  Thu Oct 11 12:42:31 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 11 Oct 2018 12:42:31 +0000
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <c696f34a-46e6-23b8-b548-a00d66a101dc@openssl.org>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
 <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
 <20181011031216.GA3589@straasha.imrryr.org>
 <CAJQZn8bRoHMYpFeC73mnYR6J72KpzrmJANfaZPLEw3dSQmkntQ@mail.gmail.com>
 <CANtcRX64RnFrhuv3ZxWErOcWHm_3iE63tWMUYkzEd_PDFJ7DGA@mail.gmail.com>
 <c696f34a-46e6-23b8-b548-a00d66a101dc@openssl.org>
Message-ID: <MWHPR18MB1037AC7420D63550100EE8AEF9E10@MWHPR18MB1037.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Matt Caswell
> Sent: Thursday, October 11, 2018 05:04
>
>
> On 11/10/18 09:47, Peter Magnusson wrote:
> > You would be better off with AES-CCM or such for your backup, that
> > gives you the integrity check.
> >  i.e. you would be reasonably sure what you decrypt is encrypted with your
> key.
>
> I'd just point out that CCM and other AEAD modes are not supported in
> the openssl enc app.

And even if they were, the AEAD modes are fragile (vulnerable to misuse). GCM of course is completely vulnerable to nonce reuse, which is why some people (e.g. Bernstein) disavow it completely. CCM is similarly vulnerable to key+counter reuse, so RFC 4309, for example, requires fresh keys for each encryption.

That was the main point of my original message: roll-your-own cryptosystems are a Bad Idea. I think providing advice like "use an AEAD mode" is bad, because it implies that crypto non-experts can safely create cryptosystems that avoid well-known pitfalls. History suggests otherwise.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From rsalz at akamai.com  Thu Oct 11 14:50:24 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 11 Oct 2018 14:50:24 +0000
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
Message-ID: <293F3555-8937-495E-B0C4-4EDC46F55468@akamai.com>

As with essentially all open source software, there is no warranty with OpenSSL.

Having said that, people use the OpenSSL applications for all sorts of things, including what you are doing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181011/b4fdf158/attachment.html>

From mythjill at gmail.com  Thu Oct 11 17:06:35 2018
From: mythjill at gmail.com (Dave Wang)
Date: Thu, 11 Oct 2018 10:06:35 -0700
Subject: [openssl-users] SSL_get_peer_certificate returns NULL in
 client_cert_cb after upgrade to openssl 1.1.1
In-Reply-To: <9eb95cdb-72c2-235d-f75a-f9c51982f14b@openssl.org>
References: <CAKvDEsXUxSPBqjvRS=mUD-6ir7fZarba=m6myNcOPe1cgu44iA@mail.gmail.com>
 <a64cdde7-38a4-645d-937b-cb7c1d729b1b@openssl.org>
 <9eb95cdb-72c2-235d-f75a-f9c51982f14b@openssl.org>
Message-ID: <CAKvDEsXDOXt+fZarewgcD8B10TyFpn05kG2oosOmEh4YQeyXjA@mail.gmail.com>

Hi Matt,

this make sense. As if I disable TLS1.3, the issue is gone. Thanks for your
help.

Regards,
Dave

On Thu, Oct 11, 2018 at 2:36 AM Matt Caswell <matt at openssl.org> wrote:

> I opened this issue to track this problem:
>
> https://github.com/openssl/openssl/issues/7384
>
> Matt
>
>
> On 11/10/18 10:25, Matt Caswell wrote:
> >
> >
> > On 10/10/18 23:04, Dave Wang wrote:
> >> Hi there,
> >>
> >> I have a client can talk with server, where the client certificate is
> >> loaded in client_cert_cb  based on matching the server side certificate.
> >>
> >> it works perfectly in openssl 1.1.0h, however it stops working after I
> >> upgrade to openssl 1.1.1.
> >>
> >> In client_cert_cb , when I call SSL_get_peer_certificate, it returns
> >> NULL, which is different from openssl 1.1.0h.
> >>
> >> I do set SSL_VERIFY_PEER on both sides.
> >>
> >>
> >> any thoughts on this?
> >
> > I assume this only happens with a TLSv1.3 handshake?
> >
> > From the documentation, the client_cert_cb is called: "when a client
> > certificate is requested by a server". In practice this means when we
> > have received the CertificateRequest message from the server.
> >
> > In TLSv1.2 (and below) the server's first flight of messages for a
> > client-auth full handshake in response to a ClientHello looks like this:
> >
> > ServerHello
> > Certificate
> > ServerKeyExchange
> > CertificateRequest
> > ServerHelloDone
> >
> > In TLSv1.3 it looks like this:
> >
> > ServerHello
> > EncryptedExtensions
> > CertificateRequest
> > Certificate
> > CertificateVerify
> > Finished
> >
> > Note that in TLSv1.2 the CertificateRequest message comes *after* the
> > server has sent the Certificate but in TLSv1.3 it comes *before*. That
> > means of course that in TLSv1.3 the client_cert_cb gets called before we
> > have processed the server's certificate and hence
> > SSL_get_peer_certificate() returns NULL.
> >
> > I'm wondering whether we should delay calling the client_cert_cb in
> > TLSv1.3 until after the CertificateVerify has been processed.
> >
> > 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/20181011/267cea72/attachment.html>

From dheinz at softwarekey.com  Thu Oct 11 20:56:30 2018
From: dheinz at softwarekey.com (Dan Heinz)
Date: Thu, 11 Oct 2018 20:56:30 +0000
Subject: [openssl-users] Manual Shutdown of OpenSSL 1.1.x library
In-Reply-To: <DM5PR1301MB2218621BD04FE9C3A0847C51C5E10@DM5PR1301MB2218.namprd13.prod.outlook.com>
References: <DM5PR1301MB2218621BD04FE9C3A0847C51C5E10@DM5PR1301MB2218.namprd13.prod.outlook.com>
Message-ID: <CY1PR0601MB1577BBD221BFDBB947A5ACA9D9E10@CY1PR0601MB1577.namprd06.prod.outlook.com>

Is there currently a way to manually shutdown the OpenSSL library?



We have a DLL that statically links OpenSSL.  Our DLL gets loaded and unloaded multiple times by a process (not our process), and we need to release OpenSSL each time.  This was not possible with OpenSSL 1.1 as of September 2017 as the process's atexit is where it gets released which will not be called after a FreeLibrary() call on our DLL.  Has this been revisited?  If there now a way to manually release OpenSSL, or are there any plans to add this ability?



Here is a link to our original post and discussion from January 2017:

https://www.mail-archive.com/openssl-users at openssl.org/msg80781.html



>From the previous post, something like this would address the issue: "I'm wondering whether an option to override the default behavior might be possible, e.g. an explicit call to OPENSSL_init_crypto() with something like an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The application would then have to call OPENSSL_cleanup() explicitly."


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

From doctor at doctor.nl2k.ab.ca  Thu Oct 11 22:51:03 2018
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Thu, 11 Oct 2018 16:51:03 -0600
Subject: [openssl-users] Openssl 1.1. compliant apps
Message-ID: <20181011225103.GA70699@doctor.nl2k.ab.ca>

Looks like

bind9

Exim

Inn

apache

POstgresql

and openssh > 7.8

Are all compliant.


What about

Dovecot

php 

?


MySQL / Mariadb / Percona

are not yet.

Any full lists?

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on Atheism
Love much. Earth has enough of bitter in it.  -Ella Wheeler Wilcox

From dclarke at blastwave.org  Fri Oct 12 01:19:52 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Thu, 11 Oct 2018 21:19:52 -0400
Subject: [openssl-users] Openssl 1.1. compliant apps
In-Reply-To: <20181011225103.GA70699@doctor.nl2k.ab.ca>
References: <20181011225103.GA70699@doctor.nl2k.ab.ca>
Message-ID: <a7630a6b-0381-803c-9fa3-71de7265e5f3@blastwave.org>

On 10/11/2018 06:51 PM, The Doctor wrote:
> Looks like

> 
> apache
> 

There is still considerable discussion in the httpd mailists on the
  topic.  Don't be so certain.

Dennis


From jb-openssl at wisemo.com  Fri Oct 12 02:31:43 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 12 Oct 2018 04:31:43 +0200
Subject: [openssl-users] openssl commandline client use
In-Reply-To: <CAJQZn8bRoHMYpFeC73mnYR6J72KpzrmJANfaZPLEw3dSQmkntQ@mail.gmail.com>
References: <CAJQZn8YXPUtA4cp+oGmWn9kpa=roUHVzpA6=ksiSXoOeEpA7Xg@mail.gmail.com>
 <MWHPR18MB1037B01082E920CCDC38C609F9E10@MWHPR18MB1037.namprd18.prod.outlook.com>
 <20181011031216.GA3589@straasha.imrryr.org>
 <CAJQZn8bRoHMYpFeC73mnYR6J72KpzrmJANfaZPLEw3dSQmkntQ@mail.gmail.com>
Message-ID: <07d605e3-11c0-09d6-acdd-20187a42a7f0@wisemo.com>

On 11/10/2018 06:44, Paul Chubb wrote:
> Hi thanks for the responses. I try not to do crypto for the very 
> reasons you raise - i simply don't know enough and your (good) pointed 
> questions have demonstrated that.
>
> ?Context:
>
> We are trying for GDPR and other privacy law compliance. We probably 
> need to meet GDPR, US requirements, Australian requirements, Japanese 
> requirements and UK requirements. The data is not hugely critical. It 
> contains names and exercise metrics. It doesn't contain credit card 
> details or anything above the level of names. I don't think it 
> contains addresses but probably does contain names of recognizable 
> organisations which could provide a tuple for identification purposes 
> if the data was compromised.
>
> A mysqldump of the db in production at present is around 170Gb however 
> that is text based and we are using a binary solution based on percola 
> xtrabackup so the final size should be smaller for the current time. 
> The documentation on this by the backup software provider is very 
> simplistic and simply pipes the stream of data through openssl and 
> then gzip:
>
> mariabackup --user=root --backup --stream=xbstream | gzip | openssl  enc -aes-256-cbc -k mypass > backup.xb.gz.enc
> There are thousands of posts that do similar and in non-crypto circles 
> it is the accepted way of doing things. That was my starting point.
>
> I am? not using a password but generating keys. The symetric key is 
> generated by "openssl rand -hex 32" which I have read is suitable. The 
> Nonce or IV is generated? by "openssl rand -hex 16". These values are 
> used once and then kept for decryption of that file. They in turn are 
> encrypted before storing - see below.
>
> The two keys are held in ram while the backup occurs. They are applied 
> to openssl using the -K and -iv switches. They are then written out to 
> disk. encrypted with a list of public RSA keys and the original 
> deleted from disk. I then package it all up and delete the intervening 
> encrypted files leaving me with an archive with the encrypted backup 
> and several copies of the nonce and key each encrypted by different 
> people's public keys.
>
> The backup regime has not been decided as yet. I expect it will be 
> something like a full backup per week and then either incrementals or 
> differentials on the other days. I expect that the fulls will be kept 
> for 30 days and the deltas for 14days. The database backups will sit 
> on a secured server disk which in turn will be backed up by the 
> hosting provider with whatever process and rotation they use.
>
> I would expect that headers in the backup stream would be predictable, 
> whether they provide a good enough attack surface I don't know. In 
> addition the clients of course know their data that may also provide 
> an attack surface. Finally I have included an encrypted file with a 
> known plain text phrase. Based on your comments, this will probably 
> not get into production but provides an easy way for testing and 
> debugging to check that things are encrypted or not.
>
> The kind of statements that prompted my question was: 
> https://security.stackexchange.com/questions/182277/is-openssl-aes-256-cbc-encryption-safe-for-offsite-backup 
> whose comments suggest that openssl should never be used for 
> production purposes.Their suggestion was GnuPG which isn't suitable 
> for this purpose because it does password/key management that assumes 
> a desktop/laptop environment and manual process. I also looked at 
> ccrypt and mcrypt but then went back to openssl.
>
> Cheers Paul
>
>
>
>
>
>
> On Thu, Oct 11, 2018 at 2:12 PM Viktor Dukhovni 
> <openssl-users at dukhovni.org <mailto:openssl-users at dukhovni.org>> wrote:
>
>     On Thu, Oct 11, 2018 at 01:23:41AM +0000, Michael Wojcik wrote:
>
>     > - Data recovery from an encrypted backup is tough. With CBC, one
>     bit goes
>     > astray and you've lost everything after that.
>
>     No, a 1 bit error in CBC ciphertext breaks only the current block,
>     and introduces a 1 bit error into the plaintext of the next block.
>     After that, you're back in sync.
>
>     But yes, indeed "openssl enc" offers little integrity protection.
>     One should probably break the data into chunks and encrypt and MAC
>     each chunk with the MAC covering the chunk sequence number, and
>     whether it is the last chunk.
>

I have not tested it with your huge data sizes, but I have had a lot of
success with the following pipeline which avoids a number of security
pitfalls by using higher levelOpenSSL commandline features:

BackupCmd | \
 ? openssl smime -sign -binary -nodetach -signer SomeDir/mycert.pem \
 ??? -inkey SomeDir/mycert.key -outform DER | \
 ? gzip -n -9 | \
 ? openssl smime -encrypt -binary -out backup.enc -outform DER -aes256 \
SomeDir/restorecert.pem

Where mycert.pem is a certificate issued to the system being backed up
by an internal company CA (also used for intranet https servers) and
restorecert.pem is another such certificate where the private key is
available only to restore procedures.

A feature of this pipeline is that backups can be reencrypted with a
different key / mechanism without ruining the integrity signature, and
can also be recompressed with a better compression algorithm in the same
way.

Another feature is that the server being backed up does not need to know
the decryption key (restorecert.key), while the server doing restores or
backup verifications does not need to know the integrity signing key
(mycert.key).

Dealing with the risk of not being able to decrypt a corrupted backup is
handled by having more than one backup, just like the risk of completely
loosing a backup (fire, flood, ...).

Special note: Because the openssl smime (and openssl cms) signature
verify commands do not have an option to verify signatures as of some
past date (such as the date a backup was made) my restore scripts have
to run openssl under the "faketime" utility to make openssl think it is
being run on the day the backup was made.

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  Fri Oct 12 07:45:10 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 12 Oct 2018 08:45:10 +0100
Subject: [openssl-users] Manual Shutdown of OpenSSL 1.1.x library
In-Reply-To: <CY1PR0601MB1577BBD221BFDBB947A5ACA9D9E10@CY1PR0601MB1577.namprd06.prod.outlook.com>
References: <DM5PR1301MB2218621BD04FE9C3A0847C51C5E10@DM5PR1301MB2218.namprd13.prod.outlook.com>
 <CY1PR0601MB1577BBD221BFDBB947A5ACA9D9E10@CY1PR0601MB1577.namprd06.prod.outlook.com>
Message-ID: <4beefcf3-9fe5-8717-5b53-817e0a35b153@openssl.org>



On 11/10/18 21:56, Dan Heinz wrote:
> Is there currently a way to manually shutdown the OpenSSL library?
> 
> 
> 
> We have a DLL that statically links OpenSSL.  Our DLL gets loaded and
> unloaded multiple times by a process (not our process), and we need
> to release OpenSSL each time.  This was not possible with OpenSSL 1.1
> as of September 2017 as the process's atexit is where it gets
> released which will not be called after a FreeLibrary() call on our
> DLL.  Has this been revisited?  If there now a way to manually
> release OpenSSL, or are there any plans to add this ability?
> 
> 
> 
> Here is a link to our original post and discussion from January
> 2017:
> 
> https://www.mail-archive.com/openssl-users at openssl.org/msg80781.html
> 
> 
> 
> From the previous post, something like this would address the issue:
> "I'm wondering whether an option to override the default behavior
> might be possible, e.g. an explicit call to OPENSSL_init_crypto()
> with something like an OPENSSL_INIT_NO_ATEXIT_CLEANUP option. The
> application would then have to call OPENSSL_cleanup() explicitly."

No such option exists for currently supported OpenSSL versions. It could
be added to a future version fairly simply:

https://github.com/openssl/openssl/pull/7388

Matt


From mann.patidar at gmail.com  Mon Oct 15 09:04:15 2018
From: mann.patidar at gmail.com (Manish Patidar)
Date: Mon, 15 Oct 2018 14:34:15 +0530
Subject: [openssl-users] Fips lib usage in Openssl 1.1.1
Message-ID: <CAN6ajHKRR9_XLBZMvx=TJWZJ1Oga6q4_dvvc_C782VMxODLQZA@mail.gmail.com>

Hi

I want to use fips certify crypto libs. Is it possible to use crypto lib
from  Openssl-fips 2.0.16 and  ssl lib from Openssl1.1.1?
If yes, how we can use, pleas provide details?

Regards
Manish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181015/13158286/attachment.html>

From rsalz at akamai.com  Mon Oct 15 12:22:24 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 15 Oct 2018 12:22:24 +0000
Subject: [openssl-users] Fips lib usage in Openssl 1.1.1
In-Reply-To: <CAN6ajHKRR9_XLBZMvx=TJWZJ1Oga6q4_dvvc_C782VMxODLQZA@mail.gmail.com>
References: <CAN6ajHKRR9_XLBZMvx=TJWZJ1Oga6q4_dvvc_C782VMxODLQZA@mail.gmail.com>
Message-ID: <941BA08F-967B-4309-ADF2-DD1441B08049@akamai.com>

  *   I want to use fips certify crypto libs. Is it possible to use crypto lib from  Openssl-fips 2.0.16 and  ssl lib from Openssl1.1.1?

No, it is not possible.  The current FIPS code only works with 1.0.2.  The project is working on a new FIPS module.  You can find some details at the blog, https://www.openssl.org/blog/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181015/75282810/attachment-0001.html>

From blaufish.public.email at gmail.com  Mon Oct 15 15:40:10 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Mon, 15 Oct 2018 17:40:10 +0200
Subject: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too
 large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
Message-ID: <CANtcRX5HjxVyVCuwcMhmcetJcRFaJXjaMC+tehrDU_hVNgGmTQ@mail.gmail.com>

Hi,

I'm trying to understand how to make "openssl ca" prompt for a PKCS#11
login pin. Version is openssl-1.1.1.

openssl req works as I would expect, prompting for PIN:

YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
local-build/bin/openssl \
 req -config yubihsm2-openssl.conf -new \
 -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out
certs.dir/ca.csr.pem
engine "pkcs11" set.
Enter PKCS#11 token PIN for YubiHSM:

openssl ca I fail to get working, no prompt presented, tried adding
-passin stdin but that has no effect.

YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
 local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform
engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \
 -config yubihsm2-openssl.conf \
 -days 3650 -extensions vpn_server_cert \
 -out server.cert.pem \
 -infiles ../server/certs.dir/server.csr.pem
engine "pkcs11" set.
Using configuration from yubihsm2-openssl.conf
Login failed
Login to token failed, returning NULL...
PKCS11_get_private_key returned NULL
cannot load CA private key from engine
140735853761408:error:28078064:UI routines:UI_set_result_ex:result too
large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid
arguments:p11_slot.c:240:
140735853761408:error:26096080:engine
routines:ENGINE_load_private_key:failed loading private
key:crypto/engine/eng_pkey.c:78:
unable to load CA private key

Best Regards
//P

From carl at five-ten-sg.com  Mon Oct 15 17:42:26 2018
From: carl at five-ten-sg.com (Carl Byington)
Date: Mon, 15 Oct 2018 10:42:26 -0700
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
Message-ID: <1539625346.18482.5.camel@ns.five-ten-sg.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I have a build of sendmail with openssl 1.1.1. It can deliver to
localhost via tls1.3, but nowhere else.

STARTTLS=client, error: connect failed=-1, reason=internal error,
SSL_error=1, errno=0, retry=-1

STARTTLS=client: error:14228044:SSL routines:construct_ca_names:internal
error:ssl/statem/statem_lib.c
:2289:

It works correctly if I disable tls1.3 via:

O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1_3
+SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1_3

Is this another symptom of
https://github.com/openssl/openssl/issues/7384, or is there something
else going on here?


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlvE0V8ACgkQL6j7milTFsGFgACfRH9BudLTi8hPCN12nv18TW4S
MTcAmwRNdzY/tMwskbmJx1bm81cNndDN
=HnJ/
-----END PGP SIGNATURE-----



From openssl-users at dukhovni.org  Mon Oct 15 19:32:56 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 15 Oct 2018 15:32:56 -0400
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <1539625346.18482.5.camel@ns.five-ten-sg.com>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
Message-ID: <20181015193256.GC983@straasha.imrryr.org>

On Mon, Oct 15, 2018 at 10:42:26AM -0700, Carl Byington wrote:

> I have a build of sendmail with openssl 1.1.1. It can deliver to
> localhost via tls1.3, but nowhere else.
> 
> STARTTLS=client, error: connect failed=-1, reason=internal error,
> SSL_error=1, errno=0, retry=-1
> 
> STARTTLS=client: error:14228044:SSL routines:construct_ca_names:internal error:ssl/statem/statem_lib.c:2289:

This fails when the list of acceptable CAs sent to the peer contains
a NULL name or the ASN.1 encoding routines fail, or memory is not
available to encode the name into the output packet.

    if (ca_sk != NULL) {
        int i;

        for (i = 0; i < sk_X509_NAME_num(ca_sk); i++) {
            unsigned char *namebytes;
            X509_NAME *name = sk_X509_NAME_value(ca_sk, i);
            int namelen;

            if (name == NULL
                    || (namelen = i2d_X509_NAME(name, NULL)) < 0
                    || !WPACKET_sub_allocate_bytes_u16(pkt, namelen,
                                                       &namebytes)
                    || i2d_X509_NAME(name, &namebytes) != namelen) {
                SSLfatal(s, SSL_AD_INTERNAL_ERROR, SSL_F_CONSTRUCT_CA_NAMES,
                         ERR_R_INTERNAL_ERROR);
                return 0;
            }
        }
    }

> It works correctly if I disable tls1.3 via:
> 
> O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1_3 +SSL_OP_CIPHER_SERVER_PREFERENCE
> O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3 +SSL_OP_NO_TLSv1_3

Unlike TLS 1.2, in TLS 1.3 the client MAY send a list of acceptable
certificate authorities to the server as an extension in its client
HELLO: https://tools.ietf.org/html/rfc8446#section-4.2.4

Perhaps Sendmail is setting the CA names the client side, and then
OpenSSL is trying to serialize the names of all your CAs to the
server.  This is a bad idea.  Don't do that.  Try using CApath, and
no or an explicitly empty CAfile, and see if that helps.

> Is this another symptom of
> https://github.com/openssl/openssl/issues/7384, or is there something
> else going on here?

No something else.  A pointer to source code of the Sendmail in
question may be helpful.  Do you see any calls to SSL_CTX_set0_CA_list()?

I guess Sendmail being both a client and server in one, may be using
a single SSL context for both purposes, and may therefore end up
configuring the CA list for both.

If you use an empty CA file, Sendmail will probably not leak all
your trusted CA names with every connection, and be more reliable
as well.

I suspect some sort of Sendmail-specific misuse of the API, but
it is also possible that use of CA names on the client side is
not sufficiently well tested on the OpenSSL side.

-- 
	Viktor.

From selva.nair at gmail.com  Mon Oct 15 20:12:43 2018
From: selva.nair at gmail.com (Selva Nair)
Date: Mon, 15 Oct 2018 16:12:43 -0400
Subject: [openssl-users] overriding EVP_PKEY method callbacks for a specific
	key only
Message-ID: <CAKuzo_g=e36P8GEKBNa_1+VO8udUXY97ysL+mW3vRDX3-mWoGg@mail.gmail.com>

 Hi,

How to override the evp_pkey_sign method in EVP_PKEY_METHOD structure for a
specific key? This is to allow signing with PSS padding using Windows CNG
API.  Using rsa_priv_enc() we can only get pre-padded data when PSS is in
use, but CNG does not seem to handle padding = none.

Also see issue 7341 on github https://github.com/openssl/openssl/issues/7341

I can use EVP_PKEY_meth_add0() to add a new method struct and that works.
But that affect all keys. Is it possible to replace the evp_pkey_sign
method on a specific key instance like one can do for RSA or EC methods?

Thanks,

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

From beldmit at gmail.com  Mon Oct 15 20:18:45 2018
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 15 Oct 2018 23:18:45 +0300
Subject: [openssl-users] overriding EVP_PKEY method callbacks for a
 specific key only
In-Reply-To: <CAKuzo_g=e36P8GEKBNa_1+VO8udUXY97ysL+mW3vRDX3-mWoGg@mail.gmail.com>
References: <CAKuzo_g=e36P8GEKBNa_1+VO8udUXY97ysL+mW3vRDX3-mWoGg@mail.gmail.com>
Message-ID: <CADqLbzJR-6waU1gd=F6MUA1YK4SQfbVDWemQEXBSQ6hazZt-nw@mail.gmail.com>

Well, you can use opaque pointer and own structure containing a flag and
switch between native and custom implementations depending on it.

I've tried it and it works

??, 15 ???. 2018 ?., 23:13 Selva Nair <selva.nair at gmail.com>:

> Hi,
>
> How to override the evp_pkey_sign method in EVP_PKEY_METHOD structure for
> a specific key? This is to allow signing with PSS padding using Windows CNG
> API.  Using rsa_priv_enc() we can only get pre-padded data when PSS is in
> use, but CNG does not seem to handle padding = none.
>
> Also see issue 7341 on github
> https://github.com/openssl/openssl/issues/7341
>
> I can use EVP_PKEY_meth_add0() to add a new method struct and that works.
> But that affect all keys. Is it possible to replace the evp_pkey_sign
> method on a specific key instance like one can do for RSA or EC methods?
>
> Thanks,
>
> Selva
> --
> 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/20181015/7943d2ed/attachment.html>

From selva.nair at gmail.com  Mon Oct 15 21:09:50 2018
From: selva.nair at gmail.com (Selva Nair)
Date: Mon, 15 Oct 2018 17:09:50 -0400
Subject: [openssl-users] overriding EVP_PKEY method callbacks for a
 specific key only
In-Reply-To: <CADqLbzJR-6waU1gd=F6MUA1YK4SQfbVDWemQEXBSQ6hazZt-nw@mail.gmail.com>
References: <CAKuzo_g=e36P8GEKBNa_1+VO8udUXY97ysL+mW3vRDX3-mWoGg@mail.gmail.com>
 <CADqLbzJR-6waU1gd=F6MUA1YK4SQfbVDWemQEXBSQ6hazZt-nw@mail.gmail.com>
Message-ID: <CAKuzo_if41EndGoszM4dZpW3rZqcHj9Rw-ar0to+2u7iUXWNng@mail.gmail.com>

Hi,

On Mon, Oct 15, 2018 at 4:19 PM Dmitry Belyavsky <beldmit at gmail.com> wrote:

> Well, you can use opaque pointer and own structure containing a flag and
> switch between native and custom implementations depending on it.
>
> I've tried it and it works
>

We do store some state information in the method app_data, so singling out
calls for our key is not hard. So, it would be necessary to check this in
both sign_init() and sign() and call the default implementations of both
as/when required, right? Will test it out.

Is there any plan to expose per-key EVP_PKEY_METHODs in the API?

Thanks,

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

From carl at five-ten-sg.com  Mon Oct 15 23:49:39 2018
From: carl at five-ten-sg.com (Carl Byington)
Date: Mon, 15 Oct 2018 16:49:39 -0700
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <20181015193256.GC983@straasha.imrryr.org>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
Message-ID: <1539647379.18482.38.camel@ns.five-ten-sg.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


> Perhaps Sendmail is setting the CA names the client side, and then
> OpenSSL is trying to serialize the names of all your CAs to the
> server.  This is a bad idea.  Don't do that.  Try using CApath, and
> no or an explicitly empty CAfile, and see if that helps.

Do you mean CACertFile and CACertPath? Redhat/Centos stock
sendmail.mc/cf uses:

O CACertFile=/etc/pki/tls/certs/ca-bundle.crt
O CACertPath=/etc/pki/tls/certs

pointing the CACertFile to 750KB file with 149 certificates. That just
seems wrong, but perhaps there is some reason for it. If CACertFile is
not specified, sendmail won't advertise STARTTLS. So we need to give it
something there, and the docs imply that it should at least contain the
certificate of the CA that signed the sendmail certificate. I have a
private CA that signed my sendmail certificate, so using:

O CACertFile=/etc/pki/tls/certs/my-ca-certificate.pem
O CACertPath=/etc/pki/tls/certs
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
+SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

on both the client and server sendmail machines, we get TLSv1.3 !

Perhaps some certificate in the stock ca-bundle.crt is malformed?


> No something else.  A pointer to source code of the Sendmail in
> question may be helpful.

http://www.five-ten-sg.com/mapper/blog/DANE

ftp://ftp.sendmail.org/pub/sendmail/snapshots/sendmail.8.16.0.29.tar.gz

http://www.five-ten-sg.com/util/sendmail-8.16.0-dane.patch




> Do you see any calls to SSL_CTX_set0_CA_list()?

No, but there is a call to  SSL_CTX_set_client_CA_list(*ctx,
SSL_load_client_CA_file(cacertfile)) which would read that ca-bundle.crt
file.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlvFJ38ACgkQL6j7milTFsH3wwCeNh0ZAOIRq4kG/Nh5gCeZaAvK
MPUAn0a7NaSk5edTMGcLa0SHpskOxTYW
=Yi1x
-----END PGP SIGNATURE-----



From ca+ssl-users at esmtp.org  Mon Oct 15 23:57:51 2018
From: ca+ssl-users at esmtp.org (Claus Assmann)
Date: Mon, 15 Oct 2018 16:57:51 -0700
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <1539647379.18482.38.camel@ns.five-ten-sg.com>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
 <1539647379.18482.38.camel@ns.five-ten-sg.com>
Message-ID: <20181015235751.GA1828@x2.esmtp.org>

On Mon, Oct 15, 2018, Carl Byington wrote:

> O CACertFile=/etc/pki/tls/certs/ca-bundle.crt

> pointing the CACertFile to 750KB file with 149 certificates. That just
> seems wrong, but perhaps there is some reason for it. If CACertFile is

sendmail: op.*:
         However, do not list too many root CAs in that
         file, otherwise the TLS handshake may fail; e.g.,

Please tell whoever is responsible for that default to fix it.
The certs should be in CACertPath if at all.

From openssl-users at dukhovni.org  Tue Oct 16 01:22:58 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 15 Oct 2018 21:22:58 -0400
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <1539647379.18482.38.camel@ns.five-ten-sg.com>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
 <1539647379.18482.38.camel@ns.five-ten-sg.com>
Message-ID: <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org>



> On Oct 15, 2018, at 7:49 PM, Carl Byington <carl at five-ten-sg.com> wrote:
> 
>> Perhaps Sendmail is setting the CA names the client side, and then
>> OpenSSL is trying to serialize the names of all your CAs to the
>> server.  This is a bad idea.  Don't do that.  Try using CApath, and
>> no or an explicitly empty CAfile, and see if that helps.
> 
> Do you mean CACertFile and CACertPath? Redhat/Centos stock
> sendmail.mc/cf uses:
> 
> O CACertFile=/etc/pki/tls/certs/ca-bundle.crt
> O CACertPath=/etc/pki/tls/certs

Yes, these.  It is common practice with TLS servers to use the CAfile
(in Sendmail aka CACertFile) as the source of CA names to send to clients
in certificate requests (when those are enabled).  Most MTAs don't request
client certificates, so this "overloading" of the parameter is mostly
harmless.  Still, in Postfix the documentation recommends keeping the
CAfile short (or even not specified at all), and having any CA cerficates
used for validating client certs be specified via CApath.  CApath is used
for indexed lookup and not enumeration.

With TLS 1.3, you suddenly have clients optionally soliciting certificates
by specific CA from servers, and if you use the same SSL_CTX for both the
client and server roles, the same CA list will be sent to remote servers
that you'd use to solicit certificates from clients.

My advice is to make sure that the CAfile is mercifully short or not
set at all (assuming that's possible in Sendmail without disabling TLS).

> pointing the CACertFile to 750KB file with 149 certificates.

With 149 certs, and typical CA names O(80) bytes, we're looking at
~12KB of cert names, which should fit into an extension that can be
up to 64KB in size.  So overflowing the extension size limit would
not be my first guess.  If you make the CA bundle available (send
it to me off-list?) I can take a closer look.

> I have a
> private CA that signed my sendmail certificate, so using:
> 
> O CACertFile=/etc/pki/tls/certs/my-ca-certificate.pem
> O CACertPath=/etc/pki/tls/certs
> O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
> +SSL_OP_CIPHER_SERVER_PREFERENCE
> O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
> 
> on both the client and server sendmail machines, we get TLSv1.3 !

So the there's something toxic about the CA list as a whole.
Either indeed some problem certiificate, or a problem encoding
the lot of them?

>> Do you see any calls to SSL_CTX_set0_CA_list()?
> 
> No, but there is a call to  SSL_CTX_set_client_CA_list(*ctx,
> SSL_load_client_CA_file(cacertfile)) which would read that ca-bundle.crt
> file.

Right, but I think that the underlying list is the same for client->server
as for server->client.  So this has the unfortunate effect of making
the client fill its HELLO message with an enormous list of CA names.

A separate SSL_CTX for the client would make Sendmail less prone to
such mishaps.  Try Postfix some time, we don't have that issue... :-)

-- 
	Viktor.


From carl at five-ten-sg.com  Tue Oct 16 03:23:00 2018
From: carl at five-ten-sg.com (Carl Byington)
Date: Mon, 15 Oct 2018 20:23:00 -0700
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <20181015235751.GA1828@x2.esmtp.org>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
 <1539647379.18482.38.camel@ns.five-ten-sg.com>
 <20181015235751.GA1828@x2.esmtp.org>
Message-ID: <1539660180.18482.49.camel@ns.five-ten-sg.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, 2018-10-15 at 16:57 -0700, Claus Assmann wrote:
> Please tell whoever is responsible for that default to fix it.

I will do that.

> The certs should be in CACertPath if at all.

Nothing to do with openssl, but for sendmail, suppose we have

O CACertFile=/etc/pki/tls/certs/one-ca-certificate.pem
O CACertPath=/etc/pki/tls/certs
O ServerCertFile=/etc/pki/tls/certs/sendmail.pem

where one-ca-certificate.pem is the certificate of the CA that signed
the sendmail.pem certificate, and /etc/pki/tls/certs/ca-bundle.crt
contains many CA certificates that we want to use for certificate
validation.

https://www.sendmail.org/~ca/email/starttls.html

I presume that means we need to split this ca-bundle.crt into 150
separate files, and compute hashes for each, with another 150 symbolic
links. Is that true, or am I missing some shortcut?



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEAREKAAYFAlvFWT8ACgkQL6j7milTFsHnswCdElJTGjCGao0n4xWqWB2nb2Bn
HyUAnj17PT/b/x26P4WGGD4TTq6Mjvuc
=O8T0
-----END PGP SIGNATURE-----



From openssl-users at dukhovni.org  Tue Oct 16 04:19:59 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 16 Oct 2018 00:19:59 -0400
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
 <1539647379.18482.38.camel@ns.five-ten-sg.com>
 <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org>
Message-ID: <AD926CFE-9AF2-452D-A58F-CCDAC0097AEA@dukhovni.org>



> On Oct 15, 2018, at 9:22 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
>> pointing the CACertFile to 750KB file with 149 certificates.
> 
> With 149 certs, and typical CA names O(80) bytes, we're looking at
> ~12KB of cert names, which should fit into an extension that can be
> up to 64KB in size.  So overflowing the extension size limit would
> not be my first guess.  If you make the CA bundle available (send
> it to me off-list?) I can take a closer look.

[ Carl sent me the CA bundle off-list ]  With the provided CA bundle
I was able to easily reproduce the same symptoms with:

 $ openssl s_client -requestCAfile bundle.pem -connect localhost:12345

Running this under a debugger the failure happens at certificate #143
because the client hello packet overflows its maximum allocation:

$6 = {
  buf = 0x0000000100724200
  staticbuf = 0x0000000000000000 <no value available>
  curr = 16364
  written = 16364
  maxsize = 16384
  subs = 0x0000000100727700
}

So even though the extension is allowed to be up to 2^16 bytes, it
seems the client HELLO is expected to fit into a single TLS record
of at most 16K bytes.

Given enough crud in the CA bundle, and a client misconfigured to
to spill its guts to the server, by sending the names of all the
trusted CAs, the limit is not too hard to exceed.

The work-around is to send *zero* CA names to the server, Sendmail
SHOULD NOT configure the SSL_CTX for the client connection to with
preferred CA names.  If that is not configurable, then keep the
CA file as short as possible, empty if possible, else just one
root CA, and everything else in CApath (yes "hashed" with the
various symlinks in place to each cert, one per file).

As for the 16K limit, and whether we should be sending client
CA names without further indication from the (TLS 1.3) client
to do so, I'm hoping Matt Caswell and or other team members
will chime in.

-- 
	Viktor.


From jb-openssl at wisemo.com  Tue Oct 16 06:13:11 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 16 Oct 2018 08:13:11 +0200
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <AD926CFE-9AF2-452D-A58F-CCDAC0097AEA@dukhovni.org>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
 <1539647379.18482.38.camel@ns.five-ten-sg.com>
 <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org>
 <AD926CFE-9AF2-452D-A58F-CCDAC0097AEA@dukhovni.org>
Message-ID: <0aa5a80f-bf84-6d75-f22d-bddee76e9a40@wisemo.com>

On 16/10/2018 06:19, Viktor Dukhovni wrote:
>> On Oct 15, 2018, at 9:22 PM, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
>>
>>> pointing the CACertFile to 750KB file with 149 certificates.
>> With 149 certs, and typical CA names O(80) bytes, we're looking at
>> ~12KB of cert names, which should fit into an extension that can be
>> up to 64KB in size.  So overflowing the extension size limit would
>> not be my first guess.  If you make the CA bundle available (send
>> it to me off-list?) I can take a closer look.
> [ Carl sent me the CA bundle off-list ]  With the provided CA bundle
> I was able to easily reproduce the same symptoms with:
>
>   $ openssl s_client -requestCAfile bundle.pem -connect localhost:12345
>
> Running this under a debugger the failure happens at certificate #143
> because the client hello packet overflows its maximum allocation:
>
> $6 = {
>    buf = 0x0000000100724200
>    staticbuf = 0x0000000000000000 <no value available>
>    curr = 16364
>    written = 16364
>    maxsize = 16384
>    subs = 0x0000000100727700
> }
>
> So even though the extension is allowed to be up to 2^16 bytes, it
> seems the client HELLO is expected to fit into a single TLS record
> of at most 16K bytes.
>
> Given enough crud in the CA bundle, and a client misconfigured to
> to spill its guts to the server, by sending the names of all the
> trusted CAs, the limit is not too hard to exceed.
>
> The work-around is to send *zero* CA names to the server, Sendmail
> SHOULD NOT configure the SSL_CTX for the client connection to with
> preferred CA names.  If that is not configurable, then keep the
> CA file as short as possible, empty if possible, else just one
> root CA, and everything else in CApath (yes "hashed" with the
> various symlinks in place to each cert, one per file).
>
> As for the 16K limit, and whether we should be sending client
> CA names without further indication from the (TLS 1.3) client
> to do so, I'm hoping Matt Caswell and or other team members
> will chime in.
>
Just for clarity, how is an OpenSSL 1.1.1 client supposed to tell
the local validation code which CAs to trust, especially if loading
the list before entering a chroot jail?

How is this different from the OpenSSL 1.0.x API?

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  Tue Oct 16 07:27:18 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 16 Oct 2018 03:27:18 -0400
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <0aa5a80f-bf84-6d75-f22d-bddee76e9a40@wisemo.com>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
 <1539647379.18482.38.camel@ns.five-ten-sg.com>
 <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org>
 <AD926CFE-9AF2-452D-A58F-CCDAC0097AEA@dukhovni.org>
 <0aa5a80f-bf84-6d75-f22d-bddee76e9a40@wisemo.com>
Message-ID: <20181016072718.GE983@straasha.imrryr.org>

On Tue, Oct 16, 2018 at 08:13:11AM +0200, Jakob Bohm via openssl-users wrote:

> > As for the 16K limit, and whether we should be sending client
> > CA names without further indication from the (TLS 1.3) client
> > to do so, I'm hoping Matt Caswell and or other team members
> > will chime in.
>
> Just for clarity, how is an OpenSSL 1.1.1 client supposed to tell
> the local validation code which CAs to trust, especially if loading
> the list before entering a chroot jail?

Loading CA files is not a problem in itself, the issue is that some
(typically server) applications overload the CAfile as also being
the source of CA hints to clients in certificate requests.  This
creates bloated server certificate request messages.  With TLS 1.3,
this is further compounded in applications that are *both* a server
and client, and use the *same* context for both purposes.  Once
that happens, the CA hints are used in both directions.

> How is this different from the OpenSSL 1.0.x API?

The API is identical, what's different is that TLS 1.3 makes the
CA hints bidirectional, given such hints have never been useful
before, it is IMHO just needless generality that's counter-productive.
Perhaps OpenSSL should require an additional non-default configuration
to enable transmission of the client's CA DNs to the server.

Or perhaps separate the server->client and client->server CA name
lists in the SSL context, so that setting one does not (surprise!)
also set the other.  Overloading the same setting for both directions
may not have anticipated bidirectional use of contexts.

Someone should perhaps open an issue to track whether anything needs
to change here beyond advice to users, and if so what.

-- 
	Viktor.

From blaufish.public.email at gmail.com  Tue Oct 16 07:54:08 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Tue, 16 Oct 2018 09:54:08 +0200
Subject: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too
 large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
In-Reply-To: <CANtcRX5HjxVyVCuwcMhmcetJcRFaJXjaMC+tehrDU_hVNgGmTQ@mail.gmail.com>
References: <CANtcRX5HjxVyVCuwcMhmcetJcRFaJXjaMC+tehrDU_hVNgGmTQ@mail.gmail.com>
Message-ID: <CANtcRX50e0bEwbG=U7L5bKif1StaEEny-01Bq7OfoO0xFvFC9Q@mail.gmail.com>

The error can be workaround by entering PIN = "..." into [pkcs11_section].
pkcs11 engine version is libp11-0.4.9.
Anyone know if this a 1) libp11 issue or 2) openssl issue or 3) me
doing something wrong?
On Mon, Oct 15, 2018 at 5:40 PM Peter Magnusson
<blaufish.public.email at gmail.com> wrote:
>
> Hi,
>
> I'm trying to understand how to make "openssl ca" prompt for a PKCS#11
> login pin. Version is openssl-1.1.1.
>
> openssl req works as I would expect, prompting for PIN:
>
> YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
> local-build/bin/openssl \
>  req -config yubihsm2-openssl.conf -new \
>  -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out
> certs.dir/ca.csr.pem
> engine "pkcs11" set.
> Enter PKCS#11 token PIN for YubiHSM:
>
> openssl ca I fail to get working, no prompt presented, tried adding
> -passin stdin but that has no effect.
>
> YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
>  local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform
> engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \
>  -config yubihsm2-openssl.conf \
>  -days 3650 -extensions vpn_server_cert \
>  -out server.cert.pem \
>  -infiles ../server/certs.dir/server.csr.pem
> engine "pkcs11" set.
> Using configuration from yubihsm2-openssl.conf
> Login failed
> Login to token failed, returning NULL...
> PKCS11_get_private_key returned NULL
> cannot load CA private key from engine
> 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too
> large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
> 140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid
> arguments:p11_slot.c:240:
> 140735853761408:error:26096080:engine
> routines:ENGINE_load_private_key:failed loading private
> key:crypto/engine/eng_pkey.c:78:
> unable to load CA private key
>
> Best Regards
> //P

From tmraz at redhat.com  Tue Oct 16 08:05:33 2018
From: tmraz at redhat.com (Tomas Mraz)
Date: Tue, 16 Oct 2018 10:05:33 +0200
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <20181016072718.GE983@straasha.imrryr.org>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
 <1539647379.18482.38.camel@ns.five-ten-sg.com>
 <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org>
 <AD926CFE-9AF2-452D-A58F-CCDAC0097AEA@dukhovni.org>
 <0aa5a80f-bf84-6d75-f22d-bddee76e9a40@wisemo.com>
 <20181016072718.GE983@straasha.imrryr.org>
Message-ID: <9dc0de36-a93e-45f0-9ac3-8eabc27da460@redhat.com>

On 10/16/2018 09:27 AM, Viktor Dukhovni wrote:
> On Tue, Oct 16, 2018 at 08:13:11AM +0200, Jakob Bohm via openssl-users wrote:
> 
>>> As for the 16K limit, and whether we should be sending client
>>> CA names without further indication from the (TLS 1.3) client
>>> to do so, I'm hoping Matt Caswell and or other team members
>>> will chime in.
>>
>> Just for clarity, how is an OpenSSL 1.1.1 client supposed to tell
>> the local validation code which CAs to trust, especially if loading
>> the list before entering a chroot jail?
> 
> Loading CA files is not a problem in itself, the issue is that some
> (typically server) applications overload the CAfile as also being
> the source of CA hints to clients in certificate requests.  This
> creates bloated server certificate request messages.  With TLS 1.3,
> this is further compounded in applications that are *both* a server
> and client, and use the *same* context for both purposes.  Once
> that happens, the CA hints are used in both directions.

What are the CA hints sent from client to server good for? This looks
like missing API in 1.1.1 as we clearly do not want to start sending
huge client helos just because of client sending the CA hints to servers
in TLS-1.3. This needs to be something that requires an explicit new API
call to set.

> 
>> How is this different from the OpenSSL 1.0.x API?
> 
> The API is identical, what's different is that TLS 1.3 makes the
> CA hints bidirectional, given such hints have never been useful
> before, it is IMHO just needless generality that's counter-productive.
> Perhaps OpenSSL should require an additional non-default configuration
> to enable transmission of the client's CA DNs to the server.
> 
> Or perhaps separate the server->client and client->server CA name
> lists in the SSL context, so that setting one does not (surprise!)
> also set the other.  Overloading the same setting for both directions
> may not have anticipated bidirectional use of contexts.
> 
> Someone should perhaps open an issue to track whether anything needs
> to change here beyond advice to users, and if so what.

I've opened it:

https://github.com/openssl/openssl/issues/7411

Tomas Mraz

From levitte at openssl.org  Tue Oct 16 08:23:06 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 16 Oct 2018 10:23:06 +0200 (CEST)
Subject: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too
 large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
In-Reply-To: <CANtcRX50e0bEwbG=U7L5bKif1StaEEny-01Bq7OfoO0xFvFC9Q@mail.gmail.com>
References: <CANtcRX5HjxVyVCuwcMhmcetJcRFaJXjaMC+tehrDU_hVNgGmTQ@mail.gmail.com>
 <CANtcRX50e0bEwbG=U7L5bKif1StaEEny-01Bq7OfoO0xFvFC9Q@mail.gmail.com>
Message-ID: <20181016.102306.441641370921958907.levitte@openssl.org>

I'm curious about this error line from the 'openssl ca' output:

> 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters

It should be interesting to try and figure out what pass phrased was
passed and where it came from.  I'm afraid that's a debugging session.

Cheers,
Richard

In message <CANtcRX50e0bEwbG=U7L5bKif1StaEEny-01Bq7OfoO0xFvFC9Q at mail.gmail.com> on Tue, 16 Oct 2018 09:54:08 +0200, Peter Magnusson <blaufish.public.email at gmail.com> said:

> The error can be workaround by entering PIN = "..." into [pkcs11_section].
> pkcs11 engine version is libp11-0.4.9.
> Anyone know if this a 1) libp11 issue or 2) openssl issue or 3) me
> doing something wrong?
> On Mon, Oct 15, 2018 at 5:40 PM Peter Magnusson
> <blaufish.public.email at gmail.com> wrote:
> >
> > Hi,
> >
> > I'm trying to understand how to make "openssl ca" prompt for a PKCS#11
> > login pin. Version is openssl-1.1.1.
> >
> > openssl req works as I would expect, prompting for PIN:
> >
> > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
> > local-build/bin/openssl \
> >  req -config yubihsm2-openssl.conf -new \
> >  -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out
> > certs.dir/ca.csr.pem
> > engine "pkcs11" set.
> > Enter PKCS#11 token PIN for YubiHSM:
> >
> > openssl ca I fail to get working, no prompt presented, tried adding
> > -passin stdin but that has no effect.
> >
> > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
> >  local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform
> > engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \
> >  -config yubihsm2-openssl.conf \
> >  -days 3650 -extensions vpn_server_cert \
> >  -out server.cert.pem \
> >  -infiles ../server/certs.dir/server.csr.pem
> > engine "pkcs11" set.
> > Using configuration from yubihsm2-openssl.conf
> > Login failed
> > Login to token failed, returning NULL...
> > PKCS11_get_private_key returned NULL
> > cannot load CA private key from engine
> > 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too
> > large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
> > 140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid
> > arguments:p11_slot.c:240:
> > 140735853761408:error:26096080:engine
> > routines:ENGINE_load_private_key:failed loading private
> > key:crypto/engine/eng_pkey.c:78:
> > unable to load CA private key
> >
> > Best Regards
> > //P
> 

From blaufish.public.email at gmail.com  Tue Oct 16 08:34:31 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Tue, 16 Oct 2018 10:34:31 +0200
Subject: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too
 large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
In-Reply-To: <20181016.102306.441641370921958907.levitte@openssl.org>
References: <CANtcRX5HjxVyVCuwcMhmcetJcRFaJXjaMC+tehrDU_hVNgGmTQ@mail.gmail.com>
 <CANtcRX50e0bEwbG=U7L5bKif1StaEEny-01Bq7OfoO0xFvFC9Q@mail.gmail.com>
 <20181016.102306.441641370921958907.levitte@openssl.org>
Message-ID: <CANtcRX4xLxcOVa0iszyo4RLBuFxa7BenA2OZw9QA-KP-=BAzpQ@mail.gmail.com>

Sorry, I am an idiot =)

Problem resolved, user error.  -key was the problem and should not be
used as I showed.

-key has a different meaning for openssl ca than for openssl req, so
my PIN was my -key argument. It got my keyfile from the openssl conf
file.
On Tue, Oct 16, 2018 at 10:23 AM Richard Levitte <levitte at openssl.org> wrote:
>
> I'm curious about this error line from the 'openssl ca' output:
>
> > 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
>
> It should be interesting to try and figure out what pass phrased was
> passed and where it came from.  I'm afraid that's a debugging session.
>
> Cheers,
> Richard
>
> In message <CANtcRX50e0bEwbG=U7L5bKif1StaEEny-01Bq7OfoO0xFvFC9Q at mail.gmail.com> on Tue, 16 Oct 2018 09:54:08 +0200, Peter Magnusson <blaufish.public.email at gmail.com> said:
>
> > The error can be workaround by entering PIN = "..." into [pkcs11_section].
> > pkcs11 engine version is libp11-0.4.9.
> > Anyone know if this a 1) libp11 issue or 2) openssl issue or 3) me
> > doing something wrong?
> > On Mon, Oct 15, 2018 at 5:40 PM Peter Magnusson
> > <blaufish.public.email at gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I'm trying to understand how to make "openssl ca" prompt for a PKCS#11
> > > login pin. Version is openssl-1.1.1.
> > >
> > > openssl req works as I would expect, prompting for PIN:
> > >
> > > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
> > > local-build/bin/openssl \
> > >  req -config yubihsm2-openssl.conf -new \
> > >  -engine pkcs11 -keyform engine -key slot_0-label_ca_key -out
> > > certs.dir/ca.csr.pem
> > > engine "pkcs11" set.
> > > Enter PKCS#11 token PIN for YubiHSM:
> > >
> > > openssl ca I fail to get working, no prompt presented, tried adding
> > > -passin stdin but that has no effect.
> > >
> > > YUBIHSM_PKCS11_CONF=yubihsm2-pkcs11.conf \
> > >  local-build/bin/openssl ca -passin stdin -engine pkcs11 -keyform
> > > engine -key "pkcs11:token=YubiHSM;object=ca_key;type=private" \
> > >  -config yubihsm2-openssl.conf \
> > >  -days 3650 -extensions vpn_server_cert \
> > >  -out server.cert.pem \
> > >  -infiles ../server/certs.dir/server.csr.pem
> > > engine "pkcs11" set.
> > > Using configuration from yubihsm2-openssl.conf
> > > Login failed
> > > Login to token failed, returning NULL...
> > > PKCS11_get_private_key returned NULL
> > > cannot load CA private key from engine
> > > 140735853761408:error:28078064:UI routines:UI_set_result_ex:result too
> > > large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
> > > 140735853761408:error:82074007:PKCS#11 module:pkcs11_login:Invalid
> > > arguments:p11_slot.c:240:
> > > 140735853761408:error:26096080:engine
> > > routines:ENGINE_load_private_key:failed loading private
> > > key:crypto/engine/eng_pkey.c:78:
> > > unable to load CA private key
> > >
> > > Best Regards
> > > //P
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From hanno at hboeck.de  Tue Oct 16 08:34:16 2018
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 16 Oct 2018 10:34:16 +0200
Subject: [openssl-users] TLS 1.3 compatibility issues with OpenSSL 1.1.1
 prereleases, please stop using them
Message-ID: <20181016103416.7319d7a6@computer>

Hi,

tl;dr If you use OpenSSL 1.1.1_pre* versions please update to the final
version as soon as possible.

Not sure if this has been discussed here before, but I'd like to point
out a mail David Benjamin has recently sent to the TLS WG list:
https://www.ietf.org/mail-archive/web/tls/current/msg27066.html

Particularly he talks about issues the Chrome team had with deploying
TLS 1.3. One of the issues affects OpenSSL prereleases.

Some early versions of OpenSSL 1.1.1 (-pre6 and earlier) would allow
connections from TLS 1.3 clients, but they would try to do a connection
with a Draft TLS 1.3 version with a client that uses the final TLS 1.3
version. This obviously fails.

Long story short: If you happen to use such an OpenSSL pre version
you'll likely have connection issues as more and more software will
support TLS 1.3. So please update as soon as possible.

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

mail/jabber: hanno at hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

From Opa114 at web.de  Tue Oct 16 09:37:39 2018
From: Opa114 at web.de (Opa114)
Date: Tue, 16 Oct 2018 09:37:39 +0000
Subject: [openssl-users] BIO_printf with ASN1_BIT_STRING and ASN1_INTEGER?
Message-ID: <AM0P195MB036991D6628DBCBA32F6AC43FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>

Hi there,

i have to print out some data, which is an ASN1_BIT_STRING and an ASN1_INTEGER with BIO_printf. For GENERAL_NAME for example there a predefined functions i can use like this: GENERAL_NAME_print(bp, GENERAL_NAME_VAR) <= 0

But for ASN1_INTGER and ASN1_BIT_STRING i haven't found any predefined function like ASN1_INTEGER_PRINT or something similiar i can use. So can someone tell me how i print out these two data types with BIO_printf in the correct and actual way?

thanks a lot.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181016/5134d3dc/attachment.html>

From dcoombs at carillon.ca  Tue Oct 16 13:17:28 2018
From: dcoombs at carillon.ca (Dave Coombs)
Date: Tue, 16 Oct 2018 09:17:28 -0400
Subject: [openssl-users] BIO_printf with ASN1_BIT_STRING and
	ASN1_INTEGER?
In-Reply-To: <AM0P195MB036991D6628DBCBA32F6AC43FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>
References: <AM0P195MB036991D6628DBCBA32F6AC43FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>
Message-ID: <6C2D73D1-3B49-45E9-858D-D15BE245C166@carillon.ca>

Hi,

You can use i2a_ASN1_INTEGER() to print an ASN1_INTEGER to a BIO.

  -Dave


> On Oct 16, 2018, at 05:37, Opa114 <Opa114 at web.de> wrote:
> 
> Hi there,
> 
> i have to print out some data, which is an ASN1_BIT_STRING and an ASN1_INTEGER with BIO_printf. For GENERAL_NAME for example there a predefined functions i can use like this: GENERAL_NAME_print(bp, GENERAL_NAME_VAR) <= 0
> 
> But for ASN1_INTGER and ASN1_BIT_STRING i haven't found any predefined function like ASN1_INTEGER_PRINT or something similiar i can use. So can someone tell me how i print out these two data types with BIO_printf in the correct and actual way?
> 
> thanks a lot.
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/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/20181016/699763c7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 9617 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181016/699763c7/attachment-0001.bin>

From Matthias.Ballreich at outlook.de  Tue Oct 16 14:32:28 2018
From: Matthias.Ballreich at outlook.de (Matthias Ballreich)
Date: Tue, 16 Oct 2018 14:32:28 +0000
Subject: [openssl-users] BIO_printf with ASN1_BIT_STRING
	and	ASN1_INTEGER?
In-Reply-To: <6C2D73D1-3B49-45E9-858D-D15BE245C166@carillon.ca>
References: <AM0P195MB036991D6628DBCBA32F6AC43FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>,
 <6C2D73D1-3B49-45E9-858D-D15BE245C166@carillon.ca>
Message-ID: <AM0P195MB036973B7DAFC598DE3F0757DFBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>

Hi,

thanks for this - what about the ASN1_BIT_STRING? Is there such a predefined function?
________________________________
Von: openssl-users <openssl-users-bounces at openssl.org> im Auftrag von Dave Coombs <dcoombs at carillon.ca>
Gesendet: Dienstag, 16. Oktober 2018 15:17 Uhr
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] BIO_printf with ASN1_BIT_STRING and ASN1_INTEGER?

Hi,

You can use i2a_ASN1_INTEGER() to print an ASN1_INTEGER to a BIO.

  -Dave


On Oct 16, 2018, at 05:37, Opa114 <Opa114 at web.de<mailto:Opa114 at web.de>> wrote:

Hi there,

i have to print out some data, which is an ASN1_BIT_STRING and an ASN1_INTEGER with BIO_printf. For GENERAL_NAME for example there a predefined functions i can use like this: GENERAL_NAME_print(bp, GENERAL_NAME_VAR) <= 0

But for ASN1_INTGER and ASN1_BIT_STRING i haven't found any predefined function like ASN1_INTEGER_PRINT or something similiar i can use. So can someone tell me how i print out these two data types with BIO_printf in the correct and actual way?

thanks a lot.
--
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/20181016/2f1c2f04/attachment.html>

From Opa114 at web.de  Tue Oct 16 14:32:45 2018
From: Opa114 at web.de (Opa114)
Date: Tue, 16 Oct 2018 14:32:45 +0000
Subject: [openssl-users] BIO_printf with ASN1_BIT_STRING
	and	ASN1_INTEGER?
In-Reply-To: <6C2D73D1-3B49-45E9-858D-D15BE245C166@carillon.ca>
References: <AM0P195MB036991D6628DBCBA32F6AC43FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>,
 <6C2D73D1-3B49-45E9-858D-D15BE245C166@carillon.ca>
Message-ID: <AM0P195MB03692DC0E1300128ABA75FF8FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>

Hi,

thanks for this - what about the ASN1_BIT_STRING? Is there such a predefined function?

________________________________
Von: openssl-users <openssl-users-bounces at openssl.org> im Auftrag von Dave Coombs <dcoombs at carillon.ca>
Gesendet: Dienstag, 16. Oktober 2018 15:17 Uhr
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] BIO_printf with ASN1_BIT_STRING and ASN1_INTEGER?

Hi,

You can use i2a_ASN1_INTEGER() to print an ASN1_INTEGER to a BIO.

  -Dave


On Oct 16, 2018, at 05:37, Opa114 <Opa114 at web.de<mailto:Opa114 at web.de>> wrote:

Hi there,

i have to print out some data, which is an ASN1_BIT_STRING and an ASN1_INTEGER with BIO_printf. For GENERAL_NAME for example there a predefined functions i can use like this: GENERAL_NAME_print(bp, GENERAL_NAME_VAR) <= 0

But for ASN1_INTGER and ASN1_BIT_STRING i haven't found any predefined function like ASN1_INTEGER_PRINT or something similiar i can use. So can someone tell me how i print out these two data types with BIO_printf in the correct and actual way?

thanks a lot.
--
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/20181016/9e077264/attachment.html>

From dimanne at gmail.com  Tue Oct 16 14:39:49 2018
From: dimanne at gmail.com (Dmitry)
Date: Tue, 16 Oct 2018 17:39:49 +0300
Subject: [openssl-users] OpenSSL occasionally generates wrong signature
Message-ID: <CAC9D8R7YRua69PHC5TwFWssiYBpVA5jhkr-hx_ObPXHFe8=MMA@mail.gmail.com>

Hello!

I have a C++ programme, ECDSA key pair and some string to sign. The
programme generates signature and saves it into a file (signature.bin).
Then I check the validity of the signature via the following command:

openssl dgst -verify ec_public.pem -signature signature.bin ToSign.txt

the problem is that *my programme sometimes generates wrong signature*. 16
times out of 21 the signature produced is invalid and the above command
outputs:
Error Verifying Data

while in the remaining 5 occurrences it outputs:
Verified OK

Do you have any ideas of how it can be possible? What am I doing wrong?


Here is the programme:

SSL_library_init();
OPENSSL_config(nullptr);
SSL_load_error_strings();
OpenSSL_add_all_algorithms();
ERR_load_BIO_strings();
CRYPTO_set_id_callback(ThreadIdFunction);
CRYPTO_set_locking_callback(LockingFunction);

const TString pk = "-----BEGIN EC PRIVATE KEY-----\n"

 "MHcCAQEEIG90zmo1o3NWNFa8wp2z4rdQXGSN8xAP/OATLpwlgi+1oAoGCCqGSM49\n"

 "AwEHoUQDQgAE5TwpzBhjUWZoOf629GfwGG5WlRJD7TSuz+ZTHUaiK5mj2qgxBOPk\n"
                       "eqOrTYXsiPwnaWe23zHjIM8NOhAm1BiGgA==\n"
                       "-----END EC PRIVATE KEY-----\n";

const TString ToSign =
"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJhc2RmIn0";

EVP_MD_CTX *Ctx    = EVP_MD_CTX_create();
BIO *       Bio    = BIO_new_mem_buf(pk.data(), pk.size());
EVP_PKEY *  EVPKey = PEM_read_bio_PrivateKey(Bio, nullptr, nullptr,
nullptr);

EVP_DigestSignInit(Ctx, nullptr, EVP_sha256(), nullptr, EVPKey);
EVP_DigestSignUpdate(Ctx, ToSign.data(), ToSign.size());
size_t SignatureLength;
EVP_DigestSignFinal(Ctx, nullptr, &SignatureLength);

TString Result;
Result.resize(SignatureLength);
EVP_DigestSignFinal(Ctx, reinterpret_cast<unsigned char *>(const_cast<char
*>(Result.data())), &SignatureLength);

// Saving to file...

Thank you in advance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181016/821bb7e2/attachment-0001.html>

From jb-openssl at wisemo.com  Tue Oct 16 14:46:04 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 16 Oct 2018 16:46:04 +0200
Subject: [openssl-users] OpenSSL occasionally generates wrong signature
In-Reply-To: <CAC9D8R7YRua69PHC5TwFWssiYBpVA5jhkr-hx_ObPXHFe8=MMA@mail.gmail.com>
References: <CAC9D8R7YRua69PHC5TwFWssiYBpVA5jhkr-hx_ObPXHFe8=MMA@mail.gmail.com>
Message-ID: <83d603b3-1a7a-fbe1-d5a1-9ee63d380b1e@wisemo.com>

On 16/10/2018 16:39, Dmitry wrote:
> Hello!
>
> I have a C++ programme, ECDSA key pair and some string to sign. The 
> programme generates signature and saves it into a file 
> (signature.bin). Then I check the validity of the signature via the 
> following command:
>
> openssl dgst -verify ec_public.pem -signature signature.bin ToSign.txt
>
> the problem is that *my programme sometimes generates wrong 
> signature*. 16 times out of 21 the signature produced is invalid and 
> the above command outputs:
> Error Verifying Data
>
> while in the remaining 5 occurrences it outputs:
> Verified OK
>
> Do you have any ideas of how it can be possible? What am I?doing wrong?
>
>
> Here is the programme:
>
> SSL_library_init();
> OPENSSL_config(nullptr);
> SSL_load_error_strings();
> OpenSSL_add_all_algorithms();
> ERR_load_BIO_strings();
> CRYPTO_set_id_callback(ThreadIdFunction);
> CRYPTO_set_locking_callback(LockingFunction);
>
> const TString pk = "-----BEGIN EC PRIVATE KEY-----\n"
> ?"MHcCAQEEIG90zmo1o3NWNFa8wp2z4rdQXGSN8xAP/OATLpwlgi+1oAoGCCqGSM49\n"
> ?"AwEHoUQDQgAE5TwpzBhjUWZoOf629GfwGG5WlRJD7TSuz+ZTHUaiK5mj2qgxBOPk\n"
> ?"eqOrTYXsiPwnaWe23zHjIM8NOhAm1BiGgA==\n"
> ? ? ? ? ? ? ? ? ? ? ?"-----END EC PRIVATE KEY-----\n";
>
> const TString ToSign = 
> "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOiJhc2RmIn0";
>
> EVP_MD_CTX *Ctx? ? = EVP_MD_CTX_create();
> BIO *? ? ? ?Bio? ? = BIO_new_mem_buf(pk.data(), pk.size());
> EVP_PKEY *? EVPKey = PEM_read_bio_PrivateKey(Bio, nullptr, nullptr, 
> nullptr);
>
> EVP_DigestSignInit(Ctx, nullptr, EVP_sha256(), nullptr, EVPKey);
> EVP_DigestSignUpdate(Ctx, ToSign.data(), ToSign.size());
> size_t SignatureLength;
> EVP_DigestSignFinal(Ctx, nullptr, &SignatureLength);
>
> TString Result;
^^^^^^^ You are treating binary data as a string.
Chances are the TString class will truncate at the first byte with
the value zero, and/or do some other text-specific thing that is bad
for binary data.

> Result.resize(SignatureLength);
> EVP_DigestSignFinal(Ctx, reinterpret_cast<unsigned char 
> *>(const_cast<char *>(Result.data())), &SignatureLength);
>
> // Saving to file...
>

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 dcoombs at carillon.ca  Tue Oct 16 15:10:22 2018
From: dcoombs at carillon.ca (Dave Coombs)
Date: Tue, 16 Oct 2018 11:10:22 -0400
Subject: [openssl-users] BIO_printf with ASN1_BIT_STRING
	and	ASN1_INTEGER?
In-Reply-To: <AM0P195MB03692DC0E1300128ABA75FF8FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>
References: <AM0P195MB036991D6628DBCBA32F6AC43FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>
 <6C2D73D1-3B49-45E9-858D-D15BE245C166@carillon.ca>
 <AM0P195MB03692DC0E1300128ABA75FF8FBFE0@AM0P195MB0369.EURP195.PROD.OUTLOOK.COM>
Message-ID: <1E7EBEDC-21F3-4E2D-B495-D2ACF255A8A5@carillon.ca>

Depends what you want it to print, I guess...  ASN1_STRING_print_ex() can print any ASN1_STRING (including an ASN1_BIT_STRING) but it'll come out binary packed.  If you want to do anything fancier like print individual bit values in a more human-readable way, you'll have to do it yourself, as far as I know.

  -Dave


> On Oct 16, 2018, at 10:32, Opa114 <Opa114 at web.de> wrote:
> 
> Hi,
> 
> thanks for this - what about the ASN1_BIT_STRING? Is there such a predefined function?
> 
> Von: openssl-users <openssl-users-bounces at openssl.org <mailto:openssl-users-bounces at openssl.org>> im Auftrag von Dave Coombs <dcoombs at carillon.ca <mailto:dcoombs at carillon.ca>>
> Gesendet: Dienstag, 16. Oktober 2018 15:17 Uhr
> An: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> Betreff: Re: [openssl-users] BIO_printf with ASN1_BIT_STRING and ASN1_INTEGER?
>  
> Hi,
> 
> You can use i2a_ASN1_INTEGER() to print an ASN1_INTEGER to a BIO.
> 
>   -Dave
> 
> 
>> On Oct 16, 2018, at 05:37, Opa114 <Opa114 at web.de <mailto:Opa114 at web.de>> wrote:
>> 
>> Hi there,
>> 
>> i have to print out some data, which is an ASN1_BIT_STRING and an ASN1_INTEGER with BIO_printf. For GENERAL_NAME for example there a predefined functions i can use like this: GENERAL_NAME_print(bp, GENERAL_NAME_VAR) <= 0
>> 
>> But for ASN1_INTGER and ASN1_BIT_STRING i haven't found any predefined function like ASN1_INTEGER_PRINT or something similiar i can use. So can someone tell me how i print out these two data types with BIO_printf in the correct and actual way?
>> 
>> thanks a lot.
>> -- 
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/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/20181016/9185dc05/attachment.html>

From dimanne at gmail.com  Tue Oct 16 15:16:57 2018
From: dimanne at gmail.com (Dmitry)
Date: Tue, 16 Oct 2018 18:16:57 +0300
Subject: [openssl-users] OpenSSL occasionally generates wrong signature
In-Reply-To: <83d603b3-1a7a-fbe1-d5a1-9ee63d380b1e@wisemo.com>
References: <CAC9D8R7YRua69PHC5TwFWssiYBpVA5jhkr-hx_ObPXHFe8=MMA@mail.gmail.com>
 <83d603b3-1a7a-fbe1-d5a1-9ee63d380b1e@wisemo.com>
Message-ID: <CAC9D8R74HEXaR1StrXKMsKt1nd+AqXRHqwMWc1ne0C1hg85_tg@mail.gmail.com>

Thank you for the hint, but it looks like the problem is somewhere else

I rewrote the piece of code in such a way:
    char *Result = new char [SignatureLength];
    EVP_DigestSignFinal(Ctx, reinterpret_cast<unsigned char *>(Result),
&SignatureLength);

    TFile SignatureBin = {"/home/gc/signature.bin", ...};
    SignatureBin.Write(Result, SignatureLength);

but the problem still persists.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181016/775f7de3/attachment.html>

From rwelty at nwtime.org  Tue Oct 16 17:44:08 2018
From: rwelty at nwtime.org (Richard Welty)
Date: Tue, 16 Oct 2018 13:44:08 -0400
Subject: [openssl-users] reasons for negative return value from
	BIO_do_connect
Message-ID: <915b95fe-4ed5-b103-95a0-a2125685a56d@nwtime.org>

i'm trying to figure out why BIO_do_connect is failing with
a negative value. so far as i know i've done all preliminaries
correctly, but apparently i've missed something. i am dumping
the SSL errors from ERR_get_error but am not getting any in
this instance.

OpenSSL version is 1.1.0h

Ubuntu 18.04 running in a VM on a Mac Mini. the network is setup
in bridged adapter mode so that the VM has a distinct IP address
from the host. i have used nmap to verify that i can reach the
target server and that the port the server is listening on is
open. the owner of the server assures me that his app is up and
listening.

i have verified with both wireshark and by looking at the logs
on the server i'm trying to reach that no actual traffic went out.

the following is output from the test run. note that i print out
the values of IP and port using BIO_get_conn_hostname and
BIO_get_conn_port to insure that i did all the processing
correctly.

TLS method obtained
TLS context established
NTS: options and ALPN protos set
NTS: remote peer bio created
141.41.241.68
NTS: remote peer hostname set to '141.41.241.68'
NTS: server port set to '443'
NTS: ssl bio obtained
NTS: ciphers set
16 Oct 13:15:39 ntpd[4439]: failed to connect to server

here is the code which is failing:

struct tls_connection* nts_tls_connect( struct peer *peer){

  long result;
  struct tls_connection* connection = malloc( sizeof (struct
tls_connection));
  connection->sock = -1;
  connection->ctx = NULL;
  connection->remote_peer = NULL;
  connection->ssl = NULL;
  connection->ke_buffer = malloc( MAX_KE_RESPONSE);

  const SSL_METHOD* method = TLSv1_2_client_method();
  if( method == NULL){
    msyslog( LOG_ERR, "Failed to obtain TLS 1.2 method from OpenSSL");
    free_tls_connection( connection);
    return NULL;
  }

  DPRINTF( 1, ("TLS method obtained\n"));

  connection->ctx = SSL_CTX_new( method);
  if( connection->ctx == NULL){
    msyslog( LOG_ERR, "Failed to establish TLS context");
    dprintf_ssl_error();
    free_tls_connection( connection);
    return NULL;
  }

  DPRINTF( 1, ("TLS context established\n"));

  // verification turned off for proof of concept
  // SSL_CTX_set_verify( connection->ctx, SSL_VERIFY_PEER, NULL);
  // SSL_CTX_set_verify_depth( connection->ctx, 4);

  const long flags
    = SSL_OP_NO_SSLv2
    | SSL_OP_NO_SSLv3
    | SSL_OP_NO_TLSv1
    | SSL_OP_NO_TLSv1_1
    | SSL_OP_NO_COMPRESSION;
  SSL_CTX_set_options( connection->ctx, flags);

  result = SSL_CTX_set_alpn_protos( connection->ctx,
				 alpn_ntske,
				 sizeof( alpn_ntske));
  if( result != 0){
    msyslog( LOG_ERR, "failed to set ALPN protos");
    dprintf_ssl_error();
    free_tls_connection( connection);
    return NULL;
  }

  DPRINTF( 1, ("NTS: options and ALPN protos set\n"));

  // verification turned off for hackathon
  // SSL_CTX_load_verify_locations...

  connection->remote_peer = BIO_new_ssl_connect( connection->ctx);
  if( connection->remote_peer == NULL){
    msyslog( LOG_ERR, "failed to create remote_peer BIO chain");
    free_tls_connection( connection);
    return NULL;
  }

  DPRINTF( 1, ("NTS: remote peer bio created\n"));

  if( peer->hostname != NULL){
    result = BIO_set_conn_hostname( connection->remote_peer,
peer->hostname);
  } else {
    char *addr = address_string( &peer->srcadr);
    result = BIO_set_conn_hostname( connection->remote_peer,addr);
    free( addr);
  }
  if( result != 1){
    msyslog( LOG_ERR, "failed to set remote peer hostname");
    free_tls_connection( connection);
    return NULL;
  }

  DPRINTF( 1, ("NTS: remote peer hostname set to \'%s\'\n",
	       BIO_get_conn_hostname( connection->remote_peer)));

  result = BIO_set_conn_port( connection->remote_peer, NTS_KE_PORT);
  if( result != 1){
    msyslog( LOG_ERR, "failed to set server port");
    free_tls_connection( connection);
    return NULL;
  }

  DPRINTF( 1, ("NTS: server port set to \'%s\'\n",
	       BIO_get_conn_port( connection->remote_peer)));

  BIO_get_ssl( connection->remote_peer, &connection->ssl);
  if( connection->ssl == NULL){
    msyslog( LOG_ERR, "failed to get SSL from BIO");
    free_tls_connection( connection);
    return NULL;
  }

  DPRINTF( 1, ("NTS: ssl bio obtained\n"));

  const char* PREFERRED_CIPHERS = "HIGH:AES256:AES128";
  result = SSL_set_cipher_list( connection->ssl, PREFERRED_CIPHERS);
  if( result != 1){
    msyslog( LOG_ERR, "failed to set cipher list");
    dprintf_ssl_error();
    free_tls_connection( connection);
    return NULL;
  }

  DPRINTF( 1, ("NTS: ciphers set\n"));

    /*
   connection->evbase = event_base_new();
  struct buffer_event *bev
    = bufferevent_openssl_socket_new( connection->evbase,
				      -1, connection->ssl,
				      BUFFEREVENT_SSL_CONNECTING,
				      BEV_OPT_CLOSE_ON_FREE);
  */

  result = BIO_do_connect( connection->remote_peer);
  if( result <= 0){
    msyslog( LOG_ERR, "failed to connect to server");
    dprintf_ssl_error();
    free_tls_connection( connection);
    return NULL;
  }

From dimanne at gmail.com  Tue Oct 16 17:56:21 2018
From: dimanne at gmail.com (Dmitry)
Date: Tue, 16 Oct 2018 20:56:21 +0300
Subject: [openssl-users] OpenSSL occasionally generates wrong signature
In-Reply-To: <CAC9D8R74HEXaR1StrXKMsKt1nd+AqXRHqwMWc1ne0C1hg85_tg@mail.gmail.com>
References: <CAC9D8R7YRua69PHC5TwFWssiYBpVA5jhkr-hx_ObPXHFe8=MMA@mail.gmail.com>
 <83d603b3-1a7a-fbe1-d5a1-9ee63d380b1e@wisemo.com>
 <CAC9D8R74HEXaR1StrXKMsKt1nd+AqXRHqwMWc1ne0C1hg85_tg@mail.gmail.com>
Message-ID: <CAC9D8R67GWXmsy7gacWpksBaKSXYNtxo+m_ERqFkhkDX2OAK1w@mail.gmail.com>

Looks like there is some problem in higher-level EVP_ functions.

I completely rewrote the example using lower-level ECDSA_do_sign and it
started to work always.

Here is the code:
   EVP_MD_CTX *Ctx = EVP_MD_CTX_create();
   EVP_DigestInit(Ctx, EVP_sha256());
   EVP_DigestUpdate(Ctx, dt.data(), dt.size());
   QByteArray Digest;
   Digest.resize(EVP_MAX_MD_SIZE);
   unsigned int Len;
   EVP_DigestFinal(Ctx, reinterpret_cast<unsigned char *>(Digest.data()),
&Len);
   Digest.resize(Len);

   BIO *   Bio   = BIO_new_mem_buf(pk.data(), pk.size());
   EC_KEY *ECKey = PEM_read_bio_ECPrivateKey(Bio, nullptr, nullptr,
nullptr);
   ECDSA_SIG *Signature = ECDSA_do_sign(reinterpret_cast<unsigned char
*>(Digest.data()), Digest.size(), ECKey);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181016/a1e977a5/attachment.html>

From jisoza at gmail.com  Tue Oct 16 21:20:53 2018
From: jisoza at gmail.com (Juan Isoza)
Date: Tue, 16 Oct 2018 23:20:53 +0200
Subject: [openssl-users] Chrome 70 with final tls 1.3 is out
Message-ID: <CAKRdTC81n7PzUEkAvANTUsKKQqA3mV-cFTfgNHo_=Y-42xh6Aw@mail.gmail.com>

Chrome 70 with final tls 1.3 install itself with automatic update. So there
will be a lot of tls 1.3 client !

And Firefox will update next week
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181016/4a75afa0/attachment.html>

From kaushalshriyan at gmail.com  Wed Oct 17 06:25:38 2018
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Wed, 17 Oct 2018 11:55:38 +0530
Subject: [openssl-users] To disable CBC ciphers
Message-ID: <CAD7Ssm-roOek6X_Lj2UBC3qMOdhgufUpeqHprRZqXxv6bOeO4w@mail.gmail.com>

Hi,

I have the below ssl settings in nginx.conf file and VAPT test has reported
us to disable CBC ciphers

ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;
> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;


openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS
Linux release 7.3.1611 (Core)

I will appreciate if someone can pitch in to help me understand to disable
CBC ciphers

Best Regards

Kaushal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181017/1327f061/attachment.html>

From levitte at openssl.org  Wed Oct 17 08:13:28 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 17 Oct 2018 10:13:28 +0200 (CEST)
Subject: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too
 large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
In-Reply-To: <CANtcRX4xLxcOVa0iszyo4RLBuFxa7BenA2OZw9QA-KP-=BAzpQ@mail.gmail.com>
References: <CANtcRX50e0bEwbG=U7L5bKif1StaEEny-01Bq7OfoO0xFvFC9Q@mail.gmail.com>
 <20181016.102306.441641370921958907.levitte@openssl.org>
 <CANtcRX4xLxcOVa0iszyo4RLBuFxa7BenA2OZw9QA-KP-=BAzpQ@mail.gmail.com>
Message-ID: <20181017.101328.1330160527459170334.levitte@openssl.org>

In message <CANtcRX4xLxcOVa0iszyo4RLBuFxa7BenA2OZw9QA-KP-=BAzpQ at mail.gmail.com> on Tue, 16 Oct 2018 10:34:31 +0200, Peter Magnusson <blaufish.public.email at gmail.com> said:

> Sorry, I am an idiot =)

No you're not.

> Problem resolved, user error.  -key was the problem and should not be
> used as I showed.
> 
> -key has a different meaning for openssl ca than for openssl req, so
> my PIN was my -key argument. It got my keyfile from the openssl conf
> file.

And this is precisely why you're not an idiot.  We're not consistent
between openssl sub-commands, so no wonder you get confused.  It's a
pattern thing, we catch on to similar patterns (such as option names).

We really should look over those options...  (but with all the other
stuff we have going on, I'm afraid this isn't the highest on our
priority list)

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From steffen at sdaoden.eu  Wed Oct 17 12:12:46 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 17 Oct 2018 14:12:46 +0200
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
Message-ID: <20181017121246.cUHhK%steffen@sdaoden.eu>

Hello, and fyi.

I have built final 1.1.1 yesterday on AlpineLinux musl after
running a prelease from end of May before.  My makefile rule for
this box is (excerpt)

        ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared \
                no-deprecated no-async no-tests \
                -DOPENSSL_NO_ASYNC \
                -Wl,-rpath,'$(LIBRPATH)' &&\
        make &&\
        $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \

The -DOPENSSL_NO_ASYNC i had to add yesterday, no-async alone was
not enough.  (I have forgotten whether this was necessary in May,
but most likely not.)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From matt at openssl.org  Wed Oct 17 12:22:25 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 17 Oct 2018 13:22:25 +0100
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <20181017121246.cUHhK%steffen@sdaoden.eu>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
Message-ID: <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>



On 17/10/2018 13:12, Steffen Nurpmeso wrote:
> Hello, and fyi.
> 
> I have built final 1.1.1 yesterday on AlpineLinux musl after
> running a prelease from end of May before.  My makefile rule for
> this box is (excerpt)
> 
>         ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared \
>                 no-deprecated no-async no-tests \
>                 -DOPENSSL_NO_ASYNC \
>                 -Wl,-rpath,'$(LIBRPATH)' &&\
>         make &&\
>         $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \
> 
> The -DOPENSSL_NO_ASYNC i had to add yesterday, no-async alone was
> not enough.  (I have forgotten whether this was necessary in May,
> but most likely not.)

This shouldn't be necessary. What errors do you get if you don't include
that?

Matt


From nic.tuv at gmail.com  Wed Oct 17 12:24:00 2018
From: nic.tuv at gmail.com (Nicola)
Date: Wed, 17 Oct 2018 15:24:00 +0300
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <20181017121246.cUHhK%steffen@sdaoden.eu>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
Message-ID: <CANm5x_PvvMC5Y_w0LyEmFQwpz=QV5Xx+gu_4R2DLaQsuUKgMbA@mail.gmail.com>

Might this be related to https://github.com/openssl/openssl/issues/7406 and
https://github.com/openssl/openssl/pull/7420 ?

Nicola

On Wed, 17 Oct 2018 at 15:12, Steffen Nurpmeso <steffen at sdaoden.eu> wrote:

> Hello, and fyi.
>
> I have built final 1.1.1 yesterday on AlpineLinux musl after
> running a prelease from end of May before.  My makefile rule for
> this box is (excerpt)
>
>         ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared \
>                 no-deprecated no-async no-tests \
>                 -DOPENSSL_NO_ASYNC \
>                 -Wl,-rpath,'$(LIBRPATH)' &&\
>         make &&\
>         $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \
>
> The -DOPENSSL_NO_ASYNC i had to add yesterday, no-async alone was
> not enough.  (I have forgotten whether this was necessary in May,
> but most likely not.)
>
> --steffen
> |
> |Der Kragenbaer,                The moon bear,
> |der holt sich munter           he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)
> --
> 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/20181017/02d9eb93/attachment-0001.html>

From steffen at sdaoden.eu  Wed Oct 17 12:43:18 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 17 Oct 2018 14:43:18 +0200
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
 <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>
Message-ID: <20181017124318.AuPzB%steffen@sdaoden.eu>

Matt Caswell wrote in <cf8b85a3-af41-ba9c-92c4-f744666c7c76 at openssl.org>:
 |
 |
 |On 17/10/2018 13:12, Steffen Nurpmeso wrote:
 |> Hello, and fyi.
 |> 
 |> I have built final 1.1.1 yesterday on AlpineLinux musl after
 |> running a prelease from end of May before.  My makefile rule for
 |> this box is (excerpt)
 |> 
 |>         ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared \
 |>                 no-deprecated no-async no-tests \
 |>                 -DOPENSSL_NO_ASYNC \
 |>                 -Wl,-rpath,'$(LIBRPATH)' &&\
 |>         make &&\
 |>         $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \
 |> 
 |> The -DOPENSSL_NO_ASYNC i had to add yesterday, no-async alone was
 |> not enough.  (I have forgotten whether this was necessary in May,
 |> but most likely not.)
 |
 |This shouldn't be necessary. What errors do you get if you don't include
 |that?

  #?0[steffen at essex code.arena]$ MAKE=make make openssl-blade MYPREFIX=$HOME/$USR/opt/.ossl-1.1.1
  cd openssl.git &&\
  if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
  ./config --prefix=/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl-1.1.1 zlib-dynamic no-hw shared \
          no-deprecated no-async no-tests \
          -Wl,-rpath,'' &&\
  make &&\
   make install_sw &&  make install_ssldirs; \
  { git clean -fxd; git reset --hard HEAD;\
  git checkout arena-manager-null; } >/dev/null
  Operating system: x86_64-whatever-linux2
  Configuring OpenSSL version 1.1.1 (0x1010100fL) for linux-x86_64-clang
  Using os-specific seed configuration
  Creating configdata.pm
  Creating Makefile
  
  **********************************************************************
  ***                                                                ***
  ***   If you want to report a building issue, please include the   ***
  ***   output from this command:                                    ***
  ***                                                                ***
  ***     perl configdata.pm --dump                                  ***
  ***                                                                ***
  **********************************************************************
  make[1]: Entering directory '/home/steffen/code.arena/openssl.git'
  /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
      "-oMakefile" crypto/include/internal/bn_conf.h.in > crypto/include/internal/bn_conf.h
  /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
      "-oMakefile" crypto/include/internal/dso_conf.h.in > crypto/include/internal/dso_conf.h
  /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
      "-oMakefile" include/openssl/opensslconf.h.in > include/openssl/opensslconf.h
  make depend && make _all
  make[2]: Entering directory '/home/steffen/code.arena/openssl.git'
  make[2]: Leaving directory '/home/steffen/code.arena/openssl.git'
  make[2]: Entering directory '/home/steffen/code.arena/openssl.git'
  clang [...]
  clang  -I. -Icrypto/include -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl-1.1.1/ssl\"" -DENGINESDIR="\"/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl-1.1.1/lib/engines-1.1\"" -DZLIB -DZLIB_SHARED -DNDEBUG -DOPENSSL_API_COMPAT=0x10100000L  -MMD -MF crypto/asn1/a_sign.d.tmp -MT crypto/asn1/a_sign.o -c -o crypto/asn1/a_sign.o crypto/asn1/a_sign.c
  In file included from crypto/asn1/a_sign.c:22:
  In file included from crypto/include/internal/evp_int.h:11:
  include/internal/refcount.h:21:12: fatal error: 'stdatomic.h' file not found
  #  include <stdatomic.h>
             ^~~~~~~~~~~~~
  1 error generated.
  make[2]: *** [Makefile:955: crypto/asn1/a_sign.o] Error 1
  make[2]: Leaving directory '/home/steffen/code.arena/openssl.git'
  make[1]: *** [Makefile:171: all] Error 2
  make[1]: Leaving directory '/home/steffen/code.arena/openssl.git'
  Previous HEAD position was 1708e3e85b Prepare for 1.1.1 release
  Switched to branch 'arena-manager-null'

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From matt at openssl.org  Wed Oct 17 12:56:08 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 17 Oct 2018 13:56:08 +0100
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <20181017124318.AuPzB%steffen@sdaoden.eu>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
 <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>
 <20181017124318.AuPzB%steffen@sdaoden.eu>
Message-ID: <bf5f388d-1964-24c8-753b-0251a7412642@openssl.org>



On 17/10/2018 13:43, Steffen Nurpmeso wrote:
> Matt Caswell wrote in <cf8b85a3-af41-ba9c-92c4-f744666c7c76 at openssl.org>:
>  |
>  |
>  |On 17/10/2018 13:12, Steffen Nurpmeso wrote:
>  |> Hello, and fyi.
>  |> 
>  |> I have built final 1.1.1 yesterday on AlpineLinux musl after
>  |> running a prelease from end of May before.  My makefile rule for
>  |> this box is (excerpt)
>  |> 
>  |>         ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared \
>  |>                 no-deprecated no-async no-tests \
>  |>                 -DOPENSSL_NO_ASYNC \
>  |>                 -Wl,-rpath,'$(LIBRPATH)' &&\
>  |>         make &&\
>  |>         $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \
>  |> 
>  |> The -DOPENSSL_NO_ASYNC i had to add yesterday, no-async alone was
>  |> not enough.  (I have forgotten whether this was necessary in May,
>  |> but most likely not.)
>  |
>  |This shouldn't be necessary. What errors do you get if you don't include
>  |that?
> 
>   #?0[steffen at essex code.arena]$ MAKE=make make openssl-blade MYPREFIX=$HOME/$USR/opt/.ossl-1.1.1
>   cd openssl.git &&\
>   if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
>   ./config --prefix=/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl-1.1.1 zlib-dynamic no-hw shared \
>           no-deprecated no-async no-tests \
>           -Wl,-rpath,'' &&\
>   make &&\
>    make install_sw &&  make install_ssldirs; \
>   { git clean -fxd; git reset --hard HEAD;\
>   git checkout arena-manager-null; } >/dev/null
>   Operating system: x86_64-whatever-linux2
>   Configuring OpenSSL version 1.1.1 (0x1010100fL) for linux-x86_64-clang
>   Using os-specific seed configuration
>   Creating configdata.pm
>   Creating Makefile
>   
>   **********************************************************************
>   ***                                                                ***
>   ***   If you want to report a building issue, please include the   ***
>   ***   output from this command:                                    ***
>   ***                                                                ***
>   ***     perl configdata.pm --dump                                  ***
>   ***                                                                ***
>   **********************************************************************
>   make[1]: Entering directory '/home/steffen/code.arena/openssl.git'
>   /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
>       "-oMakefile" crypto/include/internal/bn_conf.h.in > crypto/include/internal/bn_conf.h
>   /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
>       "-oMakefile" crypto/include/internal/dso_conf.h.in > crypto/include/internal/dso_conf.h
>   /usr/bin/perl "-I." -Mconfigdata "util/dofile.pl" \
>       "-oMakefile" include/openssl/opensslconf.h.in > include/openssl/opensslconf.h
>   make depend && make _all
>   make[2]: Entering directory '/home/steffen/code.arena/openssl.git'
>   make[2]: Leaving directory '/home/steffen/code.arena/openssl.git'
>   make[2]: Entering directory '/home/steffen/code.arena/openssl.git'
>   clang [...]
>   clang  -I. -Icrypto/include -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl-1.1.1/ssl\"" -DENGINESDIR="\"/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl-1.1.1/lib/engines-1.1\"" -DZLIB -DZLIB_SHARED -DNDEBUG -DOPENSSL_API_COMPAT=0x10100000L  -MMD -MF crypto/asn1/a_sign.d.tmp -MT crypto/asn1/a_sign.o -c -o crypto/asn1/a_sign.o crypto/asn1/a_sign.c
>   In file included from crypto/asn1/a_sign.c:22:
>   In file included from crypto/include/internal/evp_int.h:11:
>   include/internal/refcount.h:21:12: fatal error: 'stdatomic.h' file not found
>   #  include <stdatomic.h>
>              ^~~~~~~~~~~~~
>   1 error generated.
>   make[2]: *** [Makefile:955: crypto/asn1/a_sign.o] Error 1
>   make[2]: Leaving directory '/home/steffen/code.arena/openssl.git'
>   make[1]: *** [Makefile:171: all] Error 2
>   make[1]: Leaving directory '/home/steffen/code.arena/openssl.git'
>   Previous HEAD position was 1708e3e85b Prepare for 1.1.1 release
>   Switched to branch 'arena-manager-null'

And that problem goes away by specifying "-DOPENSSL_NO_ASYNC" to
config????? That issue seems to have absolutely nothing to do with that
define. None of the .c or .h files indicated in the error above
reference it, nor do they have anything to do with the async functionality.

This problem seems to be environmental. The code in question looks like
this:

# if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L \
     && !defined(__STDC_NO_ATOMICS__)
#  include <stdatomic.h>
#  define HAVE_C11_ATOMICS
# endif

stdatomic.h is part of C11. A C11 compliant compiler should provide it
unless it also define __STDC_NO_ATOMICS__. Your compiler appears to be
claiming to be C11 compliant and has not defined __STC_NO_ATOMICS__ -
and yet the header file cannot be found.

Perhaps some kind of setup issue on your machine?

Matt
`



From steffen at sdaoden.eu  Wed Oct 17 13:09:18 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 17 Oct 2018 15:09:18 +0200
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <bf5f388d-1964-24c8-753b-0251a7412642@openssl.org>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
 <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>
 <20181017124318.AuPzB%steffen@sdaoden.eu>
 <bf5f388d-1964-24c8-753b-0251a7412642@openssl.org>
Message-ID: <20181017130918._7Sz9%steffen@sdaoden.eu>

Matt Caswell wrote in <bf5f388d-1964-24c8-753b-0251a7412642 at openssl.org>:
 |On 17/10/2018 13:43, Steffen Nurpmeso wrote:
 |> Matt Caswell wrote in <cf8b85a3-af41-ba9c-92c4-f744666c7c76 at openssl.org>:
 |>|On 17/10/2018 13:12, Steffen Nurpmeso wrote:
 |>|> I have built final 1.1.1 yesterday on AlpineLinux musl after
 |>|> running a prelease from end of May before.  My makefile rule for
 |>|> this box is (excerpt)
 |>|> 
 |>|>         ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared \
 |>|>                 no-deprecated no-async no-tests \
 |>|>                 -DOPENSSL_NO_ASYNC \
 |>|>                 -Wl,-rpath,'$(LIBRPATH)' &&\
 |>|>         make &&\
 |>|>         $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \
 |>|> 
 |>|> The -DOPENSSL_NO_ASYNC i had to add yesterday, no-async alone was
 |>|> not enough.  (I have forgotten whether this was necessary in May,
 |>|> but most likely not.)
 |>|
 |>|This shouldn't be necessary. What errors do you get if you don't include
 |>|that?
 |> 
 |>   #?0[steffen at essex code.arena]$ MAKE=make make openssl-blade MYPREFIX=$H\
 |>   OME/$USR/opt/.ossl-1.1.1
 |>   cd openssl.git &&\
 |>   if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
 |>   ./config --prefix=/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl\
 |>   -1.1.1 zlib-dynamic no-hw shared \
 |>           no-deprecated no-async no-tests \
 |>           -Wl,-rpath,'' &&\
 |>   make &&\
 |>    make install_sw &&  make install_ssldirs; \
 ..
 |>   -o crypto/asn1/a_sign.o crypto/asn1/a_sign.c
 |>   In file included from crypto/asn1/a_sign.c:22:
 |>   In file included from crypto/include/internal/evp_int.h:11:
 |>   include/internal/refcount.h:21:12: fatal error: 'stdatomic.h' file \
 |>   not found
 |>   #  include <stdatomic.h>
 |>              ^~~~~~~~~~~~~
 |>   1 error generated.
 |>   make[2]: *** [Makefile:955: crypto/asn1/a_sign.o] Error 1
 |>   make[2]: Leaving directory '/home/steffen/code.arena/openssl.git'
 |>   make[1]: *** [Makefile:171: all] Error 2
 |>   make[1]: Leaving directory '/home/steffen/code.arena/openssl.git'
 |>   Previous HEAD position was 1708e3e85b Prepare for 1.1.1 release
 |>   Switched to branch 'arena-manager-null'
 |
 |And that problem goes away by specifying "-DOPENSSL_NO_ASYNC" to
 |config????? That issue seems to have absolutely nothing to do with that
 |define. None of the .c or .h files indicated in the error above
 |reference it, nor do they have anything to do with the async functionality.

Yes, that is what i did!  I looked into the AlpineLinux abuild
package system, and how they get it done, and after adding this
define the building succeeded.

 |This problem seems to be environmental. The code in question looks like
 |this:
 |
 |# if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L \
 |     && !defined(__STDC_NO_ATOMICS__)
 |#  include <stdatomic.h>
 |#  define HAVE_C11_ATOMICS
 |# endif
 |
 |stdatomic.h is part of C11. A C11 compliant compiler should provide it
 |unless it also define __STDC_NO_ATOMICS__. Your compiler appears to be
 |claiming to be C11 compliant and has not defined __STC_NO_ATOMICS__ -
 |and yet the header file cannot be found.

Yes, no such on musl i think.  But i do not know.

 |Perhaps some kind of setup issue on your machine?

But then not on my alone.  The testing/openssl1.1/APKBUILD does

        perl ./Configure $_target --prefix=/usr \
                --libdir=lib \
                --openssldir=/etc/ssl \
                shared zlib $_optflags \
                -DOPENSSL_NO_ASYNC \
                $CPPFLAGS $CFLAGS $LDFLAGS -Wa,--noexecstack

It is likely that i copied that -Define from there back in May
too, but it was a prerelease, and i did not fixate the fix, and
then have forgotten about it.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From murugesh.pitchaiah at gmail.com  Wed Oct 17 13:29:21 2018
From: murugesh.pitchaiah at gmail.com (murugesh pitchaiah)
Date: Wed, 17 Oct 2018 18:59:21 +0530
Subject: [openssl-users] To disable CBC ciphers
In-Reply-To: <CAD7Ssm-roOek6X_Lj2UBC3qMOdhgufUpeqHprRZqXxv6bOeO4w@mail.gmail.com>
References: <CAD7Ssm-roOek6X_Lj2UBC3qMOdhgufUpeqHprRZqXxv6bOeO4w@mail.gmail.com>
Message-ID: <CAOu9RAdR2eG8LCY1sS3XhzFasP0MHg03F39KROekx1T+C7EbAw@mail.gmail.com>

Hi,

You may list down what ciphers configured : "openssl ciphers"
Choose CBC ciphers and add them to the list of 'ssl_ciphers' with "!"
prefix appended to current ssl_ciphers.

> ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:

Ref: https://serverfault.com/questions/692119/meaning-of-ssl-ciphers-line-on-nginx-conf

Thanks,
Murugesh P.


On 10/17/18, Kaushal Shriyan <kaushalshriyan at gmail.com> wrote:
> Hi,
>
> I have the below ssl settings in nginx.conf file and VAPT test has reported
> us to disable CBC ciphers
>
> ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;
>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
>
>
> openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS
> Linux release 7.3.1611 (Core)
>
> I will appreciate if someone can pitch in to help me understand to disable
> CBC ciphers
>
> Best Regards
>
> Kaushal
>

From matt at openssl.org  Wed Oct 17 13:40:23 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 17 Oct 2018 14:40:23 +0100
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <20181017130918._7Sz9%steffen@sdaoden.eu>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
 <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>
 <20181017124318.AuPzB%steffen@sdaoden.eu>
 <bf5f388d-1964-24c8-753b-0251a7412642@openssl.org>
 <20181017130918._7Sz9%steffen@sdaoden.eu>
Message-ID: <18466c3a-430a-f1cb-8277-1f742e1b44ae@openssl.org>



On 17/10/2018 14:09, Steffen Nurpmeso wrote:
> Matt Caswell wrote in <bf5f388d-1964-24c8-753b-0251a7412642 at openssl.org>:
>  |On 17/10/2018 13:43, Steffen Nurpmeso wrote:
>  |> Matt Caswell wrote in <cf8b85a3-af41-ba9c-92c4-f744666c7c76 at openssl.org>:
>  |>|On 17/10/2018 13:12, Steffen Nurpmeso wrote:
>  |>|> I have built final 1.1.1 yesterday on AlpineLinux musl after
>  |>|> running a prelease from end of May before.  My makefile rule for
>  |>|> this box is (excerpt)
>  |>|> 
>  |>|>         ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared \
>  |>|>                 no-deprecated no-async no-tests \
>  |>|>                 -DOPENSSL_NO_ASYNC \
>  |>|>                 -Wl,-rpath,'$(LIBRPATH)' &&\
>  |>|>         make &&\
>  |>|>         $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \
>  |>|> 
>  |>|> The -DOPENSSL_NO_ASYNC i had to add yesterday, no-async alone was
>  |>|> not enough.  (I have forgotten whether this was necessary in May,
>  |>|> but most likely not.)
>  |>|
>  |>|This shouldn't be necessary. What errors do you get if you don't include
>  |>|that?
>  |> 
>  |>   #?0[steffen at essex code.arena]$ MAKE=make make openssl-blade MYPREFIX=$H\
>  |>   OME/$USR/opt/.ossl-1.1.1
>  |>   cd openssl.git &&\
>  |>   if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
>  |>   ./config --prefix=/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl\
>  |>   -1.1.1 zlib-dynamic no-hw shared \
>  |>           no-deprecated no-async no-tests \
>  |>           -Wl,-rpath,'' &&\
>  |>   make &&\
>  |>    make install_sw &&  make install_ssldirs; \
>  ..
>  |>   -o crypto/asn1/a_sign.o crypto/asn1/a_sign.c
>  |>   In file included from crypto/asn1/a_sign.c:22:
>  |>   In file included from crypto/include/internal/evp_int.h:11:
>  |>   include/internal/refcount.h:21:12: fatal error: 'stdatomic.h' file \
>  |>   not found
>  |>   #  include <stdatomic.h>
>  |>              ^~~~~~~~~~~~~
>  |>   1 error generated.
>  |>   make[2]: *** [Makefile:955: crypto/asn1/a_sign.o] Error 1
>  |>   make[2]: Leaving directory '/home/steffen/code.arena/openssl.git'
>  |>   make[1]: *** [Makefile:171: all] Error 2
>  |>   make[1]: Leaving directory '/home/steffen/code.arena/openssl.git'
>  |>   Previous HEAD position was 1708e3e85b Prepare for 1.1.1 release
>  |>   Switched to branch 'arena-manager-null'
>  |
>  |And that problem goes away by specifying "-DOPENSSL_NO_ASYNC" to
>  |config????? That issue seems to have absolutely nothing to do with that
>  |define. None of the .c or .h files indicated in the error above
>  |reference it, nor do they have anything to do with the async functionality.
> 
> Yes, that is what i did!  I looked into the AlpineLinux abuild
> package system, and how they get it done, and after adding this
> define the building succeeded.
> 
>  |This problem seems to be environmental. The code in question looks like
>  |this:
>  |
>  |# if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L \
>  |     && !defined(__STDC_NO_ATOMICS__)
>  |#  include <stdatomic.h>
>  |#  define HAVE_C11_ATOMICS
>  |# endif
>  |
>  |stdatomic.h is part of C11. A C11 compliant compiler should provide it
>  |unless it also define __STDC_NO_ATOMICS__. Your compiler appears to be
>  |claiming to be C11 compliant and has not defined __STC_NO_ATOMICS__ -
>  |and yet the header file cannot be found.
> 
> Yes, no such on musl i think.  But i do not know.

This is definitely an environmental issue. I just installed an Alpine
Linux VM. I got the above error consistently when using clang as the
compiler (whether or not I added "-DOPENSSL_NO_ASYNC"). I got a
successful build if I used gcc instead of clang.

With clang I was able to build successfully after this:

$ apk add clang-dev

Matt



From matt at openssl.org  Wed Oct 17 14:37:53 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 17 Oct 2018 15:37:53 +0100
Subject: [openssl-users] sendmail, openssl 1.1.1, tls1.3
In-Reply-To: <AD926CFE-9AF2-452D-A58F-CCDAC0097AEA@dukhovni.org>
References: <1539625346.18482.5.camel@ns.five-ten-sg.com>
 <20181015193256.GC983@straasha.imrryr.org>
 <1539647379.18482.38.camel@ns.five-ten-sg.com>
 <02FF3DA0-BE87-4DF9-A1DA-904217A23325@dukhovni.org>
 <AD926CFE-9AF2-452D-A58F-CCDAC0097AEA@dukhovni.org>
Message-ID: <ea9ab292-0174-d44a-d2c6-71e8ae38e90a@openssl.org>



On 16/10/2018 05:19, Viktor Dukhovni wrote:
> [ Carl sent me the CA bundle off-list ]  With the provided CA bundle
> I was able to easily reproduce the same symptoms with:

Please can someone send me the same CA bundle so that I might also
reproduce this?

Thanks

Matt


> 
>  $ openssl s_client -requestCAfile bundle.pem -connect localhost:12345
> 
> Running this under a debugger the failure happens at certificate #143
> because the client hello packet overflows its maximum allocation:
> 
> $6 = {
>   buf = 0x0000000100724200
>   staticbuf = 0x0000000000000000 <no value available>
>   curr = 16364
>   written = 16364
>   maxsize = 16384
>   subs = 0x0000000100727700
> }
> 
> So even though the extension is allowed to be up to 2^16 bytes, it
> seems the client HELLO is expected to fit into a single TLS record
> of at most 16K bytes.
> 
> Given enough crud in the CA bundle, and a client misconfigured to
> to spill its guts to the server, by sending the names of all the
> trusted CAs, the limit is not too hard to exceed.
> 
> The work-around is to send *zero* CA names to the server, Sendmail
> SHOULD NOT configure the SSL_CTX for the client connection to with
> preferred CA names.  If that is not configurable, then keep the
> CA file as short as possible, empty if possible, else just one
> root CA, and everything else in CApath (yes "hashed" with the
> various symlinks in place to each cert, one per file).
> 
> As for the 16K limit, and whether we should be sending client
> CA names without further indication from the (TLS 1.3) client
> to do so, I'm hoping Matt Caswell and or other team members
> will chime in.
> 

From Mark.Shnaider at docusign.com  Wed Oct 17 15:12:54 2018
From: Mark.Shnaider at docusign.com (Mark Shnaider)
Date: Wed, 17 Oct 2018 15:12:54 +0000
Subject: [openssl-users]  openssl 1.1.1 Cannot find fucntion
Message-ID: <DM5PR04MB375325D92C6A2564E20B06888EFF0@DM5PR04MB3753.namprd04.prod.outlook.com>



Hello ,
I use openssl 1.1.1  and cannot find function :
 lh_X509_NAME_free, lh_X509_NAME_insert, lh_X509_NAME_retrieve referenced in function _SSL_load_client_CA_file in file ssl_cert.c
Please help me to solve this problem
Mark



From steffen at sdaoden.eu  Wed Oct 17 21:07:37 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 17 Oct 2018 23:07:37 +0200
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <18466c3a-430a-f1cb-8277-1f742e1b44ae@openssl.org>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
 <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>
 <20181017124318.AuPzB%steffen@sdaoden.eu>
 <bf5f388d-1964-24c8-753b-0251a7412642@openssl.org>
 <20181017130918._7Sz9%steffen@sdaoden.eu>
 <18466c3a-430a-f1cb-8277-1f742e1b44ae@openssl.org>
Message-ID: <20181017210737.V5fKZ%steffen@sdaoden.eu>

Good evening.

Matt Caswell wrote in <18466c3a-430a-f1cb-8277-1f742e1b44ae at openssl.org>:
 |On 17/10/2018 14:09, Steffen Nurpmeso wrote:
 |> Matt Caswell wrote in <bf5f388d-1964-24c8-753b-0251a7412642 at openssl.org>:
 |>|On 17/10/2018 13:43, Steffen Nurpmeso wrote:
 |>|> Matt Caswell wrote in <cf8b85a3-af41-ba9c-92c4-f744666c7c76 at openssl.org\
 |>|> >:
 |>|>|On 17/10/2018 13:12, Steffen Nurpmeso wrote:
 |>|>|> I have built final 1.1.1 yesterday on AlpineLinux musl after
 |>|>|> running a prelease from end of May before.  My makefile rule for
 |>|>|> this box is (excerpt)
 |>|>|> 
 |>|>|>         ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared \
 |>|>|>                 no-deprecated no-async no-tests \
 |>|>|>                 -DOPENSSL_NO_ASYNC \
 |>|>|>                 -Wl,-rpath,'$(LIBRPATH)' &&\
 |>|>|>         make &&\
 |>|>|>         $(SUDO) make install_sw && $(SUDO) make install_ssldirs; \
 |>|>|> 
 |>|>|> The -DOPENSSL_NO_ASYNC i had to add yesterday, no-async alone was
 |>|>|> not enough.  (I have forgotten whether this was necessary in May,
 |>|>|> but most likely not.)
 |>|>|
 |>|>|This shouldn't be necessary. What errors do you get if you don't \
 |>|>|include
 |>|>|that?
 |>|> 
 |>|>   #?0[steffen at essex code.arena]$ MAKE=make make openssl-blade MYPREFIX=\
 |>|>   $H\
 |>|>   OME/$USR/opt/.ossl-1.1.1
 |>|>   cd openssl.git &&\
 |>|>   if [ -f NULL ]; then git checkout `cat NULL`; fi &&\
 |>|>   ./config --prefix=/home/steffen/usr-essex-alpine-linux-x86_64/opt/.os\
 |>|>   sl\
 |>|>   -1.1.1 zlib-dynamic no-hw shared \
 |>|>           no-deprecated no-async no-tests \
 |>|>           -Wl,-rpath,'' &&\
 |>|>   make &&\
 |>|>    make install_sw &&  make install_ssldirs; \
 |>  ..
 |>|>   -o crypto/asn1/a_sign.o crypto/asn1/a_sign.c
 |>|>   In file included from crypto/asn1/a_sign.c:22:
 |>|>   In file included from crypto/include/internal/evp_int.h:11:
 |>|>   include/internal/refcount.h:21:12: fatal error: 'stdatomic.h' file \
 |>|>   not found
 |>|>   #  include <stdatomic.h>
 |>|>              ^~~~~~~~~~~~~
 |>|>   1 error generated.
 |>|>   make[2]: *** [Makefile:955: crypto/asn1/a_sign.o] Error 1
 |>|>   make[2]: Leaving directory '/home/steffen/code.arena/openssl.git'
 |>|>   make[1]: *** [Makefile:171: all] Error 2
 |>|>   make[1]: Leaving directory '/home/steffen/code.arena/openssl.git'
 |>|>   Previous HEAD position was 1708e3e85b Prepare for 1.1.1 release
 |>|>   Switched to branch 'arena-manager-null'
 |>|
 |>|And that problem goes away by specifying "-DOPENSSL_NO_ASYNC" to
 |>|config????? That issue seems to have absolutely nothing to do with that
 |>|define. None of the .c or .h files indicated in the error above
 |>|reference it, nor do they have anything to do with the async functionali\
 |>|ty.
 |> 
 |> Yes, that is what i did!  I looked into the AlpineLinux abuild
 |> package system, and how they get it done, and after adding this
 |> define the building succeeded.
 |> 
 |>|This problem seems to be environmental. The code in question looks like
 |>|this:
 |>|
 |>|# if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L \
 |>|     && !defined(__STDC_NO_ATOMICS__)
 |>|#  include <stdatomic.h>
 |>|#  define HAVE_C11_ATOMICS
 |>|# endif
 |>|
 |>|stdatomic.h is part of C11. A C11 compliant compiler should provide it
 |>|unless it also define __STDC_NO_ATOMICS__. Your compiler appears to be
 |>|claiming to be C11 compliant and has not defined __STC_NO_ATOMICS__ -
 |>|and yet the header file cannot be found.
 |> 
 |> Yes, no such on musl i think.  But i do not know.
 |
 |This is definitely an environmental issue. I just installed an Alpine
 |Linux VM. I got the above error consistently when using clang as the
 |compiler (whether or not I added "-DOPENSSL_NO_ASYNC"). I got a
 |successful build if I used gcc instead of clang.
 |
 |With clang I was able to build successfully after this:
 |
 |$ apk add clang-dev

Well.  I have reported that no-async alone does not disable
inclusion of (finally) stdatomic.h even though the build does not
need it.  If i add -DOPENSSL_NO_ASYNC on top of the no-async that
i have chosen, it builds fine.
Maybe the subject was to offensive or misleading, for which
i hereby apologize.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From matt at openssl.org  Wed Oct 17 21:40:42 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 17 Oct 2018 22:40:42 +0100
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <20181017210737.V5fKZ%steffen@sdaoden.eu>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
 <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>
 <20181017124318.AuPzB%steffen@sdaoden.eu>
 <bf5f388d-1964-24c8-753b-0251a7412642@openssl.org>
 <20181017130918._7Sz9%steffen@sdaoden.eu>
 <18466c3a-430a-f1cb-8277-1f742e1b44ae@openssl.org>
 <20181017210737.V5fKZ%steffen@sdaoden.eu>
Message-ID: <e3c0e393-4aea-edd2-ee88-476090bbe0c2@openssl.org>



On 17/10/2018 22:07, Steffen Nurpmeso wrote:
>  |
>  |This is definitely an environmental issue. I just installed an Alpine
>  |Linux VM. I got the above error consistently when using clang as the
>  |compiler (whether or not I added "-DOPENSSL_NO_ASYNC"). I got a
>  |successful build if I used gcc instead of clang.
>  |
>  |With clang I was able to build successfully after this:
>  |
>  |$ apk add clang-dev
> 
> Well.  I have reported that no-async alone does not disable
> inclusion of (finally) stdatomic.h even though the build does not
> need it.

The async feature and the inclusion of stdatomic.h are entirely
independent of each other. I would not expect no-async to disable the
inclusion of stdatomic.h.

The build does not *need* stdatomic.h, but you will get better
performance if you do. The build is supposed to detect whether the
compiler has support for it automatically and only include it if it
does. It seems to me that the default Alpine clang package is slightly
broken in this respect, in that it has the defines to indicate
stdatomic.h support, but actually you need to install another package to
get it.

>  If i add -DOPENSSL_NO_ASYNC on top of the no-async that
> i have chosen, it builds fine.

This bit I do not understand at all. It makes no sense to me - and I did
not see it in my testing on Alpine. Are you sure you're not building
with gcc in that build? It's the only thing I can think of. If that's
not the case then I have no clue.

> Maybe the subject was to offensive or misleading, for which
> i hereby apologize.

I'm not sure what you are apologising for? No offence has been taken
(did I say something to suggest that it had...if so then *I* apologise!).

Matt


From rwelty at nwtime.org  Thu Oct 18 02:31:50 2018
From: rwelty at nwtime.org (Richard Welty)
Date: Wed, 17 Oct 2018 22:31:50 -0400
Subject: [openssl-users] reasons for negative return value from
	BIO_do_connect
In-Reply-To: <915b95fe-4ed5-b103-95a0-a2125685a56d@nwtime.org>
References: <915b95fe-4ed5-b103-95a0-a2125685a56d@nwtime.org>
Message-ID: <f785df24-1ef6-cba8-3b4f-f93120403600@nwtime.org>

On 10/16/18 1:44 PM, Richard Welty wrote:
> i'm trying to figure out why BIO_do_connect is failing with
> a negative value. so far as i know i've done all preliminaries
> correctly, but apparently i've missed something. i am dumping
> the SSL errors from ERR_get_error but am not getting any in
> this instance.
does anyone have any suggestions what to look for? i'm very short
of time for resolving this.

thanks,
? richard

From best.sakthi3 at gmail.com  Thu Oct 18 10:08:42 2018
From: best.sakthi3 at gmail.com (sakdev)
Date: Thu, 18 Oct 2018 03:08:42 -0700 (MST)
Subject: [openssl-users] Openssl Build Error- module unsafe for SAFESEH
 image/Unable to generate SAFESEH image
Message-ID: <1539857322075-0.post@n7.nabble.com>

Hi, 

We are using openssl-1.0.2j. For security compliance we scanned libeay32.dll
with binscope binary analyzer. Binscope result is showing *?SafeSEHCheck
(FAIL)?*.

To resolve this we added /SAFESEH flag in linker flags, and started build.
But build got failed with "Unable to generate SAFESEH image" error.

We are building openssl in VS2015 developer command prompt. How we can
resolve this error? Is OPenssl-1.0.2j is compatible with SAFESEH image?

ERROR
<http://openssl.6102.n7.nabble.com/file/t11154/OpensslBuildError.png> 


Thanks.



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

From usmanov at ieml.ru  Thu Oct 18 10:08:58 2018
From: usmanov at ieml.ru (=?windows-1251?B?0/Hs4O3u4iDA5+DyIMDt4uDw7uLo9w==?=)
Date: Thu, 18 Oct 2018 10:08:58 +0000
Subject: [openssl-users] Manually checking against ocsp.comodoca.com
	producess an error
Message-ID: <AM5PR0301MB23248717EF8B2F0CA886A13CA3F80@AM5PR0301MB2324.eurprd03.prod.outlook.com>

Hi! I'm trying to manually check ocsp with ocsp utility with OpenSSL 1.1.1 ,I'm receiving an error

 openssl version
OpenSSL 1.1.1  11 Sep 2018


 openssl ocsp -no_nonce -header Host=ocsp.comodoca.com -issuer issuer.crt -cert /home/idis/STAR_ieml_ru.crt -url http://ocsp.comodoca.com/ -CAfile issuer.crt
Error querying OCSP responder
140179987232512:error:27076072:OCSP routines:parse_http_line1:server response error:crypto/ocsp/ocsp_ht.c:260:Code=301
when I try to access ocsp.url via wget I get strange result

# wget http://ocsp.comodoca.com/
--2018-10-18 12:57:53--  http://ocsp.comodoca.com/
??????????????? ?????????? ? 192.168.1.2:3128... ?????????? ???????????.
?????? Proxy ??????, ????????? ?????... 200 OK
?????: 5 [application/ocsp-response]
Saving to: ?index.html.8?

100%[===================================================================================================================================================================================================>] 5           --.-K/s   ? 0s

2018-10-18 12:57:54 (483 KB/s) - ?index.html.8? saved [5/5]

[root] ~# less index.html.8
0^C
^A^A
index.html.8 (END)

Any idea what is going on here?

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

From Michael.Wojcik at microfocus.com  Thu Oct 18 11:32:45 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 18 Oct 2018 11:32:45 +0000
Subject: [openssl-users] Openssl Build Error- module unsafe for SAFESEH
 image/Unable to generate SAFESEH image
In-Reply-To: <1539857322075-0.post@n7.nabble.com>
References: <1539857322075-0.post@n7.nabble.com>
Message-ID: <MWHPR18MB10379CEEC5942DC92167E360F9F80@MWHPR18MB1037.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of sakdev
> Sent: Thursday, October 18, 2018 06:09
>
> To resolve this we added /SAFESEH flag in linker flags, and started build.
> But build got failed with "Unable to generate SAFESEH image" error.

You appear to have added /SAFESEH to the generic linker flags, so it's being used for both x86 (32-bit) and x64 (64-bit). It's only allowed for x86. The error you showed (and, by the way, it's better to copy and paste text than to send a screenshot) is for the x64 build.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From best.sakthi3 at gmail.com  Thu Oct 18 12:34:38 2018
From: best.sakthi3 at gmail.com (sakdev)
Date: Thu, 18 Oct 2018 05:34:38 -0700 (MST)
Subject: [openssl-users] Openssl Build Error- module unsafe for SAFESEH
 image/Unable to generate SAFESEH image
In-Reply-To: <MWHPR18MB10379CEEC5942DC92167E360F9F80@MWHPR18MB1037.namprd18.prod.outlook.com>
References: <1539857322075-0.post@n7.nabble.com>
 <MWHPR18MB10379CEEC5942DC92167E360F9F80@MWHPR18MB1037.namprd18.prod.outlook.com>
Message-ID: <1539866078628-0.post@n7.nabble.com>

Thanks for reply Michael. 

I am sure i gave 32-bit build only. "BuildWinLibs.bat vs2015 x32d clean"
This is the comment i gave for build. Here "x32r" means 32-bit release
build.

Here is the error code(text).


        rc /fo"tmp32dll/MSVC14.0\libeay32.res" /d CRYPTO ms\version32.rc
Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
Copyright (C) Microsoft Corporation.  All rights reserved.

        link /nologo /subsystem:console /opt:ref /safeseh /debug /dll
/out:out32
dll/MSVC14.0\libeay32.dll /def:ms/LIBEAY32.def
@C:\Users\SAKTHI~1\AppData\Local\
Temp\nm973D.tmp
x86cpuid.obj : error LNK2026: module unsafe for SAFESEH image.
md5-586.obj : error LNK2026: module unsafe for SAFESEH image.
sha1-586.obj : error LNK2026: module unsafe for SAFESEH image.
sha256-586.obj : error LNK2026: module unsafe for SAFESEH image.
sha512-586.obj : error LNK2026: module unsafe for SAFESEH image.
rmd-586.obj : error LNK2026: module unsafe for SAFESEH image.
bf-586.obj : error LNK2026: module unsafe for SAFESEH image.
cast-586.obj : error LNK2026: module unsafe for SAFESEH image.
aes-586.obj : error LNK2026: module unsafe for SAFESEH image.
vpaes-x86.obj : error LNK2026: module unsafe for SAFESEH image.
aesni-x86.obj : error LNK2026: module unsafe for SAFESEH image.
cmll-x86.obj : error LNK2026: module unsafe for SAFESEH image.
ghash-x86.obj : error LNK2026: module unsafe for SAFESEH image.
bn-586.obj : error LNK2026: module unsafe for SAFESEH image.
co-586.obj : error LNK2026: module unsafe for SAFESEH image.
x86-mont.obj : error LNK2026: module unsafe for SAFESEH image.
x86-gf2m.obj : error LNK2026: module unsafe for SAFESEH image.
wp-mmx.obj : error LNK2026: module unsafe for SAFESEH image.
   Creating library out32dll/MSVC14.0\libeay32.lib and object
out32dll/MSVC14.0\
libeay32.exp
out32dll/MSVC14.0\libeay32.dll : fatal error LNK1281: Unable to generate
SAFESEH
 image.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
14.0
\VC\BIN\link.EXE"' : return code '0x501'
Stop.

"nmake -f .\ms\ntdll_WIN32_REL.mak install"

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

        perl .\util\copy-if-different.pl ".\crypto\opensslconf.h"
"inc32\openssl
\opensslconf.h"
NOT copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h
        link /nologo /subsystem:console /opt:ref /safeseh /debug /dll
/out:out32
dll/MSVC14.0\libeay32.dll /def:ms/LIBEAY32.def
@C:\Users\SAKTHI~1\AppData\Local\
Temp\nmA0DE.tmp
x86cpuid.obj : error LNK2026: module unsafe for SAFESEH image.
md5-586.obj : error LNK2026: module unsafe for SAFESEH image.
sha1-586.obj : error LNK2026: module unsafe for SAFESEH image.
sha256-586.obj : error LNK2026: module unsafe for SAFESEH image.
sha512-586.obj : error LNK2026: module unsafe for SAFESEH image.
rmd-586.obj : error LNK2026: module unsafe for SAFESEH image.
bf-586.obj : error LNK2026: module unsafe for SAFESEH image.
cast-586.obj : error LNK2026: module unsafe for SAFESEH image.
aes-586.obj : error LNK2026: module unsafe for SAFESEH image.
vpaes-x86.obj : error LNK2026: module unsafe for SAFESEH image.
aesni-x86.obj : error LNK2026: module unsafe for SAFESEH image.
cmll-x86.obj : error LNK2026: module unsafe for SAFESEH image.
ghash-x86.obj : error LNK2026: module unsafe for SAFESEH image.
bn-586.obj : error LNK2026: module unsafe for SAFESEH image.
co-586.obj : error LNK2026: module unsafe for SAFESEH image.
x86-mont.obj : error LNK2026: module unsafe for SAFESEH image.
x86-gf2m.obj : error LNK2026: module unsafe for SAFESEH image.
wp-mmx.obj : error LNK2026: module unsafe for SAFESEH image.
   Creating library out32dll/MSVC14.0\libeay32.lib and object
out32dll/MSVC14.0\
libeay32.exp
out32dll/MSVC14.0\libeay32.dll : fatal error LNK1281: Unable to generate
SAFESEH
 image.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
14.0
\VC\BIN\link.EXE"' : return code '0x501'
Stop.


"COMPLETED."



Regards,
Sakthi.




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

From steffen at sdaoden.eu  Thu Oct 18 12:53:10 2018
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Thu, 18 Oct 2018 14:53:10 +0200
Subject: [openssl-users] no-async needs -DOPENSSL_NO_ASYNC nonetheless?
In-Reply-To: <e3c0e393-4aea-edd2-ee88-476090bbe0c2@openssl.org>
References: <20181017121246.cUHhK%steffen@sdaoden.eu>
 <cf8b85a3-af41-ba9c-92c4-f744666c7c76@openssl.org>
 <20181017124318.AuPzB%steffen@sdaoden.eu>
 <bf5f388d-1964-24c8-753b-0251a7412642@openssl.org>
 <20181017130918._7Sz9%steffen@sdaoden.eu>
 <18466c3a-430a-f1cb-8277-1f742e1b44ae@openssl.org>
 <20181017210737.V5fKZ%steffen@sdaoden.eu>
 <e3c0e393-4aea-edd2-ee88-476090bbe0c2@openssl.org>
Message-ID: <20181018125310.UM-oC%steffen@sdaoden.eu>

Matt Caswell wrote in <e3c0e393-4aea-edd2-ee88-476090bbe0c2 at openssl.org>:
 |On 17/10/2018 22:07, Steffen Nurpmeso wrote:
 |>|
 |>|This is definitely an environmental issue. I just installed an Alpine
 |>|Linux VM. I got the above error consistently when using clang as the
 |>|compiler (whether or not I added "-DOPENSSL_NO_ASYNC"). I got a
 |>|successful build if I used gcc instead of clang.
 |>|
 |>|With clang I was able to build successfully after this:
 |>|
 |>|$ apk add clang-dev
 |> 
 |> Well.  I have reported that no-async alone does not disable
 |> inclusion of (finally) stdatomic.h even though the build does not
 |> need it.
 |
 |The async feature and the inclusion of stdatomic.h are entirely
 |independent of each other. I would not expect no-async to disable the
 |inclusion of stdatomic.h.
 |
 |The build does not *need* stdatomic.h, but you will get better
 |performance if you do. The build is supposed to detect whether the
 |compiler has support for it automatically and only include it if it
 |does. It seems to me that the default Alpine clang package is slightly
 |broken in this respect, in that it has the defines to indicate
 |stdatomic.h support, but actually you need to install another package to
 |get it.
 |
 |>  If i add -DOPENSSL_NO_ASYNC on top of the no-async that
 |> i have chosen, it builds fine.
 |
 |This bit I do not understand at all. It makes no sense to me - and I did
 |not see it in my testing on Alpine. Are you sure you're not building
 |with gcc in that build? It's the only thing I can think of. If that's
 |not the case then I have no clue.

  clang  -I. -Icrypto/include -Iinclude -fPIC -pthread -m64 -Wa,--noexecstack -Qunused-arguments -Wall -O3 -DOPENSSL_USE_NODELETE -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl-1.1.1/ssl\"" -DENGINESDIR="\"/home/steffen/usr-essex-alpine-linux-x86_64/opt/.ossl-1.1.1/lib/engines-1.1\"" -DZLIB -DZLIB_SHARED -DNDEBUG -DOPENSSL_API_COMPAT=0x10100000L -DOPENSSL_NO_ASYNC -MMD -MF crypto/asn1/a_sign.d.tmp -MT crypto/asn1/a_sign.o -c -o crypto/asn1/a_sign.o crypto/asn1/a_sign.c       
  In file included from crypto/asn1/a_sign.c:22:
  In file included from crypto/include/internal/evp_int.h:11:
  include/internal/refcount.h:21:12: fatal error: 'stdatomic.h' file not found
  #  include <stdatomic.h>
             ^~~~~~~~~~~~~
  1 error generated.
  make[2]: *** [Makefile:955: crypto/asn1/a_sign.o] Error 1
  make[2]: Leaving directory '/home/steffen/code.arena/openssl.git'
  make[1]: *** [Makefile:171: all] Error 2
  make[1]: Leaving directory '/home/steffen/code.arena/openssl.git'

Thanks for your contiguous support.

 |> Maybe the subject was to offensive or misleading, for which
 |> i hereby apologize.
 |
 |I'm not sure what you are apologising for? No offence has been taken
 |(did I say something to suggest that it had...if so then *I* apologise!).

I am refreshing my apoligize, but transpose it to a different
topic.  Thank you.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From jb-openssl at wisemo.com  Thu Oct 18 14:24:59 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 18 Oct 2018 16:24:59 +0200
Subject: [openssl-users] Openssl Build Error- module unsafe for SAFESEH
 image/Unable to generate SAFESEH image
In-Reply-To: <1539866078628-0.post@n7.nabble.com>
References: <1539857322075-0.post@n7.nabble.com>
 <MWHPR18MB10379CEEC5942DC92167E360F9F80@MWHPR18MB1037.namprd18.prod.outlook.com>
 <1539866078628-0.post@n7.nabble.com>
Message-ID: <66e4b883-7e88-4b6f-f112-a2dc5672d06d@wisemo.com>

SAFESEH requires any code that sets up Win32/i386 SEH handlers
to include special assembler directives to add the handler code
address to a special list which the linker then puts in the
compiled program for the Windows runtime (NTDLL.DLL etc.) to
check to make sure it is only calling back to your real handler
and not to one added by a buffer overflow attack on your process.

For C/C++ code, the compiler uses only handlers in the C runtime,
each of which already include those directives.? But for Assembler
source code (such as the optimized assembler modules in OpenSSL),
there is no way to automatically detect if the code sets up any
unofficial SEH handlers.? So instead, the linker looks for a special
flag placed in the .obj files to indicate that the programmer
indicated that they did whatever necessary (which may be nothing
if the modules don't set up their own SEH handlers).

For MASM (recent versions), this means passing "/safeseh" on the
assembler command line and adding the .SAFESEH directive for any
SEH handlers defined in the .asm file:

HandlerEntrypointSymbol PROC NEAR
 ? ; Example "nothing handled" Handler:
 ? XOR EAX,EAX
 ? INC EAX
 ? RETN 10h
HandlerEntrypointSymbol ENDP
.SAFESEH HandlerEntrypointSymbol

Note that this only applies to the file that implements the
handler, not the files that push its address on the stack.

I haven't checked, but I don't think any of the OpenSSL .asm files
for Win32/i386 actually implement any handlers, so just the command
line switch is probably enough, but someone from the OpenSSL team
needs to confirm this.

On 18/10/2018 14:34, sakdev wrote:
> Thanks for reply Michael.
>
> I am sure i gave 32-bit build only. "BuildWinLibs.bat vs2015 x32d clean"
> This is the comment i gave for build. Here "x32r" means 32-bit release
> build.
>
> Here is the error code(text).
>
>
>          rc /fo"tmp32dll/MSVC14.0\libeay32.res" /d CRYPTO ms\version32.rc
> Microsoft (R) Windows (R) Resource Compiler Version 10.0.10011.16384
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>          link /nologo /subsystem:console /opt:ref /safeseh /debug /dll
> /out:out32
> dll/MSVC14.0\libeay32.dll /def:ms/LIBEAY32.def
> @C:\Users\SAKTHI~1\AppData\Local\
> Temp\nm973D.tmp
> x86cpuid.obj : error LNK2026: module unsafe for SAFESEH image.
> md5-586.obj : error LNK2026: module unsafe for SAFESEH image.
> sha1-586.obj : error LNK2026: module unsafe for SAFESEH image.
> sha256-586.obj : error LNK2026: module unsafe for SAFESEH image.
> sha512-586.obj : error LNK2026: module unsafe for SAFESEH image.
> rmd-586.obj : error LNK2026: module unsafe for SAFESEH image.
> bf-586.obj : error LNK2026: module unsafe for SAFESEH image.
> cast-586.obj : error LNK2026: module unsafe for SAFESEH image.
> aes-586.obj : error LNK2026: module unsafe for SAFESEH image.
> vpaes-x86.obj : error LNK2026: module unsafe for SAFESEH image.
> aesni-x86.obj : error LNK2026: module unsafe for SAFESEH image.
> cmll-x86.obj : error LNK2026: module unsafe for SAFESEH image.
> ghash-x86.obj : error LNK2026: module unsafe for SAFESEH image.
> bn-586.obj : error LNK2026: module unsafe for SAFESEH image.
> co-586.obj : error LNK2026: module unsafe for SAFESEH image.
> x86-mont.obj : error LNK2026: module unsafe for SAFESEH image.
> x86-gf2m.obj : error LNK2026: module unsafe for SAFESEH image.
> wp-mmx.obj : error LNK2026: module unsafe for SAFESEH image.
>     Creating library out32dll/MSVC14.0\libeay32.lib and object
> out32dll/MSVC14.0\
> libeay32.exp
> out32dll/MSVC14.0\libeay32.dll : fatal error LNK1281: Unable to generate
> SAFESEH
>   image.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
> 14.0
> \VC\BIN\link.EXE"' : return code '0x501'
> Stop.
>
> "nmake -f .\ms\ntdll_WIN32_REL.mak install"
>
> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
>          perl .\util\copy-if-different.pl ".\crypto\opensslconf.h"
> "inc32\openssl
> \opensslconf.h"
> NOT copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h
>          link /nologo /subsystem:console /opt:ref /safeseh /debug /dll
> /out:out32
> dll/MSVC14.0\libeay32.dll /def:ms/LIBEAY32.def
> @C:\Users\SAKTHI~1\AppData\Local\
> Temp\nmA0DE.tmp
> x86cpuid.obj : error LNK2026: module unsafe for SAFESEH image.
> md5-586.obj : error LNK2026: module unsafe for SAFESEH image.
> sha1-586.obj : error LNK2026: module unsafe for SAFESEH image.
> sha256-586.obj : error LNK2026: module unsafe for SAFESEH image.
> sha512-586.obj : error LNK2026: module unsafe for SAFESEH image.
> rmd-586.obj : error LNK2026: module unsafe for SAFESEH image.
> bf-586.obj : error LNK2026: module unsafe for SAFESEH image.
> cast-586.obj : error LNK2026: module unsafe for SAFESEH image.
> aes-586.obj : error LNK2026: module unsafe for SAFESEH image.
> vpaes-x86.obj : error LNK2026: module unsafe for SAFESEH image.
> aesni-x86.obj : error LNK2026: module unsafe for SAFESEH image.
> cmll-x86.obj : error LNK2026: module unsafe for SAFESEH image.
> ghash-x86.obj : error LNK2026: module unsafe for SAFESEH image.
> bn-586.obj : error LNK2026: module unsafe for SAFESEH image.
> co-586.obj : error LNK2026: module unsafe for SAFESEH image.
> x86-mont.obj : error LNK2026: module unsafe for SAFESEH image.
> x86-gf2m.obj : error LNK2026: module unsafe for SAFESEH image.
> wp-mmx.obj : error LNK2026: module unsafe for SAFESEH image.
>     Creating library out32dll/MSVC14.0\libeay32.lib and object
> out32dll/MSVC14.0\
> libeay32.exp
> out32dll/MSVC14.0\libeay32.dll : fatal error LNK1281: Unable to generate
> SAFESEH
>   image.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
> 14.0
> \VC\BIN\link.EXE"' : return code '0x501'
> Stop.
>
>
> "COMPLETED."
>

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 blaufish.public.email at gmail.com  Thu Oct 18 14:27:49 2018
From: blaufish.public.email at gmail.com (Peter Magnusson)
Date: Thu, 18 Oct 2018 16:27:49 +0200
Subject: [openssl-users] openssl ca pkcs11 UI_set_result_ex:result too
 large:crypto/ui/ui_lib.c:910:You must type in 4 to 32 characters
In-Reply-To: <20181017.101328.1330160527459170334.levitte@openssl.org>
References: <CANtcRX50e0bEwbG=U7L5bKif1StaEEny-01Bq7OfoO0xFvFC9Q@mail.gmail.com>
 <20181016.102306.441641370921958907.levitte@openssl.org>
 <CANtcRX4xLxcOVa0iszyo4RLBuFxa7BenA2OZw9QA-KP-=BAzpQ@mail.gmail.com>
 <20181017.101328.1330160527459170334.levitte@openssl.org>
Message-ID: <CANtcRX6ZatC0SNd+iNi8CHDi1XkPYx7Qe+uFGY0TDC1RzX3tjw@mail.gmail.com>

Thanks =)

This is similar to other commands, e.g. ssh, tpm2-tools, etc
inconsistencies between different flags between different
sub-commands.

Getting it right the first time is easier said than done and changing
command line behaviour later on breaks user scripts etc.

//P
On Wed, Oct 17, 2018 at 10:13 AM Richard Levitte <levitte at openssl.org> wrote:
>
> In message <CANtcRX4xLxcOVa0iszyo4RLBuFxa7BenA2OZw9QA-KP-=BAzpQ at mail.gmail.com> on Tue, 16 Oct 2018 10:34:31 +0200, Peter Magnusson <blaufish.public.email at gmail.com> said:
>
> > Sorry, I am an idiot =)
>
> No you're not.
>
> > Problem resolved, user error.  -key was the problem and should not be
> > used as I showed.
> >
> > -key has a different meaning for openssl ca than for openssl req, so
> > my PIN was my -key argument. It got my keyfile from the openssl conf
> > file.
>
> And this is precisely why you're not an idiot.  We're not consistent
> between openssl sub-commands, so no wonder you get confused.  It's a
> pattern thing, we catch on to similar patterns (such as option names).
>
> We really should look over those options...  (but with all the other
> stuff we have going on, I'm afraid this isn't the highest on our
> priority list)
>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From matt at openssl.org  Fri Oct 19 09:34:27 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Oct 2018 10:34:27 +0100
Subject: [openssl-users] Browsers deprecating TLS1.1 and TLS1.0
Message-ID: <426d2d71-f9c0-09f6-35c3-043e3d1b41d1@openssl.org>

In case you haven't seen these:

https://security.googleblog.com/2018/10/modernizing-transport-security.html

Summary: TLS1.0/TLS1.1 will be disabled in Chrome 81 in early 2020


https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/

Summary: Firefox will disable TLS1.0/TLS1.1 in March 2020


https://webkit.org/blog/8462/deprecation-of-legacy-tls-1-0-and-1-1-versions/

Summary: TLS1.0/TLS1.1. support will be removed from Safari in March 2020


https://blogs.windows.com/msedgedev/2018/10/15/modernizing-tls-edge-ie11/

Summary: Internet Explorer/Edge support for TLS1.0/TLS1.1 will be
removed in the first half of 2020.


Matt

From skip at taygeta.com  Fri Oct 19 19:03:44 2018
From: skip at taygeta.com (Skip Carter)
Date: Fri, 19 Oct 2018 12:03:44 -0700
Subject: [openssl-users] What to do with deprecation errors
Message-ID: <1539975824.4886.3.camel@taygeta.com>

Hello all,

I recently installed from source, openssl-1.1.1 on a Debian box (like
most distributions the Debian version is quite old and my application
needs very recent libraries).  It built and installed without warnings
or errors (Thanks to all concerned in creating software that can do
that).

However when I try to compile an application that uses the library, I
get the following compile time error:

/usr/include/openssl/ec.h:274:1: error: expected constructor,
destructor, or type conversion before ?DEPRECATEDIN_1_2_0?
?DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GFp(const EC_GROUP *group,
BIGNUM *p,

(and other similar errors)

Can anybody tell me what is wrong ?

I it feels like I am missing some compiler flags (I am using nothing
special: -Wall -Wextra -Wpedantic).

Thanks,

-- 
Skip Carter
Taygeta Scientific Inc.

From matt at openssl.org  Fri Oct 19 21:54:56 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Oct 2018 22:54:56 +0100
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1539975824.4886.3.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
Message-ID: <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>



On 19/10/2018 20:03, Skip Carter wrote:
> Hello all,
> 
> I recently installed from source, openssl-1.1.1 on a Debian box (like
> most distributions the Debian version is quite old and my application
> needs very recent libraries).  It built and installed without warnings
> or errors (Thanks to all concerned in creating software that can do
> that).
> 
> However when I try to compile an application that uses the library, I
> get the following compile time error:
> 
> /usr/include/openssl/ec.h:274:1: error: expected constructor,
> destructor, or type conversion before ?DEPRECATEDIN_1_2_0?
> ?DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GFp(const EC_GROUP *group,
> BIGNUM *p,

It looks like its not picking up the definition of the
DEPRECATEDIN_1_2_0 macro for some reason.

That macro should be defined in opensslconf.h (which is included from
ec.h), and looks like this:

/*
 * Do not deprecate things to be deprecated in version 1.2.0 before the
 * OpenSSL version number matches.
 */
#if OPENSSL_VERSION_NUMBER < 0x10200000L
# define DEPRECATEDIN_1_2_0(f)   f;
#elif OPENSSL_API_COMPAT < 0x10200000L
# define DEPRECATEDIN_1_2_0(f)   DECLARE_DEPRECATED(f)
#else
# define DEPRECATEDIN_1_2_0(f)
#endif


And where OPENSSL_VERSION_NUMBER is declared in opensslv.h (which is
included from opensslconf.h). Since 1.1.1 is less than 1.2.0, the first
definition of DEPRECATEDIN_1_2_0 should apply, i.e. this macro should
effectively be ignored and the parameter should be processed just like
any other function declaration.

So do you have an opensslconf.h? And does it have that macro defined in
it? My theory is that somehow or other you are picking up an old version
of that header (maybe the system version) which doesn't have the macro
defined.

Matt

> 
> (and other similar errors)
> 
> Can anybody tell me what is wrong ?
> 
> I it feels like I am missing some compiler flags (I am using nothing
> special: -Wall -Wextra -Wpedantic).
> 
> Thanks,
> 

From skip at taygeta.com  Fri Oct 19 23:54:24 2018
From: skip at taygeta.com (Skip Carter)
Date: Fri, 19 Oct 2018 16:54:24 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
Message-ID: <1539993264.4886.8.camel@taygeta.com>

On Fri, 2018-10-19 at 22:54 +0100, Matt Caswell wrote:
> 
> 
> It looks like its not picking up the definition of the
> DEPRECATEDIN_1_2_0 macro for some reason.
> 
> That macro should be defined in opensslconf.h (which is included from
> ec.h), and looks like this:
> 
> /*
> ?* Do not deprecate things to be deprecated in version 1.2.0 before
> the
> ?* OpenSSL version number matches.
> ?*/
> #if OPENSSL_VERSION_NUMBER < 0x10200000L
> # define DEPRECATEDIN_1_2_0(f)???f;
> #elif OPENSSL_API_COMPAT < 0x10200000L
> # define DEPRECATEDIN_1_2_0(f)???DECLARE_DEPRECATED(f)
> #else
> # define DEPRECATEDIN_1_2_0(f)
> #endif

> 
> And where OPENSSL_VERSION_NUMBER is declared in opensslv.h (which is
> included from opensslconf.h). Since 1.1.1 is less than 1.2.0, the
> first
> definition of DEPRECATEDIN_1_2_0 should apply, i.e. this macro should
> effectively be ignored and the parameter should be processed just
> like
> any other function declaration.
> 
> So do you have an opensslconf.h? And does it have that macro defined
> in
> it? My theory is that somehow or other you are picking up an old
> version
> of that header (maybe the system version) which doesn't have the
> macro
> defined.
> 
> Matt
> 

I found:

opensslv.h:# define OPENSSL_VERSION_NUMBER??0x1010100fL

Also to be sure my compilation environment isn't doing anything funky:

#include <stdio.h>

#include <openssl/opensslv.h>

int main(void)
{
??
? printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
??
? return 0;
}

gave me the same thing.



-- 
Skip Carter
Taygeta Scientific Inc.

From kaushalshriyan at gmail.com  Sat Oct 20 13:59:29 2018
From: kaushalshriyan at gmail.com (Kaushal Shriyan)
Date: Sat, 20 Oct 2018 19:29:29 +0530
Subject: [openssl-users] To disable CBC ciphers
In-Reply-To: <CAOu9RAdR2eG8LCY1sS3XhzFasP0MHg03F39KROekx1T+C7EbAw@mail.gmail.com>
References: <CAD7Ssm-roOek6X_Lj2UBC3qMOdhgufUpeqHprRZqXxv6bOeO4w@mail.gmail.com>
 <CAOu9RAdR2eG8LCY1sS3XhzFasP0MHg03F39KROekx1T+C7EbAw@mail.gmail.com>
Message-ID: <CAD7Ssm_UoJAg0DBedRNxkU0ZhHr2TWJjF2BTpRR5HSF8PMax9w@mail.gmail.com>

On Wed, Oct 17, 2018 at 7:00 PM murugesh pitchaiah <
murugesh.pitchaiah at gmail.com> wrote:

> Hi,
>
> You may list down what ciphers configured : "openssl ciphers"
> Choose CBC ciphers and add them to the list of 'ssl_ciphers' with "!"
> prefix appended to current ssl_ciphers.
>
> > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
>
> Ref:
> https://serverfault.com/questions/692119/meaning-of-ssl-ciphers-line-on-nginx-conf
>
> Thanks,
> Murugesh P.
>
>
> On 10/17/18, Kaushal Shriyan <kaushalshriyan at gmail.com> wrote:
> > Hi,
> >
> > I have the below ssl settings in nginx.conf file and VAPT test has
> reported
> > us to disable CBC ciphers
> >
> > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;
> >> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> >
> >
> > openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS
> > Linux release 7.3.1611 (Core)
> >
> > I will appreciate if someone can pitch in to help me understand to
> disable
> > CBC ciphers
> >
> > Best Regards
> >
> > Kaushal
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


Thanks Murugesh. I did checked openssl ciphers
https://www.openssl.org/docs/man1.0.2/apps/ciphers.html and could not see
!AAA_CBC_BBB as mentioned in your email.

ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:


Correct me if i am understanding it wrong. Basically i want to disable
Cipher Block Chaining (CBC) mode cipher encryption. Openssl and OS version
are as below :-

openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on CentOS
> Linux release 7.3.1611 (Core)


Any tools which i can run to find out vulnerabilities in the above openssl
and OS version? Please guide and i look forward to hearing from you. Thanks
in Advance.

Best Regards,

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

From skip at taygeta.com  Sat Oct 20 18:51:46 2018
From: skip at taygeta.com (Skip Carter)
Date: Sat, 20 Oct 2018 11:51:46 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1539993264.4886.8.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com>
Message-ID: <1540061506.4886.12.camel@taygeta.com>

All,

I am thinking that the DEPRECATED... macros are not expanded by the
pre-parser so the compiler sees them as a weirdly formed function and
doesn't like it.

I "installed" the header files with 'cp' was there a make command that
I was supposed to use ?

 
On Fri, 2018-10-19 at 16:54 -0700, Skip Carter wrote:
> On Fri, 2018-10-19 at 22:54 +0100, Matt Caswell wrote:
> > 
> > 
> > It looks like its not picking up the definition of the
> > DEPRECATEDIN_1_2_0 macro for some reason.
> > 
> > That macro should be defined in opensslconf.h (which is included
> > from
> > ec.h), and looks like this:
> > 
> > /*
> > ?* Do not deprecate things to be deprecated in version 1.2.0 before
> > the
> > ?* OpenSSL version number matches.
> > ?*/
> > #if OPENSSL_VERSION_NUMBER < 0x10200000L
> > # define DEPRECATEDIN_1_2_0(f)???f;
> > #elif OPENSSL_API_COMPAT < 0x10200000L
> > # define DEPRECATEDIN_1_2_0(f)???DECLARE_DEPRECATED(f)
> > #else
> > # define DEPRECATEDIN_1_2_0(f)
> > #endif
> > 
> > And where OPENSSL_VERSION_NUMBER is declared in opensslv.h (which
> > is
> > included from opensslconf.h). Since 1.1.1 is less than 1.2.0, the
> > first
> > definition of DEPRECATEDIN_1_2_0 should apply, i.e. this macro
> > should
> > effectively be ignored and the parameter should be processed just
> > like
> > any other function declaration.
> > 
> > So do you have an opensslconf.h? And does it have that macro
> > defined
> > in
> > it? My theory is that somehow or other you are picking up an old
> > version
> > of that header (maybe the system version) which doesn't have the
> > macro
> > defined.
> > 
> > Matt
> > 
> 
> I found:
> 
> opensslv.h:# define OPENSSL_VERSION_NUMBER??0x1010100fL
> 
> Also to be sure my compilation environment isn't doing anything
> funky:
> 
> #include <stdio.h>
> 
> #include <openssl/opensslv.h>
> 
> int main(void)
> {
> ??
> ? printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
> ??
> ? return 0;
> }
> 
> gave me the same thing.
> 
> 
> 
> --?
> Skip Carter
> Taygeta Scientific Inc.
-- 
Skip Carter
Taygeta Scientific Inc.


From uri at ll.mit.edu  Sun Oct 21 00:36:28 2018
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Sun, 21 Oct 2018 00:36:28 +0000
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540061506.4886.12.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
Message-ID: <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>

I'm not sure I understand what you're doing, but:

$ cat ttt.c
#include <stdio.h>
#include <openssl/opensslv.h>

int main(void)
{
  printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
  return 0;
}
$ gcc -o ttt ttt.c -lcrypto
$ ./ttt
OPENSSL_VERSION_NUMBER 1000210f
$ gcc -o ttt -I$HOME/openssl-1.1/include ttt.c -L$HOME/openssl-1.1/lib -lcrypto
$ ./ttt
OPENSSL_VERSION_NUMBER 10101010
$

--
Regards,
Uri 

?On 10/20/2018, 15:36, "openssl-users on behalf of Skip Carter" <openssl-users-bounces at openssl.org on behalf of skip at taygeta.com> wrote:

    All,
    
    I am thinking that the DEPRECATED... macros are not expanded by the
    pre-parser so the compiler sees them as a weirdly formed function and
    doesn't like it.
    
    I "installed" the header files with 'cp' was there a make command that
    I was supposed to use ?
    
     
    On Fri, 2018-10-19 at 16:54 -0700, Skip Carter wrote:
    > On Fri, 2018-10-19 at 22:54 +0100, Matt Caswell wrote:
    > > 
    > > 
    > > It looks like its not picking up the definition of the
    > > DEPRECATEDIN_1_2_0 macro for some reason.
    > > 
    > > That macro should be defined in opensslconf.h (which is included
    > > from
    > > ec.h), and looks like this:
    > > 
    > > /*
    > >  * Do not deprecate things to be deprecated in version 1.2.0 before
    > > the
    > >  * OpenSSL version number matches.
    > >  */
    > > #if OPENSSL_VERSION_NUMBER < 0x10200000L
    > > # define DEPRECATEDIN_1_2_0(f)   f;
    > > #elif OPENSSL_API_COMPAT < 0x10200000L
    > > # define DEPRECATEDIN_1_2_0(f)   DECLARE_DEPRECATED(f)
    > > #else
    > > # define DEPRECATEDIN_1_2_0(f)
    > > #endif
    > > 
    > > And where OPENSSL_VERSION_NUMBER is declared in opensslv.h (which
    > > is
    > > included from opensslconf.h). Since 1.1.1 is less than 1.2.0, the
    > > first
    > > definition of DEPRECATEDIN_1_2_0 should apply, i.e. this macro
    > > should
    > > effectively be ignored and the parameter should be processed just
    > > like
    > > any other function declaration.
    > > 
    > > So do you have an opensslconf.h? And does it have that macro
    > > defined
    > > in
    > > it? My theory is that somehow or other you are picking up an old
    > > version
    > > of that header (maybe the system version) which doesn't have the
    > > macro
    > > defined.
    > > 
    > > Matt
    > > 
    > 
    > I found:
    > 
    > opensslv.h:# define OPENSSL_VERSION_NUMBER  0x1010100fL
    > 
    > Also to be sure my compilation environment isn't doing anything
    > funky:
    > 
    > #include <stdio.h>
    > 
    > #include <openssl/opensslv.h>
    > 
    > int main(void)
    > {
    >   
    >   printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
    >   
    >   return 0;
    > }
    > 
    > gave me the same thing.
    > 
    > 
    > 
    > -- 
    > Skip Carter
    > Taygeta Scientific Inc.
    -- 
    Skip Carter
    Taygeta Scientific Inc.
    
    -- 
    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: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181021/5af1de96/attachment.bin>

From skip at taygeta.com  Sun Oct 21 01:30:27 2018
From: skip at taygeta.com (Skip Carter)
Date: Sat, 20 Oct 2018 18:30:27 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com>
 <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
Message-ID: <1540085427.4886.14.camel@taygeta.com>

Uri,

Yes, that works just fine for me too.  But if I include ssl.h I have
the problem.  The various DEPRECATED.. macros don't get pre-compiled
and get handed to the compiler.  I think I improperly installed the
headers.

On Sun, 2018-10-21 at 00:36 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> I'm not sure I understand what you're doing, but:
> 
> $ cat ttt.c
> #include <stdio.h>
> #include <openssl/opensslv.h>
> 
> int main(void)
> {
> ? printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
> ? return 0;
> }
> $ gcc -o ttt ttt.c -lcrypto
> $ ./ttt
> OPENSSL_VERSION_NUMBER 1000210f
> $ gcc -o ttt -I$HOME/openssl-1.1/include ttt.c -L$HOME/openssl-
> 1.1/lib -lcrypto
> $ ./ttt
> OPENSSL_VERSION_NUMBER 10101010
> $
> 
> --
> Regards,
> Uri?
> 
> 

????
-- 
Skip Carter
Taygeta Scientific Inc.


From rsalz at akamai.com  Sun Oct 21 01:50:50 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 21 Oct 2018 01:50:50 +0000
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540085427.4886.14.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
Message-ID: <0E6592C4-5E16-49DB-80EC-D181F172E6F2@akamai.com>

You probably do not have the headers installed into the right include path.  You should do "make install" and not cp things by hand, as you'll need the headers and the libraries, etc. 


From uri at ll.mit.edu  Sun Oct 21 02:10:20 2018
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Sun, 21 Oct 2018 02:10:20 +0000
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540085427.4886.14.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
Message-ID: <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>

On 10/20/2018, 21:41, "openssl-users on behalf of Skip Carter" <openssl-users-bounces at openssl.org on behalf of skip at taygeta.com> wrote:
    Yes, that works just fine for me too.  But if I include ssl.h I have
    the problem.  The various DEPRECATED.. macros don't get pre-compiled
    and get handed to the compiler.  I think I improperly installed the
    headers.

I think so too, because adding ssl.h doesn't break compilation/run for me:

$ cat ttt.c
#include <stdio.h>
#include <openssl/opensslv.h>
#include <openssl/ssl.h>

int main(void)
{
  printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
  return 0;
}
$ gcc -o ttt -I$HOME/openssl-1.1/include ttt.c -L$HOME/openssl-1.1/lib -lcrypto
$ ./ttt
OPENSSL_VERSION_NUMBER 10101010
$ gcc -o ttt ttt.c -lcrypto
$ ./ttt
OPENSSL_VERSION_NUMBER 1000210f
$

    
    On Sun, 2018-10-21 at 00:36 +0000, Blumenthal, Uri - 0553 - MITLL
    wrote:
    > I'm not sure I understand what you're doing, but:
    > 
    > $ cat ttt.c
    > #include <stdio.h>
    > #include <openssl/opensslv.h>
    > 
    > int main(void)
    > {
    >   printf("OPENSSL_VERSION_NUMBER %lx\n",OPENSSL_VERSION_NUMBER);
    >   return 0;
    > }
    > $ gcc -o ttt ttt.c -lcrypto
    > $ ./ttt
    > OPENSSL_VERSION_NUMBER 1000210f
    > $ gcc -o ttt -I$HOME/openssl-1.1/include ttt.c -L$HOME/openssl-
    > 1.1/lib -lcrypto
    > $ ./ttt
    > OPENSSL_VERSION_NUMBER 10101010
    > $
    > 
    > --
    > Regards,
    > Uri 
    > 
    > 
    
        
    -- 
    Skip Carter
    Taygeta Scientific Inc.
    
    -- 
    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: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181021/1dcd67a5/attachment.bin>

From skip at taygeta.com  Sun Oct 21 17:11:38 2018
From: skip at taygeta.com (Skip Carter)
Date: Sun, 21 Oct 2018 10:11:38 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com>
 <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
Message-ID: <1540141898.4886.16.camel@taygeta.com>


On Sun, 2018-10-21 at 02:10 +0000, Blumenthal, Uri - 0553 - MITLL
wrote:
> On 10/20/2018, 21:41, "openssl-users on behalf of Skip Carter" <opens
> sl-users-bounces at openssl.org on behalf of skip at taygeta.com> wrote:
> ????Yes, that works just fine for me too.??But if I include ssl.h I
> have
> ????the problem.??The various DEPRECATED.. macros don't get pre-
> compiled
> ????and get handed to the compiler.??I think I improperly installed
> the
> ????headers.
> 
> I think so too, because adding ssl.h doesn't break compilation/run
> for me:
> 

I started from 0:


tar xvf openssl-1.1.1.tar.gz
cd openssl-1.1.1/
./Configure --prefix=/usr --openssldir=/usr/lib/ssl shared linux
generic64
make
sudo make install

...no errors, no complications
 
And I still have the problem with those macros.

I am using gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)


-- 
Skip Carter
Taygeta Scientific Inc.


From rsalz at akamai.com  Sun Oct 21 18:28:28 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 21 Oct 2018 18:28:28 +0000
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540141898.4886.16.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
Message-ID: <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>

>    And I still have the problem with those macros.
  
The problem is almost definitely this:  the files that you are compiling (not openssl) are picking up the wrong header files from openssl.


From skip at taygeta.com  Sun Oct 21 19:01:51 2018
From: skip at taygeta.com (Skip Carter)
Date: Sun, 21 Oct 2018 12:01:51 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com>
 <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
Message-ID: <1540148511.4886.18.camel@taygeta.com>

Thats what I originally thought.

I experimented with manually invoking the pre-compiler (cpp) and this
is what I get:


DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,  
                    ?                                             
BIGNUM *p,
???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
???????????????????????????????????????????????BN_CTX *ctx))
the macro is not firing, shouldn't I get:

extern int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,              
        ?                                              BIGNUM *p,
???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
???
????????????????????????????????????????????BN_CTX *ctx);


On Sun, 2018-10-21 at 18:28 +0000, Salz, Rich via openssl-users wrote:
> > ???And I still have the problem with those macros.
> 
> ??
> The problem is almost definitely this:??the files that you are
> compiling (not openssl) are picking up the wrong header files from
> openssl.
> 
-- 
Skip Carter
Taygeta Scientific Inc.


From rsalz at akamai.com  Mon Oct 22 02:08:23 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Oct 2018 02:08:23 +0000
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540148511.4886.18.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
Message-ID: <8260BB64-B12E-4779-B9DF-903D23E47FD3@akamai.com>

>    DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,  

That is "proof" that the pre-processor doesn?t have the right -I flags.  Try running with the -v option or something.


From matt at openssl.org  Mon Oct 22 07:55:28 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 22 Oct 2018 08:55:28 +0100
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540148511.4886.18.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
Message-ID: <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>



On 21/10/2018 20:01, Skip Carter wrote:
> Thats what I originally thought.
> 
> I experimented with manually invoking the pre-compiler (cpp) and this
> is what I get:
> 
> 
> DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,  
>                     ?                                             
> BIGNUM *p,
> ???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
> ???????????????????????????????????????????????BN_CTX *ctx))
> the macro is not firing, shouldn't I get:
> 
> extern int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,              
>         ?                                              BIGNUM *p,
> ???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
> ???
> ????????????????????????????????????????????BN_CTX *ctx);
> 
> 
> On Sun, 2018-10-21 at 18:28 +0000, Salz, Rich via openssl-users wrote:
>>> ???And I still have the problem with those macros.
>>
>> ??
>> The problem is almost definitely this:??the files that you are
>> compiling (not openssl) are picking up the wrong header files from
>> openssl.
>>

Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in it?

Matt

From jb-openssl at wisemo.com  Mon Oct 22 13:34:20 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 22 Oct 2018 15:34:20 +0200
Subject: [openssl-users] To disable CBC ciphers
In-Reply-To: <CAD7Ssm_UoJAg0DBedRNxkU0ZhHr2TWJjF2BTpRR5HSF8PMax9w@mail.gmail.com>
References: <CAD7Ssm-roOek6X_Lj2UBC3qMOdhgufUpeqHprRZqXxv6bOeO4w@mail.gmail.com>
 <CAOu9RAdR2eG8LCY1sS3XhzFasP0MHg03F39KROekx1T+C7EbAw@mail.gmail.com>
 <CAD7Ssm_UoJAg0DBedRNxkU0ZhHr2TWJjF2BTpRR5HSF8PMax9w@mail.gmail.com>
Message-ID: <d91267e8-4681-9a77-23fa-d790200e2259@wisemo.com>

On 20/10/2018 15:59, Kaushal Shriyan wrote:
>
>
> On Wed, Oct 17, 2018 at 7:00 PM murugesh pitchaiah 
> <murugesh.pitchaiah at gmail.com <mailto:murugesh.pitchaiah at gmail.com>> 
> wrote:
>
>     Hi,
>
>     You may list down what ciphers configured : "openssl ciphers"
>     Choose CBC ciphers and add them to the list of 'ssl_ciphers' with "!"
>     prefix appended to current ssl_ciphers.
>
>     > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
>
>     Ref:
>     https://serverfault.com/questions/692119/meaning-of-ssl-ciphers-line-on-nginx-conf
>
>     Thanks,
>     Murugesh P.
>
>
>     On 10/17/18, Kaushal Shriyan <kaushalshriyan at gmail.com
>     <mailto:kaushalshriyan at gmail.com>> wrote:
>     > Hi,
>     >
>     > I have the below ssl settings in nginx.conf file and VAPT test
>     has reported
>     > us to disable CBC ciphers
>     >
>     > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;
>     >> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
>     >
>     >
>     > openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on
>     CentOS
>     > Linux release 7.3.1611 (Core)
>     >
>     > I will appreciate if someone can pitch in to help me understand
>     to disable
>     > CBC ciphers
>     >
>
>
> Thanks Murugesh. I did checked openssl ciphers 
> https://www.openssl.org/docs/man1.0.2/apps/ciphers.html and could not see
> !AAA_CBC_BBB as mentioned in your email.
>
>     ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
>
>
> Correct me if i am understanding it wrong. Basically i want to disable 
> Cipher Block Chaining (CBC) mode cipher encryption. Openssl and OS 
> version are as below :-
>
>     openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on
>     CentOS
>     Linux release 7.3.1611 (Core)
>
>
> Any tools which i can run to find out vulnerabilities in the above 
> openssl and OS version? Please guide and i look forward to hearing 
> from you. Thanks in Advance.
You need to replace AAA and BBB with actual strings corresponding to
each of the unwanted cipher suites.

The advisor that tells you to disable "CBC ciphers" is mostly wrong.
There is nothing inherently bad about correctly using ciphers in CBC
mode, however some TLS protocol versions happen to use CBC cipher
suites in a problematic way, while having no secure non-CBC cipher
suites.? More recent TLS versions (such as TLS 1.2) have less
problematic (but not perfect) CBC usage and also offers some
overhyped US government ciphers such as the AES_GCM family.

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 rama.krushna7 at gmail.com  Mon Oct 22 13:56:55 2018
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Mon, 22 Oct 2018 19:26:55 +0530
Subject: [openssl-users] Reg issue in alert message
Message-ID: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>

Hi,

I am facing an issue after openssl upgrade to 1.1.1.
I have a odbc client with maximum version support up to TLSv1.2 and  my
database is running with TLSv1.2,TLsv1.3.

The handhake is failing and I am getting following contents on my BIO dump.
"15 03 03 00 02 02 56" .
If i have understood correctly this is for alert message and But I could
not find any reference to alert description at (
https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )
corresponding to 56.

So, Could you please help me figure out what does this correspond to ?

Moreover I have following doubt.

-- If my TLSv1.2 client does not handle the  "downgrade sentinel " present
in server hello ( TLSv1.3 , will it create any problem ?
-- In the above example client is receving error such as "SSL Handshake
Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
alert inappropriate fallback]." ? Could you please help me to hint me about
how to debug this ?

Thanks and Regards,
Ram Krushna
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181022/cb04af81/attachment.html>

From matt at openssl.org  Mon Oct 22 14:10:55 2018
From: matt at openssl.org (Matt Caswell)
Date: Mon, 22 Oct 2018 15:10:55 +0100
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
References: <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA@mail.gmail.com>
Message-ID: <3c26e4ec-32e4-f3df-c1ae-0ed1cdeb5848@openssl.org>



On 22/10/2018 14:56, ramakrushna mishra wrote:
> Hi,
> 
> I am facing an issue after openssl upgrade to 1.1.1.?
> I have a odbc client with maximum version support up to TLSv1.2 and? my
> database is running with TLSv1.2,TLsv1.3.?
> 
> The handhake is failing and I am getting following contents on my BIO dump.?
> "15 03 03 00 02 02 56" .?
> If i have understood correctly this is for alert message and But I could
> not find any reference to alert description at (
> https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )?
> corresponding to 56. 

56 hex == 86 decimal == inappropriate_fallback

i.e. this doesn't tell you any further information than you have below.

> 
> So, Could you please help me figure out what does this correspond to ??
> 
> Moreover I have following doubt.?
> 
> -- If my TLSv1.2 client does not handle the? "downgrade sentinel "
> present in server hello ( TLSv1.3 , will it create any problem ? 

No, this should not be a problem.

> -- In the above example client is receving error such as "SSL Handshake
> Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> alert inappropriate fallback]." ? Could you please help me to hint me
> about how to debug this ?

What version of OpenSSL are you using for the client?

Is it possible for you to send me a wireshark trace of the failing
handshake?

In particular I am interested to see if the TLS_FALLBACK_SCSV
ciphersuite is present in the ClientHello (RFC 7507). The
TLS_FALLBACK_SCSV is only supposed to be sent if the client has already
attempted an earlier handshake that failed, and it is now trying a
downgraded protocol version. So, does the wireshark trace reveal the
client attempting an initial handshake that is failing for some other
reason, followed by a second attempt that fails with the inappropriate
fallback error?


Matt

From skip at taygeta.com  Mon Oct 22 17:50:31 2018
From: skip at taygeta.com (Skip Carter)
Date: Mon, 22 Oct 2018 10:50:31 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com>
 <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
 <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
Message-ID: <1540230631.4886.20.camel@taygeta.com>

Yes the macro is there, its just not being expanded by the pre-
compiler.


On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote:
> 
> On 21/10/2018 20:01, Skip Carter wrote:
> 
> Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in
> it?
> 
> Matt
-- 
Skip Carter
Taygeta Scientific Inc.


From rsalz at akamai.com  Mon Oct 22 17:52:40 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Oct 2018 17:52:40 +0000
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540230631.4886.20.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
 <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
 <1540230631.4886.20.camel@taygeta.com>
Message-ID: <895629BB-A217-4FE0-9EB4-172F2FC78A69@akamai.com>

>    Yes the macro is there, its just not being expanded by the pre-
    compiler.
  
That makes no sense.

Please look at your compiler manpages and figure out how to turn on verbose compiler output.  Something is strange in your environment.


 


From openssl-users at dukhovni.org  Mon Oct 22 17:54:54 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 22 Oct 2018 13:54:54 -0400
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540230631.4886.20.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
 <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
 <1540230631.4886.20.camel@taygeta.com>
Message-ID: <16D05511-7A37-421B-9171-09E9BC811634@dukhovni.org>

You're surely looking in the wrong header file.  The compiler
is using a different one in which the macro is NOT defined.

> On Oct 22, 2018, at 1:50 PM, Skip Carter <skip at taygeta.com> wrote:
> 
> Yes the macro is there, its just not being expanded by the pre-
> compiler.
> 
> 
> On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote:
>> 
>> On 21/10/2018 20:01, Skip Carter wrote:
>> 
>> Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in
>> it?

-- 
	Viktor.


From selva.nair at gmail.com  Mon Oct 22 18:00:56 2018
From: selva.nair at gmail.com (Selva Nair)
Date: Mon, 22 Oct 2018 14:00:56 -0400
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540230631.4886.20.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
 <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
 <1540230631.4886.20.camel@taygeta.com>
Message-ID: <CAKuzo_gk+4dVP=zR1ZoUMt2H=p-ivOTAXNF-uZYO_iOWPFCwdA@mail.gmail.com>

On Mon, Oct 22, 2018 at 1:51 PM Skip Carter <skip at taygeta.com> wrote:
>
> Yes the macro is there, its just not being expanded by the pre-
> compiler.

All these tests say the same thing that you are picking up a wrong (old) header.

So do:

gcc -E your-program.c | grep opensslconf.h

Then check whether the one it picks up is the right one and has
the macro defined.

Selva

From levitte at openssl.org  Mon Oct 22 18:12:50 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 22 Oct 2018 20:12:50 +0200 (CEST)
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540230631.4886.20.camel@taygeta.com>
References: <1540148511.4886.18.camel@taygeta.com>
 <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
 <1540230631.4886.20.camel@taygeta.com>
Message-ID: <20181022.201250.1411858288950862243.levitte@openssl.org>

That's very odd.  Are you *sure* the one you're looking at is the one
actually included?

Cheers,
Richard

In message <1540230631.4886.20.camel at taygeta.com> on Mon, 22 Oct 2018 10:50:31 -0700, Skip Carter <skip at taygeta.com> said:

> Yes the macro is there, its just not being expanded by the pre-
> compiler.
> 
> 
> On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote:
> > 
> > On 21/10/2018 20:01, Skip Carter wrote:
> > 
> > Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in
> > it?
> > 
> > Matt
> -- 
> Skip Carter
> Taygeta Scientific Inc.
> 
> 

From skip at taygeta.com  Mon Oct 22 18:17:14 2018
From: skip at taygeta.com (Skip Carter)
Date: Mon, 22 Oct 2018 11:17:14 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <895629BB-A217-4FE0-9EB4-172F2FC78A69@akamai.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com>
 <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
 <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
 <1540230631.4886.20.camel@taygeta.com>
 <895629BB-A217-4FE0-9EB4-172F2FC78A69@akamai.com>
Message-ID: <1540232234.4886.22.camel@taygeta.com>

On Mon, 2018-10-22 at 17:52 +0000, Salz, Rich via openssl-users wrote:
> > ???Yes the macro is there, its just not being expanded by the pre-
> 
> ????compiler.
> ??
> That makes no sense.

I am stumped,  FYI here is the the relevant output of the precompiler
(cpp)

# 261 "/usr/include/openssl/ec.h" 3 4
DEPRECATEDIN_1_2_0(int EC_GROUP_set_curve_GFp(EC_GROUP *group, const
BIGNUM *p,
??????????????????????????????????????????????const BIGNUM *a, const
BIGNUM *b,
??????????????????????????????????????????????BN_CTX *ctx))

obviously when the actual compiler gets to this, its not happy.

I have checked the precompiler version matches the compiler version.
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

> ....Something is strange in your environment.... 

 I am thinking the same but I haven't a clue what it is.  I do lots of
code development but this has me at a loss



-- 
Skip Carter
Taygeta Scientific Inc.

From skip at taygeta.com  Mon Oct 22 18:42:47 2018
From: skip at taygeta.com (Skip Carter)
Date: Mon, 22 Oct 2018 11:42:47 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <CAKuzo_gk+4dVP=zR1ZoUMt2H=p-ivOTAXNF-uZYO_iOWPFCwdA@mail.gmail.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com>
 <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
 <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
 <1540230631.4886.20.camel@taygeta.com>
 <CAKuzo_gk+4dVP=zR1ZoUMt2H=p-ivOTAXNF-uZYO_iOWPFCwdA@mail.gmail.com>
Message-ID: <1540233767.4886.24.camel@taygeta.com>

Found the problem!
Thanks to Selva for pointing the way.

The compiler was looking for opensslconf.h (and only this file, not any
other header files) at /usr/include/x86_64-linux-
gnu/openssl/opensslconf.h  when I copied
/usr/include/openssl/opensslconf.h to that location, everything worked.
  The -E flag gave it away (it was buried in the cpp output too, but
was easy to miss).


On Mon, 2018-10-22 at 14:00 -0400, Selva Nair wrote:
> On Mon, Oct 22, 2018 at 1:51 PM Skip Carter <skip at taygeta.com> wrote:
> > 
> > Yes the macro is there, its just not being expanded by the pre-
> > compiler.
> 
> All these tests say the same thing that you are picking up a wrong
> (old) header.
> 
> So do:
> 
> gcc -E your-program.c | grep opensslconf.h
> 
> Then check whether the one it picks up is the right one and has
> the macro defined.
> 
> Selva
-- 
Skip Carter
Taygeta Scientific Inc.

From jb-openssl at wisemo.com  Mon Oct 22 18:58:31 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 22 Oct 2018 20:58:31 +0200
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540233767.4886.24.camel@taygeta.com>
References: <1539975824.4886.3.camel@taygeta.com>
 <1fdcd4d1-500a-e43e-25db-9e78a8ea840d@openssl.org>
 <1539993264.4886.8.camel@taygeta.com> <1540061506.4886.12.camel@taygeta.com>
 <C116DB6A-B5B7-4268-8D4E-3AD8EC707DAA@ll.mit.edu>
 <1540085427.4886.14.camel@taygeta.com>
 <8060B340-1741-497F-8E9E-99D13CAA9398@ll.mit.edu>
 <1540141898.4886.16.camel@taygeta.com>
 <57DEE03A-C61F-4165-842E-0BE313530609@akamai.com>
 <1540148511.4886.18.camel@taygeta.com>
 <7513a526-2840-6a4e-cf9a-99666ffc1330@openssl.org>
 <1540230631.4886.20.camel@taygeta.com>
 <CAKuzo_gk+4dVP=zR1ZoUMt2H=p-ivOTAXNF-uZYO_iOWPFCwdA@mail.gmail.com>
 <1540233767.4886.24.camel@taygeta.com>
Message-ID: <27cf8e56-1e3a-671b-5438-74c2f8d6f5b3@wisemo.com>

Ah, I guess it wanted you to also compile OpenSSL for i386 and putting
that (different!) opensslconf.h in the i386-specific directory.

That also means you should have moved opensslconf.h to the subdir, not
copied it.

On 22/10/2018 20:42, Skip Carter wrote:
> Found the problem!
> Thanks to Selva for pointing the way.
>
> The compiler was looking for opensslconf.h (and only this file, not any
> other header files) at /usr/include/x86_64-linux-
> gnu/openssl/opensslconf.h  when I copied
> /usr/include/openssl/opensslconf.h to that location, everything worked.
>    The -E flag gave it away (it was buried in the cpp output too, but
> was easy to miss).
>
>
> On Mon, 2018-10-22 at 14:00 -0400, Selva Nair wrote:
>> On Mon, Oct 22, 2018 at 1:51 PM Skip Carter <skip at taygeta.com> wrote:
>>> Yes the macro is there, its just not being expanded by the pre-
>>> compiler.
>> All these tests say the same thing that you are picking up a wrong
>> (old) header.
>>
>> So do:
>>
>> gcc -E your-program.c | grep opensslconf.h
>>
>> Then check whether the one it picks up is the right one and has
>> the macro defined.
>>

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 levitte at openssl.org  Mon Oct 22 19:36:20 2018
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 22 Oct 2018 21:36:20 +0200 (CEST)
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <1540233767.4886.24.camel@taygeta.com>
References: <1540230631.4886.20.camel@taygeta.com>
 <CAKuzo_gk+4dVP=zR1ZoUMt2H=p-ivOTAXNF-uZYO_iOWPFCwdA@mail.gmail.com>
 <1540233767.4886.24.camel@taygeta.com>
Message-ID: <20181022.213620.404206055799614843.levitte@openssl.org>

If the compiler found opensslconf.h in
/usr/include/x86_64-linux-gnu/openssl/, that usually means you have an
distribution openssl package installed, one that other programs are
relying on.

Depending on the version of that package, you may have screwed things
up or not.  If you're lucky, things will go smoothly, but be warning
that your "installation" probably will get overwritten next time you
do an update that affects the openssl package.

For custom installations, I'd suggest using the /usr/local tree.  This
is what the default OpenSSL configuration + make install does.

Cheers,
Richard

In message <1540233767.4886.24.camel at taygeta.com> on Mon, 22 Oct 2018 11:42:47 -0700, Skip Carter <skip at taygeta.com> said:

> Found the problem!
> Thanks to Selva for pointing the way.
> 
> The compiler was looking for opensslconf.h (and only this file, not any
> other header files) at /usr/include/x86_64-linux-
> gnu/openssl/opensslconf.h  when I copied
> /usr/include/openssl/opensslconf.h to that location, everything worked.
>   The -E flag gave it away (it was buried in the cpp output too, but
> was easy to miss).
> 
> 
> On Mon, 2018-10-22 at 14:00 -0400, Selva Nair wrote:
> > On Mon, Oct 22, 2018 at 1:51 PM Skip Carter <skip at taygeta.com> wrote:
> > > 
> > > Yes the macro is there, its just not being expanded by the pre-
> > > compiler.
> > 
> > All these tests say the same thing that you are picking up a wrong
> > (old) header.
> > 
> > So do:
> > 
> > gcc -E your-program.c | grep opensslconf.h
> > 
> > Then check whether the one it picks up is the right one and has
> > the macro defined.
> > 
> > Selva
> -- 
> Skip Carter
> Taygeta Scientific Inc.
> 

From pgnet.dev at gmail.com  Mon Oct 22 19:56:56 2018
From: pgnet.dev at gmail.com (pgndev)
Date: Mon, 22 Oct 2018 12:56:56 -0700
Subject: [openssl-users] What to do with deprecation errors
In-Reply-To: <20181022.213620.404206055799614843.levitte@openssl.org>
References: <1540230631.4886.20.camel@taygeta.com>
 <CAKuzo_gk+4dVP=zR1ZoUMt2H=p-ivOTAXNF-uZYO_iOWPFCwdA@mail.gmail.com>
 <1540233767.4886.24.camel@taygeta.com>
 <20181022.213620.404206055799614843.levitte@openssl.org>
Message-ID: <CAHv26Djy5P8t+R6Ctw3wGrz-z25UUYmUqWVdap3rE9Ry3pFYUA@mail.gmail.com>

The "which package depends on which openssl ver" issue's been around a long
time.

FWIW, in general, I *never* touch openssl libs/headers in the default
distro path, /usr.
Just leave that alone -- too many distro packages (still) make (invalid)
assumptions about that being the only/preferred openssl version.

Also, some-not-all distros include /usr/local/ libs & headers in search
path; with a higher priority than /usr.  Drop the 'wrong version' there,
and you can cause yourself similar headaches.

Instead, I build openssl versions into standalone-dirs. E.g.,

  /usr/local/openssl102
  /usr/local/openssl110
  /usr/local/openssl111

and then build any apps I want/need to use a specific version with
appropriate CFLAGS/CPPFLAGS/INCLUDE, as well as LIBS with rpath.
Yes, it's a slog.  But for my use, it's been the only way to manage the
mess.

With the release of openssl 111, I suspect/hope things will begin to
stabilize in app-land; but, I'm not holding my breath.

And, of course, different strokes ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181022/beb76969/attachment.html>

From a.chris.clark at gmail.com  Tue Oct 23 06:50:46 2018
From: a.chris.clark at gmail.com (Chris Clark)
Date: Mon, 22 Oct 2018 23:50:46 -0700
Subject: [openssl-users] How to compile 1.1.1 under Windows
Message-ID: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>

I am attempting to upgrade a project using OpenSSL 1.0.0h to version
1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
1.1.1 for VC-WIN64A I get the following compile error:

       cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
/O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
-D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
-D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
-D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
-D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
"crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
NMAKE : fatal error U1077: 'cl' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.

My Command lines from the VS 2008 x64 Command Prompt are:
perl Configure VC-WIN64A --prefix=c:/openssl
nmake

I also tried compiling the latest stable snapshot
(openssl-1.1.1-stable-SNAP-20181022) with the same results. However
version 1.1.0h compiles without error. Can anyone tell me what the
problem is?

Here is the configuration dump:

Command line (with current working directory = .):
    c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
Perl information:
    c:\perl\bin\perl.exe
    5.24.3 for MSWin32-x64-multi-thread
Enabled features:
    aria
    asm
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    camellia
    capieng
    cast
    chacha
    cmac
    cms
    comp
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dso
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    gost
    hw(-.+)?
    idea
    makedepend
    md4
    mdc2
    multiblock
    nextprotoneg
    ocb
    ocsp
    pic
    poly1305
    posix-io
    psk
    rc2
    rc4
    rdrand
    rfc3779
    rmd160
    scrypt
    seed
    shared
    siphash
    sm2
    sm3
    sm4
    sock
    srp
    srtp
    sse2
    ssl
    static-engine
    stdio
    tests
    threads
    tls
    ts
    ui-console
    whirlpool
    tls1
    tls1-method
    tls1_1
    tls1_1-method
    tls1_2
    tls1_2-method
    tls1_3
    dtls1
    dtls1-method
    dtls1_2
    dtls1_2-method
Disabled features:
    afalgeng                [not-linux]
    asan                    [default]   OPENSSL_NO_ASAN
    crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
    crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
    ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
    egd                     [default]   OPENSSL_NO_EGD
    external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
    fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
    fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
    heartbeats              [default]   OPENSSL_NO_HEARTBEATS
    md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
    msan                    [default]   OPENSSL_NO_MSAN
    rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
    sctp                    [default]   OPENSSL_NO_SCTP
    ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
    ubsan                   [default]   OPENSSL_NO_UBSAN
    unit-test               [default]   OPENSSL_NO_UNIT_TEST
    weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
    zlib                    [default]
    zlib-dynamic            [default]
    ssl3                    [default]   OPENSSL_NO_SSL3
    ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
Config target attributes:
    AR => "lib",
    ARFLAGS => "/nologo",
    AS => "nasm",
    ASFLAGS => "-g",
    CC => "cl",
    CFLAGS => "/W3 /wd4090 /nologo /O2",
    CPP => "\$(CC) /EP /C",
    HASHBANGPERL => "/usr/bin/env perl",
    LD => "link",
    LDFLAGS => "/nologo /debug",
    MT => "mt",
    MTFLAGS => "-nologo",
    RANLIB => "CODE(0x65aff0)",
    RC => "rc",
    aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
aesni-mb-x86_64.s",
    aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
aesni-mb-x86_64.o",
    apps_aux_src => "win32_init.c",
    apps_init_src => "../ms/applink.c",
    apps_obj => "win32_init.o",
    aroutflag => "/out:",
    asflags => "-Ox -f win64 -DNEAR",
    asoutflag => "-o ",
    bf_asm_src => "bf_enc.c",
    bf_obj => "bf_enc.o",
    bin_cflags => "/Zi /Fdapp.pdb",
    bin_lflags => "/subsystem:console /opt:ref",
    bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
    bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
    bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
    build_file => "makefile",
    build_scheme => [ "unified", "windows", "VC-common" ],
    cast_asm_src => "c_enc.c",
    cast_obj => "c_enc.o",
    cflags => "/Gs0 /GF /Gy /MD",
    chacha_asm_src => "chacha-x86_64.s",
    chacha_obj => "chacha-x86_64.o",
    cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
    cmll_obj => "cmll-x86_64.o cmll_misc.o",
    coutflag => "/Fo",
    cppflags => "",
    cpuid_asm_src => "x86_64cpuid.s",
    cpuid_obj => "x86_64cpuid.o",
    defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
"UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
"_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
    des_asm_src => "des_enc.c fcrypt_b.c",
    des_obj => "des_enc.o fcrypt_b.o",
    disable => [  ],
    dso_cflags => "/Zi /Fddso.pdb",
    dso_extension => "",
    dso_scheme => "win32",
    ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
    ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
    enable => [  ],
    ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
    exe_extension => "",
    includes => [  ],
    keccak1600_asm_src => "keccak1600-x86_64.s",
    keccak1600_obj => "keccak1600-x86_64.o",
    ldoutflag => "/out:",
    lflags => "",
    lib_cflags => "/Zi /Fdossl_static.pdb",
    lib_cppflags => "",
    lib_defines => [ "L_ENDIAN" ],
    md5_asm_src => "md5-x86_64.s",
    md5_obj => "md5-x86_64.o",
    modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
    modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
    module_cflags => "",
    module_cxxflags => "",
    module_ldflags => "/dll",
    mtinflag => "-manifest ",
    mtoutflag => "-outputresource:",
    multilib => "-x64",
    padlock_asm_src => "e_padlock-x86_64.s",
    padlock_obj => "e_padlock-x86_64.o",
    perlasm_scheme => "auto",
    poly1305_asm_src => "poly1305-x86_64.s",
    poly1305_obj => "poly1305-x86_64.o",
    rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
    rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
    rc5_asm_src => "rc5_enc.c",
    rc5_obj => "rc5_enc.o",
    rcoutflag => "/fo",
    rmd160_asm_src => "",
    rmd160_obj => "",
    sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
sha1-mb-x86_64.s sha256-mb-x86_64.s",
    sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
sha1-mb-x86_64.o sha256-mb-x86_64.o",
    shared_cflag => "",
    shared_defines => [  ],
    shared_extension => "",
    shared_extension_simple => "",
    shared_ldflag => "/dll",
    shared_rcflag => "",
    shared_target => "win-shared",
    sys_id => "WIN64A",
    thread_defines => [  ],
    thread_scheme => "winthreads",
    unistd => "<unistd.h>",
    uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
    uplink_obj => "../ms/uplink.o uplink-x86_64.o",
    wp_asm_src => "wp-x86_64.s",
    wp_obj => "wp-x86_64.o",
Recorded environment:
    AR =
    ARFLAGS =
    AS =
    ASFLAGS =
    BUILDFILE =
    CC =
    CFLAGS =
    CPP =
    CPPDEFINES =
    CPPFLAGS =
    CPPINCLUDES =
    CROSS_COMPILE =
    CXX =
    CXXFLAGS =
    HASHBANGPERL =
    LD =
    LDFLAGS =
    LDLIBS =
    MT =
    MTFLAGS =
    OPENSSL_LOCAL_CONFIG_DIR =
    PERL =
    RANLIB =
    RC =
    RCFLAGS =
    RM =
    WINDRES =
    __CNF_CFLAGS =
    __CNF_CPPDEFINES =
    __CNF_CPPFLAGS =
    __CNF_CPPINCLUDES =
    __CNF_CXXFLAGS =
    __CNF_LDFLAGS =
    __CNF_LDLIBS =
Makevars:
    AR              = lib
    ARFLAGS         = /nologo
    AS              = nasm
    ASFLAGS         = -g
    CC              = cl
    CFLAGS          = /W3 /wd4090 /nologo /O2
    CPP             = $(CC) /EP /C
    CPPDEFINES      =
    CPPFLAGS        =
    CPPINCLUDES     =
    CXXFLAGS        =
    HASHBANGPERL    = /usr/bin/env perl
    LD              = link
    LDFLAGS         = /nologo /debug
    LDLIBS          =
    MT              = mt
    MTFLAGS         = -nologo
    PERL            = c:\perl\bin\perl.exe
    RC              = rc
NOTE: These variables only represent the configuration view.  The build file
template may have processed these variables further, please have a look at the
build file for more exact data:
    makefile
build file:
    makefile
build file templates:
    Configurations\common0.tmpl
    Configurations\windows-makefile.tmpl
    Configurations\common.tmpl

From jisoza at gmail.com  Tue Oct 23 06:58:12 2018
From: jisoza at gmail.com (Juan Isoza)
Date: Tue, 23 Oct 2018 08:58:12 +0200
Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not
	working
In-Reply-To: <40A86C9B-BEB7-48BD-B426-17F7CF026595@dukhovni.org>
References: <a8fe73dc-9430-6e97-a2a0-0647b0184cbe@keppler-it.de>
 <20180912142038.GI5819@akamai.com>
 <40A86C9B-BEB7-48BD-B426-17F7CF026595@dukhovni.org>
Message-ID: <CAKRdTC-4mgzZzaeLGNotYj0nDHSHpU_DXR3Vq1dgg=ZA4FWjGw@mail.gmail.com>

I suppose Facebook reports 50% because their mobile apps uses their SSL
library Fizz with Tls 1.3

https://thehackernews.com/2018/08/fizz-tls-ssl-library.html

I'm curious seeing your telemetry info now. Chrome 70 was released last
week, and FireFox 63 today, with TLS 1.3 support

regards

Le mer. 12 sept. 2018 ? 16:41, Viktor Dukhovni <openssl-users at dukhovni.org>
a ?crit :

>
>
> > On Sep 12, 2018, at 10:20 AM, Benjamin Kaduk via openssl-users <
> openssl-users at openssl.org> wrote:
> >
> > IIUC, only Firefox nightly as of approximately today will support the
> final
> > RFC 8446 version; I haven't looked into Chrome yet.
>
> From the Firefox TLS 1.3 blog entry:
>
>
> https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/
>
> What Now?
>
> TLS 1.3 is already widely deployed: both Firefox and Chrome have fielded
> ?draft? versions. Firefox 61 is already shipping draft-28, which is
> essentially the same as the final published version (just with a different
> version number). We expect to ship the final version in Firefox 63,
> scheduled for October 2018. Cloudflare, Google, and Facebook are running it
> on their servers today. Our telemetry shows that around 5% of Firefox
> connections are TLS 1.3. Cloudflare reports similar numbers, and Facebook
> reports that an astounding 50+% of their traffic is already TLS 1.3!
>
> --
>         Viktor.
>
> --
> 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/20181023/92bdf8d2/attachment-0001.html>

From Matthias.St.Pierre at ncp-e.com  Tue Oct 23 07:16:31 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 23 Oct 2018 07:16:31 +0000
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>
References: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>
Message-ID: <ccf16fbfa118412181727ecafbdc0933@Ex13.ncp.local>

Hi,

a lot of structures where made opaque going from 1.0.2 to 1.1.0.
This means, you will have to make changes to your program source code
to compile it against 1.1.0 or 1.1.1.

For details, see https://www.openssl.org/docs/faq.html#PROG2

HTH,
Matthias


> -----Urspr?ngliche Nachricht-----
> Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Chris Clark
> Gesendet: Dienstag, 23. Oktober 2018 08:51
> An: openssl-users at openssl.org
> Betreff: [openssl-users] How to compile 1.1.1 under Windows
> 
> I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> 1.1.1 for VC-WIN64A I get the following compile error:
> 
>        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> Files\\Common Files\\SSL\""
> -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> Stop.
> 
> My Command lines from the VS 2008 x64 Command Prompt are:
> perl Configure VC-WIN64A --prefix=c:/openssl
> nmake
> 
> I also tried compiling the latest stable snapshot
> (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> version 1.1.0h compiles without error. Can anyone tell me what the
> problem is?
> 
> Here is the configuration dump:
> 
> Command line (with current working directory = .):
>     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> Perl information:
>     c:\perl\bin\perl.exe
>     5.24.3 for MSWin32-x64-multi-thread
> Enabled features:
>     aria
>     asm
>     async
>     autoalginit
>     autoerrinit
>     autoload-config
>     bf
>     blake2
>     camellia
>     capieng
>     cast
>     chacha
>     cmac
>     cms
>     comp
>     ct
>     deprecated
>     des
>     dgram
>     dh
>     dsa
>     dso
>     dtls
>     dynamic-engine
>     ec
>     ec2m
>     ecdh
>     ecdsa
>     engine
>     err
>     filenames
>     gost
>     hw(-.+)?
>     idea
>     makedepend
>     md4
>     mdc2
>     multiblock
>     nextprotoneg
>     ocb
>     ocsp
>     pic
>     poly1305
>     posix-io
>     psk
>     rc2
>     rc4
>     rdrand
>     rfc3779
>     rmd160
>     scrypt
>     seed
>     shared
>     siphash
>     sm2
>     sm3
>     sm4
>     sock
>     srp
>     srtp
>     sse2
>     ssl
>     static-engine
>     stdio
>     tests
>     threads
>     tls
>     ts
>     ui-console
>     whirlpool
>     tls1
>     tls1-method
>     tls1_1
>     tls1_1-method
>     tls1_2
>     tls1_2-method
>     tls1_3
>     dtls1
>     dtls1-method
>     dtls1_2
>     dtls1_2-method
> Disabled features:
>     afalgeng                [not-linux]
>     asan                    [default]   OPENSSL_NO_ASAN
>     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
>     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
>     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
>     egd                     [default]   OPENSSL_NO_EGD
>     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
>     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
>     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
>     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
>     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
>     msan                    [default]   OPENSSL_NO_MSAN
>     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
>     sctp                    [default]   OPENSSL_NO_SCTP
>     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
>     ubsan                   [default]   OPENSSL_NO_UBSAN
>     unit-test               [default]   OPENSSL_NO_UNIT_TEST
>     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
>     zlib                    [default]
>     zlib-dynamic            [default]
>     ssl3                    [default]   OPENSSL_NO_SSL3
>     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> Config target attributes:
>     AR => "lib",
>     ARFLAGS => "/nologo",
>     AS => "nasm",
>     ASFLAGS => "-g",
>     CC => "cl",
>     CFLAGS => "/W3 /wd4090 /nologo /O2",
>     CPP => "\$(CC) /EP /C",
>     HASHBANGPERL => "/usr/bin/env perl",
>     LD => "link",
>     LDFLAGS => "/nologo /debug",
>     MT => "mt",
>     MTFLAGS => "-nologo",
>     RANLIB => "CODE(0x65aff0)",
>     RC => "rc",
>     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> aesni-mb-x86_64.s",
>     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> aesni-mb-x86_64.o",
>     apps_aux_src => "win32_init.c",
>     apps_init_src => "../ms/applink.c",
>     apps_obj => "win32_init.o",
>     aroutflag => "/out:",
>     asflags => "-Ox -f win64 -DNEAR",
>     asoutflag => "-o ",
>     bf_asm_src => "bf_enc.c",
>     bf_obj => "bf_enc.o",
>     bin_cflags => "/Zi /Fdapp.pdb",
>     bin_lflags => "/subsystem:console /opt:ref",
>     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
>     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
>     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
>     build_file => "makefile",
>     build_scheme => [ "unified", "windows", "VC-common" ],
>     cast_asm_src => "c_enc.c",
>     cast_obj => "c_enc.o",
>     cflags => "/Gs0 /GF /Gy /MD",
>     chacha_asm_src => "chacha-x86_64.s",
>     chacha_obj => "chacha-x86_64.o",
>     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
>     cmll_obj => "cmll-x86_64.o cmll_misc.o",
>     coutflag => "/Fo",
>     cppflags => "",
>     cpuid_asm_src => "x86_64cpuid.s",
>     cpuid_obj => "x86_64cpuid.o",
>     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
>     des_asm_src => "des_enc.c fcrypt_b.c",
>     des_obj => "des_enc.o fcrypt_b.o",
>     disable => [  ],
>     dso_cflags => "/Zi /Fddso.pdb",
>     dso_extension => "",
>     dso_scheme => "win32",
>     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
>     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
>     enable => [  ],
>     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
>     exe_extension => "",
>     includes => [  ],
>     keccak1600_asm_src => "keccak1600-x86_64.s",
>     keccak1600_obj => "keccak1600-x86_64.o",
>     ldoutflag => "/out:",
>     lflags => "",
>     lib_cflags => "/Zi /Fdossl_static.pdb",
>     lib_cppflags => "",
>     lib_defines => [ "L_ENDIAN" ],
>     md5_asm_src => "md5-x86_64.s",
>     md5_obj => "md5-x86_64.o",
>     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
>     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
>     module_cflags => "",
>     module_cxxflags => "",
>     module_ldflags => "/dll",
>     mtinflag => "-manifest ",
>     mtoutflag => "-outputresource:",
>     multilib => "-x64",
>     padlock_asm_src => "e_padlock-x86_64.s",
>     padlock_obj => "e_padlock-x86_64.o",
>     perlasm_scheme => "auto",
>     poly1305_asm_src => "poly1305-x86_64.s",
>     poly1305_obj => "poly1305-x86_64.o",
>     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
>     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
>     rc5_asm_src => "rc5_enc.c",
>     rc5_obj => "rc5_enc.o",
>     rcoutflag => "/fo",
>     rmd160_asm_src => "",
>     rmd160_obj => "",
>     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> sha1-mb-x86_64.s sha256-mb-x86_64.s",
>     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> sha1-mb-x86_64.o sha256-mb-x86_64.o",
>     shared_cflag => "",
>     shared_defines => [  ],
>     shared_extension => "",
>     shared_extension_simple => "",
>     shared_ldflag => "/dll",
>     shared_rcflag => "",
>     shared_target => "win-shared",
>     sys_id => "WIN64A",
>     thread_defines => [  ],
>     thread_scheme => "winthreads",
>     unistd => "<unistd.h>",
>     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
>     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
>     wp_asm_src => "wp-x86_64.s",
>     wp_obj => "wp-x86_64.o",
> Recorded environment:
>     AR =
>     ARFLAGS =
>     AS =
>     ASFLAGS =
>     BUILDFILE =
>     CC =
>     CFLAGS =
>     CPP =
>     CPPDEFINES =
>     CPPFLAGS =
>     CPPINCLUDES =
>     CROSS_COMPILE =
>     CXX =
>     CXXFLAGS =
>     HASHBANGPERL =
>     LD =
>     LDFLAGS =
>     LDLIBS =
>     MT =
>     MTFLAGS =
>     OPENSSL_LOCAL_CONFIG_DIR =
>     PERL =
>     RANLIB =
>     RC =
>     RCFLAGS =
>     RM =
>     WINDRES =
>     __CNF_CFLAGS =
>     __CNF_CPPDEFINES =
>     __CNF_CPPFLAGS =
>     __CNF_CPPINCLUDES =
>     __CNF_CXXFLAGS =
>     __CNF_LDFLAGS =
>     __CNF_LDLIBS =
> Makevars:
>     AR              = lib
>     ARFLAGS         = /nologo
>     AS              = nasm
>     ASFLAGS         = -g
>     CC              = cl
>     CFLAGS          = /W3 /wd4090 /nologo /O2
>     CPP             = $(CC) /EP /C
>     CPPDEFINES      =
>     CPPFLAGS        =
>     CPPINCLUDES     =
>     CXXFLAGS        =
>     HASHBANGPERL    = /usr/bin/env perl
>     LD              = link
>     LDFLAGS         = /nologo /debug
>     LDLIBS          =
>     MT              = mt
>     MTFLAGS         = -nologo
>     PERL            = c:\perl\bin\perl.exe
>     RC              = rc
> NOTE: These variables only represent the configuration view.  The build file
> template may have processed these variables further, please have a look at the
> build file for more exact data:
>     makefile
> build file:
>     makefile
> build file templates:
>     Configurations\common0.tmpl
>     Configurations\windows-makefile.tmpl
>     Configurations\common.tmpl
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From levitte at openssl.org  Tue Oct 23 07:19:13 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 23 Oct 2018 09:19:13 +0200 (CEST)
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>
References: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>
Message-ID: <20181023.091913.2165099182291788730.levitte@openssl.org>

I suspect you'll find some kind of error message in
crypto\sm2\sm2_sign.d.  I suspect that /showIncludes isn't supported
in VS 2008.

There is a workaround for this problem, and it's to use the
'no-makedepend' option:

    perl Configure VC-WIN64A --prefix=c:/openssl no-makedepend

For a single build, that should be good enough.

Cheers,
Richard

In message <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ at mail.gmail.com> on Mon, 22 Oct 2018 23:50:46 -0700, Chris Clark <a.chris.clark at gmail.com> said:

> I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> 1.1.1 for VC-WIN64A I get the following compile error:
> 
>        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> Files\\Common Files\\SSL\""
> -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> NMAKE : fatal error U1077: 'cl' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> Stop.
> 
> My Command lines from the VS 2008 x64 Command Prompt are:
> perl Configure VC-WIN64A --prefix=c:/openssl
> nmake
> 
> I also tried compiling the latest stable snapshot
> (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> version 1.1.0h compiles without error. Can anyone tell me what the
> problem is?
> 
> Here is the configuration dump:
> 
> Command line (with current working directory = .):
>     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> Perl information:
>     c:\perl\bin\perl.exe
>     5.24.3 for MSWin32-x64-multi-thread
> Enabled features:
>     aria
>     asm
>     async
>     autoalginit
>     autoerrinit
>     autoload-config
>     bf
>     blake2
>     camellia
>     capieng
>     cast
>     chacha
>     cmac
>     cms
>     comp
>     ct
>     deprecated
>     des
>     dgram
>     dh
>     dsa
>     dso
>     dtls
>     dynamic-engine
>     ec
>     ec2m
>     ecdh
>     ecdsa
>     engine
>     err
>     filenames
>     gost
>     hw(-.+)?
>     idea
>     makedepend
>     md4
>     mdc2
>     multiblock
>     nextprotoneg
>     ocb
>     ocsp
>     pic
>     poly1305
>     posix-io
>     psk
>     rc2
>     rc4
>     rdrand
>     rfc3779
>     rmd160
>     scrypt
>     seed
>     shared
>     siphash
>     sm2
>     sm3
>     sm4
>     sock
>     srp
>     srtp
>     sse2
>     ssl
>     static-engine
>     stdio
>     tests
>     threads
>     tls
>     ts
>     ui-console
>     whirlpool
>     tls1
>     tls1-method
>     tls1_1
>     tls1_1-method
>     tls1_2
>     tls1_2-method
>     tls1_3
>     dtls1
>     dtls1-method
>     dtls1_2
>     dtls1_2-method
> Disabled features:
>     afalgeng                [not-linux]
>     asan                    [default]   OPENSSL_NO_ASAN
>     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
>     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
>     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
>     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
>     egd                     [default]   OPENSSL_NO_EGD
>     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
>     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
>     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
>     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
>     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
>     msan                    [default]   OPENSSL_NO_MSAN
>     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
>     sctp                    [default]   OPENSSL_NO_SCTP
>     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
>     ubsan                   [default]   OPENSSL_NO_UBSAN
>     unit-test               [default]   OPENSSL_NO_UNIT_TEST
>     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
>     zlib                    [default]
>     zlib-dynamic            [default]
>     ssl3                    [default]   OPENSSL_NO_SSL3
>     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> Config target attributes:
>     AR => "lib",
>     ARFLAGS => "/nologo",
>     AS => "nasm",
>     ASFLAGS => "-g",
>     CC => "cl",
>     CFLAGS => "/W3 /wd4090 /nologo /O2",
>     CPP => "\$(CC) /EP /C",
>     HASHBANGPERL => "/usr/bin/env perl",
>     LD => "link",
>     LDFLAGS => "/nologo /debug",
>     MT => "mt",
>     MTFLAGS => "-nologo",
>     RANLIB => "CODE(0x65aff0)",
>     RC => "rc",
>     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> aesni-mb-x86_64.s",
>     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> aesni-mb-x86_64.o",
>     apps_aux_src => "win32_init.c",
>     apps_init_src => "../ms/applink.c",
>     apps_obj => "win32_init.o",
>     aroutflag => "/out:",
>     asflags => "-Ox -f win64 -DNEAR",
>     asoutflag => "-o ",
>     bf_asm_src => "bf_enc.c",
>     bf_obj => "bf_enc.o",
>     bin_cflags => "/Zi /Fdapp.pdb",
>     bin_lflags => "/subsystem:console /opt:ref",
>     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
>     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
>     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
>     build_file => "makefile",
>     build_scheme => [ "unified", "windows", "VC-common" ],
>     cast_asm_src => "c_enc.c",
>     cast_obj => "c_enc.o",
>     cflags => "/Gs0 /GF /Gy /MD",
>     chacha_asm_src => "chacha-x86_64.s",
>     chacha_obj => "chacha-x86_64.o",
>     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
>     cmll_obj => "cmll-x86_64.o cmll_misc.o",
>     coutflag => "/Fo",
>     cppflags => "",
>     cpuid_asm_src => "x86_64cpuid.s",
>     cpuid_obj => "x86_64cpuid.o",
>     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
>     des_asm_src => "des_enc.c fcrypt_b.c",
>     des_obj => "des_enc.o fcrypt_b.o",
>     disable => [  ],
>     dso_cflags => "/Zi /Fddso.pdb",
>     dso_extension => "",
>     dso_scheme => "win32",
>     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
>     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
>     enable => [  ],
>     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
>     exe_extension => "",
>     includes => [  ],
>     keccak1600_asm_src => "keccak1600-x86_64.s",
>     keccak1600_obj => "keccak1600-x86_64.o",
>     ldoutflag => "/out:",
>     lflags => "",
>     lib_cflags => "/Zi /Fdossl_static.pdb",
>     lib_cppflags => "",
>     lib_defines => [ "L_ENDIAN" ],
>     md5_asm_src => "md5-x86_64.s",
>     md5_obj => "md5-x86_64.o",
>     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
>     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
>     module_cflags => "",
>     module_cxxflags => "",
>     module_ldflags => "/dll",
>     mtinflag => "-manifest ",
>     mtoutflag => "-outputresource:",
>     multilib => "-x64",
>     padlock_asm_src => "e_padlock-x86_64.s",
>     padlock_obj => "e_padlock-x86_64.o",
>     perlasm_scheme => "auto",
>     poly1305_asm_src => "poly1305-x86_64.s",
>     poly1305_obj => "poly1305-x86_64.o",
>     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
>     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
>     rc5_asm_src => "rc5_enc.c",
>     rc5_obj => "rc5_enc.o",
>     rcoutflag => "/fo",
>     rmd160_asm_src => "",
>     rmd160_obj => "",
>     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> sha1-mb-x86_64.s sha256-mb-x86_64.s",
>     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> sha1-mb-x86_64.o sha256-mb-x86_64.o",
>     shared_cflag => "",
>     shared_defines => [  ],
>     shared_extension => "",
>     shared_extension_simple => "",
>     shared_ldflag => "/dll",
>     shared_rcflag => "",
>     shared_target => "win-shared",
>     sys_id => "WIN64A",
>     thread_defines => [  ],
>     thread_scheme => "winthreads",
>     unistd => "<unistd.h>",
>     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
>     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
>     wp_asm_src => "wp-x86_64.s",
>     wp_obj => "wp-x86_64.o",
> Recorded environment:
>     AR =
>     ARFLAGS =
>     AS =
>     ASFLAGS =
>     BUILDFILE =
>     CC =
>     CFLAGS =
>     CPP =
>     CPPDEFINES =
>     CPPFLAGS =
>     CPPINCLUDES =
>     CROSS_COMPILE =
>     CXX =
>     CXXFLAGS =
>     HASHBANGPERL =
>     LD =
>     LDFLAGS =
>     LDLIBS =
>     MT =
>     MTFLAGS =
>     OPENSSL_LOCAL_CONFIG_DIR =
>     PERL =
>     RANLIB =
>     RC =
>     RCFLAGS =
>     RM =
>     WINDRES =
>     __CNF_CFLAGS =
>     __CNF_CPPDEFINES =
>     __CNF_CPPFLAGS =
>     __CNF_CPPINCLUDES =
>     __CNF_CXXFLAGS =
>     __CNF_LDFLAGS =
>     __CNF_LDLIBS =
> Makevars:
>     AR              = lib
>     ARFLAGS         = /nologo
>     AS              = nasm
>     ASFLAGS         = -g
>     CC              = cl
>     CFLAGS          = /W3 /wd4090 /nologo /O2
>     CPP             = $(CC) /EP /C
>     CPPDEFINES      =
>     CPPFLAGS        =
>     CPPINCLUDES     =
>     CXXFLAGS        =
>     HASHBANGPERL    = /usr/bin/env perl
>     LD              = link
>     LDFLAGS         = /nologo /debug
>     LDLIBS          =
>     MT              = mt
>     MTFLAGS         = -nologo
>     PERL            = c:\perl\bin\perl.exe
>     RC              = rc
> NOTE: These variables only represent the configuration view.  The build file
> template may have processed these variables further, please have a look at the
> build file for more exact data:
>     makefile
> build file:
>     makefile
> build file templates:
>     Configurations\common0.tmpl
>     Configurations\windows-makefile.tmpl
>     Configurations\common.tmpl
> 

From Matthias.St.Pierre at ncp-e.com  Tue Oct 23 07:19:53 2018
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Tue, 23 Oct 2018 07:19:53 +0000
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <ccf16fbfa118412181727ecafbdc0933@Ex13.ncp.local>
References: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>
 <ccf16fbfa118412181727ecafbdc0933@Ex13.ncp.local>
Message-ID: <060e8341750146c38ed13d9939725b66@Ex13.ncp.local>

Oh, I should have read your mail until the end:

Are you upgrading from 1.0.0h or 1.1.0h? Your post mentions both versions.

> -----Urspr?ngliche Nachricht-----
> Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Dr. Matthias St. Pierre
> Gesendet: Dienstag, 23. Oktober 2018 09:17
> An: openssl-users at openssl.org
> Betreff: Re: [openssl-users] How to compile 1.1.1 under Windows
> 
> Hi,
> 
> a lot of structures where made opaque going from 1.0.2 to 1.1.0.
> This means, you will have to make changes to your program source code
> to compile it against 1.1.0 or 1.1.1.
> 
> For details, see https://www.openssl.org/docs/faq.html#PROG2
> 
> HTH,
> Matthias
> 
> 
> > -----Urspr?ngliche Nachricht-----
> > Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Chris Clark
> > Gesendet: Dienstag, 23. Oktober 2018 08:51
> > An: openssl-users at openssl.org
> > Betreff: [openssl-users] How to compile 1.1.1 under Windows
> >
> > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > 1.1.1 for VC-WIN64A I get the following compile error:
> >
> >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > Files\\Common Files\\SSL\""
> > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > Stop.
> >
> > My Command lines from the VS 2008 x64 Command Prompt are:
> > perl Configure VC-WIN64A --prefix=c:/openssl
> > nmake
> >
> > I also tried compiling the latest stable snapshot
> > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > version 1.1.0h compiles without error. Can anyone tell me what the
> > problem is?
> >
> > Here is the configuration dump:
> >
> > Command line (with current working directory = .):
> >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > Perl information:
> >     c:\perl\bin\perl.exe
> >     5.24.3 for MSWin32-x64-multi-thread
> > Enabled features:
> >     aria
> >     asm
> >     async
> >     autoalginit
> >     autoerrinit
> >     autoload-config
> >     bf
> >     blake2
> >     camellia
> >     capieng
> >     cast
> >     chacha
> >     cmac
> >     cms
> >     comp
> >     ct
> >     deprecated
> >     des
> >     dgram
> >     dh
> >     dsa
> >     dso
> >     dtls
> >     dynamic-engine
> >     ec
> >     ec2m
> >     ecdh
> >     ecdsa
> >     engine
> >     err
> >     filenames
> >     gost
> >     hw(-.+)?
> >     idea
> >     makedepend
> >     md4
> >     mdc2
> >     multiblock
> >     nextprotoneg
> >     ocb
> >     ocsp
> >     pic
> >     poly1305
> >     posix-io
> >     psk
> >     rc2
> >     rc4
> >     rdrand
> >     rfc3779
> >     rmd160
> >     scrypt
> >     seed
> >     shared
> >     siphash
> >     sm2
> >     sm3
> >     sm4
> >     sock
> >     srp
> >     srtp
> >     sse2
> >     ssl
> >     static-engine
> >     stdio
> >     tests
> >     threads
> >     tls
> >     ts
> >     ui-console
> >     whirlpool
> >     tls1
> >     tls1-method
> >     tls1_1
> >     tls1_1-method
> >     tls1_2
> >     tls1_2-method
> >     tls1_3
> >     dtls1
> >     dtls1-method
> >     dtls1_2
> >     dtls1_2-method
> > Disabled features:
> >     afalgeng                [not-linux]
> >     asan                    [default]   OPENSSL_NO_ASAN
> >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> >     egd                     [default]   OPENSSL_NO_EGD
> >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> >     msan                    [default]   OPENSSL_NO_MSAN
> >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> >     sctp                    [default]   OPENSSL_NO_SCTP
> >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> >     ubsan                   [default]   OPENSSL_NO_UBSAN
> >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> >     zlib                    [default]
> >     zlib-dynamic            [default]
> >     ssl3                    [default]   OPENSSL_NO_SSL3
> >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > Config target attributes:
> >     AR => "lib",
> >     ARFLAGS => "/nologo",
> >     AS => "nasm",
> >     ASFLAGS => "-g",
> >     CC => "cl",
> >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> >     CPP => "\$(CC) /EP /C",
> >     HASHBANGPERL => "/usr/bin/env perl",
> >     LD => "link",
> >     LDFLAGS => "/nologo /debug",
> >     MT => "mt",
> >     MTFLAGS => "-nologo",
> >     RANLIB => "CODE(0x65aff0)",
> >     RC => "rc",
> >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > aesni-mb-x86_64.s",
> >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > aesni-mb-x86_64.o",
> >     apps_aux_src => "win32_init.c",
> >     apps_init_src => "../ms/applink.c",
> >     apps_obj => "win32_init.o",
> >     aroutflag => "/out:",
> >     asflags => "-Ox -f win64 -DNEAR",
> >     asoutflag => "-o ",
> >     bf_asm_src => "bf_enc.c",
> >     bf_obj => "bf_enc.o",
> >     bin_cflags => "/Zi /Fdapp.pdb",
> >     bin_lflags => "/subsystem:console /opt:ref",
> >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> >     build_file => "makefile",
> >     build_scheme => [ "unified", "windows", "VC-common" ],
> >     cast_asm_src => "c_enc.c",
> >     cast_obj => "c_enc.o",
> >     cflags => "/Gs0 /GF /Gy /MD",
> >     chacha_asm_src => "chacha-x86_64.s",
> >     chacha_obj => "chacha-x86_64.o",
> >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> >     coutflag => "/Fo",
> >     cppflags => "",
> >     cpuid_asm_src => "x86_64cpuid.s",
> >     cpuid_obj => "x86_64cpuid.o",
> >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> >     des_asm_src => "des_enc.c fcrypt_b.c",
> >     des_obj => "des_enc.o fcrypt_b.o",
> >     disable => [  ],
> >     dso_cflags => "/Zi /Fddso.pdb",
> >     dso_extension => "",
> >     dso_scheme => "win32",
> >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> >     enable => [  ],
> >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> >     exe_extension => "",
> >     includes => [  ],
> >     keccak1600_asm_src => "keccak1600-x86_64.s",
> >     keccak1600_obj => "keccak1600-x86_64.o",
> >     ldoutflag => "/out:",
> >     lflags => "",
> >     lib_cflags => "/Zi /Fdossl_static.pdb",
> >     lib_cppflags => "",
> >     lib_defines => [ "L_ENDIAN" ],
> >     md5_asm_src => "md5-x86_64.s",
> >     md5_obj => "md5-x86_64.o",
> >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> >     module_cflags => "",
> >     module_cxxflags => "",
> >     module_ldflags => "/dll",
> >     mtinflag => "-manifest ",
> >     mtoutflag => "-outputresource:",
> >     multilib => "-x64",
> >     padlock_asm_src => "e_padlock-x86_64.s",
> >     padlock_obj => "e_padlock-x86_64.o",
> >     perlasm_scheme => "auto",
> >     poly1305_asm_src => "poly1305-x86_64.s",
> >     poly1305_obj => "poly1305-x86_64.o",
> >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> >     rc5_asm_src => "rc5_enc.c",
> >     rc5_obj => "rc5_enc.o",
> >     rcoutflag => "/fo",
> >     rmd160_asm_src => "",
> >     rmd160_obj => "",
> >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> >     shared_cflag => "",
> >     shared_defines => [  ],
> >     shared_extension => "",
> >     shared_extension_simple => "",
> >     shared_ldflag => "/dll",
> >     shared_rcflag => "",
> >     shared_target => "win-shared",
> >     sys_id => "WIN64A",
> >     thread_defines => [  ],
> >     thread_scheme => "winthreads",
> >     unistd => "<unistd.h>",
> >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> >     wp_asm_src => "wp-x86_64.s",
> >     wp_obj => "wp-x86_64.o",
> > Recorded environment:
> >     AR =
> >     ARFLAGS =
> >     AS =
> >     ASFLAGS =
> >     BUILDFILE =
> >     CC =
> >     CFLAGS =
> >     CPP =
> >     CPPDEFINES =
> >     CPPFLAGS =
> >     CPPINCLUDES =
> >     CROSS_COMPILE =
> >     CXX =
> >     CXXFLAGS =
> >     HASHBANGPERL =
> >     LD =
> >     LDFLAGS =
> >     LDLIBS =
> >     MT =
> >     MTFLAGS =
> >     OPENSSL_LOCAL_CONFIG_DIR =
> >     PERL =
> >     RANLIB =
> >     RC =
> >     RCFLAGS =
> >     RM =
> >     WINDRES =
> >     __CNF_CFLAGS =
> >     __CNF_CPPDEFINES =
> >     __CNF_CPPFLAGS =
> >     __CNF_CPPINCLUDES =
> >     __CNF_CXXFLAGS =
> >     __CNF_LDFLAGS =
> >     __CNF_LDLIBS =
> > Makevars:
> >     AR              = lib
> >     ARFLAGS         = /nologo
> >     AS              = nasm
> >     ASFLAGS         = -g
> >     CC              = cl
> >     CFLAGS          = /W3 /wd4090 /nologo /O2
> >     CPP             = $(CC) /EP /C
> >     CPPDEFINES      =
> >     CPPFLAGS        =
> >     CPPINCLUDES     =
> >     CXXFLAGS        =
> >     HASHBANGPERL    = /usr/bin/env perl
> >     LD              = link
> >     LDFLAGS         = /nologo /debug
> >     LDLIBS          =
> >     MT              = mt
> >     MTFLAGS         = -nologo
> >     PERL            = c:\perl\bin\perl.exe
> >     RC              = rc
> > NOTE: These variables only represent the configuration view.  The build file
> > template may have processed these variables further, please have a look at the
> > build file for more exact data:
> >     makefile
> > build file:
> >     makefile
> > build file templates:
> >     Configurations\common0.tmpl
> >     Configurations\windows-makefile.tmpl
> >     Configurations\common.tmpl
> > --
> > 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 a.chris.clark at gmail.com  Tue Oct 23 08:21:48 2018
From: a.chris.clark at gmail.com (Chris Clark)
Date: Tue, 23 Oct 2018 01:21:48 -0700
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <060e8341750146c38ed13d9939725b66@Ex13.ncp.local>
References: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>
 <ccf16fbfa118412181727ecafbdc0933@Ex13.ncp.local>
 <060e8341750146c38ed13d9939725b66@Ex13.ncp.local>
Message-ID: <CACaGmvBGJBVtvVr2y14q2s=QEmmZzEy048r_5fpqWAyLGFcXvg@mail.gmail.com>

Sorry, I meant to say I'm upgrading from 1.1.0h.
On Tue, Oct 23, 2018 at 12:20 AM Dr. Matthias St. Pierre
<Matthias.St.Pierre at ncp-e.com> wrote:
>
> Oh, I should have read your mail until the end:
>
> Are you upgrading from 1.0.0h or 1.1.0h? Your post mentions both versions.
>
> > -----Urspr?ngliche Nachricht-----
> > Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Dr. Matthias St. Pierre
> > Gesendet: Dienstag, 23. Oktober 2018 09:17
> > An: openssl-users at openssl.org
> > Betreff: Re: [openssl-users] How to compile 1.1.1 under Windows
> >
> > Hi,
> >
> > a lot of structures where made opaque going from 1.0.2 to 1.1.0.
> > This means, you will have to make changes to your program source code
> > to compile it against 1.1.0 or 1.1.1.
> >
> > For details, see https://www.openssl.org/docs/faq.html#PROG2
> >
> > HTH,
> > Matthias
> >
> >
> > > -----Urspr?ngliche Nachricht-----
> > > Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Chris Clark
> > > Gesendet: Dienstag, 23. Oktober 2018 08:51
> > > An: openssl-users at openssl.org
> > > Betreff: [openssl-users] How to compile 1.1.1 under Windows
> > >
> > > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > > 1.1.1 for VC-WIN64A I get the following compile error:
> > >
> > >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > > Files\\Common Files\\SSL\""
> > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > > Stop.
> > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > Stop.
> > >
> > > My Command lines from the VS 2008 x64 Command Prompt are:
> > > perl Configure VC-WIN64A --prefix=c:/openssl
> > > nmake
> > >
> > > I also tried compiling the latest stable snapshot
> > > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > > version 1.1.0h compiles without error. Can anyone tell me what the
> > > problem is?
> > >
> > > Here is the configuration dump:
> > >
> > > Command line (with current working directory = .):
> > >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > > Perl information:
> > >     c:\perl\bin\perl.exe
> > >     5.24.3 for MSWin32-x64-multi-thread
> > > Enabled features:
> > >     aria
> > >     asm
> > >     async
> > >     autoalginit
> > >     autoerrinit
> > >     autoload-config
> > >     bf
> > >     blake2
> > >     camellia
> > >     capieng
> > >     cast
> > >     chacha
> > >     cmac
> > >     cms
> > >     comp
> > >     ct
> > >     deprecated
> > >     des
> > >     dgram
> > >     dh
> > >     dsa
> > >     dso
> > >     dtls
> > >     dynamic-engine
> > >     ec
> > >     ec2m
> > >     ecdh
> > >     ecdsa
> > >     engine
> > >     err
> > >     filenames
> > >     gost
> > >     hw(-.+)?
> > >     idea
> > >     makedepend
> > >     md4
> > >     mdc2
> > >     multiblock
> > >     nextprotoneg
> > >     ocb
> > >     ocsp
> > >     pic
> > >     poly1305
> > >     posix-io
> > >     psk
> > >     rc2
> > >     rc4
> > >     rdrand
> > >     rfc3779
> > >     rmd160
> > >     scrypt
> > >     seed
> > >     shared
> > >     siphash
> > >     sm2
> > >     sm3
> > >     sm4
> > >     sock
> > >     srp
> > >     srtp
> > >     sse2
> > >     ssl
> > >     static-engine
> > >     stdio
> > >     tests
> > >     threads
> > >     tls
> > >     ts
> > >     ui-console
> > >     whirlpool
> > >     tls1
> > >     tls1-method
> > >     tls1_1
> > >     tls1_1-method
> > >     tls1_2
> > >     tls1_2-method
> > >     tls1_3
> > >     dtls1
> > >     dtls1-method
> > >     dtls1_2
> > >     dtls1_2-method
> > > Disabled features:
> > >     afalgeng                [not-linux]
> > >     asan                    [default]   OPENSSL_NO_ASAN
> > >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> > >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> > >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> > >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> > >     egd                     [default]   OPENSSL_NO_EGD
> > >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> > >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> > >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> > >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> > >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> > >     msan                    [default]   OPENSSL_NO_MSAN
> > >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> > >     sctp                    [default]   OPENSSL_NO_SCTP
> > >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> > >     ubsan                   [default]   OPENSSL_NO_UBSAN
> > >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> > >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> > >     zlib                    [default]
> > >     zlib-dynamic            [default]
> > >     ssl3                    [default]   OPENSSL_NO_SSL3
> > >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > > Config target attributes:
> > >     AR => "lib",
> > >     ARFLAGS => "/nologo",
> > >     AS => "nasm",
> > >     ASFLAGS => "-g",
> > >     CC => "cl",
> > >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> > >     CPP => "\$(CC) /EP /C",
> > >     HASHBANGPERL => "/usr/bin/env perl",
> > >     LD => "link",
> > >     LDFLAGS => "/nologo /debug",
> > >     MT => "mt",
> > >     MTFLAGS => "-nologo",
> > >     RANLIB => "CODE(0x65aff0)",
> > >     RC => "rc",
> > >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > > aesni-mb-x86_64.s",
> > >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > > aesni-mb-x86_64.o",
> > >     apps_aux_src => "win32_init.c",
> > >     apps_init_src => "../ms/applink.c",
> > >     apps_obj => "win32_init.o",
> > >     aroutflag => "/out:",
> > >     asflags => "-Ox -f win64 -DNEAR",
> > >     asoutflag => "-o ",
> > >     bf_asm_src => "bf_enc.c",
> > >     bf_obj => "bf_enc.o",
> > >     bin_cflags => "/Zi /Fdapp.pdb",
> > >     bin_lflags => "/subsystem:console /opt:ref",
> > >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> > >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> > >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> > >     build_file => "makefile",
> > >     build_scheme => [ "unified", "windows", "VC-common" ],
> > >     cast_asm_src => "c_enc.c",
> > >     cast_obj => "c_enc.o",
> > >     cflags => "/Gs0 /GF /Gy /MD",
> > >     chacha_asm_src => "chacha-x86_64.s",
> > >     chacha_obj => "chacha-x86_64.o",
> > >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> > >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> > >     coutflag => "/Fo",
> > >     cppflags => "",
> > >     cpuid_asm_src => "x86_64cpuid.s",
> > >     cpuid_obj => "x86_64cpuid.o",
> > >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> > >     des_asm_src => "des_enc.c fcrypt_b.c",
> > >     des_obj => "des_enc.o fcrypt_b.o",
> > >     disable => [  ],
> > >     dso_cflags => "/Zi /Fddso.pdb",
> > >     dso_extension => "",
> > >     dso_scheme => "win32",
> > >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> > >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> > >     enable => [  ],
> > >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> > >     exe_extension => "",
> > >     includes => [  ],
> > >     keccak1600_asm_src => "keccak1600-x86_64.s",
> > >     keccak1600_obj => "keccak1600-x86_64.o",
> > >     ldoutflag => "/out:",
> > >     lflags => "",
> > >     lib_cflags => "/Zi /Fdossl_static.pdb",
> > >     lib_cppflags => "",
> > >     lib_defines => [ "L_ENDIAN" ],
> > >     md5_asm_src => "md5-x86_64.s",
> > >     md5_obj => "md5-x86_64.o",
> > >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> > >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> > >     module_cflags => "",
> > >     module_cxxflags => "",
> > >     module_ldflags => "/dll",
> > >     mtinflag => "-manifest ",
> > >     mtoutflag => "-outputresource:",
> > >     multilib => "-x64",
> > >     padlock_asm_src => "e_padlock-x86_64.s",
> > >     padlock_obj => "e_padlock-x86_64.o",
> > >     perlasm_scheme => "auto",
> > >     poly1305_asm_src => "poly1305-x86_64.s",
> > >     poly1305_obj => "poly1305-x86_64.o",
> > >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> > >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> > >     rc5_asm_src => "rc5_enc.c",
> > >     rc5_obj => "rc5_enc.o",
> > >     rcoutflag => "/fo",
> > >     rmd160_asm_src => "",
> > >     rmd160_obj => "",
> > >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> > >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> > >     shared_cflag => "",
> > >     shared_defines => [  ],
> > >     shared_extension => "",
> > >     shared_extension_simple => "",
> > >     shared_ldflag => "/dll",
> > >     shared_rcflag => "",
> > >     shared_target => "win-shared",
> > >     sys_id => "WIN64A",
> > >     thread_defines => [  ],
> > >     thread_scheme => "winthreads",
> > >     unistd => "<unistd.h>",
> > >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> > >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> > >     wp_asm_src => "wp-x86_64.s",
> > >     wp_obj => "wp-x86_64.o",
> > > Recorded environment:
> > >     AR =
> > >     ARFLAGS =
> > >     AS =
> > >     ASFLAGS =
> > >     BUILDFILE =
> > >     CC =
> > >     CFLAGS =
> > >     CPP =
> > >     CPPDEFINES =
> > >     CPPFLAGS =
> > >     CPPINCLUDES =
> > >     CROSS_COMPILE =
> > >     CXX =
> > >     CXXFLAGS =
> > >     HASHBANGPERL =
> > >     LD =
> > >     LDFLAGS =
> > >     LDLIBS =
> > >     MT =
> > >     MTFLAGS =
> > >     OPENSSL_LOCAL_CONFIG_DIR =
> > >     PERL =
> > >     RANLIB =
> > >     RC =
> > >     RCFLAGS =
> > >     RM =
> > >     WINDRES =
> > >     __CNF_CFLAGS =
> > >     __CNF_CPPDEFINES =
> > >     __CNF_CPPFLAGS =
> > >     __CNF_CPPINCLUDES =
> > >     __CNF_CXXFLAGS =
> > >     __CNF_LDFLAGS =
> > >     __CNF_LDLIBS =
> > > Makevars:
> > >     AR              = lib
> > >     ARFLAGS         = /nologo
> > >     AS              = nasm
> > >     ASFLAGS         = -g
> > >     CC              = cl
> > >     CFLAGS          = /W3 /wd4090 /nologo /O2
> > >     CPP             = $(CC) /EP /C
> > >     CPPDEFINES      =
> > >     CPPFLAGS        =
> > >     CPPINCLUDES     =
> > >     CXXFLAGS        =
> > >     HASHBANGPERL    = /usr/bin/env perl
> > >     LD              = link
> > >     LDFLAGS         = /nologo /debug
> > >     LDLIBS          =
> > >     MT              = mt
> > >     MTFLAGS         = -nologo
> > >     PERL            = c:\perl\bin\perl.exe
> > >     RC              = rc
> > > NOTE: These variables only represent the configuration view.  The build file
> > > template may have processed these variables further, please have a look at the
> > > build file for more exact data:
> > >     makefile
> > > build file:
> > >     makefile
> > > build file templates:
> > >     Configurations\common0.tmpl
> > >     Configurations\windows-makefile.tmpl
> > >     Configurations\common.tmpl
> > > --
> > > 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
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From a.chris.clark at gmail.com  Tue Oct 23 08:22:34 2018
From: a.chris.clark at gmail.com (Chris Clark)
Date: Tue, 23 Oct 2018 01:22:34 -0700
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <20181023.091913.2165099182291788730.levitte@openssl.org>
References: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>
 <20181023.091913.2165099182291788730.levitte@openssl.org>
Message-ID: <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q@mail.gmail.com>

Thank you Richard. Adding the "no-makedepend" avoided the  fatal error
U1077, but now it fails due to an undeclared identifier:

cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I
"." /I "crypto\include" /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC"
-D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
-D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
-D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM"
-D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM"
-D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"PADLOCK_ASM" -D"POLY1305_ASM"
-D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\sm2\sm2_sign.obj
"crypto\sm2\sm2_sign.c"
sm2_sign.c
crypto\sm2\sm2_sign.c(70) : error C2065: 'UINT16_MAX' : undeclared identifier
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
On Tue, Oct 23, 2018 at 12:19 AM Richard Levitte <levitte at openssl.org> wrote:
>
> I suspect you'll find some kind of error message in
> crypto\sm2\sm2_sign.d.  I suspect that /showIncludes isn't supported
> in VS 2008.
>
> There is a workaround for this problem, and it's to use the
> 'no-makedepend' option:
>
>     perl Configure VC-WIN64A --prefix=c:/openssl no-makedepend
>
> For a single build, that should be good enough.
>
> Cheers,
> Richard
>
> In message <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ at mail.gmail.com> on Mon, 22 Oct 2018 23:50:46 -0700, Chris Clark <a.chris.clark at gmail.com> said:
>
> > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > 1.1.1 for VC-WIN64A I get the following compile error:
> >
> >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > Files\\Common Files\\SSL\""
> > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > Stop.
> >
> > My Command lines from the VS 2008 x64 Command Prompt are:
> > perl Configure VC-WIN64A --prefix=c:/openssl
> > nmake
> >
> > I also tried compiling the latest stable snapshot
> > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > version 1.1.0h compiles without error. Can anyone tell me what the
> > problem is?
> >
> > Here is the configuration dump:
> >
> > Command line (with current working directory = .):
> >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > Perl information:
> >     c:\perl\bin\perl.exe
> >     5.24.3 for MSWin32-x64-multi-thread
> > Enabled features:
> >     aria
> >     asm
> >     async
> >     autoalginit
> >     autoerrinit
> >     autoload-config
> >     bf
> >     blake2
> >     camellia
> >     capieng
> >     cast
> >     chacha
> >     cmac
> >     cms
> >     comp
> >     ct
> >     deprecated
> >     des
> >     dgram
> >     dh
> >     dsa
> >     dso
> >     dtls
> >     dynamic-engine
> >     ec
> >     ec2m
> >     ecdh
> >     ecdsa
> >     engine
> >     err
> >     filenames
> >     gost
> >     hw(-.+)?
> >     idea
> >     makedepend
> >     md4
> >     mdc2
> >     multiblock
> >     nextprotoneg
> >     ocb
> >     ocsp
> >     pic
> >     poly1305
> >     posix-io
> >     psk
> >     rc2
> >     rc4
> >     rdrand
> >     rfc3779
> >     rmd160
> >     scrypt
> >     seed
> >     shared
> >     siphash
> >     sm2
> >     sm3
> >     sm4
> >     sock
> >     srp
> >     srtp
> >     sse2
> >     ssl
> >     static-engine
> >     stdio
> >     tests
> >     threads
> >     tls
> >     ts
> >     ui-console
> >     whirlpool
> >     tls1
> >     tls1-method
> >     tls1_1
> >     tls1_1-method
> >     tls1_2
> >     tls1_2-method
> >     tls1_3
> >     dtls1
> >     dtls1-method
> >     dtls1_2
> >     dtls1_2-method
> > Disabled features:
> >     afalgeng                [not-linux]
> >     asan                    [default]   OPENSSL_NO_ASAN
> >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> >     egd                     [default]   OPENSSL_NO_EGD
> >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> >     msan                    [default]   OPENSSL_NO_MSAN
> >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> >     sctp                    [default]   OPENSSL_NO_SCTP
> >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> >     ubsan                   [default]   OPENSSL_NO_UBSAN
> >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> >     zlib                    [default]
> >     zlib-dynamic            [default]
> >     ssl3                    [default]   OPENSSL_NO_SSL3
> >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > Config target attributes:
> >     AR => "lib",
> >     ARFLAGS => "/nologo",
> >     AS => "nasm",
> >     ASFLAGS => "-g",
> >     CC => "cl",
> >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> >     CPP => "\$(CC) /EP /C",
> >     HASHBANGPERL => "/usr/bin/env perl",
> >     LD => "link",
> >     LDFLAGS => "/nologo /debug",
> >     MT => "mt",
> >     MTFLAGS => "-nologo",
> >     RANLIB => "CODE(0x65aff0)",
> >     RC => "rc",
> >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > aesni-mb-x86_64.s",
> >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > aesni-mb-x86_64.o",
> >     apps_aux_src => "win32_init.c",
> >     apps_init_src => "../ms/applink.c",
> >     apps_obj => "win32_init.o",
> >     aroutflag => "/out:",
> >     asflags => "-Ox -f win64 -DNEAR",
> >     asoutflag => "-o ",
> >     bf_asm_src => "bf_enc.c",
> >     bf_obj => "bf_enc.o",
> >     bin_cflags => "/Zi /Fdapp.pdb",
> >     bin_lflags => "/subsystem:console /opt:ref",
> >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> >     build_file => "makefile",
> >     build_scheme => [ "unified", "windows", "VC-common" ],
> >     cast_asm_src => "c_enc.c",
> >     cast_obj => "c_enc.o",
> >     cflags => "/Gs0 /GF /Gy /MD",
> >     chacha_asm_src => "chacha-x86_64.s",
> >     chacha_obj => "chacha-x86_64.o",
> >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> >     coutflag => "/Fo",
> >     cppflags => "",
> >     cpuid_asm_src => "x86_64cpuid.s",
> >     cpuid_obj => "x86_64cpuid.o",
> >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> >     des_asm_src => "des_enc.c fcrypt_b.c",
> >     des_obj => "des_enc.o fcrypt_b.o",
> >     disable => [  ],
> >     dso_cflags => "/Zi /Fddso.pdb",
> >     dso_extension => "",
> >     dso_scheme => "win32",
> >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> >     enable => [  ],
> >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> >     exe_extension => "",
> >     includes => [  ],
> >     keccak1600_asm_src => "keccak1600-x86_64.s",
> >     keccak1600_obj => "keccak1600-x86_64.o",
> >     ldoutflag => "/out:",
> >     lflags => "",
> >     lib_cflags => "/Zi /Fdossl_static.pdb",
> >     lib_cppflags => "",
> >     lib_defines => [ "L_ENDIAN" ],
> >     md5_asm_src => "md5-x86_64.s",
> >     md5_obj => "md5-x86_64.o",
> >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> >     module_cflags => "",
> >     module_cxxflags => "",
> >     module_ldflags => "/dll",
> >     mtinflag => "-manifest ",
> >     mtoutflag => "-outputresource:",
> >     multilib => "-x64",
> >     padlock_asm_src => "e_padlock-x86_64.s",
> >     padlock_obj => "e_padlock-x86_64.o",
> >     perlasm_scheme => "auto",
> >     poly1305_asm_src => "poly1305-x86_64.s",
> >     poly1305_obj => "poly1305-x86_64.o",
> >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> >     rc5_asm_src => "rc5_enc.c",
> >     rc5_obj => "rc5_enc.o",
> >     rcoutflag => "/fo",
> >     rmd160_asm_src => "",
> >     rmd160_obj => "",
> >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> >     shared_cflag => "",
> >     shared_defines => [  ],
> >     shared_extension => "",
> >     shared_extension_simple => "",
> >     shared_ldflag => "/dll",
> >     shared_rcflag => "",
> >     shared_target => "win-shared",
> >     sys_id => "WIN64A",
> >     thread_defines => [  ],
> >     thread_scheme => "winthreads",
> >     unistd => "<unistd.h>",
> >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> >     wp_asm_src => "wp-x86_64.s",
> >     wp_obj => "wp-x86_64.o",
> > Recorded environment:
> >     AR =
> >     ARFLAGS =
> >     AS =
> >     ASFLAGS =
> >     BUILDFILE =
> >     CC =
> >     CFLAGS =
> >     CPP =
> >     CPPDEFINES =
> >     CPPFLAGS =
> >     CPPINCLUDES =
> >     CROSS_COMPILE =
> >     CXX =
> >     CXXFLAGS =
> >     HASHBANGPERL =
> >     LD =
> >     LDFLAGS =
> >     LDLIBS =
> >     MT =
> >     MTFLAGS =
> >     OPENSSL_LOCAL_CONFIG_DIR =
> >     PERL =
> >     RANLIB =
> >     RC =
> >     RCFLAGS =
> >     RM =
> >     WINDRES =
> >     __CNF_CFLAGS =
> >     __CNF_CPPDEFINES =
> >     __CNF_CPPFLAGS =
> >     __CNF_CPPINCLUDES =
> >     __CNF_CXXFLAGS =
> >     __CNF_LDFLAGS =
> >     __CNF_LDLIBS =
> > Makevars:
> >     AR              = lib
> >     ARFLAGS         = /nologo
> >     AS              = nasm
> >     ASFLAGS         = -g
> >     CC              = cl
> >     CFLAGS          = /W3 /wd4090 /nologo /O2
> >     CPP             = $(CC) /EP /C
> >     CPPDEFINES      =
> >     CPPFLAGS        =
> >     CPPINCLUDES     =
> >     CXXFLAGS        =
> >     HASHBANGPERL    = /usr/bin/env perl
> >     LD              = link
> >     LDFLAGS         = /nologo /debug
> >     LDLIBS          =
> >     MT              = mt
> >     MTFLAGS         = -nologo
> >     PERL            = c:\perl\bin\perl.exe
> >     RC              = rc
> > NOTE: These variables only represent the configuration view.  The build file
> > template may have processed these variables further, please have a look at the
> > build file for more exact data:
> >     makefile
> > build file:
> >     makefile
> > build file templates:
> >     Configurations\common0.tmpl
> >     Configurations\windows-makefile.tmpl
> >     Configurations\common.tmpl
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From levitte at openssl.org  Tue Oct 23 08:34:53 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 23 Oct 2018 10:34:53 +0200 (CEST)
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q@mail.gmail.com>
References: <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ@mail.gmail.com>
 <20181023.091913.2165099182291788730.levitte@openssl.org>
 <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q@mail.gmail.com>
Message-ID: <20181023.103453.1842719922424343673.levitte@openssl.org>

That indicates we do things in the wrong order (foo.obj depends on
foo.d, meaning foo.d gets "built" first), but that's a side issue.

You found a bug in crypto\sm2\sm2_sign.c, thank you.  Are you willing
to write up a Github issue for it?

In message <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q at mail.gmail.com> on Tue, 23 Oct 2018 01:22:34 -0700, Chris Clark <a.chris.clark at gmail.com> said:

> Thank you Richard. Adding the "no-makedepend" avoided the  fatal error
> U1077, but now it fails due to an undeclared identifier:
> 
> cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I
> "." /I "crypto\include" /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC"
> -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
> -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
> -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM"
> -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM"
> -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"PADLOCK_ASM" -D"POLY1305_ASM"
> -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
> -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\sm2\sm2_sign.obj
> "crypto\sm2\sm2_sign.c"
> sm2_sign.c
> crypto\sm2\sm2_sign.c(70) : error C2065: 'UINT16_MAX' : undeclared identifier
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> Stop.
> On Tue, Oct 23, 2018 at 12:19 AM Richard Levitte <levitte at openssl.org> wrote:
> >
> > I suspect you'll find some kind of error message in
> > crypto\sm2\sm2_sign.d.  I suspect that /showIncludes isn't supported
> > in VS 2008.
> >
> > There is a workaround for this problem, and it's to use the
> > 'no-makedepend' option:
> >
> >     perl Configure VC-WIN64A --prefix=c:/openssl no-makedepend
> >
> > For a single build, that should be good enough.
> >
> > Cheers,
> > Richard
> >
> > In message <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ at mail.gmail.com> on Mon, 22 Oct 2018 23:50:46 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> >
> > > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > > 1.1.1 for VC-WIN64A I get the following compile error:
> > >
> > >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > > Files\\Common Files\\SSL\""
> > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > > Stop.
> > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > Stop.
> > >
> > > My Command lines from the VS 2008 x64 Command Prompt are:
> > > perl Configure VC-WIN64A --prefix=c:/openssl
> > > nmake
> > >
> > > I also tried compiling the latest stable snapshot
> > > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > > version 1.1.0h compiles without error. Can anyone tell me what the
> > > problem is?
> > >
> > > Here is the configuration dump:
> > >
> > > Command line (with current working directory = .):
> > >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > > Perl information:
> > >     c:\perl\bin\perl.exe
> > >     5.24.3 for MSWin32-x64-multi-thread
> > > Enabled features:
> > >     aria
> > >     asm
> > >     async
> > >     autoalginit
> > >     autoerrinit
> > >     autoload-config
> > >     bf
> > >     blake2
> > >     camellia
> > >     capieng
> > >     cast
> > >     chacha
> > >     cmac
> > >     cms
> > >     comp
> > >     ct
> > >     deprecated
> > >     des
> > >     dgram
> > >     dh
> > >     dsa
> > >     dso
> > >     dtls
> > >     dynamic-engine
> > >     ec
> > >     ec2m
> > >     ecdh
> > >     ecdsa
> > >     engine
> > >     err
> > >     filenames
> > >     gost
> > >     hw(-.+)?
> > >     idea
> > >     makedepend
> > >     md4
> > >     mdc2
> > >     multiblock
> > >     nextprotoneg
> > >     ocb
> > >     ocsp
> > >     pic
> > >     poly1305
> > >     posix-io
> > >     psk
> > >     rc2
> > >     rc4
> > >     rdrand
> > >     rfc3779
> > >     rmd160
> > >     scrypt
> > >     seed
> > >     shared
> > >     siphash
> > >     sm2
> > >     sm3
> > >     sm4
> > >     sock
> > >     srp
> > >     srtp
> > >     sse2
> > >     ssl
> > >     static-engine
> > >     stdio
> > >     tests
> > >     threads
> > >     tls
> > >     ts
> > >     ui-console
> > >     whirlpool
> > >     tls1
> > >     tls1-method
> > >     tls1_1
> > >     tls1_1-method
> > >     tls1_2
> > >     tls1_2-method
> > >     tls1_3
> > >     dtls1
> > >     dtls1-method
> > >     dtls1_2
> > >     dtls1_2-method
> > > Disabled features:
> > >     afalgeng                [not-linux]
> > >     asan                    [default]   OPENSSL_NO_ASAN
> > >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> > >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> > >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> > >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> > >     egd                     [default]   OPENSSL_NO_EGD
> > >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> > >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> > >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> > >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> > >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> > >     msan                    [default]   OPENSSL_NO_MSAN
> > >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> > >     sctp                    [default]   OPENSSL_NO_SCTP
> > >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> > >     ubsan                   [default]   OPENSSL_NO_UBSAN
> > >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> > >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> > >     zlib                    [default]
> > >     zlib-dynamic            [default]
> > >     ssl3                    [default]   OPENSSL_NO_SSL3
> > >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > > Config target attributes:
> > >     AR => "lib",
> > >     ARFLAGS => "/nologo",
> > >     AS => "nasm",
> > >     ASFLAGS => "-g",
> > >     CC => "cl",
> > >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> > >     CPP => "\$(CC) /EP /C",
> > >     HASHBANGPERL => "/usr/bin/env perl",
> > >     LD => "link",
> > >     LDFLAGS => "/nologo /debug",
> > >     MT => "mt",
> > >     MTFLAGS => "-nologo",
> > >     RANLIB => "CODE(0x65aff0)",
> > >     RC => "rc",
> > >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > > aesni-mb-x86_64.s",
> > >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > > aesni-mb-x86_64.o",
> > >     apps_aux_src => "win32_init.c",
> > >     apps_init_src => "../ms/applink.c",
> > >     apps_obj => "win32_init.o",
> > >     aroutflag => "/out:",
> > >     asflags => "-Ox -f win64 -DNEAR",
> > >     asoutflag => "-o ",
> > >     bf_asm_src => "bf_enc.c",
> > >     bf_obj => "bf_enc.o",
> > >     bin_cflags => "/Zi /Fdapp.pdb",
> > >     bin_lflags => "/subsystem:console /opt:ref",
> > >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> > >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> > >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> > >     build_file => "makefile",
> > >     build_scheme => [ "unified", "windows", "VC-common" ],
> > >     cast_asm_src => "c_enc.c",
> > >     cast_obj => "c_enc.o",
> > >     cflags => "/Gs0 /GF /Gy /MD",
> > >     chacha_asm_src => "chacha-x86_64.s",
> > >     chacha_obj => "chacha-x86_64.o",
> > >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> > >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> > >     coutflag => "/Fo",
> > >     cppflags => "",
> > >     cpuid_asm_src => "x86_64cpuid.s",
> > >     cpuid_obj => "x86_64cpuid.o",
> > >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> > >     des_asm_src => "des_enc.c fcrypt_b.c",
> > >     des_obj => "des_enc.o fcrypt_b.o",
> > >     disable => [  ],
> > >     dso_cflags => "/Zi /Fddso.pdb",
> > >     dso_extension => "",
> > >     dso_scheme => "win32",
> > >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> > >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> > >     enable => [  ],
> > >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> > >     exe_extension => "",
> > >     includes => [  ],
> > >     keccak1600_asm_src => "keccak1600-x86_64.s",
> > >     keccak1600_obj => "keccak1600-x86_64.o",
> > >     ldoutflag => "/out:",
> > >     lflags => "",
> > >     lib_cflags => "/Zi /Fdossl_static.pdb",
> > >     lib_cppflags => "",
> > >     lib_defines => [ "L_ENDIAN" ],
> > >     md5_asm_src => "md5-x86_64.s",
> > >     md5_obj => "md5-x86_64.o",
> > >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> > >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> > >     module_cflags => "",
> > >     module_cxxflags => "",
> > >     module_ldflags => "/dll",
> > >     mtinflag => "-manifest ",
> > >     mtoutflag => "-outputresource:",
> > >     multilib => "-x64",
> > >     padlock_asm_src => "e_padlock-x86_64.s",
> > >     padlock_obj => "e_padlock-x86_64.o",
> > >     perlasm_scheme => "auto",
> > >     poly1305_asm_src => "poly1305-x86_64.s",
> > >     poly1305_obj => "poly1305-x86_64.o",
> > >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> > >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> > >     rc5_asm_src => "rc5_enc.c",
> > >     rc5_obj => "rc5_enc.o",
> > >     rcoutflag => "/fo",
> > >     rmd160_asm_src => "",
> > >     rmd160_obj => "",
> > >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> > >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> > >     shared_cflag => "",
> > >     shared_defines => [  ],
> > >     shared_extension => "",
> > >     shared_extension_simple => "",
> > >     shared_ldflag => "/dll",
> > >     shared_rcflag => "",
> > >     shared_target => "win-shared",
> > >     sys_id => "WIN64A",
> > >     thread_defines => [  ],
> > >     thread_scheme => "winthreads",
> > >     unistd => "<unistd.h>",
> > >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> > >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> > >     wp_asm_src => "wp-x86_64.s",
> > >     wp_obj => "wp-x86_64.o",
> > > Recorded environment:
> > >     AR =
> > >     ARFLAGS =
> > >     AS =
> > >     ASFLAGS =
> > >     BUILDFILE =
> > >     CC =
> > >     CFLAGS =
> > >     CPP =
> > >     CPPDEFINES =
> > >     CPPFLAGS =
> > >     CPPINCLUDES =
> > >     CROSS_COMPILE =
> > >     CXX =
> > >     CXXFLAGS =
> > >     HASHBANGPERL =
> > >     LD =
> > >     LDFLAGS =
> > >     LDLIBS =
> > >     MT =
> > >     MTFLAGS =
> > >     OPENSSL_LOCAL_CONFIG_DIR =
> > >     PERL =
> > >     RANLIB =
> > >     RC =
> > >     RCFLAGS =
> > >     RM =
> > >     WINDRES =
> > >     __CNF_CFLAGS =
> > >     __CNF_CPPDEFINES =
> > >     __CNF_CPPFLAGS =
> > >     __CNF_CPPINCLUDES =
> > >     __CNF_CXXFLAGS =
> > >     __CNF_LDFLAGS =
> > >     __CNF_LDLIBS =
> > > Makevars:
> > >     AR              = lib
> > >     ARFLAGS         = /nologo
> > >     AS              = nasm
> > >     ASFLAGS         = -g
> > >     CC              = cl
> > >     CFLAGS          = /W3 /wd4090 /nologo /O2
> > >     CPP             = $(CC) /EP /C
> > >     CPPDEFINES      =
> > >     CPPFLAGS        =
> > >     CPPINCLUDES     =
> > >     CXXFLAGS        =
> > >     HASHBANGPERL    = /usr/bin/env perl
> > >     LD              = link
> > >     LDFLAGS         = /nologo /debug
> > >     LDLIBS          =
> > >     MT              = mt
> > >     MTFLAGS         = -nologo
> > >     PERL            = c:\perl\bin\perl.exe
> > >     RC              = rc
> > > NOTE: These variables only represent the configuration view.  The build file
> > > template may have processed these variables further, please have a look at the
> > > build file for more exact data:
> > >     makefile
> > > build file:
> > >     makefile
> > > build file templates:
> > >     Configurations\common0.tmpl
> > >     Configurations\windows-makefile.tmpl
> > >     Configurations\common.tmpl
> > >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 

From levitte at openssl.org  Tue Oct 23 09:22:17 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 23 Oct 2018 11:22:17 +0200 (CEST)
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <20181023.103453.1842719922424343673.levitte@openssl.org>
References: <20181023.091913.2165099182291788730.levitte@openssl.org>
 <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q@mail.gmail.com>
 <20181023.103453.1842719922424343673.levitte@openssl.org>
Message-ID: <20181023.112217.1628265974252467568.levitte@openssl.org>

Silly me, I forgot we already fixed that bug:

    commit 6258e244bf702dc981c8ad63ab61133b8bbf2ba3
    Author: Richard Levitte <levitte at openssl.org>
    Date:   Wed Sep 12 02:06:26 2018 +0200
    
        crypto/sm2/sm2_sign.c: ensure UINT16_MAX is properly defined
        
        Fixes #7186
        
        Reviewed-by: Tim Hudson <tjh at openssl.org>
        (Merged from https://github.com/openssl/openssl/pull/7193)
        
        (cherry picked from commit 88ea3685e4bf30fc529fe46e19effc6317726de8)

Cheers,
Richard

In message <20181023.103453.1842719922424343673.levitte at openssl.org> on Tue, 23 Oct 2018 10:34:53 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:

> That indicates we do things in the wrong order (foo.obj depends on
> foo.d, meaning foo.d gets "built" first), but that's a side issue.
> 
> You found a bug in crypto\sm2\sm2_sign.c, thank you.  Are you willing
> to write up a Github issue for it?
> 
> In message <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q at mail.gmail.com> on Tue, 23 Oct 2018 01:22:34 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> 
> > Thank you Richard. Adding the "no-makedepend" avoided the  fatal error
> > U1077, but now it fails due to an undeclared identifier:
> > 
> > cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I
> > "." /I "crypto\include" /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC"
> > -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
> > -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
> > -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM"
> > -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM"
> > -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"PADLOCK_ASM" -D"POLY1305_ASM"
> > -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
> > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\sm2\sm2_sign.obj
> > "crypto\sm2\sm2_sign.c"
> > sm2_sign.c
> > crypto\sm2\sm2_sign.c(70) : error C2065: 'UINT16_MAX' : undeclared identifier
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> > Stop.
> > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > Stop.
> > On Tue, Oct 23, 2018 at 12:19 AM Richard Levitte <levitte at openssl.org> wrote:
> > >
> > > I suspect you'll find some kind of error message in
> > > crypto\sm2\sm2_sign.d.  I suspect that /showIncludes isn't supported
> > > in VS 2008.
> > >
> > > There is a workaround for this problem, and it's to use the
> > > 'no-makedepend' option:
> > >
> > >     perl Configure VC-WIN64A --prefix=c:/openssl no-makedepend
> > >
> > > For a single build, that should be good enough.
> > >
> > > Cheers,
> > > Richard
> > >
> > > In message <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ at mail.gmail.com> on Mon, 22 Oct 2018 23:50:46 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> > >
> > > > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > > > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > > > 1.1.1 for VC-WIN64A I get the following compile error:
> > > >
> > > >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > > > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > > > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > > > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > > > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > > > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > > > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > > > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > > > Files\\Common Files\\SSL\""
> > > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > > > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > > > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > > > Stop.
> > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > > Stop.
> > > >
> > > > My Command lines from the VS 2008 x64 Command Prompt are:
> > > > perl Configure VC-WIN64A --prefix=c:/openssl
> > > > nmake
> > > >
> > > > I also tried compiling the latest stable snapshot
> > > > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > > > version 1.1.0h compiles without error. Can anyone tell me what the
> > > > problem is?
> > > >
> > > > Here is the configuration dump:
> > > >
> > > > Command line (with current working directory = .):
> > > >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > > > Perl information:
> > > >     c:\perl\bin\perl.exe
> > > >     5.24.3 for MSWin32-x64-multi-thread
> > > > Enabled features:
> > > >     aria
> > > >     asm
> > > >     async
> > > >     autoalginit
> > > >     autoerrinit
> > > >     autoload-config
> > > >     bf
> > > >     blake2
> > > >     camellia
> > > >     capieng
> > > >     cast
> > > >     chacha
> > > >     cmac
> > > >     cms
> > > >     comp
> > > >     ct
> > > >     deprecated
> > > >     des
> > > >     dgram
> > > >     dh
> > > >     dsa
> > > >     dso
> > > >     dtls
> > > >     dynamic-engine
> > > >     ec
> > > >     ec2m
> > > >     ecdh
> > > >     ecdsa
> > > >     engine
> > > >     err
> > > >     filenames
> > > >     gost
> > > >     hw(-.+)?
> > > >     idea
> > > >     makedepend
> > > >     md4
> > > >     mdc2
> > > >     multiblock
> > > >     nextprotoneg
> > > >     ocb
> > > >     ocsp
> > > >     pic
> > > >     poly1305
> > > >     posix-io
> > > >     psk
> > > >     rc2
> > > >     rc4
> > > >     rdrand
> > > >     rfc3779
> > > >     rmd160
> > > >     scrypt
> > > >     seed
> > > >     shared
> > > >     siphash
> > > >     sm2
> > > >     sm3
> > > >     sm4
> > > >     sock
> > > >     srp
> > > >     srtp
> > > >     sse2
> > > >     ssl
> > > >     static-engine
> > > >     stdio
> > > >     tests
> > > >     threads
> > > >     tls
> > > >     ts
> > > >     ui-console
> > > >     whirlpool
> > > >     tls1
> > > >     tls1-method
> > > >     tls1_1
> > > >     tls1_1-method
> > > >     tls1_2
> > > >     tls1_2-method
> > > >     tls1_3
> > > >     dtls1
> > > >     dtls1-method
> > > >     dtls1_2
> > > >     dtls1_2-method
> > > > Disabled features:
> > > >     afalgeng                [not-linux]
> > > >     asan                    [default]   OPENSSL_NO_ASAN
> > > >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> > > >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> > > >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> > > >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> > > >     egd                     [default]   OPENSSL_NO_EGD
> > > >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> > > >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> > > >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> > > >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> > > >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> > > >     msan                    [default]   OPENSSL_NO_MSAN
> > > >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> > > >     sctp                    [default]   OPENSSL_NO_SCTP
> > > >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> > > >     ubsan                   [default]   OPENSSL_NO_UBSAN
> > > >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> > > >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> > > >     zlib                    [default]
> > > >     zlib-dynamic            [default]
> > > >     ssl3                    [default]   OPENSSL_NO_SSL3
> > > >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > > > Config target attributes:
> > > >     AR => "lib",
> > > >     ARFLAGS => "/nologo",
> > > >     AS => "nasm",
> > > >     ASFLAGS => "-g",
> > > >     CC => "cl",
> > > >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> > > >     CPP => "\$(CC) /EP /C",
> > > >     HASHBANGPERL => "/usr/bin/env perl",
> > > >     LD => "link",
> > > >     LDFLAGS => "/nologo /debug",
> > > >     MT => "mt",
> > > >     MTFLAGS => "-nologo",
> > > >     RANLIB => "CODE(0x65aff0)",
> > > >     RC => "rc",
> > > >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > > > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > > > aesni-mb-x86_64.s",
> > > >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > > > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > > > aesni-mb-x86_64.o",
> > > >     apps_aux_src => "win32_init.c",
> > > >     apps_init_src => "../ms/applink.c",
> > > >     apps_obj => "win32_init.o",
> > > >     aroutflag => "/out:",
> > > >     asflags => "-Ox -f win64 -DNEAR",
> > > >     asoutflag => "-o ",
> > > >     bf_asm_src => "bf_enc.c",
> > > >     bf_obj => "bf_enc.o",
> > > >     bin_cflags => "/Zi /Fdapp.pdb",
> > > >     bin_lflags => "/subsystem:console /opt:ref",
> > > >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > > > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> > > >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > > > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> > > >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> > > >     build_file => "makefile",
> > > >     build_scheme => [ "unified", "windows", "VC-common" ],
> > > >     cast_asm_src => "c_enc.c",
> > > >     cast_obj => "c_enc.o",
> > > >     cflags => "/Gs0 /GF /Gy /MD",
> > > >     chacha_asm_src => "chacha-x86_64.s",
> > > >     chacha_obj => "chacha-x86_64.o",
> > > >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> > > >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> > > >     coutflag => "/Fo",
> > > >     cppflags => "",
> > > >     cpuid_asm_src => "x86_64cpuid.s",
> > > >     cpuid_obj => "x86_64cpuid.o",
> > > >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > > > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > > > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> > > >     des_asm_src => "des_enc.c fcrypt_b.c",
> > > >     des_obj => "des_enc.o fcrypt_b.o",
> > > >     disable => [  ],
> > > >     dso_cflags => "/Zi /Fddso.pdb",
> > > >     dso_extension => "",
> > > >     dso_scheme => "win32",
> > > >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> > > >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> > > >     enable => [  ],
> > > >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> > > >     exe_extension => "",
> > > >     includes => [  ],
> > > >     keccak1600_asm_src => "keccak1600-x86_64.s",
> > > >     keccak1600_obj => "keccak1600-x86_64.o",
> > > >     ldoutflag => "/out:",
> > > >     lflags => "",
> > > >     lib_cflags => "/Zi /Fdossl_static.pdb",
> > > >     lib_cppflags => "",
> > > >     lib_defines => [ "L_ENDIAN" ],
> > > >     md5_asm_src => "md5-x86_64.s",
> > > >     md5_obj => "md5-x86_64.o",
> > > >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> > > >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> > > >     module_cflags => "",
> > > >     module_cxxflags => "",
> > > >     module_ldflags => "/dll",
> > > >     mtinflag => "-manifest ",
> > > >     mtoutflag => "-outputresource:",
> > > >     multilib => "-x64",
> > > >     padlock_asm_src => "e_padlock-x86_64.s",
> > > >     padlock_obj => "e_padlock-x86_64.o",
> > > >     perlasm_scheme => "auto",
> > > >     poly1305_asm_src => "poly1305-x86_64.s",
> > > >     poly1305_obj => "poly1305-x86_64.o",
> > > >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> > > >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> > > >     rc5_asm_src => "rc5_enc.c",
> > > >     rc5_obj => "rc5_enc.o",
> > > >     rcoutflag => "/fo",
> > > >     rmd160_asm_src => "",
> > > >     rmd160_obj => "",
> > > >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > > > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> > > >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > > > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> > > >     shared_cflag => "",
> > > >     shared_defines => [  ],
> > > >     shared_extension => "",
> > > >     shared_extension_simple => "",
> > > >     shared_ldflag => "/dll",
> > > >     shared_rcflag => "",
> > > >     shared_target => "win-shared",
> > > >     sys_id => "WIN64A",
> > > >     thread_defines => [  ],
> > > >     thread_scheme => "winthreads",
> > > >     unistd => "<unistd.h>",
> > > >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> > > >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> > > >     wp_asm_src => "wp-x86_64.s",
> > > >     wp_obj => "wp-x86_64.o",
> > > > Recorded environment:
> > > >     AR =
> > > >     ARFLAGS =
> > > >     AS =
> > > >     ASFLAGS =
> > > >     BUILDFILE =
> > > >     CC =
> > > >     CFLAGS =
> > > >     CPP =
> > > >     CPPDEFINES =
> > > >     CPPFLAGS =
> > > >     CPPINCLUDES =
> > > >     CROSS_COMPILE =
> > > >     CXX =
> > > >     CXXFLAGS =
> > > >     HASHBANGPERL =
> > > >     LD =
> > > >     LDFLAGS =
> > > >     LDLIBS =
> > > >     MT =
> > > >     MTFLAGS =
> > > >     OPENSSL_LOCAL_CONFIG_DIR =
> > > >     PERL =
> > > >     RANLIB =
> > > >     RC =
> > > >     RCFLAGS =
> > > >     RM =
> > > >     WINDRES =
> > > >     __CNF_CFLAGS =
> > > >     __CNF_CPPDEFINES =
> > > >     __CNF_CPPFLAGS =
> > > >     __CNF_CPPINCLUDES =
> > > >     __CNF_CXXFLAGS =
> > > >     __CNF_LDFLAGS =
> > > >     __CNF_LDLIBS =
> > > > Makevars:
> > > >     AR              = lib
> > > >     ARFLAGS         = /nologo
> > > >     AS              = nasm
> > > >     ASFLAGS         = -g
> > > >     CC              = cl
> > > >     CFLAGS          = /W3 /wd4090 /nologo /O2
> > > >     CPP             = $(CC) /EP /C
> > > >     CPPDEFINES      =
> > > >     CPPFLAGS        =
> > > >     CPPINCLUDES     =
> > > >     CXXFLAGS        =
> > > >     HASHBANGPERL    = /usr/bin/env perl
> > > >     LD              = link
> > > >     LDFLAGS         = /nologo /debug
> > > >     LDLIBS          =
> > > >     MT              = mt
> > > >     MTFLAGS         = -nologo
> > > >     PERL            = c:\perl\bin\perl.exe
> > > >     RC              = rc
> > > > NOTE: These variables only represent the configuration view.  The build file
> > > > template may have processed these variables further, please have a look at the
> > > > build file for more exact data:
> > > >     makefile
> > > > build file:
> > > >     makefile
> > > > build file templates:
> > > >     Configurations\common0.tmpl
> > > >     Configurations\windows-makefile.tmpl
> > > >     Configurations\common.tmpl
> > > >
> > > --
> > > openssl-users mailing list
> > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> > 

From a.chris.clark at gmail.com  Tue Oct 23 10:17:31 2018
From: a.chris.clark at gmail.com (Chris Clark)
Date: Tue, 23 Oct 2018 03:17:31 -0700
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <20181023.112217.1628265974252467568.levitte@openssl.org>
References: <20181023.091913.2165099182291788730.levitte@openssl.org>
 <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q@mail.gmail.com>
 <20181023.103453.1842719922424343673.levitte@openssl.org>
 <20181023.112217.1628265974252467568.levitte@openssl.org>
Message-ID: <CACaGmvBCbiNeT=BkgFEsLo4fgmn-Qba-LjX4Pr8tHrffSX0kVA@mail.gmail.com>

Thanks Richard. I downloaded the latest stable snapshot in order to
bypass the UINT16_MAX definition bug, but this version fails to
configure:

C:\openssl-1.1.1-stable-SNAP-20181022>perl Configure VC-WIN64A
--prefix=c:/openssl no-makedepend
Can't locate OpenSSL/Glob.pm in @INC (you may need to install the
OpenSSL::Glob module) (@INC contains:
C:/openssl-1.1.1-stable-SNAP-20181022/util/perl c:/perl/site/lib
c:/perl/lib .) at Configure line 20.
BEGIN failed--compilation aborted at Configure line 20.


I'll try some of the older stable snapshots.
On Tue, Oct 23, 2018 at 2:22 AM Richard Levitte <levitte at openssl.org> wrote:
>
> Silly me, I forgot we already fixed that bug:
>
>     commit 6258e244bf702dc981c8ad63ab61133b8bbf2ba3
>     Author: Richard Levitte <levitte at openssl.org>
>     Date:   Wed Sep 12 02:06:26 2018 +0200
>
>         crypto/sm2/sm2_sign.c: ensure UINT16_MAX is properly defined
>
>         Fixes #7186
>
>         Reviewed-by: Tim Hudson <tjh at openssl.org>
>         (Merged from https://github.com/openssl/openssl/pull/7193)
>
>         (cherry picked from commit 88ea3685e4bf30fc529fe46e19effc6317726de8)
>
> Cheers,
> Richard
>
> In message <20181023.103453.1842719922424343673.levitte at openssl.org> on Tue, 23 Oct 2018 10:34:53 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:
>
> > That indicates we do things in the wrong order (foo.obj depends on
> > foo.d, meaning foo.d gets "built" first), but that's a side issue.
> >
> > You found a bug in crypto\sm2\sm2_sign.c, thank you.  Are you willing
> > to write up a Github issue for it?
> >
> > In message <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q at mail.gmail.com> on Tue, 23 Oct 2018 01:22:34 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> >
> > > Thank you Richard. Adding the "no-makedepend" avoided the  fatal error
> > > U1077, but now it fails due to an undeclared identifier:
> > >
> > > cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I
> > > "." /I "crypto\include" /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC"
> > > -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
> > > -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
> > > -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM"
> > > -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM"
> > > -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"PADLOCK_ASM" -D"POLY1305_ASM"
> > > -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
> > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\sm2\sm2_sign.obj
> > > "crypto\sm2\sm2_sign.c"
> > > sm2_sign.c
> > > crypto\sm2\sm2_sign.c(70) : error C2065: 'UINT16_MAX' : undeclared identifier
> > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> > > Stop.
> > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > Stop.
> > > On Tue, Oct 23, 2018 at 12:19 AM Richard Levitte <levitte at openssl.org> wrote:
> > > >
> > > > I suspect you'll find some kind of error message in
> > > > crypto\sm2\sm2_sign.d.  I suspect that /showIncludes isn't supported
> > > > in VS 2008.
> > > >
> > > > There is a workaround for this problem, and it's to use the
> > > > 'no-makedepend' option:
> > > >
> > > >     perl Configure VC-WIN64A --prefix=c:/openssl no-makedepend
> > > >
> > > > For a single build, that should be good enough.
> > > >
> > > > Cheers,
> > > > Richard
> > > >
> > > > In message <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ at mail.gmail.com> on Mon, 22 Oct 2018 23:50:46 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> > > >
> > > > > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > > > > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > > > > 1.1.1 for VC-WIN64A I get the following compile error:
> > > > >
> > > > >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > > > > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > > > > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > > > > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > > > > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > > > > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > > > > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > > > > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > > > > Files\\Common Files\\SSL\""
> > > > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > > > > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > > > > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > > > > Stop.
> > > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > > > Stop.
> > > > >
> > > > > My Command lines from the VS 2008 x64 Command Prompt are:
> > > > > perl Configure VC-WIN64A --prefix=c:/openssl
> > > > > nmake
> > > > >
> > > > > I also tried compiling the latest stable snapshot
> > > > > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > > > > version 1.1.0h compiles without error. Can anyone tell me what the
> > > > > problem is?
> > > > >
> > > > > Here is the configuration dump:
> > > > >
> > > > > Command line (with current working directory = .):
> > > > >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > > > > Perl information:
> > > > >     c:\perl\bin\perl.exe
> > > > >     5.24.3 for MSWin32-x64-multi-thread
> > > > > Enabled features:
> > > > >     aria
> > > > >     asm
> > > > >     async
> > > > >     autoalginit
> > > > >     autoerrinit
> > > > >     autoload-config
> > > > >     bf
> > > > >     blake2
> > > > >     camellia
> > > > >     capieng
> > > > >     cast
> > > > >     chacha
> > > > >     cmac
> > > > >     cms
> > > > >     comp
> > > > >     ct
> > > > >     deprecated
> > > > >     des
> > > > >     dgram
> > > > >     dh
> > > > >     dsa
> > > > >     dso
> > > > >     dtls
> > > > >     dynamic-engine
> > > > >     ec
> > > > >     ec2m
> > > > >     ecdh
> > > > >     ecdsa
> > > > >     engine
> > > > >     err
> > > > >     filenames
> > > > >     gost
> > > > >     hw(-.+)?
> > > > >     idea
> > > > >     makedepend
> > > > >     md4
> > > > >     mdc2
> > > > >     multiblock
> > > > >     nextprotoneg
> > > > >     ocb
> > > > >     ocsp
> > > > >     pic
> > > > >     poly1305
> > > > >     posix-io
> > > > >     psk
> > > > >     rc2
> > > > >     rc4
> > > > >     rdrand
> > > > >     rfc3779
> > > > >     rmd160
> > > > >     scrypt
> > > > >     seed
> > > > >     shared
> > > > >     siphash
> > > > >     sm2
> > > > >     sm3
> > > > >     sm4
> > > > >     sock
> > > > >     srp
> > > > >     srtp
> > > > >     sse2
> > > > >     ssl
> > > > >     static-engine
> > > > >     stdio
> > > > >     tests
> > > > >     threads
> > > > >     tls
> > > > >     ts
> > > > >     ui-console
> > > > >     whirlpool
> > > > >     tls1
> > > > >     tls1-method
> > > > >     tls1_1
> > > > >     tls1_1-method
> > > > >     tls1_2
> > > > >     tls1_2-method
> > > > >     tls1_3
> > > > >     dtls1
> > > > >     dtls1-method
> > > > >     dtls1_2
> > > > >     dtls1_2-method
> > > > > Disabled features:
> > > > >     afalgeng                [not-linux]
> > > > >     asan                    [default]   OPENSSL_NO_ASAN
> > > > >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> > > > >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> > > > >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> > > > >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> > > > >     egd                     [default]   OPENSSL_NO_EGD
> > > > >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> > > > >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> > > > >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> > > > >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> > > > >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> > > > >     msan                    [default]   OPENSSL_NO_MSAN
> > > > >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> > > > >     sctp                    [default]   OPENSSL_NO_SCTP
> > > > >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> > > > >     ubsan                   [default]   OPENSSL_NO_UBSAN
> > > > >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> > > > >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> > > > >     zlib                    [default]
> > > > >     zlib-dynamic            [default]
> > > > >     ssl3                    [default]   OPENSSL_NO_SSL3
> > > > >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > > > > Config target attributes:
> > > > >     AR => "lib",
> > > > >     ARFLAGS => "/nologo",
> > > > >     AS => "nasm",
> > > > >     ASFLAGS => "-g",
> > > > >     CC => "cl",
> > > > >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> > > > >     CPP => "\$(CC) /EP /C",
> > > > >     HASHBANGPERL => "/usr/bin/env perl",
> > > > >     LD => "link",
> > > > >     LDFLAGS => "/nologo /debug",
> > > > >     MT => "mt",
> > > > >     MTFLAGS => "-nologo",
> > > > >     RANLIB => "CODE(0x65aff0)",
> > > > >     RC => "rc",
> > > > >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > > > > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > > > > aesni-mb-x86_64.s",
> > > > >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > > > > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > > > > aesni-mb-x86_64.o",
> > > > >     apps_aux_src => "win32_init.c",
> > > > >     apps_init_src => "../ms/applink.c",
> > > > >     apps_obj => "win32_init.o",
> > > > >     aroutflag => "/out:",
> > > > >     asflags => "-Ox -f win64 -DNEAR",
> > > > >     asoutflag => "-o ",
> > > > >     bf_asm_src => "bf_enc.c",
> > > > >     bf_obj => "bf_enc.o",
> > > > >     bin_cflags => "/Zi /Fdapp.pdb",
> > > > >     bin_lflags => "/subsystem:console /opt:ref",
> > > > >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > > > > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> > > > >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > > > > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> > > > >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> > > > >     build_file => "makefile",
> > > > >     build_scheme => [ "unified", "windows", "VC-common" ],
> > > > >     cast_asm_src => "c_enc.c",
> > > > >     cast_obj => "c_enc.o",
> > > > >     cflags => "/Gs0 /GF /Gy /MD",
> > > > >     chacha_asm_src => "chacha-x86_64.s",
> > > > >     chacha_obj => "chacha-x86_64.o",
> > > > >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> > > > >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> > > > >     coutflag => "/Fo",
> > > > >     cppflags => "",
> > > > >     cpuid_asm_src => "x86_64cpuid.s",
> > > > >     cpuid_obj => "x86_64cpuid.o",
> > > > >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > > > > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > > > > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> > > > >     des_asm_src => "des_enc.c fcrypt_b.c",
> > > > >     des_obj => "des_enc.o fcrypt_b.o",
> > > > >     disable => [  ],
> > > > >     dso_cflags => "/Zi /Fddso.pdb",
> > > > >     dso_extension => "",
> > > > >     dso_scheme => "win32",
> > > > >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> > > > >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> > > > >     enable => [  ],
> > > > >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> > > > >     exe_extension => "",
> > > > >     includes => [  ],
> > > > >     keccak1600_asm_src => "keccak1600-x86_64.s",
> > > > >     keccak1600_obj => "keccak1600-x86_64.o",
> > > > >     ldoutflag => "/out:",
> > > > >     lflags => "",
> > > > >     lib_cflags => "/Zi /Fdossl_static.pdb",
> > > > >     lib_cppflags => "",
> > > > >     lib_defines => [ "L_ENDIAN" ],
> > > > >     md5_asm_src => "md5-x86_64.s",
> > > > >     md5_obj => "md5-x86_64.o",
> > > > >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> > > > >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> > > > >     module_cflags => "",
> > > > >     module_cxxflags => "",
> > > > >     module_ldflags => "/dll",
> > > > >     mtinflag => "-manifest ",
> > > > >     mtoutflag => "-outputresource:",
> > > > >     multilib => "-x64",
> > > > >     padlock_asm_src => "e_padlock-x86_64.s",
> > > > >     padlock_obj => "e_padlock-x86_64.o",
> > > > >     perlasm_scheme => "auto",
> > > > >     poly1305_asm_src => "poly1305-x86_64.s",
> > > > >     poly1305_obj => "poly1305-x86_64.o",
> > > > >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> > > > >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> > > > >     rc5_asm_src => "rc5_enc.c",
> > > > >     rc5_obj => "rc5_enc.o",
> > > > >     rcoutflag => "/fo",
> > > > >     rmd160_asm_src => "",
> > > > >     rmd160_obj => "",
> > > > >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > > > > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> > > > >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > > > > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> > > > >     shared_cflag => "",
> > > > >     shared_defines => [  ],
> > > > >     shared_extension => "",
> > > > >     shared_extension_simple => "",
> > > > >     shared_ldflag => "/dll",
> > > > >     shared_rcflag => "",
> > > > >     shared_target => "win-shared",
> > > > >     sys_id => "WIN64A",
> > > > >     thread_defines => [  ],
> > > > >     thread_scheme => "winthreads",
> > > > >     unistd => "<unistd.h>",
> > > > >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> > > > >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> > > > >     wp_asm_src => "wp-x86_64.s",
> > > > >     wp_obj => "wp-x86_64.o",
> > > > > Recorded environment:
> > > > >     AR =
> > > > >     ARFLAGS =
> > > > >     AS =
> > > > >     ASFLAGS =
> > > > >     BUILDFILE =
> > > > >     CC =
> > > > >     CFLAGS =
> > > > >     CPP =
> > > > >     CPPDEFINES =
> > > > >     CPPFLAGS =
> > > > >     CPPINCLUDES =
> > > > >     CROSS_COMPILE =
> > > > >     CXX =
> > > > >     CXXFLAGS =
> > > > >     HASHBANGPERL =
> > > > >     LD =
> > > > >     LDFLAGS =
> > > > >     LDLIBS =
> > > > >     MT =
> > > > >     MTFLAGS =
> > > > >     OPENSSL_LOCAL_CONFIG_DIR =
> > > > >     PERL =
> > > > >     RANLIB =
> > > > >     RC =
> > > > >     RCFLAGS =
> > > > >     RM =
> > > > >     WINDRES =
> > > > >     __CNF_CFLAGS =
> > > > >     __CNF_CPPDEFINES =
> > > > >     __CNF_CPPFLAGS =
> > > > >     __CNF_CPPINCLUDES =
> > > > >     __CNF_CXXFLAGS =
> > > > >     __CNF_LDFLAGS =
> > > > >     __CNF_LDLIBS =
> > > > > Makevars:
> > > > >     AR              = lib
> > > > >     ARFLAGS         = /nologo
> > > > >     AS              = nasm
> > > > >     ASFLAGS         = -g
> > > > >     CC              = cl
> > > > >     CFLAGS          = /W3 /wd4090 /nologo /O2
> > > > >     CPP             = $(CC) /EP /C
> > > > >     CPPDEFINES      =
> > > > >     CPPFLAGS        =
> > > > >     CPPINCLUDES     =
> > > > >     CXXFLAGS        =
> > > > >     HASHBANGPERL    = /usr/bin/env perl
> > > > >     LD              = link
> > > > >     LDFLAGS         = /nologo /debug
> > > > >     LDLIBS          =
> > > > >     MT              = mt
> > > > >     MTFLAGS         = -nologo
> > > > >     PERL            = c:\perl\bin\perl.exe
> > > > >     RC              = rc
> > > > > NOTE: These variables only represent the configuration view.  The build file
> > > > > template may have processed these variables further, please have a look at the
> > > > > build file for more exact data:
> > > > >     makefile
> > > > > build file:
> > > > >     makefile
> > > > > build file templates:
> > > > >     Configurations\common0.tmpl
> > > > >     Configurations\windows-makefile.tmpl
> > > > >     Configurations\common.tmpl
> > > > >
> > > > --
> > > > 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 a.chris.clark at gmail.com  Tue Oct 23 10:31:53 2018
From: a.chris.clark at gmail.com (Chris Clark)
Date: Tue, 23 Oct 2018 03:31:53 -0700
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <CACaGmvBCbiNeT=BkgFEsLo4fgmn-Qba-LjX4Pr8tHrffSX0kVA@mail.gmail.com>
References: <20181023.091913.2165099182291788730.levitte@openssl.org>
 <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q@mail.gmail.com>
 <20181023.103453.1842719922424343673.levitte@openssl.org>
 <20181023.112217.1628265974252467568.levitte@openssl.org>
 <CACaGmvBCbiNeT=BkgFEsLo4fgmn-Qba-LjX4Pr8tHrffSX0kVA@mail.gmail.com>
Message-ID: <CACaGmvAWKCa9CrAnqOu9_k5Wc=ev+p7hfWMzwFt46c8nrgoB9w@mail.gmail.com>

Next I tried an older stable snapshot
openssl-1.1.1-stable-SNAP-20181018 which configured without issue, but
I got a different compile result:

        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090
/nologo /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
-D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
-D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
-D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
-D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
-D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
-D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
Files\\Common Files\\SSL\""
-D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
-D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
-D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
-D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\rand\drbg_ctr.obj
"crypto\rand\drbg_ctr.c"
drbg_ctr.c
crypto\rand\drbg_ctr.c(399) : warning C4267: '=' : conversion from
'size_t' to 'int', possible loss of data
crypto\rand\drbg_ctr.c(420) : error C2065: 'INT32_MAX' : undeclared identifier
crypto\rand\drbg_ctr.c(422) : error C2065: 'INT32_MAX' : undeclared identifier
crypto\rand\drbg_ctr.c(423) : error C2065: 'INT32_MAX' : undeclared identifier
crypto\rand\drbg_ctr.c(424) : error C2065: 'INT32_MAX' : undeclared identifier
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
Stop.
On Tue, Oct 23, 2018 at 3:17 AM Chris Clark <a.chris.clark at gmail.com> wrote:
>
> Thanks Richard. I downloaded the latest stable snapshot in order to
> bypass the UINT16_MAX definition bug, but this version fails to
> configure:
>
> C:\openssl-1.1.1-stable-SNAP-20181022>perl Configure VC-WIN64A
> --prefix=c:/openssl no-makedepend
> Can't locate OpenSSL/Glob.pm in @INC (you may need to install the
> OpenSSL::Glob module) (@INC contains:
> C:/openssl-1.1.1-stable-SNAP-20181022/util/perl c:/perl/site/lib
> c:/perl/lib .) at Configure line 20.
> BEGIN failed--compilation aborted at Configure line 20.
>
>
> I'll try some of the older stable snapshots.
> On Tue, Oct 23, 2018 at 2:22 AM Richard Levitte <levitte at openssl.org> wrote:
> >
> > Silly me, I forgot we already fixed that bug:
> >
> >     commit 6258e244bf702dc981c8ad63ab61133b8bbf2ba3
> >     Author: Richard Levitte <levitte at openssl.org>
> >     Date:   Wed Sep 12 02:06:26 2018 +0200
> >
> >         crypto/sm2/sm2_sign.c: ensure UINT16_MAX is properly defined
> >
> >         Fixes #7186
> >
> >         Reviewed-by: Tim Hudson <tjh at openssl.org>
> >         (Merged from https://github.com/openssl/openssl/pull/7193)
> >
> >         (cherry picked from commit 88ea3685e4bf30fc529fe46e19effc6317726de8)
> >
> > Cheers,
> > Richard
> >
> > In message <20181023.103453.1842719922424343673.levitte at openssl.org> on Tue, 23 Oct 2018 10:34:53 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:
> >
> > > That indicates we do things in the wrong order (foo.obj depends on
> > > foo.d, meaning foo.d gets "built" first), but that's a side issue.
> > >
> > > You found a bug in crypto\sm2\sm2_sign.c, thank you.  Are you willing
> > > to write up a Github issue for it?
> > >
> > > In message <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q at mail.gmail.com> on Tue, 23 Oct 2018 01:22:34 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> > >
> > > > Thank you Richard. Adding the "no-makedepend" avoided the  fatal error
> > > > U1077, but now it fails due to an undeclared identifier:
> > > >
> > > > cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I
> > > > "." /I "crypto\include" /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC"
> > > > -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
> > > > -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
> > > > -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM"
> > > > -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM"
> > > > -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"PADLOCK_ASM" -D"POLY1305_ASM"
> > > > -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
> > > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\sm2\sm2_sign.obj
> > > > "crypto\sm2\sm2_sign.c"
> > > > sm2_sign.c
> > > > crypto\sm2\sm2_sign.c(70) : error C2065: 'UINT16_MAX' : undeclared identifier
> > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> > > > Stop.
> > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > > Stop.
> > > > On Tue, Oct 23, 2018 at 12:19 AM Richard Levitte <levitte at openssl.org> wrote:
> > > > >
> > > > > I suspect you'll find some kind of error message in
> > > > > crypto\sm2\sm2_sign.d.  I suspect that /showIncludes isn't supported
> > > > > in VS 2008.
> > > > >
> > > > > There is a workaround for this problem, and it's to use the
> > > > > 'no-makedepend' option:
> > > > >
> > > > >     perl Configure VC-WIN64A --prefix=c:/openssl no-makedepend
> > > > >
> > > > > For a single build, that should be good enough.
> > > > >
> > > > > Cheers,
> > > > > Richard
> > > > >
> > > > > In message <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ at mail.gmail.com> on Mon, 22 Oct 2018 23:50:46 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> > > > >
> > > > > > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > > > > > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > > > > > 1.1.1 for VC-WIN64A I get the following compile error:
> > > > > >
> > > > > >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > > > > > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > > > > > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > > > > > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > > > > > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > > > > > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > > > > > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > > > > > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > > > > > Files\\Common Files\\SSL\""
> > > > > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > > > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > > > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > > > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > > > > > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > > > > > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > > > > > Stop.
> > > > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > > > > Stop.
> > > > > >
> > > > > > My Command lines from the VS 2008 x64 Command Prompt are:
> > > > > > perl Configure VC-WIN64A --prefix=c:/openssl
> > > > > > nmake
> > > > > >
> > > > > > I also tried compiling the latest stable snapshot
> > > > > > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > > > > > version 1.1.0h compiles without error. Can anyone tell me what the
> > > > > > problem is?
> > > > > >
> > > > > > Here is the configuration dump:
> > > > > >
> > > > > > Command line (with current working directory = .):
> > > > > >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > > > > > Perl information:
> > > > > >     c:\perl\bin\perl.exe
> > > > > >     5.24.3 for MSWin32-x64-multi-thread
> > > > > > Enabled features:
> > > > > >     aria
> > > > > >     asm
> > > > > >     async
> > > > > >     autoalginit
> > > > > >     autoerrinit
> > > > > >     autoload-config
> > > > > >     bf
> > > > > >     blake2
> > > > > >     camellia
> > > > > >     capieng
> > > > > >     cast
> > > > > >     chacha
> > > > > >     cmac
> > > > > >     cms
> > > > > >     comp
> > > > > >     ct
> > > > > >     deprecated
> > > > > >     des
> > > > > >     dgram
> > > > > >     dh
> > > > > >     dsa
> > > > > >     dso
> > > > > >     dtls
> > > > > >     dynamic-engine
> > > > > >     ec
> > > > > >     ec2m
> > > > > >     ecdh
> > > > > >     ecdsa
> > > > > >     engine
> > > > > >     err
> > > > > >     filenames
> > > > > >     gost
> > > > > >     hw(-.+)?
> > > > > >     idea
> > > > > >     makedepend
> > > > > >     md4
> > > > > >     mdc2
> > > > > >     multiblock
> > > > > >     nextprotoneg
> > > > > >     ocb
> > > > > >     ocsp
> > > > > >     pic
> > > > > >     poly1305
> > > > > >     posix-io
> > > > > >     psk
> > > > > >     rc2
> > > > > >     rc4
> > > > > >     rdrand
> > > > > >     rfc3779
> > > > > >     rmd160
> > > > > >     scrypt
> > > > > >     seed
> > > > > >     shared
> > > > > >     siphash
> > > > > >     sm2
> > > > > >     sm3
> > > > > >     sm4
> > > > > >     sock
> > > > > >     srp
> > > > > >     srtp
> > > > > >     sse2
> > > > > >     ssl
> > > > > >     static-engine
> > > > > >     stdio
> > > > > >     tests
> > > > > >     threads
> > > > > >     tls
> > > > > >     ts
> > > > > >     ui-console
> > > > > >     whirlpool
> > > > > >     tls1
> > > > > >     tls1-method
> > > > > >     tls1_1
> > > > > >     tls1_1-method
> > > > > >     tls1_2
> > > > > >     tls1_2-method
> > > > > >     tls1_3
> > > > > >     dtls1
> > > > > >     dtls1-method
> > > > > >     dtls1_2
> > > > > >     dtls1_2-method
> > > > > > Disabled features:
> > > > > >     afalgeng                [not-linux]
> > > > > >     asan                    [default]   OPENSSL_NO_ASAN
> > > > > >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> > > > > >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> > > > > >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> > > > > >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> > > > > >     egd                     [default]   OPENSSL_NO_EGD
> > > > > >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> > > > > >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> > > > > >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> > > > > >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> > > > > >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> > > > > >     msan                    [default]   OPENSSL_NO_MSAN
> > > > > >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> > > > > >     sctp                    [default]   OPENSSL_NO_SCTP
> > > > > >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> > > > > >     ubsan                   [default]   OPENSSL_NO_UBSAN
> > > > > >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> > > > > >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> > > > > >     zlib                    [default]
> > > > > >     zlib-dynamic            [default]
> > > > > >     ssl3                    [default]   OPENSSL_NO_SSL3
> > > > > >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > > > > > Config target attributes:
> > > > > >     AR => "lib",
> > > > > >     ARFLAGS => "/nologo",
> > > > > >     AS => "nasm",
> > > > > >     ASFLAGS => "-g",
> > > > > >     CC => "cl",
> > > > > >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> > > > > >     CPP => "\$(CC) /EP /C",
> > > > > >     HASHBANGPERL => "/usr/bin/env perl",
> > > > > >     LD => "link",
> > > > > >     LDFLAGS => "/nologo /debug",
> > > > > >     MT => "mt",
> > > > > >     MTFLAGS => "-nologo",
> > > > > >     RANLIB => "CODE(0x65aff0)",
> > > > > >     RC => "rc",
> > > > > >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > > > > > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > > > > > aesni-mb-x86_64.s",
> > > > > >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > > > > > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > > > > > aesni-mb-x86_64.o",
> > > > > >     apps_aux_src => "win32_init.c",
> > > > > >     apps_init_src => "../ms/applink.c",
> > > > > >     apps_obj => "win32_init.o",
> > > > > >     aroutflag => "/out:",
> > > > > >     asflags => "-Ox -f win64 -DNEAR",
> > > > > >     asoutflag => "-o ",
> > > > > >     bf_asm_src => "bf_enc.c",
> > > > > >     bf_obj => "bf_enc.o",
> > > > > >     bin_cflags => "/Zi /Fdapp.pdb",
> > > > > >     bin_lflags => "/subsystem:console /opt:ref",
> > > > > >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > > > > > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> > > > > >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > > > > > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> > > > > >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> > > > > >     build_file => "makefile",
> > > > > >     build_scheme => [ "unified", "windows", "VC-common" ],
> > > > > >     cast_asm_src => "c_enc.c",
> > > > > >     cast_obj => "c_enc.o",
> > > > > >     cflags => "/Gs0 /GF /Gy /MD",
> > > > > >     chacha_asm_src => "chacha-x86_64.s",
> > > > > >     chacha_obj => "chacha-x86_64.o",
> > > > > >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> > > > > >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> > > > > >     coutflag => "/Fo",
> > > > > >     cppflags => "",
> > > > > >     cpuid_asm_src => "x86_64cpuid.s",
> > > > > >     cpuid_obj => "x86_64cpuid.o",
> > > > > >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > > > > > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > > > > > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> > > > > >     des_asm_src => "des_enc.c fcrypt_b.c",
> > > > > >     des_obj => "des_enc.o fcrypt_b.o",
> > > > > >     disable => [  ],
> > > > > >     dso_cflags => "/Zi /Fddso.pdb",
> > > > > >     dso_extension => "",
> > > > > >     dso_scheme => "win32",
> > > > > >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> > > > > >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> > > > > >     enable => [  ],
> > > > > >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> > > > > >     exe_extension => "",
> > > > > >     includes => [  ],
> > > > > >     keccak1600_asm_src => "keccak1600-x86_64.s",
> > > > > >     keccak1600_obj => "keccak1600-x86_64.o",
> > > > > >     ldoutflag => "/out:",
> > > > > >     lflags => "",
> > > > > >     lib_cflags => "/Zi /Fdossl_static.pdb",
> > > > > >     lib_cppflags => "",
> > > > > >     lib_defines => [ "L_ENDIAN" ],
> > > > > >     md5_asm_src => "md5-x86_64.s",
> > > > > >     md5_obj => "md5-x86_64.o",
> > > > > >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> > > > > >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> > > > > >     module_cflags => "",
> > > > > >     module_cxxflags => "",
> > > > > >     module_ldflags => "/dll",
> > > > > >     mtinflag => "-manifest ",
> > > > > >     mtoutflag => "-outputresource:",
> > > > > >     multilib => "-x64",
> > > > > >     padlock_asm_src => "e_padlock-x86_64.s",
> > > > > >     padlock_obj => "e_padlock-x86_64.o",
> > > > > >     perlasm_scheme => "auto",
> > > > > >     poly1305_asm_src => "poly1305-x86_64.s",
> > > > > >     poly1305_obj => "poly1305-x86_64.o",
> > > > > >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> > > > > >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> > > > > >     rc5_asm_src => "rc5_enc.c",
> > > > > >     rc5_obj => "rc5_enc.o",
> > > > > >     rcoutflag => "/fo",
> > > > > >     rmd160_asm_src => "",
> > > > > >     rmd160_obj => "",
> > > > > >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > > > > > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> > > > > >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > > > > > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> > > > > >     shared_cflag => "",
> > > > > >     shared_defines => [  ],
> > > > > >     shared_extension => "",
> > > > > >     shared_extension_simple => "",
> > > > > >     shared_ldflag => "/dll",
> > > > > >     shared_rcflag => "",
> > > > > >     shared_target => "win-shared",
> > > > > >     sys_id => "WIN64A",
> > > > > >     thread_defines => [  ],
> > > > > >     thread_scheme => "winthreads",
> > > > > >     unistd => "<unistd.h>",
> > > > > >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> > > > > >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> > > > > >     wp_asm_src => "wp-x86_64.s",
> > > > > >     wp_obj => "wp-x86_64.o",
> > > > > > Recorded environment:
> > > > > >     AR =
> > > > > >     ARFLAGS =
> > > > > >     AS =
> > > > > >     ASFLAGS =
> > > > > >     BUILDFILE =
> > > > > >     CC =
> > > > > >     CFLAGS =
> > > > > >     CPP =
> > > > > >     CPPDEFINES =
> > > > > >     CPPFLAGS =
> > > > > >     CPPINCLUDES =
> > > > > >     CROSS_COMPILE =
> > > > > >     CXX =
> > > > > >     CXXFLAGS =
> > > > > >     HASHBANGPERL =
> > > > > >     LD =
> > > > > >     LDFLAGS =
> > > > > >     LDLIBS =
> > > > > >     MT =
> > > > > >     MTFLAGS =
> > > > > >     OPENSSL_LOCAL_CONFIG_DIR =
> > > > > >     PERL =
> > > > > >     RANLIB =
> > > > > >     RC =
> > > > > >     RCFLAGS =
> > > > > >     RM =
> > > > > >     WINDRES =
> > > > > >     __CNF_CFLAGS =
> > > > > >     __CNF_CPPDEFINES =
> > > > > >     __CNF_CPPFLAGS =
> > > > > >     __CNF_CPPINCLUDES =
> > > > > >     __CNF_CXXFLAGS =
> > > > > >     __CNF_LDFLAGS =
> > > > > >     __CNF_LDLIBS =
> > > > > > Makevars:
> > > > > >     AR              = lib
> > > > > >     ARFLAGS         = /nologo
> > > > > >     AS              = nasm
> > > > > >     ASFLAGS         = -g
> > > > > >     CC              = cl
> > > > > >     CFLAGS          = /W3 /wd4090 /nologo /O2
> > > > > >     CPP             = $(CC) /EP /C
> > > > > >     CPPDEFINES      =
> > > > > >     CPPFLAGS        =
> > > > > >     CPPINCLUDES     =
> > > > > >     CXXFLAGS        =
> > > > > >     HASHBANGPERL    = /usr/bin/env perl
> > > > > >     LD              = link
> > > > > >     LDFLAGS         = /nologo /debug
> > > > > >     LDLIBS          =
> > > > > >     MT              = mt
> > > > > >     MTFLAGS         = -nologo
> > > > > >     PERL            = c:\perl\bin\perl.exe
> > > > > >     RC              = rc
> > > > > > NOTE: These variables only represent the configuration view.  The build file
> > > > > > template may have processed these variables further, please have a look at the
> > > > > > build file for more exact data:
> > > > > >     makefile
> > > > > > build file:
> > > > > >     makefile
> > > > > > build file templates:
> > > > > >     Configurations\common0.tmpl
> > > > > >     Configurations\windows-makefile.tmpl
> > > > > >     Configurations\common.tmpl
> > > > > >
> > > > > --
> > > > > 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 a.chris.clark at gmail.com  Tue Oct 23 10:47:05 2018
From: a.chris.clark at gmail.com (Chris Clark)
Date: Tue, 23 Oct 2018 03:47:05 -0700
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <CACaGmvAWKCa9CrAnqOu9_k5Wc=ev+p7hfWMzwFt46c8nrgoB9w@mail.gmail.com>
References: <20181023.091913.2165099182291788730.levitte@openssl.org>
 <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q@mail.gmail.com>
 <20181023.103453.1842719922424343673.levitte@openssl.org>
 <20181023.112217.1628265974252467568.levitte@openssl.org>
 <CACaGmvBCbiNeT=BkgFEsLo4fgmn-Qba-LjX4Pr8tHrffSX0kVA@mail.gmail.com>
 <CACaGmvAWKCa9CrAnqOu9_k5Wc=ev+p7hfWMzwFt46c8nrgoB9w@mail.gmail.com>
Message-ID: <CACaGmvAOtASav-v5QD-pkjOL4GtKmE=xxiBBw_MWWNOgGqk09Q@mail.gmail.com>

Richard, Moving Glob.pm into the main directory of the latest stable
snapshot openssl-1.1.1-stable-SNAP-20181022 allowed it to bypass the
missing Glob.pm message, but then it failed with the same set of
"error C2065: 'INT32_MAX' : undeclared identifier" messages as the
older openssl-1.1.1-stable-SNAP-20181018.
On Tue, Oct 23, 2018 at 3:31 AM Chris Clark <a.chris.clark at gmail.com> wrote:
>
> Next I tried an older stable snapshot
> openssl-1.1.1-stable-SNAP-20181018 which configured without issue, but
> I got a different compile result:
>
>         cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090
> /nologo /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> Files\\Common Files\\SSL\""
> -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\rand\drbg_ctr.obj
> "crypto\rand\drbg_ctr.c"
> drbg_ctr.c
> crypto\rand\drbg_ctr.c(399) : warning C4267: '=' : conversion from
> 'size_t' to 'int', possible loss of data
> crypto\rand\drbg_ctr.c(420) : error C2065: 'INT32_MAX' : undeclared identifier
> crypto\rand\drbg_ctr.c(422) : error C2065: 'INT32_MAX' : undeclared identifier
> crypto\rand\drbg_ctr.c(423) : error C2065: 'INT32_MAX' : undeclared identifier
> crypto\rand\drbg_ctr.c(424) : error C2065: 'INT32_MAX' : undeclared identifier
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> Stop.
> On Tue, Oct 23, 2018 at 3:17 AM Chris Clark <a.chris.clark at gmail.com> wrote:
> >
> > Thanks Richard. I downloaded the latest stable snapshot in order to
> > bypass the UINT16_MAX definition bug, but this version fails to
> > configure:
> >
> > C:\openssl-1.1.1-stable-SNAP-20181022>perl Configure VC-WIN64A
> > --prefix=c:/openssl no-makedepend
> > Can't locate OpenSSL/Glob.pm in @INC (you may need to install the
> > OpenSSL::Glob module) (@INC contains:
> > C:/openssl-1.1.1-stable-SNAP-20181022/util/perl c:/perl/site/lib
> > c:/perl/lib .) at Configure line 20.
> > BEGIN failed--compilation aborted at Configure line 20.
> >
> >
> > I'll try some of the older stable snapshots.
> > On Tue, Oct 23, 2018 at 2:22 AM Richard Levitte <levitte at openssl.org> wrote:
> > >
> > > Silly me, I forgot we already fixed that bug:
> > >
> > >     commit 6258e244bf702dc981c8ad63ab61133b8bbf2ba3
> > >     Author: Richard Levitte <levitte at openssl.org>
> > >     Date:   Wed Sep 12 02:06:26 2018 +0200
> > >
> > >         crypto/sm2/sm2_sign.c: ensure UINT16_MAX is properly defined
> > >
> > >         Fixes #7186
> > >
> > >         Reviewed-by: Tim Hudson <tjh at openssl.org>
> > >         (Merged from https://github.com/openssl/openssl/pull/7193)
> > >
> > >         (cherry picked from commit 88ea3685e4bf30fc529fe46e19effc6317726de8)
> > >
> > > Cheers,
> > > Richard
> > >
> > > In message <20181023.103453.1842719922424343673.levitte at openssl.org> on Tue, 23 Oct 2018 10:34:53 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:
> > >
> > > > That indicates we do things in the wrong order (foo.obj depends on
> > > > foo.d, meaning foo.d gets "built" first), but that's a side issue.
> > > >
> > > > You found a bug in crypto\sm2\sm2_sign.c, thank you.  Are you willing
> > > > to write up a Github issue for it?
> > > >
> > > > In message <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q at mail.gmail.com> on Tue, 23 Oct 2018 01:22:34 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> > > >
> > > > > Thank you Richard. Adding the "no-makedepend" avoided the  fatal error
> > > > > U1077, but now it fails due to an undeclared identifier:
> > > > >
> > > > > cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I
> > > > > "." /I "crypto\include" /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC"
> > > > > -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
> > > > > -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
> > > > > -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM"
> > > > > -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM"
> > > > > -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"PADLOCK_ASM" -D"POLY1305_ASM"
> > > > > -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
> > > > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\sm2\sm2_sign.obj
> > > > > "crypto\sm2\sm2_sign.c"
> > > > > sm2_sign.c
> > > > > crypto\sm2\sm2_sign.c(70) : error C2065: 'UINT16_MAX' : undeclared identifier
> > > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > > Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> > > > > Stop.
> > > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > > > Stop.
> > > > > On Tue, Oct 23, 2018 at 12:19 AM Richard Levitte <levitte at openssl.org> wrote:
> > > > > >
> > > > > > I suspect you'll find some kind of error message in
> > > > > > crypto\sm2\sm2_sign.d.  I suspect that /showIncludes isn't supported
> > > > > > in VS 2008.
> > > > > >
> > > > > > There is a workaround for this problem, and it's to use the
> > > > > > 'no-makedepend' option:
> > > > > >
> > > > > >     perl Configure VC-WIN64A --prefix=c:/openssl no-makedepend
> > > > > >
> > > > > > For a single build, that should be good enough.
> > > > > >
> > > > > > Cheers,
> > > > > > Richard
> > > > > >
> > > > > > In message <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ at mail.gmail.com> on Mon, 22 Oct 2018 23:50:46 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> > > > > >
> > > > > > > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > > > > > > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > > > > > > 1.1.1 for VC-WIN64A I get the following compile error:
> > > > > > >
> > > > > > >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > > > > > > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > > > > > > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > > > > > > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > > > > > > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > > > > > > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > > > > > > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > > > > > > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > > > > > > Files\\Common Files\\SSL\""
> > > > > > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > > > > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > > > > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > > > > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > > > > > > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > > > > > > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > > > > > > Stop.
> > > > > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > > > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > > > > > Stop.
> > > > > > >
> > > > > > > My Command lines from the VS 2008 x64 Command Prompt are:
> > > > > > > perl Configure VC-WIN64A --prefix=c:/openssl
> > > > > > > nmake
> > > > > > >
> > > > > > > I also tried compiling the latest stable snapshot
> > > > > > > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > > > > > > version 1.1.0h compiles without error. Can anyone tell me what the
> > > > > > > problem is?
> > > > > > >
> > > > > > > Here is the configuration dump:
> > > > > > >
> > > > > > > Command line (with current working directory = .):
> > > > > > >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > > > > > > Perl information:
> > > > > > >     c:\perl\bin\perl.exe
> > > > > > >     5.24.3 for MSWin32-x64-multi-thread
> > > > > > > Enabled features:
> > > > > > >     aria
> > > > > > >     asm
> > > > > > >     async
> > > > > > >     autoalginit
> > > > > > >     autoerrinit
> > > > > > >     autoload-config
> > > > > > >     bf
> > > > > > >     blake2
> > > > > > >     camellia
> > > > > > >     capieng
> > > > > > >     cast
> > > > > > >     chacha
> > > > > > >     cmac
> > > > > > >     cms
> > > > > > >     comp
> > > > > > >     ct
> > > > > > >     deprecated
> > > > > > >     des
> > > > > > >     dgram
> > > > > > >     dh
> > > > > > >     dsa
> > > > > > >     dso
> > > > > > >     dtls
> > > > > > >     dynamic-engine
> > > > > > >     ec
> > > > > > >     ec2m
> > > > > > >     ecdh
> > > > > > >     ecdsa
> > > > > > >     engine
> > > > > > >     err
> > > > > > >     filenames
> > > > > > >     gost
> > > > > > >     hw(-.+)?
> > > > > > >     idea
> > > > > > >     makedepend
> > > > > > >     md4
> > > > > > >     mdc2
> > > > > > >     multiblock
> > > > > > >     nextprotoneg
> > > > > > >     ocb
> > > > > > >     ocsp
> > > > > > >     pic
> > > > > > >     poly1305
> > > > > > >     posix-io
> > > > > > >     psk
> > > > > > >     rc2
> > > > > > >     rc4
> > > > > > >     rdrand
> > > > > > >     rfc3779
> > > > > > >     rmd160
> > > > > > >     scrypt
> > > > > > >     seed
> > > > > > >     shared
> > > > > > >     siphash
> > > > > > >     sm2
> > > > > > >     sm3
> > > > > > >     sm4
> > > > > > >     sock
> > > > > > >     srp
> > > > > > >     srtp
> > > > > > >     sse2
> > > > > > >     ssl
> > > > > > >     static-engine
> > > > > > >     stdio
> > > > > > >     tests
> > > > > > >     threads
> > > > > > >     tls
> > > > > > >     ts
> > > > > > >     ui-console
> > > > > > >     whirlpool
> > > > > > >     tls1
> > > > > > >     tls1-method
> > > > > > >     tls1_1
> > > > > > >     tls1_1-method
> > > > > > >     tls1_2
> > > > > > >     tls1_2-method
> > > > > > >     tls1_3
> > > > > > >     dtls1
> > > > > > >     dtls1-method
> > > > > > >     dtls1_2
> > > > > > >     dtls1_2-method
> > > > > > > Disabled features:
> > > > > > >     afalgeng                [not-linux]
> > > > > > >     asan                    [default]   OPENSSL_NO_ASAN
> > > > > > >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> > > > > > >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> > > > > > >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> > > > > > >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> > > > > > >     egd                     [default]   OPENSSL_NO_EGD
> > > > > > >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> > > > > > >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> > > > > > >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> > > > > > >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> > > > > > >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> > > > > > >     msan                    [default]   OPENSSL_NO_MSAN
> > > > > > >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> > > > > > >     sctp                    [default]   OPENSSL_NO_SCTP
> > > > > > >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> > > > > > >     ubsan                   [default]   OPENSSL_NO_UBSAN
> > > > > > >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> > > > > > >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> > > > > > >     zlib                    [default]
> > > > > > >     zlib-dynamic            [default]
> > > > > > >     ssl3                    [default]   OPENSSL_NO_SSL3
> > > > > > >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > > > > > > Config target attributes:
> > > > > > >     AR => "lib",
> > > > > > >     ARFLAGS => "/nologo",
> > > > > > >     AS => "nasm",
> > > > > > >     ASFLAGS => "-g",
> > > > > > >     CC => "cl",
> > > > > > >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> > > > > > >     CPP => "\$(CC) /EP /C",
> > > > > > >     HASHBANGPERL => "/usr/bin/env perl",
> > > > > > >     LD => "link",
> > > > > > >     LDFLAGS => "/nologo /debug",
> > > > > > >     MT => "mt",
> > > > > > >     MTFLAGS => "-nologo",
> > > > > > >     RANLIB => "CODE(0x65aff0)",
> > > > > > >     RC => "rc",
> > > > > > >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > > > > > > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > > > > > > aesni-mb-x86_64.s",
> > > > > > >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > > > > > > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > > > > > > aesni-mb-x86_64.o",
> > > > > > >     apps_aux_src => "win32_init.c",
> > > > > > >     apps_init_src => "../ms/applink.c",
> > > > > > >     apps_obj => "win32_init.o",
> > > > > > >     aroutflag => "/out:",
> > > > > > >     asflags => "-Ox -f win64 -DNEAR",
> > > > > > >     asoutflag => "-o ",
> > > > > > >     bf_asm_src => "bf_enc.c",
> > > > > > >     bf_obj => "bf_enc.o",
> > > > > > >     bin_cflags => "/Zi /Fdapp.pdb",
> > > > > > >     bin_lflags => "/subsystem:console /opt:ref",
> > > > > > >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > > > > > > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> > > > > > >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > > > > > > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> > > > > > >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> > > > > > >     build_file => "makefile",
> > > > > > >     build_scheme => [ "unified", "windows", "VC-common" ],
> > > > > > >     cast_asm_src => "c_enc.c",
> > > > > > >     cast_obj => "c_enc.o",
> > > > > > >     cflags => "/Gs0 /GF /Gy /MD",
> > > > > > >     chacha_asm_src => "chacha-x86_64.s",
> > > > > > >     chacha_obj => "chacha-x86_64.o",
> > > > > > >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> > > > > > >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> > > > > > >     coutflag => "/Fo",
> > > > > > >     cppflags => "",
> > > > > > >     cpuid_asm_src => "x86_64cpuid.s",
> > > > > > >     cpuid_obj => "x86_64cpuid.o",
> > > > > > >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > > > > > > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > > > > > > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> > > > > > >     des_asm_src => "des_enc.c fcrypt_b.c",
> > > > > > >     des_obj => "des_enc.o fcrypt_b.o",
> > > > > > >     disable => [  ],
> > > > > > >     dso_cflags => "/Zi /Fddso.pdb",
> > > > > > >     dso_extension => "",
> > > > > > >     dso_scheme => "win32",
> > > > > > >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> > > > > > >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> > > > > > >     enable => [  ],
> > > > > > >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> > > > > > >     exe_extension => "",
> > > > > > >     includes => [  ],
> > > > > > >     keccak1600_asm_src => "keccak1600-x86_64.s",
> > > > > > >     keccak1600_obj => "keccak1600-x86_64.o",
> > > > > > >     ldoutflag => "/out:",
> > > > > > >     lflags => "",
> > > > > > >     lib_cflags => "/Zi /Fdossl_static.pdb",
> > > > > > >     lib_cppflags => "",
> > > > > > >     lib_defines => [ "L_ENDIAN" ],
> > > > > > >     md5_asm_src => "md5-x86_64.s",
> > > > > > >     md5_obj => "md5-x86_64.o",
> > > > > > >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> > > > > > >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> > > > > > >     module_cflags => "",
> > > > > > >     module_cxxflags => "",
> > > > > > >     module_ldflags => "/dll",
> > > > > > >     mtinflag => "-manifest ",
> > > > > > >     mtoutflag => "-outputresource:",
> > > > > > >     multilib => "-x64",
> > > > > > >     padlock_asm_src => "e_padlock-x86_64.s",
> > > > > > >     padlock_obj => "e_padlock-x86_64.o",
> > > > > > >     perlasm_scheme => "auto",
> > > > > > >     poly1305_asm_src => "poly1305-x86_64.s",
> > > > > > >     poly1305_obj => "poly1305-x86_64.o",
> > > > > > >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> > > > > > >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> > > > > > >     rc5_asm_src => "rc5_enc.c",
> > > > > > >     rc5_obj => "rc5_enc.o",
> > > > > > >     rcoutflag => "/fo",
> > > > > > >     rmd160_asm_src => "",
> > > > > > >     rmd160_obj => "",
> > > > > > >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > > > > > > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> > > > > > >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > > > > > > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> > > > > > >     shared_cflag => "",
> > > > > > >     shared_defines => [  ],
> > > > > > >     shared_extension => "",
> > > > > > >     shared_extension_simple => "",
> > > > > > >     shared_ldflag => "/dll",
> > > > > > >     shared_rcflag => "",
> > > > > > >     shared_target => "win-shared",
> > > > > > >     sys_id => "WIN64A",
> > > > > > >     thread_defines => [  ],
> > > > > > >     thread_scheme => "winthreads",
> > > > > > >     unistd => "<unistd.h>",
> > > > > > >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> > > > > > >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> > > > > > >     wp_asm_src => "wp-x86_64.s",
> > > > > > >     wp_obj => "wp-x86_64.o",
> > > > > > > Recorded environment:
> > > > > > >     AR =
> > > > > > >     ARFLAGS =
> > > > > > >     AS =
> > > > > > >     ASFLAGS =
> > > > > > >     BUILDFILE =
> > > > > > >     CC =
> > > > > > >     CFLAGS =
> > > > > > >     CPP =
> > > > > > >     CPPDEFINES =
> > > > > > >     CPPFLAGS =
> > > > > > >     CPPINCLUDES =
> > > > > > >     CROSS_COMPILE =
> > > > > > >     CXX =
> > > > > > >     CXXFLAGS =
> > > > > > >     HASHBANGPERL =
> > > > > > >     LD =
> > > > > > >     LDFLAGS =
> > > > > > >     LDLIBS =
> > > > > > >     MT =
> > > > > > >     MTFLAGS =
> > > > > > >     OPENSSL_LOCAL_CONFIG_DIR =
> > > > > > >     PERL =
> > > > > > >     RANLIB =
> > > > > > >     RC =
> > > > > > >     RCFLAGS =
> > > > > > >     RM =
> > > > > > >     WINDRES =
> > > > > > >     __CNF_CFLAGS =
> > > > > > >     __CNF_CPPDEFINES =
> > > > > > >     __CNF_CPPFLAGS =
> > > > > > >     __CNF_CPPINCLUDES =
> > > > > > >     __CNF_CXXFLAGS =
> > > > > > >     __CNF_LDFLAGS =
> > > > > > >     __CNF_LDLIBS =
> > > > > > > Makevars:
> > > > > > >     AR              = lib
> > > > > > >     ARFLAGS         = /nologo
> > > > > > >     AS              = nasm
> > > > > > >     ASFLAGS         = -g
> > > > > > >     CC              = cl
> > > > > > >     CFLAGS          = /W3 /wd4090 /nologo /O2
> > > > > > >     CPP             = $(CC) /EP /C
> > > > > > >     CPPDEFINES      =
> > > > > > >     CPPFLAGS        =
> > > > > > >     CPPINCLUDES     =
> > > > > > >     CXXFLAGS        =
> > > > > > >     HASHBANGPERL    = /usr/bin/env perl
> > > > > > >     LD              = link
> > > > > > >     LDFLAGS         = /nologo /debug
> > > > > > >     LDLIBS          =
> > > > > > >     MT              = mt
> > > > > > >     MTFLAGS         = -nologo
> > > > > > >     PERL            = c:\perl\bin\perl.exe
> > > > > > >     RC              = rc
> > > > > > > NOTE: These variables only represent the configuration view.  The build file
> > > > > > > template may have processed these variables further, please have a look at the
> > > > > > > build file for more exact data:
> > > > > > >     makefile
> > > > > > > build file:
> > > > > > >     makefile
> > > > > > > build file templates:
> > > > > > >     Configurations\common0.tmpl
> > > > > > >     Configurations\windows-makefile.tmpl
> > > > > > >     Configurations\common.tmpl
> > > > > > >
> > > > > > --
> > > > > > 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 levitte at openssl.org  Tue Oct 23 10:57:53 2018
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 23 Oct 2018 12:57:53 +0200 (CEST)
Subject: [openssl-users] How to compile 1.1.1 under Windows
In-Reply-To: <CACaGmvAWKCa9CrAnqOu9_k5Wc=ev+p7hfWMzwFt46c8nrgoB9w@mail.gmail.com>
References: <20181023.112217.1628265974252467568.levitte@openssl.org>
 <CACaGmvBCbiNeT=BkgFEsLo4fgmn-Qba-LjX4Pr8tHrffSX0kVA@mail.gmail.com>
 <CACaGmvAWKCa9CrAnqOu9_k5Wc=ev+p7hfWMzwFt46c8nrgoB9w@mail.gmail.com>
Message-ID: <20181023.125753.184245511437463802.levitte@openssl.org>

I discovered that very same issue earlier today.  Fix is in:

commit 28361a0b821d36e3b19271b0a7909d5355b0990c (HEAD -> OpenSSL_1_1_1-stable, origin/OpenSSL_1_1_1-stable)
Author: Richard Levitte <levitte at openssl.org>
Date:   Tue Oct 23 10:15:12 2018 +0200

    RAND: ensure INT32_MAX is defined
    
    This value is used to set DRBG_MAX_LENGTH
    
    Reviewed-by: Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com>
    (Merged from https://github.com/openssl/openssl/pull/7467)
    
    (cherry picked from commit f81b043ad856d8b9af5239a4978f8bd4b965dab9)

diff --git a/crypto/rand/rand_lcl.h b/crypto/rand/rand_lcl.h
index 5d9fb13ab..38614a85b 100644
--- a/crypto/rand/rand_lcl.h
+++ b/crypto/rand/rand_lcl.h
@@ -17,6 +17,8 @@
 # include <openssl/ec.h>
 # include <openssl/rand_drbg.h>
 
+# include "internal/numbers.h"
+
 /* How many times to read the TSC as a randomness source. */
 # define TSC_READ_COUNT                 4
 
Cheers,
Richard

In message <CACaGmvAWKCa9CrAnqOu9_k5Wc=ev+p7hfWMzwFt46c8nrgoB9w at mail.gmail.com> on Tue, 23 Oct 2018 03:31:53 -0700, Chris Clark <a.chris.clark at gmail.com> said:

> Next I tried an older stable snapshot
> openssl-1.1.1-stable-SNAP-20181018 which configured without issue, but
> I got a different compile result:
> 
>         cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090
> /nologo /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> Files\\Common Files\\SSL\""
> -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\rand\drbg_ctr.obj
> "crypto\rand\drbg_ctr.c"
> drbg_ctr.c
> crypto\rand\drbg_ctr.c(399) : warning C4267: '=' : conversion from
> 'size_t' to 'int', possible loss of data
> crypto\rand\drbg_ctr.c(420) : error C2065: 'INT32_MAX' : undeclared identifier
> crypto\rand\drbg_ctr.c(422) : error C2065: 'INT32_MAX' : undeclared identifier
> crypto\rand\drbg_ctr.c(423) : error C2065: 'INT32_MAX' : undeclared identifier
> crypto\rand\drbg_ctr.c(424) : error C2065: 'INT32_MAX' : undeclared identifier
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> Stop.
> On Tue, Oct 23, 2018 at 3:17 AM Chris Clark <a.chris.clark at gmail.com> wrote:
> >
> > Thanks Richard. I downloaded the latest stable snapshot in order to
> > bypass the UINT16_MAX definition bug, but this version fails to
> > configure:
> >
> > C:\openssl-1.1.1-stable-SNAP-20181022>perl Configure VC-WIN64A
> > --prefix=c:/openssl no-makedepend
> > Can't locate OpenSSL/Glob.pm in @INC (you may need to install the
> > OpenSSL::Glob module) (@INC contains:
> > C:/openssl-1.1.1-stable-SNAP-20181022/util/perl c:/perl/site/lib
> > c:/perl/lib .) at Configure line 20.
> > BEGIN failed--compilation aborted at Configure line 20.
> >
> >
> > I'll try some of the older stable snapshots.
> > On Tue, Oct 23, 2018 at 2:22 AM Richard Levitte <levitte at openssl.org> wrote:
> > >
> > > Silly me, I forgot we already fixed that bug:
> > >
> > >     commit 6258e244bf702dc981c8ad63ab61133b8bbf2ba3
> > >     Author: Richard Levitte <levitte at openssl.org>
> > >     Date:   Wed Sep 12 02:06:26 2018 +0200
> > >
> > >         crypto/sm2/sm2_sign.c: ensure UINT16_MAX is properly defined
> > >
> > >         Fixes #7186
> > >
> > >         Reviewed-by: Tim Hudson <tjh at openssl.org>
> > >         (Merged from https://github.com/openssl/openssl/pull/7193)
> > >
> > >         (cherry picked from commit 88ea3685e4bf30fc529fe46e19effc6317726de8)
> > >
> > > Cheers,
> > > Richard
> > >
> > > In message <20181023.103453.1842719922424343673.levitte at openssl.org> on Tue, 23 Oct 2018 10:34:53 +0200 (CEST), Richard Levitte <levitte at openssl.org> said:
> > >
> > > > That indicates we do things in the wrong order (foo.obj depends on
> > > > foo.d, meaning foo.d gets "built" first), but that's a side issue.
> > > >
> > > > You found a bug in crypto\sm2\sm2_sign.c, thank you.  Are you willing
> > > > to write up a Github issue for it?
> > > >
> > > > In message <CACaGmvAzV1eUXBWh=4N0qaKs3VH0AO4cmsLXxdWeMnzNP8QJ5Q at mail.gmail.com> on Tue, 23 Oct 2018 01:22:34 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> > > >
> > > > > Thank you Richard. Adding the "no-makedepend" avoided the  fatal error
> > > > > U1077, but now it fails due to an undeclared identifier:
> > > > >
> > > > > cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /I
> > > > > "." /I "crypto\include" /I "include" -D"L_ENDIAN" -D"OPENSSL_PIC"
> > > > > -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2" -D"OPENSSL_BN_ASM_MONT"
> > > > > -D"OPENSSL_BN_ASM_MONT5" -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM"
> > > > > -D"SHA256_ASM" -D"SHA512_ASM" -D"KECCAK1600_ASM" -D"RC4_ASM"
> > > > > -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM" -D"BSAES_ASM" -D"GHASH_ASM"
> > > > > -D"ECP_NISTZ256_ASM" -D"X25519_ASM" -D"PADLOCK_ASM" -D"POLY1305_ASM"
> > > > > -D"OPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\""
> > > > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  -c /Focrypto\sm2\sm2_sign.obj
> > > > > "crypto\sm2\sm2_sign.c"
> > > > > sm2_sign.c
> > > > > crypto\sm2\sm2_sign.c(70) : error C2065: 'UINT16_MAX' : undeclared identifier
> > > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > > Studio 9.0\VC\BIN\amd64\cl.EXE"' : return code '0x2'
> > > > > Stop.
> > > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > > > Stop.
> > > > > On Tue, Oct 23, 2018 at 12:19 AM Richard Levitte <levitte at openssl.org> wrote:
> > > > > >
> > > > > > I suspect you'll find some kind of error message in
> > > > > > crypto\sm2\sm2_sign.d.  I suspect that /showIncludes isn't supported
> > > > > > in VS 2008.
> > > > > >
> > > > > > There is a workaround for this problem, and it's to use the
> > > > > > 'no-makedepend' option:
> > > > > >
> > > > > >     perl Configure VC-WIN64A --prefix=c:/openssl no-makedepend
> > > > > >
> > > > > > For a single build, that should be good enough.
> > > > > >
> > > > > > Cheers,
> > > > > > Richard
> > > > > >
> > > > > > In message <CACaGmvAh8SHsX4_dVPjzb4BQPNc5a0rQQoK-JB9Qi=Oo_4HHeQ at mail.gmail.com> on Mon, 22 Oct 2018 23:50:46 -0700, Chris Clark <a.chris.clark at gmail.com> said:
> > > > > >
> > > > > > > I am attempting to upgrade a project using OpenSSL 1.0.0h to version
> > > > > > > 1.1.1 under Visual Studio 2008-SP1, but when I try to compile version
> > > > > > > 1.1.1 for VC-WIN64A I get the following compile error:
> > > > > > >
> > > > > > >        cl  /Zi /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo
> > > > > > > /O2 /I "." /I "crypto\include" /I "include" -D"L_ENDIAN"
> > > > > > > -D"OPENSSL_PIC" -D"OPENSSL_CPUID_OBJ" -D"OPENSSL_IA32_SSE2"
> > > > > > > -D"OPENSSL_BN_ASM_MONT" -D"OPENSSL_BN_ASM_MONT5"
> > > > > > > -D"OPENSSL_BN_ASM_GF2m" -D"SHA1_ASM" -D"SHA256_ASM" -D"SHA512_ASM"
> > > > > > > -D"KECCAK1600_ASM" -D"RC4_ASM" -D"MD5_ASM" -D"AES_ASM" -D"VPAES_ASM"
> > > > > > > -D"BSAES_ASM" -D"GHASH_ASM" -D"ECP_NISTZ256_ASM" -D"X25519_ASM"
> > > > > > > -D"PADLOCK_ASM" -D"POLY1305_ASM" -D"OPENSSLDIR=\"C:\\Program
> > > > > > > Files\\Common Files\\SSL\""
> > > > > > > -D"ENGINESDIR=\"C:\\openssl\\lib\\engines-1_1\"" -D"OPENSSL_SYS_WIN32"
> > > > > > > -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE"
> > > > > > > -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS"
> > > > > > > -D"OPENSSL_USE_APPLINK" -D"NDEBUG"  /Zs /showIncludes
> > > > > > > "crypto\sm2\sm2_sign.c" 2>&1 > crypto\sm2\sm2_sign.d
> > > > > > > NMAKE : fatal error U1077: 'cl' : return code '0x2'
> > > > > > > Stop.
> > > > > > > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> > > > > > > Studio 9.0\VC\BIN\amd64\nmake.exe"' : return code '0x2'
> > > > > > > Stop.
> > > > > > >
> > > > > > > My Command lines from the VS 2008 x64 Command Prompt are:
> > > > > > > perl Configure VC-WIN64A --prefix=c:/openssl
> > > > > > > nmake
> > > > > > >
> > > > > > > I also tried compiling the latest stable snapshot
> > > > > > > (openssl-1.1.1-stable-SNAP-20181022) with the same results. However
> > > > > > > version 1.1.0h compiles without error. Can anyone tell me what the
> > > > > > > problem is?
> > > > > > >
> > > > > > > Here is the configuration dump:
> > > > > > >
> > > > > > > Command line (with current working directory = .):
> > > > > > >     c:\perl\bin\perl.exe Configure VC-WIN64A --prefix=c:/openssl
> > > > > > > Perl information:
> > > > > > >     c:\perl\bin\perl.exe
> > > > > > >     5.24.3 for MSWin32-x64-multi-thread
> > > > > > > Enabled features:
> > > > > > >     aria
> > > > > > >     asm
> > > > > > >     async
> > > > > > >     autoalginit
> > > > > > >     autoerrinit
> > > > > > >     autoload-config
> > > > > > >     bf
> > > > > > >     blake2
> > > > > > >     camellia
> > > > > > >     capieng
> > > > > > >     cast
> > > > > > >     chacha
> > > > > > >     cmac
> > > > > > >     cms
> > > > > > >     comp
> > > > > > >     ct
> > > > > > >     deprecated
> > > > > > >     des
> > > > > > >     dgram
> > > > > > >     dh
> > > > > > >     dsa
> > > > > > >     dso
> > > > > > >     dtls
> > > > > > >     dynamic-engine
> > > > > > >     ec
> > > > > > >     ec2m
> > > > > > >     ecdh
> > > > > > >     ecdsa
> > > > > > >     engine
> > > > > > >     err
> > > > > > >     filenames
> > > > > > >     gost
> > > > > > >     hw(-.+)?
> > > > > > >     idea
> > > > > > >     makedepend
> > > > > > >     md4
> > > > > > >     mdc2
> > > > > > >     multiblock
> > > > > > >     nextprotoneg
> > > > > > >     ocb
> > > > > > >     ocsp
> > > > > > >     pic
> > > > > > >     poly1305
> > > > > > >     posix-io
> > > > > > >     psk
> > > > > > >     rc2
> > > > > > >     rc4
> > > > > > >     rdrand
> > > > > > >     rfc3779
> > > > > > >     rmd160
> > > > > > >     scrypt
> > > > > > >     seed
> > > > > > >     shared
> > > > > > >     siphash
> > > > > > >     sm2
> > > > > > >     sm3
> > > > > > >     sm4
> > > > > > >     sock
> > > > > > >     srp
> > > > > > >     srtp
> > > > > > >     sse2
> > > > > > >     ssl
> > > > > > >     static-engine
> > > > > > >     stdio
> > > > > > >     tests
> > > > > > >     threads
> > > > > > >     tls
> > > > > > >     ts
> > > > > > >     ui-console
> > > > > > >     whirlpool
> > > > > > >     tls1
> > > > > > >     tls1-method
> > > > > > >     tls1_1
> > > > > > >     tls1_1-method
> > > > > > >     tls1_2
> > > > > > >     tls1_2-method
> > > > > > >     tls1_3
> > > > > > >     dtls1
> > > > > > >     dtls1-method
> > > > > > >     dtls1_2
> > > > > > >     dtls1_2-method
> > > > > > > Disabled features:
> > > > > > >     afalgeng                [not-linux]
> > > > > > >     asan                    [default]   OPENSSL_NO_ASAN
> > > > > > >     crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
> > > > > > >     crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
> > > > > > >     devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
> > > > > > >     ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
> > > > > > >     egd                     [default]   OPENSSL_NO_EGD
> > > > > > >     external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
> > > > > > >     fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
> > > > > > >     fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
> > > > > > >     heartbeats              [default]   OPENSSL_NO_HEARTBEATS
> > > > > > >     md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
> > > > > > >     msan                    [default]   OPENSSL_NO_MSAN
> > > > > > >     rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
> > > > > > >     sctp                    [default]   OPENSSL_NO_SCTP
> > > > > > >     ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
> > > > > > >     ubsan                   [default]   OPENSSL_NO_UBSAN
> > > > > > >     unit-test               [default]   OPENSSL_NO_UNIT_TEST
> > > > > > >     weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
> > > > > > >     zlib                    [default]
> > > > > > >     zlib-dynamic            [default]
> > > > > > >     ssl3                    [default]   OPENSSL_NO_SSL3
> > > > > > >     ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD
> > > > > > > Config target attributes:
> > > > > > >     AR => "lib",
> > > > > > >     ARFLAGS => "/nologo",
> > > > > > >     AS => "nasm",
> > > > > > >     ASFLAGS => "-g",
> > > > > > >     CC => "cl",
> > > > > > >     CFLAGS => "/W3 /wd4090 /nologo /O2",
> > > > > > >     CPP => "\$(CC) /EP /C",
> > > > > > >     HASHBANGPERL => "/usr/bin/env perl",
> > > > > > >     LD => "link",
> > > > > > >     LDFLAGS => "/nologo /debug",
> > > > > > >     MT => "mt",
> > > > > > >     MTFLAGS => "-nologo",
> > > > > > >     RANLIB => "CODE(0x65aff0)",
> > > > > > >     RC => "rc",
> > > > > > >     aes_asm_src => "aes-x86_64.s vpaes-x86_64.s bsaes-x86_64.s
> > > > > > > aesni-x86_64.s aesni-sha1-x86_64.s aesni-sha256-x86_64.s
> > > > > > > aesni-mb-x86_64.s",
> > > > > > >     aes_obj => "aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o
> > > > > > > aesni-x86_64.o aesni-sha1-x86_64.o aesni-sha256-x86_64.o
> > > > > > > aesni-mb-x86_64.o",
> > > > > > >     apps_aux_src => "win32_init.c",
> > > > > > >     apps_init_src => "../ms/applink.c",
> > > > > > >     apps_obj => "win32_init.o",
> > > > > > >     aroutflag => "/out:",
> > > > > > >     asflags => "-Ox -f win64 -DNEAR",
> > > > > > >     asoutflag => "-o ",
> > > > > > >     bf_asm_src => "bf_enc.c",
> > > > > > >     bf_obj => "bf_enc.o",
> > > > > > >     bin_cflags => "/Zi /Fdapp.pdb",
> > > > > > >     bin_lflags => "/subsystem:console /opt:ref",
> > > > > > >     bn_asm_src => "bn_asm.c x86_64-mont.s x86_64-mont5.s x86_64-gf2m.s
> > > > > > > rsaz_exp.c rsaz-x86_64.s rsaz-avx2.s",
> > > > > > >     bn_obj => "bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o
> > > > > > > rsaz_exp.o rsaz-x86_64.o rsaz-avx2.o",
> > > > > > >     bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
> > > > > > >     build_file => "makefile",
> > > > > > >     build_scheme => [ "unified", "windows", "VC-common" ],
> > > > > > >     cast_asm_src => "c_enc.c",
> > > > > > >     cast_obj => "c_enc.o",
> > > > > > >     cflags => "/Gs0 /GF /Gy /MD",
> > > > > > >     chacha_asm_src => "chacha-x86_64.s",
> > > > > > >     chacha_obj => "chacha-x86_64.o",
> > > > > > >     cmll_asm_src => "cmll-x86_64.s cmll_misc.c",
> > > > > > >     cmll_obj => "cmll-x86_64.o cmll_misc.o",
> > > > > > >     coutflag => "/Fo",
> > > > > > >     cppflags => "",
> > > > > > >     cpuid_asm_src => "x86_64cpuid.s",
> > > > > > >     cpuid_obj => "x86_64cpuid.o",
> > > > > > >     defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN",
> > > > > > > "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE",
> > > > > > > "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
> > > > > > >     des_asm_src => "des_enc.c fcrypt_b.c",
> > > > > > >     des_obj => "des_enc.o fcrypt_b.o",
> > > > > > >     disable => [  ],
> > > > > > >     dso_cflags => "/Zi /Fddso.pdb",
> > > > > > >     dso_extension => "",
> > > > > > >     dso_scheme => "win32",
> > > > > > >     ec_asm_src => "ecp_nistz256.c ecp_nistz256-x86_64.s x25519-x86_64.s",
> > > > > > >     ec_obj => "ecp_nistz256.o ecp_nistz256-x86_64.o x25519-x86_64.o",
> > > > > > >     enable => [  ],
> > > > > > >     ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
> > > > > > >     exe_extension => "",
> > > > > > >     includes => [  ],
> > > > > > >     keccak1600_asm_src => "keccak1600-x86_64.s",
> > > > > > >     keccak1600_obj => "keccak1600-x86_64.o",
> > > > > > >     ldoutflag => "/out:",
> > > > > > >     lflags => "",
> > > > > > >     lib_cflags => "/Zi /Fdossl_static.pdb",
> > > > > > >     lib_cppflags => "",
> > > > > > >     lib_defines => [ "L_ENDIAN" ],
> > > > > > >     md5_asm_src => "md5-x86_64.s",
> > > > > > >     md5_obj => "md5-x86_64.o",
> > > > > > >     modes_asm_src => "ghash-x86_64.s aesni-gcm-x86_64.s",
> > > > > > >     modes_obj => "ghash-x86_64.o aesni-gcm-x86_64.o",
> > > > > > >     module_cflags => "",
> > > > > > >     module_cxxflags => "",
> > > > > > >     module_ldflags => "/dll",
> > > > > > >     mtinflag => "-manifest ",
> > > > > > >     mtoutflag => "-outputresource:",
> > > > > > >     multilib => "-x64",
> > > > > > >     padlock_asm_src => "e_padlock-x86_64.s",
> > > > > > >     padlock_obj => "e_padlock-x86_64.o",
> > > > > > >     perlasm_scheme => "auto",
> > > > > > >     poly1305_asm_src => "poly1305-x86_64.s",
> > > > > > >     poly1305_obj => "poly1305-x86_64.o",
> > > > > > >     rc4_asm_src => "rc4-x86_64.s rc4-md5-x86_64.s",
> > > > > > >     rc4_obj => "rc4-x86_64.o rc4-md5-x86_64.o",
> > > > > > >     rc5_asm_src => "rc5_enc.c",
> > > > > > >     rc5_obj => "rc5_enc.o",
> > > > > > >     rcoutflag => "/fo",
> > > > > > >     rmd160_asm_src => "",
> > > > > > >     rmd160_obj => "",
> > > > > > >     sha1_asm_src => "sha1-x86_64.s sha256-x86_64.s sha512-x86_64.s
> > > > > > > sha1-mb-x86_64.s sha256-mb-x86_64.s",
> > > > > > >     sha1_obj => "sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o
> > > > > > > sha1-mb-x86_64.o sha256-mb-x86_64.o",
> > > > > > >     shared_cflag => "",
> > > > > > >     shared_defines => [  ],
> > > > > > >     shared_extension => "",
> > > > > > >     shared_extension_simple => "",
> > > > > > >     shared_ldflag => "/dll",
> > > > > > >     shared_rcflag => "",
> > > > > > >     shared_target => "win-shared",
> > > > > > >     sys_id => "WIN64A",
> > > > > > >     thread_defines => [  ],
> > > > > > >     thread_scheme => "winthreads",
> > > > > > >     unistd => "<unistd.h>",
> > > > > > >     uplink_aux_src => "../ms/uplink.c uplink-x86_64.s",
> > > > > > >     uplink_obj => "../ms/uplink.o uplink-x86_64.o",
> > > > > > >     wp_asm_src => "wp-x86_64.s",
> > > > > > >     wp_obj => "wp-x86_64.o",
> > > > > > > Recorded environment:
> > > > > > >     AR =
> > > > > > >     ARFLAGS =
> > > > > > >     AS =
> > > > > > >     ASFLAGS =
> > > > > > >     BUILDFILE =
> > > > > > >     CC =
> > > > > > >     CFLAGS =
> > > > > > >     CPP =
> > > > > > >     CPPDEFINES =
> > > > > > >     CPPFLAGS =
> > > > > > >     CPPINCLUDES =
> > > > > > >     CROSS_COMPILE =
> > > > > > >     CXX =
> > > > > > >     CXXFLAGS =
> > > > > > >     HASHBANGPERL =
> > > > > > >     LD =
> > > > > > >     LDFLAGS =
> > > > > > >     LDLIBS =
> > > > > > >     MT =
> > > > > > >     MTFLAGS =
> > > > > > >     OPENSSL_LOCAL_CONFIG_DIR =
> > > > > > >     PERL =
> > > > > > >     RANLIB =
> > > > > > >     RC =
> > > > > > >     RCFLAGS =
> > > > > > >     RM =
> > > > > > >     WINDRES =
> > > > > > >     __CNF_CFLAGS =
> > > > > > >     __CNF_CPPDEFINES =
> > > > > > >     __CNF_CPPFLAGS =
> > > > > > >     __CNF_CPPINCLUDES =
> > > > > > >     __CNF_CXXFLAGS =
> > > > > > >     __CNF_LDFLAGS =
> > > > > > >     __CNF_LDLIBS =
> > > > > > > Makevars:
> > > > > > >     AR              = lib
> > > > > > >     ARFLAGS         = /nologo
> > > > > > >     AS              = nasm
> > > > > > >     ASFLAGS         = -g
> > > > > > >     CC              = cl
> > > > > > >     CFLAGS          = /W3 /wd4090 /nologo /O2
> > > > > > >     CPP             = $(CC) /EP /C
> > > > > > >     CPPDEFINES      =
> > > > > > >     CPPFLAGS        =
> > > > > > >     CPPINCLUDES     =
> > > > > > >     CXXFLAGS        =
> > > > > > >     HASHBANGPERL    = /usr/bin/env perl
> > > > > > >     LD              = link
> > > > > > >     LDFLAGS         = /nologo /debug
> > > > > > >     LDLIBS          =
> > > > > > >     MT              = mt
> > > > > > >     MTFLAGS         = -nologo
> > > > > > >     PERL            = c:\perl\bin\perl.exe
> > > > > > >     RC              = rc
> > > > > > > NOTE: These variables only represent the configuration view.  The build file
> > > > > > > template may have processed these variables further, please have a look at the
> > > > > > > build file for more exact data:
> > > > > > >     makefile
> > > > > > > build file:
> > > > > > >     makefile
> > > > > > > build file templates:
> > > > > > >     Configurations\common0.tmpl
> > > > > > >     Configurations\windows-makefile.tmpl
> > > > > > >     Configurations\common.tmpl
> > > > > > >
> > > > > > --
> > > > > > 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 rama.krushna7 at gmail.com  Tue Oct 23 11:32:17 2018
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Tue, 23 Oct 2018 17:02:17 +0530
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <mailman.4483.1540230644.21411.openssl-users@openssl.org>
References: <mailman.4483.1540230644.21411.openssl-users@openssl.org>
Message-ID: <CAHgr=kLammN_hcYkR+OF65VyZLvLmYtxHigtH1nu5VfpZx0zdQ@mail.gmail.com>

Hi Matt,

Thanks for your response.
 My client is built with openssl 1.0.0e  and server with openssl 1.1.1.
 I have tried to collect information with wireshark, but I think as my
server and client are running on same machine , it is not capturing
anything. I have also tried with tshark on linux and got no traces again.

I have this trouble both on nt64and linuxx86_64. Do we have any other
mechanism to capture the traces ?

We have internal tracing enabled and I can see following information in our
tracing.
**********************************************************************************
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL State: 16
before SSL initialization
[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- ctrl to 00000000 [02457660] (6 bytes => 0 (0x0))

[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- contents of a BIO dump:
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:before
SSL initialization
[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- read to 00000000 [02463953] (5 bytes => 5 (0x5))

[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- contents of a BIO dump:
0000 - 16 03 01 00 b2                                    .....
[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- read to 00000000 [02463958] (178 bytes => 178 (0xB2))

[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- contents of a BIO dump:
0000 - 01 00 00 ae 03 03 10 b1-1e 8f f0 07 d6 28 d9 02   .............(..
0010 - b7 91 b4 3d 14 5a af 3e-09 96 2a cf ee 8b ca 30   ...=.Z.>..*....0
0020 - cc 68 9f 2c 2e 6e 00 00-62 00 a5 00 a3 00 a1 00   .h.,.n..b.......
0030 - 9f 00 6b 00 6a 00 69 00-68 00 39 00 38 00 37 00   ..k.j.i.h.9.8.7.
0040 - 36 00 9d 00 3d 00 35 00-a4 00 a2 00 a0 00 9e 00   6...=.5.........
0050 - 67 00 40 00 3f 00 3e 00-33 00 32 00 31 00 30 00   g. at .?.>.3.2.1.0.
0060 - 9a 00 99 00 98 00 97 00-9c 00 3c 00 2f 00 96 00   ..........<./...
0070 - 05 00 04 00 16 00 13 00-10 00 0d 00 0a 00 15 00   ................
0080 - 12 00 0f 00 0c 00 09 00-ff *56 00* 01 00 00 23 00   .........V....#.
0090 - 23 00 00 00 0d 00 16 00-14 06 01 06 02 05 01 05   #...............
00a0 - 02 04 01 04 02 03 01 03-02 02 01 02 02 00 0f 00   ................
00b0 - 01 01                                             ..
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:before
SSL initialization
[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- write to 00000000 [024725E0] (7 bytes => 7 (0x7))

[Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000 BIO
 --- contents of a BIO dump:
0000 - 15 03 03 00 02 02 56                              ......V
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION ---  write:fatal:unknown
[Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:error in
error
********************
In the above dump , "56 00 " is present in the cipher suites sent in client
hello.
So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in
client hello.
However there is no earlier failure to this handshake.

As per your comment, client should only send it if it witnessed some
earlier failure.
In that case, I have following additional doubt.

-- this set up is working when server is running with TLSv1.2 and only
failing when server has both TLSv1,2 and TLSv1.3 ( i.e with openssl1.1.1).
So are there any changes in openssl1.1.1 which will effect this behavior
when compared to openssl1.0.0e version ?


Thanks and Regards,
Ram Krushna


On Mon, Oct 22, 2018 at 11:21 PM <openssl-users-request at openssl.org> wrote:

> 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: What to do with deprecation errors (Salz, Rich)
>    2. Re: What to do with deprecation errors (Matt Caswell)
>    3. Re: To disable CBC ciphers (Jakob Bohm)
>    4. Reg issue in alert message (ramakrushna mishra)
>    5. Re: Reg issue in alert message (Matt Caswell)
>    6. Re: What to do with deprecation errors (Skip Carter)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 22 Oct 2018 02:08:23 +0000
> From: "Salz, Rich" <rsalz at akamai.com>
> To: Skip Carter <skip at taygeta.com>, "openssl-users at openssl.org"
>         <openssl-users at openssl.org>
> Subject: Re: [openssl-users] What to do with deprecation errors
> Message-ID: <8260BB64-B12E-4779-B9DF-903D23E47FD3 at akamai.com>
> Content-Type: text/plain; charset="utf-8"
>
> >    DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP
> *group,
>
> That is "proof" that the pre-processor doesn?t have the right -I flags.
> Try running with the -v option or something.
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 22 Oct 2018 08:55:28 +0100
> From: Matt Caswell <matt at openssl.org>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] What to do with deprecation errors
> Message-ID: <7513a526-2840-6a4e-cf9a-99666ffc1330 at openssl.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 21/10/2018 20:01, Skip Carter wrote:
> > Thats what I originally thought.
> >
> > I experimented with manually invoking the pre-compiler (cpp) and this
> > is what I get:
> >
> >
> > DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,
> >                     ?
> > BIGNUM *p,
> > ???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
> > ???????????????????????????????????????????????BN_CTX *ctx))
> > the macro is not firing, shouldn't I get:
> >
> > extern int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,
> >         ?                                              BIGNUM *p,
> > ???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
> > ???
> > ????????????????????????????????????????????BN_CTX *ctx);
> >
> >
> > On Sun, 2018-10-21 at 18:28 +0000, Salz, Rich via openssl-users wrote:
> >>> ???And I still have the problem with those macros.
> >>
> >> ??
> >> The problem is almost definitely this:??the files that you are
> >> compiling (not openssl) are picking up the wrong header files from
> >> openssl.
> >>
>
> Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in it?
>
> Matt
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 22 Oct 2018 15:34:20 +0200
> From: Jakob Bohm <jb-openssl at wisemo.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] To disable CBC ciphers
> Message-ID: <d91267e8-4681-9a77-23fa-d790200e2259 at wisemo.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 20/10/2018 15:59, Kaushal Shriyan wrote:
> >
> >
> > On Wed, Oct 17, 2018 at 7:00 PM murugesh pitchaiah
> > <murugesh.pitchaiah at gmail.com <mailto:murugesh.pitchaiah at gmail.com>>
> > wrote:
> >
> >     Hi,
> >
> >     You may list down what ciphers configured : "openssl ciphers"
> >     Choose CBC ciphers and add them to the list of 'ssl_ciphers' with "!"
> >     prefix appended to current ssl_ciphers.
> >
> >     > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
> >
> >     Ref:
> >
> https://serverfault.com/questions/692119/meaning-of-ssl-ciphers-line-on-nginx-conf
> >
> >     Thanks,
> >     Murugesh P.
> >
> >
> >     On 10/17/18, Kaushal Shriyan <kaushalshriyan at gmail.com
> >     <mailto:kaushalshriyan at gmail.com>> wrote:
> >     > Hi,
> >     >
> >     > I have the below ssl settings in nginx.conf file and VAPT test
> >     has reported
> >     > us to disable CBC ciphers
> >     >
> >     > ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;
> >     >> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
> >     >
> >     >
> >     > openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on
> >     CentOS
> >     > Linux release 7.3.1611 (Core)
> >     >
> >     > I will appreciate if someone can pitch in to help me understand
> >     to disable
> >     > CBC ciphers
> >     >
> >
> >
> > Thanks Murugesh. I did checked openssl ciphers
> > https://www.openssl.org/docs/man1.0.2/apps/ciphers.html and could not
> see
> > !AAA_CBC_BBB as mentioned in your email.
> >
> >     ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
> >
> >
> > Correct me if i am understanding it wrong. Basically i want to disable
> > Cipher Block Chaining (CBC) mode cipher encryption. Openssl and OS
> > version are as below :-
> >
> >     openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on
> >     CentOS
> >     Linux release 7.3.1611 (Core)
> >
> >
> > Any tools which i can run to find out vulnerabilities in the above
> > openssl and OS version? Please guide and i look forward to hearing
> > from you. Thanks in Advance.
> You need to replace AAA and BBB with actual strings corresponding to
> each of the unwanted cipher suites.
>
> The advisor that tells you to disable "CBC ciphers" is mostly wrong.
> There is nothing inherently bad about correctly using ciphers in CBC
> mode, however some TLS protocol versions happen to use CBC cipher
> suites in a problematic way, while having no secure non-CBC cipher
> suites.? More recent TLS versions (such as TLS 1.2) have less
> problematic (but not perfect) CBC usage and also offers some
> overhyped US government ciphers such as the AES_GCM family.
>
> 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
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 22 Oct 2018 19:26:55 +0530
> From: ramakrushna mishra <rama.krushna7 at gmail.com>
> To: openssl-users at openssl.org
> Subject: [openssl-users] Reg issue in alert message
> Message-ID:
>         <CAHgr=kJyCXVY9QssB2CO3hY=
> GsEwiEcvzwQ-Pyd3VKqSm51XLA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
>
> I am facing an issue after openssl upgrade to 1.1.1.
> I have a odbc client with maximum version support up to TLSv1.2 and  my
> database is running with TLSv1.2,TLsv1.3.
>
> The handhake is failing and I am getting following contents on my BIO dump.
> "15 03 03 00 02 02 56" .
> If i have understood correctly this is for alert message and But I could
> not find any reference to alert description at (
> https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )
> corresponding to 56.
>
> So, Could you please help me figure out what does this correspond to ?
>
> Moreover I have following doubt.
>
> -- If my TLSv1.2 client does not handle the  "downgrade sentinel " present
> in server hello ( TLSv1.3 , will it create any problem ?
> -- In the above example client is receving error such as "SSL Handshake
> Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> alert inappropriate fallback]." ? Could you please help me to hint me about
> how to debug this ?
>
> Thanks and Regards,
> Ram Krushna
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20181022/cb04af81/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Mon, 22 Oct 2018 15:10:55 +0100
> From: Matt Caswell <matt at openssl.org>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Reg issue in alert message
> Message-ID: <3c26e4ec-32e4-f3df-c1ae-0ed1cdeb5848 at openssl.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 22/10/2018 14:56, ramakrushna mishra wrote:
> > Hi,
> >
> > I am facing an issue after openssl upgrade to 1.1.1.?
> > I have a odbc client with maximum version support up to TLSv1.2 and? my
> > database is running with TLSv1.2,TLsv1.3.?
> >
> > The handhake is failing and I am getting following contents on my BIO
> dump.?
> > "15 03 03 00 02 02 56" .?
> > If i have understood correctly this is for alert message and But I could
> > not find any reference to alert description at (
> > https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )?
> > corresponding to 56.
>
> 56 hex == 86 decimal == inappropriate_fallback
>
> i.e. this doesn't tell you any further information than you have below.
>
> >
> > So, Could you please help me figure out what does this correspond to ??
> >
> > Moreover I have following doubt.?
> >
> > -- If my TLSv1.2 client does not handle the? "downgrade sentinel "
> > present in server hello ( TLSv1.3 , will it create any problem ?
>
> No, this should not be a problem.
>
> > -- In the above example client is receving error such as "SSL Handshake
> > Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
> > alert inappropriate fallback]." ? Could you please help me to hint me
> > about how to debug this ?
>
> What version of OpenSSL are you using for the client?
>
> Is it possible for you to send me a wireshark trace of the failing
> handshake?
>
> In particular I am interested to see if the TLS_FALLBACK_SCSV
> ciphersuite is present in the ClientHello (RFC 7507). The
> TLS_FALLBACK_SCSV is only supposed to be sent if the client has already
> attempted an earlier handshake that failed, and it is now trying a
> downgraded protocol version. So, does the wireshark trace reveal the
> client attempting an initial handshake that is failing for some other
> reason, followed by a second attempt that fails with the inappropriate
> fallback error?
>
>
> Matt
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 22 Oct 2018 10:50:31 -0700
> From: Skip Carter <skip at taygeta.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] What to do with deprecation errors
> Message-ID: <1540230631.4886.20.camel at taygeta.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Yes the macro is there, its just not being expanded by the pre-
> compiler.
>
>
> On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote:
> >
> > On 21/10/2018 20:01, Skip Carter wrote:
> >
> > Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in
> > it?
> >
> > Matt
> --
> Skip Carter
> Taygeta Scientific Inc.
>
>
>
> ------------------------------
>
> 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 47, Issue 35
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181023/07d3d698/attachment-0001.html>

From matt at openssl.org  Tue Oct 23 12:29:27 2018
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Oct 2018 13:29:27 +0100
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <CAHgr=kLammN_hcYkR+OF65VyZLvLmYtxHigtH1nu5VfpZx0zdQ@mail.gmail.com>
References: <mailman.4483.1540230644.21411.openssl-users@openssl.org>
 <CAHgr=kLammN_hcYkR+OF65VyZLvLmYtxHigtH1nu5VfpZx0zdQ@mail.gmail.com>
Message-ID: <f037b5d6-2048-d485-2833-73deacba78f0@openssl.org>



On 23/10/2018 12:32, ramakrushna mishra wrote:
> Hi Matt,
> 
> Thanks for your response.
> ?My client is built with openssl 1.0.0e

1.0.0e is very old and out of support. It should be considered insecure.
You should upgrade this to a more recent version.

>? and server with openssl 1.1.1.?
> ?I have tried to collect information with wireshark, but I think as my
> server and client are running on same machine , it is not capturing
> anything. I have also tried with tshark on linux and got no traces again.?
> 
> I have this trouble both on nt64and linuxx86_64. Do we have any other
> mechanism to capture the traces ?
> 
> We have internal tracing enabled and I can see following information in
> our tracing. 

Ok, the internal tracing is enough to see what is happening.


> **********************************************************************************
> [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL State: 16
> before SSL initialization
> [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000
> BIO? ?--- ctrl to 00000000 [02457660] (6 bytes => 0 (0x0))
> 
> [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000
> BIO? ?--- contents of a BIO dump:
> [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION ---
> SSL_accept:before SSL initialization
> [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000
> BIO? ?--- read to 00000000 [02463953] (5 bytes => 5 (0x5))
> 
> [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000
> BIO? ?--- contents of a BIO dump:
> 0000 - 16 03 01 00 b2? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .....
> [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000
> BIO? ?--- read to 00000000 [02463958] (178 bytes => 178 (0xB2))
> 
> [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000
> BIO? ?--- contents of a BIO dump:
> 0000 - 01 00 00 ae 03 03 10 b1-1e 8f f0 07 d6 28 d9 02? ?.............(..
> 0010 - b7 91 b4 3d 14 5a af 3e-09 96 2a cf ee 8b ca 30? ?...=.Z.>..*....0
> 0020 - cc 68 9f 2c 2e 6e 00 00-62 00 a5 00 a3 00 a1 00? ?.h.,.n..b.......
> 0030 - 9f 00 6b 00 6a 00 69 00-68 00 39 00 38 00 37 00? ?..k.j.i.h.9.8.7.
> 0040 - 36 00 9d 00 3d 00 35 00-a4 00 a2 00 a0 00 9e 00? ?6...=.5.........
> 0050 - 67 00 40 00 3f 00 3e 00-33 00 32 00 31 00 30 00? ?g. at .?.>.3.2.1.0.
> 0060 - 9a 00 99 00 98 00 97 00-9c 00 3c 00 2f 00 96 00? ?..........<./...
> 0070 - 05 00 04 00 16 00 13 00-10 00 0d 00 0a 00 15 00? ?................
> 0080 - 12 00 0f 00 0c 00 09 00-ff *56 00* 01 00 00 23 00? ?.........V....#.
> 0090 - 23 00 00 00 0d 00 16 00-14 06 01 06 02 05 01 05? ?#...............
> 00a0 - 02 04 01 04 02 03 01 03-02 02 01 02 02 00 0f 00? ?................
> 00b0 - 01 01? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?..
> [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION ---
> SSL_accept:before SSL initialization
> [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000
> BIO? ?--- write to 00000000 [024725E0] (7 bytes => 7 (0x7))
> 
> [Mon Oct 22 02:53:58 2018] ID-0x024545f0 CTX-0x02458750 BIO-0x00000000
> BIO? ?--- contents of a BIO dump:
> 0000 - 15 03 03 00 02 02 56? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ......V
> [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION ---? write:fatal:unknown
> [Mon Oct 22 02:53:58 2018] INTERNAL STATE OPERATION --- SSL_accept:error
> in error
> ********************
> In the above dump , "56 00 " is present in the cipher suites sent in
> client hello.?
> So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in
> client hello.?
> However there is no earlier failure to this handshake. 

This suggests there is a bug in the client application. This can only
happen if the client application calls SSL_CTX_set_mode() or
SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.

This is incorrect if there has been no previously failed handshake at a
higher protocol version. From the documentation:

    SSL_MODE_SEND_FALLBACK_SCSV

    Send TLS_FALLBACK_SCSV in the ClientHello.
    To be set only by applications that reconnect with a downgraded
    protocol version; see draft-ietf-tls-downgrade-scsv-00 for details.

    DO NOT ENABLE THIS if your application attempts a normal handshake.
    Only use this in explicit fallback retries, following the guidance
    in draft-ietf-tls-downgrade-scsv-00.

(Note the reference to draft-ietf-tls-downgrade-scsv-00 in the docs
really should be updated to RFC7507 as that document is now known).

> 
> As per your comment, client should only send it if it witnessed some
> earlier failure.?
> In that case, I have following additional doubt.?
> 
> -- this set up is working when server is running with TLSv1.2 and only
> failing when server has both TLSv1,2 and TLSv1.3 ( i.e with
> openssl1.1.1). So are there any changes in openssl1.1.1 which will
> effect this behavior when compared to openssl1.0.0e version ?

The purpose of sending TLS_FALLBACK_SCSV is to signal to the server "I
have attempted to connect to this server with a higher protocol version
than this one, but it failed". If this is unexpected to the server
because the server supports a higher protocol version then the server
assumes that a downgrade attack is taking place and aborts the connection.

Your client is declaring that it is prepared to speak TLSv1.2 ("03 03"
in the dump above) and is also declaring by sending TLS_FALLBACK_SCSV
that it first tried TLSv1.3 but it failed. This is clearly false since
OpenSSL 1.0.0e does not support TLSv1.3. A 1.1.1 server with TLSv1.3
enabled will then correctly abort the connection because it knows this
scenario should not have happened. A 1.1.1 server with TLSv1.3 disabled
should correctly complete the connection. This will not have happened
with any previous versions of OpenSSL because 1.1.1 is the first one to
support TLSv1.3.

Hope that helps,

Matt



> 
> 
> Thanks and Regards,
> Ram Krushna
> 
> 
> On Mon, Oct 22, 2018 at 11:21 PM <openssl-users-request at openssl.org
> <mailto:openssl-users-request at openssl.org>> wrote:
> 
>     Send openssl-users mailing list submissions to
>     ? ? ? ? openssl-users at openssl.org <mailto: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
>     <mailto:openssl-users-request at openssl.org>
> 
>     You can reach the person managing the list at
>     ? ? ? ? openssl-users-owner at openssl.org
>     <mailto: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: What to do with deprecation errors (Salz, Rich)
>     ? ?2. Re: What to do with deprecation errors (Matt Caswell)
>     ? ?3. Re: To disable CBC ciphers (Jakob Bohm)
>     ? ?4. Reg issue in alert message (ramakrushna mishra)
>     ? ?5. Re: Reg issue in alert message (Matt Caswell)
>     ? ?6. Re: What to do with deprecation errors (Skip Carter)
> 
> 
>     ----------------------------------------------------------------------
> 
>     Message: 1
>     Date: Mon, 22 Oct 2018 02:08:23 +0000
>     From: "Salz, Rich" <rsalz at akamai.com <mailto:rsalz at akamai.com>>
>     To: Skip Carter <skip at taygeta.com <mailto:skip at taygeta.com>>,
>     "openssl-users at openssl.org <mailto:openssl-users at openssl.org>"
>     ? ? ? ? <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
>     Subject: Re: [openssl-users] What to do with deprecation errors
>     Message-ID: <8260BB64-B12E-4779-B9DF-903D23E47FD3 at akamai.com
>     <mailto:8260BB64-B12E-4779-B9DF-903D23E47FD3 at akamai.com>>
>     Content-Type: text/plain; charset="utf-8"
> 
>     >? ? DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP
>     *group,?
> 
>     That is "proof" that the pre-processor doesn?t have the right -I
>     flags.? Try running with the -v option or something.
> 
> 
>     ------------------------------
> 
>     Message: 2
>     Date: Mon, 22 Oct 2018 08:55:28 +0100
>     From: Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] What to do with deprecation errors
>     Message-ID: <7513a526-2840-6a4e-cf9a-99666ffc1330 at openssl.org
>     <mailto:7513a526-2840-6a4e-cf9a-99666ffc1330 at openssl.org>>
>     Content-Type: text/plain; charset=utf-8
> 
> 
> 
>     On 21/10/2018 20:01, Skip Carter wrote:
>     > Thats what I originally thought.
>     >
>     > I experimented with manually invoking the pre-compiler (cpp) and this
>     > is what I get:
>     >
>     >
>     > DEPRECATEDIN_1_2_0(int EC_GROUP_get_curve_GF2m(const EC_GROUP
>     *group,?
>     >? ? ? ? ? ? ? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?
>     > BIGNUM *p,
>     > ???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
>     > ???????????????????????????????????????????????BN_CTX *ctx))
>     > the macro is not firing, shouldn't I get:
>     >
>     > extern int EC_GROUP_get_curve_GF2m(const EC_GROUP *group,? ? ? ? ?
>     ? ?
>     >? ? ? ? ??? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? BIGNUM *p,
>     > ???????????????????????????????????????????????BIGNUM *a, BIGNUM *b,
>     > ???
>     > ????????????????????????????????????????????BN_CTX *ctx);
>     >
>     >
>     > On Sun, 2018-10-21 at 18:28 +0000, Salz, Rich via openssl-users wrote:
>     >>> ???And I still have the problem with those macros.
>     >>
>     >> ??
>     >> The problem is almost definitely this:??the files that you are
>     >> compiling (not openssl) are picking up the wrong header files from
>     >> openssl.
>     >>
> 
>     Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in it?
> 
>     Matt
> 
> 
>     ------------------------------
> 
>     Message: 3
>     Date: Mon, 22 Oct 2018 15:34:20 +0200
>     From: Jakob Bohm <jb-openssl at wisemo.com <mailto:jb-openssl at wisemo.com>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] To disable CBC ciphers
>     Message-ID: <d91267e8-4681-9a77-23fa-d790200e2259 at wisemo.com
>     <mailto:d91267e8-4681-9a77-23fa-d790200e2259 at wisemo.com>>
>     Content-Type: text/plain; charset=utf-8; format=flowed
> 
>     On 20/10/2018 15:59, Kaushal Shriyan wrote:
>     >
>     >
>     > On Wed, Oct 17, 2018 at 7:00 PM murugesh pitchaiah
>     > <murugesh.pitchaiah at gmail.com
>     <mailto:murugesh.pitchaiah at gmail.com>
>     <mailto:murugesh.pitchaiah at gmail.com
>     <mailto:murugesh.pitchaiah at gmail.com>>>
>     > wrote:
>     >
>     >? ? ?Hi,
>     >
>     >? ? ?You may list down what ciphers configured : "openssl ciphers"
>     >? ? ?Choose CBC ciphers and add them to the list of 'ssl_ciphers'
>     with "!"
>     >? ? ?prefix appended to current ssl_ciphers.
>     >
>     >? ? ?> ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
>     >
>     >? ? ?Ref:
>     >? ?
>     ?https://serverfault.com/questions/692119/meaning-of-ssl-ciphers-line-on-nginx-conf
>     >
>     >? ? ?Thanks,
>     >? ? ?Murugesh P.
>     >
>     >
>     >? ? ?On 10/17/18, Kaushal Shriyan <kaushalshriyan at gmail.com
>     <mailto:kaushalshriyan at gmail.com>
>     >? ? ?<mailto:kaushalshriyan at gmail.com
>     <mailto:kaushalshriyan at gmail.com>>> wrote:
>     >? ? ?> Hi,
>     >? ? ?>
>     >? ? ?> I have the below ssl settings in nginx.conf file and VAPT test
>     >? ? ?has reported
>     >? ? ?> us to disable CBC ciphers
>     >? ? ?>
>     >? ? ?> ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH;
>     >? ? ?>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
>     >? ? ?>
>     >? ? ?>
>     >? ? ?> openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on
>     >? ? ?CentOS
>     >? ? ?> Linux release 7.3.1611 (Core)
>     >? ? ?>
>     >? ? ?> I will appreciate if someone can pitch in to help me understand
>     >? ? ?to disable
>     >? ? ?> CBC ciphers
>     >? ? ?>
>     >
>     >
>     > Thanks Murugesh. I did checked openssl ciphers
>     > https://www.openssl.org/docs/man1.0.2/apps/ciphers.html and could
>     not see
>     > !AAA_CBC_BBB as mentioned in your email.
>     >
>     >? ? ?ssl_ciphers HIGH:!aNULL:!MD5:!DH+3DES:!kEDH:!AAA_CBC_BBB:
>     >
>     >
>     > Correct me if i am understanding it wrong. Basically i want to
>     disable
>     > Cipher Block Chaining (CBC) mode cipher encryption. Openssl and OS
>     > version are as below :-
>     >
>     >? ? ?openssl version on the box is OpenSSL 1.0.2k-fips 26 Jan 2017 on
>     >? ? ?CentOS
>     >? ? ?Linux release 7.3.1611 (Core)
>     >
>     >
>     > Any tools which i can run to find out vulnerabilities in the above
>     > openssl and OS version? Please guide and i look forward to hearing
>     > from you. Thanks in Advance.
>     You need to replace AAA and BBB with actual strings corresponding to
>     each of the unwanted cipher suites.
> 
>     The advisor that tells you to disable "CBC ciphers" is mostly wrong.
>     There is nothing inherently bad about correctly using ciphers in CBC
>     mode, however some TLS protocol versions happen to use CBC cipher
>     suites in a problematic way, while having no secure non-CBC cipher
>     suites.? More recent TLS versions (such as TLS 1.2) have less
>     problematic (but not perfect) CBC usage and also offers some
>     overhyped US government ciphers such as the AES_GCM family.
> 
>     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
> 
> 
> 
>     ------------------------------
> 
>     Message: 4
>     Date: Mon, 22 Oct 2018 19:26:55 +0530
>     From: ramakrushna mishra <rama.krushna7 at gmail.com
>     <mailto:rama.krushna7 at gmail.com>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: [openssl-users] Reg issue in alert message
>     Message-ID:
>     ? ? ? ?
>     <CAHgr=kJyCXVY9QssB2CO3hY=GsEwiEcvzwQ-Pyd3VKqSm51XLA at mail.gmail.com
>     <mailto:GsEwiEcvzwQ-Pyd3VKqSm51XLA at mail.gmail.com>>
>     Content-Type: text/plain; charset="utf-8"
> 
>     Hi,
> 
>     I am facing an issue after openssl upgrade to 1.1.1.
>     I have a odbc client with maximum version support up to TLSv1.2 and? my
>     database is running with TLSv1.2,TLsv1.3.
> 
>     The handhake is failing and I am getting following contents on my
>     BIO dump.
>     "15 03 03 00 02 02 56" .
>     If i have understood correctly this is for alert message and But I could
>     not find any reference to alert description at (
>     https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )
>     corresponding to 56.
> 
>     So, Could you please help me figure out what does this correspond to ?
> 
>     Moreover I have following doubt.
> 
>     -- If my TLSv1.2 client does not handle the? "downgrade sentinel "
>     present
>     in server hello ( TLSv1.3 , will it create any problem ?
>     -- In the above example client is receving error such as "SSL Handshake
>     Failure reason [error:1407743E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1
>     alert inappropriate fallback]." ? Could you please help me to hint
>     me about
>     how to debug this ?
> 
>     Thanks and Regards,
>     Ram Krushna
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>     URL:
>     <http://mta.openssl.org/pipermail/openssl-users/attachments/20181022/cb04af81/attachment-0001.html>
> 
>     ------------------------------
> 
>     Message: 5
>     Date: Mon, 22 Oct 2018 15:10:55 +0100
>     From: Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] Reg issue in alert message
>     Message-ID: <3c26e4ec-32e4-f3df-c1ae-0ed1cdeb5848 at openssl.org
>     <mailto:3c26e4ec-32e4-f3df-c1ae-0ed1cdeb5848 at openssl.org>>
>     Content-Type: text/plain; charset=utf-8
> 
> 
> 
>     On 22/10/2018 14:56, ramakrushna mishra wrote:
>     > Hi,
>     >
>     > I am facing an issue after openssl upgrade to 1.1.1.?
>     > I have a odbc client with maximum version support up to TLSv1.2
>     and? my
>     > database is running with TLSv1.2,TLsv1.3.?
>     >
>     > The handhake is failing and I am getting following contents on my
>     BIO dump.?
>     > "15 03 03 00 02 02 56" .?
>     > If i have understood correctly this is for alert message and But I
>     could
>     > not find any reference to alert description at (
>     >
>     https://tools.ietf.org/id/draft-ietf-tls-tls13-25.html#alert-protocol )?
>     > corresponding to 56.
> 
>     56 hex == 86 decimal == inappropriate_fallback
> 
>     i.e. this doesn't tell you any further information than you have below.
> 
>     >
>     > So, Could you please help me figure out what does this correspond
>     to ??
>     >
>     > Moreover I have following doubt.?
>     >
>     > -- If my TLSv1.2 client does not handle the? "downgrade sentinel "
>     > present in server hello ( TLSv1.3 , will it create any problem ?
> 
>     No, this should not be a problem.
> 
>     > -- In the above example client is receving error such as "SSL
>     Handshake
>     > Failure reason [error:1407743E:SSL
>     routines:SSL23_GET_SERVER_HELLO:tlsv1
>     > alert inappropriate fallback]." ? Could you please help me to hint me
>     > about how to debug this ?
> 
>     What version of OpenSSL are you using for the client?
> 
>     Is it possible for you to send me a wireshark trace of the failing
>     handshake?
> 
>     In particular I am interested to see if the TLS_FALLBACK_SCSV
>     ciphersuite is present in the ClientHello (RFC 7507). The
>     TLS_FALLBACK_SCSV is only supposed to be sent if the client has already
>     attempted an earlier handshake that failed, and it is now trying a
>     downgraded protocol version. So, does the wireshark trace reveal the
>     client attempting an initial handshake that is failing for some other
>     reason, followed by a second attempt that fails with the inappropriate
>     fallback error?
> 
> 
>     Matt
> 
> 
>     ------------------------------
> 
>     Message: 6
>     Date: Mon, 22 Oct 2018 10:50:31 -0700
>     From: Skip Carter <skip at taygeta.com <mailto:skip at taygeta.com>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] What to do with deprecation errors
>     Message-ID: <1540230631.4886.20.camel at taygeta.com
>     <mailto:1540230631.4886.20.camel at taygeta.com>>
>     Content-Type: text/plain; charset="UTF-8"
> 
>     Yes the macro is there, its just not being expanded by the pre-
>     compiler.
> 
> 
>     On Mon, 2018-10-22 at 08:55 +0100, Matt Caswell wrote:
>     >
>     > On 21/10/2018 20:01, Skip Carter wrote:
>     >
>     > Does your opensslconf.h have the DEPRECATEDIN_1_2_0 macro defined in
>     > it?
>     >
>     > Matt
>     -- 
>     Skip Carter
>     Taygeta Scientific Inc.
> 
> 
> 
>     ------------------------------
> 
>     Subject: Digest Footer
> 
>     _______________________________________________
>     openssl-users mailing list
>     openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
>     ------------------------------
> 
>     End of openssl-users Digest, Vol 47, Issue 35
>     *********************************************
> 
> 

From openssl-users at dukhovni.org  Tue Oct 23 14:01:57 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 23 Oct 2018 10:01:57 -0400
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <f037b5d6-2048-d485-2833-73deacba78f0@openssl.org>
References: <mailman.4483.1540230644.21411.openssl-users@openssl.org>
 <CAHgr=kLammN_hcYkR+OF65VyZLvLmYtxHigtH1nu5VfpZx0zdQ@mail.gmail.com>
 <f037b5d6-2048-d485-2833-73deacba78f0@openssl.org>
Message-ID: <20181023140157.GL983@straasha.imrryr.org>

On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:

> > So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in
> > client hello.
> 
> This suggests there is a bug in the client application. This can only
> happen if the client application calls SSL_CTX_set_mode() or
> SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.

I have a somewhat plausible, if dicey hunch:

    Perhaps some application developers got confused between
    the similar functions SSL_CTX_set_session_cache_mode(3)
    and SSL_CTX_set_mode(3) and called the wrong one?

It just so happens that we have:

    include/openssl/ssl.h:# define SSL_MODE_SEND_FALLBACK_SCSV 0x00000080U
    include/openssl/ssl.h:# define SSL_SESS_CACHE_NO_AUTO_CLEAR            0x0080

which means that someone calling:

    SSL_CTX_set_mode(ctx, SSL_SESS_CACHE_NO_AUTO_CLEAR);

instead of:

    SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_NO_AUTO_CLEAR);

ends up doing exactly the wrong thing.  Of course just as likely
or more, the documentation of SSL_MODE_SEND_FALLBACK_SCSV may have
been misunderstood, despite all the warnings.

-- 
	Viktor.

From richard.oehlinger at adbsafegate.com  Tue Oct 23 14:38:14 2018
From: richard.oehlinger at adbsafegate.com (Richard Oehlinger)
Date: Tue, 23 Oct 2018 14:38:14 +0000
Subject: [openssl-users] CAPI-Engine doc
Message-ID: <a8a1dcc3-7032-b03d-171b-ea541df83213@adbsafegate.com>

Hi!

I'm trying to get a handle on the CAPI engine, because I need to have a 
secure Keystore on Windows. Furthermore I need it to work with Qt's 
QSslKey, which fortunately can be constructed by EVP_PKEY *.

So far so good. The key is found, but when I try to use it in a SSL 
connection i get following error:

error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object, 
error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib

I use a current Windows 10. Do I need to use a different Algorithm in 
order to work? Some googeling is indicating the provider might be wrong.


Regards,

Richard



I juse following code to load the key:

     ENGINE *engine = ENGINE_by_id("dynamic");
     assert(engine);
     ENGINE_ctrl_cmd_string(engine, "SO_PATH", "./capi.dll", 0);
     ENGINE_ctrl_cmd_string(engine, "LOAD", NULL, 0);

     assert(ENGINE_init(engine));
     assert(ENGINE_register_complete(engine));

     ERR_load_ENGINE_strings();

     assert(ENGINE_cmd_is_executable(engine, CAPI_CMD_DEBUG_LEVEL));
     assert(ENGINE_ctrl(engine, CAPI_CMD_DEBUG_LEVEL, 2, nullptr, nullptr));
     assert(ENGINE_ctrl(engine, CAPI_CMD_DEBUG_FILE, 0, 
(void*)"C:\\Users\\user\\AppData\\Local\\Temp\\engine.txt", 0));
     EVP_PKEY *key = ENGINE_load_private_key(engine, "localhost", NULL, 
NULL);
     if (!key)
     {
         cerr << "key is null";
         return {};
     }
     QSslKey ssl_key(static_cast<Qt::HANDLE>(key));

Trace Output is:

Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
Opening certificate store MY
capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C}, 
provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
Called CAPI_rsa_sign()



From selva.nair at gmail.com  Tue Oct 23 15:22:04 2018
From: selva.nair at gmail.com (Selva Nair)
Date: Tue, 23 Oct 2018 11:22:04 -0400
Subject: [openssl-users] CAPI-Engine doc
In-Reply-To: <a8a1dcc3-7032-b03d-171b-ea541df83213@adbsafegate.com>
References: <a8a1dcc3-7032-b03d-171b-ea541df83213@adbsafegate.com>
Message-ID: <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw@mail.gmail.com>

On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
<openssl-users at openssl.org> wrote:
>
> Hi!
>
> I'm trying to get a handle on the CAPI engine, because I need to have a
> secure Keystore on Windows. Furthermore I need it to work with Qt's
> QSslKey, which fortunately can be constructed by EVP_PKEY *.
>
> So far so good. The key is found, but when I try to use it in a SSL
> connection i get following error:
>
> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib

Which version of OpenSSL?

> Trace Output is:
>
> Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
> Opening certificate store MY
> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
> Called CAPI_rsa_sign()

This CSP cannot do SHA2 hashes so won't work unless you restrict
signature algorithms or set TLS version to 1.1. I believe OpenSSL
1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
can handle SHA2 and may work. I say "may" because, if the key store is
a legacy hardware token, it also depends on signature algorithms supported
by the token and may be necessary to downgrade to TLS 1.1.

Selva

From Michael.Wojcik at microfocus.com  Tue Oct 23 15:37:24 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 23 Oct 2018 15:37:24 +0000
Subject: [openssl-users] CAPI-Engine doc
In-Reply-To: <a8a1dcc3-7032-b03d-171b-ea541df83213@adbsafegate.com>
References: <a8a1dcc3-7032-b03d-171b-ea541df83213@adbsafegate.com>
Message-ID: <DM5PR18MB1324455050CC00BD3A2DD70FF9F50@DM5PR18MB1324.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Richard Oehlinger via openssl-users
> Sent: Tuesday, October 23, 2018 10:38
>
> I'm trying to get a handle on the CAPI engine, because I need to have a
> secure Keystore on Windows. Furthermore I need it to work with Qt's
> QSslKey, which fortunately can be constructed by EVP_PKEY *.

What OpenSSL version are you using? Please remember to include this informtion in every question. (And, normally, we'd ask for the platform as well, but since CAPI is Windows-specific, we know that in this case.)

> So far so good. The key is found, but when I try to use it in a SSL
> connection i get following error:
>
> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
>
> I use a current Windows 10. Do I need to use a different Algorithm in
> order to work? Some googeling is indicating the provider might be wrong.

I haven't looked at the CAPI engine code since 1.0.1j. At that time, I needed CAPI support and discovered there were various issues with the extant CAPI code, so I forked and rewrote it. That was some time back, obviously, and I'm afraid I never got around to pushing the changes back to openssl.org. (In fact, it was sufficiently long ago that I believe the organization was still reluctant to take contributions from people in the US at the time.)

The biggest issue was with provider handling. CAPI is something of a braindead API in many ways - Microsoft's replacement, CNG, is somewhat better - and the provider stuff is one of them. When a key (including a "key" which is actually just a reference to a key contained in an HSM) is imported into one of the Windows key stores, it has to be associated with a provider, and that provider has to accommodate that type and size of key; otherwise the key is unusable. Then, when you try to use the key in CAPI, you have to specify the same provider - CAPI isn't smart enough to figure it out on its own.

So my version of the CAPI engine has code to look up the key's provider and silently correct the provider type information in the engine's context structure if it's a mismatch.

Beyond that, it appears that my changes included:

- Support for building all the necessary functionality when using Microsoft Windows SDK 6.0A, which was one of my requirements at the time.

- Supporting hashes other than SHA-1 for DSA. We have US Federal customers who needed fairly comprehensive DSA support. For most people this is likely a non-issue.

- Forcing stack probes on for the callback functions, because my engine was being built outside the OpenSSL build process, but needed to match the calling convention of OpenSSL, which (at least in 1.0.1j) included stack-probe support.

- A fix suggested by Steven Henson years ago on the mailing list to capi_get_key, but never (at least by 1.0.1j) picked up in the source code: If CryptGetUserKey returns NTE_NO_KEY, xor keyspec with 3 to flip the key type and try CryptGetUesrKey again.

I think that's it, though it's possible I tweaked some other things and didn't call them out in the comments.

I suppose I should check what the CAPI engine source looks like in 1.1.1, merge my changes in if feasible, and submit a PR. One of these days...

Really, though, what we need is a new engine written to use CNG rather than CAPI. Though that would have the disadvantage of not supporting ancient Windows OS and SDK versions which, while unsupported by Microsoft, are still used in far too many places.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From Michael.Wojcik at microfocus.com  Tue Oct 23 15:37:25 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 23 Oct 2018 15:37:25 +0000
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <20181023140157.GL983@straasha.imrryr.org>
References: <mailman.4483.1540230644.21411.openssl-users@openssl.org>
 <CAHgr=kLammN_hcYkR+OF65VyZLvLmYtxHigtH1nu5VfpZx0zdQ@mail.gmail.com>
 <f037b5d6-2048-d485-2833-73deacba78f0@openssl.org>
 <20181023140157.GL983@straasha.imrryr.org>
Message-ID: <DM5PR18MB13246F528FB866508D8E9267F9F50@DM5PR18MB1324.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Tuesday, October 23, 2018 10:02
>
> On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:
>
> > > So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in
> > > client hello.
> >
> > This suggests there is a bug in the client application. This can only
> > happen if the client application calls SSL_CTX_set_mode() or
> > SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.
>
> I have a somewhat plausible, if dicey hunch:
>
>     Perhaps some application developers got confused between
>     the similar functions SSL_CTX_set_session_cache_mode(3)
>     and SSL_CTX_set_mode(3) and called the wrong one?

Certainly possible, but I wouldn't discount the possibility that someone simply thought setting SSL_MODE_SEND_FALLBACK_SCSV was the Right Thing. There was a fair bit of confusion around the Fallback SCSV when it first appeared (we had questions from customers that indicated they didn't understand it, and I had to read the ID to make sure I did). And, of course, TLS is mightly confusing in general.

It is interesting to note that those two options happen to have the same value, though, particularly given the similarity of the two function names.

This is one of those cases where C's weak type system is a problem. Though it would be nice if OpenSSL used enums rather than macros for these things.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From jb-openssl at wisemo.com  Tue Oct 23 15:42:56 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 23 Oct 2018 17:42:56 +0200
Subject: [openssl-users] CAPI-Engine doc
In-Reply-To: <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw@mail.gmail.com>
References: <a8a1dcc3-7032-b03d-171b-ea541df83213@adbsafegate.com>
 <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw@mail.gmail.com>
Message-ID: <fc161e84-bf5f-f61b-0f1d-3bfa5641edd8@wisemo.com>

On 23/10/2018 17:22, Selva Nair wrote:
> On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
> <openssl-users at openssl.org> wrote:
>> Hi!
>>
>> I'm trying to get a handle on the CAPI engine, because I need to have a
>> secure Keystore on Windows. Furthermore I need it to work with Qt's
>> QSslKey, which fortunately can be constructed by EVP_PKEY *.
>>
>> So far so good. The key is found, but when I try to use it in a SSL
>> connection i get following error:
>>
>> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
>> error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> Which version of OpenSSL?
>
>> Trace Output is:
>>
>> Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
>> Opening certificate store MY
>> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
>> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
>> Called CAPI_rsa_sign()
> This CSP cannot do SHA2 hashes so won't work unless you restrict
> signature algorithms or set TLS version to 1.1. I believe OpenSSL
> 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
> can handle SHA2 and may work. I say "may" because, if the key store is
> a legacy hardware token, it also depends on signature algorithms supported
> by the token and may be necessary to downgrade to TLS 1.1.
>
The above limitations are less severe in CNG ("CryptoAPI Next Generation")
on Windows 6.00 and later, where the old API and CSP names are actually
emulations on top of a new structure with much smaller "KSP" providers.
At the same time, the CNG emulation of the classic CryptoAPI functions
are limited to what was available in Windows 5.01 SP2 and 5.02 SP2, thus
much of the SHA-2 functionality is available only by calling the CNG
APIs directly on Windows >= 6.00, but the older APIs with a reference
to newer enum values introduced in Windows 5.01 SP3 or 5.02 SP2+Hotfix.

Put another way, Microsoft forked their crypto source tree sometime in
2004 or 2005, and anything added later was implemented differently in
the 5.0x and 6.0x code bases.

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 best.sakthi3 at gmail.com  Wed Oct 24 06:16:13 2018
From: best.sakthi3 at gmail.com (sakdev)
Date: Tue, 23 Oct 2018 23:16:13 -0700 (MST)
Subject: [openssl-users] Openssl Build Error- module unsafe for SAFESEH
 image/Unable to generate SAFESEH image
In-Reply-To: <66e4b883-7e88-4b6f-f112-a2dc5672d06d@wisemo.com>
References: <1539857322075-0.post@n7.nabble.com>
 <MWHPR18MB10379CEEC5942DC92167E360F9F80@MWHPR18MB1037.namprd18.prod.outlook.com>
 <1539866078628-0.post@n7.nabble.com>
 <66e4b883-7e88-4b6f-f112-a2dc5672d06d@wisemo.com>
Message-ID: <1540361773425-0.post@n7.nabble.com>

Added "/safeseh" in assembler flags and problem got solved. Thank you very
much.



--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

From rama.krushna7 at gmail.com  Wed Oct 24 12:25:55 2018
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Wed, 24 Oct 2018 17:55:55 +0530
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <mailman.4601.1540361783.21411.openssl-users@openssl.org>
References: <mailman.4601.1540361783.21411.openssl-users@openssl.org>
Message-ID: <CAHgr=kJxp_7mj_G6noOD1cgmEPv2fjC4DztzDaPA_kfniYhaUQ@mail.gmail.com>

Hi All,

Thank you for all for providing the information.
I suspect we are using " SSL_MODE_SEND_FALLBACK_SCSV  " and that might be
causing the issue.  The team is looking into this issue now with the
provided information.

 One doubt that came during  our investigation is :
" If client has highest version of TLS1.3 and server has support for TLS1.2
and SLV3 only.   How the handshake will  proceed ? "
I am not sure if this question should go to a new thread ?

Thanks and Regards,
Ram Krushna

On Wed, Oct 24, 2018 at 11:47 AM <openssl-users-request at openssl.org> wrote:

> 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: CAPI-Engine doc (Selva Nair)
>    2. Re: CAPI-Engine doc (Michael Wojcik)
>    3. Re: Reg issue in alert message (Michael Wojcik)
>    4. Re: CAPI-Engine doc (Jakob Bohm)
>    5. Re: Openssl Build Error- module unsafe for SAFESEH
>       image/Unable to generate SAFESEH image (sakdev)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 23 Oct 2018 11:22:04 -0400
> From: Selva Nair <selva.nair at gmail.com>
> To: richard.oehlinger at adbsafegate.com, openssl-users at openssl.org
> Subject: Re: [openssl-users] CAPI-Engine doc
> Message-ID:
>         <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=
> vfg_NTzAJsQj+D3Jw at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
> <openssl-users at openssl.org> wrote:
> >
> > Hi!
> >
> > I'm trying to get a handle on the CAPI engine, because I need to have a
> > secure Keystore on Windows. Furthermore I need it to work with Qt's
> > QSslKey, which fortunately can be constructed by EVP_PKEY *.
> >
> > So far so good. The key is found, but when I try to use it in a SSL
> > connection i get following error:
> >
> > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> > error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
>
> Which version of OpenSSL?
>
> > Trace Output is:
> >
> > Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
> > Opening certificate store MY
> > capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
> > provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
> > Called CAPI_rsa_sign()
>
> This CSP cannot do SHA2 hashes so won't work unless you restrict
> signature algorithms or set TLS version to 1.1. I believe OpenSSL
> 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
> can handle SHA2 and may work. I say "may" because, if the key store is
> a legacy hardware token, it also depends on signature algorithms supported
> by the token and may be necessary to downgrade to TLS 1.1.
>
> Selva
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 23 Oct 2018 15:37:24 +0000
> From: Michael Wojcik <Michael.Wojcik at microfocus.com>
> To: "openssl-users at openssl.org" <openssl-users at openssl.org>
> Subject: Re: [openssl-users] CAPI-Engine doc
> Message-ID:
>         <
> DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="Windows-1252"
>
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> > Of Richard Oehlinger via openssl-users
> > Sent: Tuesday, October 23, 2018 10:38
> >
> > I'm trying to get a handle on the CAPI engine, because I need to have a
> > secure Keystore on Windows. Furthermore I need it to work with Qt's
> > QSslKey, which fortunately can be constructed by EVP_PKEY *.
>
> What OpenSSL version are you using? Please remember to include this
> informtion in every question. (And, normally, we'd ask for the platform as
> well, but since CAPI is Windows-specific, we know that in this case.)
>
> > So far so good. The key is found, but when I try to use it in a SSL
> > connection i get following error:
> >
> > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> > error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> >
> > I use a current Windows 10. Do I need to use a different Algorithm in
> > order to work? Some googeling is indicating the provider might be wrong.
>
> I haven't looked at the CAPI engine code since 1.0.1j. At that time, I
> needed CAPI support and discovered there were various issues with the
> extant CAPI code, so I forked and rewrote it. That was some time back,
> obviously, and I'm afraid I never got around to pushing the changes back to
> openssl.org. (In fact, it was sufficiently long ago that I believe the
> organization was still reluctant to take contributions from people in the
> US at the time.)
>
> The biggest issue was with provider handling. CAPI is something of a
> braindead API in many ways - Microsoft's replacement, CNG, is somewhat
> better - and the provider stuff is one of them. When a key (including a
> "key" which is actually just a reference to a key contained in an HSM) is
> imported into one of the Windows key stores, it has to be associated with a
> provider, and that provider has to accommodate that type and size of key;
> otherwise the key is unusable. Then, when you try to use the key in CAPI,
> you have to specify the same provider - CAPI isn't smart enough to figure
> it out on its own.
>
> So my version of the CAPI engine has code to look up the key's provider
> and silently correct the provider type information in the engine's context
> structure if it's a mismatch.
>
> Beyond that, it appears that my changes included:
>
> - Support for building all the necessary functionality when using
> Microsoft Windows SDK 6.0A, which was one of my requirements at the time.
>
> - Supporting hashes other than SHA-1 for DSA. We have US Federal customers
> who needed fairly comprehensive DSA support. For most people this is likely
> a non-issue.
>
> - Forcing stack probes on for the callback functions, because my engine
> was being built outside the OpenSSL build process, but needed to match the
> calling convention of OpenSSL, which (at least in 1.0.1j) included
> stack-probe support.
>
> - A fix suggested by Steven Henson years ago on the mailing list to
> capi_get_key, but never (at least by 1.0.1j) picked up in the source code:
> If CryptGetUserKey returns NTE_NO_KEY, xor keyspec with 3 to flip the key
> type and try CryptGetUesrKey again.
>
> I think that's it, though it's possible I tweaked some other things and
> didn't call them out in the comments.
>
> I suppose I should check what the CAPI engine source looks like in 1.1.1,
> merge my changes in if feasible, and submit a PR. One of these days...
>
> Really, though, what we need is a new engine written to use CNG rather
> than CAPI. Though that would have the disadvantage of not supporting
> ancient Windows OS and SDK versions which, while unsupported by Microsoft,
> are still used in far too many places.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 23 Oct 2018 15:37:25 +0000
> From: Michael Wojcik <Michael.Wojcik at microfocus.com>
> To: "openssl-users at openssl.org" <openssl-users at openssl.org>
> Subject: Re: [openssl-users] Reg issue in alert message
> Message-ID:
>         <
> DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
> >
>
> Content-Type: text/plain; charset="Windows-1252"
>
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> > Of Viktor Dukhovni
> > Sent: Tuesday, October 23, 2018 10:02
> >
> > On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:
> >
> > > > So, I think client have set TLS_FALLBACK_SCSV in cipher suite list in
> > > > client hello.
> > >
> > > This suggests there is a bug in the client application. This can only
> > > happen if the client application calls SSL_CTX_set_mode() or
> > > SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.
> >
> > I have a somewhat plausible, if dicey hunch:
> >
> >     Perhaps some application developers got confused between
> >     the similar functions SSL_CTX_set_session_cache_mode(3)
> >     and SSL_CTX_set_mode(3) and called the wrong one?
>
> Certainly possible, but I wouldn't discount the possibility that someone
> simply thought setting SSL_MODE_SEND_FALLBACK_SCSV was the Right Thing.
> There was a fair bit of confusion around the Fallback SCSV when it first
> appeared (we had questions from customers that indicated they didn't
> understand it, and I had to read the ID to make sure I did). And, of
> course, TLS is mightly confusing in general.
>
> It is interesting to note that those two options happen to have the same
> value, though, particularly given the similarity of the two function names.
>
> This is one of those cases where C's weak type system is a problem. Though
> it would be nice if OpenSSL used enums rather than macros for these things.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 23 Oct 2018 17:42:56 +0200
> From: Jakob Bohm <jb-openssl at wisemo.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] CAPI-Engine doc
> Message-ID: <fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 23/10/2018 17:22, Selva Nair wrote:
> > On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
> > <openssl-users at openssl.org> wrote:
> >> Hi!
> >>
> >> I'm trying to get a handle on the CAPI engine, because I need to have a
> >> secure Keystore on Windows. Furthermore I need it to work with Qt's
> >> QSslKey, which fortunately can be constructed by EVP_PKEY *.
> >>
> >> So far so good. The key is found, but when I try to use it in a SSL
> >> connection i get following error:
> >>
> >> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> >> error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> > Which version of OpenSSL?
> >
> >> Trace Output is:
> >>
> >> Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
> >> Opening certificate store MY
> >> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
> >> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
> >> Called CAPI_rsa_sign()
> > This CSP cannot do SHA2 hashes so won't work unless you restrict
> > signature algorithms or set TLS version to 1.1. I believe OpenSSL
> > 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
> > can handle SHA2 and may work. I say "may" because, if the key store is
> > a legacy hardware token, it also depends on signature algorithms
> supported
> > by the token and may be necessary to downgrade to TLS 1.1.
> >
> The above limitations are less severe in CNG ("CryptoAPI Next Generation")
> on Windows 6.00 and later, where the old API and CSP names are actually
> emulations on top of a new structure with much smaller "KSP" providers.
> At the same time, the CNG emulation of the classic CryptoAPI functions
> are limited to what was available in Windows 5.01 SP2 and 5.02 SP2, thus
> much of the SHA-2 functionality is available only by calling the CNG
> APIs directly on Windows >= 6.00, but the older APIs with a reference
> to newer enum values introduced in Windows 5.01 SP3 or 5.02 SP2+Hotfix.
>
> Put another way, Microsoft forked their crypto source tree sometime in
> 2004 or 2005, and anything added later was implemented differently in
> the 5.0x and 6.0x code bases.
>
> 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
>
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 23 Oct 2018 23:16:13 -0700 (MST)
> From: sakdev <best.sakthi3 at gmail.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Openssl Build Error- module unsafe for
>         SAFESEH image/Unable to generate SAFESEH image
> Message-ID: <1540361773425-0.post at n7.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Added "/safeseh" in assembler flags and problem got solved. Thank you very
> much.
>
>
>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.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 47, Issue 45
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181024/fe32d429/attachment-0001.html>

From matt at openssl.org  Wed Oct 24 12:57:04 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Oct 2018 13:57:04 +0100
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <CAHgr=kJxp_7mj_G6noOD1cgmEPv2fjC4DztzDaPA_kfniYhaUQ@mail.gmail.com>
References: <mailman.4601.1540361783.21411.openssl-users@openssl.org>
 <CAHgr=kJxp_7mj_G6noOD1cgmEPv2fjC4DztzDaPA_kfniYhaUQ@mail.gmail.com>
Message-ID: <eb5d58cb-e8b8-fc6b-5992-a25e83e8d2e6@openssl.org>



On 24/10/2018 13:25, ramakrushna mishra wrote:
> Hi All,
> 
> Thank you for all for providing the information.
> I suspect we are using " SSL_MODE_SEND_FALLBACK_SCSV??" and that might
> be causing the issue.? The team is looking into this issue now with the
> provided information.?
> 
> ?One doubt that came during? our investigation is :
> " If client has highest version of TLS1.3 and server has support for
> TLS1.2 and SLV3 only.? ?How the handshake will? proceed ? " 

The protocol will negotiate the highest commonly supported protocol
version. So if the server supports TLS1.3 and the client only supports
TLS1.2 then TLS1.2 will be used. Don't use SSLv3. That is disabled by
default in current OpenSSL versions.

Matt

> I am not sure if this question should go to a new thread ?
> 
> Thanks and Regards,
> Ram Krushna
> 
> On Wed, Oct 24, 2018 at 11:47 AM <openssl-users-request at openssl.org
> <mailto:openssl-users-request at openssl.org>> wrote:
> 
>     Send openssl-users mailing list submissions to
>     ? ? ? ? openssl-users at openssl.org <mailto: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
>     <mailto:openssl-users-request at openssl.org>
> 
>     You can reach the person managing the list at
>     ? ? ? ? openssl-users-owner at openssl.org
>     <mailto: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: CAPI-Engine doc (Selva Nair)
>     ? ?2. Re: CAPI-Engine doc (Michael Wojcik)
>     ? ?3. Re: Reg issue in alert message (Michael Wojcik)
>     ? ?4. Re: CAPI-Engine doc (Jakob Bohm)
>     ? ?5. Re: Openssl Build Error- module unsafe for SAFESEH
>     ? ? ? image/Unable to generate SAFESEH image (sakdev)
> 
> 
>     ----------------------------------------------------------------------
> 
>     Message: 1
>     Date: Tue, 23 Oct 2018 11:22:04 -0400
>     From: Selva Nair <selva.nair at gmail.com <mailto:selva.nair at gmail.com>>
>     To: richard.oehlinger at adbsafegate.com
>     <mailto:richard.oehlinger at adbsafegate.com>,
>     openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] CAPI-Engine doc
>     Message-ID:
>     ? ? ? ?
>     <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw at mail.gmail.com
>     <mailto:vfg_NTzAJsQj%2BD3Jw at mail.gmail.com>>
>     Content-Type: text/plain; charset="UTF-8"
> 
>     On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
>     <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>     >
>     > Hi!
>     >
>     > I'm trying to get a handle on the CAPI engine, because I need to
>     have a
>     > secure Keystore on Windows. Furthermore I need it to work with Qt's
>     > QSslKey, which fortunately can be constructed by EVP_PKEY *.
>     >
>     > So far so good. The key is found, but when I try to use it in a SSL
>     > connection i get following error:
>     >
>     > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
>     > error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> 
>     Which version of OpenSSL?
> 
>     > Trace Output is:
>     >
>     > Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
>     > Opening certificate store MY
>     > capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
>     > provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
>     > Called CAPI_rsa_sign()
> 
>     This CSP cannot do SHA2 hashes so won't work unless you restrict
>     signature algorithms or set TLS version to 1.1. I believe OpenSSL
>     1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
>     can handle SHA2 and may work. I say "may" because, if the key store is
>     a legacy hardware token, it also depends on signature algorithms
>     supported
>     by the token and may be necessary to downgrade to TLS 1.1.
> 
>     Selva
> 
> 
>     ------------------------------
> 
>     Message: 2
>     Date: Tue, 23 Oct 2018 15:37:24 +0000
>     From: Michael Wojcik <Michael.Wojcik at microfocus.com
>     <mailto:Michael.Wojcik at microfocus.com>>
>     To: "openssl-users at openssl.org <mailto:openssl-users at openssl.org>"
>     <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
>     Subject: Re: [openssl-users] CAPI-Engine doc
>     Message-ID:
>     ? ? ? ?
>     <DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
>     <mailto:DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com>>
> 
>     Content-Type: text/plain; charset="Windows-1252"
> 
>     > From: openssl-users [mailto:openssl-users-bounces at openssl.org
>     <mailto:openssl-users-bounces at openssl.org>] On Behalf
>     > Of Richard Oehlinger via openssl-users
>     > Sent: Tuesday, October 23, 2018 10:38
>     >
>     > I'm trying to get a handle on the CAPI engine, because I need to
>     have a
>     > secure Keystore on Windows. Furthermore I need it to work with Qt's
>     > QSslKey, which fortunately can be constructed by EVP_PKEY *.
> 
>     What OpenSSL version are you using? Please remember to include this
>     informtion in every question. (And, normally, we'd ask for the
>     platform as well, but since CAPI is Windows-specific, we know that
>     in this case.)
> 
>     > So far so good. The key is found, but when I try to use it in a SSL
>     > connection i get following error:
>     >
>     > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
>     > error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
>     >
>     > I use a current Windows 10. Do I need to use a different Algorithm in
>     > order to work? Some googeling is indicating the provider might be
>     wrong.
> 
>     I haven't looked at the CAPI engine code since 1.0.1j. At that time,
>     I needed CAPI support and discovered there were various issues with
>     the extant CAPI code, so I forked and rewrote it. That was some time
>     back, obviously, and I'm afraid I never got around to pushing the
>     changes back to openssl.org <http://openssl.org>. (In fact, it was
>     sufficiently long ago that I believe the organization was still
>     reluctant to take contributions from people in the US at the time.)
> 
>     The biggest issue was with provider handling. CAPI is something of a
>     braindead API in many ways - Microsoft's replacement, CNG, is
>     somewhat better - and the provider stuff is one of them. When a key
>     (including a "key" which is actually just a reference to a key
>     contained in an HSM) is imported into one of the Windows key stores,
>     it has to be associated with a provider, and that provider has to
>     accommodate that type and size of key; otherwise the key is
>     unusable. Then, when you try to use the key in CAPI, you have to
>     specify the same provider - CAPI isn't smart enough to figure it out
>     on its own.
> 
>     So my version of the CAPI engine has code to look up the key's
>     provider and silently correct the provider type information in the
>     engine's context structure if it's a mismatch.
> 
>     Beyond that, it appears that my changes included:
> 
>     - Support for building all the necessary functionality when using
>     Microsoft Windows SDK 6.0A, which was one of my requirements at the
>     time.
> 
>     - Supporting hashes other than SHA-1 for DSA. We have US Federal
>     customers who needed fairly comprehensive DSA support. For most
>     people this is likely a non-issue.
> 
>     - Forcing stack probes on for the callback functions, because my
>     engine was being built outside the OpenSSL build process, but needed
>     to match the calling convention of OpenSSL, which (at least in
>     1.0.1j) included stack-probe support.
> 
>     - A fix suggested by Steven Henson years ago on the mailing list to
>     capi_get_key, but never (at least by 1.0.1j) picked up in the source
>     code: If CryptGetUserKey returns NTE_NO_KEY, xor keyspec with 3 to
>     flip the key type and try CryptGetUesrKey again.
> 
>     I think that's it, though it's possible I tweaked some other things
>     and didn't call them out in the comments.
> 
>     I suppose I should check what the CAPI engine source looks like in
>     1.1.1, merge my changes in if feasible, and submit a PR. One of
>     these days...
> 
>     Really, though, what we need is a new engine written to use CNG
>     rather than CAPI. Though that would have the disadvantage of not
>     supporting ancient Windows OS and SDK versions which, while
>     unsupported by Microsoft, are still used in far too many places.
> 
>     --
>     Michael Wojcik
>     Distinguished Engineer, Micro Focus
> 
> 
> 
> 
>     ------------------------------
> 
>     Message: 3
>     Date: Tue, 23 Oct 2018 15:37:25 +0000
>     From: Michael Wojcik <Michael.Wojcik at microfocus.com
>     <mailto:Michael.Wojcik at microfocus.com>>
>     To: "openssl-users at openssl.org <mailto:openssl-users at openssl.org>"
>     <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
>     Subject: Re: [openssl-users] Reg issue in alert message
>     Message-ID:
>     ? ? ? ?
>     <DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
>     <mailto:DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com>>
> 
>     Content-Type: text/plain; charset="Windows-1252"
> 
>     > From: openssl-users [mailto:openssl-users-bounces at openssl.org
>     <mailto:openssl-users-bounces at openssl.org>] On Behalf
>     > Of Viktor Dukhovni
>     > Sent: Tuesday, October 23, 2018 10:02
>     >
>     > On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:
>     >
>     > > > So, I think client have set TLS_FALLBACK_SCSV in cipher suite
>     list in
>     > > > client hello.
>     > >
>     > > This suggests there is a bug in the client application. This can
>     only
>     > > happen if the client application calls SSL_CTX_set_mode() or
>     > > SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.
>     >
>     > I have a somewhat plausible, if dicey hunch:
>     >
>     >? ? ?Perhaps some application developers got confused between
>     >? ? ?the similar functions SSL_CTX_set_session_cache_mode(3)
>     >? ? ?and SSL_CTX_set_mode(3) and called the wrong one?
> 
>     Certainly possible, but I wouldn't discount the possibility that
>     someone simply thought setting SSL_MODE_SEND_FALLBACK_SCSV was the
>     Right Thing. There was a fair bit of confusion around the Fallback
>     SCSV when it first appeared (we had questions from customers that
>     indicated they didn't understand it, and I had to read the ID to
>     make sure I did). And, of course, TLS is mightly confusing in general.
> 
>     It is interesting to note that those two options happen to have the
>     same value, though, particularly given the similarity of the two
>     function names.
> 
>     This is one of those cases where C's weak type system is a problem.
>     Though it would be nice if OpenSSL used enums rather than macros for
>     these things.
> 
>     --
>     Michael Wojcik
>     Distinguished Engineer, Micro Focus
> 
> 
> 
> 
> 
>     ------------------------------
> 
>     Message: 4
>     Date: Tue, 23 Oct 2018 17:42:56 +0200
>     From: Jakob Bohm <jb-openssl at wisemo.com <mailto:jb-openssl at wisemo.com>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] CAPI-Engine doc
>     Message-ID: <fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com
>     <mailto:fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com>>
>     Content-Type: text/plain; charset=utf-8; format=flowed
> 
>     On 23/10/2018 17:22, Selva Nair wrote:
>     > On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
>     > <openssl-users at openssl.org <mailto:openssl-users at openssl.org>> wrote:
>     >> Hi!
>     >>
>     >> I'm trying to get a handle on the CAPI engine, because I need to
>     have a
>     >> secure Keystore on Windows. Furthermore I need it to work with Qt's
>     >> QSslKey, which fortunately can be constructed by EVP_PKEY *.
>     >>
>     >> So far so good. The key is found, but when I try to use it in a SSL
>     >> connection i get following error:
>     >>
>     >> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
>     >> error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
>     > Which version of OpenSSL?
>     >
>     >> Trace Output is:
>     >>
>     >> Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
>     >> Opening certificate store MY
>     >> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
>     >> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
>     >> Called CAPI_rsa_sign()
>     > This CSP cannot do SHA2 hashes so won't work unless you restrict
>     > signature algorithms or set TLS version to 1.1. I believe OpenSSL
>     > 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
>     > can handle SHA2 and may work. I say "may" because, if the key store is
>     > a legacy hardware token, it also depends on signature algorithms
>     supported
>     > by the token and may be necessary to downgrade to TLS 1.1.
>     >
>     The above limitations are less severe in CNG ("CryptoAPI Next
>     Generation")
>     on Windows 6.00 and later, where the old API and CSP names are actually
>     emulations on top of a new structure with much smaller "KSP" providers.
>     At the same time, the CNG emulation of the classic CryptoAPI functions
>     are limited to what was available in Windows 5.01 SP2 and 5.02 SP2, thus
>     much of the SHA-2 functionality is available only by calling the CNG
>     APIs directly on Windows >= 6.00, but the older APIs with a reference
>     to newer enum values introduced in Windows 5.01 SP3 or 5.02 SP2+Hotfix.
> 
>     Put another way, Microsoft forked their crypto source tree sometime in
>     2004 or 2005, and anything added later was implemented differently in
>     the 5.0x and 6.0x code bases.
> 
>     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
> 
> 
> 
>     ------------------------------
> 
>     Message: 5
>     Date: Tue, 23 Oct 2018 23:16:13 -0700 (MST)
>     From: sakdev <best.sakthi3 at gmail.com <mailto:best.sakthi3 at gmail.com>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] Openssl Build Error- module unsafe for
>     ? ? ? ? SAFESEH image/Unable to generate SAFESEH image
>     Message-ID: <1540361773425-0.post at n7.nabble.com
>     <mailto:1540361773425-0.post at n7.nabble.com>>
>     Content-Type: text/plain; charset=us-ascii
> 
>     Added "/safeseh" in assembler flags and problem got solved. Thank
>     you very
>     much.
> 
> 
> 
>     --
>     Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
> 
> 
>     ------------------------------
> 
>     Subject: Digest Footer
> 
>     _______________________________________________
>     openssl-users mailing list
>     openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
>     ------------------------------
> 
>     End of openssl-users Digest, Vol 47, Issue 45
>     *********************************************
> 
> 

From takahashi.akira.58s at kyoto-u.jp  Wed Oct 24 14:55:23 2018
From: takahashi.akira.58s at kyoto-u.jp (Akira Takahashi)
Date: Wed, 24 Oct 2018 23:55:23 +0900
Subject: [openssl-users] Using SM2 ECIES in 1.1.1
Message-ID: <f4163a25-e9b6-f60b-b3ea-8aadf2c190fe@kyoto-u.jp>

Hi all,


Since the version 1.1.1 supports the SM2 public key cryptography suite I am 
trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over different 
standardized prime curves i.e. not just sm2p256v1.

Is there CLI or minimal code snippet to achieve it via the EVP interface?

The current man page of SM2 seems to only describe SM2 as a signature algorithm, 
but not as a public key encryption.


Thank you in advance for your help!

Akira




From matt at openssl.org  Wed Oct 24 15:14:47 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 24 Oct 2018 16:14:47 +0100
Subject: [openssl-users] Using SM2 ECIES in 1.1.1
In-Reply-To: <f4163a25-e9b6-f60b-b3ea-8aadf2c190fe@kyoto-u.jp>
References: <f4163a25-e9b6-f60b-b3ea-8aadf2c190fe@kyoto-u.jp>
Message-ID: <92097423-88c0-5a7d-9395-a84195b257d6@openssl.org>



On 24/10/2018 15:55, Akira Takahashi wrote:
> Hi all,
> 
> 
> Since the version 1.1.1 supports the SM2 public key cryptography suite I
> am trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over
> different standardized prime curves i.e. not just sm2p256v1.
> 
> Is there CLI or minimal code snippet to achieve it via the EVP interface?
> 
> The current man page of SM2 seems to only describe SM2 as a signature
> algorithm, but not as a public key encryption.

You can use the EVP_PKEY_encrypt() function for this purpose.

A generic example (not SM2 specific) is on the EVP_PKEY_encrypt() man page:

https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_encrypt.html

Doing this for SM2 is essentially the same as shown in that example
except of course don't call the RSA specific
EVP_PKEY_CTX_set_rsa_padding() function.

Setting up of the EVP_PKEY itself to contain an SM2 key is the same as
for sign/verify, i.e. you need to call EVP_PKEY_set_alias_type(). There
is no need to set an id though. See:

https://www.openssl.org/docs/man1.1.1/man7/SM2.html

Hope that helps,

Matt

From socketpair at gmail.com  Wed Oct 24 16:42:49 2018
From: socketpair at gmail.com (=?UTF-8?B?0JzQsNGA0Log0JrQvtGA0LXQvdCx0LXRgNCz?=)
Date: Wed, 24 Oct 2018 21:42:49 +0500
Subject: [openssl-users] openssl cms encrypt recipientInfo [questions for
	openssl developers].
Message-ID: <CAEmTpZF9hUxy6fQyX+ZNgs-HBJiw6nxGVanXXix-vA8D8HgLXg@mail.gmail.com>

Here is a dump of my CMS encrypted message.

===================
CMS_ContentInfo:.
  contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3)
  d.envelopedData:.
    version: 2
    originatorInfo: <ABSENT>
    recipientInfos:
      d.kari:.
        version: 3
        d.originatorKey:.
          algorithm:.
            algorithm: id-ecPublicKey (1.2.840.10045.2.1)
            parameter: <ABSENT>
          publicKey:  (0 unused bits)
            0000 - 04 89 ee 81 d8 05 30 2d-4e 3a a3 33 dd 8b   ......0-N:.3..
            000e - c5 7d 56 79 02 2b 16 7a-f5 4c 20 3f 18 ed   .}Vy.+.z.L ?..
            001c - 92 ba 81 98 88 f8 7a 6c-41 ba 8e bb c0 a5   ......zlA.....
            002a - 41 c4 2a fe 36 31 5c f3-92 9c b5 ad 79 a9   A.*.61\.....y.
            0038 - 9c 4c 75 69 23 9d a1 5b-ef                  .Lui#..[.
        ukm: <ABSENT>
        keyEncryptionAlgorithm:.
          algorithm: dhSinglePass-stdDH-sha256kdf-scheme (1.3.132.1.11.1)
          parameter: SEQUENCE:
        recipientEncryptedKeys:
            d.rKeyId:.
              subjectKeyIdentifier:.
                0000 - 82 46 4f ae b4 cb 84 7b-f4 70 68 6f d0   .FO....{.pho.
                000d - 24 e7 15 8c 34 f3 c4                     $...4..
              date: <ABSENT>
              other: <ABSENT>
            encryptedKey:.
              0000 - f9 b1 b1 28 2a 0c ea e5-eb 3b 0f 22 a5 f4   ...(*....;."..
              000e - 51 8e 22 a3 76 4f fe 01-6f 26 37 b5 24 1c   Q.".vO..o&7.$.
              001c - 20 ba 9f 1a 11 92 25 a5-e4 4e 79 6f          .....%..Nyo
    encryptedContentInfo:.
      contentType: pkcs7-data (1.2.840.113549.1.7.1)
      contentEncryptionAlgorithm:.
        algorithm: aes-256-cbc (2.16.840.1.101.3.4.1.42)
        parameter: OCTET STRING:
          0000 - c4 12 53 6c 1f 04 ee 3a-2f 19 43 6f 87 0c af   ..Sl...:/.Co...
          000f - 9b                                             .
      encryptedContent:.
        0000 - 9f 18 ea 29 08 26 f5 8c-7c 69 ae 23 f2 ca 95   ...).&..|i.#...
        000f - 76                                             v
    unprotectedAttrs:
      <EMPTY>
========

As you can see it has reference to one recipient, identified by his
subjectKeyIdentifier. By some reason
RecipientInfos/d.kari/d.originatorKey also includes full public key
from recipient's certificate. Questions:

1. Why is it required?
2. Is it possible to omit it since it is superfluous (IMHO) ?
3. https://github.com/openssl/openssl/blob/master/crypto/cms/cms_kari.c#L386
(and RFC) say that there could be either key, subjectandserial or
subjectkeyidentifier. So, how to set it using command line openssl
application ?

-- 
Segmentation fault

From skip at taygeta.com  Wed Oct 24 22:34:08 2018
From: skip at taygeta.com (Skip Carter)
Date: Wed, 24 Oct 2018 15:34:08 -0700
Subject: [openssl-users] ssl_accept failure
Message-ID: <1540420448.4886.36.camel@taygeta.com>

I have a server-side application that fails when some clients connect:

waiting for SSL accept()...
SSL_accept() (0) failure -1
SSL_accept() (1) failure 5
[DEBUG]?????Error string : error:00000005:lib(0):func(0):DH lib
SSL_accept() sockerrno is: 0

I think that something earlier failed silently and what I am looking at
is a consequence. 

I need help with that error message.  
In general those "Error string : error:000000..." are pretty cryptic.
I know from messing around that:
      Error string : error:00000001:lib(0):func(0):reason(1)
means that there was no cipher overlap between the client and server.

For some clients, SSL_accept() succeeds and the rest of the application
runs properly.  I have not been able to sort out what the difference
is.

-- 
Skip Carter
Taygeta Scientific Inc.

From rama.krushna7 at gmail.com  Thu Oct 25 09:12:52 2018
From: rama.krushna7 at gmail.com (ramakrushna mishra)
Date: Thu, 25 Oct 2018 14:42:52 +0530
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <mailman.4625.1540399390.21411.openssl-users@openssl.org>
References: <mailman.4625.1540399390.21411.openssl-users@openssl.org>
Message-ID: <CAHgr=kKvyZ7y=cbCkpCgYUuw=H1YcfTYz5O6csJSZdMzrXWudg@mail.gmail.com>

Hi Matt,

Thank you for the response.
But I wanted to know the handshake behavior when client has support for
"TLSv1.3,TLSv1.2" and server has support for ("TLSv1.2,TLSv1")  or
("TLSv1.2,SSLv3).

Both client and server is built with openssl 1.1.1 and the above connection
fails with handshake failure.  The same connection works if server has
continious range of protocol version such as
("TLSv1.2,TLSv1.1,TLSv1,SSLv3).

So, is the handshake behavior change if the supported protocol versions are
not in continuous range ?

Thanks and regards,
Ram Krushna

On Wed, Oct 24, 2018 at 10:14 PM <openssl-users-request at openssl.org> wrote:

> 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: Reg issue in alert message (Matt Caswell)
>    2. Using SM2 ECIES in 1.1.1 (Akira Takahashi)
>    3. Re: Using SM2 ECIES in 1.1.1 (Matt Caswell)
>    4. openssl cms encrypt recipientInfo [questions for  openssl
>       developers]. (???? ?????????)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 Oct 2018 13:57:04 +0100
> From: Matt Caswell <matt at openssl.org>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Reg issue in alert message
> Message-ID: <eb5d58cb-e8b8-fc6b-5992-a25e83e8d2e6 at openssl.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 24/10/2018 13:25, ramakrushna mishra wrote:
> > Hi All,
> >
> > Thank you for all for providing the information.
> > I suspect we are using " SSL_MODE_SEND_FALLBACK_SCSV??" and that might
> > be causing the issue.? The team is looking into this issue now with the
> > provided information.?
> >
> > ?One doubt that came during? our investigation is :
> > " If client has highest version of TLS1.3 and server has support for
> > TLS1.2 and SLV3 only.? ?How the handshake will? proceed ? "
>
> The protocol will negotiate the highest commonly supported protocol
> version. So if the server supports TLS1.3 and the client only supports
> TLS1.2 then TLS1.2 will be used. Don't use SSLv3. That is disabled by
> default in current OpenSSL versions.
>
> Matt
>
> > I am not sure if this question should go to a new thread ?
> >
> > Thanks and Regards,
> > Ram Krushna
> >
> > On Wed, Oct 24, 2018 at 11:47 AM <openssl-users-request at openssl.org
> > <mailto:openssl-users-request at openssl.org>> wrote:
> >
> >     Send openssl-users mailing list submissions to
> >     ? ? ? ? openssl-users at openssl.org <mailto: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
> >     <mailto:openssl-users-request at openssl.org>
> >
> >     You can reach the person managing the list at
> >     ? ? ? ? openssl-users-owner at openssl.org
> >     <mailto: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: CAPI-Engine doc (Selva Nair)
> >     ? ?2. Re: CAPI-Engine doc (Michael Wojcik)
> >     ? ?3. Re: Reg issue in alert message (Michael Wojcik)
> >     ? ?4. Re: CAPI-Engine doc (Jakob Bohm)
> >     ? ?5. Re: Openssl Build Error- module unsafe for SAFESEH
> >     ? ? ? image/Unable to generate SAFESEH image (sakdev)
> >
> >
> >
>  ----------------------------------------------------------------------
> >
> >     Message: 1
> >     Date: Tue, 23 Oct 2018 11:22:04 -0400
> >     From: Selva Nair <selva.nair at gmail.com <mailto:selva.nair at gmail.com
> >>
> >     To: richard.oehlinger at adbsafegate.com
> >     <mailto:richard.oehlinger at adbsafegate.com>,
> >     openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> >     Subject: Re: [openssl-users] CAPI-Engine doc
> >     Message-ID:
> >     ? ? ? ?
> >     <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw at mail.gmail.com
> >     <mailto:vfg_NTzAJsQj%2BD3Jw at mail.gmail.com>>
> >     Content-Type: text/plain; charset="UTF-8"
> >
> >     On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
> >     <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
> wrote:
> >     >
> >     > Hi!
> >     >
> >     > I'm trying to get a handle on the CAPI engine, because I need to
> >     have a
> >     > secure Keystore on Windows. Furthermore I need it to work with Qt's
> >     > QSslKey, which fortunately can be constructed by EVP_PKEY *.
> >     >
> >     > So far so good. The key is found, but when I try to use it in a SSL
> >     > connection i get following error:
> >     >
> >     > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> >     > error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> >
> >     Which version of OpenSSL?
> >
> >     > Trace Output is:
> >     >
> >     > Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
> >     > Opening certificate store MY
> >     > capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
> >     > provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
> >     > Called CAPI_rsa_sign()
> >
> >     This CSP cannot do SHA2 hashes so won't work unless you restrict
> >     signature algorithms or set TLS version to 1.1. I believe OpenSSL
> >     1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
> >     can handle SHA2 and may work. I say "may" because, if the key store
> is
> >     a legacy hardware token, it also depends on signature algorithms
> >     supported
> >     by the token and may be necessary to downgrade to TLS 1.1.
> >
> >     Selva
> >
> >
> >     ------------------------------
> >
> >     Message: 2
> >     Date: Tue, 23 Oct 2018 15:37:24 +0000
> >     From: Michael Wojcik <Michael.Wojcik at microfocus.com
> >     <mailto:Michael.Wojcik at microfocus.com>>
> >     To: "openssl-users at openssl.org <mailto:openssl-users at openssl.org>"
> >     <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
> >     Subject: Re: [openssl-users] CAPI-Engine doc
> >     Message-ID:
> >     ? ? ? ?
> >     <
> DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
> >     <mailto:
> DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
> >>
> >
> >     Content-Type: text/plain; charset="Windows-1252"
> >
> >     > From: openssl-users [mailto:openssl-users-bounces at openssl.org
> >     <mailto:openssl-users-bounces at openssl.org>] On Behalf
> >     > Of Richard Oehlinger via openssl-users
> >     > Sent: Tuesday, October 23, 2018 10:38
> >     >
> >     > I'm trying to get a handle on the CAPI engine, because I need to
> >     have a
> >     > secure Keystore on Windows. Furthermore I need it to work with Qt's
> >     > QSslKey, which fortunately can be constructed by EVP_PKEY *.
> >
> >     What OpenSSL version are you using? Please remember to include this
> >     informtion in every question. (And, normally, we'd ask for the
> >     platform as well, but since CAPI is Windows-specific, we know that
> >     in this case.)
> >
> >     > So far so good. The key is found, but when I try to use it in a SSL
> >     > connection i get following error:
> >     >
> >     > error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> >     > error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> >     >
> >     > I use a current Windows 10. Do I need to use a different Algorithm
> in
> >     > order to work? Some googeling is indicating the provider might be
> >     wrong.
> >
> >     I haven't looked at the CAPI engine code since 1.0.1j. At that time,
> >     I needed CAPI support and discovered there were various issues with
> >     the extant CAPI code, so I forked and rewrote it. That was some time
> >     back, obviously, and I'm afraid I never got around to pushing the
> >     changes back to openssl.org <http://openssl.org>. (In fact, it was
> >     sufficiently long ago that I believe the organization was still
> >     reluctant to take contributions from people in the US at the time.)
> >
> >     The biggest issue was with provider handling. CAPI is something of a
> >     braindead API in many ways - Microsoft's replacement, CNG, is
> >     somewhat better - and the provider stuff is one of them. When a key
> >     (including a "key" which is actually just a reference to a key
> >     contained in an HSM) is imported into one of the Windows key stores,
> >     it has to be associated with a provider, and that provider has to
> >     accommodate that type and size of key; otherwise the key is
> >     unusable. Then, when you try to use the key in CAPI, you have to
> >     specify the same provider - CAPI isn't smart enough to figure it out
> >     on its own.
> >
> >     So my version of the CAPI engine has code to look up the key's
> >     provider and silently correct the provider type information in the
> >     engine's context structure if it's a mismatch.
> >
> >     Beyond that, it appears that my changes included:
> >
> >     - Support for building all the necessary functionality when using
> >     Microsoft Windows SDK 6.0A, which was one of my requirements at the
> >     time.
> >
> >     - Supporting hashes other than SHA-1 for DSA. We have US Federal
> >     customers who needed fairly comprehensive DSA support. For most
> >     people this is likely a non-issue.
> >
> >     - Forcing stack probes on for the callback functions, because my
> >     engine was being built outside the OpenSSL build process, but needed
> >     to match the calling convention of OpenSSL, which (at least in
> >     1.0.1j) included stack-probe support.
> >
> >     - A fix suggested by Steven Henson years ago on the mailing list to
> >     capi_get_key, but never (at least by 1.0.1j) picked up in the source
> >     code: If CryptGetUserKey returns NTE_NO_KEY, xor keyspec with 3 to
> >     flip the key type and try CryptGetUesrKey again.
> >
> >     I think that's it, though it's possible I tweaked some other things
> >     and didn't call them out in the comments.
> >
> >     I suppose I should check what the CAPI engine source looks like in
> >     1.1.1, merge my changes in if feasible, and submit a PR. One of
> >     these days...
> >
> >     Really, though, what we need is a new engine written to use CNG
> >     rather than CAPI. Though that would have the disadvantage of not
> >     supporting ancient Windows OS and SDK versions which, while
> >     unsupported by Microsoft, are still used in far too many places.
> >
> >     --
> >     Michael Wojcik
> >     Distinguished Engineer, Micro Focus
> >
> >
> >
> >
> >     ------------------------------
> >
> >     Message: 3
> >     Date: Tue, 23 Oct 2018 15:37:25 +0000
> >     From: Michael Wojcik <Michael.Wojcik at microfocus.com
> >     <mailto:Michael.Wojcik at microfocus.com>>
> >     To: "openssl-users at openssl.org <mailto:openssl-users at openssl.org>"
> >     <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
> >     Subject: Re: [openssl-users] Reg issue in alert message
> >     Message-ID:
> >     ? ? ? ?
> >     <
> DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
> >     <mailto:
> DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
> >>
> >
> >     Content-Type: text/plain; charset="Windows-1252"
> >
> >     > From: openssl-users [mailto:openssl-users-bounces at openssl.org
> >     <mailto:openssl-users-bounces at openssl.org>] On Behalf
> >     > Of Viktor Dukhovni
> >     > Sent: Tuesday, October 23, 2018 10:02
> >     >
> >     > On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:
> >     >
> >     > > > So, I think client have set TLS_FALLBACK_SCSV in cipher suite
> >     list in
> >     > > > client hello.
> >     > >
> >     > > This suggests there is a bug in the client application. This can
> >     only
> >     > > happen if the client application calls SSL_CTX_set_mode() or
> >     > > SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.
> >     >
> >     > I have a somewhat plausible, if dicey hunch:
> >     >
> >     >? ? ?Perhaps some application developers got confused between
> >     >? ? ?the similar functions SSL_CTX_set_session_cache_mode(3)
> >     >? ? ?and SSL_CTX_set_mode(3) and called the wrong one?
> >
> >     Certainly possible, but I wouldn't discount the possibility that
> >     someone simply thought setting SSL_MODE_SEND_FALLBACK_SCSV was the
> >     Right Thing. There was a fair bit of confusion around the Fallback
> >     SCSV when it first appeared (we had questions from customers that
> >     indicated they didn't understand it, and I had to read the ID to
> >     make sure I did). And, of course, TLS is mightly confusing in
> general.
> >
> >     It is interesting to note that those two options happen to have the
> >     same value, though, particularly given the similarity of the two
> >     function names.
> >
> >     This is one of those cases where C's weak type system is a problem.
> >     Though it would be nice if OpenSSL used enums rather than macros for
> >     these things.
> >
> >     --
> >     Michael Wojcik
> >     Distinguished Engineer, Micro Focus
> >
> >
> >
> >
> >
> >     ------------------------------
> >
> >     Message: 4
> >     Date: Tue, 23 Oct 2018 17:42:56 +0200
> >     From: Jakob Bohm <jb-openssl at wisemo.com <mailto:
> jb-openssl at wisemo.com>>
> >     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> >     Subject: Re: [openssl-users] CAPI-Engine doc
> >     Message-ID: <fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com
> >     <mailto:fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com>>
> >     Content-Type: text/plain; charset=utf-8; format=flowed
> >
> >     On 23/10/2018 17:22, Selva Nair wrote:
> >     > On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via
> openssl-users
> >     > <openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
> wrote:
> >     >> Hi!
> >     >>
> >     >> I'm trying to get a handle on the CAPI engine, because I need to
> >     have a
> >     >> secure Keystore on Windows. Furthermore I need it to work with
> Qt's
> >     >> QSslKey, which fortunately can be constructed by EVP_PKEY *.
> >     >>
> >     >> So far so good. The key is found, but when I try to use it in a
> SSL
> >     >> connection i get following error:
> >     >>
> >     >> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
> >     >> error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> >     > Which version of OpenSSL?
> >     >
> >     >> Trace Output is:
> >     >>
> >     >> Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
> >     >> Opening certificate store MY
> >     >> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
> >     >> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
> >     >> Called CAPI_rsa_sign()
> >     > This CSP cannot do SHA2 hashes so won't work unless you restrict
> >     > signature algorithms or set TLS version to 1.1. I believe OpenSSL
> >     > 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
> >     > can handle SHA2 and may work. I say "may" because, if the key
> store is
> >     > a legacy hardware token, it also depends on signature algorithms
> >     supported
> >     > by the token and may be necessary to downgrade to TLS 1.1.
> >     >
> >     The above limitations are less severe in CNG ("CryptoAPI Next
> >     Generation")
> >     on Windows 6.00 and later, where the old API and CSP names are
> actually
> >     emulations on top of a new structure with much smaller "KSP"
> providers.
> >     At the same time, the CNG emulation of the classic CryptoAPI
> functions
> >     are limited to what was available in Windows 5.01 SP2 and 5.02 SP2,
> thus
> >     much of the SHA-2 functionality is available only by calling the CNG
> >     APIs directly on Windows >= 6.00, but the older APIs with a reference
> >     to newer enum values introduced in Windows 5.01 SP3 or 5.02
> SP2+Hotfix.
> >
> >     Put another way, Microsoft forked their crypto source tree sometime
> in
> >     2004 or 2005, and anything added later was implemented differently in
> >     the 5.0x and 6.0x code bases.
> >
> >     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
> >
> >
> >
> >     ------------------------------
> >
> >     Message: 5
> >     Date: Tue, 23 Oct 2018 23:16:13 -0700 (MST)
> >     From: sakdev <best.sakthi3 at gmail.com <mailto:best.sakthi3 at gmail.com
> >>
> >     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> >     Subject: Re: [openssl-users] Openssl Build Error- module unsafe for
> >     ? ? ? ? SAFESEH image/Unable to generate SAFESEH image
> >     Message-ID: <1540361773425-0.post at n7.nabble.com
> >     <mailto:1540361773425-0.post at n7.nabble.com>>
> >     Content-Type: text/plain; charset=us-ascii
> >
> >     Added "/safeseh" in assembler flags and problem got solved. Thank
> >     you very
> >     much.
> >
> >
> >
> >     --
> >     Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
> >
> >
> >     ------------------------------
> >
> >     Subject: Digest Footer
> >
> >     _______________________________________________
> >     openssl-users mailing list
> >     openssl-users at openssl.org <mailto:openssl-users at openssl.org>
> >     https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> >     ------------------------------
> >
> >     End of openssl-users Digest, Vol 47, Issue 45
> >     *********************************************
> >
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 Oct 2018 23:55:23 +0900
> From: Akira Takahashi <takahashi.akira.58s at kyoto-u.jp>
> To: openssl-users at openssl.org
> Subject: [openssl-users] Using SM2 ECIES in 1.1.1
> Message-ID: <f4163a25-e9b6-f60b-b3ea-8aadf2c190fe at kyoto-u.jp>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> Hi all,
>
>
> Since the version 1.1.1 supports the SM2 public key cryptography suite I
> am
> trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over different
> standardized prime curves i.e. not just sm2p256v1.
>
> Is there CLI or minimal code snippet to achieve it via the EVP interface?
>
> The current man page of SM2 seems to only describe SM2 as a signature
> algorithm,
> but not as a public key encryption.
>
>
> Thank you in advance for your help!
>
> Akira
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Wed, 24 Oct 2018 16:14:47 +0100
> From: Matt Caswell <matt at openssl.org>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Using SM2 ECIES in 1.1.1
> Message-ID: <92097423-88c0-5a7d-9395-a84195b257d6 at openssl.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> On 24/10/2018 15:55, Akira Takahashi wrote:
> > Hi all,
> >
> >
> > Since the version 1.1.1 supports the SM2 public key cryptography suite I
> > am trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over
> > different standardized prime curves i.e. not just sm2p256v1.
> >
> > Is there CLI or minimal code snippet to achieve it via the EVP interface?
> >
> > The current man page of SM2 seems to only describe SM2 as a signature
> > algorithm, but not as a public key encryption.
>
> You can use the EVP_PKEY_encrypt() function for this purpose.
>
> A generic example (not SM2 specific) is on the EVP_PKEY_encrypt() man page:
>
> https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_encrypt.html
>
> Doing this for SM2 is essentially the same as shown in that example
> except of course don't call the RSA specific
> EVP_PKEY_CTX_set_rsa_padding() function.
>
> Setting up of the EVP_PKEY itself to contain an SM2 key is the same as
> for sign/verify, i.e. you need to call EVP_PKEY_set_alias_type(). There
> is no need to set an id though. See:
>
> https://www.openssl.org/docs/man1.1.1/man7/SM2.html
>
> Hope that helps,
>
> Matt
>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 24 Oct 2018 21:42:49 +0500
> From: ???? ????????? <socketpair at gmail.com>
> To: openssl-users at openssl.org
> Subject: [openssl-users] openssl cms encrypt recipientInfo [questions
>         for     openssl developers].
> Message-ID:
>         <
> CAEmTpZF9hUxy6fQyX+ZNgs-HBJiw6nxGVanXXix-vA8D8HgLXg at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Here is a dump of my CMS encrypted message.
>
> ===================
> CMS_ContentInfo:.
>   contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3)
>   d.envelopedData:.
>     version: 2
>     originatorInfo: <ABSENT>
>     recipientInfos:
>       d.kari:.
>         version: 3
>         d.originatorKey:.
>           algorithm:.
>             algorithm: id-ecPublicKey (1.2.840.10045.2.1)
>             parameter: <ABSENT>
>           publicKey:  (0 unused bits)
>             0000 - 04 89 ee 81 d8 05 30 2d-4e 3a a3 33 dd 8b
>  ......0-N:.3..
>             000e - c5 7d 56 79 02 2b 16 7a-f5 4c 20 3f 18 ed   .}Vy.+.z.L
> ?..
>             001c - 92 ba 81 98 88 f8 7a 6c-41 ba 8e bb c0 a5
>  ......zlA.....
>             002a - 41 c4 2a fe 36 31 5c f3-92 9c b5 ad 79 a9
>  A.*.61\.....y.
>             0038 - 9c 4c 75 69 23 9d a1 5b-ef                  .Lui#..[.
>         ukm: <ABSENT>
>         keyEncryptionAlgorithm:.
>           algorithm: dhSinglePass-stdDH-sha256kdf-scheme (1.3.132.1.11.1)
>           parameter: SEQUENCE:
>         recipientEncryptedKeys:
>             d.rKeyId:.
>               subjectKeyIdentifier:.
>                 0000 - 82 46 4f ae b4 cb 84 7b-f4 70 68 6f d0
>  .FO....{.pho.
>                 000d - 24 e7 15 8c 34 f3 c4                     $...4..
>               date: <ABSENT>
>               other: <ABSENT>
>             encryptedKey:.
>               0000 - f9 b1 b1 28 2a 0c ea e5-eb 3b 0f 22 a5 f4
>  ...(*....;."..
>               000e - 51 8e 22 a3 76 4f fe 01-6f 26 37 b5 24 1c
>  Q.".vO..o&7.$.
>               001c - 20 ba 9f 1a 11 92 25 a5-e4 4e 79 6f
> .....%..Nyo
>     encryptedContentInfo:.
>       contentType: pkcs7-data (1.2.840.113549.1.7.1)
>       contentEncryptionAlgorithm:.
>         algorithm: aes-256-cbc (2.16.840.1.101.3.4.1.42)
>         parameter: OCTET STRING:
>           0000 - c4 12 53 6c 1f 04 ee 3a-2f 19 43 6f 87 0c af
>  ..Sl...:/.Co...
>           000f - 9b                                             .
>       encryptedContent:.
>         0000 - 9f 18 ea 29 08 26 f5 8c-7c 69 ae 23 f2 ca 95
>  ...).&..|i.#...
>         000f - 76                                             v
>     unprotectedAttrs:
>       <EMPTY>
> ========
>
> As you can see it has reference to one recipient, identified by his
> subjectKeyIdentifier. By some reason
> RecipientInfos/d.kari/d.originatorKey also includes full public key
> from recipient's certificate. Questions:
>
> 1. Why is it required?
> 2. Is it possible to omit it since it is superfluous (IMHO) ?
> 3.
> https://github.com/openssl/openssl/blob/master/crypto/cms/cms_kari.c#L386
> (and RFC) say that there could be either key, subjectandserial or
> subjectkeyidentifier. So, how to set it using command line openssl
> application ?
>
> --
> Segmentation fault
>
>
> ------------------------------
>
> 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 47, Issue 47
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181025/08b3dd60/attachment-0001.html>

From richard.oehlinger at adbsafegate.com  Thu Oct 25 09:54:58 2018
From: richard.oehlinger at adbsafegate.com (Richard Oehlinger)
Date: Thu, 25 Oct 2018 09:54:58 +0000
Subject: [openssl-users] CAPI-Engine doc
In-Reply-To: <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw@mail.gmail.com>
References: <a8a1dcc3-7032-b03d-171b-ea541df83213@adbsafegate.com>
 <CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw@mail.gmail.com>
Message-ID: <4b1033ea-2b7a-42fc-dc25-6e77542195c8@adbsafegate.com>

On 10/23/2018 05:22 PM, Selva Nair wrote:
> On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via openssl-users
> <openssl-users at openssl.org> wrote:
>> Hi!
>>
>> I'm trying to get a handle on the CAPI engine, because I need to have a
>> secure Keystore on Windows. Furthermore I need it to work with Qt's
>> QSslKey, which fortunately can be constructed by EVP_PKEY *.
>>
>> So far so good. The key is found, but when I try to use it in a SSL
>> connection i get following error:
>>
>> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
>> error:1409B006:SSL routines:ssl3_send_server_key_exchange:EVP lib
> Which version of OpenSSL?
I use 1.0.2p.
>
>> Trace Output is:
>>
>> Setting debug file to C:\Users\user\AppData\Local\Temp\engine.txt
>> Opening certificate store MY
>> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
>> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
>> Called CAPI_rsa_sign()
> This CSP cannot do SHA2 hashes so won't work unless you restrict
> signature algorithms or set TLS version to 1.1. I believe OpenSSL
> 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
> can handle SHA2 and may work. I say "may" because, if the key store is
> a legacy hardware token, it also depends on signature algorithms supported
> by the token and may be necessary to downgrade to TLS 1.1.
>
> Selva
Yes this did the trick, when forced the TLS version 1.1 the key did work.
Unfortunately I've requirement of 1.2 on my project.
I managed to set the provider name from outside when using a different 
lookup method:

     assert(ENGINE_ctrl(engine, CAPI_CMD_SET_CSP_TYPE, PROV_RSA_AES, 0, 0));
     assert(ENGINE_ctrl(engine, CAPI_CMD_SET_CSP_NAME, 0, 
(void*)MS_ENH_RSA_AES_PROV, 0))
     assert(ENGINE_ctrl(engine, CAPI_CMD_LOOKUP_METHOD, 
CAPI_LU_CONTNAME, 0,0));
     EVP_PKEY *key = ENGINE_load_private_key(engine, 
"{4EBA52A8-AB4B-47DB-B777-2B26351F324C}", NULL, NULL);

Now I need to somehow lookup the key name myself, but at least it works 
with TLS 1.2 now.

Thank you for all your help!
Regards,
Richard



From jb-openssl at wisemo.com  Thu Oct 25 17:58:39 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 25 Oct 2018 19:58:39 +0200
Subject: [openssl-users] ssl_accept failure
In-Reply-To: <1540420448.4886.36.camel@taygeta.com>
References: <1540420448.4886.36.camel@taygeta.com>
Message-ID: <f14e93fc-c5bf-9079-e22a-8cbe3cb27862@wisemo.com>

On 25/10/2018 00:34, Skip Carter wrote:
> I have a server-side application that fails when some clients connect:
>
> waiting for SSL accept()...
> SSL_accept() (0) failure -1
> SSL_accept() (1) failure 5
> [DEBUG]?????Error string : error:00000005:lib(0):func(0):DH lib
> SSL_accept() sockerrno is: 0
>
> I think that something earlier failed silently and what I am looking at
> is a consequence.
>
> I need help with that error message.
> In general those "Error string : error:000000..." are pretty cryptic.
> I know from messing around that:
>        Error string : error:00000001:lib(0):func(0):reason(1)
> means that there was no cipher overlap between the client and server.
>
> For some clients, SSL_accept() succeeds and the rest of the application
> runs properly.  I have not been able to sort out what the difference
> is.
>
First, note the OpenSSL FAQ about how to turn on readable error messages.

Lack of cipher overlap is a pretty common failure and usually involves
conflicting cipher list configurations at server and client, thus some
clients may not be configured to allow any of the cipher suite values
(the ones that have names in the "openssl ciphers" command).

So if this is the error, the easiest test is to capture the failing
connections with Wireshark.? Wireshark's builtin SSL/TLS decoder will
directly tell you which cipher suites the failing clients allow (it's
in plaintext in the Server Hello message, so no need to provide
Wireshark with the private key).? Then check if you really have all
those disabled and decide which one (if any) you are willing to enable
to serve those clients.

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 skip at taygeta.com  Thu Oct 25 21:01:00 2018
From: skip at taygeta.com (Skip Carter)
Date: Thu, 25 Oct 2018 14:01:00 -0700
Subject: [openssl-users] ssl_accept failure
In-Reply-To: <f14e93fc-c5bf-9079-e22a-8cbe3cb27862@wisemo.com>
References: <1540420448.4886.36.camel@taygeta.com>
 <f14e93fc-c5bf-9079-e22a-8cbe3cb27862@wisemo.com>
Message-ID: <1540501260.4886.38.camel@taygeta.com>

On Thu, 2018-10-25 at 19:58 +0200, Jakob Bohm via openssl-users wrote:

> First, note the OpenSSL FAQ about how to turn on readable error
> messages.

I am already using the ERR_error_string(), but the result is still
opaque to me.

Error string : error:00000005:lib(0):func(0):DH lib?

The FAQ says this is the format is:
[pid]:error:[error code]:[library name]:[function name]:[reason
string]:[file name]:[line]:[optional text message]

Which I interpret to mean:
    error: 5
    library: 0
    function: 0
    reason: DH lib

which I don't find to be helpful at all.

-- 
Skip Carter
Taygeta Scientific Inc.

From zhihong.lu at hotmail.com  Fri Oct 26 08:47:46 2018
From: zhihong.lu at hotmail.com (lu zhihong)
Date: Fri, 26 Oct 2018 08:47:46 +0000
Subject: [openssl-users] openssl 1.1.1 cross compile error to vxworks 6.8
Message-ID: <SG2SPR01MB00204F5F130CC60CF1CBA9F28DF00@SG2SPR01MB0020.apcprd03.prod.outlook.com>

Hi?All
Now I am trying build openssl1.1.1 version libs in cross compiler platform(susu12+Vxworks 6.8 ). the build target is vxworks-ppc860.but it failed.
I have tried use different Vxworks versions(such as Vxworks6.4,Vxworks6.8),it still failed.
I want to know if build openssl libs using Vxworks compiler, does it need open some special macro or need take care something? Please help to point out.

The compile issues details messages as follows:
1. h_errno not defined
crypto/bio/b_addr.c: In function 'BIO_lookup_ex':
crypto/bio/b_addr.c:785: error: 'h_errno' undeclared (first use in this function)

2. streams/un.h not found , I can only found sys/un.h
include/internal/sockets.h:76:29: error: streams/un.h: No such file or directory



3. some int type redefined(int8_t, int16_t, int32_t, uint8_t , uint16_t, uint32_t, int64_t, uint64_t) both in stdint.h and vxTypes.h
When first include vxTypes.h then include stdint.h will make this issue

One example:
In include/openssl/crypto.h
First include time.h (time.h -> vxWorks.h-> vxWorksCommon.h-> vxTypes.h)
Then include openssl/e_os2.h(e_os2.h -> stdint.h)

So: In file included from include/openssl/e_os2.h:258,
from include/openssl/crypto.h:17,
from crypto/aes/aes_core.c:42:
vxworks-6.8/target/usr/h/stdint.h:26: error: redefinition of typedef 'int8_t'
vxworks-6.8/target/h/types/vxTypes.h:180: error: previous declaration of 'int8_t' was here
vxworks-6.8/target/usr/h/stdint.h:27: error: redefinition of typedef 'int16_t'
vxworks-6.8/target/h/types/vxTypes.h:190: error: previous declaration of 'int16_t' was here
vxworks-6.8/target/usr/h/stdint.h:28: error: redefinition of typedef 'int32_t'
vxworks-6.8/target/h/types/vxTypes.h:200: error: previous declaration of 'int32_t' was here
vxworks-6.8/target/usr/h/stdint.h:31: error: redefinition of typedef 'uint8_t'
vxworks-6.8/target/h/types/vxTypes.h:185: error: previous declaration of 'uint8_t' was here
vxworks-6.8/target/usr/h/stdint.h:32: error: redefinition of typedef 'uint16_t'
vxworks-6.8/target/h/types/vxTypes.h:195: error: previous declaration of 'uint16_t' was here
vxworks-6.8/target/usr/h/stdint.h:33: error: redefinition of typedef 'uint32_t'
vxworks-6.8/target/h/types/vxTypes.h:205: error: previous declaration of 'uint32_t' was here
vxworks-6.8/target/usr/h/stdint.h:88: error: redefinition of typedef 'int64_t'
vxworks-6.8/target/h/types/vxTypes.h:210: error: previous declaration of 'int64_t' was here
vxworks-6.8/target/usr/h/stdint.h:92: error: redefinition of typedef 'uint64_t'
vxworks-6.8/target/h/types/vxTypes.h:215: error: previous declaration of 'uint64_t' was here

Thank you in advance for your help!

lu

From matt at openssl.org  Fri Oct 26 09:07:35 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Oct 2018 10:07:35 +0100
Subject: [openssl-users] ssl_accept failure
In-Reply-To: <1540420448.4886.36.camel@taygeta.com>
References: <1540420448.4886.36.camel@taygeta.com>
Message-ID: <f2a0faaf-12f7-6c0e-1bdd-b793bbfbe5fe@openssl.org>



On 24/10/2018 23:34, Skip Carter wrote:
> I have a server-side application that fails when some clients connect:
> 
> waiting for SSL accept()...
> SSL_accept() (0) failure -1
> SSL_accept() (1) failure 5

How did you obtain the error number 5? Is this the return value from
SSL_get_error()? If so that means SSL_ERROR_SYSCALL which has this
description in the docs:

    Some non-recoverable I/O error occurred.
    The OpenSSL error queue may contain more information on the error.
    For socket I/O on Unix systems, consult B<errno> for details.

    This value can also be returned for other errors, check the error
    queue for details.

> [DEBUG]?????Error string : error:00000005:lib(0):func(0):DH lib
> SSL_accept() sockerrno is: 0

How did you generate this error string? It looks like you might have
taken the return value (5) from SSL_get_error() and stuffed it into
ERR_error_string() or a similar function. That would give you output
like this - but is the incorrect way of doing things.

Matt


> 
> I think that something earlier failed silently and what I am looking at
> is a consequence. 
> 
> I need help with that error message.  
> In general those "Error string : error:000000..." are pretty cryptic.
> I know from messing around that:
>       Error string : error:00000001:lib(0):func(0):reason(1)
> means that there was no cipher overlap between the client and server.
> 
> For some clients, SSL_accept() succeeds and the rest of the application
> runs properly.  I have not been able to sort out what the difference
> is.
> 

From matt at openssl.org  Fri Oct 26 10:07:07 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Oct 2018 11:07:07 +0100
Subject: [openssl-users] openssl 1.1.1 cross compile error to vxworks 6.8
In-Reply-To: <SG2SPR01MB00204F5F130CC60CF1CBA9F28DF00@SG2SPR01MB0020.apcprd03.prod.outlook.com>
References: <SG2SPR01MB00204F5F130CC60CF1CBA9F28DF00@SG2SPR01MB0020.apcprd03.prod.outlook.com>
Message-ID: <377e5ce9-646e-6789-040c-18e6bdad2f86@openssl.org>



On 26/10/2018 09:47, lu zhihong wrote:
> Hi?All
> Now I am trying build openssl1.1.1 version libs in cross compiler platform(susu12+Vxworks 6.8 ). the build target is vxworks-ppc860.but it failed.
> I have tried use different Vxworks versions(such as Vxworks6.4,Vxworks6.8),it still failed.
> I want to know if build openssl libs using Vxworks compiler, does it need open some special macro or need take care something? Please help to point out.

Vxworks isn't a platform we test on - but there is vxworks specific code
in the codebase so in theory it should work. We're always happy to
receive patches for non-core platforms.

> 
> The compile issues details messages as follows:
> 1. h_errno not defined
> crypto/bio/b_addr.c: In function 'BIO_lookup_ex':
> crypto/bio/b_addr.c:785: error: 'h_errno' undeclared (first use in this function)

h_errno has been removed from recent versions of POSIX. It looks like we
should remove this (at least for recent POSIX versions). Patches
gratefully received.


> 
> 2. streams/un.h not found , I can only found sys/un.h
> include/internal/sockets.h:76:29: error: streams/un.h: No such file or directory

That's a bit odd. internal/sockets.h has this code:

#    ifdef OPENSSL_SYS_VXWORKS
#     include <streams/un.h>
#    else
#     include <sys/un.h>
#    endif

So for all our other platforms we include sys/un.h, but for vxworks only
we include streams/un.h. Presumably this was done as some historical
workaround for this platform that no longer applies to current versions.
A fix would be to simply remove this special case code and always
include sys/un.h - although this begs the question: is the special case
still needed for some historical vxworks platform version that people
are still using?


> 3. some int type redefined(int8_t, int16_t, int32_t, uint8_t , uint16_t, uint32_t, int64_t, uint64_t) both in stdint.h and vxTypes.h
> When first include vxTypes.h then include stdint.h will make this issue
> 
> One example:
> In include/openssl/crypto.h
> First include time.h (time.h -> vxWorks.h-> vxWorksCommon.h-> vxTypes.h)
> Then include openssl/e_os2.h(e_os2.h -> stdint.h)
> 

TBH, this looks like a vxworks platform bug. It shouldn't fail if you
include 2 different standard header files (time.h and stdint.h)!?

Matt


From matt at openssl.org  Fri Oct 26 10:55:09 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 26 Oct 2018 11:55:09 +0100
Subject: [openssl-users] Reg issue in alert message
In-Reply-To: <CAHgr=kKvyZ7y=cbCkpCgYUuw=H1YcfTYz5O6csJSZdMzrXWudg@mail.gmail.com>
References: <mailman.4625.1540399390.21411.openssl-users@openssl.org>
 <CAHgr=kKvyZ7y=cbCkpCgYUuw=H1YcfTYz5O6csJSZdMzrXWudg@mail.gmail.com>
Message-ID: <acf512b8-b3fe-83b9-aad2-68d03b336e35@openssl.org>



On 25/10/2018 10:12, ramakrushna mishra wrote:
> Hi Matt,
> 
> Thank you for the response.
> But I wanted to know the handshake behavior when client has support for
> "TLSv1.3,TLSv1.2" and server has support for ("TLSv1.2,TLSv1")? or
> ("TLSv1.2,SSLv3).
> 
> Both client and server is built with openssl 1.1.1 and the above
> connection fails with handshake failure.? The same connection works if
> server has continious range of protocol version such as
> ("TLSv1.2,TLSv1.1,TLSv1,SSLv3).?
> 
> So, is the handshake behavior change if the supported protocol versions
> are not in continuous range ?

On the server side I would expect this to successfully connect with
TLSv1.2. I just tested this using s_server/s_client and it worked as
expected:

$ openssl s_server -no_tls1_3 -no_tls1_1
$ openssl s_client -min_protocol "TLSv1.2"

A non continuous range on the client side works slightly differently. So
this fails:

$ openssl s_server -min_protocol "TLSv1.2"
$ openssl s_client -no_tls1_3 -no_tls1_1

This is because of the way the supported versions are advertised by the
client in the ClientHello. In the above scenario the client will
advertise TLSv1.0 as its highest supported version.

Matt


> 
> Thanks and regards,
> Ram Krushna
> 
> On Wed, Oct 24, 2018 at 10:14 PM <openssl-users-request at openssl.org
> <mailto:openssl-users-request at openssl.org>> wrote:
> 
>     Send openssl-users mailing list submissions to
>     ? ? ? ? openssl-users at openssl.org <mailto: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
>     <mailto:openssl-users-request at openssl.org>
> 
>     You can reach the person managing the list at
>     ? ? ? ? openssl-users-owner at openssl.org
>     <mailto: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: Reg issue in alert message (Matt Caswell)
>     ? ?2. Using SM2 ECIES in 1.1.1 (Akira Takahashi)
>     ? ?3. Re: Using SM2 ECIES in 1.1.1 (Matt Caswell)
>     ? ?4. openssl cms encrypt recipientInfo [questions for? openssl
>     ? ? ? developers]. (???? ?????????)
> 
> 
>     ----------------------------------------------------------------------
> 
>     Message: 1
>     Date: Wed, 24 Oct 2018 13:57:04 +0100
>     From: Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] Reg issue in alert message
>     Message-ID: <eb5d58cb-e8b8-fc6b-5992-a25e83e8d2e6 at openssl.org
>     <mailto:eb5d58cb-e8b8-fc6b-5992-a25e83e8d2e6 at openssl.org>>
>     Content-Type: text/plain; charset=utf-8
> 
> 
> 
>     On 24/10/2018 13:25, ramakrushna mishra wrote:
>     > Hi All,
>     >
>     > Thank you for all for providing the information.
>     > I suspect we are using " SSL_MODE_SEND_FALLBACK_SCSV??" and that might
>     > be causing the issue.? The team is looking into this issue now
>     with the
>     > provided information.?
>     >
>     > ?One doubt that came during? our investigation is :
>     > " If client has highest version of TLS1.3 and server has support for
>     > TLS1.2 and SLV3 only.? ?How the handshake will? proceed ? "
> 
>     The protocol will negotiate the highest commonly supported protocol
>     version. So if the server supports TLS1.3 and the client only supports
>     TLS1.2 then TLS1.2 will be used. Don't use SSLv3. That is disabled by
>     default in current OpenSSL versions.
> 
>     Matt
> 
>     > I am not sure if this question should go to a new thread ?
>     >
>     > Thanks and Regards,
>     > Ram Krushna
>     >
>     > On Wed, Oct 24, 2018 at 11:47 AM
>     <openssl-users-request at openssl.org
>     <mailto:openssl-users-request at openssl.org>
>     > <mailto:openssl-users-request at openssl.org
>     <mailto:openssl-users-request at openssl.org>>> wrote:
>     >
>     >? ? ?Send openssl-users mailing list submissions to
>     >? ? ?? ? ? ? openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org> <mailto:openssl-users at openssl.org
>     <mailto: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
>     <mailto:openssl-users-request at openssl.org>
>     >? ? ?<mailto:openssl-users-request at openssl.org
>     <mailto:openssl-users-request at openssl.org>>
>     >
>     >? ? ?You can reach the person managing the list at
>     >? ? ?? ? ? ? openssl-users-owner at openssl.org
>     <mailto:openssl-users-owner at openssl.org>
>     >? ? ?<mailto:openssl-users-owner at openssl.org
>     <mailto: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: CAPI-Engine doc (Selva Nair)
>     >? ? ?? ?2. Re: CAPI-Engine doc (Michael Wojcik)
>     >? ? ?? ?3. Re: Reg issue in alert message (Michael Wojcik)
>     >? ? ?? ?4. Re: CAPI-Engine doc (Jakob Bohm)
>     >? ? ?? ?5. Re: Openssl Build Error- module unsafe for SAFESEH
>     >? ? ?? ? ? image/Unable to generate SAFESEH image (sakdev)
>     >
>     >
>     >? ?
>     ?----------------------------------------------------------------------
>     >
>     >? ? ?Message: 1
>     >? ? ?Date: Tue, 23 Oct 2018 11:22:04 -0400
>     >? ? ?From: Selva Nair <selva.nair at gmail.com
>     <mailto:selva.nair at gmail.com> <mailto:selva.nair at gmail.com
>     <mailto:selva.nair at gmail.com>>>
>     >? ? ?To: richard.oehlinger at adbsafegate.com
>     <mailto:richard.oehlinger at adbsafegate.com>
>     >? ? ?<mailto:richard.oehlinger at adbsafegate.com
>     <mailto:richard.oehlinger at adbsafegate.com>>,
>     >? ? ?openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     <mailto:openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
>     >? ? ?Subject: Re: [openssl-users] CAPI-Engine doc
>     >? ? ?Message-ID:
>     >? ? ?? ? ? ?
>     >? ?
>     ?<CAKuzo_iqEBP-QG19Hsg5dFVoUG+2q-5O=vfg_NTzAJsQj+D3Jw at mail.gmail.com
>     <mailto:vfg_NTzAJsQj%2BD3Jw at mail.gmail.com>
>     >? ? ?<mailto:vfg_NTzAJsQj%2BD3Jw at mail.gmail.com
>     <mailto:vfg_NTzAJsQj%252BD3Jw at mail.gmail.com>>>
>     >? ? ?Content-Type: text/plain; charset="UTF-8"
>     >
>     >? ? ?On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via
>     openssl-users
>     >? ? ?<openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     <mailto:openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org>>> wrote:
>     >? ? ?>
>     >? ? ?> Hi!
>     >? ? ?>
>     >? ? ?> I'm trying to get a handle on the CAPI engine, because I need to
>     >? ? ?have a
>     >? ? ?> secure Keystore on Windows. Furthermore I need it to work
>     with Qt's
>     >? ? ?> QSslKey, which fortunately can be constructed by EVP_PKEY *.
>     >? ? ?>
>     >? ? ?> So far so good. The key is found, but when I try to use it
>     in a SSL
>     >? ? ?> connection i get following error:
>     >? ? ?>
>     >? ? ?> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
>     >? ? ?> error:1409B006:SSL
>     routines:ssl3_send_server_key_exchange:EVP lib
>     >
>     >? ? ?Which version of OpenSSL?
>     >
>     >? ? ?> Trace Output is:
>     >? ? ?>
>     >? ? ?> Setting debug file to
>     C:\Users\user\AppData\Local\Temp\engine.txt
>     >? ? ?> Opening certificate store MY
>     >? ? ?> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
>     >? ? ?> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
>     >? ? ?> Called CAPI_rsa_sign()
>     >
>     >? ? ?This CSP cannot do SHA2 hashes so won't work unless you restrict
>     >? ? ?signature algorithms or set TLS version to 1.1. I believe OpenSSL
>     >? ? ?1.1.0 will try to load The ".. Enhanced RSA AES .. Provider" which
>     >? ? ?can handle SHA2 and may work. I say "may" because, if the key
>     store is
>     >? ? ?a legacy hardware token, it also depends on signature algorithms
>     >? ? ?supported
>     >? ? ?by the token and may be necessary to downgrade to TLS 1.1.
>     >
>     >? ? ?Selva
>     >
>     >
>     >? ? ?------------------------------
>     >
>     >? ? ?Message: 2
>     >? ? ?Date: Tue, 23 Oct 2018 15:37:24 +0000
>     >? ? ?From: Michael Wojcik <Michael.Wojcik at microfocus.com
>     <mailto:Michael.Wojcik at microfocus.com>
>     >? ? ?<mailto:Michael.Wojcik at microfocus.com
>     <mailto:Michael.Wojcik at microfocus.com>>>
>     >? ? ?To: "openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org> <mailto:openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org>>"
>     >? ? ?<openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     <mailto:openssl-users at openssl.org <mailto:openssl-users at openssl.org>>>
>     >? ? ?Subject: Re: [openssl-users] CAPI-Engine doc
>     >? ? ?Message-ID:
>     >? ? ?? ? ? ?
>     >? ?
>     ?<DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
>     <mailto:DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com>
>     >? ?
>     ?<mailto:DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
>     <mailto:DM5PR18MB1324455050CC00BD3A2DD70FF9F50 at DM5PR18MB1324.namprd18.prod.outlook.com>>>
>     >
>     >? ? ?Content-Type: text/plain; charset="Windows-1252"
>     >
>     >? ? ?> From: openssl-users
>     [mailto:openssl-users-bounces at openssl.org
>     <mailto:openssl-users-bounces at openssl.org>
>     >? ? ?<mailto:openssl-users-bounces at openssl.org
>     <mailto:openssl-users-bounces at openssl.org>>] On Behalf
>     >? ? ?> Of Richard Oehlinger via openssl-users
>     >? ? ?> Sent: Tuesday, October 23, 2018 10:38
>     >? ? ?>
>     >? ? ?> I'm trying to get a handle on the CAPI engine, because I need to
>     >? ? ?have a
>     >? ? ?> secure Keystore on Windows. Furthermore I need it to work
>     with Qt's
>     >? ? ?> QSslKey, which fortunately can be constructed by EVP_PKEY *.
>     >
>     >? ? ?What OpenSSL version are you using? Please remember to include
>     this
>     >? ? ?informtion in every question. (And, normally, we'd ask for the
>     >? ? ?platform as well, but since CAPI is Windows-specific, we know that
>     >? ? ?in this case.)
>     >
>     >? ? ?> So far so good. The key is found, but when I try to use it
>     in a SSL
>     >? ? ?> connection i get following error:
>     >? ? ?>
>     >? ? ?> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
>     >? ? ?> error:1409B006:SSL
>     routines:ssl3_send_server_key_exchange:EVP lib
>     >? ? ?>
>     >? ? ?> I use a current Windows 10. Do I need to use a different
>     Algorithm in
>     >? ? ?> order to work? Some googeling is indicating the provider
>     might be
>     >? ? ?wrong.
>     >
>     >? ? ?I haven't looked at the CAPI engine code since 1.0.1j. At that
>     time,
>     >? ? ?I needed CAPI support and discovered there were various issues
>     with
>     >? ? ?the extant CAPI code, so I forked and rewrote it. That was
>     some time
>     >? ? ?back, obviously, and I'm afraid I never got around to pushing the
>     >? ? ?changes back to openssl.org <http://openssl.org>
>     <http://openssl.org>. (In fact, it was
>     >? ? ?sufficiently long ago that I believe the organization was still
>     >? ? ?reluctant to take contributions from people in the US at the
>     time.)
>     >
>     >? ? ?The biggest issue was with provider handling. CAPI is
>     something of a
>     >? ? ?braindead API in many ways - Microsoft's replacement, CNG, is
>     >? ? ?somewhat better - and the provider stuff is one of them. When
>     a key
>     >? ? ?(including a "key" which is actually just a reference to a key
>     >? ? ?contained in an HSM) is imported into one of the Windows key
>     stores,
>     >? ? ?it has to be associated with a provider, and that provider has to
>     >? ? ?accommodate that type and size of key; otherwise the key is
>     >? ? ?unusable. Then, when you try to use the key in CAPI, you have to
>     >? ? ?specify the same provider - CAPI isn't smart enough to figure
>     it out
>     >? ? ?on its own.
>     >
>     >? ? ?So my version of the CAPI engine has code to look up the key's
>     >? ? ?provider and silently correct the provider type information in the
>     >? ? ?engine's context structure if it's a mismatch.
>     >
>     >? ? ?Beyond that, it appears that my changes included:
>     >
>     >? ? ?- Support for building all the necessary functionality when using
>     >? ? ?Microsoft Windows SDK 6.0A, which was one of my requirements
>     at the
>     >? ? ?time.
>     >
>     >? ? ?- Supporting hashes other than SHA-1 for DSA. We have US Federal
>     >? ? ?customers who needed fairly comprehensive DSA support. For most
>     >? ? ?people this is likely a non-issue.
>     >
>     >? ? ?- Forcing stack probes on for the callback functions, because my
>     >? ? ?engine was being built outside the OpenSSL build process, but
>     needed
>     >? ? ?to match the calling convention of OpenSSL, which (at least in
>     >? ? ?1.0.1j) included stack-probe support.
>     >
>     >? ? ?- A fix suggested by Steven Henson years ago on the mailing
>     list to
>     >? ? ?capi_get_key, but never (at least by 1.0.1j) picked up in the
>     source
>     >? ? ?code: If CryptGetUserKey returns NTE_NO_KEY, xor keyspec with 3 to
>     >? ? ?flip the key type and try CryptGetUesrKey again.
>     >
>     >? ? ?I think that's it, though it's possible I tweaked some other
>     things
>     >? ? ?and didn't call them out in the comments.
>     >
>     >? ? ?I suppose I should check what the CAPI engine source looks like in
>     >? ? ?1.1.1, merge my changes in if feasible, and submit a PR. One of
>     >? ? ?these days...
>     >
>     >? ? ?Really, though, what we need is a new engine written to use CNG
>     >? ? ?rather than CAPI. Though that would have the disadvantage of not
>     >? ? ?supporting ancient Windows OS and SDK versions which, while
>     >? ? ?unsupported by Microsoft, are still used in far too many places.
>     >
>     >? ? ?--
>     >? ? ?Michael Wojcik
>     >? ? ?Distinguished Engineer, Micro Focus
>     >
>     >
>     >
>     >
>     >? ? ?------------------------------
>     >
>     >? ? ?Message: 3
>     >? ? ?Date: Tue, 23 Oct 2018 15:37:25 +0000
>     >? ? ?From: Michael Wojcik <Michael.Wojcik at microfocus.com
>     <mailto:Michael.Wojcik at microfocus.com>
>     >? ? ?<mailto:Michael.Wojcik at microfocus.com
>     <mailto:Michael.Wojcik at microfocus.com>>>
>     >? ? ?To: "openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org> <mailto:openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org>>"
>     >? ? ?<openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     <mailto:openssl-users at openssl.org <mailto:openssl-users at openssl.org>>>
>     >? ? ?Subject: Re: [openssl-users] Reg issue in alert message
>     >? ? ?Message-ID:
>     >? ? ?? ? ? ?
>     >? ?
>     ?<DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
>     <mailto:DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com>
>     >? ?
>     ?<mailto:DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com
>     <mailto:DM5PR18MB13246F528FB866508D8E9267F9F50 at DM5PR18MB1324.namprd18.prod.outlook.com>>>
>     >
>     >? ? ?Content-Type: text/plain; charset="Windows-1252"
>     >
>     >? ? ?> From: openssl-users
>     [mailto:openssl-users-bounces at openssl.org
>     <mailto:openssl-users-bounces at openssl.org>
>     >? ? ?<mailto:openssl-users-bounces at openssl.org
>     <mailto:openssl-users-bounces at openssl.org>>] On Behalf
>     >? ? ?> Of Viktor Dukhovni
>     >? ? ?> Sent: Tuesday, October 23, 2018 10:02
>     >? ? ?>
>     >? ? ?> On Tue, Oct 23, 2018 at 01:29:27PM +0100, Matt Caswell wrote:
>     >? ? ?>
>     >? ? ?> > > So, I think client have set TLS_FALLBACK_SCSV in cipher
>     suite
>     >? ? ?list in
>     >? ? ?> > > client hello.
>     >? ? ?> >
>     >? ? ?> > This suggests there is a bug in the client application.
>     This can
>     >? ? ?only
>     >? ? ?> > happen if the client application calls SSL_CTX_set_mode() or
>     >? ? ?> > SSL_set_mode() to set the SSL_MODE_SEND_FALLBACK_SCSV mode.
>     >? ? ?>
>     >? ? ?> I have a somewhat plausible, if dicey hunch:
>     >? ? ?>
>     >? ? ?>? ? ?Perhaps some application developers got confused between
>     >? ? ?>? ? ?the similar functions SSL_CTX_set_session_cache_mode(3)
>     >? ? ?>? ? ?and SSL_CTX_set_mode(3) and called the wrong one?
>     >
>     >? ? ?Certainly possible, but I wouldn't discount the possibility that
>     >? ? ?someone simply thought setting SSL_MODE_SEND_FALLBACK_SCSV was the
>     >? ? ?Right Thing. There was a fair bit of confusion around the Fallback
>     >? ? ?SCSV when it first appeared (we had questions from customers that
>     >? ? ?indicated they didn't understand it, and I had to read the ID to
>     >? ? ?make sure I did). And, of course, TLS is mightly confusing in
>     general.
>     >
>     >? ? ?It is interesting to note that those two options happen to
>     have the
>     >? ? ?same value, though, particularly given the similarity of the two
>     >? ? ?function names.
>     >
>     >? ? ?This is one of those cases where C's weak type system is a
>     problem.
>     >? ? ?Though it would be nice if OpenSSL used enums rather than
>     macros for
>     >? ? ?these things.
>     >
>     >? ? ?--
>     >? ? ?Michael Wojcik
>     >? ? ?Distinguished Engineer, Micro Focus
>     >
>     >
>     >
>     >
>     >
>     >? ? ?------------------------------
>     >
>     >? ? ?Message: 4
>     >? ? ?Date: Tue, 23 Oct 2018 17:42:56 +0200
>     >? ? ?From: Jakob Bohm <jb-openssl at wisemo.com
>     <mailto:jb-openssl at wisemo.com> <mailto:jb-openssl at wisemo.com
>     <mailto:jb-openssl at wisemo.com>>>
>     >? ? ?To: openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org> <mailto:openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org>>
>     >? ? ?Subject: Re: [openssl-users] CAPI-Engine doc
>     >? ? ?Message-ID: <fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com
>     <mailto:fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com>
>     >? ? ?<mailto:fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com
>     <mailto:fc161e84-bf5f-f61b-0f1d-3bfa5641edd8 at wisemo.com>>>
>     >? ? ?Content-Type: text/plain; charset=utf-8; format=flowed
>     >
>     >? ? ?On 23/10/2018 17:22, Selva Nair wrote:
>     >? ? ?> On Tue, Oct 23, 2018 at 10:38 AM Richard Oehlinger via
>     openssl-users
>     >? ? ?> <openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org> <mailto:openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org>>> wrote:
>     >? ? ?>> Hi!
>     >? ? ?>>
>     >? ? ?>> I'm trying to get a handle on the CAPI engine, because I
>     need to
>     >? ? ?have a
>     >? ? ?>> secure Keystore on Windows. Furthermore I need it to work
>     with Qt's
>     >? ? ?>> QSslKey, which fortunately can be constructed by EVP_PKEY *.
>     >? ? ?>>
>     >? ? ?>> So far so good. The key is found, but when I try to use it
>     in a SSL
>     >? ? ?>> connection i get following error:
>     >? ? ?>>
>     >? ? ?>> error:80070063:lib(128):CAPI_RSA_SIGN:cant create hash object,
>     >? ? ?>> error:1409B006:SSL
>     routines:ssl3_send_server_key_exchange:EVP lib
>     >? ? ?> Which version of OpenSSL?
>     >? ? ?>
>     >? ? ?>> Trace Output is:
>     >? ? ?>>
>     >? ? ?>> Setting debug file to
>     C:\Users\user\AppData\Local\Temp\engine.txt
>     >? ? ?>> Opening certificate store MY
>     >? ? ?>> capi_get_key, contname={4EBA52A8-AB4B-47DB-B777-2B26351F324C},
>     >? ? ?>> provname=Microsoft Enhanced Cryptographic Provider v1.0, type=1
>     >? ? ?>> Called CAPI_rsa_sign()
>     >? ? ?> This CSP cannot do SHA2 hashes so won't work unless you restrict
>     >? ? ?> signature algorithms or set TLS version to 1.1. I believe
>     OpenSSL
>     >? ? ?> 1.1.0 will try to load The ".. Enhanced RSA AES .. Provider"
>     which
>     >? ? ?> can handle SHA2 and may work. I say "may" because, if the
>     key store is
>     >? ? ?> a legacy hardware token, it also depends on signature algorithms
>     >? ? ?supported
>     >? ? ?> by the token and may be necessary to downgrade to TLS 1.1.
>     >? ? ?>
>     >? ? ?The above limitations are less severe in CNG ("CryptoAPI Next
>     >? ? ?Generation")
>     >? ? ?on Windows 6.00 and later, where the old API and CSP names are
>     actually
>     >? ? ?emulations on top of a new structure with much smaller "KSP"
>     providers.
>     >? ? ?At the same time, the CNG emulation of the classic CryptoAPI
>     functions
>     >? ? ?are limited to what was available in Windows 5.01 SP2 and 5.02
>     SP2, thus
>     >? ? ?much of the SHA-2 functionality is available only by calling
>     the CNG
>     >? ? ?APIs directly on Windows >= 6.00, but the older APIs with a
>     reference
>     >? ? ?to newer enum values introduced in Windows 5.01 SP3 or 5.02
>     SP2+Hotfix.
>     >
>     >? ? ?Put another way, Microsoft forked their crypto source tree
>     sometime in
>     >? ? ?2004 or 2005, and anything added later was implemented
>     differently in
>     >? ? ?the 5.0x and 6.0x code bases.
>     >
>     >? ? ?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
>     >
>     >
>     >
>     >? ? ?------------------------------
>     >
>     >? ? ?Message: 5
>     >? ? ?Date: Tue, 23 Oct 2018 23:16:13 -0700 (MST)
>     >? ? ?From: sakdev <best.sakthi3 at gmail.com
>     <mailto:best.sakthi3 at gmail.com> <mailto:best.sakthi3 at gmail.com
>     <mailto:best.sakthi3 at gmail.com>>>
>     >? ? ?To: openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org> <mailto:openssl-users at openssl.org
>     <mailto:openssl-users at openssl.org>>
>     >? ? ?Subject: Re: [openssl-users] Openssl Build Error- module
>     unsafe for
>     >? ? ?? ? ? ? SAFESEH image/Unable to generate SAFESEH image
>     >? ? ?Message-ID: <1540361773425-0.post at n7.nabble.com
>     <mailto:1540361773425-0.post at n7.nabble.com>
>     >? ? ?<mailto:1540361773425-0.post at n7.nabble.com
>     <mailto:1540361773425-0.post at n7.nabble.com>>>
>     >? ? ?Content-Type: text/plain; charset=us-ascii
>     >
>     >? ? ?Added "/safeseh" in assembler flags and problem got solved. Thank
>     >? ? ?you very
>     >? ? ?much.
>     >
>     >
>     >
>     >? ? ?--
>     >? ? ?Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
>     >
>     >
>     >? ? ?------------------------------
>     >
>     >? ? ?Subject: Digest Footer
>     >
>     >? ? ?_______________________________________________
>     >? ? ?openssl-users mailing list
>     >? ? ?openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     <mailto:openssl-users at openssl.org <mailto:openssl-users at openssl.org>>
>     >? ? ?https://mta.openssl.org/mailman/listinfo/openssl-users
>     >
>     >
>     >? ? ?------------------------------
>     >
>     >? ? ?End of openssl-users Digest, Vol 47, Issue 45
>     >? ? ?*********************************************
>     >
>     >
> 
> 
>     ------------------------------
> 
>     Message: 2
>     Date: Wed, 24 Oct 2018 23:55:23 +0900
>     From: Akira Takahashi <takahashi.akira.58s at kyoto-u.jp
>     <mailto:takahashi.akira.58s at kyoto-u.jp>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: [openssl-users] Using SM2 ECIES in 1.1.1
>     Message-ID: <f4163a25-e9b6-f60b-b3ea-8aadf2c190fe at kyoto-u.jp
>     <mailto:f4163a25-e9b6-f60b-b3ea-8aadf2c190fe at kyoto-u.jp>>
>     Content-Type: text/plain; charset=utf-8; format=flowed
> 
>     Hi all,
> 
> 
>     Since the version 1.1.1 supports the SM2 public key cryptography
>     suite I am
>     trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over
>     different
>     standardized prime curves i.e. not just sm2p256v1.
> 
>     Is there CLI or minimal code snippet to achieve it via the EVP
>     interface?
> 
>     The current man page of SM2 seems to only describe SM2 as a
>     signature algorithm,
>     but not as a public key encryption.
> 
> 
>     Thank you in advance for your help!
> 
>     Akira
> 
> 
> 
> 
> 
>     ------------------------------
> 
>     Message: 3
>     Date: Wed, 24 Oct 2018 16:14:47 +0100
>     From: Matt Caswell <matt at openssl.org <mailto:matt at openssl.org>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: Re: [openssl-users] Using SM2 ECIES in 1.1.1
>     Message-ID: <92097423-88c0-5a7d-9395-a84195b257d6 at openssl.org
>     <mailto:92097423-88c0-5a7d-9395-a84195b257d6 at openssl.org>>
>     Content-Type: text/plain; charset=utf-8
> 
> 
> 
>     On 24/10/2018 15:55, Akira Takahashi wrote:
>     > Hi all,
>     >
>     >
>     > Since the version 1.1.1 supports the SM2 public key cryptography
>     suite I
>     > am trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over
>     > different standardized prime curves i.e. not just sm2p256v1.
>     >
>     > Is there CLI or minimal code snippet to achieve it via the EVP
>     interface?
>     >
>     > The current man page of SM2 seems to only describe SM2 as a signature
>     > algorithm, but not as a public key encryption.
> 
>     You can use the EVP_PKEY_encrypt() function for this purpose.
> 
>     A generic example (not SM2 specific) is on the EVP_PKEY_encrypt()
>     man page:
> 
>     https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_encrypt.html
> 
>     Doing this for SM2 is essentially the same as shown in that example
>     except of course don't call the RSA specific
>     EVP_PKEY_CTX_set_rsa_padding() function.
> 
>     Setting up of the EVP_PKEY itself to contain an SM2 key is the same as
>     for sign/verify, i.e. you need to call EVP_PKEY_set_alias_type(). There
>     is no need to set an id though. See:
> 
>     https://www.openssl.org/docs/man1.1.1/man7/SM2.html
> 
>     Hope that helps,
> 
>     Matt
> 
> 
>     ------------------------------
> 
>     Message: 4
>     Date: Wed, 24 Oct 2018 21:42:49 +0500
>     From: ???? ????????? <socketpair at gmail.com
>     <mailto:socketpair at gmail.com>>
>     To: openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     Subject: [openssl-users] openssl cms encrypt recipientInfo [questions
>     ? ? ? ? for? ? ?openssl developers].
>     Message-ID:
>     ? ? ? ?
>     <CAEmTpZF9hUxy6fQyX+ZNgs-HBJiw6nxGVanXXix-vA8D8HgLXg at mail.gmail.com
>     <mailto:CAEmTpZF9hUxy6fQyX%2BZNgs-HBJiw6nxGVanXXix-vA8D8HgLXg at mail.gmail.com>>
>     Content-Type: text/plain; charset="UTF-8"
> 
>     Here is a dump of my CMS encrypted message.
> 
>     ===================
>     CMS_ContentInfo:.
>     ? contentType: pkcs7-envelopedData (1.2.840.113549.1.7.3)
>     ? d.envelopedData:.
>     ? ? version: 2
>     ? ? originatorInfo: <ABSENT>
>     ? ? recipientInfos:
>     ? ? ? d.kari:.
>     ? ? ? ? version: 3
>     ? ? ? ? d.originatorKey:.
>     ? ? ? ? ? algorithm:.
>     ? ? ? ? ? ? algorithm: id-ecPublicKey (1.2.840.10045.2.1)
>     ? ? ? ? ? ? parameter: <ABSENT>
>     ? ? ? ? ? publicKey:? (0 unused bits)
>     ? ? ? ? ? ? 0000 - 04 89 ee 81 d8 05 30 2d-4e 3a a3 33 dd 8b?
>     ?......0-N:.3..
>     ? ? ? ? ? ? 000e - c5 7d 56 79 02 2b 16 7a-f5 4c 20 3f 18 ed?
>     ?.}Vy.+.z.L ?..
>     ? ? ? ? ? ? 001c - 92 ba 81 98 88 f8 7a 6c-41 ba 8e bb c0 a5?
>     ?......zlA.....
>     ? ? ? ? ? ? 002a - 41 c4 2a fe 36 31 5c f3-92 9c b5 ad 79 a9?
>     ?A.*.61\.....y.
>     ? ? ? ? ? ? 0038 - 9c 4c 75 69 23 9d a1 5b-ef? ? ? ? ? ? ? ? ? .Lui#..[.
>     ? ? ? ? ukm: <ABSENT>
>     ? ? ? ? keyEncryptionAlgorithm:.
>     ? ? ? ? ? algorithm: dhSinglePass-stdDH-sha256kdf-scheme
>     (1.3.132.1.11.1)
>     ? ? ? ? ? parameter: SEQUENCE:
>     ? ? ? ? recipientEncryptedKeys:
>     ? ? ? ? ? ? d.rKeyId:.
>     ? ? ? ? ? ? ? subjectKeyIdentifier:.
>     ? ? ? ? ? ? ? ? 0000 - 82 46 4f ae b4 cb 84 7b-f4 70 68 6f d0?
>     ?.FO....{.pho.
>     ? ? ? ? ? ? ? ? 000d - 24 e7 15 8c 34 f3 c4? ? ? ? ? ? ? ? ? ? ?$...4..
>     ? ? ? ? ? ? ? date: <ABSENT>
>     ? ? ? ? ? ? ? other: <ABSENT>
>     ? ? ? ? ? ? encryptedKey:.
>     ? ? ? ? ? ? ? 0000 - f9 b1 b1 28 2a 0c ea e5-eb 3b 0f 22 a5 f4?
>     ?...(*....;."..
>     ? ? ? ? ? ? ? 000e - 51 8e 22 a3 76 4f fe 01-6f 26 37 b5 24 1c?
>     ?Q.".vO..o&7.$.
>     ? ? ? ? ? ? ? 001c - 20 ba 9f 1a 11 92 25 a5-e4 4e 79 6f? ? ? ? ?
>     .....%..Nyo
>     ? ? encryptedContentInfo:.
>     ? ? ? contentType: pkcs7-data (1.2.840.113549.1.7.1)
>     ? ? ? contentEncryptionAlgorithm:.
>     ? ? ? ? algorithm: aes-256-cbc (2.16.840.1.101.3.4.1.42)
>     ? ? ? ? parameter: OCTET STRING:
>     ? ? ? ? ? 0000 - c4 12 53 6c 1f 04 ee 3a-2f 19 43 6f 87 0c af?
>     ?..Sl...:/.Co...
>     ? ? ? ? ? 000f - 9b? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?.
>     ? ? ? encryptedContent:.
>     ? ? ? ? 0000 - 9f 18 ea 29 08 26 f5 8c-7c 69 ae 23 f2 ca 95?
>     ?...).&..|i.#...
>     ? ? ? ? 000f - 76? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?v
>     ? ? unprotectedAttrs:
>     ? ? ? <EMPTY>
>     ========
> 
>     As you can see it has reference to one recipient, identified by his
>     subjectKeyIdentifier. By some reason
>     RecipientInfos/d.kari/d.originatorKey also includes full public key
>     from recipient's certificate. Questions:
> 
>     1. Why is it required?
>     2. Is it possible to omit it since it is superfluous (IMHO) ?
>     3.
>     https://github.com/openssl/openssl/blob/master/crypto/cms/cms_kari.c#L386
>     (and RFC) say that there could be either key, subjectandserial or
>     subjectkeyidentifier. So, how to set it using command line openssl
>     application ?
> 
>     -- 
>     Segmentation fault
> 
> 
>     ------------------------------
> 
>     Subject: Digest Footer
> 
>     _______________________________________________
>     openssl-users mailing list
>     openssl-users at openssl.org <mailto:openssl-users at openssl.org>
>     https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
>     ------------------------------
> 
>     End of openssl-users Digest, Vol 47, Issue 47
>     *********************************************
> 
> 

From skip at taygeta.com  Fri Oct 26 18:16:10 2018
From: skip at taygeta.com (Skip Carter)
Date: Fri, 26 Oct 2018 11:16:10 -0700
Subject: [openssl-users] ssl_accept failure
In-Reply-To: <f2a0faaf-12f7-6c0e-1bdd-b793bbfbe5fe@openssl.org>
References: <1540420448.4886.36.camel@taygeta.com>
 <f2a0faaf-12f7-6c0e-1bdd-b793bbfbe5fe@openssl.org>
Message-ID: <1540577770.4886.40.camel@taygeta.com>

On Fri, 2018-10-26 at 10:07 +0100, Matt Caswell wrote:

> How did you generate this error string? It looks like you might have
> taken the return value (5) from SSL_get_error() and stuffed it into
> ERR_error_string() or a similar function. That would give you output
> like this - but is the incorrect way of doing things.
> 

Yeah, thats what I did.  After looking at the docs more carefully, I
think I am now handling the error properly.  But I am still stuck:

   ret = ERR_get_error();

is returning 0, so there is no error queue to interpret, and errno is
0.


-- 
Skip Carter
Taygeta Scientific Inc.

From kgoldman at us.ibm.com  Fri Oct 26 21:08:07 2018
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Fri, 26 Oct 2018 17:08:07 -0400
Subject: [openssl-users] Using (not building) openssl with mingw on Windows
	10
Message-ID: <pqvvjb$phc$1@blaine.gmane.org>

I've been happily using the Shining Light 32-bit binaries with both 
openssl 1.0 and 1.1 and mingw.

On a new machine, I tried the 64-bit binaries.  However, they're missing 
the openssl/lib/mingw directory where the .a files resided.

It looks like the link procedure changed.  Any hints before I start 
experimenting?


From skip at taygeta.com  Fri Oct 26 22:12:23 2018
From: skip at taygeta.com (Skip Carter)
Date: Fri, 26 Oct 2018 15:12:23 -0700
Subject: [openssl-users] cipher suites
Message-ID: <1540591943.4886.43.camel@taygeta.com>

If my application will support both TLSv1.2 and TLSv1.3 connections to
it (depending who is connecting), do I have to call both
SSL_CTX_set_ciphersuites() and SSL_CTX_set_cipher_list() when setting
up my context?


-- 
Skip Carter
Taygeta Scientific Inc.

From openssl-users at dukhovni.org  Fri Oct 26 22:47:27 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 26 Oct 2018 18:47:27 -0400
Subject: [openssl-users] cipher suites
In-Reply-To: <1540591943.4886.43.camel@taygeta.com>
References: <1540591943.4886.43.camel@taygeta.com>
Message-ID: <F3EFDD3A-EBDB-4B62-B6F8-3A141BDDCD40@dukhovni.org>

You don't have to call either.  Both have sensible defaults.
Especially, with TLS 1.3, there is generally little reason
to choose non-default ciphers.

> On Oct 26, 2018, at 6:12 PM, Skip Carter <skip at taygeta.com> wrote:
> 
> If my application will support both TLSv1.2 and TLSv1.3 connections to
> it (depending who is connecting), do I have to call both
> SSL_CTX_set_ciphersuites() and SSL_CTX_set_cipher_list() when setting
> up my context?

If you're doing something unusual, or provide a configurable interface
with optional overrides of the ciphers to the application users, you
can customize either or both lists.

-- 
	Viktor.


From paul.dale at oracle.com  Mon Oct 29 01:09:45 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Sun, 28 Oct 2018 18:09:45 -0700 (PDT)
Subject: [openssl-users] Low severity timing attack in ECDSA (CVE-2018-0735)
Message-ID: <65ac4276-79b0-48fa-88d2-98ff52ad8cf8@default>

Timing vulnerability in ECDSA signature generation (CVE-2018-0735)
==================================================================

Severity: Low

The OpenSSL ECDSA signature algorithm has been shown to be vulnerable to a
timing side channel attack. An attacker could use variations in the signing
algorithm to recover the private key.

Due to the low severity of this issue we are not issuing a new release
of OpenSSL 1.1.1 or 1.1.0 at this time. The fix will be included in
OpenSSL 1.1.1a and OpenSSL 1.1.0j when they become available. The fix
is also available in commit b1d6d55ece (for 1.1.1) and commit 56fb454d28
(for 1.1.0) in the OpenSSL git repository.

This issue was reported to OpenSSL on 25th October 2018 by Samuel Weiser.

References
==========

URL for this Security Advisory:
https://www.openssl.org/news/secadv/20181029.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



Pauli
-- 
Oracle
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217
Oracle Australia

From takahashi.akira.58s at kyoto-u.jp  Mon Oct 29 05:27:38 2018
From: takahashi.akira.58s at kyoto-u.jp (Akira Takahashi)
Date: Mon, 29 Oct 2018 14:27:38 +0900
Subject: [openssl-users] Using SM2 ECIES in 1.1.1
In-Reply-To: <92097423-88c0-5a7d-9395-a84195b257d6@openssl.org>
References: <f4163a25-e9b6-f60b-b3ea-8aadf2c190fe@kyoto-u.jp>
 <92097423-88c0-5a7d-9395-a84195b257d6@openssl.org>
Message-ID: <3a9ae1bc-2f8c-b0d7-c427-a8f0a4704f54@kyoto-u.jp>

Thanks a lot for your advice.
Just calling EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2) right after loading a key worked perfectly and I was able to reuse the code in pkeyutl since everything else was indeed almost identical to RSA!

Best regards,
Akira

On 10/25/2018 12:14 AM, Matt Caswell wrote:
>
> On 24/10/2018 15:55, Akira Takahashi wrote:
>> Hi all,
>>
>>
>> Since the version 1.1.1 supports the SM2 public key cryptography suite I
>> am trying to test its ECIES (found in crypto/sm2/sm2_crypto.c) over
>> different standardized prime curves i.e. not just sm2p256v1.
>>
>> Is there CLI or minimal code snippet to achieve it via the EVP interface?
>>
>> The current man page of SM2 seems to only describe SM2 as a signature
>> algorithm, but not as a public key encryption.
> You can use the EVP_PKEY_encrypt() function for this purpose.
>
> A generic example (not SM2 specific) is on the EVP_PKEY_encrypt() man page:
>
> https://www.openssl.org/docs/man1.1.1/man3/EVP_PKEY_encrypt.html
>
> Doing this for SM2 is essentially the same as shown in that example
> except of course don't call the RSA specific
> EVP_PKEY_CTX_set_rsa_padding() function.
>
> Setting up of the EVP_PKEY itself to contain an SM2 key is the same as
> for sign/verify, i.e. you need to call EVP_PKEY_set_alias_type(). There
> is no need to set an id though. See:
>
> https://www.openssl.org/docs/man1.1.1/man7/SM2.html
>
> Hope that helps,
>
> Matt


From jb-openssl at wisemo.com  Mon Oct 29 11:18:58 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 29 Oct 2018 12:18:58 +0100
Subject: [openssl-users] Using (not building) openssl with mingw on
 Windows 10
In-Reply-To: <pqvvjb$phc$1@blaine.gmane.org>
References: <pqvvjb$phc$1@blaine.gmane.org>
Message-ID: <09f436c6-a225-3d6a-540d-361026bc95b2@wisemo.com>

On 26/10/2018 23:08, Ken Goldman wrote:
> I've been happily using the Shining Light 32-bit binaries with both 
> openssl 1.0 and 1.1 and mingw.
>
> On a new machine, I tried the 64-bit binaries.? However, they're 
> missing the openssl/lib/mingw directory where the .a files resided.
>
> It looks like the link procedure changed.? Any hints before I start 
> experimenting?
>
Note that Win32 (Microsoft) .LIB files are actually standard unix-style
.a files with the file names changed to match the the historic
MS-DOS/Win16 practice (which had a different file format).

So it is highly likely the .LIB files can be used with mingw by just
copying/symlinking them, or even just using a Mingw option to load
.LIB files.

Beware however of the crazy GNU interpretation that listing a library
file explicitly means include *all* the code from the library, not
just the referenced object files.

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 paul.dale at oracle.com  Mon Oct 29 21:03:59 2018
From: paul.dale at oracle.com (Paul Dale)
Date: Mon, 29 Oct 2018 14:03:59 -0700 (PDT)
Subject: [openssl-users] Low severity timing attack in DSA (CVE-2018-0734)
Message-ID: <227e9c98-90e5-47ed-b548-1b3bff5de66b@default>

Timing vulnerability in DSA signature generation (CVE-2018-0734) 
================================================================ 
  
Severity: Low 
  
The OpenSSL DSA signature algorithm has been shown to be vulnerable to a 
timing side channel attack. An attacker could use variations in the signing 
algorithm to recover the private key. 
  
Due to the low severity of this issue we are not issuing a new release 
of OpenSSL 1.1.1, 1.1.0 or 1.0.2 at this time. The fix will be included 
in OpenSSL 1.1.1a, OpenSSL 1.1.0j and OpenSSL 1.0.2q when they become 
available. The fix is also available in commit 8abfe72e8c (for 1.1.1), 
ef11e19d13 (for 1.1.0) and commit 43e6a58d49 (for 1.0.2) in the OpenSSL 
git repository. 
  
This issue was reported to OpenSSL on 16th October 2018 by Samuel Weiser. 
  
References 
========== 
  
URL for this Security Advisory: 
https://www.openssl.org/news/secadv/20181030.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 <https://www.openssl.org/policies/secpolicy.html> 
  
  
Pauli 
-- 
Oracle 
Dr Paul Dale | Cryptographer | Network Security & Encryption 
Phone +61 7 3031 7217 
Oracle Australia 
  

-----BEGIN PGP MESSAGE----- 
Version: GnuPG v2 

owGlVGtsFFUU3j4kMHRThCYEELyQCm3ZZ7cvCkUXlodSaNltEaSF3s7c3Rk6O3eZ 
me2wWOWRtipSqaFQEBAt8ggEtVSKUiQQEaxEQXkUKAjlIZZHKVVIsJh4Z7pLiz9M 
jDubzJ17znzn+8755lbqI3S9w9qbpw8/fMppDTt+q1A3t8n/eQ7n5QQPKPbzAhJh 
IcdzcgBwAnC47EDiPAKU/SICHqRGZQ4LIG7irEnGRIs1zWhJtSXF66mM//nTU0BP 
uVAxEknpdJCJFW0nh0Ugy4cElyvzH2Qg78Ekl/UCFkqgECEBSCxWBCBj8vRECo/U 
Dain5C6JEscgQLNQEBAPoCxDusgE7EJwiURAYz/PAL9EIKDIaWoltRUyYaJWJyB6 
qrs4ARcRjQlvLcMncsVQRqAIBUyaAIdfI6DGeKwAKagQYDfZ4wiyJJEMheghmgQs 
axsqUQgEpBBsHkEJ6SmSH+qD1UQug3azACyShcWUSAR0ARKdyATUvrm5RUDheF5t 
ByfQvJ9BjJ4iUp4Cgoanni0LABSYHlsEeyFQWKR1IECwaOwlfGAx5Hi1vd21SHHI 
S6TZoZDaNpLt5WSQBgvdKDURpdEgzq1xJle8QU8ht9WKrGMYq607YInXOARfTbKh 
FJicxiSNCWUQSvGhkQSJ6ikPSRWRD0ucjMVg83N6dJiYRA2LMmLUgYQEEi9bU2QW 
ZNEyLiRDVD0NCgPABb1+4pBXESchsQvNidxIRAKNpJ5210K5zkygctMm4EK0X5ux 
nSnmJEImXU+xsuyT0s1mRVFMmJSWJN6ERY+ZzFgyS4iGTLFZLW212CwmeZGsoc7A 
MkrXVGKB5wTiSCRK6tenmYdYJogPvFAdDPD7GKjKU4gzSZDhVPNCHjBIJhMhrLts 
qhpEw59MGB8qCEZBD4c9cSnNQ0ni3Bwd/A58mhtJHP2LJh/mOZpDmi5tHTCxspcH 
4/7jC+OBxpL8s6Gf5/SU0UjWWSKkeWJAhwjUbeCAxGglYKIY8MnYI0IfSzSWgBlI 
VrBY1D2MkWCSQKtJagMJJItJQ0enWEEqsFls5JZoTQ2hA7tfkkXIc+TcAO+EPxep 
C+ut6/VMuHpU6qg+/ULn5+N70Y+j+lWuPFFfv3VnR+ydNvn7BuNiZppp5qOpytsv 
dxTZyyOX13x897uduWt2Xq5/ccINV0ZceEHDVbFyx7bzx6rfYHJbBsyPBZ0j4w7U 
Xg6PnLNw3wZzY1TM7YJ555K/eeDsXdJ/q27jlb5jseXi/Y6Mt/JMB2uMRdKttXtG 
n//MsKrk9B8FWa1U1keXTj2y39V9vX/28gGrGsfsurNp4xex7KOqptboHMdiHlyq 
s+3ZPHzfjCUroLO67MvM9rKfA5uyJ9qGrIsurWialbnDvf/H/Pdf6uyztPWIcXPY 
uxsmiGej7g9aPWp0xoq9+bveq+i8Oflk9Q9VK2L61rKzY/JeH5LvPlbnzvsp1jgq 
e430uHbKhG/bq9ZPP3ArwdZ25mFt0tznqZw+eCAcVtpyIdxnoE7v2sJUJiRfwW8O 
Przl3gtO8UjOgbas+jNjP4mxrj2uNNyYEzHCXXezPL/loX3l7311Z8Vq5y/nfru6 
yV1f4ZvuHTSt2Tgs8VO2ctzA/rVFEWUXI6p/NQyu2F4W3XRt37ENSzvm8MuTbzfY 
Fh3EzzZc+qv1+itLpuz5oH3mqqXNkVtLdLsf1kZtnLqs+c91pvmZ/hrdA8OCxpM1 
WRWrz+5tdpe3DC2lxl24OHTEMsfhlFkJjeOvxc9bb9zeWNpYZ9/RfvS1rxznK2q2 
3anPjumEebkR5vEfnqi6ktCr39Hd1+MPTdO1/Q0= 
=VVHo 
-----END PGP MESSAGE----- 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181029/c1fd850c/attachment-0001.html>

From jaspreetcj at gmail.com  Tue Oct 30 11:00:47 2018
From: jaspreetcj at gmail.com (Jaspreetcj)
Date: Tue, 30 Oct 2018 04:00:47 -0700 (MST)
Subject: [openssl-users] Connect to a host from a machine behind internet
	proxy
Message-ID: <1540897247917-0.post@n7.nabble.com>

Hi,
I am trying to connect to a host using openSSL from a machine which is
behind a internet proxy.

How do I connect using connect command and configure the proxy.

Any command such as -- proxy ?




--
Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html

From ppohja at gmail.com  Tue Oct 30 23:52:09 2018
From: ppohja at gmail.com (Pietu Pohjalainen)
Date: Wed, 31 Oct 2018 01:52:09 +0200
Subject: [openssl-users] Verifying Android hardware attestation certificates
	with OpenSSL
Message-ID: <CALixA8kzJ-U0E+yKk8d4ck72fARafsZS2Fwkj_Z9Kjy4+ordDA@mail.gmail.com>

Dear all,

I have been trying to verify hardware attestation certificates originating
from different Android phones with the OpenSSL tool. There seems to be not
too much information about how are these supposed to work. With OpenSSL I'm
getting mixed results.

Android developer spec for certificate extension data schema is available at
https://developer.android.com/training/articles/security-key-attestation and
is linking to a few years old Java code example at
https://github.com/googlesamples/android-key-attestation . Unfortunately
this Java code has not been updated to match later versions of key
attestation, and it fails with many of my real world use cases.

The OpenSSL command shipping with Mac OS 10.13 (LibreSSL 2.2.7) fails even
to parse these certificates.

OpenSSL 1.1.0g shipping with Ubuntu parses all of my example certificates
just fine. However, trying to verify certificate chains sometime succeeds,
sometime fails. ver 1.1.2-dev follows the same pattern.

So far, I have figured out the following patterns:
- Certificate chain extracted from a real world device is either 3 or 4
certificates.
- When the chain is 4 certificates, the last one is equal to Google's root
certificate found in the Java code example
https://github.com/googlesamples/android-key-attestation/blob/master/server/src/main/java/com/android/example/KeyAttestationExample.java
- When the chain is 3 certificates, the middle and last certificates are
always the same.

- Out of these 8 real world chains, I'm having
* 3 cases where OpenSSL verifies the chain just nice - branches a, g and h
in the upcoming transcript.
* 1 case where OpenSSL gives error

error 20 at 0 depth lookup: unable to get local issuer certificate

error f1.pem: verification failed

139747492622784:error:0D07207B:asn1 encoding
routines:ASN1_get_object:header too long:crypto/asn1/asn1_lib.c:101:

139747492622784:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad
object header:crypto/asn1/tasn_dec.c:1118:
139747492622784:error:0D08303A:asn1 encoding
routines:asn1_template_noexp_d2i:nested asn1
error:crypto/asn1/tasn_dec.c:553:
* 4 cases where OpenSSL gives error

error 20 at 0 depth lookup: unable to get local issuer certificate
error e1.pem: verification failed

The hardware devices are in somewhat random order, as follows:
a: Nokia 8 running Android 8.1
b: Motorola Moto Z running Android 7.1.1
c: Nokia 1 running Android 8.1
d: Nokia 2 running Android 7.1.1
e: Sony Oneplus A5000 running Android 7.1.1
f: Huawei Honor 8 running Android 7.0
g: Nokia 5.1 running Android 8.0
h: OnePlus 3T running Android 8.0


Due to other OpenSSL implementations failing to even parse these
certificates, I'm now in doubt is it my wrong usage pattern, certificates
that are really faulty, or is this a bug with OpenSSL.


br,
Pietu

--- clip ---

Here's my full set of files and commands tried:

$ /usr/local/bin/openssl version

OpenSSL 1.1.2-dev  xx XXX xxxx


$ md5sum a2.pem b2.pem d2.pem e2.pem f2.pem h2.pem

2575f8bb229a2c5bc02260dbc8af5575  a2.pem

2575f8bb229a2c5bc02260dbc8af5575  b2.pem

2575f8bb229a2c5bc02260dbc8af5575  d2.pem

2575f8bb229a2c5bc02260dbc8af5575  e2.pem

2575f8bb229a2c5bc02260dbc8af5575  f2.pem

2575f8bb229a2c5bc02260dbc8af5575  h2.pem


$ md5sum a3.pem b3.pem d3.pem e3.pem f3.pem h3.pem

0ec1822cb22ea66f96fc459633dfee78  a3.pem

0ec1822cb22ea66f96fc459633dfee78  b3.pem

0ec1822cb22ea66f96fc459633dfee78  d3.pem

0ec1822cb22ea66f96fc459633dfee78  e3.pem

0ec1822cb22ea66f96fc459633dfee78  f3.pem

0ec1822cb22ea66f96fc459633dfee78  h3.pem


*$ # Test out chains with 3 certificates - a and h verify fine.*

$ for branch in a; do echo; echo "Checking $branch"; cat "$branch"1.pem
"$branch"2.pem "$branch"3.pem; /usr/local/bin/openssl verify -CAfile <(cat
"$branch"2.pem "$branch"3.pem) "$branch"1.pem; echo; done


Checking a

-----BEGIN CERTIFICATE-----

MIICgDCCAiagAwIBAgIBATAKBggqhkjOPQQDAjCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFTATBgNVBAoMDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDE7MDkGA1UEAwwyQW5kcm9pZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBJbnRlcm1lZGlhdGUwIBcNNzAwMTAxMDAwMDAwWhgPMjEwNjAyMDcwNjI4MTVaMB8xHTAbBgNVBAMMFEFuZHJvaWQgS2V5c3RvcmUgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEDRgbsaYD1OPI5P78IVIJsgQlAIDKIoGl7BAbuV4tkx0Km3tfcoMAwfWL1exnBoAxuw2ZHUhlNUhWE8kyAW7bsaOB5jCB4zALBgNVHQ8EBAMCB4AwgbIGCisGAQQB1nkCAREEgaMwgaACAQIKAQACAQEKAQEEC2hlbGxvIHdvcmxkBAAwSr+FPQgCBgFmrBioCL+FRToEODA2MRAwDgQJY29tLnB5eXBsAgEMMSIEIIMi9g2//U87C53x3twp61y6K1+22oaTkEjGgyTgXw37MDehBTEDAgECogMCAQOjBAICAQClCzEJAgEEAgEFAgEGqgMCAQG/g3cCBQC/hT4DAgEAv4U/AgUAMB8GA1UdIwQYMBaAFD/8rNYasTqegSC41SUcxWW7HpGpMAoGCCqGSM49BAMCA0gAMEUCIQC+ty2c6G69zydlw3mhdTV0C+IMN45WIxC4K4kpvQIT2wIgBE48WjBNlRTH3RWURiL1oIriLcfTlN7sKeMVkeH1PCU=

-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----

MIICeDCCAh6gAwIBAgICEAEwCgYIKoZIzj0EAwIwgZgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRYwFAYDVQQHDA1Nb3VudGFpbiBWaWV3MRUwEwYDVQQKDAxHb29nbGUsIEluYy4xEDAOBgNVBAsMB0FuZHJvaWQxMzAxBgNVBAMMKkFuZHJvaWQgS2V5c3RvcmUgU29mdHdhcmUgQXR0ZXN0YXRpb24gUm9vdDAeFw0xNjAxMTEwMDQ2MDlaFw0yNjAxMDgwMDQ2MDlaMIGIMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTswOQYDVQQDDDJBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9uIEludGVybWVkaWF0ZTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABOueefhCY1msyyqRTImGzHCtkGaTgqlzJhP+rMv4ISdMIXSXSir+pblNf2bU4GUQZjW8U7ego6ZxWD7bPhGuEBSjZjBkMB0GA1UdDgQWBBQ//KzWGrE6noEguNUlHMVlux6RqTAfBgNVHSMEGDAWgBTIrel3TEXDo88NFhDkeUM6IVowzzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB/wQEAwIChDAKBggqhkjOPQQDAgNIADBFAiBLipt77oK8wDOHri/AiZi03cONqycqRZ9pDMfDktQPjgIhAO7aAV229DLp1IQ7YkyUBO86fMy9Xvsiu+f+uXc/WT/7

-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----

MIICizCCAjKgAwIBAgIJAKIFntEOQ1tXMAoGCCqGSM49BAMCMIGYMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2FsaWZvcm5pYTEWMBQGA1UEBwwNTW91bnRhaW4gVmlldzEVMBMGA1UECgwMR29vZ2xlLCBJbmMuMRAwDgYDVQQLDAdBbmRyb2lkMTMwMQYDVQQDDCpBbmRyb2lkIEtleXN0b3JlIFNvZnR3YXJlIEF0dGVzdGF0aW9uIFJvb3QwHhcNMTYwMTExMDA0MzUwWhcNMzYwMTA2MDA0MzUwWjCBmDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFjAUBgNVBAcMDU1vdW50YWluIFZpZXcxFTATBgNVBAoMDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDEzMDEGA1UEAwwqQW5kcm9pZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBSb290MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7l1ex+HA220Dpn7mthvsTWpdamguD/9/SQ59dx9EIm29sa/6FsvHrcV30lacqrewLVQBXT5DKyqO107sSHVBpKNjMGEwHQYDVR0OBBYEFMit6XdMRcOjzw0WEOR5QzohWjDPMB8GA1UdIwQYMBaAFMit6XdMRcOjzw0WEOR5QzohWjDPMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgKEMAoGCCqGSM49BAMCA0cAMEQCIDUho++LNEYenNVg8x1YiSBq3KNlQfYNns6KGYxmSGB7AiBNC/NR2TB8fVvaNTQdqEcbY6WFZTytTySn502vQX3xvw==

-----END CERTIFICATE-----


a1.pem: OK



*$ #for keeping msg length in moderation, not duplicating root and
intermediate certificates*

$ for branch in b d e f h; do echo; echo "Checking $branch"1.pem; cat
"$branch"1.pem; /usr/local/bin/openssl verify -CAfile <(cat "$branch"2.pem
"$branch"3.pem) "$branch"1.pem; echo; done


Checking b1.pem

-----BEGIN CERTIFICATE-----

MIIBzTCCAXOgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIEtleW1hc3RlcjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBYGA1UEAwwPQSBLZXltYXN0ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEuvoG6Aobkj6eP+Q4bCf7vIY2hLvsQ9rRKG0mdD1YDPoE7lnth4ekSa+lhlMnieHrsH2pnGLZxP4jZoSk3GQdJaOBpTCBojALBgNVHQ8EBAMCB4AwcgYKKwYBBAHWeQIBEQRkMGICAQEKAQACAQEKAQEEC2hlbGxvIHdvcmxkBAAwDL+FPQgCBgFmrHjFgDA3oQUxAwIBAqIDAgEDowQCAgEApQsxCQIBBAIBBQIBBqoDAgEBv4N3AgUAv4U+AwIBAL+FPwIFADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNIADBFAiEA+atKJFXAli8iI4u42gP+dRCarhtXYTPvSx4gBUoGWEsCIGdA9chHpZmRaNYr+oODruhF+Q1xIyLJYX+pq2q6wHvl

-----END CERTIFICATE-----


CN = A Keymaster Key

error 20 at 0 depth lookup: unable to get local issuer certificate

error b1.pem: verification failed



Checking d1.pem

-----BEGIN CERTIFICATE-----

MIIB1zCCAX2gAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIEtleW1hc3RlcjAeFw03MDAxMDEwMDAwMDBaFw02OTEyMzEyMzU5NTlaMBoxGDAWBgNVBAMMD0EgS2V5bWFzdGVyIEtleTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABD2A/WLrFMSEGX3XdgKDlxcTAstZnlXgJRZsLC+Z55JR80UYfNgV7EfN3arpKMuJ3fFJ/cYEoACTLHjinhmXVFijgbEwga4wCwYDVR0PBAQDAgeAMH4GCisGAQQB1nkCAREEcDBuAgEBCgEAAgECCgEABAtoZWxsbyB3b3JsZAQAME+hBTEDAgECogMCAQOjBAICAQClCzEJAgEEAgEFAgEGqgMCAQG/g3cCBQC/hT0IAgYBZq9Wdbi/hT4DAgEAv4VBBQIDARHVv4VCBQIDAxRPMAAwHwYDVR0jBBgwFoAUP/ys1hqxOp6BILjVJRzFZbsekakwCgYIKoZIzj0EAwIDSAAwRQIhAObHcoPKw6ntrXr+EC7HmGJO9heDbSuFMjO9sbcOw6rYAiBXtqcI6p0VCDN+jPtztLYtxeqkCnZYDve8MTkrReNSJQ==

-----END CERTIFICATE-----


CN = A Keymaster Key

error 20 at 0 depth lookup: unable to get local issuer certificate

error d1.pem: verification failed



Checking e1.pem

-----BEGIN CERTIFICATE-----

MIIBzTCCAXOgAwIBAgIBATAKBggqhkjOPQQDAjAcMRowGAYDVQQDDBFBbmRyb2lkIEtleW1hc3RlcjAgFw03MDAxMDEwMDAwMDBaGA8yMTA2MDIwNzA2MjgxNVowGjEYMBYGA1UEAwwPQSBLZXltYXN0ZXIgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE+KjC/Y5eImDnRgreH+fZeXj9r4725cHz3T8p7wCyWJKajku2c8khAJepG4fUEqHwiggPj7V5IWhaxzi29g7U1aOBpTCBojALBgNVHQ8EBAMCB4AwcgYKKwYBBAHWeQIBEQRkMGICAQEKAQACAQEKAQEEC2hlbGxvIHdvcmxkBAAwDL+FPQgCBgFmr+53yDA3oQUxAwIBAqIDAgEDowQCAgEApQsxCQIBBAIBBQIBBqoDAgEBv4N3AgUAv4U+AwIBAL+FPwIFADAfBgNVHSMEGDAWgBQ//KzWGrE6noEguNUlHMVlux6RqTAKBggqhkjOPQQDAgNIADBFAiEAmm+LNCeZRpBBHUxXGVU9VC/fxEwoLfbC3x7UNCd3ra4CIAW9JO5u6msXwvix4QD0OSBrdrzUCzuS9ItwfjZv+mB3

-----END CERTIFICATE-----


CN = A Keymaster Key

error 20 at 0 depth lookup: unable to get local issuer certificate

error e1.pem: verification failed



Checking f1.pem

-----BEGIN CERTIFICATE-----

MIIB/TCCAaSgAwIBAgIBATAKBggqhkjOPQQDAjAdMRswGQYDVQQDExJBbmRyb2lkIEtleW1hc3RlcjIwHhcNNzAwMTAxMDAwMDAwWhcNMDYwMjA3MDYyODE1WjAaMRgwFgYDVQQDEw9BIEtleW1hc3RlciBLZXkwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASiqHWB8dQg1/Fw67gZvYqIq2WZvbWFll4W5y2uz0UymS34g0FMGkwsJqAlnCquVFraoiaJH35x+jPrGqmdXy6Mo4HXMIHUMAsGA1UdDwQEAwIHgDAIBgNVHR8EAQAwgboGCisGAQQB1nkCAREEgaswgagCAQEKAQECAQIKAQEEC2hlbGxvIHdvcmxkBAAwJL+DdwIFAL+FPQgCBgFmxPuCBb+FQQUCAwERcL+FQgUCAwMUUDBloQUxAwIBAqIDAgEDowQCAgEApQUxAwIBBKoDAgEBv4U+AwIBAL+FQCowKAQgU0HmsmRpeacOV2UwB6HzEBaUIeyb3Z8aVkj3Wt4AWvEBAf8KAQC/hUEFAgMBEXC/hUIFAgMDFFAwCgYIKoZIzj0EAwIDRwAwRAIgEH9o6neMfv7o6ixwUkL4t7r5uS9FbMGAS9Pt9St9qecCICKhqBjZBisaGDSqE3Qo2vFUpvtB03tDHqlzScWXbry1

-----END CERTIFICATE-----



CN = A Keymaster Key

error 20 at 0 depth lookup: unable to get local issuer certificate

error f1.pem: verification failed

140121898299840:error:0D07207B:asn1 encoding
routines:ASN1_get_object:header too long:crypto/asn1/asn1_lib.c:101:

140121898299840:error:0D068066:asn1 encoding routines:asn1_check_tlen:bad
object header:crypto/asn1/tasn_dec.c:1118:

140121898299840:error:0D08303A:asn1 encoding
routines:asn1_template_noexp_d2i:nested asn1
error:crypto/asn1/tasn_dec.c:553:



Checking h1.pem

-----BEGIN CERTIFICATE-----

MIICgDCCAiagAwIBAgIBATAKBggqhkjOPQQDAjCBiDELMAkGA1UEBhMCVVMxEzARBgNVBAgMCkNhbGlmb3JuaWExFTATBgNVBAoMDEdvb2dsZSwgSW5jLjEQMA4GA1UECwwHQW5kcm9pZDE7MDkGA1UEAwwyQW5kcm9pZCBLZXlzdG9yZSBTb2Z0d2FyZSBBdHRlc3RhdGlvbiBJbnRlcm1lZGlhdGUwIBcNNzAwMTAxMDAwMDAwWhgPMjEwNjAyMDcwNjI4MTVaMB8xHTAbBgNVBAMMFEFuZHJvaWQgS2V5c3RvcmUgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE99dbLWDWw+j/h1MO8Sap27sC+wnjS3w4I2FIea+Tw8AzjCnG3F9tqNwPEDP1Y/NILB0TqgLQ8sKwxXrxXR7yW6OB5jCB4zALBgNVHQ8EBAMCB4AwgbIGCisGAQQB1nkCAREEgaMwgaACAQIKAQACAQEKAQEEC2hlbGxvIHdvcmxkBAAwSr+FPQgCBgFmxQWrGL+FRToEODA2MRAwDgQJY29tLnB5eXBsAgEMMSIEIIMi9g2//U87C53x3twp61y6K1+22oaTkEjGgyTgXw37MDehBTEDAgECogMCAQOjBAICAQClCzEJAgEEAgEFAgEGqgMCAQG/g3cCBQC/hT4DAgEAv4U/AgUAMB8GA1UdIwQYMBaAFD/8rNYasTqegSC41SUcxWW7HpGpMAoGCCqGSM49BAMCA0gAMEUCIDyO1O3bN1RqAPlmEku6Bm64EZVsnXP2AUqABbh5uZQmAiEApb4XgXemFO2By1Uk/2YSTmZY8wKUAf4ZsWCc6+fxiio=

-----END CERTIFICATE-----


h1.pem: OK



*# Test out chains with 4 certificates - g verifies fine.*

$ for branch in c g; do echo; echo "Checking $branch"; cat "$branch"1.pem
"$branch"2.pem "$branch"3.pem "$branch"4.pem; /usr/local/bin/openssl verify
-CAfile <(cat "$branch"2.pem "$branch"3.pem "$branch"4.pem) "$branch"1.pem;
echo; done


Checking c

-----BEGIN CERTIFICATE-----

MIICUTCCAfagAwIBAgIBATAKBggqhkjOPQQDAjAbMRkwFwYDVQQFExA5NWU3MzI4NzZiNjUxNjhkMCIYDzE5MDAwMTAwMDAwMDAwWhgPMTkwMDAxMDAwMDAwMDBaMB8xHTAbBgNVBAMMFEFuZHJvaWQgS2V5c3RvcmUgS2V5MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE7Sd6FaAz8BONTGJvtGw5AIaiLhGH4ILfaD9OKzLYjfjB/nTcW6ti+CjSMtaROpXzbuYh6IgCGlD089gPnP5+BaOCASEwggEdMAsGA1UdDwQEAwIHgDCB7AYKKwYBBAHWeQIBEQSB3TCB2gIBAgoBAQIBAwoBAQQLaGVsbG8gd29ybGQEADBKv4U9CAIGAWasjANIv4VFOgQ4MDYxEDAOBAljb20ucHl5cGwCAQwxIgQggyL2Db/9TzsLnfHe3CnrXLorX7bahpOQSMaDJOBfDfswcaEFMQMCAQKiAwIBA6MEAgIBAKULMQkCAQQCAQUCAQaqAwIBAb+DdwIFAL+FPgMCAQC/hUAqMCgEIE15D6Cl/oHWs1K5Cv5DBoTZvIF1GM0kxQ5jQzlffFHyAQEBCgEAv4VBBQIDATjkv4VCBQIDAxRQMB8GA1UdIwQYMBaAFBuQe659NNU7MawBkucw39T1flt2MAoGCCqGSM49BAMCA0kAMEYCIQC14bLPGSNXwYUrFzO3Xno7WLHCy1wFtcP+mXCnVlvCngIhAMX60lRiVTvfl2Bq09opnfb3Y7QgE0DViuhheQyNSvL4

-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----

MIICKzCCAbKgAwIBAgIKFhlXZkYXJGEUNDAKBggqhkjOPQQDAjAbMRkwFwYDVQQFExA1YjAzNTljY2E4ODc5Y2I1MB4XDTE2MDUyNjE2NTQxNloXDTI2MDUyNDE2NTQxNlowGzEZMBcGA1UEBRMQOTVlNzMyODc2YjY1MTY4ZDBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABJoEzxn1L0hLklubtqi8kvk9KEJf4nu8UB7EfcHn5zGbONW9HGgwBlq5X5llRvmNUToPcgbI3sHOvFoHky5nrgyjgd0wgdowHQYDVR0OBBYEFBuQe659NNU7MawBkucw39T1flt2MB8GA1UdIwQYMBaAFAbd7gqSHZtx4caJQUTvOTlwJgA1MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgeAMCQGA1UdHgQdMBugGTAXghVpbnZhbGlkO2VtYWlsOmludmFsaWQwVAYDVR0fBE0wSzBJoEegRYZDaHR0cHM6Ly9hbmRyb2lkLmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC8xNjE5NTc2NjQ2MTcyNDYxMTQzNDAKBggqhkjOPQQDAgNnADBkAjAMeVZ84Z55FM2+nOrljCQlb7xpdiYDTc96LQyh8OE6EZj8jkQQL9Lh3MT5p5lZ+QsCMGLwHkdPAeD1M8PYEJRyurfC4EYV1k3zJowZbRmYu3N8ztCb3FBgE+1oJpxEPNXIGQ==

-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----

MIIDwzCCAaugAwIBAgIKA4gmZ2BliZaFczANBgkqhkiG9w0BAQsFADAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MB4XDTE2MDUyNjE2NDEyOVoXDTI2MDUyNDE2NDEyOVowGzEZMBcGA1UEBRMQNWIwMzU5Y2NhODg3OWNiNTB2MBAGByqGSM49AgEGBSuBBAAiA2IABHf4FUKTZivDuwdyVbXyPF12IRuDzZKq61MbqooE3/gx9gIS9pFS4NZgGTnjSMm6ltYrCv3sDzuPQls+V+BLPQgNfRHavmP9eulc1uR3GNgCnKqxB2o0QcTQGPAxJA81c6OBtjCBszAdBgNVHQ4EFgQUBt3uCpIdm3HhxolBRO85OXAmADUwHwYDVR0jBBgwFoAUNmHhAHyIBQlRi0RsR/8aTMnqTxIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cHM6Ly9hbmRyb2lkLmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC9FOEZBMTk2MzE0RDJGQTE4MA0GCSqGSIb3DQEBCwUAA4ICAQAsPFNbAeVGRXKg0H1Ixy31n+vc1GAtLTtdruQGZ3rk6Dq3G5OiNfwLI4vRowDERgTr5RoVRMLs9HzTTCvvdEBhcILKOnaPAd6Jg4HvBi8hsfbXEvRi2kmIfiYAabC71ErJLFEMprTJMSDEOe3lXCJG409z99ofsf/s1M1i77NFVCwstAvRLMjc9TjxRXrGrGD0rMdG2RkionXa3H+4cYqSUf7JCIW6dMB2p+4R3n463DqxxSJNGbchGGUbL6b0qIWdaVcwG2ro+WyItfyw5C4h9XSosauyC9ajjZLt8RAK2ouZHN/kyIXcD1U7IFbSy0SZfaRDLNCzse4iL6IOnuyITEFLnvLfcDSwNX1/ptBRAeeme7G1nwpeohJjiddmf20e421+n3tWUyUhLk9s83MJQQp+mhfApA1Qvz+a7M3OqPvHhBoeu6C4NOlYkb8mrjtuZ/RU5WIRXfyXZqA05Qnu8usuxxNFozU5hWbXIZQx7at2x/7t8/kgHSJhKs4hWIdbVgIDyWIhgoDD+gqTIRlzTwrS876dgy0MTZm1riMEBB5jvAhaeciDBf8u6AFWnMsS0UVtOinr5lTRkHSwie2n90kazqpkeMUdnbBSG7HSMhyg5lvem9G82NakH4S1EPgRBLN1eF8Q51ZmzeNl3DnIGGjNI+LAXw10KVuEkzgd8A==

-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----

MIIFYDCCA0igAwIBAgIJAOj6GWMU0voYMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNVBAUTEGY5MjAwOWU4NTNiNmIwNDUwHhcNMTYwNTI2MTYyODUyWhcNMjYwNTI0MTYyODUyWjAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAr7bHgiuxpwHsK7Qui8xUFmOr75gvMsd/dTEDDJdSSxtf6An7xyqpRR90PL2abxM1dEqlXnf2tqw1Ne4Xwl5jlRfdnJLmN0pTy/4lj4/7tv0Sk3iiKkypnEUtR6WfMgH0QZfKHM1+di+y9TFRtv6y//0rb+T+W8a9nsNL/ggjnar86461qO0rOs2cXjp3kOG1FEJ5MVmFmBGtnrKpa73XpXyTqRxB/M0n1n/W9nGqC4FSYa04T6N5RIZGBN2z2MT5IKGbFlbC8UrW0DxW7AYImQQcHtGl/m00QLVWutHQoVJYnFPlXTcHYvASLu+RhhsbDmxMgJJ0mcDpvsC4PjvB+TxywElgS70vE0XmLD+OJtvsBslHZvPBKCOdT0MS+tgSOIfga+z1Z1g7+DVagf7quvmag8jfPioyKvxnK/EgsTUVi2ghzq8wm27ud/mIM7AY2qEORR8Go3TVB4HzWQgpZrt3i5MIlCaY504LzSRiigHCzAPlHws+W0rB5N+er5/2pJKnfBSDiCiFAVtCLOZ7gLiMm0jhO2B6tUXHI/+MRPjy02i59lINMRRev56GKtcd9qO/0kUJWdZTdA2XoS82ixPvZtXQpUpuL12ab+9EaDK8Z4RHJYYfCT3Q5vNAXaiWQ+8PTWm2QgBR/bkwSWc+NpUFgNPN9PvQi8WEg5UmAGMCAwEAAaOBpjCBozAdBgNVHQ4EFgQUNmHhAHyIBQlRi0RsR/8aTMnqTxIwHwYDVR0jBBgwFoAUNmHhAHyIBQlRi0RsR/8aTMnqTxIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cHM6Ly9hbmRyb2lkLmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC8wDQYJKoZIhvcNAQELBQADggIBACDIw41L3KlXG0aMiS//cqrG+EShHUGo8HNsw30W1kJtjn6UBwRM6jnmiwfBPb8VA91chb2vssAtX2zbTvqBJ9+LBPGCdw/E53Rbf86qhxKaiAHOjpvAy5Y3m00mqC0w/Zwvju1twb4vhLaJ5NkUJYsUS7rmJKHHBnETLi8GFqiEsqTWpG/6ibYCv7rYDBJDcR9W62BW9jfIoBQcxUCUJouMPH25lLNcDc1ssqvC2v7iUgI9LeoM1sNovqPmQUiG9rHli1vXxzCyaMTjwftkJLkf6724DFhuKug2jITV0QkXvaJWF4nUaHOTNA4uJU9WDvZLI1j83A+/xnAJUucIv/zGJ1AMH2boHqF8CY16LpsYgBt6tKxxWH00XcyDCdW2KlBCeqbQPcsFmWyWugxdcekhYsAWyoSf818NUsZdBWBaR/OukXrNLfkQ79IyZohZbvabO/X+MVT3rriAoKc8oE2Uws6DF+60PV7/WIPjNvXySdqspImSN78mflxDqwLqRBYkA3I75qppLGG9rp7UCdRjxMl8ZDBld+7yvHVgt1cVzJx9xnyGCC23UaicMDSXYrB4I4WHXPGjxhZuCuPBLTdOLU8YRvMYdEvYebWHMpvwGCF6bAx3JBpIeOQ1wDB5y0USicV3YgYGmi+NZfhA4URSh77Yd6uuJOJENRaNVTzk

-----END CERTIFICATE-----


CN = Android Keystore Key

error 20 at 0 depth lookup: unable to get local issuer certificate

error c1.pem: verification failed



Checking g

-----BEGIN CERTIFICATE-----

MIICMzCCAdmgAwIBAgIBATAKBggqhkjOPQQDAjApMRkwFwYDVQQFExBhMTk1Mzk2NGJhMmEyODlkMQwwCgYDVQQMDANURUUwHhcNNzAwMTAxMDAwMDAwWhcNNDkxMjMxMjM1OTU5WjAfMR0wGwYDVQQDDBRBbmRyb2lkIEtleXN0b3JlIEtleTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABP8c/Ldx44Ms4bM37CyNoE6Us5uS8dAERkRV8kyxCY7bD3P9rds93fflXJS8Pccyb/fXXJgSS3T2SVdbbPrc5oqjgfswgfgwDAYDVR0PBAUDAweAADCB5wYKKwYBBAHWeQIBEQSB2DCB1QIBAgoBAQIBAwoBAQQLaGVsbG8gd29ybGQEADBLv4U9CQIHBXlxm+8jSL+FRToEODA2MRAwDgQJY29tLnB5eXBsAgEPMSIEIIMi9g2//U87C53x3twp61y6K1+22oaTkEjGgyTgXw37MGuhBTEDAgECogMCAQOjBAICAQClBTEDAgEEqgMCAQG/g3cCBQC/hT4DAgEAv4VAKjAoBCBNeQ+gpf6B1rNSuQr+QwaE2byBdRjNJMUOY0M5X3xR8gEB/woBAL+FQQUCAwE4gL+FQgUCAwMUUDAKBggqhkjOPQQDAgNIADBFAiEA7cObHYk5pcrMI+ZGd5KmVMlr83SbHzDJe6z3rNLqtlwCIAM/9o4YhpHmujecGzSX9sMk/xEaNHXdytqmxwh2wFBM

-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----

MIICJjCCAaugAwIBAgIKEyY3BBKHSRYpeTAKBggqhkjOPQQDAjApMRkwFwYDVQQFExAyOTYwY2I5YWViZDUwNWY0MQwwCgYDVQQMDANURUUwHhcNMTgwMzIxMjA1ODE1WhcNMjgwMzE4MjA1ODE1WjApMRkwFwYDVQQFExBhMTk1Mzk2NGJhMmEyODlkMQwwCgYDVQQMDANURUUwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATHJiYgEb7N5f8ZnbKTZkDSvp2VugEEvz4Mm7wxVmcizwSPMPiTjv6gm2n1CoNBSHLVnTZ84ywfEk7HiftX1K6Co4G6MIG3MB0GA1UdDgQWBBQkYNkasG1v9aQK31IvheOpubhN5jAfBgNVHSMEGDAWgBTZCjmyzP+wdzrAqIzS/zURX5DNxjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwICBDBUBgNVHR8ETTBLMEmgR6BFhkNodHRwczovL2FuZHJvaWQuZ29vZ2xlYXBpcy5jb20vYXR0ZXN0YXRpb24vY3JsLzEzMjYzNzA0MTI4NzQ5MTYyOTc5MAoGCCqGSM49BAMCA2kAMGYCMQCsCvSIoT/6E+cbiD+v4e+Y6PUYX3ZcatDAAM1eWTAWZmnabkTW9u3/BWhzYYYm4fYCMQCdsRDgh8XG4ZWJhuvFtHy/C3vi1Hf1wD93YoHOLLJaIPvuv/hWR+1UpKO2lgHo9+4=

-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----

MIID0TCCAbmgAwIBAgIKA4gmZ2BliZaFfTANBgkqhkiG9w0BAQsFADAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MB4XDTE4MDMyMTIwNTM1M1oXDTI4MDMxODIwNTM1M1owKTEZMBcGA1UEBRMQMjk2MGNiOWFlYmQ1MDVmNDEMMAoGA1UEDAwDVEVFMHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEjXELw7zFszCPjAS+Qn6zEFajdp6hD+53zSpN7egUzWfkFEh+wcLa4k67Fv2tKuekmLIhr4xidPllElgiwAyeB33abMJ5BckSX1ayj4lnpMVvYRovl/5ZHIKNIJMN/hC6o4G2MIGzMB0GA1UdDgQWBBTZCjmyzP+wdzrAqIzS/zURX5DNxjAfBgNVHSMEGDAWgBQ2YeEAfIgFCVGLRGxH/xpMyepPEjAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwICBDBQBgNVHR8ESTBHMEWgQ6BBhj9odHRwczovL2FuZHJvaWQuZ29vZ2xlYXBpcy5jb20vYXR0ZXN0YXRpb24vY3JsL0U4RkExOTYzMTREMkZBMTgwDQYJKoZIhvcNAQELBQADggIBAJKrsCoJam9qc1ZaHeQWf2TAjHDDVylLuUvczTSuu8VhZJiU0+yKGbTNnA13n/dvn7rmMj8W6ObWL582Se9MBBdKtAVeCG7qYFq+m6kYFIfL8sOuutKXG5eW+8VY4he0hu+5eZiS2e3mAZGYF9JwQTAv0H//6+9eLm/+j+L5tr2X4b7H6k2h4YW5HTIzIbVMvp/ic/zmv+RvrmYyXliaz1xglRqrJ6EiFI9/KsYYsSSVgorlrXPyKOBeXGc2SFIVQmLwfW4gc9BC8V4qBDcpFK1kxOfnkyXloVZeat4yuYFSIdtJq9FErMFHfp+pDjIKRGeeWWrPzkbELqtHUSeSktbqN229c+86YRfScxpx5iJ0Jp2YsHkiYDFs+0LOex2RNdOKErGKZ+8QbMtVxUIQARTlhZkeLTLAWufFcclEbZkpoe6jo131VjAlUrkQfK6dVVMx+gLhOffLjH9EmUOD8Y1an9DQCsZl1tpBN4WgInbRMlzBsKF17Z9BEW1f2A+Gn0mnznZoq6t0OxsvRJTEHEgswQh4Vkr77UYSdcwQ0flrpD9Oe6ObnB0VSSCVo1yhPC39R35Z5KDhiNS8BkuPaJoUK8RBbkl5ay4O86LFfY9tdAoHT0A/2hmq/NZhz48K1C9AJGtS+0+zHwSatjWJ7rM/KXAhJ0Nln/nMaeteQy2f

-----END CERTIFICATE-----


-----BEGIN CERTIFICATE-----

MIIFYDCCA0igAwIBAgIJAOj6GWMU0voYMA0GCSqGSIb3DQEBCwUAMBsxGTAXBgNVBAUTEGY5MjAwOWU4NTNiNmIwNDUwHhcNMTYwNTI2MTYyODUyWhcNMjYwNTI0MTYyODUyWjAbMRkwFwYDVQQFExBmOTIwMDllODUzYjZiMDQ1MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAr7bHgiuxpwHsK7Qui8xUFmOr75gvMsd/dTEDDJdSSxtf6An7xyqpRR90PL2abxM1dEqlXnf2tqw1Ne4Xwl5jlRfdnJLmN0pTy/4lj4/7tv0Sk3iiKkypnEUtR6WfMgH0QZfKHM1+di+y9TFRtv6y//0rb+T+W8a9nsNL/ggjnar86461qO0rOs2cXjp3kOG1FEJ5MVmFmBGtnrKpa73XpXyTqRxB/M0n1n/W9nGqC4FSYa04T6N5RIZGBN2z2MT5IKGbFlbC8UrW0DxW7AYImQQcHtGl/m00QLVWutHQoVJYnFPlXTcHYvASLu+RhhsbDmxMgJJ0mcDpvsC4PjvB+TxywElgS70vE0XmLD+OJtvsBslHZvPBKCOdT0MS+tgSOIfga+z1Z1g7+DVagf7quvmag8jfPioyKvxnK/EgsTUVi2ghzq8wm27ud/mIM7AY2qEORR8Go3TVB4HzWQgpZrt3i5MIlCaY504LzSRiigHCzAPlHws+W0rB5N+er5/2pJKnfBSDiCiFAVtCLOZ7gLiMm0jhO2B6tUXHI/+MRPjy02i59lINMRRev56GKtcd9qO/0kUJWdZTdA2XoS82ixPvZtXQpUpuL12ab+9EaDK8Z4RHJYYfCT3Q5vNAXaiWQ+8PTWm2QgBR/bkwSWc+NpUFgNPN9PvQi8WEg5UmAGMCAwEAAaOBpjCBozAdBgNVHQ4EFgQUNmHhAHyIBQlRi0RsR/8aTMnqTxIwHwYDVR0jBBgwFoAUNmHhAHyIBQlRi0RsR/8aTMnqTxIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAYYwQAYDVR0fBDkwNzA1oDOgMYYvaHR0cHM6Ly9hbmRyb2lkLmdvb2dsZWFwaXMuY29tL2F0dGVzdGF0aW9uL2NybC8wDQYJKoZIhvcNAQELBQADggIBACDIw41L3KlXG0aMiS//cqrG+EShHUGo8HNsw30W1kJtjn6UBwRM6jnmiwfBPb8VA91chb2vssAtX2zbTvqBJ9+LBPGCdw/E53Rbf86qhxKaiAHOjpvAy5Y3m00mqC0w/Zwvju1twb4vhLaJ5NkUJYsUS7rmJKHHBnETLi8GFqiEsqTWpG/6ibYCv7rYDBJDcR9W62BW9jfIoBQcxUCUJouMPH25lLNcDc1ssqvC2v7iUgI9LeoM1sNovqPmQUiG9rHli1vXxzCyaMTjwftkJLkf6724DFhuKug2jITV0QkXvaJWF4nUaHOTNA4uJU9WDvZLI1j83A+/xnAJUucIv/zGJ1AMH2boHqF8CY16LpsYgBt6tKxxWH00XcyDCdW2KlBCeqbQPcsFmWyWugxdcekhYsAWyoSf818NUsZdBWBaR/OukXrNLfkQ79IyZohZbvabO/X+MVT3rriAoKc8oE2Uws6DF+60PV7/WIPjNvXySdqspImSN78mflxDqwLqRBYkA3I75qppLGG9rp7UCdRjxMl8ZDBld+7yvHVgt1cVzJx9xnyGCC23UaicMDSXYrB4I4WHXPGjxhZuCuPBLTdOLU8YRvMYdEvYebWHMpvwGCF6bAx3JBpIeOQ1wDB5y0USicV3YgYGmi+NZfhA4URSh77Yd6uuJOJENRaNVTzk

-----END CERTIFICATE-----



g1.pem: OK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181031/bc53618b/attachment-0001.html>

From shiva4a4 at gmail.com  Wed Oct 31 12:18:12 2018
From: shiva4a4 at gmail.com (Shiva shankar)
Date: Wed, 31 Oct 2018 17:48:12 +0530
Subject: [openssl-users] How to implement custom engine EC_KEY_set_group
	method
Message-ID: <CAM+aGhDnW=UcXLVd4f2aTGxnizBB6aixEiJ38dG0KSnSWyLRFA@mail.gmail.com>

Hi All,

I have few queries on how to implement custom engine ECDH ec set_group
method and it's return value. Any inputs are highly appreciated.


While setting engine group,currently always default group is set.


int EC_KEY_set_group(EC_KEY *key, const EC_GROUP *group)
 {
     if (key->meth->set_group != NULL && key->meth->set_group(key, group)
== 0) *  #Const object & pass by value,whatever the value set by
custom engine is not reflected in the group object *
         return 0;
     EC_GROUP_free(key->group);*#Freeing the key->group.*
     key->group = EC_GROUP_dup(group); *#Assigning the same **group object*
     return (key->group == NULL) ? 0 : 1;
 }

Below is my engine set_group code.

int my_engine_set_group(EC_KEY *key, const EC_GROUP *grp)

{

      if(grp->curve_name==P256)

          key->group = get_custom_group();

    #*What should be the  return value for supported and non supported
curves ?*

        return 1;

       else #Other curves such as P384,P521

         return 0;

}


Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20181031/5a780a5e/attachment.html>