From emadsen at hbmachining.com  Mon Jun  3 00:49:10 2019
From: emadsen at hbmachining.com (Erik Madsen)
Date: Sun, 2 Jun 2019 17:49:10 -0700
Subject: -keyform ENG and NodeJS
Message-ID: <4a36f4b0-37db-bcb8-4286-50f2559b7e09@hbmachining.com>

I am using a Hardware Security Module.? Both s_client and cURL work fine 
due to we can use the CLI "-keyform ENG" for s_client and "--key-type 
ENG" for curl

Is it possible to specify this in the openssl.cnf file instead of the CLI?

For testing this, the following works:

openssl s_client -connect host:port -engine engineSO -keyform ENG -cert 
/path/to/signed/cert


If we can do like this:

OPENSSL_CONF=openssl.cnf openssl s_client -connect host:port -engine 
engineSO -cert /path/to/signed/cert (removed the -keyform)

I think will work fine


Any help greatly appreciated


From openssl-users at dukhovni.org  Mon Jun  3 01:35:37 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 2 Jun 2019 21:35:37 -0400
Subject: -keyform ENG and NodeJS
In-Reply-To: <4a36f4b0-37db-bcb8-4286-50f2559b7e09@hbmachining.com>
References: <4a36f4b0-37db-bcb8-4286-50f2559b7e09@hbmachining.com>
Message-ID: <20190603013537.GB67454@straasha.imrryr.org>

On Sun, Jun 02, 2019 at 05:49:10PM -0700, Erik Madsen wrote:

> I am using a Hardware Security Module.? Both s_client and cURL work fine 
> due to we can use the CLI "-keyform ENG" for s_client and "--key-type 
> ENG" for curl
> 
> Is it possible to specify this in the openssl.cnf file instead of the CLI?

You could be a bit more explicit about whether this a TLS or some
other application.  Configuration is "module"-specific.

> For testing this, the following works:
> 
> openssl s_client -connect host:port -engine engineSO -keyform ENG -cert 
> /path/to/signed/cert
> 
> 
> If we can do like this:
> 
> OPENSSL_CONF=openssl.cnf openssl s_client -connect host:port -engine 
> engineSO -cert /path/to/signed/cert (removed the -keyform)
> 
> I think will work fine

I don't believe that the SSL "conf module" presently supports a
"command" that allows you specify the "keyform" of a private key
file.  It has a "PrivateKey" "command", but this appears to be
unconditionally limited to PEM.

If anyone else knows otherwise, corrections welcome

-- 
	Viktor.

From emadsen at hbmachining.com  Mon Jun  3 01:47:25 2019
From: emadsen at hbmachining.com (Erik Madsen)
Date: Sun, 02 Jun 2019 18:47:25 -0700
Subject: -keyform ENG and NodeJS
In-Reply-To: <20190603013537.GB67454@straasha.imrryr.org>
References: <4a36f4b0-37db-bcb8-4286-50f2559b7e09@hbmachining.com>
 <20190603013537.GB67454@straasha.imrryr.org>
Message-ID: <20303409-94a9-404b-b038-4c286994d7c1@hbmachining.com>

Sorry about that

It is TLS and we want Root Of Trust from a non exportable, non readable Private key on the Hardware Security Module.

By explicitly adding "-keyform ENG" s_client works perfectly.

And with cURL "--key-type ENG" also works

NodeJs crypto module has setEngine but there's no option for passing keyform.

I requested from NodeJs team as well, but if we can do something to tell openssl "keyform is always ENG" I think maybe that would work.


-------- Original Message --------
From: Viktor Dukhovni <openssl-users at dukhovni.org>
Sent: Sun Jun 02 18:35:37 PDT 2019
To: openssl-users at openssl.org
Subject: Re: -keyform ENG and NodeJS

On Sun, Jun 02, 2019 at 05:49:10PM -0700, Erik Madsen wrote:

> I am using a Hardware Security Module.? Both s_client and cURL work fine 
> due to we can use the CLI "-keyform ENG" for s_client and "--key-type 
> ENG" for curl
> 
> Is it possible to specify this in the openssl.cnf file instead of the CLI?

You could be a bit more explicit about whether this a TLS or some
other application.  Configuration is "module"-specific.

> For testing this, the following works:
> 
> openssl s_client -connect host:port -engine engineSO -keyform ENG -cert 
> /path/to/signed/cert
> 
> 
> If we can do like this:
> 
> OPENSSL_CONF=openssl.cnf openssl s_client -connect host:port -engine 
> engineSO -cert /path/to/signed/cert (removed the -keyform)
> 
> I think will work fine

I don't believe that the SSL "conf module" presently supports a
"command" that allows you specify the "keyform" of a private key
file.  It has a "PrivateKey" "command", but this appears to be
unconditionally limited to PEM.

If anyone else knows otherwise, corrections welcome

-- 
	Viktor.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190602/38b2d09c/attachment.html>

From openssl-users at dukhovni.org  Mon Jun  3 02:14:29 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 2 Jun 2019 22:14:29 -0400
Subject: -keyform ENG and NodeJS
In-Reply-To: <20303409-94a9-404b-b038-4c286994d7c1@hbmachining.com>
References: <4a36f4b0-37db-bcb8-4286-50f2559b7e09@hbmachining.com>
 <20190603013537.GB67454@straasha.imrryr.org>
 <20303409-94a9-404b-b038-4c286994d7c1@hbmachining.com>
Message-ID: <EF63ECD0-22F7-46AE-BCFF-93DBC3AEA9E1@dukhovni.org>



> On Jun 2, 2019, at 9:47 PM, Erik Madsen <emadsen at hbmachining.com> wrote:
> 
> It is TLS and we want Root Of Trust from a non exportable, non readable Private key on the Hardware Security Module.
> 
> By explicitly adding "-keyform ENG" s_client works perfectly.
> 
> And with cURL "--key-type ENG" also works
> 
> NodeJs crypto module has setEngine but there's no option for passing keyform.
> 
> I requested from NodeJs team as well, but if we can do something to tell openssl "keyform is always ENG" I think maybe that would work.

If nobody on the list finds something I missed, a feature
request on Github is the next step, or you could do that
right away.

[ Some on the team prefer to track issues on Github from
the outset, I prefer to resolve routine questions on the
list, and move to Github when it is clear that developer
action will be needed to resolve the issue. The workflow
preference is matter of taste... ]

-- 
	Viktor.


From emadsen at hbmachining.com  Mon Jun  3 02:19:48 2019
From: emadsen at hbmachining.com (Erik Madsen)
Date: Sun, 02 Jun 2019 19:19:48 -0700
Subject: -keyform ENG and NodeJS
In-Reply-To: <EF63ECD0-22F7-46AE-BCFF-93DBC3AEA9E1@dukhovni.org>
References: <4a36f4b0-37db-bcb8-4286-50f2559b7e09@hbmachining.com>
 <20190603013537.GB67454@straasha.imrryr.org>
 <20303409-94a9-404b-b038-4c286994d7c1@hbmachining.com>
 <EF63ECD0-22F7-46AE-BCFF-93DBC3AEA9E1@dukhovni.org>
Message-ID: <957e4012-a70f-4b66-b682-fd4967dbb589@hbmachining.com>

https://github.com/nodejs/help/issues/1622

Here is a more detailed explanation of how NodeJS is failing...I posted in November, but we are close to production, so scrambling to find solutions

Thanks so much for the help.


-------- Original Message --------
From: Viktor Dukhovni <openssl-users at dukhovni.org>
Sent: Sun Jun 02 19:14:29 PDT 2019
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: -keyform ENG and NodeJS



> On Jun 2, 2019, at 9:47 PM, Erik Madsen <emadsen at hbmachining.com> wrote:
> 
> It is TLS and we want Root Of Trust from a non exportable, non readable Private key on the Hardware Security Module.
> 
> By explicitly adding "-keyform ENG" s_client works perfectly.
> 
> And with cURL "--key-type ENG" also works
> 
> NodeJs crypto module has setEngine but there's no option for passing keyform.
> 
> I requested from NodeJs team as well, but if we can do something to tell openssl "keyform is always ENG" I think maybe that would work.

If nobody on the list finds something I missed, a feature
request on Github is the next step, or you could do that
right away.

[ Some on the team prefer to track issues on Github from
the outset, I prefer to resolve routine questions on the
list, and move to Github when it is clear that developer
action will be needed to resolve the issue. The workflow
preference is matter of taste... ]

-- 
	Viktor.

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

From chitrang.srivastava at gmail.com  Mon Jun  3 12:35:01 2019
From: chitrang.srivastava at gmail.com (Chitrang Srivastava)
Date: Mon, 3 Jun 2019 18:05:01 +0530
Subject: Compile EC(Elliptic Curve) crypto
Message-ID: <CANPP3o2CE6g24wPZBYXUU3TJm_+87f8GX8zW0zKq4q_N7Fupjw@mail.gmail.com>

Hi,

I am porting Openssl 1.1.1b for an embedded platform.
I see that EC folder generate some of function in assembly  for e.g
These functions are generated based on environment like x86-64/ppc/armv8
etc.
Is there any C version of these function to use directly ?

Thanks,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190603/65b4aec5/attachment-0001.html>

From jb-openssl at wisemo.com  Mon Jun  3 12:47:56 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 3 Jun 2019 14:47:56 +0200
Subject: Compile EC(Elliptic Curve) crypto
In-Reply-To: <CANPP3o2CE6g24wPZBYXUU3TJm_+87f8GX8zW0zKq4q_N7Fupjw@mail.gmail.com>
References: <CANPP3o2CE6g24wPZBYXUU3TJm_+87f8GX8zW0zKq4q_N7Fupjw@mail.gmail.com>
Message-ID: <59c8eecf-7669-7d49-ad8f-ea62e074f63c@wisemo.com>

On 03/06/2019 14:35, Chitrang Srivastava wrote:
> Hi,
>
> I am porting Openssl 1.1.1b for an embedded platform.
> I see that EC folder generate some of function in assembly for e.g
> These functions are generated based on environment like 
> x86-64/ppc/armv8 etc.
> Is there any C version of these function to use directly ?
> Thanks,
>
All algorithms etc. are available as C code, the assembler optimizations
are used if they exist for a compilation target and have not been
explicitly disabled with the configure option "no-asm".

Because embedded platforms often have slow CPUs, keeping the assembler
optimizations enabled is especially advantageous on such systems.

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 chitrang.srivastava at gmail.com  Mon Jun  3 12:51:04 2019
From: chitrang.srivastava at gmail.com (Chitrang Srivastava)
Date: Mon, 3 Jun 2019 18:21:04 +0530
Subject: Compile EC(Elliptic Curve) crypto
In-Reply-To: <59c8eecf-7669-7d49-ad8f-ea62e074f63c@wisemo.com>
References: <CANPP3o2CE6g24wPZBYXUU3TJm_+87f8GX8zW0zKq4q_N7Fupjw@mail.gmail.com>
 <59c8eecf-7669-7d49-ad8f-ea62e074f63c@wisemo.com>
Message-ID: <CANPP3o1hUZ9GVLAn+8EjU=q6n-WPD-80ZT4Gbt+LpERs9E3PkA@mail.gmail.com>

Thanks,
I will check out.



On Mon, Jun 3, 2019 at 6:18 PM Jakob Bohm via openssl-users <
openssl-users at openssl.org> wrote:

> On 03/06/2019 14:35, Chitrang Srivastava wrote:
> > Hi,
> >
> > I am porting Openssl 1.1.1b for an embedded platform.
> > I see that EC folder generate some of function in assembly for e.g
> > These functions are generated based on environment like
> > x86-64/ppc/armv8 etc.
> > Is there any C version of these function to use directly ?
> > Thanks,
> >
> All algorithms etc. are available as C code, the assembler optimizations
> are used if they exist for a compilation target and have not been
> explicitly disabled with the configure option "no-asm".
>
> Because embedded platforms often have slow CPUs, keeping the assembler
> optimizations enabled is especially advantageous on such systems.
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190603/57558e7c/attachment.html>

From mtownsend1973 at gmail.com  Mon Jun  3 15:35:58 2019
From: mtownsend1973 at gmail.com (Martin Townsend)
Date: Mon, 3 Jun 2019 16:35:58 +0100
Subject: Signing using EVP_PKEY_encrypt when using pkcs11 engine
Message-ID: <CABatt_yhGOOZpvbAkX_ieMckLKSwkEDMxRovDZ-VpgjBeoyrNw@mail.gmail.com>

Hi,

I'm trying to modify the evm/ima utility so that it can use a HSM to
perform signing.  I've setup SoftHSM and used this to create a
certificate with an RSA public key pair.  The evmctl code creates the
hash and then calls a function to perform the sign operation which
ends up calling
len = RSA_private_encrypt(size + asn1->size, buf, hdr->sig,
  key, RSA_PKCS1_PADDING);

My idea was to keep the hash calculation as is, and replace the
RSA_private_encrypt with code that uses the private key in the HSM to
encrypt the hash buffer that has been calculated.

My initialisation looks like this
    /* Load the configuration using OPENSSL_CONF environment variable */
    OPENSSL_config(NULL);
    /* Try and load PKCS11 engine */
    const char* s = getenv("OPENSSL_CONF");
    printf("Trying to load pkcs#11 engine\n");
    printf("OPENSSL_CONF=%s\n", s);
    pkcs_engine = ENGINE_by_id("pkcs11");
    if (!pkcs_engine) {
        printf("PKCS#11 engine not found, not using HSM\n");
    } else {
        int rv = ENGINE_init(pkcs_engine);

        if (!rv) {
            fprintf(stderr, "PKCS#11 could not be initialised\n");
            ENGINE_free(pkcs_engine);
            pkcs_engine = NULL;
        }

        ENGINE_set_default(pkcs_engine, ENGINE_METHOD_ALL);
    }

    OpenSSL_add_all_algorithms();
    OpenSSL_add_all_digests();
    ERR_load_crypto_strings();

and then I load the private key with

    key = ENGINE_load_private_key(pkcs_engine, keyid, UI_OpenSSL(), NULL);
    if (!key) {
        log_err("%s: Failed to load private key with id: %s\n", keyid,
__func__);
        ERR_print_errors_fp(stderr);
    }


and then use the following to perform the encryption

        /* Create context */
        hsm_key_ctx = EVP_PKEY_CTX_new(hsm_key, NULL);
        if (hsm_key_ctx == NULL) {
            log_err("sign_hash_v2: failed to create context\n");
            ERR_print_errors_fp(stderr);
            return -1;
        }
        rv = EVP_PKEY_encrypt_init(hsm_key_ctx);
        if (rv <= 0) {
            log_err("sign_hash_v2: failed to init encrypt (rv=%d\n", rv);
            ERR_print_errors_fp(stderr);
            EVP_PKEY_CTX_free(hsm_key_ctx);
            return -1;
        }
        /* TODO: What padding??? RSA_PKCS1_PSS_PADDING?? */
        rv = EVP_PKEY_CTX_set_rsa_padding(hsm_key_ctx, RSA_PKCS1_PADDING);
        if (rv <= 0) {
            log_err("sign_hash_v2: failed to set RSA_PKCS1_PADDING
(rv=%d\n", rv);
            ERR_print_errors_fp(stderr);
            EVP_PKEY_CTX_free(hsm_key_ctx);
            return -1;
        }
        if (rv <= 0) {
            log_err("sign_hash_v2: failed to set RSA_PKCS1_PADDING
(rv=%d\n", rv);
            ERR_print_errors_fp(stderr);
            EVP_PKEY_CTX_free(hsm_key_ctx);
            return -1;
        }

        /* Create signature */
        outlen = 0;
        rv = EVP_PKEY_encrypt(hsm_key_ctx, NULL, &outlen, buf, size +
asn1->size);
        if ((rv <= 0) || (outlen == 0)) {
            log_err("sign_hash_v2: failed to learn needed output buf
len (rv=%d)\n", rv);
            ERR_print_errors_fp(stderr);
            EVP_PKEY_CTX_free(hsm_key_ctx);
            return -1;
        }
        /*outlen = 256;*/
        log_info("EVP_PKEY_encrypt: outlen: %lu\n", outlen);
        rv = EVP_PKEY_encrypt(hsm_key_ctx, hdr->sig, &outlen, buf,
size + asn1->size);
        if (rv <= 0) {
            log_err("sign_hash_v2: EVP_PKEY_encrypt() failed (rv=%d)\n", rv);
            ERR_print_errors_fp(stderr);
            EVP_PKEY_CTX_free(hsm_key_ctx);
            return -1;
        }

But I find that when I create a signature for a particular file it's
always different with each invocation of the utility. If I try and
verify it using the associated public key I get:

RSA_public_decrypt() failed: -1
errno: No data available (61)
error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01
error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed

Is there something I am missing in my code above?  I tried setting the
Engine in EVP_PKEY_CTX_new but get:
sign_hash_v2: failed to create context
140174165591744:error:260C0065:engine
routines:ENGINE_get_pkey_meth:unimplemented public key
method:tb_pkmeth.c:128:
140174165591744:error:0609D09C:digital envelope
routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:166:
errno: Invalid argument (22)

Any help appreciated,
Martin.

From juanamichi at gmail.com  Mon Jun  3 15:40:02 2019
From: juanamichi at gmail.com (Daniel Pedraza)
Date: Mon, 3 Jun 2019 10:40:02 -0500
Subject: Trying to get a public info for a certificate
Message-ID: <CAHz9Yx0rGL5tWrC11V1QxeAWNiudVz6DW3b16N0xujtus12pmA@mail.gmail.com>

Hi guys!

I'm trying to upgrade an old C project from OpenSSL 1.0.2 to the newest
1.1.1 version. Everything's going smoothly, except for one little detail:

There's a part of the code where we're doing a sha256 hash of the public
key of our certificate. On the older OpenSSL, we were able to get the
public key by doing cert->cert_info->key->public_key->data. On the newer
version, we no longer have access to the cert_info struct.

I tried doing:

EVP_PKEY * public_key = X509_get0_pubkey(cert);

this gives me an EVP_PKEY value, which I tried to convert to a char** by
doing this:

unsigned char *buf, *p;
int len = i2d_PublicKey(public_key, NULL);
buf = OPENSSL_malloc(len);
p = buf;
i2d_PublicKey(public_key, &p);

This gives me a buffer with the correct length, but it seems like it has
different data from what the public_key->data used to give me.

Granted, I am not very savvy with OpenSSL, or with ssl in general, so maybe
I'm doing something wrong/dumb? I've spent a fair bit of time on the
documentation/wiki but I can?t seem to find the answer. Seems to me like
this should be something very straightforward?

Any help would be v much appreciated

-Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190603/298f9db1/attachment.html>

From matt at openssl.org  Mon Jun  3 16:23:03 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 3 Jun 2019 17:23:03 +0100
Subject: Trying to get a public info for a certificate
In-Reply-To: <CAHz9Yx0rGL5tWrC11V1QxeAWNiudVz6DW3b16N0xujtus12pmA@mail.gmail.com>
References: <CAHz9Yx0rGL5tWrC11V1QxeAWNiudVz6DW3b16N0xujtus12pmA@mail.gmail.com>
Message-ID: <16cca609-2ad6-8c2f-55a2-a47943750195@openssl.org>



On 03/06/2019 16:40, Daniel Pedraza wrote:
> Hi guys!
> 
> I'm trying to upgrade an old C project from OpenSSL 1.0.2 to the newest 1.1.1
> version. Everything's going smoothly, except for one little detail:
> 
> There's a part of the code where we're doing a sha256 hash of the public key of
> our certificate. On the older OpenSSL, we were able to get the public key by
> doing cert->cert_info->key->public_key->data. On the newer version, we no longer
> have access to the cert_info struct.
> 
> I tried doing:
> 
> EVP_PKEY * public_key = X509_get0_pubkey(cert);
> 
> this gives me an EVP_PKEY value, which I tried to convert to a char** by doing this:
> 
> unsigned char *buf, *p;
> int len = i2d_PublicKey(public_key, NULL);
> buf = OPENSSL_malloc(len);
> p = buf;
> i2d_PublicKey(public_key, &p);
> 
> This gives me a buffer with the correct length, but it seems like it has
> different data from what the public_key->data used to give me.
> 
> Granted, I am not very savvy with OpenSSL, or with ssl in general, so maybe I'm
> doing something wrong/dumb? I've spent a fair bit of time on the
> documentation/wiki but I can?t seem to find the answer. Seems to me like this
> should be something very straightforward?
> 
> Any help would be v much appreciated

Probably what you want is the X509_get0_pubkey_bitstr() function. This gives you
the data as an ASN1_BIT_STRING structure (i.e. what used to be accessible as
cert->cert_info->key->public_key).

Matt


From openssl-users at dukhovni.org  Mon Jun  3 16:31:11 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 3 Jun 2019 12:31:11 -0400
Subject: Trying to get a public info for a certificate
In-Reply-To: <CAHz9Yx0rGL5tWrC11V1QxeAWNiudVz6DW3b16N0xujtus12pmA@mail.gmail.com>
References: <CAHz9Yx0rGL5tWrC11V1QxeAWNiudVz6DW3b16N0xujtus12pmA@mail.gmail.com>
Message-ID: <20190603163111.GC67454@straasha.imrryr.org>

On Mon, Jun 03, 2019 at 10:40:02AM -0500, Daniel Pedraza wrote:

> There's a part of the code where we're doing a sha256 hash of the public
> key of our certificate. On the older OpenSSL, we were able to get the
> public key by doing cert->cert_info->key->public_key->data. On the newer
> version, we no longer have access to the cert_info struct.
> 
> I tried doing:
> 
> EVP_PKEY * public_key = X509_get0_pubkey(cert);
> 
> this gives me an EVP_PKEY value, which I tried to convert to a char** by
> doing this:
> 
> unsigned char *buf, *p;
> int len = i2d_PublicKey(public_key, NULL);
> buf = OPENSSL_malloc(len);
> p = buf;
> i2d_PublicKey(public_key, &p);

To obtain the serialized buffer 'buf' of length 'len' that you
can then checksum, there are two essentially equivalent approaches:

   1.   X509 *cert = ...;
        X509_PUBKEY *xpk = X509_get_X509_PUBKEY(cert);
	int len = i2d_X509_PUBKEY(xpk, NULL);
        unsigned char *buf = malloc(len);	/* error check */
	unsigned char *buf2 = buf;

	i2d_X509_PUBKEY(xpk, &buf2);
	OPENSSL_assert(buf2 - buf == len);

   2.   X509 *cert = ...;
	EVP_PKEY *pkey = X509_get0_pubkey(cert);
	int len = i2d_PUBKEY(pkey, NULL);
	unsigned char *buf = malloc(len);	/* error check */
	unsigned char *buf2 = buf;

	i2d_PUBKEY(pkey, &buf2);
	OPENSSL_assert(buf2 - buf == len);

The first approach avoids having to reconstruct (allocate, use and
free) the X509_PUBKEY (SPKI) from the underlying EVP_PKEY, so will
be slightly more efficient.

> This gives me a buffer with the correct length, but it seems like it has
> different data from what the public_key->data used to give me.

I don't recall what public_key->data contains, but if different it
was probably not the right thing to use, since you should be capturing
the complete SPKI structure (public key algorithm OID, any parameters
and the key data).  If it contains just the key bits, without the
algorithm and parameters, it is unwise to use that.

If needed for backwards-compatibility, you should be able to recover
the key bitstring with X509_get0_pubkey_bitstr(3), but you really
should not.  The SPKI is the right object to fingerprint.

-- 
	Viktor.

From openssl-users at dukhovni.org  Mon Jun  3 16:40:15 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 3 Jun 2019 12:40:15 -0400
Subject: osf-contact Striking out everywhere
In-Reply-To: <ab413d58-6af5-4c38-d592-c940c8487847@openssl.org>
References: <1a8d60c6-95e8-b10b-e37e-34dae0113ccc@hbmachining.com>
 <2c9278aa-2fb3-6e0a-2c83-2535f16e0f32@openssl.org>
 <43ea2978-5ada-660c-e55d-5a617415ed2c@hbmachining.com>
 <ab413d58-6af5-4c38-d592-c940c8487847@openssl.org>
Message-ID: <20190603164015.GD67454@straasha.imrryr.org>

On Mon, Jun 03, 2019 at 04:41:47PM +0100, Matt Caswell wrote:

> On 03/06/2019 15:16, Erik Madsen wrote:
>
> > Thanks for the reply! Is there any link for avail variables for openssl.conf? 
> 
> See:
> 
> https://www.openssl.org/docs/man1.1.1/man5/config.html
> 
> > 
> > [ssl_section]
> > KeyForm = ENG
> > 
> > no success...but at this point, honestly just scrambling.

KeyForm is not a defined parameter for the SSL module.  The
supported parameters are listed in:

    https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html

-- 
	Viktor.

From juanamichi at gmail.com  Mon Jun  3 17:03:38 2019
From: juanamichi at gmail.com (Daniel Pedraza)
Date: Mon, 3 Jun 2019 12:03:38 -0500
Subject: Trying to get a public info for a certificate
In-Reply-To: <20190603163111.GC67454@straasha.imrryr.org>
References: <CAHz9Yx0rGL5tWrC11V1QxeAWNiudVz6DW3b16N0xujtus12pmA@mail.gmail.com>
 <20190603163111.GC67454@straasha.imrryr.org>
Message-ID: <CAHz9Yx1=PZEWyU69ARibwuFXj-bbds9zUEXM4Z4ZnGUUZOdZ5g@mail.gmail.com>

Thanks a lot, Matt and Viktor! You guys are absolutely right,
X509_get0_pubkey_bitstr gives me the same struct that was once inside of
cert_info->key->public_key.

@Viktor I had also tried your second approach (didn't know about the first
one!) and for some reason it doesn't have the "correct" data. My guess is
you're right and the application has been hashing the wrong thing all
along. I will look into it.

Anyway, thanks a lot you guys, you are the best!

On Mon, Jun 3, 2019 at 11:31 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Mon, Jun 03, 2019 at 10:40:02AM -0500, Daniel Pedraza wrote:
>
> > There's a part of the code where we're doing a sha256 hash of the public
> > key of our certificate. On the older OpenSSL, we were able to get the
> > public key by doing cert->cert_info->key->public_key->data. On the newer
> > version, we no longer have access to the cert_info struct.
> >
> > I tried doing:
> >
> > EVP_PKEY * public_key = X509_get0_pubkey(cert);
> >
> > this gives me an EVP_PKEY value, which I tried to convert to a char** by
> > doing this:
> >
> > unsigned char *buf, *p;
> > int len = i2d_PublicKey(public_key, NULL);
> > buf = OPENSSL_malloc(len);
> > p = buf;
> > i2d_PublicKey(public_key, &p);
>
> To obtain the serialized buffer 'buf' of length 'len' that you
> can then checksum, there are two essentially equivalent approaches:
>
>    1.   X509 *cert = ...;
>         X509_PUBKEY *xpk = X509_get_X509_PUBKEY(cert);
>         int len = i2d_X509_PUBKEY(xpk, NULL);
>         unsigned char *buf = malloc(len);       /* error check */
>         unsigned char *buf2 = buf;
>
>         i2d_X509_PUBKEY(xpk, &buf2);
>         OPENSSL_assert(buf2 - buf == len);
>
>    2.   X509 *cert = ...;
>         EVP_PKEY *pkey = X509_get0_pubkey(cert);
>         int len = i2d_PUBKEY(pkey, NULL);
>         unsigned char *buf = malloc(len);       /* error check */
>         unsigned char *buf2 = buf;
>
>         i2d_PUBKEY(pkey, &buf2);
>         OPENSSL_assert(buf2 - buf == len);
>
> The first approach avoids having to reconstruct (allocate, use and
> free) the X509_PUBKEY (SPKI) from the underlying EVP_PKEY, so will
> be slightly more efficient.
>
> > This gives me a buffer with the correct length, but it seems like it has
> > different data from what the public_key->data used to give me.
>
> I don't recall what public_key->data contains, but if different it
> was probably not the right thing to use, since you should be capturing
> the complete SPKI structure (public key algorithm OID, any parameters
> and the key data).  If it contains just the key bits, without the
> algorithm and parameters, it is unwise to use that.
>
> If needed for backwards-compatibility, you should be able to recover
> the key bitstring with X509_get0_pubkey_bitstr(3), but you really
> should not.  The SPKI is the right object to fingerprint.
>
> --
>         Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190603/07b62bc0/attachment.html>

From emadsen at hbmachining.com  Mon Jun  3 17:03:56 2019
From: emadsen at hbmachining.com (Erik Madsen)
Date: Mon, 03 Jun 2019 10:03:56 -0700
Subject: osf-contact Striking out everywhere
In-Reply-To: <20190603164015.GD67454@straasha.imrryr.org>
References: <1a8d60c6-95e8-b10b-e37e-34dae0113ccc@hbmachining.com>
 <2c9278aa-2fb3-6e0a-2c83-2535f16e0f32@openssl.org>
 <43ea2978-5ada-660c-e55d-5a617415ed2c@hbmachining.com>
 <ab413d58-6af5-4c38-d592-c940c8487847@openssl.org>
 <20190603164015.GD67454@straasha.imrryr.org>
Message-ID: <a4eec435-d997-4a2a-b638-afdd3ef95e31@hbmachining.com>

Is there any possibility of setting second argument here from config?

SSL_CTX_set_client_cert_engine (SSL_CTX * ctx, ENGINE * )

I think at this point it's a Node issue not allowing for an engine to be used for the key...I know GOST works, but pretty sure that allows for a PrivateKey to be set.

I am almost 100% that node is getting the cert, but failing to get the key from the engine, so it's throwing the error "no client cert method" and according to strace, my engine is loading, but this call in Node crypto is setting engine fine, but in the TLS connection, there is no PEM formatted key.

One would think if cURL and s_client can work, NodeJs should also...

It will probably end up being something silly :O

?Thanks,

Erik?


-------- Original Message --------
From: Viktor Dukhovni <openssl-users at dukhovni.org>
Sent: Mon Jun 03 09:40:15 PDT 2019
To: openssl-users at openssl.org
Subject: Re: osf-contact Striking out everywhere

On Mon, Jun 03, 2019 at 04:41:47PM +0100, Matt Caswell wrote:

> On 03/06/2019 15:16, Erik Madsen wrote:
>
> > Thanks for the reply! Is there any link for avail variables for openssl.conf? 
> 
> See:
> 
> https://www.openssl.org/docs/man1.1.1/man5/config.html
> 
> > 
> > [ssl_section]
> > KeyForm = ENG
> > 
> > no success...but at this point, honestly just scrambling.

KeyForm is not a defined parameter for the SSL module.  The
supported parameters are listed in:

    https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html

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

From emadsen at hbmachining.com  Mon Jun  3 19:54:46 2019
From: emadsen at hbmachining.com (Erik Madsen)
Date: Mon, 3 Jun 2019 12:54:46 -0700
Subject: osf-contact Striking out everywhere
In-Reply-To: <a4eec435-d997-4a2a-b638-afdd3ef95e31@hbmachining.com>
References: <1a8d60c6-95e8-b10b-e37e-34dae0113ccc@hbmachining.com>
 <2c9278aa-2fb3-6e0a-2c83-2535f16e0f32@openssl.org>
 <43ea2978-5ada-660c-e55d-5a617415ed2c@hbmachining.com>
 <ab413d58-6af5-4c38-d592-c940c8487847@openssl.org>
 <20190603164015.GD67454@straasha.imrryr.org>
 <a4eec435-d997-4a2a-b638-afdd3ef95e31@hbmachining.com>
Message-ID: <73cf0ce1-e0b4-6d4e-ad06-4f34891fe041@hbmachining.com>



any thoughts here?

On 6/3/19 10:03 AM, Erik Madsen wrote:
> Is there any possibility of setting second argument here from config?
>
> SSL_CTX_set_client_cert_engine (SSL_CTX * ctx, ENGINE * )
>
> I think at this point it's a Node issue not allowing for an engine to 
> be used for the key...I know GOST works, but pretty sure that allows 
> for a PrivateKey to be set.
>
> I am almost 100% that node is getting the cert, but failing to get the 
> key from the engine, so it's throwing the error "no client cert 
> method" and according to strace, my engine is loading, but this call 
> in Node crypto is setting engine fine, but in the TLS connection, 
> there is no PEM formatted key.
>
> One would think if cURL and s_client can work, NodeJs should also...
>
> It will probably end up being something silly :O
>
> Thanks,
>
> Erik
> ------------------------------------------------------------------------
> *From:* Viktor Dukhovni
> *Sent:* Mon Jun 03 09:40:15 PDT 2019
> *To:* openssl-users at openssl.org
> *Subject:* Re: osf-contact Striking out everywhere
>
> On Mon, Jun 03, 2019 at 04:41:47PM +0100, Matt Caswell wrote:
>
>     On 03/06/2019 15:16, Erik Madsen wrote:
>
>         Thanks for the reply! Is there any link for avail variables
>         for openssl.conf? 
>
>     See: https://www.openssl.org/docs/man1.1.1/man5/config.html
>
>         [ssl_section] KeyForm = ENG no success...but at this point,
>         honestly just scrambling. 
>
>
> KeyForm is not a defined parameter for the SSL module.  The
> supported parameters are listed in:
>
>      https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190603/b529034e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ficbjipkcfbehdho.png
Type: image/png
Size: 19446 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190603/b529034e/attachment-0001.png>

From openssl-users at dukhovni.org  Mon Jun  3 19:58:57 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 3 Jun 2019 15:58:57 -0400
Subject: osf-contact Striking out everywhere
In-Reply-To: <73cf0ce1-e0b4-6d4e-ad06-4f34891fe041@hbmachining.com>
References: <1a8d60c6-95e8-b10b-e37e-34dae0113ccc@hbmachining.com>
 <2c9278aa-2fb3-6e0a-2c83-2535f16e0f32@openssl.org>
 <43ea2978-5ada-660c-e55d-5a617415ed2c@hbmachining.com>
 <ab413d58-6af5-4c38-d592-c940c8487847@openssl.org>
 <20190603164015.GD67454@straasha.imrryr.org>
 <a4eec435-d997-4a2a-b638-afdd3ef95e31@hbmachining.com>
 <73cf0ce1-e0b4-6d4e-ad06-4f34891fe041@hbmachining.com>
Message-ID: <20190603195857.GE67454@straasha.imrryr.org>

On Mon, Jun 03, 2019 at 12:54:46PM -0700, Erik Madsen wrote:

> any thoughts here?

You're posting images instead of text, and to the wrong list.
The issue seems to be in node.

-- 
	Viktor.

From emadsen at hbmachining.com  Mon Jun  3 21:52:42 2019
From: emadsen at hbmachining.com (Erik Madsen)
Date: Mon, 3 Jun 2019 14:52:42 -0700
Subject: osf-contact Striking out everywhere
In-Reply-To: <20190603195857.GE67454@straasha.imrryr.org>
References: <1a8d60c6-95e8-b10b-e37e-34dae0113ccc@hbmachining.com>
 <2c9278aa-2fb3-6e0a-2c83-2535f16e0f32@openssl.org>
 <43ea2978-5ada-660c-e55d-5a617415ed2c@hbmachining.com>
 <ab413d58-6af5-4c38-d592-c940c8487847@openssl.org>
 <20190603164015.GD67454@straasha.imrryr.org>
 <a4eec435-d997-4a2a-b638-afdd3ef95e31@hbmachining.com>
 <73cf0ce1-e0b4-6d4e-ad06-4f34891fe041@hbmachining.com>
 <20190603195857.GE67454@straasha.imrryr.org>
Message-ID: <a3899698-51e8-2cd2-bf97-16501791c804@hbmachining.com>

Sorry about that....Im new to this format

It was a snip of this:

if (typeof options.clientCertEngine === 'string') {
 ???? if (c.context.setClientCertEngine)
 ?????? c.context.setClientCertEngine(options.clientCertEngine);

options.clientCertEngine is just the path of the SO file

and it is calling openssl function:

SSL_CTX_set_client_cert_engine (SSL_CTX *ctx, ENGINE *e)

am I wrong that there should be a second argument passed from Node to 
Openssl?

Really appreciate all your support


On 6/3/19 12:58 PM, Viktor Dukhovni wrote:

> On Mon, Jun 03, 2019 at 12:54:46PM -0700, Erik Madsen wrote:
>
>> any thoughts here?
> You're posting images instead of text, and to the wrong list.
> The issue seems to be in node.
>

From openssl-users at dukhovni.org  Mon Jun  3 22:25:35 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 3 Jun 2019 18:25:35 -0400
Subject: osf-contact Striking out everywhere
In-Reply-To: <a3899698-51e8-2cd2-bf97-16501791c804@hbmachining.com>
References: <1a8d60c6-95e8-b10b-e37e-34dae0113ccc@hbmachining.com>
 <2c9278aa-2fb3-6e0a-2c83-2535f16e0f32@openssl.org>
 <43ea2978-5ada-660c-e55d-5a617415ed2c@hbmachining.com>
 <ab413d58-6af5-4c38-d592-c940c8487847@openssl.org>
 <20190603164015.GD67454@straasha.imrryr.org>
 <a4eec435-d997-4a2a-b638-afdd3ef95e31@hbmachining.com>
 <73cf0ce1-e0b4-6d4e-ad06-4f34891fe041@hbmachining.com>
 <20190603195857.GE67454@straasha.imrryr.org>
 <a3899698-51e8-2cd2-bf97-16501791c804@hbmachining.com>
Message-ID: <20190603222535.GF67454@straasha.imrryr.org>

On Mon, Jun 03, 2019 at 02:52:42PM -0700, Erik Madsen wrote:

> if (typeof options.clientCertEngine === 'string') {
>   if (c.context.setClientCertEngine)
>     c.context.setClientCertEngine(options.clientCertEngine);
> 
> options.clientCertEngine is just the path of the SO file
> 
> and it is calling openssl function:
> 
> SSL_CTX_set_client_cert_engine (SSL_CTX *ctx, ENGINE *e)
> 
> am I wrong that there should be a second argument passed from Node to 
> Openssl?

This question is best asked and answered on the node list (but it
may be worth mentioning that in an object-oriented language, the
'self' argument of object methods is generally implicit).

-- 
	Viktor.

From emadsen at hbmachining.com  Mon Jun  3 22:32:38 2019
From: emadsen at hbmachining.com (Erik Madsen)
Date: Mon, 03 Jun 2019 15:32:38 -0700
Subject: osf-contact Striking out everywhere
In-Reply-To: <20190603222535.GF67454@straasha.imrryr.org>
References: <1a8d60c6-95e8-b10b-e37e-34dae0113ccc@hbmachining.com>
 <2c9278aa-2fb3-6e0a-2c83-2535f16e0f32@openssl.org>
 <43ea2978-5ada-660c-e55d-5a617415ed2c@hbmachining.com>
 <ab413d58-6af5-4c38-d592-c940c8487847@openssl.org>
 <20190603164015.GD67454@straasha.imrryr.org>
 <a4eec435-d997-4a2a-b638-afdd3ef95e31@hbmachining.com>
 <73cf0ce1-e0b4-6d4e-ad06-4f34891fe041@hbmachining.com>
 <20190603195857.GE67454@straasha.imrryr.org>
 <a3899698-51e8-2cd2-bf97-16501791c804@hbmachining.com>
 <20190603222535.GF67454@straasha.imrryr.org>
Message-ID: <fdaf7dcc-4108-4b84-951a-9ac811627dc0@hbmachining.com>

Thanks for the clarification.

If resolution found, would you want me to report that here?

I'm off to the Node Team.

?Thanks,

Erik?


-------- Original Message --------
From: Viktor Dukhovni <openssl-users at dukhovni.org>
Sent: Mon Jun 03 15:25:35 PDT 2019
To: openssl-users at openssl.org
Subject: Re: osf-contact Striking out everywhere

On Mon, Jun 03, 2019 at 02:52:42PM -0700, Erik Madsen wrote:

> if (typeof options.clientCertEngine === 'string') {
>   if (c.context.setClientCertEngine)
>     c.context.setClientCertEngine(options.clientCertEngine);
> 
> options.clientCertEngine is just the path of the SO file
> 
> and it is calling openssl function:
> 
> SSL_CTX_set_client_cert_engine (SSL_CTX *ctx, ENGINE *e)
> 
> am I wrong that there should be a second argument passed from Node to 
> Openssl?

This question is best asked and answered on the node list (but it
may be worth mentioning that in an object-oriented language, the
'self' argument of object methods is generally implicit).

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

From shivakumar2696 at gmail.com  Tue Jun  4 08:30:59 2019
From: shivakumar2696 at gmail.com (shiva kumar)
Date: Tue, 4 Jun 2019 14:00:59 +0530
Subject: Dyanmic engine for OpenSSL 1.1.1b
Message-ID: <CAN9sONdHzHw3vDRu00Mb92ZnC4GuDbWcBzwpx1RpKF38odERSQ@mail.gmail.com>

Hi,
when I am performing make test while building OpenSSL 1.1.1b I got error as
:

../test/recipes/70-test_sslcbcpadding.t ............ skipped:
test_sslcbcpadding needs the dynamic engine feature enabled
../test/recipes/70-test_sslcertstatus.t ............ skipped:
test_sslcertstatus needs the dynamic engine feature enabled
../test/recipes/70-test_sslextension.t ............. skipped:
test_sslextension needs the dynamic engine feature enabled
../test/recipes/70-test_sslmessages.t .............. skipped:
test_sslmessages needs the dynamic engine feature enabled
../test/recipes/70-test_sslrecords.t ............... skipped:
test_sslrecords needs the dynamic engine feature enabled
../test/recipes/70-test_sslsessiontick.t ........... skipped:
test_sslsessiontick needs the dynamic engine feature enabled

what is meant by enabling dynamic engine feature ?
can anyone please explain me ?

I also got as
../test/recipes/90-test_shlibload.t ................ skipped: Test only
supported in a shared build

is they any problem if I create a n*o-shared* build ?
how is the linking works in *no-shared*  build  comapred to shared build ?
please explain me.

Thanks and Regards
Shivakumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190604/fd6e91ea/attachment.html>

From paul.dale at oracle.com  Tue Jun  4 08:35:01 2019
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Tue, 4 Jun 2019 18:35:01 +1000
Subject: Dyanmic engine for OpenSSL 1.1.1b
In-Reply-To: <CAN9sONdHzHw3vDRu00Mb92ZnC4GuDbWcBzwpx1RpKF38odERSQ@mail.gmail.com>
References: <CAN9sONdHzHw3vDRu00Mb92ZnC4GuDbWcBzwpx1RpKF38odERSQ@mail.gmail.com>
Message-ID: <CDB539B2-A27B-4AF3-853F-11F984557106@oracle.com>

You built with the no-shared option.  None of these are errors, they just aren?t supported without shared library support.

As for the linking, the difference is a single (larger) executable or a smaller executable plus a shared library.  If lots of applications use the same shared library, there is a space saving.


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



> On 4 Jun 2019, at 6:30 pm, shiva kumar <shivakumar2696 at gmail.com> wrote:
> 
> Hi,
> when I am performing make test while building OpenSSL 1.1.1b I got error as :
> 
> ../test/recipes/70-test_sslcbcpadding.t ............ skipped: test_sslcbcpadding needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslcertstatus.t ............ skipped: test_sslcertstatus needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslextension.t ............. skipped: test_sslextension needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslmessages.t .............. skipped: test_sslmessages needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslrecords.t ............... skipped: test_sslrecords needs the dynamic engine feature enabled
> ../test/recipes/70-test_sslsessiontick.t ........... skipped: test_sslsessiontick needs the dynamic engine feature enabled
> 
> what is meant by enabling dynamic engine feature ?
> can anyone please explain me ?
> 
> I also got as 
> ../test/recipes/90-test_shlibload.t ................ skipped: Test only supported in a shared build
> 
> is they any problem if I create a no-shared build ?
> how is the linking works in no-shared  build  comapred to shared build ?
> please explain me.
> 
> Thanks and Regards
> Shivakumar

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190604/4a9c9498/attachment-0001.html>

From dengwenbin_0301 at 126.com  Tue Jun  4 09:34:20 2019
From: dengwenbin_0301 at 126.com (dengwenbin_0301)
Date: Tue, 4 Jun 2019 17:34:20 +0800 (CST)
Subject: Fw: Building openssl outside of the source tree" doesn't work well
Message-ID: <302ab318.7ad4.16b21d6e682.Coremail.dengwenbin_0301@126.com>

Dear,

Please help check this. I attached the config dump in previous email.

Thanks,
Wenbin
--------- Forwarded Message ---------
From: dengwenbin_0301
Date: 05/27/2019 14:24
To: Richard Levitte
Subject: Re:Re: Fw:Re:Re: Building openssl outside of the source tree" doesn't work well
Sorry, the previously attached dump might too large to send out successfully. I copied it directly here.

Command line (with current working directory = .):

    /usr/bin/perl ../Configure linux-x86_64

Perl information:

    /usr/bin/perl
    5.22.1 for x86_64-linux-gnu-thread-multi

Enabled features:

    afalgeng
    aria
    asm
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    camellia
    capieng
    cast
    chacha
    cmac
    cms
    comp
    crmf
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    fips
    gost
    idea
    legacy
    makedepend
    md4
    mdc2
    module
    multiblock
    nextprotoneg
    pinshared
    ocb
    ocsp
    padlockeng
    pic
    poly1305
    posix-io
    psk
    rc2
    rc4
    rdrand
    rfc3779
    rmd160
    scrypt
    seed
    shared
    siphash
    siv
    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:

    ktls                    [default] OPENSSL_NO_KTLS
    asan                    [default] OPENSSL_NO_ASAN
    buildtest-c++           [default]
    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
    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
    trace                   [default] OPENSSL_NO_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 => "ar",
    ARFLAGS => "r",
    CC => "gcc",
    CFLAGS => "-Wall -O3",
    CXX => "g++",
    CXXFLAGS => "-Wall -O3",
    HASHBANGPERL => "/usr/bin/env perl",
    RANLIB => "ranlib",
    RC => "windres",
    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 => "",
    apps_init_src => "",
    apps_obj => "",
    bf_asm_src => "bf_enc.c",
    bf_obj => "bf_enc.o",
    bn_asm_src => "asm/x86_64-gcc.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 => "asm/x86_64-gcc.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 => "SIXTY_FOUR_BIT_LONG",
    build_file => "Makefile",
    build_scheme => [ "unified", "unix" ],
    cast_asm_src => "c_enc.c",
    cast_obj => "c_enc.o",
    cflags => "-pthread -m64",
    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",
    cppflags => "",
    cpuid_asm_src => "x86_64cpuid.s",
    cpuid_obj => "x86_64cpuid.o",
    cxxflags => "-std=c++11 -pthread -m64",
    defines => [  ],
    des_asm_src => "des_enc.c fcrypt_b.c",
    des_obj => "des_enc.o fcrypt_b.o",
    disable => [  ],
    dso_ldflags => "-z defs",
    dso_scheme => "dlfcn",
    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 => [ "afalgeng" ],
    ex_libs => "-ldl -pthread",
    includes => [  ],
    keccak1600_asm_src => "keccak1600-x86_64.s",
    keccak1600_obj => "keccak1600-x86_64.o",
    lflags => "",
    lib_cflags => "",
    lib_cppflags => "-DOPENSSL_USE_NODELETE -DL_ENDIAN",
    lib_defines => [  ],
    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 => "-fPIC",
    module_cxxflags => "",
    module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic",
    multilib => "64",
    padlock_asm_src => "e_padlock-x86_64.s",
    padlock_obj => "e_padlock-x86_64.o",
    perl_platform => "Unix",
    perlasm_scheme => "elf",
    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",
    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 => "-fPIC",
    shared_defflag => "-Wl,--version-script=",
    shared_defines => [  ],
    shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic",
    shared_rcflag => "",
    shared_sonameflag => "-Wl,-soname=",
    shared_target => "linux-shared",
    thread_defines => [  ],
    thread_scheme => "pthreads",
    unistd => "<unistd.h>",
    uplink_aux_src => "",
    uplink_obj => "",
    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              = ar
    ARFLAGS         = r
    CC              = gcc
    CFLAGS          = -Wall -O3
    CPPDEFINES      =
    CPPFLAGS        =
    CPPINCLUDES     =
    CXX             = g++
    CXXFLAGS        = -Wall -O3
    HASHBANGPERL    = /usr/bin/env perl
    LDFLAGS         =
    LDLIBS          =
    PERL            = /usr/bin/perl
    RANLIB          = ranlib
    RC              = windres
    RCFLAGS         =

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/unix-Makefile.tmpl
    ../Configurations/common.tmpl



Thanks,
Wenbin

zAt 2019-05-24 20:23:58, "Richard Levitte" <levitte at openssl.org> wrote:
>Well, those -I options are directly generated from 'INCLUDE'
>statements in build.info files.
>
>Would you mind giving me the output from this command?
>
>    perl configdata.pm --dump
>
>Cheers,
>Richard
>
>On Fri, 24 May 2019 04:45:11 +0200,
>dengwenbin_0301 wrote:
>> 
>> 
>> I tried on openssl-1.1.1a and openssl-1.1.1b and they all have the same issue. I think it has
>> something to do with my env. But i am not able to figure out what is the cause.
>> 
>> Thanks,
>> Wenbin
>> 
>> -------- Forwarding messages --------
>> From: "dengwenbin_0301" <dengwenbin_0301 at 126.com>
>> Date: 2019-05-22 09:40:19
>> To: "Richard Levitte" <levitte at openssl.org>
>> Subject: Re:Re: Building openssl outside of the source tree" doesn't work well
>> Thanks for your reply, Richard.
>> 
>> Yes,  the "-Iinclude -Iapps/include" is missing. I don't know why this happened. I attached the
>> the configdata.pm and its dump. Please help have a check.
>> 
>> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ git log -n 1
>> commit d3136af3c3905a730bd8fb44158aab36a2549d9b
>> Author: Richard Levitte <levitte at openssl.org>
>> Date:   Sat May 18 16:24:21 2019 -0700
>> 
>>     Configure: let platform->dsoext() default with platform->shlibextsimple()
>>    
>>     We still use '.so' as a last resort...
>>    
>>     Fixes #8950
>>    
>>     Reviewed-by: Tim Hudson <tjh at openssl.org>
>>     (Merged from https://github.com/openssl/openssl/pull/8951)
>> 
>> At 2019-05-21 11:47:14, "Richard Levitte" <levitte at openssl.org> wrote:
>> >On Tue, 21 May 2019 03:26:41 +0200,
>> >dengwenbin_0301 wrote:
>> >> 
>> >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl [master]$ cd obj/
>> >> 
>> >> wdeng at pek-dliu4-u1:~/wenbindfiles/openssl/openssl/obj [master]$ ../config
>> >> Operating system: x86_64-whatever-linux2
>> >> Configuring OpenSSL version 3.0.0-dev for target linux-x86_64
>> >> Using os-specific seed configuration
>> >> Creating configdata.pm
>> >> Creating Makefile
>> >> 
>> >> **********************************************************************
>> >> ***                                                                ***
>> >> ***   OpenSSL has been successfully configured                     ***
>> >> ***                                                                ***
>> >> ***   If you encounter a problem while building, please open an    ***
>> >> ***   issue on GitHub <https://github.com/openssl/openssl/issues> ; ***
>> >> ***   and include the output from the following command:           ***
>> >> ***                                                                ***
>> >> ***       perl configdata.pm --dump                                ***
>> >> ***                                                                ***
>> >> ***   (If you are new to OpenSSL, you might want to consult the    ***
>> >> ***   'Troubleshooting' section in the INSTALL file first)         ***
>> >> ***                                                                ***
>> >> **********************************************************************
>> >> wdeng:~/wenbindfiles/openssl/openssl/obj [master]$ make
>> >> make depend && make _all
>> >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
>> >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
>> >> make[1]: Entering directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
>> >> gcc   -fPIC -pthread -m64 -Wa,--noexecstack -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 -DPOLY1305_ASM
>> >> -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-3\"" -DMODULESDIR="\"/usr
>> >> /local/lib/ossl-modules\"" -DNDEBUG  -MMD -MF apps/libapps-lib-app_rand.d.tmp -MT apps/
>> >> libapps-lib-app_rand.o -c -o apps/libapps-lib-app_rand.o ../apps/app_rand.c
>> >> ../apps/app_rand.c:10:18: fatal error: apps.h: No such file or directory
>> >> compilation terminated.
>> >> Makefile:826: recipe for target 'apps/libapps-lib-app_rand.o' failed
>> >> make[1]: *** [apps/libapps-lib-app_rand.o] Error 1
>> >> make[1]: Leaving directory '/folk/wdeng/wenbindfiles/openssl/openssl/obj'
>> >> Makefile:165: recipe for target 'all' failed
>> >> make: *** [all] Error 2
>> >
>> >I tried exactly that just now, exactly same 'obj' ubdirectory, and it
>> >works with no problem.
>> >
>> >Something I'm noticing from your command line is that all -I options
>> >that I expect to see there are gone.  This is what I expect (note that
>> >I go directly at the object file for demonstration purposes):
>> >
>> >    : ; make apps/libapps-lib-app_rand.o 
>> >    gcc  -I. -Iinclude -Iapps/include -I.. -I../include
>> >    -I../apps/include  -fPIC -pthread -m64 -Wa,--noexecstack -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 -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\""
>> >    -DENGINESDIR="\"/usr/local/lib/engines-3\""
>> >    -DMODULESDIR="\"/usr/local/lib/ossl-modules\"" -DNDEBUG  -MMD -MF
>> >    apps/libapps-lib-app_rand.d.tmp -MT apps/libapps-lib-app_rand.o -c
>> >    -o apps/libapps-lib-app_rand.o ../apps/app_rand.c
>> >
>> >So the question is what happened to '-I. -Iinclude -Iapps/include
>> >-I.. -I../include -I../apps/include' in your build.
>> >
>> >I cannot say right now, but it might help if you show the output from
>> >'./configdata.pm --dump'
>> >
>> >Cheers,
>> >Richard
>> >
>> >-- 
>> >Richard Levitte         levitte at openssl.org
>> >OpenSSL Project         http://www.openssl.org/~levitte/
>> 
>> 
>> 
>> 
>-- 
>Richard Levitte         levitte at openssl.org
>OpenSSL Project         http://www.openssl.org/~levitte/





 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190604/1c81efce/attachment-0001.html>

From mtownsend1973 at gmail.com  Tue Jun  4 14:47:33 2019
From: mtownsend1973 at gmail.com (Martin Townsend)
Date: Tue, 4 Jun 2019 15:47:33 +0100
Subject: Signing using EVP_PKEY_encrypt when using pkcs11 engine
In-Reply-To: <CABatt_yhGOOZpvbAkX_ieMckLKSwkEDMxRovDZ-VpgjBeoyrNw@mail.gmail.com>
References: <CABatt_yhGOOZpvbAkX_ieMckLKSwkEDMxRovDZ-VpgjBeoyrNw@mail.gmail.com>
Message-ID: <CABatt_w1jaGDU7tqOg3mP2agqK71JigmnHCw+K=MsCXCc9BwVg@mail.gmail.com>

On Mon, Jun 3, 2019 at 4:35 PM Martin Townsend <mtownsend1973 at gmail.com> wrote:
>
> Hi,
>
> I'm trying to modify the evm/ima utility so that it can use a HSM to
> perform signing.  I've setup SoftHSM and used this to create a
> certificate with an RSA public key pair.  The evmctl code creates the
> hash and then calls a function to perform the sign operation which
> ends up calling
> len = RSA_private_encrypt(size + asn1->size, buf, hdr->sig,
>   key, RSA_PKCS1_PADDING);
>
> My idea was to keep the hash calculation as is, and replace the
> RSA_private_encrypt with code that uses the private key in the HSM to
> encrypt the hash buffer that has been calculated.
>
> My initialisation looks like this
>     /* Load the configuration using OPENSSL_CONF environment variable */
>     OPENSSL_config(NULL);
>     /* Try and load PKCS11 engine */
>     const char* s = getenv("OPENSSL_CONF");
>     printf("Trying to load pkcs#11 engine\n");
>     printf("OPENSSL_CONF=%s\n", s);
>     pkcs_engine = ENGINE_by_id("pkcs11");
>     if (!pkcs_engine) {
>         printf("PKCS#11 engine not found, not using HSM\n");
>     } else {
>         int rv = ENGINE_init(pkcs_engine);
>
>         if (!rv) {
>             fprintf(stderr, "PKCS#11 could not be initialised\n");
>             ENGINE_free(pkcs_engine);
>             pkcs_engine = NULL;
>         }
>
>         ENGINE_set_default(pkcs_engine, ENGINE_METHOD_ALL);
>     }
>
>     OpenSSL_add_all_algorithms();
>     OpenSSL_add_all_digests();
>     ERR_load_crypto_strings();
>
> and then I load the private key with
>
>     key = ENGINE_load_private_key(pkcs_engine, keyid, UI_OpenSSL(), NULL);
>     if (!key) {
>         log_err("%s: Failed to load private key with id: %s\n", keyid,
> __func__);
>         ERR_print_errors_fp(stderr);
>     }
>
>
> and then use the following to perform the encryption
>
>         /* Create context */
>         hsm_key_ctx = EVP_PKEY_CTX_new(hsm_key, NULL);
>         if (hsm_key_ctx == NULL) {
>             log_err("sign_hash_v2: failed to create context\n");
>             ERR_print_errors_fp(stderr);
>             return -1;
>         }
>         rv = EVP_PKEY_encrypt_init(hsm_key_ctx);
>         if (rv <= 0) {
>             log_err("sign_hash_v2: failed to init encrypt (rv=%d\n", rv);
>             ERR_print_errors_fp(stderr);
>             EVP_PKEY_CTX_free(hsm_key_ctx);
>             return -1;
>         }
>         /* TODO: What padding??? RSA_PKCS1_PSS_PADDING?? */
>         rv = EVP_PKEY_CTX_set_rsa_padding(hsm_key_ctx, RSA_PKCS1_PADDING);
>         if (rv <= 0) {
>             log_err("sign_hash_v2: failed to set RSA_PKCS1_PADDING
> (rv=%d\n", rv);
>             ERR_print_errors_fp(stderr);
>             EVP_PKEY_CTX_free(hsm_key_ctx);
>             return -1;
>         }
>         if (rv <= 0) {
>             log_err("sign_hash_v2: failed to set RSA_PKCS1_PADDING
> (rv=%d\n", rv);
>             ERR_print_errors_fp(stderr);
>             EVP_PKEY_CTX_free(hsm_key_ctx);
>             return -1;
>         }
>
>         /* Create signature */
>         outlen = 0;
>         rv = EVP_PKEY_encrypt(hsm_key_ctx, NULL, &outlen, buf, size +
> asn1->size);
>         if ((rv <= 0) || (outlen == 0)) {
>             log_err("sign_hash_v2: failed to learn needed output buf
> len (rv=%d)\n", rv);
>             ERR_print_errors_fp(stderr);
>             EVP_PKEY_CTX_free(hsm_key_ctx);
>             return -1;
>         }
>         /*outlen = 256;*/
>         log_info("EVP_PKEY_encrypt: outlen: %lu\n", outlen);
>         rv = EVP_PKEY_encrypt(hsm_key_ctx, hdr->sig, &outlen, buf,
> size + asn1->size);
>         if (rv <= 0) {
>             log_err("sign_hash_v2: EVP_PKEY_encrypt() failed (rv=%d)\n", rv);
>             ERR_print_errors_fp(stderr);
>             EVP_PKEY_CTX_free(hsm_key_ctx);
>             return -1;
>         }
>
> But I find that when I create a signature for a particular file it's
> always different with each invocation of the utility. If I try and
> verify it using the associated public key I get:
>
> RSA_public_decrypt() failed: -1
> errno: No data available (61)
> error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01
> error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed
>
> Is there something I am missing in my code above?  I tried setting the
> Engine in EVP_PKEY_CTX_new but get:
> sign_hash_v2: failed to create context
> 140174165591744:error:260C0065:engine
> routines:ENGINE_get_pkey_meth:unimplemented public key
> method:tb_pkmeth.c:128:
> 140174165591744:error:0609D09C:digital envelope
> routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:166:
> errno: Invalid argument (22)
>
> Any help appreciated,
> Martin.

I switched over to using the Cryptoki API of SoftHSMv2 and encryption
using the private key isn't allowed (I get
CKR_KEY_FUNCTION_NOT_PERMITTED error as I'm guessing the CKA_ENCRYPT
flag isn't set) which makes sense as you don't usually encrypt with a
private key but this means that I can't do what I wanted with evmctl
where the hash has already been created and just needs encrypting.  I
will take a look modifying evmctl to use the Signing function of
SoftHSM via C_Sign.

From Matthias.St.Pierre at ncp-e.com  Tue Jun  4 15:49:37 2019
From: Matthias.St.Pierre at ncp-e.com (Matthias St. Pierre)
Date: Tue, 4 Jun 2019 17:49:37 +0200
Subject: AW: Performance Issue With OpenSSL 1.1.1c
In-Reply-To: <cd9baa006973418f962e0b256668afb8@Ex13.ncp.local>
References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com>
 <ceee67ad67e080db840dfb0e34580154469fa53c.camel@redhat.com>
 <cd9baa006973418f962e0b256668afb8@Ex13.ncp.local>
Message-ID: <7cfa9c74-b303-0548-32f8-b08c0c1f00cb@ncp-e.com>

Hi,

I opened an issue on GitHub to discuss this problem in more detail.

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

It would be nice if you could join the discussion there.


Matthias


@Jay:? in particular I'm interested to learn, which linux version and distribution
you were using. On newer systems, `getentropy()` should be the method of
choice, because it does not share the deficiencies of the `/dev/urandom` device.




On 30.05.19 02:11, Dr. Matthias St. Pierre wrote:
>> To workaround the /dev/random blocking issue, you can just add:
>>
>> -DDEVRANDOM="\"/dev/urandom\""
>>
>> as a parameter to ./Configure
>>
>> This will remove the special handling of /dev/urandom and /dev/random
>> in 1.1.1c.
>
> Tom??, Jay,
>
> I'm afraid this suggestion won't help, because `DEVRANDOM_WAIT` is defined
> unconditionally in e_os.h:
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/e_os.h#L30-L34
>
> This means that the select() call will happen on linux independently of what
> `DEVRANDOM` is defined to be:
>
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1c/crypto/rand/rand_unix.c#L509-L535
>
> I think that pull request #8251 needs to be reconsidered. Give me one day or two,
> I'll create a GitHub issue for that and post the link here when it's ready.
>
> Matthias
>
>


From rsalz at akamai.com  Tue Jun  4 20:12:09 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 4 Jun 2019 20:12:09 +0000
Subject: debugging a make/dependency issue
Message-ID: <F6B69B87-88DC-4D7C-B971-A8D4F7EF9B51@akamai.com>

I am importing some code into openssl and getting a strange build error:

make[1]: *** No rule to make target 'crypto/bn/crypto/include.o', needed by 'libcrypto.a'.  Stop.

Any common ideas on what to look for (e.g., missing header file, wrong INCLUDE settings in build.info, etc) ?

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

From Matthias.St.Pierre at ncp-e.com  Wed Jun  5 05:12:25 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Wed, 5 Jun 2019 05:12:25 +0000
Subject: AW: AW: Performance Issue With OpenSSL 1.1.1c
In-Reply-To: <7cfa9c74-b303-0548-32f8-b08c0c1f00cb@ncp-e.com>
References: <88e12191-ef06-2ae9-d220-e5bb754f9c14@roadrunner.com>
 <ceee67ad67e080db840dfb0e34580154469fa53c.camel@redhat.com>
 <cd9baa006973418f962e0b256668afb8@Ex13.ncp.local>
 <7cfa9c74-b303-0548-32f8-b08c0c1f00cb@ncp-e.com>
Message-ID: <aedf8301d5a24a4d9f1fb983dad5d990@Ex13.ncp.local>

Yay,

there are some controversial discussions taking place on

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

It would be great if you could join us and provide more details about the
circumstances of your issue. In particular, information like kernel/os version
and whether the significant startup delay is encountered only at early boot time
or also when you start the daemon manually when the system is up and running.

Matthias


From sowmyapatteda at gmail.com  Thu Jun  6 06:46:06 2019
From: sowmyapatteda at gmail.com (Sowmya P)
Date: Thu, 6 Jun 2019 12:16:06 +0530
Subject: query related to openssl certificate generation of Ed X25519,X448
Message-ID: <CACUmOws4D2xT3VCXxk3arZkqf-qu5rQOuYd1HKUoGBXyfT1F4Q@mail.gmail.com>

Hi ,
Have query regarding generation of X255519 and X448 certificate chain

Below is the script which i used to generate certificate chain of Ecdsa
type.
https://github.com/raja-ashok/sample_certificates/blob/master/ECC_Prime256_Certs/gen_ecc_cert.sh

Now for generating EdDSA certificate chain I am using command from (
https://github.com/openssl/openssl/issues/6201). But with this command I am
able to generate only certificate and private key pair. But not able to
generate certificate chain.



Below is the command used for generating end entity cert

Openssl req -config openssl.cnf -new -key serverkey.pem
-subj?/C=IN/ST=kar/L=En/0=htipl/OU=team/CN=server? -outr server_cert.csr

Openssl ca -config openssl.cnf  -cert rootcert.pem -key rootkey.pem
-extensions usr_cert -subj -days 360 -md sha256 -in server_cert.csr -out
server_cert.pem
   When i executed above command below errro is thrown

Cant open ./root/private/cakey.pem for reading no such file or directory
 System library:fopen:no such file or directory:crypto/bio/bss_file.c :72
Bio routines :BIO_new_file:no such file crypto/bio:bss_file.c




Tried another command to generated server cert that is openssl x509 -req
-days 360 -in server_cert.csr -signkey rootykey.pem -sha256 -out
serever.crt

For this       elliptic curve routines:pkey_ecd_ctrl:invalid digest
type:crypto/ec/ecx_meth.c
 error will be thrown


Please help me out to resolve this issue


Thanks ,
Soumya pattada.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190606/3914b3a4/attachment-0001.html>

From bbrumley at gmail.com  Thu Jun  6 12:23:32 2019
From: bbrumley at gmail.com (Billy Brumley)
Date: Thu, 6 Jun 2019 15:23:32 +0300
Subject: query related to openssl certificate generation of Ed X25519, X448
In-Reply-To: <CACUmOws4D2xT3VCXxk3arZkqf-qu5rQOuYd1HKUoGBXyfT1F4Q@mail.gmail.com>
References: <CACUmOws4D2xT3VCXxk3arZkqf-qu5rQOuYd1HKUoGBXyfT1F4Q@mail.gmail.com>
Message-ID: <CAFeDd5Y-UXzAZbiovKv0a25wbiWF8an9yogD91VCV_Sr+RWgQg@mail.gmail.com>

I think the error messages are pretty clear in these cases. Trying to
set a hash with (standardized) EdDSA is not going to go well for you.

Have you tried this very nice walkthrough?

https://tools.ietf.org/html/draft-moskowitz-eddsa-pki-00

BBB

On Thu, Jun 6, 2019 at 9:47 AM Sowmya P <sowmyapatteda at gmail.com> wrote:
>
> Hi ,
> Have query regarding generation of X255519 and X448 certificate chain
>
> Below is the script which i used to generate certificate chain of Ecdsa type.
> https://github.com/raja-ashok/sample_certificates/blob/master/ECC_Prime256_Certs/gen_ecc_cert.sh
>
> Now for generating EdDSA certificate chain I am using command from (https://github.com/openssl/openssl/issues/6201). But with this command I am able to generate only certificate and private key pair. But not able to generate certificate chain.
>
>
>
> Below is the command used for generating end entity cert
>
> Openssl req -config openssl.cnf -new -key serverkey.pem -subj?/C=IN/ST=kar/L=En/0=htipl/OU=team/CN=server? -outr server_cert.csr
>
> Openssl ca -config openssl.cnf  -cert rootcert.pem -key rootkey.pem -extensions usr_cert -subj -days 360 -md sha256 -in server_cert.csr -out server_cert.pem
>    When i executed above command below errro is thrown
>
> Cant open ./root/private/cakey.pem for reading no such file or directory
>  System library:fopen:no such file or directory:crypto/bio/bss_file.c :72
> Bio routines :BIO_new_file:no such file crypto/bio:bss_file.c
>
>
>
>
> Tried another command to generated server cert that is openssl x509 -req -days 360 -in server_cert.csr -signkey rootykey.pem -sha256 -out serever.crt
>
> For this       elliptic curve routines:pkey_ecd_ctrl:invalid digest type:crypto/ec/ecx_meth.c
>  error will be thrown
>
>
> Please help me out to resolve this issue
>
>
> Thanks ,
> Soumya pattada.
>
>

From rashok.svks at gmail.com  Thu Jun  6 15:15:57 2019
From: rashok.svks at gmail.com (Raja Ashok)
Date: Thu, 6 Jun 2019 20:45:57 +0530
Subject: Handling signature_algorithm extension on TLS1.3 server
Message-ID: <CADSGPoFFtEbBz-Q3TMiiY7uRF_04WZA0PRPdZ2=niaWPti6CJA@mail.gmail.com>

Hi,

Currently has_usable_cert() function is called on tls_choose_sigalg() to
find out the suitable certificate available. But currently rsa_pkcs1_xxx
and rsa_pss_rsae_xxx certs are stored on same index SSL_PKEY_RSA. Because
of this it may ends in choosing rsa_pkcs1_xxx cert for rsa_pss_rsae_xxx
extension. Is this behaviour correct ?

As per my understanding a new index should be created like
SSL_PKEY_RSA_PSS_RSAE_SIGN for rsa_pss_rsae_xxx type certs.

Regards,
Raja Ashok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190606/88733d16/attachment.html>

From matt at openssl.org  Thu Jun  6 15:40:42 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 6 Jun 2019 16:40:42 +0100
Subject: Handling signature_algorithm extension on TLS1.3 server
In-Reply-To: <CADSGPoFFtEbBz-Q3TMiiY7uRF_04WZA0PRPdZ2=niaWPti6CJA@mail.gmail.com>
References: <CADSGPoFFtEbBz-Q3TMiiY7uRF_04WZA0PRPdZ2=niaWPti6CJA@mail.gmail.com>
Message-ID: <6fb3da57-ad1f-3dd3-285c-294d4328ee90@openssl.org>



On 06/06/2019 16:15, Raja Ashok wrote:
> Hi,
> 
> Currently has_usable_cert() function is called on tls_choose_sigalg() to find
> out the suitable certificate available. But currently rsa_pkcs1_xxx and
> rsa_pss_rsae_xxx certs are stored on same index SSL_PKEY_RSA. Because of this it
> may ends in choosing rsa_pkcs1_xxx cert for rsa_pss_rsae_xxx extension. Is this
> behaviour correct ?

There are two things to consider:

1) The OID in the RSA cert, which can be one of rsaEncryption or RSASSA-PSS. The
former is for "traditional" RSA certs, whilst the latter *only* allows use of
the key for signing (it cannot be used for encryption).

2) The type of signing in use, e.g. RSASSA-PKCS-v1_5 or RSASSA-PSS.

rsaEncryption certs are capable of doing *either* form of signing, whilst
RSASSA-PSS certs can only do PSS signing.

We store rsaEncryption certs under the SSL_PKEY_RSA index, and RSASSA-PSS certs
under the SSL_PKEY_RSA_PSS_SIGN index.

TLSv1.2 and below signs handshake messages using PKCS v1.5. which corresponds to
these signature algorithms:

          rsa_pkcs1_sha256(0x0401)
          rsa_pkcs1_sha384(0x0501)
          rsa_pkcs1_sha512(0x0601)

These sig algs cannot be used in TLSv1.3 for signing handshake messages,
although they may appear in a ClientHello for backwards compatibility with
TLSv1.2. You can only use these sig algs with "traditional" RSA certs (not PSS
RSA certs).

TLSv1.3 signs handshake messages using PSS which corresponds to these signature
algorithms for "traditional" (rsaEncryption) certs:

          rsa_pss_rsae_sha256(0x0804)
          rsa_pss_rsae_sha384(0x0805)
          rsa_pss_rsae_sha512(0x0806)

Or these signature algorithms for PSS certs:

          rsa_pss_pss_sha256(0x0809)
          rsa_pss_pss_sha384(0x080a)
          rsa_pss_pss_sha512(0x080b)

Therefore it is perfectly correct behaviour that a cert stored under the
SSL_PKEY_RSA index could be used for signing handshake message using either
rsa_pkcs1_xxx or for rsa_pss_rsae_xxx. The former is used in TLSv1.2 and the
latter is used in TLSv1.3.

Matt

From lj at acronisscs.com  Thu Jun  6 21:34:28 2019
From: lj at acronisscs.com (Larry Jordan)
Date: Thu, 6 Jun 2019 21:34:28 +0000
Subject: Trying to use a ((constructor)) to force libcrypto.so into FIPS mode
Message-ID: <BYAPR07MB47927BB6288B3756E4EB7142BB170@BYAPR07MB4792.namprd07.prod.outlook.com>

Re: openssl-1.0.2r
Re: openssl-fips-2.0.16
OS: Linux Mint 19.1 (Ubuntu)

I have added a shared library initializer function to cryptlib.c to force OpenSSL into FIPS mode, without requiring a ?module operator? to directly initiate (i.e. call FIPS_mode_set(1)).

void __attribute__((constructor)) ForceFIPSModeOn()
{
   FIPS_mode_set(1);
   FIPS_selftest_check();
}

The build fails shortly after creating the executable ?fips_premain_dso?.

fips.c(140): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE
Aborted (core dumped)

I traced the problem to a failed FIPS_check_incore_fingerprint call. The embedded signature appears uninitialized:

Starting FIPS_selftest
fips: 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
imem: 33 53 e6 29 f6 eb df f3 d0 23 e9 7c 39 84 91 e0 3f 32 83 b2
 failed FIPS_check_incore_fingerprint

I am at a loss to explain what is happening. Is my initializer running before the embedded sig is loaded? Or is there another issue.

If I remove the call to FIPS_selftest_check(), the link completes, but the selftest still fails, when it is initiated from the initializer. A ?module operator? can still use the libcrypto.so services, because all subsequent selftests pass.

How can I get my module initializer to pass the selftest?

Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

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

From jfriesne at gmail.com  Fri Jun  7 03:42:19 2019
From: jfriesne at gmail.com (Jeremy Friesner)
Date: Thu, 6 Jun 2019 20:42:19 -0700
Subject: Public-key based authentication of clients
Message-ID: <3F368BA8-0D4F-4E29-8D8D-C5A7B86DDF71@gmail.com>

Hi All,

I have a simple C++ client/server application, in which the clients use OpenSSL's PSK (Pre-Shared-Key) mechanism to log in to the server via TLS -- i.e. the client GUI prompts the user to enter a username and password, and when the client connects, it calls SSL_set_psk_client_callback(), and the server calls SSL_set_psk_server_callback(), and OpenSSL does its thing, and if the client's username and password matches the ones the server is expecting, the TLS connection is allowed, otherwise it is rejected.

That all works great; however, what I'd like to do now (mostly just to see if it can be done) is add an alternative, keypair-based mechanism, similar to what github (and I imagine many other web services) provide.

I imagine it would work like this: The user runs the openssl app to create a private/public keypair, and (by some external mechanism) gives the public key-file to the server, and the private key-file to the client. Then, when the client program connects to the server, it has to prove to the server (via cryptographic math) that it has the private-key file in its possession, and the server uses the public-key to verify that proof, before deciding whether to let the client continue or not.

This seems like it should be pretty straightforward, but I haven't been able to find any clear documentation or examples of how to implement it using the OpenSSL library.  Is it possible to implement this behavior using OpenSSL, and if so, how might I go about it?

Thanks,
Jeremy


From Tobias.Wolf at t-systems.com  Fri Jun  7 05:55:54 2019
From: Tobias.Wolf at t-systems.com (Tobias.Wolf at t-systems.com)
Date: Fri, 7 Jun 2019 05:55:54 +0000
Subject: authEnvelopedData 
Message-ID: <LEJPR01MB0412101FDD876ED582FE56DCA4100@LEJPR01MB0412.DEUPRD01.PROD.OUTLOOK.DE>

Hi everyone,

I need to create a "authEnvelopedData" (https://tools.ietf.org/html/rfc5083#2.1) ASN1 structure but I know how to archive this. I tried with "PKCS7_encrypt" but here I got only "envelopedData".
I`ll try next with CMS_encrypt and to modify CMS_ContentInfo to add the authEnvelopedData parameter. Would this way work?


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

From rashok.svks at gmail.com  Fri Jun  7 06:27:42 2019
From: rashok.svks at gmail.com (Raja Ashok)
Date: Fri, 7 Jun 2019 11:57:42 +0530
Subject: Handling signature_algorithm extension on TLS1.3 server
In-Reply-To: <6fb3da57-ad1f-3dd3-285c-294d4328ee90@openssl.org>
References: <CADSGPoFFtEbBz-Q3TMiiY7uRF_04WZA0PRPdZ2=niaWPti6CJA@mail.gmail.com>
 <6fb3da57-ad1f-3dd3-285c-294d4328ee90@openssl.org>
Message-ID: <CADSGPoGxtQ+Cs-4Dr7hyy03sR=t78psqpoh=r7-+GoLDwAgVxg@mail.gmail.com>

Thanks for the detailed explanation.

So rsaEncryption cert can do both RSASSA-PKCS-v1_5 and RSASSA-PSS type
signature. And also the digital signature present on the cert can be of
type RSASSA-PKCS-v1_5 or RSASSA-PSS.

Currently in 1.1.1c's has_usable_cert() function, digital signature
(Issuer's signature) present on rsaEncryption cert type is not checked. So
if TLS1.3 client sends rsa_pss_rsae_xxx in "signature_algorithm" extension
and if the server's rsaEncrypted cert has digital signature of type
RSASSA-PKCS-v1_5, then it should not use that certificate but it is using
currently.

And also the hash algorithm used on rsaEncryption cert's digital signature
is not checked with "signature_algorithm" extension received from client.
If TLS1.3 client sends rsa_pss_rsae_sha384 and rsa_pss_rsae_sha512 in
"signature_algorithm" extension, and if server has a rsaEncrypted cert with
signature of type rsa_pss_rsae_sha256 then it should not use that
certificate, but it is using currently.


On Thu, Jun 6, 2019 at 9:11 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 06/06/2019 16:15, Raja Ashok wrote:
> > Hi,
> >
> > Currently has_usable_cert() function is called on tls_choose_sigalg() to
> find
> > out the suitable certificate available. But currently rsa_pkcs1_xxx and
> > rsa_pss_rsae_xxx certs are stored on same index SSL_PKEY_RSA. Because of
> this it
> > may ends in choosing rsa_pkcs1_xxx cert for rsa_pss_rsae_xxx extension.
> Is this
> > behaviour correct ?
>
> There are two things to consider:
>
> 1) The OID in the RSA cert, which can be one of rsaEncryption or
> RSASSA-PSS. The
> former is for "traditional" RSA certs, whilst the latter *only* allows use
> of
> the key for signing (it cannot be used for encryption).
>
> 2) The type of signing in use, e.g. RSASSA-PKCS-v1_5 or RSASSA-PSS.
>
> rsaEncryption certs are capable of doing *either* form of signing, whilst
> RSASSA-PSS certs can only do PSS signing.
>
> We store rsaEncryption certs under the SSL_PKEY_RSA index, and RSASSA-PSS
> certs
> under the SSL_PKEY_RSA_PSS_SIGN index.
>
> TLSv1.2 and below signs handshake messages using PKCS v1.5. which
> corresponds to
> these signature algorithms:
>
>           rsa_pkcs1_sha256(0x0401)
>           rsa_pkcs1_sha384(0x0501)
>           rsa_pkcs1_sha512(0x0601)
>
> These sig algs cannot be used in TLSv1.3 for signing handshake messages,
> although they may appear in a ClientHello for backwards compatibility with
> TLSv1.2. You can only use these sig algs with "traditional" RSA certs (not
> PSS
> RSA certs).
>
> TLSv1.3 signs handshake messages using PSS which corresponds to these
> signature
> algorithms for "traditional" (rsaEncryption) certs:
>
>           rsa_pss_rsae_sha256(0x0804)
>           rsa_pss_rsae_sha384(0x0805)
>           rsa_pss_rsae_sha512(0x0806)
>
> Or these signature algorithms for PSS certs:
>
>           rsa_pss_pss_sha256(0x0809)
>           rsa_pss_pss_sha384(0x080a)
>           rsa_pss_pss_sha512(0x080b)
>
> Therefore it is perfectly correct behaviour that a cert stored under the
> SSL_PKEY_RSA index could be used for signing handshake message using either
> rsa_pkcs1_xxx or for rsa_pss_rsae_xxx. The former is used in TLSv1.2 and
> the
> latter is used in TLSv1.3.
>
> Matt
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190607/2f9483ad/attachment.html>

From matt at openssl.org  Fri Jun  7 11:02:08 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 7 Jun 2019 12:02:08 +0100
Subject: Handling signature_algorithm extension on TLS1.3 server
In-Reply-To: <CADSGPoGxtQ+Cs-4Dr7hyy03sR=t78psqpoh=r7-+GoLDwAgVxg@mail.gmail.com>
References: <CADSGPoFFtEbBz-Q3TMiiY7uRF_04WZA0PRPdZ2=niaWPti6CJA@mail.gmail.com>
 <6fb3da57-ad1f-3dd3-285c-294d4328ee90@openssl.org>
 <CADSGPoGxtQ+Cs-4Dr7hyy03sR=t78psqpoh=r7-+GoLDwAgVxg@mail.gmail.com>
Message-ID: <ac7e2b9d-9290-9e00-db91-069db2a36cc0@openssl.org>



On 07/06/2019 07:27, Raja Ashok wrote:
> Thanks for the detailed explanation.
> 
> So rsaEncryption cert can do both RSASSA-PKCS-v1_5 and RSASSA-PSS type
> signature. And also the digital signature present on the cert can be of type
> RSASSA-PKCS-v1_5 or RSASSA-PSS.
> 
> Currently in 1.1.1c's has_usable_cert() function, digital signature (Issuer's
> signature) present on rsaEncryption cert type is not checked. So if TLS1.3
> client sends rsa_pss_rsae_xxx in "signature_algorithm" extension and if the
> server's rsaEncrypted cert has digital signature of type RSASSA-PKCS-v1_5, then
> it should not use that certificate but it is using currently.

There are two extensions to consider signature_algorithms and
signature_algorithms_cert. From RFC8446:

   TLS 1.3 provides two extensions for indicating which signature
   algorithms may be used in digital signatures.  The
   "signature_algorithms_cert" extension applies to signatures in
   certificates, and the "signature_algorithms" extension, which
   originally appeared in TLS 1.2, applies to signatures in
   CertificateVerify messages.

Looking at the code for has_usable_cert you can see it first checking to see if
it has a certificate that can sign in accordance with signature algorithms. And
then it goes on to check whether the signature in the certificate itself is
consistent with signature_algorithms_cert.

So, if signature_algorithms_cert does not contain rsa_pkcs1_* and the
certificate contains a PKCS1.5 signature, then it shouldn't be being used.

However the RFC then goes on to say:

   If no "signature_algorithms_cert" extension is
   present, then the "signature_algorithms" extension also applies to
   signatures appearing in certificates.

This was an area of some ambiguity in the TLSv1.2 spec where only
signature_algorithms exists. I believe it was common practice for
implementations to not check the signatures in certificates for conformance with
this (certainly that is the way OpenSSL behaves). The TLSv1.3 spec seems to be
more explicit about this. I would expect our TLSv1.2 implementation to continue
to operate as it did before so this additional checking of signatures in
certificates where only the signature_algorithms extensions is present should
only apply to TLSv1.3.

I don't see any code to do this in has_usable_cert so this looks like a
potential bug. Although possibly it was left out on purpose.

Ben Kaduk may have a view on this who implemented this code:

https://github.com/openssl/openssl/pull/5068/commits/e639c37bddea48334cb45d88d407c655641e1a35


Matt

From levitte at openssl.org  Fri Jun  7 11:36:53 2019
From: levitte at openssl.org (Richard Levitte)
Date: Fri, 07 Jun 2019 13:36:53 +0200
Subject: debugging a make/dependency issue
In-Reply-To: <F6B69B87-88DC-4D7C-B971-A8D4F7EF9B51@akamai.com>
References: <F6B69B87-88DC-4D7C-B971-A8D4F7EF9B51@akamai.com>
Message-ID: <8736klzkx6.wl-levitte@openssl.org>

The first thing to do is reconfigure, as that will regenerate the
Makefile.

Otherwise, the thing I can think of is if someone mixed up INCLUDE and
SOURCE in a build.info.  The following in crypto/bn/build.info
would probably generate that kind of fault:

    SOURCE[../../libcrypto]=../include

The correct line would be:

    INCLUDE[../../libcrypto]=../include

(or well, if there's a '../include' somewhere in a SOURCE directive,
it should be removed)

Cheers,
Richard

On Tue, 04 Jun 2019 22:12:09 +0200,
Salz, Rich via openssl-users wrote:
> 
> 
> I am importing some code into openssl and getting a strange build error:
> 
> make[1]: *** No rule to make target 'crypto/bn/crypto/include.o', needed by 'libcrypto.a'.  Stop.
> 
> Any common ideas on what to look for (e.g., missing header file, wrong INCLUDE settings in
> build.info, etc) ?
> 
> 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From rashok.svks at gmail.com  Fri Jun  7 12:42:26 2019
From: rashok.svks at gmail.com (Raja Ashok)
Date: Fri, 7 Jun 2019 18:12:26 +0530
Subject: Handling signature_algorithm extension on TLS1.3 server
In-Reply-To: <ac7e2b9d-9290-9e00-db91-069db2a36cc0@openssl.org>
References: <CADSGPoFFtEbBz-Q3TMiiY7uRF_04WZA0PRPdZ2=niaWPti6CJA@mail.gmail.com>
 <6fb3da57-ad1f-3dd3-285c-294d4328ee90@openssl.org>
 <CADSGPoGxtQ+Cs-4Dr7hyy03sR=t78psqpoh=r7-+GoLDwAgVxg@mail.gmail.com>
 <ac7e2b9d-9290-9e00-db91-069db2a36cc0@openssl.org>
Message-ID: <CADSGPoEumsEU4Yvtj1RyLoQPOkR6oWvj0f-vmcA=qMm5m5Kk8g@mail.gmail.com>

>
> This was an area of some ambiguity in the TLSv1.2 spec where only
> signature_algorithms exists. I believe it was common practice for
> implementations to not check the signatures in certificates for
> conformance with
> this (certainly that is the way OpenSSL behaves). The TLSv1.3 spec seems
> to be
> more explicit about this. I would expect our TLSv1.2 implementation to
> continue
> to operate as it did before so this additional checking of signatures in
> certificates where only the signature_algorithms extensions is present
> should
> only apply to TLSv1.3.
>
> I don't see any code to do this in has_usable_cert so this looks like a
> potential bug. Although possibly it was left out on purpose.
>

Yes. Currently this check is missing for both TLSv1.2 and TLSv1.3. I feel
we may need to add for both TLSv1.2 and TLSv1.3, because TLSv1.2 RFC 5246
also mandates to do this check.

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.


Fix should be something like
https://github.com/raja-ashok/openssl/commit/2eb916d6048f54fd6109329d31850f8eb4407780

Atleast we should add this check for TLSv1.3. Otherwise cert with
rsa_pkcsv1_5_xxx signature getting selected even if client has not included
rsa_pkcsv1_5_xxx in signature_algorithm ext, but included rsa_pss_rsae_xxx.
This looks weird.

Apart from this I am having one more doubt, that TLSv1.3 RFC 8446 says
certificate with legacy signature(rsa_pkcsv1_5_sha1 and ecdsa_sha1) can be
selected if no other valid certificate present on TLS1.3 server. But in
tls_choose_sigalgs() function for TLSv1.3 we are currently skipping all
SHA1 based and RSA_PKCSv1_5 based signature algorithm. I feel instead of
avoiding we should consider as a low priority in this function for
selecting legacy certificates with rsa_pkcsv1_5 and ecdsa_sha1.


      TLS 1.3 servers MUST NOT offer a SHA-1 signed certificate unless
      no valid certificate chain can be produced without it (see
      Section 4.4.2.2 <https://tools.ietf.org/html/rfc8446#section-4.4.2.2>).




> Ben Kaduk may have a view on this who implemented this code:
>
>
> https://github.com/openssl/openssl/pull/5068/commits/e639c37bddea48334cb45d88d407c655641e1a35
>
>
And also requesting Ben Kaduk to put some light on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190607/2164d0d5/attachment-0001.html>

From rsalz at akamai.com  Fri Jun  7 12:53:00 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 7 Jun 2019 12:53:00 +0000
Subject: debugging a make/dependency issue
In-Reply-To: <8736klzkx6.wl-levitte@openssl.org>
References: <F6B69B87-88DC-4D7C-B971-A8D4F7EF9B51@akamai.com>
 <8736klzkx6.wl-levitte@openssl.org>
Message-ID: <87EA6AFE-7698-453B-A801-967DEE3CA6F3@akamai.com>

Thanks.

I had a trailing backslash on a source list, and it gobbled up the next line which was an INCLUDE directive.
 


From tshort at akamai.com  Fri Jun  7 14:49:13 2019
From: tshort at akamai.com (Short, Todd)
Date: Fri, 7 Jun 2019 14:49:13 +0000
Subject: SSL_check_chain() broken
Message-ID: <8FA0CCB3-6D13-4F2A-8B36-86D26E27BD87@akamai.com>

Hi,

It looks as though SSL_check_chain() use within the cert_cb (as recommended) was broken by PR 7257.

PR 7257 moves setting the shared_sigalgs to after the cert_cb takes place, but deep down in the call stack, SSL_check_chain() has a dependency on shared_sigalgs being set.

In 1.1.1, the following works, using SSL_check_chain() in the cert_cb. But it fails in 1.1.1a:

apps/openssl s_server -xcert apps/server.pem -xkey apps/server.pem -nocert

Is there harm in setting the shared_sigalgs before cert_cb and resetting them if SSL_set_SSL_CTX() is called? Basically what PR 7256 tried to do?

I opened issue 9099.
--
-Todd Short
// tshort at akamai.com
// ?One if by land, two if by sea, threeif by the Internet."

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

From hkario at redhat.com  Fri Jun  7 16:07:19 2019
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 07 Jun 2019 18:07:19 +0200
Subject: Handling signature_algorithm extension on TLS1.3 server
In-Reply-To: <CADSGPoEumsEU4Yvtj1RyLoQPOkR6oWvj0f-vmcA=qMm5m5Kk8g@mail.gmail.com>
References: <CADSGPoFFtEbBz-Q3TMiiY7uRF_04WZA0PRPdZ2=niaWPti6CJA@mail.gmail.com>
 <ac7e2b9d-9290-9e00-db91-069db2a36cc0@openssl.org>
 <CADSGPoEumsEU4Yvtj1RyLoQPOkR6oWvj0f-vmcA=qMm5m5Kk8g@mail.gmail.com>
Message-ID: <30591254.IpTQv7yrRR@pintsize.usersys.redhat.com>

On Friday, 7 June 2019 14:42:26 CEST Raja Ashok wrote:
> > This was an area of some ambiguity in the TLSv1.2 spec where only
> > signature_algorithms exists. I believe it was common practice for
> > implementations to not check the signatures in certificates for
> > conformance with
> > this (certainly that is the way OpenSSL behaves). The TLSv1.3 spec seems
> > to be
> > more explicit about this. I would expect our TLSv1.2 implementation to
> > continue
> > to operate as it did before so this additional checking of signatures in
> > certificates where only the signature_algorithms extensions is present
> > should
> > only apply to TLSv1.3.
> > 
> > I don't see any code to do this in has_usable_cert so this looks like a
> > potential bug. Although possibly it was left out on purpose.
> 
> Yes. Currently this check is missing for both TLSv1.2 and TLSv1.3. I feel
> we may need to add for both TLSv1.2 and TLSv1.3, because TLSv1.2 RFC 5246
> also mandates to do this check.
> 
>    If the client provided a "signature_algorithms" extension, then all
>    certificates provided by the server MUST be signed by a
>    hash/signature algorithm pair that appears in that extension.


OTOH, the practice in TLS 1.2, and behaviour codified in TLS 1.3 RFC, is that 
if you have just one chain, give it to client and let it sort out if it likes 
it or not

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190607/40e787ab/attachment.sig>

From ninjosh97 at gmail.com  Fri Jun  7 17:20:07 2019
From: ninjosh97 at gmail.com (Joshua Hutchins)
Date: Fri, 7 Jun 2019 12:20:07 -0500
Subject: Making use of the new TLS 1.3 PSK features?
Message-ID: <CABsrs4APfX0vhDPeRnZjWDJH4Pf1Bwff=+4_8uLhfb3kTbDRQQ@mail.gmail.com>

Hi, I'm pretty new to openssl (sort of new to being a developer to be
honest).
I am using libcurl to send pretty small HTTP requests every 5 or so
minutes, using TLS. I'm trying to use some of the new features in TLS 1.3
to reduce the *size* of the handshake, as this is going to be going over
mobile data and doing a full TLS handshake every 5 minutes accounts for
about 60% of my total data usage.

Any advice for this? I've already built nghttp2, openssl, and libcurl from
scratch so I have all the new features.

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190607/3c01561b/attachment.html>

From andrew.tucker at salesforce.com  Fri Jun  7 17:34:26 2019
From: andrew.tucker at salesforce.com (Andrew Tucker)
Date: Fri, 7 Jun 2019 10:34:26 -0700
Subject: Trying to use a ((constructor)) to force libcrypto.so into FIPS
 mode
In-Reply-To: <BYAPR07MB47927BB6288B3756E4EB7142BB170@BYAPR07MB4792.namprd07.prod.outlook.com>
References: <BYAPR07MB47927BB6288B3756E4EB7142BB170@BYAPR07MB4792.namprd07.prod.outlook.com>
Message-ID: <CAJ3attr9Ksmq0hjSHq-8rpEzKG5-N2WG59BU0TPiScpPL9JF6A@mail.gmail.com>

Assuming your OpenSSL library is already FIPS capable you need to build and
link with the FIPS container library enable the integrity check in your app.

Details are in section C.1 of the FIPS user guide at
https://www.openssl.org/docs/fips/UserGuide-2.0.pdf


On Thu, Jun 6, 2019 at 2:34 PM Larry Jordan via openssl-users <
openssl-users at openssl.org> wrote:

> Re: openssl-1.0.2r
>
> Re: openssl-fips-2.0.16
>
> OS: Linux Mint 19.1 (Ubuntu)
>
>
>
> I have added a shared library initializer function to cryptlib.c to force
> OpenSSL into FIPS mode, without requiring a ?module operator? to directly
> initiate (i.e. call FIPS_mode_set(1)).
>
>
>
> void __attribute__((constructor)) ForceFIPSModeOn()
>
> {
>
>    FIPS_mode_set(1);
>
>    FIPS_selftest_check();
>
> }
>
>
>
> The build fails shortly after creating the executable ?fips_premain_dso?.
>
>
>
> fips.c(140): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST
> FAILURE
>
> Aborted (core dumped)
>
>
>
> I traced the problem to a failed FIPS_check_incore_fingerprint call. The
> embedded signature appears uninitialized:
>
>
>
> Starting FIPS_selftest
> fips: 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> imem: 33 53 e6 29 f6 eb df f3 d0 23 e9 7c 39 84 91 e0 3f 32 83 b2
>  failed FIPS_check_incore_fingerprint
>
>
>
> I am at a loss to explain what is happening. Is my initializer running
> before the embedded sig is loaded? Or is there another issue.
>
>
>
> If I remove the call to FIPS_selftest_check(), the link completes, but the
> selftest still fails, when it is initiated from the initializer. A ?module
> operator? can still use the libcrypto.so services, because all subsequent
> selftests pass.
>
>
>
> How can I get my module initializer to pass the selftest?
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190607/712679e0/attachment-0001.html>

From d3ck0r at gmail.com  Fri Jun  7 17:37:32 2019
From: d3ck0r at gmail.com (J Decker)
Date: Fri, 7 Jun 2019 10:37:32 -0700
Subject: Trying to use a ((constructor)) to force libcrypto.so into FIPS
 mode
In-Reply-To: <BYAPR07MB47927BB6288B3756E4EB7142BB170@BYAPR07MB4792.namprd07.prod.outlook.com>
References: <BYAPR07MB47927BB6288B3756E4EB7142BB170@BYAPR07MB4792.namprd07.prod.outlook.com>
Message-ID: <CAA2GJqXF1PF-swt_AsPDzjRcJownvyzyK2v98td5SeRknQ2zrA@mail.gmail.com>

On Thu, Jun 6, 2019 at 2:34 PM Larry Jordan via openssl-users <
openssl-users at openssl.org> wrote:

> Re: openssl-1.0.2r
>
> Re: openssl-fips-2.0.16
>
> OS: Linux Mint 19.1 (Ubuntu)
>
>
>
> I have added a shared library initializer function to cryptlib.c to force
> OpenSSL into FIPS mode, without requiring a ?module operator? to directly
> initiate (i.e. call FIPS_mode_set(1)).
>
>
>
> void __attribute__((constructor)) ForceFIPSModeOn()
>
> {
>
>    FIPS_mode_set(1);
>
>    FIPS_selftest_check();
>
> }
>
>
>
> The build fails shortly after creating the executable ?fips_premain_dso?.
>
>
>
> fips.c(140): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST
> FAILURE
>
> Aborted (core dumped)
>

I'm gonna guess that this is calling a function before OpenSSL Is
initialized... did you also move your init code to a constructor?


>
>
> I traced the problem to a failed FIPS_check_incore_fingerprint call. The
> embedded signature appears uninitialized:
>
>
>
> Starting FIPS_selftest
> fips: 00 ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> imem: 33 53 e6 29 f6 eb df f3 d0 23 e9 7c 39 84 91 e0 3f 32 83 b2
>  failed FIPS_check_incore_fingerprint
>
>
>
> I am at a loss to explain what is happening. Is my initializer running
> before the embedded sig is loaded? Or is there another issue.
>
>
>
> If I remove the call to FIPS_selftest_check(), the link completes, but the
> selftest still fails, when it is initiated from the initializer. A ?module
> operator? can still use the libcrypto.so services, because all subsequent
> selftests pass.
>
>
>
> How can I get my module initializer to pass the selftest?
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190607/3f8e7408/attachment.html>

From hkario at redhat.com  Fri Jun  7 18:36:28 2019
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 07 Jun 2019 20:36:28 +0200
Subject: Making use of the new TLS 1.3 PSK features?
In-Reply-To: <CABsrs4APfX0vhDPeRnZjWDJH4Pf1Bwff=+4_8uLhfb3kTbDRQQ@mail.gmail.com>
References: <CABsrs4APfX0vhDPeRnZjWDJH4Pf1Bwff=+4_8uLhfb3kTbDRQQ@mail.gmail.com>
Message-ID: <2302733.1OjRvdb8jA@pintsize.usersys.redhat.com>

On Friday, 7 June 2019 19:20:07 CEST Joshua Hutchins wrote:
> Hi, I'm pretty new to openssl (sort of new to being a developer to be
> honest).
> I am using libcurl to send pretty small HTTP requests every 5 or so
> minutes, using TLS. I'm trying to use some of the new features in TLS 1.3
> to reduce the *size* of the handshake, as this is going to be going over
> mobile data and doing a full TLS handshake every 5 minutes accounts for
> about 60% of my total data usage.
> 
> Any advice for this? I've already built nghttp2, openssl, and libcurl from
> scratch so I have all the new features.

performing session resumption should stop the server from sending the 
certificate to the client ? make sure that you preserve the session data and 
use it for future connections

mismatch between the key shares sent by the client and what the server will 
use will cause the connection to fallback to HelloRetryRequest mode, sending 
just one key share will also reduce the size of the handshake ? ensure the 
enabled groups match the list and order of the list in server

ensuring the connection uses ECDSA will also reduce the size of initial 
handshake and will cause the handshake to be smaller when the resumption is 
rejected by server ? that will require reconfiguring the server

disabling sending of padding extension should also reduce the size of 
ClientHello message (at a potential cost of interoperability issues)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky?ova 115, 612 00  Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190607/944067b4/attachment.sig>

From lewis at sophists.com  Fri Jun  7 21:14:23 2019
From: lewis at sophists.com (Lewis G. Pringle, Jr.)
Date: Fri, 7 Jun 2019 17:14:23 -0400
Subject: Since I switched to OpenSSL 1.1.1c, I've found -Dpurify is not working
Message-ID: <002501d51d75$fba82ea0$f2f88be0$@sophists.com>

When I run valgrind, I get thousands of errors (exactly like I used to get
before I turned on -Dpurify).

 

I've found this problem running g++ on the last 3 versions of Ubuntu (1804,
1810, and 1904)

 

               Lewis.

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

From giovanni.fontana72 at gmail.com  Fri Jun  7 22:26:30 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Sat, 8 Jun 2019 00:26:30 +0200
Subject: failing in reproducing .so files
Message-ID: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>

Hello everybody,
I'm working on tailoring openssl (v1.1.1b) for various purposes.
Trying to compile (sending the command make on the terminal of linux) it
looks quite good the building of every files. At the end the files
libcrypto.a and libssl.a are produced, but not the ones with the extension
.so

At the end of building log I got the following:







*/usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
error: ld returned 1 exit statusMakefile:754: recipe for target
'libcrypto.so' failedmake[1]: *** [libcrypto.so] Error 1make[1]: Leaving
directory '/home/vm/progetti/OPEN_SSL/OPEN_SSL/openssl-1.1.1b'Makefile:172:
recipe for target 'all' failedmake: *** [all] Error 2*



No other errors are shown in the entire log.
Sending "make update" command it will not finish the execution (see below)






























*vm at vm-VirtualBox:~/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b$ make
update( cd .; /usr/bin/perl VMS/VMSify-conf.pl \            <
apps/openssl.cnf > apps/openssl-vms.cnf )( cd .; /usr/bin/perl
crypto/bn/bn_prime.pl <http://bn_prime.pl> > crypto/bn/bn_prime.h )( cd .;
/usr/bin/perl crypto/objects/objects.pl <http://objects.pl> -n \
crypto/objects/objects.txt \            crypto/objects/obj_mac.num \
    > crypto/objects/obj_mac.new && \    mv crypto/objects/obj_mac.new
crypto/objects/obj_mac.num )( cd .; /usr/bin/perl crypto/objects/objects.pl
<http://objects.pl> \            crypto/objects/objects.txt \
crypto/objects/obj_mac.num \            > include/openssl/obj_mac.h )( cd
.; /usr/bin/perl crypto/objects/obj_dat.pl <http://obj_dat.pl> \
include/openssl/obj_mac.h \            > crypto/objects/obj_dat.h )( cd .;
/usr/bin/perl crypto/objects/objxref.pl <http://objxref.pl> \
crypto/objects/obj_mac.num \            crypto/objects/obj_xref.txt \
        > crypto/objects/obj_xref.h )( cd .; /usr/bin/perl
crypto/conf/keysets.pl <http://keysets.pl> \                >
crypto/conf/conf_def.h )( cd .; /usr/bin/perl crypto/asn1/charmap.pl
<http://charmap.pl> \                > crypto/asn1/charmap.h )( cd .;
/usr/bin/perl fuzz/mkfuzzoids.pl <http://mkfuzzoids.pl> \
crypto/objects/obj_dat.h \            > fuzz/oids.txt )( b=`pwd`; set -e;
cd .; \          /usr/bin/perl util/ck_errf.pl <http://ck_errf.pl> -strict
-internal; \          /usr/bin/perl -I$b util/mkerr.pl <http://mkerr.pl>
-internal )*


Any help?
Thanks in advance
Giovanni Fontana
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190608/1cb24f74/attachment-0001.html>

From openssl-users at dukhovni.org  Sat Jun  8 00:20:26 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 7 Jun 2019 20:20:26 -0400
Subject: Handling signature_algorithm extension on TLS1.3 server
In-Reply-To: <30591254.IpTQv7yrRR@pintsize.usersys.redhat.com>
References: <CADSGPoFFtEbBz-Q3TMiiY7uRF_04WZA0PRPdZ2=niaWPti6CJA@mail.gmail.com>
 <ac7e2b9d-9290-9e00-db91-069db2a36cc0@openssl.org>
 <CADSGPoEumsEU4Yvtj1RyLoQPOkR6oWvj0f-vmcA=qMm5m5Kk8g@mail.gmail.com>
 <30591254.IpTQv7yrRR@pintsize.usersys.redhat.com>
Message-ID: <F0EF7165-C874-444B-9A7B-AE698B59EBA0@dukhovni.org>



> On Jun 7, 2019, at 12:07 PM, Hubert Kario <hkario at redhat.com> wrote:
> 
> OTOH, the practice in TLS 1.2, and behaviour codified in TLS 1.3 RFC, is that 
> if you have just one chain, give it to client and let it sort out if it likes 
> it or not

Absolutely.  The text in RFC5246 is a specification overreach from TLS into
X.509 that is counterproductive in practice.  We should not implement the
part of RFC5246 that would have the server fail the handshake when its
certificate chain has *potentially* unsupported signatures.  Deciding
whether the chain is OK (or even looked at all) is up to the client.

-- 
	Viktor.


From kurt at roeckx.be  Sat Jun  8 16:03:54 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 8 Jun 2019 18:03:54 +0200
Subject: Since I switched to OpenSSL 1.1.1c, I've found -Dpurify is not
 working
In-Reply-To: <002501d51d75$fba82ea0$f2f88be0$@sophists.com>
References: <002501d51d75$fba82ea0$f2f88be0$@sophists.com>
Message-ID: <20190608160353.GA16521@roeckx.be>

On Fri, Jun 07, 2019 at 05:14:23PM -0400, Lewis G. Pringle, Jr. wrote:
> When I run valgrind, I get thousands of errors (exactly like I used to get
> before I turned on -Dpurify).

You probably need commit 15d7e7997e219fc5fef3f6003cc6bd7b2e7379d4


Kurt


From kurt at roeckx.be  Sat Jun  8 16:07:16 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 8 Jun 2019 18:07:16 +0200
Subject: failing in reproducing .so files
In-Reply-To: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
Message-ID: <20190608160715.GB16521@roeckx.be>

On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
> */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:

There seems to be a problem generating the libcrypto.map file for
you. What does the file look like? Which perl version are you
using? Which libc do you use?


Kurt


From giovanni.fontana72 at gmail.com  Sun Jun  9 07:04:52 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Sun, 9 Jun 2019 09:04:52 +0200
Subject: failing in reproducing .so files
In-Reply-To: <20190608160715.GB16521@roeckx.be>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
Message-ID: <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>

Hello Kurt,


   - it's perl 5, version 26, subversion 1 (v5.26.1) built for
   x86_64-linux-gnu-thread-multi
   - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27


I guess is something from what I added since the original OPENSSL I'm able
to build, as well as other intermediate modifications. My issue is it looks
like the log doesn't give so much info and also the *make update* doesn't
complete his task.

BR
Giovanni

Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx <kurt at roeckx.be> ha
scritto:

> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>
> There seems to be a problem generating the libcrypto.map file for
> you. What does the file look like? Which perl version are you
> using? Which libc do you use?
>
>
> Kurt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190609/cfa8d7b7/attachment.html>

From dhamija_shalu at yahoo.com  Sun Jun  9 10:31:17 2019
From: dhamija_shalu at yahoo.com (shalu dhamija)
Date: Sun, 9 Jun 2019 10:31:17 +0000 (UTC)
Subject: Query related to  SSL_CTX_set_msg_callback_arg
References: <1697313919.344174.1560076277804.ref@mail.yahoo.com>
Message-ID: <1697313919.344174.1560076277804@mail.yahoo.com>

Hi All,In openssl 1.0.2, I was using? SSL_CTX_set_msg_callback_arg() API to set the application specific argument. And in the callback, I was retrieving that argument from SSL pointer received in the callback e.g. "ssl->msg_callback_arg"But in openssl1.1.1, the SSL structure members are no more accessible. And I did not find any API to get the msg_callback_arg back. Can someone please comment on this if there is any way to get the msg_callback_arg back in the callbacks from ssl pointer.
Regards,Shalini Dhamija
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190609/b2fb1281/attachment.html>

From dhamija_shalu at yahoo.com  Sun Jun  9 10:39:36 2019
From: dhamija_shalu at yahoo.com (shalu dhamija)
Date: Sun, 9 Jun 2019 10:39:36 +0000 (UTC)
Subject: Query related to session resumption in TLS1.3
In-Reply-To: <20190516164038.GZ67454@straasha.imrryr.org>
References: <1215030240.3310705.1558019010498.ref@mail.yahoo.com>
 <1215030240.3310705.1558019010498@mail.yahoo.com>
 <1144086040.3361810.1558023733499@mail.yahoo.com>
 <20190516164038.GZ67454@straasha.imrryr.org>
Message-ID: <194967166.358200.1560076776323@mail.yahoo.com>

  Hi Viktor,Thanks for your response. In my code, somehow, the ssl_read was not getting called ( due to some bug) due to which the session ticket was not being read resulting in no callback. I have fixed it and its working now.Now the resumption using TLS1.3 is working fine but I want to clarify the following behavior:As per openssl documentation:'The default number of tickets is 2; the default number of tickets sent following a resumption handshake is 1'. (https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_num_tickets.html)But in my case, following the resumption handshake, I am always getting two session tickets from the server. Is this behavior fine as it is server dependent.
Regards,Shalini Dhamija'
?
    On Thursday, 16 May, 2019, 10:10:57 pm IST, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:  
 
 On Thu, May 16, 2019 at 04:22:13PM +0000, shalu dhamija via openssl-users wrote:

> But the same flow does not work for TLS1.3. In TLSv1.3, sessions are
> established after the main handshake has completed. So, I have implemented
> the callback SSL_CTX_sess_set_new_cb. And in the callback, I am storing
> the session into the cache. In subsequent connections, the session is
> present in the map, SSL_set_session API returns true. But SSL_session_reused
> is always returning false.

This is not expected, perhaps your code is not quite right.

> I have the following queries:
> 1. Is the above mentioned approach applicable for TLS 1.3?

Yes.? It works, for example, in Postfix:

? https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L543-L547
? https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1001-L1004
? https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_client.c#L1146

> 2. There is a mention that PreShared keys are used for session
> resumption in TLS1.3.

This is misleading.? In TLS 1.3, the PSKs and session tickets have
been internally unified into a single protocol mechanism.? This
internal detail is not something that users need to worry about.

> Can someone please clarify, how should I make my
> client send psk using openssl for subsequent connection?

This is not the right question.? SSL_set_session() is all you need
for session resumption.

-- 
??? Viktor.
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190609/e165baea/attachment-0001.html>

From jgh at wizmail.org  Sun Jun  9 14:40:06 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Sun, 9 Jun 2019 15:40:06 +0100
Subject: Query related to SSL_CTX_set_msg_callback_arg
In-Reply-To: <1697313919.344174.1560076277804@mail.yahoo.com>
References: <1697313919.344174.1560076277804.ref@mail.yahoo.com>
 <1697313919.344174.1560076277804@mail.yahoo.com>
Message-ID: <e4a0f470-16d1-cbc6-1537-b6a98d632733@wizmail.org>

On 09/06/2019 11:31, shalu dhamija wrote:
> Hi All,In openssl 1.0.2, I was using? SSL_CTX_set_msg_callback_arg() API to set the application specific argument. And in the callback, I was retrieving that argument from SSL pointer received in the callback e.g. "ssl->msg_callback_arg"But in openssl1.1.1, the SSL structure members are no more accessible. And I did not find any API to get the msg_callback_arg back. Can someone please comment on this if there is any way to get the msg_callback_arg back in the callbacks from ssl pointer.

When the callback is called, the arg you set is given to the callback
function, as a function argument.  It's not intended as a general-
purpose data stash.

-- 
Cheers,
  Jeremy

From aerowolf at gmail.com  Sun Jun  9 17:30:27 2019
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Sun, 9 Jun 2019 12:30:27 -0500
Subject: failing in reproducing .so files
In-Reply-To: <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
Message-ID: <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>

Can you try building an unmodified version of the tarball, and see if it
has a problem?

-Kyle

On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <giovanni.fontana72 at gmail.com>
wrote:

> Hello Kurt,
>
>
>    - it's perl 5, version 26, subversion 1 (v5.26.1) built for
>    x86_64-linux-gnu-thread-multi
>    - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>
>
> I guess is something from what I added since the original OPENSSL I'm able
> to build, as well as other intermediate modifications. My issue is it looks
> like the log doesn't give so much info and also the *make update* doesn't
> complete his task.
>
> BR
> Giovanni
>
> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx <kurt at roeckx.be> ha
> scritto:
>
>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>>
>> There seems to be a problem generating the libcrypto.map file for
>> you. What does the file look like? Which perl version are you
>> using? Which libc do you use?
>>
>>
>> Kurt
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190609/c71a7598/attachment.html>

From jakub.openssl at gmail.com  Sun Jun  9 18:04:21 2019
From: jakub.openssl at gmail.com (Jakub Zelenka)
Date: Sun, 9 Jun 2019 19:04:21 +0100
Subject: authEnvelopedData
In-Reply-To: <LEJPR01MB0412101FDD876ED582FE56DCA4100@LEJPR01MB0412.DEUPRD01.PROD.OUTLOOK.DE>
References: <LEJPR01MB0412101FDD876ED582FE56DCA4100@LEJPR01MB0412.DEUPRD01.PROD.OUTLOOK.DE>
Message-ID: <CAPdL4POfopwhAADdqRtx0a6j7N59Z1N-dtm+dubwEk7XELM58Q@mail.gmail.com>

>
>  I need to create a ?authEnvelopedData? (
> https://tools.ietf.org/html/rfc5083#2.1) ASN1 structure but I know how to
> archive this. I tried with ?PKCS7_encrypt? but here I got only
> ?envelopedData?.
>

This is not currently supported. I created a PR some time ago that adds
support for it: https://github.com/openssl/openssl/pull/8024

It still waits for review from the OpenSSL devs...


> I`ll try next with CMS_encrypt and to modify CMS_ContentInfo to add the
> authEnvelopedData parameter. Would this way work?
>

I guess you might end up with the similar result like my PR.

Cheers

Jakub
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190609/1905543f/attachment.html>

From openssl-users at dukhovni.org  Sun Jun  9 19:33:13 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 9 Jun 2019 15:33:13 -0400
Subject: Query related to session resumption in TLS1.3
In-Reply-To: <194967166.358200.1560076776323@mail.yahoo.com>
References: <1215030240.3310705.1558019010498.ref@mail.yahoo.com>
 <1215030240.3310705.1558019010498@mail.yahoo.com>
 <1144086040.3361810.1558023733499@mail.yahoo.com>
 <20190516164038.GZ67454@straasha.imrryr.org>
 <194967166.358200.1560076776323@mail.yahoo.com>
Message-ID: <20190609193313.GA67454@straasha.imrryr.org>

On Sun, Jun 09, 2019 at 10:39:36AM +0000, shalu dhamija wrote:

>   "The default number of tickets is 2; the default number of tickets sent
>   following a resumption handshake is 1".  But in my case, following the
>   resumption handshake, I am always getting two session tickets from the
>   server.  Is this behavior fine as it is server dependent.

The behaviour is server-impementation dependent.  If the server is
not using OpenSSL, it might always return multiple tickets.  This
is IMHO unwise, because each resumption increases the number of
available tickets without bound.

In conversation with Matt Caswell he and I came up with the current
OpenSSL design in which a client that uses a pool of N concurrent
sessions *without* ticket re-use (each session repeatedly obtaining
a "continuation" ticket) obtains the requisite tickets after N-1
full handshakes, at which point no excess tickets are delivered so
long as the client's concurrency needs are met.

Servers also have the (non-default) *option* of resuming sessions
with a valid ticket *without* returning a new ticket.  Postfix makes
use of this option to vend exactly one ticket per full handshake,
and not return any new tickets on resumption.  Client MTAs that
support resumption are expected to re-use tickets.

-- 
	Viktor.

From dengwenbin_0301 at 126.com  Mon Jun 10 07:20:17 2019
From: dengwenbin_0301 at 126.com (dengwenbin_0301)
Date: Mon, 10 Jun 2019 15:20:17 +0800 (CST)
Subject: Crash in x86_64-mont5.s when running speed for RSA on openssl-1.1.1a
Message-ID: <2cbede1f.599c.16b40425538.Coremail.dengwenbin_0301@126.com>

Hello,

Starting from the rsa choice "rsa2048", there is crash due to segment fault when running speed.  RSA512 and rsa1024 doesn't have this issue.

Following is the call stacks, registers info when crash happened. It shows that the register %rbp is zero at that point. The value of %rbp is set by instruction "movq    %xmm2,$nptr " in label .L8x_no_tail. I don't understand how the algorithm in the x86_64-mont5.s works. So i have no idea why a zero value of %xmm2 was moved to %rbp at that point. Please help have a look.

(wrdbg) bt
#0  0x0000000000242d23 at __bn_sqrx8x_reduction+0x6c
#1  0x000000000023f96b at bn_sqr8x_mont+0xcb
#2  0x000000000023b014 at bn_mul_mont_fixed_top+0x64
#3  0x00000000002b61f5 at BN_mod_exp_mont+0x445
#4  0x0000000000281b1f at rsa_ossl_public_decrypt+0x28f
#5  0x0000000000285c0a at int_rsa_verify+0x8a
#6  0x0000000000285f92 at RSA_verify+0x32
#7  0x0000000000217963 at RSA_verify_loop+0x53
#8  0x00000000002176d8 at run_benchmark+0x108
#9  0x0000000000212e80 at speed_main+0x1400
#10 0x0000000000201411 in main (argc=1, argv=0x68ff20) at rtp.c:33
#11 0x0000000000201073 at _start+0x72
(wrdbg) info registers
  rax             0x0000000000000000  0                                
  rdx             0x68f8f88932a43dc0  7564068842312580544                       
  rcx             0xfffffffffffffff8  18446744073709551608                       
  rbx             0x123959978a8b3640  1313179273754523200                       
  rsi             0x0000000000000000  0                                
  rdi             0x0000000000688430  6849584                          
  rbp             0x0000000000000000  0                                
  rsp             0x00000000006883b8  6849464                          
  r8              0x123959978a8b3640  1313179273754523200                       
  r9              0xf7a5b45905344009  17844867392957857801                       
  r10             0x73dbc32a132b324b  8348480919738987083                       
  r11             0x37cda4961a791379  4021051006907913081                       
  r12             0x701103ae9d18bf8a  8075239655346847626                       
  r13             0xbfbd1a5d2ab85477  13816228219293553783                       
  r14             0x3f3610a53ecd4756  4554846375041124182                       
  r15             0xea5e26bc1a343a39  16887978242021276217                       
  rip             0x0000000000242d23  2370851                           PC
  eflags          0x00000246          582        [ pf zf if ]          
  fpu                                 None                             
  xmm                                 None     

                  __bn_sqrx8x_reduction:
0000000000242cb7:   xor     eax, eax
0000000000242cb9:   mov     rbx, qword ptr [rsp+0x28]
0000000000242cbe:   mov     rdx, qword ptr [rsp+0x38]
0000000000242cc3:   lea     rcx, ptr [rbp+r9*1-0x40]
0000000000242cc8:   mov     qword ptr [rsp+0x8], rcx
0000000000242ccd:   mov     qword ptr [rsp+0x10], rdi
0000000000242cd2:   lea     rdi, ptr [rsp+0x38]
0000000000242cd7:   jmp     0x242ce0 <__bn_sqrx8x_reduction+41>
0000000000242cd9:   nop     dword ptr [rax], eax
0000000000242ce0:   mov     r9, qword ptr [rdi+0x8]
0000000000242ce4:   mov     r10, qword ptr [rdi+0x10]
0000000000242ce8:   mov     r11, qword ptr [rdi+0x18]
0000000000242cec:   mov     r12, qword ptr [rdi+0x20]
0000000000242cf0:   mov     r8, rdx
0000000000242cf3:   imul    rdx, rbx
0000000000242cf7:   mov     r13, qword ptr [rdi+0x28]
0000000000242cfb:   mov     r14, qword ptr [rdi+0x30]
0000000000242cff:   mov     r15, qword ptr [rdi+0x38]
0000000000242d03:   mov     qword ptr [rsp+0x20], rax
0000000000242d08:   lea     rdi, ptr [rdi+0x40]
0000000000242d0c:   xor     rsi, rsi
0000000000242d0f:   mov     rcx, -8
0000000000242d16:   jmp     0x242d20 <__bn_sqrx8x_reduction+105>
0000000000242d18:   nop     dword ptr [rax+rax*1], eax
0000000000242d20:   mov     rbx, r8
0000000000242d23:   mulx    r8, rax, qword ptr [rbp]
0000000000242d29:   adcx    rax, rbx
0000000000242d2f:   adox    r8, r9

L8x_no_tail:
    adc 8*0($tptr),%r8
    adc 8*1($tptr),%r9
    adc 8*2($tptr),%r10
    adc 8*3($tptr),%r11
    adc 8*4($tptr),%r12
    adc 8*5($tptr),%r13
    adc 8*6($tptr),%r14
    adc 8*7($tptr),%r15
    adc \$0,%rax        # top-most carry
     mov    -8($nptr),%rcx      # np[num-1]
     xor    $carry,$carry
    movq    %xmm2,$nptr     # restore $nptr
    mov %r8,8*0($tptr)      # store top 512 bits
    mov %r9,8*1($tptr)
     movq   %xmm3,$num      # $num is %r9, can't be moved upwards


configdata.pm --dump:
Command line (with current working directory = .):

    /usr/bin/perl ../Configure vxworks-x86-64 no-weak-ssl-ciphers no-aria no-blake2 no-camellia no-chacha no-cmac no-md2 no-md4 no-mdc2 no-ocb no-poly1305 no-rc2 no-rc5 no-scrypt no-seed no-siphash no-sm2 no-sm3 no-sm4 no-whirlpool no-autoerrinit no-comp no-sctp no-srtp --with-rand-seed=none -DOPENSSL_SYS_VXWORKS_SUPPORT -DVXWORKS_USER_SPACE -fPIC

Perl information:

    /usr/bin/perl
    5.22.1 for x86_64-linux-gnu-thread-multi

Enabled features:

    asm
    async
    autoalginit
    autoload-config
    bf
    capieng
    cast
    cms
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dso
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    gost
    hw(-.+)?
    idea
    multiblock
    nextprotoneg
    ocsp
    pic
    posix-io
    psk
    rc4
    rdrand
    rfc3779
    rmd160
    shared
    sock
    srp
    sse2
    ssl
    static-engine
    stdio
    tests
    tls
    ts
    ui-console
    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]  
    aria                    [option]      OPENSSL_NO_ARIA (skip crypto/aria)
    asan                    [default]     OPENSSL_NO_ASAN
    autoerrinit             [option]      OPENSSL_NO_AUTOERRINIT
    blake2                  [option]      OPENSSL_NO_BLAKE2 (skip crypto/blake2)
    camellia                [option]      OPENSSL_NO_CAMELLIA (skip crypto/camellia)
    chacha                  [option]      OPENSSL_NO_CHACHA (skip crypto/chacha)
    cmac                    [option]      OPENSSL_NO_CMAC (skip crypto/cmac)
    comp                    [option]      OPENSSL_NO_COMP (skip crypto/comp)
    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
    makedepend              [unavailable]
    md2                     [option]      OPENSSL_NO_MD2 (skip crypto/md2)
    md4                     [option]      OPENSSL_NO_MD4 (skip crypto/md4)
    mdc2                    [option]      OPENSSL_NO_MDC2 (skip crypto/mdc2)
    msan                    [default]     OPENSSL_NO_MSAN
    ocb                     [option]      OPENSSL_NO_OCB
    poly1305                [option]      OPENSSL_NO_POLY1305 (skip crypto/poly1305)
    rc2                     [option]      OPENSSL_NO_RC2 (skip crypto/rc2)
    rc5                     [option]      OPENSSL_NO_RC5 (skip crypto/rc5)
    scrypt                  [option]      OPENSSL_NO_SCRYPT
    sctp                    [option]      OPENSSL_NO_SCTP
    seed                    [option]      OPENSSL_NO_SEED (skip crypto/seed)
    siphash                 [option]      OPENSSL_NO_SIPHASH (skip crypto/siphash)
    sm2                     [option]      OPENSSL_NO_SM2 (skip crypto/sm2)
    sm3                     [option]      OPENSSL_NO_SM3 (skip crypto/sm3)
    sm4                     [option]      OPENSSL_NO_SM4 (skip crypto/sm4)
    srtp                    [option]      OPENSSL_NO_SRTP
    ssl-trace               [default]     OPENSSL_NO_SSL_TRACE
    threads                 [unavailable]
    ubsan                   [default]     OPENSSL_NO_UBSAN
    unit-test               [default]     OPENSSL_NO_UNIT_TEST
    whirlpool               [option]     
    weak-ssl-ciphers        [option]      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 => "ar",
    ARFLAGS => "r",
    CC => "dummy",
    CFLAGS => "",
    HASHBANGPERL => "/usr/bin/env perl",
    RANLIB => "ranlib",
    RC => "windres",
    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 => "",
    apps_init_src => "",
    apps_obj => "",
    bf_asm_src => "bf_enc.c",
    bf_obj => "bf_enc.o",
    bn_asm_src => "asm/x86_64-gcc.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 => "asm/x86_64-gcc.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 => "SIXTY_FOUR_BIT_LONG",
    build_file => "Makefile",
    build_scheme => [ "unified", "unix" ],
    cast_asm_src => "c_enc.c",
    cast_obj => "c_enc.o",
    cflags => "",
    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",
    cppflags => "\$(VSB_CONFIG_FILE_MACRO)",
    cpuid_asm_src => "x86_64cpuid.s",
    cpuid_obj => "x86_64cpuid.o",
    defines => [  ],
    des_asm_src => "des_enc.c fcrypt_b.c",
    des_obj => "des_enc.o fcrypt_b.o",
    disable => [  ],
    dso_extension => ".so",
    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 => [  ],
    exe_extension => "",
    includes => [  ],
    keccak1600_asm_src => "keccak1600-x86_64.s",
    keccak1600_obj => "keccak1600-x86_64.o",
    lflags => "",
    lib_cflags => "",
    lib_cppflags => "",
    lib_defines => [  ],
    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 => "-shared",
    padlock_asm_src => "e_padlock-x86_64.s",
    padlock_obj => "e_padlock-x86_64.o",
    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",
    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 => ".so.\$(SHLIB_VERSION_NUMBER)",
    shared_extension_simple => ".so",
    shared_ldflag => "-shared",
    shared_rcflag => "",
    shared_target => "dummy",
    sys_id => "VXWORKS",
    thread_defines => [  ],
    thread_scheme => "(unknown)",
    unistd => "<unistd.h>",
    uplink_aux_src => "",
    uplink_obj => "",
    wp_asm_src => "wp-x86_64.s",
    wp_obj => "wp-x86_64.o",

Recorded environment:

    AR =
    BUILDFILE =
    CC =
    CROSS_COMPILE =
    CXX =
    HASHBANGPERL =
    OPENSSL_LOCAL_CONFIG_DIR =
    PERL =
    RANLIB =
    RC =
    WINDRES =
    __CNF_CFLAGS =
    __CNF_CPPDEFINES =
    __CNF_CPPFLAGS =
    __CNF_CPPINCLUDES =
    __CNF_CXXFLAGS =
    __CNF_LDFLAGS =
    __CNF_LDLIBS =

Makevars:

    AR              = ar
    ARFLAGS         = r
    CC              = dummy
    CFLAGS          = -fPIC
    CPPDEFINES      = OPENSSL_SYS_VXWORKS_SUPPORT VXWORKS_USER_SPACE
    CPPFLAGS        =
    CPPINCLUDES     =
    CXXFLAGS        = -fPIC
    HASHBANGPERL    = /usr/bin/env perl
    LDFLAGS         =
    LDLIBS          =
    PERL            = /usr/bin/perl
    RANLIB          = ranlib
    RC              = windres

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/unix-Makefile.tmpl
    ../Configurations/common.tmpl


Thanks,
Wenbin

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

From dhamija_shalu at yahoo.com  Mon Jun 10 07:16:26 2019
From: dhamija_shalu at yahoo.com (shalu dhamija)
Date: Mon, 10 Jun 2019 07:16:26 +0000 (UTC)
Subject: Query related to SSL_CTX_set_msg_callback_arg
In-Reply-To: <e4a0f470-16d1-cbc6-1537-b6a98d632733@wizmail.org>
References: <1697313919.344174.1560076277804.ref@mail.yahoo.com>
 <1697313919.344174.1560076277804@mail.yahoo.com>
 <e4a0f470-16d1-cbc6-1537-b6a98d632733@wizmail.org>
Message-ID: <430476574.632818.1560150986543@mail.yahoo.com>

 Actually while setting the callback, we can not pass the user-defined/application data. For example:?void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx,? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int (*new_session_cb)(SSL *, SSL_SESSION *));
When the callback arrives, I have SSL* and SSL_SESSION*. Earlier I was getting it from the 'msg_callback_arg' of SSL pointer but in the openssl1.1.1, SSL structure is no longer accessible.

    On Sunday, 9 June, 2019, 8:27:46 pm IST, Jeremy Harris <jgh at wizmail.org> wrote:  
 
 On 09/06/2019 11:31, shalu dhamija wrote:
> Hi All,In openssl 1.0.2, I was using? SSL_CTX_set_msg_callback_arg() API to set the application specific argument. And in the callback, I was retrieving that argument from SSL pointer received in the callback e.g. "ssl->msg_callback_arg"But in openssl1.1.1, the SSL structure members are no more accessible. And I did not find any API to get the msg_callback_arg back. Can someone please comment on this if there is any way to get the msg_callback_arg back in the callbacks from ssl pointer.

When the callback is called, the arg you set is given to the callback
function, as a function argument.? It's not intended as a general-
purpose data stash.

-- 
Cheers,
? Jeremy
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/81784131/attachment.html>

From openssl-users at dukhovni.org  Mon Jun 10 08:32:29 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jun 2019 04:32:29 -0400
Subject: Query related to SSL_CTX_set_msg_callback_arg
In-Reply-To: <430476574.632818.1560150986543@mail.yahoo.com>
References: <1697313919.344174.1560076277804.ref@mail.yahoo.com>
 <1697313919.344174.1560076277804@mail.yahoo.com>
 <e4a0f470-16d1-cbc6-1537-b6a98d632733@wizmail.org>
 <430476574.632818.1560150986543@mail.yahoo.com>
Message-ID: <20190610083229.GD67454@straasha.imrryr.org>

On Mon, Jun 10, 2019 at 07:16:26AM +0000, shalu dhamija via openssl-users wrote:

>  Actually while setting the callback, we can not pass the user-defined/application data.

You can however attach it to the SSL connection handle as "ex_data":

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_misc.c#L300-L304
    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L395-L406
    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L812-L817

and retrieve it from the SSL handle as needed:

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_server.c#L265

-- 
	Viktor.

From giovanni.fontana72 at gmail.com  Mon Jun 10 08:34:34 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Mon, 10 Jun 2019 10:34:34 +0200
Subject: failing in reproducing .so files
In-Reply-To: <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
 <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
Message-ID: <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>

The unmodified version works. As I said, it's sure the issue is on what I
added, but info from the building logs is not sufficient to figure out what
is the issue there. So as result of the building I have just:

   - libcrypto.a
   - libssl.a
   - libcrypto.map


so what is missing are the following files:

   - libssl.map
   - libcrypto.so
   - libssl.so


Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <aerowolf at gmail.com>
ha scritto:

> Can you try building an unmodified version of the tarball, and see if it
> has a problem?
>
> -Kyle
>
> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <giovanni.fontana72 at gmail.com>
> wrote:
>
>> Hello Kurt,
>>
>>
>>    - it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>    x86_64-linux-gnu-thread-multi
>>    - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>
>>
>> I guess is something from what I added since the original OPENSSL I'm
>> able to build, as well as other intermediate modifications. My issue is
>> it looks like the log doesn't give so much info and also the *make
>> update* doesn't complete his task.
>>
>> BR
>> Giovanni
>>
>> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx <kurt at roeckx.be> ha
>> scritto:
>>
>>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>>>
>>> There seems to be a problem generating the libcrypto.map file for
>>> you. What does the file look like? Which perl version are you
>>> using? Which libc do you use?
>>>
>>>
>>> Kurt
>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/45b174a0/attachment.html>

From jgh at wizmail.org  Mon Jun 10 10:05:08 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 10 Jun 2019 11:05:08 +0100
Subject: Query related to SSL_CTX_set_msg_callback_arg
In-Reply-To: <20190610083229.GD67454@straasha.imrryr.org>
References: <1697313919.344174.1560076277804.ref@mail.yahoo.com>
 <1697313919.344174.1560076277804@mail.yahoo.com>
 <e4a0f470-16d1-cbc6-1537-b6a98d632733@wizmail.org>
 <430476574.632818.1560150986543@mail.yahoo.com>
 <20190610083229.GD67454@straasha.imrryr.org>
Message-ID: <03ec8f42-3ce9-54a5-1c42-401d7bae8395@wizmail.org>

On 10/06/2019 09:32, Viktor Dukhovni wrote:
> On Mon, Jun 10, 2019 at 07:16:26AM +0000, shalu dhamija via openssl-users wrote:
> 
>>  Actually while setting the callback, we can not pass the user-defined/application data.
> 
> You can however attach it to the SSL connection handle as "ex_data":

I fail to see the point.  You don't need to pass the data, only a
pointer to the data.  Any time you set the callback, you can set
the callback-arg.  When the callback is called it is given the arg;
if the arg was a pointer you can deref to get the data... which could
have been manipulated as needed in the interim.

Using the ex_data facility is not needed.

-- 
Cheers,
  Jeremy

From swamy.j-s at in.abb.com  Mon Jun 10 11:52:15 2019
From: swamy.j-s at in.abb.com (Swamy J-S)
Date: Mon, 10 Jun 2019 11:52:15 +0000
Subject: Issue with EVP_sha256 and Tspi_Context_CreateObject
Message-ID: <HE1PR0602MB3643B8E469CCCC4F3679CE2A96130@HE1PR0602MB3643.eurprd06.prod.outlook.com>

Hi,

Earlier with openssl 1.0.2n version, I was using EVP_sha256 for creating Certificate Signing Request  and "TSS_HASH_OTHER" flag in Tspi_Context_CreateObject.

Recently I upgraded openssl to 1.1.0g version and now am getting "Signature Verify Failure" in my CSR. I have attached the screenshot here

If I use EVP_sha1 and TSS_HASH_SHA1, then I am able to generate certificate but if it fails in TLS Handshake with my HTTPS Server.

Are there any changes in openssl engine structure with respect to Signing and private key encryption in openssl 1.1.0?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/bbf34a2e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Untitled.png
Type: image/png
Size: 37358 bytes
Desc: Untitled.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/bbf34a2e/attachment-0001.png>

From aerowolf at gmail.com  Mon Jun 10 14:12:43 2019
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Mon, 10 Jun 2019 09:12:43 -0500
Subject: failing in reproducing .so files
In-Reply-To: <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
 <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
 <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>
Message-ID: <CAPMEXDYMRfpEyJtUObDJ0OagS9bViiOtOX48RxE3QC9RyeTuLw@mail.gmail.com>

In the unmodified directory:
$ make clean
$ make 2>&1 | tee /tmp/openssl-working-build.log

In the modified directory:
$ make clean
$ make 2>&1 | tee /tmp/openssl-broken-build.log

$ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
${PAGER:more}

Take note of the differences in output, and use that to determine what
broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
when you need to capture why something is failing.)

Good luck.

-Kyle H

On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <giovanni.fontana72 at gmail.com>
wrote:

> The unmodified version works. As I said, it's sure the issue is on what I
> added, but info from the building logs is not sufficient to figure out what
> is the issue there. So as result of the building I have just:
>
>    - libcrypto.a
>    - libssl.a
>    - libcrypto.map
>
>
> so what is missing are the following files:
>
>    - libssl.map
>    - libcrypto.so
>    - libssl.so
>
>
> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <aerowolf at gmail.com>
> ha scritto:
>
>> Can you try building an unmodified version of the tarball, and see if it
>> has a problem?
>>
>> -Kyle
>>
>> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <giovanni.fontana72 at gmail.com>
>> wrote:
>>
>>> Hello Kurt,
>>>
>>>
>>>    - it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>>    x86_64-linux-gnu-thread-multi
>>>    - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>>
>>>
>>> I guess is something from what I added since the original OPENSSL I'm
>>> able to build, as well as other intermediate modifications. My issue is
>>> it looks like the log doesn't give so much info and also the *make
>>> update* doesn't complete his task.
>>>
>>> BR
>>> Giovanni
>>>
>>> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx <kurt at roeckx.be> ha
>>> scritto:
>>>
>>>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>>>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>>>>
>>>> There seems to be a problem generating the libcrypto.map file for
>>>> you. What does the file look like? Which perl version are you
>>>> using? Which libc do you use?
>>>>
>>>>
>>>> Kurt
>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/309aea4d/attachment.html>

From jeremy.farrell at oracle.com  Mon Jun 10 14:21:29 2019
From: jeremy.farrell at oracle.com (J. J. Farrell)
Date: Mon, 10 Jun 2019 15:21:29 +0100
Subject: Query related to SSL_CTX_set_msg_callback_arg
In-Reply-To: <03ec8f42-3ce9-54a5-1c42-401d7bae8395@wizmail.org>
References: <1697313919.344174.1560076277804.ref@mail.yahoo.com>
 <1697313919.344174.1560076277804@mail.yahoo.com>
 <e4a0f470-16d1-cbc6-1537-b6a98d632733@wizmail.org>
 <430476574.632818.1560150986543@mail.yahoo.com>
 <20190610083229.GD67454@straasha.imrryr.org>
 <03ec8f42-3ce9-54a5-1c42-401d7bae8395@wizmail.org>
Message-ID: <08e23a0e-a1ba-fec2-03ba-fdf1faf4cca0@oracle.com>

On 10/06/2019 11:05, Jeremy Harris wrote:
> On 10/06/2019 09:32, Viktor Dukhovni wrote:
>> On Mon, Jun 10, 2019 at 07:16:26AM +0000, shalu dhamija via openssl-users wrote:
>>
>>> Actually while setting the callback, we can not pass the user-defined/application data.
>> You can however attach it to the SSL connection handle as "ex_data":
> I fail to see the point.  You don't need to pass the data, only a
> pointer to the data.

Well ... obviously ...

> Any time you set the callback, you can set the callback-arg.

How? As Shalu quoted, the prototype of the call to set the callback is

|void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, int (*new_session_cb)(SSL *, 
SSL_SESSION *));|


How do we specify a user-defined callback data pointer in that call?

> When the callback is called it is given the arg;

Where? According to the prototype which Shalu quoted the callback gets 
just a pointer to an SSL and a pointer to an SSL_SESSION; neither of 
those is a user-defined data pointer.

> if the arg was a pointer you can deref to get the data... which could
> have been manipulated as needed in the interim.
>
> Using the ex_data facility is not needed.

I may be missing something, but I can't see any other way to do it.

-- 
J. J. Farrell
Not speaking for Oracle

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

From jgh at wizmail.org  Mon Jun 10 14:54:23 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Mon, 10 Jun 2019 15:54:23 +0100
Subject: Query related to SSL_CTX_set_msg_callback_arg
In-Reply-To: <08e23a0e-a1ba-fec2-03ba-fdf1faf4cca0@oracle.com>
References: <1697313919.344174.1560076277804.ref@mail.yahoo.com>
 <1697313919.344174.1560076277804@mail.yahoo.com>
 <e4a0f470-16d1-cbc6-1537-b6a98d632733@wizmail.org>
 <430476574.632818.1560150986543@mail.yahoo.com>
 <20190610083229.GD67454@straasha.imrryr.org>
 <03ec8f42-3ce9-54a5-1c42-401d7bae8395@wizmail.org>
 <08e23a0e-a1ba-fec2-03ba-fdf1faf4cca0@oracle.com>
Message-ID: <93d1db5d-9579-dcc5-6853-2ad20f159182@wizmail.org>

On 10/06/2019 15:21, J. J. Farrell wrote:
> |void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, int (*new_session_cb)(SSL *,
> SSL_SESSION *));|
> 
> 
> How do we specify a user-defined callback data pointer in that call?

You don't; you additionally use
  SSL_CTX_set_msg_callback_arg()
which the OP said he was already using.

-- 
Cheers,
  Jeremy

From intera_91 at yahoo.co.uk  Mon Jun 10 15:21:16 2019
From: intera_91 at yahoo.co.uk (Patrick Regnouf)
Date: Mon, 10 Jun 2019 15:21:16 +0000 (UTC)
Subject: New to the list and one question ;-)
References: <878602270.1383842.1560180076719.ref@mail.yahoo.com>
Message-ID: <878602270.1383842.1560180076719@mail.yahoo.com>

Hello all,?
Hello all,?
Presently writing a server/relay dealing with an h264 stream.
one of the threads' job is to establish a handshake with the browser requesting the stream in order to feed the libsrtp2 with keys and salts and start encrypting the h264 stream towards the browser.
all is well and good when the program works on the linux PC and the handshake is succesful using the 0xc02f cipher. and that is linked to version 3.0.0 of openssl.
on the embedded version, (linked with version? 1.0.2s)? firefox fails the handshake with ssl_no_shared_cipher whereas chrome and safari do successfully handshake
chrome client hello contains 12 ciphers and the server hello seems to choose 0xc02f cipher
firefox client hello contains only 10 ciphers (including the above mentioned 0xc02f cipher) and fails.
any suggestion as to what could causes that failure would be appreciated.
Thanks




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/91cf6112/attachment-0001.html>

From Michal.Trojnara at stunnel.org  Mon Jun 10 16:09:32 2019
From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=)
Date: Mon, 10 Jun 2019 18:09:32 +0200
Subject: stunnel 5.55 released
Message-ID: <fe332081-d25c-b37d-9995-a278ad5345ed@stunnel.org>

Dear Users,

I have released version 5.55 of stunnel.
This release addresses a number of important Windows issues, including
security vulnerabilities.

Version 5.55, 2019.06.10, urgency: HIGH
* Security bugfixes
? - Fixed a Windows local privilege escalation vulnerability
??? caused insecure OpenSSL cross-compilation defaults.
??? Successful exploitation requires stunnel to be deployed
??? as a Windows service, and user-writable C:\ folder. This
??? vulnerability was discovered and reported by Rich Mirch.
? - OpenSSL DLLs updated to version 1.1.1c.
* Bugfixes
? - Implemented a workaround for Windows hangs caused by its
??? inability to the monitor the same socket descriptor from
??? multiple threads.
? - Windows configuration (including cryptographic keys)
??? is now completely removed at uninstall.
? - A number of testing framework fixes and improvements.

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

SHA-256 hashes:
90de69f41c58342549e74c82503555a6426961b29af3ed92f878192727074c62?
stunnel-5.55.tar.gz
e586b68da9e4faedf41cbcc8378402d7b188bb25b1f0f3cd1f2ce68620ef9e29?
stunnel-5.55-win64-installer.exe
7af80d424986149629aad7d75710400f58ba259042c58557adf743627b5c8e3c?
stunnel-5.55-android.zip

Best regards,
??? Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/1fe47054/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/1fe47054/attachment.sig>

From openssl-users at dukhovni.org  Mon Jun 10 17:18:07 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jun 2019 13:18:07 -0400
Subject: Query related to SSL_CTX_set_msg_callback_arg
In-Reply-To: <93d1db5d-9579-dcc5-6853-2ad20f159182@wizmail.org>
References: <1697313919.344174.1560076277804.ref@mail.yahoo.com>
 <1697313919.344174.1560076277804@mail.yahoo.com>
 <e4a0f470-16d1-cbc6-1537-b6a98d632733@wizmail.org>
 <430476574.632818.1560150986543@mail.yahoo.com>
 <20190610083229.GD67454@straasha.imrryr.org>
 <03ec8f42-3ce9-54a5-1c42-401d7bae8395@wizmail.org>
 <08e23a0e-a1ba-fec2-03ba-fdf1faf4cca0@oracle.com>
 <93d1db5d-9579-dcc5-6853-2ad20f159182@wizmail.org>
Message-ID: <7D5ECA53-B687-42AA-960F-9946A7996DF5@dukhovni.org>

> On Jun 10, 2019, at 10:54 AM, Jeremy Harris <jgh at wizmail.org> wrote:
> 
>> |void SSL_CTX_sess_set_new_cb(SSL_CTX *ctx, int (*new_session_cb)(SSL *,
>> SSL_SESSION *));|
>> 
>> 
>> How do we specify a user-defined callback data pointer in that call?
> 
> You don't; you additionally use
>  SSL_CTX_set_msg_callback_arg()
> which the OP said he was already using.

That was a different callback (upthread), the OP is now asking about
the new session callback, which has no explicit application argument.
Perhaps there should be a new "_ex" version that supports an argument,
but in the meantime applications that want an application context with
the new session callback have been using ex_data for the last decade
or two.

-- 
	Viktor.


From openssl-users at dukhovni.org  Mon Jun 10 17:41:10 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jun 2019 13:41:10 -0400
Subject: New to the list and one question ;-)
In-Reply-To: <878602270.1383842.1560180076719@mail.yahoo.com>
References: <878602270.1383842.1560180076719.ref@mail.yahoo.com>
 <878602270.1383842.1560180076719@mail.yahoo.com>
Message-ID: <20190610174109.GF67454@straasha.imrryr.org>

On Mon, Jun 10, 2019 at 03:21:16PM +0000, Patrick Regnouf via openssl-users wrote:

> All is well and good when the program works on the linux PC and the
> handshake is succesful using the 0xc02f cipher. and that is linked to
> version 3.0.0 of openssl.  on the embedded version, (linked with version
> 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas
> chrome and safari do successfully handshake chrome client hello contains
> 12 ciphers and the server hello seems to choose 0xc02f cipher firefox
> client hello contains only 10 ciphers (including the above mentioned 0xc02f
> cipher) and fails.  any suggestion as to what could causes that failure
> would be appreciated.

In addition to the cipher algorithm, the two parties must also agree
on the signature algorithms, supported EC groups, ...

You've not provided much detail about the configuration of the
embedded (1.0.2s) server.  The cipher that works with the other
browsers is:

    0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD

this requires a shared ECDHE curve, are you using "auto", or an
explicit curve?  What are the signature algorithms on your certificate
chain?

It would also be useful to post PCAP files of a working handshake
with Chrome, and a failing handshake with Firefox.

-- 
	Viktor.

From jakub.openssl at gmail.com  Mon Jun 10 17:52:58 2019
From: jakub.openssl at gmail.com (Jakub Zelenka)
Date: Mon, 10 Jun 2019 18:52:58 +0100
Subject: CMS and GCM
In-Reply-To: <cdb9f869-76dc-650d-8755-76821e3037d3@openca.org>
References: <cdb9f869-76dc-650d-8755-76821e3037d3@openca.org>
Message-ID: <CAPdL4PPkrVSATuQueEO6OhSnMa-Qo2PU9njs_mF=KpXG3N0YZA@mail.gmail.com>

Hi,

On Mon, May 13, 2019 at 12:50 AM Dr. Pala <madwolf at openca.org> wrote:

> Hi All,
>
> I am having issues using AES GCM in EnvelopedData - in particular if I use
> AES CBC, that is ok, but when I try to use the GCM mode, I simply cannot
> finalize the data.
>
>  If you want to use AES GCM, then you need AuthEnvelopedData.

> Are there any specific operations that need to happen in order to use AES
> in GCM mode (as per RFC5084) ?
>
>  I have created a PR for this:
https://github.com/openssl/openssl/pull/8024 . It just needs a review from
OpenSSL committers. I also need to rebase it once anyone is interested in
reviewing it. :)

Cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/4dd863fd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ddaoiiheablnooch.png
Type: image/png
Size: 3146 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190610/4dd863fd/attachment.png>

From paul at mad-scientist.net  Mon Jun 10 17:52:06 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Mon, 10 Jun 2019 13:52:06 -0400
Subject: Question: why doesn't my wildcard matching work with OpenSSL?
Message-ID: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>

I'm having problems trying to get wildcard matching working with
OpenSSL.  Full hostname matching is working fine, but when my
certification uses a wildcard I always get an error.  That includes
both with OpenSSL 1.1.1b linked into my normal client, AND with the
openssl CLI with a system default version.  However, trying to use this
same certificate and hostname matching works fine with Java and Python
clients.

Note for my C client I have not set any special flags for matching, I'm
just using the default and using SSL_set1_host() to add the hostname. 
But, I can't even get it to work with openssl itself.

I feel like I must be missing something dumb.  Any pointers
appreciated!

For example, here's a connection attempt using the CLI... note if I
remove the -verify_hostname option the connection works fine:


$ openssl s_client -connect admin0.domain:8004 \
    -CAfile ca.cert -verify_hostname admin0.domain

CONNECTED(00000003)
depth=1 C = US, ST = MA, L = Boston, O = Mycorp, OU = Eng, CN = ca.mycorp.com
verify return:1
depth=0 CN = *.domain
verify return:1
---
Certificate chain
 0 s:/CN=*.domain
   i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
 1 s:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
   i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
---
Server certificate
-----BEGIN CERTIFICATE-----
  ...
-----END CERTIFICATE-----
subject=/CN=*.domain
issuer=/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
---
Acceptable client certificate CA names
/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=nuocmd.mycorp.com
/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: ...
Shared Requested Signature Algorithms: ...
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
  ...
---
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: ...
    Session-ID-ctx: 
    Master-Key: ...
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1560181877
    Timeout   : 300 (sec)
    Verify return code: 62 (Hostname mismatch)



From openssl-users at dukhovni.org  Mon Jun 10 18:23:48 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jun 2019 14:23:48 -0400
Subject: Question: why doesn't my wildcard matching work with OpenSSL?
In-Reply-To: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>
References: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>
Message-ID: <20190610182348.GI67454@straasha.imrryr.org>

On Mon, Jun 10, 2019 at 01:52:06PM -0400, Paul Smith wrote:

> Note for my C client I have not set any special flags for matching, I'm
> just using the default and using SSL_set1_host() to add the hostname. 
> But, I can't even get it to work with openssl itself.
> 
> For example, here's a connection attempt using the CLI... note if I
> remove the -verify_hostname option the connection works fine:
> 
> $ openssl s_client -connect admin0.domain:8004 \
>     -CAfile ca.cert -verify_hostname admin0.domain
> 
> CONNECTED(00000003)
> depth=1 C = US, ST = MA, L = Boston, O = Mycorp, OU = Eng, CN = ca.mycorp.com
> verify return:1
> depth=0 CN = *.domain
> verify return:1
> ---
> Certificate chain
>  0 s:/CN=*.domain
>    i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
>  1 s:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
>    i:/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
>   ...
> -----END CERTIFICATE-----
> subject=/CN=*.domain
> issuer=/C=US/ST=MA/L=Boston/O=Mycorp/OU=Eng/CN=ca.mycorp.com
> ---
>     Verify return code: 62 (Hostname mismatch)

It seems that you've elided too much information.  Is the hostname
really "admin0.domain", or is there some underlying domain name
that you've obfuscated?

-- 
	Viktor.

From paul at mad-scientist.net  Mon Jun 10 18:39:27 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Mon, 10 Jun 2019 14:39:27 -0400
Subject: Question: why doesn't my wildcard matching work with OpenSSL?
In-Reply-To: <20190610182348.GI67454@straasha.imrryr.org>
References: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>
 <20190610182348.GI67454@straasha.imrryr.org>
Message-ID: <1d34814f8e5853483df3600d784b97f693103ae0.camel@mad-scientist.net>

On Mon, 2019-06-10 at 14:23 -0400, Viktor Dukhovni wrote:
> > $ openssl s_client -connect admin0.domain:8004 \
> >      -CAfile ca.cert -verify_hostname admin0.domain
> > 
> > ---
> >      Verify return code: 62 (Hostname mismatch)
> 
> It seems that you've elided too much information.  Is the hostname
> really "admin0.domain", or is there some underlying domain name
> that you've obfuscated?

I tried not to elide anything other than a lot of keys and stuff. 
Maybe that info isn't output?

That is actually the hostname (I have this running in a Docker
container to get the hostname set up without a lot of hassle).

But maybe that's my confusion.  What "hostname" is OpenSSL looking at? 
I told it the name I wanted it to use for the verify on the command
line: "-verify_hostname admin0.domain", which matches the wildcard the
certificate provides.

That appears to be what the docs say; from verify(1ssl):

 -verify_hostname hostname
     Verify if the hostname matches DNS name in Subject Alternative Name
     or Common Name in the subject certificate.

I thought that's all it used: this value plus the wildcard in the
certificate.  Am I misunderstanding this?  Where else will openssl go
looking for hostnames to match?

Note that if I don't use wildcards but instead have a full hostname in
the certificate, then verify hostname does work.  It's only using a
wildcard that doesn't match the way I thought it would.

Thanks for the reply!


From openssl-users at dukhovni.org  Mon Jun 10 19:14:59 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jun 2019 15:14:59 -0400
Subject: Question: why doesn't my wildcard matching work with OpenSSL?
In-Reply-To: <1d34814f8e5853483df3600d784b97f693103ae0.camel@mad-scientist.net>
References: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>
 <20190610182348.GI67454@straasha.imrryr.org>
 <1d34814f8e5853483df3600d784b97f693103ae0.camel@mad-scientist.net>
Message-ID: <D64B0A31-6F3B-4030-88CD-A04DFC87B7AF@dukhovni.org>

> On Jun 10, 2019, at 2:39 PM, Paul Smith <paul at mad-scientist.net> wrote:
> 
> On Mon, 2019-06-10 at 14:23 -0400, Viktor Dukhovni wrote:
>>> $ openssl s_client -connect admin0.domain:8004 \
>>>     -CAfile ca.cert -verify_hostname admin0.domain
>>> 
>>> ---
>>>     Verify return code: 62 (Hostname mismatch)
>> 
>> It seems that you've elided too much information.  Is the hostname
>> really "admin0.domain", or is there some underlying domain name
>> that you've obfuscated?
> 
> I tried not to elide anything other than a lot of keys and stuff. 
> Maybe that info isn't output?
> 
> That is actually the hostname (I have this running in a Docker
> container to get the hostname set up without a lot of hassle).

As a safety measure, OpenSSL does not support "*.tld" wildcards.
The non-wildcard portion of the domain name needs to have at
least two labels.  It seems I've neglected to document this... :-(

You can have "*.domain.example", but not "*.domain".

-- 
	Viktor.


From Michael.Wojcik at microfocus.com  Mon Jun 10 20:12:15 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 10 Jun 2019 20:12:15 +0000
Subject: Question: why doesn't my wildcard matching work with OpenSSL?
In-Reply-To: <bb85dbe4df0bdd962690e9c9035828234d83119c.camel@mad-scientist.net>
References: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>
 <BYAPR18MB2918E4627691F981F9679F4CF9130@BYAPR18MB2918.namprd18.prod.outlook.com>
 <bb85dbe4df0bdd962690e9c9035828234d83119c.camel@mad-scientist.net>
Message-ID: <BYAPR18MB29182FA2268163699B0DE4E5F9130@BYAPR18MB2918.namprd18.prod.outlook.com>

I don't know why you sent this to me directly rather than to the list.

> From: Paul Smith [mailto:paul at mad-scientist.net]
> Sent: Monday, June 10, 2019 12:54
> To: Michael Wojcik
>
> On Mon, 2019-06-10 at 18:49 +0000, Michael Wojcik wrote:
> > Argh. You cut out the actual relevant information. We need to see the
> > server certificate.
> >
> > In particulary, does it contain any Subject Alternative Name
> > extensions?
>
> What I cut out was only the base64-encoded certificate.

Yes. That was what we needed to see. The certificate.

> There weren't any settings shown there.

I didn't mention "settings". I discussed Subject Alternative Name extensions, which are part of the certificate.

> > I have a vague memory that wildcard matching only works with SANs.

As it turns out, you're hitting the OpenSSL restriction on wildcards with fewer than two domain components, as Viktor explained. I'd forgotten about that restriction.

However, I still recommend using a proper X.509v3 server certificate with one or more SANs. If you're running your own CA using the openssl utiltity, there are various online tutorials showing how to generate modern certificates.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From paul at mad-scientist.net  Mon Jun 10 20:31:54 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Mon, 10 Jun 2019 16:31:54 -0400
Subject: Question: why doesn't my wildcard matching work with OpenSSL?
In-Reply-To: <BYAPR18MB29182FA2268163699B0DE4E5F9130@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>
 <BYAPR18MB2918E4627691F981F9679F4CF9130@BYAPR18MB2918.namprd18.prod.outlook.com>
 <bb85dbe4df0bdd962690e9c9035828234d83119c.camel@mad-scientist.net>
 <BYAPR18MB29182FA2268163699B0DE4E5F9130@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <bb104c0eff62d5278825c6ee5d7c14a49451b193.camel@mad-scientist.net>

On Mon, 2019-06-10 at 20:12 +0000, Michael Wojcik wrote:
> > What I cut out was only the base64-encoded certificate.
> 
> Yes. That was what we needed to see. The certificate.

Yep, that's my bad.  Thanks for the reminder.

> As it turns out, you're hitting the OpenSSL restriction on wildcards
> with fewer than two domain components, as Viktor explained. I'd
> forgotten about that restriction.
> 
> However, I still recommend using a proper X.509v3 server certificate
> with one or more SANs. If you're running your own CA using the
> openssl utiltity, there are various online tutorials showing how to
> generate modern certificates.

Just to be clear, this is being seen in our docker-based test
environment using a virtual network and the docker resolvers, where
we're creating our own certificates so we can easily do both positive
and negative testing with things like good/bad hostnames, expired
certificates, incorrect chains, testing key rotation, etc. etc.

Our Java and Python clients work fine, but the C/C++ clients were
failing.

These certificates aren't being used "for real".

I'll look into enhancing our test environment to address this.  Cheers!


From paul at mad-scientist.net  Mon Jun 10 20:41:11 2019
From: paul at mad-scientist.net (Paul Smith)
Date: Mon, 10 Jun 2019 16:41:11 -0400
Subject: Question: why doesn't my wildcard matching work with OpenSSL?
In-Reply-To: <D64B0A31-6F3B-4030-88CD-A04DFC87B7AF@dukhovni.org>
References: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>
 <20190610182348.GI67454@straasha.imrryr.org>
 <1d34814f8e5853483df3600d784b97f693103ae0.camel@mad-scientist.net>
 <D64B0A31-6F3B-4030-88CD-A04DFC87B7AF@dukhovni.org>
Message-ID: <f8f9ac118fb9c56ec1a1e08a8c0e235936f6e512.camel@mad-scientist.net>

On Mon, 2019-06-10 at 15:14 -0400, Viktor Dukhovni wrote:
> As a safety measure, OpenSSL does not support "*.tld" wildcards.
> The non-wildcard portion of the domain name needs to have at
> least two labels.  It seems I've neglected to document this... :-(
> 
> You can have "*.domain.example", but not "*.domain".

I see, thanks, that's good info.  We will try to figure out how to
modify our Docker-based test configuration to use a multi-label domain
name for its private network.

I'm not sure how or if that will impact users, outside of our test
environment.


Is this something controlled by an option for X509_check_host() or is
it just hardcoded and can't be modified?  I didn't see any options in
the docs that seem to manage that, unless it's a side-effect.


From openssl-users at dukhovni.org  Mon Jun 10 22:00:39 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Jun 2019 18:00:39 -0400
Subject: Question: why doesn't my wildcard matching work with OpenSSL?
In-Reply-To: <f8f9ac118fb9c56ec1a1e08a8c0e235936f6e512.camel@mad-scientist.net>
References: <075532aecff5b19de51bed5cdd2583b98b43e8a0.camel@mad-scientist.net>
 <20190610182348.GI67454@straasha.imrryr.org>
 <1d34814f8e5853483df3600d784b97f693103ae0.camel@mad-scientist.net>
 <D64B0A31-6F3B-4030-88CD-A04DFC87B7AF@dukhovni.org>
 <f8f9ac118fb9c56ec1a1e08a8c0e235936f6e512.camel@mad-scientist.net>
Message-ID: <342FCCEE-A0BA-4FF7-91D1-977277EFBED9@dukhovni.org>

> On Jun 10, 2019, at 4:41 PM, Paul Smith <paul at mad-scientist.net> wrote:
> 
>> As a safety measure, OpenSSL does not support "*.tld" wildcards.
>> The non-wildcard portion of the domain name needs to have at
>> least two labels.  It seems I've neglected to document this... :-(
>> 
>> You can have "*.domain.example", but not "*.domain".
> 
> Is this something controlled by an option for X509_check_host() or is
> it just hardcoded and can't be modified?  I didn't see any options in
> the docs that seem to manage that, unless it's a side-effect.

This is not presently configurable.  I see some references to
similar policies in at least some of the major browsers, not
just OpenSSL, so it is probably best to avoid *.tld wildcards.

-- 
	Viktor.


From hareesh.sai at gmail.com  Tue Jun 11 10:50:15 2019
From: hareesh.sai at gmail.com (Hareesh D)
Date: Tue, 11 Jun 2019 16:20:15 +0530
Subject: TLSv12 Client Certificate Selection Behavior !!
Message-ID: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>

TLSv12 client is sending RSA certificate even when it dont have
digitalSignature bit in keyUsage extension. But RFC5246 sectiin-7.4.6 says
its MUST condition for client to send RSA certificate with digitalSignature
bit set in keyUsage extension.

1. Though server is rejecting such certificates, not sure why client sends
such certificates even when there is MUST condition for this point. Should
client send empty certificate list instead of sending wrong one? Client has
the provision of sensing empty certificate list when it don't have a
suitable certificate according to certificate request.

2. And also client is not checking the certificate_types requested in
certificate_message and also server not validating if the response is
according to the type requested. Consider server requesting only DSA
certificate. Client sending RSA certificate and server accepting it.

Is this behavior valid and according to RFC ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190611/e2fdd040/attachment.html>

From jb-openssl at wisemo.com  Tue Jun 11 14:19:07 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 11 Jun 2019 16:19:07 +0200
Subject: TLSv12 Client Certificate Selection Behavior !!
In-Reply-To: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>
References: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>
Message-ID: <b02fc97e-32cb-87f0-63cc-9dd1b7fa6c43@wisemo.com>

On 11/06/2019 12:50, Hareesh D wrote:
> TLSv12 client is sending RSA certificate even when it dont have 
> digitalSignature bit in keyUsage extension. But RFC5246 sectiin-7.4.6 
> says its MUST condition for client to send RSA certificate with 
> digitalSignature bit set in keyUsage extension.
>
> 1. Though server is rejecting such certificates, not sure why client 
> sends such certificates even when there is MUST condition for this 
> point. Should client send empty certificate list instead of sending 
> wrong one? Client has the provision of sensing empty certificate list 
> when it don't have a suitable certificate according to certificate 
> request.
>
> 2. And also client is not checking the certificate_types requested in 
> certificate_message and also server not validating if the response is 
> according to the type requested. Consider server requesting only DSA 
> certificate. Client sending RSA certificate and server accepting it.
>
> Is this behavior valid and according to RFC ?
There's an overarching OpenSSL policy that certificate checks are
done exclusively by the relying end (for client certs, that's the
server), except when certified end is trying to choose from
multiple certificates.

Thus with only one certificate available, the OpenSSL sends the
(untrusted, and in this case inappropriate) certificate, just in
case the server was somehow configured to make a special exception
for this particular case.

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 Michael.Wojcik at microfocus.com  Tue Jun 11 16:15:44 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 11 Jun 2019 16:15:44 +0000
Subject: TLSv12 Client Certificate Selection Behavior !!
In-Reply-To: <b02fc97e-32cb-87f0-63cc-9dd1b7fa6c43@wisemo.com>
References: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>
 <b02fc97e-32cb-87f0-63cc-9dd1b7fa6c43@wisemo.com>
Message-ID: <BYAPR18MB2918495D1DAEDD59A7827333F9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Jakob Bohm via openssl-users
> Sent: Tuesday, June 11, 2019 08:19
>
> On 11/06/2019 12:50, Hareesh D wrote:
> >
> > Is this behavior valid and according to RFC ?
>
> There's an overarching OpenSSL policy that certificate checks are
> done exclusively by the relying end (for client certs, that's the
> server), except when certified end is trying to choose from
> multiple certificates.
>
> Thus with only one certificate available, the OpenSSL sends the
> (untrusted, and in this case inappropriate) certificate, just in
> case the server was somehow configured to make a special exception
> for this particular case.

Yes. I for one would argue this existing behavior (i.e. not enforcing every mandate of every applicable standard, at every step of the way) is the Right Thing to do. While it's good that OpenSSL is increasingly providing functionality to make it easier for applications to follow the RFCs and other standards, it's also very important that applications have the flexibility to violate some aspects of those standards. That is critical for interoperability with non-standard peers, as Jakob wrote, and for testing, among other things.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From openssl-users at dukhovni.org  Tue Jun 11 16:39:27 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 11 Jun 2019 12:39:27 -0400
Subject: TLSv12 Client Certificate Selection Behavior !!
In-Reply-To: <BYAPR18MB2918495D1DAEDD59A7827333F9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>
 <b02fc97e-32cb-87f0-63cc-9dd1b7fa6c43@wisemo.com>
 <BYAPR18MB2918495D1DAEDD59A7827333F9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <1FD4CEA2-C0BD-4A54-9238-C3204D2228B0@dukhovni.org>

> On Jun 11, 2019, at 12:15 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
>> There's an overarching OpenSSL policy that certificate checks are
>> done exclusively by the relying end (for client certs, that's the
>> server), except when certified end is trying to choose from
>> multiple certificates.
>> 
>> Thus with only one certificate available, the OpenSSL sends the
>> (untrusted, and in this case inappropriate) certificate, just in
>> case the server was somehow configured to make a special exception
>> for this particular case.
> 
> Yes. I for one would argue this existing behavior (i.e. not enforcing every mandate of every applicable standard, at every step of the way) is the Right Thing to do. While it's good that OpenSSL is increasingly providing functionality to make it easier for applications to follow the RFCs and other standards, it's also very important that applications have the flexibility to violate some aspects of those standards. That is critical for interoperability with non-standard peers, as Jakob wrote, and for testing, among other things.

That said, the intention isn't to ignore all the requirements, just
some of those that are not always a good idea to enforce, and perhaps
should never have been mandated in the first place.  Therefore, while
we leave enforcing the certificate signature algorithms to the peer,
enforcing keyUsage in client certificate selection is less obviously
counterproductive, and in fact can (as reported) avoid interop issues.

The OP did not specify which version of OpenSSL did not perform the
expected check.  I'd be open to adding such a check in master and
perhaps even 1.1.1 (as a bug fix).  A client certificate that cannot
do digital signatures is not much use.  On the other hand, applications
should not configure such certificates as client certificates, there
is not context in which they are valid.  So another potential response
is: "if it hurts, don't do that!"

-- 
	Viktor.


From michael.l.lewis at rbccm.com  Tue Jun 11 16:55:48 2019
From: michael.l.lewis at rbccm.com (Lewis, Michael L)
Date: Tue, 11 Jun 2019 16:55:48 +0000
Subject: building openssl for windows - missing do_win64a from ms directory.
Message-ID: <27a5b43f1c9f46289fa5dd0a75085a42@SXLOE205.fg.rbc.com>

Hi,

I'm trying to build OpenSSL for windows (openssl-1.1.1c), I do the following steps:


1.       cd into open ssl directory.

2.       Run: perl Configure VC-WIN64A, this appears to work fine ...



C:\develop\ignite\openssl-1.1.1c>perl Configure VC-WIN64A

Configuring OpenSSL version 1.1.1c (0x1010103fL) for VC-WIN64A

Using os-specific seed configuration

Creating configdata.pm

Creating makefile

The issue I have is that I don't see 'do_win64a' within the 'ms' directory (I'm following build instructions here: http://eran.geek.co.il/wp/archives/3897
and https://wiki.openssl.org/index.php/Compilation_and_Installation#W64)

Anyone have any ideas on what I'm doing wrong? (The output from perl configdata.pm -dump is shown below).

Thanks,
Mike Lewis


C:\develop\ignite\openssl-1.1.1c>perl configdata.pm -dump

Command line (with current working directory = .):

    C:\Strawberry\perl\bin\perl.exe Configure VC-WIN64A

Perl information:

    C:\Strawberry\perl\bin\perl.exe
    5.12.3 for MSWin32-x86-multi-thread

Enabled features:

    aria
    asm
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    buildtest-c\+\+
    camellia
    capieng
    cast
    chacha
    cmac
    cms
    comp
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    gost
    hw(-.+)?
    idea
    makedepend
    md4
    mdc2
    multiblock
    nextprotoneg
    pinshared
    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(0x253c2ac)",
    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_APPL
    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 => ".dll",
    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 => ".dll",
    shared_extension_simple => ".dll",
    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:\Strawberry\perl\bin\perl.exe
    RANLIB          = ranlib
    RC              = rc
    RCFLAGS         =

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

C:\develop\ignite\openssl-1.1.1c>

_______________________________________________________________________

This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.

Unauthorised use or disclosure is prohibited. If you receive this e-mail in error, please advise immediately and delete the original message without copying, using, or telling anyone about its contents.

This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.

This message does not create or change any contract. Royal Bank of Canada and its subsidiaries accept no responsibility for damage caused by any viruses contained in this email or its attachments. Emails may be monitored.

RBC Capital Markets is a business name used by branches and subsidiaries of Royal Bank of Canada, including Royal Bank of Canada, London branch and RBC Europe Limited. In accordance with English law requirements, details regarding RBC Europe Limited and Royal Bank of Canada, London Branch are set out below:

RBC EUROPE LIMITED
Registered in England and Wales 995939
Registered Address: Riverbank House, 2 Swan Lane, London, EC4R 3BF.
Authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority.

ROYAL BANK OF CANADA, LONDON BRANCH
Incorporated in Canada in 1869 with Limited Liability.
Registered in England and Wales BR000548
Registered Address: 1 Place Ville Marie, Canada.
Branch location: Riverbank House, 2 Swan Lane, London, EC4R 3BF.
Authorised and regulated by the Office of the Superintendent of Financial Institutions of Canada. Authorised by the Prudential Regulation Authority. Subject to regulation by the Financial Conduct Authority and limited regulation by the Prudential Regulation Authority. Details of our regulation by the Prudential Regulation Authority are available from us on request.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190611/a9516ad7/attachment-0001.html>

From rsalz at akamai.com  Tue Jun 11 17:10:20 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 11 Jun 2019 17:10:20 +0000
Subject: building openssl for windows - missing do_win64a from ms
 directory.
In-Reply-To: <27a5b43f1c9f46289fa5dd0a75085a42@SXLOE205.fg.rbc.com>
References: <27a5b43f1c9f46289fa5dd0a75085a42@SXLOE205.fg.rbc.com>
Message-ID: <7D30BE30-0F6B-4234-BD21-050E5D84F19E@akamai.com>

  *   The issue I have is that I don?t see ?do_win64a? within the ?ms? directory (I?m following build instructions here: http://eran.geek.co.il/wp/archives/3897<https://urldefense.proofpoint.com/v2/url?u=http-3A__eran.geek.co.il_wp_archives_3897&d=DwMFAg&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=hEkMnP1wPdf9361j4VkyM_FTx6-OxvUjDBs0yFmmLWw&s=49YOtTqdLOG0wGL7Syv9PuchjjUZi0IpR1IWoA5iLRE&e=> and https://wiki.openssl.org/index.php/Compilation_and_Installation#W64 )

Those files are outdated; look at the NOTES.WIN file.

(PS that email disclaimer is obnoxious, it?d be great if you could get it disabled.)

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

From Michael.Wojcik at microfocus.com  Tue Jun 11 17:02:11 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 11 Jun 2019 17:02:11 +0000
Subject: TLSv12 Client Certificate Selection Behavior !!
In-Reply-To: <1FD4CEA2-C0BD-4A54-9238-C3204D2228B0@dukhovni.org>
References: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>
 <b02fc97e-32cb-87f0-63cc-9dd1b7fa6c43@wisemo.com>
 <BYAPR18MB2918495D1DAEDD59A7827333F9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
 <1FD4CEA2-C0BD-4A54-9238-C3204D2228B0@dukhovni.org>
Message-ID: <BYAPR18MB291809DBCD6FB6441453D90BF9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Viktor Dukhovni
> Sent: Tuesday, June 11, 2019 10:39

> A client certificate that cannot do digital signatures is not much use.

There may be existing applications which use TLS entirely within an organization, where the server does not check KU, and the peers use certificates generated by an internal CA that doesn't set those extensions properly. In that use case, enforcing the KU requirement would break backward compatibility.

Maybe that's not worth worrying about; maybe the advantages of enforcing KU on the client certificate at the client end (better diagnostics for the client application, enforce the standard even if the server doesn't) outweigh it. But I don't think it's entirely accurate to say a client certificate with incorrect/missing KU (or EKU, or other extensions) is necessarily useless.

To be honest I don't have a strong feeling about this particular suggestion. If OpenSSL started requiring proper KU on client certificates, and that forced some people to fix their internal CA configurations, that's arguably a good thing; such people may well be using too-small keys and outdated algorithms too. Disruption can definitely be good in this area. Just wanted to point out that it might be possible to rely on the existing behavior.

And, of course, there are no doubt still people out there running internal CAs that generate X.509v1 certs, which won't have any extensions at all. No KU, no EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client certificate would be bypassed if the client cert is v1 - but then using a v1 certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably should not enforce.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From openssl-users at dukhovni.org  Tue Jun 11 17:21:25 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 11 Jun 2019 13:21:25 -0400
Subject: TLSv12 Client Certificate Selection Behavior !!
In-Reply-To: <BYAPR18MB291809DBCD6FB6441453D90BF9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
References: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>
 <b02fc97e-32cb-87f0-63cc-9dd1b7fa6c43@wisemo.com>
 <BYAPR18MB2918495D1DAEDD59A7827333F9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
 <1FD4CEA2-C0BD-4A54-9238-C3204D2228B0@dukhovni.org>
 <BYAPR18MB291809DBCD6FB6441453D90BF9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
Message-ID: <32CC4930-6B00-4434-8943-F33A26E318A5@dukhovni.org>

> On Jun 11, 2019, at 1:02 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
> And, of course, there are no doubt still people out there running internal CAs that generate X.509v1 certs, which won't have any extensions at all. No KU, no EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client certificate would be bypassed if the client cert is v1 - but then using a v1 certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably should not enforce.

Yes, v1 certs would get a free ride.  The reason to enforce KU
in client certs would be that client certs are not infrequently
(though not always) optional, and it can be better to not send
any client cert, than to send one the server will reject.

RSA client certs without digital signature in KU are increasingly
not interoperable as more server implementations are checking the
keyUsage these days.  So at some point it makes sense to consider
not offering such (client) certs to the peer server.

But at the end of the day, the user should not have configured
such a client cert in the first place, so it may also make sense
to just leave the responsibility with the user.

-- 
	Viktor.


From levitte at openssl.org  Tue Jun 11 19:53:09 2019
From: levitte at openssl.org (Richard Levitte)
Date: Tue, 11 Jun 2019 21:53:09 +0200
Subject: building openssl for windows - missing do_win64a from ms
 directory.
In-Reply-To: <27a5b43f1c9f46289fa5dd0a75085a42@SXLOE205.fg.rbc.com>
References: <27a5b43f1c9f46289fa5dd0a75085a42@SXLOE205.fg.rbc.com>
Message-ID: <B5D6AE29-1FDE-4CA3-844D-50E7B379181A@openssl.org>

I'd suggest reading the files called 'README' and 'INSTALL' as a start.

Cheers
Richard


"Lewis, Michael L" <michael.l.lewis at rbccm.com> skrev: (11 juni 2019 18:55:48 CEST)
>Hi,
>
>I'm trying to build OpenSSL for windows (openssl-1.1.1c), I do the
>following steps:
>
>
>1.       cd into open ssl directory.
>
>2.       Run: perl Configure VC-WIN64A, this appears to work fine ...
>
>
>
>C:\develop\ignite\openssl-1.1.1c>perl Configure VC-WIN64A
>
>Configuring OpenSSL version 1.1.1c (0x1010103fL) for VC-WIN64A
>
>Using os-specific seed configuration
>
>Creating configdata.pm
>
>Creating makefile
>
>The issue I have is that I don't see 'do_win64a' within the 'ms'
>directory (I'm following build instructions here:
>http://eran.geek.co.il/wp/archives/3897
>and
>https://wiki.openssl.org/index.php/Compilation_and_Installation#W64)
>
>Anyone have any ideas on what I'm doing wrong? (The output from perl
>configdata.pm -dump is shown below).
>
>Thanks,
>Mike Lewis
>
>
>C:\develop\ignite\openssl-1.1.1c>perl configdata.pm -dump
>
>Command line (with current working directory = .):
>
>    C:\Strawberry\perl\bin\perl.exe Configure VC-WIN64A
>
>Perl information:
>
>    C:\Strawberry\perl\bin\perl.exe
>    5.12.3 for MSWin32-x86-multi-thread
>
>Enabled features:
>
>    aria
>    asm
>    async
>    autoalginit
>    autoerrinit
>    autoload-config
>    bf
>    blake2
>    buildtest-c\+\+
>    camellia
>    capieng
>    cast
>    chacha
>    cmac
>    cms
>    comp
>    ct
>    deprecated
>    des
>    dgram
>    dh
>    dsa
>    dtls
>    dynamic-engine
>    ec
>    ec2m
>    ecdh
>    ecdsa
>    engine
>    err
>    filenames
>    gost
>    hw(-.+)?
>    idea
>    makedepend
>    md4
>    mdc2
>    multiblock
>    nextprotoneg
>    pinshared
>    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(0x253c2ac)",
>    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_APPL
>    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 => ".dll",
>    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 => ".dll",
>    shared_extension_simple => ".dll",
>    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:\Strawberry\perl\bin\perl.exe
>    RANLIB          = ranlib
>    RC              = rc
>    RCFLAGS         =
>
>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
>
>C:\develop\ignite\openssl-1.1.1c>
>
>_______________________________________________________________________
>
>This email is intended only for the use of the individual(s) to whom it
>is addressed and may be privileged and confidential.
>
>Unauthorised use or disclosure is prohibited. If you receive this
>e-mail in error, please advise immediately and delete the original
>message without copying, using, or telling anyone about its contents.
>
>This message may have been altered without your or our knowledge and
>the sender does not accept any liability for any errors or omissions in
>the message.
>
>This message does not create or change any contract. Royal Bank of
>Canada and its subsidiaries accept no responsibility for damage caused
>by any viruses contained in this email or its attachments. Emails may
>be monitored.
>
>RBC Capital Markets is a business name used by branches and
>subsidiaries of Royal Bank of Canada, including Royal Bank of Canada,
>London branch and RBC Europe Limited. In accordance with English law
>requirements, details regarding RBC Europe Limited and Royal Bank of
>Canada, London Branch are set out below:
>
>RBC EUROPE LIMITED
>Registered in England and Wales 995939
>Registered Address: Riverbank House, 2 Swan Lane, London, EC4R 3BF.
>Authorised by the Prudential Regulation Authority and regulated by the
>Financial Conduct Authority and the Prudential Regulation Authority.
>
>ROYAL BANK OF CANADA, LONDON BRANCH
>Incorporated in Canada in 1869 with Limited Liability.
>Registered in England and Wales BR000548
>Registered Address: 1 Place Ville Marie, Canada.
>Branch location: Riverbank House, 2 Swan Lane, London, EC4R 3BF.
>Authorised and regulated by the Office of the Superintendent of
>Financial Institutions of Canada. Authorised by the Prudential
>Regulation Authority. Subject to regulation by the Financial Conduct
>Authority and limited regulation by the Prudential Regulation
>Authority. Details of our regulation by the Prudential Regulation
>Authority are available from us on request.

-- 
Richard by mobile

From mcr at sandelman.ca  Tue Jun 11 20:58:46 2019
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 11 Jun 2019 16:58:46 -0400
Subject: TLSv12 Client Certificate Selection Behavior !!
In-Reply-To: <32CC4930-6B00-4434-8943-F33A26E318A5@dukhovni.org>
References: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>
 <b02fc97e-32cb-87f0-63cc-9dd1b7fa6c43@wisemo.com>
 <BYAPR18MB2918495D1DAEDD59A7827333F9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
 <1FD4CEA2-C0BD-4A54-9238-C3204D2228B0@dukhovni.org>
 <BYAPR18MB291809DBCD6FB6441453D90BF9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
 <32CC4930-6B00-4434-8943-F33A26E318A5@dukhovni.org>
Message-ID: <18756.1560286726@localhost>


Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
    > Yes, v1 certs would get a free ride.  The reason to enforce KU
    > in client certs would be that client certs are not infrequently
    > (though not always) optional, and it can be better to not send
    > any client cert, than to send one the server will reject.

802.1AR seems to discourage KU in IDevID because at most KU bits make
the certificate less useable, and IDevID certificates are expected to live
for decades.

    > RSA client certs without digital signature in KU are increasingly
    > not interoperable as more server implementations are checking the
    > keyUsage these days.  So at some point it makes sense to consider
    > not offering such (client) certs to the peer server.

I would like knobs for this.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- 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/20190611/5b5597fd/attachment.sig>

From jb-openssl at wisemo.com  Tue Jun 11 23:41:47 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 12 Jun 2019 01:41:47 +0200
Subject: TLSv12 Client Certificate Selection Behavior !!
In-Reply-To: <32CC4930-6B00-4434-8943-F33A26E318A5@dukhovni.org>
References: <CAD19CyS8yMLzbAtsv0eMeFm7=Fo+uDeaBg9+FdmaT44QsLccgg@mail.gmail.com>
 <b02fc97e-32cb-87f0-63cc-9dd1b7fa6c43@wisemo.com>
 <BYAPR18MB2918495D1DAEDD59A7827333F9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
 <1FD4CEA2-C0BD-4A54-9238-C3204D2228B0@dukhovni.org>
 <BYAPR18MB291809DBCD6FB6441453D90BF9ED0@BYAPR18MB2918.namprd18.prod.outlook.com>
 <32CC4930-6B00-4434-8943-F33A26E318A5@dukhovni.org>
Message-ID: <552e97d6-2bac-7d5f-8fa6-0576d019148e@wisemo.com>

On 11/06/2019 19:21, Viktor Dukhovni wrote:
>> On Jun 11, 2019, at 1:02 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
>>
>> And, of course, there are no doubt still people out there running internal CAs that generate X.509v1 certs, which won't have any extensions at all. No KU, no EKU, no SAN, no SKID/AKID ... Presumably a check for proper KU on the client certificate would be bypassed if the client cert is v1 - but then using a v1 certificate is another violation of RFC 5246 (7.4.2) that OpenSSL probably should not enforce.
> Yes, v1 certs would get a free ride.  The reason to enforce KU
> in client certs would be that client certs are not infrequently
> (though not always) optional, and it can be better to not send
> any client cert, than to send one the server will reject.
>
> RSA client certs without digital signature in KU are increasingly
> not interoperable as more server implementations are checking the
> keyUsage these days.  So at some point it makes sense to consider
> not offering such (client) certs to the peer server.
>
> But at the end of the day, the user should not have configured
> such a client cert in the first place, so it may also make sense
> to just leave the responsibility with the user.
>
Note that the most common variant of encrypt-only RSA client certs
is probably encrypt-only e-mail client certs with other client uses
tacked on.

Such certificates are typically paired with a "same logical
identity" sign-only e-mail/client certificate, with the key
difference being that the encrypt-only-private key is kept around
for a lot longer in order to decrypt stored e-mails that are
(wisely) stored only in their original encrypted form.

In that /specific/ case, attempting to use the encrypt-only cert
as a TLS client cert is typically some kind of logic certificate
selection error, such as a Web client blindly using the locally
stored long-term decryption key instead of the signing key stored
on a removable, but also loosable, smart card, however there may
be company-internal reasons to do so deliberately in order for
background activities to operate when the user (and smartcard) is
"away from terminal".

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 john.sha.jiang at gmail.com  Wed Jun 12 07:45:12 2019
From: john.sha.jiang at gmail.com (John Jiang)
Date: Wed, 12 Jun 2019 15:45:12 +0800
Subject: Is X25519/X448 supported for TLSv1.2?
Message-ID: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>

Hi,
Using OpenSSL 1.1.1.
Just want to confirm that if OpenSSL supports curves X25519 and X448 for
TLSv1.2.

Tried below commands,
openssl s_server -trace -state -cert server.cer -key server.key -accept port
openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519
-connect localhost:port

the server side raised the below error,
140735913575296:error:1417A0C1:SSL
routines:tls_post_process_client_hello:no shared
cipher:ssl/statem/statem_srvr.c:2253:

If using -groups P-256, the handshaking was fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190612/fcaef7bb/attachment.html>

From openssl-users at dukhovni.org  Wed Jun 12 08:33:41 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 12 Jun 2019 04:33:41 -0400
Subject: Is X25519/X448 supported for TLSv1.2?
In-Reply-To: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>
References: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>
Message-ID: <20190612083341.GB33899@straasha.imrryr.org>

On Wed, Jun 12, 2019 at 03:45:12PM +0800, John Jiang wrote:

> Using OpenSSL 1.1.1.
> Just want to confirm that if OpenSSL supports curves X25519 and X448 for
> TLSv1.2.

Yes, it does.

> Tried below commands,
> openssl s_server -trace -state -cert server.cer -key server.key -accept port
> openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519 -connect localhost:port

With same commands, using OpenSSL 1.1.1c, I get:

    CONNECTION ESTABLISHED
    Protocol version: TLSv1.2
    Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
    Peer certificate:
    Hash used: SHA256
    Signature type: RSA-PSS
    Supported Elliptic Curve Point Formats: uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
    Server Temp Key: X25519, 253 bits

Perhaps your s_client is not the one from 1.1.1 or it is dynamically
linked against 1.1.0 libraries...

-- 
	Viktor.

From intera_91 at yahoo.co.uk  Wed Jun 12 09:27:33 2019
From: intera_91 at yahoo.co.uk (Patrick Regnouf)
Date: Wed, 12 Jun 2019 09:27:33 +0000 (UTC)
Subject: New to the list and one question ;-)
References: <1778690509.238067.1560331653395.ref@mail.yahoo.com>
Message-ID: <1778690509.238067.1560331653395@mail.yahoo.com>

As requested here are two captures attached: one successfully handshakes with the server (chrome)? and one fails the handshake (firefox).
I would be very grateful if anyone could shed some light on this.

the openssl version which is linked to my server/relay program is 1.0.2s

Thanks

/Patrick




On Mon, 2019-06-10 at 13:41 -0400, Viktor Dukhovni wrote:On Mon, Jun 10, 2019 at 03:21:16PM +0000, Patrick Regnouf via openssl-users wrote:
> 
> > All is well and good when the program works on the linux PC and the
> > handshake is succesful using the 0xc02f cipher. and that is linked to
> > version 3.0.0 of openssl.? on the embedded version, (linked with version
> > 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas
> > chrome and safari do successfully handshake chrome client hello contains
> > 12 ciphers and the server hello seems to choose 0xc02f cipher firefox
> > client hello contains only 10 ciphers (including the above mentioned 0xc02f
> > cipher) and fails.? any suggestion as to what could causes that failure
> > would be appreciated.
> 
> In addition to the cipher algorithm, the two parties must also agree
> on the signature algorithms, supported EC groups, ...
> 
> You've not provided much detail about the configuration of the
> embedded (1.0.2s) server.? The cipher that works with the other
> browsers is:
> 
>???? 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH???? Au=RSA? Enc=AESGCM(128) Mac=AEAD
> 
> this requires a shared ECDHE curve, are you using "auto", or an
> explicit curve?? What are the signature algorithms on your certificate
> chain?
> 
> It would also be useful to post PCAP files of a working handshake
> with Chrome, and a failing handshake with Firefox.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190612/be09c994/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chrome_success.pcap
Type: application/vnd.tcpdump.pcap
Size: 4328 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190612/be09c994/attachment-0002.pcap>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: firefox_fail.pcap
Type: application/vnd.tcpdump.pcap
Size: 808 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190612/be09c994/attachment-0003.pcap>

From john.sha.jiang at gmail.com  Wed Jun 12 09:31:30 2019
From: john.sha.jiang at gmail.com (John Jiang)
Date: Wed, 12 Jun 2019 17:31:30 +0800
Subject: Is X25519/X448 supported for TLSv1.2?
In-Reply-To: <20190612083341.GB33899@straasha.imrryr.org>
References: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>
 <20190612083341.GB33899@straasha.imrryr.org>
Message-ID: <CAJbO6CQB_vAkX_GRjL2CHFOx3aWTCNewxJ8UFStHwwazdBU7WQ@mail.gmail.com>

On Wed, Jun 12, 2019 at 4:34 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Wed, Jun 12, 2019 at 03:45:12PM +0800, John Jiang wrote:
>
> > Using OpenSSL 1.1.1.
> > Just want to confirm that if OpenSSL supports curves X25519 and X448 for
> > TLSv1.2.
>
> Yes, it does.
>
> > Tried below commands,
> > openssl s_server -trace -state -cert server.cer -key server.key -accept
> port
> > openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519
> -connect localhost:port
>
> With same commands, using OpenSSL 1.1.1c, I get:
>
>     CONNECTION ESTABLISHED
>     Protocol version: TLSv1.2
>     Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
>     Peer certificate:
>     Hash used: SHA256
>     Signature type: RSA-PSS
>     Supported Elliptic Curve Point Formats:
> uncompressed:ansiX962_compressed_prime:ansiX962_compressed_char2
>     Server Temp Key: X25519, 253 bits
>
> Perhaps your s_client is not the one from 1.1.1 or it is dynamically
> linked against 1.1.0 libraries...
>
My s_client can support TLSv1.3, so it should not be from any pre-1.1.1
version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190612/57dd9412/attachment.html>

From matt at openssl.org  Wed Jun 12 10:04:45 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 12 Jun 2019 11:04:45 +0100
Subject: New to the list and one question ;-)
In-Reply-To: <1778690509.238067.1560331653395@mail.yahoo.com>
References: <1778690509.238067.1560331653395.ref@mail.yahoo.com>
 <1778690509.238067.1560331653395@mail.yahoo.com>
Message-ID: <be673dab-44ce-6cba-af73-ebfc45e38b26@openssl.org>



On 12/06/2019 10:27, Patrick Regnouf via openssl-users wrote:
> As requested here are two captures attached: one successfully handshakes with
> the server (chrome)? and one fails the handshake (firefox).
> I would be very grateful if anyone could shed some light on this.
> 
> the openssl version which is linked to my server/relay program is 1.0.2s

Contrary to what you said in your original post the chrome session is NOT
selecting 0xc02f. Instead it is selecting 0x002f which is
TLS_RSA_WITH_AES_128_CBC_SHA (aka AES128-SHA in the OpenSSL naming scheme).

This cipher is not being offered by firefox but is by chrome. It is striking to
note that although chrome is offering a whole list of ciphersuites offering
forward secrecy (i.e. all those including ECDHE/DHE), the server is instead
selecting a very old ciphersuite that does not support forward secrecy.

In comparison firefox does not offer any ciphersuites that do not support
forward secrecy and the connection fails.

Have you called SSL_CTX_set_tmp_dh() or SSL_CTX_set_ecdh_auto() on the server?
I'd suggest trying those and see if it helps.

Matt


> 
> Thanks
> 
> /Patrick
> 
> 
> 
> 
> On Mon, 2019-06-10 at 13:41 -0400, Viktor Dukhovni wrote:
> On Mon, Jun 10, 2019 at 03:21:16PM +0000, Patrick Regnouf via openssl-users wrote:
>>
>> > All is well and good when the program works on the linux PC and the
>> > handshake is succesful using the 0xc02f cipher. and that is linked to
>> > version 3.0.0 of openssl.? on the embedded version, (linked with version
>> > 1.0.2s) firefox fails the handshake with ssl_no_shared_cipher whereas
>> > chrome and safari do successfully handshake chrome client hello contains
>> > 12 ciphers and the server hello seems to choose 0xc02f cipher firefox
>> > client hello contains only 10 ciphers (including the above mentioned 0xc02f
>> > cipher) and fails.? any suggestion as to what could causes that failure
>> > would be appreciated.
>>
>> In addition to the cipher algorithm, the two parties must also agree
>> on the signature algorithms, supported EC groups, ...
>>
>> You've not provided much detail about the configuration of the
>> embedded (1.0.2s) server.? The cipher that works with the other
>> browsers is:
>>
>>???? 0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH???? Au=RSA?
> Enc=AESGCM(128) Mac=AEAD
>>
>> this requires a shared ECDHE curve, are you using "auto", or an
>> explicit curve?? What are the signature algorithms on your certificate
>> chain?
>>
>> It would also be useful to post PCAP files of a working handshake
>> with Chrome, and a failing handshake with Firefox.
> 

From yitiger at hotmail.com  Wed Jun 12 15:31:37 2019
From: yitiger at hotmail.com (Yi tiger)
Date: Wed, 12 Jun 2019 15:31:37 +0000
Subject: RSA public and private key encrypt with fips issue
Message-ID: <HK0PR06MB2514F792B8F0CAF155FA7724B2EC0@HK0PR06MB2514.apcprd06.prod.outlook.com>

Hi guys,

I have download openssl 1.0.2s and fips 2.0.16 and build successfully on windows and then I try to write a simple app encrypted with public key and decrypt with private key. But It failed decrypted with private key when fips mode is turned on, decrypt will be success if fips is turned off.
I got below error

[cid:image001.png at 01D52176.09181B50]

The first error occurs if I pass RSA_sizeof(rsa) as  RSA_private_decrypt ?s first parameter, the second error if I pass the encrypted buffer?s length as RSA_private_decrypt?s first parameter.
I also noticed return value of RSA_size is different when fips mode is turned on.
Its size is 256 if fips is turned off, but become 128 if fips turned on.
RSA_public_encrypt return value is equal to RSA_size when fips is turned off, but its return value will great than RSA_size when truned on, maybe this cause decrypt or something its my code problem?

Below is my source code,


#include "openssl\crypto.h"
#include "openssl\rsa.h"
#include "openssl\err.h"
#include "openssl/pem.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char* privatekey;
int privlen;
char* publickey;
int publen;

void generate()
{
       int mode = FIPS_mode();
       if (mode == 0)
       {
              int ret = FIPS_mode_set(1);
              if (ret != 1)
              {
                     printf("error %s", ERR_get_error());
              }
       }

       RSA *rsa = RSA_generate_key(2048, 3, NULL, NULL);

       BIO *bio = BIO_new(BIO_s_mem());
       PEM_write_bio_RSAPrivateKey(bio, rsa, NULL, NULL, 0, NULL, NULL);
       int rszsize = RSA_size(rsa);
       privlen = BIO_pending(bio);
       privatekey = (char*)malloc(privlen + 1);
       BIO_read(bio, privatekey, privlen);

       PEM_write_bio_RSAPublicKey(bio, rsa);
       publen = BIO_pending(bio);
       publickey = (char*)malloc(publen + 1);
       BIO_read(bio, publickey, publen);

       BIO_free_all(bio);
       RSA_free(rsa);
}

void Encrypt(const char* password)
{
       BIO *bio = BIO_new(BIO_s_mem());
       RSA *rsa = NULL;
       BIO_write(bio, publickey, publen);
       RSA* temp = PEM_read_bio_RSAPublicKey(bio, &rsa, NULL, NULL);
       char encrypted[500];
       int len = 0;
       if (temp != NULL)
       {
              int rsasize = RSA_size(rsa);
              len = RSA_public_encrypt((int)strlen(password), (unsigned char*)password, (unsigned char*)encrypted, rsa, RSA_PKCS1_OAEP_PADDING);
              if (len == -1)
              {
                     int e = ERR_get_error();
                     char * err = ERR_error_string(ERR_get_error(), encrypted);
                     printf("RSA_public_encrypt failed.\n");
              }
              else
              {
                     printf("%s", encrypted);
              }
       }

       BIO *newbio = BIO_new_mem_buf(privatekey, privlen);
       RSA *privRsa = NULL;
       PEM_read_bio_RSAPrivateKey(newbio, &privRsa, NULL, NULL);

       char p[4096] = { 0 };
       int rsasize = RSA_size(privRsa);
       if (privRsa != NULL)
       {
              int ret = RSA_private_decrypt(rsasize, (unsigned char*)encrypted, (unsigned char*)p, privRsa, RSA_PKCS1_OAEP_PADDING);
              if (ret == -1)
              {
                     int e = ERR_get_error();
                     char * err = ERR_error_string(ERR_get_error(), p);
                     printf("error");
              }
       }
}

Thanks,
Tiger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190612/c309c5c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 152DDD620E3544FC80BD3B3AE89C45CB.png
Type: image/png
Size: 4386 bytes
Desc: 152DDD620E3544FC80BD3B3AE89C45CB.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190612/c309c5c2/attachment-0001.png>

From openssl-users at dukhovni.org  Wed Jun 12 19:00:04 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 12 Jun 2019 15:00:04 -0400
Subject: Is X25519/X448 supported for TLSv1.2?
In-Reply-To: <CAJbO6CQB_vAkX_GRjL2CHFOx3aWTCNewxJ8UFStHwwazdBU7WQ@mail.gmail.com>
References: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>
 <20190612083341.GB33899@straasha.imrryr.org>
 <CAJbO6CQB_vAkX_GRjL2CHFOx3aWTCNewxJ8UFStHwwazdBU7WQ@mail.gmail.com>
Message-ID: <20190612190004.GE33899@straasha.imrryr.org>

On Wed, Jun 12, 2019 at 05:31:30PM +0800, John Jiang wrote:

> > > Tried below commands,
> > > openssl s_server -trace -state -cert server.cer -key server.key -accept port
> > > openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519 -connect localhost:port
> >
> > With same commands, using OpenSSL 1.1.1c, I get:
> >
> >     CONNECTION ESTABLISHED
> >     Protocol version: TLSv1.2
> >     Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
> >     Peer certificate:
> >     Hash used: SHA256
> >     Signature type: RSA-PSS
> >     Supported Elliptic Curve Point Formats: ...
> >     Server Temp Key: X25519, 253 bits
> >
> > Perhaps your s_client is not the one from 1.1.1 or it is dynamically
> > linked against 1.1.0 libraries...
> >
> My s_client can support TLSv1.3, so it should not be from any pre-1.1.1
> version.

You say that, but the evidence suggests otherwise.  In each of
whatever shells you're using to start the client and server,
it would be prudent to run:

    $ openssl version -v

Here's an example with the command and library at the same version:

    $ /usr/local/bin/openssl version -v
    OpenSSL 1.1.1c  28 May 2019

And here's another where they differ in the patchlevel:

    $ LD_PRELOAD=/lib/libcrypto.so.111:/usr/lib/libssl.so.111 /usr/local/bin/openssl version -v
    OpenSSL 1.1.1c  28 May 2019 (Library: OpenSSL 1.1.1a-freebsd  20 Nov 2018)

Without forcing anything with LD_PRELOAD, ... are your client and
server in fact 1.1.1 in both the executable and the library?

-- 
	Viktor.

From john.sha.jiang at gmail.com  Thu Jun 13 02:49:14 2019
From: john.sha.jiang at gmail.com (John Jiang)
Date: Thu, 13 Jun 2019 10:49:14 +0800
Subject: Is X25519/X448 supported for TLSv1.2?
In-Reply-To: <20190612190004.GE33899@straasha.imrryr.org>
References: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>
 <20190612083341.GB33899@straasha.imrryr.org>
 <CAJbO6CQB_vAkX_GRjL2CHFOx3aWTCNewxJ8UFStHwwazdBU7WQ@mail.gmail.com>
 <20190612190004.GE33899@straasha.imrryr.org>
Message-ID: <CAJbO6CQRVYpEYbGJxjSQvx68RbV7Kc40oST2GtQFs8ahyfzR4A@mail.gmail.com>

I got the point: the server certificate is ECDSA with curve secp256r1.
It works with RSA certificate and curves
sepc256r1/sepc384r1/sepc521r1/x25519/x448.

On Thu, Jun 13, 2019 at 3:00 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Wed, Jun 12, 2019 at 05:31:30PM +0800, John Jiang wrote:
>
> > > > Tried below commands,
> > > > openssl s_server -trace -state -cert server.cer -key server.key
> -accept port
> > > > openssl s_client -trace -state -CAfile ca.cer -tls1_2 -groups X25519
> -connect localhost:port
> > >
> > > With same commands, using OpenSSL 1.1.1c, I get:
> > >
> > >     CONNECTION ESTABLISHED
> > >     Protocol version: TLSv1.2
> > >     Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
> > >     Peer certificate:
> > >     Hash used: SHA256
> > >     Signature type: RSA-PSS
> > >     Supported Elliptic Curve Point Formats: ...
> > >     Server Temp Key: X25519, 253 bits
> > >
> > > Perhaps your s_client is not the one from 1.1.1 or it is dynamically
> > > linked against 1.1.0 libraries...
> > >
> > My s_client can support TLSv1.3, so it should not be from any pre-1.1.1
> > version.
>
> You say that, but the evidence suggests otherwise.  In each of
> whatever shells you're using to start the client and server,
> it would be prudent to run:
>
>     $ openssl version -v
>
> Here's an example with the command and library at the same version:
>
>     $ /usr/local/bin/openssl version -v
>     OpenSSL 1.1.1c  28 May 2019
>
> And here's another where they differ in the patchlevel:
>
>     $ LD_PRELOAD=/lib/libcrypto.so.111:/usr/lib/libssl.so.111
> /usr/local/bin/openssl version -v
>     OpenSSL 1.1.1c  28 May 2019 (Library: OpenSSL 1.1.1a-freebsd  20 Nov
> 2018)
>
> Without forcing anything with LD_PRELOAD, ... are your client and
> server in fact 1.1.1 in both the executable and the library?
>
> --
>         Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190613/48566d53/attachment.html>

From openssl-users at dukhovni.org  Thu Jun 13 04:27:56 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 13 Jun 2019 00:27:56 -0400
Subject: Is X25519/X448 supported for TLSv1.2?
In-Reply-To: <CAJbO6CQRVYpEYbGJxjSQvx68RbV7Kc40oST2GtQFs8ahyfzR4A@mail.gmail.com>
References: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>
 <20190612083341.GB33899@straasha.imrryr.org>
 <CAJbO6CQB_vAkX_GRjL2CHFOx3aWTCNewxJ8UFStHwwazdBU7WQ@mail.gmail.com>
 <20190612190004.GE33899@straasha.imrryr.org>
 <CAJbO6CQRVYpEYbGJxjSQvx68RbV7Kc40oST2GtQFs8ahyfzR4A@mail.gmail.com>
Message-ID: <20190613042756.GI33899@straasha.imrryr.org>

On Thu, Jun 13, 2019 at 10:49:14AM +0800, John Jiang wrote:

> I got the point: the server certificate is ECDSA with curve secp256r1.
> It works with RSA certificate and curves
> sepc256r1/sepc384r1/sepc521r1/x25519/x448.

See https://github.com/openssl/openssl/issues/4175#issuecomment-322915924

When using ECDSA with TLSv1.2, the group list MUST include the group
used in the certificate.  Otherwise, you get no shared cipher as
you reported.  You can *prefer* X25519, but you cannot only offer
X25519.

-- 
	Viktor.

From yitiger at hotmail.com  Thu Jun 13 06:04:08 2019
From: yitiger at hotmail.com (Yi tiger)
Date: Thu, 13 Jun 2019 06:04:08 +0000
Subject: RSA public and private key encrypt with fips issue
In-Reply-To: <HK0PR06MB2514F792B8F0CAF155FA7724B2EC0@HK0PR06MB2514.apcprd06.prod.outlook.com>
References: <HK0PR06MB2514F792B8F0CAF155FA7724B2EC0@HK0PR06MB2514.apcprd06.prod.outlook.com>
Message-ID: <HK0PR06MB2514A38C3ADD080778C4602EB2EF0@HK0PR06MB2514.apcprd06.prod.outlook.com>

Hi guys,

I then build the same source code on my Linux box (CentOS 7.1 3.10.0-299.el7.x86_64) it work fine.
The environment is windows 10 with VS 2017, the sample app is configured for 32-bit.

Can anyone help?

Thanks very much.


Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10

________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Yi tiger <yitiger at hotmail.com>
Sent: Wednesday, June 12, 2019 11:31:37 PM
To: openssl-users at openssl.org
Subject: RSA public and private key encrypt with fips issue

Hi guys,

I have download openssl 1.0.2s and fips 2.0.16 and build successfully on windows and then I try to write a simple app encrypted with public key and decrypt with private key. But It failed decrypted with private key when fips mode is turned on, decrypt will be success if fips is turned off.
I got below error

[cid:image001.png at 01D52176.09181B50]

The first error occurs if I pass RSA_sizeof(rsa) as  RSA_private_decrypt ?s first parameter, the second error if I pass the encrypted buffer?s length as RSA_private_decrypt?s first parameter.
I also noticed return value of RSA_size is different when fips mode is turned on.
Its size is 256 if fips is turned off, but become 128 if fips turned on.
RSA_public_encrypt return value is equal to RSA_size when fips is turned off, but its return value will great than RSA_size when truned on, maybe this cause decrypt or something its my code problem?

Below is my source code,


#include "openssl\crypto.h"
#include "openssl\rsa.h"
#include "openssl\err.h"
#include "openssl/pem.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

char* privatekey;
int privlen;
char* publickey;
int publen;

void generate()
{
       int mode = FIPS_mode();
       if (mode == 0)
       {
              int ret = FIPS_mode_set(1);
              if (ret != 1)
              {
                     printf("error %s", ERR_get_error());
              }
       }

       RSA *rsa = RSA_generate_key(2048, 3, NULL, NULL);

       BIO *bio = BIO_new(BIO_s_mem());
       PEM_write_bio_RSAPrivateKey(bio, rsa, NULL, NULL, 0, NULL, NULL);
       int rszsize = RSA_size(rsa);
       privlen = BIO_pending(bio);
       privatekey = (char*)malloc(privlen + 1);
       BIO_read(bio, privatekey, privlen);

       PEM_write_bio_RSAPublicKey(bio, rsa);
       publen = BIO_pending(bio);
       publickey = (char*)malloc(publen + 1);
       BIO_read(bio, publickey, publen);

       BIO_free_all(bio);
       RSA_free(rsa);
}

void Encrypt(const char* password)
{
       BIO *bio = BIO_new(BIO_s_mem());
       RSA *rsa = NULL;
       BIO_write(bio, publickey, publen);
       RSA* temp = PEM_read_bio_RSAPublicKey(bio, &rsa, NULL, NULL);
       char encrypted[500];
       int len = 0;
       if (temp != NULL)
       {
              int rsasize = RSA_size(rsa);
              len = RSA_public_encrypt((int)strlen(password), (unsigned char*)password, (unsigned char*)encrypted, rsa, RSA_PKCS1_OAEP_PADDING);
              if (len == -1)
              {
                     int e = ERR_get_error();
                     char * err = ERR_error_string(ERR_get_error(), encrypted);
                     printf("RSA_public_encrypt failed.\n");
              }
              else
              {
                     printf("%s", encrypted);
              }
       }

       BIO *newbio = BIO_new_mem_buf(privatekey, privlen);
       RSA *privRsa = NULL;
       PEM_read_bio_RSAPrivateKey(newbio, &privRsa, NULL, NULL);

       char p[4096] = { 0 };
       int rsasize = RSA_size(privRsa);
       if (privRsa != NULL)
       {
              int ret = RSA_private_decrypt(rsasize, (unsigned char*)encrypted, (unsigned char*)p, privRsa, RSA_PKCS1_OAEP_PADDING);
              if (ret == -1)
              {
                     int e = ERR_get_error();
                     char * err = ERR_error_string(ERR_get_error(), p);
                     printf("error");
              }
       }
}

Thanks,
Tiger

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190613/bf319b57/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 152DDD620E3544FC80BD3B3AE89C45CB.png
Type: image/png
Size: 4386 bytes
Desc: 152DDD620E3544FC80BD3B3AE89C45CB.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190613/bf319b57/attachment-0001.png>

From jgh at wizmail.org  Thu Jun 13 14:07:21 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Thu, 13 Jun 2019 15:07:21 +0100
Subject: EVP_DigestSign()
Message-ID: <ba02b552-945c-798b-eeb9-3b667bcfbc5e@wizmail.org>

[OpenSSL 1.1.1b FIPS   on Fedora 29]

What can a return code <= 0 from EVP_DigestSign(),
with  ERR_peek_error() return of 0,
be caused by?

ERR_error_string() decodes the 0 as "00000000:lib(0):func(0):reason(0)"
(assuming the ERR_peek_error(), ERR_get_error() sequence is not
lying to me) which is not very helpful.  OTOH, ERR_get_error()
docs says that 0 means "no error" - so why the fail return from
the EVP call?

The call was: EVP_DigestSign(ctx, NULL, &siglen, NULL, 0)
- i.e. I'm asking for the siglen, so that I can allocate memory
for the sig.
-- 
Thanks,
  Jeremy

From intera_91 at yahoo.co.uk  Thu Jun 13 17:06:36 2019
From: intera_91 at yahoo.co.uk (Patrick Regnouf)
Date: Thu, 13 Jun 2019 17:06:36 +0000 (UTC)
Subject: New to the list and one question ;-)
References: <1062700044.1644780.1560445596450.ref@mail.yahoo.com>
Message-ID: <1062700044.1644780.1560445596450@mail.yahoo.com>

Thanks Matt, adding a call to?SSL_CTX_set_ecdh_auto()? on the server side actually did the trick. Problem solved!!!
/Patrick?



Contrary to what you said in your original post the chrome session is NOT
selecting 0xc02f. Instead it is selecting 0x002f which is
TLS_RSA_WITH_AES_128_CBC_SHA (aka AES128-SHA in the OpenSSL naming scheme).

This cipher is not being offered by firefox but is by chrome. It is striking to
note that although chrome is offering a whole list of ciphersuites offering
forward secrecy (i.e. all those including ECDHE/DHE), the server is instead
selecting a very old ciphersuite that does not support forward secrecy.

In comparison firefox does not offer any ciphersuites that do not support
forward secrecy and the connection fails.

Have you called SSL_CTX_set_tmp_dh() or SSL_CTX_set_ecdh_auto() on the server?
I'd suggest trying those and see if it helps.

Matt


Sent from Yahoo Mail for iPhone
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190613/80e49b8c/attachment.html>

From minfrin at sharp.fm  Thu Jun 13 23:42:05 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Fri, 14 Jun 2019 01:42:05 +0200
Subject: Shutting down openssl - is the correct thing to do nothing?
Message-ID: <7120C70A-0866-488C-BA53-9E04F0F9C577@sharp.fm>

Hi all,

I am currently reviewing the shutdown behaviour in both httpd?s mod_ssl and apr?s apr-crypto-openssl modules.

Am I right in understanding that from openssl v1.1.0 and upwards, all the following calls are no longer necessary, will be called automatically atexit by the openssl library, and these can be removed from the code?

https://svn.apache.org/viewvc/httpd/httpd/tags/2.4.39/modules/ssl/mod_ssl.c?view=markup#l329

    FIPS_mode_set(0);
    OBJ_cleanup();
    CONF_modules_free();
    EVP_cleanup();
    ENGINE_cleanup();
    SSL_COMP_free_compression_methods();
    ERR_remove_thread_state(NULL);
    ERR_remove_state(0);
    ERR_free_strings();
    CRYPTO_cleanup_all_ex_data();

https://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/crypto/apr_crypto_openssl.c?view=markup#l114

    ERR_free_strings();
    EVP_cleanup();
    ENGINE_cleanup();

Regards,
Graham
?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3260 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/6709b883/attachment.bin>

From john.sha.jiang at gmail.com  Fri Jun 14 01:05:32 2019
From: john.sha.jiang at gmail.com (John Jiang)
Date: Fri, 14 Jun 2019 09:05:32 +0800
Subject: Is X25519/X448 supported for TLSv1.2?
In-Reply-To: <20190613042756.GI33899@straasha.imrryr.org>
References: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>
 <20190612083341.GB33899@straasha.imrryr.org>
 <CAJbO6CQB_vAkX_GRjL2CHFOx3aWTCNewxJ8UFStHwwazdBU7WQ@mail.gmail.com>
 <20190612190004.GE33899@straasha.imrryr.org>
 <CAJbO6CQRVYpEYbGJxjSQvx68RbV7Kc40oST2GtQFs8ahyfzR4A@mail.gmail.com>
 <20190613042756.GI33899@straasha.imrryr.org>
Message-ID: <CAJbO6CRTAsAOgaDJdpX6WLnJtt26wr-H5T0oJbvMFVryWUWx5A@mail.gmail.com>

On Thu, Jun 13, 2019 at 12:28 PM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Thu, Jun 13, 2019 at 10:49:14AM +0800, John Jiang wrote:
>
> > I got the point: the server certificate is ECDSA with curve secp256r1.
> > It works with RSA certificate and curves
> > sepc256r1/sepc384r1/sepc521r1/x25519/x448.
>
> See https://github.com/openssl/openssl/issues/4175#issuecomment-322915924
>
> When using ECDSA with TLSv1.2, the group list MUST include the group
> used in the certificate.  Otherwise, you get no shared cipher as
> you reported.

How about this point in TLSv1.3?
With my testing, the case "ECDSA certificate with curve secp256r1 + named
group secp521r1" work fine with OpenSSL s_server and s_client.


> You can *prefer* X25519, but you cannot only offer
> X25519.
>
Just an intentional test.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/4c83ac8b/attachment.html>

From openssl-users at dukhovni.org  Fri Jun 14 01:44:46 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 13 Jun 2019 21:44:46 -0400
Subject: Is X25519/X448 supported for TLSv1.2?
In-Reply-To: <CAJbO6CRTAsAOgaDJdpX6WLnJtt26wr-H5T0oJbvMFVryWUWx5A@mail.gmail.com>
References: <CAJbO6CQrqwM6Sxx=bw0POHPp0Pg2DN1HqLSBsf-c-BVH1vwTcQ@mail.gmail.com>
 <20190612083341.GB33899@straasha.imrryr.org>
 <CAJbO6CQB_vAkX_GRjL2CHFOx3aWTCNewxJ8UFStHwwazdBU7WQ@mail.gmail.com>
 <20190612190004.GE33899@straasha.imrryr.org>
 <CAJbO6CQRVYpEYbGJxjSQvx68RbV7Kc40oST2GtQFs8ahyfzR4A@mail.gmail.com>
 <20190613042756.GI33899@straasha.imrryr.org>
 <CAJbO6CRTAsAOgaDJdpX6WLnJtt26wr-H5T0oJbvMFVryWUWx5A@mail.gmail.com>
Message-ID: <20190614014446.GK33899@straasha.imrryr.org>

On Fri, Jun 14, 2019 at 09:05:32AM +0800, John Jiang wrote:

> > See https://github.com/openssl/openssl/issues/4175#issuecomment-322915924
> >
> > When using ECDSA with TLSv1.2, the group list MUST include the group
> > used in the certificate.  Otherwise, you get no shared cipher as
> > you reported.
> 
> How about this point in TLSv1.3?
> With my testing, the case "ECDSA certificate with curve secp256r1 + named
> group secp521r1" work fine with OpenSSL s_server and s_client.

In TLS 1.3, the "supported groups" extension restricts the curves
used in the key exchange:

  https://tools.ietf.org/html/rfc8446#section-4.2.7

The curves used for signing are covered by "signature algorithms":

    https://tools.ietf.org/html/rfc8446#section-4.2.3

Which should, if I am not mistaken, allow an ECDSA certificate to
be used with a "supported groups" list that does not list the curve
associated with the certificate.

-- 
	Viktor.

From matt at openssl.org  Fri Jun 14 07:41:49 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 14 Jun 2019 08:41:49 +0100
Subject: Shutting down openssl - is the correct thing to do nothing?
In-Reply-To: <7120C70A-0866-488C-BA53-9E04F0F9C577@sharp.fm>
References: <7120C70A-0866-488C-BA53-9E04F0F9C577@sharp.fm>
Message-ID: <0cee78dd-6d29-46e6-cc5c-9a21e5efd6d7@openssl.org>



On 14/06/2019 00:42, Graham Leggett wrote:
> Hi all,
> 
> I am currently reviewing the shutdown behaviour in both httpd?s mod_ssl and apr?s apr-crypto-openssl modules.
> 
> Am I right in understanding that from openssl v1.1.0 and upwards, all the following calls are no longer necessary, will be called automatically atexit by the openssl library, and these can be removed from the code?
> 
> https://svn.apache.org/viewvc/httpd/httpd/tags/2.4.39/modules/ssl/mod_ssl.c?view=markup#l329
> 
>     FIPS_mode_set(0);
>     OBJ_cleanup();
>     CONF_modules_free();
>     EVP_cleanup();
>     ENGINE_cleanup();
>     SSL_COMP_free_compression_methods();
>     ERR_remove_thread_state(NULL);
>     ERR_remove_state(0);
>     ERR_free_strings();
>     CRYPTO_cleanup_all_ex_data();
> 
> https://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/crypto/apr_crypto_openssl.c?view=markup#l114
> 
>     ERR_free_strings();
>     EVP_cleanup();
>     ENGINE_cleanup();
> 

Correct. *All* of the above calls are no-ops in 1.1.0+, e.g:

#  define EVP_cleanup() while(0) continue

There are one or two caveats around auto-init and auto-deinit of the library.
The documentation for it is here:

https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html

Matt

From minfrin at sharp.fm  Fri Jun 14 08:17:08 2019
From: minfrin at sharp.fm (Graham Leggett)
Date: Fri, 14 Jun 2019 10:17:08 +0200
Subject: Shutting down openssl - is the correct thing to do nothing?
In-Reply-To: <0cee78dd-6d29-46e6-cc5c-9a21e5efd6d7@openssl.org>
References: <7120C70A-0866-488C-BA53-9E04F0F9C577@sharp.fm>
 <0cee78dd-6d29-46e6-cc5c-9a21e5efd6d7@openssl.org>
Message-ID: <CC4DB01A-7BF6-47CC-A13A-1843C1C47009@sharp.fm>

On 14 Jun 2019, at 09:41, Matt Caswell <matt at openssl.org> wrote:

> Correct. *All* of the above calls are no-ops in 1.1.0+, e.g:
> 
> #  define EVP_cleanup() while(0) continue
> 
> There are one or two caveats around auto-init and auto-deinit of the library.
> The documentation for it is here:
> 
> https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html <https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html>

Further to the above question, having read the documentation, it looks like all of these init routines should be removed in v1.1.0 and above:

https://svn.apache.org/viewvc/httpd/httpd/tags/2.4.39/modules/ssl/mod_ssl.c?view=markup#l398

CRYPTO_malloc_init();
OPENSSL_malloc_init();
ERR_load_crypto_strings();
SSL_load_error_strings();
SSL_library_init();
ENGINE_load_builtin_engines();
OpenSSL_add_all_algorithms();
OPENSSL_load_builtin_modules();

https://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/crypto/apr_crypto_openssl.c?view=markup#l133

CRYPTO_malloc_init();
OPENSSL_malloc_init();
ERR_load_crypto_strings();
OpenSSL_add_all_algorithms();
ENGINE_load_builtin_engines();
ENGINE_register_all_complete();

Can you confirm I?ve interpreted this correctly?

Regards,
Graham
?

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

From matt at openssl.org  Fri Jun 14 09:12:19 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 14 Jun 2019 10:12:19 +0100
Subject: Shutting down openssl - is the correct thing to do nothing?
In-Reply-To: <CC4DB01A-7BF6-47CC-A13A-1843C1C47009@sharp.fm>
References: <7120C70A-0866-488C-BA53-9E04F0F9C577@sharp.fm>
 <0cee78dd-6d29-46e6-cc5c-9a21e5efd6d7@openssl.org>
 <CC4DB01A-7BF6-47CC-A13A-1843C1C47009@sharp.fm>
Message-ID: <83821782-85ad-133b-ef2a-24a75173bd97@openssl.org>



On 14/06/2019 09:17, Graham Leggett wrote:
> On 14 Jun 2019, at 09:41, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
>> Correct. *All* of the above calls are no-ops in 1.1.0+, e.g:
>>
>> # ?define EVP_cleanup() while(0) continue
>>
>> There are one or two caveats around auto-init and auto-deinit of the library.
>> The documentation for it is here:
>>
>> https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html
> 
> Further to the above question, having read the documentation, it looks like all
> of these init routines should be removed in v1.1.0 and above:

Mostly, but not quite. The library will automatically initialise itself with no
requirement to explicitly do so. However there are certain things that don't
happen automatically because they're not necessarily appropriate for all
applications. See comments below:

> 
> https://svn.apache.org/viewvc/httpd/httpd/tags/2.4.39/modules/ssl/mod_ssl.c?view=markup#l398
> 
> CRYPTO_malloc_init();

This function doesn't exist at all in 1.1.0+.

> OPENSSL_malloc_init();

This is a no-op in 1.1.0+

> ERR_load_crypto_strings();
> SSL_load_error_strings();
> SSL_library_init();

These all happen automatically. There is no need to call them directly. They're
all macros for calling OPENSSL_init_crypto() explicitly with default
options...but since they are default options anyway there is no need to do this.

> ENGINE_load_builtin_engines();

This does NOT happen automatically. It is a non-default option in
OPENSSL_init_crypto(). You can get the same effect by calling
OPENSSL_init_crypto with the OPENSSL_INIT_ENGINE_ALL_BUILTIN option explicitly. See:

https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_init_crypto.html

> OpenSSL_add_all_algorithms();

No need to call this one. Its a macro for calling OPENSSL_init_crypto()
explicitly with default options - but this will happen anyway.

> OPENSSL_load_builtin_modules();

This does NOT happen automatically if you are just using libcrypto. This is used
for initialising config file modules. libcrypto does not automatically load a
config file. If you call OPENSSL_init_crypto() explicitly with the
OPENSSL_INIT_LOAD_CONFIG option then it will load the config file and end up
calling the above function automatically as part of that.

In 1.1.1 a config file is loaded automatically for libssl users. So if you're a
1.1.1 libssl user then you don't need to call this function. A config file is
not loaded automatically for libssl in 1.1.0.

It is expected that in OpenSSL 3.0 loading a config file will happen
automatically in both libcrypto and libssl.

> 
> https://svn.apache.org/viewvc/apr/apr-util/tags/1.6.1/crypto/apr_crypto_openssl.c?view=markup#l133
> 
> CRYPTO_malloc_init();
> OPENSSL_malloc_init();
> ERR_load_crypto_strings();
> OpenSSL_add_all_algorithms();
> ENGINE_load_builtin_engines();

As above.

> ENGINE_register_all_complete();

This is the same as for ENGINE_load_builtin_engines(). It does NOT happen
automatically, but will get called if you use the
OPENSSL_INIT_ENGINE_ALL_BUILTIN option to OPENSSL_init_crypto.


Matt
> 
> Can you confirm I?ve interpreted this correctly?
> 
> Regards,
> Graham
> ?
> 

From Chethan.Kumar at toshiba-tsip.com  Fri Jun 14 09:35:06 2019
From: Chethan.Kumar at toshiba-tsip.com (Chethan Kumar)
Date: Fri, 14 Jun 2019 09:35:06 +0000
Subject: SHA1_Init () is called through SSL_shutdown () in FIPS mode
Message-ID: <447C096A3E2889439233CDD6DAB29F95C18AAF2D@tosblrmbx04.TOSHIBA-TSIP.COM>

Hi all,

Need help in resolving an error or understanding the flow.
Openssl library we are using is FIPS capabled.
Openssl version is 1.0.2n with fips-2.0.16
Platform: Linux version 3.10.38-ltsi-WR6.0.0.11_standard (gcc version 4.8.1)
We have an application which uses libssl and libcrypto for its operations.
Application is crashing because of a call to SSL_shutdown().

Gdb trace is shown below.

(gdb) bt

#0  0x42926357 in raise () from /lib/libc.so.6

#1  0x42929962 in abort () from /lib/libc.so.6

#2  0x77453e7a in OpenSSLDie () from /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#3  0x7745d0d8 in SHA1_Init () from /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#4  0x774f75ee in init () from /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#5  0x774ee8e0 in EVP_DigestInit_ex () from /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#6  0x774ea1f9 in ssleay_rand_bytes () from /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#7  0x774ea413 in ssleay_rand_nopseudo_bytes () from /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#8  0x774eabd0 in RAND_bytes () from /home/SYSROM_SRC/build/release/lib/libcrypto.so.1.0.0

#9  0x77654500 in tls1_enc () from /home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#10 0x77645eda in ssl3_dispatch_alert () from /home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#11 0x77644804 in ssl3_send_alert () from /home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#12 0x7764107e in ssl3_shutdown () from /home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#13 0x77662481 in SSL_shutdown () from /home/SYSROM_SRC/build/release/lib/libssl.so.1.0.0

#14 0x088a300e in tcp_disconnect ()

#15 0x088a623f in soap_closesock ()

#16 0x08886929 in soap_serve___stg2__login(soap*) ()

#17 0x08865547 in soap_serve_request ()

#18 0x0885fdee in soap_serve ()

As far as I know, SHA1_Init() is restricted when FIPS is enabled.
I want to know, why SHA1_Init() was called even when FIPS is enabled.

Let me know, if any more information is required to resolve the issue.

Thanks in advance,
Chethan Kumar

The information contained in this e-mail message and in any
attachments/annexure/appendices is confidential to the 
recipient and may contain privileged information. 
If you are not the intended recipient, please notify the
sender and delete the message along with any 
attachments/annexure/appendices. You should not disclose,
copy or otherwise use the information contained in the
message or any annexure. Any views expressed in this e-mail 
are those of the individual sender except where the sender 
specifically states them to be the views of 
Toshiba Software India Pvt. Ltd. (TSIP),Bangalore.

Although this transmission and any attachments are believed to be
free of any virus or other defect that might affect any computer 
system into which it is received and opened, it is the responsibility
of the recipient to ensure that it is virus free and no responsibility 
is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or
damage arising in any way from its use.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/48f8f69c/attachment-0001.html>

From ayb.serti at gmail.com  Fri Jun 14 10:09:19 2019
From: ayb.serti at gmail.com (Serti Ayoub)
Date: Fri, 14 Jun 2019 12:09:19 +0200
Subject: Race Condition
Message-ID: <CAB_5jmFyuv+U=HAHxDnpZAqh4oMkNQ06vw6jBC1hTgUt620QtA@mail.gmail.com>

Hi,

We upgraded a code base from openssl 1.0.2 to openssl1.1.1b.
The upgrade was straightforward and we manage to activate and use TLS1.3.
OpenSSL is used to implement multi-threaded HTTPS server.

While using TLS1.3 as the minimum version with option SSL_OP_NO_TICKET  the
app crash randomly due to a race condition in openssl, exactly when 2
threads use the same SSL_SESSION*.

Some t

We don't install any session management callback and we keep session
caching mode to 2 ( SSL_SESS_CACHE_SERVER).

I made some debugging/tracing and I found that SSL_OP_NO_TICKET force
openssl to call lookup_sess_in_cache() function ( file ssl_sess.c )

CRYPTO_THREAD_read_lock(s->session_ctx->lock);
ret = lh_SSL_SESSION_retrieve(s->session_ctx->sessions, &data);
if (ret != NULL) {
/* don't allow other threads to steal it: */
SSL_SESSION_up_ref(ret);
}
CRYPTO_THREAD_unlock(s->session_ctx->lock);

lh_SSL_SESSION_retriev() doesn't make any lock check in retrieved session
and lookup_sess_in_cache don't lock the session avec SSL_SESSION have a
CRYPT_RWLOCK member.

I can't provide a sample to reproduce the crash, it's totaly random.

Here example of thread call stack:

Thread1:
libssl-1_1-x64.dll!tls_parse_ctos_supported_groups(ssl_st * s, PACKET *
pkt, unsigned int context, x509_st * x, unsigned __int64 chainidx) Ligne
966 C
  libssl-1_1-x64.dll!tls_parse_extension(ssl_st * s, tlsext_index_en idx,
int context, raw_extension_st * exts, x509_st * x, unsigned __int64
chainidx) Ligne 715 C
  libssl-1_1-x64.dll!tls_parse_all_extensions(ssl_st * s, int context,
raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx, int fin)
Ligne 748 C
  libssl-1_1-x64.dll!tls_early_post_process_client_hello(ssl_st * s) Ligne
1883 C
  libssl-1_1-x64.dll!tls_post_process_client_hello(ssl_st * s, WORK_STATE
wst) Ligne 2222 C
  libssl-1_1-x64.dll!ossl_statem_server_post_process_message(ssl_st * s,
WORK_STATE wst) Ligne 1220 C
  libssl-1_1-x64.dll!read_state_machine(ssl_st * s) Ligne 664 C
  libssl-1_1-x64.dll!state_machine(ssl_st * s, int server) Ligne 434 C
  libssl-1_1-x64.dll!ossl_statem_accept(ssl_st * s) Ligne 256 C
  libssl-1_1-x64.dll!ssl3_read_bytes(ssl_st * s, int type, int *
recvd_type, unsigned char * buf, unsigned __int64 len, int peek, unsigned
__int64 * readbytes) Ligne 1270 C
  libssl-1_1-x64.dll!ssl3_read_internal(ssl_st * s, void * buf, unsigned
__int64 len, int peek, unsigned __int64 * readbytes) Ligne 4473 C
  libssl-1_1-x64.dll!ssl3_read(ssl_st * s, void * buf, unsigned __int64
len, unsigned __int64 * readbytes) Ligne 4498 C
  libssl-1_1-x64.dll!ssl_read_internal(ssl_st * s, void * buf, unsigned
__int64 num, unsigned __int64 * readbytes) Ligne 1754 C
  libssl-1_1-x64.dll!SSL_read(ssl_st * s, void * buf, int num) Ligne 1766 C

Thread2:
  libcrypto-1_1-x64.dll!CRYPTO_malloc(unsigned __int64 num, const char *
file, int line) Ligne 222 C
 libssl-1_1-x64.dll!tls1_save_u16(PACKET * pkt, wchar_t * * pdest, unsigned
__int64 * pdestlen) Ligne 1779 C
  libssl-1_1-x64.dll!tls_parse_ctos_supported_groups(ssl_st * s, PACKET *
pkt, unsigned int context, x509_st * x, unsigned __int64 chainidx) Ligne
968 C
  libssl-1_1-x64.dll!tls_parse_extension(ssl_st * s, tlsext_index_en idx,
int context, raw_extension_st * exts, x509_st * x, unsigned __int64
chainidx) Ligne 715 C
  libssl-1_1-x64.dll!tls_parse_all_extensions(ssl_st * s, int context,
raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx, int fin)
Ligne 748 C
  libssl-1_1-x64.dll!tls_early_post_process_client_hello(ssl_st * s) Ligne
1883 C
  libssl-1_1-x64.dll!tls_post_process_client_hello(ssl_st * s, WORK_STATE
wst) Ligne 2222 C
  libssl-1_1-x64.dll!ossl_statem_server_post_process_message(ssl_st * s,
WORK_STATE wst) Ligne 1220 C
  libssl-1_1-x64.dll!read_state_machine(ssl_st * s) Ligne 664 C
  libssl-1_1-x64.dll!state_machine(ssl_st * s, int server) Ligne 434 C
  libssl-1_1-x64.dll!ossl_statem_accept(ssl_st * s) Ligne 256 C
  libssl-1_1-x64.dll!ssl3_read_bytes(ssl_st * s, int type, int *
recvd_type, unsigned char * buf, unsigned __int64 len, int peek, unsigned
__int64 * readbytes) Ligne 1270 C
  libssl-1_1-x64.dll!ssl3_read_internal(ssl_st * s, void * buf, unsigned
__int64 len, int peek, unsigned __int64 * readbytes) Ligne 4473 C
  libssl-1_1-x64.dll!ssl3_read(ssl_st * s, void * buf, unsigned __int64
len, unsigned __int64 * readbytes) Ligne 4498 C
  libssl-1_1-x64.dll!ssl_read_internal(ssl_st * s, void * buf, unsigned
__int64 num, unsigned __int64 * readbytes) Ligne 1754 C
  libssl-1_1-x64.dll!SSL_read(ssl_st * s, void * buf, int num) Ligne 1766 C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/67786c58/attachment.html>

From matt at openssl.org  Fri Jun 14 12:09:30 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 14 Jun 2019 13:09:30 +0100
Subject: Race Condition
In-Reply-To: <CAB_5jmFyuv+U=HAHxDnpZAqh4oMkNQ06vw6jBC1hTgUt620QtA@mail.gmail.com>
References: <CAB_5jmFyuv+U=HAHxDnpZAqh4oMkNQ06vw6jBC1hTgUt620QtA@mail.gmail.com>
Message-ID: <77502174-3b7c-8f80-0694-67e3d2e7bc65@openssl.org>



On 14/06/2019 11:09, Serti Ayoub wrote:
> 
> I can't provide a sample to reproduce the crash, it's totaly random.
> ?
> Here example of thread call stack:

Yes, this does look like a bug. My guess is most people don't hit this because
they don't set SSL_OP_NO_TICKET in TLSv1.3. The default behaviour is to use
stateless tickets which aren't shared between threads, so no race condition is
possible. However, with SSL_OP_NO_TICKET we use stateful tickets which means the
session objects *are* shared.

Session objects are supposed to be immutable after the initial handshake is
complete so that this sort of thing doesn't happen. Looks like that isn't the
case in the handling of supported groups. In reality there is no reason at all
to store the supported groups information in the session object since we don't
reuse that information from one session resume to another anyway so its just
misplaced in the session object.

Please try out this patch:

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

Matt




From rashok.svks at gmail.com  Fri Jun 14 12:28:05 2019
From: rashok.svks at gmail.com (Raja Ashok)
Date: Fri, 14 Jun 2019 17:58:05 +0530
Subject: RSA PSS RSAE Cert Generation
Message-ID: <CADSGPoEwGNbaHi5FfBR+Vtva2BQJO445aM2jicG9v=FUFD7BEQ@mail.gmail.com>

Hi All,

For using with TLS1.3, I am able to generate rsa_pss_pss cert (Both Public
key and Signature of RSA_PSS OID) with the below script.

https://github.com/raja-ashok/sample_certificates/blob/master/RSA_PSS_PSS_Certs/gen_rsa_cert.sh

Can some one help me to find out the command for generating rsa_pss_rsae
cert (Public key of rsaEncryption OID and Signature of RSA PSS OID) ?

Thanks in advance !
Raja Ashok
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/19cff0fe/attachment.html>

From paul.dale at oracle.com  Fri Jun 14 12:02:31 2019
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Fri, 14 Jun 2019 22:02:31 +1000
Subject: Race Condition
In-Reply-To: <CAB_5jmFyuv+U=HAHxDnpZAqh4oMkNQ06vw6jBC1hTgUt620QtA@mail.gmail.com>
References: <CAB_5jmFyuv+U=HAHxDnpZAqh4oMkNQ06vw6jBC1hTgUt620QtA@mail.gmail.com>
Message-ID: <009263AD-3EE8-4023-B7F0-B973DC8AD2EB@oracle.com>

The SSL sessions are not thread safe.  It is up to the calling application to ensure that this race condition does not occur.


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



> On 14 Jun 2019, at 8:09 pm, Serti Ayoub <ayb.serti at gmail.com> wrote:
> 
> Hi,
> 
> We upgraded a code base from openssl 1.0.2 to openssl1.1.1b.
> The upgrade was straightforward and we manage to activate and use TLS1.3.
> OpenSSL is used to implement multi-threaded HTTPS server. 
> 
> While using TLS1.3 as the minimum version with option SSL_OP_NO_TICKET  the app crash randomly due to a race condition in openssl, exactly when 2 threads use the same SSL_SESSION*.
> 
> Some t
> 
> We don't install any session management callback and we keep session caching mode to 2 ( SSL_SESS_CACHE_SERVER).
> 
> I made some debugging/tracing and I found that SSL_OP_NO_TICKET force openssl to call lookup_sess_in_cache() function ( file ssl_sess.c )  
> 
>         CRYPTO_THREAD_read_lock(s->session_ctx->lock);
>         ret = lh_SSL_SESSION_retrieve(s->session_ctx->sessions, &data);
>         if (ret != NULL) {
>             /* don't allow other threads to steal it: */
>             SSL_SESSION_up_ref(ret);
>         }
>         CRYPTO_THREAD_unlock(s->session_ctx->lock);
> 
> lh_SSL_SESSION_retriev() doesn't make any lock check in retrieved session and lookup_sess_in_cache don't lock the session avec SSL_SESSION have a CRYPT_RWLOCK member.
> 
> I can't provide a sample to reproduce the crash, it's totaly random.
>  
> Here example of thread call stack:
> 
> Thread1:
> libssl-1_1-x64.dll!tls_parse_ctos_supported_groups(ssl_st * s, PACKET * pkt, unsigned int context, x509_st * x, unsigned __int64 chainidx) Ligne 966	C
>  	libssl-1_1-x64.dll!tls_parse_extension(ssl_st * s, tlsext_index_en idx, int context, raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx) Ligne 715	C
>  	libssl-1_1-x64.dll!tls_parse_all_extensions(ssl_st * s, int context, raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx, int fin) Ligne 748	C
>  	libssl-1_1-x64.dll!tls_early_post_process_client_hello(ssl_st * s) Ligne 1883	C
>  	libssl-1_1-x64.dll!tls_post_process_client_hello(ssl_st * s, WORK_STATE wst) Ligne 2222	C
>  	libssl-1_1-x64.dll!ossl_statem_server_post_process_message(ssl_st * s, WORK_STATE wst) Ligne 1220	C
>  	libssl-1_1-x64.dll!read_state_machine(ssl_st * s) Ligne 664	C
>  	libssl-1_1-x64.dll!state_machine(ssl_st * s, int server) Ligne 434	C
>  	libssl-1_1-x64.dll!ossl_statem_accept(ssl_st * s) Ligne 256	C
>  	libssl-1_1-x64.dll!ssl3_read_bytes(ssl_st * s, int type, int * recvd_type, unsigned char * buf, unsigned __int64 len, int peek, unsigned __int64 * readbytes) Ligne 1270	C
>  	libssl-1_1-x64.dll!ssl3_read_internal(ssl_st * s, void * buf, unsigned __int64 len, int peek, unsigned __int64 * readbytes) Ligne 4473	C
>  	libssl-1_1-x64.dll!ssl3_read(ssl_st * s, void * buf, unsigned __int64 len, unsigned __int64 * readbytes) Ligne 4498	C
>  	libssl-1_1-x64.dll!ssl_read_internal(ssl_st * s, void * buf, unsigned __int64 num, unsigned __int64 * readbytes) Ligne 1754	C
>  	libssl-1_1-x64.dll!SSL_read(ssl_st * s, void * buf, int num) Ligne 1766	C
> 
> Thread2:
>  	libcrypto-1_1-x64.dll!CRYPTO_malloc(unsigned __int64 num, const char * file, int line) Ligne 222	C
>  libssl-1_1-x64.dll!tls1_save_u16(PACKET * pkt, wchar_t * * pdest, unsigned __int64 * pdestlen) Ligne 1779	C
>  	libssl-1_1-x64.dll!tls_parse_ctos_supported_groups(ssl_st * s, PACKET * pkt, unsigned int context, x509_st * x, unsigned __int64 chainidx) Ligne 968	C
>  	libssl-1_1-x64.dll!tls_parse_extension(ssl_st * s, tlsext_index_en idx, int context, raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx) Ligne 715	C
>  	libssl-1_1-x64.dll!tls_parse_all_extensions(ssl_st * s, int context, raw_extension_st * exts, x509_st * x, unsigned __int64 chainidx, int fin) Ligne 748	C
>  	libssl-1_1-x64.dll!tls_early_post_process_client_hello(ssl_st * s) Ligne 1883	C
>  	libssl-1_1-x64.dll!tls_post_process_client_hello(ssl_st * s, WORK_STATE wst) Ligne 2222	C
>  	libssl-1_1-x64.dll!ossl_statem_server_post_process_message(ssl_st * s, WORK_STATE wst) Ligne 1220	C
>  	libssl-1_1-x64.dll!read_state_machine(ssl_st * s) Ligne 664	C
>  	libssl-1_1-x64.dll!state_machine(ssl_st * s, int server) Ligne 434	C
>  	libssl-1_1-x64.dll!ossl_statem_accept(ssl_st * s) Ligne 256	C
>  	libssl-1_1-x64.dll!ssl3_read_bytes(ssl_st * s, int type, int * recvd_type, unsigned char * buf, unsigned __int64 len, int peek, unsigned __int64 * readbytes) Ligne 1270	C
>  	libssl-1_1-x64.dll!ssl3_read_internal(ssl_st * s, void * buf, unsigned __int64 len, int peek, unsigned __int64 * readbytes) Ligne 4473	C
>  	libssl-1_1-x64.dll!ssl3_read(ssl_st * s, void * buf, unsigned __int64 len, unsigned __int64 * readbytes) Ligne 4498	C
>  	libssl-1_1-x64.dll!ssl_read_internal(ssl_st * s, void * buf, unsigned __int64 num, unsigned __int64 * readbytes) Ligne 1754	C
>  	libssl-1_1-x64.dll!SSL_read(ssl_st * s, void * buf, int num) Ligne 1766	C
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/15bc1210/attachment-0001.html>

From matt at openssl.org  Fri Jun 14 14:56:59 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 14 Jun 2019 15:56:59 +0100
Subject: RSA PSS RSAE Cert Generation
In-Reply-To: <CADSGPoEwGNbaHi5FfBR+Vtva2BQJO445aM2jicG9v=FUFD7BEQ@mail.gmail.com>
References: <CADSGPoEwGNbaHi5FfBR+Vtva2BQJO445aM2jicG9v=FUFD7BEQ@mail.gmail.com>
Message-ID: <5c410354-ac4f-5c15-51bc-eb7ee72b0caf@openssl.org>



On 14/06/2019 13:28, Raja Ashok wrote:
> Hi All,
> 
> For using with TLS1.3, I am able to generate rsa_pss_pss cert (Both Public key
> and Signature of RSA_PSS OID) with the below script.
> 
> https://github.com/raja-ashok/sample_certificates/blob/master/RSA_PSS_PSS_Certs/gen_rsa_cert.sh
> 
> Can some one help me to find out the command for generating rsa_pss_rsae cert
> (Public key of rsaEncryption OID and Signature of RSA PSS OID) ?

It's not entirely clear to me what you are asking for. In your script you
generate a root certificate and a server certificate. Both the root and the
server certificate use the RSA PSS OID. The signature in the server certificate
will be PSS because the root is using the PSS OID.

If you want to generate a server certificate that uses the rsaEncryption OID
then just drop the "-sigopt rsa_padding_mode:pss" option from the command
generating the serv_req.pem file. The rsaEncryption OID is the default.

The signature in the certificate depends on the oid in the root certificate and
how you sign using it. Since your root uses the RSA PSS OID then the signature
in the server cert will still be PSS.

But I'm not sure that is what you are actually asking for. There is no such
thing as an "rsa_pss_rsae" certificate. I think you are confusing the sig algs
from TLSv1.3 with the certificate type. In order to use the "rsa_pss_rsae" sig
alg in TLSv1.3 all you need is an RSA certificate with the rsaEncryption OID. It
makes no difference what the signature in the certificate is (that is only
relevant for verifying the chain). As long as you use a cert with the
rsaEncryption OID in it, and you negotiate TLSv1.3, then any signatures
generated during the handshake will be PSS signatures using an rsa_pss_rsae sig alg.

Matt

From giovanni.fontana72 at gmail.com  Fri Jun 14 18:12:47 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Fri, 14 Jun 2019 20:12:47 +0200
Subject: failing in reproducing .so files
In-Reply-To: <CAPMEXDYMRfpEyJtUObDJ0OagS9bViiOtOX48RxE3QC9RyeTuLw@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
 <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
 <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>
 <CAPMEXDYMRfpEyJtUObDJ0OagS9bViiOtOX48RxE3QC9RyeTuLw@mail.gmail.com>
Message-ID: <CAC-fp6M_LDJPE+uExNMJQ3NFAb=1PPeYRVDqg=fzSCqQ9Vg2Tw@mail.gmail.com>

A little bit further...with my problem in trying to build a tailored
version of openSSL.

If I do make I get at the end of building (trying to make .map file before
the .so files )

 creating test/libtestutil.a
ranlib test/libtestutil.a || echo Never mind.
/usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
Error: EVP_PKEY_get0_TUV does not have a number assigned
Makefile:762: recipe for target 'libcrypto.map' failed
make[1]: *** [libcrypto.map] Error 25
make[1]: Leaving directory
'/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
Makefile:172: recipe for target 'all' failed
make: *** [all] Error 2



...where EVP_PKEY_get0_TUV is a proprietary function similar to
EVP_PKEY_get0_RSA (),
Usually with a function that *does not have a number assigned *it could be
ok to do a *make update*, but when I run a *make update* it stopped after a
small while without concluding the action (and no more commands I can run
in that terminal window).
Here the log:

( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
            < apps/openssl.cnf > apps/openssl-vms.cnf )
( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
            crypto/objects/objects.txt \
            crypto/objects/obj_mac.num \
            > crypto/objects/obj_mac.new && \
    mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
( cd .; /usr/bin/perl crypto/objects/objects.pl \
            crypto/objects/objects.txt \
            crypto/objects/obj_mac.num \
            > include/openssl/obj_mac.h )
( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
            include/openssl/obj_mac.h \
            > crypto/objects/obj_dat.h )
( cd .; /usr/bin/perl crypto/objects/objxref.pl \
            crypto/objects/obj_mac.num \
            crypto/objects/obj_xref.txt \
            > crypto/objects/obj_xref.h )
( cd .; /usr/bin/perl crypto/conf/keysets.pl \
                > crypto/conf/conf_def.h )
( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
                > crypto/asn1/charmap.h )
( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
            crypto/objects/obj_dat.h \
            > fuzz/oids.txt )
( b=`pwd`; set -e; cd .; \
          /usr/bin/perl util/ck_errf.pl -strict -internal; \
          /usr/bin/perl -I$b util/mkerr.pl  -internal )




... as I said the compilation is OK for each file (even the one with
EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?

Kind regards
Giovanni Fontana




Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton <aerowolf at gmail.com>
ha scritto:

> In the unmodified directory:
> $ make clean
> $ make 2>&1 | tee /tmp/openssl-working-build.log
>
> In the modified directory:
> $ make clean
> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>
> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
> ${PAGER:more}
>
> Take note of the differences in output, and use that to determine what
> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
> when you need to capture why something is failing.)
>
> Good luck.
>
> -Kyle H
>
> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <giovanni.fontana72 at gmail.com>
> wrote:
>
>> The unmodified version works. As I said, it's sure the issue is on what I
>> added, but info from the building logs is not sufficient to figure out what
>> is the issue there. So as result of the building I have just:
>>
>>    - libcrypto.a
>>    - libssl.a
>>    - libcrypto.map
>>
>>
>> so what is missing are the following files:
>>
>>    - libssl.map
>>    - libcrypto.so
>>    - libssl.so
>>
>>
>> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <aerowolf at gmail.com>
>> ha scritto:
>>
>>> Can you try building an unmodified version of the tarball, and see if it
>>> has a problem?
>>>
>>> -Kyle
>>>
>>> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <
>>> giovanni.fontana72 at gmail.com> wrote:
>>>
>>>> Hello Kurt,
>>>>
>>>>
>>>>    - it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>>>    x86_64-linux-gnu-thread-multi
>>>>    - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>>>
>>>>
>>>> I guess is something from what I added since the original OPENSSL I'm
>>>> able to build, as well as other intermediate modifications. My issue is
>>>> it looks like the log doesn't give so much info and also the *make
>>>> update* doesn't complete his task.
>>>>
>>>> BR
>>>> Giovanni
>>>>
>>>> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx <kurt at roeckx.be>
>>>> ha scritto:
>>>>
>>>>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>>>>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION scriptcollect2:
>>>>>
>>>>> There seems to be a problem generating the libcrypto.map file for
>>>>> you. What does the file look like? Which perl version are you
>>>>> using? Which libc do you use?
>>>>>
>>>>>
>>>>> Kurt
>>>>>
>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/43318e24/attachment.html>

From beldmit at gmail.com  Fri Jun 14 18:15:58 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 14 Jun 2019 20:15:58 +0200
Subject: failing in reproducing .so files
In-Reply-To: <CAC-fp6M_LDJPE+uExNMJQ3NFAb=1PPeYRVDqg=fzSCqQ9Vg2Tw@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
 <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
 <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>
 <CAPMEXDYMRfpEyJtUObDJ0OagS9bViiOtOX48RxE3QC9RyeTuLw@mail.gmail.com>
 <CAC-fp6M_LDJPE+uExNMJQ3NFAb=1PPeYRVDqg=fzSCqQ9Vg2Tw@mail.gmail.com>
Message-ID: <CADqLbzK3tYXr2e0dMDg3mATbpiW4ZyPwiCgc0xveuAHzMH0Tig@mail.gmail.com>

It's worth trying to run make update before running make.

??, 14 ???. 2019 ?., 20:13 Giovanni Fontana <giovanni.fontana72 at gmail.com>:

> A little bit further...with my problem in trying to build a tailored
> version of openSSL.
>
> If I do make I get at the end of building (trying to make .map file
> before the .so files )
>
>  creating test/libtestutil.a
> ranlib test/libtestutil.a || echo Never mind.
> /usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
> Error: EVP_PKEY_get0_TUV does not have a number assigned
> Makefile:762: recipe for target 'libcrypto.map' failed
> make[1]: *** [libcrypto.map] Error 25
> make[1]: Leaving directory
> '/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
> Makefile:172: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
>
> ...where EVP_PKEY_get0_TUV is a proprietary function similar to
> EVP_PKEY_get0_RSA (),
> Usually with a function that *does not have a number assigned *it could
> be ok to do a *make update*, but when I run a *make update* it stopped
> after a small while without concluding the action (and no more commands I
> can run in that terminal window).
> Here the log:
>
> ( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
>             < apps/openssl.cnf > apps/openssl-vms.cnf )
> ( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
>             crypto/objects/objects.txt \
>             crypto/objects/obj_mac.num \
>             > crypto/objects/obj_mac.new && \
>     mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl \
>             crypto/objects/objects.txt \
>             crypto/objects/obj_mac.num \
>             > include/openssl/obj_mac.h )
> ( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
>             include/openssl/obj_mac.h \
>             > crypto/objects/obj_dat.h )
> ( cd .; /usr/bin/perl crypto/objects/objxref.pl \
>             crypto/objects/obj_mac.num \
>             crypto/objects/obj_xref.txt \
>             > crypto/objects/obj_xref.h )
> ( cd .; /usr/bin/perl crypto/conf/keysets.pl \
>                 > crypto/conf/conf_def.h )
> ( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
>                 > crypto/asn1/charmap.h )
> ( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
>             crypto/objects/obj_dat.h \
>             > fuzz/oids.txt )
> ( b=`pwd`; set -e; cd .; \
>           /usr/bin/perl util/ck_errf.pl -strict -internal; \
>           /usr/bin/perl -I$b util/mkerr.pl  -internal )
>
>
>
>
> ... as I said the compilation is OK for each file (even the one with
> EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?
>
> Kind regards
> Giovanni Fontana
>
>
>
>
> Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton <aerowolf at gmail.com>
> ha scritto:
>
>> In the unmodified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-working-build.log
>>
>> In the modified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>>
>> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
>> ${PAGER:more}
>>
>> Take note of the differences in output, and use that to determine what
>> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
>> when you need to capture why something is failing.)
>>
>> Good luck.
>>
>> -Kyle H
>>
>> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <
>> giovanni.fontana72 at gmail.com> wrote:
>>
>>> The unmodified version works. As I said, it's sure the issue is on what
>>> I added, but info from the building logs is not sufficient to figure out
>>> what is the issue there. So as result of the building I have just:
>>>
>>>    - libcrypto.a
>>>    - libssl.a
>>>    - libcrypto.map
>>>
>>>
>>> so what is missing are the following files:
>>>
>>>    - libssl.map
>>>    - libcrypto.so
>>>    - libssl.so
>>>
>>>
>>> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <
>>> aerowolf at gmail.com> ha scritto:
>>>
>>>> Can you try building an unmodified version of the tarball, and see if
>>>> it has a problem?
>>>>
>>>> -Kyle
>>>>
>>>> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <
>>>> giovanni.fontana72 at gmail.com> wrote:
>>>>
>>>>> Hello Kurt,
>>>>>
>>>>>
>>>>>    - it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>>>>    x86_64-linux-gnu-thread-multi
>>>>>    - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>>>>
>>>>>
>>>>> I guess is something from what I added since the original OPENSSL I'm
>>>>> able to build, as well as other intermediate modifications. My issue is
>>>>> it looks like the log doesn't give so much info and also the *make
>>>>> update* doesn't complete his task.
>>>>>
>>>>> BR
>>>>> Giovanni
>>>>>
>>>>> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx <kurt at roeckx.be>
>>>>> ha scritto:
>>>>>
>>>>>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>>>>>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION
>>>>>> scriptcollect2:
>>>>>>
>>>>>> There seems to be a problem generating the libcrypto.map file for
>>>>>> you. What does the file look like? Which perl version are you
>>>>>> using? Which libc do you use?
>>>>>>
>>>>>>
>>>>>> Kurt
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/999d25e7/attachment-0001.html>

From giovanni.fontana72 at gmail.com  Fri Jun 14 18:26:09 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Fri, 14 Jun 2019 20:26:09 +0200
Subject: failing in reproducing .so files
In-Reply-To: <CADqLbzK3tYXr2e0dMDg3mATbpiW4ZyPwiCgc0xveuAHzMH0Tig@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
 <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
 <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>
 <CAPMEXDYMRfpEyJtUObDJ0OagS9bViiOtOX48RxE3QC9RyeTuLw@mail.gmail.com>
 <CAC-fp6M_LDJPE+uExNMJQ3NFAb=1PPeYRVDqg=fzSCqQ9Vg2Tw@mail.gmail.com>
 <CADqLbzK3tYXr2e0dMDg3mATbpiW4ZyPwiCgc0xveuAHzMH0Tig@mail.gmail.com>
Message-ID: <CAC-fp6ODavsPLLjxebR0zqmzs9QLbjO5gi5ka7pSrxbbwU0PLw@mail.gmail.com>

...I just tried once more and (after a make clean) I run again a make
update, but it is stopped always in the same place. No more commands in
that specific terminal.
After that opening a new terminal and run the make, of course, I get the
same error again (Error: EVP_PKEY_get0_TUV does not have a number assigned).


Il giorno ven 14 giu 2019 alle ore 20:16 Dmitry Belyavsky <beldmit at gmail.com>
ha scritto:

> It's worth trying to run make update before running make.
>
> ??, 14 ???. 2019 ?., 20:13 Giovanni Fontana <giovanni.fontana72 at gmail.com
> >:
>
>> A little bit further...with my problem in trying to build a tailored
>> version of openSSL.
>>
>> If I do make I get at the end of building (trying to make .map file
>> before the .so files )
>>
>>  creating test/libtestutil.a
>> ranlib test/libtestutil.a || echo Never mind.
>> /usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
>> Error: EVP_PKEY_get0_TUV does not have a number assigned
>> Makefile:762: recipe for target 'libcrypto.map' failed
>> make[1]: *** [libcrypto.map] Error 25
>> make[1]: Leaving directory
>> '/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
>> Makefile:172: recipe for target 'all' failed
>> make: *** [all] Error 2
>>
>>
>>
>> ...where EVP_PKEY_get0_TUV is a proprietary function similar to
>> EVP_PKEY_get0_RSA (),
>> Usually with a function that *does not have a number assigned *it could
>> be ok to do a *make update*, but when I run a *make update* it stopped
>> after a small while without concluding the action (and no more commands I
>> can run in that terminal window).
>> Here the log:
>>
>> ( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
>>             < apps/openssl.cnf > apps/openssl-vms.cnf )
>> ( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
>> ( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
>>             crypto/objects/objects.txt \
>>             crypto/objects/obj_mac.num \
>>             > crypto/objects/obj_mac.new && \
>>     mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
>> ( cd .; /usr/bin/perl crypto/objects/objects.pl \
>>             crypto/objects/objects.txt \
>>             crypto/objects/obj_mac.num \
>>             > include/openssl/obj_mac.h )
>> ( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
>>             include/openssl/obj_mac.h \
>>             > crypto/objects/obj_dat.h )
>> ( cd .; /usr/bin/perl crypto/objects/objxref.pl \
>>             crypto/objects/obj_mac.num \
>>             crypto/objects/obj_xref.txt \
>>             > crypto/objects/obj_xref.h )
>> ( cd .; /usr/bin/perl crypto/conf/keysets.pl \
>>                 > crypto/conf/conf_def.h )
>> ( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
>>                 > crypto/asn1/charmap.h )
>> ( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
>>             crypto/objects/obj_dat.h \
>>             > fuzz/oids.txt )
>> ( b=`pwd`; set -e; cd .; \
>>           /usr/bin/perl util/ck_errf.pl -strict -internal; \
>>           /usr/bin/perl -I$b util/mkerr.pl  -internal )
>>
>>
>>
>>
>> ... as I said the compilation is OK for each file (even the one with
>> EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?
>>
>> Kind regards
>> Giovanni Fontana
>>
>>
>>
>>
>> Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton <
>> aerowolf at gmail.com> ha scritto:
>>
>>> In the unmodified directory:
>>> $ make clean
>>> $ make 2>&1 | tee /tmp/openssl-working-build.log
>>>
>>> In the modified directory:
>>> $ make clean
>>> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>>>
>>> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
>>> ${PAGER:more}
>>>
>>> Take note of the differences in output, and use that to determine what
>>> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
>>> when you need to capture why something is failing.)
>>>
>>> Good luck.
>>>
>>> -Kyle H
>>>
>>> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <
>>> giovanni.fontana72 at gmail.com> wrote:
>>>
>>>> The unmodified version works. As I said, it's sure the issue is on what
>>>> I added, but info from the building logs is not sufficient to figure out
>>>> what is the issue there. So as result of the building I have just:
>>>>
>>>>    - libcrypto.a
>>>>    - libssl.a
>>>>    - libcrypto.map
>>>>
>>>>
>>>> so what is missing are the following files:
>>>>
>>>>    - libssl.map
>>>>    - libcrypto.so
>>>>    - libssl.so
>>>>
>>>>
>>>> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <
>>>> aerowolf at gmail.com> ha scritto:
>>>>
>>>>> Can you try building an unmodified version of the tarball, and see if
>>>>> it has a problem?
>>>>>
>>>>> -Kyle
>>>>>
>>>>> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <
>>>>> giovanni.fontana72 at gmail.com> wrote:
>>>>>
>>>>>> Hello Kurt,
>>>>>>
>>>>>>
>>>>>>    - it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>>>>>    x86_64-linux-gnu-thread-multi
>>>>>>    - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>>>>>
>>>>>>
>>>>>> I guess is something from what I added since the original OPENSSL I'm
>>>>>> able to build, as well as other intermediate modifications. My issue is
>>>>>> it looks like the log doesn't give so much info and also the *make
>>>>>> update* doesn't complete his task.
>>>>>>
>>>>>> BR
>>>>>> Giovanni
>>>>>>
>>>>>> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx <kurt at roeckx.be>
>>>>>> ha scritto:
>>>>>>
>>>>>>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>>>>>>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION
>>>>>>> scriptcollect2:
>>>>>>>
>>>>>>> There seems to be a problem generating the libcrypto.map file for
>>>>>>> you. What does the file look like? Which perl version are you
>>>>>>> using? Which libc do you use?
>>>>>>>
>>>>>>>
>>>>>>> Kurt
>>>>>>>
>>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/5061ab8c/attachment.html>

From aerowolf at gmail.com  Fri Jun 14 18:33:16 2019
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Fri, 14 Jun 2019 13:33:16 -0500
Subject: failing in reproducing .so files
In-Reply-To: <CAC-fp6M_LDJPE+uExNMJQ3NFAb=1PPeYRVDqg=fzSCqQ9Vg2Tw@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
 <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
 <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>
 <CAPMEXDYMRfpEyJtUObDJ0OagS9bViiOtOX48RxE3QC9RyeTuLw@mail.gmail.com>
 <CAC-fp6M_LDJPE+uExNMJQ3NFAb=1PPeYRVDqg=fzSCqQ9Vg2Tw@mail.gmail.com>
Message-ID: <CAPMEXDb-KxQoShmtA5JTsXDjHosyGeJad1mdZa4jOJZ0UmrcgQ@mail.gmail.com>

Log into a different terminal window, run top.  Figure out if it's
infinitely looping, if it's getting stuck in a syscall (which sounds likely
-- if it is the case, you need to figure out why, which could be as simple
as a needed fsck or a required kernel update to address a bug), or if you
can kill -9 it when it gets in that state.

You can also try compiling your code on a different machine.  If it fails
there, try a different distribution of your OS (if available).  If these
all fail, it could be something that the OpenSSL team might need to address
in the script.

Good luck.

-Kyle H

On Fri, Jun 14, 2019, 13:13 Giovanni Fontana <giovanni.fontana72 at gmail.com>
wrote:

> A little bit further...with my problem in trying to build a tailored
> version of openSSL.
>
> If I do make I get at the end of building (trying to make .map file
> before the .so files )
>
>  creating test/libtestutil.a
> ranlib test/libtestutil.a || echo Never mind.
> /usr/bin/perl util/mkdef.pl crypto linux > libcrypto.map
> Error: EVP_PKEY_get0_TUV does not have a number assigned
> Makefile:762: recipe for target 'libcrypto.map' failed
> make[1]: *** [libcrypto.map] Error 25
> make[1]: Leaving directory
> '/home/vm/progetti/OPEN_SSL/OPEN_SSL_QP/openssl-1.1.1b'
> Makefile:172: recipe for target 'all' failed
> make: *** [all] Error 2
>
>
>
> ...where EVP_PKEY_get0_TUV is a proprietary function similar to
> EVP_PKEY_get0_RSA (),
> Usually with a function that *does not have a number assigned *it could
> be ok to do a *make update*, but when I run a *make update* it stopped
> after a small while without concluding the action (and no more commands I
> can run in that terminal window).
> Here the log:
>
> ( cd .; /usr/bin/perl VMS/VMSify-conf.pl \
>             < apps/openssl.cnf > apps/openssl-vms.cnf )
> ( cd .; /usr/bin/perl crypto/bn/bn_prime.pl > crypto/bn/bn_prime.h )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl -n \
>             crypto/objects/objects.txt \
>             crypto/objects/obj_mac.num \
>             > crypto/objects/obj_mac.new && \
>     mv crypto/objects/obj_mac.new crypto/objects/obj_mac.num )
> ( cd .; /usr/bin/perl crypto/objects/objects.pl \
>             crypto/objects/objects.txt \
>             crypto/objects/obj_mac.num \
>             > include/openssl/obj_mac.h )
> ( cd .; /usr/bin/perl crypto/objects/obj_dat.pl \
>             include/openssl/obj_mac.h \
>             > crypto/objects/obj_dat.h )
> ( cd .; /usr/bin/perl crypto/objects/objxref.pl \
>             crypto/objects/obj_mac.num \
>             crypto/objects/obj_xref.txt \
>             > crypto/objects/obj_xref.h )
> ( cd .; /usr/bin/perl crypto/conf/keysets.pl \
>                 > crypto/conf/conf_def.h )
> ( cd .; /usr/bin/perl crypto/asn1/charmap.pl \
>                 > crypto/asn1/charmap.h )
> ( cd .; /usr/bin/perl fuzz/mkfuzzoids.pl \
>             crypto/objects/obj_dat.h \
>             > fuzz/oids.txt )
> ( b=`pwd`; set -e; cd .; \
>           /usr/bin/perl util/ck_errf.pl -strict -internal; \
>           /usr/bin/perl -I$b util/mkerr.pl  -internal )
>
>
>
>
> ... as I said the compilation is OK for each file (even the one with
> EVP_PKEY_get0_TUV) , but then no .so libraries. Any suggestions?
>
> Kind regards
> Giovanni Fontana
>
>
>
>
> Il giorno lun 10 giu 2019 alle ore 16:12 Kyle Hamilton <aerowolf at gmail.com>
> ha scritto:
>
>> In the unmodified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-working-build.log
>>
>> In the modified directory:
>> $ make clean
>> $ make 2>&1 | tee /tmp/openssl-broken-build.log
>>
>> $ diff /tmp/openssl-working-build.log /tmp/openssl-broken-build.log |
>> ${PAGER:more}
>>
>> Take note of the differences in output, and use that to determine what
>> broke.  (the '2>&1' syntax redirects stderr to stdout, which is very useful
>> when you need to capture why something is failing.)
>>
>> Good luck.
>>
>> -Kyle H
>>
>> On Mon, Jun 10, 2019, 03:34 Giovanni Fontana <
>> giovanni.fontana72 at gmail.com> wrote:
>>
>>> The unmodified version works. As I said, it's sure the issue is on what
>>> I added, but info from the building logs is not sufficient to figure out
>>> what is the issue there. So as result of the building I have just:
>>>
>>>    - libcrypto.a
>>>    - libssl.a
>>>    - libcrypto.map
>>>
>>>
>>> so what is missing are the following files:
>>>
>>>    - libssl.map
>>>    - libcrypto.so
>>>    - libssl.so
>>>
>>>
>>> Il giorno dom 9 giu 2019 alle ore 19:30 Kyle Hamilton <
>>> aerowolf at gmail.com> ha scritto:
>>>
>>>> Can you try building an unmodified version of the tarball, and see if
>>>> it has a problem?
>>>>
>>>> -Kyle
>>>>
>>>> On Sun, Jun 9, 2019, 07:31 Giovanni Fontana <
>>>> giovanni.fontana72 at gmail.com> wrote:
>>>>
>>>>> Hello Kurt,
>>>>>
>>>>>
>>>>>    - it's perl 5, version 26, subversion 1 (v5.26.1) built for
>>>>>    x86_64-linux-gnu-thread-multi
>>>>>    - ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
>>>>>
>>>>>
>>>>> I guess is something from what I added since the original OPENSSL I'm
>>>>> able to build, as well as other intermediate modifications. My issue is
>>>>> it looks like the log doesn't give so much info and also the *make
>>>>> update* doesn't complete his task.
>>>>>
>>>>> BR
>>>>> Giovanni
>>>>>
>>>>> Il giorno sab 8 giu 2019 alle ore 18:07 Kurt Roeckx <kurt at roeckx.be>
>>>>> ha scritto:
>>>>>
>>>>>> On Sat, Jun 08, 2019 at 12:26:30AM +0200, Giovanni Fontana wrote:
>>>>>> > */usr/bin/ld:libcrypto.map:0: syntax error in VERSION
>>>>>> scriptcollect2:
>>>>>>
>>>>>> There seems to be a problem generating the libcrypto.map file for
>>>>>> you. What does the file look like? Which perl version are you
>>>>>> using? Which libc do you use?
>>>>>>
>>>>>>
>>>>>> Kurt
>>>>>>
>>>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/b6792268/attachment-0001.html>

From rsalz at akamai.com  Fri Jun 14 18:48:43 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 14 Jun 2019 18:48:43 +0000
Subject: failing in reproducing .so files
In-Reply-To: <CAC-fp6ODavsPLLjxebR0zqmzs9QLbjO5gi5ka7pSrxbbwU0PLw@mail.gmail.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
 <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
 <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>
 <CAPMEXDYMRfpEyJtUObDJ0OagS9bViiOtOX48RxE3QC9RyeTuLw@mail.gmail.com>
 <CAC-fp6M_LDJPE+uExNMJQ3NFAb=1PPeYRVDqg=fzSCqQ9Vg2Tw@mail.gmail.com>
 <CADqLbzK3tYXr2e0dMDg3mATbpiW4ZyPwiCgc0xveuAHzMH0Tig@mail.gmail.com>
 <CAC-fp6ODavsPLLjxebR0zqmzs9QLbjO5gi5ka7pSrxbbwU0PLw@mail.gmail.com>
Message-ID: <293BA51E-9771-4F41-A010-4CF9F39A82AC@akamai.com>

If you are adding new functions to the library, you need to
1A           Make sure there is a prototype in one of the existing OpenSSL header files;
                OR
1B           If your prototype is in a new header file, you will have to edit Configurations/unix-Makefile.tmpl to pick up that file.

2              Run configure

3.            Do ?make update?  Verify that the previous steps worked by looking for your new function(s) being declared in util/libcrypto.num

4.            Run make

This could be documented somewhere; anyone want to copy this email into a new issue?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190614/c1803ffe/attachment.html>

From openssl-users at dukhovni.org  Fri Jun 14 19:33:43 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 14 Jun 2019 15:33:43 -0400
Subject: Race Condition
In-Reply-To: <009263AD-3EE8-4023-B7F0-B973DC8AD2EB@oracle.com>
References: <CAB_5jmFyuv+U=HAHxDnpZAqh4oMkNQ06vw6jBC1hTgUt620QtA@mail.gmail.com>
 <009263AD-3EE8-4023-B7F0-B973DC8AD2EB@oracle.com>
Message-ID: <4C0105D9-4214-4848-87F4-AB5562292A51@dukhovni.org>

> On Jun 14, 2019, at 8:02 AM, Dr Paul Dale <paul.dale at oracle.com> wrote:
> 
> The SSL sessions are not thread safe.  It is up to the calling application to ensure that this race condition does not occur.

Paul, it sounds like you're confusing (SSL_SESSION *) with (SSL *).

-- 
	Viktor.


From paul.dale at oracle.com  Fri Jun 14 22:10:19 2019
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Sat, 15 Jun 2019 08:10:19 +1000
Subject: Race Condition
In-Reply-To: <4C0105D9-4214-4848-87F4-AB5562292A51@dukhovni.org>
References: <CAB_5jmFyuv+U=HAHxDnpZAqh4oMkNQ06vw6jBC1hTgUt620QtA@mail.gmail.com>
 <009263AD-3EE8-4023-B7F0-B973DC8AD2EB@oracle.com>
 <4C0105D9-4214-4848-87F4-AB5562292A51@dukhovni.org>
Message-ID: <0C0F301B-DAF1-465D-AC45-D756507CDA74@oracle.com>

I did confuse things, apologies.
One day I?ll learn that I shouldn?t answer questions late on a Friday evening after a long week.

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



> On 15 Jun 2019, at 5:33 am, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> 
>> On Jun 14, 2019, at 8:02 AM, Dr Paul Dale <paul.dale at oracle.com> wrote:
>> 
>> The SSL sessions are not thread safe.  It is up to the calling application to ensure that this race condition does not occur.
> 
> Paul, it sounds like you're confusing (SSL_SESSION *) with (SSL *).
> 
> -- 
> 	Viktor.
> 

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

From tniessen at tnie.de  Sat Jun 15 14:08:14 2019
From: tniessen at tnie.de (=?UTF-8?Q?Tobias_Nie=c3=9fen?=)
Date: Sat, 15 Jun 2019 16:08:14 +0200
Subject: Calling EVP_DigestFinal_ex multiple times
Message-ID: <5519fe7b-8410-245c-8fb1-142e6943d005@tnie.de>

Hello,

I am wondering whether it is permitted to call EVP_DigestFinal_ex multiple times on the same context in order to retrieve the same digest twice. I expected OpenSSL to fail with an error code, but SHA256 seems to permit it whereas SHA3 seems to cause a segmentation fault. The documentation does not explicitely forbid or allow it, so I am wondering where this should be addressed: In the implementation of EVP_*, in SHA2, in SHA3, in the documentation, or not at all?

Thank you in advance!
Tobias

From giovanni.fontana72 at gmail.com  Sat Jun 15 15:19:57 2019
From: giovanni.fontana72 at gmail.com (Giovanni Fontana)
Date: Sat, 15 Jun 2019 17:19:57 +0200
Subject: failing in reproducing .so files
In-Reply-To: <293BA51E-9771-4F41-A010-4CF9F39A82AC@akamai.com>
References: <CAC-fp6MF8uvJCSEwSbmSmdR-a36+7JopKXYU6VpS1eJVVojGyw@mail.gmail.com>
 <20190608160715.GB16521@roeckx.be>
 <CAC-fp6MOnA3vrNvTUdinhGNLNEd9LvS8xbQu==NsW+eM5SCYkA@mail.gmail.com>
 <CAPMEXDa3WJLZTdy6B=5T1mtVMGvOyHCwkG-fmjOLAOCHq+QV2Q@mail.gmail.com>
 <CAC-fp6N9xV_a+zsJvAO55i-QG2M2hoknrw-21wWYQ7063062jg@mail.gmail.com>
 <CAPMEXDYMRfpEyJtUObDJ0OagS9bViiOtOX48RxE3QC9RyeTuLw@mail.gmail.com>
 <CAC-fp6M_LDJPE+uExNMJQ3NFAb=1PPeYRVDqg=fzSCqQ9Vg2Tw@mail.gmail.com>
 <CADqLbzK3tYXr2e0dMDg3mATbpiW4ZyPwiCgc0xveuAHzMH0Tig@mail.gmail.com>
 <CAC-fp6ODavsPLLjxebR0zqmzs9QLbjO5gi5ka7pSrxbbwU0PLw@mail.gmail.com>
 <293BA51E-9771-4F41-A010-4CF9F39A82AC@akamai.com>
Message-ID: <CAC-fp6Nm7Gf9gYCZZb+O12qh1q1J362Vo3_ST7jQCSJMZY0zMA@mail.gmail.com>

Thanks Salz,
That investigation I will do for all the files I added, but for sure is not
that case for the API I added (EVP_PKEY_get0_TUV)  since is in a "native"
openssl file (crypto/evp/p_lib.c and include/openssl/evp.h)... But OK it
could be a side effect.

Il giorno ven 14 giu 2019 alle ore 20:48 Salz, Rich <rsalz at akamai.com> ha
scritto:

> If you are adding new functions to the library, you need to
>
> 1A           Make sure there is a prototype in one of the existing OpenSSL
> header files;
>
>                 OR
>
> 1B           If your prototype is in a new header file, you will have to
> edit Configurations/unix-Makefile.tmpl to pick up that file.
>
>
>
> 2              Run configure
>
>
>
> 3.            Do ?make update?  Verify that the previous steps worked by
> looking for your new function(s) being declared in util/libcrypto.num
>
>
>
> 4.            Run make
>
>
>
> This could be documented somewhere; anyone want to copy this email into a
> new issue?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190615/4583eb0a/attachment.html>

From wolf.tobias at gmx.net  Sun Jun 16 10:11:55 2019
From: wolf.tobias at gmx.net (Tobias Wolf)
Date: Sun, 16 Jun 2019 12:11:55 +0200
Subject: BIO in memory usage....
Message-ID: <018c01d5242b$eeb01b10$cc105130$@gmx.net>

I`d like to understand how a memory bio can be reseted with the internal
read counter back to zero for further reusage.



e.g.

I want to try to read first der and then pem



 <https://www.openssl.org/docs/man1.1.1/man3/d2i_X509.html> d2i_X509



and then:



 <https://www.openssl.org/docs/man1.1.1/man3/PEM_read_X509.html>
PEM_read_X509



Then the second call will fail because the bio has already read some bytes,
when I call each function with a newly created bio it is working fine.

I already tried with BIO_seek, BIO_tell (returns 0?!), BIO_reset.



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

From d3ck0r at gmail.com  Sun Jun 16 12:22:36 2019
From: d3ck0r at gmail.com (J Decker)
Date: Sun, 16 Jun 2019 05:22:36 -0700
Subject: BIO in memory usage....
In-Reply-To: <018c01d5242b$eeb01b10$cc105130$@gmx.net>
References: <018c01d5242b$eeb01b10$cc105130$@gmx.net>
Message-ID: <CAA2GJqUjGWHZNYct7hEyJsZXb-3iAVNLe1Z_U5-dxrYjdJbifw@mail.gmail.com>

On Sun, Jun 16, 2019 at 3:17 AM Tobias Wolf <wolf.tobias at gmx.net> wrote:

> I`d like to understand how a memory bio can be reseted with the internal
> read counter back to zero for further reusage.
>
>
>
> e.g.
>
> I want to try to read first der and then pem
>
>
>
> d2i_X509 <https://www.openssl.org/docs/man1.1.1/man3/d2i_X509.html>
>
>
>
> and then:
>
>
>
> PEM_read_X509
> <https://www.openssl.org/docs/man1.1.1/man3/PEM_read_X509.html>
>
>
>
> Then the second call will fail because the bio has already read some
> bytes, when I call each function with a newly created bio it is working
> fine.
>
> I already tried with BIO_seek, BIO_tell (returns 0?!), BIO_reset.
>

After reset did you also refill it?

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

From dfulger at gmx.com  Sun Jun 16 18:29:05 2019
From: dfulger at gmx.com (Dan Fulger)
Date: Sun, 16 Jun 2019 20:29:05 +0200
Subject: An idiosyncratic port of OpenSSL 1.1.1c to OS/400 ILE
Message-ID: <trinity-dab157e8-d9b1-48de-9c4d-1a6b0581843c-1560709744993@3c-app-mailcom-bs14>

This port is for ILE (native OS/400)?not PASE (PASE is almost like Unix, and already comes with openssl).
?
The idiosynchrasies are explained in the README.as400 file in AS400patch.tar.gz.
?
AS400patch.tar.gz (large patch for OpenSSL and other files):
https://drive.google.com/file/d/1xHk6dMjFW0MDrUsHiNSQLpk5LRz5H4yB

The patch is smaller than the 1.1.1b one because an AIX compatibility fix in 1.1.1c was almost identical to portions of my patch.
?
AS400_GNU.tar.gz (source for GNU/IBM tools required to build openssl in ILE environment):
https://drive.google.com/open?id=1DeKIE32nmUpvk7fvrcSYlflUn_k1CBso


From shivakumar2696 at gmail.com  Mon Jun 17 07:24:32 2019
From: shivakumar2696 at gmail.com (shiva kumar)
Date: Mon, 17 Jun 2019 12:54:32 +0530
Subject: Make file removed in openssl 1.1.1
Message-ID: <CAN9sONeBNV69uO6tJ26+hh-YZLY9KbpHkMFAFJ433MkxvKR_Pw@mail.gmail.com>

Hi,
In the OpenSSL 1.1.1 Make file is generated on top directory after when
config is executed.
 In OpenSSL 1.0.2 there is Make file at each directory and is hierarchical,
but this is not the same in 1.1.1 version.
Actually I was modifying the Makefile configurations manually in apps and
engines directory and also changing Makefile.org on top directory for my
build, now I'm not able to do that in OpenSSL 1.1.1b since, make file has
been removed in 1.1.1

can anyone please let me know how can I actually perform those changes in
the make file in OpenSSL 1.1.1b

Thanks and Regards
Shiv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190617/f22c7f93/attachment-0001.html>

From tmraz at redhat.com  Mon Jun 17 08:24:40 2019
From: tmraz at redhat.com (Tomas Mraz)
Date: Mon, 17 Jun 2019 10:24:40 +0200
Subject: BIO in memory usage....
In-Reply-To: <018c01d5242b$eeb01b10$cc105130$@gmx.net>
References: <018c01d5242b$eeb01b10$cc105130$@gmx.net>
Message-ID: <5a48587d753ef7e432e0084f174b1ae1d2fc0c85.camel@redhat.com>

On Sun, 2019-06-16 at 12:11 +0200, Tobias Wolf wrote:
> I`d like to understand how a memory bio can be reseted with the
> internal read counter back to zero for further reusage.
>  
> e.g.
> I want to try to read first der and then pem
>  
> d2i_X509
>  
> and then:
>  
> PEM_read_X509
>  
> Then the second call will fail because the bio has already read some
> bytes, when I call each function with a newly created bio it is
> working fine.
> I already tried with BIO_seek, BIO_tell (returns 0?!), BIO_reset.

If the BIO is read-only (created with BIO_new_mem_buf()) the BIO_reset
will work as you expect.

Please also see the NOTES section of BIO_s_mem manpage.

-- 
Tom?? Mr?z
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]



From matt at openssl.org  Mon Jun 17 09:06:48 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 17 Jun 2019 10:06:48 +0100
Subject: Calling EVP_DigestFinal_ex multiple times
In-Reply-To: <5519fe7b-8410-245c-8fb1-142e6943d005@tnie.de>
References: <5519fe7b-8410-245c-8fb1-142e6943d005@tnie.de>
Message-ID: <a2005825-10bb-180c-3d6f-fae347452fe3@openssl.org>



On 15/06/2019 15:08, Tobias Nie?en wrote:
> Hello,
> 
> I am wondering whether it is permitted to call EVP_DigestFinal_ex multiple
> times on the same context in order to retrieve the same digest twice. I
> expected OpenSSL to fail with an error code, but SHA256 seems to permit it
> whereas SHA3 seems to cause a segmentation fault. The documentation does not
> explicitely forbid or allow it, so I am wondering where this should be
> addressed: In the implementation of EVP_*, in SHA2, in SHA3, in the
> documentation, or not at all?

I believe this should not be allowed. Probably this is a documentation issue.

Matt


From matt at openssl.org  Mon Jun 17 10:22:09 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 17 Jun 2019 11:22:09 +0100
Subject: Make file removed in openssl 1.1.1
In-Reply-To: <CAN9sONeBNV69uO6tJ26+hh-YZLY9KbpHkMFAFJ433MkxvKR_Pw@mail.gmail.com>
References: <CAN9sONeBNV69uO6tJ26+hh-YZLY9KbpHkMFAFJ433MkxvKR_Pw@mail.gmail.com>
Message-ID: <3745c875-a8a9-aaff-3659-bdd8839e7c47@openssl.org>



On 17/06/2019 08:24, shiva kumar wrote:
> Hi,
> In the OpenSSL 1.1.1 Make file is generated on top directory after when config
> is executed.
> ?In OpenSSL 1.0.2 there is Make file at each directory and is hierarchical, but
> this is not the same in 1.1.1 version.
> Actually I was modifying the Makefile configurations manually in apps and
> engines directory and also changing Makefile.org on top directory for my build,
> now I'm not able to do that in OpenSSL 1.1.1b since, make file has been removed
> in 1.1.1
> 
> can anyone please let me know how can I actually perform those changes in the
> make file in OpenSSL 1.1.1b

It depends on what you want to achieve. The top level template Makefile is in
Configureations/unix-Makefile.tmpl. Each individual directory contains a
build.info file which allows you to make per-directory changes to things like
the sources to be compiled, etc.

Matt


From nagalakshmi.j at altran.com  Mon Jun 17 10:48:25 2019
From: nagalakshmi.j at altran.com (Nagalakshmi V J)
Date: Mon, 17 Jun 2019 10:48:25 +0000
Subject: Requesting information regarding OpenSSL upgrade
In-Reply-To: <MAXPR01MB24931667B399B09EAB014A39E7EF0@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM>
References: <MAXPR01MB24931667B399B09EAB014A39E7EF0@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM>
Message-ID: <MAXPR01MB2493ECD57EA21060F733108DE7EB0@MAXPR01MB2493.INDPRD01.PROD.OUTLOOK.COM>

Hi All,


We are currently using OpenSSL version 1.0.2j. Since OpenSSL 1.0.2  support is going to be stopped by end of this year, we are planning to upgrade to 1.1.1c version.



We are using Compiler GCC 3.4.3 in Linux and vc6 in Windows. Can we go ahead with these compiler versions while upgrading OpenSSL version or should we upgrade the compiler also.



Can anyone suggest?



Thanks and regards,
Nagalakshmi

=====================================================
Please refer to https://northamerica.altran.com/email-disclaimer
for important disclosures regarding this electronic communication.
=====================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190617/34eecaae/attachment.html>

From rsalz at akamai.com  Mon Jun 17 12:24:18 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 17 Jun 2019 12:24:18 +0000
Subject: Make file removed in openssl 1.1.1
In-Reply-To: <3745c875-a8a9-aaff-3659-bdd8839e7c47@openssl.org>
References: <CAN9sONeBNV69uO6tJ26+hh-YZLY9KbpHkMFAFJ433MkxvKR_Pw@mail.gmail.com>
 <3745c875-a8a9-aaff-3659-bdd8839e7c47@openssl.org>
Message-ID: <694EF50E-9CFE-4044-8F2B-D2B4A0DD8248@akamai.com>

>    It depends on what you want to achieve. The top level template Makefile is in
    Configureations/unix-Makefile.tmpl. Each individual directory contains a
    build.info file which allows you to make per-directory changes to things like
    the sources to be compiled, etc.
  
And also important, these are all processed to build a single Makefile.  There's only one now.


From wolf.tobias at gmx.net  Mon Jun 17 15:09:28 2019
From: wolf.tobias at gmx.net (Tobias Wolf)
Date: Mon, 17 Jun 2019 17:09:28 +0200
Subject: PkiPath with openssl
Message-ID: <trinity-0f8c416d-a62b-465a-8ef0-6349041e8d29-1560784168957@3c-app-gmx-bs19>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190617/a4bbf39f/attachment-0001.html>

From vieuxtech at gmail.com  Mon Jun 17 20:06:31 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Mon, 17 Jun 2019 13:06:31 -0700
Subject: Calling EVP_DigestFinal_ex multiple times
In-Reply-To: <a2005825-10bb-180c-3d6f-fae347452fe3@openssl.org>
References: <5519fe7b-8410-245c-8fb1-142e6943d005@tnie.de>
 <a2005825-10bb-180c-3d6f-fae347452fe3@openssl.org>
Message-ID: <CA+Sj9TmtcWSfMjnJqsDtCPT163Bm9EcUmQ4fBDGV_kF2txfrDw@mail.gmail.com>

On Mon, Jun 17, 2019 at 2:07 AM Matt Caswell <matt at openssl.org> wrote:
> On 15/06/2019 15:08, Tobias Nie?en wrote:
> > I am wondering whether it is permitted to call EVP_DigestFinal_ex multiple
> > times on the same context in order to retrieve the same digest twice. I
> > expected OpenSSL to fail with an error code, but SHA256 seems to permit it
> > whereas SHA3 seems to cause a segmentation fault. The documentation does not
> > explicitely forbid or allow it, so I am wondering where this should be
> > addressed: In the implementation of EVP_*, in SHA2, in SHA3, in the
> > documentation, or not at all?
>
> I believe this should not be allowed. Probably this is a documentation issue.

Just a doc issue? Shouldn't the SHAs behave more uniformly?

Also, is segfaulting a reasonable result of this kind of API use,
calling an API twice? Segving on bad memory is unavoidable, but
calling an API twice sounds detectable.

Cheers,
Sam

From eric_njedjou at hotmail.com  Mon Jun 17 20:29:04 2019
From: eric_njedjou at hotmail.com (Eric Ntonfo)
Date: Mon, 17 Jun 2019 20:29:04 +0000
Subject: Issues establising SSL connection after a wget command
Message-ID: <VI1PR05MB59177E15EB175C44659AE2C9F8EB0@VI1PR05MB5917.eurprd05.prod.outlook.com>


Hello,
I am running an Ubuntu 12.04 TLS server and can't use wget to download software packages
The command
wget http://curl.haxx.se/download/curl-7.63.0.tar.bz2
fails with the following error

--2019-06-17 22:10:11--  http://curl.haxx.se/download/curl-7.63.0.tar.bz2
Resolving curl.haxx.se (curl.haxx.se)... 2a04:4e42:9::561, 151.101.38.49
Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://curl.haxx.se/download/curl-7.63.0.tar.bz2 [following]
--2019-06-17 22:10:11--  https://curl.haxx.se/download/curl-7.63.0.tar.bz2
Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:443... connected.
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Unable to establish SSL connection.

I am unable to fix this issue. I have upgraded from openssl 1.0.1 on my Ubuntu box to openssl 1.0.2 having heard that this latest version fix the bug
But still having it.

Can someone help please?
Regards
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190617/fbcfb202/attachment.html>

From wiml at omnigroup.com  Mon Jun 17 22:43:04 2019
From: wiml at omnigroup.com (Wim Lewis)
Date: Mon, 17 Jun 2019 15:43:04 -0700
Subject: PkiPath with openssl
In-Reply-To: <trinity-0f8c416d-a62b-465a-8ef0-6349041e8d29-1560784168957@3c-app-gmx-bs19>
References: <trinity-0f8c416d-a62b-465a-8ef0-6349041e8d29-1560784168957@3c-app-gmx-bs19>
Message-ID: <BCCEA426-3102-458E-9D48-9305AD3130F2@omnigroup.com>


On Jun 17, 2019, at 8:09 AM, Tobias Wolf <wolf.tobias at gmx.net> wrote:
> there already a function available? In fact I?d like to provide a STACK(X509)* as a parameter and get the pem or der encoded asn1 structure back.

Assuming you've already assembled the list of certificates you want to encode, I think you can use the generic ASN.1 routines (see the docs in doc/man3/X509_dup.pod; I'm not sure why that's where they live) to define the encoded structure of the PkiPath; and use the ASN1_SEQUENCE_OF macro in that definition. See also the "asn1t.h" header.

I don't remember how to actually do this, but perhaps this will point you in a useful direction.



From lisa.matias at gmail.com  Tue Jun 18 04:19:41 2019
From: lisa.matias at gmail.com (Lisa Matias)
Date: Mon, 17 Jun 2019 21:19:41 -0700
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
Message-ID: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>

With OpenSSL version 1.1.1, my previously working code is now failing with
this error:

*error: dereferencing pointer to incomplete type ?X509_NAME_ENTRY {aka
struct X509_name_entry_st}?*


Basically, I am trying to do the following...

X509_NAME_ENTRY *nameEntry;
nameEntry = X509_NAME_ENTRY_create_by_NID (&nameEntry, nid,
                        derTagToVType (tag), buffer, bufferLength);
*nameEntry->value->flags = specifiedFlags;*


And the error occurs at the last line above only with this newer version of
OpenSSL 1.1.1 and not with any of the older versions I have been using for
many years.

Unfortunately, I do not see any function in the openssl include files such
as "*X509_NAME_ENTRY_set_flags*(...)" which are available to use instead.

Does anyone know if there any alternative generic method in OpenSSL 1.1.1
to set flags for a X509_NAME_ENTRY, which is independent of the ASN.1 type
of the X509_NAME_ENTRY?

Thanks.

Lisa.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190617/4f1311e5/attachment.html>

From shivakumar2696 at gmail.com  Tue Jun 18 04:56:25 2019
From: shivakumar2696 at gmail.com (shiva kumar)
Date: Tue, 18 Jun 2019 10:26:25 +0530
Subject: Make file removed in openssl 1.1.1
In-Reply-To: <694EF50E-9CFE-4044-8F2B-D2B4A0DD8248@akamai.com>
References: <CAN9sONeBNV69uO6tJ26+hh-YZLY9KbpHkMFAFJ433MkxvKR_Pw@mail.gmail.com>
 <3745c875-a8a9-aaff-3659-bdd8839e7c47@openssl.org>
 <694EF50E-9CFE-4044-8F2B-D2B4A0DD8248@akamai.com>
Message-ID: <CAN9sONdeGwCa47T4sNU9pBShxp0H72xR=_ebtOMDw2km4qDocQ@mail.gmail.com>

Actually I wanted to change the library dependencies from shared to archive
libraries as follows
*SHLIBDEPS='libcrypto.a'*  In Makefile which I was doing in 1.0.2 version,
How can I do this? in 1.1.1 version.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190618/b05af3fb/attachment.html>

From openssl-users at dukhovni.org  Tue Jun 18 05:36:49 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 18 Jun 2019 01:36:49 -0400
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
In-Reply-To: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
References: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
Message-ID: <20190618053649.GY84864@straasha.imrryr.org>

On Mon, Jun 17, 2019 at 09:19:41PM -0700, Lisa Matias wrote:

> X509_NAME_ENTRY *nameEntry;
> nameEntry = X509_NAME_ENTRY_create_by_NID (&nameEntry, nid,
>                         derTagToVType (tag), buffer, bufferLength);
> *nameEntry->value->flags = specifiedFlags;*

Can you be a bit more explicit about why you need to do this?
What flags do you intend to set and why?

That said, you can use:

    ASN1_STRING *X509_NAME_ENTRY_get_data(const X509_NAME_ENTRY *ne);

to get the ASN1_STRING holding the value, and since ASN1_STRINGs
are not opaque types, you can just use:

	value->flags = ...

asuming that's a sensible thing to do.  You may however be straying
into undocumented behaviour, and so it might be good to know whether
perhaps there's a better way of getting the result you actually want.

-- 
	Viktor.

From shivakumar2696 at gmail.com  Tue Jun 18 07:20:03 2019
From: shivakumar2696 at gmail.com (shiva kumar)
Date: Tue, 18 Jun 2019 12:50:03 +0530
Subject: Information on Build.info
Message-ID: <CAN9sONcgH5ZNNn61=Vmo=wwXfVL2hEkR3d4C1-Y80UPx1=qsRg@mail.gmail.com>

Hi,
Actually I wanted to know how build.info file in each directory such as
apps, engines etc, will used generate the Make file, what would happen If I
wanted to change the build.info file

1) in openssl/*apps/build.info <http://build.info>*
what would happen if I change
*DEPEND[openssl]=libapps.a ../libssl*
to
*DEPEND[openssl]=libapps.a ../libssl.a*

2)in openssl/*engines/build.info <http://build.info>*
what would hapen if I change
*  LIBS=../libcrypto*
  to
*  LIBS=../libcrypto.a*

*  DEPEND[padlock]=../libcrypto*
  to
  *DEPEND[padlock]=../libcrypto*

  *DEPEND[capi]=../libcrypto*
  to
  *DEPEND[capi]=../libcrypto.a*

  *DEPEND[afalg]=../libcrypto*
  to
  *DEPEND[afalg]=../libcrypto*

  * DEPEND[dasync]=../libcrypto*
   to
    *DEPEND[dasync]=../libcrypto*

    *DEPEND[ossltest]=../libcrypt*
   to
    *DEPEND[ossltest]=../libcrypt*

3) in *openssl/build.file*
    what would happen if I change
    *DEPEND[libssl]=libcrypto*
    to
   * DEPEND[libssl]=libcrypto.a*

please let me know

Thanks and Regards
Shivakumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190618/03b386b0/attachment-0001.html>

From xpahos at gmail.com  Tue Jun 18 09:13:24 2019
From: xpahos at gmail.com (Alexander Gryanko)
Date: Tue, 18 Jun 2019 12:13:24 +0300
Subject: Something like SSL_CTX_set_alpn_select_cb for ciphers and ssl/tls
 protocol version
Message-ID: <CALPhgfKy7Ga2wQT2LQ73_PujAZvx8bfWA+hoNZ06v2WR4MMN2w@mail.gmail.com>

Hello,

I'm looking for the way to do something like SSL_CTX_set_alpn_select_cb but
for ciphers and ssl/tls protocol version. As I see
ssl_choose_server_version and ssl3_choose_cipher has no any callbacks in
tls_early_post_process_client_hello. Is there any way to disable protocols
for some cases? Something like A/B testing with 50% of traffic with enabled
Chacha20 and 50% of traffic with disabled.

Thank you.

-- 
? ?????????,
????????? ??????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190618/886eb148/attachment.html>

From matt at openssl.org  Tue Jun 18 09:48:14 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 18 Jun 2019 10:48:14 +0100
Subject: Issues establising SSL connection after a wget command
In-Reply-To: <VI1PR05MB59177E15EB175C44659AE2C9F8EB0@VI1PR05MB5917.eurprd05.prod.outlook.com>
References: <VI1PR05MB59177E15EB175C44659AE2C9F8EB0@VI1PR05MB5917.eurprd05.prod.outlook.com>
Message-ID: <46bef5df-e0b9-67b6-4fbc-17d8932713d2@openssl.org>



On 17/06/2019 21:29, Eric Ntonfo wrote:
> 
> Hello,
> I am running an Ubuntu 12.04 TLS server and can't use wget to download software
> packages
> The command
> wget http://curl.haxx.se/download/curl-7.63.0.tar.bz2
> fails with the following error
> 
> --2019-06-17 22:10:11-- ?http://curl.haxx.se/download/curl-7.63.0.tar.bz2
> Resolving curl.haxx.se (curl.haxx.se)... 2a04:4e42:9::561, 151.101.38.49
> Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:80... connected.
> HTTP request sent, awaiting response... 301 Moved Permanently
> Location: https://curl.haxx.se/download/curl-7.63.0.tar.bz2 [following]
> --2019-06-17 22:10:11-- ?https://curl.haxx.se/download/curl-7.63.0.tar.bz2
> Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:443... connected.
> *OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
> protocol version*
> Unable to establish SSL connection.

You get this error when the client is offering a version of TLS that is too low
for the server. I just did some tests and it appears that this server will
refuse to connect with anything less than TLSv1.2.

That should be fine with both OpenSSL 1.0.1 and OpenSSL 1.0.2. Both of those
support TLSv1.2 and will offer it by default. However an application can
override the defaults. My suspicion is that your version of wget is old and, for
some reason, is overriding the default TLS version and requiring some earlier
version.

Upgrading wget might work.

Matt


> 
> I am unable to fix this issue. I have upgraded from openssl 1.0.1 on my Ubuntu
> box to openssl 1.0.2 having heard that this latest version fix the bug
> But still having it.
> 
> Can someone help please?
> Regards
> Eric

From matt at openssl.org  Tue Jun 18 10:04:26 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 18 Jun 2019 11:04:26 +0100
Subject: Something like SSL_CTX_set_alpn_select_cb for ciphers and ssl/tls
 protocol version
In-Reply-To: <CALPhgfKy7Ga2wQT2LQ73_PujAZvx8bfWA+hoNZ06v2WR4MMN2w@mail.gmail.com>
References: <CALPhgfKy7Ga2wQT2LQ73_PujAZvx8bfWA+hoNZ06v2WR4MMN2w@mail.gmail.com>
Message-ID: <1d247933-c138-9c8c-299d-869ec2d82218@openssl.org>



On 18/06/2019 10:13, Alexander Gryanko wrote:
> Hello,?
> 
> I'm looking for the way to do something like SSL_CTX_set_alpn_select_cb but for
> ciphers and ssl/tls protocol version. As I see ssl_choose_server_version and
> ssl3_choose_cipher has no any callbacks in tls_early_post_process_client_hello.
> Is there any way to disable protocols for some cases? Something like A/B testing
> with 50% of traffic with enabled Chacha20 and 50% of traffic with disabled.

If you are using OpenSSL 1.1.1 then probably you could do something with the
client hello callback:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_client_hello_cb.html

Matt


From lisa.matias at gmail.com  Tue Jun 18 14:16:46 2019
From: lisa.matias at gmail.com (Lisa Matias)
Date: Tue, 18 Jun 2019 07:16:46 -0700
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
In-Reply-To: <20190618053649.GY84864@straasha.imrryr.org>
References: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
 <20190618053649.GY84864@straasha.imrryr.org>
Message-ID: <CAEhRMxiR92vAWf+ti0GqX-=7eO9DcytfnYnS4=gxb8fPxf+JXw@mail.gmail.com>

If you look here:

https://www.openssl.org/docs/man1.1.0/man3/X509_NAME_ENTRY_get_data.html

It states:

*X509_NAME_ENTRY_get_data() retrieves the field value of ne in
and ASN1_STRING structure.*


Unfortunately this does not work for any non-string X.500 attributes such
as x500UniqueIdentifer which is defined as an ASN.1 BIT STRING.

I am only looking to fix in OpenSSL 1.1.1, what was previously working in
all older versions of OpenSSL all the way back to 0.9.7 which included a
way to support non-string attributes in X509_NAME_ENTRY.

Thanks.

Lisa.



On Mon, 17 Jun 2019 at 22:37, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Mon, Jun 17, 2019 at 09:19:41PM -0700, Lisa Matias wrote:
>
> > X509_NAME_ENTRY *nameEntry;
> > nameEntry = X509_NAME_ENTRY_create_by_NID (&nameEntry, nid,
> >                         derTagToVType (tag), buffer, bufferLength);
> > *nameEntry->value->flags = specifiedFlags;*
>
> Can you be a bit more explicit about why you need to do this?
> What flags do you intend to set and why?
>
> That said, you can use:
>
>     ASN1_STRING *X509_NAME_ENTRY_get_data(const X509_NAME_ENTRY *ne);
>
> to get the ASN1_STRING holding the value, and since ASN1_STRINGs
> are not opaque types, you can just use:
>
>         value->flags = ...
>
> asuming that's a sensible thing to do.  You may however be straying
> into undocumented behaviour, and so it might be good to know whether
> perhaps there's a better way of getting the result you actually want.
>
> --
>         Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190618/8f5aed86/attachment.html>

From eric_njedjou at hotmail.com  Tue Jun 18 14:51:52 2019
From: eric_njedjou at hotmail.com (Eric Ntonfo)
Date: Tue, 18 Jun 2019 14:51:52 +0000
Subject: Issues establising SSL connection after a wget command
In-Reply-To: <VI1PR05MB59177E15EB175C44659AE2C9F8EB0@VI1PR05MB5917.eurprd05.prod.outlook.com>
References: <VI1PR05MB59177E15EB175C44659AE2C9F8EB0@VI1PR05MB5917.eurprd05.prod.outlook.com>
Message-ID: <VI1PR05MB59173DAD81B4EA4ADA961D0AF8EA0@VI1PR05MB5917.eurprd05.prod.outlook.com>

Hello,
Please still looking forward to a suggestion of solution on my error:1407742E issue below
How can i fix this?
It's not only a matter of using wget. All commands that require to ocnnect to an SSL server are failing
Yhans a lot
Eric



On Mon, 2019-06-17 at 20:29 +0000, Eric Ntonfo wrote:

Hello,
I am running an Ubuntu 12.04 TLS server and can't use wget to download software packages
The command
wget http://curl.haxx.se/download/curl-7.63.0.tar.bz2
fails with the following error

--2019-06-17 22:10:11--  http://curl.haxx.se/download/curl-7.63.0.tar.bz2
Resolving curl.haxx.se (curl.haxx.se)... 2a04:4e42:9::561, 151.101.38.49
Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://curl.haxx.se/download/curl-7.63.0.tar.bz2 [following]
--2019-06-17 22:10:11--  https://curl.haxx.se/download/curl-7.63.0.tar.bz2
Connecting to curl.haxx.se (curl.haxx.se)|2a04:4e42:9::561|:443... connected.
OpenSSL: error:1407742E:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert protocol version
Unable to establish SSL connection.

I am unable to fix this issue. I have upgraded from openssl 1.0.1 on my Ubuntu box to openssl 1.0.2 having heard that this latest version fix the bug
But still having it.

Can someone help please?
Regards
Eric


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

From rsalz at akamai.com  Tue Jun 18 15:48:49 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 18 Jun 2019 15:48:49 +0000
Subject: Issues establising SSL connection after a wget command
In-Reply-To: <VI1PR05MB59173DAD81B4EA4ADA961D0AF8EA0@VI1PR05MB5917.eurprd05.prod.outlook.com>
References: <VI1PR05MB59177E15EB175C44659AE2C9F8EB0@VI1PR05MB5917.eurprd05.prod.outlook.com>
 <VI1PR05MB59173DAD81B4EA4ADA961D0AF8EA0@VI1PR05MB5917.eurprd05.prod.outlook.com>
Message-ID: <4F22B5DE-161F-46F9-9560-657B55345E69@akamai.com>

You posted on Monday about a problem, got one suggestion, and then you posted on Tuesday; not much patience. :)

My suggestion: use a current release, at least something in the 1.1.x line.

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

From wiml at omnigroup.com  Tue Jun 18 17:05:46 2019
From: wiml at omnigroup.com (Wim Lewis)
Date: Tue, 18 Jun 2019 10:05:46 -0700
Subject: PkiPath with openssl
In-Reply-To: <trinity-a6de8b96-933b-46be-82c8-90bbb0d68032-1560839705330@3c-app-gmx-bs08>
References: <trinity-0f8c416d-a62b-465a-8ef0-6349041e8d29-1560784168957@3c-app-gmx-bs19>
 <BCCEA426-3102-458E-9D48-9305AD3130F2@omnigroup.com>
 <trinity-a6de8b96-933b-46be-82c8-90bbb0d68032-1560839705330@3c-app-gmx-bs08>
Message-ID: <88BE272B-C520-4F97-A1BD-671C542A60AB@omnigroup.com>


On Jun 17, 2019, at 11:35 PM, Tobias Wolf <wolf.tobias at gmx.net> wrote:
> The specification said about sorting and providing the pki path in correct order. 

Ah, I thought you were asking about producing the correct DER representation, not assembling the list of certs.

In that case, take a look at the documentation for X509_verify_cert() and X509_STORE_add_cert() (also see X509_STORE_CTX_init(), X509_VERIFY_PARAM_*(), X509_STORE_CTX_get*_chain()). This will discover and validate a trust chain from a specified certificate to any of a set of trust anchors, via a set of possible intermediate certificates. The resulting chain should be ordered properly (you may need to reverse the order).  If you don't want to spend the extra time verifying signatures and constraints and so on, you might be able to turn that off by setting some options.

I think the X509_STORE_add_cert() manpage has the most comprehensible description of how these pieces fit together.



From openssl-users at dukhovni.org  Tue Jun 18 19:30:17 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 18 Jun 2019 15:30:17 -0400
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
In-Reply-To: <CAEhRMxiR92vAWf+ti0GqX-=7eO9DcytfnYnS4=gxb8fPxf+JXw@mail.gmail.com>
References: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
 <20190618053649.GY84864@straasha.imrryr.org>
 <CAEhRMxiR92vAWf+ti0GqX-=7eO9DcytfnYnS4=gxb8fPxf+JXw@mail.gmail.com>
Message-ID: <20190618193017.GC84864@straasha.imrryr.org>

On Tue, Jun 18, 2019 at 07:16:46AM -0700, Lisa Matias wrote:

> If you look here:
> 
> https://www.openssl.org/docs/man1.1.0/man3/X509_NAME_ENTRY_get_data.html
> 
> It states:
> 
> *X509_NAME_ENTRY_get_data() retrieves the field value of ne in
> and ASN1_STRING structure.*

Regardless of the entry type, the underlying value is always stored
as an ASN.1 string.

    struct X509_name_entry_st {
	ASN1_OBJECT *object;        /* AttributeType */
	ASN1_STRING *value;         /* AttributeValue */
	int set;                    /* index of RDNSequence for this entry */
	int size;                   /* temp variable */
    };

The flags you're looking for are associated with the ASN.1 string.
To indicate that it is a bit-string you set:

    value->flags |= ASN1_STRING_FLAG_BITS_LEFT | i

where "i" is the number of unused bits in the final octet.

> Unfortunately this does not work for any non-string X.500 attributes such
> as x500UniqueIdentifer which is defined as an ASN.1 BIT STRING.

Actually, it does.

-- 
	Viktor.

From lisa.matias at gmail.com  Tue Jun 18 21:27:30 2019
From: lisa.matias at gmail.com (Lisa Matias)
Date: Tue, 18 Jun 2019 14:27:30 -0700
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
In-Reply-To: <20190618193017.GC84864@straasha.imrryr.org>
References: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
 <20190618053649.GY84864@straasha.imrryr.org>
 <CAEhRMxiR92vAWf+ti0GqX-=7eO9DcytfnYnS4=gxb8fPxf+JXw@mail.gmail.com>
 <20190618193017.GC84864@straasha.imrryr.org>
Message-ID: <CAEhRMxh92ApHb4U1hrR5ynu43oM_=8y7gkGccpGAs8xsfrh=BA@mail.gmail.com>

Sorry, I was just frustrated that the changes to OpenSSL 1.1.1 broke code
which worked for nearly 15 years, by denying access to previously
accessible C structs.

I was able to use OpenSSL to generate a certificate with a subject
containing the x500UniqueIdentifier attribute as a pure ASN.1 BIT STRING,
as you can see with the following snippet from OpenSSL asn1parse.

  ___:d=5  hl=2 l=   3 prim: OBJECT            :x500UniqueIdentifier
  ___:d=5  hl=2 l=  16 prim: BIT STRING

Are you sure that the ASN.1 BIT STRING value is really stored as an ASN.1
STRING in a X500_NAME_ENTRY, when it is a binary value and not a text value?

Regardless, I did try this as you helpfully suggested:

(X509_NAME_ENTRY_get_data (nameEntry)->flags) |=
(ASN1_STRING_FLAG_BITS_LEFT | i);


And it seems to be working properly for x500UniqueIdentifer attribute,
without any errors I can find during compile or in the content of the
resulting certificates.

Thank you very much for your assistance.

Lisa.


On Tue, 18 Jun 2019 at 12:30, Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Tue, Jun 18, 2019 at 07:16:46AM -0700, Lisa Matias wrote:
>
> > If you look here:
> >
> > https://www.openssl.org/docs/man1.1.0/man3/X509_NAME_ENTRY_get_data.html
> >
> > It states:
> >
> > *X509_NAME_ENTRY_get_data() retrieves the field value of ne in
> > and ASN1_STRING structure.*
>
> Regardless of the entry type, the underlying value is always stored
> as an ASN.1 string.
>
>     struct X509_name_entry_st {
>         ASN1_OBJECT *object;        /* AttributeType */
>         ASN1_STRING *value;         /* AttributeValue */
>         int set;                    /* index of RDNSequence for this entry
> */
>         int size;                   /* temp variable */
>     };
>
> The flags you're looking for are associated with the ASN.1 string.
> To indicate that it is a bit-string you set:
>
>     value->flags |= ASN1_STRING_FLAG_BITS_LEFT | i
>
> where "i" is the number of unused bits in the final octet.
>
> > Unfortunately this does not work for any non-string X.500 attributes such
> > as x500UniqueIdentifer which is defined as an ASN.1 BIT STRING.
>
> Actually, it does.
>
> --
>         Viktor.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190618/e46e974b/attachment.html>

From openssl-users at dukhovni.org  Tue Jun 18 21:43:16 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 18 Jun 2019 17:43:16 -0400
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
In-Reply-To: <CAEhRMxh92ApHb4U1hrR5ynu43oM_=8y7gkGccpGAs8xsfrh=BA@mail.gmail.com>
References: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
 <20190618053649.GY84864@straasha.imrryr.org>
 <CAEhRMxiR92vAWf+ti0GqX-=7eO9DcytfnYnS4=gxb8fPxf+JXw@mail.gmail.com>
 <20190618193017.GC84864@straasha.imrryr.org>
 <CAEhRMxh92ApHb4U1hrR5ynu43oM_=8y7gkGccpGAs8xsfrh=BA@mail.gmail.com>
Message-ID: <20190618214315.GF84864@straasha.imrryr.org>

On Tue, Jun 18, 2019 at 02:27:30PM -0700, Lisa Matias wrote:

> Sorry, I was just frustrated that the changes to OpenSSL 1.1.1 broke code
> which worked for nearly 15 years, by denying access to previously
> accessible C structs.

Those changes are needed to make sure that future changes in the
internals DO NOT break your code.  The internal data layout would
ideally not have been exposed the first place, but my time-machine
is out of order...

> Are you sure that the ASN.1 BIT STRING value is really stored as an ASN.1
> STRING in a X500_NAME_ENTRY, when it is a binary value and not a text value?

Yes, it is stored as ASN.1 string, which is just a buffer with a length,
but also has:

    struct asn1_string_st {
	int length;
	int type;
	unsigned char *data;
	/*
	 * The value of the following field depends on the type being held.  It
	 * is mostly being used for BIT_STRING so if the input data has a
	 * non-zero 'unused bits' value, it will be handled correctly
	 */
	long flags;
    };

a type field (the NID for the associated OID) and flags as noted
in the comment.

> Regardless, I did try this as you helpfully suggested:
> 
> (X509_NAME_ENTRY_get_data (nameEntry)->flags) |=
> (ASN1_STRING_FLAG_BITS_LEFT | i);
> 
> And it seems to be working properly for x500UniqueIdentifer attribute,
> without any errors I can find during compile or in the content of the
> resulting certificates.
> 
> Thank you very much for your assistance.

You're welcome, that is the correct technique at present.  We should
perhaps provide getter/setter functions for the flags, or perhaps
even a specific function for indicating the value is a bitstring,
and how many bits it holds.  For now the ASN.1 string is not an
opaque structure.

-- 
	Viktor.

From uri at ll.mit.edu  Tue Jun 18 21:51:31 2019
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 18 Jun 2019 21:51:31 +0000
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
In-Reply-To: <20190618214315.GF84864@straasha.imrryr.org>
References: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
 <20190618053649.GY84864@straasha.imrryr.org>
 <CAEhRMxiR92vAWf+ti0GqX-=7eO9DcytfnYnS4=gxb8fPxf+JXw@mail.gmail.com>
 <20190618193017.GC84864@straasha.imrryr.org>
 <CAEhRMxh92ApHb4U1hrR5ynu43oM_=8y7gkGccpGAs8xsfrh=BA@mail.gmail.com>
 <20190618214315.GF84864@straasha.imrryr.org>
Message-ID: <7C16A7F8-2801-4A23-861D-CE53BAA7D1B0@ll.mit.edu>

On 6/18/19, 5:44 PM, "openssl-users on behalf of Viktor Dukhovni" <openssl-users-bounces at openssl.org on behalf of openssl-users at dukhovni.org> wrote:

    We should
    perhaps provide getter/setter functions for the flags, or perhaps
    even a specific function for indicating the value is a bitstring,
    and how many bits it holds.  For now the ASN.1 string is not an
    opaque structure.

Considering how OpenSSL design evolved, I suspect that the time may come when this string would become opaque. Therefore, I suggest that getter/setter functions should be added.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190618/5de3dd18/attachment-0001.bin>

From openssl-users at dukhovni.org  Wed Jun 19 01:11:39 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 18 Jun 2019 21:11:39 -0400
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
In-Reply-To: <7C16A7F8-2801-4A23-861D-CE53BAA7D1B0@ll.mit.edu>
References: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
 <20190618053649.GY84864@straasha.imrryr.org>
 <CAEhRMxiR92vAWf+ti0GqX-=7eO9DcytfnYnS4=gxb8fPxf+JXw@mail.gmail.com>
 <20190618193017.GC84864@straasha.imrryr.org>
 <CAEhRMxh92ApHb4U1hrR5ynu43oM_=8y7gkGccpGAs8xsfrh=BA@mail.gmail.com>
 <20190618214315.GF84864@straasha.imrryr.org>
 <7C16A7F8-2801-4A23-861D-CE53BAA7D1B0@ll.mit.edu>
Message-ID: <20190619011139.GH84864@straasha.imrryr.org>

On Tue, Jun 18, 2019 at 09:51:31PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:

> > We should perhaps provide getter/setter functions for the flags, or
> > perhaps even a specific function for indicating the value is a bitstring,
> > and how many bits it holds.  For now the ASN.1 string is not an opaque
> > structure.
> 
> Considering how OpenSSL design evolved, I suspect that the time may come
> when this string would become opaque. Therefore, I suggest that
> getter/setter functions should be added.

Any thoughts about the interface?  Some flag bits look internal,
and not necessarily ideal for applications to modify directly, so
while these might do:

    long ASN1_STRING_get_flags(ASN1_STRING *);
    void ASN1_STRING_set_flags(ASN1_STRING *, long);

Perhaps all that's needed is:

    int ASN1_BIT_STRING_set_unused(ASN1_STRING *, int);

which sets the unused bit count, checking that the ASN1_STRING type
is V_ASN1_BIT_STRING and the count is in the range [0,7].

-- 
	Viktor.


From uri at ll.mit.edu  Wed Jun 19 03:21:03 2019
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 19 Jun 2019 03:21:03 +0000
Subject: how to set flags in X509_NAME_ENTRY in OpenSSL 1.1.1
In-Reply-To: <20190619011139.GH84864@straasha.imrryr.org>
References: <CAEhRMxiSbydTvJJ9Aun7FJk5tnzaowrwW3Ed_rrs2GP6+BZ7ow@mail.gmail.com>
 <20190618053649.GY84864@straasha.imrryr.org>
 <CAEhRMxiR92vAWf+ti0GqX-=7eO9DcytfnYnS4=gxb8fPxf+JXw@mail.gmail.com>
 <20190618193017.GC84864@straasha.imrryr.org>
 <CAEhRMxh92ApHb4U1hrR5ynu43oM_=8y7gkGccpGAs8xsfrh=BA@mail.gmail.com>
 <20190618214315.GF84864@straasha.imrryr.org>
 <7C16A7F8-2801-4A23-861D-CE53BAA7D1B0@ll.mit.edu>
 <20190619011139.GH84864@straasha.imrryr.org>
Message-ID: <36C1B6F4-1DC4-4B54-8AF1-733F30EAE30E@ll.mit.edu>

    > > For now the ASN.1 string is not an opaque structure.
    > 
    > Considering how OpenSSL design evolved, I suspect that the time may come
    > when this string would become opaque. Therefore, I suggest that
    > getter/setter functions should be added.
    
    Any thoughts about the interface?

Alas, since I don't have any experience actually using these flags, I don't consider myself competent suggesting the API here.

    Some flag bits look internal, and not necessarily ideal for applications to modify directly, so
    while these might do:
    
        long ASN1_STRING_get_flags(ASN1_STRING *);
        void ASN1_STRING_set_flags(ASN1_STRING *, long);
    
This makes sense. Also, if there are flags that users are likely to need - perhaps explicit getter/setter calls for those individual flags? This would lower the likelihood of erroneously affecting unintended flags by a "ricochet"...

    Perhaps all that's needed is:
    
        int ASN1_BIT_STRING_set_unused(ASN1_STRING *, int);
    
    which sets the unused bit count, checking that the ASN1_STRING type
    is V_ASN1_BIT_STRING and the count is in the range [0,7].
    
That I don't know. I can't figure how or why I would use ..._set_unused()... But as I said, my competence in this particular thing is low.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5249 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/8d8e98ce/attachment.bin>

From shivakumar2696 at gmail.com  Wed Jun 19 10:07:33 2019
From: shivakumar2696 at gmail.com (shiva kumar)
Date: Wed, 19 Jun 2019 15:37:33 +0530
Subject: Make test error in OpenSSL 1.1.1b
Message-ID: <CAN9sONdGB3VPyVYhZ3Ae3mhSkdhjAr+Js7+08HL3+_xeEf3fBQ@mail.gmail.com>

Hi,
In the OpenSSL 1.1.1b build after make test I'm getting error as follows













*../test/recipes/70-test_comp.t                   (Wstat: 35584 Tests: 0
Failed: 0)  Non-zero exit status: 139  Parse errors: No plan found in TAP
output../test/recipes/70-test_key_share.t              (Wstat: 35584 Tests:
0 Failed: 0)  Non-zero exit status: 139  Parse errors: No plan found in TAP
output../test/recipes/70-test_renegotiation.t          (Wstat: 35584 Tests:
0 Failed: 0)  Non-zero exit status: 139  Parse errors: No plan found in TAP
output../test/recipes/70-test_sslcbcpadding.t          (Wstat: 35584 Tests:
4 Failed: 0)  Non-zero exit status: 139  Parse errors: Bad plan.  You
planned 5 tests but ran 4.../test/recipes/70-test_sslcertstatus.t
 (Wstat: 35584 Tests: 0 Failed: 0)  Non-zero exit status: 139*

can anyone please let me know why I'm getting this error ? what might have
caused this?.

Regards
Shiv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/98a97e1a/attachment.html>

From matt at openssl.org  Wed Jun 19 10:10:06 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 19 Jun 2019 11:10:06 +0100
Subject: Make test error in OpenSSL 1.1.1b
In-Reply-To: <CAN9sONdGB3VPyVYhZ3Ae3mhSkdhjAr+Js7+08HL3+_xeEf3fBQ@mail.gmail.com>
References: <CAN9sONdGB3VPyVYhZ3Ae3mhSkdhjAr+Js7+08HL3+_xeEf3fBQ@mail.gmail.com>
Message-ID: <9c7f011e-2265-413d-fe75-fc1e557a3840@openssl.org>



On 19/06/2019 11:07, shiva kumar wrote:
> Hi,
> In the OpenSSL 1.1.1b build after make test I'm getting error as follows
> /*../test/recipes/70-test_comp.t ? ? ? ? ? ? ? ? ? (Wstat: 35584 Tests: 0 Failed: 0)
> ? Non-zero exit status: 139
> ? Parse errors: No plan found in TAP output
> ../test/recipes/70-test_key_share.t ? ? ? ? ? ? ?(Wstat: 35584 Tests: 0 Failed: 0)
> ? Non-zero exit status: 139
> ? Parse errors: No plan found in TAP output
> ../test/recipes/70-test_renegotiation.t ? ? ? ? ?(Wstat: 35584 Tests: 0 Failed: 0)
> ? Non-zero exit status: 139
> ? Parse errors: No plan found in TAP output
> ../test/recipes/70-test_sslcbcpadding.t ? ? ? ? ?(Wstat: 35584 Tests: 4 Failed: 0)
> ? Non-zero exit status: 139
> ? Parse errors: Bad plan.? You planned 5 tests but ran 4.
> ../test/recipes/70-test_sslcertstatus.t ? ? ? ? ?(Wstat: 35584 Tests: 0 Failed: 0)
> ? Non-zero exit status: 139*/
> 
> can anyone please let me know why I'm getting this error ? what might have
> caused?this?.

Is it just the "70" series of tests that fail, or do others fail too?

What is your platform, and how did you configure OpenSSL?

Matt


From numamaheswari at pulsesecure.net  Wed Jun 19 12:00:28 2019
From: numamaheswari at pulsesecure.net (Umamaheswari Nagarajan)
Date: Wed, 19 Jun 2019 12:00:28 +0000
Subject: OpenSSL compilation in Windows
Message-ID: <BN8PR06MB5714205214C48C7455492E51ABE50@BN8PR06MB5714.namprd06.prod.outlook.com>

Hi,

We have a windows application which uses OpenSSL libraries(current version 1.0.2j). We will ship the libraries along with our application.

Currently we are trying to upgrade to OpenSSL 1.1.1c version.

We have been using the vc6 compiler for our application. But OpenSSL 1.1.1c is not compiling with vc6. However, with higher compiler version say (VC 9.0) we are able to compile it.

Our question - can we use the OpenSSL libraries compiled with higher version and keep using the vc6 compiler for our application.




Thanks and Regards,
Uma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/d8322a23/attachment-0001.html>

From hamed_gibago at yahoo.com  Wed Jun 19 12:22:12 2019
From: hamed_gibago at yahoo.com (DonCorleone)
Date: Wed, 19 Jun 2019 12:22:12 +0000 (UTC)
Subject: How to handle servername indication with openssl library from server
References: <1202706378.3652179.1560946932679.ref@mail.yahoo.com>
Message-ID: <1202706378.3652179.1560946932679@mail.yahoo.com>

I've develepted some windows server side socket in c
and want to add sni server name indication to support sni

but servername callback never called and cant get servername
is there any suggestion?

I've defined some functions for initializing ssl before main function:

??? void init_openssl()
??? {
?? ??? ?SSL_load_error_strings();
?? ??? ?OpenSSL_add_ssl_algorithms();
??? }
?? ?
??? SSL_CTX *create_context()
??? {
?? ??? ?const SSL_METHOD *method;
?? ??? ?SSL_CTX *ctx;
?? ?
?? ??? ?//method = SSLv23_server_method();
?? ??? ?method = TLSv1_1_server_method();
?? ?
?? ??? ?ctx = SSL_CTX_new(method);
?? ??? ?if (!ctx) {
?? ??? ??? ?perror("Unable to create SSL context");
?? ??? ??? ?ERR_print_errors_fp(stderr);
?? ??? ??? ?exit(EXIT_FAILURE);
?? ??? ?}
?? ?
?? ??? ?return ctx;
??? }
?? ?
??? void configure_context(SSL_CTX *ctx)
??? {
?? ??? ?
?? ??? ?SSL_CTX_set_ecdh_auto(ctx, 1);
?? ?
?? ??? ?/* Set the key and cert */
?? ??? ?if (SSL_CTX_use_certificate_file(ctx, "somesite.cer", SSL_FILETYPE_PEM) <= 0) {
?? ??? ??? ?ERR_print_errors_fp(stderr);
?? ?
?? ??? ??? ?exit(EXIT_FAILURE);
?? ??? ?}
?? ?
?? ??? ?if (SSL_CTX_use_PrivateKey_file(ctx, "key.pem", SSL_FILETYPE_PEM) <= 0) {
?? ??? ??? ?ERR_print_errors_fp(stderr);
?? ?
?? ??? ??? ?exit(EXIT_FAILURE);
?? ??? ?}
??? }
?? ?
??? static int ssl_servername_cb(SSL *ssl, int *ad, void *arg)
??? {
?? ??? ?if (ssl == NULL)
?? ??? ??? ?return SSL_TLSEXT_ERR_NOACK;
?? ?
?? ??? ?const char* servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);
?? ??? ?printf("ServerName: %s\n", servername);
??? }
?? ?

and here is my main function: 

??? int main()
??? {
?? ?
??? SSL_CTX *ctx;
?? ?
?? ??? ?init_openssl();
?? ??? ?ctx = create_context();
?? ?
?? ??? ?configure_context(ctx);
?? ??? ?
?? ??? ?SSL_CTX_set_tlsext_servername_callback(ctx, ssl_servername_cb);
?? ??? ?
?? ?
?? ?
?? ??? ?WSADATA wsaData;
?? ??? ?int iResult;
?? ?
?? ??? ?SOCKET ListenSocket = INVALID_SOCKET;
?? ??? ?SOCKET ClientSocket = INVALID_SOCKET;
?? ?
?? ??? ?struct addrinfo *result = NULL;
?? ??? ?struct addrinfo hints;
?? ?
?? ??? ?int iSendResult;
?? ??? ?char recvbuf[DEFAULT_BUFLEN];
?? ??? ?int recvbuflen = DEFAULT_BUFLEN;
?? ?
?? ??? ?// Initialize Winsock
?? ??? ?iResult = WSAStartup(MAKEWORD(2, 2), &wsaData);
?? ??? ?if (iResult != 0) {
?? ??? ??? ?printf("WSAStartup failed with error: %d\n", iResult);
?? ??? ??? ?return 1;
?? ??? ?}
?? ?
?? ??? ?ZeroMemory(&hints, sizeof(hints));
?? ??? ?hints.ai_family = AF_INET;
?? ??? ?hints.ai_socktype = SOCK_STREAM;
?? ??? ?hints.ai_protocol = IPPROTO_TCP;
?? ??? ?hints.ai_flags = AI_PASSIVE;
?? ?
?? ??? ?// Resolve the server address and port
?? ??? ?//iResult = getaddrinfo(NULL, DEFAULT_PORT, &hints, &result);
?? ??? ?iResult = getaddrinfo("192.168.200.1", DEFAULT_PORT, &hints, &result);
?? ??? ?//iResult = getaddrinfo("127.0.0.1", DEFAULT_PORT, &hints, &result);
?? ??? ?
?? ??? ?if (iResult != 0) {
?? ??? ??? ?printf("getaddrinfo failed with error: %d\n", iResult);
?? ??? ??? ?WSACleanup();
?? ??? ??? ?return 1;
?? ??? ?}
?? ?
?? ??? ?// Create a SOCKET for connecting to server?? ?
?? ??? ?ListenSocket = socket(result->ai_family, result->ai_socktype, result->ai_protocol);
?? ??? ?if (ListenSocket == INVALID_SOCKET) {
?? ??? ??? ?printf("socket failed with error: %ld\n", WSAGetLastError());
?? ??? ??? ?freeaddrinfo(result);
?? ??? ??? ?WSACleanup();
?? ??? ??? ?return 1;
?? ??? ?}
?? ?
?? ??? ?// Setup the TCP listening socket?? ?
?? ??? ?iResult = bind(ListenSocket, result->ai_addr, (int)result->ai_addrlen);
?? ??? ?if (iResult == SOCKET_ERROR) {
?? ??? ??? ?printf("bind failed with error: %d\n", WSAGetLastError());
?? ??? ??? ?freeaddrinfo(result);
?? ??? ??? ?closesocket(ListenSocket);
?? ??? ??? ?WSACleanup();
?? ??? ??? ?return 1;
?? ??? ?}
?? ?
?? ??? ?freeaddrinfo(result);
?? ?
?? ??? ?iResult = listen(ListenSocket, SOMAXCONN);
?? ??? ?if (iResult == SOCKET_ERROR) {
?? ??? ??? ?printf("listen failed with error: %d\n", WSAGetLastError());
?? ??? ??? ?closesocket(ListenSocket);
?? ??? ??? ?WSACleanup();
?? ??? ??? ?return 1;
?? ??? ?}
?? ?
?? ??? ?// Accept a client socket?? ??? ?
?? ??? ?ClientSocket = accept(ListenSocket, NULL, NULL);?? ?
?? ??? ?SSL *ssl;
?? ??? ?
?? ??? ?if (ClientSocket == INVALID_SOCKET) {
?? ??? ??? ?printf("accept failed with error: %d\n", WSAGetLastError());
?? ??? ??? ?closesocket(ListenSocket);
?? ??? ??? ?WSACleanup();
?? ??? ??? ?return 1;
?? ??? ?}
?? ?
?? ??? ?// No longer need server socket
?? ??? ?closesocket(ListenSocket);
?? ?
?? ??? ?// Receive until the peer shuts down the connection
?? ??? ?do {
?? ??? ??? ?
?? ??? ??? ?ssl = SSL_new(ctx);
?? ??? ??? ?SSL_set_fd(ssl, ListenSocket);
?? ??? ??? ?//int rr = SSL_accept(ssl);
?? ?
?? ??? ??? ?iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);
?? ??? ??? ?
?? ??? ??? ?//int type=SSL_get_servername_type(ssl);
?? ??? ??? ?//const char[] x=SSL_get_servername(ssl, type);
?? ??? ??? ?//const char *zx= SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);
?? ??? ??? ?
?? ??? ??? ?if (iResult > 0) {
?? ??? ??? ??? ?printf("Bytes received: %d\n", iResult);
?? ?
?? ??? ??? ??? ?// Echo the buffer back to the sender
?? ??? ??? ??? ?iSendResult = send(ClientSocket, recvbuf, iResult, 0);
?? ??? ??? ??? ?if (iSendResult == SOCKET_ERROR) {
?? ??? ??? ??? ??? ?printf("send failed with error: %d\n", WSAGetLastError());
?? ??? ??? ??? ??? ?closesocket(ClientSocket);
?? ??? ??? ??? ??? ?WSACleanup();
?? ??? ??? ??? ??? ?return 1;
?? ??? ??? ??? ?}
?? ??? ??? ??? ?printf("Bytes sent: %d\n", iSendResult);
?? ??? ??? ?}
?? ??? ??? ?else if (iResult == 0)
?? ??? ??? ??? ?printf("Connection closing...\n");
?? ??? ??? ?else {
?? ??? ??? ??? ?printf("recv failed with error: %d\n", WSAGetLastError());
?? ??? ??? ??? ?closesocket(ClientSocket);
?? ??? ??? ??? ?WSACleanup();
?? ??? ??? ??? ?return 1;
?? ??? ??? ?}
?? ?
?? ??? ?} while (iResult > 0);
?? ?
??? return 0;
??? }

In do while function I've tried to call 

??? const char* servername = SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name);
but didn't find anything.
I know that clienthello handshake is in first bytes that is received from socket.

??? iResult = recv(ClientSocket, recvbuf, recvbuflen, 0);

And I receive 219 bytes of data. I need to handle servername and find it, and load certificate file and do continuous job, and maybe after that keep going with higher level in c# sslstream class.
Any suggestion?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/6ea38764/attachment.html>

From darshanmody at avaya.com  Wed Jun 19 14:05:54 2019
From: darshanmody at avaya.com (Mody, Darshan Arvindkumar (Darshan))
Date: Wed, 19 Jun 2019 14:05:54 +0000
Subject: unknown message digest algorithm
Message-ID: <DM6PR15MB2906D19E48917E93312E64CEA7E50@DM6PR15MB2906.namprd15.prod.outlook.com>

Hi

We are facing issues with regards to SSL_Read operation.

We see the error "error:0D0C50A1:asn1 encoding routines:ASN1_item_verify: unknown message digest algorithm" during SSL read operation. Below are my queries


  1.  Is it possible to have such error during 'read operation' on Openssl
  2.  Where can this issue occur?

To my understanding this issue can occur when a far-end client tries to establish the connection with the server and has issue with his certificates (SHA-2 encryption on the certificates)

Thanks for your guidance.

Regards
Darshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/044b445a/attachment-0001.html>

From skip at taygeta.com  Wed Jun 19 15:06:31 2019
From: skip at taygeta.com (Skip Carter)
Date: Wed, 19 Jun 2019 08:06:31 -0700
Subject: How to handle servername indication with openssl library from
 server
In-Reply-To: <1202706378.3652179.1560946932679@mail.yahoo.com>
References: <1202706378.3652179.1560946932679.ref@mail.yahoo.com>
 <1202706378.3652179.1560946932679@mail.yahoo.com>
Message-ID: <1560956791.4729.1.camel@taygeta.com>

if this is a C++ program, be sure to use C linkage for the callback
e.g.


extern "C" {
> ? ? static int ssl_servername_cb(SSL *ssl, int *ad, void *arg)
> ??? {
> ?? ??? ?if (ssl == NULL)
> ?? ??? ??? ?return SSL_TLSEXT_ERR_NOACK;
> ?? ?
> ?? ??? ?const char* servername = SSL_get_servername(ssl,
> TLSEXT_NAMETYPE_host_name);
> ?? ??? ?printf("ServerName: %s\n", servername);
> ??? }

}

That is all I can think of.

--?
Dr Everett (Skip) Carter
skip at taygeta.com

Taygeta Scientific Inc
607 Charles Ave
Seaside CA 93955
831-641-0645 x103


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/78169f97/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/78169f97/attachment.sig>

From samiya.khanum at broadcom.com  Wed Jun 19 18:07:21 2019
From: samiya.khanum at broadcom.com (Samiya Khanum)
Date: Wed, 19 Jun 2019 23:37:21 +0530
Subject: openssl-1.1.1b: Compilation errors when use async and ct
Message-ID: <CADmX34obtmNHbTSbR3aaTwc37FFfWGUZ5nt4a=yaLRM+_whBNQ@mail.gmail.com>

Hi,

While compiling async I see below errors with UCLIBC.



*libcrypto.so: undefined reference to `getcontext'libcrypto.so: undefined
reference to `setcontext'libcrypto.so: undefined reference to `makecontext'*

As UCLIBC doesn't have support to these APIs, i have added no-async in
configure. With no-async below errors are seen.




*libcrypto.so: undefined reference to `ERR_load_ASYNC_strings'libcrypto.so:
undefined reference to `async_init'libcrypto.so: undefined reference to
`async_delete_thread_state'libcrypto.so: undefined reference to
`async_deinit'*

Do we need to have macro check" #ifndef OPENSSL_NO_ASYNC" before these api
calls?

Similarly for CT, we are seeing below errors. With no-ct options,
compilation is OK.

We would like to know what would be the impact if we disable async and ct
features. Could you please help us in understanding these features.

In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:17:0:
../../../../vendor/openssl/crypto/ct/ct_locl.h:58:5: error: unknown type
name 'sct_version_t'
     sct_version_t version;
     ^
../../../../vendor/openssl/crypto/ct/ct_locl.h:78:5: error: unknown type
name 'ct_log_entry_type_t'
     ct_log_entry_type_t entry_type;
     ^
../../../../vendor/openssl/crypto/ct/ct_locl.h:80:5: error: unknown type
name 'sct_source_t'
     sct_source_t source;
     ^
../../../../vendor/openssl/crypto/ct/ct_locl.h:82:5: error: unknown type
name 'sct_validation_status_t'
     sct_validation_status_t validation_status;
     ^
In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:14:0:
../../../../vendor/openssl/crypto/ct/ct_b64.c: In function
'ct_base64_decode':
../../../../vendor/openssl/crypto/ct/ct_b64.c:38:15: error:
'CT_F_CT_BASE64_DECODE' undeclared (first use in this function)
         CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
               ^
../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)        ERR_put_error(a,b,c,d,e)
                                                           ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:38:9: note: in expansion of
macro 'CTerr'
         CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
         ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:38:15: note: each undeclared
identifier is reported only once for each function it appears in
         CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
               ^
../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)        ERR_put_error(a,b,c,d,e)
                                                           ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:38:9: note: in expansion of
macro 'CTerr'
         CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
         ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:44:38: error:
'CT_R_BASE64_DECODE_ERROR' undeclared (first use in this function)
         CTerr(CT_F_CT_BASE64_DECODE, CT_R_BASE64_DECODE_ERROR);
                                      ^
../../../../vendor/openssl/include/openssl/err.h:29:61: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)        ERR_put_error(a,b,c,d,e)
                                                             ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:44:9: note: in expansion of
macro 'CTerr'
         CTerr(CT_F_CT_BASE64_DECODE, CT_R_BASE64_DECODE_ERROR);
         ^
../../../../vendor/openssl/crypto/ct/ct_b64.c: At top level:
../../../../vendor/openssl/crypto/ct/ct_b64.c:64:26: error: unknown type
name 'ct_log_entry_type_t'
                          ct_log_entry_type_t entry_type, uint64_t
timestamp,
                          ^
In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:14:0:
../../../../vendor/openssl/crypto/ct/ct_b64.c: In function
'CTLOG_new_from_base64':
../../../../vendor/openssl/crypto/ct/ct_b64.c:143:15: error:
'CT_F_CTLOG_NEW_FROM_BASE64' undeclared (first use in this function)
         CTerr(CT_F_CTLOG_NEW_FROM_BASE64, ERR_R_PASSED_INVALID_ARGUMENT);
               ^
../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)        ERR_put_error(a,b,c,d,e)
                                                           ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:143:9: note: in expansion of
macro 'CTerr'
         CTerr(CT_F_CTLOG_NEW_FROM_BASE64, ERR_R_PASSED_INVALID_ARGUMENT);
         ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:149:43: error:
'CT_R_LOG_CONF_INVALID_KEY' undeclared (first use in this function)
         CTerr(CT_F_CTLOG_NEW_FROM_BASE64, CT_R_LOG_CONF_INVALID_KEY);
                                           ^
../../../../vendor/openssl/include/openssl/err.h:29:61: note: in definition
of macro 'ERR_PUT_error'
 #  define ERR_PUT_error(a,b,c,d,e)        ERR_put_error(a,b,c,d,e)
                                                             ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:149:9: note: in expansion of
macro 'CTerr'
         CTerr(CT_F_CTLOG_NEW_FROM_BASE64, CT_R_LOG_CONF_INVALID_KEY);
         ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:161:15: warning: implicit
declaration of function 'CTLOG_new' [-Wimplicit-function-declaration]
     *ct_log = CTLOG_new(pkey, name);
               ^
../../../../vendor/openssl/crypto/ct/ct_b64.c:161:13: warning: assignment
makes pointer from integer without a cast [-Wint-conversion]
     *ct_log = CTLOG_new(pkey, name);
             ^


Thanks & Regards,
Samiya khanum
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/97097972/attachment.html>

From jeremy.farrell at oracle.com  Wed Jun 19 18:11:53 2019
From: jeremy.farrell at oracle.com (J. J. Farrell)
Date: Wed, 19 Jun 2019 19:11:53 +0100
Subject: Information on Build.info
In-Reply-To: <CAN9sONcgH5ZNNn61=Vmo=wwXfVL2hEkR3d4C1-Y80UPx1=qsRg@mail.gmail.com>
References: <CAN9sONcgH5ZNNn61=Vmo=wwXfVL2hEkR3d4C1-Y80UPx1=qsRg@mail.gmail.com>
Message-ID: <5fea9af7-b9c2-ec35-5bb0-eae8acc4f07b@oracle.com>

Have you tried it? It's the simplest way to find out what would happen, 
though it's a very strange thing to do. It's almost certainly not the 
best way to do whatever you're trying to do.

If you take a step back and tell us what you are trying to achieve 
overall you'll be more likely to get useful advice. What do you want to 
end up with when you do the build? How is what you want different from 
what you get when you do a build without any modifications?

On 18/06/2019 08:20, shiva kumar wrote:
> Hi,
> Actually I wanted to know how build.info <http://build.info> file in 
> each directory such as apps, engines etc, will used generate the Make 
> file, what would happen If I wanted to change the build.info 
> <http://build.info> file
>
> 1) in openssl/*apps/build.info <http://build.info>*
> what would happen if I change
> *DEPEND[openssl]=libapps.a ../libssl*
> to
> *DEPEND[openssl]=libapps.a ../libssl.a*
>
> 2)in openssl/*engines/build.info <http://build.info>*
> what would hapen if I change
> *? LIBS=../libcrypto*
> ? to
> *? LIBS=../libcrypto.a*
> *
> *
> *??DEPEND[padlock]=../libcrypto*
> ? to
> *DEPEND[padlock]=../libcrypto*
>
> *DEPEND[capi]=../libcrypto*
> ? to
> *DEPEND[capi]=../libcrypto.a*
>
> *DEPEND[afalg]=../libcrypto*
> ? to
> *DEPEND[afalg]=../libcrypto*
>
> *?DEPEND[dasync]=../libcrypto*
> ? ?to
> *DEPEND[dasync]=../libcrypto*
>
> *DEPEND[ossltest]=../libcrypt*
> ? ?to
> *DEPEND[ossltest]=../libcrypt*
>
> 3) in *openssl/build.file*
> ? ? what would happen if I change
> *DEPEND[libssl]=libcrypto*
> ? ? to
> *?DEPEND[libssl]=libcrypto.a*
>
> please let me know
>
> Thanks and Regards
> Shivakumar

-- 
J. J. Farrell
Not speaking for Oracle

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190619/6f056b33/attachment-0001.html>

From levitte at openssl.org  Wed Jun 19 20:28:55 2019
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 19 Jun 2019 22:28:55 +0200
Subject: Information on Build.info
In-Reply-To: <5fea9af7-b9c2-ec35-5bb0-eae8acc4f07b@oracle.com>
References: <CAN9sONcgH5ZNNn61=Vmo=wwXfVL2hEkR3d4C1-Y80UPx1=qsRg@mail.gmail.com>
 <5fea9af7-b9c2-ec35-5bb0-eae8acc4f07b@oracle.com>
Message-ID: <68F3F9E5-4B4A-4F99-9316-A783D2AB2688@openssl.org>

A very simple answer would be to have 'no-shared' as a configuration option.
That does mean that no shared libraries will be built, and that might not be satisfactory.

Any, for the question "what would happen?" is that any program or module that get this change will be linked with the static library instead of the shared one, unconditionally.

Cheers
Richard


"J. J. Farrell" <jeremy.farrell at oracle.com> skrev: (19 juni 2019 20:11:53 CEST)
>Have you tried it? It's the simplest way to find out what would happen,
>
>though it's a very strange thing to do. It's almost certainly not the 
>best way to do whatever you're trying to do.
>
>If you take a step back and tell us what you are trying to achieve 
>overall you'll be more likely to get useful advice. What do you want to
>
>end up with when you do the build? How is what you want different from 
>what you get when you do a build without any modifications?
>
>On 18/06/2019 08:20, shiva kumar wrote:
>> Hi,
>> Actually I wanted to know how build.info <http://build.info> file in 
>> each directory such as apps, engines etc, will used generate the Make
>
>> file, what would happen If I wanted to change the build.info 
>> <http://build.info> file
>>
>> 1) in openssl/*apps/build.info <http://build.info>*
>> what would happen if I change
>> *DEPEND[openssl]=libapps.a ../libssl*
>> to
>> *DEPEND[openssl]=libapps.a ../libssl.a*
>>
>> 2)in openssl/*engines/build.info <http://build.info>*
>> what would hapen if I change
>> *? LIBS=../libcrypto*
>> ? to
>> *? LIBS=../libcrypto.a*
>> *
>> *
>> *??DEPEND[padlock]=../libcrypto*
>> ? to
>> *DEPEND[padlock]=../libcrypto*
>>
>> *DEPEND[capi]=../libcrypto*
>> ? to
>> *DEPEND[capi]=../libcrypto.a*
>>
>> *DEPEND[afalg]=../libcrypto*
>> ? to
>> *DEPEND[afalg]=../libcrypto*
>>
>> *?DEPEND[dasync]=../libcrypto*
>> ? ?to
>> *DEPEND[dasync]=../libcrypto*
>>
>> *DEPEND[ossltest]=../libcrypt*
>> ? ?to
>> *DEPEND[ossltest]=../libcrypt*
>>
>> 3) in *openssl/build.file*
>> ? ? what would happen if I change
>> *DEPEND[libssl]=libcrypto*
>> ? ? to
>> *?DEPEND[libssl]=libcrypto.a*
>>
>> please let me know
>>
>> Thanks and Regards
>> Shivakumar

-- 
Skickat fr?n min Android-enhet med K-9 Mail. Urs?kta min f?ordighet.

From matt at openssl.org  Thu Jun 20 08:30:46 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 20 Jun 2019 09:30:46 +0100
Subject: openssl-1.1.1b: Compilation errors when use async and ct
In-Reply-To: <CADmX34obtmNHbTSbR3aaTwc37FFfWGUZ5nt4a=yaLRM+_whBNQ@mail.gmail.com>
References: <CADmX34obtmNHbTSbR3aaTwc37FFfWGUZ5nt4a=yaLRM+_whBNQ@mail.gmail.com>
Message-ID: <32f96191-638d-f4cf-1e41-74f3572b849b@openssl.org>



On 19/06/2019 19:07, Samiya Khanum via openssl-users wrote:
> Hi,
> 
> While compiling async I see below errors with UCLIBC.
> 
> /libcrypto.so: undefined reference to `getcontext'
> libcrypto.so: undefined reference to `setcontext'
> libcrypto.so: undefined reference to `makecontext'/
> 
> As UCLIBC doesn't have support to these APIs, i have added no-async in
> configure. With no-async below errors are seen.
> /
> /
> /libcrypto.so: undefined reference to `ERR_load_ASYNC_strings'
> libcrypto.so: undefined reference to `async_init'
> libcrypto.so: undefined reference to `async_delete_thread_state'
> libcrypto.so: undefined reference to `async_deinit'/

no-async actually still compiles the high level async code, but you get the
"null" implementation which doesn't do anything.

The only thing I can suggest is to try "make clean" and start again.

Matt


> /
> /
> Do we need to have macro check" #ifndef OPENSSL_NO_ASYNC" before these api calls?
> 
> Similarly for CT, we are seeing below errors. With no-ct options, compilation is OK.
> 
> We would like to know what would be the impact if we disable async and ct
> features. Could you please help us in understanding these features.
> 
> In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:17:0:
> ../../../../vendor/openssl/crypto/ct/ct_locl.h:58:5: error: unknown type name
> 'sct_version_t'
> ? ? ?sct_version_t version;
> ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_locl.h:78:5: error: unknown type name
> 'ct_log_entry_type_t'
> ? ? ?ct_log_entry_type_t entry_type;
> ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_locl.h:80:5: error: unknown type name
> 'sct_source_t'
> ? ? ?sct_source_t source;
> ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_locl.h:82:5: error: unknown type name
> 'sct_validation_status_t'
> ? ? ?sct_validation_status_t validation_status;
> ? ? ?^
> In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:14:0:
> ../../../../vendor/openssl/crypto/ct/ct_b64.c: In function 'ct_base64_decode':
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:38:15: error:
> 'CT_F_CT_BASE64_DECODE' undeclared (first use in this function)
> ? ? ? ? ?CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
> ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition of
> macro 'ERR_PUT_error'
> ?# ?define ERR_PUT_error(a,b,c,d,e) ? ? ? ?ERR_put_error(a,b,c,d,e)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:38:9: note: in expansion of macro
> 'CTerr'
> ? ? ? ? ?CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
> ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:38:15: note: each undeclared
> identifier is reported only once for each function it appears in
> ? ? ? ? ?CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
> ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition of
> macro 'ERR_PUT_error'
> ?# ?define ERR_PUT_error(a,b,c,d,e) ? ? ? ?ERR_put_error(a,b,c,d,e)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:38:9: note: in expansion of macro
> 'CTerr'
> ? ? ? ? ?CTerr(CT_F_CT_BASE64_DECODE, ERR_R_MALLOC_FAILURE);
> ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:44:38: error:
> 'CT_R_BASE64_DECODE_ERROR' undeclared (first use in this function)
> ? ? ? ? ?CTerr(CT_F_CT_BASE64_DECODE, CT_R_BASE64_DECODE_ERROR);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ^
> ../../../../vendor/openssl/include/openssl/err.h:29:61: note: in definition of
> macro 'ERR_PUT_error'
> ?# ?define ERR_PUT_error(a,b,c,d,e) ? ? ? ?ERR_put_error(a,b,c,d,e)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:44:9: note: in expansion of macro
> 'CTerr'
> ? ? ? ? ?CTerr(CT_F_CT_BASE64_DECODE, CT_R_BASE64_DECODE_ERROR);
> ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c: At top level:
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:64:26: error: unknown type name
> 'ct_log_entry_type_t'
> ? ? ? ? ? ? ? ? ? ? ? ? ? ct_log_entry_type_t entry_type, uint64_t timestamp,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ^
> In file included from ../../../../vendor/openssl/crypto/ct/ct_b64.c:14:0:
> ../../../../vendor/openssl/crypto/ct/ct_b64.c: In function 'CTLOG_new_from_base64':
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:143:15: error:
> 'CT_F_CTLOG_NEW_FROM_BASE64' undeclared (first use in this function)
> ? ? ? ? ?CTerr(CT_F_CTLOG_NEW_FROM_BASE64, ERR_R_PASSED_INVALID_ARGUMENT);
> ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/include/openssl/err.h:29:59: note: in definition of
> macro 'ERR_PUT_error'
> ?# ?define ERR_PUT_error(a,b,c,d,e) ? ? ? ?ERR_put_error(a,b,c,d,e)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:143:9: note: in expansion of macro
> 'CTerr'
> ? ? ? ? ?CTerr(CT_F_CTLOG_NEW_FROM_BASE64, ERR_R_PASSED_INVALID_ARGUMENT);
> ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:149:43: error:
> 'CT_R_LOG_CONF_INVALID_KEY' undeclared (first use in this function)
> ? ? ? ? ?CTerr(CT_F_CTLOG_NEW_FROM_BASE64, CT_R_LOG_CONF_INVALID_KEY);
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/include/openssl/err.h:29:61: note: in definition of
> macro 'ERR_PUT_error'
> ?# ?define ERR_PUT_error(a,b,c,d,e) ? ? ? ?ERR_put_error(a,b,c,d,e)
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:149:9: note: in expansion of macro
> 'CTerr'
> ? ? ? ? ?CTerr(CT_F_CTLOG_NEW_FROM_BASE64, CT_R_LOG_CONF_INVALID_KEY);
> ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:161:15: warning: implicit
> declaration of function 'CTLOG_new' [-Wimplicit-function-declaration]
> ? ? ?*ct_log = CTLOG_new(pkey, name);
> ? ? ? ? ? ? ? ?^
> ../../../../vendor/openssl/crypto/ct/ct_b64.c:161:13: warning: assignment makes
> pointer from integer without a cast [-Wint-conversion]
> ? ? ?*ct_log = CTLOG_new(pkey, name);
> ? ? ? ? ? ? ?^
> 
> 
> Thanks & Regards,
> Samiya khanum

From matt at openssl.org  Thu Jun 20 11:56:29 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 20 Jun 2019 12:56:29 +0100
Subject: Make test error in OpenSSL 1.1.1b
In-Reply-To: <CAN9sONcUOehth8UXQNsK-fNhCK9h4RT=5+r8gn6zmDmEiPAngg@mail.gmail.com>
References: <CAN9sONdGB3VPyVYhZ3Ae3mhSkdhjAr+Js7+08HL3+_xeEf3fBQ@mail.gmail.com>
 <9c7f011e-2265-413d-fe75-fc1e557a3840@openssl.org>
 <CAN9sONcUOehth8UXQNsK-fNhCK9h4RT=5+r8gn6zmDmEiPAngg@mail.gmail.com>
Message-ID: <5bbf0ce5-1e50-b11e-8f25-50f01c8c65e6@openssl.org>



On 20/06/2019 12:47, shiva kumar wrote:
> yes it's just? "70" series of tests.
> 
> I'm using HP-UX IA64 platform,?
> I configured normally? that I used to do ( shared, no-rc5, no-idea, no-mdc2,
> options used). but, after make file generation?
> I changed "-lcrypto" to "libcrypto.a", to link archive files instead of shared
> files.
> and then make executed normally
> but when I run make test I'm getting this?error.
> why I'm getting this error ?

If you want static linking why not just build with "no-shared"?

If you don't modify the Makefile does it work?

Matt


> 
> 
> On Wed, Jun 19, 2019 at 3:40 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 19/06/2019 11:07, shiva kumar wrote:
>     > Hi,
>     > In the OpenSSL 1.1.1b build after make test I'm getting error as follows
>     > /*../test/recipes/70-test_comp.t ? ? ? ? ? ? ? ? ? (Wstat: 35584 Tests: 0
>     Failed: 0)
>     > ? Non-zero exit status: 139
>     > ? Parse errors: No plan found in TAP output
>     > ../test/recipes/70-test_key_share.t ? ? ? ? ? ? ?(Wstat: 35584 Tests: 0
>     Failed: 0)
>     > ? Non-zero exit status: 139
>     > ? Parse errors: No plan found in TAP output
>     > ../test/recipes/70-test_renegotiation.t ? ? ? ? ?(Wstat: 35584 Tests: 0
>     Failed: 0)
>     > ? Non-zero exit status: 139
>     > ? Parse errors: No plan found in TAP output
>     > ../test/recipes/70-test_sslcbcpadding.t ? ? ? ? ?(Wstat: 35584 Tests: 4
>     Failed: 0)
>     > ? Non-zero exit status: 139
>     > ? Parse errors: Bad plan.? You planned 5 tests but ran 4.
>     > ../test/recipes/70-test_sslcertstatus.t ? ? ? ? ?(Wstat: 35584 Tests: 0
>     Failed: 0)
>     > ? Non-zero exit status: 139*/
>     >
>     > can anyone please let me know why I'm getting this error ? what might have
>     > caused?this?.
> 
>     Is it just the "70" series of tests that fail, or do others fail too?
> 
>     What is your platform, and how did you configure OpenSSL?
> 
>     Matt
> 
> 
> 
> -- 
> *With Best Regards*
> *Shivakumar S*

From matt at openssl.org  Thu Jun 20 12:04:47 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 20 Jun 2019 13:04:47 +0100
Subject: Make test error in OpenSSL 1.1.1b
In-Reply-To: <CAN9sONexqUb2RZ1A2tYLF1HrOb_NrGGCgU3YF8NVVdxV1p4iTw@mail.gmail.com>
References: <CAN9sONdGB3VPyVYhZ3Ae3mhSkdhjAr+Js7+08HL3+_xeEf3fBQ@mail.gmail.com>
 <9c7f011e-2265-413d-fe75-fc1e557a3840@openssl.org>
 <CAN9sONcUOehth8UXQNsK-fNhCK9h4RT=5+r8gn6zmDmEiPAngg@mail.gmail.com>
 <5bbf0ce5-1e50-b11e-8f25-50f01c8c65e6@openssl.org>
 <CAN9sONexqUb2RZ1A2tYLF1HrOb_NrGGCgU3YF8NVVdxV1p4iTw@mail.gmail.com>
Message-ID: <6263b268-ca84-8a31-bae1-d99cf514ebf3@openssl.org>



On 20/06/2019 12:59, shiva kumar wrote:
> If I don't modify it will work.
> But when I do the same modification in 1.0.2 versions it was working.
> May I know why this was working in 1.0.2 version
> 

(Please respond to the list not just to me - others may be able to help if I cannot)

1.0.2 and 1.1.1 are quite different in a lot of ways. The build system is very
different, so its likely that your changes are having unintended consequences.
Additionally there are many more tests in 1.1.1 compared to 1.0.2. None of the
"70" series of tests existed at all in 1.0.2.

Why are you trying to make changes? Why doesn't "no-shared" suffice?

Matt

> On Thu, 20 Jun 2019 at 5:26 PM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 20/06/2019 12:47, shiva kumar wrote:
>     > yes it's just? "70" series of tests.
>     >
>     > I'm using HP-UX IA64 platform,?
>     > I configured normally? that I used to do ( shared, no-rc5, no-idea, no-mdc2,
>     > options used). but, after make file generation?
>     > I changed "-lcrypto" to "libcrypto.a", to link archive files instead of shared
>     > files.
>     > and then make executed normally
>     > but when I run make test I'm getting this?error.
>     > why I'm getting this error ?
> 
>     If you want static linking why not just build with "no-shared"?
> 
>     If you don't modify the Makefile does it work?
> 
>     Matt
> 
> 
>     >
>     >
>     > On Wed, Jun 19, 2019 at 3:40 PM Matt Caswell <matt at openssl.org
>     <mailto:matt at openssl.org>
>     > <mailto:matt at openssl.org <mailto:matt at openssl.org>>> wrote:
>     >
>     >
>     >
>     >? ? ?On 19/06/2019 11:07, shiva kumar wrote:
>     >? ? ?> Hi,
>     >? ? ?> In the OpenSSL 1.1.1b build after make test I'm getting error as follows
>     >? ? ?> /*../test/recipes/70-test_comp.t ? ? ? ? ? ? ? ? ? (Wstat: 35584
>     Tests: 0
>     >? ? ?Failed: 0)
>     >? ? ?> ? Non-zero exit status: 139
>     >? ? ?> ? Parse errors: No plan found in TAP output
>     >? ? ?> ../test/recipes/70-test_key_share.t ? ? ? ? ? ? ?(Wstat: 35584 Tests: 0
>     >? ? ?Failed: 0)
>     >? ? ?> ? Non-zero exit status: 139
>     >? ? ?> ? Parse errors: No plan found in TAP output
>     >? ? ?> ../test/recipes/70-test_renegotiation.t ? ? ? ? ?(Wstat: 35584 Tests: 0
>     >? ? ?Failed: 0)
>     >? ? ?> ? Non-zero exit status: 139
>     >? ? ?> ? Parse errors: No plan found in TAP output
>     >? ? ?> ../test/recipes/70-test_sslcbcpadding.t ? ? ? ? ?(Wstat: 35584 Tests: 4
>     >? ? ?Failed: 0)
>     >? ? ?> ? Non-zero exit status: 139
>     >? ? ?> ? Parse errors: Bad plan.? You planned 5 tests but ran 4.
>     >? ? ?> ../test/recipes/70-test_sslcertstatus.t ? ? ? ? ?(Wstat: 35584 Tests: 0
>     >? ? ?Failed: 0)
>     >? ? ?> ? Non-zero exit status: 139*/
>     >? ? ?>
>     >? ? ?> can anyone please let me know why I'm getting this error ? what
>     might have
>     >? ? ?> caused?this?.
>     >
>     >? ? ?Is it just the "70" series of tests that fail, or do others fail too?
>     >
>     >? ? ?What is your platform, and how did you configure OpenSSL?
>     >
>     >? ? ?Matt
>     >
>     >
>     >
>     > --
>     > *With Best Regards*
>     > *Shivakumar S*
> 
> -- 
> *With Best Regards*
> *Shivakumar S*

From darshanmody at avaya.com  Thu Jun 20 17:29:41 2019
From: darshanmody at avaya.com (Mody, Darshan Arvindkumar (Darshan))
Date: Thu, 20 Jun 2019 17:29:41 +0000
Subject: unknown message digest algorithm
In-Reply-To: <DM6PR15MB2906D19E48917E93312E64CEA7E50@DM6PR15MB2906.namprd15.prod.outlook.com>
References: <DM6PR15MB2906D19E48917E93312E64CEA7E50@DM6PR15MB2906.namprd15.prod.outlook.com>
Message-ID: <DM6PR15MB290630920AADBC8BFD806FE0A7E40@DM6PR15MB2906.namprd15.prod.outlook.com>

Hi

The openssl version is 1.0.2

Thanks and Regards
Darshan

From: Mody, Darshan Arvindkumar (Darshan)
Sent: Wednesday, 19 June, 19:49
Subject: unknown message digest algorithm
To: 'openssl-users at openssl.org', openssl-dev at openssl.org
Cc: Mahajan, Hrishikesh Ulhas (Hrishikesh), Phadnis, Mohan Vinayak (Mohan)


Hi

We are facing issues with regards to SSL_Read operation.

We see the error ?error:0D0C50A1:asn1 encoding routines:ASN1_item_verify: unknown message digest algorithm? during SSL read operation. Below are my queries

Is it possible to have such error during ?read operation? on OpensslWhere can this issue occur?

To my understanding this issue can occur when a far-end client tries to establish the connection with the server and has issue with his certificates (SHA-2 encryption on the certificates)

Thanks for your guidance.

Regards
Darshan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190620/386413d9/attachment-0001.html>

From rsalz at akamai.com  Fri Jun 21 13:37:20 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 21 Jun 2019 13:37:20 +0000
Subject: Proposal to remove some platforms
Message-ID: <31A285CA-F212-4304-BAF9-5ACD6C0EC387@akamai.com>

I created a handful of PR?s to remove support for some platforms.  The project would like to hear from people about this.  The pull requests are as follows:

Remove HP PARISC support https://github.com/openssl/openssl/pull/9210
Remove HP/MPE and Tru64 Unix support https://github.com/openssl/openssl/pull/9209
Remove VOS support https://github.com/openssl/openssl/pull/9208
Remove NextStep support https://github.com/openssl/openssl/pull/9204
Remove BS2000/OSD support https://github.com/openssl/openssl/pull/9185

PLEASE review the comments before posting, as most of these have issues beyond just removing config stanza?s.

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

From rsalz at akamai.com  Sun Jun 23 16:36:16 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 23 Jun 2019 16:36:16 +0000
Subject: Proposal to remove some platforms
In-Reply-To: <18F277FD-A36A-4157-A89A-7CC4860D4D5D@zoulas.com>
References: <31A285CA-F212-4304-BAF9-5ACD6C0EC387@akamai.com>
 <18F277FD-A36A-4157-A89A-7CC4860D4D5D@zoulas.com>
Message-ID: <7D661F3C-D282-4EE5-AC37-8D789D0EC936@akamai.com>

>Yes NetBSD cares about PARISC... We still build and run on it.

Thanks.  The targets removed in that PR were for hpux-parisc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190623/437ffcba/attachment.html>

From vieuxtech at gmail.com  Mon Jun 24 21:34:14 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Mon, 24 Jun 2019 14:34:14 -0700
Subject: any subtleties about OCSP in TLS1.3 with ecdh curves?
Message-ID: <CA+Sj9TmS-zM2EF2cVbB_Ed0Y+nmMGknz+5jEd-j0Mc9dskXgbg@mail.gmail.com>

Node.js has a bug report and repro of ocsp status not being sent from
a node server to the openssl CLI when TLS1.3 is being used, but only
when server is setting an ecdh curve, with SSL_CTX_set1_curves_list()

repro is https://github.com/sam-github/node-ocsp-bug-repro

TLS trace of success is
https://github.com/sam-github/node-ocsp-bug-repro/blob/master/ok.txt,
and of failure is
https://github.com/sam-github/node-ocsp-bug-repro/blob/master/notok.txt

I hacked up node a bit, and it does look like in both cases the same
API interactions between node and openssl are ocurring, at least with
respect to the cb from SSL_set_cert_cb() is happening, after which
time we save some data, and then we call
SSL_set_tlsext_status_ocsp_resp() with that data.

AFAICT, with SSL_CTX_set1_curves_list() called, the ocsp data never
shows up in the server response.

I'm not sure what to look at next, does anybody have ideas?


Thanks,
Sam

From mcr at sandelman.ca  Tue Jun 25 14:38:50 2019
From: mcr at sandelman.ca (Michael Richardson)
Date: Tue, 25 Jun 2019 10:38:50 -0400
Subject: ECDSA curves and certificates in 1.0.2X vs 1.1.x
Message-ID: <12238.1561473530@localhost>

The CIRALabs SecureHomeGateway generates an ECDSA key/CSR at manufacturing
time which is enrolled into a CA to form an IDevID certificate.

We are pondering a regression where the generated key goes clearly
prime256v1, and "prime-field".  We are generating with

openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
                -nodes -subj "/CN=${ULA_HOSTNAME}" \
                -keyout ${KEY_NAME}.key -out ${KEY_NAME}.csr -outform DER \
                -reqexts SAN \
                -config /tmp/shg.ossl.cnf

Evidence below, and also at: https://gist.github.com/mcr/089fe7206644f417ba213c9dfe093c7a

I thought that maybe we had a build-regression that meant that we went from
1.1.x back to 1.0.x (this is with nic.cz's build of openwrt 18.06), but so
far this does not appear to be the case.   But... it worked before!  I swear.
(so I didn't think about the version that there)

***
  My question is: is there some build options that I can't see that might have
  affected this?  Made it work before.  My impression is that 1.0.x did *not*
  support ECDSA certificates, yet it seemed to generate CSRs, just does not put in the
  right OIDs in the public parts such that it is recognized by others.
***

We happen to include 1.1.1 in a container, and I will probably change things
to use the openssl inside the container to generate the CSR, but I'm rather confused.


1.1.1:
root at turris:/etc/shg# openssl ec -noout -text -in shg.key
read EC key
Private-Key: (256 bit)
priv:
    stuff
pub:
    04:0c:d5:2f:3b:ed:17:ae:dc:50:57:23:60:10:1e:
    e3:61:84:3b:f4:ad:dd:0d:f4:cd:b4:81:f9:45:4c:
    ee:aa:c6:d3:1a:0c:db:5d:4a:ad:fe:26:d7:c9:a8:
    a2:3c:b6:97:4e:f0:bc:10:37:a2:cc:7b:9a:e6:40:
    ea:c3:1d:d9:52
ASN1 OID: prime256v1
NIST CURVE: P-256

With an openssl 1.0.2s or 1.0.2l:

OpenSSL 1.0.2l  25 May 2017
read EC key
Private-Key: (256 bit)
priv:
    stuff
pub:
    04:c5:e6:dc:fc:df:c1:c0:c2:88:c0:b8:c2:dc:d0:
    fa:1c:3a:84:1a:52:66:8c:fb:a1:bf:c9:77:e1:fa:
    41:33:9a:33:2a:a8:73:ff:70:1b:3d:bb:d9:cf:a0:
    bb:9f:78:14:37:3a:f8:55:bc:7a:86:a3:c2:66:ea:
    b8:e9:3d:05:5d
Field Type: prime-field
Prime: ..elided
A:
B:
Generator (uncompressed):
Order:
Cofactor:  1 (0x1)
Seed:

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [


From kgoldman at us.ibm.com  Tue Jun 25 14:59:12 2019
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Tue, 25 Jun 2019 10:59:12 -0400
Subject: Building a DER sequence
Message-ID: <qetcs1$3uhm$1@blaine.gmane.org>

I have to build a DER byte stream for a sequence containing:

	algorithm ID
	issuer
	validity
	subject name
	extensions

What is the general approach?

Is there openssl support for this?

Do I construct a sequence and add items to it - top down?

Or do I construct the items and then make a sequence from it - bottom up?
	
Or do I place the items in a custom structure and then write the i2d() 
myself?

Any advice, pointers, or sample code would be welcome.


From john.sha.jiang at gmail.com  Wed Jun 26 01:41:04 2019
From: john.sha.jiang at gmail.com (John Jiang)
Date: Wed, 26 Jun 2019 09:41:04 +0800
Subject: Enabled weak cipher suites
Message-ID: <CAJbO6CR2WDayPOEmzSf5g8PoQ0B-J1ZQpfr+BS6UQ0ioDJw0XA@mail.gmail.com>

Hi,
I'm using s_server and s_client from OpenSSL 1.1.1.
It looks the weak cipher suites, like SSL_RSA_WITH_RC4_128_MD5, are
disabled.
Is there any way to re-enable these cipher suites?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190626/4720e93b/attachment-0001.html>

From paul.dale at oracle.com  Wed Jun 26 06:58:27 2019
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Wed, 26 Jun 2019 16:58:27 +1000
Subject: Enabled weak cipher suites
In-Reply-To: <CAJbO6CR2WDayPOEmzSf5g8PoQ0B-J1ZQpfr+BS6UQ0ioDJw0XA@mail.gmail.com>
References: <CAJbO6CR2WDayPOEmzSf5g8PoQ0B-J1ZQpfr+BS6UQ0ioDJw0XA@mail.gmail.com>
Message-ID: <A4FABC06-90CA-4EAF-8F53-86B24DE36879@oracle.com>

Yes there is but it will require a reconfigure and a recompile.

The big question is: "why??
RC4 and MD5 are both considered broken.


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



> On 26 Jun 2019, at 11:41 am, John Jiang <john.sha.jiang at gmail.com> wrote:
> 
> Hi,
> I'm using s_server and s_client from OpenSSL 1.1.1.
> It looks the weak cipher suites, like SSL_RSA_WITH_RC4_128_MD5, are disabled.
> Is there any way to re-enable these cipher suites?
> 
> Thanks!

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

From dclarke at blastwave.org  Wed Jun 26 07:12:09 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Wed, 26 Jun 2019 03:12:09 -0400
Subject: Enabled weak cipher suites
In-Reply-To: <CAJbO6CR2WDayPOEmzSf5g8PoQ0B-J1ZQpfr+BS6UQ0ioDJw0XA@mail.gmail.com>
References: <CAJbO6CR2WDayPOEmzSf5g8PoQ0B-J1ZQpfr+BS6UQ0ioDJw0XA@mail.gmail.com>
Message-ID: <b8352156-6637-65b9-f9eb-c03d750b1162@blastwave.org>

On 6/25/19 9:41 PM, John Jiang wrote:
> Hi,
> I'm using s_server and s_client from OpenSSL 1.1.1.
> It looks the weak cipher suites, like SSL_RSA_WITH_RC4_128_MD5, are 
> disabled.
> Is there any way to re-enable these cipher suites?

Fairly certain that is a configuration option however I have not
bothered with those since 1.0.2 or so.


-- 
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken
GreyBeard and suspenders optional

From syedmoulana at yahoo.com  Wed Jun 26 07:46:39 2019
From: syedmoulana at yahoo.com (syed moulana)
Date: Wed, 26 Jun 2019 07:46:39 +0000 (UTC)
Subject: Using openssl test
References: <168765686.63037.1561535199877.ref@mail.yahoo.com>
Message-ID: <168765686.63037.1561535199877@mail.yahoo.com>

Hi?Is there any test application scripts? bundled with openssl_1.1.1b ? If yes.? How to compile it.Is it possible use that test application to verify SSL handshake ?

Thank youSyed
Sent from Yahoo Mail on Android
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190626/86a391c6/attachment.html>

From openssl-users at dukhovni.org  Wed Jun 26 08:59:55 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 26 Jun 2019 04:59:55 -0400
Subject: ECDSA curves and certificates in 1.0.2X vs 1.1.x
In-Reply-To: <12238.1561473530@localhost>
References: <12238.1561473530@localhost>
Message-ID: <20190626085955.GF84864@straasha.imrryr.org>

On Tue, Jun 25, 2019 at 10:38:50AM -0400, Michael Richardson wrote:

> openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
>                 -nodes -subj "/CN=${ULA_HOSTNAME}" \
>                 -keyout ${KEY_NAME}.key -out ${KEY_NAME}.csr -outform DER \
>                 -reqexts SAN \
>                 -config /tmp/shg.ossl.cnf

This generates a key that has explicit parameters (rather than a named
curve) also in OpenSSL 1.0.2h, for example.  Since you probably want
to use named curves, with 1.0.2 you'll have to generate the key separately,
and explicitly indicate that you want a named curve key.  For that also
include an additional:

	-pkeyopt ec_param_enc:named_curve

option.  This was not on by default in OpenSSL 1.0.2.

> ***
>   My question is: is there some build options that I can't see that might have
>   affected this?  Made it work before.  My impression is that 1.0.x did *not*
>   support ECDSA certificates, yet it seemed to generate CSRs, just does not put in the
>   right OIDs in the public parts such that it is recognized by others.
> ***

OpenSSL 1.0.2 has reasonably complete ECDSA support, but various
aspects of the implementation are better in 1.1.1.

-- 
	Viktor.

From john.sha.jiang at gmail.com  Wed Jun 26 11:18:47 2019
From: john.sha.jiang at gmail.com (John Jiang)
Date: Wed, 26 Jun 2019 19:18:47 +0800
Subject: Enabled weak cipher suites
In-Reply-To: <A4FABC06-90CA-4EAF-8F53-86B24DE36879@oracle.com>
References: <CAJbO6CR2WDayPOEmzSf5g8PoQ0B-J1ZQpfr+BS6UQ0ioDJw0XA@mail.gmail.com>
 <A4FABC06-90CA-4EAF-8F53-86B24DE36879@oracle.com>
Message-ID: <CAJbO6CSKSi8Lvcf6zQJekEzPX2ATWuVVrDtjoxkhtGSjYo7iog@mail.gmail.com>

On Wed, Jun 26, 2019 at 2:59 PM Dr Paul Dale <paul.dale at oracle.com> wrote:

> Yes there is but it will require a reconfigure and a recompile.
>
Could you please show me more details about it?
Which option(s) should be used for configuring and compiling?


>
> The big question is: "why??
> RC4 and MD5 are both considered broken.
>
Don't worry, just for some testing.

Thanks!


>
> Pauli
> --
> Dr Paul Dale | Cryptographer | Network Security & Encryption
> Phone +61 7 3031 7217
> Oracle Australia
>
>
>
> On 26 Jun 2019, at 11:41 am, John Jiang <john.sha.jiang at gmail.com> wrote:
>
> Hi,
> I'm using s_server and s_client from OpenSSL 1.1.1.
> It looks the weak cipher suites, like SSL_RSA_WITH_RC4_128_MD5, are
> disabled.
> Is there any way to re-enable these cipher suites?
>
> Thanks!
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190626/f3eec781/attachment.html>

From matt at openssl.org  Wed Jun 26 11:29:15 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 26 Jun 2019 12:29:15 +0100
Subject: Enabled weak cipher suites
In-Reply-To: <CAJbO6CSKSi8Lvcf6zQJekEzPX2ATWuVVrDtjoxkhtGSjYo7iog@mail.gmail.com>
References: <CAJbO6CR2WDayPOEmzSf5g8PoQ0B-J1ZQpfr+BS6UQ0ioDJw0XA@mail.gmail.com>
 <A4FABC06-90CA-4EAF-8F53-86B24DE36879@oracle.com>
 <CAJbO6CSKSi8Lvcf6zQJekEzPX2ATWuVVrDtjoxkhtGSjYo7iog@mail.gmail.com>
Message-ID: <91ac6b44-71e3-1487-2d76-df164722e40c@openssl.org>



On 26/06/2019 12:18, John Jiang wrote:
> On Wed, Jun 26, 2019 at 2:59 PM Dr Paul Dale <paul.dale at oracle.com
> <mailto:paul.dale at oracle.com>> wrote:
> 
>     Yes there is but it will require a reconfigure and a recompile.
> 
> Could you please show me more details about it?
> Which option(s) should be used for configuring and compiling?

To compile in support for weak ciphersuites:

$ ./config enable-weak-ssl-ciphers

And then make/make test/make install as usual.

Once support is compiled in the weak ciphersuites are still not enabled in the
"DEFAULT" set of ciphersuites - you have to explicitly enable them at run time, e.g.

$ openssl s_server -no_tls1_3 -cipher "RC4-MD5:@SECLEVEL=0"

$ openssl s_client -no_tls1_3 -cipher "RC4-MD5:@SECLEVEL=0"

Matt

> ?
> 
> 
>     The big question is: "why??
>     RC4 and MD5 are both considered broken.
> 
> Don't worry, just for some testing.
> 
> Thanks!
> 
> 
> 
>     Pauli
>     --?
>     Dr Paul Dale | Cryptographer | Network?Security & Encryption?
>     Phone +61 7 3031 7217
>     Oracle Australia
> 
> 
> 
>>     On 26 Jun 2019, at 11:41 am, John Jiang <john.sha.jiang at gmail.com
>>     <mailto:john.sha.jiang at gmail.com>> wrote:
>>
>>     Hi,
>>     I'm using s_server and s_client from OpenSSL 1.1.1.
>>     It looks the weak cipher suites, like SSL_RSA_WITH_RC4_128_MD5, are disabled.
>>     Is there any way to re-enable these cipher suites?
>>
>>     Thanks!
> 

From hareesh.sai at gmail.com  Wed Jun 26 13:29:52 2019
From: hareesh.sai at gmail.com (Hareesh D)
Date: Wed, 26 Jun 2019 18:59:52 +0530
Subject: Validating RSA Random Probably Prime KAT !!
Message-ID: <CAD19CyRbV08qySEPCVZ9rBJr5Wa4PXobF7mntBKjs0v8jZv6fg@mail.gmail.com>

These is a testvector available in NIST Keyagrn_186-3_Random
ProbablyPrime3_3_KAT.txt.

Is it possible to verify this with OpenSSL1.1.1a. If yes, Can you please
give the corresponding APIs to be used.

I considered prandom, qrandom as factors p, q and tried checking RSA key
generation with the mentioned exponent. But results are not as expected. I
guess prandom, qrandom are to be used as only initial random prime numbers
and see that key generation tries to generate a new random number when they
are not meeting the criteria as mentioned in the *.txt file (reason as part
of Result) .
Just my assumption.

Is this file really a test vector and implementations should comply? I see
some info about this in rsa2vs.pdf (available in NIST) section 6.2.2.1.

How OpenSSL complies to this.

Thanks !!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190626/f7e7a8ff/attachment-0001.html>

From doctor at doctor.nl2k.ab.ca  Wed Jun 26 14:29:33 2019
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 26 Jun 2019 08:29:33 -0600
Subject: evp.t errors
Message-ID: <20190626142933.GB63998@doctor.nl2k.ab.ca>

Anyone getting this in the last 2 days?



../test/recipes/30-test_evp.t ...................... Dubious, test returned 1 (wstat 256, 0x100)
Failed 1/10 subtests
-- 
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
All appears to change when we change.  -Henri-Fr=C3=A9d=C3=A9ric Amiel

From rsalz at akamai.com  Wed Jun 26 15:34:14 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 26 Jun 2019 15:34:14 +0000
Subject: Building a DER sequence
In-Reply-To: <qetcs1$3uhm$1@blaine.gmane.org>
References: <qetcs1$3uhm$1@blaine.gmane.org>
Message-ID: <9881273A-830E-4EAD-B0A9-E0299919B7CE@akamai.com>

    Do I construct a sequence and add items to it - top down?

No, because then you have to go back and patch the sequence length and perhaps slide everything up or down a copule of bytes.

I would look at an existing simple sequence and start writing your own based on that; look for ASN1_SEQUENCE macros in crypto/x509/x*.c files.  Another set of macros will declare the i2d/d2i and PEM functions if needed.



From matt at openssl.org  Wed Jun 26 16:12:41 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 26 Jun 2019 17:12:41 +0100
Subject: Using openssl test
In-Reply-To: <168765686.63037.1561535199877@mail.yahoo.com>
References: <168765686.63037.1561535199877.ref@mail.yahoo.com>
 <168765686.63037.1561535199877@mail.yahoo.com>
Message-ID: <ecffabc8-3fcf-1979-b96b-68dc63b748dc@openssl.org>



On 26/06/2019 08:46, syed moulana via openssl-users wrote:
> Hi?
> Is there any test application scripts? bundled with openssl_1.1.1b ? If yes.?
> How to compile it.
> Is it possible use that test application to verify SSL handshake ?

I think you are probably wanting to use s_server/s_client which are documented here:

https://www.openssl.org/docs/man1.1.1/man1/s_server.html
https://www.openssl.org/docs/man1.1.1/man1/s_client.html

Matt

From bill_hallahan at hotmail.com  Wed Jun 26 22:29:00 2019
From: bill_hallahan at hotmail.com (Bill Hallahan)
Date: Wed, 26 Jun 2019 22:29:00 +0000
Subject: Link error with openssl-1.1.1-c on AIX
Message-ID: <BN7PR06MB3874EC9964F717A80D6E4E5394E20@BN7PR06MB3874.namprd06.prod.outlook.com>

To whom it may concern.

I am trying to build openssl-1.1.1-c on AIX using the xlc compiler.  I know Linux quite well, but only have passing knowledge of AIX.

This is the system. (The name is sanitized - I am paranoid about security).

bash-4.2$ uname -a
AIX sanitized 1 6 00CD1ECE4C00
bash-4.2$

I have found the c99 compiler and the xlc compiler seem to work best. The arguments produced by the following configuration command are not compatible with gcc.

   ./config -static no-ec no-mdc2 no-rc5 no-idea --openssldir=/path_sanitized

I would prefer to use the xlc compiler.

(I am still trying to figure out how to get the compiler version. "-V" does not work).

I was getting many linker errors, but I have fixed the Makefile to include certain libraries.  Now I just have one unresolved external, which is "ecp_nistz256_mul_mont".

This is the output of the link failure.

/usr/local/packages/vac_remote/9-sept2008/./usr/vac/bin/.orig/xlc: 1501-210 (W) command option t contains an incorrect subargument
ld: 0711-317 ERROR: Undefined symbol: .ecp_nistz256_mul_mont
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information.
make[2]: *** [apps/openssl] Error 8
make[2]: Leaving directory `/scratch/bhallaha/view_storage/bhallaha_o2_19_18_1_ossl/reliaty/web/openssl-1.1.1c'

I see a perl script related to the needed module and a number of assembly language files, and I presume only one is for AIX.

I've tried adding  -DECP_NISTZ256_ASM to the compile lines, but I still get that unresolved external.

Does anyone know what I need to do?  I'll eventually figure this out, but I'd like this to work as soon as possible.

    Regards,
         Bill



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

From openssl-users at dukhovni.org  Wed Jun 26 22:51:59 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 26 Jun 2019 18:51:59 -0400
Subject: Link error with openssl-1.1.1-c on AIX
In-Reply-To: <BN7PR06MB3874EC9964F717A80D6E4E5394E20@BN7PR06MB3874.namprd06.prod.outlook.com>
References: <BN7PR06MB3874EC9964F717A80D6E4E5394E20@BN7PR06MB3874.namprd06.prod.outlook.com>
Message-ID: <20190626225159.GN84864@straasha.imrryr.org>

On Wed, Jun 26, 2019 at 10:29:00PM +0000, Bill Hallahan wrote:

> I am trying to build openssl-1.1.1-c on AIX using the xlc compiler.  I
> know Linux quite well, but only have passing knowledge of AIX.
> 
>    ./config -static no-ec no-mdc2 no-rc5 no-idea --openssldir=/path_sanitized

You're disabling elliptic-curve crytography for some reason, this
is generally unwise.

> I was getting many linker errors, but I have fixed the Makefile to include
> certain libraries.  Now I just have one unresolved external, which is
> "ecp_nistz256_mul_mont".

As a result that function is no longer-available, but it seems that
"no-ec" is not enough to suppress all the call-sites.  Your best bet
is to not specify "no-ec".

-- 
	Viktor.

From Michael.Wojcik at microfocus.com  Wed Jun 26 23:16:07 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 26 Jun 2019 23:16:07 +0000
Subject: Link error with openssl-1.1.1-c on AIX
In-Reply-To: <BN7PR06MB3874EC9964F717A80D6E4E5394E20@BN7PR06MB3874.namprd06.prod.outlook.com>
References: <BN7PR06MB3874EC9964F717A80D6E4E5394E20@BN7PR06MB3874.namprd06.prod.outlook.com>
Message-ID: <BYAPR18MB2918EC342B45BF42AC03009EF9E20@BYAPR18MB2918.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Bill Hallahan
> Sent: Wednesday, June 26, 2019 16:29

> I am trying to build openssl-1.1.1-c on AIX using the xlc compiler.

> I have found the c99 compiler and the xlc compiler seem to work best. The arguments
> produced by the following configuration command are not compatible with gcc.

>   ./config -static no-ec no-mdc2 no-rc5 no-idea --openssldir=/path_sanitized

We run Configure rather than config, bootstrapping our AIX openssl build with:

$ ./Configure aix-cc threads enable-ssl3 no-ec2m no-idea no-rc5 enable-weak-ssl-ciphers no-shared -DOPENSSL_NO_AUTOLOAD_CONFIG --prefix=`pwd`/buildoutput --openssldir=`pwd`/buildoutput -qmaxmem=-1 -qlanglvl-stdc99 -qlanglvl=stdc99 -D_LARGE_FILES=1

(I'm not currently the maintainer of our OpenSSL build process, so I can't provide the rationale for all of that, but it's working in our environment.)

For 64-bit, use aix64-cc instead.

Now, that's what config ought to select, but I'm not a fan of config, personnally. For a repeatable build process I like to tell the OpenSSL build process how to configure itself.

> I would prefer to use the xlc compiler.

The "c99" and "xlc" commands both invoke the same compiler - IBM's XL C compiler (aka "C/Set", etc, in some releases). They just set different default options for things like language level and extensions.

> (I am still trying to figure out how to get the compiler version. "-V" does not work).

$ lslpp -i '*xlc*'

will list the LPPs (Licensed Program Products) that have "xlc" in the name. You should have one named xlccmp.X.Y.Z, followed by a handful with the same name variously suffixed (e.g. "xlccmp.13.1.0.lib"). The X.Y.Z are the XLC version.

For more info, run e.g.

$ lslpp -l xlccmp.13.1.0

which will show what patch level you're at.

The LPP stuff is one of the remaining AIXisms in AIX.

> I was getting many linker errors, but I have fixed the Makefile to include certain
> libraries.

That shouldn't be necessary, so it sounds like configuration did not run properly.

>   Now I just have one unresolved external, which is "ecp_nistz256_mul_mont".

Well, that does sound like an issue with the assembly routines, since there's a PPC version of that one (I think, glancing at the source). You could try configurinng with no-asm, but generally you only want to do that when diagnosing an issue, not for production use. (There's widespread opinion that OpenSSL is too slow for production use without the assembly routines. I think that depends on use cases, but it's a popular opinion.)

> I've tried adding  -DECP_NISTZ256_ASM to the compile lines, but I still get that
> unresolved external.

Trying to fool the configuration generally isn't a useful approach.

I suggest reconfiguring, using a variation on my command line above that includes the options you want. Or you might try mine verbatim (well, probably without --prefix and --openssldir) to see if it works, then change it to use your options to see if you can narrow down what's causing the issue.

Incidentally: why no-ec? Removing all ECC is going to give you a rather outdated set of crypto algorithms. If you're concerned about possible IP encumbrance, I'd recommend no-ec2m. (I am not a lawyer, but I'm happy to offer worthless legal advice on the Internet.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From hmurray at megapathdsl.net  Wed Jun 26 23:25:08 2019
From: hmurray at megapathdsl.net (Hal Murray)
Date: Wed, 26 Jun 2019 16:25:08 -0700
Subject: Does openssl sanity check ALPN strings?
Message-ID: <20190626232508.9C55240605C@ip-64-139-1-69.sjc.megapath.net>


If a client passes {99, "a", "z" } with a length of 3 to 
SSL_CTX_set_alpn_protos,
does that get rejected or sent to the server?

If a somebody sends that to a server, does it get passed to the alpn callback?


-- 
These are my opinions.  I hate spam.




From wiml at omnigroup.com  Wed Jun 26 23:47:14 2019
From: wiml at omnigroup.com (Wim Lewis)
Date: Wed, 26 Jun 2019 16:47:14 -0700
Subject: Does openssl sanity check ALPN strings?
In-Reply-To: <20190626232508.9C55240605C@ip-64-139-1-69.sjc.megapath.net>
References: <20190626232508.9C55240605C@ip-64-139-1-69.sjc.megapath.net>
Message-ID: <741A94B3-81E7-452F-B3EE-479929FABF74@omnigroup.com>


On Jun 26, 2019, at 4:25 PM, Hal Murray <hmurray at megapathdsl.net> wrote:
> If a client passes {99, "a", "z" } with a length of 3 to 
> SSL_CTX_set_alpn_protos,
> does that get rejected or sent to the server?
> 
> If a somebody sends that to a server, does it get passed to the alpn callback?

I don't think OpenSSL does any checking on the client side --- whatever bytes you supply get sent to the server.

On the server side it does some checking before calling the alpn callback but I don't know that it makes any guarantees of validity.



From hareesh.sai at gmail.com  Thu Jun 27 06:08:00 2019
From: hareesh.sai at gmail.com (Hareesh D)
Date: Thu, 27 Jun 2019 11:38:00 +0530
Subject: Validating RSA Random Probably Prime KAT !!
In-Reply-To: <CAD19CyRbV08qySEPCVZ9rBJr5Wa4PXobF7mntBKjs0v8jZv6fg@mail.gmail.com>
References: <CAD19CyRbV08qySEPCVZ9rBJr5Wa4PXobF7mntBKjs0v8jZv6fg@mail.gmail.com>
Message-ID: <CAD19CyQvCvjDVAuWCwjf4NmpgZs1uS=WEmjQujp+cdW10e6Ljg@mail.gmail.com>

Looks like BN_is_prime_ex() is the API to check this test.

On Wed, 26 Jun 2019, 18:59 Hareesh D, <hareesh.sai at gmail.com> wrote:

> These is a testvector available in NIST Keyagrn_186-3_Random
> ProbablyPrime3_3_KAT.txt.
>
> Is it possible to verify this with OpenSSL1.1.1a. If yes, Can you please
> give the corresponding APIs to be used.
>
> I considered prandom, qrandom as factors p, q and tried checking RSA key
> generation with the mentioned exponent. But results are not as expected. I
> guess prandom, qrandom are to be used as only initial random prime numbers
> and see that key generation tries to generate a new random number when they
> are not meeting the criteria as mentioned in the *.txt file (reason as part
> of Result) .
> Just my assumption.
>
> Is this file really a test vector and implementations should comply? I see
> some info about this in rsa2vs.pdf (available in NIST) section 6.2.2.1.
>
> How OpenSSL complies to this.
>
> Thanks !!
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190627/c036f443/attachment.html>

From mcr at sandelman.ca  Thu Jun 27 22:00:43 2019
From: mcr at sandelman.ca (Michael Richardson)
Date: Thu, 27 Jun 2019 18:00:43 -0400
Subject: ECDSA curves and certificates in 1.0.2X vs 1.1.x
In-Reply-To: <20190626085955.GF84864@straasha.imrryr.org>
References: <12238.1561473530@localhost>
 <20190626085955.GF84864@straasha.imrryr.org>
Message-ID: <10392.1561672843@localhost>


Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
    > On Tue, Jun 25, 2019 at 10:38:50AM -0400, Michael Richardson wrote:

    >> openssl req -new -newkey ec -pkeyopt ec_paramgen_curve:prime256v1 \
    >> -nodes -subj "/CN=${ULA_HOSTNAME}" \
    >> -keyout ${KEY_NAME}.key -out ${KEY_NAME}.csr -outform DER \
    >> -reqexts SAN \
    >> -config /tmp/shg.ossl.cnf

    > This generates a key that has explicit parameters (rather than a named
    > curve) also in OpenSSL 1.0.2h, for example.  Since you probably want
    > to use named curves, with 1.0.2 you'll have to generate the key separately,
    > and explicitly indicate that you want a named curve key.  For that also
    > include an additional:

    > -pkeyopt ec_param_enc:named_curve

    > option.  This was not on by default in OpenSSL 1.0.2.

Thank you again, this worked great.
(I wonder if we had that before, and it just got lost as we rebuild from source)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

-------------- 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/20190627/b3fa31e6/attachment.sig>

From hmurray at megapathdsl.net  Fri Jun 28 08:36:05 2019
From: hmurray at megapathdsl.net (Hal Murray)
Date: Fri, 28 Jun 2019 01:36:05 -0700
Subject: Does openssl sanity check ALPN strings?
In-Reply-To: Message from Wim Lewis <wiml@omnigroup.com> of "Wed,
 26 Jun 2019 16:47:14 PDT."
 <741A94B3-81E7-452F-B3EE-479929FABF74@omnigroup.com>
Message-ID: <20190628083605.5202F40605C@ip-64-139-1-69.sjc.megapath.net>


wiml at omnigroup.com said:
> I don't think OpenSSL does any checking on the client side --- whatever bytes
> you supply get sent to the server.

> On the server side it does some checking before calling the alpn callback but
> I don't know that it makes any guarantees of validity. 

Thanks.

Does out/outlen as returned by the server side alpn callback include the 
length byte?

man page says:
       cb is the application defined callback. The in, inlen parameters are a
       vector in protocol-list format. The value of the out, outlen vector
       should be set to the value of a single protocol selected from the in,
       inlen vector. The out buffer may point directly into in, or to a buffer
       that outlives the handshake. The arg parameter is the pointer set via
       SSL_CTX_set_alpn_select_cb().



-- 
These are my opinions.  I hate spam.




From mrichter at solarflare.com  Fri Jun 28 21:22:48 2019
From: mrichter at solarflare.com (Mark Richter)
Date: Fri, 28 Jun 2019 21:22:48 +0000
Subject: error: dereferencing pointer to incomplete type DH {aka struct dh_st}
Message-ID: <1561756968379.5594@solarflare.com>

I've tried looking this up on the web, but there is no cleare guidance on how to get around this.


I'm attempting to build our RHEL 7 based product on RHEL 8 and running into a lot of changes from openssl 1.0.2k-fips (RHEL 7) to 1.1.1 FIPS (RHEL 8).  I haven't found a good guide to adapting the sources to these changes.


Where can I find one?


Thanks.

Mark Richter | Senior Staff Engineer
SolarFlare Communications, Inc. | www.Solarflare.com<http://www.solarflare.com/>
9444 Waples Street, #170, San Diego, CA  92121
Mobile: +1 949-632-8403
[Description: Description: cid:EC628FDE-ACA6-4F34-A8AE-E1F672D4E395]
The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited.

From rsalz at akamai.com  Fri Jun 28 21:36:07 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 28 Jun 2019 21:36:07 +0000
Subject: error: dereferencing pointer to incomplete type DH {aka struct
 dh_st}
In-Reply-To: <1561756968379.5594@solarflare.com>
References: <1561756968379.5594@solarflare.com>
Message-ID: <F5F801EA-7035-41D4-AEB4-4020B394C79B@akamai.com>

>    I'm attempting to build our RHEL 7 based product on RHEL 8 and running into a lot of changes from openssl 1.0.2k-fips (RHEL 7) to 1.1.1 FIPS (RHEL 8).  I haven't found a good guide to adapting the sources to these changes.

Web search for "openssl opaque accessors" turns up many hits; these two seem useful:
  
	https://wiki.openssl.org/index.php/OpenSSL_1.1.0_Changes
	http://vega.pgw.jp/~kabe/vsd/migrate2openssl-1.1.html 
 
PS: A long confidential email disclaimer is silly, particularly when posting to a large public mailing list. :)


From openssl-users at dukhovni.org  Fri Jun 28 21:41:23 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 28 Jun 2019 17:41:23 -0400
Subject: error: dereferencing pointer to incomplete type DH {aka struct
 dh_st}
In-Reply-To: <1561756968379.5594@solarflare.com>
References: <1561756968379.5594@solarflare.com>
Message-ID: <20190628214123.GZ84864@straasha.imrryr.org>

On Fri, Jun 28, 2019 at 09:22:48PM +0000, Mark Richter wrote:

> I've tried looking this up on the web, but there is no clear guidance on how to get around this.

The documentation is a good place to start.

    https://www.openssl.org/docs/man1.1.1/man3/DH_set0_pqg.html

If that's not it, look for other manpages that mention DH:

    https://www.openssl.org/docs/man1.1.1/man3/

In Postfix I have some macros that simulate 1.1.x interfaces for
OpenSSL 1.0.2:

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls.h#L87-L117

these are by no means a complete list, but my advice is to do
something similar, that is, switch to the 1.1.x APIs and define
forward-compatibility macros for 1.0.2.

-- 
	Viktor.