From kurt at roeckx.be  Tue Jan  1 00:45:51 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 1 Jan 2019 01:45:51 +0100
Subject: [openssl-users] Authentication over ECDHE
In-Reply-To: <27fa0004-7684-9343-218b-558682c79201@openssl.org>
References: <1d66ccc0-87ac-82ad-818d-f71bf1e9f811@gmx.de>
 <04e8446f-35fb-dc21-ff34-ea64f6dae0c9@gmail.com>
 <4d287beb-f79b-5fb8-9a6f-8a612c175474@gmx.de>
 <20181231.101257.2069367019671144053.levitte@openssl.org>
 <ac7e992a-ab83-6270-bd3a-548a8c49fa53@gmx.de>
 <27fa0004-7684-9343-218b-558682c79201@openssl.org>
Message-ID: <20190101004551.GA728@roeckx.be>

On Mon, Dec 31, 2018 at 02:11:56PM +0000, Matt Caswell wrote:
> 
> Well, you have vocally complained about the state of the documentation. You have
> the benefit of being a new OpenSSL user. You know what things were confusing or
> unclear in the documentation. More experienced OpenSSL coders often don't have
> the perspective - because some things are just "obvious" to them. So help with
> pull requests to improve the documentation.

Or you could just file a bug pointing out the areas that are
unclear.


Kurt


From ckashiquekvk at gmail.com  Wed Jan  2 05:02:07 2019
From: ckashiquekvk at gmail.com (ASHIQUE CK)
Date: Wed, 2 Jan 2019 10:32:07 +0530
Subject: [openssl-users] Openssl async support
In-Reply-To: <CAEcRwS4H9NuUepeOZQ2ewBbO8ueh8mjpgUjOXhmxC0Q=ALGNbQ@mail.gmail.com>
References: <CAEcRwS7HYusHPcyzo1EZciUOWZHQCAgjpOo18XLqDctWZkBd_w@mail.gmail.com>
 <CAEcRwS70fgKyk849UjA47gPWrtF=1cz_n2Y7==KGCooNbmCewQ@mail.gmail.com>
 <CAEcRwS6a=7yacrTJ34VS4Y3uDrT1C3cv0XYBuy=j7OPzLvnVfA@mail.gmail.com>
 <CAEcRwS6U9Q5kSOirqa-dXe1bv+VJeHTDj0JGpv-62Uv1ScusdA@mail.gmail.com>
 <CAEcRwS4H9NuUepeOZQ2ewBbO8ueh8mjpgUjOXhmxC0Q=ALGNbQ@mail.gmail.com>
Message-ID: <CAEcRwS47q2cW986WZTmUP11m3doT+YZSjPvmE5QYshMEfdAfyg@mail.gmail.com>

Hi,
Any help on this ?


On Mon, Dec 31, 2018 at 10:44 AM ASHIQUE CK <ckashiquekvk at gmail.com> wrote:

> Gentle reminder
>
> On Thu, Dec 27, 2018 at 8:37 PM ASHIQUE CK <ckashiquekvk at gmail.com> wrote:
>
>> Hi all,
>>
>>           Thanks for the earlier reply. But still Iam facing issue
>> regarding the asynchronous job operation.
>>
>>            I have implemented asynchronous job operation partially. I am
>> now getting requests asynchronously ie. getting the next request after
>> calling ASYNC_pause_job from the first request. But I am unable to resume
>> the paused jobs after job completion.
>>
>> Test setup consists of a nginx server and three SSL client apps.
>>
>> I have got the first 16kb processing request (AES-GCM
>> encryption/decryption) from client1 and have submitted the request to the
>> engine and done ASYNC_pause_job, so client1 entered into waiting state. But
>> when we run the client2 app, the first job went into ASYNC_FINISH state
>> before job completion. Similarly, when we run the client3 app, the second
>> job went into ASYNC_FINISH state. Can you help regarding this?
>>
>>
>>
>> On Wed, Dec 19, 2018 at 5:33 PM ASHIQUE CK <ckashiquekvk at gmail.com>
>> wrote:
>>
>>> Gentle reminder
>>>
>>> On Tue, Dec 18, 2018 at 4:06 PM ASHIQUE CK <ckashiquekvk at gmail.com>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I truly understand that everyone might be busy with your work and
>>>> didn't found time to reply. That's okay, but incase you have accidendly
>>>> forgot to reply, please accept this as a gentle reminder.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Dec 17, 2018 at 6:11 PM ASHIQUE CK <ckashiquekvk at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I have some queries regarding OpenSSL async operation.
>>>>>
>>>>> Current setup
>>>>> -------------
>>>>> I have one* OpenSSL dynamic engine (with RSA and AES-GCM support) *and
>>>>> linked it with *Nginx* server. Multiple *WGET* commands on the client
>>>>> side.
>>>>>
>>>>> Current issue
>>>>> -------------
>>>>>   Since OpenSSL *do_cipher call *(the function in which actual
>>>>> AES-GCM encryption/decryption happening) comes from one client at a time
>>>>> which is reducing file downloading performance. So we need an *asynchronous
>>>>> operation in OpenSSL* ie. we need multiple do_cipher calls at the
>>>>> same time from which we should submit requests to HW without affecting the
>>>>> incoming requests and should wait for HW output.
>>>>>
>>>>> Queries
>>>>> --------
>>>>>  1) Is there is any other scheme for multiple do_cipher calls at a
>>>>> time?.
>>>>>  2) Any method to enable asynchronous call from OpenSSL?
>>>>>
>>>>> Versions
>>>>> -------------
>>>>> Openssl - 1.1.0h
>>>>> Nginx1.11.10
>>>>> Wget 1.17.1
>>>>>
>>>>>  Kindly support me. Please inform me if any more inputs needed. Thanks
>>>>> in advance.
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190102/236290c2/attachment.html>

From matt at openssl.org  Wed Jan  2 09:41:09 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 2 Jan 2019 09:41:09 +0000
Subject: [openssl-users] tls1_change_cipher_state
In-Reply-To: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
References: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
Message-ID: <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>



On 27/12/2018 08:37, Dmitry Belyavsky wrote:
> Hello,
> 
> Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 are unused in
> this function?

Looks that way. They should be removed.

Matt



From jb-openssl at wisemo.com  Wed Jan  2 09:52:13 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 2 Jan 2019 10:52:13 +0100
Subject: [openssl-users] Authentication over ECDHE
In-Reply-To: <20181229.223353.2252472956067207821.levitte@openssl.org>
References: <38b97114-0c66-40ed-f631-58aa20940a3a@gmx.de>
 <20181229.170846.804158981742723988.levitte@openssl.org>
 <20181229.223353.2252472956067207821.levitte@openssl.org>
Message-ID: <607db8ee-9c13-b43a-9fa2-c5c202c03393@wisemo.com>

On 29/12/2018 22:33, Richard Levitte wrote:
> In message <20181229.170846.804158981742723988.levitte at openssl.org> on Sat, 29 Dec 2018 17:08:46 +0100 (CET), Richard Levitte <levitte at openssl.org> said:
>
>> In message <38b97114-0c66-40ed-f631-58aa20940a3a at gmx.de> on Sat, 29 Dec 2018 14:19:47 +0100, "C.Wehrmeyer" <c.wehrmeyer at gmx.de> said:
>>
> ...
>>> What's wrong with that, you ask? Let me show you how I'd have done
>>> that:
>>>
>>>> static const unsigned char ssl3_pad_1[] =
>>>> {
>>>>      "66666666"
>>>>      "66666666"
>>>>      "66666666"
>>>>      "66666666"
>>>>      "66666666"
>>>>      "66666666"
>>>> };
>>>>
>>>> static const unsigned char*ssl3_pad_2[] =
>>>> {
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>>      "\\\\\\\\\\\\\\\\"
>>>> };
>>> So, no. I don't trust anyone. Especially not this mess of a code.
>> You do know that your string insert NUL bytes, right?  If you have a
>> look at how they're used, you might see why those stray NUL bytes
>> aren't a good thing.
> Never mind this remark...  For some reason, my brain added commas
> after each partial string.  Meh...
>

It still inserts NUL bytes at the end of each array, changing
sizeof(array) as well as cache access patterns (and thus side
channel effects).

Enjoy

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


From matt at openssl.org  Wed Jan  2 10:04:20 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 2 Jan 2019 10:04:20 +0000
Subject: [openssl-users] Openssl async support
In-Reply-To: <CAEcRwS6U9Q5kSOirqa-dXe1bv+VJeHTDj0JGpv-62Uv1ScusdA@mail.gmail.com>
References: <CAEcRwS7HYusHPcyzo1EZciUOWZHQCAgjpOo18XLqDctWZkBd_w@mail.gmail.com>
 <CAEcRwS70fgKyk849UjA47gPWrtF=1cz_n2Y7==KGCooNbmCewQ@mail.gmail.com>
 <CAEcRwS6a=7yacrTJ34VS4Y3uDrT1C3cv0XYBuy=j7OPzLvnVfA@mail.gmail.com>
 <CAEcRwS6U9Q5kSOirqa-dXe1bv+VJeHTDj0JGpv-62Uv1ScusdA@mail.gmail.com>
Message-ID: <f4934cc2-1af2-9c4a-34d4-cf5d2d5c3670@openssl.org>



On 27/12/2018 15:07, ASHIQUE CK wrote:
> Hi all,
> 
> ? ? ? ? ? Thanks for the earlier reply. But still Iam facing issue regarding the
> asynchronous job operation.
> 
> ? ? ? ? ? ?I have implemented asynchronous job operation partially. I am now
> getting requests asynchronously ie. getting the next request after calling
> ASYNC_pause_job from the first request. But I am unable to resume the paused
> jobs after job completion.
> 
> Test setup consists of a nginx server and three SSL client apps.
> 
> I have got the first 16kb processing request (AES-GCM encryption/decryption)
> from client1 and have submitted the request to the engine and done
> ASYNC_pause_job, so client1 entered into waiting state. But when we run the
> client2 app, the first job went into ASYNC_FINISH state before job completion.
> Similarly, when we run the client3 app, the second job went into ASYNC_FINISH
> state. Can you help regarding this?

It's unclear from your description what you are doing or what exactly the issue
is. Are you able to share some code to show us what is happening?

Matt




> 
> 
> 
> On Wed, Dec 19, 2018 at 5:33 PM ASHIQUE CK <ckashiquekvk at gmail.com
> <mailto:ckashiquekvk at gmail.com>> wrote:
> 
>     Gentle reminder
> 
>     On Tue, Dec 18, 2018 at 4:06 PM ASHIQUE CK <ckashiquekvk at gmail.com
>     <mailto:ckashiquekvk at gmail.com>> wrote:
> 
>         Hi all,
> 
>         I truly understand that everyone might be busy with your work and didn't
>         found time to reply. That's okay, but incase you have accidendly forgot
>         to reply, please accept this as a gentle reminder.
> 
> 
> 
> 
> 
>         On Mon, Dec 17, 2018 at 6:11 PM ASHIQUE CK <ckashiquekvk at gmail.com
>         <mailto:ckashiquekvk at gmail.com>> wrote:
> 
>             Hi all,
> 
>             I have some queries regarding OpenSSL async operation.
> 
>             Current setup
>             -------------
>             I have one*OpenSSL dynamic engine (with RSA and AES-GCM support)
>             *and linked it with *Nginx* server. Multiple *WGET* commands on the
>             client side.
> 
>             Current issue
>             -------------
>             ?Since OpenSSL *do_cipher call?*(the function in which actual
>             AES-GCM encryption/decryption happening) comes from one client at a
>             time which is reducing file downloading performance. So we need an
>             *asynchronous operation in OpenSSL* ie. we need multiple do_cipher
>             calls at the same time from which we should submit requests to HW
>             without affecting the incoming requests and should wait for HW output.
> 
>             Queries
>             --------
>             ?1) Is there is any other scheme for multiple do_cipher calls at a
>             time?.?
>             ?2) Any method to enable asynchronous call from OpenSSL?? ?
> 
>             Versions
>             -------------
>             Openssl - 1.1.0h
>             Nginx1.11.10
>             Wget 1.17.1
> 
>             ?Kindly support me. Please inform me if any more inputs needed.
>             Thanks in advance.
> 
> 

From jb-openssl at wisemo.com  Wed Jan  2 10:14:04 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 2 Jan 2019 11:14:04 +0100
Subject: [openssl-users] tls1_change_cipher_state
In-Reply-To: <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
References: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
 <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
Message-ID: <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>

On 02/01/2019 10:41, Matt Caswell wrote:
>
> On 27/12/2018 08:37, Dmitry Belyavsky wrote:
>> Hello,
>>
>> Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 are unused in
>> this function?
> Looks that way. They should be removed.
>

By the way, why aren't any of your test compilers configured to
warn about unused local variables?? It's a common feature in many
compilers and thus a free consistency check that can catch typos.

Of cause doing so requires establishing a coding standard for how
to silence such warnings where a local variable is used only in
conditionally compiled code.

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 beldmit at gmail.com  Wed Jan  2 10:16:07 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Wed, 2 Jan 2019 13:16:07 +0300
Subject: [openssl-users] tls1_change_cipher_state
In-Reply-To: <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>
References: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
 <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
 <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>
Message-ID: <CADqLbzK72cQ0MjQGe=PNwZ=-Fvbs=Xd=EcZejbYqMxZ9NY7CGQ@mail.gmail.com>

Dear Jakob,

On Wed, Jan 2, 2019 at 1:14 PM Jakob Bohm via openssl-users <
openssl-users at openssl.org> wrote:

> On 02/01/2019 10:41, Matt Caswell wrote:
> >
> > On 27/12/2018 08:37, Dmitry Belyavsky wrote:
> >> Hello,
> >>
> >> Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 are
> unused in
> >> this function?
> > Looks that way. They should be removed.
> >
>
> By the way, why aren't any of your test compilers configured to
> warn about unused local variables?  It's a common feature in many
> compilers and thus a free consistency check that can catch typos.
>
> Of cause doing so requires establishing a coding standard for how
> to silence such warnings where a local variable is used only in
> conditionally compiled code.
>

I think that compiler treats them as used, because buffers are static and
cleansed at the end of the function.

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190102/486e30cb/attachment.html>

From dclarke at blastwave.org  Wed Jan  2 10:18:16 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Wed, 2 Jan 2019 05:18:16 -0500
Subject: [openssl-users] tls1_change_cipher_state
In-Reply-To: <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>
References: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
 <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
 <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>
Message-ID: <73f913f0-c7d0-2805-d28c-2273fc8c2968@blastwave.org>

On 1/2/19 5:14 AM, Jakob Bohm via openssl-users wrote:
> On 02/01/2019 10:41, Matt Caswell wrote:
>>
>> On 27/12/2018 08:37, Dmitry Belyavsky wrote:
>>> Hello,
>>>
>>> Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 
>>> are unused in
>>> this function?
>> Looks that way. They should be removed.
>>
> 
> By the way, why aren't any of your test compilers configured to
> warn about unused local variables?? It's a common feature in many
> compilers and thus a free consistency check that can catch typos.

Traditionally ( past four decades ) that was a feature provided by
something like 'lint' but I have not seen a lint picker lately other
than in the Oracle Studio compiler tools and it certainly isn't open
source in any way. Works very well however.

Dennis

From beldmit at gmail.com  Wed Jan  2 10:32:00 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Wed, 2 Jan 2019 13:32:00 +0300
Subject: [openssl-users] tls1_change_cipher_state
In-Reply-To: <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
References: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
 <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
Message-ID: <CADqLbzLRjJV-3j3ZrCyO_SXbOxHBSCTxDxHrBxnn=YDJ8iGq6g@mail.gmail.com>

Hello,

On Wed, Jan 2, 2019 at 12:41 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 27/12/2018 08:37, Dmitry Belyavsky wrote:
> > Hello,
> >
> > Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 are
> unused in
> > this function?
>
> Looks that way. They should be removed.
>

#7971

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190102/03b710bf/attachment.html>

From matt at openssl.org  Wed Jan  2 10:55:57 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 2 Jan 2019 10:55:57 +0000
Subject: [openssl-users] tls1_change_cipher_state
In-Reply-To: <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>
References: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
 <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
 <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>
Message-ID: <2c185b56-1e55-96ee-f7ee-aae0404c0298@openssl.org>



On 02/01/2019 10:14, Jakob Bohm via openssl-users wrote:
> On 02/01/2019 10:41, Matt Caswell wrote:
>>
>> On 27/12/2018 08:37, Dmitry Belyavsky wrote:
>>> Hello,
>>>
>>> Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 are unused in
>>> this function?
>> Looks that way. They should be removed.
>>
> 
> By the way, why aren't any of your test compilers configured to
> warn about unused local variables?? It's a common feature in many
> compilers and thus a free consistency check that can catch typos.

We do have that, but in this particular case the compiler has been fooled into
thinking that the buffers are used:

int tls1_change_cipher_state(SSL *s, int which)
{
    unsigned char *p, *mac_secret;
    unsigned char tmp1[EVP_MAX_KEY_LENGTH];
    unsigned char tmp2[EVP_MAX_KEY_LENGTH];
    unsigned char iv1[EVP_MAX_IV_LENGTH * 2];
    unsigned char iv2[EVP_MAX_IV_LENGTH * 2];

...

 err2:
    OPENSSL_cleanse(tmp1, sizeof(tmp1));
    OPENSSL_cleanse(tmp2, sizeof(tmp1));
    OPENSSL_cleanse(iv1, sizeof(iv1));
    OPENSSL_cleanse(iv2, sizeof(iv2));
    return (0);
}

Matt

From jb-openssl at wisemo.com  Wed Jan  2 11:12:04 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 2 Jan 2019 12:12:04 +0100
Subject: [openssl-users] tls1_change_cipher_state
In-Reply-To: <73f913f0-c7d0-2805-d28c-2273fc8c2968@blastwave.org>
References: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
 <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
 <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>
 <73f913f0-c7d0-2805-d28c-2273fc8c2968@blastwave.org>
Message-ID: <1edb0d24-5628-00b6-1aa6-4486c8706897@wisemo.com>

On 02/01/2019 11:18, Dennis Clarke wrote:
> On 1/2/19 5:14 AM, Jakob Bohm via openssl-users wrote:
>> On 02/01/2019 10:41, Matt Caswell wrote:
>>>
>>> On 27/12/2018 08:37, Dmitry Belyavsky wrote:
>>>> Hello,
>>>>
>>>> Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 
>>>> are unused in
>>>> this function?
>>> Looks that way. They should be removed.
>>>
>>
>> By the way, why aren't any of your test compilers configured to
>> warn about unused local variables?? It's a common feature in many
>> compilers and thus a free consistency check that can catch typos.
>
> Traditionally ( past four decades ) that was a feature provided by
> something like 'lint' but I have not seen a lint picker lately other
> than in the Oracle Studio compiler tools and it certainly isn't open
> source in any way. Works very well however.
>

Most traditional lint features have migrated into the compilers
(as warnings).? In this case gcc -Wunused enables a number of
such warnings.

Microsoft Visual C includes an advanced but flawed supplemental
linter in the form of the PREfast (code analysis) feature, which
tries to do semantic consistency checks for things like buffer
sizes and semaphore use.? This is closed source however.


By the way, I wonder if there is a way to tell gcc or clang that
OPENSSL_cleanse doesn't count as usage, without triggering other
warnings (such as not using the value written by by
OPENSSL_cleanse).

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 steffen at sdaoden.eu  Wed Jan  2 13:04:47 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Wed, 02 Jan 2019 14:04:47 +0100
Subject: [openssl-users] tls1_change_cipher_state
In-Reply-To: <73f913f0-c7d0-2805-d28c-2273fc8c2968@blastwave.org>
References: <CADqLbzKcP=-0Gurtv56NRxCuSj5Qpb24QrMrpV3hGMwH-ELm2g@mail.gmail.com>
 <7743a4b0-6dde-1c7e-0804-a71a0621a61b@openssl.org>
 <044bbe98-a19e-3bdc-87c6-1ae62d1d9589@wisemo.com>
 <73f913f0-c7d0-2805-d28c-2273fc8c2968@blastwave.org>
Message-ID: <20190102130447.NUpo-%steffen@sdaoden.eu>

Dennis Clarke wrote in <73f913f0-c7d0-2805-d28c-2273fc8c2968 at blastwave.org>:
 |On 1/2/19 5:14 AM, Jakob Bohm via openssl-users wrote:
 |> On 02/01/2019 10:41, Matt Caswell wrote:
 |>>
 |>> On 27/12/2018 08:37, Dmitry Belyavsky wrote:
 |>>> Hello,
 |>>>
 |>>> Am I right supposing that local variables tmp1, tmp2, iv1, and iv2 
 |>>> are unused in
 |>>> this function?
 |>> Looks that way. They should be removed.
 |>>
 |> 
 |> By the way, why aren't any of your test compilers configured to
 |> warn about unused local variables?? It's a common feature in many
 |> compilers and thus a free consistency check that can catch typos.
 |
 |Traditionally ( past four decades ) that was a feature provided by
 |something like 'lint' but I have not seen a lint picker lately other
 |than in the Oracle Studio compiler tools and it certainly isn't open
 |source in any way. Works very well however.

I am not using it, but i occasionally see Christos Zoulas making
commits to the NetBSD version of lint.  They also seem to keep the
code instrumented with comments like "falltrough" etc., for it.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From jain61 at gmail.com  Wed Jan  2 18:38:43 2019
From: jain61 at gmail.com (NJ)
Date: Wed, 2 Jan 2019 11:38:43 -0700 (MST)
Subject: [openssl-users] OpenSSL Read and Write in different threads
Message-ID: <1546454323865-0.post@n7.nabble.com>

Hi,

I am using OpenSSL in multi threaded application where I call SSL_read and
SSL_write from two different threads.
I am first establishing DTLS connection over wireless connection to
communicate and to send encrypted messages using OpenSSL.

I am successfully able to send and receive data but wanted to clear the
connection and re-establish the new connection using DTLS. So in other words
do not want the same session reuse.

I am facing Segmentation fault while doing SSL_free and trying to understand
the cause. I am having following questions -

1) OpenSSL manual states that SSL_read and SSL_write should happen from
single thread as the SSL CTX could not be used at the same time. But if the
application takes care of reading and writing synchronously or in safe
manner is it still an issue ?

2) What is the meaning of OpenSSL is multithread safe ? I found various
sample implementations which uses CRYPTO_set_id_callback API to implement
THREAD_setup and cleanup APIs used in DTLS based server implementation. I
believe these APIs prevents the multiple threads to simultaneously access
SSL_ctx at the same time ? But if it is true than why it is not preventing
the SSL_write and SSL_read issue.

3) How to enable debugging option in OpenSSL as I am using gdb but I do not
see any thing except the call stack during Seg Fault.

(gdb)
0xb6e3cc10 in dtls1_get_record() from /usr/lib/libssl.so.1.0.0

Thanks
NJ




 



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

From Neil.Craig at bbc.co.uk  Thu Jan  3 10:31:07 2019
From: Neil.Craig at bbc.co.uk (Neil Craig)
Date: Thu, 3 Jan 2019 10:31:07 +0000
Subject: [openssl-users] Session params output fails via cron
Message-ID: <D85394E7.170ED%Neil.Craig@bbc.co.uk>

Hi all

Does anyone know why openssl (silently) fails to write session data to a file when run from cron? (It works fine running manually) via e.g.: /path/to/openssl s_client -connect <host>:443 -servername <hostname> -tls1_3 ?sess_out

Running the same command but with ?tls1_2 works fine from cron. This feels like it might be a bug? Or am I missing something? There?s nothing obvious in the output that suggests failure.

Any help would be much appreciated, happy to provide more info and/or do more testing.

Cheers

Neil Craig
Lead Technical Architect | Online Technology Group
[cid:2EBC98B1-F146-4192-B967-20E7C30AA8C0]
Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org




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

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190103/808b9a97/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 60158DAA-E151-40BD-A3FB-C615340C7061[4].png
Type: image/png
Size: 1914 bytes
Desc: 60158DAA-E151-40BD-A3FB-C615340C7061[4].png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190103/808b9a97/attachment-0001.png>

From matt at openssl.org  Thu Jan  3 11:02:10 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 3 Jan 2019 11:02:10 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
Message-ID: <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>



On 03/01/2019 10:31, Neil Craig wrote:
> Hi all
> 
> Does anyone know why openssl (silently) fails to write session data to a file
> when run from cron? (It works fine running manually) via e.g.: /path/to/openssl
> s_client -connect <host>:443 -servername <hostname> -tls1_3 ?sess_out
> 
> Running the same command but with ?tls1_2 works fine from cron. This feels like
> it might be a bug? Or am I missing something? There?s nothing obvious in the
> output that suggests failure.
> 
> Any help would be much appreciated, happy to provide more info and/or do more
> testing.

TLSv1.3 sessions work differently to TLSv1.2 sessions. Significantly a TLSv1.2
session is established during the handshake. In TLSv1.3 the handshake completes
first. At that point data can be exchanged. At some later point (usually
immediately after the handshake has completed) the server may send to the client
new session ticket messages to create a session for later resumption.

When s_client is run non-interactively it will connect to the server and
complete the handshake. It will then read any data from stdin and send it to the
server. It will keep doing this until it hits EOF from stdin and then close the
connection.

My guess is that s_client is closing the connection before the server has had a
chance to send its new session tickets.

You might want to experiment with the -ign_eof option to s_client. This will
keep s_client running even after having hit EOF from stdin.

Matt


From Neil.Craig at bbc.co.uk  Thu Jan  3 11:52:36 2019
From: Neil.Craig at bbc.co.uk (Neil Craig)
Date: Thu, 3 Jan 2019 11:52:36 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
Message-ID: <D853A781.170F7%Neil.Craig@bbc.co.uk>

Thanks for the quick reply Matt. I tried -ign_eof but it had no effect,
sadly.

If anyone has any further suggestions, I?d appreciate it very much as this
is in aid of our automated released testing for TLS1.3 on our production
traffic management service.

Cheers

Neil Craig
Lead Technical Architect | Online Technology Group

Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org





On 03/01/2019, 11:02, "openssl-users on behalf of Matt Caswell"
<openssl-users-bounces at openssl.org on behalf of matt at openssl.org> wrote:

>
>
>On 03/01/2019 10:31, Neil Craig wrote:
>> Hi all
>>
>> Does anyone know why openssl (silently) fails to write session data to
>>a file
>> when run from cron? (It works fine running manually) via e.g.:
>>/path/to/openssl
>> s_client -connect <host>:443 -servername <hostname> -tls1_3 ?sess_out
>>
>> Running the same command but with ?tls1_2 works fine from cron. This
>>feels like
>> it might be a bug? Or am I missing something? There?s nothing obvious
>>in the
>> output that suggests failure.
>>
>> Any help would be much appreciated, happy to provide more info and/or
>>do more
>> testing.
>
>TLSv1.3 sessions work differently to TLSv1.2 sessions. Significantly a
>TLSv1.2
>session is established during the handshake. In TLSv1.3 the handshake
>completes
>first. At that point data can be exchanged. At some later point (usually
>immediately after the handshake has completed) the server may send to the
>client
>new session ticket messages to create a session for later resumption.
>
>When s_client is run non-interactively it will connect to the server and
>complete the handshake. It will then read any data from stdin and send it
>to the
>server. It will keep doing this until it hits EOF from stdin and then
>close the
>connection.
>
>My guess is that s_client is closing the connection before the server has
>had a
>chance to send its new session tickets.
>
>You might want to experiment with the -ign_eof option to s_client. This
>will
>keep s_client running even after having hit EOF from stdin.
>
>Matt
>
>--
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

From matt at openssl.org  Thu Jan  3 11:56:20 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 3 Jan 2019 11:56:20 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
Message-ID: <2f4cc8b5-cde7-ba88-d39d-65a055d427c0@openssl.org>



On 03/01/2019 10:31, Neil Craig wrote:
> Hi all
> 
> Does anyone know why openssl (silently) fails to write session data to a file
> when run from cron? (It works fine running manually) via e.g.: /path/to/openssl
> s_client -connect <host>:443 -servername <hostname> -tls1_3 ?sess_out

I assume you are actually supplying a filename after the "-sess_out" flag, right?

Matt


From Neil.Craig at bbc.co.uk  Thu Jan  3 12:09:43 2019
From: Neil.Craig at bbc.co.uk (Neil Craig)
Date: Thu, 3 Jan 2019 12:09:43 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <2f4cc8b5-cde7-ba88-d39d-65a055d427c0@openssl.org>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <2f4cc8b5-cde7-ba88-d39d-65a055d427c0@openssl.org>
Message-ID: <D853ABEF.17102%Neil.Craig@bbc.co.uk>

I am, yes. And as I say, it works fine interactively, it?s just via cron
that it fails.

Neil Craig
Lead Technical Architect | Online Technology Group

Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org





On 03/01/2019, 11:56, "openssl-users on behalf of Matt Caswell"
<openssl-users-bounces at openssl.org on behalf of matt at openssl.org> wrote:

>
>
>On 03/01/2019 10:31, Neil Craig wrote:
>> Hi all
>>
>> Does anyone know why openssl (silently) fails to write session data to
>>a file
>> when run from cron? (It works fine running manually) via e.g.:
>>/path/to/openssl
>> s_client -connect <host>:443 -servername <hostname> -tls1_3 ?sess_out
>
>I assume you are actually supplying a filename after the "-sess_out"
>flag, right?
>
>Matt
>
>--
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

From rsalz at akamai.com  Thu Jan  3 13:53:17 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 3 Jan 2019 13:53:17 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <D853ABEF.17102%Neil.Craig@bbc.co.uk>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <2f4cc8b5-cde7-ba88-d39d-65a055d427c0@openssl.org>
 <D853ABEF.17102%Neil.Craig@bbc.co.uk>
Message-ID: <23375AF4-3B46-4C64-98BF-7CF45364EB4E@akamai.com>

Two of the more common causes of cron failure are
	- Environment variable missing or has different value (PATH etc)
	- File permissions are different if running under root vs normal interactive user.

Hope that helps.



From jb-openssl at wisemo.com  Thu Jan  3 14:52:04 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 3 Jan 2019 15:52:04 +0100
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <D853A781.170F7%Neil.Craig@bbc.co.uk>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
Message-ID: <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>

On 03/01/2019 12:52, Neil Craig wrote:
> Thanks for the quick reply Matt. I tried -ign_eof but it had no effect,
> sadly.
>
> If anyone has any further suggestions, I?d appreciate it very much as this
> is in aid of our automated released testing for TLS1.3 on our production
> traffic management service.
>
> Cheers
>
> Neil Craig
> Lead Technical Architect | Online Technology Group
>
> Broadcast Centre, London W12 7TQ | BC4 A3
> Twitter: https://twitter.com/tdp_org
>
>
>
>
>
> On 03/01/2019, 11:02, "openssl-users on behalf of Matt Caswell"
> <openssl-users-bounces at openssl.org on behalf of matt at openssl.org> wrote:
>
>>
>> On 03/01/2019 10:31, Neil Craig wrote:
>>> Hi all
>>>
>>> Does anyone know why openssl (silently) fails to write session data to
>>> a file
>>> when run from cron? (It works fine running manually) via e.g.:
>>> /path/to/openssl
>>> s_client -connect <host>:443 -servername <hostname> -tls1_3 ?sess_out
>>>
>>> Running the same command but with ?tls1_2 works fine from cron. This
>>> feels like
>>> it might be a bug? Or am I missing something? There?s nothing obvious
>>> in the
>>> output that suggests failure.
>>>
>>> Any help would be much appreciated, happy to provide more info and/or
>>> do more
>>> testing.
>> TLSv1.3 sessions work differently to TLSv1.2 sessions. Significantly a
>> TLSv1.2
>> session is established during the handshake. In TLSv1.3 the handshake
>> completes
>> first. At that point data can be exchanged. At some later point (usually
>> immediately after the handshake has completed) the server may send to the
>> client
>> new session ticket messages to create a session for later resumption.
>>
>> When s_client is run non-interactively it will connect to the server and
>> complete the handshake. It will then read any data from stdin and send it
>> to the
>> server. It will keep doing this until it hits EOF from stdin and then
>> close the
>> connection.
>>
>> My guess is that s_client is closing the connection before the server has
>> had a
>> chance to send its new session tickets.
>>
>> You might want to experiment with the -ign_eof option to s_client. This
>> will
>> keep s_client running even after having hit EOF from stdin.
>>

Maybe cron jobs are run without a valid stdin handle (rather than a
readable handle at EOF), in which case explicitly adding "</dev/null"
may be a fix.

Or maybe there is a bug in how the new TLS1.3 code handles the
-ign_eof option early in the connection, here again testing with
"</dev/null" may help figuring out what is happening.

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 mikeb at preveil.com  Thu Jan  3 16:03:01 2019
From: mikeb at preveil.com (Mike Blaguszewski)
Date: Thu, 3 Jan 2019 11:03:01 -0500
Subject: [openssl-users] RNG behavior by default
Message-ID: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>

I am using the EVP API (version 1.1.1) for performing public key and symmetric key operations across a variety of platforms (macOS, Windows, Linux, iOS and Android). I am currently not doing anything to explicitly seed OpenSSL?s random number generator. My understanding is that the default behavior <https://www.openssl.org/blog/blog/2017/08/12/random/> should be cryptographically secure.

So my concerns are:
1. Whether I really can count on getting a high-entropy PRNG across these various platforms, without any explicit initialization.
2. If something goes wrong with PRNG initialization, that it will fail hard rather than fall back to something less secure. And if so how I detect such a failure.

Our current implementation uses libsodium, which relies on the usual system calls to generate entropy, so if I can count on OpenSSL always doing this then I?m happy. 

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

From Michael.Wojcik at microfocus.com  Thu Jan  3 16:55:56 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 3 Jan 2019 16:55:56 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
Message-ID: <MW2PR18MB20900C286CAB7CC0A0A2F873F98D0@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Jakob Bohm via openssl-users
> Sent: Thursday, January 03, 2019 09:52
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Session params output fails via cron
>
>
> Maybe cron jobs are run without a valid stdin handle (rather than a
> readable handle at EOF), in which case explicitly adding "</dev/null"
> may be a fix.
>
> Or maybe there is a bug in how the new TLS1.3 code handles the
> -ign_eof option early in the connection, here again testing with
> "</dev/null" may help figuring out what is happening.

Or if the OP is already redirecting / piping stdin in the cron job command line, something like this:

(cat input.txt; sleep 10) | openssl s_client ...

so that stdin remains open for a while after the actual input is exhausted. Maybe use that in conjunction with -ign_eof (shouldn't hurt, assuming the server closes its end of the connection when it's done).

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From andrewrobertschmidt at gmail.com  Thu Jan  3 20:18:05 2019
From: andrewrobertschmidt at gmail.com (Andy Schmidt)
Date: Thu, 3 Jan 2019 12:18:05 -0800
Subject: [openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()
Message-ID: <CAJf0N3_nh232j-YzJqUd3hb0+pAe_9T_x9Q_jt87CC75hiwwyA@mail.gmail.com>

I am adding the RFC 7919 Diffie-Hellman parameters to our TLS servers, and
I've found that these parameters won't pass OpenSSL's Diffie Hellman
parameter check function DH_check(). The return code is
DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears to fail
because the remainder of the prime divided by 24 is not 11. That its, p mod
24 != 11. I have a couple of questions:

What relationship between the prime p and the generator g is this checking
for? I thought that since p was a safe prime, as long as the generator g
wasn't 1 the only choice is between the full group and the subgroup of the
squares?

I would like to use DH_check() to attempt to ensure that Diffie Hellman
parameters haven't been tampered on operating systems that don't have
digital signatures for executable binaries.

The OpenSSL version in use is 1.0.2q.

Any help is greatly appreciated.
Andy Schmidt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190103/b49b6ced/attachment.html>

From kurt at roeckx.be  Thu Jan  3 21:45:35 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 3 Jan 2019 22:45:35 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
Message-ID: <20190103214535.GA12692@roeckx.be>

On Thu, Jan 03, 2019 at 11:03:01AM -0500, Mike Blaguszewski wrote:
> I am using the EVP API (version 1.1.1) for performing public key and symmetric key operations across a variety of platforms (macOS, Windows, Linux, iOS and Android). I am currently not doing anything to explicitly seed OpenSSL?s random number generator. My understanding is that the default behavior <https://www.openssl.org/blog/blog/2017/08/12/random/> should be cryptographically secure.
> 
> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these various platforms, without any explicit initialization.
> 2. If something goes wrong with PRNG initialization, that it will fail hard rather than fall back to something less secure. And if so how I detect such a failure.
> 
> Our current implementation uses libsodium, which relies on the usual system calls to generate entropy, so if I can count on OpenSSL always doing this then I?m happy. 

It will make use of system calls when available. Those are known
to provide system calls:
- Linux since 3.17
- Darwin since 16 (OSX 10.12, IOS 10.0).
- Solaris since 11.3
- OpenBSD since 5.6
- FreeBSD since 12.0 (1200061)

By default it will fall back to use something like /dev/urandom if
the system call is not available or returns an error.

On Windows we are also using the system provided entropy by using
function calls.

You do not need to do anything to initialize RNG. It will
automatically initiailze on first use.

It will hard fail when it's not able to get entropy.

Since it now reseeds from time to time, it can actually start to
fail after having run succesfully for some time. But it's very
unlikely that you would run into that, by default we should make
sure that we can always get entropy.


Kurt


From openssl-users at dukhovni.org  Thu Jan  3 21:54:19 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 3 Jan 2019 16:54:19 -0500
Subject: [openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()
In-Reply-To: <CAJf0N3_nh232j-YzJqUd3hb0+pAe_9T_x9Q_jt87CC75hiwwyA@mail.gmail.com>
References: <CAJf0N3_nh232j-YzJqUd3hb0+pAe_9T_x9Q_jt87CC75hiwwyA@mail.gmail.com>
Message-ID: <20190103215419.GC79754@straasha.imrryr.org>

On Jan 3, 2019, at 3:18 PM, Andy Schmidt <andrewrobertschmidt at gmail.com> wrote:

> I am adding the RFC 7919 Diffie-Hellman parameters to our TLS
> servers, and I've found that these parameters won't pass OpenSSL's
> Diffie Hellman parameter check function DH_check(). The return code
> is DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears
> to fail because the remainder of the prime divided by 24 is not 11.
> That its, p mod 24 != 11. I have a couple of questions:
>
> What relationship between the prime p and the generator g is this checking
> for? I thought that since p was a safe prime, as long as the generator g
> wasn't 1 the only choice is between the full group and the subgroup of the
> squares?

For a safe prime $p = 2q + 1$ with $q$ also prime, the order of $2$ is $q$
provided $2$ is quadratic residue mod $p$, which, by quadratic reciprocity,
considering that $q$ is odd and not a multiple of 3 for any primes of interest,
gives $p \cong 23 mod 24$, which then gives $q \cong 11 mod 12$.

The order of $2$ is $2q$ when $2$ is not a quadratic residue mod $p$, which
then gives $p \cong 3 mod 8$ and so taking mod 3 into account
$p \cong 11 mod 24$.

So it seems that the check in question wants $2$ to generates the
full multiplicative group of order $2q$, rather than the prime-order
subgroup of quadratic residues of order $q$.

> I would like to use DH_check() to attempt to ensure that Diffie Hellman
> parameters haven't been tampered on operating systems that don't have
> digital signatures for executable binaries.
> 
> The OpenSSL version in use is 1.0.2q.

The primes in RFC7919 are all 23 mod 24, which has $o(2) = q$ rather
than $o(2) = 2q$.  This is actually fine, perhaps even better, and
the code in DH_check() is too strict in wanting the generator to
generate the full multiplicative group mod $p$, rather than just
the subgroup of of quadratic residues of order $q$.

So a pull request for OpenSSL would be welcome.  Given that we
should not care whether the order of $g$ is $q$ or $2q$, it suffices
to just check that $p$ is plausibly prime and $q = (p-1)/2 == (p
>> 1)$ is plausibly prime.  The special checks for $g == 2, 3 and
5$ should be removed.  For 1.1.1 the patch would be something like:

--- a/crypto/dh/dh_check.c
+++ b/crypto/dh/dh_check.c
@@ -88,8 +88,6 @@ int DH_check_ex(const DH *dh)
         DHerr(DH_F_DH_CHECK_EX, DH_R_CHECK_INVALID_Q_VALUE);
     if ((errflags & DH_CHECK_INVALID_J_VALUE) != 0)
         DHerr(DH_F_DH_CHECK_EX, DH_R_CHECK_INVALID_J_VALUE);
-    if ((errflags & DH_UNABLE_TO_CHECK_GENERATOR) != 0)
-        DHerr(DH_F_DH_CHECK_EX, DH_R_UNABLE_TO_CHECK_GENERATOR);
     if ((errflags & DH_CHECK_P_NOT_PRIME) != 0)
         DHerr(DH_F_DH_CHECK_EX, DH_R_CHECK_P_NOT_PRIME);
     if ((errflags & DH_CHECK_P_NOT_SAFE_PRIME) != 0)
@@ -140,20 +138,7 @@ int DH_check(const DH *dh, int *ret)
         if (dh->j && BN_cmp(dh->j, t1))
             *ret |= DH_CHECK_INVALID_J_VALUE;
 
-    } else if (BN_is_word(dh->g, DH_GENERATOR_2)) {
-        l = BN_mod_word(dh->p, 24);
-        if (l == (BN_ULONG)-1)
-            goto err;
-        if (l != 11)
-            *ret |= DH_NOT_SUITABLE_GENERATOR;
-    } else if (BN_is_word(dh->g, DH_GENERATOR_5)) {
-        l = BN_mod_word(dh->p, 10);
-        if (l == (BN_ULONG)-1)
-            goto err;
-        if ((l != 3) && (l != 7))
-            *ret |= DH_NOT_SUITABLE_GENERATOR;
-    } else
-        *ret |= DH_UNABLE_TO_CHECK_GENERATOR;
+    }
 
     r = BN_is_prime_ex(dh->p, BN_prime_checks, ctx, NULL);
     if (r < 0)

-- 
	Viktor.


From kurt at roeckx.be  Thu Jan  3 21:59:42 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 3 Jan 2019 22:59:42 +0100
Subject: [openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()
In-Reply-To: <CAJf0N3_nh232j-YzJqUd3hb0+pAe_9T_x9Q_jt87CC75hiwwyA@mail.gmail.com>
References: <CAJf0N3_nh232j-YzJqUd3hb0+pAe_9T_x9Q_jt87CC75hiwwyA@mail.gmail.com>
Message-ID: <20190103215941.GB12692@roeckx.be>

On Thu, Jan 03, 2019 at 12:18:05PM -0800, Andy Schmidt wrote:
> I am adding the RFC 7919 Diffie-Hellman parameters to our TLS servers, and
> I've found that these parameters won't pass OpenSSL's Diffie Hellman
> parameter check function DH_check(). The return code is
> DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears to fail
> because the remainder of the prime divided by 24 is not 11. That its, p mod
> 24 != 11. I have a couple of questions:
> 
> What relationship between the prime p and the generator g is this checking
> for? I thought that since p was a safe prime, as long as the generator g
> wasn't 1 the only choice is between the full group and the subgroup of the
> squares?
> 
> I would like to use DH_check() to attempt to ensure that Diffie Hellman
> parameters haven't been tampered on operating systems that don't have
> digital signatures for executable binaries.

See:
https://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11


Kurt


From andrewrobertschmidt at gmail.com  Thu Jan  3 23:52:45 2019
From: andrewrobertschmidt at gmail.com (Andy Schmidt)
Date: Thu, 3 Jan 2019 15:52:45 -0800
Subject: [openssl-users] RFC 7919 DH parameters and OpenSSL DH_check()
In-Reply-To: <20190103215941.GB12692@roeckx.be>
References: <CAJf0N3_nh232j-YzJqUd3hb0+pAe_9T_x9Q_jt87CC75hiwwyA@mail.gmail.com>
 <20190103215941.GB12692@roeckx.be>
Message-ID: <CAJf0N3-pGSx9OsnoY-01=9irjFdDaBWyz+q7mB5=2v80hMkAqQ@mail.gmail.com>

Thank you Victor and Kurt for your quick replies! They were very helpful

Best,
Andy Schmidt

On Thu, Jan 3, 2019 at 2:00 PM Kurt Roeckx <kurt at roeckx.be> wrote:

> On Thu, Jan 03, 2019 at 12:18:05PM -0800, Andy Schmidt wrote:
> > I am adding the RFC 7919 Diffie-Hellman parameters to our TLS servers,
> and
> > I've found that these parameters won't pass OpenSSL's Diffie Hellman
> > parameter check function DH_check(). The return code is
> > DH_NOT_SUITABLE_GENERATOR. Looking at the source code, it appears to fail
> > because the remainder of the prime divided by 24 is not 11. That its, p
> mod
> > 24 != 11. I have a couple of questions:
> >
> > What relationship between the prime p and the generator g is this
> checking
> > for? I thought that since p was a safe prime, as long as the generator g
> > wasn't 1 the only choice is between the full group and the subgroup of
> the
> > squares?
> >
> > I would like to use DH_check() to attempt to ensure that Diffie Hellman
> > parameters haven't been tampered on operating systems that don't have
> > digital signatures for executable binaries.
>
> See:
>
> https://crypto.stackexchange.com/questions/12961/diffie-hellman-parameter-check-when-g-2-must-p-mod-24-11
>
>
> Kurt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190103/d03ceca2/attachment-0001.html>

From Neil.Craig at bbc.co.uk  Fri Jan  4 10:58:40 2019
From: Neil.Craig at bbc.co.uk (Neil Craig)
Date: Fri, 4 Jan 2019 10:58:40 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
Message-ID: <D854EBE7.17182%Neil.Craig@bbc.co.uk>

Sorry for the delay.

Jakob - you?re a star! Thanks so much, your suggestion works. So I added
</dev/null to now give:


/path/to/openssl s_client -connect <host>:443 -servername <hostname>
-tls1_3 ?sess_out </dev/null


Actually, I also redirect stdin and stderr to a ?log? file for debugging
after the above but that?s not relevant here.


I?m wondering if this would be something worthy of attention in openssl?

I?ll document it on my blog in case anyone else comes across the same
issue.

Thanks everyone for your suggestions and time spent, really appreciated!

Cheers

Neil Craig
Lead Technical Architect | Online Technology Group

Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org





On 03/01/2019, 14:52, "openssl-users on behalf of Jakob Bohm via
openssl-users" <openssl-users-bounces at openssl.org on behalf of
openssl-users at openssl.org> wrote:

>On 03/01/2019 12:52, Neil Craig wrote:
>> Thanks for the quick reply Matt. I tried -ign_eof but it had no effect,
>> sadly.
>>
>> If anyone has any further suggestions, I?d appreciate it very much as
>>this
>> is in aid of our automated released testing for TLS1.3 on our production
>> traffic management service.
>>
>> Cheers
>>
>> Neil Craig
>> Lead Technical Architect | Online Technology Group
>>
>> Broadcast Centre, London W12 7TQ | BC4 A3
>> Twitter: https://twitter.com/tdp_org
>>
>>
>>
>>
>>
>> On 03/01/2019, 11:02, "openssl-users on behalf of Matt Caswell"
>> <openssl-users-bounces at openssl.org on behalf of matt at openssl.org> wrote:
>>
>>>
>>> On 03/01/2019 10:31, Neil Craig wrote:
>>>> Hi all
>>>>
>>>> Does anyone know why openssl (silently) fails to write session data to
>>>> a file
>>>> when run from cron? (It works fine running manually) via e.g.:
>>>> /path/to/openssl
>>>> s_client -connect <host>:443 -servername <hostname> -tls1_3 ?sess_out
>>>>
>>>> Running the same command but with ?tls1_2 works fine from cron. This
>>>> feels like
>>>> it might be a bug? Or am I missing something? There?s nothing obvious
>>>> in the
>>>> output that suggests failure.
>>>>
>>>> Any help would be much appreciated, happy to provide more info and/or
>>>> do more
>>>> testing.
>>> TLSv1.3 sessions work differently to TLSv1.2 sessions. Significantly a
>>> TLSv1.2
>>> session is established during the handshake. In TLSv1.3 the handshake
>>> completes
>>> first. At that point data can be exchanged. At some later point
>>>(usually
>>> immediately after the handshake has completed) the server may send to
>>>the
>>> client
>>> new session ticket messages to create a session for later resumption.
>>>
>>> When s_client is run non-interactively it will connect to the server
>>>and
>>> complete the handshake. It will then read any data from stdin and send
>>>it
>>> to the
>>> server. It will keep doing this until it hits EOF from stdin and then
>>> close the
>>> connection.
>>>
>>> My guess is that s_client is closing the connection before the server
>>>has
>>> had a
>>> chance to send its new session tickets.
>>>
>>> You might want to experiment with the -ign_eof option to s_client. This
>>> will
>>> keep s_client running even after having hit EOF from stdin.
>>>
>
>Maybe cron jobs are run without a valid stdin handle (rather than a
>readable handle at EOF), in which case explicitly adding "</dev/null"
>may be a fix.
>
>Or maybe there is a bug in how the new TLS1.3 code handles the
>-ign_eof option early in the connection, here again testing with
>"</dev/null" may help figuring out what is happening.
>
>Enjoy
>
>Jakob
>--
>Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
>This public discussion message is non-binding and may contain errors.
>WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>--
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

From Neil.Craig at bbc.co.uk  Fri Jan  4 11:30:40 2019
From: Neil.Craig at bbc.co.uk (Neil Craig)
Date: Fri, 4 Jan 2019 11:30:40 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <D854EBE7.17182%Neil.Craig@bbc.co.uk>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
Message-ID: <D854F30B.1718F%Neil.Craig@bbc.co.uk>

Actually, my apologies, I missed -ign_eof - that is also needed, so the
?fixed? request is:

/path/to/openssl s_client -connect <host>:443 -servername <hostname>
-tls1_3 ?sess_out -ign_eof </dev/null


Cheers

Neil Craig
Lead Technical Architect | Online Technology Group

Broadcast Centre, London W12 7TQ | BC4 A3
Twitter: https://twitter.com/tdp_org





On 04/01/2019, 10:58, "Neil Craig" <Neil.Craig at bbc.co.uk> wrote:

>Sorry for the delay.
>
>Jakob - you?re a star! Thanks so much, your suggestion works. So I added
></dev/null to now give:
>
>
>/path/to/openssl s_client -connect <host>:443 -servername <hostname>
>-tls1_3 ?sess_out </dev/null
>
>
>Actually, I also redirect stdin and stderr to a ?log? file for debugging
>after the above but that?s not relevant here.
>
>
>I?m wondering if this would be something worthy of attention in openssl?
>
>I?ll document it on my blog in case anyone else comes across the same
>issue.
>
>Thanks everyone for your suggestions and time spent, really appreciated!
>
>Cheers
>
>Neil Craig
>Lead Technical Architect | Online Technology Group
>
>Broadcast Centre, London W12 7TQ | BC4 A3
>Twitter: https://twitter.com/tdp_org
>
>
>
>
>
>On 03/01/2019, 14:52, "openssl-users on behalf of Jakob Bohm via
>openssl-users" <openssl-users-bounces at openssl.org on behalf of
>openssl-users at openssl.org> wrote:
>
>>On 03/01/2019 12:52, Neil Craig wrote:
>>> Thanks for the quick reply Matt. I tried -ign_eof but it had no effect,
>>> sadly.
>>>
>>> If anyone has any further suggestions, I?d appreciate it very much as
>>>this
>>> is in aid of our automated released testing for TLS1.3 on our
>>>production
>>> traffic management service.
>>>
>>> Cheers
>>>
>>> Neil Craig
>>> Lead Technical Architect | Online Technology Group
>>>
>>> Broadcast Centre, London W12 7TQ | BC4 A3
>>> Twitter: https://twitter.com/tdp_org
>>>
>>>
>>>
>>>
>>>
>>> On 03/01/2019, 11:02, "openssl-users on behalf of Matt Caswell"
>>> <openssl-users-bounces at openssl.org on behalf of matt at openssl.org>
>>>wrote:
>>>
>>>>
>>>> On 03/01/2019 10:31, Neil Craig wrote:
>>>>> Hi all
>>>>>
>>>>> Does anyone know why openssl (silently) fails to write session data
>>>>>to
>>>>> a file
>>>>> when run from cron? (It works fine running manually) via e.g.:
>>>>> /path/to/openssl
>>>>> s_client -connect <host>:443 -servername <hostname> -tls1_3 ?sess_out
>>>>>
>>>>> Running the same command but with ?tls1_2 works fine from cron. This
>>>>> feels like
>>>>> it might be a bug? Or am I missing something? There?s nothing obvious
>>>>> in the
>>>>> output that suggests failure.
>>>>>
>>>>> Any help would be much appreciated, happy to provide more info and/or
>>>>> do more
>>>>> testing.
>>>> TLSv1.3 sessions work differently to TLSv1.2 sessions. Significantly a
>>>> TLSv1.2
>>>> session is established during the handshake. In TLSv1.3 the handshake
>>>> completes
>>>> first. At that point data can be exchanged. At some later point
>>>>(usually
>>>> immediately after the handshake has completed) the server may send to
>>>>the
>>>> client
>>>> new session ticket messages to create a session for later resumption.
>>>>
>>>> When s_client is run non-interactively it will connect to the server
>>>>and
>>>> complete the handshake. It will then read any data from stdin and send
>>>>it
>>>> to the
>>>> server. It will keep doing this until it hits EOF from stdin and then
>>>> close the
>>>> connection.
>>>>
>>>> My guess is that s_client is closing the connection before the server
>>>>has
>>>> had a
>>>> chance to send its new session tickets.
>>>>
>>>> You might want to experiment with the -ign_eof option to s_client.
>>>>This
>>>> will
>>>> keep s_client running even after having hit EOF from stdin.
>>>>
>>
>>Maybe cron jobs are run without a valid stdin handle (rather than a
>>readable handle at EOF), in which case explicitly adding "</dev/null"
>>may be a fix.
>>
>>Or maybe there is a bug in how the new TLS1.3 code handles the
>>-ign_eof option early in the connection, here again testing with
>>"</dev/null" may help figuring out what is happening.
>>
>>Enjoy
>>
>>Jakob
>>--
>>Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>>Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
>>This public discussion message is non-binding and may contain errors.
>>WiseMo - Remote Service Management for PCs, Phones and Embedded
>>
>>--
>>openssl-users mailing list
>>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

From Matthias.St.Pierre at ncp-e.com  Fri Jan  4 12:46:11 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Fri, 4 Jan 2019 12:46:11 +0000
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
Message-ID: <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>

> So my concerns are:
> 1. Whether I really can count on getting a high-entropy PRNG across these various platforms, without any explicit initialization.

Yes, for the mentioned platforms, the default configuration is `--with-rand-seed=os`, which means the DRBG automatically seeds
and reseeds using os entropy sources.

2. If something goes wrong with PRNG initialization, that it will fail hard rather than fall back to something less secure. And if so how I detect such a failure.

If the (re-)seeding fails, the DRBG enters an error state. When you try to generate random bytes it will detect the error state and try
automatically to heal the error state by reinstantiating. But if reseeding fails, it will return and error code and not generate any pseudo random bytes.

Citing from the manual pages:

	OpenSSL comes with a default implementation of the RAND API which is based on the
	deterministic random bit generator (DRBG) model as described in [NIST SP 800-90A Rev. 1].
	The default random generator will initialize automatically on first use and will be fully functional
	without having to be initialized ('seeded') explicitly. It seeds and reseeds itself automatically using
	trusted random sources provided by the operating system.

	As a normal application developer, you do not have to worry about any details, just use RAND_bytes(3)
	to obtain random data. Having said that, there is one important rule to obey: Always check the error
	return value of RAND_bytes(3) and do not take randomness for granted.

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

(See also https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html)

Matthias


From steffen at sdaoden.eu  Fri Jan  4 13:48:48 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Fri, 04 Jan 2019 14:48:48 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
Message-ID: <20190104134848.7zm4s%steffen@sdaoden.eu>

Dr. Matthias St. Pierre wrote in <450169f8ca7c43d1841c4c8052e78c72 at Ex13.\
ncp.local>:
 |> So my concerns are:
 |> 1. Whether I really can count on getting a high-entropy PRNG across \
 |> these various platforms, without any explicit initialization.
 |
 |Yes, for the mentioned platforms, the default configuration is `--with-r\
 |and-seed=os`, which means the DRBG automatically seeds
 |and reseeds using os entropy sources.
 |
 |2. If something goes wrong with PRNG initialization, that it will fail \
 |hard rather than fall back to something less secure. And if so how \
 |I detect such a failure.
 |
 |If the (re-)seeding fails, the DRBG enters an error state. When you \
 |try to generate random bytes it will detect the error state and try
 |automatically to heal the error state by reinstantiating. But if reseeding \
 |fails, it will return and error code and not generate any pseudo random \
 |bytes.
 |
 |Citing from the manual pages:
 ...
 | As a normal application developer, you do not have to worry about \
 | any details, just use RAND_bytes(3)
 | to obtain random data. Having said that, there is one important rule \
 | to obey: Always check the error
 | return value of RAND_bytes(3) and do not take randomness for granted.
 |
 | https://www.openssl.org/docs/man1.1.1/man7/RAND.html

That is new however, _imho_.  The wording of RAND_bytes(3) (still)
says that "an error occurs [.if.] not [been] seeded with enough
[data]", and RAND_status(3) returns 1 if the PRNG "has been seeded
with enough data".  So if it is seeded it is seeded, in my
understanding anything further on up the road only mixes in noise
(which likely will undergo further maths and be stirred into the
pool, i have not looked, actually).  I do not test RAND_bytes(3)
return (yet), because i have ensured the PRNG is sufficiently
seeded, and RAND_status(3) returns success, before RAND_bytes(3)
is used the first time.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From rsalz at akamai.com  Fri Jan  4 17:15:49 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 4 Jan 2019 17:15:49 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <D854EBE7.17182%Neil.Craig@bbc.co.uk>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
Message-ID: <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>

    Jakob - you?re a star! Thanks so much, your suggestion works. So I added
    </dev/null to now give:
...
    I?m wondering if this would be something worthy of attention in openssl?
   
Maybe open an issue to catch this.  Seems like the apps could check and redirect to /dev/null if the FD isn't valid.


From openssl at foocrypt.net  Fri Jan  4 17:27:15 2019
From: openssl at foocrypt.net (openssl at foocrypt.net)
Date: Sat, 5 Jan 2019 04:27:15 +1100
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
 <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
Message-ID: <2088979A-B657-4FE0-BBCC-A26B646AE35F@foocrypt.net>

Just a thought ?

Do you get the same error when running the command from within a shell script from cron [ in either bash or Korn or one of the other sh?s ] or by executing the shell script from the command line ?

What are your default environment settings and shell for the user you are executing the commands via cron ?

> On 5 Jan 2019, at 04:15, Salz, Rich via openssl-users <openssl-users at openssl.org> wrote:
> 
>    Jakob - you?re a star! Thanks so much, your suggestion works. So I added
>    </dev/null to now give:
> ...
>    I?m wondering if this would be something worthy of attention in openssl?
> 
> Maybe open an issue to catch this.  Seems like the apps could check and redirect to /dev/null if the FD isn't valid.
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From jb-openssl at wisemo.com  Fri Jan  4 18:01:30 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 4 Jan 2019 19:01:30 +0100
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
 <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
Message-ID: <57d89133-ef59-6961-7941-34efb82d8240@wisemo.com>

On 04/01/2019 18:15, Salz, Rich wrote:
>      Jakob - you?re a star! Thanks so much, your suggestion works. So I added
>      </dev/null to now give:
> ...
>      I?m wondering if this would be something worthy of attention in openssl?
>     
> Maybe open an issue to catch this.  Seems like the apps could check and redirect to /dev/null if the FD isn't valid.
> 

Perhaps it is simpler to just accept invalid stdin if -ignoreeof is set.

In particular, this avoids dealing with OS specific names of /dev/null,
as well as chroot jails without that character device.


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 kurt at roeckx.be  Fri Jan  4 18:07:35 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 4 Jan 2019 19:07:35 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190104134848.7zm4s%steffen@sdaoden.eu>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu>
Message-ID: <20190104180735.GA25041@roeckx.be>

On Fri, Jan 04, 2019 at 02:48:48PM +0100, Steffen Nurpmeso wrote:
> Dr. Matthias St. Pierre wrote in <450169f8ca7c43d1841c4c8052e78c72 at Ex13.\
> ncp.local>:
>  |> So my concerns are:
>  |> 1. Whether I really can count on getting a high-entropy PRNG across \
>  |> these various platforms, without any explicit initialization.
>  |
>  |Yes, for the mentioned platforms, the default configuration is `--with-r\
>  |and-seed=os`, which means the DRBG automatically seeds
>  |and reseeds using os entropy sources.
>  |
>  |2. If something goes wrong with PRNG initialization, that it will fail \
>  |hard rather than fall back to something less secure. And if so how \
>  |I detect such a failure.
>  |
>  |If the (re-)seeding fails, the DRBG enters an error state. When you \
>  |try to generate random bytes it will detect the error state and try
>  |automatically to heal the error state by reinstantiating. But if reseeding \
>  |fails, it will return and error code and not generate any pseudo random \
>  |bytes.
>  |
>  |Citing from the manual pages:
>  ...
>  | As a normal application developer, you do not have to worry about \
>  | any details, just use RAND_bytes(3)
>  | to obtain random data. Having said that, there is one important rule \
>  | to obey: Always check the error
>  | return value of RAND_bytes(3) and do not take randomness for granted.
>  |
>  | https://www.openssl.org/docs/man1.1.1/man7/RAND.html
> 
> That is new however, _imho_.  The wording of RAND_bytes(3) (still)
> says that "an error occurs [.if.] not [been] seeded with enough
> [data]", and RAND_status(3) returns 1 if the PRNG "has been seeded
> with enough data".  So if it is seeded it is seeded, in my
> understanding anything further on up the road only mixes in noise
> (which likely will undergo further maths and be stirred into the
> pool, i have not looked, actually).  I do not test RAND_bytes(3)
> return (yet), because i have ensured the PRNG is sufficiently
> seeded, and RAND_status(3) returns success, before RAND_bytes(3)
> is used the first time.

For 1.1.0 and older that works, because they do not reseed. Since
1.1.1 it does reseed, and if the reseed fails, it will go to an
error state. So yes, this is new behavior.

The RAND_bytes and RAND_status manpages can clearly be improved.
Since you always have to check RAND_bytes's return value now,
RAND_status is mostly useless.


Kurt


From openssl at jordan.maileater.net  Fri Jan  4 18:16:03 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Fri, 4 Jan 2019 18:16:03 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
 <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
Message-ID: <010101681a14473a-b5370c04-ae2c-4cbe-bce7-2b3385938cce-000000@us-west-2.amazonses.com>

On 1/4/2019 9:15 AM, Salz, Rich via openssl-users wrote:
>     Jakob - you?re a star! Thanks so much, your suggestion works. So I added
>     </dev/null to now give:
> ...
>     I?m wondering if this would be something worthy of attention in openssl?
>    
> Maybe open an issue to catch this.  Seems like the apps could check and redirect to /dev/null if the FD isn't valid.


All kinds of Bad Stuff will happen if file descriptors {0,1,2} aren't
set up right.? Start with, say, an application opening a database,
getting fd? 2 because that happens to be the first available, and then
for some reason writing an error message to stderr.

I'd be shocked if cron starts an application without *something*
reasonable on {0,1,2}.? I'd consider it to be a very serious bug in
cron.? (I can't speak to anything else, but Solaris cron has 0 on
/dev/null and 1 and 2 leading to a temporary file that gets mailed to
the user if non-empty.)

Whether an application should try to cope with such a broken
environment... shrug.? Few if any do.

If you want to, what you want is something like:

	int fd;
	do {
		fd = open("/dev/null", O_RDWR);
	} while (fd < 3);
	close(fd);

(That's strictly not quite right, since it leaves 0 open writable and 1
and 2 open readable, but that's pretty harmless.)

-- 
Jordan Brown, Oracle Solaris

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

From Michael.Wojcik at microfocus.com  Fri Jan  4 21:04:02 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 4 Jan 2019 21:04:02 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <010101681a14473a-b5370c04-ae2c-4cbe-bce7-2b3385938cce-000000@us-west-2.amazonses.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
 <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
 <010101681a14473a-b5370c04-ae2c-4cbe-bce7-2b3385938cce-000000@us-west-2.amazonses.com>
Message-ID: <MW2PR18MB2090C5FE016931BBC166B133F98E0@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown
> Sent: Friday, January 04, 2019 13:16

> If you want to, what you want is something like:
>       int fd;
>       do {
>               fd = open("/dev/null", O_RDWR);
>       } while (fd < 3);
>       close(fd);
> (That's strictly not quite right, since it leaves 0 open writable and 1 and 2 open readable,
> but that's pretty harmless.)

Behavior is unfortunate if open fails, e.g. because the NFILES limit is reached, or because /dev/null is inaccessible (e.g. due to a poorly-configured chroot). You'd be better off with (fd >= 0 && fd < 3).

Since source bytes are cheap, though, and there are at most three opens to be done, I'd just do it explicitly for the three stdio descriptors. That would also make the intention clear. (Yes, the intention of your version is clear to old UNIX hands. It might not be to other people.)

I'm ignoring portability considerations, since I personally don't think this would be a great thing to implement in the apps, so I'm not going to be submitting a PR for it.

--
Michael Wojcik
Distinguished Engineer, Micro Focus





From paul.dale at oracle.com  Fri Jan  4 22:45:37 2019
From: paul.dale at oracle.com (Dr Paul Dale)
Date: Sat, 5 Jan 2019 08:45:37 +1000
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
Message-ID: <23F7C37B-ED4E-4FC9-A773-CDD07B199D1D@oracle.com>

I know that iOS (which was listed) has a good randomness source (SecRandomCopyBytes <https://developer.apple.com/documentation/security/1399291-secrandomcopybytes>) but I don?t think OpenSSL uses it yet.
I?m not sure about the quality of Android?s sources, but would expect them to be decent.


Pauli


> On 4 Jan 2019, at 10:46 pm, Dr. Matthias St. Pierre <Matthias.St.Pierre at ncp-e.com> wrote:
> 
>> So my concerns are:
>> 1. Whether I really can count on getting a high-entropy PRNG across these various platforms, without any explicit initialization.
> 
> Yes, for the mentioned platforms, the default configuration is `--with-rand-seed=os`, which means the DRBG automatically seeds
> and reseeds using os entropy sources.
> 
> 2. If something goes wrong with PRNG initialization, that it will fail hard rather than fall back to something less secure. And if so how I detect such a failure.
> 
> If the (re-)seeding fails, the DRBG enters an error state. When you try to generate random bytes it will detect the error state and try
> automatically to heal the error state by reinstantiating. But if reseeding fails, it will return and error code and not generate any pseudo random bytes.
> 
> Citing from the manual pages:
> 
> 	OpenSSL comes with a default implementation of the RAND API which is based on the
> 	deterministic random bit generator (DRBG) model as described in [NIST SP 800-90A Rev. 1].
> 	The default random generator will initialize automatically on first use and will be fully functional
> 	without having to be initialized ('seeded') explicitly. It seeds and reseeds itself automatically using
> 	trusted random sources provided by the operating system.
> 
> 	As a normal application developer, you do not have to worry about any details, just use RAND_bytes(3)
> 	to obtain random data. Having said that, there is one important rule to obey: Always check the error
> 	return value of RAND_bytes(3) and do not take randomness for granted.
> 
> 	https://www.openssl.org/docs/man1.1.1/man7/RAND.html
> 
> (See also https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html)
> 
> Matthias
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

From Matthias.St.Pierre at ncp-e.com  Sat Jan  5 00:50:42 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sat, 5 Jan 2019 00:50:42 +0000
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190104180735.GA25041@roeckx.be>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
Message-ID: <b89b48fce6b54eadaba632402d789ee9@Ex13.ncp.local>


I agree with Kurt, except for one point:

> The RAND_bytes and RAND_status manpages can clearly be improved.

Both manpages got an update during the DRBG rewrite (by me) and I don't
see any contradiction. You bring it to the point yourself:

> So _IF_ it is seeded it is seeded...

It is true that the DRBG will automatically seed, but it is equally true
that it can still end up in an unseeded (error) state, if no suitable entropy
source is available. And since this can also happen during reseeding (which
in particular is enforced after a fork), it is always necessary to check the return
value of the RAND_bytes() function. Because in the error state, the buffer is not
filled at all.

Matthias



From openssl at jordan.maileater.net  Sat Jan  5 02:01:11 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Sat, 5 Jan 2019 02:01:11 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <MW2PR18MB2090C5FE016931BBC166B133F98E0@MW2PR18MB2090.namprd18.prod.outlook.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
 <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
 <010101681a14473a-b5370c04-ae2c-4cbe-bce7-2b3385938cce-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090C5FE016931BBC166B133F98E0@MW2PR18MB2090.namprd18.prod.outlook.com>
Message-ID: <010101681bbe201f-f1989a35-d189-4af5-840e-0e3fda67d2ec-000000@us-west-2.amazonses.com>

On 1/4/2019 1:04 PM, Michael Wojcik wrote:
> Behavior is unfortunate if open fails, e.g. because the NFILES limit is reached, or because /dev/null is inaccessible (e.g. due to a poorly-configured chroot). You'd be better off with (fd >= 0 && fd < 3).

Yes.? Oops.

-- 
Jordan Brown, Oracle Solaris

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

From kurt at roeckx.be  Sat Jan  5 11:02:24 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 5 Jan 2019 12:02:24 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <23F7C37B-ED4E-4FC9-A773-CDD07B199D1D@oracle.com>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <23F7C37B-ED4E-4FC9-A773-CDD07B199D1D@oracle.com>
Message-ID: <20190105110223.GA15406@roeckx.be>

On Sat, Jan 05, 2019 at 08:45:37AM +1000, Dr Paul Dale wrote:
> I?m not sure about the quality of Android?s sources, but would expect them to be decent.

Android is just a Linux kernel. It always had /dev/urandom. Oreo
(8.0) requires at least Linux kernel 4.4. There were no
requirements for the kernel version before this. Some devices with
Marshmallow (6.0) will run a Linux kernel with 3.18, but not all
of them.


Kurt


From steffen at sdaoden.eu  Sat Jan  5 19:33:18 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 05 Jan 2019 20:33:18 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190104180735.GA25041@roeckx.be>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
Message-ID: <20190105193318.TPV_w%steffen@sdaoden.eu>

Good evening.

Please excuse the late reply.

Kurt Roeckx wrote in <20190104180735.GA25041 at roeckx.be>:
 |On Fri, Jan 04, 2019 at 02:48:48PM +0100, Steffen Nurpmeso wrote:
 |> Dr. Matthias St. Pierre wrote in <450169f8ca7c43d1841c4c8052e78c72 at Ex13.\
 |> ncp.local>:
 ...
 |>|2. If something goes wrong with PRNG initialization, that it will fail \
 |>|hard rather than fall back to something less secure. And if so how \
 |>|I detect such a failure.
 |>|
 |>|If the (re-)seeding fails, the DRBG enters an error state. When you \
 |>|try to generate random bytes it will detect the error state and try
 |>|automatically to heal the error state by reinstantiating. But if \
 |>|reseeding \
 |>|fails, it will return and error code and not generate any pseudo random \
 |>|bytes.
 |>|
 |>|Citing from the manual pages:
 |>  ...
 |>| As a normal application developer, you do not have to worry about \
 |>| any details, just use RAND_bytes(3)
 |>| to obtain random data. Having said that, there is one important rule \
 |>| to obey: Always check the error
 |>| return value of RAND_bytes(3) and do not take randomness for granted.
 |>|
 |>| https://www.openssl.org/docs/man1.1.1/man7/RAND.html
 |> 
 |> That is new however, _imho_.  The wording of RAND_bytes(3) (still)
 |> says that "an error occurs [.if.] not [been] seeded with enough
 |> [data]", and RAND_status(3) returns 1 if the PRNG "has been seeded
 |> with enough data".  So if it is seeded it is seeded, in my
 |> understanding anything further on up the road only mixes in noise
 |> (which likely will undergo further maths and be stirred into the
 |> pool, i have not looked, actually).  I do not test RAND_bytes(3)
 |> return (yet), because i have ensured the PRNG is sufficiently
 |> seeded, and RAND_status(3) returns success, before RAND_bytes(3)
 |> is used the first time.
 |
 |For 1.1.0 and older that works, because they do not reseed. Since
 |1.1.1 it does reseed, and if the reseed fails, it will go to an
 |error state. So yes, this is new behavior.

Thanks.  Well this is good to know, i have to think about how
i will deal with this.

(I am also really interested and will look into OpenSSL to see if
the abort() that seems to happen if the initial seed fails is in
a linker-resolved constructor, and if not, why later failures do
not also abort.  Yes, while i am going, the full truth is that
i do not like it, i do not like that possibly a constructor call
is made for something that is possibly not needed, if it is done
like that, that someone simply aborts because of a some internal
PRNG, especially so if it is not in a constructor call and if
errors can and are expected to be handled by PRNG users anyway,
i do not like that the stuff is instantiated in all threads, which
in addition requires forks handlers to be installed all over the
place.  Now, on NetBSD for example, and because of libraries i am
linking in, i do have two complete sets of fork handlers and PRNG
buffers all over the place, one for NetBSD LibC, one for OpenSSL.
In my unfortunately not so humble opinion this looks like a modern
white first world child.  Including the postural defect.

I am sorry for this rant.  Yeah, i think OpenSSL even offers PRNG
objects which i can use and control directly, and through this
i regain a bit control of resource usage etc.  Without rewriting
software in order to pregenerate randoms in the main( manager)
thread to pass them through to jobs in thread pools.  Just look
for those and do not use the TSD/fork-aware RAND_bytes().
But before i become a total troll.. the Linux kernel that drives
the world from smallest to hugest has one internal entropy pool
that feeds two public pools, whereas i the lucent little hobby
server from user space get an armada of these.  Wow.

It is not your fault of course.  I am sorry for this rant.
Thanks for your answer.)

How do i deal with this?  Maybe i simply always use my builtin
ARC4, it is so small, or upgrade to ChaCha20 or so, and add
something like a Blake2 filter to protect that pool, and only
serve the output of it.  Or something.

 |The RAND_bytes and RAND_status manpages can clearly be improved.
 |Since you always have to check RAND_bytes's return value now,
 |RAND_status is mostly useless.

Yes, in my opinion good documentation is hard, almost impossible.
I am not using it, but i always enjoy reading the concise
(concise!  Says Mr. McIlroy.) yet helpful manuals from the really
great guys, for example the Plan9 manuals regarding programming.
Maybe a bit too concise for end-users, except academics.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From steffen at sdaoden.eu  Sat Jan  5 19:41:31 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Sat, 05 Jan 2019 20:41:31 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <b89b48fce6b54eadaba632402d789ee9@Ex13.ncp.local>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
 <b89b48fce6b54eadaba632402d789ee9@Ex13.ncp.local>
Message-ID: <20190105194131.ToAvQ%steffen@sdaoden.eu>

Dr. Matthias St. Pierre wrote in <b89b48fce6b54eadaba632402d789ee9 at Ex13.\
ncp.local>:
 |I agree with Kurt, except for one point:
 |
 |> The RAND_bytes and RAND_status manpages can clearly be improved.
 |
 |Both manpages got an update during the DRBG rewrite (by me) and I don't
 |see any contradiction. You bring it to the point yourself:

I had a superficial look yesterday, but i think i have to reread
them in total, anyway.

 |> So _IF_ it is seeded it is seeded...
 |
 |It is true that the DRBG will automatically seed, but it is equally true
 |that it can still end up in an unseeded (error) state, if no suitable \
 |entropy
 |source is available. And since this can also happen during reseeding (which
 |in particular is enforced after a fork), it is always necessary to \
 |check the return
 |value of the RAND_bytes() function. Because in the error state, the \
 |buffer is not
 |filled at all.

That is really bad.  Of course you had to do it like this, and you
surely have looked around to see what servers and other software
which use OpenSSL do with the PRNG after forking (i.e., whether
they reiterate the [RAND_file_name(),] RAND_load_file(),
[:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as
documented, or not).

I think i will move away from RAND_ then, nonetheless, and at
least for the things i have control of.
But i will definitely reread the manual now.

Thanks for your answer.
Ciao and a nice weekend from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From kurt at roeckx.be  Sat Jan  5 22:15:06 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 5 Jan 2019 23:15:06 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190105193318.TPV_w%steffen@sdaoden.eu>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu>
 <20190104180735.GA25041@roeckx.be>
 <20190105193318.TPV_w%steffen@sdaoden.eu>
Message-ID: <20190105221506.GA18502@roeckx.be>

On Sat, Jan 05, 2019 at 08:33:18PM +0100, Steffen Nurpmeso wrote:
> 
> (I am also really interested and will look into OpenSSL to see if
> the abort() that seems to happen if the initial seed fails is in
> a linker-resolved constructor, and if not, why later failures do
> not also abort.

We do not call abort(). A function like RAND_bytes() or
RAND_status() will just return an error.

> Yes, while i am going, the full truth is that
> i do not like it, i do not like that possibly a constructor call
> is made for something that is possibly not needed, if it is done
> like that, that someone simply aborts because of a some internal
> PRNG, especially so if it is not in a constructor call and if
> errors can and are expected to be handled by PRNG users anyway,

RAND_bytes() has always documented that it can fail. Most function
calls can return errors for various reasons. Not checking for such
errors is in my opinion a bad style.

> i do not like that the stuff is instantiated in all threads

It's only created in each thread that tries to the RNG. I'm not
sure what exactly your problem with it is. Either we need a global
lock, or we need an RNG per thread. We went with the per thread
RNG.

We have a master DRBG that you can get with
RAND_DRBG_get0_master(). I recommend that you do not use it. It
requires that you take an external lock to use it. Internally we
lock it, but there is no way for you to use the same lock.

> which
> in addition requires forks handlers to be installed all over the
> place.

OpenSSL adds it's own fork handler now. You should not need to do
anything on fork related to OpenSSL.

> the Linux kernel that drives
> the world from smallest to hugest has one internal entropy pool
> that feeds two public pools, whereas i the lucent little hobby
> server from user space get an armada of these.  Wow.

Linux has a master pool, and a pool per core for the very same
reason as we also have a master DRBG and per thread DRBG.


Kurt


From Matthias.St.Pierre at ncp-e.com  Sat Jan  5 23:34:54 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sat, 5 Jan 2019 23:34:54 +0000
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190105194131.ToAvQ%steffen@sdaoden.eu>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
 <b89b48fce6b54eadaba632402d789ee9@Ex13.ncp.local>
 <20190105194131.ToAvQ%steffen@sdaoden.eu>
Message-ID: <bb6e16e3fee246e887f185d3fbbfd3a2@Ex13.ncp.local>

>  |Both manpages got an update during the DRBG rewrite (by me) and I don't
>  |see any contradiction. You bring it to the point yourself:
> 
> I had a superficial look yesterday, but i think i have to reread
> them in total, anyway.

Yes, please start with RAND(7) and RAND_DRBG(7).

> That is really bad.  Of course you had to do it like this, and you
> surely have looked around to see what servers and other software
> which use OpenSSL do with the PRNG after forking (i.e., whether
> they reiterate the [RAND_file_name(),] RAND_load_file(),
> [:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as
> documented, or not).

I really don't understand your frustration: the new PRNG was designed
to relieve the application from the burden of seeding. It is easier to use,
not more complicated: No need to call RAND_add(), RAND_seed(),
RAND_load_file() and all this stuff. Just make sure the os entropy sources
are available and then simply use RAND_bytes(). But don't expect it to
succeed always.

> I think i will move away from RAND_ then, nonetheless, and at
> least for the things i have control of.

I don't think this is a good idea. In the case when there is no suitable entropy
source, the OpenSSL RNG will fail to generate random bytes, indeed.
But how do you expect your application to seed the RNG properly in this
case? What is your application's entropy source? If you have one, which
OpenSSL does not handle yet, you could theoretically register your
own get_entropy callback for the master DRBG at application startup time.

But if you don't have a better entropy source than OpenSSL, you are bound to
fail, too. And isn't it better for your application to fail gracefully in this case
than to provide snake oil security?

HTH,
Matthias


P.S: As for automatic reseeding: There are potential issues when upgrading
applications which do a fork and chroot from 1.1.0 to 1.1.1. Because in
version 1.1.1, the application will reseed after fork, and the reseeding can fail
if the application developer (or administrator) did not pay attention to provide
a random device in the chroot jail. This was no problem with 1.1.0 and below,
because the RNG never reseeded automatically.

OpenSSL does everything to avoid such a chroot reseeding failure (#6432 and #7437).
Also, on modern linux systems OpenSSL will prefer the getrandom system call
which does not have this limitation of the random devices. 


https://github.com/openssl/openssl/pull/6432
https://github.com/openssl/openssl/pull/7437




From ananthuu741 at gmail.com  Sun Jan  6 05:00:04 2019
From: ananthuu741 at gmail.com (Ananthu Unnikrishnan)
Date: Sun, 6 Jan 2019 10:30:04 +0530
Subject: [openssl-users] Openssl asynchronous operation in real network
Message-ID: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>

Hi all,

       We have implemented a dynamic engine and tested in the async mode
using OpenSSL speed command. But in a real network scenario, we have seen
only starting the async_job(in file ssl/ssl_lib.c, function:
ssl_start_async_job) in the OpenSSL. We haven't seen polling async_fd's for
resuming the job as in apps/speed.c(in speed command case).
        So can anyone please suggest any solution for resuming the
async_jobs in real network scenario? Thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190106/b8bf5210/attachment-0001.html>

From antiac at gmail.com  Sun Jan  6 18:54:44 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Sun, 6 Jan 2019 19:54:44 +0100
Subject: [openssl-users] Possible bug in crypto/engine
Message-ID: <CAPN6PET8798ZTjCa0gjPwFEGEaT8zCwLtndwwfaYw+=BXPmXxg@mail.gmail.com>

Hi,

I sign a text file with:
openssl cms -sign -signer cert.pem -inkey 01 -keyform engine -engine pkcs11
in openssl.cnf
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /path/pkcs11.so
MODULE_PATH = /path/opensc-pkcs11.so

everything works well but if I write a wrong key, es. -inkey 101, this is
gdb result:

PKCS11_get_private_key returned NULL
cannot load signing key file from engine
140737353990592:error:26096080:engine
routines:ENGINE_load_private_key:failed loading private
key:crypto/engine/eng_pkey.c:78:
unable to load signing key file
Program received signal SIGSEGV, Segmentation fault.
__GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
27    pthread_rwlock_wrlock.c: No *such* file or directory

I realized that the error is probably here:
crypto/engine/eng_lib.c line 93
if (e->destroy)
        e->destroy(e);
CRYPTO_free_ex_data(CRYPTO_EX_INDEX_ENGINE, e, &e->ex_data);
if I comment these lines openssl does not crash

I do not know engine well and I do not know what these two lines do, if
anyone has any suggestions I can do some tests

Thanks,
Antonio Iacono
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190106/f6a76e1b/attachment.html>

From beldmit at gmail.com  Sun Jan  6 19:03:27 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Sun, 6 Jan 2019 22:03:27 +0300
Subject: [openssl-users] Possible bug in crypto/engine
In-Reply-To: <CAPN6PET8798ZTjCa0gjPwFEGEaT8zCwLtndwwfaYw+=BXPmXxg@mail.gmail.com>
References: <CAPN6PET8798ZTjCa0gjPwFEGEaT8zCwLtndwwfaYw+=BXPmXxg@mail.gmail.com>
Message-ID: <CADqLbzK=kwf7j1dJ_PF0S0psrrCr2Y-tiR1Vgi=j4uDs=z3oJQ@mail.gmail.com>

Hello

??, 6 ???. 2019 ?., 21:55 Antonio Iacono antiac at gmail.com:

> Hi,
>
> I sign a text file with:
> openssl cms -sign -signer cert.pem -inkey 01 -keyform engine -engine
> pkcs11
> in openssl.cnf
> [pkcs11_section]
> engine_id = pkcs11
> dynamic_path = /path/pkcs11.so
> MODULE_PATH = /path/opensc-pkcs11.so
>
> everything works well but if I write a wrong key, es. -inkey 101, this is
> gdb result:
>
> PKCS11_get_private_key returned NULL
> cannot load signing key file from engine
> 140737353990592:error:26096080:engine
> routines:ENGINE_load_private_key:failed loading private
> key:crypto/engine/eng_pkey.c:78:
> unable to load signing key file
> Program received signal SIGSEGV, Segmentation fault.
> __GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
> 27    pthread_rwlock_wrlock.c: No *such* file or directory
>
> I realized that the error is probably here:
> crypto/engine/eng_lib.c line 93
> if (e->destroy)
>         e->destroy(e);
> CRYPTO_free_ex_data(CRYPTO_EX_INDEX_ENGINE, e, &e->ex_data);
> if I comment these lines openssl does not crash
>
> I do not know engine well and I do not know what these two lines do, if
> anyone has any suggestions I can do some tests
>

I am not sure that the bug you found is in OpenSSL. I suspect it can be in
pkcs11 engine. The lines you've commented are a call of the engine cleanup
code.


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

From Matthias.St.Pierre at ncp-e.com  Sun Jan  6 22:53:06 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sun, 6 Jan 2019 22:53:06 +0000
Subject: [openssl-users] Possible bug in crypto/engine
In-Reply-To: <CAPN6PET8798ZTjCa0gjPwFEGEaT8zCwLtndwwfaYw+=BXPmXxg@mail.gmail.com>
References: <CAPN6PET8798ZTjCa0gjPwFEGEaT8zCwLtndwwfaYw+=BXPmXxg@mail.gmail.com>
Message-ID: <33528ccabc6c4591b69b02edf1d06d23@Ex13.ncp.local>

Antonio,

did you debug the preinstalled openssl app or have you tried to debug your own version, built with a debug configuration?

You get the best results in the debugger if you use the `debug-linux-x86_64` config target and
after building (you only need to run `make`, not `make install`) run it in the debugger directly from the source
directory as follows:

    util/shlib_wrap.sh  gdb  apps/openssl cms -sign -signer cert.pem -inkey 101 -keyform engine -engine pkcs11

If you can reproduce the crash with your debug version, please post a backtrace of the call stack when it?s stopped
at the segmentation fault.

HTH,
Matthias

Von: openssl-users <openssl-users-bounces at openssl.org> Im Auftrag von Antonio Iacono
Gesendet: Sonntag, 6. Januar 2019 19:55
An: openssl-users at openssl.org
Betreff: [openssl-users] Possible bug in crypto/engine

Hi,

I sign a text file with:
openssl cms -sign -signer cert.pem -inkey 01 -keyform engine -engine pkcs11
in openssl.cnf
[pkcs11_section]
engine_id = pkcs11
dynamic_path = /path/pkcs11.so
MODULE_PATH = /path/opensc-pkcs11.so
everything works well but if I write a wrong key, es. -inkey 101, this is gdb result:

PKCS11_get_private_key returned NULL
cannot load signing key file from engine
140737353990592:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78:
unable to load signing key file
Program received signal SIGSEGV, Segmentation fault.
__GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
27    pthread_rwlock_wrlock.c: No such file or directory

I realized that the error is probably here:
crypto/engine/eng_lib.c line 93
if (e->destroy)
        e->destroy(e);
CRYPTO_free_ex_data(CRYPTO_EX_INDEX_ENGINE, e, &e->ex_data);
if I comment these lines openssl does not crash

I do not know engine well and I do not know what these two lines do, if anyone has any suggestions I can do some tests

Thanks,
Antonio Iacono
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190106/a386a7ba/attachment-0001.html>

From Matthias.St.Pierre at ncp-e.com  Sun Jan  6 23:37:51 2019
From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre)
Date: Sun, 6 Jan 2019 23:37:51 +0000
Subject: [openssl-users] Possible bug in crypto/engine
In-Reply-To: <33528ccabc6c4591b69b02edf1d06d23@Ex13.ncp.local>
References: <CAPN6PET8798ZTjCa0gjPwFEGEaT8zCwLtndwwfaYw+=BXPmXxg@mail.gmail.com>
 <33528ccabc6c4591b69b02edf1d06d23@Ex13.ncp.local>
Message-ID: <9858516656b6468e9b81aef73d3c0233@Ex13.ncp.local>

Sorry, the command contains a little error: please replace `gdb ?` by `gdb ?args ?`:

    util/shlib_wrap.sh  gdb  --args apps/openssl cms -sign -signer cert.pem -inkey 101 -keyform engine -engine pkcs11


From antiac at gmail.com  Sun Jan  6 23:51:09 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Mon, 7 Jan 2019 00:51:09 +0100
Subject: [openssl-users] Possible bug in crypto/engine
In-Reply-To: <33528ccabc6c4591b69b02edf1d06d23@Ex13.ncp.local>
References: <CAPN6PET8798ZTjCa0gjPwFEGEaT8zCwLtndwwfaYw+=BXPmXxg@mail.gmail.com>
 <33528ccabc6c4591b69b02edf1d06d23@Ex13.ncp.local>
Message-ID: <CAPN6PERYRdQzzTRBAmpXHkKe9YTMPWvZTPhmh8u1YxW7-CW3Rw@mail.gmail.com>

Thanks Dmitry and Matthias,

I solved, as suggested the problem was not openssl, but libp11 I had
compiled with version 1.1 of libcrypto instead version 3.

Antonio


Il giorno dom 6 gen 2019 alle ore 23:53 Dr. Matthias St. Pierre <
Matthias.St.Pierre at ncp-e.com> ha scritto:

> Antonio,
>
>
>
> did you debug the preinstalled openssl app or have you tried to debug your
> own version, built with a debug configuration?
>
>
>
> You get the best results in the debugger if you use the
> `debug-linux-x86_64` config target and
> after building (you only need to run `make`, not `make install`) run it in
> the debugger directly from the source
>
> directory as follows:
>
>
>
>     util/shlib_wrap.sh  gdb  apps/openssl cms -sign -signer cert.pem -
> inkey 101 -keyform engine -engine pkcs11
>
>
>
> If you can reproduce the crash with your debug version, please post a
> backtrace of the call stack when it?s stopped
>
> at the segmentation fault.
>
>
>
> HTH,
>
> Matthias
>
>
>
> *Von:* openssl-users <openssl-users-bounces at openssl.org> *Im Auftrag von *Antonio
> Iacono
> *Gesendet:* Sonntag, 6. Januar 2019 19:55
> *An:* openssl-users at openssl.org
> *Betreff:* [openssl-users] Possible bug in crypto/engine
>
>
>
> Hi,
>
>
>
> I sign a text file with:
>
> openssl cms -sign -signer cert.pem -inkey 01 -keyform engine -engine
> pkcs11
>
> in openssl.cnf
>
> [pkcs11_section]
> engine_id = pkcs11
> dynamic_path = /path/pkcs11.so
> MODULE_PATH = /path/opensc-pkcs11.so
>
> everything works well but if I write a wrong key, es. -inkey 101, this is
> gdb result:
>
>
>
> PKCS11_get_private_key returned NULL
> cannot load signing key file from engine
> 140737353990592:error:26096080:engine
> routines:ENGINE_load_private_key:failed loading private
> key:crypto/engine/eng_pkey.c:78:
> unable to load signing key file
> Program received signal SIGSEGV, Segmentation fault.
> __GI___pthread_rwlock_wrlock (rwlock=0x0) at pthread_rwlock_wrlock.c:27
> 27    pthread_rwlock_wrlock.c: No *such* file or directory
>
>
>
> I realized that the error is probably here:
>
> crypto/engine/eng_lib.c line 93
>
> if (e->destroy)
>         e->destroy(e);
>
> CRYPTO_free_ex_data(CRYPTO_EX_INDEX_ENGINE, e, &e->ex_data);
>
> if I comment these lines openssl does not crash
>
>
>
> I do not know engine well and I do not know what these two lines do, if
> anyone has any suggestions I can do some tests
>
>
>
> Thanks,
>
> Antonio Iacono
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/f18b8b6a/attachment.html>

From shivakumar2696 at gmail.com  Mon Jan  7 05:08:36 2019
From: shivakumar2696 at gmail.com (shiva kumar)
Date: Mon, 7 Jan 2019 10:38:36 +0530
Subject: [openssl-users] Request for the list of API changes from 1.0.2k to
	1.1.1a
Message-ID: <CAN9sONdR-J57R_gBqyKDEfVQwHPUoDz3=nqge3QfqdKiAR9gRQ@mail.gmail.com>

Hi,

I'm using OpenSSL 1.0.2k, I wated to move to 1.1.1a so I'm building the
1.1.1a
I wanted to know list of all the API that are changed from 1.0.2k to
1.1.1a, so I request  you to provide all the list of API

Thanks and Regards
Shivakumar

-- 
*With Best Regards*
*Shivakumar S*
*Mysore, Karnataka*
*# 91-9945543956*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/48412b13/attachment.html>

From ananthuu741 at gmail.com  Mon Jan  7 12:55:29 2019
From: ananthuu741 at gmail.com (Ananthu Unnikrishnan)
Date: Mon, 7 Jan 2019 18:25:29 +0530
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
Message-ID: <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>

Hi all,

Adding more details to the previous mail. We have edited the OpenSSL code
for implementing the polling for changed fd's as in OpenSSL speed command.
Attached the code snippet of the same along with this mail.
Mentioned below some observations which found doubtful:

1) We have got prints in ASYNC_FINISH case, before getting print in
ASYNC_PAUSE case. Attaching the log also, so you can understand easily.
2) Shown below the code snippet which we have written to provide a write on
fd.

if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
        printf("In dynamic engine | waitctx == NULL : %d\n", __LINE__);
        return ret;
    }

    printf("\n----- In dynamic engine | After pausing | job is %lx |
waitctx in resume job %lx |-----\n", job, waitctx);

        if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id, &efd,
                              &custom)) > 0) {
        if (write(efd, &buf, sizeof(uint64_t)) == -1) {
            printf("\nFailed to write\n");
        }
    }

Here waitctx is getting NULL when we tried to fetch waitctx using
ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB) ie.1176
bytes contained in the job address from the engine,  we got correct data
before calling ASYNC_pause() and but got half data zero data when we tried
to access the same address after ASYNC_pause().

Attaching both job structure contents before and after calling
ASYNC_pause(). Also, we got the correct data in the same address when we
have printed from ssl_start_async_job() before polling starts, where we
have started the async_job
.
The prints starting with "In dynamic engine" are prints inside the engine,
rest prints are from ss/ssl_lib.c. Kindly check this and please point out
if anything is wrong somewhere. Thanks in advance.


On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan <ananthuu741 at gmail.com>
wrote:

> Hi all,
>
>        We have implemented a dynamic engine and tested in the async mode
> using OpenSSL speed command. But in a real network scenario, we have seen
> only starting the async_job(in file ssl/ssl_lib.c, function:
> ssl_start_async_job) in the OpenSSL. We haven't seen polling async_fd's for
> resuming the job as in apps/speed.c(in speed command case).
>         So can anyone please suggest any solution for resuming the
> async_jobs in real network scenario? Thanks in advance.
>
>
>
>

-- 
With best Regards,

         Ananthu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/189e5a07/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ASYNC_JOB_contents_after_pause
Type: application/octet-stream
Size: 3528 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/189e5a07/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ASYNC_JOB_contents_before_pause
Type: application/octet-stream
Size: 3528 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/189e5a07/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log_async_job
Type: application/octet-stream
Size: 543 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/189e5a07/attachment-0005.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: code_snippet_ssl_lib.c
Type: text/x-csrc
Size: 3628 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/189e5a07/attachment-0001.c>

From byyang at iis.sinica.edu.tw  Mon Jan  7 12:56:35 2019
From: byyang at iis.sinica.edu.tw (Bo-Yin Yang)
Date: Mon, 7 Jan 2019 20:56:35 +0800
Subject: [openssl-users] possible C bugs in ecp_nistp521
Message-ID: <62e4e761-5f33-1298-7dcd-6d21b4c4edb2@iis.sinica.edu.tw>

Dear all,

we found some counter-examples (examples where wrong answers were 
returned) for field element computations in the C routines for P-521 
(that is, modulo 2^521-1).   The counterexamples, a C test file, a 
Makefile, and a short README are attached.

The routines in question are: felem_square, felem_mul, felem_diff_128_64.

Can someone inform us whether these are in fact a couple of bugs that we 
found, or did we miss something.

Best wishes,
Bo-Yin Yang


P.S.

The counterexamples are:

- for felem_square and felem_mul:
   felem in = {
     0x3fd9049d07fdc0ad, 0x3ece5f4000000000, 0x39c5349d6a623811,
     0x3bf48f8409415499, 0x3ffdac80c8300000, 0x3ff3f3de63be6baf,
     0x3fa3eff5c6db1743, 0x3dde8d0ddc21079f, 0x3e068b5ec961f8fc
   };

- for felem_diff_128_64:
   largefelem out = {
     0,0,0,
     0,0,0,
     0,0,0
   };
   felem in = {
     0x4000000000012270, 0x1000000000000000, 0x0010000000000000,
     0x0400000000000000, 0x0800000000000000, 0x0020000000000000,
     0x0000000040000000, 0x0002000000000000, 0x0000000400000000
   };

-- B.Y.

-------------- next part --------------
all: check.c $(SRC_DIR)/crypto/ec/ecp_nistp521.c
	$(CC) -I$(SRC_DIR) -I$(SRC_DIR)/include -I$(SRC_DIR)/crypto/include \
		-pthread -m64 -std=c99 -Wall -fdata-sections -ffunction-sections \
		-o check check.c $(SRC_DIR)/libcrypto.a -ldl
clean:
	rm -f check
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check.c
Type: text/x-csrc
Size: 13853 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/a8f9fbbb/attachment.c>
-------------- next part --------------
This is a little program to compare the outputs of functions
	felem_square,
	felem_mul, 
	felem_diff_128_64
against the outputs of functions
	BN_mod_sqr,
	BN_mod_mul,
	BN_mod_sub.
The objective is to check the correctness of these felem_* functions.


/////////////////////////////////////////////////////////
//
//  HOW TO USE IT
//
/////////////////////////////////////////////////////////

Note: this is only tested on Ubuntu and MacOS using GCC and Clang.

1. Configure your OpenSSL source code with the option 
   "enable-ec_nistp_64_gcc_128", and then compile it to generate the
   static library "libcrypto.a". For example:

   > ./config enable-ec_nistp_64_gcc_128
   > make

2. Enter the directory of this little program, run "make" while 
   assigning SRC_DIR with the path of the OpenSSL source tree:

   > make SRC_DIR=path-to-OpenSSL
   (replace "path-to-OpenSSL" with the path to the source tree)

3. Execute the binary "check".


/////////////////////////////////////////////////////////
//
//  WHAT IS THE OUTPUT OF IT
//
/////////////////////////////////////////////////////////

This little program contains one counter-example and one passed 
example for each felem_* function. In the output from the program
you can see the inputs and outputs from felem_* and BN_mod_* 
functions. 




From cfernando at alteryx.com  Mon Jan  7 15:20:55 2019
From: cfernando at alteryx.com (Chris Fernando)
Date: Mon, 7 Jan 2019 15:20:55 +0000
Subject: [openssl-users] Compiling FIPS-cable OpenSSL on Windows Server
	2012R2
Message-ID: <8B308719-0560-4E2C-A53E-51DF3C21BE0B@alteryx.com>

I perused the list archives for all of 2018 and did not see anything current relating to this problem, so if this is a question that has been asked & answered, please feel free to point me at the relevant location to read about what I'm doing incorrectly. =)

I'm not at all familiar with Windows & compiling Open Source projects, but I am having no trouble on Linux with OpenSSL + FIPS. On Windows, with Visual Studio 2017 (Community Edition), I am able to compile the FIPS 2.0.16 module and OpenSSL 1.0.2q (NO FIPS) without issue.

When I try to compile OpenSSL with the FIPS canister, per the User Guide instructions, I end up with the following error.

        cl /Fotmp32dll\o_fips.obj  -Iinc32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS
 -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN
-DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -Ic:\..\openssl-fips/
include -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO
_SSL2 -DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_
CIPHERS -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/lib -D_WINDLL  -DOPENSSL_BUIL
D_SHLIBCRYPTO -c .\crypto\o_fips.c
o_fips.c
.\crypto\o_fips.c(61): fatal error C1083: Cannot open include file: 'openssl/fip
s.h': No such file or directory
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017
\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\cl.EXE"' : return code '0x2
'
Stop.


I am doing the following to compile FIPS:
cd c:\path\to\fips-source
ms\do_fips no-asm

I am doing the following to compile OpenSSL+FIPS (Strawberry Perl installed):
cd c:\path\to\openssl-source
nmake -f ms\ntdll.mak clean
nmake -f ms\nt.mak clean
perl Configure VC-WIN64A fips no-asm --with-fipsdir=c:\path\to\fips-source
ms\do_win64a no-asm
nmake -f ms\ntdll.mak


I feel like I'm missing something fundamental here and I know the User Guide says to install the FIPS files in a protected area. However, as I'm just building the source on this device, shouldn't I be able to to do the above and have it work?

Any help would be greatly appreciated.


Thanks,

Chris

From jb-openssl at wisemo.com  Mon Jan  7 16:06:15 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 7 Jan 2019 17:06:15 +0100
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <MW2PR18MB2090C5FE016931BBC166B133F98E0@MW2PR18MB2090.namprd18.prod.outlook.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
 <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
 <010101681a14473a-b5370c04-ae2c-4cbe-bce7-2b3385938cce-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090C5FE016931BBC166B133F98E0@MW2PR18MB2090.namprd18.prod.outlook.com>
Message-ID: <f3ca663e-dbd1-4dcb-46a5-305fb9091576@wisemo.com>

On 04/01/2019 22:04, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown
>> Sent: Friday, January 04, 2019 13:16
>> If you want to, what you want is something like:
>>        int fd;
>>        do {
>>                fd = open("/dev/null", O_RDWR);
>>        } while (fd < 3);
>>        close(fd);
>> (That's strictly not quite right, since it leaves 0 open writable and 1 and 2 open readable,
>> but that's pretty harmless.)
> Behavior is unfortunate if open fails, e.g. because the NFILES limit is reached, or because /dev/null is inaccessible (e.g. due to a poorly-configured chroot). You'd be better off with (fd >= 0 && fd < 3).
>
> Since source bytes are cheap, though, and there are at most three opens to be done, I'd just do it explicitly for the three stdio descriptors. That would also make the intention clear. (Yes, the intention of your version is clear to old UNIX hands. It might not be to other people.)
>
> I'm ignoring portability considerations, since I personally don't think this would be a great thing to implement in the apps, so I'm not going to be submitting a PR for it.
>
A chroot with no other reason to open /dev/null should not contain that
file name, even on unix-like platforms (least privilege chroot design).

Please refer to my previous post about the many other reasons why
opening /dev/null has a high risk of failure.

Stepping back, it is worth investigating if:

 ?- Running TLS1.3 s_client with -ignoreeof and no stdin actually fails
 ? earlier than with stdin == /dev/null

 ?- If this is triggered by a code bug.

P.S.

On some Debian systems, cron runs scripts with stdout and stderr piped
(directly or indirectly) to a mail program that times out if a cron job
runs for a long time.


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 cfernando at alteryx.com  Mon Jan  7 17:52:38 2019
From: cfernando at alteryx.com (Chris Fernando)
Date: Mon, 7 Jan 2019 17:52:38 +0000
Subject: [openssl-users] Compiling FIPS-cable OpenSSL on Windows
	Server	2012R2
In-Reply-To: <8B308719-0560-4E2C-A53E-51DF3C21BE0B@alteryx.com>
References: <8B308719-0560-4E2C-A53E-51DF3C21BE0B@alteryx.com>
Message-ID: <CF9431BA-641B-4CCA-8E5E-863F050E8AF2@alteryx.com>

> 
> On Jan 7, 2019, at 09:20, Chris Fernando via openssl-users <openssl-users at openssl.org> wrote:
> 
> I perused the list archives for all of 2018 and did not see anything current relating to this problem, so if this is a question that has been asked & answered, please feel free to point me at the relevant location to read about what I'm doing incorrectly. =)
> 
> I'm not at all familiar with Windows & compiling Open Source projects, but I am having no trouble on Linux with OpenSSL + FIPS. On Windows, with Visual Studio 2017 (Community Edition), I am able to compile the FIPS 2.0.16 module and OpenSSL 1.0.2q (NO FIPS) without issue.
> 
> [snip]
> 
> 
> I am doing the following to compile FIPS:
> cd c:\path\to\fips-source
> ms\do_fips no-asm
> 
> I am doing the following to compile OpenSSL+FIPS (Strawberry Perl installed):
> cd c:\path\to\openssl-source
> nmake -f ms\ntdll.mak clean
> nmake -f ms\nt.mak clean
> perl Configure VC-WIN64A fips no-asm --with-fipsdir=c:\path\to\fips-source
> ms\do_win64a no-asm
> nmake -f ms\ntdll.mak
> 
> [snip]


Well, I managed to get the compile to move a bit further by copying "inc32" to "include", "util" to "bin", and "out32dll" to "lib" in the FIPS source directory, that I was including in --with-fipsdir= .

However, now I am getting the following error during the OpenSSL build process.


        cl /Fotmp32dll\fips_premain_dso.obj -DFINGERPRINT_PREMAIN_DSO_LOAD -Iinc
32 -Itmp32dll /MD /Ox -DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPEN
SSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_S
ECURE_NO_DEPRECATE -IC:\Users\cfernando\Downloads\ossl\ossl\openssl-fips/include
 -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_SSL2 -
DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_WEAK_SSL_CIPHERS
 -DOPENSSL_NO_STATIC_ENGINE /Zi /Fdtmp32dll/app -c C:\Users\cfernando\Downloads\
ossl\ossl\openssl-fips\lib\fips_premain.c
fips_premain.c
        ml  /c ms\uptable.asm
Microsoft (R) Macro Assembler Version 14.16.27025.1
Copyright (C) Microsoft Corporation.  All rights reserved.

 Assembling: ms\uptable.asm
ms\uptable.asm(9) : error A2006:undefined symbol : rsp
ms\uptable.asm(10) : error A2006:undefined symbol : rsp
ms\uptable.asm(11) : error A2006:undefined symbol : rsp
ms\uptable.asm(12) : error A2006:undefined symbol : rsp
ms\uptable.asm(13) : error A2006:undefined symbol : rcx
ms\uptable.asm(14) : error A2006:undefined symbol : rdx
ms\uptable.asm(16) : error A2006:undefined symbol : rcx
ms\uptable.asm(17) : error A2006:undefined symbol : rdx
ms\uptable.asm(18) : error A2006:undefined symbol : r8
ms\uptable.asm(19) : error A2006:undefined symbol : r9
ms\uptable.asm(20) : error A2006:undefined symbol : rax
ms\uptable.asm(21) : error A2006:undefined symbol : rsp
ms\uptable.asm(22) : error A2006:undefined symbol : rax
ms\uptable.asm(29) : error A2006:undefined symbol : rsp
ms\uptable.asm(30) : error A2006:undefined symbol : rsp
ms\uptable.asm(31) : error A2006:undefined symbol : rsp
ms\uptable.asm(32) : error A2006:undefined symbol : rsp
ms\uptable.asm(33) : error A2006:undefined symbol : rcx
ms\uptable.asm(34) : error A2006:undefined symbol : rdx
ms\uptable.asm(36) : error A2006:undefined symbol : rcx
ms\uptable.asm(37) : error A2006:undefined symbol : rdx
ms\uptable.asm(38) : error A2006:undefined symbol : r8
ms\uptable.asm(39) : error A2006:undefined symbol : r9
ms\uptable.asm(40) : error A2006:undefined symbol : rax
ms\uptable.asm(41) : error A2006:undefined symbol : rsp
ms\uptable.asm(42) : error A2006:undefined symbol : rax
ms\uptable.asm(49) : error A2006:undefined symbol : rsp
ms\uptable.asm(50) : error A2006:undefined symbol : rsp
ms\uptable.asm(51) : error A2006:undefined symbol : rsp
ms\uptable.asm(52) : error A2006:undefined symbol : rsp
ms\uptable.asm(53) : error A2006:undefined symbol : rcx
ms\uptable.asm(54) : error A2006:undefined symbol : rdx
ms\uptable.asm(56) : error A2006:undefined symbol : rcx
ms\uptable.asm(57) : error A2006:undefined symbol : rdx
ms\uptable.asm(58) : error A2006:undefined symbol : r8
ms\uptable.asm(59) : error A2006:undefined symbol : r9
ms\uptable.asm(60) : error A2006:undefined symbol : rax
ms\uptable.asm(61) : error A2006:undefined symbol : rsp
ms\uptable.asm(62) : error A2006:undefined symbol : rax
ms\uptable.asm(69) : error A2006:undefined symbol : rsp
ms\uptable.asm(70) : error A2006:undefined symbol : rsp
ms\uptable.asm(71) : error A2006:undefined symbol : rsp
ms\uptable.asm(72) : error A2006:undefined symbol : rsp
ms\uptable.asm(73) : error A2006:undefined symbol : rcx
ms\uptable.asm(74) : error A2006:undefined symbol : rdx
ms\uptable.asm(76) : error A2006:undefined symbol : rcx
ms\uptable.asm(77) : error A2006:undefined symbol : rdx
ms\uptable.asm(78) : error A2006:undefined symbol : r8
ms\uptable.asm(79) : error A2006:undefined symbol : r9
ms\uptable.asm(80) : error A2006:undefined symbol : rax
ms\uptable.asm(81) : error A2006:undefined symbol : rsp
ms\uptable.asm(82) : error A2006:undefined symbol : rax
ms\uptable.asm(89) : error A2006:undefined symbol : rsp
ms\uptable.asm(90) : error A2006:undefined symbol : rsp
ms\uptable.asm(91) : error A2006:undefined symbol : rsp
ms\uptable.asm(92) : error A2006:undefined symbol : rsp
ms\uptable.asm(93) : error A2006:undefined symbol : rcx
ms\uptable.asm(94) : error A2006:undefined symbol : rdx
ms\uptable.asm(96) : error A2006:undefined symbol : rcx
ms\uptable.asm(97) : error A2006:undefined symbol : rdx
ms\uptable.asm(98) : error A2006:undefined symbol : r8
ms\uptable.asm(99) : error A2006:undefined symbol : r9
ms\uptable.asm(100) : error A2006:undefined symbol : rax
ms\uptable.asm(101) : error A2006:undefined symbol : rsp
ms\uptable.asm(102) : error A2006:undefined symbol : rax
ms\uptable.asm(109) : error A2006:undefined symbol : rsp
ms\uptable.asm(110) : error A2006:undefined symbol : rsp
ms\uptable.asm(111) : error A2006:undefined symbol : rsp
ms\uptable.asm(112) : error A2006:undefined symbol : rsp
ms\uptable.asm(113) : error A2006:undefined symbol : rcx
ms\uptable.asm(114) : error A2006:undefined symbol : rdx
ms\uptable.asm(116) : error A2006:undefined symbol : rcx
ms\uptable.asm(117) : error A2006:undefined symbol : rdx
ms\uptable.asm(118) : error A2006:undefined symbol : r8
ms\uptable.asm(119) : error A2006:undefined symbol : r9
ms\uptable.asm(120) : error A2006:undefined symbol : rax
ms\uptable.asm(121) : error A2006:undefined symbol : rsp
ms\uptable.asm(122) : error A2006:undefined symbol : rax
ms\uptable.asm(129) : error A2006:undefined symbol : rsp
ms\uptable.asm(130) : error A2006:undefined symbol : rsp
ms\uptable.asm(131) : error A2006:undefined symbol : rsp
ms\uptable.asm(132) : error A2006:undefined symbol : rsp
ms\uptable.asm(133) : error A2006:undefined symbol : rcx
ms\uptable.asm(134) : error A2006:undefined symbol : rdx
ms\uptable.asm(136) : error A2006:undefined symbol : rcx
ms\uptable.asm(137) : error A2006:undefined symbol : rdx
ms\uptable.asm(138) : error A2006:undefined symbol : r8
ms\uptable.asm(139) : error A2006:undefined symbol : r9
ms\uptable.asm(140) : error A2006:undefined symbol : rax
ms\uptable.asm(141) : error A2006:undefined symbol : rsp
ms\uptable.asm(142) : error A2006:undefined symbol : rax
ms\uptable.asm(149) : error A2006:undefined symbol : rsp
ms\uptable.asm(150) : error A2006:undefined symbol : rsp
ms\uptable.asm(151) : error A2006:undefined symbol : rsp
ms\uptable.asm(152) : error A2006:undefined symbol : rsp
ms\uptable.asm(153) : error A2006:undefined symbol : rcx
ms\uptable.asm(154) : error A2006:undefined symbol : rdx
ms\uptable.asm(156) : error A2006:undefined symbol : rcx
ms\uptable.asm(157) : error A2006:undefined symbol : rdx
ms\uptable.asm(158) : error A2006:undefined symbol : r8
ms\uptable.asm(159) : fatal error A1012:error count exceeds 100; stopping assembly
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x86\ml.EXE"' : return code '0x1'
Stop.


Any thoughts?

Thanks,

Chris


From steffen at sdaoden.eu  Mon Jan  7 18:31:36 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 07 Jan 2019 19:31:36 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190105221506.GA18502@roeckx.be>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
 <20190105193318.TPV_w%steffen@sdaoden.eu> <20190105221506.GA18502@roeckx.be>
Message-ID: <20190107183136.-eW61%steffen@sdaoden.eu>

A wonderful Monday in the beautiful Winter time i wish.

I am sorry for the late reply again, i got a bug report for the
mailer i maintain, and from a long time user.
I hope it is ok that i compress the answers in one message, i am
talking much too much...

Kurt Roeckx wrote in <20190105221506.GA18502 at roeckx.be>:
 |On Sat, Jan 05, 2019 at 08:33:18PM +0100, Steffen Nurpmeso wrote:
 |> 
 |> (I am also really interested and will look into OpenSSL to see if
 |> the abort() that seems to happen if the initial seed fails is in
 |> a linker-resolved constructor, and if not, why later failures do
 |> not also abort.
 |
 |We do not call abort(). A function like RAND_bytes() or
 |RAND_status() will just return an error.

Aah, i see.  I obviously had a completely false impression of the
new design.  I do not know where this came from, if i now search
in doc/ of the [master] there no mention of such wording, neither
abort nor exit nor whatever.  Hmm.?

  ...
 |RAND_bytes() has always documented that it can fail. Most function
 |calls can return errors for various reasons. Not checking for such
 |errors is in my opinion a bad style.

Well i, and until just now, interpreted the PRNG as something like
a "cipher stream", which simply applies (magic, to me) math to
a buffer of undefined content and an algorithm-chosen size.  Just
like MD5, which' RFC (1321) does not have error conditions.  (A
digest, but i had the RFC number at hand.)

So, to me.., i do not see any possible error condition, since the
initial seeding has been testified with RAND_status().

This is different now, and i will change the implementation as
soon as possible.  (This week.)

 |> i do not like that the stuff is instantiated in all threads
 |
 |It's only created in each thread that tries to the RNG. I'm not
 |sure what exactly your problem with it is. Either we need a global
 |lock, or we need an RNG per thread. We went with the per thread
 |RNG.

All my fault.  As a side note, i remember a commit message of
DragonFlyBSD and M. Dillon fly by (some years ago) where he
utilized the effect of SMP races as a random source.  If i recall
correctly.  Of course you had to protect the reseed count or
whatever (but there atomic cas or a spinlock would suffice
i guess).

 |We have a master DRBG that you can get with
 |RAND_DRBG_get0_master(). I recommend that you do not use it. It
 |requires that you take an external lock to use it. Internally we
 |lock it, but there is no way for you to use the same lock.
 |
 |> which
 |> in addition requires forks handlers to be installed all over the
 |> place.
 |
 |OpenSSL adds it's own fork handler now. You should not need to do
 |anything on fork related to OpenSSL.

It is just, to me, lack of standard.  But i do not dlopen() you,
and i do not dlclose() you.  In this scenario libraries may do use
anything, install atexit, onfork, whatever.  Other SSL libraries
even removed the possibility to hook the memory allocation
methods!

 |> the Linux kernel that drives
 |> the world from smallest to hugest has one internal entropy pool
 |> that feeds two public pools, whereas i the lucent little hobby
 |> server from user space get an armada of these.  Wow.
 |
 |Linux has a master pool, and a pool per core for the very same
 |reason as we also have a master DRBG and per thread DRBG.

I have read [1], but not that thorougly.  I was referring to the
user space interface, anyway.  (The thing is, i would have
preferred reading a one or two pages abstract instead of flying
over 138 pages.  I seem to know he knows.  I have read some
dissertations in my life, and i like the dedication if people
translate a complete system manual to German there, or show in
detail that they know know know their topic.  Having said that,
a very nice such work i have read from the Uni Kaiserslautern, it
was about 30 pages and it had been clear that "he can", shaking
off his hand.  Why need more?  Very good.  Imho.)

  [1] https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf?__blob=publicationFile&v=7

 --End of <20190105221506.GA18502 at roeckx.be>

Dr. Matthias St. Pierre wrote in <bb6e16e3fee246e887f185d3fbbfd3a2 at Ex13.\
ncp.local>:
 |>|Both manpages got an update during the DRBG rewrite (by me) and I don't
 |>|see any contradiction. You bring it to the point yourself:
 |> 
 |> I had a superficial look yesterday, but i think i have to reread
 |> them in total, anyway.
 |
 |Yes, please start with RAND(7) and RAND_DRBG(7).

Thanks.  I did just now.

 |> That is really bad.  Of course you had to do it like this, and you
 |> surely have looked around to see what servers and other software
 |> which use OpenSSL do with the PRNG after forking (i.e., whether
 |> they reiterate the [RAND_file_name(),] RAND_load_file(),
 |> [:[RAND_add(),] RAND_status()], [RAND_write_file()] dance as
 |> documented, or not).
 |
 |I really don't understand your frustration: the new PRNG was designed
 |to relieve the application from the burden of seeding. It is easier to use,
 |not more complicated: No need to call RAND_add(), RAND_seed(),
 |RAND_load_file() and all this stuff. Just make sure the os entropy sources
 |are available and then simply use RAND_bytes(). But don't expect it to
 |succeed always.

And may i ask, what to do if it fails?  Try it in a loop a finite
number of times, assuming it over-and-over detects it is in an
error state and tries to reseed unless that succeeds, and bail if
still without success thereafter?

Talking about the only program in the public that i represent:
i will not abort that one just because a PRNG fails to produce
some bytes that this program uses for the purpose of, well, having
some (pseudo but) random bytes; because: this is _completely_
disproportionate to the use cases of those random numbers.
I guess the same could be said about UUIDS generated via PRNGs
instead of how the standard defines them, etc. etc.
Please do not say "use random(3) or rand(3)" now, please.
So what to do?

 |> I think i will move away from RAND_ then, nonetheless, and at
 |> least for the things i have control of.
 |
 |I don't think this is a good idea. In the case when there is no suitable \
 |entropy
 |source, the OpenSSL RNG will fail to generate random bytes, indeed.
 |But how do you expect your application to seed the RNG properly in this
 |case? What is your application's entropy source? If you have one, which

Yes, that is the problem.  We do have several possibilities for
VAL_RANDOM.  Some of them only seed our builtin ARC4
implementation, which until now exposes the internal buffer as
such (sufficient for our purpose yet).  Examples of this are
/dev/urandom, Linux getrandom as system call or library call,
aehh...  If that seeding fails, we create a completely
unscientific homebrew seed via CLOCK_REALTIME or gettimeofday(2),
whatever is available, wildly XORing through the buffer, further
randomizing those weakly through the well-known algorithm from
"Random number generators: good ones are hard to find", Park and
Miller, Communications of the ACM, vol. 31, no. 10, October 1988,
p. 1195 (a_aux_rand_weak()).  This is the code:

   if(n_poption & n_PO_D_V)
      n_err(_("P(seudo)R(andomNumber)G(enerator): creating homebrew seed\n"));
   for(seed = (uintptr_t)a_aux_rand & UI32_MAX, rnd = 21; rnd != 0; --rnd){
      for(u.i = n_NELEM(a_aux_rand->b32); u.i-- != 0;){
         ui32_t t, k;

# ifdef mx_HAVE_CLOCK_GETTIME
         clock_gettime(CLOCK_REALTIME, &ts);
         t = (ui32_t)ts.tv_nsec;
# else
         gettimeofday(&ts, NULL);
         t = (ui32_t)ts.tv_usec;
# endif
         if(rnd & 1)
            t = (t >> 16) | (t << 16);
         a_aux_rand->b32[u.i] ^= a_aux_rand_weak(seed ^ t);
         a_aux_rand->b32[t % n_NELEM(a_aux_rand->b32)] ^= seed;
         if(rnd == 7 || rnd == 17)
            a_aux_rand->b32[u.i] ^= a_aux_rand_weak(seed ^ (ui32_t)ts.tv_sec);
         k = a_aux_rand->b32[u.i] % n_NELEM(a_aux_rand->b32);
         a_aux_rand->b32[k] ^= a_aux_rand->b32[u.i];
         seed ^= a_aux_rand_weak(a_aux_rand->b32[k]);
         if((rnd & 3) == 3)
            seed ^= su_prime_lookup_next(seed);
      }

So this is totally unscientific nonsense and overkill in one, but
at least we mix the low bits into the upper ones of the smallest
moving time fractions, and as such perform better than many
C libraries seem to have done in the past, as far as i know.
I think this is the best i can do.  Wait.  We _could_ check
whether we have subsecond precision sleep, and do nanosleep(0) do
gain some kind of sched_yield().

Others completely replace all this code: if we find a native
arc4random(3) (posix_random(3) will not become true,
unfortunately) we use that.  If we are linked against OpenSSL, we
do use yours exclusively -- but this possibly has to be changed.

 |OpenSSL does not handle yet, you could theoretically register your
 |own get_entropy callback for the master DRBG at application startup time.

So by hooking in such after the initial seeding succeeded (as
testified via RAND_status()) i can ensure that further reseeding
goes over my table and will (thus) always succeed?  I will look
into this possibility, thanks for the suggestion!

 |But if you don't have a better entropy source than OpenSSL, you are \
 |bound to
 |fail, too. And isn't it better for your application to fail gracefully \
 |in this case
 |than to provide snake oil security?

Well, as above, it is disproportionate to the use case of randoms
here.  (But this ARC4 stuff is a port of an old C++ library class,
and will move to an external C library in the future.  That is to
say, for now we could get by simply with a_aux_rand_weak(), but
since this code is old and what i have used so long.)

And i for one think that "snake oil security" is a wording much
too strong in the case of reseeding of a very secure stream
cipher, the entropy pool of which is protected by a very secure
distorting digest.  I do not know about forward security, however.
And i have read in the documented quoted above however, that the
in-between-boots random entropy file is not even counted against
security no more, which is why sshd blocks booting a minute.
That i find total overkill.

 |P.S: As for automatic reseeding: There are potential issues when upgrading
 |applications which do a fork and chroot from 1.1.0 to 1.1.1. Because in
 |version 1.1.1, the application will reseed after fork, and the reseeding \
 |can fail
 |if the application developer (or administrator) did not pay attention \
 |to provide
 |a random device in the chroot jail. This was no problem with 1.1.0 \
 |and below,
 |because the RNG never reseeded automatically.
 |
 |OpenSSL does everything to avoid such a chroot reseeding failure (#6432 \
 |and #7437).
 |Also, on modern linux systems OpenSSL will prefer the getrandom system call
 |which does not have this limitation of the random devices. 
 |
 |https://github.com/openssl/openssl/pull/6432
 |https://github.com/openssl/openssl/pull/7437

Thanks for the information.  (It does not apply here, but thank
you nonetheless!)

 --End of <bb6e16e3fee246e887f185d3fbbfd3a2 at Ex13.ncp.local>

Ciao from Germany,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From jb-openssl at wisemo.com  Mon Jan  7 19:38:12 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 7 Jan 2019 20:38:12 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190107183136.-eW61%steffen@sdaoden.eu>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
 <20190105193318.TPV_w%steffen@sdaoden.eu> <20190105221506.GA18502@roeckx.be>
 <20190107183136.-eW61%steffen@sdaoden.eu>
Message-ID: <95bceb59-b299-015a-f9c2-e2487a6998ad@wisemo.com>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190107/21564320/attachment-0001.html>

From steffen at sdaoden.eu  Mon Jan  7 21:31:10 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 07 Jan 2019 22:31:10 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <95bceb59-b299-015a-f9c2-e2487a6998ad@wisemo.com>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
 <20190105193318.TPV_w%steffen@sdaoden.eu> <20190105221506.GA18502@roeckx.be>
 <20190107183136.-eW61%steffen@sdaoden.eu>
 <95bceb59-b299-015a-f9c2-e2487a6998ad@wisemo.com>
Message-ID: <20190107213110.ORJSp%steffen@sdaoden.eu>

Good evening.

Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\
8ad at wisemo.com>:
 |Small corrections below:
 |
 |On 07/01/2019 19:31, Steffen Nurpmeso wrote:
 |
 ||...
 |||RAND_load_file() and all this stuff. Just make sure the os entropy \
 |||sources
 |||are available and then simply use RAND_bytes(). But don't expect it to
 |||succeed always.
 |
 ||And may i ask, what to do if it fails?  Try it in a loop a finite
 ||number of times, assuming it over-and-over detects it is in an
 ||error state and tries to reseed unless that succeeds, and bail if
 ||still without success thereafter?
 |
 ||Talking about the only program in the public that i represent:
 ||i will not abort that one just because a PRNG fails to produce
 ||some bytes that this program uses for the purpose of, well, having
 ||some (pseudo but) random bytes; because: this is _completely_
 ||disproportionate to the use cases of those random numbers.
 ||I guess the same could be said about UUIDS generated via PRNGs
 ||instead of how the standard defines them, etc. etc.
 ||Please do not say "use random(3) or rand(3)" now, please.
 ||So what to do?
 |
 |"Just failing" is precisely to allow you (and others) to do something 
 |sensible without the random bytes, such as using something less secure, 
 |or doing a polite error reporting to the user.

I have to say i struggle with the OpenSSL project release
announcements.  Really.  I see a short mail which simply points
users to some (granted super duper) web site (with custom fonts
and such -- it must look fantastic on such a tablet thing that
i do not own!), and on these pages, which i, unfortunately and
until now, over and over again look at, ... to see nothing.

I mean, OpenSSL is such a vivid part of the infrastructure, top
that with security, of the world, it is used a billion of times
each and every day, and how many people really now about the
details inside this library with the terrible interface names (a
few minutes ago i discovered the also new ADMISSIONS.pod
documentation, and this is a statement for a language with
namespaces and method-on-object not instance-on-function; i always
think by myself that some university should perform neurological
science on what looking at

  const STACK_OF(ADMISSIONS) *ADMISSION_SYNTAX_get0_contentsOfAdmissions(const ADMISSION_SYNTAX *as);

from 9 to 5 (or 14 to 04 or whatever)/365-52 actually causes, how
do you say that in english?, what damages to the brain it causes,
anyway.)

The thing is, i have just seen the release candidate announcement
for bash 5.0 a while ago, and know what my own release message
will (have to) look like.

I did know nothing of all that.

 |||> I think i will move away from RAND_ then, nonetheless, and at
 |||> least for the things i have control of.
 |||
 |||I don't think this is a good idea. In the case when there is no suitable \
 |||\
 |||entropy
 |||source, the OpenSSL RNG will fail to generate random bytes, indeed.
 |||But how do you expect your application to seed the RNG properly in this
 |||case? What is your application's entropy source? If you have one, which
 |
 ||Yes, that is the problem.  We do have several possibilities for
 ||VAL_RANDOM.  Some of them only seed our builtin ARC4
 ||implementation, which until now exposes the internal buffer as
 ...
 ||randomizing those weakly through the well-known algorithm from
 ||"Random number generators: good ones are hard to find", Park and
 ||Miller, Communications of the ACM, vol. 31, no. 10, October 1988,
 ||p. 1195 (a_aux_rand_weak()).  This is the code:
 ...
 |Note that since that ancient article, ARC4 was not only invented, 
 |but also found too insecure for modern use.

I seem to know that for things like save transport.
I have for example suppressed adding the 

   for(u.i = 5 * sizeof(a_aux_rand->b8); u.i != 0; --u.i)
      a_aux_rand_get8();

which follows the unscientific seeding.  (And which likely is also
unscientific given that we have been seeded with random data
rather than with key/nonce ... whatever.)

 |Enjoy

Not really!  For example i read

  The reseeding default values are applied only during creation of
  a DRBG instance.  To ensure that they are applied to the global
  and thread-local DRBG instances (<master>, resp. <public> and
  <private>), it is necessary to call
  RAND_DRBG_set_reseed_defaults() before creating any thread and
  before calling any cryptographic routines that obtain random
  data directly or indirectly.

Does this give me at least the promise that OPENSSL_init_ssl() can
be called without rendering RAND_DRBG_set_reseed_defaults(0,0,0,0)
effectively a useless call?
I see that said function may return error, but it seems that the
MAX_RESEED_INTERVAL it fails to accept is not a public variable!
I tend to do the much more expensive dance with
RAND_DRBG_get0_public() and RAND_DRBG_get0_master() and
individually applying RAND_DRBG_set_reseed_time_interval() as well
as RAND_DRBG_set_reseed_interval() on each of them.
Is this even allowed without calling OPENSSL_init_ssl() first?

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From openssl at jordan.maileater.net  Mon Jan  7 21:26:56 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Mon, 7 Jan 2019 21:26:56 +0000
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <f3ca663e-dbd1-4dcb-46a5-305fb9091576@wisemo.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
 <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
 <010101681a14473a-b5370c04-ae2c-4cbe-bce7-2b3385938cce-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090C5FE016931BBC166B133F98E0@MW2PR18MB2090.namprd18.prod.outlook.com>
 <f3ca663e-dbd1-4dcb-46a5-305fb9091576@wisemo.com>
Message-ID: <010101682a361f10-586a6851-0664-4cdb-8923-cab80ed91bc2-000000@us-west-2.amazonses.com>

[ Off topic for OpenSSL... ]

On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote:
> A chroot with no other reason to open /dev/null should not contain that
> file name, even on unix-like platforms (least privilege chroot design).


There's always a first reason :-)

But also:? /dev/null is part of the definition of UNIX
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html#tag_10_01>.?
Programs have every right to expect that it will be there.? Yes, you can
build a chroot environment that doesn't include it... but then you can't
complain when programs don't work in your environment.? You can also
build an environment that doesn't include system libraries, and there
are reasons to do so, but few programs will work in it.

Looking at Solaris, about 15% of the programs in /usr/bin and 5% of the
libraries in /usr/lib have a reference to /dev/null.

-- 
Jordan Brown, Oracle Solaris

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

From jb-openssl at wisemo.com  Mon Jan  7 21:40:37 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 7 Jan 2019 22:40:37 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190107213110.ORJSp%steffen@sdaoden.eu>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
 <20190105193318.TPV_w%steffen@sdaoden.eu> <20190105221506.GA18502@roeckx.be>
 <20190107183136.-eW61%steffen@sdaoden.eu>
 <95bceb59-b299-015a-f9c2-e2487a6998ad@wisemo.com>
 <20190107213110.ORJSp%steffen@sdaoden.eu>
Message-ID: <07f4dea3-1a62-0c8c-76a4-cbe56abc870a@wisemo.com>

On 07/01/2019 22:31, Steffen Nurpmeso wrote:
> Good evening.
> 
> Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\
> 8ad at wisemo.com>:
>   |Small corrections below:
>   | ...

Note that I do not represent the project at all, I am just another user 
trying to help you.

As such, I cannot really respond to your criticism of other project 
aspects, some of which I myself don't like either, while others are 
obvious to me as someone who has more or less followed along since this 
was a two-man Australian project.

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 jb-openssl at wisemo.com  Mon Jan  7 21:51:01 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 7 Jan 2019 22:51:01 +0100
Subject: [openssl-users] Session params output fails via cron
In-Reply-To: <010101682a361f10-586a6851-0664-4cdb-8923-cab80ed91bc2-000000@us-west-2.amazonses.com>
References: <D85394E7.170ED%Neil.Craig@bbc.co.uk>
 <e3cbbf43-fed7-e9a2-ee4f-34ceec673b3e@openssl.org>
 <D853A781.170F7%Neil.Craig@bbc.co.uk>
 <27c7b3bc-7734-fbe1-8577-efffca15f79c@wisemo.com>
 <D854EBE7.17182%Neil.Craig@bbc.co.uk>
 <592EDC27-3851-407C-B04E-3BBA5B2E86D9@akamai.com>
 <010101681a14473a-b5370c04-ae2c-4cbe-bce7-2b3385938cce-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090C5FE016931BBC166B133F98E0@MW2PR18MB2090.namprd18.prod.outlook.com>
 <f3ca663e-dbd1-4dcb-46a5-305fb9091576@wisemo.com>
 <010101682a361f10-586a6851-0664-4cdb-8923-cab80ed91bc2-000000@us-west-2.amazonses.com>
Message-ID: <f9567b47-c662-e184-6628-23926b097ede@wisemo.com>

On 07/01/2019 22:26, Jordan Brown wrote:
> [ Off topic for OpenSSL... ]
>
> On 1/7/2019 8:06 AM, Jakob Bohm via openssl-users wrote:
>> A chroot with no other reason to open /dev/null should not contain that
>> file name, even on unix-like platforms (least privilege chroot design).
>
>
> There's always a first reason :-)
>
> But also:? /dev/null is part of the definition of UNIX 
> <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap10.html#tag_10_01>.? 
> Programs have every right to expect that it will be there.? Yes, you 
> can build a chroot environment that doesn't include it... but then you 
> can't complain when programs don't work in your environment.? You can 
> also build an environment that doesn't include system libraries, and 
> there are reasons to do so, but few programs will work in it.
>
> Looking at Solaris, about 15% of the programs in /usr/bin and 5% of 
> the libraries in /usr/lib have a reference to /dev/null.
>
>
The whole point of a chroot jail is to deny a program access to any
and all parts of Unix (and the local flavor) it won't need.? For
example, most chroot jails remove /bin/ls, with ftp servers as the
major exception.

Thus /dev/null being part of UNIX/POSIX doesn't say anything about
its availability in chroot jails. Nor does it say anything about
its availability on non-unix platforms, many of which are explicitly
supported by the OpenSSL libraries.

For many programs, it is standard to chroot to a directory with
nothing or almost nothing after loading configuration files, code,
certificates etc. /var/empty and /var/www are common examples.


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 steffen at sdaoden.eu  Mon Jan  7 22:21:39 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Mon, 07 Jan 2019 23:21:39 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <07f4dea3-1a62-0c8c-76a4-cbe56abc870a@wisemo.com>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
 <20190105193318.TPV_w%steffen@sdaoden.eu> <20190105221506.GA18502@roeckx.be>
 <20190107183136.-eW61%steffen@sdaoden.eu>
 <95bceb59-b299-015a-f9c2-e2487a6998ad@wisemo.com>
 <20190107213110.ORJSp%steffen@sdaoden.eu>
 <07f4dea3-1a62-0c8c-76a4-cbe56abc870a@wisemo.com>
Message-ID: <20190107222139.7s9jy%steffen@sdaoden.eu>

Jakob Bohm via openssl-users wrote in <07f4dea3-1a62-0c8c-76a4-cbe56abc8\
70a at wisemo.com>:
 |On 07/01/2019 22:31, Steffen Nurpmeso wrote:
 |> Good evening.
 |> 
 |> Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\
 |> 8ad at wisemo.com>:
 |>|Small corrections below:
 |>| ...
 |
 |Note that I do not represent the project at all, I am just another user 
 |trying to help you.

Surprise!  Indeed i do see your name only once in the commits!
So now, what to do?  What is due?  Congratulations, or even an
excuse?  I had a very false impression indeed.  Excuse this miss
of mine, please.

 |As such, I cannot really respond to your criticism of other project 
 |aspects, some of which I myself don't like either, while others are 
 |obvious to me as someone who has more or less followed along since this 
 |was a two-man Australian project.

Then you lead me by more than a decade in respect to "following"
the project.  (I only saw, otherwise offline, the headers and
libraries fly by.)  (And in my granted lengthy text i thought
about changing my ARC4 thing to ChaCha, and not feed the bytes of
the pool as such, but run a Blake2 digest on top of it, and feed
the output of that.  For now, however, this ARC4 PRNG, and then
also well seeded, is really good enough for my purpose(s).)

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From steffen at sdaoden.eu  Mon Jan  7 23:26:25 2019
From: steffen at sdaoden.eu (Steffen Nurpmeso)
Date: Tue, 08 Jan 2019 00:26:25 +0100
Subject: [openssl-users] RNG behavior by default
In-Reply-To: <20190107183136.-eW61%steffen@sdaoden.eu>
References: <6935DA20-A077-4573-86AD-FF5873559D63@preveil.com>
 <450169f8ca7c43d1841c4c8052e78c72@Ex13.ncp.local>
 <20190104134848.7zm4s%steffen@sdaoden.eu> <20190104180735.GA25041@roeckx.be>
 <20190105193318.TPV_w%steffen@sdaoden.eu> <20190105221506.GA18502@roeckx.be>
 <20190107183136.-eW61%steffen@sdaoden.eu>
Message-ID: <20190107232625.g2S6h%steffen@sdaoden.eu>

Steffen Nurpmeso wrote in <20190107183136.-eW61%steffen at sdaoden.eu>:
  ...
 |  ...
 ||RAND_bytes() has always documented that it can fail. Most function
 ...
 |So, to me.., i do not see any possible error condition, since the
 |initial seeding has been testified with RAND_status().
 |
 |This is different now, and i will change the implementation as
 |soon as possible.  (This week.)

So i did, we disable the OpenSSL reseeding by directly calling
RAND_DRBG_set_reseed_defaults() after calling OPENSSL_init_ssl(),
which i hope will always be possible.
Be warned that i gave credit to both of you.

I have seen DRBG offers a lot of possibilities to control what
OpenSSL does, also regarding the fork handlers and all that.
Thanks for these possibilities, it is a terribly huge interface,
but it allows users to have control on what happens, instead of
sitting on an intransparent black box!  Getting something going on
such a thing causes grief, as it is hacky and otherwise
troublesome!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

From psteuer at mail.de  Tue Jan  8 01:36:40 2019
From: psteuer at mail.de (Patrick Steuer)
Date: Tue, 8 Jan 2019 02:36:40 +0100
Subject: [openssl-users] possible C bugs in ecp_nistp521
In-Reply-To: <62e4e761-5f33-1298-7dcd-6d21b4c4edb2@iis.sinica.edu.tw>
References: <62e4e761-5f33-1298-7dcd-6d21b4c4edb2@iis.sinica.edu.tw>
Message-ID: <e4b59229-4676-bf47-9333-f133f4edce2e@mail.de>

Dear Bo-Yin Yang,

I looked into your felem_square counterexample:

There is an overflow in the result's least significant 128-bit limb such 
that the computed result is 2^128 smaller than the actual result.

The general problem is the following..

The function's comment says:
/*-
  * felem_square sets |out| = |in|^2
  * On entry:
  *   in[i] < 2^62
  * On exit:
  *   out[i] < 17 * max(in[i]) * max(in[i])
  */

If you look at the function's code youll notice that given the entry 
assumption, the exit assertion's "less than" should actually be a
"less than or equal to" for in the case of all in[i]s being equal to say 
x, max(in[i])=x and out[0]=17*x^2.

So out[0] is stored in 128-bits, but for e.g. x=2^62-1, out[0]>2^128.

If its a bug depends on the contexts from which felem_square is called. 
If for some reason its inputs are guaranteed to satisfy some stricter 
entry condition than stated in the above comment (such that there is no 
overflow) things might be alright.

I didnt look at your other examples but id expect something similar.

Best Regards,

Patrick Steuer

From ananthuu741 at gmail.com  Tue Jan  8 05:56:40 2019
From: ananthuu741 at gmail.com (Ananthu Unnikrishnan)
Date: Tue, 8 Jan 2019 11:26:40 +0530
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
 <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
Message-ID: <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>

Can anyone please help on this? If u need any additional information please
let me know.

On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan <ananthuu741 at gmail.com>
wrote:

> Hi all,
>
> Adding more details to the previous mail. We have edited the OpenSSL code
> for implementing the polling for changed fd's as in OpenSSL speed command.
> Attached the code snippet of the same along with this mail.
> Mentioned below some observations which found doubtful:
>
> 1) We have got prints in ASYNC_FINISH case, before getting print in
> ASYNC_PAUSE case. Attaching the log also, so you can understand easily.
> 2) Shown below the code snippet which we have written to provide a write
> on fd.
>
> if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
>         printf("In dynamic engine | waitctx == NULL : %d\n", __LINE__);
>         return ret;
>     }
>
>     printf("\n----- In dynamic engine | After pausing | job is %lx |
> waitctx in resume job %lx |-----\n", job, waitctx);
>
>         if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id, &efd,
>                               &custom)) > 0) {
>         if (write(efd, &buf, sizeof(uint64_t)) == -1) {
>             printf("\nFailed to write\n");
>         }
>     }
>
> Here waitctx is getting NULL when we tried to fetch waitctx using
> ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB) ie.1176
> bytes contained in the job address from the engine,  we got correct data
> before calling ASYNC_pause() and but got half data zero data when we tried
> to access the same address after ASYNC_pause().
>
> Attaching both job structure contents before and after calling
> ASYNC_pause(). Also, we got the correct data in the same address when we
> have printed from ssl_start_async_job() before polling starts, where we
> have started the async_job
> .
> The prints starting with "In dynamic engine" are prints inside the engine,
> rest prints are from ss/ssl_lib.c. Kindly check this and please point out
> if anything is wrong somewhere. Thanks in advance.
>
>
> On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan <
> ananthuu741 at gmail.com> wrote:
>
>> Hi all,
>>
>>        We have implemented a dynamic engine and tested in the async mode
>> using OpenSSL speed command. But in a real network scenario, we have seen
>> only starting the async_job(in file ssl/ssl_lib.c, function:
>> ssl_start_async_job) in the OpenSSL. We haven't seen polling async_fd's for
>> resuming the job as in apps/speed.c(in speed command case).
>>         So can anyone please suggest any solution for resuming the
>> async_jobs in real network scenario? Thanks in advance.
>>
>>
>>
>>
>
> --
> With best Regards,
>
>          Ananthu
>
>
>

-- 
With best Regards,

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

From xj546641978 at gmail.com  Tue Jan  8 07:43:47 2019
From: xj546641978 at gmail.com (Jin Xie)
Date: Mon, 7 Jan 2019 23:43:47 -0800
Subject: [openssl-users] Problems on authentication during TLS handshake
Message-ID: <5c3455a3.1c69fb81.1e3a5.8433@mx.google.com>

Hello everyone,

I?m new at OpenSSL programming and encountered a problem while build TLS connection. I?m working on a crypto chip ATECC508A. So the client private key is stored in the chip and no way to get it out. However during standard TLS handshake, I need to provide client private key by ?SSL_CTX_use_private_key()? if server needs to identify the client. Because the server will give a ?challenge? to client and client needs to encrypt it by client private key. Then the server will decode it by client public key and check if they match. For your reference: https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake

I have written my sample client and server code. Everything works fine if I use my own test certificates: selft-signed CA and client cert signed by CA (this means I have the test client cert private key so that I could use SSL_CTX_use_private_key() to import it). 

The problem is here, in ATECC508A, I?m not able to provide private key directly but have API to sign any digests. So I wonder are there any ways to do some ?modification? during handshake? I have tried following two ways:

1. Using OpenSSL Engine. I see that we could set our own algorithms inside engine to overwrite original methods. I think signing ?challenge? is at EC_KEY_METHOD. So I write an EC_KEY_METHOD engine and load it successful. Besides I print ?enter? and ?leave? at the beginning and end of every function in EC_KEY_METHOD. When I do some tests using ?ECDSA_sign?, I could see ?enter? and ?leave? printed from my sign_sig and sign function. However if I run TLS connection, nothing printed (except engine initialization log) and authentication failed (obviously). Those means my own sign and verify functions hasn?t been called.

2. Set callback in SSL or SLL_ctx? I have checked the source code of these two structures but not sure how to do that.

Those are what I tried and of course failed every try. :( So could anyone point me what should I do? Maybe I used wrong engine, missed some important callback or others?

Best Regards,

Jim

=========

I post my client test code for your reference:

#include <openssl/ssl.h>
#include <openssl/conf.h>
#include "openssl/eccx08_engine.h"
#include "openssl/eccx08_engine_internal.h"

int main()
{
??? static ENGINE *ateccx08_engine;
??? OpenSSL_add_all_algorithms();
??? ERR_load_crypto_strings();

??? PRINTF("ENGINE_load_dynamic");
??? ENGINE_load_dynamic();

??? printf("CONF_modules_load_file");
??? if (!CONF_modules_load_file(NULL, NULL, CONF_MFLAGS_DEFAULT_SECTION))
??? {
??????? printf("Config failed to load");
??? }

??? printf("ENGINE_by_id");
??? ateccx08_engine = ENGINE_by_id("ateccx08");

??? if (ateccx08_engine == NULL)
??? {
??????? printf("Engine failed to load");
??? }

??? // after some initialization

??? // load client-side cert and key, signed by intermediate cert
??? SSL_CTX_use_certificate_file(m_ctx, ClientCertificateFileTest, SSL_FILETYPE_PEM);

??? // no need anymore because no way to extract private key
??? // SSL_CTX_use_PrivateKey_file(m_ctx, ClientPrivateKeyFileTest, SSL_FILETYPE_PEM);

??? // load intermediate cert, signed by CA
??? ?X509* chaincert = X509_new();
??? BIO* bio_cert = BIO_new_file(SignerCertificateFileTest, "rb");
??? PEM_read_bio_X509(bio_cert, &chaincert, NULL, NULL);
??? SSL_CTX_add1_chain_cert(m_ctx, chaincert)

??? m_ssl = SSL_new(m_ctx);

??? // get_seocket is my own API
??? m_sock = get_socket();

??? SSL_set_fd(m_ssl, m_sock)

??? // doing handshake and build connection, however no output from ECDSA sign algorithm
??? auto r = SSL_connect(m_ssl);
}



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

From openssl-users at dukhovni.org  Tue Jan  8 08:05:28 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 8 Jan 2019 03:05:28 -0500
Subject: [openssl-users] Problems on authentication during TLS handshake
In-Reply-To: <5c3455a3.1c69fb81.1e3a5.8433@mx.google.com>
References: <5c3455a3.1c69fb81.1e3a5.8433@mx.google.com>
Message-ID: <20190108080528.GN79754@straasha.imrryr.org>

On Mon, Jan 07, 2019 at 11:43:47PM -0800, Jin Xie wrote:

[ Going forward, please try to post plain-text with regular spaces,
  rather than Unicode non-breaking spaces. ]

>        // load client-side cert and key, signed by intermediate cert
>        SSL_CTX_use_certificate_file(m_ctx, ClientCertificateFileTest, SSL_FILETYPE_PEM);
> 
>        // no need anymore because no way to extract private key
>        // SSL_CTX_use_PrivateKey_file(m_ctx, ClientPrivateKeyFileTest, SSL_FILETYPE_PEM);

Your problem is here, you can't skip loading some form of private
key handle.  OpenSSL 1.1.1 provides an SSL_CTX_use_cert_and_key()
function, which allows the private key to passed as NULL, in which
case it will use the public key as a stand-in for the missing private
key.  All the relevant functions are in ssl/ssl_rsa.c, if you are
willing to read the source code to find the most suitable interface.

If you're using 1.1.0 or 1.0.2 there is probably another way, but
I don't know it off-hand.

-- 
	Viktor.

From aerowolf at gmail.com  Tue Jan  8 08:29:17 2019
From: aerowolf at gmail.com (Kyle Hamilton)
Date: Tue, 8 Jan 2019 02:29:17 -0600
Subject: [openssl-users] possible C bugs in ecp_nistp521
In-Reply-To: <e4b59229-4676-bf47-9333-f133f4edce2e@mail.de>
References: <62e4e761-5f33-1298-7dcd-6d21b4c4edb2@iis.sinica.edu.tw>
 <e4b59229-4676-bf47-9333-f133f4edce2e@mail.de>
Message-ID: <CAPMEXDZhSb-BsBSGFQ2jHpDdwogGG0=dvnKVz=nBdDf7U2nLKg@mail.gmail.com>

I would expect that correct results would be provided for all valid
inputs (including those inputs that are not otherwise constrained).
As such, I would class this as a bug in OpenSSL.

-Kyle H

On Mon, Jan 7, 2019 at 7:44 PM Patrick Steuer <psteuer at mail.de> wrote:
>
> Dear Bo-Yin Yang,
>
> I looked into your felem_square counterexample:
>
> There is an overflow in the result's least significant 128-bit limb such
> that the computed result is 2^128 smaller than the actual result.
>
> The general problem is the following..
>
> The function's comment says:
> /*-
>   * felem_square sets |out| = |in|^2
>   * On entry:
>   *   in[i] < 2^62
>   * On exit:
>   *   out[i] < 17 * max(in[i]) * max(in[i])
>   */
>
> If you look at the function's code youll notice that given the entry
> assumption, the exit assertion's "less than" should actually be a
> "less than or equal to" for in the case of all in[i]s being equal to say
> x, max(in[i])=x and out[0]=17*x^2.
>
> So out[0] is stored in 128-bits, but for e.g. x=2^62-1, out[0]>2^128.
>
> If its a bug depends on the contexts from which felem_square is called.
> If for some reason its inputs are guaranteed to satisfy some stricter
> entry condition than stated in the above comment (such that there is no
> overflow) things might be alright.
>
> I didnt look at your other examples but id expect something similar.
>
> Best Regards,
>
> Patrick Steuer
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From xj546641978 at gmail.com  Tue Jan  8 08:38:32 2019
From: xj546641978 at gmail.com (Jin Xie)
Date: Tue, 8 Jan 2019 00:38:32 -0800
Subject: [openssl-users] Problems on authentication during TLS handshake
In-Reply-To: <20190108080528.GN79754@straasha.imrryr.org>
References: <5c3455a3.1c69fb81.1e3a5.8433@mx.google.com>
 <20190108080528.GN79754@straasha.imrryr.org>
Message-ID: <5c346277.1c69fb81.bd5ee.e77a@mx.google.com>

Hi Viktor,

Thanks for your replay! Sorry for my wrong format and I would use plaint-text in the future. 

As for ?in which case it will use the public key as a stand-in for the missing private key?, do you mean use ?client cert public key? instead of ?client cert private key?? If so is it possible that I pass ?client cert public key? in ?SSL_CTX_use_PrivateKey_file?? (I?m running on 1.1 :(((( )

Thanks,

Jim

From: Viktor Dukhovni
Sent: Tuesday, January 8, 2019 12:05 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Problems on authentication during TLS handshake

On Mon, Jan 07, 2019 at 11:43:47PM -0800, Jin Xie wrote:

[ Going forward, please try to post plain-text with regular spaces,
  rather than Unicode non-breaking spaces. ]

>        // load client-side cert and key, signed by intermediate cert
>        SSL_CTX_use_certificate_file(m_ctx, ClientCertificateFileTest, SSL_FILETYPE_PEM);
> 
>        // no need anymore because no way to extract private key
>        // SSL_CTX_use_PrivateKey_file(m_ctx, ClientPrivateKeyFileTest, SSL_FILETYPE_PEM);

Your problem is here, you can't skip loading some form of private
key handle.  OpenSSL 1.1.1 provides an SSL_CTX_use_cert_and_key()
function, which allows the private key to passed as NULL, in which
case it will use the public key as a stand-in for the missing private
key.  All the relevant functions are in ssl/ssl_rsa.c, if you are
willing to read the source code to find the most suitable interface.

If you're using 1.1.0 or 1.0.2 there is probably another way, but
I don't know it off-hand.

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

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

From openssl-users at dukhovni.org  Tue Jan  8 09:10:38 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 8 Jan 2019 04:10:38 -0500
Subject: [openssl-users] Problems on authentication during TLS handshake
In-Reply-To: <5c346277.1c69fb81.bd5ee.e77a@mx.google.com>
References: <5c3455a3.1c69fb81.1e3a5.8433@mx.google.com>
 <20190108080528.GN79754@straasha.imrryr.org>
 <5c346277.1c69fb81.bd5ee.e77a@mx.google.com>
Message-ID: <20190108091037.GO79754@straasha.imrryr.org>

On Tue, Jan 08, 2019 at 12:38:32AM -0800, Jin Xie wrote:

> As for ?in which case it will use the public key as a stand-in for the
> missing private key?, do you mean use ?client cert public key? instead of
> ?client cert private key?? If so is it possible that I pass ?client cert
> public key? in ?SSL_CTX_use_PrivateKey_file?? (I?m running on 1.1 :(((( )

With engines, you have to use ENGINE_load_private_key(), and then
SSL_CTX_use_PrivateKey().

See the code in apps/s_client.c and load_key() in apps/apps.c.

-- 
	Viktor.

From xj546641978 at gmail.com  Tue Jan  8 18:32:07 2019
From: xj546641978 at gmail.com (Jin Xie)
Date: Tue, 8 Jan 2019 10:32:07 -0800
Subject: [openssl-users] Problems on authentication during TLS handshake
In-Reply-To: <20190108091037.GO79754@straasha.imrryr.org>
References: <5c3455a3.1c69fb81.1e3a5.8433@mx.google.com>
 <20190108080528.GN79754@straasha.imrryr.org>
 <5c346277.1c69fb81.bd5ee.e77a@mx.google.com>
 <20190108091037.GO79754@straasha.imrryr.org>
Message-ID: <CAFAhtnDgPQp9U1Cb8GhQi9y3kA9aVXFtT-Cv909BV7xsA=bftg@mail.gmail.com>

Thank you! I would have a try.

On Tue, Jan 8, 2019 at 1:10 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

> On Tue, Jan 08, 2019 at 12:38:32AM -0800, Jin Xie wrote:
>
> > As for ?in which case it will use the public key as a stand-in for the
> > missing private key?, do you mean use ?client cert public key? instead of
> > ?client cert private key?? If so is it possible that I pass ?client cert
> > public key? in ?SSL_CTX_use_PrivateKey_file?? (I?m running on 1.1 :(((( )
>
> With engines, you have to use ENGINE_load_private_key(), and then
> SSL_CTX_use_PrivateKey().
>
> See the code in apps/s_client.c and load_key() in apps/apps.c.
>
> --
>         Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190108/8c17c8b0/attachment.html>

From vieuxtech at gmail.com  Tue Jan  8 22:23:27 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Tue, 8 Jan 2019 14:23:27 -0800
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
	suite names?
Message-ID: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>

node.js has an API that lists all the cipher suite names that can be
validly passed to set_cipher_list(), but I don't see how to get them
for TLS1.3 to list the valid inputs to set_cipher_suites().

The openssl ciphers CLI doesn't seem able to do this either.

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_cipher_list.html
lists the 1.3 suites, there aren't many, so I could just hard-code
them into our API, but that's pretty fragile, I assume there will be a
few more, eventually.

Or, I guess I could just link to the openssl man page online for
TLS1.3, and tell people that
file:///home/sam/w/core/node/out/doc/api/crypto.html#crypto_crypto_getciphers
only works for TLS1.2 and below.

Cheers,
Sam

From antiac at gmail.com  Tue Jan  8 23:37:06 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Wed, 9 Jan 2019 00:37:06 +0100
Subject: [openssl-users] Problems on authentication during TLS handshake
In-Reply-To: <CAFAhtnDgPQp9U1Cb8GhQi9y3kA9aVXFtT-Cv909BV7xsA=bftg@mail.gmail.com>
References: <5c3455a3.1c69fb81.1e3a5.8433@mx.google.com>
 <20190108080528.GN79754@straasha.imrryr.org>
 <5c346277.1c69fb81.bd5ee.e77a@mx.google.com>
 <20190108091037.GO79754@straasha.imrryr.org>
 <CAFAhtnDgPQp9U1Cb8GhQi9y3kA9aVXFtT-Cv909BV7xsA=bftg@mail.gmail.com>
Message-ID: <CAPN6PEROOzmkjXBS0W1kN9qffNF_9c9t_AOpLj-+iYNL2aYUNQ@mail.gmail.com>

Il giorno mar 8 gen 2019 alle ore 19:32 Jin Xie <xj546641978 at gmail.com> ha
scritto:

> Thank you! I would have a try.
>
>
Look here: https://github.com/MicrochipTech/cryptoauth-openssl-engine

Antonio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190109/2db447d2/attachment-0001.html>

From xj546641978 at gmail.com  Wed Jan  9 00:01:02 2019
From: xj546641978 at gmail.com (Jin Xie)
Date: Tue, 8 Jan 2019 16:01:02 -0800
Subject: [openssl-users] Problems on authentication during TLS handshake
In-Reply-To: <CAPN6PEROOzmkjXBS0W1kN9qffNF_9c9t_AOpLj-+iYNL2aYUNQ@mail.gmail.com>
References: <5c3455a3.1c69fb81.1e3a5.8433@mx.google.com>
 <20190108080528.GN79754@straasha.imrryr.org>
 <5c346277.1c69fb81.bd5ee.e77a@mx.google.com>
 <20190108091037.GO79754@straasha.imrryr.org>
 <CAFAhtnDgPQp9U1Cb8GhQi9y3kA9aVXFtT-Cv909BV7xsA=bftg@mail.gmail.com>
 <CAPN6PEROOzmkjXBS0W1kN9qffNF_9c9t_AOpLj-+iYNL2aYUNQ@mail.gmail.com>
Message-ID: <CAFAhtnAVYoo6p5em8jVZVajNTT7vV4Zqcv_DQtkPb0-OeawYXQ@mail.gmail.com>

Agreed. I use this as my engine sample and rewrite it to support OpenSSL
1.1 since this repo only works in OpenSSL 1.0.2. This takes a long time.

Moreover very appreciated the support from everyone and Viktor, it's *important
*to use public key in SSL_CTX_use_PrivateKey(). Now my engine is working
during handshake and all encrypt processes and server is able to recognize
my client.

I would give some follow up in this thread if I have more results.

Thanks,

Jim



On Tue, Jan 8, 2019 at 3:37 PM Antonio Iacono <antiac at gmail.com> wrote:

> Il giorno mar 8 gen 2019 alle ore 19:32 Jin Xie <xj546641978 at gmail.com>
> ha scritto:
>
>> Thank you! I would have a try.
>>
>>
> Look here: https://github.com/MicrochipTech/cryptoauth-openssl-engine
>
> Antonio
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190108/83041439/attachment.html>

From openssl-users at dukhovni.org  Wed Jan  9 03:10:13 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 8 Jan 2019 22:10:13 -0500
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
Message-ID: <20190109031013.GQ79754@straasha.imrryr.org>

On Tue, Jan 08, 2019 at 02:23:27PM -0800, Sam Roberts wrote:

> node.js has an API that lists all the cipher suite names that can be
> validly passed to set_cipher_list(), but I don't see how to get them
> for TLS1.3 to list the valid inputs to set_cipher_suites().

The intent is that you SHOULD NOT generally customize the list.
All the ciphers in question are quite safe, and if the default
changes, you should probably go with that, rather than a frozen
time-capsule version.

Is there a good reason to want to change or freeze them at this
time?

-- 
	Viktor.

From rsalz at akamai.com  Wed Jan  9 03:18:57 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 9 Jan 2019 03:18:57 +0000
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <20190109031013.GQ79754@straasha.imrryr.org>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <20190109031013.GQ79754@straasha.imrryr.org>
Message-ID: <E6754718-5CE1-4FCF-8720-BCD64D8BD435@akamai.com>

I would expect that smartphone clients might want to prioritize CHACHA over AES, but I don't think Node cares about that environment.
 


From openssl at jordan.maileater.net  Wed Jan  9 03:27:44 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Wed, 9 Jan 2019 03:27:44 +0000
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <20190109031013.GQ79754@straasha.imrryr.org>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <20190109031013.GQ79754@straasha.imrryr.org>
Message-ID: <0101016830a6cd54-50bfb8fd-e53f-4f19-8662-ce62a869f97e-000000@us-west-2.amazonses.com>

On 1/8/2019 7:10 PM, Viktor Dukhovni wrote:
> The intent is that you SHOULD NOT generally customize the list. All
> the ciphers in question are quite safe, and if the default changes,
> you should probably go with that, rather than a frozen time-capsule
> version.
>
> Is there a good reason to want to change or freeze them at this time?
>

Our products allow the user to enable and disable individual ciphers, to
allow for both customer policy (e.g. a customer-specific approved-cipher
list) and for the possibility that one is found to be vulnerable.? They
are "quite safe" today... but what about tomorrow?


-- 
Jordan Brown, Oracle Solaris

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

From openssl-users at dukhovni.org  Wed Jan  9 03:44:07 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 8 Jan 2019 22:44:07 -0500
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <0101016830a6cd54-50bfb8fd-e53f-4f19-8662-ce62a869f97e-000000@us-west-2.amazonses.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <20190109031013.GQ79754@straasha.imrryr.org>
 <0101016830a6cd54-50bfb8fd-e53f-4f19-8662-ce62a869f97e-000000@us-west-2.amazonses.com>
Message-ID: <20190109034407.GR79754@straasha.imrryr.org>

On Wed, Jan 09, 2019 at 03:27:44AM +0000, Jordan Brown wrote:

> > Is there a good reason to want to change or freeze them at this time?
> 
> Our products allow the user to enable and disable individual ciphers, to
> allow for both customer policy (e.g. a customer-specific approved-cipher
> list) and for the possibility that one is found to be vulnerable.? They
> are "quite safe" today... but what about tomorrow?

The ciphersuites in TLS 1.3, are just the symmetric bulk encryption
algorithms coupled with a PRF (HKDF).

So what you get is AESGCM with SHA2 or CHACHA20 with Poly1305.
Breaks in either would be dramatic advances in cryptanalysis.  While
protocol designs are brittle, and public key algorithms are potentially
vulnerable to attack by future universal quantum computers, the
basic building blocks of modern symmetric cryptography are looking
quite robust for the forseeable future.  We're no longer dealing
with 1970's or 1980's designs like DES and RC4.

Yes, they could perhaps be broken, but there's precious little
evidence of that happening any time soon.

You could just provide a free-form emergency string parameter that
users are advised to not change unless some major advance makes it
necessary.  At that time, advice can be published as to what the
override setting should be.

-- 
	Viktor.

From vieuxtech at gmail.com  Wed Jan  9 04:19:45 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Tue, 8 Jan 2019 20:19:45 -0800
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <20190109031013.GQ79754@straasha.imrryr.org>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <20190109031013.GQ79754@straasha.imrryr.org>
Message-ID: <CA+Sj9TngT7HWYy9RgwRD6E6XS+4OQSwanxLxoxNUg8fsdYw7aQ@mail.gmail.com>

On Tue, Jan 8, 2019 at 7:10 PM Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Tue, Jan 08, 2019 at 02:23:27PM -0800, Sam Roberts wrote:
> > node.js has an API that lists all the cipher suite names that can be
> > validly passed to set_cipher_list(), but I don't see how to get them
> > for TLS1.3 to list the valid inputs to set_cipher_suites().
>
> The intent is that you SHOULD NOT generally customize the list.

There are many reasons users might want to customize it, writing unit
tests for example, to ensure that their software interoperates with
clients that only support some of the ciphers. For the same reasons
OpenSSL allows the cipher suite to be customized, Node.js exposes this
capability to its users, along with a recommendation to not do this
casually. The Node.js default will, of course, be the same as OpenSSL
for TLS1.3.

Anyhow, my question isn't about how to call set_cipher_suites(), its
about how to get the list of ciphers supported by OpenSSL for TLS1.3
in such a way that when new ciphers become available, they are
returned.

I realized the link to the API I provided, not that its that relevant,
was to my local dev filesystem, oops! The API is
https://nodejs.org/api/crypto.html#crypto_crypto_getciphers.

From openssl-users at dukhovni.org  Wed Jan  9 04:21:59 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 8 Jan 2019 23:21:59 -0500
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <0101016830d31044-da28b406-63f8-42c5-ad7d-9d6d6cb59fcc-000000@us-west-2.amazonses.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <20190109031013.GQ79754@straasha.imrryr.org>
 <0101016830a6cd54-50bfb8fd-e53f-4f19-8662-ce62a869f97e-000000@us-west-2.amazonses.com>
 <20190109034407.GR79754@straasha.imrryr.org>
 <0101016830d31044-da28b406-63f8-42c5-ad7d-9d6d6cb59fcc-000000@us-west-2.amazonses.com>
Message-ID: <20190109042159.GT79754@straasha.imrryr.org>

On Wed, Jan 09, 2019 at 04:16:05AM +0000, Jordan Brown wrote:

> > You could just provide a free-form emergency string parameter that
> > users are advised to not change unless some major advance makes it
> > necessary. At that time, advice can be published as to what the
> > override setting should be.
> 
> That doesn't sound like a 21st century user interface.

How do you plan to offer a built-in menu of algorithms that have
not yet been added to OpenSSL?  And if users are better off leaving
the list alone, why encourage that with a fancy UI?

> However, as I think about it, I remember that we already need a
> softcoded list of algorithms, to avoid offering (e.g.) the PSK
> algorithms.

In TLS 1.3, the handshake parameters are configured separately from
the cipherlist.  The use of (non-resumption) PSKs requires callbacks,
so they're never enabled out of the box.

> It sounds like TLS 1.3 will need the same.

Actually, it won't, nor did earlier versions, the ciphers were
listed by "openssl ciphers -v", but they can't get activated without
application support.

-- 
	Viktor.

From openssl at jordan.maileater.net  Wed Jan  9 04:16:05 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Wed, 9 Jan 2019 04:16:05 +0000
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <20190109034407.GR79754@straasha.imrryr.org>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <20190109031013.GQ79754@straasha.imrryr.org>
 <0101016830a6cd54-50bfb8fd-e53f-4f19-8662-ce62a869f97e-000000@us-west-2.amazonses.com>
 <20190109034407.GR79754@straasha.imrryr.org>
Message-ID: <0101016830d31044-da28b406-63f8-42c5-ad7d-9d6d6cb59fcc-000000@us-west-2.amazonses.com>

On 1/8/2019 7:44 PM, Viktor Dukhovni wrote:
> So what you get is AESGCM with SHA2 or CHACHA20 with Poly1305.
> Breaks in either would be dramatic advances in cryptanalysis.

History shows that protocols, algorithms, and implementations all have
flaws.? We assume that flaws will be discovered and design so that our
customers can work around them.

> You could just provide a free-form emergency string parameter that
> users are advised to not change unless some major advance makes it
> necessary. At that time, advice can be published as to what the
> override setting should be.

That doesn't sound like a 21st century user interface.

However, as I think about it, I remember that we already need a
softcoded list of algorithms, to avoid offering (e.g.) the PSK
algorithms.? It sounds like TLS 1.3 will need the same.? That's
unfortunate - I'd really like to treat the crypto subsystem as a black
box - but completely survivable.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

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

From openssl at jordan.maileater.net  Wed Jan  9 17:42:17 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Wed, 9 Jan 2019 17:42:17 +0000
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <20190109042159.GT79754@straasha.imrryr.org>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <20190109031013.GQ79754@straasha.imrryr.org>
 <0101016830a6cd54-50bfb8fd-e53f-4f19-8662-ce62a869f97e-000000@us-west-2.amazonses.com>
 <20190109034407.GR79754@straasha.imrryr.org>
 <0101016830d31044-da28b406-63f8-42c5-ad7d-9d6d6cb59fcc-000000@us-west-2.amazonses.com>
 <20190109042159.GT79754@straasha.imrryr.org>
Message-ID: <0101016833b52ba3-38db3a7b-9254-41d5-89bc-2e01ab3321cd-000000@us-west-2.amazonses.com>

On 1/8/2019 8:21 PM, Viktor Dukhovni wrote:
> How do you plan to offer a built-in menu of algorithms that have not
> yet been added to OpenSSL?


I'm a bit confused as to why we would need to - if the underlying
OpenSSL doesn't support a particular algorithm, then there's no need to
disable it.

The ideal would be that we ask OpenSSL what algorithms (and protocol
versions) it supports, and we export that list to the user.? However,
practically we've found that we couldn't do that even with TLS1.2,
because (a) "openssl ciphers" (and the underlying APIs) report PSK-* and
other algorithms we don't intend to support, and (b) the underlying
OpenSSL includes support for algorithms that our security policies don't
allow us to support.? Also, there's the question of whether a particular
algorithm or protocol version is supported but disabled by default, or
enabled by default.? For instance, today we support TLS 1.0, 1.1, and
1.2, but 1.0 is disabled by default.? That's a policy question that
OpenSSL can't help us with.


> And if users are better off leaving the list alone, why encourage that
> with a fancy UI? 


That's a good question, but at the same time we have a high-level UI
policy that we don't offer "non-fancy" UIs.


>> However, as I think about it, I remember that we already need a
>> softcoded list of algorithms, to avoid offering (e.g.) the PSK
>> algorithms.
> In TLS 1.3, the handshake parameters are configured separately from
> the cipherlist.  The use of (non-resumption) PSKs requires callbacks,
> so they're never enabled out of the box.
>
>> It sounds like TLS 1.3 will need the same.
> Actually, it won't, nor did earlier versions, the ciphers were
> listed by "openssl ciphers -v", but they can't get activated without
> application support.


Right... we found that when we blindly asked for the cipher list, it
included ciphers that weren't actually operable because we didn't have
the associated application support.? We had hoped to be able to use
relatively simple rules to determine the list of allowable ciphers, but
then found that we needed much more complex rules than were desirable.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

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

From bbrumley at gmail.com  Wed Jan  9 20:29:21 2019
From: bbrumley at gmail.com (Billy Brumley)
Date: Wed, 9 Jan 2019 22:29:21 +0200
Subject: [openssl-users] possible C bugs in ecp_nistp521
In-Reply-To: <CAPMEXDZhSb-BsBSGFQ2jHpDdwogGG0=dvnKVz=nBdDf7U2nLKg@mail.gmail.com>
References: <62e4e761-5f33-1298-7dcd-6d21b4c4edb2@iis.sinica.edu.tw>
 <e4b59229-4676-bf47-9333-f133f4edce2e@mail.de>
 <CAPMEXDZhSb-BsBSGFQ2jHpDdwogGG0=dvnKVz=nBdDf7U2nLKg@mail.gmail.com>
Message-ID: <CAFeDd5aNymy_WW=Fmc4PbE8xX5yzQ5857kcm0ZparVMULB4JJw@mail.gmail.com>

> I would expect that correct results would be provided for all valid
> inputs (including those inputs that are not otherwise constrained).
> As such, I would class this as a bug in OpenSSL.

These functions are not part of the public OpenSSL API so that's just
not how it works. There is a ton of internal code across the library
that makes assumptions about the inputs, e.g. in this case the
internal caller using some non-trivial representation that somehow
bounds limbs.

In this instance, I suspect Patrick's statement is valid -- hopefully
it's just a documentation typo and the bounds are tighter.

In any case, this (and any other might-be arithmetic bug) is
potentially a security issue so it shouldn't be discussed on a public
mailing list.

BBB

From dkg at fifthhorseman.net  Wed Jan  9 21:21:27 2019
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 09 Jan 2019 16:21:27 -0500
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
	suite names?
In-Reply-To: <0101016830d31044-da28b406-63f8-42c5-ad7d-9d6d6cb59fcc-000000@us-west-2.amazonses.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <20190109031013.GQ79754@straasha.imrryr.org>
 <0101016830a6cd54-50bfb8fd-e53f-4f19-8662-ce62a869f97e-000000@us-west-2.amazonses.com>
 <20190109034407.GR79754@straasha.imrryr.org>
 <0101016830d31044-da28b406-63f8-42c5-ad7d-9d6d6cb59fcc-000000@us-west-2.amazonses.com>
Message-ID: <87ef9lh6i0.fsf@fifthhorseman.net>

On Wed 2019-01-09 04:16:05 +0000, Jordan Brown wrote:
> On 1/8/2019 7:44 PM, Viktor Dukhovni wrote:
>> You could just provide a free-form emergency string parameter that
>> users are advised to not change unless some major advance makes it
>> necessary. At that time, advice can be published as to what the
>> override setting should be.
>
> That doesn't sound like a 21st century user interface.

a 21st century interface is: upgrade your software to the new patch
level that avoids the known flaws.

      --dkg

From minyard at acm.org  Thu Jan 10 02:54:30 2019
From: minyard at acm.org (Corey Minyard)
Date: Wed, 9 Jan 2019 20:54:30 -0600
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and certificate
	access
Message-ID: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>

I'm working on an application using openssl, and I would like to set 
some things up for verification based upon information in the 
certificate.? Unfortunately, from what I can tell, there is no way to do 
this.? (Maybe it's not a good idea.? Not sure.)

What I would like to do is pull out some information from the 
certificate that is being verified, set/modify the verify store based 
upon that information (basically chose the CA based upon something in 
the certificate.? What I really need is X509_STORE_CTX_get_cert(), but 
that function does not exist, and there's no way to get ctx->cert from 
what I can tell.? It's not available with SSL_get_peer_certificate at 
the point where the cert verify call is done.

It would also be nice to be able to replace the verify store in the 
X509_STORE_CTX, or empty it, but I haven't looked too hard at that.

More details on what I am trying to do follow, in case you are interested...

I am the maintainer for ser2net, a program that allows network 
connections to connect to serial ports.? People have asked for login 
security, but I refuse to transmit passwords like this over the network 
in the clear.? But, in reality, people are logging in over this 
interface, and it has bothered me for a while.? So, I've been looking at 
adding security.? I have rewritten ser2net to split it into two parts: a 
library that does general-purpose stream I/O to handle all the 
connections and the serial ports, and the main handling and 
configuration.? The library (called gensio) is a layered system, so you 
have TCP/UCP/SCTP/stdio/serial/IPMIsol available as low-level 
interfaces.? Then you have filter layers on top, like SSL and telnet.? 
So you can create an SCTP connection, put SSL on top of that, then put 
telnet on top of that, for instance.? I already have basic SSL support 
working.

My first inclination for a secure connection was to use ssh. However, 
ssh is not as well suited for this as I would have liked, and all the 
ssh libraries are tied to a file descriptor in ways that are not easily 
fixable, and thus can't be used on top of an abstract connection, which 
is what I need.? That was rather disappointing, as it would have been 
really nice to for users to just be able to ssh to ser2net.

So now I'm looking at doing something like what ssh does, but with 
openssl. Unfortunately, SSL has no concept of a userid and I would like 
to have it verify certificates from different stores based upon a 
userid.? I've come up with the following options:

 1. Send the userid in a lower layer filter so it is transmitted before
    ssl starts up.? This means the userid is not authenticated in any
    way, which seems like a bad idea.
 2. Set the userid in the certificate and use client authentication to
    authenticate the user logging in.? Set the username in the CN field
    of the certificate so it can't be changed, extract that and set the
    CA before verification.? This is what I'm currently trying to do,
    and I keep running into roadblocks.
 3. Create a filter layer that can sit on top of SSL that will basically
    do what SSL client authentication does, except it can get the userid
    as the first part of the data and then run the authentication from
    there.? This is definitely doable, and then the userid is
    transmitted encrypted (which seems nice) but it's duplicating some
    fairly complex code that would already be done for me by openssl.

I am afraid I am going to be stuck with option 3, which is not terrible, 
I suppose.? But does anyone have any ideas here?

Thanks,

-corey


From ananthuu741 at gmail.com  Thu Jan 10 09:39:26 2019
From: ananthuu741 at gmail.com (Ananthu Unnikrishnan)
Date: Thu, 10 Jan 2019 15:09:26 +0530
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
 <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
 <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>
Message-ID: <CADqiADhOP27jU6nie1PpXAF_vTe-XXJXb3F8hb0-EELF+_fGDQ@mail.gmail.com>

Hi all,

        We are not able to access the waitctx address from the job address
using ASYNC_get_wait_ctx(job) from a thread which starts in the bind
section of the dynamic engine. The job address is the same as that we got
using ASYNC_get_current_job.  Can anyone help on this?



On Tue, Jan 8, 2019 at 11:26 AM Ananthu Unnikrishnan <ananthuu741 at gmail.com>
wrote:

> Can anyone please help on this? If u need any additional information
> please let me know.
>
> On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan <ananthuu741 at gmail.com>
> wrote:
>
>> Hi all,
>>
>> Adding more details to the previous mail. We have edited the OpenSSL code
>> for implementing the polling for changed fd's as in OpenSSL speed command.
>> Attached the code snippet of the same along with this mail.
>> Mentioned below some observations which found doubtful:
>>
>> 1) We have got prints in ASYNC_FINISH case, before getting print in
>> ASYNC_PAUSE case. Attaching the log also, so you can understand easily.
>> 2) Shown below the code snippet which we have written to provide a write
>> on fd.
>>
>> if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
>>         printf("In dynamic engine | waitctx == NULL : %d\n", __LINE__);
>>         return ret;
>>     }
>>
>>     printf("\n----- In dynamic engine | After pausing | job is %lx |
>> waitctx in resume job %lx |-----\n", job, waitctx);
>>
>>         if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id, &efd,
>>                               &custom)) > 0) {
>>         if (write(efd, &buf, sizeof(uint64_t)) == -1) {
>>             printf("\nFailed to write\n");
>>         }
>>     }
>>
>> Here waitctx is getting NULL when we tried to fetch waitctx using
>> ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB) ie.1176
>> bytes contained in the job address from the engine,  we got correct data
>> before calling ASYNC_pause() and but got half data zero data when we tried
>> to access the same address after ASYNC_pause().
>>
>> Attaching both job structure contents before and after calling
>> ASYNC_pause(). Also, we got the correct data in the same address when we
>> have printed from ssl_start_async_job() before polling starts, where we
>> have started the async_job
>> .
>> The prints starting with "In dynamic engine" are prints inside the
>> engine, rest prints are from ss/ssl_lib.c. Kindly check this and please
>> point out if anything is wrong somewhere. Thanks in advance.
>>
>>
>> On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan <
>> ananthuu741 at gmail.com> wrote:
>>
>>> Hi all,
>>>
>>>        We have implemented a dynamic engine and tested in the async mode
>>> using OpenSSL speed command. But in a real network scenario, we have seen
>>> only starting the async_job(in file ssl/ssl_lib.c, function:
>>> ssl_start_async_job) in the OpenSSL. We haven't seen polling async_fd's for
>>> resuming the job as in apps/speed.c(in speed command case).
>>>         So can anyone please suggest any solution for resuming the
>>> async_jobs in real network scenario? Thanks in advance.
>>>
>>>
>>>
>>>
>>
>> --
>> With best Regards,
>>
>>          Ananthu
>>
>>
>>
>
> --
> With best Regards,
>
>          Ananthu
>
>
>

-- 
With best Regards,

         Ananthu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190110/824b6bf2/attachment-0001.html>

From vishwaskn at gmail.com  Thu Jan 10 11:49:19 2019
From: vishwaskn at gmail.com (vishwas k.n.)
Date: Thu, 10 Jan 2019 17:19:19 +0530
Subject: [openssl-users] SSL_sendfile
Message-ID: <CADH=hKo-Gons3yd4s0MjJL7wuyNcQa7iv=yZeeH8Xe43HW7-Ew@mail.gmail.com>

Hello All,

I had a question regarding supporting sendfile with OpenSSL. Is there a
branch which supports SSL version of the sendfile() ?.
I wasnt able to locate it in master branch.
If yes, could you please point me to it ?.
If no, could you please let me know the reason behind not having it in
OpenSSL. I find there are references where there is a SSL_sendfile which is
committed to freebsd and is available publicly. Hence the question.

thanks,
-vishwas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190110/e3d1b997/attachment.html>

From matt at openssl.org  Thu Jan 10 14:51:16 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 10 Jan 2019 14:51:16 +0000
Subject: [openssl-users] SSL_sendfile
In-Reply-To: <CADH=hKo-Gons3yd4s0MjJL7wuyNcQa7iv=yZeeH8Xe43HW7-Ew@mail.gmail.com>
References: <CADH=hKo-Gons3yd4s0MjJL7wuyNcQa7iv=yZeeH8Xe43HW7-Ew@mail.gmail.com>
Message-ID: <76b634b2-18ac-1138-2589-9434a80395dc@openssl.org>



On 10/01/2019 11:49, vishwas k.n. wrote:
> Hello All,
> 
> I had a question regarding supporting sendfile with OpenSSL. Is there a branch
> which supports SSL version of the sendfile() ?.

No, this doesn't exist.


> I wasnt able to locate it in master branch.
> If yes, could you please point me to it ?.
> If no, could you please let me know the reason behind not having it in OpenSSL.
> I find there are references where there is a SSL_sendfile which is committed to
> freebsd and is available publicly. Hence the question.

Well, the purpose of sendfile is to read data from one fd and write it to
another *but without going through user space*, i.e. it is a kernel level
operation. In this way it is much more efficient.

OpenSSL on the other hand is a user space library. All of its SSL/TLS processing
happens within user space - so the optimisation of doing it all in the kernel is
not an option(*). I suppose you could envisage an optimisation which is
effectively a combination of SSL_read()/SSL_write() but copying directly from
the internal OpenSSL buffers of one SSL object, into the internal OpenSSL
buffers of another SSL object. This would all still happen in user space, but
would avoid copying to a user application buffer in the middle.

I'm not aware of anyone asking for that capability before, but if someone wanted
to produce a pull request for it, it would be discussed and considered.

Matt

* Actually in the master branch there is current ongoing work to integrate
Kernel TLS support. This (optionally) moves encryption/decryption of records
into the kernel which might make a "real" sendfile possible at some point in the
future. See:

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


From openssl at jordan.maileater.net  Thu Jan 10 16:15:04 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Thu, 10 Jan 2019 16:15:04 +0000
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
Message-ID: <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>

On 1/9/2019 6:54 PM, Corey Minyard wrote:
> 2. Set the userid in the certificate and use client authentication to
> ?? authenticate the user logging in.? Set the username in the CN field
> ?? of the certificate so it can't be changed, extract that and set the
> ?? CA before verification.? This is what I'm currently trying to do,
> ?? and I keep running into roadblocks.

Why do you think you need to set the CA?

It seems like you should let OpenSSL verify the certificate against your
list of trusted CAs, and if it succeeds then you know that one of those
CAs vouches for this user's identity.? Then you look at their subject
name to derive the user ID (probably from its CN).? If you want to be
really paranoid - if you believe that Verisign can vouch for John and
Comodo can vouch for Sam, but not vice versa, factor the issuer name
into the process.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

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

From matt at openssl.org  Thu Jan 10 16:41:12 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 10 Jan 2019 16:41:12 +0000
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <CADqiADhOP27jU6nie1PpXAF_vTe-XXJXb3F8hb0-EELF+_fGDQ@mail.gmail.com>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
 <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
 <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>
 <CADqiADhOP27jU6nie1PpXAF_vTe-XXJXb3F8hb0-EELF+_fGDQ@mail.gmail.com>
Message-ID: <f0cb28ac-c683-e430-33f1-f1dad945e868@openssl.org>



On 10/01/2019 09:39, Ananthu Unnikrishnan wrote:
> Hi all,
> 
> ? ? ? ? We are not able to access the waitctx?address from the job address using
> ASYNC_get_wait_ctx(job) from a thread which starts in the bind section of the
> dynamic engine. The job address is the same as that we got
> using?ASYNC_get_current_job.? Can anyone help on this?

It's very unclear from the your various emails what you are trying to achieve
and the problem that you are experiencing.

>From the above it sounds like you are starting threads from inside your dynamic
engine? ASYNC_JOBs are always local to a thread. When a job is started it is
associated with the current thread. So ASYNC_get_current_job() returns the job
associated with the current thread. Similarly if you pause a job,
ASYNC_pause_job() must be called from that same thread. Finally if you restart a
paused job it must also be restarted on the same thread.

If you are starting new threads from within your engine then extreme care must
be taken to obey the above rules - otherwise you are likely to get strange results.

Matt


> 
> ? ? ? ? ?
> 
> On Tue, Jan 8, 2019 at 11:26 AM Ananthu Unnikrishnan <ananthuu741 at gmail.com
> <mailto:ananthuu741 at gmail.com>> wrote:
> 
>     Can anyone please help on this? If u need any additional information please
>     let me know.
> 
>     On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan <ananthuu741 at gmail.com
>     <mailto:ananthuu741 at gmail.com>> wrote:
> 
>         Hi all,
> 
>         Adding more details to the previous mail. We have edited the OpenSSL
>         code for implementing the polling for changed fd's?as in OpenSSL speed
>         command. Attached the code snippet of the same along with this mail.
>         Mentioned below some observations which found doubtful:
> 
>         1) We have got prints in ASYNC_FINISH case, before getting print in
>         ASYNC_PAUSE case. Attaching the log also, so you can understand easily.?
>         2) Shown below the code snippet which we have written to provide a write
>         on fd.
> 
>         if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
>         ? ? ? ? printf("In dynamic engine | waitctx == NULL : %d\n", __LINE__);
>         ? ? ? ? return ret;
>         ? ? }
> 
>         ? ? printf("\n----- In dynamic engine | After pausing | job is %lx |?
>         waitctx in resume job %lx |-----\n", job, waitctx);
> 
>         ? ? ? ? if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id, &efd,
>         ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &custom)) > 0) {
>         ? ? ? ? if (write(efd, &buf, sizeof(uint64_t)) == -1) {
>         ? ? ? ? ? ? printf("\nFailed to write\n");
>         ? ? ? ? }
>         ? ? }
> 
>         Here waitctx is getting NULL when we tried to fetch waitctx using
>         ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB) ie.1176
>         bytes contained in the job address from the engine,? we got correct data
>         before calling ASYNC_pause() and but got half data zero data when we
>         tried to access the same address after ASYNC_pause().?
> 
>         Attaching both job structure contents before and after calling
>         ASYNC_pause(). Also, we got the correct data in the same address when we
>         have printed from ssl_start_async_job() before polling starts, where we
>         have started the async_job
>         .?
>         The prints starting with "In dynamic engine" are prints inside the
>         engine, rest prints are from ss/ssl_lib.c. Kindly check this and please
>         point out if anything is wrong somewhere. Thanks in advance.
> 
> 
>         On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan
>         <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>> wrote:
> 
>             Hi all,
> 
>             ?????? We have implemented a dynamic engine and tested in the async
>             mode using OpenSSL speed command. But in a real network scenario, we
>             have seen only starting the async_job(in file ssl/ssl_lib.c,
>             function: ssl_start_async_job) in the OpenSSL. We haven't seen
>             polling async_fd's for resuming the job as in apps/speed.c(in speed
>             command case).
>             ??????? So can anyone please suggest any solution for resuming the
>             async_jobs in real network scenario? Thanks in advance.
> 
> 
> 
> 
> 
>         -- 
>         With best Regards,?
> 
>         ???????? Ananthu
> 
> 
> 
> 
>     -- 
>     With best Regards,?
> 
>     ???????? Ananthu
> 
> 
> 
> 
> -- 
> With best Regards,?
> 
> ???????? Ananthu
> 
> 
> 

From openssl-users at dukhovni.org  Thu Jan 10 17:17:27 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 10 Jan 2019 12:17:27 -0500
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
Message-ID: <20190110171727.GY79754@straasha.imrryr.org>

On Wed, Jan 09, 2019 at 08:54:30PM -0600, Corey Minyard wrote:


> What I would like to do is pull out some information from the 
> certificate that is being verified, set/modify the verify store based 
> upon that information (basically chose the CA based upon something in 
> the certificate.? What I really need is X509_STORE_CTX_get_cert(), but 
> that function does not exist,

It does in OpenSSL 1.1.0 and later:

    See X509_STORE_CTX_get0_cert().

In OpenSSL 1.0.2 the structures are not opaque, so Postfix has forward
compatibility macros:

    https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls.h#L92-L110

-- 
	Viktor.

From Michael.Wojcik at microfocus.com  Thu Jan 10 17:00:27 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 10 Jan 2019 17:00:27 +0000
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>
Message-ID: <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown
> Sent: Thursday, January 10, 2019 11:15

> On 1/9/2019 6:54 PM, Corey Minyard wrote:
>> 2. Set the userid in the certificate and use client authentication to
>>   authenticate the user logging in.  Set the username in the CN field
>>   of the certificate so it can't be changed, extract that and set the
>>   CA before verification.  This is what I'm currently trying to do,
>>   and I keep running into roadblocks.

> Why do you think you need to set the CA?

Agreed. That's an odd requirement.

> Then you look at their subject name to derive the user ID (probably from its CN).

That's one logical option, but some systems (e.g. IBM zOS) instead maintain a database mapping client certificates to system user IDs. That has the advantage of not imposing any particular requirement on the client certificate's subject name format, with the disadvantage of additional administration. (For HTTPS, there's a provision for "automatic registration" where an unrecognized but valid and trusted client certificate will trigger HTTP Basic Authentication, and if those credentials are verified by the OS, the certificate is added to the database.) The database may index certificates by subject DN (for ease of administration, e.g. when certificates are renewed) or by fingerprint (as a defense against impersonation if a CA is compromised).

> If you want to be really paranoid - if you believe that Verisign can vouch for John
> and Comodo can vouch for Sam, but not vice versa, factor the issuer name into the process.

Right. For the original "set the CA" plan to work, you would need to already have some association between client certificates and CAs, so you can simply check that a validated client certificate was issued by the expected CA.

But again this would be an unusual requirement; and even if it exists, the contemporary standard mechanism for guarding against rogue or compromised CAs is Certificate Transparency. Checking CT logs seems like overkill in this case, and it would arguably be more useful to implement revocation checks and other defenses first; but if restricting certificates by issuer is important for some reason, CT might be a better approach than inventing your own mechanism.

Regarding Corey's original note: SSL/TLS does not have a "username" concept because it would be redundant or inconsistent. A certificate is a peer identifier; it takes the place of a username.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


From ananthuu741 at gmail.com  Thu Jan 10 18:09:40 2019
From: ananthuu741 at gmail.com (Ananthu Unnikrishnan)
Date: Thu, 10 Jan 2019 23:39:40 +0530
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <f0cb28ac-c683-e430-33f1-f1dad945e868@openssl.org>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
 <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
 <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>
 <CADqiADhOP27jU6nie1PpXAF_vTe-XXJXb3F8hb0-EELF+_fGDQ@mail.gmail.com>
 <f0cb28ac-c683-e430-33f1-f1dad945e868@openssl.org>
Message-ID: <CADqiADhYtL8pyR87UZvMXOCf7VARbLmzKuJ7fz-sHD5=ad5seA@mail.gmail.com>

Hi Matt,

        Thanks a lot for the reply.

       After calling ASYNC_pause_job() from the engine, control will
transfer to the place where we start the ASYNC_start_job right? So how can
we write the code to put a trigger on fd in the same thread? If I am wrong
please correct me. Also if u can suggest where resume operation should be
done, it would be helpful.

On Thu, Jan 10, 2019 at 10:11 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 10/01/2019 09:39, Ananthu Unnikrishnan wrote:
> > Hi all,
> >
> >         We are not able to access the waitctx address from the job
> address using
> > ASYNC_get_wait_ctx(job) from a thread which starts in the bind section
> of the
> > dynamic engine. The job address is the same as that we got
> > using ASYNC_get_current_job.  Can anyone help on this?
>
> It's very unclear from the your various emails what you are trying to
> achieve
> and the problem that you are experiencing.
>
> From the above it sounds like you are starting threads from inside your
> dynamic
> engine? ASYNC_JOBs are always local to a thread. When a job is started it
> is
> associated with the current thread. So ASYNC_get_current_job() returns the
> job
> associated with the current thread. Similarly if you pause a job,
> ASYNC_pause_job() must be called from that same thread. Finally if you
> restart a
> paused job it must also be restarted on the same thread.
>
> If you are starting new threads from within your engine then extreme care
> must
> be taken to obey the above rules - otherwise you are likely to get strange
> results.
>
> Matt
>
>
> >
> >
> >
> > On Tue, Jan 8, 2019 at 11:26 AM Ananthu Unnikrishnan <
> ananthuu741 at gmail.com
> > <mailto:ananthuu741 at gmail.com>> wrote:
> >
> >     Can anyone please help on this? If u need any additional information
> please
> >     let me know.
> >
> >     On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan <
> ananthuu741 at gmail.com
> >     <mailto:ananthuu741 at gmail.com>> wrote:
> >
> >         Hi all,
> >
> >         Adding more details to the previous mail. We have edited the
> OpenSSL
> >         code for implementing the polling for changed fd's as in OpenSSL
> speed
> >         command. Attached the code snippet of the same along with this
> mail.
> >         Mentioned below some observations which found doubtful:
> >
> >         1) We have got prints in ASYNC_FINISH case, before getting print
> in
> >         ASYNC_PAUSE case. Attaching the log also, so you can understand
> easily.
> >         2) Shown below the code snippet which we have written to provide
> a write
> >         on fd.
> >
> >         if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
> >                 printf("In dynamic engine | waitctx == NULL : %d\n",
> __LINE__);
> >                 return ret;
> >             }
> >
> >             printf("\n----- In dynamic engine | After pausing | job is
> %lx |
> >         waitctx in resume job %lx |-----\n", job, waitctx);
> >
> >                 if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id,
> &efd,
> >                                       &custom)) > 0) {
> >                 if (write(efd, &buf, sizeof(uint64_t)) == -1) {
> >                     printf("\nFailed to write\n");
> >                 }
> >             }
> >
> >         Here waitctx is getting NULL when we tried to fetch waitctx using
> >         ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB)
> ie.1176
> >         bytes contained in the job address from the engine,  we got
> correct data
> >         before calling ASYNC_pause() and but got half data zero data
> when we
> >         tried to access the same address after ASYNC_pause().
> >
> >         Attaching both job structure contents before and after calling
> >         ASYNC_pause(). Also, we got the correct data in the same address
> when we
> >         have printed from ssl_start_async_job() before polling starts,
> where we
> >         have started the async_job
> >         .
> >         The prints starting with "In dynamic engine" are prints inside
> the
> >         engine, rest prints are from ss/ssl_lib.c. Kindly check this and
> please
> >         point out if anything is wrong somewhere. Thanks in advance.
> >
> >
> >         On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan
> >         <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>> wrote:
> >
> >             Hi all,
> >
> >                    We have implemented a dynamic engine and tested in
> the async
> >             mode using OpenSSL speed command. But in a real network
> scenario, we
> >             have seen only starting the async_job(in file ssl/ssl_lib.c,
> >             function: ssl_start_async_job) in the OpenSSL. We haven't
> seen
> >             polling async_fd's for resuming the job as in
> apps/speed.c(in speed
> >             command case).
> >                     So can anyone please suggest any solution for
> resuming the
> >             async_jobs in real network scenario? Thanks in advance.
> >
> >
> >
> >
> >
> >         --
> >         With best Regards,
> >
> >                  Ananthu
> >
> >
> >
> >
> >     --
> >     With best Regards,
> >
> >              Ananthu
> >
> >
> >
> >
> > --
> > With best Regards,
> >
> >          Ananthu
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


-- 
With best Regards,

         Ananthu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190110/6d68ee53/attachment.html>

From jb-openssl at wisemo.com  Thu Jan 10 18:32:02 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 10 Jan 2019 19:32:02 +0100
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>
Message-ID: <1a000a0d-e62a-c795-6d56-0e18fe183444@wisemo.com>

On 10/01/2019 18:00, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown
>> Sent: Thursday, January 10, 2019 11:15
>> On 1/9/2019 6:54 PM, Corey Minyard wrote:
>>> 2. Set the userid in the certificate and use client authentication to
>>>    authenticate the user logging in.  Set the username in the CN field
>>>    of the certificate so it can't be changed, extract that and set the
>>>    CA before verification.  This is what I'm currently trying to do,
>>>    and I keep running into roadblocks.
>> Why do you think you need to set the CA?
> Agreed. That's an odd requirement.
>
>> Then you look at their subject name to derive the user ID (probably from its CN).
> That's one logical option, but some systems (e.g. IBM zOS) instead maintain a database mapping client certificates to system user IDs. That has the advantage of not imposing any particular requirement on the client certificate's subject name format, with the disadvantage of additional administration. (For HTTPS, there's a provision for "automatic registration" where an unrecognized but valid and trusted client certificate will trigger HTTP Basic Authentication, and if those credentials are verified by the OS, the certificate is added to the database.) The database may index certificates by subject DN (for ease of administration, e.g. when certificates are renewed) or by fingerprint (as a defense against impersonation if a CA is compromised).
>
>> If you want to be really paranoid - if you believe that Verisign can vouch for John
>> and Comodo can vouch for Sam, but not vice versa, factor the issuer name into the process.
> Right. For the original "set the CA" plan to work, you would need to already have some association between client certificates and CAs, so you can simply check that a validated client certificate was issued by the expected CA.
>
> But again this would be an unusual requirement; and even if it exists, the contemporary standard mechanism for guarding against rogue or compromised CAs is Certificate Transparency. Checking CT logs seems like overkill in this case, and it would arguably be more useful to implement revocation checks and other defenses first; but if restricting certificates by issuer is important for some reason, CT might be a better approach than inventing your own mechanism.
CT does nothing of the sort, it just provides a means to ensure all
certificates are potentially subject to 3rd party audits.

And CT cannot be legally used for user certificates anyway because
CT publishes unredacted certificate content to the world.

One really should be careful with security ideas from a company whose
main source of income is to spy on the world population for profit.

> Regarding Corey's original note: SSL/TLS does not have a "username" concept because it would be redundant or inconsistent. A certificate is a peer identifier; it takes the place of a username.

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 tonyxie87 at gmail.com  Thu Jan 10 18:46:51 2019
From: tonyxie87 at gmail.com (Tony Xie)
Date: Thu, 10 Jan 2019 14:46:51 -0400
Subject: [openssl-users] Send SNI by default
Message-ID: <CAJSo2ud+o09LfN_YkniGpqWO6RaORD4ZFQdimWRmPvCpMXuHqA@mail.gmail.com>

Is there a configuration inside of openssl to send SNI by default. The
equivalent to executing:

openssl s_client -connect host:port -servername name

with the `-servername` option being omitted and implied to be the host by
default.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190110/e93a30e6/attachment.html>

From minyard at acm.org  Thu Jan 10 18:55:01 2019
From: minyard at acm.org (Corey Minyard)
Date: Thu, 10 Jan 2019 12:55:01 -0600
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>
Message-ID: <866074a5-055f-a97c-f233-2c7dae338338@acm.org>

On 1/10/19 11:00 AM, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown
>> Sent: Thursday, January 10, 2019 11:15
>> On 1/9/2019 6:54 PM, Corey Minyard wrote:
>>> 2. Set the userid in the certificate and use client authentication to
>>>    authenticate the user logging in.  Set the username in the CN field
>>>    of the certificate so it can't be changed, extract that and set the
>>>    CA before verification.  This is what I'm currently trying to do,
>>>    and I keep running into roadblocks.
>> Why do you think you need to set the CA?
> Agreed. That's an odd requirement.

Thanks for the responses.

It is unusual, perhaps, but I'm trying to implement something like ssh 
does.? I can't expect users of ser2net to obtain certificates from a 
real certificate authority, that's too high a barrier for entry.? I want 
them to be able to generate a key pair, put the public key on the server 
in their account, and authenticate against that.

It's a balance of getting reasonable security that people will actually use.

-corey


From georg.hoellrigl at gmx.at  Thu Jan 10 18:51:07 2019
From: georg.hoellrigl at gmx.at (=?ISO-8859-1?Q?Georg_H=F6llrigl?=)
Date: Thu, 10 Jan 2019 19:51:07 +0100
Subject: [openssl-users] Send SNI by default
In-Reply-To: <CAJSo2ud+o09LfN_YkniGpqWO6RaORD4ZFQdimWRmPvCpMXuHqA@mail.gmail.com>
Message-ID: <0MdWO8-1gw1R410Ye-00PLoc@mail.gmx.com>

That is the default starting from openssl 1.1.1.
Kind RegardsGeorg?
-------- Urspr?ngliche Nachricht --------Von: Tony Xie <tonyxie87 at gmail.com> Datum: 10.01.19  19:46  (GMT+01:00) An: openssl-users at openssl.org Betreff: [openssl-users] Send SNI by default 
Is there a configuration inside of openssl to send SNI by default. The equivalent to executing:
openssl s_client -connect host:port -servername name
with the `-servername` option being omitted and implied to be the host by default.?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190110/95ef4d37/attachment.html>

From minyard at acm.org  Thu Jan 10 18:56:24 2019
From: minyard at acm.org (Corey Minyard)
Date: Thu, 10 Jan 2019 12:56:24 -0600
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <20190110171727.GY79754@straasha.imrryr.org>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <20190110171727.GY79754@straasha.imrryr.org>
Message-ID: <dcfb3bdf-4765-ffc8-bde2-c06843afae5b@acm.org>

On 1/10/19 11:17 AM, Viktor Dukhovni wrote:
> On Wed, Jan 09, 2019 at 08:54:30PM -0600, Corey Minyard wrote:
>
>
>> What I would like to do is pull out some information from the
>> certificate that is being verified, set/modify the verify store based
>> upon that information (basically chose the CA based upon something in
>> the certificate.? What I really need is X509_STORE_CTX_get_cert(), but
>> that function does not exist,
> It does in OpenSSL 1.1.0 and later:
>
>      See X509_STORE_CTX_get0_cert().
>
> In OpenSSL 1.0.2 the structures are not opaque, so Postfix has forward
> compatibility macros:
>
>      https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls.h#L92-L110
>
That's useful, thanks.? The macros are just what I needed.

-corey


From jb-openssl at wisemo.com  Thu Jan 10 22:10:11 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Thu, 10 Jan 2019 23:10:11 +0100
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <866074a5-055f-a97c-f233-2c7dae338338@acm.org>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>
 <866074a5-055f-a97c-f233-2c7dae338338@acm.org>
Message-ID: <b674caac-d6d5-39eb-a0df-96aaebefe7ba@wisemo.com>

On 10/01/2019 19:55, Corey Minyard wrote:
> On 1/10/19 11:00 AM, Michael Wojcik wrote:
>>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On 
>>> Behalf Of Jordan Brown
>>> Sent: Thursday, January 10, 2019 11:15
>>> On 1/9/2019 6:54 PM, Corey Minyard wrote:
>>>> 2. Set the userid in the certificate and use client authentication to
>>>> ?? authenticate the user logging in.? Set the username in the CN field
>>>> ?? of the certificate so it can't be changed, extract that and set the
>>>> ?? CA before verification.? This is what I'm currently trying to do,
>>>> ?? and I keep running into roadblocks.
>>> Why do you think you need to set the CA?
>> Agreed. That's an odd requirement.
>
> Thanks for the responses.
>
> It is unusual, perhaps, but I'm trying to implement something like ssh 
> does.? I can't expect users of ser2net to obtain certificates from a 
> real certificate authority, that's too high a barrier for entry.? I 
> want them to be able to generate a key pair, put the public key on the 
> server in their account, and authenticate against that.
>
> It's a balance of getting reasonable security that people will 
> actually use.
>
A simpler solution is to report "Any client CA accepted", then
compare the returned certificate fingerprint (strong hash of
DER-encoded end cert) against a user database, listing the
user name for each cert.

Validation then only checks if the certificate is revoked or
technically invalid (expired, claims to be signed by a CA
that didn't, syntactically invalid, wrong Extended-Key-Usage
etc.).? But signed by a completely unknown CA, or self-signed
is A-OK as long as the end cert is listed as belonging to that
user (similar to an SSH public key).

By the way, I do think ssh can be made to work by handing the
SSH library the actual serial port handles once the user has
been authenticated.? Some SSH libraries may even be able to
do things like BREAK via standard SSH mechanisms.




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 charlesm at mcn.org  Thu Jan 10 23:07:35 2019
From: charlesm at mcn.org (Charles Mills)
Date: Thu, 10 Jan 2019 15:07:35 -0800
Subject: [openssl-users] Close TCP socket after SSL_clear()?
Message-ID: <01ae01d4a939$466214d0$d3263e70$@mcn.org>

On Windows, for a new session, I am issuing a Windows accept() followed by
SSL_new(), SSL_set_fd() and so forth.

 

When the session sees some sort of an abnormal receive condition, I am doing

 

       int retCode = SSL_get_shutdown(sessionSSL);

       if ( retCode & SSL_RECEIVED_SHUTDOWN )

       {

              SSL_shutdown(sessionSSL);

       }

       else

       {

              SSL_clear(sessionSSL);

       }

 

Questions:

 

1.       Do I also need to do a closesocket() (equivalent to UNIX close())
on the Windows socket?

2.       Does anyone want to critique the above logic in any other way?

 

The code basically "works" but I see evidence that a Windows TCP session is
still open following an SSL error.

 

Thanks,

 

Charles Mills



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

From vishwaskn at gmail.com  Fri Jan 11 03:39:05 2019
From: vishwaskn at gmail.com (vishwas k.n.)
Date: Fri, 11 Jan 2019 09:09:05 +0530
Subject: [openssl-users] SSL_sendfile
In-Reply-To: <76b634b2-18ac-1138-2589-9434a80395dc@openssl.org>
References: <CADH=hKo-Gons3yd4s0MjJL7wuyNcQa7iv=yZeeH8Xe43HW7-Ew@mail.gmail.com>
 <76b634b2-18ac-1138-2589-9434a80395dc@openssl.org>
Message-ID: <CADH=hKqt96vvTyAS+uEAEcOUqv+J=G6PNuoStcU+zM3Mek7ZKw@mail.gmail.com>

Thanks for the quick and detailed response Matt. Much appreciated.
-vishwas.

On Thu, Jan 10, 2019 at 8:21 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 10/01/2019 11:49, vishwas k.n. wrote:
> > Hello All,
> >
> > I had a question regarding supporting sendfile with OpenSSL. Is there a
> branch
> > which supports SSL version of the sendfile() ?.
>
> No, this doesn't exist.
>
>
> > I wasnt able to locate it in master branch.
> > If yes, could you please point me to it ?.
> > If no, could you please let me know the reason behind not having it in
> OpenSSL.
> > I find there are references where there is a SSL_sendfile which is
> committed to
> > freebsd and is available publicly. Hence the question.
>
> Well, the purpose of sendfile is to read data from one fd and write it to
> another *but without going through user space*, i.e. it is a kernel level
> operation. In this way it is much more efficient.
>
> OpenSSL on the other hand is a user space library. All of its SSL/TLS
> processing
> happens within user space - so the optimisation of doing it all in the
> kernel is
> not an option(*). I suppose you could envisage an optimisation which is
> effectively a combination of SSL_read()/SSL_write() but copying directly
> from
> the internal OpenSSL buffers of one SSL object, into the internal OpenSSL
> buffers of another SSL object. This would all still happen in user space,
> but
> would avoid copying to a user application buffer in the middle.
>
> I'm not aware of anyone asking for that capability before, but if someone
> wanted
> to produce a pull request for it, it would be discussed and considered.
>
> Matt
>
> * Actually in the master branch there is current ongoing work to integrate
> Kernel TLS support. This (optionally) moves encryption/decryption of
> records
> into the kernel which might make a "real" sendfile possible at some point
> in the
> future. See:
>
> https://github.com/openssl/openssl/pull/7848
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190111/ca025014/attachment-0001.html>

From matt at openssl.org  Fri Jan 11 09:41:49 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 11 Jan 2019 09:41:49 +0000
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <CADqiADhYtL8pyR87UZvMXOCf7VARbLmzKuJ7fz-sHD5=ad5seA@mail.gmail.com>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
 <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
 <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>
 <CADqiADhOP27jU6nie1PpXAF_vTe-XXJXb3F8hb0-EELF+_fGDQ@mail.gmail.com>
 <f0cb28ac-c683-e430-33f1-f1dad945e868@openssl.org>
 <CADqiADhYtL8pyR87UZvMXOCf7VARbLmzKuJ7fz-sHD5=ad5seA@mail.gmail.com>
Message-ID: <2c98a823-b680-9cdb-104d-6f66c4bba652@openssl.org>



On 10/01/2019 18:09, Ananthu Unnikrishnan wrote:
> Hi Matt,
> 
> ??????? Thanks a lot for the reply.
> 
> ?????? After calling ASYNC_pause_job() from the engine, control will transfer to
> the place where we start the ASYNC_start_job right? So how can we write the code
> to put a trigger on fd in the same thread?

I'm not saying you can't use threads to do this - only that you need to be
careful about using them and must obey the rules.


> If I am wrong? please correct me.
> Also if u can suggest where resume operation should be done, it would be helpful.

Typically the calling application will wait on the fd (e.g. using "select" or
similar) until it is readable. Once it sees the fd as readable then it calls
ASYNC_start_job() again.


As an aside you may also be interested in this PR that is currently being reviewed:

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

This adds an alternative mechanism for signalling other than using fds (i.e. to
use a callback instead) and will be available in OpenSSL 3.0 when it gets released.

Matt



> 
> On Thu, Jan 10, 2019 at 10:11 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 10/01/2019 09:39, Ananthu Unnikrishnan wrote:
>     > Hi all,
>     >
>     > ? ? ? ? We are not able to access the waitctx?address from the job address
>     using
>     > ASYNC_get_wait_ctx(job) from a thread which starts in the bind section of the
>     > dynamic engine. The job address is the same as that we got
>     > using?ASYNC_get_current_job.? Can anyone help on this?
> 
>     It's very unclear from the your various emails what you are trying to achieve
>     and the problem that you are experiencing.
> 
>     From the above it sounds like you are starting threads from inside your dynamic
>     engine? ASYNC_JOBs are always local to a thread. When a job is started it is
>     associated with the current thread. So ASYNC_get_current_job() returns the job
>     associated with the current thread. Similarly if you pause a job,
>     ASYNC_pause_job() must be called from that same thread. Finally if you restart a
>     paused job it must also be restarted on the same thread.
> 
>     If you are starting new threads from within your engine then extreme care must
>     be taken to obey the above rules - otherwise you are likely to get strange
>     results.
> 
>     Matt
> 
> 
>     >
>     > ? ? ? ? ?
>     >
>     > On Tue, Jan 8, 2019 at 11:26 AM Ananthu Unnikrishnan
>     <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     > <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>> wrote:
>     >
>     >? ? ?Can anyone please help on this? If u need any additional information
>     please
>     >? ? ?let me know.
>     >
>     >? ? ?On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan
>     <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     >? ? ?<mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>> wrote:
>     >
>     >? ? ? ? ?Hi all,
>     >
>     >? ? ? ? ?Adding more details to the previous mail. We have edited the OpenSSL
>     >? ? ? ? ?code for implementing the polling for changed fd's?as in OpenSSL speed
>     >? ? ? ? ?command. Attached the code snippet of the same along with this mail.
>     >? ? ? ? ?Mentioned below some observations which found doubtful:
>     >
>     >? ? ? ? ?1) We have got prints in ASYNC_FINISH case, before getting print in
>     >? ? ? ? ?ASYNC_PAUSE case. Attaching the log also, so you can understand
>     easily.?
>     >? ? ? ? ?2) Shown below the code snippet which we have written to provide a
>     write
>     >? ? ? ? ?on fd.
>     >
>     >? ? ? ? ?if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
>     >? ? ? ? ?? ? ? ? printf("In dynamic engine | waitctx == NULL : %d\n",
>     __LINE__);
>     >? ? ? ? ?? ? ? ? return ret;
>     >? ? ? ? ?? ? }
>     >
>     >? ? ? ? ?? ? printf("\n----- In dynamic engine | After pausing | job is %lx |?
>     >? ? ? ? ?waitctx in resume job %lx |-----\n", job, waitctx);
>     >
>     >? ? ? ? ?? ? ? ? if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id, &efd,
>     >? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &custom)) > 0) {
>     >? ? ? ? ?? ? ? ? if (write(efd, &buf, sizeof(uint64_t)) == -1) {
>     >? ? ? ? ?? ? ? ? ? ? printf("\nFailed to write\n");
>     >? ? ? ? ?? ? ? ? }
>     >? ? ? ? ?? ? }
>     >
>     >? ? ? ? ?Here waitctx is getting NULL when we tried to fetch waitctx using
>     >? ? ? ? ?ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB)
>     ie.1176
>     >? ? ? ? ?bytes contained in the job address from the engine,? we got
>     correct data
>     >? ? ? ? ?before calling ASYNC_pause() and but got half data zero data when we
>     >? ? ? ? ?tried to access the same address after ASYNC_pause().?
>     >
>     >? ? ? ? ?Attaching both job structure contents before and after calling
>     >? ? ? ? ?ASYNC_pause(). Also, we got the correct data in the same address
>     when we
>     >? ? ? ? ?have printed from ssl_start_async_job() before polling starts,
>     where we
>     >? ? ? ? ?have started the async_job
>     >? ? ? ? ?.?
>     >? ? ? ? ?The prints starting with "In dynamic engine" are prints inside the
>     >? ? ? ? ?engine, rest prints are from ss/ssl_lib.c. Kindly check this and
>     please
>     >? ? ? ? ?point out if anything is wrong somewhere. Thanks in advance.
>     >
>     >
>     >? ? ? ? ?On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan
>     >? ? ? ? ?<ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>> wrote:
>     >
>     >? ? ? ? ? ? ?Hi all,
>     >
>     >? ? ? ? ? ? ??????? We have implemented a dynamic engine and tested in the
>     async
>     >? ? ? ? ? ? ?mode using OpenSSL speed command. But in a real network
>     scenario, we
>     >? ? ? ? ? ? ?have seen only starting the async_job(in file ssl/ssl_lib.c,
>     >? ? ? ? ? ? ?function: ssl_start_async_job) in the OpenSSL. We haven't seen
>     >? ? ? ? ? ? ?polling async_fd's for resuming the job as in apps/speed.c(in
>     speed
>     >? ? ? ? ? ? ?command case).
>     >? ? ? ? ? ? ???????? So can anyone please suggest any solution for resuming the
>     >? ? ? ? ? ? ?async_jobs in real network scenario? Thanks in advance.
>     >
>     >
>     >
>     >
>     >
>     >? ? ? ? ?--
>     >? ? ? ? ?With best Regards,?
>     >
>     >? ? ? ? ????????? Ananthu
>     >
>     >
>     >
>     >
>     >? ? ?--
>     >? ? ?With best Regards,?
>     >
>     >? ? ????????? Ananthu
>     >
>     >
>     >
>     >
>     > --
>     > With best Regards,?
>     >
>     > ???????? Ananthu
>     >
>     >
>     >
>     -- 
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 
> -- 
> With best Regards,?
> 
> ???????? Ananthu
> 
> 
> 

From karl at denninger.net  Fri Jan 11 18:04:15 2019
From: karl at denninger.net (Karl Denninger)
Date: Fri, 11 Jan 2019 12:04:15 -0600
Subject: [openssl-users] Close TCP socket after SSL_clear()?
In-Reply-To: <01ae01d4a939$466214d0$d3263e70$@mcn.org>
References: <01ae01d4a939$466214d0$d3263e70$@mcn.org>
Message-ID: <78e3038e-6eec-89a5-75d1-c4be9ebffe29@denninger.net>


On 1/10/2019 17:07, Charles Mills wrote:
>
> On Windows, for a new session, I am issuing a Windows accept()
> followed by SSL_new(), SSL_set_fd() and so forth.
>
> ?
>
> When the session sees some sort of an abnormal receive condition, I am
> doing
>
> ?
>
> ?????? int *retCode* = SSL_get_shutdown(sessionSSL);
>
> ?????? if ( *retCode* & SSL_RECEIVED_SHUTDOWN )
>
> ?????? {
>
> ????????????? SSL_shutdown(sessionSSL);
>
> ?????? }
>
> ?????? else
>
> ?????? {
>
> ????????????? SSL_clear(sessionSSL);
>
> ?????? }
>
> ?
>
> Questions:
>
> ?
>
> 1.?????? Do I also need to do a closesocket() (equivalent to UNIX
> close()) on the Windows socket?
>
> 2.?????? Does anyone want to critique the above logic in any other way?
>
> ?
>
> The code basically ?works? but I see evidence that a Windows TCP
> session is still open following an SSL error.
>
> ?
>
> Thanks,
>
> ?
>
> /Charles Mills/
>
>
Are you sure you want to use SSL_clear() in the first place?? It retains
the session's settings which is only useful if the *exact* same peer is
going to reconnect on the same SSL object.? If a *different* peer
connects there's a decent shot that the connection will fail.

You also likely want to call SSL_shutdown(connection) again IF the first
call returns zero; the first one sends a notification and if the other
end hasn't closed yet returns zero.? The second waits for a termination,
either normal notification or abnormal, from the other end.

??? if (!SSL_shutdown(connection)) {
??????? SSL_shutdown(connection)
??? }

The underlying handle is still open at the OS level after this, so on
Unix anyway you want to notify the OS that the socket is invalid for
further I/O and then close it.

Code snippet (took_error is a flag that says "this connection is no
longer needed", it's could be either an error in the higher level code
or a "we're all done, let this connection go" indication):

??????????????? if (slave_socket[x].took_error) {
??????????????????? slave_socket[x].connected = 0;? /* Connection is void */
??????????????????? if (slave_socket[x].ssl_fd != NULL) { /* If there's
a valid SSL connection */
??????????????????????? if (!SSL_shutdown(slave_socket[x].ssl_fd)) {
??????????????????????????? SSL_shutdown(slave_socket[x].ssl_fd);
??????????????????????? }
??????????????????????? SSL_free(slave_socket[x].ssl_fd);
??????????????????????? slave_socket[x].ssl = 0; /* We are not in SSL
mode */
??????????????????? }
??????????????????? shutdown(slave_socket[x].fd, SHUT_RDWR);
??????????????????? close(slave_socket[x].fd);

??????????????????? ..... Clean up the rest of the things you need to do
when the connection ends

Since the next connection may come from a different peer I do not use
SSL_clear but rather SSL_free.

The call to shutdown() tells the OS to send any data queued on the
socket, wait for an ACK and then send FIN.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190111/b55a7285/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4897 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190111/b55a7285/attachment-0001.bin>

From openssl at jordan.maileater.net  Fri Jan 11 18:14:28 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Fri, 11 Jan 2019 18:14:28 +0000
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <866074a5-055f-a97c-f233-2c7dae338338@acm.org>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>
 <866074a5-055f-a97c-f233-2c7dae338338@acm.org>
Message-ID: <010101683e1f5b1c-490bd19c-5224-4627-a980-8a9c23e208d7-000000@us-west-2.amazonses.com>

On 1/10/2019 10:55 AM, Corey Minyard wrote:
> It is unusual, perhaps, but I'm trying to implement something like ssh
> does.? I can't expect users of ser2net to obtain certificates from a
> real certificate authority, that's too high a barrier for entry.? I
> want them to be able to generate a key pair, put the public key on the
> server in their account, and authenticate against that. 


Nobody said you needed a real certificate authority.? You need a
*trusted* certificate authority.

You could put the user's self-signed certificate into their account as a
trusted CA.

However... it seems like you're reinventing ssh.? Your replacement for
ssh will likely require a custom client, which will be a pain in the
neck for your users.? Maybe you should start with an existing ssh
library and hack it until it behaves the way you need.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

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

From vieuxtech at gmail.com  Fri Jan 11 18:42:53 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Fri, 11 Jan 2019 10:42:53 -0800
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
	certificate access
In-Reply-To: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
Message-ID: <CA+Sj9TkAx-T+Bi6xTJ8tzcMqZTLrgRh2nzzGMQ2cPhKS7_F-Jg@mail.gmail.com>

On Wed, Jan 9, 2019 at 6:54 PM Corey Minyard <minyard at acm.org> wrote:
> My first inclination for a secure connection was to use ssh. However,
> ssh is not as well suited for this as I would have liked, and all the
> ssh libraries are tied to a file descriptor in ways that are not easily
> fixable, and thus can't be used on top of an abstract connection, which
> is what I need.  That was rather disappointing, as it would have been
> really nice to for users to just be able to ssh to ser2net.

Not to second guess your finding that ssh isn't working well for you,
you know your own code best, but for my own interest, I'm curious what
about the fd is a problem? Perhaps the mismatch between X.509+TLS and
the auth model you want are enough to reconsider your abstractions?
Generating certs is pretty annoying and fragile, and using ssh clients
is pretty easy!

It sounds like your are building the abstractions (in C?) inside the
sernet process, but maybe your abstraction can be an fd, and the
"layers" can be child processes that connect fd-to-fd, sortof
qmail-like? Or, ssh should be able to execute an arbitrary command on
the server, and that command should be able to do anything it wants
with the ssh-facing socket descriptors, perhaps sending data to/from
your server which can then move the data through the in-process
abstractions?

Cheers,
Sam

From charlesm at mcn.org  Fri Jan 11 20:27:24 2019
From: charlesm at mcn.org (Charles Mills)
Date: Fri, 11 Jan 2019 12:27:24 -0800
Subject: [openssl-users] Close TCP socket after SSL_clear()?
In-Reply-To: <78e3038e-6eec-89a5-75d1-c4be9ebffe29@denninger.net>
References: <01ae01d4a939$466214d0$d3263e70$@mcn.org>
 <78e3038e-6eec-89a5-75d1-c4be9ebffe29@denninger.net>
Message-ID: <00ab01d4a9ec$10187000$30495000$@mcn.org>

@Karl, thanks, I'm not sure of anything. This was my first OpenSSL project
and I just hacked on it until it "worked." It's been working for years but
now we are seeing a re-connection error.

 

So, it sounds like

 

.         Do the SSL_shutdown() a second time if it returns 0.

.         Lose the SSL_clear()

.         There is an SSL_free() in there following the snippet I pasted -
leave it in there

.         Clean up the underlying socket appropriately. Looks like perhaps
shutdown(socket, SD_BOTH) is the Windows equivalent of SHUT_RDWR - followed
by closesocket()

 

Thanks again!

 

Charles

 

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Karl Denninger
Sent: Friday, January 11, 2019 10:04 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Close TCP socket after SSL_clear()?

 

 

On 1/10/2019 17:07, Charles Mills wrote:

On Windows, for a new session, I am issuing a Windows accept() followed by
SSL_new(), SSL_set_fd() and so forth.

 

When the session sees some sort of an abnormal receive condition, I am doing

 

       int retCode = SSL_get_shutdown(sessionSSL);

       if ( retCode & SSL_RECEIVED_SHUTDOWN )

       {

              SSL_shutdown(sessionSSL);

       }

       else

       {

              SSL_clear(sessionSSL);

       }

 

Questions:

 

1.       Do I also need to do a closesocket() (equivalent to UNIX close())
on the Windows socket?

2.       Does anyone want to critique the above logic in any other way?

 

The code basically "works" but I see evidence that a Windows TCP session is
still open following an SSL error.

 

Thanks,

 

Charles Mills




 

Are you sure you want to use SSL_clear() in the first place?  It retains the
session's settings which is only useful if the *exact* same peer is going to
reconnect on the same SSL object.  If a *different* peer connects there's a
decent shot that the connection will fail.

You also likely want to call SSL_shutdown(connection) again IF the first
call returns zero; the first one sends a notification and if the other end
hasn't closed yet returns zero.  The second waits for a termination, either
normal notification or abnormal, from the other end.

    if (!SSL_shutdown(connection)) {
        SSL_shutdown(connection)
    }

The underlying handle is still open at the OS level after this, so on Unix
anyway you want to notify the OS that the socket is invalid for further I/O
and then close it.

Code snippet (took_error is a flag that says "this connection is no longer
needed", it's could be either an error in the higher level code or a "we're
all done, let this connection go" indication):

                if (slave_socket[x].took_error) {
                    slave_socket[x].connected = 0;  /* Connection is void */
                    if (slave_socket[x].ssl_fd != NULL) { /* If there's a
valid SSL connection */
                        if (!SSL_shutdown(slave_socket[x].ssl_fd)) {
                            SSL_shutdown(slave_socket[x].ssl_fd);
                        }
                        SSL_free(slave_socket[x].ssl_fd);
                        slave_socket[x].ssl = 0; /* We are not in SSL mode
*/
                    }
                    shutdown(slave_socket[x].fd, SHUT_RDWR);
                    close(slave_socket[x].fd);

                    ..... Clean up the rest of the things you need to do
when the connection ends

Since the next connection may come from a different peer I do not use
SSL_clear but rather SSL_free.

The call to shutdown() tells the OS to send any data queued on the socket,
wait for an ACK and then send FIN.

-- 
Karl Denninger
karl at denninger.net
The Market Ticker
[S/MIME encrypted email preferred] 

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

From Michael.Wojcik at microfocus.com  Fri Jan 11 20:48:01 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 11 Jan 2019 20:48:01 +0000
Subject: [openssl-users] Close TCP socket after SSL_clear()?
In-Reply-To: <78e3038e-6eec-89a5-75d1-c4be9ebffe29@denninger.net>
References: <01ae01d4a939$466214d0$d3263e70$@mcn.org>
 <78e3038e-6eec-89a5-75d1-c4be9ebffe29@denninger.net>
Message-ID: <SN1PR18MB20953254EF5529CC24BEB4B0F9850@SN1PR18MB2095.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Karl Denninger
> Sent: Friday, January 11, 2019 13:04

>    if (!SSL_shutdown(connection)) {
>        SSL_shutdown(connection)
>    }

Or if you really want to baffle future maintainers:

        SSL_shutdown(connection) || SSL_shutdown(connection);

> The underlying handle is still open at the OS level after this, so on Unix anyway you want
> to notify the OS that the socket is invalid for further I/O and then close it.
> ...
>                    shutdown(slave_socket[x].fd, SHUT_RDWR);
>                    close(slave_socket[x].fd);

Maybe I'm missing something, but I don't see much advantage to calling shutdown(SHUT_RDRW) and then immediately calling close(). close will implicitly do what shutdown does, in the normal case, including trying to send unsent data and waiting (for a while) for any remaining ACKs.

If there's unsent or un-ACK'd data, shutdown will attempt to send it until the TCP retransmit limit is reached; that's normally longer than the linger time for the socket, so shutdown could try harder, and by the same token block longer, than close. But the same effect can be achieved by setting a longer linger time for the socket and just calling close.

Similarly, if linger has been disabled (by setting the SO_LINGER option appropriately), then close will just abort the connection (i.e. send an RST, rather than a FIN, and not wait for the corresponding FIN-ACK; or if the peer sent the FIN, send an RST rather than a FIN-ACK and not wait for the last ACK). But anyone who disables linger on a TLS connection gets what they deserve.

shutdown is generally useful if:

- You only want a half-close (which is rarely used, even when it would be useful, and isn't generally appropriate for a TLS connection).

- You want a full close, but you want to be able to retrieve the error information from the socket if the close fails. In that case, use shutdown, followed by getsockopt(SO_ERROR) if shutdown returns an error, followed by close. But your code is ignoring the return value from shutdown and not using getsockopt(SO_ERROR).

The real question is: will the application do anything differently if any remaining outbound data - which there shouldn't be because at this point we've tried to do a blocking SSL_shutdown - can't be sent, and the closing FIN / FIN-ACK / ACK handshake completed, within the default linger time? And if so, will the application do anything that can't be achieved by just increasing the linger time?

I think it'd be nice if more non-trivial applications used shutdown(SHUT_RDWR) + getsockopt(SO_ERROR) + close, and reported the error (if there is one) for diagnostic purposes. But beyond that there isn't a lot most applications can do, and for most a simple close is probably going to be fine.

But as I said I may have overlooked some good reason for this particular code pattern.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From charlesm at mcn.org  Fri Jan 11 22:06:17 2019
From: charlesm at mcn.org (Charles Mills)
Date: Fri, 11 Jan 2019 14:06:17 -0800
Subject: [openssl-users] Close TCP socket after SSL_clear()?
In-Reply-To: <SN1PR18MB20953254EF5529CC24BEB4B0F9850@SN1PR18MB2095.namprd18.prod.outlook.com>
References: <01ae01d4a939$466214d0$d3263e70$@mcn.org>
 <78e3038e-6eec-89a5-75d1-c4be9ebffe29@denninger.net>
 <SN1PR18MB20953254EF5529CC24BEB4B0F9850@SN1PR18MB2095.namprd18.prod.outlook.com>
Message-ID: <010801d4a9f9$e066c790$a13456b0$@mcn.org>

>        SSL_shutdown(connection) || SSL_shutdown(connection);

I like it! (Not!)

I don't pretend to be a bits and bytes expert on TCP protocol. You can't be
an expert on everything.

So I will listen to expert advice. I know 99% of you all are 'nix guys and
this is a Windows problem. I am seeing OTOH where my Windows doc says
closesocket() does an abortive termination, and OTOH a discussion of a
graceful closesocket() with SO_LINGER/SO_DONTLINGER.

(1) This code is (at the application level) purely a receiver of data and
(2) without the TLS layer in place it is hard to picture any meaningful data
transfer and (3) we are in a session cleanup situation anyway -- so it seems
to me that an abortive disconnect is perfectly fine. Am I wrong?

Thanks for all of your help.

Charles


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Michael Wojcik
Sent: Friday, January 11, 2019 12:48 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Close TCP socket after SSL_clear()?

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
Of Karl Denninger
> Sent: Friday, January 11, 2019 13:04

>    if (!SSL_shutdown(connection)) {
>        SSL_shutdown(connection)
>    }

Or if you really want to baffle future maintainers:

        SSL_shutdown(connection) || SSL_shutdown(connection);

> The underlying handle is still open at the OS level after this, so on Unix
anyway you want
> to notify the OS that the socket is invalid for further I/O and then close
it.
> ...
>                    shutdown(slave_socket[x].fd, SHUT_RDWR);
>                    close(slave_socket[x].fd);

Maybe I'm missing something, but I don't see much advantage to calling
shutdown(SHUT_RDRW) and then immediately calling close(). close will
implicitly do what shutdown does, in the normal case, including trying to
send unsent data and waiting (for a while) for any remaining ACKs.

If there's unsent or un-ACK'd data, shutdown will attempt to send it until
the TCP retransmit limit is reached; that's normally longer than the linger
time for the socket, so shutdown could try harder, and by the same token
block longer, than close. But the same effect can be achieved by setting a
longer linger time for the socket and just calling close.

Similarly, if linger has been disabled (by setting the SO_LINGER option
appropriately), then close will just abort the connection (i.e. send an RST,
rather than a FIN, and not wait for the corresponding FIN-ACK; or if the
peer sent the FIN, send an RST rather than a FIN-ACK and not wait for the
last ACK). But anyone who disables linger on a TLS connection gets what they
deserve.

shutdown is generally useful if:

- You only want a half-close (which is rarely used, even when it would be
useful, and isn't generally appropriate for a TLS connection).

- You want a full close, but you want to be able to retrieve the error
information from the socket if the close fails. In that case, use shutdown,
followed by getsockopt(SO_ERROR) if shutdown returns an error, followed by
close. But your code is ignoring the return value from shutdown and not
using getsockopt(SO_ERROR).

The real question is: will the application do anything differently if any
remaining outbound data - which there shouldn't be because at this point
we've tried to do a blocking SSL_shutdown - can't be sent, and the closing
FIN / FIN-ACK / ACK handshake completed, within the default linger time? And
if so, will the application do anything that can't be achieved by just
increasing the linger time?

I think it'd be nice if more non-trivial applications used
shutdown(SHUT_RDWR) + getsockopt(SO_ERROR) + close, and reported the error
(if there is one) for diagnostic purposes. But beyond that there isn't a lot
most applications can do, and for most a simple close is probably going to
be fine.

But as I said I may have overlooked some good reason for this particular
code pattern.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



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


From minyard at acm.org  Fri Jan 11 22:08:32 2019
From: minyard at acm.org (Corey Minyard)
Date: Fri, 11 Jan 2019 16:08:32 -0600
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <010101683e1f5b1c-490bd19c-5224-4627-a980-8a9c23e208d7-000000@us-west-2.amazonses.com>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>
 <866074a5-055f-a97c-f233-2c7dae338338@acm.org>
 <010101683e1f5b1c-490bd19c-5224-4627-a980-8a9c23e208d7-000000@us-west-2.amazonses.com>
Message-ID: <9c581872-6c9b-e288-b965-58ae152c77ce@acm.org>

On 1/11/19 12:14 PM, Jordan Brown wrote:
> On 1/10/2019 10:55 AM, Corey Minyard wrote:
>> It is unusual, perhaps, but I'm trying to implement something like 
>> ssh does.? I can't expect users of ser2net to obtain certificates 
>> from a real certificate authority, that's too high a barrier for 
>> entry.? I want them to be able to generate a key pair, put the public 
>> key on the server in their account, and authenticate against that. 
>
>
> Nobody said you needed a real certificate authority.? You need a 
> *trusted* certificate authority.
>
> You could put the user's self-signed certificate into their account as 
> a trusted CA.
>
Well, that's what I meant :)? And the self-signed certificates is what 
I've planned.? If I used the default CA, then the user would have to get 
a certificate from someplace else, they couldn't generate it themselves.


> However... it seems like you're reinventing ssh.? Your replacement for 
> ssh will likely require a custom client, which will be a pain in the 
> neck for your users.? Maybe you should start with an existing ssh 
> library and hack it until it behaves the way you need.
>
Indeed, ssh is where I started, and I would love to use it.? A custom 
client will be a pain, for sure, and I'd like to avoid it if possible.

But openssh only allows one connection per process, which is definitely 
not going to work with what I need.

libssh should be able to support multiple connections per process, but I 
spent about a week hacking on it, and the code is all wrapped around 
itself, not layered, and the changes to fix it would be huge.? And I'm 
not going to support a fork of something that complex, and the 
maintainer didn't seem too keen on those types of changes.

I didn't find any other server libraries that were suitable.? I'm not 
going to write my own ssh library.

Plus no ssh client will do serial port control over the network 
connection (like RFC2217), and many ser2net users use that.? So I might 
have been stuck with a custom client, anyway.

I don't really like my options, but I'm kind of boxed in.? I'm not sure 
why ssh doesn't run on top of ssl; that seems so sensible.? I assume 
that's for historical reasons.

Thanks,

-corey


From minyard at acm.org  Fri Jan 11 22:22:15 2019
From: minyard at acm.org (Corey Minyard)
Date: Fri, 11 Jan 2019 16:22:15 -0600
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <CA+Sj9TkAx-T+Bi6xTJ8tzcMqZTLrgRh2nzzGMQ2cPhKS7_F-Jg@mail.gmail.com>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <CA+Sj9TkAx-T+Bi6xTJ8tzcMqZTLrgRh2nzzGMQ2cPhKS7_F-Jg@mail.gmail.com>
Message-ID: <cbca46a1-bd0b-22b5-65b2-21e992ac2dd6@acm.org>

On 1/11/19 12:42 PM, Sam Roberts wrote:
> On Wed, Jan 9, 2019 at 6:54 PM Corey Minyard <minyard at acm.org> wrote:
>> My first inclination for a secure connection was to use ssh. However,
>> ssh is not as well suited for this as I would have liked, and all the
>> ssh libraries are tied to a file descriptor in ways that are not easily
>> fixable, and thus can't be used on top of an abstract connection, which
>> is what I need.  That was rather disappointing, as it would have been
>> really nice to for users to just be able to ssh to ser2net.
> Not to second guess your finding that ssh isn't working well for you,
> you know your own code best, but for my own interest, I'm curious what
> about the fd is a problem? Perhaps the mismatch between X.509+TLS and
> the auth model you want are enough to reconsider your abstractions?
> Generating certs is pretty annoying and fragile, and using ssh clients
> is pretty easy!

Generating certs is easy if you do it like ssh does, and openssl is 
quite capable of that.

The auth model is not the issue, though.? The problems I'm having are 
plugging
in to openssl in the right places to do what I want.? But the help I've 
received
here has got me through that, I think.


>
> It sounds like your are building the abstractions (in C?) inside the
> sernet process, but maybe your abstraction can be an fd, and the
> "layers" can be child processes that connect fd-to-fd, sortof
> qmail-like? Or, ssh should be able to execute an arbitrary command on
> the server, and that command should be able to do anything it wants
> with the ssh-facing socket descriptors, perhaps sending data to/from
> your server which can then move the data through the in-process
> abstractions?

The model I have is something like openssl and the BIOs.? You can plug 
different
things together in openssl any way you like.? In each piece, you shove 
data in
one side and data comes out the other.? You have BIOs at the end for dealing
with sockets or whatnot.? So getting openssl running inside my framework
was quite easy.

Both openssh and libssh are not designed that way.? There is no clean 
separation
between dealing with file descriptors (that's what I meant by fd) and 
the rest
of the library.? And there were a number of other issues, too.

Thanks,

-corey


From Michael.Wojcik at microfocus.com  Sat Jan 12 14:20:21 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sat, 12 Jan 2019 14:20:21 +0000
Subject: [openssl-users] Close TCP socket after SSL_clear()?
In-Reply-To: <010801d4a9f9$e066c790$a13456b0$@mcn.org>
References: <01ae01d4a939$466214d0$d3263e70$@mcn.org>
 <78e3038e-6eec-89a5-75d1-c4be9ebffe29@denninger.net>
 <SN1PR18MB20953254EF5529CC24BEB4B0F9850@SN1PR18MB2095.namprd18.prod.outlook.com>
 <010801d4a9f9$e066c790$a13456b0$@mcn.org>
Message-ID: <MW2PR18MB20902F13E30549AD2C99C81DF9860@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Charles Mills
> Sent: Friday, January 11, 2019 17:06
>
> >        SSL_shutdown(connection) || SSL_shutdown(connection);
>
> I like it! (Not!)
>
> I don't pretend to be a bits and bytes expert on TCP protocol. You can't be
> an expert on everything.
>
> So I will listen to expert advice. I know 99% of you all are 'nix guys and
> this is a Windows problem. I am seeing OTOH where my Windows doc says
> closesocket() does an abortive termination, and OTOH a discussion of a
> graceful closesocket() with SO_LINGER/SO_DONTLINGER.
>
> (1) This code is (at the application level) purely a receiver of data and
> (2) without the TLS layer in place it is hard to picture any meaningful data
> transfer and (3) we are in a session cleanup situation anyway -- so it seems
> to me that an abortive disconnect is perfectly fine. Am I wrong?

Yes, you're wrong. You don't want an abortive disconnect.

A TCP connection can be closed in four (or five) ways:

1. Normal close, which involves the FIN / FIN-ACK / ACK sequence. When the last ACK is received, both sides know that all data has been received by the peer stack, and at the point when the corresponding ACK was generated, the peer "believed" it would be able to deliver the data to the application eventually. (That is, the stack hadn't been informed that the application's identifier for the connection - the socket - had been closed.)

2. Abortive close, which involves a RST from one side to the peer, and that's it. RST is a one-way, unacknowledged flow. There are a number of reasons why it's undesirable, some of which I'll go into below.

3. Abortive close due to network management message: the stack receives an ICMP message indicating a packet could not be delivered, such as HOST_UNREACH. From the application's point of view, the result is similar to #2, except for the particular error code it sees.

4. Timeout from TCP retransmit, either for an application send or, if it's enabled, TCP keepalive.

5. Arguably a separate case: 1-3 but generated by a middlebox, such as as a router, or an application firewall. In other words, the connection is forced closed by someone spoofing the peer. From the application's point of view, that makes no difference.

Applications should almost never use an abortive close. TCP is intended to be a reliable (best-effort) stream transport, and it can only meet its (already weak) service guarantees if you let it acknowledge all application data and close the conversation cleanly.

Now, when you have a higher-level conversation protocol such as TLS, and the higher-level protocol has already negotiated end-of-conversation, that may not seem important; the peers have agreed that they're not going to send anything more. That assumes, however, that the peers are well-behaved. And it is at the very least notionally cleaner to let the conversation close normally.

Beyond that, an abortive close can cause TIME_WAIT Assassination, which is a Bad Thing. If you don't know what TIME_WAIT Assassination is, that's a sign you shouldn't be doing abortive closes. Don't invoke extraordinary behavior you don't understand.

Now, all that said: Winsock closesocket will NOT do an abortive disconnect if you have not mucked with the SO_LINGER socket option (which you should not do unless you understand TCP). I don't know what documentation you saw that claims otherwise, but it's wrong.

Calling shutdown before closesocket won't hurt anything, but (if you use the pattern that we've discussed in this thread) won't do anything useful either, in most cases.

One case I forgot in my previous discussion: It's worth remembering that close/closesocket operates on a single reference to the connection, while shutdown operates on the connection itself. That is, the logic for close/closesocket is notionally something like this:

   close the descriptor/handle
   decrement the conversation's reference count
   if the reference count is 0
      if connection is still open for sending
         shutdown(SHUT_WR)
      if connection is still open for receiving
         shutdown(SHUT_RD)

In the case where you have multiple descriptors or handles for a conversation - for example due to dup'ing a socket or forking on UNIX, or duplicating a handle (possibly into a different process) on Windows - then close/closesocket won't do the shutdown-equivalent until they have *all* been closed. An explicit shutdown, on the other hand, doesn't close any of the descriptors/handles, but it does send a FIN (for SHUT_WR) or flush inbound data and refuse to receive any more (for SHUT_RD) on the conversation, which of course affects all descriptors/handles.

So if your application creates multiple references to the conversation, then depending on your design, you might want the shutdown. Or you might not, if you want the shutdown-on-last-close semantics. Neither option is correct for all applications.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From Michael.Wojcik at microfocus.com  Sat Jan 12 14:20:22 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sat, 12 Jan 2019 14:20:22 +0000
Subject: [openssl-users] SSL_CTX_set_cert_verify_callback and
 certificate access
In-Reply-To: <9c581872-6c9b-e288-b965-58ae152c77ce@acm.org>
References: <b41f31a9-3a24-4a18-3b2c-a2a708eb4086@acm.org>
 <01010168388bad87-3eafc8ba-4928-4953-9f55-742ba5d6ef23-000000@us-west-2.amazonses.com>
 <MW2PR18MB2090E661DD1FA38FF053FDBBF9840@MW2PR18MB2090.namprd18.prod.outlook.com>
 <866074a5-055f-a97c-f233-2c7dae338338@acm.org>
 <010101683e1f5b1c-490bd19c-5224-4627-a980-8a9c23e208d7-000000@us-west-2.amazonses.com>
 <9c581872-6c9b-e288-b965-58ae152c77ce@acm.org>
Message-ID: <MW2PR18MB20909A382842C26CB3214D4FF9860@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Corey Minyard
> Sent: Friday, January 11, 2019 17:09
>
> I don't really like my options, but I'm kind of boxed in.  I'm not sure
> why ssh doesn't run on top of ssl; that seems so sensible.  I assume
> that's for historical reasons.

Since SSH and SSL were developed simultaneously (both first relased in 1995), neither could be based on the other.

More importantly, SSH and SSL are completely different protocols, initially designed for different use cases and as cryptographically-secured replacements for different existing mechanisms. In their early versions they had very different approaches to PKI, and as they're commonly used they still do.

There are remote-shell and file-transfer applications built on TLS (Telnet-over-TLS and Telnet-with-STARTTLS[1], and similarly for FTP[2]). There's no real advantage to changing SSH to use the same architecture. It would force users away from the SSH PKI, which is widely abused[3]; but the X.509 PKIX is such a mess that it's hard to claim it's all that much better.

Asking why SSH isn't built on SSL is a bit like asking why TCP/IP isn't based on X.25. Similarity of intent doesn't indicate similarity of fitness for a particular purpose.


[1] Though as always with opportunistic TLS, you want a client which will fail safe by aborting the connection, or at least make it *very* clear to the user, when a secure channel cannot be established.

[2] Sometimes referred to as "SFTP" or "FTPS", but the nomenclature is inconsistent; people also use those for SSH-based file transfer, among other things.

[3] Anecdotal evidence and some surveys suggest many, likely most, SSH users practice poor key hygiene, accepting public keys without checking their provenance.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From ananthuu741 at gmail.com  Sun Jan 13 04:36:29 2019
From: ananthuu741 at gmail.com (Ananthu Unnikrishnan)
Date: Sun, 13 Jan 2019 10:06:29 +0530
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <2c98a823-b680-9cdb-104d-6f66c4bba652@openssl.org>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
 <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
 <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>
 <CADqiADhOP27jU6nie1PpXAF_vTe-XXJXb3F8hb0-EELF+_fGDQ@mail.gmail.com>
 <f0cb28ac-c683-e430-33f1-f1dad945e868@openssl.org>
 <CADqiADhYtL8pyR87UZvMXOCf7VARbLmzKuJ7fz-sHD5=ad5seA@mail.gmail.com>
 <2c98a823-b680-9cdb-104d-6f66c4bba652@openssl.org>
Message-ID: <CADqiADhBHss=Hyu60cjX5bt0O86x3+wq+ftSZWuzGUnZbVZbfg@mail.gmail.com>

Hi Matt,

            Thanks a lot for the response. The alternative method to resume
job operation is a good one.

            I need some more clarifications regarding the async job
operation. Please help.
            In ssl/ss_lib.c, ssl_start_async_job() function found. In which
ASYNC_start_job function is calling but no mechanism found for polling the
fd's. Is it written elsewhere?.


On Fri, Jan 11, 2019 at 3:12 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 10/01/2019 18:09, Ananthu Unnikrishnan wrote:
> > Hi Matt,
> >
> >         Thanks a lot for the reply.
> >
> >        After calling ASYNC_pause_job() from the engine, control will
> transfer to
> > the place where we start the ASYNC_start_job right? So how can we write
> the code
> > to put a trigger on fd in the same thread?
>
> I'm not saying you can't use threads to do this - only that you need to be
> careful about using them and must obey the rules.
>
>
> > If I am wrong  please correct me.
> > Also if u can suggest where resume operation should be done, it would be
> helpful.
>
> Typically the calling application will wait on the fd (e.g. using "select"
> or
> similar) until it is readable. Once it sees the fd as readable then it
> calls
> ASYNC_start_job() again.
>
>
> As an aside you may also be interested in this PR that is currently being
> reviewed:
>
> https://github.com/openssl/openssl/pull/7573
>
> This adds an alternative mechanism for signalling other than using fds
> (i.e. to
> use a callback instead) and will be available in OpenSSL 3.0 when it gets
> released.
>
> Matt
>
>
>
> >
> > On Thu, Jan 10, 2019 at 10:11 PM Matt Caswell <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >
> >
> >     On 10/01/2019 09:39, Ananthu Unnikrishnan wrote:
> >     > Hi all,
> >     >
> >     >         We are not able to access the waitctx address from the job
> address
> >     using
> >     > ASYNC_get_wait_ctx(job) from a thread which starts in the bind
> section of the
> >     > dynamic engine. The job address is the same as that we got
> >     > using ASYNC_get_current_job.  Can anyone help on this?
> >
> >     It's very unclear from the your various emails what you are trying
> to achieve
> >     and the problem that you are experiencing.
> >
> >     From the above it sounds like you are starting threads from inside
> your dynamic
> >     engine? ASYNC_JOBs are always local to a thread. When a job is
> started it is
> >     associated with the current thread. So ASYNC_get_current_job()
> returns the job
> >     associated with the current thread. Similarly if you pause a job,
> >     ASYNC_pause_job() must be called from that same thread. Finally if
> you restart a
> >     paused job it must also be restarted on the same thread.
> >
> >     If you are starting new threads from within your engine then extreme
> care must
> >     be taken to obey the above rules - otherwise you are likely to get
> strange
> >     results.
> >
> >     Matt
> >
> >
> >     >
> >     >
> >     >
> >     > On Tue, Jan 8, 2019 at 11:26 AM Ananthu Unnikrishnan
> >     <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
> >     > <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>
> wrote:
> >     >
> >     >     Can anyone please help on this? If u need any additional
> information
> >     please
> >     >     let me know.
> >     >
> >     >     On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan
> >     <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
> >     >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>
> wrote:
> >     >
> >     >         Hi all,
> >     >
> >     >         Adding more details to the previous mail. We have edited
> the OpenSSL
> >     >         code for implementing the polling for changed fd's as in
> OpenSSL speed
> >     >         command. Attached the code snippet of the same along with
> this mail.
> >     >         Mentioned below some observations which found doubtful:
> >     >
> >     >         1) We have got prints in ASYNC_FINISH case, before getting
> print in
> >     >         ASYNC_PAUSE case. Attaching the log also, so you can
> understand
> >     easily.
> >     >         2) Shown below the code snippet which we have written to
> provide a
> >     write
> >     >         on fd.
> >     >
> >     >         if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) ==
> NULL) {
> >     >                 printf("In dynamic engine | waitctx == NULL :
> %d\n",
> >     __LINE__);
> >     >                 return ret;
> >     >             }
> >     >
> >     >             printf("\n----- In dynamic engine | After pausing |
> job is %lx |
> >     >         waitctx in resume job %lx |-----\n", job, waitctx);
> >     >
> >     >                 if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx,
> engine_id, &efd,
> >     >                                       &custom)) > 0) {
> >     >                 if (write(efd, &buf, sizeof(uint64_t)) == -1) {
> >     >                     printf("\nFailed to write\n");
> >     >                 }
> >     >             }
> >     >
> >     >         Here waitctx is getting NULL when we tried to fetch
> waitctx using
> >     >         ASYNC_get_wait_ctx(). We have printed data of
> sizeof(ASYNC_JOB)
> >     ie.1176
> >     >         bytes contained in the job address from the engine,  we got
> >     correct data
> >     >         before calling ASYNC_pause() and but got half data zero
> data when we
> >     >         tried to access the same address after ASYNC_pause().
> >     >
> >     >         Attaching both job structure contents before and after
> calling
> >     >         ASYNC_pause(). Also, we got the correct data in the same
> address
> >     when we
> >     >         have printed from ssl_start_async_job() before polling
> starts,
> >     where we
> >     >         have started the async_job
> >     >         .
> >     >         The prints starting with "In dynamic engine" are prints
> inside the
> >     >         engine, rest prints are from ss/ssl_lib.c. Kindly check
> this and
> >     please
> >     >         point out if anything is wrong somewhere. Thanks in
> advance.
> >     >
> >     >
> >     >         On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan
> >     >         <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
> >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>
> wrote:
> >     >
> >     >             Hi all,
> >     >
> >     >                    We have implemented a dynamic engine and tested
> in the
> >     async
> >     >             mode using OpenSSL speed command. But in a real network
> >     scenario, we
> >     >             have seen only starting the async_job(in file
> ssl/ssl_lib.c,
> >     >             function: ssl_start_async_job) in the OpenSSL. We
> haven't seen
> >     >             polling async_fd's for resuming the job as in
> apps/speed.c(in
> >     speed
> >     >             command case).
> >     >                     So can anyone please suggest any solution for
> resuming the
> >     >             async_jobs in real network scenario? Thanks in advance.
> >     >
> >     >
> >     >
> >     >
> >     >
> >     >         --
> >     >         With best Regards,
> >     >
> >     >                  Ananthu
> >     >
> >     >
> >     >
> >     >
> >     >     --
> >     >     With best Regards,
> >     >
> >     >              Ananthu
> >     >
> >     >
> >     >
> >     >
> >     > --
> >     > With best Regards,
> >     >
> >     >          Ananthu
> >     >
> >     >
> >     >
> >     --
> >     openssl-users mailing list
> >     To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> >
> > --
> > With best Regards,
> >
> >          Ananthu
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


-- 
With best Regards,

         Ananthu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190113/5561224a/attachment-0001.html>

From ylavic.dev at gmail.com  Sun Jan 13 21:11:11 2019
From: ylavic.dev at gmail.com (Yann Ylavic)
Date: Sun, 13 Jan 2019 22:11:11 +0100
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
Message-ID: <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>

On Tue, Jan 8, 2019 at 11:24 PM Sam Roberts <vieuxtech at gmail.com> wrote:
>
> node.js has an API that lists all the cipher suite names that can be
> validly passed to set_cipher_list(), but I don't see how to get them
> for TLS1.3 to list the valid inputs to set_cipher_suites().

FWIW, the below works for me:

$ openssl ciphers -v TLSv1.3
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any
Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD


Regards,
Yann.

From matt at openssl.org  Mon Jan 14 12:02:53 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 14 Jan 2019 12:02:53 +0000
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <CADqiADhBHss=Hyu60cjX5bt0O86x3+wq+ftSZWuzGUnZbVZbfg@mail.gmail.com>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
 <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
 <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>
 <CADqiADhOP27jU6nie1PpXAF_vTe-XXJXb3F8hb0-EELF+_fGDQ@mail.gmail.com>
 <f0cb28ac-c683-e430-33f1-f1dad945e868@openssl.org>
 <CADqiADhYtL8pyR87UZvMXOCf7VARbLmzKuJ7fz-sHD5=ad5seA@mail.gmail.com>
 <2c98a823-b680-9cdb-104d-6f66c4bba652@openssl.org>
 <CADqiADhBHss=Hyu60cjX5bt0O86x3+wq+ftSZWuzGUnZbVZbfg@mail.gmail.com>
Message-ID: <09eaae85-a81f-086a-5f58-0272dea73abf@openssl.org>



On 13/01/2019 04:36, Ananthu Unnikrishnan wrote:
> Hi Matt,
> 
> ? ? ? ? ? ? Thanks a lot for the response. The alternative method to resume job
> operation is a good one.?
> ? ? ? ? ? ? ?
> ? ? ? ? ? ? I need some more clarifications regarding the async job operation.
> Please help.
> ??????????? In ssl/ss_lib.c, ssl_start_async_job() function found. In which
> ASYNC_start_job function is calling but no mechanism found for polling the fd's.
> Is it written elsewhere?. 

You are supposed to write the fd polling code yourself, e.g. by using
SSL_get_all_async_fds() or SSL_get_changed_async_fds() to get hold of the fds,
and then followed by "select" or similar.

See:

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

mATT



> ???????????
> 
> On Fri, Jan 11, 2019 at 3:12 PM Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> wrote:
> 
> 
> 
>     On 10/01/2019 18:09, Ananthu Unnikrishnan wrote:
>     > Hi Matt,
>     >
>     > ??????? Thanks a lot for the reply.
>     >
>     > ?????? After calling ASYNC_pause_job() from the engine, control will
>     transfer to
>     > the place where we start the ASYNC_start_job right? So how can we write
>     the code
>     > to put a trigger on fd in the same thread?
> 
>     I'm not saying you can't use threads to do this - only that you need to be
>     careful about using them and must obey the rules.
> 
> 
>     > If I am wrong? please correct me.
>     > Also if u can suggest where resume operation should be done, it would be
>     helpful.
> 
>     Typically the calling application will wait on the fd (e.g. using "select" or
>     similar) until it is readable. Once it sees the fd as readable then it calls
>     ASYNC_start_job() again.
> 
> 
>     As an aside you may also be interested in this PR that is currently being
>     reviewed:
> 
>     https://github.com/openssl/openssl/pull/7573
> 
>     This adds an alternative mechanism for signalling other than using fds (i.e. to
>     use a callback instead) and will be available in OpenSSL 3.0 when it gets
>     released.
> 
>     Matt
> 
> 
> 
>     >
>     > On Thu, Jan 10, 2019 at 10:11 PM Matt Caswell <matt at openssl.org
>     <mailto:matt at openssl.org>
>     > <mailto:matt at openssl.org <mailto:matt at openssl.org>>> wrote:
>     >
>     >
>     >
>     >? ? ?On 10/01/2019 09:39, Ananthu Unnikrishnan wrote:
>     >? ? ?> Hi all,
>     >? ? ?>
>     >? ? ?> ? ? ? ? We are not able to access the waitctx?address from the job
>     address
>     >? ? ?using
>     >? ? ?> ASYNC_get_wait_ctx(job) from a thread which starts in the bind
>     section of the
>     >? ? ?> dynamic engine. The job address is the same as that we got
>     >? ? ?> using?ASYNC_get_current_job.? Can anyone help on this?
>     >
>     >? ? ?It's very unclear from the your various emails what you are trying to
>     achieve
>     >? ? ?and the problem that you are experiencing.
>     >
>     >? ? ?From the above it sounds like you are starting threads from inside
>     your dynamic
>     >? ? ?engine? ASYNC_JOBs are always local to a thread. When a job is started
>     it is
>     >? ? ?associated with the current thread. So ASYNC_get_current_job() returns
>     the job
>     >? ? ?associated with the current thread. Similarly if you pause a job,
>     >? ? ?ASYNC_pause_job() must be called from that same thread. Finally if you
>     restart a
>     >? ? ?paused job it must also be restarted on the same thread.
>     >
>     >? ? ?If you are starting new threads from within your engine then extreme
>     care must
>     >? ? ?be taken to obey the above rules - otherwise you are likely to get strange
>     >? ? ?results.
>     >
>     >? ? ?Matt
>     >
>     >
>     >? ? ?>
>     >? ? ?> ? ? ? ? ?
>     >? ? ?>
>     >? ? ?> On Tue, Jan 8, 2019 at 11:26 AM Ananthu Unnikrishnan
>     >? ? ?<ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>
>     >? ? ?> <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>> wrote:
>     >? ? ?>
>     >? ? ?>? ? ?Can anyone please help on this? If u need any additional information
>     >? ? ?please
>     >? ? ?>? ? ?let me know.
>     >? ? ?>
>     >? ? ?>? ? ?On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan
>     >? ? ?<ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>
>     >? ? ?>? ? ?<mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>> wrote:
>     >? ? ?>
>     >? ? ?>? ? ? ? ?Hi all,
>     >? ? ?>
>     >? ? ?>? ? ? ? ?Adding more details to the previous mail. We have edited the
>     OpenSSL
>     >? ? ?>? ? ? ? ?code for implementing the polling for changed fd's?as in
>     OpenSSL speed
>     >? ? ?>? ? ? ? ?command. Attached the code snippet of the same along with
>     this mail.
>     >? ? ?>? ? ? ? ?Mentioned below some observations which found doubtful:
>     >? ? ?>
>     >? ? ?>? ? ? ? ?1) We have got prints in ASYNC_FINISH case, before getting
>     print in
>     >? ? ?>? ? ? ? ?ASYNC_PAUSE case. Attaching the log also, so you can understand
>     >? ? ?easily.?
>     >? ? ?>? ? ? ? ?2) Shown below the code snippet which we have written to
>     provide a
>     >? ? ?write
>     >? ? ?>? ? ? ? ?on fd.
>     >? ? ?>
>     >? ? ?>? ? ? ? ?if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job)) == NULL) {
>     >? ? ?>? ? ? ? ?? ? ? ? printf("In dynamic engine | waitctx == NULL : %d\n",
>     >? ? ?__LINE__);
>     >? ? ?>? ? ? ? ?? ? ? ? return ret;
>     >? ? ?>? ? ? ? ?? ? }
>     >? ? ?>
>     >? ? ?>? ? ? ? ?? ? printf("\n----- In dynamic engine | After pausing | job
>     is %lx |?
>     >? ? ?>? ? ? ? ?waitctx in resume job %lx |-----\n", job, waitctx);
>     >? ? ?>
>     >? ? ?>? ? ? ? ?? ? ? ? if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx, engine_id,
>     &efd,
>     >? ? ?>? ? ? ? ?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? &custom)) > 0) {
>     >? ? ?>? ? ? ? ?? ? ? ? if (write(efd, &buf, sizeof(uint64_t)) == -1) {
>     >? ? ?>? ? ? ? ?? ? ? ? ? ? printf("\nFailed to write\n");
>     >? ? ?>? ? ? ? ?? ? ? ? }
>     >? ? ?>? ? ? ? ?? ? }
>     >? ? ?>
>     >? ? ?>? ? ? ? ?Here waitctx is getting NULL when we tried to fetch waitctx
>     using
>     >? ? ?>? ? ? ? ?ASYNC_get_wait_ctx(). We have printed data of sizeof(ASYNC_JOB)
>     >? ? ?ie.1176
>     >? ? ?>? ? ? ? ?bytes contained in the job address from the engine,? we got
>     >? ? ?correct data
>     >? ? ?>? ? ? ? ?before calling ASYNC_pause() and but got half data zero data
>     when we
>     >? ? ?>? ? ? ? ?tried to access the same address after ASYNC_pause().?
>     >? ? ?>
>     >? ? ?>? ? ? ? ?Attaching both job structure contents before and after calling
>     >? ? ?>? ? ? ? ?ASYNC_pause(). Also, we got the correct data in the same address
>     >? ? ?when we
>     >? ? ?>? ? ? ? ?have printed from ssl_start_async_job() before polling starts,
>     >? ? ?where we
>     >? ? ?>? ? ? ? ?have started the async_job
>     >? ? ?>? ? ? ? ?.?
>     >? ? ?>? ? ? ? ?The prints starting with "In dynamic engine" are prints
>     inside the
>     >? ? ?>? ? ? ? ?engine, rest prints are from ss/ssl_lib.c. Kindly check this and
>     >? ? ?please
>     >? ? ?>? ? ? ? ?point out if anything is wrong somewhere. Thanks in advance.
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ? ? ?On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan
>     >? ? ?>? ? ? ? ?<ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>
>     >? ? ?<mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
>     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>> wrote:
>     >? ? ?>
>     >? ? ?>? ? ? ? ? ? ?Hi all,
>     >? ? ?>
>     >? ? ?>? ? ? ? ? ? ??????? We have implemented a dynamic engine and tested
>     in the
>     >? ? ?async
>     >? ? ?>? ? ? ? ? ? ?mode using OpenSSL speed command. But in a real network
>     >? ? ?scenario, we
>     >? ? ?>? ? ? ? ? ? ?have seen only starting the async_job(in file ssl/ssl_lib.c,
>     >? ? ?>? ? ? ? ? ? ?function: ssl_start_async_job) in the OpenSSL. We
>     haven't seen
>     >? ? ?>? ? ? ? ? ? ?polling async_fd's for resuming the job as in
>     apps/speed.c(in
>     >? ? ?speed
>     >? ? ?>? ? ? ? ? ? ?command case).
>     >? ? ?>? ? ? ? ? ? ???????? So can anyone please suggest any solution for
>     resuming the
>     >? ? ?>? ? ? ? ? ? ?async_jobs in real network scenario? Thanks in advance.
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ? ? ?--
>     >? ? ?>? ? ? ? ?With best Regards,?
>     >? ? ?>
>     >? ? ?>? ? ? ? ????????? Ananthu
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>? ? ?--
>     >? ? ?>? ? ?With best Regards,?
>     >? ? ?>
>     >? ? ?>? ? ????????? Ananthu
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?> --
>     >? ? ?> With best Regards,?
>     >? ? ?>
>     >? ? ?> ???????? Ananthu
>     >? ? ?>
>     >? ? ?>
>     >? ? ?>
>     >? ? ?--
>     >? ? ?openssl-users mailing list
>     >? ? ?To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>     >
>     >
>     >
>     > --
>     > With best Regards,?
>     >
>     > ???????? Ananthu
>     >
>     >
>     >
>     -- 
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 
> -- 
> With best Regards,?
> 
> ???????? Ananthu
> 
> 
> 

From matt at openssl.org  Mon Jan 14 12:09:26 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 14 Jan 2019 12:09:26 +0000
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
Message-ID: <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>



On 13/01/2019 21:11, Yann Ylavic wrote:
> On Tue, Jan 8, 2019 at 11:24 PM Sam Roberts <vieuxtech at gmail.com> wrote:
>>
>> node.js has an API that lists all the cipher suite names that can be
>> validly passed to set_cipher_list(), but I don't see how to get them
>> for TLS1.3 to list the valid inputs to set_cipher_suites().
> 
> FWIW, the below works for me:
> 
> $ openssl ciphers -v TLSv1.3
> TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
> TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any
> Enc=CHACHA20/POLY1305(256) Mac=AEAD
> TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD

This works more "by accident". There is no ciphersuite alias called "TLSv1.3",
so using it as above results in no ciphersuites matched. Since the TLSv1.3
ciphersuites are on by default anyway that's all that you get back.

Matt


From grahame at healthintersections.com.au  Mon Jan 14 12:45:31 2019
From: grahame at healthintersections.com.au (Grahame Grieve)
Date: Mon, 14 Jan 2019 23:45:31 +1100
Subject: [openssl-users] Binary Distribution DLL Names
Message-ID: <CAG47hGYKMY1qQiwf0CFs9oHML0-2kf1AcEHu-GkY7W=rEgXqrw@mail.gmail.com>

Hi

I have a 64bit windows application that uses openSSL, and I am using the
indy distribution from https://indy.fulgan.com/SSL/. This makes the file
names of the openssl dlls libeay32.dll and ssleay32.dll (even though they
are 64bit).  Other distributions use other names (libcrypto-XX-x64.dll etc)

I believe that the filename variations are at the root of an issue I have
with openSSL. My symptoms are this: when I run my unit tests that do (among
other things) a bunch of tests of my SSL server, all is good. However,
anytime I load the mysql odbc driver into the memory space, I get an memory
corruption problem in libeay32.dll when shutting down. Google suggests that
this is due to a build mismatch between the two dlls... I'm guessing that
mysql is loading some other dll variant of openssl and some build mismatch
is arising ?

I'm clutching at straws here, but has this been an issue before? is there
any policy issue around distrubution filenames? Is there any other likely
cause why loading the mysql odbc driver causes memory corruptions in
openssl when shutting down?

thanks
Grahame
-- 
-----
http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190114/6be6d4f5/attachment.html>

From ylavic.dev at gmail.com  Mon Jan 14 13:18:18 2019
From: ylavic.dev at gmail.com (Yann Ylavic)
Date: Mon, 14 Jan 2019 14:18:18 +0100
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
Message-ID: <CAKQ1sVOAe2Ongj+CrVXAtF90fCX5OBU=v6QCY5piAnTWod5Mnw@mail.gmail.com>

On Mon, Jan 14, 2019 at 1:09 PM Matt Caswell <matt at openssl.org> wrote:
>
> This works more "by accident". There is no ciphersuite alias called "TLSv1.3",
> so using it as above results in no ciphersuites matched. Since the TLSv1.3
> ciphersuites are on by default anyway that's all that you get back.

OK, thanks for the explanation.

I suppose one can always, e.g.:

$ openssl ciphers -v |grep TLSv1.3 |awk '{print $1}' # or whatever filtering

to not depend on this "accident", right?

Regards,
Yann.

From vieuxtech at gmail.com  Mon Jan 14 19:03:55 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Mon, 14 Jan 2019 11:03:55 -0800
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <CAKQ1sVOAe2Ongj+CrVXAtF90fCX5OBU=v6QCY5piAnTWod5Mnw@mail.gmail.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
 <CAKQ1sVOAe2Ongj+CrVXAtF90fCX5OBU=v6QCY5piAnTWod5Mnw@mail.gmail.com>
Message-ID: <CA+Sj9T=nwO5gSmBCMDJXRY9a_Bk-cOBC3CMk_CE9eGTdto6Hyw@mail.gmail.com>

On Mon, Jan 14, 2019 at 5:18 AM Yann Ylavic <ylavic.dev at gmail.com> wrote:
> I suppose one can always, e.g.:
>
> $ openssl ciphers -v |grep TLSv1.3 |awk '{print $1}' # or whatever filtering
>
> to not depend on this "accident", right?

No, `ciphers` gives you the TLS cipher suites that are enabled, it
doesn't give all.

As you saw with both of your `ciphers` commands, they are printing the
3 TLS1.3 cipher suites that are enabled by default, but OpenSSL
supports 5 TLS1.3 cipher suites, two are missing from the output.

Cheers,
Sam

From charlesm at mcn.org  Mon Jan 14 19:08:32 2019
From: charlesm at mcn.org (Charles Mills)
Date: Mon, 14 Jan 2019 11:08:32 -0800
Subject: [openssl-users] Close TCP socket after SSL_clear()?
In-Reply-To: <MW2PR18MB20902F13E30549AD2C99C81DF9860@MW2PR18MB2090.namprd18.prod.outlook.com>
References: <01ae01d4a939$466214d0$d3263e70$@mcn.org>
 <78e3038e-6eec-89a5-75d1-c4be9ebffe29@denninger.net>
 <SN1PR18MB20953254EF5529CC24BEB4B0F9850@SN1PR18MB2095.namprd18.prod.outlook.com>
 <010801d4a9f9$e066c790$a13456b0$@mcn.org>
 <MW2PR18MB20902F13E30549AD2C99C81DF9860@MW2PR18MB2090.namprd18.prod.outlook.com>
Message-ID: <025301d4ac3c$8adbc1a0$a09344e0$@mcn.org>

Thanks @Michael. I read up on TIME_WAIT Assassination.

I think that sort of thing may have been the problem I was trying to fix.
After an "error" disconnection, the customer was reporting that their client
could not re-connect. I had trouble getting good traces out of the customer,
but I suspect the problem was that the underlying TCP connection was still
hanging.

I have never in my life touched SO_LINGER. There is no socket duplication,
fork(), or the like.

Thanks again,

Charles


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
Michael Wojcik
Sent: Saturday, January 12, 2019 6:20 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Close TCP socket after SSL_clear()?

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
Of
> Charles Mills
> Sent: Friday, January 11, 2019 17:06
>
> >        SSL_shutdown(connection) || SSL_shutdown(connection);
>
> I like it! (Not!)
>
> I don't pretend to be a bits and bytes expert on TCP protocol. You can't
be
> an expert on everything.
>
> So I will listen to expert advice. I know 99% of you all are 'nix guys and
> this is a Windows problem. I am seeing OTOH where my Windows doc says
> closesocket() does an abortive termination, and OTOH a discussion of a
> graceful closesocket() with SO_LINGER/SO_DONTLINGER.
>
> (1) This code is (at the application level) purely a receiver of data and
> (2) without the TLS layer in place it is hard to picture any meaningful
data
> transfer and (3) we are in a session cleanup situation anyway -- so it
seems
> to me that an abortive disconnect is perfectly fine. Am I wrong?

Yes, you're wrong. You don't want an abortive disconnect.

A TCP connection can be closed in four (or five) ways:

1. Normal close, which involves the FIN / FIN-ACK / ACK sequence. When the
last ACK is received, both sides know that all data has been received by the
peer stack, and at the point when the corresponding ACK was generated, the
peer "believed" it would be able to deliver the data to the application
eventually. (That is, the stack hadn't been informed that the application's
identifier for the connection - the socket - had been closed.)

2. Abortive close, which involves a RST from one side to the peer, and
that's it. RST is a one-way, unacknowledged flow. There are a number of
reasons why it's undesirable, some of which I'll go into below.

3. Abortive close due to network management message: the stack receives an
ICMP message indicating a packet could not be delivered, such as
HOST_UNREACH. From the application's point of view, the result is similar to
#2, except for the particular error code it sees.

4. Timeout from TCP retransmit, either for an application send or, if it's
enabled, TCP keepalive.

5. Arguably a separate case: 1-3 but generated by a middlebox, such as as a
router, or an application firewall. In other words, the connection is forced
closed by someone spoofing the peer. From the application's point of view,
that makes no difference.

Applications should almost never use an abortive close. TCP is intended to
be a reliable (best-effort) stream transport, and it can only meet its
(already weak) service guarantees if you let it acknowledge all application
data and close the conversation cleanly.

Now, when you have a higher-level conversation protocol such as TLS, and the
higher-level protocol has already negotiated end-of-conversation, that may
not seem important; the peers have agreed that they're not going to send
anything more. That assumes, however, that the peers are well-behaved. And
it is at the very least notionally cleaner to let the conversation close
normally.

Beyond that, an abortive close can cause TIME_WAIT Assassination, which is a
Bad Thing. If you don't know what TIME_WAIT Assassination is, that's a sign
you shouldn't be doing abortive closes. Don't invoke extraordinary behavior
you don't understand.

Now, all that said: Winsock closesocket will NOT do an abortive disconnect
if you have not mucked with the SO_LINGER socket option (which you should
not do unless you understand TCP). I don't know what documentation you saw
that claims otherwise, but it's wrong.

Calling shutdown before closesocket won't hurt anything, but (if you use the
pattern that we've discussed in this thread) won't do anything useful
either, in most cases.

One case I forgot in my previous discussion: It's worth remembering that
close/closesocket operates on a single reference to the connection, while
shutdown operates on the connection itself. That is, the logic for
close/closesocket is notionally something like this:

   close the descriptor/handle
   decrement the conversation's reference count
   if the reference count is 0
      if connection is still open for sending
         shutdown(SHUT_WR)
      if connection is still open for receiving
         shutdown(SHUT_RD)

In the case where you have multiple descriptors or handles for a
conversation - for example due to dup'ing a socket or forking on UNIX, or
duplicating a handle (possibly into a different process) on Windows - then
close/closesocket won't do the shutdown-equivalent until they have *all*
been closed. An explicit shutdown, on the other hand, doesn't close any of
the descriptors/handles, but it does send a FIN (for SHUT_WR) or flush
inbound data and refuse to receive any more (for SHUT_RD) on the
conversation, which of course affects all descriptors/handles.

So if your application creates multiple references to the conversation, then
depending on your design, you might want the shutdown. Or you might not, if
you want the shutdown-on-last-close semantics. Neither option is correct for
all applications.



From openssl-users at dukhovni.org  Mon Jan 14 20:31:36 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 14 Jan 2019 15:31:36 -0500
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <CAKQ1sVOAe2Ongj+CrVXAtF90fCX5OBU=v6QCY5piAnTWod5Mnw@mail.gmail.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
 <CAKQ1sVOAe2Ongj+CrVXAtF90fCX5OBU=v6QCY5piAnTWod5Mnw@mail.gmail.com>
Message-ID: <20190114203136.GL79754@straasha.imrryr.org>

On Mon, Jan 14, 2019 at 02:18:18PM +0100, Yann Ylavic wrote:

> I suppose one can always, e.g.:
> 
> $ openssl ciphers -v |grep TLSv1.3 |awk '{print $1}' # or whatever filtering
> 
> to not depend on this "accident", right?

The correct form would be:

    $ /usr/local/bin/openssl ciphers -s tls1_3 | tr ':' '\n'
    TLS_AES_256_GCM_SHA384
    TLS_CHACHA20_POLY1305_SHA256
    TLS_AES_128_GCM_SHA256

This shows which ciphers are applicable to TLS 1.3.  If TLS 1.4 ever
appears, and supports both TLS 1.3 and TLS 1.4 ciphers, then:

    $ /usr/local/bin/openssl ciphers -s tls1_4 | tr ':' '\n'

would show both, as both would be applicable.

-- 
	Viktor.

From openssl-users at dukhovni.org  Mon Jan 14 20:33:23 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 14 Jan 2019 15:33:23 -0500
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <20190114203136.GL79754@straasha.imrryr.org>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
 <CAKQ1sVOAe2Ongj+CrVXAtF90fCX5OBU=v6QCY5piAnTWod5Mnw@mail.gmail.com>
 <20190114203136.GL79754@straasha.imrryr.org>
Message-ID: <20190114203323.GM79754@straasha.imrryr.org>

On Mon, Jan 14, 2019 at 03:31:36PM -0500, Viktor Dukhovni wrote:

> > to not depend on this "accident", right?
> 
> The correct form would be:
> 
>     $ /usr/local/bin/openssl ciphers -s tls1_3 | tr ':' '\n'
>     TLS_AES_256_GCM_SHA384
>     TLS_CHACHA20_POLY1305_SHA256
>     TLS_AES_128_GCM_SHA256

Sorry, that shoulld "-tls1_3" not "tls1_3".

> This shows which ciphers are applicable to TLS 1.3.  If TLS 1.4 ever
> appears, and supports both TLS 1.3 and TLS 1.4 ciphers, then:
> 
>     $ /usr/local/bin/openssl ciphers -s tls1_4 | tr ':' '\n'

And likewise here: "-tls1_4" (if that comes to pass).

-- 
	Viktor.

From vinayashreeks18 at gmail.com  Tue Jan 15 09:17:47 2019
From: vinayashreeks18 at gmail.com (vin)
Date: Tue, 15 Jan 2019 02:17:47 -0700 (MST)
Subject: [openssl-users] OpenSSL handshake failure with RSA bad
	signature error
In-Reply-To: <CAJ-5c6vU5H5eQ+S2YOFu5M9CND3pq5-=wSt7HBJeER4zeHArgw@mail.gmail.com>
References: <CAJ-5c6uaW1iQ7xLD7L0qPcePqfVvqOw3VZQFFSiJX41xTuN8qQ@mail.gmail.com>
 <CAJ-5c6vU5H5eQ+S2YOFu5M9CND3pq5-=wSt7HBJeER4zeHArgw@mail.gmail.com>
Message-ID: <1547543867833-0.post@n7.nabble.com>

hi

You found solution for this issue.I am also facing the same.



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

From mksarav at gmail.com  Tue Jan 15 11:29:08 2019
From: mksarav at gmail.com (M K Saravanan)
Date: Tue, 15 Jan 2019 19:29:08 +0800
Subject: [openssl-users] Why openssl is printing session ID where there is
 none sent by server, when using session ticket?
Message-ID: <CAG5P2e-adCqf5de0E9NGfBSw_nQwjGRwjAJW5zw+fO11ZZ7Jqg@mail.gmail.com>

Hi,

When I use openssl s_client to connect to a server which uses session
ticket to resume a session (session ID is turned off), openssl is
still printing a session ID where none is sent by the server (packet
capture shows session ID length = zero in the Server Hello).

==========
New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
    Session-ID: 8C7B3863F4B599A10BB83258D0FCE0530CC3C858DC0E2561199599C4806D7457
    Session-ID-ctx:
    Master-Key:
226360F20D74DB3F5FED014C20AD897CF75C21D14FA358BE934BD50FAF4F1696CB9A05A45F6FACDD46D912CDAE060D0F
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 3600 (seconds)
    TLS session ticket:
    0000 - c9 c2 1a de f4 8f 59 1f-2a e1 58 b3 71 9f 9a 5f   ......Y.*.X.q.._
    0010 - 2f eb 0f a6 4c 0a e4 11-d9 db 52 7f 12 f6 0e a6   /...L.....R.....
    0020 - ec 2a c2 9b 3c d3 f5 b0-4e 93 b0 eb 44 12 3d 2b   .*..<...N...D.=+
    0030 - 46 a1 16 4d 4b aa 0d e4-63 68 ae b9 b8 27 16 d5   F..MK...ch...'..
    0040 - 1b d0 00 2c a5 48 5d b4-ba 44 3e 97 40 3e 74 ac   ...,.H]..D>.@>t.
    0050 - 76 94 e4 ae 1b c5 bb 44-48 49 88 65 cc 3c fc 95   v......DHI.e.<..
    0060 - 6e 92 ee 54 44 b1 f0 b1-7e 28 7d 5d 28 d1 00 1a   n..TD...~(}](...
    0070 - 8e f3 53 34 bc d9 c7 7f-e5 21 1c 15 cf 19 21 4f   ..S4.....!....!O
    0080 - 2b 51 b4 7c cf dd de 51-50 ce e2 b9 5f bd 65 55   +Q.|...QP..._.eU
    0090 - c4 0d fc 0f 6f ee 40 08-ac 7c fa 2a fa 9c 07 1d   ....o. at ..|.*....
    00a0 - 60 97 19 fd f5 7f 3e 73-c0 24 0a 51 63 0d db 73   `.....>s.$.Qc..s

    Start Time: 1547551254
    Timeout   : 7200 (sec)
    Verify return code: 18 (self signed certificate)
    Extended master secret: no
==========

OpenSSL version:

$ openssl version
OpenSSL 1.1.1a  20 Nov 2018

OS version:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.1 LTS
Release:        18.04
Codename:       bionic
----------------------------------
Is it a bug?

with regards,
Saravanan

From matt at openssl.org  Tue Jan 15 12:01:37 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 15 Jan 2019 12:01:37 +0000
Subject: [openssl-users] Why openssl is printing session ID where there
 is none sent by server, when using session ticket?
In-Reply-To: <CAG5P2e-adCqf5de0E9NGfBSw_nQwjGRwjAJW5zw+fO11ZZ7Jqg@mail.gmail.com>
References: <CAG5P2e-adCqf5de0E9NGfBSw_nQwjGRwjAJW5zw+fO11ZZ7Jqg@mail.gmail.com>
Message-ID: <ac45bb3a-63de-4ab6-9329-fca6547204cf@openssl.org>



On 15/01/2019 11:29, M K Saravanan wrote:
> Hi,
> 
> When I use openssl s_client to connect to a server which uses session
> ticket to resume a session (session ID is turned off), openssl is
> still printing a session ID where none is sent by the server (packet
> capture shows session ID length = zero in the Server Hello).


This is perhaps best explained by this comment in the client side code for
processing a new ticket from the server:

    /*
     * There are two ways to detect a resumed ticket session. One is to set
     * an appropriate session ID and then the server must return a match in
     * ServerHello. This allows the normal client session ID matching to work
     * and we know much earlier that the ticket has been accepted. The
     * other way is to set zero length session ID when the ticket is
     * presented and rely on the handshake to determine session resumption.
     * We choose the former approach because this fits in with assumptions
     * elsewhere in OpenSSL. The session ID is set to the SHA256 (or SHA1 is
     * SHA256 is disabled) hash of the ticket.
     */

So in other words, when the client receives a ticket from the server it assigns
it its own session id. This session id will be presented back to the server when
the client attempts to resume using the ticket - and the server MUST echo it
back if it accepts the ticket.

Matt




> 
> ==========
> New, TLSv1.2, Cipher is DHE-RSA-AES256-GCM-SHA384
> Server public key is 2048 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : DHE-RSA-AES256-GCM-SHA384
>     Session-ID: 8C7B3863F4B599A10BB83258D0FCE0530CC3C858DC0E2561199599C4806D7457
>     Session-ID-ctx:
>     Master-Key:
> 226360F20D74DB3F5FED014C20AD897CF75C21D14FA358BE934BD50FAF4F1696CB9A05A45F6FACDD46D912CDAE060D0F
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     TLS session ticket lifetime hint: 3600 (seconds)
>     TLS session ticket:
>     0000 - c9 c2 1a de f4 8f 59 1f-2a e1 58 b3 71 9f 9a 5f   ......Y.*.X.q.._
>     0010 - 2f eb 0f a6 4c 0a e4 11-d9 db 52 7f 12 f6 0e a6   /...L.....R.....
>     0020 - ec 2a c2 9b 3c d3 f5 b0-4e 93 b0 eb 44 12 3d 2b   .*..<...N...D.=+
>     0030 - 46 a1 16 4d 4b aa 0d e4-63 68 ae b9 b8 27 16 d5   F..MK...ch...'..
>     0040 - 1b d0 00 2c a5 48 5d b4-ba 44 3e 97 40 3e 74 ac   ...,.H]..D>.@>t.
>     0050 - 76 94 e4 ae 1b c5 bb 44-48 49 88 65 cc 3c fc 95   v......DHI.e.<..
>     0060 - 6e 92 ee 54 44 b1 f0 b1-7e 28 7d 5d 28 d1 00 1a   n..TD...~(}](...
>     0070 - 8e f3 53 34 bc d9 c7 7f-e5 21 1c 15 cf 19 21 4f   ..S4.....!....!O
>     0080 - 2b 51 b4 7c cf dd de 51-50 ce e2 b9 5f bd 65 55   +Q.|...QP..._.eU
>     0090 - c4 0d fc 0f 6f ee 40 08-ac 7c fa 2a fa 9c 07 1d   ....o. at ..|.*....
>     00a0 - 60 97 19 fd f5 7f 3e 73-c0 24 0a 51 63 0d db 73   `.....>s.$.Qc..s
> 
>     Start Time: 1547551254
>     Timeout   : 7200 (sec)
>     Verify return code: 18 (self signed certificate)
>     Extended master secret: no
> ==========
> 
> OpenSSL version:
> 
> $ openssl version
> OpenSSL 1.1.1a  20 Nov 2018
> 
> OS version:
> $ lsb_release -a
> No LSB modules are available.
> Distributor ID: Ubuntu
> Description:    Ubuntu 18.04.1 LTS
> Release:        18.04
> Codename:       bionic
> ----------------------------------
> Is it a bug?
> 
> with regards,
> Saravanan
> 

From jgh at wizmail.org  Tue Jan 15 13:08:53 2019
From: jgh at wizmail.org (Jeremy Harris)
Date: Tue, 15 Jan 2019 13:08:53 +0000
Subject: [openssl-users] cipher names
Message-ID: <193e764d-46f6-ea30-15fa-a97ced28b876@wizmail.org>

Hi,

RFC 8316 section 4.3 gives a need for cipher names per the
IANA registry https://www.iana.org/assignments/tls-parameters

Those have underbars not hyphens, lead with a "TLS_" and
have an embedded "WITH_", in contrast with the strings
returned by SSL_get_current_cipher().

Is there a supported way of getting the IANA-format name?
-- 
Thanks,
  Jeremy

From matt at openssl.org  Tue Jan 15 13:36:07 2019
From: matt at openssl.org (Matt Caswell)
Date: Tue, 15 Jan 2019 13:36:07 +0000
Subject: [openssl-users] cipher names
In-Reply-To: <193e764d-46f6-ea30-15fa-a97ced28b876@wizmail.org>
References: <193e764d-46f6-ea30-15fa-a97ced28b876@wizmail.org>
Message-ID: <258ba6cb-964a-f466-aa42-e77f0c43af58@openssl.org>



On 15/01/2019 13:08, Jeremy Harris wrote:
> Hi,
> 
> RFC 8316 section 4.3 gives a need for cipher names per the
> IANA registry https://www.iana.org/assignments/tls-parameters
> 
> Those have underbars not hyphens, lead with a "TLS_" and
> have an embedded "WITH_", in contrast with the strings
> returned by SSL_get_current_cipher().
> 
> Is there a supported way of getting the IANA-format name?
> 

You can use SSL_CIPHER_standard_name() for this:

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

Matt

From lear at ofcourseimright.com  Tue Jan 15 15:29:04 2019
From: lear at ofcourseimright.com (Eliot Lear)
Date: Tue, 15 Jan 2019 16:29:04 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
Message-ID: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>

I realize things haven't been made easy to do this on purpose, and that
there's even a comment in one of the man pages to that effect, but here
goes...

I have an application that requires long-lived signatures, perhaps long
past the point where the signer's cert has expired.? I'd like a way to
extract the signature date from a CMS structure.? With all the opaque
structs that have been introduced in the last few releases, it's not
clear to me how to do that.? Any examples or guidance (other than don't
do that)?

TIA

Eliot


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

From charlesm at mcn.org  Tue Jan 15 18:49:58 2019
From: charlesm at mcn.org (Charles Mills)
Date: Tue, 15 Jan 2019 10:49:58 -0800
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
Message-ID: <03a101d4ad03$1cfdcfd0$56f96f70$@mcn.org>

Leaping into something where I really don't know what I am talking about, does not code signing do that routinely? I can install software signed with a certificate that has expired, provided it had not expired when the code was signed.

Does that help, or it is just useless chatter about something you already knew?

Charles


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Eliot Lear
Sent: Tuesday, January 15, 2019 7:29 AM
To: openssl-users at openssl.org
Subject: [openssl-users] in the department of "ain't no perfect"

I realize things haven't been made easy to do this on purpose, and that there's even a comment in one of the man pages to that effect, but here goes...

I have an application that requires long-lived signatures, perhaps long past the point where the signer's cert has expired.  I'd like a way to extract the signature date from a CMS structure.  With all the opaque structs that have been introduced in the last few releases, it's not clear to me how to do that.  Any examples or guidance (other than don't do that)?


From rsalz at akamai.com  Tue Jan 15 20:12:45 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 15 Jan 2019 20:12:45 +0000
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <03a101d4ad03$1cfdcfd0$56f96f70$@mcn.org>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <03a101d4ad03$1cfdcfd0$56f96f70$@mcn.org>
Message-ID: <0C920015-BFEF-45EF-8C3C-3370D85ABB95@akamai.com>

> like a way to extract the signature date from a CMS structure.  With all the opaque structs that have been introduced in the last few releases, it's not clear to me how to do that.  Any examples or guidance (other than don't do that)?


Can you list which fields you need and open an issue on github?  Yes, this would be a bug-fix because "going opaque" made some things not possible.

Thanks.


From Michael.Wojcik at microfocus.com  Tue Jan 15 20:17:10 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 15 Jan 2019 20:17:10 +0000
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <03a101d4ad03$1cfdcfd0$56f96f70$@mcn.org>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <03a101d4ad03$1cfdcfd0$56f96f70$@mcn.org>
Message-ID: <MW2PR18MB2090E58C549784493E3E047DF9810@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Charles Mills
> Sent: Tuesday, January 15, 2019 13:50
>
> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> > Eliot Lear
> > Sent: Tuesday, January 15, 2019 7:29 AM
>
> > Subject: [openssl-users] in the department of "ain't no perfect"

In the department of "how to post to a technical mailing list": Please choose a meaningful subject line. That's more useful for recipients, and much more useful for people skimming through archives, either a public one or their own collection. (As someone with a literature and rhetoric background I understand the impulse toward stylistic flair, but the subject line isn't the occasion for it. Kairos, y'know.)

> > I have an application that requires long-lived signatures, perhaps long past
> > the point where the signer's cert has expired.
>
> Leaping into something where I really don't know what I am talking about,
> does not code signing do that routinely? I can install software signed with a
> certificate that has expired, provided it had not expired when the code was
> signed.

That's because it's a timestamped signature. Timestamping involves getting a signed timestamp from a public timestamp server run by a trusted source (typically a public CA), and adding that to the document being signed. It attests that the signature was generated while the signing certificate was still valid.

There are issues with timestamped signatures. In particular, because information about certificate revocation (CRL entries and OCSP records) is generally discarded after the revoked certificate expires - to prevent CRLs and OCSP databases from growing without limit - once a certificate has expired there's no way to know whether a timestamped signature was created before the certificate was revoked. Or, for that matter, before the key was compromised (which was presumably some time before revocation).

I don't know whether Eliot has considered timestamped signatures, but generally timestamping is done by whoever generates the message. I suppose you could receive a message, and if its signature is not timestamped, you could validate the signature, then enclose the whole thing in a message of your own, which you could then timestamp and sign, attesting that it was valid when you received it. (Or you could keep that information in some other fashion, of course.)

> > I'd like a way to extract the signature date from a CMS structure.

Date or data? It's not clear what your intention is here.

> > With all the opaque structs that have
> > been introduced in the last few releases, it's not clear to me how to do
> > that.

Offhand, I don't know. But I'll note that - returning to the matter of mailing-list use - you haven't told us what version of OpenSSL you're using. Or your platform, though since this is an API question that shouldn't matter (unless someone can suggest an alternative API - which, come to think of it, someone might, if only we knew more about your platform and application).

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From lear at ofcourseimright.com  Tue Jan 15 21:38:32 2019
From: lear at ofcourseimright.com (Eliot Lear)
Date: Tue, 15 Jan 2019 22:38:32 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <0C920015-BFEF-45EF-8C3C-3370D85ABB95@akamai.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <03a101d4ad03$1cfdcfd0$56f96f70$@mcn.org>
 <0C920015-BFEF-45EF-8C3C-3370D85ABB95@akamai.com>
Message-ID: <71df2de4-3763-1c08-1e54-6d1787d8660b@ofcourseimright.com>

Hi Rich and thanks for your response.? Please see below.

On 15.01.19 21:12, Salz, Rich via openssl-users wrote:
>> like a way to extract the signature date from a CMS structure.  With all the opaque structs that have been introduced in the last few releases, it's not clear to me how to do that.  Any examples or guidance (other than don't do that)?
>
> Can you list which fields you need and open an issue on github?  Yes, this would be a bug-fix because "going opaque" made some things not possible.


Wilco.? For the benefit of others, I'm the verifier, and at least at the
moment, no externally signed timestamp is available.? So what I want
access to is the id-signingTime attribute from the CMS structure,
preferably parsed neatly into a time_t akin to
X509_VERIFY_PARAM_get_time, but presumably coming? from CMS_ContentInfo.

I don't know if this was was ever externalized, Rich, but I'll open the
Github issue.? I recognize that examining this value is not without
risks in the general case.

Eliot

ps: sorry for the artsy subject line.




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

From mksarav at gmail.com  Wed Jan 16 02:48:53 2019
From: mksarav at gmail.com (M K Saravanan)
Date: Wed, 16 Jan 2019 10:48:53 +0800
Subject: [openssl-users] Why openssl is printing session ID where there
 is none sent by server, when using session ticket?
In-Reply-To: <ac45bb3a-63de-4ab6-9329-fca6547204cf@openssl.org>
References: <CAG5P2e-adCqf5de0E9NGfBSw_nQwjGRwjAJW5zw+fO11ZZ7Jqg@mail.gmail.com>
 <ac45bb3a-63de-4ab6-9329-fca6547204cf@openssl.org>
Message-ID: <CAG5P2e-YvWEzvWDKp56OkQdzPj4tbw8jYgmpZQ06yo6D8iEmNw@mail.gmail.com>

Hi Matt,

On Tue, 15 Jan 2019 at 20:02, Matt Caswell <matt at openssl.org> wrote:
> This is perhaps best explained by this comment in the client side code for
> processing a new ticket from the server:
>
>     /*
>      * There are two ways to detect a resumed ticket session. One is to set
>      * an appropriate session ID and then the server must return a match in
>      * ServerHello. This allows the normal client session ID matching to work
>      * and we know much earlier that the ticket has been accepted. The
>      * other way is to set zero length session ID when the ticket is
>      * presented and rely on the handshake to determine session resumption.
>      * We choose the former approach because this fits in with assumptions
>      * elsewhere in OpenSSL. The session ID is set to the SHA256 (or SHA1 is
>      * SHA256 is disabled) hash of the ticket.
>      */

Beautiful!  Thank you so much for the clarification.

with regards,
Saravanan

From ananthuu741 at gmail.com  Wed Jan 16 05:36:08 2019
From: ananthuu741 at gmail.com (Ananthu Unnikrishnan)
Date: Wed, 16 Jan 2019 11:06:08 +0530
Subject: [openssl-users] Openssl asynchronous operation in real network
In-Reply-To: <09eaae85-a81f-086a-5f58-0272dea73abf@openssl.org>
References: <CADqiADgndoAkYs2PQ9kvE1hgHYQRH5KdmAiPgx-+ZZR7eQEQvA@mail.gmail.com>
 <CADqiADj65nc8NAXjAhHy2neAQGd9i-kTpyRhaL9sL=307KjGAg@mail.gmail.com>
 <CADqiADif7GoyTpSHStsdT32SDvY6-p0c+Fbs86BWJ0=g1+SACA@mail.gmail.com>
 <CADqiADhOP27jU6nie1PpXAF_vTe-XXJXb3F8hb0-EELF+_fGDQ@mail.gmail.com>
 <f0cb28ac-c683-e430-33f1-f1dad945e868@openssl.org>
 <CADqiADhYtL8pyR87UZvMXOCf7VARbLmzKuJ7fz-sHD5=ad5seA@mail.gmail.com>
 <2c98a823-b680-9cdb-104d-6f66c4bba652@openssl.org>
 <CADqiADhBHss=Hyu60cjX5bt0O86x3+wq+ftSZWuzGUnZbVZbfg@mail.gmail.com>
 <09eaae85-a81f-086a-5f58-0272dea73abf@openssl.org>
Message-ID: <CADqiADg++uuQ4nL5u=b8KviDLZ1FW508VxNjnxAGFrDt4Gw2LA@mail.gmail.com>

Hi Matt,

        Thanks for your update. Will try to implement one scheme using the
same.

        I have one doubt regarding the points which we have discussed
earlier.

        I am now facing an issue of getting an invalid waitctx address
while trying to get it using ASYNC_get_wait_ctx(). I have checked using
gdb, in which got memory inaccessible print when I tried to dump
the waitctx structure. If I put some delay in the engine, things are
working fine, ie. no corruption of waitctx structure address.

        But I am just copying the address of job structure before the
ASYNC_pause().  After the HW operation is completed I will use this address
to get waitctx and fd using ASYNC_get_wait_ctx() and
ASYNC_WAIT_CTX_get_fd() from the thread which  I have created from the
engine. I haven't access the job address directly from the thread.

        I know you have already told me that I should be careful while
handling ASYNC_JOB structure from outside threads. But I have only a little
experience on handling these ASYNC_JOB structures. If you can provide a
solution for this, it would be helpful.

On 14 Jan 2019 5:33 pm, "Matt Caswell" <matt at openssl.org> wrote:

>
>
> On 13/01/2019 04:36, Ananthu Unnikrishnan wrote:
> > Hi Matt,
> >
> >             Thanks a lot for the response. The alternative method to
> resume job
> > operation is a good one.
> >
> >             I need some more clarifications regarding the async job
> operation.
> > Please help.
> >             In ssl/ss_lib.c, ssl_start_async_job() function found. In
> which
> > ASYNC_start_job function is calling but no mechanism found for polling
> the fd's.
> > Is it written elsewhere?.
>
> You are supposed to write the fd polling code yourself, e.g. by using
> SSL_get_all_async_fds() or SSL_get_changed_async_fds() to get hold of the
> fds,
> and then followed by "select" or similar.
>
> See:
>
> https://www.openssl.org/docs/man1.1.1/man3/SSL_get_all_async_fds.html
>
> mATT
>
>
>
> >
> >
> > On Fri, Jan 11, 2019 at 3:12 PM Matt Caswell <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> >
> >
> >
> >     On 10/01/2019 18:09, Ananthu Unnikrishnan wrote:
> >     > Hi Matt,
> >     >
> >     >         Thanks a lot for the reply.
> >     >
> >     >        After calling ASYNC_pause_job() from the engine, control
> will
> >     transfer to
> >     > the place where we start the ASYNC_start_job right? So how can we
> write
> >     the code
> >     > to put a trigger on fd in the same thread?
> >
> >     I'm not saying you can't use threads to do this - only that you need
> to be
> >     careful about using them and must obey the rules.
> >
> >
> >     > If I am wrong  please correct me.
> >     > Also if u can suggest where resume operation should be done, it
> would be
> >     helpful.
> >
> >     Typically the calling application will wait on the fd (e.g. using
> "select" or
> >     similar) until it is readable. Once it sees the fd as readable then
> it calls
> >     ASYNC_start_job() again.
> >
> >
> >     As an aside you may also be interested in this PR that is currently
> being
> >     reviewed:
> >
> >     https://github.com/openssl/openssl/pull/7573
> >
> >     This adds an alternative mechanism for signalling other than using
> fds (i.e. to
> >     use a callback instead) and will be available in OpenSSL 3.0 when it
> gets
> >     released.
> >
> >     Matt
> >
> >
> >
> >     >
> >     > On Thu, Jan 10, 2019 at 10:11 PM Matt Caswell <matt at openssl.org
> >     <mailto:matt at openssl.org>
> >     > <mailto:matt at openssl.org <mailto:matt at openssl.org>>> wrote:
> >     >
> >     >
> >     >
> >     >     On 10/01/2019 09:39, Ananthu Unnikrishnan wrote:
> >     >     > Hi all,
> >     >     >
> >     >     >         We are not able to access the waitctx address from
> the job
> >     address
> >     >     using
> >     >     > ASYNC_get_wait_ctx(job) from a thread which starts in the
> bind
> >     section of the
> >     >     > dynamic engine. The job address is the same as that we got
> >     >     > using ASYNC_get_current_job.  Can anyone help on this?
> >     >
> >     >     It's very unclear from the your various emails what you are
> trying to
> >     achieve
> >     >     and the problem that you are experiencing.
> >     >
> >     >     From the above it sounds like you are starting threads from
> inside
> >     your dynamic
> >     >     engine? ASYNC_JOBs are always local to a thread. When a job is
> started
> >     it is
> >     >     associated with the current thread. So ASYNC_get_current_job()
> returns
> >     the job
> >     >     associated with the current thread. Similarly if you pause a
> job,
> >     >     ASYNC_pause_job() must be called from that same thread.
> Finally if you
> >     restart a
> >     >     paused job it must also be restarted on the same thread.
> >     >
> >     >     If you are starting new threads from within your engine then
> extreme
> >     care must
> >     >     be taken to obey the above rules - otherwise you are likely to
> get strange
> >     >     results.
> >     >
> >     >     Matt
> >     >
> >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > On Tue, Jan 8, 2019 at 11:26 AM Ananthu Unnikrishnan
> >     >     <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
> >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>
> >     >     > <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
> >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>>
> wrote:
> >     >     >
> >     >     >     Can anyone please help on this? If u need any additional
> information
> >     >     please
> >     >     >     let me know.
> >     >     >
> >     >     >     On Mon, Jan 7, 2019 at 6:25 PM Ananthu Unnikrishnan
> >     >     <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
> >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>
> >     >     >     <mailto:ananthuu741 at gmail.com <mailto:
> ananthuu741 at gmail.com>
> >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>>
> wrote:
> >     >     >
> >     >     >         Hi all,
> >     >     >
> >     >     >         Adding more details to the previous mail. We have
> edited the
> >     OpenSSL
> >     >     >         code for implementing the polling for changed
> fd's as in
> >     OpenSSL speed
> >     >     >         command. Attached the code snippet of the same along
> with
> >     this mail.
> >     >     >         Mentioned below some observations which found
> doubtful:
> >     >     >
> >     >     >         1) We have got prints in ASYNC_FINISH case, before
> getting
> >     print in
> >     >     >         ASYNC_PAUSE case. Attaching the log also, so you can
> understand
> >     >     easily.
> >     >     >         2) Shown below the code snippet which we have
> written to
> >     provide a
> >     >     write
> >     >     >         on fd.
> >     >     >
> >     >     >         if ((waitctx = ASYNC_get_wait_ctx((ASYNC_JOB *)job))
> == NULL) {
> >     >     >                 printf("In dynamic engine | waitctx == NULL
> : %d\n",
> >     >     __LINE__);
> >     >     >                 return ret;
> >     >     >             }
> >     >     >
> >     >     >             printf("\n----- In dynamic engine | After
> pausing | job
> >     is %lx |
> >     >     >         waitctx in resume job %lx |-----\n", job, waitctx);
> >     >     >
> >     >     >                 if ((ret = ASYNC_WAIT_CTX_get_fd(waitctx,
> engine_id,
> >     &efd,
> >     >     >                                       &custom)) > 0) {
> >     >     >                 if (write(efd, &buf, sizeof(uint64_t)) ==
> -1) {
> >     >     >                     printf("\nFailed to write\n");
> >     >     >                 }
> >     >     >             }
> >     >     >
> >     >     >         Here waitctx is getting NULL when we tried to fetch
> waitctx
> >     using
> >     >     >         ASYNC_get_wait_ctx(). We have printed data of
> sizeof(ASYNC_JOB)
> >     >     ie.1176
> >     >     >         bytes contained in the job address from the engine,
> we got
> >     >     correct data
> >     >     >         before calling ASYNC_pause() and but got half data
> zero data
> >     when we
> >     >     >         tried to access the same address after
> ASYNC_pause().
> >     >     >
> >     >     >         Attaching both job structure contents before and
> after calling
> >     >     >         ASYNC_pause(). Also, we got the correct data in the
> same address
> >     >     when we
> >     >     >         have printed from ssl_start_async_job() before
> polling starts,
> >     >     where we
> >     >     >         have started the async_job
> >     >     >         .
> >     >     >         The prints starting with "In dynamic engine" are
> prints
> >     inside the
> >     >     >         engine, rest prints are from ss/ssl_lib.c. Kindly
> check this and
> >     >     please
> >     >     >         point out if anything is wrong somewhere. Thanks in
> advance.
> >     >     >
> >     >     >
> >     >     >         On Sun, Jan 6, 2019 at 10:30 AM Ananthu Unnikrishnan
> >     >     >         <ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com
> >
> >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>
> >     >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>
> >     <mailto:ananthuu741 at gmail.com <mailto:ananthuu741 at gmail.com>>>>
> wrote:
> >     >     >
> >     >     >             Hi all,
> >     >     >
> >     >     >                    We have implemented a dynamic engine and
> tested
> >     in the
> >     >     async
> >     >     >             mode using OpenSSL speed command. But in a real
> network
> >     >     scenario, we
> >     >     >             have seen only starting the async_job(in file
> ssl/ssl_lib.c,
> >     >     >             function: ssl_start_async_job) in the OpenSSL. We
> >     haven't seen
> >     >     >             polling async_fd's for resuming the job as in
> >     apps/speed.c(in
> >     >     speed
> >     >     >             command case).
> >     >     >                     So can anyone please suggest any
> solution for
> >     resuming the
> >     >     >             async_jobs in real network scenario? Thanks in
> advance.
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >         --
> >     >     >         With best Regards,
> >     >     >
> >     >     >                  Ananthu
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >     --
> >     >     >     With best Regards,
> >     >     >
> >     >     >              Ananthu
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > --
> >     >     > With best Regards,
> >     >     >
> >     >     >          Ananthu
> >     >     >
> >     >     >
> >     >     >
> >     >     --
> >     >     openssl-users mailing list
> >     >     To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> >     >
> >     >
> >     >
> >     > --
> >     > With best Regards,
> >     >
> >     >          Ananthu
> >     >
> >     >
> >     >
> >     --
> >     openssl-users mailing list
> >     To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> >
> > --
> > With best Regards,
> >
> >          Ananthu
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190116/a1991443/attachment-0001.html>

From hkario at redhat.com  Wed Jan 16 11:27:34 2019
From: hkario at redhat.com (Hubert Kario)
Date: Wed, 16 Jan 2019 12:27:34 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <71df2de4-3763-1c08-1e54-6d1787d8660b@ofcourseimright.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <0C920015-BFEF-45EF-8C3C-3370D85ABB95@akamai.com>
 <71df2de4-3763-1c08-1e54-6d1787d8660b@ofcourseimright.com>
Message-ID: <5673079.YMQc8crFEW@pintsize.usersys.redhat.com>

On Tuesday, 15 January 2019 22:38:32 CET Eliot Lear wrote:
> Hi Rich and thanks for your response.  Please see below.
> 
> On 15.01.19 21:12, Salz, Rich via openssl-users wrote:
> >> like a way to extract the signature date from a CMS structure.  With all
> >> the opaque structs that have been introduced in the last few releases,
> >> it's not clear to me how to do that.  Any examples or guidance (other
> >> than don't do that)?> 
> > Can you list which fields you need and open an issue on github?  Yes, this
> > would be a bug-fix because "going opaque" made some things not possible.
> Wilco.  For the benefit of others, I'm the verifier, and at least at the
> moment, no externally signed timestamp is available.  So what I want
> access to is the id-signingTime attribute from the CMS structure,
> preferably parsed neatly into a time_t akin to
> X509_VERIFY_PARAM_get_time, but presumably coming  from CMS_ContentInfo.
> 
> I don't know if this was was ever externalized, Rich, but I'll open the
> Github issue.  I recognize that examining this value is not without
> risks in the general case.

for one, if the attacker can forge a signature, he or she can easily forge 
that attribute too ? it's not something you can depend on

For maintaining signatures that need to be valid long into the future 
standards like CAdES should be used. They keep time of signing in timestamps 
signed by trusted time-stamping authorities, along with the rest of revocation 
data necessary to verify the original signature.
-- 
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/20190116/89619fb1/attachment.sig>

From lear at ofcourseimright.com  Wed Jan 16 12:22:53 2019
From: lear at ofcourseimright.com (Eliot Lear)
Date: Wed, 16 Jan 2019 13:22:53 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <5673079.YMQc8crFEW@pintsize.usersys.redhat.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <0C920015-BFEF-45EF-8C3C-3370D85ABB95@akamai.com>
 <71df2de4-3763-1c08-1e54-6d1787d8660b@ofcourseimright.com>
 <5673079.YMQc8crFEW@pintsize.usersys.redhat.com>
Message-ID: <41dd4a6c-dcfc-a761-22cd-8b76031ca9a6@ofcourseimright.com>

Hi Hubert

On 16.01.19 12:27, Hubert Kario wrote:
> For maintaining signatures that need to be valid long into the future 
> standards like CAdES should be used. They keep time of signing in timestamps 
> signed by trusted time-stamping authorities, along with the rest of revocation 
> data necessary to verify the original signature.


Understood.? At this point in the maturity cycle of the technology,
we're just not there yet.? My choices are, have people ignore invalid
signatures in their entirety or provide something more nuanced for now.

Eliot


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

From hkario at redhat.com  Wed Jan 16 14:46:40 2019
From: hkario at redhat.com (Hubert Kario)
Date: Wed, 16 Jan 2019 15:46:40 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <41dd4a6c-dcfc-a761-22cd-8b76031ca9a6@ofcourseimright.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <5673079.YMQc8crFEW@pintsize.usersys.redhat.com>
 <41dd4a6c-dcfc-a761-22cd-8b76031ca9a6@ofcourseimright.com>
Message-ID: <8236256.ihoYfv2QBE@pintsize.usersys.redhat.com>

On Wednesday, 16 January 2019 13:22:53 CET Eliot Lear wrote:
> Hi Hubert
> 
> On 16.01.19 12:27, Hubert Kario wrote:
> > For maintaining signatures that need to be valid long into the future
> > standards like CAdES should be used. They keep time of signing in
> > timestamps signed by trusted time-stamping authorities, along with the
> > rest of revocation data necessary to verify the original signature.
> 
> Understood.  At this point in the maturity cycle of the technology,
> we're just not there yet.  My choices are, have people ignore invalid
> signatures in their entirety or provide something more nuanced for now.

you don't have to start with implementing the full CAdES-LTA, you can start 
with just adding support for timestamping, the CAdES-T

using time from the signature to verify it is as good as ignoring the 
certificate expiration date - if you need to make the signatures verifiable 
now, do that, not use the false sense of security of using easily fakeable 
date
-- 
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/20190116/6e474714/attachment.sig>

From charlesm at mcn.org  Wed Jan 16 20:04:07 2019
From: charlesm at mcn.org (Charles Mills)
Date: Wed, 16 Jan 2019 12:04:07 -0800
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <8236256.ihoYfv2QBE@pintsize.usersys.redhat.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <5673079.YMQc8crFEW@pintsize.usersys.redhat.com>
 <41dd4a6c-dcfc-a761-22cd-8b76031ca9a6@ofcourseimright.com>
 <8236256.ihoYfv2QBE@pintsize.usersys.redhat.com>
Message-ID: <058d01d4add6$a35377f0$e9fa67d0$@mcn.org>

Temporary solutions that "work" tend to become permanent solutions.

That's how products end up shipping with hard-coded admin passwords or similar back doors.

Charles


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Hubert Kario
Sent: Wednesday, January 16, 2019 6:47 AM
To: Eliot Lear
Cc: openssl-users at openssl.org
Subject: Re: [openssl-users] in the department of "ain't no perfect"

On Wednesday, 16 January 2019 13:22:53 CET Eliot Lear wrote:
> Hi Hubert
> 
> On 16.01.19 12:27, Hubert Kario wrote:
> > For maintaining signatures that need to be valid long into the 
> > future standards like CAdES should be used. They keep time of 
> > signing in timestamps signed by trusted time-stamping authorities, 
> > along with the rest of revocation data necessary to verify the original signature.
> 
> Understood.  At this point in the maturity cycle of the technology, 
> we're just not there yet.  My choices are, have people ignore invalid 
> signatures in their entirety or provide something more nuanced for now.

you don't have to start with implementing the full CAdES-LTA, you can start with just adding support for timestamping, the CAdES-T

using time from the signature to verify it is as good as ignoring the certificate expiration date - if you need to make the signatures verifiable now, do that, not use the false sense of security of using easily fakeable date


From openssl-users at dukhovni.org  Wed Jan 16 20:25:32 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 16 Jan 2019 15:25:32 -0500
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
Message-ID: <B6A8DC5E-2AA0-4958-A5EA-5989CFF7F05B@dukhovni.org>

> On Jan 15, 2019, at 10:29 AM, Eliot Lear <lear at ofcourseimright.com> wrote:
> 
> I have an application that requires long-lived signatures, perhaps long
> past the point where the signer's cert has expired.  I'd like a way to
> extract the signature date from a CMS structure.  With all the opaque
> structs that have been introduced in the last few releases, it's not
> clear to me how to do that.  Any examples or guidance (other than don't
> do that)?

I doubt this has anything to do with opaque structures.  The real
issue here is that IIRC CMS (previously known as PKCS7) has no
signature date.  It just has to be signed data and a signature,
with an X.509 certificate that has an expiration.

For long-term storage, the date of interest is NOT when the object
was signed, but when it was received, verified and stored.  For
that what you need is separate long-term integrity protection for
the underlying object store, separate from the origin signatures
on inbound objects, that need only be valid at time of import.

Indeed with content that's also encrypted, you'll typically want
to immediately decrypt it, decoupling it from a comparatively
short-lived inbound encryption public key, and re-encrypt for
storage under a key that is managed as part of the object store.

The na?ve model of using the signer and recipient keys as long-term
verification and decryption keys is deeply flawed for data retention.
This is a bit part of the reason why end-to-end email encryption has
negligible adoption, the storage infrastructure to make it usable was
never built.

-- 
	Viktor.


From Steven.Winfield at cantabcapital.com  Wed Jan 16 21:53:32 2019
From: Steven.Winfield at cantabcapital.com (Steven Winfield)
Date: Wed, 16 Jan 2019 21:53:32 +0000
Subject: [openssl-users] Get peer certificate after handshake failure
Message-ID: <E9FA92C2921F31408041863B74EE4C2001BD2EF7A5@CCPMAILDAG03.cantab.local>

Hi all,

First time posting here so please be gentle ;-)

TL;DR: After a failed handshake, caused by our peer's certificate failing verification, what is the correct way to get hold of the peer's certificate?

A little more detail:
I'd like my server applications to be able to log some details about the client's certificate after a failed handshake, such as CN, SAN, not-valid-before, and not-valid-after values.
So, after a failed handshake, I thought should be able to call SSL_get_peer_certificate(), however I'm using python (:-) bear with me...) where in the guts of SSLSocket.getpeercert() the call to SSL_get_peer_certificate() isn't even attempted if SSL_is_init_finished() is false.[1]

Is SSL_is_init_finished() too severe a check in this case, and SSL_get_peer_certificate() would actually work fine?

More detail, in case it is relevant:
We have an internal CA, and both the server and client have certificates signed by this CA, and both trust the CA's certificate.
The SSLContexts on both sides have:
  * verify flags = SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT
  * certificate store verify flags = X509_V_FLAG_TRUSTED_FIRST | X509_V_FLAG_X509_STRICT

Any help would be greatly appreciated.

Best wishes,
Steven.


[1] https://github.com/python/cpython/blob/3.7/Modules/_ssl.c#L1813



This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. 
The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. 
See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. 
If you cannot access this link, please notify us by reply message and we will send the contents to you.

GAM Holding AG and its subsidiaries (Cantab ? GAM Systematic) will collect and use information about you in the course of your interactions with us. 
Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. 
Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190116/06522436/attachment-0001.html>

From petrescucc at gmail.com  Thu Jan 17 14:21:08 2019
From: petrescucc at gmail.com (Petrescu Constantin Cezar)
Date: Thu, 17 Jan 2019 14:21:08 +0000
Subject: [openssl-users] Question regarding OpenSSL compilations
Message-ID: <CALm_qjV6Agt_prKmTg=g_R_JE5tiV4S3a95BW3Gcoqz_fSf=1Q@mail.gmail.com>

Dear sirs/madams,

My name is Costin Cezar Petrescu and I am a student at Royal Holloway. I am
intending to conduct some research regarding compilation errors, tricks to
fix compiler mistakes and their affects over cryptographic libraries.

If it is possible, I would like to find more about OpenSSL issues. If there
are some things you believe could be related to what I do, can you guide me
to them?

Thanks in advance.

Kind regards,
Costin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190117/63b41575/attachment.html>

From matt at openssl.org  Thu Jan 17 14:37:07 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 17 Jan 2019 14:37:07 +0000
Subject: [openssl-users] Question regarding OpenSSL compilations
In-Reply-To: <CALm_qjV6Agt_prKmTg=g_R_JE5tiV4S3a95BW3Gcoqz_fSf=1Q@mail.gmail.com>
References: <CALm_qjV6Agt_prKmTg=g_R_JE5tiV4S3a95BW3Gcoqz_fSf=1Q@mail.gmail.com>
Message-ID: <bb6960bd-3710-8808-b44a-a380023d264a@openssl.org>



On 17/01/2019 14:21, Petrescu Constantin Cezar wrote:
> Dear sirs/madams,
> 
> My name is Costin Cezar Petrescu and I am a student at Royal Holloway. I am
> intending to conduct some research regarding compilation errors, tricks to fix
> compiler mistakes and their affects over cryptographic libraries.?
> 
> If it is possible, I would like to find more about OpenSSL issues. If there are
> some things you believe could be related to what I do, can you guide me to them? ?

You can see all our current issues on github here:

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

You can also look at the closed issues (to see historically the kind of problem
we face) from the same page (click where it says "xxx Closed" - where xxx is a
number). Typically when we fix an issue it gets automatically linked to the
commit that fixed it.

We don't specifically separate out issues related to "compilation errors" you'd
have to search for those yourself. Of course most compilation errors wouldn't
ever make it as far as git in the first place since they would be fixed by the
developer before getting that far.

Matt


From hkario at redhat.com  Thu Jan 17 16:29:53 2019
From: hkario at redhat.com (Hubert Kario)
Date: Thu, 17 Jan 2019 17:29:53 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <B6A8DC5E-2AA0-4958-A5EA-5989CFF7F05B@dukhovni.org>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <B6A8DC5E-2AA0-4958-A5EA-5989CFF7F05B@dukhovni.org>
Message-ID: <5163262.KKx49qeQVV@pintsize.usersys.redhat.com>

On Wednesday, 16 January 2019 21:25:32 CET Viktor Dukhovni wrote:
> > On Jan 15, 2019, at 10:29 AM, Eliot Lear <lear at ofcourseimright.com> wrote:
> > 
> > I have an application that requires long-lived signatures, perhaps long
> > past the point where the signer's cert has expired.  I'd like a way to
> > extract the signature date from a CMS structure.  With all the opaque
> > structs that have been introduced in the last few releases, it's not
> > clear to me how to do that.  Any examples or guidance (other than don't
> > do that)?
> 
> For long-term storage, the date of interest is NOT when the object
> was signed, but when it was received, verified and stored.  For
> that what you need is separate long-term integrity protection for
> the underlying object store, separate from the origin signatures
> on inbound objects, that need only be valid at time of import.

alternatively, you can save all the certificates and revocation data, bind it 
to the original signature using a timestamp from a TSA and store that (that's 
necessary if you want to be able to prove to some 3rd party that you received 
a correctly signed document/message at that time)

but that is very close to reimplementing CAdES, or related standards, and is 
far from simple (for one, requires adding, regularly, new timestamps to extend 
validity of the original signature and subsequent timestamps)

-- 
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/20190117/e16c8353/attachment.sig>

From rsalz at akamai.com  Thu Jan 17 16:33:12 2019
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 17 Jan 2019 16:33:12 +0000
Subject: [openssl-users] Question regarding OpenSSL compilations
In-Reply-To: <CALm_qjV6Agt_prKmTg=g_R_JE5tiV4S3a95BW3Gcoqz_fSf=1Q@mail.gmail.com>
References: <CALm_qjV6Agt_prKmTg=g_R_JE5tiV4S3a95BW3Gcoqz_fSf=1Q@mail.gmail.com>
Message-ID: <A04C303F-7E1A-4D8C-BDA9-A3DAA5540874@akamai.com>

Look at the tricks openssl has to do in order to properly zeroized memory and avoid having the compiler optimize it away.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190117/7ce9ab28/attachment.html>

From lear at ofcourseimright.com  Thu Jan 17 17:03:55 2019
From: lear at ofcourseimright.com (Eliot Lear)
Date: Thu, 17 Jan 2019 18:03:55 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <5163262.KKx49qeQVV@pintsize.usersys.redhat.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <B6A8DC5E-2AA0-4958-A5EA-5989CFF7F05B@dukhovni.org>
 <5163262.KKx49qeQVV@pintsize.usersys.redhat.com>
Message-ID: <4965ac04-0b8c-db50-0c20-a7418f36759b@ofcourseimright.com>


On 17.01.19 17:29, Hubert Kario wrote:
>
> alternatively, you can save all the certificates and revocation data, bind it 
> to the original signature using a timestamp from a TSA and store that (that's 
> necessary if you want to be able to prove to some 3rd party that you received 
> a correctly signed document/message at that time)
>
> but that is very close to reimplementing CAdES, or related standards, and is 
> far from simple (for one, requires adding, regularly, new timestamps to extend 
> validity of the original signature and subsequent timestamps)
>

Right.? There are a lot of trust challenges around the timestamp.?
Because there are multiple non-cooperating entities involved, the signer
is not in a position to predict who the recipients will trust, and the
recipients may be retrieving the information later.? This is not a
simple matter.

What's more, we're not in a position to provide meaningful programmatic
diagnostic info in this case because CMS is calling X.509 codes, and so
ERR_get_err has a little issue when multiple libraries are in play.? And
while nobody likes to hear, ?I'll just bypass this one thing?, as a
matter of practicality we want to provide the application user (in this
case an administrator) a choice of what to do with as much information
as possible.

Eliot




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

From Steven.Winfield at cantabcapital.com  Thu Jan 17 17:39:39 2019
From: Steven.Winfield at cantabcapital.com (Steven Winfield)
Date: Thu, 17 Jan 2019 17:39:39 +0000
Subject: [openssl-users] Get peer certificate after handshake failure
In-Reply-To: <7qrmrnett1l4ulgi5hy45rl3.1547739068530@email.android.com>
References: <7qrmrnett1l4ulgi5hy45rl3.1547739068530@email.android.com>
Message-ID: <E9FA92C2921F31408041863B74EE4C2001BD2F8D92@CCPMAILDAG03.cantab.local>

Hi all,

First time posting here so please be gentle ;-)

TL;DR: After a failed handshake, caused by our peer?s certificate failing verification, what is the correct way to get hold of the peer?s certificate?

A little more detail:
I?d like my server applications to be able to log some details about the client?s certificate after a failed handshake, such as CN, SAN, not-valid-before, and not-valid-after values.
So, after a failed handshake, I thought should be able to call SSL_get_peer_certificate(), however I?m using python (:-) bear with me?) where in the guts of SSLSocket.getpeercert() the call to SSL_get_peer_certificate() isn?t even attempted if SSL_is_init_finished() is false.[1]

Is SSL_is_init_finished() too severe a check in this case, and SSL_get_peer_certificate() would actually work fine?

More detail, in case it is relevant:
We have an internal CA, and both the server and client have certificates signed by this CA, and both trust the CA?s certificate.
The SSLContexts on both sides have:
  * verify flags = SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT
  * certificate store verify flags = X509_V_FLAG_TRUSTED_FIRST | X509_V_FLAG_X509_STRICT

Any help would be greatly appreciated.

Best wishes,
Steven.

[1] https://github.com/python/cpython/blob/3.7/Modules/_ssl.c#L1813<https://github.com/python/cpython/blob/3.7/Modules/_ssl.c#L1813>

You'll have better luck getting the peer certificate *during* the handshake, not after.
Read e. g. https://stackoverflow.com/questions/9089957/validating-client-certificates-in-pyopenssl<https://stackoverflow.com/questions/9089957/validating-client-certificates-in-pyopenssl> on how to set up a verify callback function using PyOpenSSL.

HTH,

JJK

Thanks for the pointer! Python?s standard ssl module doesn?t expose that callback (yet), and I?d rather not switch everything to PyOpenSSL, but I?ll see what I can do.
Cheers,
Steven.



This email is confidential. If you are not the intended recipient, please advise us immediately and delete this message. 
The registered name of Cantab- part of GAM Systematic is Cantab Capital Partners LLP. 
See - http://www.gam.com/en/Legal/Email+disclosures+EU for further information on confidentiality, the risks of non-secure electronic communication, and certain disclosures which we are required to make in accordance with applicable legislation and regulations. 
If you cannot access this link, please notify us by reply message and we will send the contents to you.

GAM Holding AG and its subsidiaries (Cantab ? GAM Systematic) will collect and use information about you in the course of your interactions with us. 
Full details about the data types we collect and what we use this for and your related rights is set out in our online privacy policy at https://www.gam.com/en/legal/privacy-policy. 
Please familiarise yourself with this policy and check it from time to time for updates as it supplements this notice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190117/a8df1418/attachment-0001.html>

From openssl-users at dukhovni.org  Thu Jan 17 18:17:10 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 17 Jan 2019 13:17:10 -0500
Subject: [openssl-users] Get peer certificate after handshake failure
In-Reply-To: <E9FA92C2921F31408041863B74EE4C2001BD2F8D92@CCPMAILDAG03.cantab.local>
References: <7qrmrnett1l4ulgi5hy45rl3.1547739068530@email.android.com>
 <E9FA92C2921F31408041863B74EE4C2001BD2F8D92@CCPMAILDAG03.cantab.local>
Message-ID: <20190117181710.GQ79754@straasha.imrryr.org>

On Thu, Jan 17, 2019 at 05:39:39PM +0000, Steven Winfield wrote:

> TL;DR: After a failed handshake, caused by our peer?s certificate failing
> verification, what is the correct way to get hold of the peer?s certificate?

You can't get it after, but you can get it *during* the handshake, by
implementing a "verify callback".

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


From cfernando at alteryx.com  Thu Jan 17 18:29:21 2019
From: cfernando at alteryx.com (Chris Fernando)
Date: Thu, 17 Jan 2019 18:29:21 +0000
Subject: [openssl-users] Compiling FIPS-cable OpenSSL on
	Windows	Server	2012R2
In-Reply-To: <CF9431BA-641B-4CCA-8E5E-863F050E8AF2@alteryx.com>
References: <8B308719-0560-4E2C-A53E-51DF3C21BE0B@alteryx.com>
 <CF9431BA-641B-4CCA-8E5E-863F050E8AF2@alteryx.com>
Message-ID: <CA69BD8D-613A-4799-B55E-E9F1E04FA5D9@alteryx.com>

> On Jan 7, 2019, at 11:52, Chris Fernando via openssl-users <openssl-users at openssl.org> wrote:
> 
>> 
>> On Jan 7, 2019, at 09:20, Chris Fernando via openssl-users <openssl-users at openssl.org> wrote:
>> 
>> I perused the list archives for all of 2018 and did not see anything current relating to this problem, so if this is a question that has been asked & answered, please feel free to point me at the relevant location to read about what I'm doing incorrectly. =)
>> 
>> I'm not at all familiar with Windows & compiling Open Source projects, but I am having no trouble on Linux with OpenSSL + FIPS. On Windows, with Visual Studio 2017 (Community Edition), I am able to compile the FIPS 2.0.16 module and OpenSSL 1.0.2q (NO FIPS) without issue.
>> 
>> [snip]
>> 
>> 
>> I am doing the following to compile FIPS:
>> cd c:\path\to\fips-source
>> ms\do_fips no-asm
>> 
>> I am doing the following to compile OpenSSL+FIPS (Strawberry Perl installed):
>> cd c:\path\to\openssl-source
>> nmake -f ms\ntdll.mak clean
>> nmake -f ms\nt.mak clean
>> perl Configure VC-WIN64A fips no-asm --with-fipsdir=c:\path\to\fips-source
>> ms\do_win64a no-asm
>> nmake -f ms\ntdll.mak
>> 
>> [snip]
> 
> 
> Well, I managed to get the compile to move a bit further by copying "inc32" to "include", "util" to "bin", and "out32dll" to "lib" in the FIPS source directory, that I was including in --with-fipsdir= .
> 
> However, now I am getting the following error during the OpenSSL build process.
> 
> [snip]

So, for anyone searching in the future, I managed to get it to compile ensuring the following:

Ensure the following is installed:
 * Perl (I used Strawberry Perl 5.24.4.1)
 * NASM (I used 2.14.02)
 * MS Visual Studio 2017 Community with the MS Windows SDK (what I used)

- Ensure your Windows PATH variable has NASM and Perl included (not including this is what was causing my errors).
- Start the Visual Studio 'Developer Command Prompt'.
- Change directory to the decompressed openssl source directory.
- Follow the instructions in the OpenSSL FIPS User Guide. I had to ensure '--with-fipsdir=' pointed to where my FIPS object code was installed. It was, purposefully, not in C:\usr\local\ssl\fips-2.0\, which was also causing problems for me.

I appreciate those who reached out to me directly to provide guidance in solving my compile issues.

Thanks,

Chris




From hkario at redhat.com  Thu Jan 17 20:20:37 2019
From: hkario at redhat.com (Hubert Kario)
Date: Thu, 17 Jan 2019 21:20:37 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <4965ac04-0b8c-db50-0c20-a7418f36759b@ofcourseimright.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <5163262.KKx49qeQVV@pintsize.usersys.redhat.com>
 <4965ac04-0b8c-db50-0c20-a7418f36759b@ofcourseimright.com>
Message-ID: <2437700.lTpqg6aPhl@pintsize.usersys.redhat.com>

On Thursday, 17 January 2019 18:03:55 CET Eliot Lear wrote:
> On 17.01.19 17:29, Hubert Kario wrote:
> > alternatively, you can save all the certificates and revocation data, bind
> > it to the original signature using a timestamp from a TSA and store that
> > (that's necessary if you want to be able to prove to some 3rd party that
> > you received a correctly signed document/message at that time)
> > 
> > but that is very close to reimplementing CAdES, or related standards, and
> > is far from simple (for one, requires adding, regularly, new timestamps
> > to extend validity of the original signature and subsequent timestamps)
> 
> Right.  There are a lot of trust challenges around the timestamp. 
> Because there are multiple non-cooperating entities involved, the signer
> is not in a position to predict who the recipients will trust, and the
> recipients may be retrieving the information later.  This is not a
> simple matter.
> 
> What's more, we're not in a position to provide meaningful programmatic
> diagnostic info in this case because CMS is calling X.509 codes, and so
> ERR_get_err has a little issue when multiple libraries are in play.  And
> while nobody likes to hear, ?I'll just bypass this one thing?, as a
> matter of practicality we want to provide the application user (in this
> case an administrator) a choice of what to do with as much information
> as possible.

then I'd say that showing the date from within the signature will be more 
confusing than helpful to the administrator

-- 
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/20190117/61d400a4/attachment.sig>

From dclarke at blastwave.org  Thu Jan 17 23:23:11 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Thu, 17 Jan 2019 18:23:11 -0500
Subject: [openssl-users] crypto/objects/o_names.c problem with Solaris 10
 and strict Oracle Studio 12.6 c99
Message-ID: <e199d9d0-b5f6-2fac-631f-046a0f5ae9b4@blastwave.org>


Fairly sure I did not run into all these issues with 1.1.1 on the exact
same systems but regardless here we are.  I *know* that I tested every
one of the 'pre' testing versions and have 1.1.1 running fine just about
everywhere.  So here goes the long story with ye strict C99 compiler :

$ env | sort
CC=/opt/developerstudio12.6/bin/c99
CFLAGS=-m64 -xarch=sparc -g -Xc -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 
-xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1
COLUMNS=132
CPPFLAGS=-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -D_TS_ERRNO
CXX=/opt/developerstudio12.6/bin/CC
HOME=/export/home/dclarke
LD_OPTIONS=-R/usr/local/lib -L/usr/local/lib
LD_RUN_PATH=/usr/local/lib
LINES=43
LOGNAME=dclarke
MAIL=/var/mail//dclarke
OPENSSL_SOURCE=/usr/local/build/openssl-1.1.1a_SunOS5.10_sparc64vii+.001
PATH=/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/opt/developerstudio12.6/bin:/sbin:/bin:/usr/bin:/usr/sbin
PERL=/usr/local/bin/perl
PWD=/usr/local/build/openssl-1.1.1a_SunOS5.10_sparc64vii+.003
SSH_CLIENT=66.225.151.244 39653 22
SSH_CONNECTION=66.225.151.244 39653 68.179.116.204 22
SSH_TTY=/dev/pts/6
TERM=vt100
TMPDIR=/var/tmp/dclarke
TZ=GMT0
USER=dclarke
_=/usr/xpg4/bin/env



Here we need to modify Configurations/10-main.conf to insert those
CFLAGS for solaris64-sparcv9-cc as well as a few other minor tweaks :


#### Solaris configurations
     "solaris-common" => {
         inherit_from     => [ "BASE_unix" ],
         template         => 1,
         lib_cppflags     => "-DFILIO_H",
         ex_libs          => add("-lsocket -lnsl -ldl -lrt"),
         dso_scheme       => "dlfcn",
         thread_scheme    => "pthreads",
         shared_target    => "self",
         shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)",
         shared_ldflag    => "-Wl,-Bsymbolic",
         shared_defflag   => "-Wl,-M,",
         shared_sonameflag=> "-Wl,-h,",
     },

See ex_libs?  We need -lrt due to a call to a time function embedded
somewhere in the mixture and the easy solution is just add -lrt there.

Really this is a bug that should be filed but I can come back to that.

Now go down to the Solaris with Sun C setups and maybe change that
to "Solaris with Oracle Studio C" setups because it has been almost
a decade.  I want a debug release with all the required symbols and
not stripped.  So let's remove the optimization entirely at line 331
and just have this :


#### SPARC Solaris with Sun C setups
# SC4.0 doesn't pass 'make test', upgrade to SC5.0 or SC4.2.
# SC4.2 is ok, better than gcc even on bn as long as you tell it -xarch=v8
# SC5.0 note: Compiler common patch 107357-01 or later is required!
     "solaris-sparcv7-cc" => {
         inherit_from     => [ "solaris-common" ],
         CC               => "cc",
         CFLAGS           => add_before(picker(debug   => "-g",
                                               release => "-g -xdepend")),
         cflags           => add_before("-xstrconst -Xa"),
         cppflags         => add(threads("-D_REENTRANT")),
         lib_cppflags     => add("-DB_ENDIAN -DBN_DIV2W"),
         lflags           => add(threads("-mt")),
         ex_libs          => add(threads("-lpthread")),
         bn_ops           => "BN_LLONG RC4_CHAR",
         shared_cflag     => "-KPIC",
         shared_ldflag    => add_before("-G -dy -z text"),
     },

Now then, onwards to line 350 or so where we finally find the section 
just for solaris64-sparcv9-cc and here we need to throw away that old 
deprecated -xarch flag and insert the whole long string :


     "solaris64-sparcv9-cc" => {
         inherit_from     => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
         cflags           => add_before("-m64 -xarch=sparc -g -Xc 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff -xme
malign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -xbuiltin=%none -xunroll=1"),
         bn_ops           => "BN_LLONG RC4_CHAR",
         multilib         => "/64",
     },

That works.

We end up with :

corv $ diff -c ./Configurations/10-main.conf.orig 
./Configurations/10-main.conf
*** ./Configurations/10-main.conf.orig  Tue Nov 20 13:35:37 2018
--- ./Configurations/10-main.conf       Thu Jan 17 22:24:56 2019
***************
*** 208,214 ****
           inherit_from     => [ "BASE_unix" ],
           template         => 1,
           lib_cppflags     => "-DFILIO_H",
!         ex_libs          => add("-lsocket -lnsl -ldl"),
           dso_scheme       => "dlfcn",
           thread_scheme    => "pthreads",
           shared_target    => "self",
--- 208,214 ----
           inherit_from     => [ "BASE_unix" ],
           template         => 1,
           lib_cppflags     => "-DFILIO_H",
!         ex_libs          => add("-lsocket -lnsl -ldl -lrt"),
           dso_scheme       => "dlfcn",
           thread_scheme    => "pthreads",
           shared_target    => "self",
***************
*** 328,334 ****
           inherit_from     => [ "solaris-common" ],
           CC               => "cc",
           CFLAGS           => add_before(picker(debug   => "-g",
!                                               release => "-xO5 
-xdepend")),
           cflags           => add_before("-xstrconst -Xa"),
           cppflags         => add(threads("-D_REENTRANT")),
           lib_cppflags     => add("-DB_ENDIAN -DBN_DIV2W"),
--- 328,334 ----
           inherit_from     => [ "solaris-common" ],
           CC               => "cc",
           CFLAGS           => add_before(picker(debug   => "-g",
!                                               release => "-g -xdepend")),
           cflags           => add_before("-xstrconst -Xa"),
           cppflags         => add(threads("-D_REENTRANT")),
           lib_cppflags     => add("-DB_ENDIAN -DBN_DIV2W"),
***************
*** 349,355 ****
       },
       "solaris64-sparcv9-cc" => {
           inherit_from     => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
!         cflags           => add_before("-xarch=v9"),
           bn_ops           => "BN_LLONG RC4_CHAR",
           multilib         => "/64",
       },
--- 349,355 ----
       },
       "solaris64-sparcv9-cc" => {
           inherit_from     => [ "solaris-sparcv7-cc", asm("sparcv9_asm") ],
!         cflags           => add_before("-m64 -xarch=sparc -g -Xc 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff 
-xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -xbuiltin=%none -xunroll=1"),
           bn_ops           => "BN_LLONG RC4_CHAR",
           multilib         => "/64",
       },
corv $

Now then nothing works on the old Solaris world without an up to date
perl or at least something not covered in moss and dust thus :

corv $ /usr/local/bin/perl -V | head -1
Summary of my perl5 (revision 5 version 26 subversion 1) configuration:
corv $

Recall that we are going to try strict C99 compliance mode here
therefore CC=/opt/developerstudio12.6/bin/c99 :

corv $ /usr/local/bin/perl ./Configure solaris64-sparcv9-cc 2>&1 | tee 
../openssl-1.1.1a_SunOS5.10_sparc64vii+.003.config.log
Configuring OpenSSL version 1.1.1a (0x1010101fL) for solaris64-sparcv9-cc
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)         ***
***                                                                ***
**********************************************************************
corv $

If one tries to view or edit the Makefile then Oracle Solaris 'vi' blows
up because the line length explodes the buffers.  One must use 'vim' or
similar.  Yet another feature of an old old old operating system.  Even
on brand new shiney sparc hardware from Oracle.

Thankfully the Makefile says :

CROSS_COMPILE=
CC=$(CROSS_COMPILE)/opt/developerstudio12.6/bin/c99

CPPFLAGS=-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -D_TS_ERRNO
CFLAGS=-m64 -xarch=sparc -g -Xc -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32
  -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1

PERL=/usr/local/bin/perl


##### Project flags ##################################################

# Variables starting with CNF_ are common variables for all product types

CNF_CPPFLAGS=-D_REENTRANT -DNDEBUG
CNF_CFLAGS=-m64 -xarch=sparc -g -Xc -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=p
ic32 -xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none 
-xunroll=1 -xstrconst -Xa
CNF_CXXFLAGS=
CNF_LDFLAGS=-mt
CNF_EX_LIBS=-lsocket -lnsl -ldl -lrt -lpthread

We should be okay here.


corv $ echo $PATH
/usr/xpg6/bin:/usr/xpg4/bin:/usr/ccs/bin:/opt/developerstudio12.6/bin:/sbin:/bin:/usr/bin:/usr/sbin
corv $ /usr/xpg4/bin/date '+%Y%m%d%H%M%S'
20190117224215
corv $ /usr/bin/time -p /usr/local/bin/gmake
.
.
.
/opt/developerstudio12.6/bin/c99  -I. -Icrypto/include -Iinclude -KPIC 
-m64 -xarch=sparc -g -Xc -errfmt=error -erroff=%none -errshort=full 
-xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -xstrconst -Xa 
-m64 -xarch=sparc -g -Xc -errfmt=error -erroff=%none -errshort=full 
-xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl 
-xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 -DFILIO_H 
-DB_ENDIAN -DBN_DIV2W -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -D_REENTRANT -DNDEBUG 
-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
-D_TS_ERRNO  -c -o crypto/objects/o_names.o crypto/objects/o_names.c
"crypto/objects/o_names.c", line 114: error: undefined symbol: strcasecmp
"crypto/objects/o_names.c", line 114: warning: improper pointer/integer 
combination: op "="
"crypto/objects/o_names.c", line 151: warning: implicit function 
declaration: strcasecmp
c99: acomp failed for crypto/objects/o_names.c
gmake[1]: *** [Makefile:1642: crypto/objects/o_names.o] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1a_SunOS5.10_sparc64vii+.003'
gmake: *** [Makefile:169: all] Error 2

real 513.85
user 408.84
sys 160.27
corv $

Sure enough we see :

    104      for (i = sk_NAME_FUNCS_num(name_funcs_stack); i < 
names_type_num; i++) {
    105          CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE);
    106          name_funcs = OPENSSL_zalloc(sizeof(*name_funcs));
    107          CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ENABLE);
    108          if (name_funcs == NULL) {
    109              OBJerr(OBJ_F_OBJ_NAME_NEW_INDEX, ERR_R_MALLOC_FAILURE);
    110              ret = 0;
    111              goto out;
    112          }
    113          name_funcs->hash_func = openssl_lh_strcasehash;
    114          name_funcs->cmp_func = obj_strcasecmp;
    115          CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE);
    116
    117          push = sk_NAME_FUNCS_push(name_funcs_stack, name_funcs);
    118          CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ENABLE);
    119
    120          if (!push) {
    121              OBJerr(OBJ_F_OBJ_NAME_NEW_INDEX, ERR_R_MALLOC_FAILURE);
    122              OPENSSL_free(name_funcs);
    123              ret = 0;
    124              goto out;
    125          }
    126      }

Well what is "obj_strcasecmp" ?

     24  /*
     25   * We define this wrapper for two reasons. Firstly, later 
versions of
     26   * DEC C add linkage information to certain functions, which 
makes it
     27   * tricky to use them as values to regular function pointers.
     28   * Secondly, in the EDK2 build environment, the strcasecmp 
function is
     29   * actually an external function with the Microsoft ABI, so we 
can't
     30   * transparently assign function pointers to it.
     31   */
     32  #if defined(OPENSSL_SYS_VMS_DECC) || defined(OPENSSL_SYS_UEFI)
     33  static int obj_strcasecmp(const char *a, const char *b)
     34  {
     35      return strcasecmp(a, b);
     36  }
     37  #else
     38  #define obj_strcasecmp strcasecmp
     39  #endif
     40

More historical computing perhaps.  I know that I can not recall the
last time I had seen a DEC system running but the OPENSSL_SYS_UEFI looks
suspect to me. At the very least it is a more modern idea.  I just want
a trivial tweak here to test "normal" strcasecmp :

corv $ diff -c crypto/objects/o_names.c.orig crypto/objects/o_names.c
*** crypto/objects/o_names.c.orig       Tue Nov 20 13:35:38 2018
--- crypto/objects/o_names.c    Thu Jan 17 23:03:44 2019
***************
*** 10,16 ****
   #include <stdio.h>
   #include <stdlib.h>
   #include <string.h>
!
   #include <openssl/err.h>
   #include <openssl/lhash.h>
   #include <openssl/objects.h>
--- 10,16 ----
   #include <stdio.h>
   #include <stdlib.h>
   #include <string.h>
! #include <strings.h>
   #include <openssl/err.h>
   #include <openssl/lhash.h>
   #include <openssl/objects.h>
***************
*** 111,117 ****
               goto out;
           }
           name_funcs->hash_func = openssl_lh_strcasehash;
!         name_funcs->cmp_func = obj_strcasecmp;
           CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE);

           push = sk_NAME_FUNCS_push(name_funcs_stack, name_funcs);
--- 111,117 ----
               goto out;
           }
           name_funcs->hash_func = openssl_lh_strcasehash;
!         name_funcs->cmp_func = strcasecmp;
           CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE);

           push = sk_NAME_FUNCS_push(name_funcs_stack, name_funcs);
corv $

Manually trying a very verbose compile of just that one file puts me 
back in a loop and I find this to be odd at the very least :

corv $
corv $ $CC $CFLAGS -I. -Icrypto/include -Iinclude -KPIC \
 > -DFILIO_H -DB_ENDIAN -DBN_DIV2W -DOPENSSL_PIC \
 > -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT \
 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM \
 > -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM \
 > -DECP_NISTZ256_ASM -DPOLY1305_ASM \
 > -DOPENSSLDIR="\"/usr/local/ssl\"" \
 > -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" \
 > -D_REENTRANT -DNDEBUG -I/usr/local/include \
 > -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE \
 > -D_TS_ERRNO \
 > -H -\# -c -o crypto/objects/o_names.o \
 > crypto/objects/o_names.c
### c99: Note: NLSPATH = 
/opt/developerstudio12.6/bin/../lib/locale/%L/LC_MESSAGES/%N.cat:/opt/developerstudio12.6/bin/../../lib/locale/%L/LC_MESSAGES/%N.cat
### c99: Note: TMPDIR = /var/tmp/dclarke
###     command line files and options (expanded):
### -m64 -xarch=sparc 
-xdebuginfo=line,param,variable,tagtype,codetag,decl -xglobalize=yes 
-xpatchpadding=fix -xkeep_unref=funcs,vars -Xc -errfmt=error 
-erroff=%none -errshort=full -xstrconst -xmemalign=8s -xnolibmil 
-xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 
-I. -Icrypto/include -Iinclude -xcode=pic32 -DFILIO_H -DB_ENDIAN 
-DBN_DIV2W -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" 
-D_REENTRANT -DNDEBUG -I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS 
-D_LARGEFILE64_SOURCE -D_TS_ERRNO -H -# -c -ocrypto/objects/o_names.o 
crypto/objects/o_names.c
/opt/developerstudio12.6/lib/compilers/bin/acomp -DFILIO_H -DB_ENDIAN 
-DBN_DIV2W -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT 
-DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
-DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM 
-DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" 
-D_REENTRANT -DNDEBUG -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
-D_TS_ERRNO -H -Qy -Xc -xc99=%all 
-features=no%mergestrings,extinl,no%typeof,no%extensions,conststrings,no%zla,no%iddollar,no%gcc_enums 
-i crypto/objects/o_names.c -D__SunOS_5_10 -D__SunOS_RELEASE=0x051000 
-D__SUNPRO_C=0x5150 -D__unix -D__SVR4__ -D__svr4__ -D__SVR4 -D__sun 
-D__sun__ -D__SunOS -D__sparcv9 -D__sparc_v9__ -D__sparc -D__sparc__ 
-D_LP64 -D__LP64__ -D__arch64__ -D__ORDER_LITTLE_ENDIAN__=1234 
-D__ORDER_BIG_ENDIAN__=4321 -D__BYTE_ORDER__=__ORDER_BIG_ENDIAN__ 
-D__BUILTIN_VA_ARG_INCR -D__C99FEATURES__ -D__PRAGMA_REDEFINE_EXTNAME 
-D__FLT_EVAL_METHOD__=0 -D__SUN_PREFETCH -I. -Icrypto/include -Iinclude 
-I/usr/local/include -I-xbuiltin 
-I/opt/developerstudio12.6/lib/compilers/include/cc -I/usr/xpg6/include 
-I/usr/xpg4/include -2K -errfmt=error -erroff=%none -errshort=full 
-errwarn=E_CANT_ACCESS_INCLUDE_DIR -xwarn_include_dir=permission 
-xbuiltin=%none -strconst -fsimple=0 -m64 -fparam_ir -fparam_ir 
-xglobalize=yes -xdebuginfo=line,param,variable,tagtype,codetag,decl 
-xkeep_unref=funcs,vars -xF=%none 
-xdbggen=dwarf+usedonly+incl+line+param+variable+tagtype+codetag+decl 
-xldscope=global -xivdep=loop -xanalyze=code -c99OS 
"-g/opt/developerstudio12.6/bin/c99 -m64 -xarch=sparc -g -Xc 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff 
-xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -xbuiltin=%none -xunroll=1 -I. -Icrypto/include -Iinclude 
-KPIC -DFILIO_H -DB_ENDIAN -DBN_DIV2W -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ 
-DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM 
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM 
-DPOLY1305_ASM -DOPENSSLDIR='"/usr/local/ssl"' 
-DENGINESDIR='"/usr/local/lib/engines-1.1"' -D_REENTRANT -DNDEBUG 
-I/usr/local/include -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE 
-D_TS_ERRNO -H -c " -destination_ir=iropt -r 
/var/tmp/dclarke/acomp.1547766424.13382.01.ir
/usr/include/stdio.h
         /usr/include/sys/feature_tests.h
                 /usr/include/sys/ccompile.h
                 /usr/include/sys/isa_defs.h
         /usr/include/iso/stdio_iso.h
                 /usr/include/sys/va_list.h
                 /usr/include/stdio_tag.h
                 /usr/include/stdio_impl.h
         /usr/include/iso/stdio_c99.h
/usr/include/stdlib.h
         /usr/include/iso/stdlib_iso.h
         /usr/include/iso/stdlib_c99.h
/usr/include/string.h
         /usr/include/iso/string_iso.h
/usr/include/strings.h
         /usr/include/sys/types.h
                 /usr/include/sys/machtypes.h
                 /usr/include/sys/int_types.h
                 /usr/include/sys/select.h
                         /usr/include/sys/time_impl.h
                         /usr/include/sys/time.h
                                 /usr/include/sys/types.h
                                 /usr/include/time.h
                                         /usr/include/iso/time_iso.h
                                 /usr/include/sys/select.h
include/openssl/err.h
         include/openssl/e_os2.h
                 include/openssl/opensslconf.h
                         include/openssl/opensslv.h
                 /usr/include/inttypes.h
                         /usr/include/sys/inttypes.h
                                 /usr/include/sys/int_limits.h
                                 /usr/include/sys/int_const.h
                                 /usr/include/sys/int_fmtio.h
                         /usr/include/sys/stdint.h
         include/openssl/ossl_typ.h
                 /usr/include/limits.h
                         /usr/include/iso/limits_iso.h
         include/openssl/bio.h
                 /usr/include/stdarg.h
                         /usr/include/iso/stdarg_iso.h
                                 /usr/include/sys/va_impl.h
                         /usr/include/iso/stdarg_c99.h
                 include/openssl/crypto.h
                         include/openssl/safestack.h
                                 include/openssl/stack.h
                         include/openssl/opensslconf.h
                         include/openssl/cryptoerr.h
                                 include/openssl/symhacks.h
                         /usr/include/pthread.h
                                 /usr/include/sched.h
                 include/openssl/bioerr.h
         include/openssl/lhash.h
         /usr/include/errno.h
                 /usr/include/sys/errno.h
include/openssl/objects.h
         include/openssl/obj_mac.h
         include/openssl/asn1.h
                 include/openssl/opensslconf.h
                 include/openssl/asn1err.h
                 include/openssl/bn.h
                         include/openssl/opensslconf.h
                         include/openssl/bnerr.h
         include/openssl/objectserr.h
include/internal/thread_once.h
crypto/include/internal/lhash.h
crypto/objects/obj_lcl.h
./e_os.h
         include/openssl/opensslconf.h
         include/internal/nelem.h
         /usr/include/unistd.h
                 /usr/include/sys/unistd.h
"crypto/objects/o_names.c", line 114: error: undefined symbol: strcasecmp
"crypto/objects/o_names.c", line 114: warning: improper pointer/integer 
combination: op "="
"crypto/objects/o_names.c", line 151: warning: implicit function 
declaration: strcasecmp
c99: acomp failed for crypto/objects/o_names.c
corv $

The beauty of that flag -H is simply to show every header file involved.
So would love to hear someones thoughts on why strcasecmp suddenly went
missing?

Dennis

ps: even looking through the pre-processed source I see only two lines
     with strcasecmp so I am guessing the real issue is the horrific
     monster typedef struct name_funcs_st NAME_FUNCS;

From openssl at jordan.maileater.net  Fri Jan 18 01:33:20 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Fri, 18 Jan 2019 01:33:20 +0000
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
Message-ID: <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>

On 1/14/2019 4:09 AM, Matt Caswell wrote:
> This works more "by accident". There is no ciphersuite alias called
> "TLSv1.3", so using it as above results in no ciphersuites matched.
> Since the TLSv1.3 ciphersuites are on by default anyway that's all
> that you get back.


>From what you say, and based on experimentation, it seems like the
TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them.

    $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384
    *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]

    $ openssl ciphers AES:-SHA384
    *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]

That doesn't seem right.? Am I missing something?

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

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

From Michael.Wojcik at microfocus.com  Fri Jan 18 01:25:10 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 18 Jan 2019 01:25:10 +0000
Subject: [openssl-users] crypto/objects/o_names.c problem with Solaris
 10 and strict Oracle Studio 12.6 c99
In-Reply-To: <e199d9d0-b5f6-2fac-631f-046a0f5ae9b4@blastwave.org>
References: <e199d9d0-b5f6-2fac-631f-046a0f5ae9b4@blastwave.org>
Message-ID: <MW2PR18MB2090107A46C37015C6F496E3F99C0@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Dennis Clarke
> Sent: Thursday, January 17, 2019 18:23
>
> "crypto/objects/o_names.c", line 114: error: undefined symbol: strcasecmp
> "crypto/objects/o_names.c", line 114: warning: improper pointer/integer
> combination: op "="
> "crypto/objects/o_names.c", line 151: warning: implicit function
> declaration: strcasecmp

Note the issue here is an undefined symbol, which consequently has an implicit definition as an int with external linkage and static duration. So we're talking about a header problem, not a library problem.

> So would love to hear someones thoughts on why strcasecmp suddenly went
> missing?

Well...

strcasecmp is a heresy. The C specification (ISO 9899) does not include strcasecmp, and reserves all identifiers with external linkage beginning with "str" for the library.

The *correct* way to do case-insensitive string comparisons in C is to write your own using the ctype.h functions (though it's tricky to get this right, due to the signed-char Undefined Behavior problem), with a name that doesn't infringe on a reserved part of the namespace. Or use a library which provides the same.

Unfortunately, strcasecmp was invented before C was standardized (as part of the BSD 4.something implementation, maybe?), and consequently gained too much traction to ever go away. Then it was standardized by XPG4, just to make things more difficult. And thus it's part of the Single UNIX Specification, even though the SUS has language about not conflicting with ISO 9899. Everyone just looks the other way and whistles quietly to themselves when they come across it.

*Consequently*, under Open Group Base Specifications Issue 7 (the latest version of SUS), to get a definition for strcasecmp you have to include <strings.h>. Note the second "s". <string.h> is the ISO C header for things like strcmp; <strings.h> is the SUS header for strcasecmp and other look-like-standard-C-but-aren't string functions. There's no way anyone would ever confuse the two.

Normally, the Solaris headers (at least for 10.2, which is what I'm logged into at the moment) include string.h in strings.h and vice versa, to hide this abomination from the eyes of the innocent. But those inclusions are wrapped in all manner of ifdeffery which I am not about to try to untangle.

Now, we see in the output you included in your note that you are getting strings.h in o_names.c. So that should be OK, yes?

But of course the declaration of strcasecmp in strings.h is itself ifdeffed. To get it, _XPG4_2 must be defined, and __EXTENSIONS__ must NOT be defined.

My guess is you're falling foul of one of those two conditions, when you compile in strict mode.

The simplest fix would be to whack a declaration of strcasecmp into the source file itself, but that's inelegant and hard to maintain - presumably you'd rather do something through the OpenSSL configure process. As for that, well... the only thing that comes to mind is something like:

1. Add -Dstrcasecmp=cmpstrci to the compiler flags
2. Add -lcmpstrci to the link flags
3. Create a little libcmpstrci.a (no need for it to be a shared object) with a case-insensitive string comparison function named cmpstrci. It can use strcasecmp if it must, or you can implement your own.

Or the problem might be something else, of course, but the fact that strings.h does appear in the output but strcasecmp isn't declared does suggest the conditional-compilation in strings.h is to blame.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From jb-openssl at wisemo.com  Fri Jan 18 04:45:11 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 18 Jan 2019 05:45:11 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <B6A8DC5E-2AA0-4958-A5EA-5989CFF7F05B@dukhovni.org>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <B6A8DC5E-2AA0-4958-A5EA-5989CFF7F05B@dukhovni.org>
Message-ID: <00f36cb1-5325-2550-ee2b-6aef46eb9df3@wisemo.com>

On 16/01/2019 21:25, Viktor Dukhovni wrote:
>> On Jan 15, 2019, at 10:29 AM, Eliot Lear <lear at ofcourseimright.com> wrote:
>>
>> I have an application that requires long-lived signatures, perhaps long
>> past the point where the signer's cert has expired.  I'd like a way to
>> extract the signature date from a CMS structure.  With all the opaque
>> structs that have been introduced in the last few releases, it's not
>> clear to me how to do that.  Any examples or guidance (other than don't
>> do that)?
> I doubt this has anything to do with opaque structures.  The real
> issue here is that IIRC CMS (previously known as PKCS7) has no
> signature date.  It just has to be signed data and a signature,
> with an X.509 certificate that has an expiration.

There is a commonly implemented extension (the signingTime
authenticated/signed attribute, RFC2985 section 5.3.3 and RFC2630 section
11.3) to store this.? Microsoft tools show this as the date of the
signature, separate from the date of any signed timestamp.

There are also at least 3 common non-authenticated/unsigned attributes
for storing time stamp results:

Option A: OID 1.2.840.113549.1.9.6: An RFC2985 section 5.3.6 (RFC2630
 ? section 11.4) countersignature where the countersigning certificate
 ? has the timestamping extended key usage and the countersignature has
 ? an authenticated/signed signingTime attribute. This form is used and
 ? expected by some Microsoft implementations, including backward
 ? compatible code signing.

Option B: OID 1.2.840.113549.1.9.16.2.14: As defined in RFC3161
 ? Appendix A.

Option C: OID 1.3.6.1.4.1.311.3.3.1: The value of this attribute
 ? is a SET OF TimeStampToken (where each TimeStampToken is as defined
 ? in RFC3161).? This form is used and expected by some Microsoft
 ? implementations, including current code signing features.

In all 3 forms, the timestamp signs the encryptedDigest/signature
 ? in the SignerInfo having the attribute.? The timestamp only
 ? authenticates the fact that the signature was made at or before
 ? the specified time, revocation information may be obtained and
 ? archived by the relying party (but contains its own timestamps
 ? and signatures).

Note: The dual naming above is because RFC2630 CMS changed the names
of various things relative to the otherwise identical definitions in
PKCS#7.? The 3 attributes are used with any version of CMS/PKCS#7,
including version 1.


>
> For long-term storage, the date of interest is NOT when the object
> was signed, but when it was received, verified and stored.  For
> that what you need is separate long-term integrity protection for
> the underlying object store, separate from the origin signatures
> on inbound objects, that need only be valid at time of import.
>
> Indeed with content that's also encrypted, you'll typically want
> to immediately decrypt it, decoupling it from a comparatively
> short-lived inbound encryption public key, and re-encrypt for
> storage under a key that is managed as part of the object store.
For encrypted e-mail there is an obvious source of the date when
the signed mail was locally stored (thus the signatures inside
must have been created before that).

This source is the reception/delivery timestamp recorded in the
mail headers by your local trusted mail server or by equivalent
code in your local POP3 client.? This of cause won't work with
an untrusted 3rd party hosted mail storage server, unless some
trust can be assigned to that server.

An important limitation is that some CAs prematurely discard
historic revocation information for mail certificates, and that
most mail clients and servers don't capture and store that
information.

> The na?ve model of using the signer and recipient keys as long-term
> verification and decryption keys is deeply flawed for data retention.
> This is a bit part of the reason why end-to-end email encryption has
> negligible adoption, the storage infrastructure to make it usable was
> never built.
>

As explained above, most of that storage infrastructure is in
fact in place, but the major e-mail clients lack the code to use
it.? For example the "openssl cms" command (used by some unix mail
clients, such as Mutt) doesn't have an option to specify the "as of"
date extracted from an external trusted source.? Nor does it have
an option to input a recorded OCSP response or CRL to be validated
and used according to that "as of" date.

A much bigger hindrance is the significant difficulty of finding
3rd party e-mail CA services, as those tend to be buried in weird
corners of CA sites or overly entangled with specific services
such as citizen ID for specific countries (typically allowing only
one non-secret e-mail address per person).? To clarify, I have found
at least one useful service, but it was by no means easy.


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 dclarke at blastwave.org  Fri Jan 18 04:56:23 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Thu, 17 Jan 2019 23:56:23 -0500
Subject: [openssl-users] crypto/objects/o_names.c problem with Solaris
 10 and strict Oracle Studio 12.6 c99
In-Reply-To: <MW2PR18MB2090107A46C37015C6F496E3F99C0@MW2PR18MB2090.namprd18.prod.outlook.com>
References: <e199d9d0-b5f6-2fac-631f-046a0f5ae9b4@blastwave.org>
 <MW2PR18MB2090107A46C37015C6F496E3F99C0@MW2PR18MB2090.namprd18.prod.outlook.com>
Message-ID: <83acecfd-5cf1-bac2-e7d8-c4f8f186d31a@blastwave.org>

On 1/17/19 8:25 PM, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
>> Dennis Clarke
>> Sent: Thursday, January 17, 2019 18:23
>>
>> "crypto/objects/o_names.c", line 114: error: undefined symbol: strcasecmp
>> "crypto/objects/o_names.c", line 114: warning: improper pointer/integer
>> combination: op "="
>> "crypto/objects/o_names.c", line 151: warning: implicit function
>> declaration: strcasecmp
> 
> Note the issue here is an undefined symbol, which consequently has an implicit definition as an int with external linkage and static duration. So we're talking about a header problem, not a library problem.
> 
>> So would love to hear someones thoughts on why strcasecmp suddenly went
>> missing?
> 
> Well...
> 
> strcasecmp is a heresy. 

Love it.

I knew something like this was in the air and I could smell it :-)

<snip>
> 
> But of course the declaration of strcasecmp in strings.h is itself ifdeffed. 
To get it, _XPG4_2 must be defined, and __EXTENSIONS__ must NOT be defined.

Full moon black cat ifdeffery crud here we go.

> 
> My guess is you're falling foul of one of those two conditions, when you compile in strict mode.
> 
> The simplest fix would be to whack a declaration of strcasecmp into the source file itself

Yeah .. that's icky.

> but that's inelegant and hard to maintain - presumably you'd rather do something through the OpenSSL configure process. As for that, well... the only thing that comes to mind is something like:
> 
> 1. Add -Dstrcasecmp=cmpstrci to the compiler flags
> 2. Add -lcmpstrci to the link flags
> 3. Create a little libcmpstrci.a (no need for it to be a shared object) with a case-insensitive string comparison function named cmpstrci. It can use strcasecmp if it must, or you can implement your own.
> 
> Or the problem might be something else, of course, but the fact that strings.h does appear in the output but strcasecmp isn't declared does suggest the conditional-compilation in strings.h is to blame.
> 

Thank you for the great reply where clearly you have seen ifdeffery
nonsense bite you.  I get caught between a rock and a hrd place here
every time because if I try to go with just ordinary cc and just some
transition loosey goosey not-really-compliant or strict CFLAGS then I
arrive in a different ugly place :


${LDCMD:-/opt/developerstudio12.6/bin/cc} -m64 -xarch=sparc -g -Xa 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff 
-xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -xbuiltin=%none -xunroll=1 -xstrconst -Xa -m64 -xarch=sparc 
-g -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff 
-xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -xbuiltin=%none -xunroll=1 -L. -mt  \
         -o test/rsa_complex test/rsa_complex.o \
          -lsocket -lnsl -ldl -lrt -lpthread
Undefined                       first referenced
  symbol                             in file
OPENSSL_sk_pop_free                 test/rsa_complex.o
OPENSSL_sk_dup                      test/rsa_complex.o
OPENSSL_sk_pop                      test/rsa_complex.o
OPENSSL_sk_num                      test/rsa_complex.o
OPENSSL_sk_new                      test/rsa_complex.o
OPENSSL_sk_set                      test/rsa_complex.o
OPENSSL_sk_free                     test/rsa_complex.o
OPENSSL_sk_find                     test/rsa_complex.o
OPENSSL_sk_push                     test/rsa_complex.o
OPENSSL_sk_sort                     test/rsa_complex.o
OPENSSL_sk_zero                     test/rsa_complex.o
OPENSSL_sk_is_sorted                test/rsa_complex.o
OPENSSL_sk_shift                    test/rsa_complex.o
OPENSSL_sk_value                    test/rsa_complex.o
OPENSSL_sk_delete_ptr               test/rsa_complex.o
OPENSSL_sk_unshift                  test/rsa_complex.o
OPENSSL_sk_new_null                 test/rsa_complex.o
OPENSSL_sk_set_cmp_func             test/rsa_complex.o
OPENSSL_sk_reserve                  test/rsa_complex.o
OPENSSL_sk_new_reserve              test/rsa_complex.o
OPENSSL_sk_delete                   test/rsa_complex.o
OPENSSL_sk_insert                   test/rsa_complex.o
OPENSSL_sk_deep_copy                test/rsa_complex.o
OPENSSL_sk_find_ex                  test/rsa_complex.o
ld: fatal: symbol referencing errors. No output written to test/rsa_complex
gmake[1]: *** [Makefile:3561: test/rsa_complex] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1a_SunOS5.10_sparc64vii+.004'
gmake: *** [Makefile:169: all] Error 2

Looks like getting a debug non-optimized library will be a major pain.

Dennis

From dclarke at blastwave.org  Fri Jan 18 06:05:08 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 18 Jan 2019 01:05:08 -0500
Subject: [openssl-users] compile hell : fatal: symbol referencing errors.
 OPENSSL_sk_pop_free etc etc etc
Message-ID: <548d6c68-3443-d5f8-3496-ed12cd7a774d@blastwave.org>


So it seems to no longer matter if I try strict C99 or just cc with or
without strict CFLAGS. I always arrive at the same place :

${LDCMD:-/opt/developerstudio12.6/bin/cc} -m64 -xarch=sparc -g -Xa 
-errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff 
-xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc 
-ftrap=%none -xbuiltin=%none -xunroll=1 -Qy -xdebugformat=dwarf 
-xstrconst -Xa -m64 -xarch=sparc -g -Xa -errfmt=error -erroff=%none 
-errshort=full -xstrconst -xildoff -xmemalign=8s -xnolibmil -xcode=pic32 
-xregs=no%appl -xlibmieee -mc -ftrap=%none -xbuiltin=%none -xunroll=1 
-Qy -xdebugformat=dwarf -L. -mt  \
         -o test/rsa_complex test/rsa_complex.o \
          -lsocket -lnsl -ldl -lrt -lpthread
cc: Warning: multiple use of -Q option, previous one discarded.
Undefined                       first referenced
  symbol                             in file
OPENSSL_sk_pop_free                 test/rsa_complex.o
OPENSSL_sk_dup                      test/rsa_complex.o
OPENSSL_sk_pop                      test/rsa_complex.o
OPENSSL_sk_num                      test/rsa_complex.o
OPENSSL_sk_new                      test/rsa_complex.o
OPENSSL_sk_set                      test/rsa_complex.o
OPENSSL_sk_free                     test/rsa_complex.o
OPENSSL_sk_find                     test/rsa_complex.o
OPENSSL_sk_push                     test/rsa_complex.o
OPENSSL_sk_sort                     test/rsa_complex.o
OPENSSL_sk_zero                     test/rsa_complex.o
OPENSSL_sk_is_sorted                test/rsa_complex.o
OPENSSL_sk_shift                    test/rsa_complex.o
OPENSSL_sk_value                    test/rsa_complex.o
OPENSSL_sk_delete_ptr               test/rsa_complex.o
OPENSSL_sk_unshift                  test/rsa_complex.o
OPENSSL_sk_new_null                 test/rsa_complex.o
OPENSSL_sk_set_cmp_func             test/rsa_complex.o
OPENSSL_sk_reserve                  test/rsa_complex.o
OPENSSL_sk_new_reserve              test/rsa_complex.o
OPENSSL_sk_delete                   test/rsa_complex.o
OPENSSL_sk_insert                   test/rsa_complex.o
OPENSSL_sk_deep_copy                test/rsa_complex.o
OPENSSL_sk_find_ex                  test/rsa_complex.o
ld: fatal: symbol referencing errors. No output written to test/rsa_complex
gmake[1]: *** [Makefile:3561: test/rsa_complex] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1a_SunOS5.10_sparc64vii+.005'
gmake: *** [Makefile:169: all] Error 2

corv $

Attempts to use C99 and strict CFLAGS simply falls into a hell with some
oddball strcmpcase function issue regardless if I use strings.h or not
so let's just stay here and try to figure out what do I need to do to
get a debug non-stripped and not optimized build out of 1.1.1a?

Certainly did not have these issues with 1.1.1 or any of the pre-release
versions. Not that I recall.

So .. any thoughts?

Dennis

From dclarke at blastwave.org  Fri Jan 18 06:53:08 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 18 Jan 2019 01:53:08 -0500
Subject: [openssl-users] Dealing with RFC2553 and RFC3493 where NI_MAXHOST
 and NI_MAXSERV no longer exist
Message-ID: <5d844b74-2f1c-45cc-5368-09c4c29c2068@blastwave.org>


Going in circles trying to compile 1.1.1a with strict C99 and no
optimizations and with a ready to debug and single step resultant
library.  Ran headlong into crypto/bio/b_addr.c where we see :

    176  /*-
    177   * addr_strings - helper function to get host and service names
    178   * @ap: the BIO_ADDR that has the input info
    179   * @numeric: 0 if actual names should be returned, 1 if the numeric
    180   * representation should be returned.
    181   * @hostname: a pointer to a pointer to a memory area to store the
    182   * host name or numeric representation.  Unused if NULL.
    183   * @service: a pointer to a pointer to a memory area to store the
    184   * service name or numeric representation.  Unused if NULL.
    185   *
    186   * The return value is 0 on failure, with the error code in the 
error
    187   * stack, and 1 on success.
    188   */
    189  static int addr_strings(const BIO_ADDR *ap, int numeric,
    190                          char **hostname, char **service)
    191  {
    192      if (BIO_sock_init() != 1)
    193          return 0;
    194
    195      if (1) {
    196  #ifdef AI_PASSIVE
    197          int ret = 0;
    198          char host[NI_MAXHOST] = "", serv[NI_MAXSERV] = "";
    199          int flags = 0;
    200
.
.
.

Where we see NI_MAXHOST and NI_MAXSERV used however those did exist in 
RFC2553 and then were removed in RFC3493 and thus strict C99 halts in a 
noisey way unless __EXTENSIONS__ is defined.

"crypto/bio/b_addr.c", line 198: error: undefined symbol: NI_MAXHOST
"crypto/bio/b_addr.c", line 198: error: variable length array can not be 
initialized: host
"crypto/bio/b_addr.c", line 198: error: undefined symbol: NI_MAXSERV
"crypto/bio/b_addr.c", line 198: error: variable length array can not be 
initialized: serv
c99: acomp failed for crypto/bio/b_addr.c

Right.

If I attempt to use "extensions" and other things then this compiles
just fine and the process fails in other places.  For now, however, the
values NI_MAXHOST and NI_MAXSERV don't really exist in netdb.h as
far as I can see.

Dennis

From lear at ofcourseimright.com  Fri Jan 18 07:09:00 2019
From: lear at ofcourseimright.com (Eliot Lear)
Date: Fri, 18 Jan 2019 08:09:00 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <2437700.lTpqg6aPhl@pintsize.usersys.redhat.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <5163262.KKx49qeQVV@pintsize.usersys.redhat.com>
 <4965ac04-0b8c-db50-0c20-a7418f36759b@ofcourseimright.com>
 <2437700.lTpqg6aPhl@pintsize.usersys.redhat.com>
Message-ID: <d2864ba1-352d-0549-4780-b6bc2c624936@ofcourseimright.com>


On 17.01.19 21:20, Hubert Kario wrote:
> then I'd say that showing the date from within the signature will be more 
> confusing than helpful to the administrator

Nevermind the date, you can't even get the expiration error
programmatically.


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

From dclarke at blastwave.org  Fri Jan 18 08:32:31 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 18 Jan 2019 03:32:31 -0500
Subject: [openssl-users] The less than perfect way to compile a debug library
Message-ID: <81f8ffd2-ef76-c89e-ffd0-3e5c750fcf99@blastwave.org>



This is based on the sickly things that happen on Solaris as documented 
by various people at :

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

One must do :

/*
  * Copyright 2018 The OpenSSL Project Authors. All Rights Reserved.
  *
  * Licensed under the OpenSSL license (the "License").  You may not use
  * this file except in compliance with the License.  You can obtain a copy
  * in the file LICENSE in the source distribution or at
  * https://www.openssl.org/source/license.html
  */

/*
  * Check to see if there is a conflict between complex.h and openssl/rsa.h.
  * The former defines "I" as a macro and earlier versions of the latter use
  * for function arguments.
  */
#if defined(__STDC_VERSION__)
# if __STDC_VERSION__ >= 199901L
#  include <complex.h>
# endif
#endif
#include <openssl/rsa.h>
#include <stdlib.h>

/* per https://github.com/openssl/openssl/issues/6912 */
#pragma weak OPENSSL_sk_pop_free
#pragma weak OPENSSL_sk_dup
#pragma weak OPENSSL_sk_pop
#pragma weak OPENSSL_sk_num
#pragma weak OPENSSL_sk_new
#pragma weak OPENSSL_sk_set
#pragma weak OPENSSL_sk_free
#pragma weak OPENSSL_sk_find
#pragma weak OPENSSL_sk_push
#pragma weak OPENSSL_sk_sort
#pragma weak OPENSSL_sk_zero
#pragma weak OPENSSL_sk_is_sorted
#pragma weak OPENSSL_sk_shift
#pragma weak OPENSSL_sk_value
#pragma weak OPENSSL_sk_delete_ptr
#pragma weak OPENSSL_sk_unshift
#pragma weak OPENSSL_sk_new_null
#pragma weak OPENSSL_sk_set_cmp_func
#pragma weak OPENSSL_sk_reserve
#pragma weak OPENSSL_sk_new_reserve
#pragma weak OPENSSL_sk_delete
#pragma weak OPENSSL_sk_insert
#pragma weak OPENSSL_sk_deep_copy
#pragma weak OPENSSL_sk_find_ex

int main(int argc, char *argv[])
{
     /* There are explicitly no run time checks for this one */
     return EXIT_SUCCESS;
}

That is horrific but allows a strict C99 compile to proceed.

Dennis

From vieuxtech at gmail.com  Fri Jan 18 06:07:03 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Thu, 17 Jan 2019 22:07:03 -0800
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
 <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
Message-ID: <CA+Sj9TmtfoguEkhf-JKs=yJR0dB2vv5DSb2twHACDZq3nTHrpw@mail.gmail.com>

On Thu, Jan 17, 2019 at 5:40 PM Jordan Brown
<openssl at jordan.maileater.net> wrote:
> On 1/14/2019 4:09 AM, Matt Caswell wrote:
>
> This works more "by accident". There is no ciphersuite alias called "TLSv1.3", so using it as above results in no ciphersuites matched. Since the TLSv1.3 ciphersuites are on by default anyway that's all that you get back.
>
>
> From what you say, and based on experimentation, it seems like the TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them.

3 of 5 TLS1.3 cipher suites are enabled by default

I'm having to reverse engineer the intention, but I think that it was
thought that the cipher list API with its mini language was too
complex, so there is a new API for setting TLS1.3 cipher suites,
_set_ciphersuites(), and for openssl cipher, you can pass args to it
using the -ciphersuites option. You can also pass an empty string ""
to clear them.

Another reason for the second API and the odd interactions between
them may be that there are existing apps calling the set_cipher_list()
APIs.. if their arg applied to TLS1.3 ciphers, it would always clear
them, so existing apps wouldn't use TLS1.3 even though they were
theoretically capable.

Anyhow, you are seeing that seperation of two APIs, each configuring
suites for different protocol familes (pre/post TLS1.3).

From vcizek at suse.com  Fri Jan 18 10:51:12 2019
From: vcizek at suse.com (Vitezslav Cizek)
Date: Fri, 18 Jan 2019 11:51:12 +0100
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
 <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
Message-ID: <20190118115112.2f08ca00@zvon.suse.cz>

Hi,

V Fri, 18 Jan 2019 01:33:20 +0000
"Jordan Brown" <openssl at jordan.maileater.net> naps?no:

> On 1/14/2019 4:09 AM, Matt Caswell wrote:
> > This works more "by accident". There is no ciphersuite alias called
> > "TLSv1.3", so using it as above results in no ciphersuites matched.
> > Since the TLSv1.3 ciphersuites are on by default anyway that's all
> > that you get back.  
> 
> 
> From what you say, and based on experimentation, it seems like the
> TLSv1.3 ciphersuites are enabled even if you explicitly say to
> disable them.
> 
>     $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384
>     *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
>     $ openssl ciphers AES:-SHA384
>     *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> That doesn't seem right.? Am I missing something?

Yes.
TLS 1.3 ciphers are configured differently, you need to use
the -ciphersuites option.

See https://www.openssl.org/docs/man1.1.1/man1/ciphers.html

Try
# openssl ciphers -v -ciphersuites '' SHA384

  Vita

-- 
V?t?zslav ???ek             Emergency Update Team (EMU)
"Whilst you sleep, we're probably saving the universe."

From Michael.Wojcik at microfocus.com  Fri Jan 18 13:05:12 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 18 Jan 2019 13:05:12 +0000
Subject: [openssl-users] crypto/objects/o_names.c problem with Solaris
 10 and strict Oracle Studio 12.6 c99
In-Reply-To: <83acecfd-5cf1-bac2-e7d8-c4f8f186d31a@blastwave.org>
References: <e199d9d0-b5f6-2fac-631f-046a0f5ae9b4@blastwave.org>
 <MW2PR18MB2090107A46C37015C6F496E3F99C0@MW2PR18MB2090.namprd18.prod.outlook.com>
 <83acecfd-5cf1-bac2-e7d8-c4f8f186d31a@blastwave.org>
Message-ID: <MW2PR18MB2090DAAC2AC5E389B6B02EAFF99C0@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of
> Dennis Clarke
> Sent: Thursday, January 17, 2019 23:56
>
> Thank you for the great reply where clearly you have seen ifdeffery
> nonsense bite you.  I get caught between a rock and a hrd place here
> every time because if I try to go with just ordinary cc and just some
> transition loosey goosey not-really-compliant or strict CFLAGS then I
> arrive in a different ugly place :
>
>
> ${LDCMD:-/opt/developerstudio12.6/bin/cc} -m64 -xarch=sparc -g -Xa
> -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff
> -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc
> -ftrap=%none -xbuiltin=%none -xunroll=1 -xstrconst -Xa -m64 -xarch=sparc
> -g -Xa -errfmt=error -erroff=%none -errshort=full -xstrconst -xildoff
> -xmemalign=8s -xnolibmil -xcode=pic32 -xregs=no%appl -xlibmieee -mc
> -ftrap=%none -xbuiltin=%none -xunroll=1 -L. -mt  \
>          -o test/rsa_complex test/rsa_complex.o \
>           -lsocket -lnsl -ldl -lrt -lpthread
> Undefined                       first referenced
>   symbol                             in file
> OPENSSL_sk_pop_free                 test/rsa_complex.o [etc]

Am I missing something, or is this just because Configure somehow gave you a makefile for the tests that doesn't actually link the OpenSSL libraries? There's just libsocket, libnsl, libdl, librt, and libpthread there.

I don't know how that would have happened, but I haven't looked at the Configure for 1.1.1 as closely as I have the 1.0.2. (I was primarily responsible for hacking my team's OpenSSL builds for the 1.0.2 line, but a different developer for 1.1.1 implemented our move to that release.)

It appears for our Solaris 11 SPARC build of 1.1.1 we're using stock OpenSSL Configure with "solaris-sparcv9-gcc" as the target (or solaris64-sparcv9-gcc for 64-bit builds). If memory serves, we used to use the Sun/Oracle implementation (SUNWspro) in older products, but that would have been with OpenSSL 1.0.2 or possibly earlier. I'm not sure when we switched to gcc on Solaris. So unfortunately I don't have any more-specific advice for building 1.1.1 using the Developer Studio toolchain.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From grahame at healthintersections.com.au  Fri Jan 18 11:51:49 2019
From: grahame at healthintersections.com.au (Grahame Grieve)
Date: Fri, 18 Jan 2019 22:51:49 +1100
Subject: [openssl-users] Binary Distribution DLL Names
In-Reply-To: <CAG47hGYKMY1qQiwf0CFs9oHML0-2kf1AcEHu-GkY7W=rEgXqrw@mail.gmail.com>
References: <CAG47hGYKMY1qQiwf0CFs9oHML0-2kf1AcEHu-GkY7W=rEgXqrw@mail.gmail.com>
Message-ID: <CAG47hGba_CaX80FR+Xy9_zbqTKW863ee=hNDvwHojq2gML-kww@mail.gmail.com>

I got no response to this. I presume that mean that this is a stupid
question, but I'm afraid I don't understand why

Grahame


On Mon, Jan 14, 2019 at 11:45 PM Grahame Grieve <
grahame at healthintersections.com.au> wrote:

> Hi
>
> I have a 64bit windows application that uses openSSL, and I am using the
> indy distribution from https://indy.fulgan.com/SSL/. This makes the file
> names of the openssl dlls libeay32.dll and ssleay32.dll (even though they
> are 64bit).  Other distributions use other names (libcrypto-XX-x64.dll etc)
>
> I believe that the filename variations are at the root of an issue I have
> with openSSL. My symptoms are this: when I run my unit tests that do (among
> other things) a bunch of tests of my SSL server, all is good. However,
> anytime I load the mysql odbc driver into the memory space, I get an memory
> corruption problem in libeay32.dll when shutting down. Google suggests that
> this is due to a build mismatch between the two dlls... I'm guessing that
> mysql is loading some other dll variant of openssl and some build mismatch
> is arising ?
>
> I'm clutching at straws here, but has this been an issue before? is there
> any policy issue around distrubution filenames? Is there any other likely
> cause why loading the mysql odbc driver causes memory corruptions in
> openssl when shutting down?
>
> thanks
> Grahame
> --
> -----
> http://www.healthintersections.com.au / grahame at healthintersections.com.au
> / +61 411 867 065
>


-- 
-----
http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190118/ab833444/attachment.html>

From matt at openssl.org  Fri Jan 18 16:27:59 2019
From: matt at openssl.org (Matt Caswell)
Date: Fri, 18 Jan 2019 16:27:59 +0000
Subject: [openssl-users] Binary Distribution DLL Names
In-Reply-To: <CAG47hGba_CaX80FR+Xy9_zbqTKW863ee=hNDvwHojq2gML-kww@mail.gmail.com>
References: <CAG47hGYKMY1qQiwf0CFs9oHML0-2kf1AcEHu-GkY7W=rEgXqrw@mail.gmail.com>
 <CAG47hGba_CaX80FR+Xy9_zbqTKW863ee=hNDvwHojq2gML-kww@mail.gmail.com>
Message-ID: <815395cd-cb2c-434b-d74b-154b69245585@openssl.org>



On 18/01/2019 11:51, Grahame Grieve wrote:
> I got no response to this. I presume that mean that this is a stupid question,
> but I'm afraid I don't understand why
> 
> Grahame
> 
> 
> On Mon, Jan 14, 2019 at 11:45 PM Grahame Grieve
> <grahame at healthintersections.com.au <mailto:grahame at healthintersections.com.au>>
> wrote:
> 
>     Hi
> 
>     I have a 64bit windows application that uses openSSL, and I am using the
>     indy distribution from?https://indy.fulgan.com/SSL/. This makes the file
>     names of the openssl dlls libeay32.dll and ssleay32.dll (even though they
>     are 64bit).


That distribution is OpenSSL 1.0.2 which uses those old names.


> Other distributions use other names (libcrypto-XX-x64.dll etc)

Other distributions you have seen are probably using OpenSSL 1.1.0 or 1.1.1
which use the new names.

> 
>     I believe that the filename variations are at the root of an issue I have
>     with openSSL. My symptoms are this: when I run my unit tests that do (among
>     other things) a bunch of tests of my SSL server, all is good. However,
>     anytime I load the mysql odbc driver into the memory space, I get an memory
>     corruption problem in libeay32.dll when shutting down. Google suggests that
>     this is due to a build mismatch between the two dlls... I'm guessing that
>     mysql is loading some other dll variant of openssl and some build mismatch
>     is arising ??
> 
>     I'm clutching at straws here, but has this been an issue before? is there
>     any policy issue around distrubution filenames? Is there any other likely
>     cause why loading the mysql odbc driver causes memory corruptions in openssl
>     when shutting down??

I've not seen it before. The distribution filenames vary based on the version of
OpenSSL you are using.

Matt

From bkaduk at akamai.com  Fri Jan 18 18:01:07 2019
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Fri, 18 Jan 2019 12:01:07 -0600
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
 <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
Message-ID: <20190118180107.GI13623@akamai.com>

On Fri, Jan 18, 2019 at 01:33:20AM +0000, Jordan Brown wrote:
> On 1/14/2019 4:09 AM, Matt Caswell wrote:
> > This works more "by accident". There is no ciphersuite alias called
> > "TLSv1.3", so using it as above results in no ciphersuites matched.
> > Since the TLSv1.3 ciphersuites are on by default anyway that's all
> > that you get back.
> 
> 
> From what you say, and based on experimentation, it seems like the
> TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them.
> 
>     $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384
>     *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
>     $ openssl ciphers AES:-SHA384
>     *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> That doesn't seem right.? Am I missing something?

Presumably.  The TLS 1.3 ciphersuites are entirely separate from the traditional
cipher list:

    -ciphersuites val
        Sets the list of TLSv1.3 ciphersuites. This list will be combined with
        any TLSv1.2 and below ciphersuites that have been configured. The format
        for this list is a simple colon (":") separated list of TLSv1.3
        ciphersuite names. By default this value is:

         TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA25

-Ben

From hkario at redhat.com  Fri Jan 18 18:18:05 2019
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 18 Jan 2019 19:18:05 +0100
Subject: [openssl-users] in the department of "ain't no perfect"
In-Reply-To: <00f36cb1-5325-2550-ee2b-6aef46eb9df3@wisemo.com>
References: <8370a88f-54b2-4eec-ab64-f148c4ec3279@ofcourseimright.com>
 <B6A8DC5E-2AA0-4958-A5EA-5989CFF7F05B@dukhovni.org>
 <00f36cb1-5325-2550-ee2b-6aef46eb9df3@wisemo.com>
Message-ID: <1623168.zJAeVusSUg@pintsize.usersys.redhat.com>

On Friday, 18 January 2019 05:45:11 CET Jakob Bohm via openssl-users wrote:
> On 16/01/2019 21:25, Viktor Dukhovni wrote:
> >> On Jan 15, 2019, at 10:29 AM, Eliot Lear <lear at ofcourseimright.com>
> > The na?ve model of using the signer and recipient keys as long-term
> > verification and decryption keys is deeply flawed for data retention.
> > This is a bit part of the reason why end-to-end email encryption has
> > negligible adoption, the storage infrastructure to make it usable was
> > never built.
> 
> As explained above, most of that storage infrastructure is in
> fact in place, but the major e-mail clients lack the code to use
> it.  For example the "openssl cms" command (used by some unix mail
> clients, such as Mutt) doesn't have an option to specify the "as of"
> date extracted from an external trusted source.

it does in newer versions (it is definitely present in 1.1.0i):
 -attime intmax             verification epoch time

> Nor does it have
> an option to input a recorded OCSP response or CRL to be validated
> and used according to that "as of" date.

that's true

-- 
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/20190118/2cdd56c4/attachment.sig>

From hkario at redhat.com  Fri Jan 18 18:20:13 2019
From: hkario at redhat.com (Hubert Kario)
Date: Fri, 18 Jan 2019 19:20:13 +0100
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
	suite names?
In-Reply-To: <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
 <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
Message-ID: <110563780.GbbGS6gMBA@pintsize.usersys.redhat.com>

On Friday, 18 January 2019 02:33:20 CET Jordan Brown wrote:
> On 1/14/2019 4:09 AM, Matt Caswell wrote:
> > This works more "by accident". There is no ciphersuite alias called
> > "TLSv1.3", so using it as above results in no ciphersuites matched.
> > Since the TLSv1.3 ciphersuites are on by default anyway that's all
> > that you get back.
> 
> From what you say, and based on experimentation, it seems like the
> TLSv1.3 ciphersuites are enabled even if you explicitly say to disable them.
> 
>     $ openssl ciphers SHA384:\!TLS_AES_256_GCM_SHA384
>     *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
>     $ openssl ciphers AES:-SHA384
>     *TLS_AES_256_GCM_SHA384*:TLS_CHACHA20_POLY1305_SHA256:[...]
> 
> That doesn't seem right.  Am I missing something?

see man 1 ciphers
section "TLS v1.3 cipher suites" specifies all ciphers that are supported for 
TLS 1.3 while -ciphersuites is used to change which are enabled

-- 
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/20190118/19de467b/attachment.sig>

From dclarke at blastwave.org  Fri Jan 18 22:41:09 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 18 Jan 2019 17:41:09 -0500
Subject: [openssl-users] compile hell : fatal: symbol referencing
 errors. OPENSSL_sk_pop_free etc etc etc
In-Reply-To: <548d6c68-3443-d5f8-3496-ed12cd7a774d@blastwave.org>
References: <548d6c68-3443-d5f8-3496-ed12cd7a774d@blastwave.org>
Message-ID: <9d441f2b-ff95-2315-ed97-077b8d1c28a8@blastwave.org>

On 1/18/19 1:05 AM, Dennis Clarke wrote:
> 
> So it seems to no longer matter if I try strict C99 or just cc with or
> without strict CFLAGS. I always arrive at the same place :

Ignore this .. fixed .. done .. closed ... not even a correct issue.

Thou shalt not pass C99 here.  Thus sayeth the Salz and so let it be 
written ...


Dennis


From dclarke at blastwave.org  Fri Jan 18 22:45:09 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 18 Jan 2019 17:45:09 -0500
Subject: [openssl-users] The less than perfect way to compile a debug
 library
In-Reply-To: <81f8ffd2-ef76-c89e-ffd0-3e5c750fcf99@blastwave.org>
References: <81f8ffd2-ef76-c89e-ffd0-3e5c750fcf99@blastwave.org>
Message-ID: <8ba9092e-d891-fb02-1a28-a8010ef8e01c@blastwave.org>

On 1/18/19 3:32 AM, Dennis Clarke wrote:
> 
> 
> This is based on the sickly things that happen on Solaris as documented 
> by various people at :

fixed .. done

https://github.com/openssl/openssl/pull/7721/commits/23dcef5ad68efe6f6882328de5948ae6820000fb


> 
> https://github.com/openssl/openssl/issues/6912

Dennis


From dclarke at blastwave.org  Fri Jan 18 23:40:05 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Fri, 18 Jan 2019 18:40:05 -0500
Subject: [openssl-users] Dealing with RFC2553 and RFC3493 where
 NI_MAXHOST and NI_MAXSERV no longer exist
In-Reply-To: <5d844b74-2f1c-45cc-5368-09c4c29c2068@blastwave.org>
References: <5d844b74-2f1c-45cc-5368-09c4c29c2068@blastwave.org>
Message-ID: <48549c55-f120-9856-6fb1-687237e75b20@blastwave.org>

On 1/18/19 1:53 AM, Dennis Clarke wrote:
> 
> Going in circles trying to compile 1.1.1a with strict C99 and no
> optimizations and with a ready to debug and single step resultant
> library. 

Ignore all this.  Thou shalt not C99 here.

Dennis


From openssl at jordan.maileater.net  Sat Jan 19 02:38:33 2019
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Sat, 19 Jan 2019 02:38:33 +0000
Subject: [openssl-users] is there an API to list all the TLS 1.3 cipher
 suite names?
In-Reply-To: <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
References: <CA+Sj9Tm4mbXz5PoWXs0586HZimPZSx17nQJhJ0Ba4ip9iQkd2g@mail.gmail.com>
 <CAKQ1sVPket294AAvO9R0YNardpT2fy_gpK_dvF6o2X1cghTYUw@mail.gmail.com>
 <2203b9cd-2517-d08e-5e54-a82fe8118a70@openssl.org>
 <010101685e974c76-2bd9c557-a828-48a1-81bc-75d6562e74d8-000000@us-west-2.amazonses.com>
Message-ID: <0101016863f95e7b-7157fe98-142d-4bd5-9aed-947aa2ebc555-000000@us-west-2.amazonses.com>

On 1/17/2019 5:33 PM, Jordan Brown wrote:
> Am I missing something?


Seems I was.? Thanks, all.

-- 
Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris

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

From grahame at healthintersections.com.au  Sat Jan 19 02:51:58 2019
From: grahame at healthintersections.com.au (Grahame Grieve)
Date: Sat, 19 Jan 2019 13:51:58 +1100
Subject: [openssl-users] Binary Distribution DLL Names
In-Reply-To: <815395cd-cb2c-434b-d74b-154b69245585@openssl.org>
References: <CAG47hGYKMY1qQiwf0CFs9oHML0-2kf1AcEHu-GkY7W=rEgXqrw@mail.gmail.com>
 <CAG47hGba_CaX80FR+Xy9_zbqTKW863ee=hNDvwHojq2gML-kww@mail.gmail.com>
 <815395cd-cb2c-434b-d74b-154b69245585@openssl.org>
Message-ID: <CAG47hGZKDb03JdTmNLDyqrfb9+feeswy+X9wiXR_zTaJmOzacA@mail.gmail.com>

thanks very much. I will see what I can do about the indy distribution
which seems to have fallen behind

Grahame


On Sat, Jan 19, 2019 at 9:27 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 18/01/2019 11:51, Grahame Grieve wrote:
> > I got no response to this. I presume that mean that this is a stupid
> question,
> > but I'm afraid I don't understand why
> >
> > Grahame
> >
> >
> > On Mon, Jan 14, 2019 at 11:45 PM Grahame Grieve
> > <grahame at healthintersections.com.au <mailto:
> grahame at healthintersections.com.au>>
> > wrote:
> >
> >     Hi
> >
> >     I have a 64bit windows application that uses openSSL, and I am using
> the
> >     indy distribution from https://indy.fulgan.com/SSL/. This makes the
> file
> >     names of the openssl dlls libeay32.dll and ssleay32.dll (even though
> they
> >     are 64bit).
>
>
> That distribution is OpenSSL 1.0.2 which uses those old names.
>
>
> > Other distributions use other names (libcrypto-XX-x64.dll etc)
>
> Other distributions you have seen are probably using OpenSSL 1.1.0 or 1.1.1
> which use the new names.
>
> >
> >     I believe that the filename variations are at the root of an issue I
> have
> >     with openSSL. My symptoms are this: when I run my unit tests that do
> (among
> >     other things) a bunch of tests of my SSL server, all is good.
> However,
> >     anytime I load the mysql odbc driver into the memory space, I get an
> memory
> >     corruption problem in libeay32.dll when shutting down. Google
> suggests that
> >     this is due to a build mismatch between the two dlls... I'm guessing
> that
> >     mysql is loading some other dll variant of openssl and some build
> mismatch
> >     is arising ?
> >
> >     I'm clutching at straws here, but has this been an issue before? is
> there
> >     any policy issue around distrubution filenames? Is there any other
> likely
> >     cause why loading the mysql odbc driver causes memory corruptions in
> openssl
> >     when shutting down?
>
> I've not seen it before. The distribution filenames vary based on the
> version of
> OpenSSL you are using.
>
> Matt
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>


-- 
-----
http://www.healthintersections.com.au / grahame at healthintersections.com.au
/ +61 411 867 065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190119/6ef9058e/attachment.html>

From erik at efca.com  Sat Jan 19 05:34:37 2019
From: erik at efca.com (Erik Forsberg)
Date: Fri, 18 Jan 2019 21:34:37 -0800
Subject: [openssl-users] Dealing with RFC2553 and RFC3493 where
 NI_MAXHOST and NI_MAXSERV no longer exist
In-Reply-To: <48549c55-f120-9856-6fb1-687237e75b20@blastwave.org>
References: <48549c55-f120-9856-6fb1-687237e75b20@blastwave.org>
Message-ID: <xLAFDQdUqJ1rFf2@srv.efca.com>

hmm, been reading this whole thread.
I dont have any current issues building with Sun Studio 12.6 in  2011 mode (but I only do Intel x86 and x86_64)
However, I do have a preference for using gcc for openssl builds though.
Do note however, that in my opinion, for Solaris, one MUST do the -R linker options
to avoid runtime issues with Solaris builds of OpenSSL, But I suppose thats for everyone to
discover for themselves. I discovered it the hard way during the 1.0.1 era.
The -strict mode I think is impossible as of now
(dot-asm) I do want to see your PR for adding support for -R to get incorporated, been sitting for a while -:)

Here are my preferred config settings for Solaris cc

???"efca-x64-cc" => {
???????inherit_from????=> [ "solaris-common", asm("x86_64_asm") ],
???????CC??????????????=> "cc",
???????CFLAGS??????????=> add_before(picker(debug??=> "-g",
?????????????????????????????????????????????release => "-xO5 -xdepend -xbuiltin")),
???????cflags??????????=> add_before("-m64 -xarch=generic -xstrconst -std=gnu11"),
???????cppflags????????=> add(threads("-D_REENTRANT")),
???????lib_cppflags????=> add("-DL_ENDIAN"),
???????lflags??????????=> add(threads("-mt")),
???????ex_libs?????????=> add(threads("-lpthread")),
???????bn_ops??????????=> "SIXTY_FOUR_BIT_LONG",
???????perlasm_scheme??=> "elf",
???????shared_cflag????=> "-KPIC",
???????shared_ldflag???=> add_before("-G -dy -z text -R\$(INSTALLTOP)/\$(LIBDIR)"),
???????multilib????????=> "/64",
???},

>-- Original Message --
>
>On 1/18/19 1:53 AM, Dennis Clarke wrote:
>> 
>> Going in circles trying to compile 1.1.1a with strict C99 and no
>> optimizations and with a ready to debug and single step resultant
>> library. 
>
>Ignore all this.  Thou shalt not C99 here.
>
>Dennis
>
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From thiagu.m at gmail.com  Tue Jan 22 05:58:41 2019
From: thiagu.m at gmail.com (Thiagu Mohan)
Date: Tue, 22 Jan 2019 11:28:41 +0530
Subject: [openssl-users] Compiling openssl 1.0.2q for OS390-Unix
In-Reply-To: <CAA56SLysSD_T--XUdRFqY6tc+U_Q_j6LqtPP7iOQH9e2mtfh_w@mail.gmail.com>
References: <CAA56SLwhizHJ+jBexOoL8bP2QC9zhbkbH6Do++_sMrau2yL+WQ@mail.gmail.com>
 <CAA56SLysSD_T--XUdRFqY6tc+U_Q_j6LqtPP7iOQH9e2mtfh_w@mail.gmail.com>
Message-ID: <CAA56SLzQpQ8sFRTXZdCCMvRT6ZGe7s+TO7v4-qUSZhAGztFzSQ@mail.gmail.com>

Hi,
>
> When i tried compiling openssl 1.0.2q for OS390-Unix  i got sevaeral
> warning like below but got the libraries libcrypto.a and libssl.a  compiled
>
> INFORMATIONAL CCN3764 /usr/include/signal.h:62    Option rent is ignored
> for variable __sigign because pragma variable(NORENT) is specified.
> INFORMATIONAL CCN3684 ./openssl.c:218   Exporting function main is not
> allowed.
> INFORMATIONAL CCN3684 ./bntest.c:143   Exporting function main is not
> allowed. IEW2689W 4C40 DEFINITION SIDE FILE IS NOT DEFINED.
> FSUM3065 The LINKEDIT step ended with return code 4.
>
>
> But while building my project with these libraries  i am getting lot of
> unresolved errors like
>
> plink: error: symbol 'X509_SIG_it' from archive member
> "libcrypto.a(p12_asn.o)" is unresolved
> plink: error: symbol 'PKCS12_AUTHSAFES_it' from archive member
> "libcrypto.a(p12_add.o)" is unresolved
>
> Any pointers ??
>
> Thiagu Mohan
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190122/7f7cb3f6/attachment-0001.html>

From Michael.Wojcik at microfocus.com  Tue Jan 22 13:29:43 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 22 Jan 2019 13:29:43 +0000
Subject: [openssl-users] Compiling openssl 1.0.2q for OS390-Unix
In-Reply-To: <CAA56SLzQpQ8sFRTXZdCCMvRT6ZGe7s+TO7v4-qUSZhAGztFzSQ@mail.gmail.com>
References: <CAA56SLwhizHJ+jBexOoL8bP2QC9zhbkbH6Do++_sMrau2yL+WQ@mail.gmail.com>
 <CAA56SLysSD_T--XUdRFqY6tc+U_Q_j6LqtPP7iOQH9e2mtfh_w@mail.gmail.com>
 <CAA56SLzQpQ8sFRTXZdCCMvRT6ZGe7s+TO7v4-qUSZhAGztFzSQ@mail.gmail.com>
Message-ID: <MW2PR18MB20904BC33CCC3D6357B6B71AF9980@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Thiagu Mohan
> Sent: Tuesday, January 22, 2019 00:59
>
> When i tried compiling openssl 1.0.2q for OS390-Unix  i got sevaeral warning like below but
> got the libraries libcrypto.a and libssl.a  compiled

> INFORMATIONAL CCN3764 /usr/include/signal.h:62    Option rent is ignored for variable __sigign
> because pragma variable(NORENT) is specified.
> INFORMATIONAL CCN3684 ./openssl.c:218   Exporting function main is not allowed.
> INFORMATIONAL CCN3684 ./bntest.c:143   Exporting function main is not allowed. IEW2689W 4C40
> DEFINITION SIDE FILE IS NOT DEFINED.
> FSUM3065 The LINKEDIT step ended with return code 4.

None of those look relevant to your issue. The RENT (reentrant, if memory serves) option is specifically suppressed for __sigign by a pragma; that's probably done in the system header, so it's behaving as expected. For the openssl utility program and the test programs, you're getting diagnostics saying you can't export the main function - that's expected too.

> But while building my project with these libraries  i am getting lot of unresolved errors like

> plink: error: symbol 'X509_SIG_it' from archive member "libcrypto.a(p12_asn.o)" is unresolved
> plink: error: symbol 'PKCS12_AUTHSAFES_it' from archive member "libcrypto.a(p12_add.o)" is
> unresolved

Are you sure you're linking against the libraries you built, and not other copies elsewhere on the system?

I did a quick scan through the 1.0.2n source (don't have 1.0.2q handy), and I don't see X509_SIG_it anywhere. There's X509_SIG, X509_SIG_new, and X509_SIG_free. Similarly, there's PKCS12_AUTHSAFES but no PKCS12_AUTHSAFES_it. It's possible those were introduced after 1.0.2n, though.

My suggestion would be to scan all the generated .o files with nm to see where those symbols are being introduced (apparently they're at least in p12_asn.o and p12_add.o, but maybe elsewhere as well?). That will help narrow the problem down.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From kurt at roeckx.be  Tue Jan 22 19:58:02 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 22 Jan 2019 20:58:02 +0100
Subject: [openssl-users] Dealing with RFC2553 and RFC3493 where
 NI_MAXHOST and NI_MAXSERV no longer exist
In-Reply-To: <48549c55-f120-9856-6fb1-687237e75b20@blastwave.org>
References: <5d844b74-2f1c-45cc-5368-09c4c29c2068@blastwave.org>
 <48549c55-f120-9856-6fb1-687237e75b20@blastwave.org>
Message-ID: <20190122195802.GA8133@roeckx.be>

On Fri, Jan 18, 2019 at 06:40:05PM -0500, Dennis Clarke wrote:
> On 1/18/19 1:53 AM, Dennis Clarke wrote:
> > 
> > Going in circles trying to compile 1.1.1a with strict C99 and no
> > optimizations and with a ready to debug and single step resultant
> > library.
> 
> Ignore all this.  Thou shalt not C99 here.

Our code base is currently C89/C90, with some extenions, but things
like gcc default to something like "gnu99", "gnu11" or "gnu17".
And we actually make use of some of those extensions not in C89.

The ones I know about:
- asm(): Most of those should go away if you define PEDANTIC. I
  think the only exception is code we compile when gcc is used.
- strdup() and strcasecmp() which are in POSIX, but not in C
- Setting the mutex type, which seems to be UNIX98 or XOPEN2K8
- isascii: XOPEN
- usleep: Was in POSIX, has been replaced by nanosleep
- long long: Since C99

Then we also use things like int32_t, but define the type ourself
if the compiler is C89. We detect C11 support for atomics.

Anyway, if you have a good patch to remove things that are no
longer in a standard, and it also works with older systems, I suggest
submit a patch.


Kurt


From dclarke at blastwave.org  Tue Jan 22 20:54:28 2019
From: dclarke at blastwave.org (Dennis Clarke)
Date: Tue, 22 Jan 2019 15:54:28 -0500
Subject: [openssl-users] Dealing with RFC2553 and RFC3493 where
 NI_MAXHOST and NI_MAXSERV no longer exist
In-Reply-To: <20190122195802.GA8133@roeckx.be>
References: <5d844b74-2f1c-45cc-5368-09c4c29c2068@blastwave.org>
 <48549c55-f120-9856-6fb1-687237e75b20@blastwave.org>
 <20190122195802.GA8133@roeckx.be>
Message-ID: <f5937799-c1e1-4caf-5ca2-be8d962ccb65@blastwave.org>

On 1/22/19 2:58 PM, Kurt Roeckx wrote:
> On Fri, Jan 18, 2019 at 06:40:05PM -0500, Dennis Clarke wrote:
>> On 1/18/19 1:53 AM, Dennis Clarke wrote:
>>>
>>> Going in circles trying to compile 1.1.1a with strict C99 and no
>>> optimizations and with a ready to debug and single step resultant
>>> library.
>>
>> Ignore all this.  Thou shalt not C99 here.
> 
> Our code base is currently C89/C90, with some extenions, but things
> like gcc default to something like "gnu99", "gnu11" or "gnu17".
> And we actually make use of some of those extensions not in C89.

I tend to look at anything 'gnu-foo' as clearly non-standard but still
very very popular and thus defacto standard.  Whatever that means. :-)

> 
> The ones I know about:
> - asm(): Most of those should go away if you define PEDANTIC.

No need with the Oracle Studio compilers.  Just use c99 and strict
CFLAGS and watch it utter the endless complaints.

>   I think the only exception is code we compile when gcc is used.
> - strdup() and strcasecmp() which are in POSIX, but not in C

Yep .. that thing.

> - Setting the mutex type, which seems to be UNIX98 or XOPEN2K8
> - isascii: XOPEN
> - usleep: Was in POSIX, has been replaced by nanosleep
> - long long: Since C99
> 
> Then we also use things like int32_t, but define the type ourself
> if the compiler is C89. We detect C11 support for atomics.
> 
> Anyway, if you have a good patch to remove things that are no
> longer in a standard, and it also works with older systems, I suggest
> submit a patch.

I think that Rich Salz has already weighed in on this battle and the
code base is C89 clean.  A leap to C99 compliance may not be on anyones
horizon at all and I am not sure how much work would be needed. Curious
to look at it however.

Dennis Clarke

ps: see excellent email from Michael Wojcik Fri Jan 18 01:25:10 UTC 2019
     where "strcasecmp is a heresy" :

https://mta.openssl.org/pipermail/openssl-users/2019-January/009735.html

From hvbang246 at gmail.com  Wed Jan 23 10:06:59 2019
From: hvbang246 at gmail.com (Hoang Bang)
Date: Wed, 23 Jan 2019 17:06:59 +0700
Subject: [openssl-users] Fwd: Can't build openssl with VS2005 on Windows
In-Reply-To: <CAAVZGX-qLEGSBZzhWnbY8wpW+V1CAAh+_4_o-pjyaSbd8fWquQ@mail.gmail.com>
References: <CAAVZGX-qLEGSBZzhWnbY8wpW+V1CAAh+_4_o-pjyaSbd8fWquQ@mail.gmail.com>
Message-ID: <CAAVZGX9BRrSHxRAMnLCHzSpxatiTMBfydCosOJHTuo=2=E8Kvw@mail.gmail.com>

Hi team,
Please help about my case !
I want build openssl version 1.1.1a witch VS2005 on windows 7
I installed ActivePerl-5.24.3.2404-MSWin32-x64-404865.exe,
nasm-2.14.03rc2-installer-x86 and download source
nasm-2.14.03rc2-installer-x86.
I run cmd with permission Admin and added localtion of ActivePerl to
%patch% :


*@set path=%path%;C:\Program Files
(x86)\NASM;C:\Perl64\site\bin;C:\Perl64\bin;call "c:\Program Files
(x86)\Microsoft Visual Studio 8\VC\bin\vcvars32.bat";*

and run command on folder openssl:
perl Configure VC-WIN32 no-shared no-asm --prefix=C:/openssl
nmake
======================================
I have error :







*crypto\ct\ct_prn.c(38) : error C2220: warning treated as error - no
'object' file generatedcrypto\ct\ct_prn.c(38) : warning C4244: 'function' :
conversion from 'uint64_t' to 'long', possibleloss of dataNMAKE : fatal
error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
8\VC\BIN\cl.EXE"' : return code '0x2'Stop.NMAKE : fatal error U1077:
'"C:\Program Files (x86)\Microsoft Visual Studio 8\VC\BIN\nmake.exe"' :
return code '0x2'Stop.*

Please help me to be able to build successfully !
Thank you very much !

Regards,
Bang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190123/ae4f6854/attachment.html>

From a.cudbardb at freeradius.org  Wed Jan 23 13:01:35 2019
From: a.cudbardb at freeradius.org (Arran Cudbard-Bell)
Date: Wed, 23 Jan 2019 20:01:35 +0700
Subject: [openssl-users] SSL_CTX_set_session_cache_mode(ctx,
 SSL_SESS_CACHE_OFF); has no effect with TLS 1.3
Message-ID: <14CCBFD1-4136-4902-8957-53651E24B451@freeradius.org>

As per the subject line:

	SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF) 

does not seem to disable generation of stateless tickets with TLS 1.3:

	SSL_CTX_set_num_tickets(ctx, 0); 

is also required to prevent the tickets being generated.

There's no mention of this additional call on the SSL_CTX_set_session_cache_mode pages (but is documented elsewhere).

It really seems like SSL_SESS_CACHE_OFF should also disable TLS1.3 session tickets if the intent is for TLS 1.3 to mostly be a drop in replacement for TLS <= 1.2.  A user upgrades OpenSSL library and suddenly session resumption enabled where it wasn't before... that doesn't seem right.

In our case this broke our session_resumption control toggle, where 'session_resumption = no' prevented our EAP server implementation from presenting tickets with TLS <= 1.2 but still allowed them if TLS 1.3 was negotiated.

Disabling session resumption is more important with EAP methods like EAP-TTLS and EAP-PEAP because it controls whether phase 2 runs or not - phase 2 being where the actual credential validation happens.

This was tested with current OpensSL master HEAD.  Can test with the 1.1.* branch if that'd help.

-Arran

From a.cudbardb at freeradius.org  Wed Jan 23 14:04:24 2019
From: a.cudbardb at freeradius.org (Arran Cudbard-Bell)
Date: Wed, 23 Jan 2019 21:04:24 +0700
Subject: [openssl-users] SSL_read() returns -1,
 and SSL_read_ex does not update readbytes where a record containing
 a session ticket is being read (TLS 1.3)
Message-ID: <E237621D-28C5-4437-B287-360822E24D82@freeradius.org>

I'm working with wpa_supplicant to try and fix up its EAP-TTLS and EAP-PEAP implementations to work correctly with TLS 1.3 and session tickets.

Where a new_session_ticket message is sent after client/server finish, calls to SSL_read() result in the new_session_ticket message being processed correctly, but SSL_read() returns -1 if no application_data is available in the input BIO. SSL_read_ex() returns 0, but readbytes isn't updated to reflect the number of bytes consumed whilst processing the session tickets.

It seems to be that SSL_read() should return a positive integer representing the number of bytes read from the BIO whilst processing the session tickets, and SSL_read_ex should update readbytes to the number of bytes read from the BIO whilst processing the session tickets, as is done with other handshake messages.

Can someone comment on whether this is a defect, or intended behaviour used to signal that no application_data was processed?

-Arran


From matt at openssl.org  Wed Jan 23 14:12:55 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 23 Jan 2019 14:12:55 +0000
Subject: [openssl-users] SSL_read() returns -1,
 and SSL_read_ex does not update readbytes where a record containing
 a session ticket is being read (TLS 1.3)
In-Reply-To: <E237621D-28C5-4437-B287-360822E24D82@freeradius.org>
References: <E237621D-28C5-4437-B287-360822E24D82@freeradius.org>
Message-ID: <d504a160-60be-4d65-eaef-03fd8c3ad57d@openssl.org>



On 23/01/2019 14:04, Arran Cudbard-Bell wrote:
> I'm working with wpa_supplicant to try and fix up its EAP-TTLS and EAP-PEAP
> implementations to work correctly with TLS 1.3 and session tickets.
> 
> Where a new_session_ticket message is sent after client/server finish, calls
> to SSL_read() result in the new_session_ticket message being processed
> correctly, but SSL_read() returns -1 if no application_data is available in
> the input BIO. SSL_read_ex() returns 0, but readbytes isn't updated to
> reflect the number of bytes consumed whilst processing the session tickets.

This is intended behaviour. SSL_read() returns the number of plaintext
application data bytes that have been populated in the provided buffer
(similarly for readbytes). If no application data is available then you get the
-1 (for SSL_read()) or 0 (for SSL_read_ex()) return code. You also get that
return code for other types of issues, and you are supposed to call
SSL_get_error() to interpret it.

Note that by default OpenSSL sets SSL_MODE_AUTO_RETRY in 1.1.1 (which it didn't
in 1.1.0). This should mean that it automatically tries again to read
application data without returning an error. Have you switched
SSL_MODE_AUTO_RETRY off?

> 
> It seems to be that SSL_read() should return a positive integer representing
> the number of bytes read from the BIO whilst processing the session tickets,
> and SSL_read_ex should update readbytes to the number of bytes read from the
> BIO whilst processing the session tickets, as is done with other handshake
> messages.

This is not correct. SSL_read()/SSL_read_ex() only ever provide the number of
application data bytes that have been read, irrespective of how many bytes were
read from the underlying BIO.


Matt

From matt at openssl.org  Wed Jan 23 14:57:48 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 23 Jan 2019 14:57:48 +0000
Subject: [openssl-users] SSL_CTX_set_session_cache_mode(ctx,
 SSL_SESS_CACHE_OFF); has no effect with TLS 1.3
In-Reply-To: <14CCBFD1-4136-4902-8957-53651E24B451@freeradius.org>
References: <14CCBFD1-4136-4902-8957-53651E24B451@freeradius.org>
Message-ID: <a80081da-c487-7b96-f045-e7a0c1a2ba79@openssl.org>



On 23/01/2019 13:01, Arran Cudbard-Bell wrote:
> As per the subject line:
> 
> SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF)
> 
> does not seem to disable generation of stateless tickets with TLS 1.3:

No - nor does it disable *stateless* tickets with TLSv1.2. The purpose of the
above call is to disable session caching on the server. Since the whole point
about stateless tickets is to not require caching this has no effect on
stateless tickets. Therefore if SSL_OP_NO_TICKET has not been set then session
tickets will still be generated in TLSv1.2 even with the cache mode set to
SSL_SESS_CACHE_OFF.

However if you set the above and *also* set SSL_OP_NO_TICKET then you have
disabled both generation of stateless tickets and the creation of stateful
sessions in TLSv1.2, i.e. no sessions will be created at all in TLSv1.2

TLSv1.3 sessions are slightly different. There is no distinction at the protocol
level between stateful session ids and stateless tickets. Instead, when sessions
are created, they are always in the form of tickets. OpenSSL supports both
stateful and stateless tickets in TLSv1.3 (with the former consisting of a
session id wrapped up in a ticket). In order to maximise compatibility between
TLSv1.3 and TLSv1.2, SSL_OP_NO_TICKET in TLSv1.3 disables *stateless* tickets
only (not stateful ones).

So we might expect that if we disable the session cache (using
SSL_SESS_CACHE_OFF) *and* disable stateless ticket generation using
SSL_OP_NO_TICKET then no tickets at all would be generated in TLSv1.3. On
testing this that doesn't seem to be the case. This appears to be an OpenSSL bug
- and I assume that is the scenario you are hitting.

Interestingly I note that the tickets generated in such a case are useless. If
you attempt to resume using them then it doesn't work. So if your intention is
simply to prevent resumption at all costs, then you have achieved it already (in
spite of the bug that creates the tickets).

I created a new github issue to track this problem:

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

Matt

From a.cudbardb at freeradius.org  Wed Jan 23 15:12:28 2019
From: a.cudbardb at freeradius.org (Arran Cudbard-Bell)
Date: Wed, 23 Jan 2019 22:12:28 +0700
Subject: [openssl-users] SSL_CTX_set_session_cache_mode(ctx,
 SSL_SESS_CACHE_OFF); has no effect with TLS 1.3
In-Reply-To: <a80081da-c487-7b96-f045-e7a0c1a2ba79@openssl.org>
References: <14CCBFD1-4136-4902-8957-53651E24B451@freeradius.org>
 <a80081da-c487-7b96-f045-e7a0c1a2ba79@openssl.org>
Message-ID: <C26D47D9-2BC9-4187-BCA6-C800834FD1DB@freeradius.org>



> On Jan 23, 2019, at 9:57 PM, Matt Caswell <matt at openssl.org> wrote:
> 
> 
> 
> On 23/01/2019 13:01, Arran Cudbard-Bell wrote:
>> As per the subject line:
>> 
>> SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF)
>> 
>> does not seem to disable generation of stateless tickets with TLS 1.3:
> 
> No - nor does it disable *stateless* tickets with TLSv1.2. The purpose of the
> above call is to disable session caching on the server. Since the whole point
> about stateless tickets is to not require caching this has no effect on
> stateless tickets.

Apologies, I meant stateful tickets. SSL_OP_NO_TICKET was already set to disable stateless tickets.

> So we might expect that if we disable the session cache (using
> SSL_SESS_CACHE_OFF) *and* disable stateless ticket generation using
> SSL_OP_NO_TICKET then no tickets at all would be generated in TLSv1.3. On
> testing this that doesn't seem to be the case. This appears to be an OpenSSL bug
> - and I assume that is the scenario you are hitting.

OK, thanks for confirming.

> Interestingly I note that the tickets generated in such a case are useless. If
> you attempt to resume using them then it doesn't work. So if your intention is
> simply to prevent resumption at all costs, then you have achieved it already (in
> spite of the bug that creates the tickets).

That is interesting indeed, and good to know.

> I created a new github issue to track this problem:

Appreciated.

-Arran

From thiagu.m at gmail.com  Wed Jan 23 15:38:12 2019
From: thiagu.m at gmail.com (Thiagu Mohan)
Date: Wed, 23 Jan 2019 21:08:12 +0530
Subject: [openssl-users] Compiling openssl 1.0.2q for OS390-Unix
In-Reply-To: <CAA56SLzDkTtH56sPXOKOv2hSZC9OvvsbUK23-4e5=mF7xMJ9bg@mail.gmail.com>
References: <CAA56SLx=0y8NRHDZMCwM4PGf50B5noQKDbWLvOUa_ijuD1fLsg@mail.gmail.com>
 <CAA56SLw7jd4__0CJcY1Y=h3Lj9g4XXvySaX5dQCckqrbjbZsrQ@mail.gmail.com>
 <MW2PR18MB2090324EA6A226B2F3F221CBF9980@MW2PR18MB2090.namprd18.prod.outlook.com>
 <CAA56SLzDkTtH56sPXOKOv2hSZC9OvvsbUK23-4e5=mF7xMJ9bg@mail.gmail.com>
Message-ID: <CAA56SLyP0EGs1DnJ+XosFexog0X5ptr8qmEvkp4j86KyJV5_ng@mail.gmail.com>

---------- Forwarded message ---------
From: Thiagu Mohan <thiagu.m at gmail.com>
Date: Wed, Jan 23, 2019 at 4:39 PM
Subject: Re: [openssl-users] Compiling openssl 1.0.2q for OS390-Unix
To: Michael Wojcik <Michael.Wojcik at microfocus.com>


Yes I am using the option for Configure as OS390-Unix  only and using
c89.sh from tools directory in the openssl tar file.


Regards,
Thaigu



On Wed, Jan 23, 2019 at 2:50 AM Michael Wojcik <
Michael.Wojcik at microfocus.com> wrote:

> > From: Thiagu Mohan [mailto:thiagu.m at gmail.com]
> > Sent: Tuesday, January 22, 2019 13:02
> > To: Michael Wojcik
>
> Please reply to the mailing list, and not to me directly.
>
> > PKCS12_AUTHSAFES_it    these symbols must be typedefs.
>
> I don't know how you came to that conclusion, but it's wrong. A bit of
> digging shows the *_it symbols are used to provide access to global
> variables on platforms which do not automatically resolve non-function
> symbols in shared libraries/objects.
>
> > On Tue, Jan 22, 2019 at 11:24 PM Thiagu Mohan <thiagu.m at gmail.com>
> wrote:
>
> > I checked the source of 1.0.2n and 1.0.2q. these  symbols  are found in
> libeay.num
> > in both the sources and not in any other source code.
>
> Though the util/*.num files are included in the source tarballs, they're
> not really source code. They're created by mkdef.pl. Unfortunately
> mkdef.pl achieves a level of unreadableness that is impressive even by
> Perl standards, so that's not much help.
>
> I'll be frank: This isn't a problem I've run into before, and I don't have
> time at the moment to try to figure out what's causing it. Maybe someone
> who has more experience in this particular area will chime in.
>
> You did run Configure for the OS390-Unix target, right? And it's using the
> c89.sh wrapper from the tools directory?
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>

-- 
Thiagu Mohan


-- 
Thiagu Mohan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190123/c4999797/attachment.html>

From c.scharfenberg at francotyp.com  Thu Jan 24 09:19:03 2019
From: c.scharfenberg at francotyp.com (Scharfenberg, Carsten)
Date: Thu, 24 Jan 2019 09:19:03 +0000
Subject: [openssl-users] decrypt error
Message-ID: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>

Hello everybody,

I've just joined this group because I hope you guys can help me with my problem.

I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS 1.2 connections with client authentication.
The TLS handshake runs through fine. But then the server answers with a Decrypt Error Alert to the Finish message sent by the client.
How would I debug this error?
Is it possible that something is wrong with my certificates?

I've had a look into the source code. Unfortunately it's not so easy to read. It seems to me the alert is generated here:
ssl\statem\statem_lib.c:809 in function 'tls_process_finished' when the comparison of 'pkt' and 's->s3->tmp.peer_finish_md' fails.
Unfortunately I currently do not know what this means.

For detailed information I've appended a pcap file.



Regards,
C. Scharfenberg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190124/97ead4f1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: decrpyt_error.pcap
Type: application/octet-stream
Size: 7359 bytes
Desc: decrpyt_error.pcap
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190124/97ead4f1/attachment-0001.obj>

From matt at openssl.org  Thu Jan 24 10:20:07 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 24 Jan 2019 10:20:07 +0000
Subject: [openssl-users] decrypt error
In-Reply-To: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
References: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
Message-ID: <b6470929-a1ce-9d9f-6fd4-736652e387c1@openssl.org>



On 24/01/2019 09:19, Scharfenberg, Carsten wrote:
> Hello everybody,
> ?
> I?ve just joined this group because I hope you guys can help me with my problem.
> ?
> I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS 1.2
> connections with client authentication.
> The TLS handshake runs through fine. But then the server answers with a Decrypt
> Error Alert to the Finish message sent by the client.

What is the client? Is this also OpenSSL (and if so which version), or is it
something else?

> How would I debug this error?
> Is it possible that something is wrong with my certificates?

That seems unlikely. If there was something wrong with the certificates I would
have expected the handshake to fail before the point that it gets to.

> ?
> I?ve had a look into the source code. Unfortunately it?s not so easy to read. It
> seems to me the alert is generated here:
> ssl\statem\statem_lib.c:809 in function ?tls_process_finished? when the
> comparison of ?pkt? and ?s->s3->tmp.peer_finish_md? fails.
> Unfortunately I currently do not know what this means.

As each endpoint sends and receives handshake messages they both digest the
contents of those messages. The last step in the process is for each endpoint to
compare the digests that they created. They should be the same. If they are
different then that indicates that something has changed between one endpoint
sending one of those messages and its peer receiving it. This could in theory be
an active attacker. More likely though it could be due to some form of
corruption taking place somewhere. Some ideas as to the source of a possible
corruption:

- client application bug
- server application bug
- client TLS library bug
- server TLS library bug
- network "middlebox" corruption

I'd start by trying to isolate whether the problem is on the client side, the
server side, or the network. e.g. if the client is on the same host as the
server does the issue occur? Can you connect from a different client (different
application and/or different library or library version). Can the client connect
to other servers successfully.

Matt

From c.scharfenberg at francotyp.com  Thu Jan 24 11:00:03 2019
From: c.scharfenberg at francotyp.com (Scharfenberg, Carsten)
Date: Thu, 24 Jan 2019 11:00:03 +0000
Subject: [openssl-users] decrypt error
In-Reply-To: <442j7k01d1g064vh@zosma>
References: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
 <442j7k01d1g064vh@zosma>
Message-ID: <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>

Thanks for your answer, Matt.

Obviously the issue is caused by the server.

Currently I have two servers: 
1. The legacy server running IIS
2. The new server running HAProxy
I also have two clients:
1. the actual hardware client equipped with a hardware security module
2. curl using a client certificate that I have created according to the procedure that is used for the hardware device above

Now the picture is: both clients work with the legacy server but none of them work with the new HAProxy server.

BTW: if you have a detailed look at my provided pcap you will notice that the client certificate is expired. I've fixed this - without change in the outcom.

Regards,
Carsten

On 24/01/2019 09:19, Scharfenberg, Carsten wrote:
> Hello everybody,
> ?
> I've just joined this group because I hope you guys can help me with my problem.
> ?
> I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS 1.2
> connections with client authentication.
> The TLS handshake runs through fine. But then the server answers with a Decrypt
> Error Alert to the Finish message sent by the client.

What is the client? Is this also OpenSSL (and if so which version), or is it
something else?

> How would I debug this error?
> Is it possible that something is wrong with my certificates?

That seems unlikely. If there was something wrong with the certificates I would
have expected the handshake to fail before the point that it gets to.

> ?
> I've had a look into the source code. Unfortunately it's not so easy to read. It
> seems to me the alert is generated here:
> ssl\statem\statem_lib.c:809 in function 'tls_process_finished' when the
> comparison of 'pkt' and 's->s3->tmp.peer_finish_md' fails.
> Unfortunately I currently do not know what this means.

As each endpoint sends and receives handshake messages they both digest the
contents of those messages. The last step in the process is for each endpoint to
compare the digests that they created. They should be the same. If they are
different then that indicates that something has changed between one endpoint
sending one of those messages and its peer receiving it. This could in theory be
an active attacker. More likely though it could be due to some form of
corruption taking place somewhere. Some ideas as to the source of a possible
corruption:

- client application bug
- server application bug
- client TLS library bug
- server TLS library bug
- network "middlebox" corruption

I'd start by trying to isolate whether the problem is on the client side, the
server side, or the network. e.g. if the client is on the same host as the
server does the issue occur? Can you connect from a different client (different
application and/or different library or library version). Can the client connect
to other servers successfully.

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

From hkario at redhat.com  Thu Jan 24 14:23:24 2019
From: hkario at redhat.com (Hubert Kario)
Date: Thu, 24 Jan 2019 15:23:24 +0100
Subject: [openssl-users] decrypt error
In-Reply-To: <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>
References: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
 <442j7k01d1g064vh@zosma>
 <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>
Message-ID: <1906183.SQB1eLdFod@pintsize.usersys.redhat.com>

On Thursday, 24 January 2019 12:00:03 CET Scharfenberg, Carsten wrote:
> Thanks for your answer, Matt.
> 
> Obviously the issue is caused by the server.

the issue still could be in a client and it was just exposed by the new, more 
strict server behaviour
 
> Currently I have two servers:
> 1. The legacy server running IIS
> 2. The new server running HAProxy
> I also have two clients:
> 1. the actual hardware client equipped with a hardware security module
> 2. curl using a client certificate that I have created according to the
> procedure that is used for the hardware device above
> 
> Now the picture is: both clients work with the legacy server but none of
> them work with the new HAProxy server.
> 
> BTW: if you have a detailed look at my provided pcap you will notice that
> the client certificate is expired. I've fixed this - without change in the
> outcom.
> 
> Regards,
> Carsten
> 
> On 24/01/2019 09:19, Scharfenberg, Carsten wrote:
> > Hello everybody,
> >  
> > I've just joined this group because I hope you guys can help me with my
> > problem. 
> > I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve
> > TLS 1.2 connections with client authentication.
> > The TLS handshake runs through fine. But then the server answers with a
> > Decrypt Error Alert to the Finish message sent by the client.
> 
> What is the client? Is this also OpenSSL (and if so which version), or is it
> something else?
> 
> > How would I debug this error?
> > Is it possible that something is wrong with my certificates?
> 
> That seems unlikely. If there was something wrong with the certificates I
> would have expected the handshake to fail before the point that it gets to.
> >  
> > I've had a look into the source code. Unfortunately it's not so easy to
> > read. It seems to me the alert is generated here:
> > ssl\statem\statem_lib.c:809 in function 'tls_process_finished' when the
> > comparison of 'pkt' and 's->s3->tmp.peer_finish_md' fails.
> > Unfortunately I currently do not know what this means.
> 
> As each endpoint sends and receives handshake messages they both digest the
> contents of those messages. The last step in the process is for each
> endpoint to compare the digests that they created. They should be the same.
> If they are different then that indicates that something has changed
> between one endpoint sending one of those messages and its peer receiving
> it. This could in theory be an active attacker. More likely though it could
> be due to some form of corruption taking place somewhere. Some ideas as to
> the source of a possible corruption:
> 
> - client application bug
> - server application bug
> - client TLS library bug
> - server TLS library bug
> - network "middlebox" corruption
> 
> I'd start by trying to isolate whether the problem is on the client side,
> the server side, or the network. e.g. if the client is on the same host as
> the server does the issue occur? Can you connect from a different client
> (different application and/or different library or library version). Can
> the client connect to other servers successfully.
> 
> Matt


-- 
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/20190124/7aef2fc5/attachment.sig>

From matt at openssl.org  Thu Jan 24 15:33:42 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 24 Jan 2019 15:33:42 +0000
Subject: [openssl-users] decrypt error
In-Reply-To: <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>
References: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
 <442j7k01d1g064vh@zosma>
 <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>
Message-ID: <6eba099f-9e6f-357a-431e-ad3d1adc0f50@openssl.org>



On 24/01/2019 11:00, Scharfenberg, Carsten wrote:
> Thanks for your answer, Matt.
> 
> Obviously the issue is caused by the server.
> 
> Currently I have two servers: 
> 1. The legacy server running IIS
> 2. The new server running HAProxy
> I also have two clients:
> 1. the actual hardware client equipped with a hardware security module
> 2. curl using a client certificate that I have created according to the procedure that is used for the hardware device above
> 
> Now the picture is: both clients work with the legacy server but none of them work with the new HAProxy server.

Hmmm. It's possible that it is still a client issue if the negotiated
extensions/ciphersuite/protocol version etc differ between the connection for
the old server and the new server. You might want to experiment with different
ciphersuite/group/sigalgs etc settings on the server to see if there is
sensitivity there to this issue.

Matt



> 
> BTW: if you have a detailed look at my provided pcap you will notice that the client certificate is expired. I've fixed this - without change in the outcom.
> 
> Regards,
> Carsten
> 
> On 24/01/2019 09:19, Scharfenberg, Carsten wrote:
>> Hello everybody,
>> ?
>> I've just joined this group because I hope you guys can help me with my problem.
>> ?
>> I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS 1.2
>> connections with client authentication.
>> The TLS handshake runs through fine. But then the server answers with a Decrypt
>> Error Alert to the Finish message sent by the client.
> 
> What is the client? Is this also OpenSSL (and if so which version), or is it
> something else?
> 
>> How would I debug this error?
>> Is it possible that something is wrong with my certificates?
> 
> That seems unlikely. If there was something wrong with the certificates I would
> have expected the handshake to fail before the point that it gets to.
> 
>> ?
>> I've had a look into the source code. Unfortunately it's not so easy to read. It
>> seems to me the alert is generated here:
>> ssl\statem\statem_lib.c:809 in function 'tls_process_finished' when the
>> comparison of 'pkt' and 's->s3->tmp.peer_finish_md' fails.
>> Unfortunately I currently do not know what this means.
> 
> As each endpoint sends and receives handshake messages they both digest the
> contents of those messages. The last step in the process is for each endpoint to
> compare the digests that they created. They should be the same. If they are
> different then that indicates that something has changed between one endpoint
> sending one of those messages and its peer receiving it. This could in theory be
> an active attacker. More likely though it could be due to some form of
> corruption taking place somewhere. Some ideas as to the source of a possible
> corruption:
> 
> - client application bug
> - server application bug
> - client TLS library bug
> - server TLS library bug
> - network "middlebox" corruption
> 
> I'd start by trying to isolate whether the problem is on the client side, the
> server side, or the network. e.g. if the client is on the same host as the
> server does the issue occur? Can you connect from a different client (different
> application and/or different library or library version). Can the client connect
> to other servers successfully.
> 
> Matt
> 

From matt at openssl.org  Thu Jan 24 15:38:03 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 24 Jan 2019 15:38:03 +0000
Subject: [openssl-users] decrypt error
In-Reply-To: <6eba099f-9e6f-357a-431e-ad3d1adc0f50@openssl.org>
References: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
 <442j7k01d1g064vh@zosma>
 <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>
 <6eba099f-9e6f-357a-431e-ad3d1adc0f50@openssl.org>
Message-ID: <f1d38bb8-050e-e297-d156-4decdbf9b940@openssl.org>



On 24/01/2019 15:33, Matt Caswell wrote:
> 
> 
> On 24/01/2019 11:00, Scharfenberg, Carsten wrote:
>> Thanks for your answer, Matt.
>>
>> Obviously the issue is caused by the server.
>>
>> Currently I have two servers: 
>> 1. The legacy server running IIS
>> 2. The new server running HAProxy
>> I also have two clients:
>> 1. the actual hardware client equipped with a hardware security module
>> 2. curl using a client certificate that I have created according to the procedure that is used for the hardware device above
>>
>> Now the picture is: both clients work with the legacy server but none of them work with the new HAProxy server.
> 
> Hmmm. It's possible that it is still a client issue if the negotiated
> extensions/ciphersuite/protocol version etc differ between the connection for
> the old server and the new server. You might want to experiment with different
> ciphersuite/group/sigalgs etc settings on the server to see if there is
> sensitivity there to this issue.

Another thought - are connections successful if client auth is NOT used?

Matt

> 
> Matt
> 
> 
> 
>>
>> BTW: if you have a detailed look at my provided pcap you will notice that the client certificate is expired. I've fixed this - without change in the outcom.
>>
>> Regards,
>> Carsten
>>
>> On 24/01/2019 09:19, Scharfenberg, Carsten wrote:
>>> Hello everybody,
>>> ?
>>> I've just joined this group because I hope you guys can help me with my problem.
>>> ?
>>> I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS 1.2
>>> connections with client authentication.
>>> The TLS handshake runs through fine. But then the server answers with a Decrypt
>>> Error Alert to the Finish message sent by the client.
>>
>> What is the client? Is this also OpenSSL (and if so which version), or is it
>> something else?
>>
>>> How would I debug this error?
>>> Is it possible that something is wrong with my certificates?
>>
>> That seems unlikely. If there was something wrong with the certificates I would
>> have expected the handshake to fail before the point that it gets to.
>>
>>> ?
>>> I've had a look into the source code. Unfortunately it's not so easy to read. It
>>> seems to me the alert is generated here:
>>> ssl\statem\statem_lib.c:809 in function 'tls_process_finished' when the
>>> comparison of 'pkt' and 's->s3->tmp.peer_finish_md' fails.
>>> Unfortunately I currently do not know what this means.
>>
>> As each endpoint sends and receives handshake messages they both digest the
>> contents of those messages. The last step in the process is for each endpoint to
>> compare the digests that they created. They should be the same. If they are
>> different then that indicates that something has changed between one endpoint
>> sending one of those messages and its peer receiving it. This could in theory be
>> an active attacker. More likely though it could be due to some form of
>> corruption taking place somewhere. Some ideas as to the source of a possible
>> corruption:
>>
>> - client application bug
>> - server application bug
>> - client TLS library bug
>> - server TLS library bug
>> - network "middlebox" corruption
>>
>> I'd start by trying to isolate whether the problem is on the client side, the
>> server side, or the network. e.g. if the client is on the same host as the
>> server does the issue occur? Can you connect from a different client (different
>> application and/or different library or library version). Can the client connect
>> to other servers successfully.
>>
>> Matt
>>

From c.scharfenberg at francotyp.com  Thu Jan 24 15:55:49 2019
From: c.scharfenberg at francotyp.com (Scharfenberg, Carsten)
Date: Thu, 24 Jan 2019 15:55:49 +0000
Subject: [openssl-users] decrypt error
In-Reply-To: <f1d38bb8-050e-e297-d156-4decdbf9b940@openssl.org>
References: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
 <442j7k01d1g064vh@zosma>
 <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>
 <6eba099f-9e6f-357a-431e-ad3d1adc0f50@openssl.org>
 <f1d38bb8-050e-e297-d156-4decdbf9b940@openssl.org>
Message-ID: <A0075AC8F849D648B8077B454DA0D87E2CD3A10D@ES-2010.francotyp.com>

Yes, it works if I deactivate client auth.
Concerning the cipher: I use one specific cipher on server and on client side. This is the only cipher supported by the actual hardware client.
Concerning the sigalg: I've had big trouble with this because due to bug in the client I need to restrict the sigalgs offered by the server. This is not possible with haproxy. But it is possible with openssl.cnf since version 1.1.1. This is why I've installed haproxy and openssl from Debian testing.
So I'm very confident about the cipher suite and the signature algorithm.

I've just created a new certificate hierarchy. Et voila: it works.
So obviously this issue is certificate-related.
Still I have to figure out what is wrong with the old certificates because I cannot replace them in the productive environment.
My next step will be to create new hierarchy again that matches the original hierarchy as close as possible (including constraints and extensions).

-----Urspr?ngliche Nachricht-----
Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Matt Caswell
Gesendet: Donnerstag, 24. Januar 2019 16:38
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] decrypt error



On 24/01/2019 15:33, Matt Caswell wrote:
> 
> 
> On 24/01/2019 11:00, Scharfenberg, Carsten wrote:
>> Thanks for your answer, Matt.
>>
>> Obviously the issue is caused by the server.
>>
>> Currently I have two servers: 
>> 1. The legacy server running IIS
>> 2. The new server running HAProxy
>> I also have two clients:
>> 1. the actual hardware client equipped with a hardware security module
>> 2. curl using a client certificate that I have created according to the procedure that is used for the hardware device above
>>
>> Now the picture is: both clients work with the legacy server but none of them work with the new HAProxy server.
> 
> Hmmm. It's possible that it is still a client issue if the negotiated
> extensions/ciphersuite/protocol version etc differ between the connection for
> the old server and the new server. You might want to experiment with different
> ciphersuite/group/sigalgs etc settings on the server to see if there is
> sensitivity there to this issue.

Another thought - are connections successful if client auth is NOT used?

Matt

> 
> Matt
> 
> 
> 
>>
>> BTW: if you have a detailed look at my provided pcap you will notice that the client certificate is expired. I've fixed this - without change in the outcom.
>>
>> Regards,
>> Carsten
>>
>> On 24/01/2019 09:19, Scharfenberg, Carsten wrote:
>>> Hello everybody,
>>> ?
>>> I've just joined this group because I hope you guys can help me with my problem.
>>> ?
>>> I'm using haproxy 1.8.17 and openssl 1.1.1a from Debian testing to serve TLS 1.2
>>> connections with client authentication.
>>> The TLS handshake runs through fine. But then the server answers with a Decrypt
>>> Error Alert to the Finish message sent by the client.
>>
>> What is the client? Is this also OpenSSL (and if so which version), or is it
>> something else?
>>
>>> How would I debug this error?
>>> Is it possible that something is wrong with my certificates?
>>
>> That seems unlikely. If there was something wrong with the certificates I would
>> have expected the handshake to fail before the point that it gets to.
>>
>>> ?
>>> I've had a look into the source code. Unfortunately it's not so easy to read. It
>>> seems to me the alert is generated here:
>>> ssl\statem\statem_lib.c:809 in function 'tls_process_finished' when the
>>> comparison of 'pkt' and 's->s3->tmp.peer_finish_md' fails.
>>> Unfortunately I currently do not know what this means.
>>
>> As each endpoint sends and receives handshake messages they both digest the
>> contents of those messages. The last step in the process is for each endpoint to
>> compare the digests that they created. They should be the same. If they are
>> different then that indicates that something has changed between one endpoint
>> sending one of those messages and its peer receiving it. This could in theory be
>> an active attacker. More likely though it could be due to some form of
>> corruption taking place somewhere. Some ideas as to the source of a possible
>> corruption:
>>
>> - client application bug
>> - server application bug
>> - client TLS library bug
>> - server TLS library bug
>> - network "middlebox" corruption
>>
>> I'd start by trying to isolate whether the problem is on the client side, the
>> server side, or the network. e.g. if the client is on the same host as the
>> server does the issue occur? Can you connect from a different client (different
>> application and/or different library or library version). Can the client connect
>> to other servers successfully.
>>
>> Matt
>>
-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From a.cudbardb at freeradius.org  Thu Jan 24 16:09:40 2019
From: a.cudbardb at freeradius.org (Arran Cudbard-Bell)
Date: Thu, 24 Jan 2019 23:09:40 +0700
Subject: [openssl-users] SSL_read() returns -1,
 and SSL_read_ex does not update readbytes where a record containing
 a session ticket is being read (TLS 1.3)
In-Reply-To: <d504a160-60be-4d65-eaef-03fd8c3ad57d@openssl.org>
References: <E237621D-28C5-4437-B287-360822E24D82@freeradius.org>
 <d504a160-60be-4d65-eaef-03fd8c3ad57d@openssl.org>
Message-ID: <BE1A5F7C-D899-46EF-9C55-B67AB45BD5C9@freeradius.org>

> On 23/01/2019 14:04, Arran Cudbard-Bell wrote:
>> I'm working with wpa_supplicant to try and fix up its EAP-TTLS and EAP-PEAP
>> implementations to work correctly with TLS 1.3 and session tickets.
>> 
>> Where a new_session_ticket message is sent after client/server finish, calls
>> to SSL_read() result in the new_session_ticket message being processed
>> correctly, but SSL_read() returns -1 if no application_data is available in
>> the input BIO. SSL_read_ex() returns 0, but readbytes isn't updated to
>> reflect the number of bytes consumed whilst processing the session tickets.
> 
> This is intended behaviour. SSL_read() returns the number of plaintext
> application data bytes that have been populated in the provided buffer
> (similarly for readbytes).

OK, confirmed.  There was something in our code base that lead me to believe SSL_read() was returning the number of bytes consumed when processing handshake messages. I've just confirmed this is not the case and it always returns -1 during the handshake phase.

> If no application data is available then you get the
> -1 (for SSL_read()) or 0 (for SSL_read_ex()) return code. You also get that
> return code for other types of issues, and you are supposed to call
> SSL_get_error() to interpret it.

In this case SSL_get_error() returns 2 (SSL_ERROR_WANT_READ) with either SSL_MODE_AUTO_RETRY on or /off.

> Note that by default OpenSSL sets SSL_MODE_AUTO_RETRY in 1.1.1 (which it didn't
> in 1.1.0). This should mean that it automatically tries again to read
> application data without returning an error. Have you switched
> SSL_MODE_AUTO_RETRY off?

It was left at defaults for the initial tests.

>> It seems to be that SSL_read() should return a positive integer representing
>> the number of bytes read from the BIO whilst processing the session tickets,
>> and SSL_read_ex should update readbytes to the number of bytes read from the
>> BIO whilst processing the session tickets, as is done with other handshake
>> messages.
> 
> This is not correct. SSL_read()/SSL_read_ex() only ever provide the number of
> application data bytes that have been read, irrespective of how many bytes were
> read from the underlying BIO.

Would call BIO_pending() before/after the call to SSL_read() be the best way to determine the number of bytes consumed by SSL_read()?

We could use this to determine what SSL_ERROR_WANT_READ is indicating.  As it seems  SSL_ERROR_WANT_READ could indicate two conditions in this scenario:

1) No pending bytes - Additional handshake messages were processed, there's an expectation of additional application_data, but no hint that more application_data will be forthcoming.
2) Pending bytes - There is an incomplete record that needs processing.  Additional data should be fed into the BIO.

-Arran

From matt at openssl.org  Thu Jan 24 16:27:19 2019
From: matt at openssl.org (Matt Caswell)
Date: Thu, 24 Jan 2019 16:27:19 +0000
Subject: [openssl-users] SSL_read() returns -1,
 and SSL_read_ex does not update readbytes where a record containing
 a session ticket is being read (TLS 1.3)
In-Reply-To: <BE1A5F7C-D899-46EF-9C55-B67AB45BD5C9@freeradius.org>
References: <E237621D-28C5-4437-B287-360822E24D82@freeradius.org>
 <d504a160-60be-4d65-eaef-03fd8c3ad57d@openssl.org>
 <BE1A5F7C-D899-46EF-9C55-B67AB45BD5C9@freeradius.org>
Message-ID: <d895b8a3-3eba-6c99-ff4c-e078ead7099e@openssl.org>



>> If no application data is available then you get the -1 (for SSL_read()) or
>> 0 (for SSL_read_ex()) return code. You also get that return code for other
>> types of issues, and you are supposed to call SSL_get_error() to interpret
>> it.
> 
> In this case SSL_get_error() returns 2 (SSL_ERROR_WANT_READ) with either
> SSL_MODE_AUTO_RETRY on or /off.
> 
>> Note that by default OpenSSL sets SSL_MODE_AUTO_RETRY in 1.1.1 (which it
>> didn't in 1.1.0). This should mean that it automatically tries again to
>> read application data without returning an error. Have you switched 
>> SSL_MODE_AUTO_RETRY off?
> 
> It was left at defaults for the initial tests.

If SSL_MODE_AUTO_RETRY is on, and you're getting SSL_ERROR_WANT_READ this means
there is no application data available from the underlying BIO yet. OpenSSL may
have processed intervening session tickets, but if so it has then immediately
tried to read application data and there wasn't any there.

> 
>>> It seems to be that SSL_read() should return a positive integer
>>> representing the number of bytes read from the BIO whilst processing the
>>> session tickets, and SSL_read_ex should update readbytes to the number of
>>> bytes read from the BIO whilst processing the session tickets, as is done
>>> with other handshake messages.
>> 
>> This is not correct. SSL_read()/SSL_read_ex() only ever provide the number
>> of application data bytes that have been read, irrespective of how many
>> bytes were read from the underlying BIO.
> 
> Would call BIO_pending() before/after the call to SSL_read() be the best way
> to determine the number of bytes consumed by SSL_read()?
> 
> We could use this to determine what SSL_ERROR_WANT_READ is indicating.  As it
> seems  SSL_ERROR_WANT_READ could indicate two conditions in this scenario:
> 
> 1) No pending bytes - Additional handshake messages were processed, there's
> an expectation of additional application_data, but no hint that more
> application_data will be forthcoming.

> 2) Pending bytes - There is an
> incomplete record that needs processing.  Additional data should be fed into
> the BIO.

Probably you want to use SSL_pending() and/or SSL_has_pending(). From the docs:

SSL_pending() returns the number of bytes which have been processed, buffered
and are available inside B<ssl> for immediate read.

...

SSL_has_pending() returns 1 if B<s> has buffered data (whether processed or
unprocessed) and 0 otherwise.

See the following for full details:

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

Matt

From john.hughes at secid.co.uk  Thu Jan 24 20:26:41 2019
From: john.hughes at secid.co.uk (john.hughes at secid.co.uk)
Date: Thu, 24 Jan 2019 20:26:41 -0000
Subject: [openssl-users] ec_point_is_compat
Message-ID: <018801d4b423$1dbdcca0$593965e0$@secid.co.uk>

In a test harness I'm writing I'm adding in a facility to check the validity
of an EC public key according to the 4 tests of X9.62.

 

The curve and point I supply to EC_POINT_is_at_infinity works fine.

 

However, when I come to use EC_POINT_is_on_curve it fails. The error return
indicates the error is "incompatible objects". Looking through the openssl
source indicates that the error is a result of failing one of the tests in
the inline function ec_point_is_compat.  In this function there are four
simple tests - most of which pertains to looking at the values of curve_name
in the EC_POINT and EC_GROUP structures.  So I thought, quite simply, look
at what these two structures hold pertaining to the member curve_name - and
then I can figure out what I'm doing wrong.

 

The openssl interface has the function EC_GROUP_get_curve_name() which I
used to show that curve name was 409 (for NIST P192) and 415 (for NIST
P256). But to my surprise there was no function of
EC_POINT_get_curve_name().

 

Has any one any suggestions why my code is failing the ec_point_is_compat
tests and how to get hold of the values of meth and curve_name in my
EC_GROUP and EC_POINT structures so I can determine why the checks are
failing

 

 

John

 

 

 

 

 

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

From jb-openssl at wisemo.com  Fri Jan 25 01:16:52 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 25 Jan 2019 02:16:52 +0100
Subject: [openssl-users] decrypt error
In-Reply-To: <A0075AC8F849D648B8077B454DA0D87E2CD3A10D@ES-2010.francotyp.com>
References: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
 <442j7k01d1g064vh@zosma>
 <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>
 <6eba099f-9e6f-357a-431e-ad3d1adc0f50@openssl.org>
 <f1d38bb8-050e-e297-d156-4decdbf9b940@openssl.org>
 <A0075AC8F849D648B8077B454DA0D87E2CD3A10D@ES-2010.francotyp.com>
Message-ID: <80819bfc-b31e-e930-f379-7c0d79bc12d5@wisemo.com>

Since this seems to be a certificate issue, would it be possible
to make the server log all the certificate checking steps and
errors with the failing certificates.

One obvious test would be to try connecting to the "openssl s_server"
utility with a similar configuration and lots of debug options. Another
would be to install all the debug symbols and running haproxy under a
debugger with strategically set breakpoints to look at the execution stack
when errors are reported or validation occurs.

On 24/01/2019 16:55, Scharfenberg, Carsten wrote:
> Yes, it works if I deactivate client auth.
> Concerning the cipher: I use one specific cipher on server and on client side. This is the only cipher supported by the actual hardware client.
> Concerning the sigalg: I've had big trouble with this because due to bug in the client I need to restrict the sigalgs offered by the server. This is not possible with haproxy. But it is possible with openssl.cnf since version 1.1.1. This is why I've installed haproxy and openssl from Debian testing.
> So I'm very confident about the cipher suite and the signature algorithm.
>
> I've just created a new certificate hierarchy. Et voila: it works.
> So obviously this issue is certificate-related.
> Still I have to figure out what is wrong with the old certificates because I cannot replace them in the productive environment.
> My next step will be to create new hierarchy again that matches the original hierarchy as close as possible (including constraints and extensions).
>

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 c.scharfenberg at francotyp.com  Fri Jan 25 10:42:54 2019
From: c.scharfenberg at francotyp.com (Scharfenberg, Carsten)
Date: Fri, 25 Jan 2019 10:42:54 +0000
Subject: [openssl-users] decrypt error
In-Reply-To: <80819bfc-b31e-e930-f379-7c0d79bc12d5@wisemo.com>
References: <A0075AC8F849D648B8077B454DA0D87E2CD3A03C@ES-2010.francotyp.com>
 <442j7k01d1g064vh@zosma>
 <A0075AC8F849D648B8077B454DA0D87E2CD3A075@ES-2010.francotyp.com>
 <6eba099f-9e6f-357a-431e-ad3d1adc0f50@openssl.org>
 <f1d38bb8-050e-e297-d156-4decdbf9b940@openssl.org>
 <A0075AC8F849D648B8077B454DA0D87E2CD3A10D@ES-2010.francotyp.com>
 <80819bfc-b31e-e930-f379-7c0d79bc12d5@wisemo.com>
Message-ID: <A0075AC8F849D648B8077B454DA0D87E2CD3A271@ES-2010.francotyp.com>

Yes, it is a certificate error: a very stupid one.
I've used the wrong CA cert - from a different hierarchy.

I'm sorry for the hassle.
Nevertheless thanks for your support.

Carsten

-----Urspr?ngliche Nachricht-----
Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Jakob Bohm via openssl-users
Gesendet: Freitag, 25. Januar 2019 02:17
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] decrypt error

Since this seems to be a certificate issue, would it be possible
to make the server log all the certificate checking steps and
errors with the failing certificates.

One obvious test would be to try connecting to the "openssl s_server"
utility with a similar configuration and lots of debug options. Another
would be to install all the debug symbols and running haproxy under a
debugger with strategically set breakpoints to look at the execution stack
when errors are reported or validation occurs.

On 24/01/2019 16:55, Scharfenberg, Carsten wrote:
> Yes, it works if I deactivate client auth.
> Concerning the cipher: I use one specific cipher on server and on client side. This is the only cipher supported by the actual hardware client.
> Concerning the sigalg: I've had big trouble with this because due to bug in the client I need to restrict the sigalgs offered by the server. This is not possible with haproxy. But it is possible with openssl.cnf since version 1.1.1. This is why I've installed haproxy and openssl from Debian testing.
> So I'm very confident about the cipher suite and the signature algorithm.
>
> I've just created a new certificate hierarchy. Et voila: it works.
> So obviously this issue is certificate-related.
> Still I have to figure out what is wrong with the old certificates because I cannot replace them in the productive environment.
> My next step will be to create new hierarchy again that matches the original hierarchy as close as possible (including constraints and extensions).
>

Enjoy

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

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

From andrew.tucker at salesforce.com  Fri Jan 25 20:16:02 2019
From: andrew.tucker at salesforce.com (Andrew Tucker)
Date: Fri, 25 Jan 2019 12:16:02 -0800
Subject: [openssl-users] issue with EVP_EncryptUpdate in XTS mode?
Message-ID: <CAJ3attrd=RpmJ39Yg2Z7dyDLy6LoW4EsgEEgXWkLET=ZyogwxA@mail.gmail.com>

I was doing some comparisons of XTS and GCM mode using the EVP APIs and
found a discrepancy that seems to be an issue with XTS.

In GCM mode if the buffer is encrypted in one call to EVP_EncryptUpdate or
with several calls with smaller buffers the resulting ciphertext is the
same, as I would expect.   With XTS mode, calling EVP_EncryptUpdate results
in the same ciphertext for the same plaintext and does not match the
results when the buffer is encrypted with one call to EVP_EncryptUpdate.

I would expect that the counter is incremented in both XTS and GCM mode in
the same way and that in both cases the output would match regardless of
the encryption block size.

A simple repro test is attached.    If you run it you can see that the
output "GCM in one block" matches the output for "GCM in 16 byte blocks"
and the outputs do not match for XTS.

I am using OpenSSL v1.02p but I have tried with other versions and got the
same results.

Am I misunderstanding the use of XTS mode or is this an issue with OpenSSL?

Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190125/d0db3ddb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xtsgcmtest.c
Type: application/octet-stream
Size: 3354 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190125/d0db3ddb/attachment.obj>

From kurt at roeckx.be  Fri Jan 25 22:14:03 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 25 Jan 2019 23:14:03 +0100
Subject: [openssl-users] SSL_read() returns -1,
 and SSL_read_ex does not update readbytes where a record containing
 a session ticket is being read (TLS 1.3)
In-Reply-To: <BE1A5F7C-D899-46EF-9C55-B67AB45BD5C9@freeradius.org>
References: <E237621D-28C5-4437-B287-360822E24D82@freeradius.org>
 <d504a160-60be-4d65-eaef-03fd8c3ad57d@openssl.org>
 <BE1A5F7C-D899-46EF-9C55-B67AB45BD5C9@freeradius.org>
Message-ID: <20190125221403.GA18016@roeckx.be>

On Thu, Jan 24, 2019 at 11:09:40PM +0700, Arran Cudbard-Bell wrote:
> We could use this to determine what SSL_ERROR_WANT_READ is indicating.  As it seems  SSL_ERROR_WANT_READ could indicate two conditions in this scenario:
> 
> 1) No pending bytes - Additional handshake messages were processed, there's an expectation of additional application_data, but no hint that more application_data will be forthcoming.
> 2) Pending bytes - There is an incomplete record that needs processing.  Additional data should be fed into the BIO.

If you call SSL_read() and you get SSL_ERROR_WANT_READ it means
we can't return any application data at this time. Try again later.

With SSL_MODE_AUTO_RETRY off, it could be that calling it directly
again can now return application data. If it's on, it means it
wasn't available yet and you need to wait for it to arrive.

If you use an fd BIO and select(), SSL_ERROR_WANT_READ just means
you should wait with select() for more data.


Kurt


From matt at openssl.org  Sat Jan 26 00:17:56 2019
From: matt at openssl.org (Matt Caswell)
Date: Sat, 26 Jan 2019 00:17:56 +0000
Subject: [openssl-users] issue with EVP_EncryptUpdate in XTS mode?
In-Reply-To: <CAJ3attrd=RpmJ39Yg2Z7dyDLy6LoW4EsgEEgXWkLET=ZyogwxA@mail.gmail.com>
References: <CAJ3attrd=RpmJ39Yg2Z7dyDLy6LoW4EsgEEgXWkLET=ZyogwxA@mail.gmail.com>
Message-ID: <ae4d2fde-2389-4b86-13b1-087aac46fb94@openssl.org>



On 25/01/2019 20:16, Andrew Tucker wrote:
> I was doing some comparisons of XTS and GCM mode using the EVP APIs and found a
> discrepancy that seems to be an issue with XTS.
> 
> In GCM mode if the buffer is encrypted in one call to EVP_EncryptUpdate or with
> several calls with smaller buffers the resulting ciphertext is the same, as I
> would expect.? ?With XTS mode, calling EVP_EncryptUpdate results in the same
> ciphertext for the same plaintext and does not match the results when the buffer
> is encrypted with one call to EVP_EncryptUpdate.
> 
> I would expect that the counter is incremented in both XTS and GCM mode in the
> same way and that in both cases the output would match regardless of the
> encryption block size.
> 
> A simple repro test is attached.? ? If you run it you can see that the output
> "GCM in one block" matches the output for "GCM in 16 byte blocks" and the
> outputs do not match for XTS.
> 
> I am using OpenSSL v1.02p but I have tried with other versions and got the same
> results.
> 
> Am I misunderstanding the use of XTS mode or is this an issue with OpenSSL?

The documentation for XTS mode seems to be particularly dreadful (i.e.
practically non-existent).

XTS mode was designed for disk encryption and works quite differently to modes
like GCM. XTS encrypts blocks at a time where each block has a separate "tweak"
value (and by "block" here I'm talking about disk blocks not encryption blocks).
There is no "streaming" concept - there is not necessarily any relationship with
the tweak from one block to be encrypted to the next one. AFAICT from code
inspection you are expected to set the tweak in the IV field and then encrypt an
entire (disk) block in one go with EVP_EncryptUpdate().

This seems to be supported by this post from Steve Henson where he describes the
XTS implementation as not being able to stream and as a "one shot" version:

http://openssl.6102.n7.nabble.com/patch-AES-XTS-supporting-custom-iv-from-openssl-enc-command-tt51949.html#a52009

In this later post in the same thread Steve talks about calling
EVP_EncryptInit_ex again with all the params set to NULL except the ctx and iv
(i.e. tweak) in order to set a new tweak and then call EVP_EncryptUpdate again.

http://openssl.6102.n7.nabble.com/patch-AES-XTS-supporting-custom-iv-from-openssl-enc-command-tp51949p52006.html

In other words I think you are supposed to use it something like this (error
handling omitted for brevity):

EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();

EVP_EncryptInit_ex(ctx, EVP_aes_256_xts(), NULL, aes_key, NULL);

EVP_EncryptInit_ex(ctx, NULL, NULL, NULL, tweak1);
EVP_EncryptUpdate(ctx, out, &outl, block1, blocklen1);
EVP_EncryptInit_ex(ctx, NULL, NULL, NULL, tweak2);
EVP_EncryptUpdate(ctx, out, &outl, block2, blocklen2);
EVP_EncryptInit_ex(ctx, NULL, NULL, NULL, tweak3);
EVP_EncryptUpdate(ctx, out, &outl, block3, blocklen3);

That really needs to go in the man pages.

Matt






From prithiraj.das at gmail.com  Sun Jan 27 17:43:14 2019
From: prithiraj.das at gmail.com (prithiraj das)
Date: Sun, 27 Jan 2019 23:13:14 +0530
Subject: [openssl-users] RSA Digital Signing
Message-ID: <CAPSktiO9ohfykyuWmZ3YOVf3pEdoaB3ZcXd=_q0=ChFBBsOrjg@mail.gmail.com>

Hi All,

Using OpenSSL, I need to implement digital signing. My approach as of now
is:
1)  At the sender side, generate the hash of the data using sha256.
2)  Encrypt the hash of the data using RSA Private key for the purpose of
signing. Send this encrypted hash and the data from Step 1 to the receiverr
side.
3)  At the receiver's end, Decrypt the signed data(encrypted hash) using
the corresponding RSA Public key.
4)  Generate hash of the data and verify the decrypted content against this
hash to verify the signature

I was thinking of using RSA_private_encrypt() method to do the signing and
RSA_public_decrypt() method to decrypt the signed hash using the
corresponding RSA public key. Would the above be a bad approach especially
when it comes to using the methods mentioned ? Please recommend the methods
to be used that would be better for the purpose of digital signing and
verification using sha256 and RSA keys

Thanks and Regards,
Prithiraj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190127/e8526656/attachment-0001.html>

From openssl-users at dukhovni.org  Sun Jan 27 18:22:27 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 27 Jan 2019 13:22:27 -0500
Subject: [openssl-users] RSA Digital Signing
In-Reply-To: <CAPSktiO9ohfykyuWmZ3YOVf3pEdoaB3ZcXd=_q0=ChFBBsOrjg@mail.gmail.com>
References: <CAPSktiO9ohfykyuWmZ3YOVf3pEdoaB3ZcXd=_q0=ChFBBsOrjg@mail.gmail.com>
Message-ID: <CFBEC834-7BFC-4EA4-AD28-1A76467041AB@dukhovni.org>

> On Jan 27, 2019, at 12:43 PM, prithiraj das <prithiraj.das at gmail.com> wrote:
> 
> Using OpenSSL, I need to implement digital signing. My approach as of now is:
> 1)  At the sender side, generate the hash of the data using sha256.
> 2)  Encrypt the hash of the data using RSA Private key for the purpose of signing. Send this encrypted hash and the data from Step 1 to the receiverr side.
> 3)  At the receiver's end, Decrypt the signed data(encrypted hash) using the corresponding RSA Public key.
> 4)  Generate hash of the data and verify the decrypted content against this hash to verify the signature
> 
> I was thinking of using RSA_private_encrypt() method to do the signing and RSA_public_decrypt() method to decrypt the signed hash using the corresponding RSA public key. Would the above be a bad approach especially when it comes to using the methods mentioned ? Please recommend the methods to be used that would be better for the purpose of digital signing and verification using sha256 and RSA keys

Do not invent your own RSA-based signature scheme.  Use a standard
RSA signature primitive.  Either RSA-PSS, or PKCS#1 v1.5

   https://en.wikipedia.org/wiki/PKCS_1#Schemes

Typically, you would use CMS, which handles all the details internally.

   https://www.openssl.org/docs/man1.1.0/apps/cms.html

-- 
	Viktor.


From matt at openssl.org  Mon Jan 28 09:53:59 2019
From: matt at openssl.org (Matt Caswell)
Date: Mon, 28 Jan 2019 09:53:59 +0000
Subject: [openssl-users] RSA Digital Signing
In-Reply-To: <CAPSktiO9ohfykyuWmZ3YOVf3pEdoaB3ZcXd=_q0=ChFBBsOrjg@mail.gmail.com>
References: <CAPSktiO9ohfykyuWmZ3YOVf3pEdoaB3ZcXd=_q0=ChFBBsOrjg@mail.gmail.com>
Message-ID: <1a5f3a20-f833-7019-fa5f-a79779d58a3d@openssl.org>



On 27/01/2019 17:43, prithiraj das wrote:
> Hi All,
> 
> Using OpenSSL, I need to implement digital signing. My approach as of now is:
> 1)? At the sender side, generate the hash of the data using sha256.
> 2)? Encrypt the hash of the data using RSA Private key for the purpose of
> signing. Send this encrypted hash and the data from Step 1 to the receiverr side.
> 3)? At the receiver's end, Decrypt the signed data(encrypted hash) using the
> corresponding RSA Public key.
> 4)? Generate hash of the data and verify the decrypted content against this hash
> to verify the signature
> 
> I was thinking of using RSA_private_encrypt() method to do the signing and
> RSA_public_decrypt() method to decrypt the signed hash using the corresponding
> RSA public key. Would the above be a bad approach especially when it comes to
> using the methods mentioned ? Please recommend the methods to be used that would
> be better for the purpose of digital signing and verification using sha256 and
> RSA keys

Consider using the EVP_DigestSign*() functions, rather than the RSA_* ones. This
is the preferred way of doing this:

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

This has the advantages of handling all of the digesting and padding issues for
you. It also gives you greater flexibility to change digest and/or signing
algorithms at a later point if you wish.

Matt


From andrew.tucker at salesforce.com  Mon Jan 28 18:03:59 2019
From: andrew.tucker at salesforce.com (Andrew Tucker)
Date: Mon, 28 Jan 2019 10:03:59 -0800
Subject: [openssl-users] issue with EVP_EncryptUpdate in XTS mode?
In-Reply-To: <ae4d2fde-2389-4b86-13b1-087aac46fb94@openssl.org>
References: <CAJ3attrd=RpmJ39Yg2Z7dyDLy6LoW4EsgEEgXWkLET=ZyogwxA@mail.gmail.com>
 <ae4d2fde-2389-4b86-13b1-087aac46fb94@openssl.org>
Message-ID: <CAJ3attp7uptYyj9En=aB_uT0hevYbykkr4Rvi7uih_9=+NCy8A@mail.gmail.com>

Thanks for the feedback Matt.

I definitely missed this difference between XTS and GCM and didnt realize
one supports "streaming" and one doesnt.

For our application we only ever call EncryptUpdate once so XTS works well
but its great to understand the limitations and make sure future changes
dont screw something up.

On Fri, Jan 25, 2019 at 4:18 PM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 25/01/2019 20:16, Andrew Tucker wrote:
> > I was doing some comparisons of XTS and GCM mode using the EVP APIs and
> found a
> > discrepancy that seems to be an issue with XTS.
> >
> > In GCM mode if the buffer is encrypted in one call to EVP_EncryptUpdate
> or with
> > several calls with smaller buffers the resulting ciphertext is the same,
> as I
> > would expect.   With XTS mode, calling EVP_EncryptUpdate results in the
> same
> > ciphertext for the same plaintext and does not match the results when
> the buffer
> > is encrypted with one call to EVP_EncryptUpdate.
> >
> > I would expect that the counter is incremented in both XTS and GCM mode
> in the
> > same way and that in both cases the output would match regardless of the
> > encryption block size.
> >
> > A simple repro test is attached.    If you run it you can see that the
> output
> > "GCM in one block" matches the output for "GCM in 16 byte blocks" and the
> > outputs do not match for XTS.
> >
> > I am using OpenSSL v1.02p but I have tried with other versions and got
> the same
> > results.
> >
> > Am I misunderstanding the use of XTS mode or is this an issue with
> OpenSSL?
>
> The documentation for XTS mode seems to be particularly dreadful (i.e.
> practically non-existent).
>
> XTS mode was designed for disk encryption and works quite differently to
> modes
> like GCM. XTS encrypts blocks at a time where each block has a separate
> "tweak"
> value (and by "block" here I'm talking about disk blocks not encryption
> blocks).
> There is no "streaming" concept - there is not necessarily any
> relationship with
> the tweak from one block to be encrypted to the next one. AFAICT from code
> inspection you are expected to set the tweak in the IV field and then
> encrypt an
> entire (disk) block in one go with EVP_EncryptUpdate().
>
> This seems to be supported by this post from Steve Henson where he
> describes the
> XTS implementation as not being able to stream and as a "one shot" version:
>
>
> http://openssl.6102.n7.nabble.com/patch-AES-XTS-supporting-custom-iv-from-openssl-enc-command-tt51949.html#a52009
>
> In this later post in the same thread Steve talks about calling
> EVP_EncryptInit_ex again with all the params set to NULL except the ctx
> and iv
> (i.e. tweak) in order to set a new tweak and then call EVP_EncryptUpdate
> again.
>
>
> http://openssl.6102.n7.nabble.com/patch-AES-XTS-supporting-custom-iv-from-openssl-enc-command-tp51949p52006.html
>
> In other words I think you are supposed to use it something like this
> (error
> handling omitted for brevity):
>
> EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
>
> EVP_EncryptInit_ex(ctx, EVP_aes_256_xts(), NULL, aes_key, NULL);
>
> EVP_EncryptInit_ex(ctx, NULL, NULL, NULL, tweak1);
> EVP_EncryptUpdate(ctx, out, &outl, block1, blocklen1);
> EVP_EncryptInit_ex(ctx, NULL, NULL, NULL, tweak2);
> EVP_EncryptUpdate(ctx, out, &outl, block2, blocklen2);
> EVP_EncryptInit_ex(ctx, NULL, NULL, NULL, tweak3);
> EVP_EncryptUpdate(ctx, out, &outl, block3, blocklen3);
>
> That really needs to go in the man pages.
>
> Matt
>
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190128/8c15cd5d/attachment.html>

From rmf.aero at gmail.com  Tue Jan 29 19:23:42 2019
From: rmf.aero at gmail.com (Rich Fought)
Date: Tue, 29 Jan 2019 11:23:42 -0800
Subject: [openssl-users] OpenSSL 1.1.1 Support for DH Ciphers?
Message-ID: <bb2a9365-25bf-038a-fa10-a0119541f8cb@gmail.com>

The OpenSSL 1.1.1 ciphers manpage claims that some non-ephemeral DH 
ciphers are supported:

TLS1.0:
DH-RSA-AES128-SHA
DH-RSA-AES256-SHA

TLS1.2:
DH-RSA-AES128-SHA256
DH-RSA-AES256-SHA256
DH-RSA-AES128-GCM-SHA256
DH-RSA-AES256-GCM-SHA256

However, I am unable to see them with openssl ciphers command

 > openssl ciphers -v -s DH

All I see are DHE ciphers.? DH is needed for compatibility with legacy 
servers.

Are these only enabled via a compile time option?? Or is the 
documentation incorrect?

Regards,
Rich



From openssl-users at dukhovni.org  Tue Jan 29 19:42:48 2019
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 29 Jan 2019 14:42:48 -0500
Subject: [openssl-users] OpenSSL 1.1.1 Support for DH Ciphers?
In-Reply-To: <bb2a9365-25bf-038a-fa10-a0119541f8cb@gmail.com>
References: <bb2a9365-25bf-038a-fa10-a0119541f8cb@gmail.com>
Message-ID: <7FDFDBC3-96D9-4FD1-AFD2-AAE578CD9B71@dukhovni.org>

> On Jan 29, 2019, at 2:23 PM, Rich Fought <rmf.aero at gmail.com> wrote:
> 
> The OpenSSL 1.1.1 ciphers manpage claims that some non-ephemeral DH ciphers are supported:
> 
> TLS1.0:
> DH-RSA-AES128-SHA
> DH-RSA-AES256-SHA

The static DH and ECDH ciphers have been removed.

> TLS1.2:
> DH-RSA-AES128-SHA256
> DH-RSA-AES256-SHA256
> DH-RSA-AES128-GCM-SHA256
> DH-RSA-AES256-GCM-SHA256
> 
> However, I am unable to see them with openssl ciphers command
> 
> > openssl ciphers -v -s DH
> 
> All I see are DHE ciphers.  DH is needed for compatibility with legacy servers.

They are NOT needed for compatibility with legacy servers.

> Are these only enabled via a compile time option?  Or is the documentation incorrect?

The documentation is likely out of date.

-- 
	Viktor.


From kurt at roeckx.be  Tue Jan 29 23:11:23 2019
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 30 Jan 2019 00:11:23 +0100
Subject: [openssl-users] OpenSSL 1.1.1 Support for DH Ciphers?
In-Reply-To: <7FDFDBC3-96D9-4FD1-AFD2-AAE578CD9B71@dukhovni.org>
References: <bb2a9365-25bf-038a-fa10-a0119541f8cb@gmail.com>
 <7FDFDBC3-96D9-4FD1-AFD2-AAE578CD9B71@dukhovni.org>
Message-ID: <20190129231122.GA19418@roeckx.be>

On Tue, Jan 29, 2019 at 02:42:48PM -0500, Viktor Dukhovni wrote:
> > On Jan 29, 2019, at 2:23 PM, Rich Fought <rmf.aero at gmail.com> wrote:
> > 
> > The OpenSSL 1.1.1 ciphers manpage claims that some non-ephemeral DH ciphers are supported:
> > 
> > TLS1.0:
> > DH-RSA-AES128-SHA
> > DH-RSA-AES256-SHA
> 
> The static DH and ECDH ciphers have been removed.
> 
> > TLS1.2:
> > DH-RSA-AES128-SHA256
> > DH-RSA-AES256-SHA256
> > DH-RSA-AES128-GCM-SHA256
> > DH-RSA-AES256-GCM-SHA256
> > 
> > However, I am unable to see them with openssl ciphers command
> > 
> > > openssl ciphers -v -s DH
> > 
> > All I see are DHE ciphers.  DH is needed for compatibility with legacy servers.
> 
> They are NOT needed for compatibility with legacy servers.

To clarify, the static DH has fixed DH parameters in the
certificate. Instead of generating the parameters on each
connection, it's fixed in the certificate. It's higly unlikely
that you have such certificates. They're very difficult to
actually generate. Other then some test certificates, I have never
seen any actual such certificate.

Even if you somehow managed to generate such certificate, both the
client and server would actually need to be set up to work with
static DH, and only static DH, which also seems unlikely. 


Kurt


From guerinp at talasi.fr  Wed Jan 30 09:45:17 2019
From: guerinp at talasi.fr (=?UTF-8?Q?Patrice_Gu=c3=a9rin?=)
Date: Wed, 30 Jan 2019 10:45:17 +0100
Subject: [openssl-users] EVP_Encrypt/EVP_Decrypt input/output buffers
	requirements
Message-ID: <453a3593-80f2-1014-d862-e41feb3a749f@talasi.fr>

Hello to all,

Documentation does not provide input/output buffers requirements for 
encryption/decryption, so
is it safe to submit the same buffer (ie, input=output) for these 
operations ?
If not, what is the minimum distance 'd' required (input = output+d) ?
This is to be used in small memory environment.

Thank you.
Kind regards,
Patrice.


From matt at openssl.org  Wed Jan 30 10:13:17 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 30 Jan 2019 10:13:17 +0000
Subject: [openssl-users] EVP_Encrypt/EVP_Decrypt input/output buffers
 requirements
In-Reply-To: <453a3593-80f2-1014-d862-e41feb3a749f@talasi.fr>
References: <453a3593-80f2-1014-d862-e41feb3a749f@talasi.fr>
Message-ID: <0fed2421-7e0b-4165-9ea1-303b84ac339e@openssl.org>



On 30/01/2019 09:45, Patrice Gu?rin wrote:
> Hello to all,
> 
> Documentation does not provide input/output buffers requirements for
> encryption/decryption, so
> is it safe to submit the same buffer (ie, input=output) for these operations ?
> If not, what is the minimum distance 'd' required (input = output+d) ?
> This is to be used in small memory environment.

EVP_Encrypt*/EVP_Decrypt* support in-place encryption/decryption, i.e. where in
== out. They don't support "partially" overlapping buffers, i.e. where "in !=
out" but some portions of the buffer still overlap.

Matt


From jb-openssl at wisemo.com  Wed Jan 30 10:54:19 2019
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 30 Jan 2019 11:54:19 +0100
Subject: [openssl-users] OpenSSL 1.1.1 Support for DH Ciphers?
In-Reply-To: <20190129231122.GA19418@roeckx.be>
References: <bb2a9365-25bf-038a-fa10-a0119541f8cb@gmail.com>
 <7FDFDBC3-96D9-4FD1-AFD2-AAE578CD9B71@dukhovni.org>
 <20190129231122.GA19418@roeckx.be>
Message-ID: <146d6c18-eefc-94bf-0b0f-db067dc5f571@wisemo.com>

On 30/01/2019 00:11, Kurt Roeckx wrote:
> On Tue, Jan 29, 2019 at 02:42:48PM -0500, Viktor Dukhovni wrote:
>>> On Jan 29, 2019, at 2:23 PM, Rich Fought <rmf.aero at gmail.com> wrote:
>>>
>>> The OpenSSL 1.1.1 ciphers manpage claims that some non-ephemeral DH ciphers are supported:
>>>
>>> TLS1.0:
>>> DH-RSA-AES128-SHA
>>> DH-RSA-AES256-SHA
>> The static DH and ECDH ciphers have been removed.
>>
>>> TLS1.2:
>>> DH-RSA-AES128-SHA256
>>> DH-RSA-AES256-SHA256
>>> DH-RSA-AES128-GCM-SHA256
>>> DH-RSA-AES256-GCM-SHA256
>>>
>>> However, I am unable to see them with openssl ciphers command
>>>
>>>> openssl ciphers -v -s DH
>>> All I see are DHE ciphers.  DH is needed for compatibility with legacy servers.
>> They are NOT needed for compatibility with legacy servers.
> To clarify, the static DH has fixed DH parameters in the
> certificate. Instead of generating the parameters on each
> connection, it's fixed in the certificate. It's higly unlikely
> that you have such certificates. They're very difficult to
> actually generate. Other then some test certificates, I have never
> seen any actual such certificate.
>
> Even if you somehow managed to generate such certificate, both the
> client and server would actually need to be set up to work with
> static DH, and only static DH, which also seems unlikely.
>
At least when not using client certificates, no special client
configuration is needed (other than a non-crippled SSL library).

Server sends the DH parameters from the certificate.? Client
generates a random ephemeral key (just like with the DHE suites),
server "signs" finished message with something derived from the
shared DH result, thus proving it has the private DH key to
correctly complete the DH exchange.

A few SSL/TLS messages may be differently formatted than for DHE,
that's all.? Of cause the static DH suites provide no forward
secrecy after a private key breach, but that's no different
from the basic RSA suites.

Public CAs no longer issue DH certificates, so these will not be
found in public services that rely on the browser/mail/OS
certificate trusts, but they may still exist in private trust
contexts not constrained by browser politics.


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 vieuxtech at gmail.com  Wed Jan 30 21:21:37 2019
From: vieuxtech at gmail.com (Sam Roberts)
Date: Wed, 30 Jan 2019 13:21:37 -0800
Subject: [openssl-users] is the openssl wiki down for maintenance,
	or is something broken?
Message-ID: <CA+Sj9TntJeo5c=w7W7ST9bfDw7q8h5Okb7DZfn+RgOYuH3sXHQ@mail.gmail.com>

https://wiki.openssl.org/index.php/TLS1.3

is returning

```
Sorry! This site is experiencing technical difficulties.
Try waiting a few minutes and reloading.

(Cannot access the database)
```

From boyd.hanalei.ako at gmail.com  Wed Jan 30 23:07:55 2019
From: boyd.hanalei.ako at gmail.com (Boyd Ako)
Date: Wed, 30 Jan 2019 13:07:55 -1000
Subject: [openssl-users] Smartcard cert used for encrypt\decrypt
Message-ID: <CAGD21cJ1dkgSFXfLZJ6qmJLB_OhgOmcFrRh4-qXUaawCcq-yUA@mail.gmail.com>

Does anybody know how to use the smartcard to encrypt and decrypt files?

I was able to encrypt a file using the cert on the smartcard. However, I
couldn't decrypt it. I think it's mainly because I don't know how to get
the Private Key on the token to decrypt it. I've tried `pkcs11-tool -l --id
0002 -r --type privkey` but I get a "sorry, reading private keys not (yet)
supported" message.

To encrypt:
pkcs15-tool -r 0002 > x509.cert
openssl smime -encrypt -binary -aes-256-cbc -in clear.txt -out
clear.txt.enc -outform PEM x509.cert




------------------------------
Thank you for your time,

Boyd H. Ako

boyd.hanalei.ako at gmail.com
https://www.boydhanaleiako.me

PGP/GPG Public Key:
https://sks-keyservers.net/pks/lookup?op=get&search=0xC58073B21618F134
------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190130/1c5146d0/attachment.html>

From guerinp at talasi.fr  Wed Jan 30 23:29:29 2019
From: guerinp at talasi.fr (=?UTF-8?Q?Patrice_Gu=c3=a9rin?=)
Date: Thu, 31 Jan 2019 00:29:29 +0100
Subject: [openssl-users] EVP_Encrypt/EVP_Decrypt input/output buffers
 requirements
In-Reply-To: <0fed2421-7e0b-4165-9ea1-303b84ac339e@openssl.org>
References: <453a3593-80f2-1014-d862-e41feb3a749f@talasi.fr>
 <0fed2421-7e0b-4165-9ea1-303b84ac339e@openssl.org>
Message-ID: <ca1c2688-852b-41f0-260b-41562f338aea@talasi.fr>

Hello Matt,

Thank you very much.

Patrice.

Matt Caswell a ?crit?:
>
> On 30/01/2019 09:45, Patrice Gu?rin wrote:
>> Hello to all,
>>
>> Documentation does not provide input/output buffers requirements for
>> encryption/decryption, so
>> is it safe to submit the same buffer (ie, input=output) for these operations ?
>> If not, what is the minimum distance 'd' required (input = output+d) ?
>> This is to be used in small memory environment.
> EVP_Encrypt*/EVP_Decrypt* support in-place encryption/decryption, i.e. where in
> == out. They don't support "partially" overlapping buffers, i.e. where "in !=
> out" but some portions of the buffer still overlap.
>
> Matt
>


From matt at openssl.org  Wed Jan 30 23:32:41 2019
From: matt at openssl.org (Matt Caswell)
Date: Wed, 30 Jan 2019 23:32:41 +0000
Subject: [openssl-users] is the openssl wiki down for maintenance,
 or is something broken?
In-Reply-To: <CA+Sj9TntJeo5c=w7W7ST9bfDw7q8h5Okb7DZfn+RgOYuH3sXHQ@mail.gmail.com>
References: <CA+Sj9TntJeo5c=w7W7ST9bfDw7q8h5Okb7DZfn+RgOYuH3sXHQ@mail.gmail.com>
Message-ID: <5a9a3f26-a10c-0494-5148-50f08d8986f3@openssl.org>



On 30/01/2019 21:21, Sam Roberts wrote:
> https://wiki.openssl.org/index.php/TLS1.3
> 
> is returning
> 
> ```
> Sorry! This site is experiencing technical difficulties.
> Try waiting a few minutes and reloading.
> 
> (Cannot access the database)
> ```
> 

Something was broken. Fixed now.

Matt

From beldmit at gmail.com  Thu Jan 31 10:09:00 2019
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Thu, 31 Jan 2019 13:09:00 +0300
Subject: [openssl-users] Adding custom OBJ identifiers
Message-ID: <CADqLbzJj1g-_woGOZUdQ-55LibNdC=__5JOAM+giQUTBFAjBZw@mail.gmail.com>

Hello,

What is best practice to add own object identifiers to the crypto/objects/*
files?

It's not a problem to add all the necessary strings to the
crypto/objects/objects.txt file and invoke 'make generate_crypto_objects',
but during the branch development, the changes in the main openssl branch
usually cause numerous merge conflicts. So any advice is appreciated.

Thank you!

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190131/cfa93163/attachment-0001.html>

From Michael.Wojcik at microfocus.com  Thu Jan 31 13:10:59 2019
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 31 Jan 2019 13:10:59 +0000
Subject: [openssl-users] Smartcard cert used for encrypt\decrypt
In-Reply-To: <CAGD21cJ1dkgSFXfLZJ6qmJLB_OhgOmcFrRh4-qXUaawCcq-yUA@mail.gmail.com>
References: <CAGD21cJ1dkgSFXfLZJ6qmJLB_OhgOmcFrRh4-qXUaawCcq-yUA@mail.gmail.com>
Message-ID: <MW2PR18MB20905764695931FE7BDB077CF9910@MW2PR18MB2090.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Boyd Ako
> Sent: Wednesday, January 30, 2019 18:08

> Does anybody know how to use the smartcard to encrypt and decrypt files?

This may depend somewhat on the type of smartcard. While PKCS#11 is a standard, there are all sorts of differences in implementations

> I was able to encrypt a file using the cert on the smartcard. However, I couldn't decrypt it.
> I think it's mainly because I don't know how to get the Private Key on the token to decrypt
> it. I've tried `pkcs11-tool -l --id 0002 -r --type privkey` but I get a "sorry, reading
> private keys not (yet) supported" message.

You're Doing It Wrong.

The point of hardware cryptographic devices is that *secrets stay on them*. You're not supposed to get private keys off the device, except for special and rare use cases such as cloning a device for redundancy.

If you want to do this with OpenSSL, you need to use the OpenSSL PKCS#11 engine. In most OpenSSL builds I've seen, the PKCS#11 engine isn't linked into the openssl executable, so you use the "dynamic" engine to load it. And the PKCS#11 engine will need a suitable driver.

This gets quite complicated, and I don't have time to dig up all my notes, and I've never tried your use case anyway. (I used HSMs for code signing.) But here's an example of using a NitroKey HSM to generate a CSR, using the openssl utility and PKCS#11 engine on Windows:

C:\> openssl
OpenSSL> engine -t dynamic -pre SO_PATH:\path\to\pkcs11.dll -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:\path\to\opensc-pkcs11.dll
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:\path\to\pkcs11.dll
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:\path\to\opensc-pkcs11.dll
Loaded: (pkcs11) pkcs11 engine
     [ available ]
OpenSSL> req -engine pkcs11 -new -key 0:10 -keyform engine -out csr.pem -text -days 1095
engine "pkcs11" set.
No private keys found.
Enter PKCS#11 token PIN for SmartCard-HSM (UserPIN): 6-digit PIN
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [US]: you can change any of these or hit Enter for the defaults
State or Province Name (full name) [XX]:
Locality Name (eg, city) [Some City]:
Organization Name (eg, company) [MyOrg]:
Organizational Unit Name (eg, section) [Whatever]:
Common Name (eg. YOUR name) [Me]:
Email Address [foo at bar.com]:
OpenSSL>

Here pkcs11.dll is the OpenSSL PKCS#11 engine in dynamic-load module form. If your OpenSSL installation doesn't have it, you'll have to build it. opensc-pkcs11.dll is the PKCS#11 driver from the OpenSC open-source smartcard interface project. OpenSC has a configuration file which needs to be set up to match your particular hardware.

--
Michael Wojcik
Distinguished Engineer, Micro Focus


From antiac at gmail.com  Thu Jan 31 14:18:32 2019
From: antiac at gmail.com (Antonio Iacono)
Date: Thu, 31 Jan 2019 15:18:32 +0100
Subject: [openssl-users] Smartcard cert used for encrypt\decrypt
In-Reply-To: <CAGD21cJ1dkgSFXfLZJ6qmJLB_OhgOmcFrRh4-qXUaawCcq-yUA@mail.gmail.com>
References: <CAGD21cJ1dkgSFXfLZJ6qmJLB_OhgOmcFrRh4-qXUaawCcq-yUA@mail.gmail.com>
Message-ID: <CAPN6PER_9mr1qJj8rS428sgUCcme75w+nLKYJBuyrnR7TOWpgQ@mail.gmail.com>

> Does anybody know how to use the smartcard to encrypt and decrypt files?

Hi Boyd,

there are many ways to encrypt/decrypto with smartcard but since you
wrote to the list of OpenSSL I answer you how to do with OpenSSL.
In the meantime you need two other software, in addition to openssl,
the engine and the pkcs11 library.
A step-by-step guide can be found here:
https://github.com/OpenSC/OpenSC/wiki/Quick-Start-with-OpenSC

Antonio

From uri at ll.mit.edu  Thu Jan 31 21:46:11 2019
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 31 Jan 2019 21:46:11 +0000
Subject: [openssl-users] Smartcard cert used for encrypt\decrypt
In-Reply-To: <CAPN6PER_9mr1qJj8rS428sgUCcme75w+nLKYJBuyrnR7TOWpgQ@mail.gmail.com>
References: <CAGD21cJ1dkgSFXfLZJ6qmJLB_OhgOmcFrRh4-qXUaawCcq-yUA@mail.gmail.com>
 <CAPN6PER_9mr1qJj8rS428sgUCcme75w+nLKYJBuyrnR7TOWpgQ@mail.gmail.com>
Message-ID: <C6F4FC58-D18F-47AD-8CFA-08704DB41874@ll.mit.edu>

On 1/31/19, 09:19, "openssl-users on behalf of Antonio Iacono" <openssl-users-bounces at openssl.org on behalf of antiac at gmail.com> wrote:

 

??? > Does anybody know how to use the smartcard to encrypt and decrypt files?

 

Smartcard performs public-key crypto operations, which aren't suitable for bulk processing, such as file encryption/decryption. In general, you'd need a hybrid scheme - generate a random symmetric key, encrypt the file with that symmetric key, and encrypt this symmetric key itself with an appropriate public key from the smartcard. Decryption would be the reverse: with the smartcard (using the private key) decrypt the symmetric key, and pass that symmetric key to OpenSSL to decrypt the file. 

 

Here's an example, which I hope would be useful, as it shows how to use OpenSSL to encrypt and decrypt data (like symmetric keys ? short). It uses OpenSC as PKCS#11 library, libp11 as PKCS#11 engine/interface to OpenSSL, p11-kit to allow URI for objects on the smartcard, and OpenSSL itself:

 

#!/bin/bash

 

# Settings for US DoD CAC smartcard

MANUFACTURER="manufacturer=Common%20Access%20Card;"

PRK="pkcs11:${MANUFACTURER}id=%00%03;type=private"

PUBK="pkcs11:${MANUFACTURER}id=%00%03;type=public"

 

# Generate a random text file

openssl -out textfile.txt -hex 600

TEXTFILE="textfile.txt"

 

# Generate random symmetric key

KEY=`openssl rand -hex 32`

# Generate random IV for file encryption

IV=`openssl rand ?-hex 16`

 

# Encrypt symmetric key to token RSA KEY MAN Key

Echo $KEY | xxd -r -p 200 | openssl pkeyutl -engine pkcs11 -keyform engine -encrypt -pubin -inkey "${PUBK}" -pkeyopt rsa_padding_mode:oaep -out encrypted.key.enc

# Encrypt file with above symmetric key and IV

openssl enc -aes-256-cfb -a -e -in ${TEXTFILE} -out ${TEXTFILE}.enc -K ${KEY} -iv ${IV}

 

# Decrypt symmetric key on the token

KEY2=`openssl pkeyutl -engine pkcs11 -keyform engine -decrypt -inkey "${PRK}" -pkeyopt rsa_padding_mode:oaep -in ${TMP}.key.enc | xxd -p -c 200`

# Decrypt the file

openssl enc -aes-256-cfb -a -d -in ${TEXTFILE}.enc -out ${TEXTFILE}.dec -K ${KEY2} -iv ${IV}

 

 

 

 

??? 

????Hi Boyd,

??? 

????there are many ways to encrypt/decrypto with smartcard but since you

??? wrote to the list of OpenSSL I answer you how to do with OpenSSL.

??? In the meantime you need two other software, in addition to openssl,

??? the engine and the pkcs11 library.

??? A step-by-step guide can be found here:

??? https://github.com/OpenSC/OpenSC/wiki/Quick-Start-with-OpenSC

??? 

????Antonio

??? -- 

????openssl-users mailing list

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

??? 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190131/c5e4d80f/attachment-0001.html>
-------------- 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/20190131/c5e4d80f/attachment-0001.bin>