From janzon at gmail.com  Sat Oct  1 16:05:32 2016
From: janzon at gmail.com (Daniel Janzon)
Date: Sat, 01 Oct 2016 16:05:32 +0000
Subject: [openssl-users] Possible to control session reuse from the
	client?
In-Reply-To: <32126FB1-2531-41E8-B066-6176D12B1E3D@dukhovni.org>
References: <CAAGHsvBjPNxEVy1KDE3HXK6ZT93AZn-aOU8Ncog_91zHFTmGHA@mail.gmail.com>
 <32126FB1-2531-41E8-B066-6176D12B1E3D@dukhovni.org>
Message-ID: <CAAGHsvAVU3kKTfEdbfjgZOZFV+9gPBiDhZPcBD+Mx_caj04vfQ@mail.gmail.com>

Hm... Thanks, but I think I miss some piece of the puzzle. How does client
and server side session differ and how do they interact? I thought the TLS
session was always cached on the server side and all the client would have
to do was to send its session ID.

On Fri, Sep 30, 2016 at 12:00 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

>
> > On Sep 29, 2016, at 11:55 AM, Daniel Janzon <janzon at gmail.com> wrote:
> >
> > For performance testing purposes, I would like to turn off session reuse
> in the (homegrown) client I use for testing. Is there a function in the
> openssl library to do it?
> >
> > I tried googling for "openssl client don't send session id" but I didn't
> find anything useful.
>
> Just do nothing.  Client sessions are not reused unless you explicitly
> arrange for reuse of a session by calling SSL_set_session() before
> SSL_connect().  If you're trying to avoid wasting memory on storing
> client-side sessions that you'll never reuse then this may help:
>
>    SSL_CTX_set_session_cache_mode(client_ctx, SSL_SESS_CACHE_OFF);
>
> but note this is also the default state, so is also not needed unless
> some other code has explicitly enabled client-side caching of sessions.
>
> Only the server-side cache is enabled by default.
>
> --
> --
>         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/20161001/42161562/attachment.html>

From rsalz at akamai.com  Sat Oct  1 16:12:56 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 1 Oct 2016 16:12:56 +0000
Subject: [openssl-users] Possible to control session reuse from
	the	client?
In-Reply-To: <CAAGHsvAVU3kKTfEdbfjgZOZFV+9gPBiDhZPcBD+Mx_caj04vfQ@mail.gmail.com>
References: <CAAGHsvBjPNxEVy1KDE3HXK6ZT93AZn-aOU8Ncog_91zHFTmGHA@mail.gmail.com>
 <32126FB1-2531-41E8-B066-6176D12B1E3D@dukhovni.org>
 <CAAGHsvAVU3kKTfEdbfjgZOZFV+9gPBiDhZPcBD+Mx_caj04vfQ@mail.gmail.com>
Message-ID: <2e7367070e36450d9059e8cbbf745493@usma1ex-dag1mb1.msg.corp.akamai.com>

Sessions are the server holds the state and the client sends a session-id.  Tickets are the client holds the state and sends it to the server.

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

From openssl-users at dukhovni.org  Sat Oct  1 16:17:36 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 1 Oct 2016 16:17:36 +0000
Subject: [openssl-users] Possible to control session reuse from the
 client?
In-Reply-To: <CAAGHsvAVU3kKTfEdbfjgZOZFV+9gPBiDhZPcBD+Mx_caj04vfQ@mail.gmail.com>
References: <CAAGHsvBjPNxEVy1KDE3HXK6ZT93AZn-aOU8Ncog_91zHFTmGHA@mail.gmail.com>
 <32126FB1-2531-41E8-B066-6176D12B1E3D@dukhovni.org>
 <CAAGHsvAVU3kKTfEdbfjgZOZFV+9gPBiDhZPcBD+Mx_caj04vfQ@mail.gmail.com>
Message-ID: <20161001161735.GV4670@mournblade.imrryr.org>

On Sat, Oct 01, 2016 at 04:05:32PM +0000, Daniel Janzon wrote:

> Hm... Thanks, but I think I miss some piece of the puzzle. How does client
> and server side session differ and how do they interact? I thought the TLS
> session was always cached on the server side and all the client would have
> to do was to send its session ID.

Well, the client needs a lot more than just an "id".  It needs to
retain the session master key, protocol version, ... so that if
the server agrees to resume the session the client can do so.

With session tickets, all the storage is the client side, the client
stores the server's session too, encrypted under a key that only
the server knows.  The client sends along the server's session
back to the server in the sessiont ticket extension (RFC 5077).

Client session caching is off by default, and in any case there's
no automatic resumption.  The client must call SSL_set_sesion() to
trigger resumption.

-- 
	Viktor.

From openssl-users at dukhovni.org  Sat Oct  1 16:19:53 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sat, 1 Oct 2016 16:19:53 +0000
Subject: [openssl-users] Possible to control session reuse from
	the	client?
In-Reply-To: <2e7367070e36450d9059e8cbbf745493@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAAGHsvBjPNxEVy1KDE3HXK6ZT93AZn-aOU8Ncog_91zHFTmGHA@mail.gmail.com>
 <32126FB1-2531-41E8-B066-6176D12B1E3D@dukhovni.org>
 <CAAGHsvAVU3kKTfEdbfjgZOZFV+9gPBiDhZPcBD+Mx_caj04vfQ@mail.gmail.com>
 <2e7367070e36450d9059e8cbbf745493@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161001161953.GW4670@mournblade.imrryr.org>

On Sat, Oct 01, 2016 at 04:12:56PM +0000, Salz, Rich wrote:

> Sessions are the server holds the state and the client sends a session-id.

The client always holds (the client side of the) state.  What varies
is how much (server) state is also stored at the server.

> Tickets are the client holds the state and sends it to the server.

With tickets the client also stores the server state, encrypted,
so that the server need only hold a decryption key, which is the
same for multiple client sessions.

-- 
	Viktor.

From gjcoram at gmail.com  Sat Oct  1 20:32:52 2016
From: gjcoram at gmail.com (Geoffrey Coram)
Date: Sat, 1 Oct 2016 16:32:52 -0400
Subject: [openssl-users] calloc vs kssl_calloc
In-Reply-To: <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAA0uMedWeqoESGRwCOENCopeT_wTR+HxwG06WveFs5tzSmmjsg@mail.gmail.com>
 <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161001163252.3AF31C18.gjcoram@gmail.com>

On 09/30/2016 09:29, "Salz, Rich" <rsalz at akamai.com> wrote:
>
> > Is there something more I should do on this issue?? I recall the 
> OpenSSL terms of use strongly discouraged people from the US from 
> helping, due to US export restrictions. 
> 
> That's kinda outdated.


That didn't answer my question.  I reported a bug, I'm not a developer
/ on the developer list; will someone else take this, or is there some
bug database that I should enter an issue into?

From noloader at gmail.com  Sat Oct  1 20:53:33 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 1 Oct 2016 16:53:33 -0400
Subject: [openssl-users] calloc vs kssl_calloc
In-Reply-To: <20161001163252.3AF31C18.gjcoram@gmail.com>
References: <CAA0uMedWeqoESGRwCOENCopeT_wTR+HxwG06WveFs5tzSmmjsg@mail.gmail.com>
 <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161001163252.3AF31C18.gjcoram@gmail.com>
Message-ID: <CAH8yC8kxz66ZjmG4tCv46yAL17wFNE9334oK+ExT+JODb4htUQ@mail.gmail.com>

On Sat, Oct 1, 2016 at 4:32 PM, Geoffrey Coram <gjcoram at gmail.com> wrote:
> ....I reported a bug, I'm not a developer
> / on the developer list; will someone else take this, or is there some
> bug database that I should enter an issue into?

If its an OpenSSL bug, then I believe you send an email to
rt at openssl.org along with the details. OpenSSL makes it easy on folks.

Also see Item 17 in the FAQ: "I think I've found a bug, what should I
do?", http://www.openssl.org/docs/faq.html#BUILD17.

From noloader at gmail.com  Sat Oct  1 21:01:16 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 1 Oct 2016 17:01:16 -0400
Subject: [openssl-users] OpenSSL and sourc'ing countries (was: calloc vs
	kssl_calloc)
Message-ID: <CAH8yC8n+K0nod4n-Aq6OpAyHyLX=U2ki6ORh2Uurnt_jVfoedw@mail.gmail.com>

>>> Is there something more I should do on this issue?  I recall the OpenSSL
>>> terms of use strongly discouraged people from the US from helping, due to US
>>> export restrictions.
>>
>> That's kinda outdated.
>
> However there are very many OpenSSL users (myself included)
> who rely on the legal status of OpenSSL/SSLeay as having no
> US origin parts.  If this has changed, it needs a big red
> banner at the top of the www.openssl.org, every affected
> source file with the original EAY copyright boilerplate or
> its OpenSSL clone etc.

That's kind of interesting. Are you saying there are countries where
you can source and import your crypto from some countries, but not
other countries?

As I understand the US procedures from working with DoC and BIS, you
don't need an import license (only an export license). But I'd be
interested in hearing how some countries are trying to control the
crypto from the import side of the equation.

More humorously, does import versus export even matter? The crypto
genie is out of the bottle. It can't be put back.

Jeff

From rsalz at akamai.com  Sat Oct  1 21:08:03 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 1 Oct 2016 21:08:03 +0000
Subject: [openssl-users] calloc vs kssl_calloc
In-Reply-To: <20161001163252.3AF31C18.gjcoram@gmail.com>
References: <CAA0uMedWeqoESGRwCOENCopeT_wTR+HxwG06WveFs5tzSmmjsg@mail.gmail.com>
 <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161001163252.3AF31C18.gjcoram@gmail.com>
Message-ID: <6ba8c1b605354e41be726c1c7dd5a64d@usma1ex-dag1mb1.msg.corp.akamai.com>


> That didn't answer my question.  I reported a bug, I'm not a developer / on
> the developer list; will someone else take this, or is there some bug database
> that I should enter an issue into?

As it says in https://www.openssl.org/community/, email it to rt at openssl.org

It also says this in the README.

From rsalz at akamai.com  Sat Oct  1 21:18:44 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 1 Oct 2016 21:18:44 +0000
Subject: [openssl-users] calloc vs kssl_calloc
In-Reply-To: <5494c531-b77a-e155-cfa6-2effc2de30c5@wisemo.com>
References: <20160926115651.6018EB40.gjcoram@gmail.com>
 <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com>
 <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com>
 <CAA0uMedWeqoESGRwCOENCopeT_wTR+HxwG06WveFs5tzSmmjsg@mail.gmail.com>
 <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5494c531-b77a-e155-cfa6-2effc2de30c5@wisemo.com>
Message-ID: <439c0131ebcd4f64807e3d26fa266aa6@usma1ex-dag1mb1.msg.corp.akamai.com>


> However there are very many OpenSSL users (myself included) who rely on
> the legal status of OpenSSL/SSLeay as having no US origin parts.  If this has
> changed, it needs a big red banner at the top of the www.openssl.org, every
> affected source file with the original EAY copyright boilerplate or its OpenSSL
> clone etc.

As of 1.1.0 every single file has modifications by US Citizens because I globally changed the copyright.

We are NOT going to mark US/non-US contributions, sorry.

OpenSSL and SSLeay has always had US contributions, it's just that we were done indirectly.  For example, "git show eb64730" which was early 2000.


From noloader at gmail.com  Sat Oct  1 23:01:25 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 1 Oct 2016 19:01:25 -0400
Subject: [openssl-users] calloc vs kssl_calloc
In-Reply-To: <439c0131ebcd4f64807e3d26fa266aa6@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20160926115651.6018EB40.gjcoram@gmail.com>
 <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com>
 <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com>
 <CAA0uMedWeqoESGRwCOENCopeT_wTR+HxwG06WveFs5tzSmmjsg@mail.gmail.com>
 <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5494c531-b77a-e155-cfa6-2effc2de30c5@wisemo.com>
 <439c0131ebcd4f64807e3d26fa266aa6@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAH8yC8nvf8E_An6MamTpDRWSh8VV83R20RJdD0DXLaPRZsY6zA@mail.gmail.com>

On Sat, Oct 1, 2016 at 5:18 PM, Salz, Rich <rsalz at akamai.com> wrote:
>
>> However there are very many OpenSSL users (myself included) who rely on
>> the legal status of OpenSSL/SSLeay as having no US origin parts.  If this has
>> changed, it needs a big red banner at the top of the www.openssl.org, every
>> affected source file with the original EAY copyright boilerplate or its OpenSSL
>> clone etc.
>
> We are NOT going to mark US/non-US contributions, sorry.

That's kind of a new twist on "Authentication is not X". For Java and
Web Apps, its "Authentication is not Authorizations" (Sandboxes and
Secure Contexts). For Git is "Authentication is not Code Integrity"
(Commit Signing).

In the new case, I thinks its "Authentication is not Lawfulness". Or
is it Lawlessness?

Jeff

From rschm2 at unh.newhaven.edu  Sun Oct  2 17:17:22 2016
From: rschm2 at unh.newhaven.edu (Schmicker, Robert)
Date: Sun, 2 Oct 2016 17:17:22 +0000
Subject: [openssl-users] Properly Reseeding RAND_bytes()
Message-ID: <F73B24D2-76CF-4280-A408-4EA784EF8F05@unh.newhaven.edu>

Hello,

I?m a little unsure on the recommended way to properly reseed the RAND_bytes() function. My output provides random numbers, but only the first 16 bytes. The output of byte 16 and on is just some period of the first 16 bytes and therefore has several duplicated numbers.

My inputs are four seeds, each 128 bits in size. A SEED_SIZE with a value of 16 (where I believe the periodicity to be coming from). 

Then an output buffer of 256 bits containing the random bytes as well as the RAND_SIZE with a value of 64.


1: RAND_seed(s->seed1, SEED_SIZE);
2: RAND_bytes(buffer1, RAND_SIZE);

3: RAND_seed(s->seed2, SEED_SIZE);
4: RAND_bytes(buffer2, RAND_SIZE);

5: RAND_seed(s->seed3, SEED_SIZE);
6: RAND_bytes(buffer3, RAND_SIZE);

7: RAND_seed(s->seed4, SEED_SIZE);
8: RAND_bytes(buffer4, RAND_SIZE);

Any reason why four very different seeds are providing the same random numbers, but just in different orders?

Thank you for the read and any help,
Rob Schmicker

From rschm2 at unh.newhaven.edu  Sun Oct  2 16:21:04 2016
From: rschm2 at unh.newhaven.edu (Robert Schmicker)
Date: Sun, 2 Oct 2016 12:21:04 -0400
Subject: [openssl-users] RAND_bytes() Properly Reseeding
Message-ID: <0990c6fc-49d4-45a7-933d-17cb08d61b61@unh.newhaven.edu>

Hello,

I?m a little unsure on the recommended way to properly reseed the RAND_bytes() function. My output provides random numbers, but only the first 16 bytes. The output of byte 16 and on is just some period of the first 16 bytes and therefore has several duplicated numbers.

My inputs are four seeds, each 128 bits in size. A SEED_SIZE with a value of 16 (where I believe the periodicity to be coming from).

Then an output buffer of 256 bits containing the random bytes as well as the RAND_SIZE with a value of 64.


1: RAND_seed(s->seed1, SEED_SIZE);
2: RAND_bytes(buffer1, RAND_SIZE);

3: RAND_seed(s->seed2, SEED_SIZE);
4: RAND_bytes(buffer2, RAND_SIZE);

5: RAND_seed(s->seed3, SEED_SIZE);
6: RAND_bytes(buffer3, RAND_SIZE);

7: RAND_seed(s->seed4, SEED_SIZE);
8: RAND_bytes(buffer4, RAND_SIZE);

Any reason why four very different seeds are providing the same random numbers, but just in different orders?

Thank you for the read and any help,
Rob Schmicker


From rsalz at akamai.com  Mon Oct  3 14:52:57 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 3 Oct 2016 14:52:57 +0000
Subject: [openssl-users] OpenSSL F2F
Message-ID: <d4cebb45a27743608c0d67659fada315@usma1ex-dag1mb1.msg.corp.akamai.com>

Sorry, we didn't think to put this out earlier...

The OpenSSL dev team is having a face-to-face meeting this week in Berlin, co-located with LinuxCon.  If you're in the area, feel free to stop by. In particular, on Tuesday from 16:50-17:40 - "Members of the openssl development team will be available to help with porting applications to 1.1.0, help guide how people can contribute to the project, and be available to discuss other technical issues. Downstream distributions and embedded applications developers should also stop by to introduce themselves"

If you're not available during that time, but want to chat, please let us know.

                /r$

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz

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

From bkaduk at akamai.com  Mon Oct  3 16:41:12 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 3 Oct 2016 11:41:12 -0500
Subject: [openssl-users] calloc vs kssl_calloc
In-Reply-To: <20161001163252.3AF31C18.gjcoram@gmail.com>
References: <CAA0uMedWeqoESGRwCOENCopeT_wTR+HxwG06WveFs5tzSmmjsg@mail.gmail.com>
 <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <20161001163252.3AF31C18.gjcoram@gmail.com>
Message-ID: <13634792-2b96-7a56-fa51-62c39870641b@akamai.com>

On 10/01/2016 03:32 PM, Geoffrey Coram wrote:
> On 09/30/2016 09:29, "Salz, Rich" <rsalz at akamai.com> wrote:
>>> Is there something more I should do on this issue?  I recall the 
>> OpenSSL terms of use strongly discouraged people from the US from 
>> helping, due to US export restrictions. 
>>
>> That's kinda outdated.
>
> That didn't answer my question.  I reported a bug, I'm not a developer
> / on the developer list; will someone else take this, or is there some
> bug database that I should enter an issue into?

The general question has been answered already.  In this specific case,
the best thing for you to do would be to test
https://github.com/openssl/openssl/pull/1622 , which I submitted after
making the claim that the calloc usage was "just a bug".

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

From jb-openssl at wisemo.com  Mon Oct  3 23:31:23 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 4 Oct 2016 01:31:23 +0200
Subject: [openssl-users] OpenSSL and sourc'ing countries (was: calloc vs
 kssl_calloc)
In-Reply-To: <CAH8yC8n+K0nod4n-Aq6OpAyHyLX=U2ki6ORh2Uurnt_jVfoedw@mail.gmail.com>
References: <CAH8yC8n+K0nod4n-Aq6OpAyHyLX=U2ki6ORh2Uurnt_jVfoedw@mail.gmail.com>
Message-ID: <6dfe3783-7554-50bc-916d-fbee8e6b5d2d@wisemo.com>

On 01/10/2016 23:01, Jeffrey Walton wrote:
>>>> Is there something more I should do on this issue?  I recall the OpenSSL
>>>> terms of use strongly discouraged people from the US from helping, due to US
>>>> export restrictions.
>>> That's kinda outdated.
>> However there are very many OpenSSL users (myself included)
>> who rely on the legal status of OpenSSL/SSLeay as having no
>> US origin parts.  If this has changed, it needs a big red
>> banner at the top of the www.openssl.org, every affected
>> source file with the original EAY copyright boilerplate or
>> its OpenSSL clone etc.
> That's kind of interesting. Are you saying there are countries where
> you can source and import your crypto from some countries, but not
> other countries?
I'm not sure about that either.  Part of my point is that when
*exporting* or *reexporting* products that include OpenSSL code,
the various filings (including DoC/BIS as it happens) tend to
include declarations related to the country of origin of the
cryptographic software.

Therefore (and for other reasons) it is very disconcerting if a
project such as OpenSSL, which is actually famous for its non-US
origin, silently changes its country of origin.

> As I understand the US procedures from working with DoC and BIS, you
> don't need an import license (only an export license). But I'd be
> interested in hearing how some countries are trying to control the
> crypto from the import side of the equation.
>
> More humorously, does import versus export even matter? The crypto
> genie is out of the bottle. It can't be put back.
Unfortunately, governments tend to disagree, and we can't all
afford to ignore ill-conceived laws.



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 Oct  3 23:48:42 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 4 Oct 2016 01:48:42 +0200
Subject: [openssl-users] calloc vs kssl_calloc
In-Reply-To: <439c0131ebcd4f64807e3d26fa266aa6@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <20160926115651.6018EB40.gjcoram@gmail.com>
 <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com>
 <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com>
 <CAA0uMedWeqoESGRwCOENCopeT_wTR+HxwG06WveFs5tzSmmjsg@mail.gmail.com>
 <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5494c531-b77a-e155-cfa6-2effc2de30c5@wisemo.com>
 <439c0131ebcd4f64807e3d26fa266aa6@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <b9e92912-e535-a311-2c33-dbc406643c4e@wisemo.com>

On 01/10/2016 23:18, Salz, Rich wrote:
>> However there are very many OpenSSL users (myself included) who rely on
>> the legal status of OpenSSL/SSLeay as having no US origin parts.  If this has
>> changed, it needs a big red banner at the top of the www.openssl.org, every
>> affected source file with the original EAY copyright boilerplate or its OpenSSL
>> clone etc.
> As of 1.1.0 every single file has modifications by US Citizens because I globally changed the copyright.
Really, I thought the US team dealt exclusively with the FIPS
bureaucracy acting as "cutouts" between US government interests
and the non-US developers, never actually touching the code.
> We are NOT going to mark US/non-US contributions, sorry.
>
> OpenSSL and SSLeay has always had US contributions, it's just that we were done indirectly.  For example, "git show eb64730" which was early 2000.
>
This fact was *not* published widely enough to be seen by
everyone concerned.  It was certainly not published as widely
as the fact that SSLeay was created and maintained entirely
outside the US, and that this was one of its major attractions.

Basically that internal checkin (which I have no idea what is,
since I only see the released tarballs) or any earlier US code
changes would have been a watershed change.

Enjoy

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


From rsalz at akamai.com  Tue Oct  4 05:56:31 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 4 Oct 2016 05:56:31 +0000
Subject: [openssl-users] calloc vs kssl_calloc
In-Reply-To: <b9e92912-e535-a311-2c33-dbc406643c4e@wisemo.com>
References: <20160926115651.6018EB40.gjcoram@gmail.com>
 <088105a918b245ec9e6d3a34b0c61c51@usma1ex-dag1mb1.msg.corp.akamai.com>
 <2732dcb1-9ad0-ac48-9f66-7ffc7f5b8237@akamai.com>
 <CAA0uMedWeqoESGRwCOENCopeT_wTR+HxwG06WveFs5tzSmmjsg@mail.gmail.com>
 <508981692b7c43cb8172a76f93c17bf6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5494c531-b77a-e155-cfa6-2effc2de30c5@wisemo.com>
 <439c0131ebcd4f64807e3d26fa266aa6@usma1ex-dag1mb1.msg.corp.akamai.com>
 <b9e92912-e535-a311-2c33-dbc406643c4e@wisemo.com>
Message-ID: <fd13527c25554a0d9742e8e98d831f04@usma1ex-dag1mb1.msg.corp.akamai.com>


> This fact was *not* published widely enough to be seen by everyone
> concerned.  It was certainly not published as widely as the fact that SSLeay
> was created and maintained entirely outside the US, and that this was one of
> its major attractions.
> 
> Basically that internal checkin (which I have no idea what is, since I only see
> the released tarballs) or any earlier US code changes would have been a
> watershed change.

Well, I can't go back to 2000 and change things.

You'll have to decide what you want to do now.

From Michael.Wojcik at microfocus.com  Tue Oct  4 12:33:37 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 4 Oct 2016 12:33:37 +0000
Subject: [openssl-users] RAND_bytes() Properly Reseeding
In-Reply-To: <0990c6fc-49d4-45a7-933d-17cb08d61b61@unh.newhaven.edu>
References: <0990c6fc-49d4-45a7-933d-17cb08d61b61@unh.newhaven.edu>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015E6A5638@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Robert Schmicker
> Sent: Sunday, October 02, 2016 12:21
> 
> I?m a little unsure on the recommended way to properly reseed the
> RAND_bytes() function. My output provides random numbers, but only the
> first 16 bytes. The output of byte 16 and on is just some period of the first 16
> bytes and therefore has several duplicated numbers.

Do you have a small program that demonstrates the problem?

Michael Wojcik 
Distinguished Engineer, Micro Focus 



From totszwai at gmail.com  Wed Oct  5 18:12:17 2016
From: totszwai at gmail.com (Eric To)
Date: Wed, 5 Oct 2016 14:12:17 -0400
Subject: [openssl-users] BN_mod_inverse:no inverse when calling
	OCSP_basic_sign
Message-ID: <CANHiQDnZYj0DnoQjwgVYwyg7dbJ_SygSs3pW=+MJF73DMg8YEQ@mail.gmail.com>

Version: openssl 1.0.1u
OS: RHEL 6.5
Arch: x86_64 GNU/Linux


I'm getting a critical error when openssl try to sign the basic response.
The overall basic response itself seems fine since openssl can still decode
the response if i use -no_signature_verify...

Without it, i get:
Response Verify Failure
140479349708456:error:04091077:rsa routines:INT_RSA_VERIFY:wrong signature
length:rsa_sign.c:186:
140479349708456:error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP
lib:a_verify.c:218:
140479349708456:error:27069075:OCSP routines:OCSP_basic_verify:signature
failure:ocsp_vfy.c:105:


Any hint on troubleshooting this would be great. Here is how I call the
OCSP_basic_sign:

OCSP_BASICRESP *bresp;
X509 *signer;
EVP_PKEY *key;
...
OCSP_basic_sign(bresp,
                    signer, key,
                    EVP_sha1(),
                    NULL, 0);

But getting the following error internally from OCSP_basic_sign:

OPENSSL ERROR: error:0306E06C:bignum routines:BN_mod_inverse:no inverse
OPENSSL ERROR: error:0D0DC006:asn1 encoding routines:ASN1_item_sign_ctx:EVP
lib

Running it through dbg, it failed at ASN1_item_sign_ctx In
crypto/asn1/a_sign.c

303    if (!EVP_DigestSignUpdate(ctx, buf_in, inl)
304        || !EVP_DigestSignFinal(ctx, buf_out, &outl)) {
305        outl = 0;
306        ASN1err(ASN1_F_ASN1_ITEM_SIGN_CTX, ERR_R_EVP_LIB);
307        goto err;
308    }


(gdb) print inl
$1 = 284
(gdb) print outl
$2 = 256
(gdb) print *ctx
$4 = {digest = 0x7fb2ecf12b80, engine = 0x0, flags = 0, md_data =
0x7fb2ef1629d0, pctx = 0x7fb2ef162970,
  update = 0x7fb2ecc2515a <update>}
(gdb) print *ctx->digest
$5 = {type = 64, pkey_type = 65, md_size = 20, flags = 12, init =
0x7fb2ecc2513c <init>, update = 0x7fb2ecc2515a <update>,
  final = 0x7fb2ecc2518b <final>, copy = 0, cleanup = 0, sign =
0x7fb2ecbf0c70 <RSA_sign>, verify = 0x7fb2ecbf1568 <RSA_verify>,
  required_pkey_type = {6, 19, 0, 0, 0}, block_size = 64, ctx_size = 104,
md_ctrl = 0}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161005/b953b69d/attachment.html>

From steve at openssl.org  Wed Oct  5 18:52:01 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 5 Oct 2016 18:52:01 +0000
Subject: [openssl-users] BN_mod_inverse:no inverse when calling
 OCSP_basic_sign
In-Reply-To: <CANHiQDnZYj0DnoQjwgVYwyg7dbJ_SygSs3pW=+MJF73DMg8YEQ@mail.gmail.com>
References: <CANHiQDnZYj0DnoQjwgVYwyg7dbJ_SygSs3pW=+MJF73DMg8YEQ@mail.gmail.com>
Message-ID: <20161005185201.GA19523@openssl.org>

On Wed, Oct 05, 2016, Eric To wrote:

> 
> Any hint on troubleshooting this would be great. Here is how I call the
> OCSP_basic_sign:
> 
> OCSP_BASICRESP *bresp;
> X509 *signer;
> EVP_PKEY *key;
> ...
> OCSP_basic_sign(bresp,
>                     signer, key,
>                     EVP_sha1(),
>                     NULL, 0);
> 
> But getting the following error internally from OCSP_basic_sign:
> 
> OPENSSL ERROR: error:0306E06C:bignum routines:BN_mod_inverse:no inverse
> OPENSSL ERROR: error:0D0DC006:asn1 encoding routines:ASN1_item_sign_ctx:EVP
> lib
> 

Where does the key come from? Trying using the -check option to the rsa
utility to see if it is valid.

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

From kgoldman at us.ibm.com  Thu Oct  6 13:42:34 2016
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 6 Oct 2016 09:42:34 -0400
Subject: [openssl-users] pod to html
Message-ID: <nt5kc9$re4$1@blaine.gmane.org>

Does someone have the precise command to bulk convert the pod files to 
html, with all the cross references, relative directory, index, etc.?

I'd like to have a local copy for times the web site is unavailable.


From matt at openssl.org  Thu Oct  6 14:11:23 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 6 Oct 2016 15:11:23 +0100
Subject: [openssl-users] pod to html
In-Reply-To: <nt5kc9$re4$1@blaine.gmane.org>
References: <nt5kc9$re4$1@blaine.gmane.org>
Message-ID: <8df8e2a6-7368-87e7-92f7-c06da578e855@openssl.org>



On 06/10/16 14:42, Ken Goldman wrote:
> Does someone have the precise command to bulk convert the pod files to
> html, with all the cross references, relative directory, index, etc.?
> 
> I'd like to have a local copy for times the web site is unavailable.
> 

Just doing "make install_html_docs" should do it.

Matt

From ajaygargnsit at gmail.com  Fri Oct  7 03:21:24 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Fri, 7 Oct 2016 08:51:24 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
	wrapping "sockets"
Message-ID: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>

Hi All.

I understand the basic gist of setting up SSL-connections using
OpenSSL, as per
http://stackoverflow.com/questions/7698488/turn-a-simple-socket-into-an-ssl-socket

However, I am a bit unsure about certain implementations.
In particular (let's talk only about the client-side), I wonder how do
the following methods work internally ::


      * SSL_connect (implicitly involving underlying-socket-reads and
underlying-socket-writes)
      * SSL_write (involving underlying-socket-writes)
      * SSL_read (involving underlying-socket-reads)


We have a framework which we have ported to a variety of devices,
involving GPRS-connectivity, and devices without operating-systems.
I know that there is "no one universal socket-write" and "no one
universal socket-read" implementations.

With the above in mind, I wonder how the "SSL_connect", "SSL_write",
"SSL_read" actually handle the root-level writes/reads (given that we
do not pass any "root-level-socket-write" and "root-level-socket-read"
callbacks before "SSL_write" and "SSL_read").


Looking forward to some help; I will be grateful for any pointers.


Thanks and Regards,
Ajay

From openssl-users at dukhovni.org  Fri Oct  7 03:49:01 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 7 Oct 2016 03:49:01 +0000
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
Message-ID: <20161007034901.GJ4670@mournblade.imrryr.org>

On Fri, Oct 07, 2016 at 08:51:24AM +0530, Ajay Garg wrote:

> However, I am a bit unsure about certain implementations.
> In particular (let's talk only about the client-side), I wonder how do
> the following methods work internally ::
> 
> 
>       * SSL_connect (implicitly involving underlying-socket-reads and
> underlying-socket-writes)

Correct.

>       * SSL_write (involving underlying-socket-writes)

This can also involve socket reads, e.g. when the peer requests
renegotiation.  Hence, on non-blocking sockets this can fail with
SSL_ERROR_WANT_READ.  The application should then retry the write
(generally with the identitical data) when the socket becomes
*readable*.

>       * SSL_read (involving underlying-socket-reads)

This can also involve socket writes, e.g. when the peer requests
renegotiation.  Hence, on non-blocking sockets this can fail with
SSL_ERROR_WANT_WRITE.  The application should then retry the read
when the socket becomes *writable*.

> We have a framework which we have ported to a variety of devices,
> involving GPRS-connectivity, and devices without operating-systems.
> I know that there is "no one universal socket-write" and "no one
> universal socket-read" implementations.

No idea what "root-level" means.  Perhaps you mean something
analogous to a system-call?  If so OpenSSL can either be handed
the socket to use, or plugged into some other way of moving data
via the BIO pair interface.

    https://www.openssl.org/docs/manmaster/crypto/BIO_s_bio.html

-- 
	Viktor.

From ajaygargnsit at gmail.com  Fri Oct  7 04:39:07 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Fri, 7 Oct 2016 10:09:07 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <20161007034901.GJ4670@mournblade.imrryr.org>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
Message-ID: <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>

On Fri, Oct 7, 2016 at 9:19 AM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 08:51:24AM +0530, Ajay Garg wrote:
>
>> However, I am a bit unsure about certain implementations.
>> In particular (let's talk only about the client-side), I wonder how do
>> the following methods work internally ::
>>
>>
>>       * SSL_connect (implicitly involving underlying-socket-reads and
>> underlying-socket-writes)
>
> Correct.
>
>>       * SSL_write (involving underlying-socket-writes)
>
> This can also involve socket reads, e.g. when the peer requests
> renegotiation.  Hence, on non-blocking sockets this can fail with
> SSL_ERROR_WANT_READ.  The application should then retry the write
> (generally with the identitical data) when the socket becomes
> *readable*.
>
>>       * SSL_read (involving underlying-socket-reads)
>
> This can also involve socket writes, e.g. when the peer requests
> renegotiation.  Hence, on non-blocking sockets this can fail with
> SSL_ERROR_WANT_WRITE.  The application should then retry the read
> when the socket becomes *writable*.
>
>> We have a framework which we have ported to a variety of devices,
>> involving GPRS-connectivity, and devices without operating-systems.
>> I know that there is "no one universal socket-write" and "no one
>> universal socket-read" implementations.
>
> No idea what "root-level" means.  Perhaps you mean something
> analogous to a system-call?  If so OpenSSL can either be handed
> the socket to use, or plugged into some other way of moving data
> via the BIO pair interface.
>
>     https://www.openssl.org/docs/manmaster/crypto/BIO_s_bio.html


Ahhhh.... let me have a look.. I think this will fit in :)

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



-- 
Regards,
Ajay

From ajaygargnsit at gmail.com  Fri Oct  7 06:58:46 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Fri, 7 Oct 2016 12:28:46 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
Message-ID: <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>

Victor,

I realise I am still stuck with the original issue.

Taking "bio1" as the SSL-facing-bio, and "bio2" as the
network-facing-bio, how do we write-into/read-from "bio2"?
Are there callbacks available that will allow ::

   * Writing to network via "bio2" (after "bio1" has
internally-transferred the bytes to "bio2") ?
   * Reading from network via "bio2" (after which "bio1" can
internally-pick-up the bytes from "bio2") ?

Also, how do "bio1" and "bio2" communicate in case of non-ideal
scenarios (timeouts, errors)?

On Fri, Oct 7, 2016 at 10:09 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> On Fri, Oct 7, 2016 at 9:19 AM, Viktor Dukhovni
> <openssl-users at dukhovni.org> wrote:
>> On Fri, Oct 07, 2016 at 08:51:24AM +0530, Ajay Garg wrote:
>>
>>> However, I am a bit unsure about certain implementations.
>>> In particular (let's talk only about the client-side), I wonder how do
>>> the following methods work internally ::
>>>
>>>
>>>       * SSL_connect (implicitly involving underlying-socket-reads and
>>> underlying-socket-writes)
>>
>> Correct.
>>
>>>       * SSL_write (involving underlying-socket-writes)
>>
>> This can also involve socket reads, e.g. when the peer requests
>> renegotiation.  Hence, on non-blocking sockets this can fail with
>> SSL_ERROR_WANT_READ.  The application should then retry the write
>> (generally with the identitical data) when the socket becomes
>> *readable*.
>>
>>>       * SSL_read (involving underlying-socket-reads)
>>
>> This can also involve socket writes, e.g. when the peer requests
>> renegotiation.  Hence, on non-blocking sockets this can fail with
>> SSL_ERROR_WANT_WRITE.  The application should then retry the read
>> when the socket becomes *writable*.
>>
>>> We have a framework which we have ported to a variety of devices,
>>> involving GPRS-connectivity, and devices without operating-systems.
>>> I know that there is "no one universal socket-write" and "no one
>>> universal socket-read" implementations.
>>
>> No idea what "root-level" means.  Perhaps you mean something
>> analogous to a system-call?  If so OpenSSL can either be handed
>> the socket to use, or plugged into some other way of moving data
>> via the BIO pair interface.
>>
>>     https://www.openssl.org/docs/manmaster/crypto/BIO_s_bio.html
>
>
> Ahhhh.... let me have a look.. I think this will fit in :)
>
>>
>> --
>>         Viktor.
>> --.
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> --
> Regards,
> Ajay



-- 
Regards,
Ajay

From astib at mag0.net  Fri Oct  7 09:05:34 2016
From: astib at mag0.net (Ales Stibal)
Date: Fri, 7 Oct 2016 11:05:34 +0200
Subject: [openssl-users] socket change with SSL_set_fd
Message-ID: <75a8c4a1-e833-cb94-8690-cc30f1c46499@mag0.net>

Hi folks,
I have a small, but important question which affects my project design.

May I change underlying socket for SSL with SSL_set_fd when socket was 
already set and used before?

I believe it should not be problem, since in theory it's just the 
transport channel for OpenSSL where to write, or read from.
Am I correct?

Many thanks,
   Ales


From openssl-users at dukhovni.org  Fri Oct  7 09:55:04 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 7 Oct 2016 09:55:04 +0000
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
Message-ID: <20161007095504.GK4670@mournblade.imrryr.org>

On Fri, Oct 07, 2016 at 12:28:46PM +0530, Ajay Garg wrote:

> I realise I am still stuck with the original issue.

Failure to read the documentation closely.

> Also, how do "bio1" and "bio2" communicate in case of non-ideal
> scenarios (timeouts, errors)?

They don't, you move all the data.  All reads/writes by OpenSSL will
return SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE when the requisite
data is not already buffered.  At that point you do the requsite
I/O and copy data into and out of the network bio.

First, do all pending writes:

    BIO_ctrl_pending(network_bio)
    BIO_read(network_bio, ...)

    ... write the opaque ciphertext to the underlying socket-like
    ... thing when it is writable, take to not block or drop
    ... the ciphertext on the floor if you do.

then if SSL_ERROR_WANT_READ, find out how much OpenSSL wants to
read, and read that much data from the underlying socket-like thing
and copy its (opaque ciphertext) into the network bio:

    BIO_ctrl_get_read_request(network_bio)
    BIO_write(network_bio, ...)

A double-buffer (separate read/write) between the socket and SSL
may make the logic simpler, but the write side must be flushed
whenever to the SSL network BIO becomes empty, to avoid deadlock.
And of course avoid blocking on reads when it is OpenSSL's turn to
write.  In general you have an event loop, a non-blocking socket
thingy, and select/poll/... read/write or both depending on
SSL_ERROR_WANT_READ/WRITE and the state of any intermediate buffers
you're managing.

A careful read of the manpage will expose all these facilities.

-- 
	Viktor.

From hariprasad_mc07 at yahoo.com  Fri Oct  7 12:16:28 2016
From: hariprasad_mc07 at yahoo.com (HariPrasad MC)
Date: Fri, 7 Oct 2016 12:16:28 +0000 (UTC)
Subject: [openssl-users] Building FIPS capable openssl on Android
References: <1945032651.25042.1475842588669.ref@mail.yahoo.com>
Message-ID: <1945032651.25042.1475842588669@mail.yahoo.com>

I'm trying to port the FIPS module to Android openssl.
Can someone please suggest the Prerequisite to be followed for linking Fips module(fipscanister)
to Android Openssl in Android.mk.

From ajaygargnsit at gmail.com  Fri Oct  7 14:35:13 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Fri, 7 Oct 2016 20:05:13 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <20161007095504.GK4670@mournblade.imrryr.org>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
Message-ID: <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>

Hi Viktor.

Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
seem daunting, but I am learning :)

Also, let's not bother too much about the APIs/methods as such.
I will be grateful if you could confirm/reject my
architectural-understanding so far.

Let's say "bio1" is the SSL-BIO, and "bio2" is the In-Memory-BIO, and
they have been made a pair, with the architecture being ::

App <=> bio1 <=> bio2 <=> device-specific-socket


So, for writes, following steps can be made to happen synchronously
(even with blocking device-specific-sockets) ::

   W1. App writes x app-payload-bytes to bio1.

   W2. Internally, x app-payload-bytes (at bio1) become y
app-payload-encrypted-bytes (at bio2).

   W3. Thereafter, the y app-payload-encrypted-bytes are transferred
over the wire via the device-specific-socket.

I think W2 is the key-step architecturally.


For reads, following steps can be made to happen synchronously (even
with blocking device-specific-sockets, carrying read-timeout feature)
::

  R1. App wants x app-payload-bytes.

  R2. If bio1 can produce at least x app-payload-bytes, then we are done.

        Else, we read some (let's say n) app-payload-encrypted-bytes
from device-specific-socket, write them into bio2, and
        again enquire if bio1 can now produce at least x app-payload-bytes.

        If still not, we keep reading n app-payload-encrypted-bytes
from device-specific-socket and writing them into bio2, until
        bio1 can produce at least x app-payload-bytes.

  R3. Finally, App reads x app-payload-bytes.

Here too, I think R2 is the key-step architecturally.



Is my above architectural-understanding of the workflow between App
and Device-Specific-Socket correct?


Anyway, thanks for your help so far.


Thanks and Regards,
Ajay




On Fri, Oct 7, 2016 at 3:25 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 12:28:46PM +0530, Ajay Garg wrote:
>
>> I realise I am still stuck with the original issue.
>
> Failure to read the documentation closely.
>
>> Also, how do "bio1" and "bio2" communicate in case of non-ideal
>> scenarios (timeouts, errors)?
>
> They don't, you move all the data.  All reads/writes by OpenSSL will
> return SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE when the requisite
> data is not already buffered.  At that point you do the requsite
> I/O and copy data into and out of the network bio.
>
> First, do all pending writes:
>
>     BIO_ctrl_pending(network_bio)
>     BIO_read(network_bio, ...)
>
>     ... write the opaque ciphertext to the underlying socket-like
>     ... thing when it is writable, take to not block or drop
>     ... the ciphertext on the floor if you do.
>
> then if SSL_ERROR_WANT_READ, find out how much OpenSSL wants to
> read, and read that much data from the underlying socket-like thing
> and copy its (opaque ciphertext) into the network bio:
>
>     BIO_ctrl_get_read_request(network_bio)
>     BIO_write(network_bio, ...)
>
> A double-buffer (separate read/write) between the socket and SSL
> may make the logic simpler, but the write side must be flushed
> whenever to the SSL network BIO becomes empty, to avoid deadlock.
> And of course avoid blocking on reads when it is OpenSSL's turn to
> write.  In general you have an event loop, a non-blocking socket
> thingy, and select/poll/... read/write or both depending on
> SSL_ERROR_WANT_READ/WRITE and the state of any intermediate buffers
> you're managing.
>
> A careful read of the manpage will expose all these facilities.
>
> --
>         Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay

From jb-openssl at wisemo.com  Fri Oct  7 14:57:24 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 7 Oct 2016 16:57:24 +0200
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
Message-ID: <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>

On 07/10/2016 16:35, Ajay Garg wrote:
> Hi Viktor.
>
> Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
> seem daunting, but I am learning :)
>
> Also, let's not bother too much about the APIs/methods as such.
> I will be grateful if you could confirm/reject my
> architectural-understanding so far.
>
> Let's say "bio1" is the SSL-BIO, and "bio2" is the In-Memory-BIO, and
> they have been made a pair, with the architecture being ::
>
> App <=> bio1 <=> bio2 <=> device-specific-socket
>
One caveat for both scenarios below:

RW2a: During step R2 or W2, the SSL/TLS protocol may need to
transmit some data in the opposite direction in order to handle
automatically setting or changing the encryption keys etc.  Thus
during W2, some data may be read from bio2 and during R2, some
data may be written to bio2.

This doesn't happen every time, but it always happens for the
first app-payload-bytes, and it may happen at any later time
subject to changes as the protocol and/or library are improved.

> So, for writes, following steps can be made to happen synchronously
> (even with blocking device-specific-sockets) ::
>
>     W1. App writes x app-payload-bytes to bio1.
>
>     W2. Internally, x app-payload-bytes (at bio1) become y
> app-payload-encrypted-bytes (at bio2).
>
>     W3. Thereafter, the y app-payload-encrypted-bytes are transferred
> over the wire via the device-specific-socket.
>
> I think W2 is the key-step architecturally.
>
>
> For reads, following steps can be made to happen synchronously (even
> with blocking device-specific-sockets, carrying read-timeout feature)
> ::
>
>    R1. App wants x app-payload-bytes.
>
>    R2. If bio1 can produce at least x app-payload-bytes, then we are done.
>
>          Else, we read some (let's say n) app-payload-encrypted-bytes
> from device-specific-socket, write them into bio2, and
>          again enquire if bio1 can now produce at least x app-payload-bytes.
>
>          If still not, we keep reading n app-payload-encrypted-bytes
> from device-specific-socket and writing them into bio2, until
>          bio1 can produce at least x app-payload-bytes.
>
>    R3. Finally, App reads x app-payload-bytes.
>
> Here too, I think R2 is the key-step architecturally.
>
>
>
> Is my above architectural-understanding of the workflow between App
> and Device-Specific-Socket correct?
>
>
> Anyway, thanks for your help so far.
>
>
> Thanks and Regards,
> Ajay
>
>
>
>
> On Fri, Oct 7, 2016 at 3:25 PM, Viktor Dukhovni
> <openssl-users at dukhovni.org> wrote:
>> On Fri, Oct 07, 2016 at 12:28:46PM +0530, Ajay Garg wrote:
>>
>>> I realise I am still stuck with the original issue.
>> Failure to read the documentation closely.
>>
>>> Also, how do "bio1" and "bio2" communicate in case of non-ideal
>>> scenarios (timeouts, errors)?
>> They don't, you move all the data.  All reads/writes by OpenSSL will
>> return SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE when the requisite
>> data is not already buffered.  At that point you do the requsite
>> I/O and copy data into and out of the network bio.
>>
>> First, do all pending writes:
>>
>>      BIO_ctrl_pending(network_bio)
>>      BIO_read(network_bio, ...)
>>
>>      ... write the opaque ciphertext to the underlying socket-like
>>      ... thing when it is writable, take to not block or drop
>>      ... the ciphertext on the floor if you do.
>>
>> then if SSL_ERROR_WANT_READ, find out how much OpenSSL wants to
>> read, and read that much data from the underlying socket-like thing
>> and copy its (opaque ciphertext) into the network bio:
>>
>>      BIO_ctrl_get_read_request(network_bio)
>>      BIO_write(network_bio, ...)
>>
>> A double-buffer (separate read/write) between the socket and SSL
>> may make the logic simpler, but the write side must be flushed
>> whenever to the SSL network BIO becomes empty, to avoid deadlock.
>> And of course avoid blocking on reads when it is OpenSSL's turn to
>> write.  In general you have an event loop, a non-blocking socket
>> thingy, and select/poll/... read/write or both depending on
>> SSL_ERROR_WANT_READ/WRITE and the state of any intermediate buffers
>> you're managing.
>>
>> A careful read of the manpage will expose all these facilities.

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 ajaygargnsit at gmail.com  Fri Oct  7 17:00:06 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Fri, 7 Oct 2016 22:30:06 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
Message-ID: <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>

Thanks for the reply Viktor.

On Fri, Oct 7, 2016 at 8:27 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> On 07/10/2016 16:35, Ajay Garg wrote:
>>
>> Hi Viktor.
>>
>> Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
>> seem daunting, but I am learning :)
>>
>> Also, let's not bother too much about the APIs/methods as such.
>> I will be grateful if you could confirm/reject my
>> architectural-understanding so far.
>>
>> Let's say "bio1" is the SSL-BIO, and "bio2" is the In-Memory-BIO, and
>> they have been made a pair, with the architecture being ::
>>
>> App <=> bio1 <=> bio2 <=> device-specific-socket
>>
> One caveat for both scenarios below:
>
> RW2a: During step R2 or W2, the SSL/TLS protocol may need to
> transmit some data in the opposite direction in order to handle
> automatically setting or changing the encryption keys etc.  Thus
> during W2, some data may be read from bio2 and during R2, some
> data may be written to bio2.
>
> This doesn't happen every time, but it always happens for the
> first app-payload-bytes, and it may happen at any later time
> subject to changes as the protocol and/or library are improved.

Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
and if "bio1" requires reading from bio2/peer, bio_write() will return
SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
app-payload-encrypted-bytes from device-socket, put them into "bio2"
(thus internally fulfilling bio1's need for read), and then again try
bio_write() to "bio1" WITH IDENTICAL APP-PAYLOAD-BYTES. If it again
returns SSL_ERROR_WANT_READ, we repeat the cycle.

For reading app-payload-bytes, we do a bio_read() from "bio1", and if
"bio1" requires writing bytes to bio2/peer, bio_read() will return
SSL_ERROR_WANT_WRITE (even for blocking sockets). We then pick up the
app-payload-encrypted-bytes from "bio2", transfer them over the wire
via device-specific-socket (thus fulfilling bio1's need to send bytes
to peer), and then again try bio_read() from "bio1" WITH IDENTICAL
APP-PAYLOAD-BYTES. If it again returns SSL_ERROR_WANT_WRITE, we repeat
the cycle.

Obviously, for the above two sub-plots, the only chance of failure if
reading/writing bytes fails over the wire.
But that is not the norm; if it does happen, then everything will be
restarted from scratch (at least by me).


Is my understanding correct (especially for the case if
blocking-sockets are being used throughout)?

If yes, then it seems everything can be done fully synchronously for
blocking-sockets, thus eliminating the need of multiple threads, and
thus enabling us to integrate OpenSSL seamlessly in our already
existing framework across all devices that we have ported our
framework to (devices with/without operating-systems, with/without
GPRS/Wifi).

So, eagerly awaiting your reply :)



Thanks a ton for the lightning-quick help so far !!!!



Thanks and Regards,
Ajay


>
>
>> So, for writes, following steps can be made to happen synchronously
>> (even with blocking device-specific-sockets) ::
>>
>>     W1. App writes x app-payload-bytes to bio1.
>>
>>     W2. Internally, x app-payload-bytes (at bio1) become y
>> app-payload-encrypted-bytes (at bio2).
>>
>>     W3. Thereafter, the y app-payload-encrypted-bytes are transferred
>> over the wire via the device-specific-socket.
>>
>> I think W2 is the key-step architecturally.
>>
>>
>> For reads, following steps can be made to happen synchronously (even
>> with blocking device-specific-sockets, carrying read-timeout feature)
>> ::
>>
>>    R1. App wants x app-payload-bytes.
>>
>>    R2. If bio1 can produce at least x app-payload-bytes, then we are done.
>>
>>          Else, we read some (let's say n) app-payload-encrypted-bytes
>> from device-specific-socket, write them into bio2, and
>>          again enquire if bio1 can now produce at least x
>> app-payload-bytes.
>>
>>          If still not, we keep reading n app-payload-encrypted-bytes
>> from device-specific-socket and writing them into bio2, until
>>          bio1 can produce at least x app-payload-bytes.
>>
>>    R3. Finally, App reads x app-payload-bytes.
>>
>> Here too, I think R2 is the key-step architecturally.
>>
>>
>>
>> Is my above architectural-understanding of the workflow between App
>> and Device-Specific-Socket correct?
>>
>>
>> Anyway, thanks for your help so far.
>>
>>
>> Thanks and Regards,
>> Ajay
>>
>>
>>
>>
>> On Fri, Oct 7, 2016 at 3:25 PM, Viktor Dukhovni
>> <openssl-users at dukhovni.org> wrote:
>>>
>>> On Fri, Oct 07, 2016 at 12:28:46PM +0530, Ajay Garg wrote:
>>>
>>>> I realise I am still stuck with the original issue.
>>>
>>> Failure to read the documentation closely.
>>>
>>>> Also, how do "bio1" and "bio2" communicate in case of non-ideal
>>>> scenarios (timeouts, errors)?
>>>
>>> They don't, you move all the data.  All reads/writes by OpenSSL will
>>> return SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE when the requisite
>>> data is not already buffered.  At that point you do the requsite
>>> I/O and copy data into and out of the network bio.
>>>
>>> First, do all pending writes:
>>>
>>>      BIO_ctrl_pending(network_bio)
>>>      BIO_read(network_bio, ...)
>>>
>>>      ... write the opaque ciphertext to the underlying socket-like
>>>      ... thing when it is writable, take to not block or drop
>>>      ... the ciphertext on the floor if you do.
>>>
>>> then if SSL_ERROR_WANT_READ, find out how much OpenSSL wants to
>>> read, and read that much data from the underlying socket-like thing
>>> and copy its (opaque ciphertext) into the network bio:
>>>
>>>      BIO_ctrl_get_read_request(network_bio)
>>>      BIO_write(network_bio, ...)
>>>
>>> A double-buffer (separate read/write) between the socket and SSL
>>> may make the logic simpler, but the write side must be flushed
>>> whenever to the SSL network BIO becomes empty, to avoid deadlock.
>>> And of course avoid blocking on reads when it is OpenSSL's turn to
>>> write.  In general you have an event loop, a non-blocking socket
>>> thingy, and select/poll/... read/write or both depending on
>>> SSL_ERROR_WANT_READ/WRITE and the state of any intermediate buffers
>>> you're managing.
>>>
>>> A careful read of the manpage will expose all these facilities.
>
>
> 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



-- 
Regards,
Ajay

From openssl-users at dukhovni.org  Fri Oct  7 17:47:01 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 7 Oct 2016 17:47:01 +0000
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
 <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
Message-ID: <20161007174701.GN4670@mournblade.imrryr.org>

On Fri, Oct 07, 2016 at 10:30:06PM +0530, Ajay Garg wrote:

> Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
> and if "bio1" requires reading from bio2/peer, bio_write() will return
> SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
> app-payload-encrypted-bytes from device-socket,

No, it will *usually* return SSL_ERROR_WANT_WRITE, that's when you
write "some" (based on pending data amount from bio2) to the network
that you read from bio2.  Those writes might be written via a buffer
you interpose, however it is important to flush that buffer as
much as possible before attempting any network reads (flush fully
if the network reads are potentially blocking).

However, it might sometimes return SSL_ERROR_WANT_READ, in which
case, the SSL layer wants to read, even though the application
wants to write.  Your job is to do the read on the SSL layer's
behalf, and then retry the write.

Where "some" is obtained by queried bio2 for the amount of pending
data.  You can loop reading/sending smaller amounts that if the
entire amount is too big to write to the target in one go without
blocking.  Otherwise, you need a large enough write buffer downstream.
If you can't fully drain bio2's output in one go, just keep the
socket selected for write and try again later when more space is
available.

> put them into "bio2"
> (thus internally fulfilling bio1's need for read), and then again try
> bio_write() to "bio1" WITH IDENTICAL APP-PAYLOAD-BYTES. If it again
> returns SSL_ERROR_WANT_READ, we repeat the cycle.

Well, you may not fulfill that need, if you don't drain all the
pending data, and so the SSL_ERROR_WANT_... may repeat.  What you
do with bio2 has no direct relationship on the direction of the
I/O in bio1.  Just keep track of whether the crypto wants to read
or write, and whether either bio2 or any buffer you interpose
downstream has pending data.  Then move data between the network
and bio2 as appropriate.

> For reading app-payload-bytes, we do a bio_read() from "bio1", and if
> "bio1" requires writing bytes to bio2/peer, bio_read() will return
> SSL_ERROR_WANT_WRITE (even for blocking sockets).

No, it will *usually* return SSL_ERROR_WANT_READ, that's when you
read "some" (based on desired read size from bio2) from the network
and write the results to bio2.  Those reads might be satisfied from
a buffer you interpose.

However, it might sometimes return SSL_ERROR_WANT_WRITE, in which
case, the SSL layer wants to write, even though the application wants
to read.  Your job is to do the write on the SSL layer's behalf,
and then retry the read.

> We then pick up the
> app-payload-encrypted-bytes from "bio2", transfer them over the wire
> via device-specific-socket (thus fulfilling bio1's need to send bytes
> to peer), and then again try bio_read() from "bio1" WITH IDENTICAL
> APP-PAYLOAD-BYTES. If it again returns SSL_ERROR_WANT_WRITE, we repeat
> the cycle.

When retrying app-layer reads, you do not need to provide the same
buffer or read request size on subsequent attempts.

> Obviously, for the above two sub-plots, the only chance of failure if
> reading/writing bytes fails over the wire.
> But that is not the norm; if it does happen, then everything will be
> restarted from scratch (at least by me).

> If yes, then it seems everything can be done fully synchronously for
> blocking-sockets,

No, synchronous operation will not work.  The network may not be
ready to receive more data when you're ready to write (network
layer data), or have more data when you're ready to read.  Use of
bio-pairs with blocking sockets is highly risky, you'll probably
dead-lock with some regularity.

> thus eliminating the need of multiple threads,

You don't need threads, an event loop will do.  Indeed an event
loop is generally better, don't know whether the same bio-pair is
safe for use by multiple threads.

You just need to be able to perform the equivalent of

	select()/poll()/...

on whatever interface you have for moving data to/from
the network.

-- 
	Viktor.

From MHeimlich at Steelcloud.com  Fri Oct  7 17:56:35 2016
From: MHeimlich at Steelcloud.com (Matthew Heimlich)
Date: Fri, 7 Oct 2016 17:56:35 +0000
Subject: [openssl-users] Building an application with OpenSSL and FIPS
	support.
Message-ID: <f96bb34681594427a15ed6daf3bdfe50@SC-EXCH01.Steelcloud.com>

I'm on RHEL7. I've got a very simple encryption/decryption program that works fine without FIPS support enabled, but fails when it is:

#include <openssl/conf.h>
#include <openssl/evp.h>
#include <openssl/err.h>
#include <string.h>

void handleErrors(void)
{
    ERR_print_errors_fp(stderr);
    abort();
}

    int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char *key,
    unsigned char *iv, unsigned char *ciphertext)
{
  EVP_CIPHER_CTX *ctx;

  int len;

  int ciphertext_len;

  /* Create and initialise the context */
  if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();

  /* Initialise the encryption operation. IMPORTANT - ensure you use a key
   * and IV size appropriate for your cipher
   * In this example we are using 256 bit AES (i.e. a 256 bit key). The
   * IV size for *most* modes is the same as the block size. For AES this
   * is 128 bits */
  if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
    handleErrors();

  /* Provide the message to be encrypted, and obtain the encrypted output.
   * EVP_EncryptUpdate can be called multiple times if necessary
   */
  if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len))
    handleErrors();
  ciphertext_len = len;

  /* Finalise the encryption. Further ciphertext bytes may be written at
   * this stage.
   */
  if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors();
  ciphertext_len += len;

  /* Clean up */
  EVP_CIPHER_CTX_free(ctx);

  return ciphertext_len;
}

int decrypt(unsigned char *ciphertext, int ciphertext_len, unsigned char *key,
  unsigned char *iv, unsigned char *plaintext)
{
  EVP_CIPHER_CTX *ctx;

  int len;

  int plaintext_len;

  /* Create and initialise the context */
  if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();

  /* Initialise the decryption operation. IMPORTANT - ensure you use a key
   * and IV size appropriate for your cipher
   * In this example we are using 256 bit AES (i.e. a 256 bit key). The
   * IV size for *most* modes is the same as the block size. For AES this
   * is 128 bits */
  if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
    handleErrors();

  /* Provide the message to be decrypted, and obtain the plaintext output.
   * EVP_DecryptUpdate can be called multiple times if necessary
   */
  if(1 != EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len))
    handleErrors();
  plaintext_len = len;

  /* Finalise the decryption. Further plaintext bytes may be written at
   * this stage.
   */
  if(1 != EVP_DecryptFinal_ex(ctx, plaintext + len, &len)) handleErrors();
  plaintext_len += len;

  /* Clean up */
  EVP_CIPHER_CTX_free(ctx);

  return plaintext_len;
}

int main (void)
{
  /* Force FIPS initialization */
  FIPS_mode_set(1);
  /* Set up the key and iv. Do I need to say to not hard code these in a
   * real application? :-)
   */

  /* A 256 bit key */
  unsigned char *key = (unsigned char *)"01234567890123456789012345678901";

  /* A 128 bit IV */
  unsigned char *iv = (unsigned char *)"01234567890123456";

  /* Message to be encrypted */
  unsigned char *plaintext =
                (unsigned char *)"The quick brown fox jumps over the lazy dog";

  /* Buffer for ciphertext. Ensure the buffer is long enough for the
   * ciphertext which may be longer than the plaintext, dependant on the
   * algorithm and mode
   */
  unsigned char ciphertext[128];

  /* Buffer for the decrypted text */
  unsigned char decryptedtext[128];

  int decryptedtext_len, ciphertext_len;

  /* Initialise the library */
  ERR_load_crypto_strings();
  OpenSSL_add_all_algorithms();
  OPENSSL_config(NULL);

  /* Encrypt the plaintext */
  ciphertext_len = encrypt (plaintext, strlen ((char *)plaintext), key, iv,
                            ciphertext);

  /* Do something useful with the ciphertext here */
  printf("Ciphertext is:\n");
  BIO_dump_fp (stdout, (const char *)ciphertext, ciphertext_len);

  /* Decrypt the ciphertext */
  decryptedtext_len = decrypt(ciphertext, ciphertext_len, key, iv,
    decryptedtext);

  /* Add a NULL terminator. We are expecting printable text */
  decryptedtext[decryptedtext_len] = '\0';

  /* Show the decrypted text */
  printf("Decrypted text is:\n");
  printf("%s\n", decryptedtext);

  /* Clean up */
  EVP_cleanup();
  ERR_free_strings();

  return 0;
}


As you can see, just the demo code with FIPS enabled. Without FIPS, my output is:

Ciphertext is:
0000 - e0 6f 63 a7 11 e8 b7 aa-9f 94 40 10 7d 46 80 a1   .oc....... at .}F..
0010 - 17 99 43 80 ea 31 d2 a2-99 b9 53 02 d4 39 b9 70   ..C..1....S..9.p
0020 - 2c 8e 65 a9 92 36 ec 92-07 04 91 5c f1 a9 8a 44   ,.e..6.....\...D
Decrypted text is:
The quick brown fox jumps over the lazy dog


With FIPS, compilation goes fine, but generates the following when run:

139686960322208:error:2D0A0086:FIPS routines:FIPS_cipher:selftest failed:fips_enc.c:336:
139686960322208:error:2D0A0086:FIPS routines:FIPS_cipher:selftest failed:fips_enc.c:336:


I've tried both as a C project, and as a C++ project, pointing the CC env variable at both the fipsld script, and the modified fipsld++ from the wiki script as appropriate. My FIPSLD_CC variable points to gcc as noted in the FIPS documentation.

What am I missing here??



Thanks,

Matt Heimlich ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161007/67f29ddb/attachment-0001.html>

From ajaygargnsit at gmail.com  Fri Oct  7 18:35:24 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sat, 8 Oct 2016 00:05:24 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <20161007174701.GN4670@mournblade.imrryr.org>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
 <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
 <20161007174701.GN4670@mournblade.imrryr.org>
Message-ID: <CAHP4M8V2fdxgjjnUpZtBE31gvTx=gAnsY_L5bgN_kVazNFe9Rw@mail.gmail.com>

Thanks Viktor.

On all our device-types, we are using blocking-sockets, but reads can
signal that no data is available (equivalent to SO_RCVTIMEO value set
as the socket-option on linux-like systems).

It seems you have provided me enough insight to get my hands dirty :)


Thanks and Regards,
Ajay

On Fri, Oct 7, 2016 at 11:17 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 10:30:06PM +0530, Ajay Garg wrote:
>
>> Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
>> and if "bio1" requires reading from bio2/peer, bio_write() will return
>> SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
>> app-payload-encrypted-bytes from device-socket,
>
> No, it will *usually* return SSL_ERROR_WANT_WRITE, that's when you
> write "some" (based on pending data amount from bio2) to the network
> that you read from bio2.  Those writes might be written via a buffer
> you interpose, however it is important to flush that buffer as
> much as possible before attempting any network reads (flush fully
> if the network reads are potentially blocking).
>
> However, it might sometimes return SSL_ERROR_WANT_READ, in which
> case, the SSL layer wants to read, even though the application
> wants to write.  Your job is to do the read on the SSL layer's
> behalf, and then retry the write.
>
> Where "some" is obtained by queried bio2 for the amount of pending
> data.  You can loop reading/sending smaller amounts that if the
> entire amount is too big to write to the target in one go without
> blocking.  Otherwise, you need a large enough write buffer downstream.
> If you can't fully drain bio2's output in one go, just keep the
> socket selected for write and try again later when more space is
> available.
>
>> put them into "bio2"
>> (thus internally fulfilling bio1's need for read), and then again try
>> bio_write() to "bio1" WITH IDENTICAL APP-PAYLOAD-BYTES. If it again
>> returns SSL_ERROR_WANT_READ, we repeat the cycle.
>
> Well, you may not fulfill that need, if you don't drain all the
> pending data, and so the SSL_ERROR_WANT_... may repeat.  What you
> do with bio2 has no direct relationship on the direction of the
> I/O in bio1.  Just keep track of whether the crypto wants to read
> or write, and whether either bio2 or any buffer you interpose
> downstream has pending data.  Then move data between the network
> and bio2 as appropriate.
>
>> For reading app-payload-bytes, we do a bio_read() from "bio1", and if
>> "bio1" requires writing bytes to bio2/peer, bio_read() will return
>> SSL_ERROR_WANT_WRITE (even for blocking sockets).
>
> No, it will *usually* return SSL_ERROR_WANT_READ, that's when you
> read "some" (based on desired read size from bio2) from the network
> and write the results to bio2.  Those reads might be satisfied from
> a buffer you interpose.
>
> However, it might sometimes return SSL_ERROR_WANT_WRITE, in which
> case, the SSL layer wants to write, even though the application wants
> to read.  Your job is to do the write on the SSL layer's behalf,
> and then retry the read.
>
>> We then pick up the
>> app-payload-encrypted-bytes from "bio2", transfer them over the wire
>> via device-specific-socket (thus fulfilling bio1's need to send bytes
>> to peer), and then again try bio_read() from "bio1" WITH IDENTICAL
>> APP-PAYLOAD-BYTES. If it again returns SSL_ERROR_WANT_WRITE, we repeat
>> the cycle.
>
> When retrying app-layer reads, you do not need to provide the same
> buffer or read request size on subsequent attempts.
>
>> Obviously, for the above two sub-plots, the only chance of failure if
>> reading/writing bytes fails over the wire.
>> But that is not the norm; if it does happen, then everything will be
>> restarted from scratch (at least by me).
>
>> If yes, then it seems everything can be done fully synchronously for
>> blocking-sockets,
>
> No, synchronous operation will not work.  The network may not be
> ready to receive more data when you're ready to write (network
> layer data), or have more data when you're ready to read.  Use of
> bio-pairs with blocking sockets is highly risky, you'll probably
> dead-lock with some regularity.
>
>> thus eliminating the need of multiple threads,
>
> You don't need threads, an event loop will do.  Indeed an event
> loop is generally better, don't know whether the same bio-pair is
> safe for use by multiple threads.
>
> You just need to be able to perform the equivalent of
>
>         select()/poll()/...
>
> on whatever interface you have for moving data to/from
> the network.
>
> --
>         Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay

From Craig_Weeks at trendmicro.com  Fri Oct  7 18:44:41 2016
From: Craig_Weeks at trendmicro.com (Craig_Weeks at trendmicro.com)
Date: Fri, 7 Oct 2016 18:44:41 +0000
Subject: [openssl-users] Linking FIPS 2.0.12 and OpenSSL 1.0.2f - "multiple
 definition of `bn_div_3_words"
Message-ID: <D61A2A25686C654F89CE8D10509E05E101B7F36C@SJDCEXMBX03.us.trendnet.org>

I am trying to build a library of FIPS 2.0.12 and OpenSSL 1.0.2f for MIPS architecture on vxWorks.  I am getting this error during the link step:

../libcrypto.a(bn-mips.o)(.text+0x700): In function `bn_div_3_words':
: multiple definition of `bn_div_3_words'
/usr/local/src/w/branches/zorro/tos390_tls/vendor/openssl-fips-2.0.12_installation/lib//fipscanister.o(.text+0x321c0): first defined here

I see that others have encountered this problem in the past, but I have found no explanation or resolution.

https://marc.info/?l=openssl-users&m=141216400714219&w=2

Can someone provide guidance for resolving this error?

Craig Weeks | Senior Software Engineer, Support Response Team (SRT)

craig_weeks at trendmicro.com<mailto:Richard_Fangman at trendmicro.com>

14231 Tandem Blvd, Austin TX 78728

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


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161007/7e2efaed/attachment.html>

From ethan.rahn at gmail.com  Fri Oct  7 20:01:10 2016
From: ethan.rahn at gmail.com (Ethan Rahn)
Date: Fri, 7 Oct 2016 13:01:10 -0700
Subject: [openssl-users] Building an application with OpenSSL and FIPS
	support.
In-Reply-To: <f96bb34681594427a15ed6daf3bdfe50@SC-EXCH01.Steelcloud.com>
References: <f96bb34681594427a15ed6daf3bdfe50@SC-EXCH01.Steelcloud.com>
Message-ID: <CAEW9rAj9iHzKDm+giQ6Jz6RmtH=fptGC=C1q6HzpYGByS2qTQg@mail.gmail.com>

Matt,

What part of the selftest fails? Can you step through it with a debugger?

Cheers,

Ethan

On Fri, Oct 7, 2016 at 10:56 AM, Matthew Heimlich <MHeimlich at steelcloud.com>
wrote:

> I'm on RHEL7. I've got a very simple encryption/decryption program that
> works fine without FIPS support enabled, but fails when it is:
>
> #include <openssl/conf.h>
> #include <openssl/evp.h>
> #include <openssl/err.h>
> #include <string.h>
>
> void handleErrors(void)
> {
>     ERR_print_errors_fp(stderr);
>     abort();
> }
>
>     int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char *key,
>     unsigned char *iv, unsigned char *ciphertext)
> {
>   EVP_CIPHER_CTX *ctx;
>
>   int len;
>
>   int ciphertext_len;
>
>   /* Create and initialise the context */
>   if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();
>
>   /* Initialise the encryption operation. IMPORTANT - ensure you use a key
>    * and IV size appropriate for your cipher
>    * In this example we are using 256 bit AES (i.e. a 256 bit key). The
>    * IV size for *most* modes is the same as the block size. For AES this
>    * is 128 bits */
>   if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
>     handleErrors();
>
>   /* Provide the message to be encrypted, and obtain the encrypted output.
>    * EVP_EncryptUpdate can be called multiple times if necessary
>    */
>   if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len))
>     handleErrors();
>   ciphertext_len = len;
>
>   /* Finalise the encryption. Further ciphertext bytes may be written at
>    * this stage.
>    */
>   if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors();
>   ciphertext_len += len;
>
>   /* Clean up */
>   EVP_CIPHER_CTX_free(ctx);
>
>   return ciphertext_len;
> }
>
> int decrypt(unsigned char *ciphertext, int ciphertext_len, unsigned char *key,
>   unsigned char *iv, unsigned char *plaintext)
> {
>   EVP_CIPHER_CTX *ctx;
>
>   int len;
>
>   int plaintext_len;
>
>   /* Create and initialise the context */
>   if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();
>
>   /* Initialise the decryption operation. IMPORTANT - ensure you use a key
>    * and IV size appropriate for your cipher
>    * In this example we are using 256 bit AES (i.e. a 256 bit key). The
>    * IV size for *most* modes is the same as the block size. For AES this
>    * is 128 bits */
>   if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
>     handleErrors();
>
>   /* Provide the message to be decrypted, and obtain the plaintext output.
>    * EVP_DecryptUpdate can be called multiple times if necessary
>    */
>   if(1 != EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len))
>     handleErrors();
>   plaintext_len = len;
>
>   /* Finalise the decryption. Further plaintext bytes may be written at
>    * this stage.
>    */
>   if(1 != EVP_DecryptFinal_ex(ctx, plaintext + len, &len)) handleErrors();
>   plaintext_len += len;
>
>   /* Clean up */
>   EVP_CIPHER_CTX_free(ctx);
>
>   return plaintext_len;
> }
>
> int main (void)
> {
>   /* Force FIPS initialization */
>   FIPS_mode_set(1);
>   /* Set up the key and iv. Do I need to say to not hard code these in a
>    * real application? :-)
>    */
>
>   /* A 256 bit key */
>   unsigned char *key = (unsigned char *)"01234567890123456789012345678901";
>
>   /* A 128 bit IV */
>   unsigned char *iv = (unsigned char *)"01234567890123456";
>
>   /* Message to be encrypted */
>   unsigned char *plaintext =
>                 (unsigned char *)"The quick brown fox jumps over the lazy dog";
>
>   /* Buffer for ciphertext. Ensure the buffer is long enough for the
>    * ciphertext which may be longer than the plaintext, dependant on the
>    * algorithm and mode
>    */
>   unsigned char ciphertext[128];
>
>   /* Buffer for the decrypted text */
>   unsigned char decryptedtext[128];
>
>   int decryptedtext_len, ciphertext_len;
>
>   /* Initialise the library */
>   ERR_load_crypto_strings();
>   OpenSSL_add_all_algorithms();
>   OPENSSL_config(NULL);
>
>   /* Encrypt the plaintext */
>   ciphertext_len = encrypt (plaintext, strlen ((char *)plaintext), key, iv,
>                             ciphertext);
>
>   /* Do something useful with the ciphertext here */
>   printf("Ciphertext is:\n");
>   BIO_dump_fp (stdout, (const char *)ciphertext, ciphertext_len);
>
>   /* Decrypt the ciphertext */
>   decryptedtext_len = decrypt(ciphertext, ciphertext_len, key, iv,
>     decryptedtext);
>
>   /* Add a NULL terminator. We are expecting printable text */
>   decryptedtext[decryptedtext_len] = '\0';
>
>   /* Show the decrypted text */
>   printf("Decrypted text is:\n");
>   printf("%s\n", decryptedtext);
>
>   /* Clean up */
>   EVP_cleanup();
>   ERR_free_strings();
>
>   return 0;
> }
>
> As you can see, just the demo code with FIPS enabled. Without FIPS, my
> output is:
>
> Ciphertext is:
> 0000 - e0 6f 63 a7 11 e8 b7 aa-9f 94 40 10 7d 46 80 a1   .oc....... at .}F..
> 0010 - 17 99 43 80 ea 31 d2 a2-99 b9 53 02 d4 39 b9 70   ..C..1....S..9.p
> 0020 - 2c 8e 65 a9 92 36 ec 92-07 04 91 5c f1 a9 8a 44   ,.e..6.....\...D
> Decrypted text is:
> The quick brown fox jumps over the lazy dog
>
> With FIPS, compilation goes fine, but generates the following when run:
>
> 139686960322208:error:2D0A0086:FIPS routines:FIPS_cipher:selftest failed:fips_enc.c:336:
> 139686960322208:error:2D0A0086:FIPS routines:FIPS_cipher:selftest failed:fips_enc.c:336:
>
> I've tried both as a C project, and as a C++ project, pointing the CC env
> variable at both the fipsld script, and the modified fipsld++ from the wiki
> script as appropriate. My FIPSLD_CC variable points to gcc as noted in the
> FIPS documentation.
>
> What am I missing here??
>
>
>
> Thanks,
>
> Matt Heimlich ?
>
> --
> 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/20161007/8ff801a1/attachment-0001.html>

From MHeimlich at Steelcloud.com  Fri Oct  7 20:37:01 2016
From: MHeimlich at Steelcloud.com (Matthew Heimlich)
Date: Fri, 7 Oct 2016 20:37:01 +0000
Subject: [openssl-users] Building an application with OpenSSL and
	FIPS	support.
In-Reply-To: <CAEW9rAj9iHzKDm+giQ6Jz6RmtH=fptGC=C1q6HzpYGByS2qTQg@mail.gmail.com>
References: <f96bb34681594427a15ed6daf3bdfe50@SC-EXCH01.Steelcloud.com>,
 <CAEW9rAj9iHzKDm+giQ6Jz6RmtH=fptGC=C1q6HzpYGByS2qTQg@mail.gmail.com>
Message-ID: <1475872620756.37526@Steelcloud.com>

Running fails specifically on the line:


if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors();


Although I've added some additional debugging code at this point, including this function:


int Check_Enable_FIPS(void)
{
    int mode = FIPS_mode();
    int ret = 0;
    unsigned long err = 0;

    if(mode == 0)
    {
        ret = FIPS_mode_set(1 /* on */);
        printf("Attempting to set FIPS mode to 1...\n");
        err = ERR_peek_last_error();
        printf("Last error was: %lx\n", err);
        if(ret != 1)
        {
            err = ERR_get_error();
        }
    } else {
        ret = FIPS_mode_set(0 /* off */);
        if(ret != 1)
        {
            err = ERR_get_error();
        }
    }

    if(ret != 1)
    {
        printf("FIPS_mode_set failed: %lx\n", err);
    }


    printf("FIPS mode is: %d\n", FIPS_mode());
}??

Which returns


Attempting to set FIPS mode to 1...
Last error was: 2d06b06f
FIPS_mode_set failed: 2d06b06f
FIPS mode is: 0?


So it would appear that my FIPS mode is never even being set, and walking through the code would seem to confirm this. In addition, the error code doesn't seem to be present in the FIPS documentation, but errstr informs me that it is


error:2D06B06F:FIPS routines:DSA_BUILTIN_PARAMGEN2:fingerprint does not match nonpic relocated?



Any tips on where to go from here?

Thanks,

Matt Heimlich
________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Ethan Rahn <ethan.rahn at gmail.com>
Sent: Friday, October 7, 2016 4:01 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Building an application with OpenSSL and FIPS support.

Matt,

What part of the selftest fails? Can you step through it with a debugger?

Cheers,

Ethan

On Fri, Oct 7, 2016 at 10:56 AM, Matthew Heimlich <MHeimlich at steelcloud.com<mailto:MHeimlich at steelcloud.com>> wrote:

I'm on RHEL7. I've got a very simple encryption/decryption program that works fine without FIPS support enabled, but fails when it is:

#include <openssl/conf.h>
#include <openssl/evp.h>
#include <openssl/err.h>
#include <string.h>

void handleErrors(void)
{
    ERR_print_errors_fp(stderr);
    abort();
}

    int encrypt(unsigned char *plaintext, int plaintext_len, unsigned char *key,
    unsigned char *iv, unsigned char *ciphertext)
{
  EVP_CIPHER_CTX *ctx;

  int len;

  int ciphertext_len;

  /* Create and initialise the context */
  if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();

  /* Initialise the encryption operation. IMPORTANT - ensure you use a key
   * and IV size appropriate for your cipher
   * In this example we are using 256 bit AES (i.e. a 256 bit key). The
   * IV size for *most* modes is the same as the block size. For AES this
   * is 128 bits */
  if(1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
    handleErrors();

  /* Provide the message to be encrypted, and obtain the encrypted output.
   * EVP_EncryptUpdate can be called multiple times if necessary
   */
  if(1 != EVP_EncryptUpdate(ctx, ciphertext, &len, plaintext, plaintext_len))
    handleErrors();
  ciphertext_len = len;

  /* Finalise the encryption. Further ciphertext bytes may be written at
   * this stage.
   */
  if(1 != EVP_EncryptFinal_ex(ctx, ciphertext + len, &len)) handleErrors();
  ciphertext_len += len;

  /* Clean up */
  EVP_CIPHER_CTX_free(ctx);

  return ciphertext_len;
}

int decrypt(unsigned char *ciphertext, int ciphertext_len, unsigned char *key,
  unsigned char *iv, unsigned char *plaintext)
{
  EVP_CIPHER_CTX *ctx;

  int len;

  int plaintext_len;

  /* Create and initialise the context */
  if(!(ctx = EVP_CIPHER_CTX_new())) handleErrors();

  /* Initialise the decryption operation. IMPORTANT - ensure you use a key
   * and IV size appropriate for your cipher
   * In this example we are using 256 bit AES (i.e. a 256 bit key). The
   * IV size for *most* modes is the same as the block size. For AES this
   * is 128 bits */
  if(1 != EVP_DecryptInit_ex(ctx, EVP_aes_256_cbc(), NULL, key, iv))
    handleErrors();

  /* Provide the message to be decrypted, and obtain the plaintext output.
   * EVP_DecryptUpdate can be called multiple times if necessary
   */
  if(1 != EVP_DecryptUpdate(ctx, plaintext, &len, ciphertext, ciphertext_len))
    handleErrors();
  plaintext_len = len;

  /* Finalise the decryption. Further plaintext bytes may be written at
   * this stage.
   */
  if(1 != EVP_DecryptFinal_ex(ctx, plaintext + len, &len)) handleErrors();
  plaintext_len += len;

  /* Clean up */
  EVP_CIPHER_CTX_free(ctx);

  return plaintext_len;
}

int main (void)
{
  /* Force FIPS initialization */
  FIPS_mode_set(1);
  /* Set up the key and iv. Do I need to say to not hard code these in a
   * real application? :-)
   */

  /* A 256 bit key */
  unsigned char *key = (unsigned char *)"01234567890123456789012345678901";

  /* A 128 bit IV */
  unsigned char *iv = (unsigned char *)"01234567890123456";

  /* Message to be encrypted */
  unsigned char *plaintext =
                (unsigned char *)"The quick brown fox jumps over the lazy dog";

  /* Buffer for ciphertext. Ensure the buffer is long enough for the
   * ciphertext which may be longer than the plaintext, dependant on the
   * algorithm and mode
   */
  unsigned char ciphertext[128];

  /* Buffer for the decrypted text */
  unsigned char decryptedtext[128];

  int decryptedtext_len, ciphertext_len;

  /* Initialise the library */
  ERR_load_crypto_strings();
  OpenSSL_add_all_algorithms();
  OPENSSL_config(NULL);

  /* Encrypt the plaintext */
  ciphertext_len = encrypt (plaintext, strlen ((char *)plaintext), key, iv,
                            ciphertext);

  /* Do something useful with the ciphertext here */
  printf("Ciphertext is:\n");
  BIO_dump_fp (stdout, (const char *)ciphertext, ciphertext_len);

  /* Decrypt the ciphertext */
  decryptedtext_len = decrypt(ciphertext, ciphertext_len, key, iv,
    decryptedtext);

  /* Add a NULL terminator. We are expecting printable text */
  decryptedtext[decryptedtext_len] = '\0';

  /* Show the decrypted text */
  printf("Decrypted text is:\n");
  printf("%s\n", decryptedtext);

  /* Clean up */
  EVP_cleanup();
  ERR_free_strings();

  return 0;
}


As you can see, just the demo code with FIPS enabled. Without FIPS, my output is:

Ciphertext is:
0000 - e0 6f 63 a7 11 e8 b7 aa-9f 94 40 10 7d 46 80 a1   .oc....... at .}F..
0010 - 17 99 43 80 ea 31 d2 a2-99 b9 53 02 d4 39 b9 70   ..C..1....S..9.p
0020 - 2c 8e 65 a9 92 36 ec 92-07 04 91 5c f1 a9 8a 44   ,.e..6.....\...D
Decrypted text is:
The quick brown fox jumps over the lazy dog


With FIPS, compilation goes fine, but generates the following when run:

139686960322208:error:2D0A0086:FIPS routines:FIPS_cipher:selftest failed:fips_enc.c:336:
139686960322208:error:2D0A0086:FIPS routines:FIPS_cipher:selftest failed:fips_enc.c:336:


I've tried both as a C project, and as a C++ project, pointing the CC env variable at both the fipsld script, and the modified fipsld++ from the wiki script as appropriate. My FIPSLD_CC variable points to gcc as noted in the FIPS documentation.

What am I missing here??



Thanks,

Matt Heimlich ?

--
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/20161007/8c5754f2/attachment-0001.html>

From Craig_Weeks at trendmicro.com  Fri Oct  7 21:20:27 2016
From: Craig_Weeks at trendmicro.com (Craig_Weeks at trendmicro.com)
Date: Fri, 7 Oct 2016 21:20:27 +0000
Subject: [openssl-users] Linking FIPS 2.0.12 and OpenSSL 1.0.2f -
 "multiple definition of `bn_div_3_words"
Message-ID: <D61A2A25686C654F89CE8D10509E05E101B7F447@SJDCEXMBX03.us.trendnet.org>

I was able to at least make the multiple definition error go away by specifying 'no-asm' as a parameter to the Configure command.  Can anyone explain what the implications of such a setting are?

From: Craig Weeks (RD-US)
Sent: Friday, October 7, 2016 1:45 PM
To: 'openssl-users at openssl.org' <openssl-users at openssl.org>
Subject: Linking FIPS 2.0.12 and OpenSSL 1.0.2f - "multiple definition of `bn_div_3_words"

I am trying to build a library of FIPS 2.0.12 and OpenSSL 1.0.2f for MIPS architecture on vxWorks.  I am getting this error during the link step:

../libcrypto.a(bn-mips.o)(.text+0x700): In function `bn_div_3_words':
: multiple definition of `bn_div_3_words'
/usr/local/src/w/branches/zorro/tos390_tls/vendor/openssl-fips-2.0.12_installation/lib//fipscanister.o(.text+0x321c0): first defined here

I see that others have encountered this problem in the past, but I have found no explanation or resolution.

https://marc.info/?l=openssl-users&m=141216400714219&w=2

Can someone provide guidance for resolving this error?

Craig Weeks | Senior Software Engineer, Support Response Team (SRT)

craig_weeks at trendmicro.com<mailto:Richard_Fangman at trendmicro.com>

14231 Tandem Blvd, Austin TX 78728

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


<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161007/bdd051e6/attachment.html>

From ajaygargnsit at gmail.com  Sun Oct  9 14:47:18 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sun, 9 Oct 2016 20:17:18 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <20161007174701.GN4670@mournblade.imrryr.org>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
 <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
 <20161007174701.GN4670@mournblade.imrryr.org>
Message-ID: <CAHP4M8UNLSda2hx9O5HVFQc3OzJA0sv=xJz=9XR98gTFDnO5xw@mail.gmail.com>

Hi Viktor.

On Fri, Oct 7, 2016 at 11:17 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Fri, Oct 07, 2016 at 10:30:06PM +0530, Ajay Garg wrote:
>
>> Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
>> and if "bio1" requires reading from bio2/peer, bio_write() will return
>> SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
>> app-payload-encrypted-bytes from device-socket,
>
> No, it will *usually* return SSL_ERROR_WANT_WRITE, that's when you
> write "some" (based on pending data amount from bio2) to the network
> that you read from bio2.  Those writes might be written via a buffer
> you interpose, however it is important to flush that buffer as
> much as possible before attempting any network reads (flush fully
> if the network reads are potentially blocking).
>
> However, it might sometimes return SSL_ERROR_WANT_READ, in which
> case, the SSL layer wants to read, even though the application
> wants to write.  Your job is to do the read on the SSL layer's
> behalf, and then retry the write.

For this particular sub-case, let's say SSL-layer wants to obtain "n"
bytes from the socket/wire.

So, in this case, is it ok to do a blocking-read on the socket, unless
"n" bytes are received (of course, a socket "error" will be handled in
the blocking-call; it's just that any socket-timeouts will not be
considered).



I hope the following is NOT happening internally ::

*
SSL-layer "advertises" that it wants "n" bytes from socket/wire.

*
However, in reality, it first wants "x" bytes from socket/wire, then
actually wants to send "m" bytes, and then finally wants to receive
the remaining "n-x" bytes from socket/wire.


I am sure it is not happening, just want to confirm :)

>
> Where "some" is obtained by queried bio2 for the amount of pending
> data.  You can loop reading/sending smaller amounts that if the
> entire amount is too big to write to the target in one go without
> blocking.  Otherwise, you need a large enough write buffer downstream.
> If you can't fully drain bio2's output in one go, just keep the
> socket selected for write and try again later when more space is
> available.
>
>> put them into "bio2"
>> (thus internally fulfilling bio1's need for read), and then again try
>> bio_write() to "bio1" WITH IDENTICAL APP-PAYLOAD-BYTES. If it again
>> returns SSL_ERROR_WANT_READ, we repeat the cycle.
>
> Well, you may not fulfill that need, if you don't drain all the
> pending data, and so the SSL_ERROR_WANT_... may repeat.  What you
> do with bio2 has no direct relationship on the direction of the
> I/O in bio1.  Just keep track of whether the crypto wants to read
> or write, and whether either bio2 or any buffer you interpose
> downstream has pending data.  Then move data between the network
> and bio2 as appropriate.
>
>> For reading app-payload-bytes, we do a bio_read() from "bio1", and if
>> "bio1" requires writing bytes to bio2/peer, bio_read() will return
>> SSL_ERROR_WANT_WRITE (even for blocking sockets).
>
> No, it will *usually* return SSL_ERROR_WANT_READ, that's when you
> read "some" (based on desired read size from bio2) from the network
> and write the results to bio2.  Those reads might be satisfied from
> a buffer you interpose.
>
> However, it might sometimes return SSL_ERROR_WANT_WRITE, in which
> case, the SSL layer wants to write, even though the application wants
> to read.  Your job is to do the write on the SSL layer's behalf,
> and then retry the read.
>
>> We then pick up the
>> app-payload-encrypted-bytes from "bio2", transfer them over the wire
>> via device-specific-socket (thus fulfilling bio1's need to send bytes
>> to peer), and then again try bio_read() from "bio1" WITH IDENTICAL
>> APP-PAYLOAD-BYTES. If it again returns SSL_ERROR_WANT_WRITE, we repeat
>> the cycle.
>
> When retrying app-layer reads, you do not need to provide the same
> buffer or read request size on subsequent attempts.
>
>> Obviously, for the above two sub-plots, the only chance of failure if
>> reading/writing bytes fails over the wire.
>> But that is not the norm; if it does happen, then everything will be
>> restarted from scratch (at least by me).
>
>> If yes, then it seems everything can be done fully synchronously for
>> blocking-sockets,
>
> No, synchronous operation will not work.  The network may not be
> ready to receive more data when you're ready to write (network
> layer data), or have more data when you're ready to read.  Use of
> bio-pairs with blocking sockets is highly risky, you'll probably
> dead-lock with some regularity.
>
>> thus eliminating the need of multiple threads,
>
> You don't need threads, an event loop will do.  Indeed an event
> loop is generally better, don't know whether the same bio-pair is
> safe for use by multiple threads.
>
> You just need to be able to perform the equivalent of
>
>         select()/poll()/...
>
> on whatever interface you have for moving data to/from
> the network.
>
> --
>         Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay

From openssl-users at dukhovni.org  Sun Oct  9 17:25:00 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 9 Oct 2016 13:25:00 -0400
Subject: [openssl-users] Root-Level queries while using SSL-connections
	wrapping "sockets"
In-Reply-To: <CAHP4M8UNLSda2hx9O5HVFQc3OzJA0sv=xJz=9XR98gTFDnO5xw@mail.gmail.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
 <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
 <20161007174701.GN4670@mournblade.imrryr.org>
 <CAHP4M8UNLSda2hx9O5HVFQc3OzJA0sv=xJz=9XR98gTFDnO5xw@mail.gmail.com>
Message-ID: <C24A43DA-1E8F-4814-9514-3550F6589F32@dukhovni.org>


> On Oct 9, 2016, at 10:47 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> 
>> However, it might sometimes return SSL_ERROR_WANT_READ, in which
>> case, the SSL layer wants to read, even though the application
>> wants to write.  Your job is to do the read on the SSL layer's
>> behalf, and then retry the write.
> 
> For this particular sub-case, let's say SSL-layer wants to obtain "n"
> bytes from the socket/wire.
> 
> So, in this case, is it ok to do a blocking-read on the socket, unless
> "n" bytes are received (of course, a socket "error" will be handled in
> the blocking-call; it's just that any socket-timeouts will not be
> considered).

Yes, you can do a blocking read (provided you have already flushed all
pending writes).

-- 
	Viktor.


From ajaygargnsit at gmail.com  Sun Oct  9 18:12:12 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sun, 9 Oct 2016 23:42:12 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <C24A43DA-1E8F-4814-9514-3550F6589F32@dukhovni.org>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
 <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
 <20161007174701.GN4670@mournblade.imrryr.org>
 <CAHP4M8UNLSda2hx9O5HVFQc3OzJA0sv=xJz=9XR98gTFDnO5xw@mail.gmail.com>
 <C24A43DA-1E8F-4814-9514-3550F6589F32@dukhovni.org>
Message-ID: <CAHP4M8XwSJcWhTeYH5fbn=5SGpWRY8uw5JX6P-_QWekki5crGA@mail.gmail.com>

On Sun, Oct 9, 2016 at 10:55 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
>
>> On Oct 9, 2016, at 10:47 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
>>
>>> However, it might sometimes return SSL_ERROR_WANT_READ, in which
>>> case, the SSL layer wants to read, even though the application
>>> wants to write.  Your job is to do the read on the SSL layer's
>>> behalf, and then retry the write.
>>
>> For this particular sub-case, let's say SSL-layer wants to obtain "n"
>> bytes from the socket/wire.
>>
>> So, in this case, is it ok to do a blocking-read on the socket, unless
>> "n" bytes are received (of course, a socket "error" will be handled in
>> the blocking-call; it's just that any socket-timeouts will not be
>> considered).
>
> Yes, you can do a blocking read (provided you have already flushed all
> pending writes).

Thanks a ton Viktor for the reply.

(Yes, in the above case I mentioned, all pending writes would have
been flushed).


Also, I will be grateful if you could let me know if ANY of the
sub-flows in ANY of the flows below is wrong, remembering that "bio1"
is the SSL-BIO where the app-payload-bytes are written in, and "bio2"
is the IN-MEMORY-BIO where the app-payload-encrypted-bytes emerge.

        app   <==>   bio1   <==>    bio2   <==>   socket

Also, for all my cases, Nagle's algorithm has been disabled on the
client as well as the server, so every write (at client/server)
constitutes a packet-transferred.


a)
Can

           BIO_write(bio1, buf, n)

return a positive, non-zero return-value other than "n"?
In other words, is it possible that only partial-bytes are written?


b)
Let's say

           BIO_write(bio1, buf, n)

was successful in writing "n" bytes to "bio1".

So, will ALL the app-payload-encrypted-bytes be available at "bio2"
immediately in a synchronous manner (so that they can be immediately
sent to the server over the wire) ?

Implicit in this workflow is my assumption that SSL too builds up a
packet for every BIO_write done over "bio1".


c)
Will the following sequence happen exactly as follows ::

   i)
   App wants to read some bytes, but in a probing manner (bytes
may/may-not have been sent by server).

   ii)
   Now, currently, "bio1", "bio2", "socket" are in clean-state.
   Nothing is pending "in the real sense" to be written/read anywhere.

   iii)
   When app does

           BIO_read(bio1)

   SSL_ERROR_WANT_READ would be returned (after all, "bio1" cannot
provide any app-payload-bytes unless it
   has received any app-payload-encrypted-bytes from server).

   iv)
   Doing

           BIO_get_read_request(bio2)

   would return 0.


   v)
   So, we try reading 1 byte from the socket (in a non-blocking
manner, obviously).
   IFFFF successful, we write the 1 byte into "bio2" (and so, "bio1"
will get the smell of a new encrypted packet).


   vi)
   Thereafter, when app again does

          BIO_read(bio1),

   (assuming we do not hit any re-negotiation case in this cycle) this time,

          BIO_get_read_request(bio2)

   will return a non-zero value "n".


  vii)
  We read the "n" bytes over the wire, and write them to "bio2".


  viii)
  Finally, the "m" decrypted-packet-bytes will be available at "bio1",
from the encrypted-packet
  of length "n+1" bytes.

Is my story of 8-points in case c) correct? :)


I am sorry for bothering you so much, but I can take comfort from the
fact that such idiotic questions will help noobs like me integrate
openssl faster, with better understanding of the internals, which will
obviously lead to slicker code.


Thanks again to everyone for the help so far ....


Thanks and Regards,
Ajay






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



-- 
Regards,
Ajay

From Michael.Wojcik at microfocus.com  Sun Oct  9 21:09:41 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sun, 9 Oct 2016 21:09:41 +0000
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <CAHP4M8XwSJcWhTeYH5fbn=5SGpWRY8uw5JX6P-_QWekki5crGA@mail.gmail.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
 <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
 <20161007174701.GN4670@mournblade.imrryr.org>
 <CAHP4M8UNLSda2hx9O5HVFQc3OzJA0sv=xJz=9XR98gTFDnO5xw@mail.gmail.com>
 <C24A43DA-1E8F-4814-9514-3550F6589F32@dukhovni.org>
 <CAHP4M8XwSJcWhTeYH5fbn=5SGpWRY8uw5JX6P-_QWekki5crGA@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015E6A7B92@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Ajay Garg
> Sent: Sunday, October 09, 2016 14:12
> 
> Also, for all my cases, Nagle's algorithm has been disabled on the
> client as well as the server, so every write (at client/server)
> constitutes a packet-transferred.

This assumption is incorrect. Nagle is not the only factor which interferes with a 1-to-1 mapping between application sends and (IP) packets on the wire. The peer's receive window, the interface and path MTUs, fragmentation, transient network failures ... many  things can either split an application message into multiple IP packets or even multiple TCP segments, or cause multiple application messages to be coalesced into a single TCP segment (which usually is also a single IP packet, now that path MTU determination usually works properly).

You should never assume TCP is anything other than a byte-stream service. An application that makes any assumptions about how its send operations translate into TCP segments or IP packets is asking for trouble.

-- 
Michael Wojcik 
Distinguished Engineer, Micro Focus 




From ajaygargnsit at gmail.com  Mon Oct 10 01:04:31 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 06:34:31 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015E6A7B92@prvxmb03.microfocus.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
 <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
 <20161007174701.GN4670@mournblade.imrryr.org>
 <CAHP4M8UNLSda2hx9O5HVFQc3OzJA0sv=xJz=9XR98gTFDnO5xw@mail.gmail.com>
 <C24A43DA-1E8F-4814-9514-3550F6589F32@dukhovni.org>
 <CAHP4M8XwSJcWhTeYH5fbn=5SGpWRY8uw5JX6P-_QWekki5crGA@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6A7B92@prvxmb03.microfocus.com>
Message-ID: <CAHP4M8WARfaKTL-E-+GT=ou1johZUbVaBSv_Vgv3GbbskSjJgw@mail.gmail.com>

Thanks Michael for the reply.

And yes, your points are absolutely valid.

We do not assume anything at the client/server as such, we just read
the byte-streams, and generate (MQTT) packets out of bytestreams as
and when the starting- and ending- boundaries of a (new) MQTT-packet
are received.


Still, I believe all my 3 questions (step a, step b, and the 8-point
story in step c) are independent of this, and would like to hear from
you experts as to if my understanding of all those 3 steps is correct,
including the all important assumption

*Implicit in this workflow is my assumption that SSL too builds up a
packet for every BIO_write done over "bio1". *

I say it the most important, because our application is MQTT-based,
and all our communication is request/response based; we send a packet,
and expect an acknowledgement.

In other words, if my implicit assumption is correct, then every
"BIO_write(bio1)" would generate a complete SSL-packet, which would be
available at "bio2" instantly and synchronously - ready to be
transferred over the wire.


Again, would be thankful from the bottom of my heart, to hear
confirmations/rejections regarding my theories in step a), step b) and
8-point-story in step c) as per my previous email.



Thanks and Regards,
Ajay

On Mon, Oct 10, 2016 at 2:39 AM, Michael Wojcik
<Michael.Wojcik at microfocus.com> wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Ajay Garg
>> Sent: Sunday, October 09, 2016 14:12
>>
>> Also, for all my cases, Nagle's algorithm has been disabled on the
>> client as well as the server, so every write (at client/server)
>> constitutes a packet-transferred.
>
> This assumption is incorrect. Nagle is not the only factor which interferes with a 1-to-1 mapping between application sends and (IP) packets on the wire. The peer's receive window, the interface and path MTUs, fragmentation, transient network failures ... many  things can either split an application message into multiple IP packets or even multiple TCP segments, or cause multiple application messages to be coalesced into a single TCP segment (which usually is also a single IP packet, now that path MTU determination usually works properly).
>
> You should never assume TCP is anything other than a byte-stream service. An application that makes any assumptions about how its send operations translate into TCP segments or IP packets is asking for trouble.
>
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay

From ajaygargnsit at gmail.com  Mon Oct 10 05:25:10 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 10:55:10 +0530
Subject: [openssl-users] Sequence of steps to initialize a ssl-session (only
	client-mode)
Message-ID: <CAHP4M8VsDmTbZgxq=7-6z5oT6VSwBz6WDzutaD282UMNQrFjFw@mail.gmail.com>

Hi All.

We are just dealing with the client-side, and following are the steps ::

    SSL_library_init();
    OpenSSL_add_ssl_algorithms();
    OpenSSL_add_all_algorithms();
    SSL_load_error_strings();
    ERR_load_crypto_strings();

    solitary_ssl_ctx = SSL_CTX_new(TLSv1_2_client_method());
    if(solitary_ssl_ctx == NULL)
    {

        HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context")
        resetDevice();
    }

    if(!SSL_CTX_use_certificate_file(solitary_ssl_ctx,
"/home/sensegrow/cert", SSL_FILETYPE_PEM))
    {
        HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context-Certificate")
        resetDevice();
    }

    if(!SSL_CTX_use_PrivateKey_file(solitary_ssl_ctx,
"/home/sensegrow/key", SSL_FILETYPE_PEM))
    {
        HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context-Key")
        resetDevice();
    }

    ssl_init_successful = 1;



-- 
Regards,
Ajay

From ajaygargnsit at gmail.com  Mon Oct 10 05:25:44 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 10:55:44 +0530
Subject: [openssl-users] [PLEASE IGNORE] Re: Sequence of steps to initialize
 a ssl-session (only client-mode)
Message-ID: <CAHP4M8WJK_8mWqwrHBwH+YTxXeLY2RtD+ycbpRfdqR_PCXhdKQ@mail.gmail.com>

Sorry, the "send" button was clicked accidentally :(

On Mon, Oct 10, 2016 at 10:55 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> Hi All.
>
> We are just dealing with the client-side, and following are the steps ::
>
>     SSL_library_init();
>     OpenSSL_add_ssl_algorithms();
>     OpenSSL_add_all_algorithms();
>     SSL_load_error_strings();
>     ERR_load_crypto_strings();
>
>     solitary_ssl_ctx = SSL_CTX_new(TLSv1_2_client_method());
>     if(solitary_ssl_ctx == NULL)
>     {
>
>         HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context")
>         resetDevice();
>     }
>
>     if(!SSL_CTX_use_certificate_file(solitary_ssl_ctx,
> "/home/sensegrow/cert", SSL_FILETYPE_PEM))
>     {
>         HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context-Certificate")
>         resetDevice();
>     }
>
>     if(!SSL_CTX_use_PrivateKey_file(solitary_ssl_ctx,
> "/home/sensegrow/key", SSL_FILETYPE_PEM))
>     {
>         HANDLE_CATASTROPHIC_INIT_ERROR("SSL-Context-Key")
>         resetDevice();
>     }
>
>     ssl_init_successful = 1;
>
>
>
> --
> Regards,
> Ajay



-- 
Regards,
Ajay

From openssl-users at dukhovni.org  Mon Oct 10 05:30:46 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Oct 2016 01:30:46 -0400
Subject: [openssl-users] Sequence of steps to initialize a ssl-session
	(only client-mode)
In-Reply-To: <CAHP4M8VsDmTbZgxq=7-6z5oT6VSwBz6WDzutaD282UMNQrFjFw@mail.gmail.com>
References: <CAHP4M8VsDmTbZgxq=7-6z5oT6VSwBz6WDzutaD282UMNQrFjFw@mail.gmail.com>
Message-ID: <75E97CC7-1A63-4C9B-B6DA-B5E06185941F@dukhovni.org>


> On Oct 10, 2016, at 1:25 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> 
>    solitary_ssl_ctx = SSL_CTX_new(TLSv1_2_client_method());

Don't use TLSv1_2_client_method(), instead use either:

	SSLv23_client_method()  -- OpenSSL <= 1.0.2
        TLS_client_method()     -- OpenSSL >= 1.1.0

If you want to disable older protocol versions, do that
via the appropriate options.

-- 
	Viktor.


From ajaygargnsit at gmail.com  Mon Oct 10 05:53:14 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 11:23:14 +0530
Subject: [openssl-users] [Version-2] Sequence of steps to initialize a
	ssl-session (only client-mode)
Message-ID: <CAHP4M8UEagSrcpUcNPoaog+LnjF2uA1mU9prJq2CvzzXfvV2kA@mail.gmail.com>

[Thanks Viktor, I made the change as suggested by you in the other
incomplete email that I sent accidentally].


Hi All.

We are just dealing with the client-side, and following are the steps ::

#################################################################################################
    SSL_library_init();
    OpenSSL_add_ssl_algorithms();
    OpenSSL_add_all_algorithms();
    SSL_load_error_strings();
    ERR_load_crypto_strings();

    solitary_ssl_ctx = SSL_CTX_new(SSLv23_client_method());
    if(solitary_ssl_ctx == NULL)
    {
        // Control does not reach here.
    }

    if(!SSL_CTX_use_certificate_file(solitary_ssl_ctx,
"/path/of/certificate", SSL_FILETYPE_PEM))
    {
        // Control does not reach here.
    }

    if(!SSL_CTX_use_PrivateKey_file(solitary_ssl_ctx, "/path/of/key",
SSL_FILETYPE_PEM))
    {
        // Control does not reach here.
    }

    socket->ssl = SSL_new(solitary_ssl_ctx);
    if(socket->ssl == NULL)
    {
        // Control does not reach here.
    }

    if (!BIO_new_bio_pair(&(socket->inter_bio), SSL_BUFFER_SIZE,
&(socket->network_bio), SSL_BUFFER_SIZE));
    {
        // *CONTROL REACHES HERE*
    }

    socket->ssl_bio = BIO_new(BIO_f_ssl());
    if (!(socket->ssl_bio))
    {
        // Status Unknown
    }

    SSL_set_connect_state(socket->ssl);
    SSL_set_bio(socket->ssl, socket->inter_bio, socket->inter_bio);
    (void)BIO_set_ssl(socket->ssl_bio, socket->ssl, BIO_NOCLOSE);
#################################################################################################




The socket structure has the following ::

#################################################################################################
           SSL *ssl;

           BIO *ssl_bio;                 // app-payload-bytes will be
written by app into it.
           BIO *inter_bio;               // intermediate-bio, have no idea
what it really is used for.
           BIO *network_bio;          // app-payload-encrypted-bytes will
"emerge" from this bio, ready to be written over the wire
#################################################################################################



I have followed the minimal steps (only for client-mode) as per
http://opensource.apple.com/source/OpenSSL096/OpenSSL096-6.2/openssl/ssl/ssltest.c
So, what am I missing which is causing

                   BIO_new_bio_pair

to fail?


Thanks and Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/1fa7508a/attachment-0001.html>

From ajaygargnsit at gmail.com  Mon Oct 10 05:56:09 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 11:26:09 +0530
Subject: [openssl-users] [Version-2] Sequence of steps to initialize a
	ssl-session (only client-mode)
In-Reply-To: <CAHP4M8UEagSrcpUcNPoaog+LnjF2uA1mU9prJq2CvzzXfvV2kA@mail.gmail.com>
References: <CAHP4M8UEagSrcpUcNPoaog+LnjF2uA1mU9prJq2CvzzXfvV2kA@mail.gmail.com>
Message-ID: <CAHP4M8Vhv11oOE__3mYHr66P4bGcdNL4Aq-nHuWgjmChMznZ3Q@mail.gmail.com>

Damn the semicolon at the end :(
Sorry for the noise.


Thanks and Regards,
Ajay

On Mon, Oct 10, 2016 at 11:23 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:

> [Thanks Viktor, I made the change as suggested by you in the other
> incomplete email that I sent accidentally].
>
>
> Hi All.
>
> We are just dealing with the client-side, and following are the steps ::
>
> ############################################################
> #####################################
>     SSL_library_init();
>     OpenSSL_add_ssl_algorithms();
>     OpenSSL_add_all_algorithms();
>     SSL_load_error_strings();
>     ERR_load_crypto_strings();
>
>     solitary_ssl_ctx = SSL_CTX_new(SSLv23_client_method());
>     if(solitary_ssl_ctx == NULL)
>     {
>         // Control does not reach here.
>     }
>
>     if(!SSL_CTX_use_certificate_file(solitary_ssl_ctx,
> "/path/of/certificate", SSL_FILETYPE_PEM))
>     {
>         // Control does not reach here.
>     }
>
>     if(!SSL_CTX_use_PrivateKey_file(solitary_ssl_ctx, "/path/of/key",
> SSL_FILETYPE_PEM))
>     {
>         // Control does not reach here.
>     }
>
>     socket->ssl = SSL_new(solitary_ssl_ctx);
>     if(socket->ssl == NULL)
>     {
>         // Control does not reach here.
>     }
>
>     if (!BIO_new_bio_pair(&(socket->inter_bio), SSL_BUFFER_SIZE,
> &(socket->network_bio), SSL_BUFFER_SIZE));
>     {
>         // *CONTROL REACHES HERE*
>     }
>
>     socket->ssl_bio = BIO_new(BIO_f_ssl());
>     if (!(socket->ssl_bio))
>     {
>         // Status Unknown
>     }
>
>     SSL_set_connect_state(socket->ssl);
>     SSL_set_bio(socket->ssl, socket->inter_bio, socket->inter_bio);
>     (void)BIO_set_ssl(socket->ssl_bio, socket->ssl, BIO_NOCLOSE);
> ############################################################
> #####################################
>
>
>
>
> The socket structure has the following ::
>
> ############################################################
> #####################################
>            SSL *ssl;
>
>            BIO *ssl_bio;                 // app-payload-bytes will be
> written by app into it.
>            BIO *inter_bio;               // intermediate-bio, have no idea
> what it really is used for.
>            BIO *network_bio;          // app-payload-encrypted-bytes will
> "emerge" from this bio, ready to be written over the wire
> ############################################################
> #####################################
>
>
>
> I have followed the minimal steps (only for client-mode) as per
> http://opensource.apple.com/source/OpenSSL096/OpenSSL096-
> 6.2/openssl/ssl/ssltest.c
> So, what am I missing which is causing
>
>                    BIO_new_bio_pair
>
> to fail?
>
>
> Thanks and Regards,
> Ajay
>
>


-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/a4c30025/attachment.html>

From ajaygargnsit at gmail.com  Mon Oct 10 06:20:56 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 11:50:56 +0530
Subject: [openssl-users] Getting the retry reason for a "failed"
	BIO_write/BIO_read
Message-ID: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>

Hi All.

Taking the socket-structure as ::

############################################################
#####################################
           SSL *ssl;

           BIO *ssl_bio;                 // app-payload-bytes will be
written by app into it.
           BIO *inter_bio;               // intermediate-bio, have no idea
what it really is used for.
           BIO *network_bio;          // app-payload-encrypted-bytes will
"emerge" from this bio, ready to be written over the wire
############################################################
#####################################




and assuming all initialization went fine, what is the correct way to get
the retry-reason ::

############################################################
#####################################
        if(BIO_should_retry(socket->ssl_bio) != 0)
        {
              int reason =  BIO_get_retry_reason(socket->ssl_bio);
        }

                                              OR

        if(BIO_should_retry(socket->ssl_bio) != 0)
        {
              int reason =
BIO_get_retry_reason(BIO_get_retry_BIO(socket->ssl_bio, NULL));
        }
############################################################
#####################################


Right now, I am receiving 0 (zero) as the reason in both the cases, and
none of SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ (in either case).


Thanks and Regards,
Ajay



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/15f8295f/attachment.html>

From openssl-users at dukhovni.org  Mon Oct 10 06:49:29 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Oct 2016 02:49:29 -0400
Subject: [openssl-users] Getting the retry reason for a "failed"
	BIO_write/BIO_read
In-Reply-To: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>
References: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>
Message-ID: <B60FA156-A80B-41AE-BC14-2271BC14889C@dukhovni.org>


> On Oct 10, 2016, at 2:20 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> 
>            BIO *inter_bio;               // intermediate-bio, have no idea what it really is used for.

The internal BIO from BIO_new_bio_pair must be attached to the SSL
handle via:

    SSL_set_bio(ssl, internal_bio, internal_bio);

When SSL writes ciphertext to the internal bio, you can read that via
the network_bio.  When you write to the network_bio, SSL can read the
data via the internal_bio.

-- 
	Viktor.


From ajaygargnsit at gmail.com  Mon Oct 10 06:58:38 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 12:28:38 +0530
Subject: [openssl-users] Getting the retry reason for a "failed"
	BIO_write/BIO_read
In-Reply-To: <B60FA156-A80B-41AE-BC14-2271BC14889C@dukhovni.org>
References: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>
 <B60FA156-A80B-41AE-BC14-2271BC14889C@dukhovni.org>
Message-ID: <CAHP4M8WMEFqkpGyuY15Rrux3wmEt6jHTR1Lwkzpk5sktLJB4SA@mail.gmail.com>

Hi Viktor,

I am already setting that.

   socket->ssl_bio = BIO_new(BIO_f_ssl());
    if (!(socket->ssl_bio))
    {
        HANDLE_CATASTROPHIC_INIT_ERROR("client-ssl-bio")
        return;
    }

    SSL_set_connect_state(socket->ssl);
    SSL_set_bio(socket->ssl, socket->inter_bio, socket->inter_bio);
    BIO_set_ssl(socket->ssl_bio, socket->ssl, BIO_NOCLOSE);


On Mon, Oct 10, 2016 at 12:19 PM, Viktor Dukhovni <
openssl-users at dukhovni.org> wrote:

>
> > On Oct 10, 2016, at 2:20 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> >
> >            BIO *inter_bio;               // intermediate-bio, have no
> idea what it really is used for.
>
> The internal BIO from BIO_new_bio_pair must be attached to the SSL
> handle via:
>
>     SSL_set_bio(ssl, internal_bio, internal_bio);
>
> When SSL writes ciphertext to the internal bio, you can read that via
> the network_bio.  When you write to the network_bio, SSL can read the
> data via the internal_bio.
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/cd20d979/attachment.html>

From ajaygargnsit at gmail.com  Mon Oct 10 07:52:19 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 13:22:19 +0530
Subject: [openssl-users] Getting the retry reason for a "failed"
	BIO_write/BIO_read
In-Reply-To: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>
References: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>
Message-ID: <CAHP4M8Wgwe6CVam-mCG9_AC2X270NvgCU9HLaFpmcOi80bRnWA@mail.gmail.com>

Following works :

If(BIO_should_read(socket->ssl_bio) != 0)

If(BIO_should_write(socket->ssl_bio) != 0)

With this, I could get the entire end-to-end workflow to work !!!!

Thanks a ton for all the help !!!

On Mon, Oct 10, 2016 at 11:50 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:

> Hi All.
>
> Taking the socket-structure as ::
>
> ############################################################
> #####################################
>            SSL *ssl;
>
>            BIO *ssl_bio;                 // app-payload-bytes will be
> written by app into it.
>            BIO *inter_bio;               // intermediate-bio, have no idea
> what it really is used for.
>            BIO *network_bio;          // app-payload-encrypted-bytes will
> "emerge" from this bio, ready to be written over the wire
> ############################################################
> #####################################
>
>
>
>
> and assuming all initialization went fine, what is the correct way to get
> the retry-reason ::
>
> ############################################################
> #####################################
>         if(BIO_should_retry(socket->ssl_bio) != 0)
>         {
>               int reason =  BIO_get_retry_reason(socket->ssl_bio);
>         }
>
>                                               OR
>
>         if(BIO_should_retry(socket->ssl_bio) != 0)
>         {
>               int reason = BIO_get_retry_reason(BIO_get_retry_BIO(socket->ssl_bio,
> NULL));
>         }
> ############################################################
> #####################################
>
>
> Right now, I am receiving 0 (zero) as the reason in both the cases, and
> none of SSL_ERROR_WANT_WRITE or SSL_ERROR_WANT_READ (in either case).
>
>
> Thanks and Regards,
> Ajay
>
>
>
> --
> Regards,
> Ajay
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/fff9d985/attachment-0001.html>

From ajaygargnsit at gmail.com  Mon Oct 10 07:56:19 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 13:26:19 +0530
Subject: [openssl-users] Root-Level queries while using SSL-connections
 wrapping "sockets"
In-Reply-To: <CAHP4M8WARfaKTL-E-+GT=ou1johZUbVaBSv_Vgv3GbbskSjJgw@mail.gmail.com>
References: <CAHP4M8VJZ79G4qjzUUSxnEo8jCPM8L-uCeMtfLtPD99mkvvxJA@mail.gmail.com>
 <20161007034901.GJ4670@mournblade.imrryr.org>
 <CAHP4M8W+yyF_fEuqwnkwfLZVEk-9ESQmJZhkW_R07R5NXMMtsg@mail.gmail.com>
 <CAHP4M8XdLBUkBE9z_H1YzBU79ZmYajm1A2CFGUzWQ8SFTHN=fw@mail.gmail.com>
 <20161007095504.GK4670@mournblade.imrryr.org>
 <CAHP4M8XJsb9QeqYp7UDOSfc=QJhoO4ANFjkyniWKcN2dgS_wGA@mail.gmail.com>
 <623a812f-a42b-5207-50cc-071b53089a3f@wisemo.com>
 <CAHP4M8XWCgUorU2=saXy+DzZY0GDwVqpNMiUcPDAYL0ZRMz3cg@mail.gmail.com>
 <20161007174701.GN4670@mournblade.imrryr.org>
 <CAHP4M8UNLSda2hx9O5HVFQc3OzJA0sv=xJz=9XR98gTFDnO5xw@mail.gmail.com>
 <C24A43DA-1E8F-4814-9514-3550F6589F32@dukhovni.org>
 <CAHP4M8XwSJcWhTeYH5fbn=5SGpWRY8uw5JX6P-_QWekki5crGA@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6A7B92@prvxmb03.microfocus.com>
 <CAHP4M8WARfaKTL-E-+GT=ou1johZUbVaBSv_Vgv3GbbskSjJgw@mail.gmail.com>
Message-ID: <CAHP4M8Vun_oBX63Nboe2wToc72caKf-HQpnBSszZN-e9nO=NxA@mail.gmail.com>

Hi All.

I guess all my theories are bang on, as the entire framework was integrated
seamlessly making use of the above "theories".

Thanks a ton to everyone, and extra thanks to Viktor ?

Thanks and Regards,
Ajay

On 10 Oct 2016 6:34 a.m., "Ajay Garg" <ajaygargnsit at gmail.com> wrote:

> Thanks Michael for the reply.
>
> And yes, your points are absolutely valid.
>
> We do not assume anything at the client/server as such, we just read
> the byte-streams, and generate (MQTT) packets out of bytestreams as
> and when the starting- and ending- boundaries of a (new) MQTT-packet
> are received.
>
>
> Still, I believe all my 3 questions (step a, step b, and the 8-point
> story in step c) are independent of this, and would like to hear from
> you experts as to if my understanding of all those 3 steps is correct,
> including the all important assumption
>
> *Implicit in this workflow is my assumption that SSL too builds up a
> packet for every BIO_write done over "bio1". *
>
> I say it the most important, because our application is MQTT-based,
> and all our communication is request/response based; we send a packet,
> and expect an acknowledgement.
>
> In other words, if my implicit assumption is correct, then every
> "BIO_write(bio1)" would generate a complete SSL-packet, which would be
> available at "bio2" instantly and synchronously - ready to be
> transferred over the wire.
>
>
> Again, would be thankful from the bottom of my heart, to hear
> confirmations/rejections regarding my theories in step a), step b) and
> 8-point-story in step c) as per my previous email.
>
>
>
> Thanks and Regards,
> Ajay
>
> On Mon, Oct 10, 2016 at 2:39 AM, Michael Wojcik
> <Michael.Wojcik at microfocus.com> wrote:
> >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf
> >> Of Ajay Garg
> >> Sent: Sunday, October 09, 2016 14:12
> >>
> >> Also, for all my cases, Nagle's algorithm has been disabled on the
> >> client as well as the server, so every write (at client/server)
> >> constitutes a packet-transferred.
> >
> > This assumption is incorrect. Nagle is not the only factor which
> interferes with a 1-to-1 mapping between application sends and (IP) packets
> on the wire. The peer's receive window, the interface and path MTUs,
> fragmentation, transient network failures ... many  things can either split
> an application message into multiple IP packets or even multiple TCP
> segments, or cause multiple application messages to be coalesced into a
> single TCP segment (which usually is also a single IP packet, now that path
> MTU determination usually works properly).
> >
> > You should never assume TCP is anything other than a byte-stream
> service. An application that makes any assumptions about how its send
> operations translate into TCP segments or IP packets is asking for trouble.
> >
> > --
> > Michael Wojcik
> > Distinguished Engineer, Micro Focus
> >
> >
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
> --
> Regards,
> Ajay
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/795673ff/attachment.html>

From openssl-users at dukhovni.org  Mon Oct 10 08:01:22 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 10 Oct 2016 04:01:22 -0400
Subject: [openssl-users] Getting the retry reason for a "failed"
	BIO_write/BIO_read
In-Reply-To: <CAHP4M8Wgwe6CVam-mCG9_AC2X270NvgCU9HLaFpmcOi80bRnWA@mail.gmail.com>
References: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>
 <CAHP4M8Wgwe6CVam-mCG9_AC2X270NvgCU9HLaFpmcOi80bRnWA@mail.gmail.com>
Message-ID: <CDCF53F0-F1E8-4A0C-8D7B-D96E9F8221D9@dukhovni.org>


> On Oct 10, 2016, at 3:52 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> 
> If(BIO_should_read(socket->ssl_bio) != 0)
> 
> If(BIO_should_write(socket->ssl_bio) != 0)

In Postfix, we don't bother with the application layer ssl_bio,
and just do SSL_read()/SSL_write() directly.  You only need this
if you specifically want a BIO API to SSL.

> With this, I could get the entire end-to-end workflow to work !!!!

You might not be done yet.  Is the client verifying the server
certificate including name checks?  Just doing TLS, without
certificate checks, only protects against passive attacks.

-- 
	Viktor.


From ajaygargnsit at gmail.com  Mon Oct 10 09:17:54 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 14:47:54 +0530
Subject: [openssl-users] Getting the retry reason for a "failed"
	BIO_write/BIO_read
In-Reply-To: <CDCF53F0-F1E8-4A0C-8D7B-D96E9F8221D9@dukhovni.org>
References: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>
 <CAHP4M8Wgwe6CVam-mCG9_AC2X270NvgCU9HLaFpmcOi80bRnWA@mail.gmail.com>
 <CDCF53F0-F1E8-4A0C-8D7B-D96E9F8221D9@dukhovni.org>
Message-ID: <CAHP4M8WF_YjhGaPEa+6E1Ad8krBgpZjYybe5mBXY=vW_w9TnYQ@mail.gmail.com>

On Mon, Oct 10, 2016 at 1:31 PM, Viktor Dukhovni <openssl-users at dukhovni.org
> wrote:

>
> > On Oct 10, 2016, at 3:52 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
> >
> > If(BIO_should_read(socket->ssl_bio) != 0)
> >
> > If(BIO_should_write(socket->ssl_bio) != 0)
>
> In Postfix, we don't bother with the application layer ssl_bio,
> and just do SSL_read()/SSL_write() directly.  You only need this
> if you specifically want a BIO API to SSL.
>
> > With this, I could get the entire end-to-end workflow to work !!!!
>
> You might not be done yet.  Is the client verifying the server
> certificate including name checks?  Just doing TLS, without
> certificate checks, only protects against passive attacks.
>

Thanks Viktor.

I will add this "enhancement", once I complete the code, in a manner that
is portable across "any" device.
Please expect a few questions from me on other threads :P


Thanks and Regards,
Ajay

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



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/490d6a0a/attachment.html>

From ajaygargnsit at gmail.com  Mon Oct 10 11:23:36 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 10 Oct 2016 16:53:36 +0530
Subject: [openssl-users] Getting the retry reason for a "failed"
	BIO_write/BIO_read
In-Reply-To: <CAHP4M8WF_YjhGaPEa+6E1Ad8krBgpZjYybe5mBXY=vW_w9TnYQ@mail.gmail.com>
References: <CAHP4M8UmaUcpTgo+MZ33BZ1qTNDtfD3Z0zF8_CCDHKZPQx2pAA@mail.gmail.com>
 <CAHP4M8Wgwe6CVam-mCG9_AC2X270NvgCU9HLaFpmcOi80bRnWA@mail.gmail.com>
 <CDCF53F0-F1E8-4A0C-8D7B-D96E9F8221D9@dukhovni.org>
 <CAHP4M8WF_YjhGaPEa+6E1Ad8krBgpZjYybe5mBXY=vW_w9TnYQ@mail.gmail.com>
Message-ID: <CAHP4M8Xoqg2BBUL2Jt3G81gWXO3QsLimh9sqJM7XJHG7TJiOvg@mail.gmail.com>

On Mon, Oct 10, 2016 at 2:47 PM, Ajay Garg <ajaygargnsit at gmail.com> wrote:

>
>
> On Mon, Oct 10, 2016 at 1:31 PM, Viktor Dukhovni <
> openssl-users at dukhovni.org> wrote:
>
>>
>> > On Oct 10, 2016, at 3:52 AM, Ajay Garg <ajaygargnsit at gmail.com> wrote:
>> >
>> > If(BIO_should_read(socket->ssl_bio) != 0)
>> >
>> > If(BIO_should_write(socket->ssl_bio) != 0)
>>
>> In Postfix, we don't bother with the application layer ssl_bio,
>> and just do SSL_read()/SSL_write() directly.  You only need this
>> if you specifically want a BIO API to SSL.
>>
>
I am sorry, but I don't get this :(


In broad words, is there anything wrong in ::

    int rc = BIO_write(socket->ssl_bio) / BIO_read(socket->ssl)

followed by

    if(rc < 0)
    {
              If(BIO_should_read(socket->ssl_bio) != 0)
              {
              }
              If(BIO_should_write(socket->ssl_bio) != 0)
              {
              }
     }

?


>
>> > With this, I could get the entire end-to-end workflow to work !!!!
>>
>> You might not be done yet.  Is the client verifying the server
>> certificate including name checks?  Just doing TLS, without
>> certificate checks, only protects against passive attacks.
>>
>
> Thanks Viktor.
>
> I will add this "enhancement", once I complete the code, in a manner that
> is portable across "any" device.
> Please expect a few questions from me on other threads :P
>
>
> Thanks and Regards,
> Ajay
>
>>
>> --
>>         Viktor.
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
>
> --
> Regards,
> Ajay
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/de40a360/attachment-0001.html>

From steve at openssl.org  Mon Oct 10 12:24:06 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 10 Oct 2016 12:24:06 +0000
Subject: [openssl-users] Linking FIPS 2.0.12 and OpenSSL 1.0.2f -
 "multiple definition of `bn_div_3_words"
In-Reply-To: <D61A2A25686C654F89CE8D10509E05E101B7F36C@SJDCEXMBX03.us.trendnet.org>
References: <D61A2A25686C654F89CE8D10509E05E101B7F36C@SJDCEXMBX03.us.trendnet.org>
Message-ID: <20161010122406.GA26450@openssl.org>

On Fri, Oct 07, 2016, Craig_Weeks at trendmicro.com wrote:

> I am trying to build a library of FIPS 2.0.12 and OpenSSL 1.0.2f for MIPS architecture on vxWorks.  I am getting this error during the link step:
> 
> ../libcrypto.a(bn-mips.o)(.text+0x700): In function `bn_div_3_words':
> : multiple definition of `bn_div_3_words'
> /usr/local/src/w/branches/zorro/tos390_tls/vendor/openssl-fips-2.0.12_installation/lib//fipscanister.o(.text+0x321c0): first defined here
> 
> I see that others have encountered this problem in the past, but I have found no explanation or resolution.
> 

The FIPS module uses some source from regular OpenSSL. In order to avoid
duplicate symbol errors (like the one above) the ones in the FIPS module are
renames to FIPS_symbol or fips_symbol.

Unfortunately some of these haven't been renamed on some of the less commonly
used platforms. The result is the error you see above.

We can't just change the symbol name in the FIPS module as that would require
a change letter and approval. What you can however do is rename the symbol in
regular OpenSSL. The way you do this is to change occurrences of
bn_div_3_words to ossl_bn-div_3_words and the recompile regular
OpenSSL with this change: without the "fips" option. The reason for this is
that you want to ensure you have renamed all the symbols in regular OpenSSL:
if you missed any you'll get a linker error.

Then you compile a FIPS capable OpenSSL and you shouldn't get a link error any
more.

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

From steve at openssl.org  Mon Oct 10 12:44:06 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Mon, 10 Oct 2016 12:44:06 +0000
Subject: [openssl-users] Building an application with OpenSSL and
	FIPS	support.
In-Reply-To: <1475872620756.37526@Steelcloud.com>
References: <f96bb34681594427a15ed6daf3bdfe50@SC-EXCH01.Steelcloud.com>
 <CAEW9rAj9iHzKDm+giQ6Jz6RmtH=fptGC=C1q6HzpYGByS2qTQg@mail.gmail.com>
 <1475872620756.37526@Steelcloud.com>
Message-ID: <20161010124406.GB26450@openssl.org>

On Fri, Oct 07, 2016, Matthew Heimlich wrote:

> Which returns
> 
> 
> Attempting to set FIPS mode to 1...
> Last error was: 2d06b06f
> FIPS_mode_set failed: 2d06b06f
> FIPS mode is: 0???
> 
> So it would appear that my FIPS mode is never even being set, and walking through the code would seem to confirm this. In addition, the error code doesn't seem to be present in the FIPS documentation, but errstr informs me that it is
> 
> 
> error:2D06B06F:FIPS routines:DSA_BUILTIN_PARAMGEN2:fingerprint does not match nonpic relocated???
> 
> Any tips on where to go from here?
> 

Which versions of the FIPS module and OpenSSL are you using?

In the FIPS capable OpenSSL try this:

OPENSSL_FIPS=1 openssl md5 /dev/null
OPENSSL_FIPS=1 openssl sha1 /dev/null

Please give details of any errors you get.

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

From kgoldman at us.ibm.com  Mon Oct 10 13:30:28 2016
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Mon, 10 Oct 2016 09:30:28 -0400
Subject: [openssl-users] pod to html
In-Reply-To: <8df8e2a6-7368-87e7-92f7-c06da578e855@openssl.org>
References: <nt5kc9$re4$1@blaine.gmane.org>
 <8df8e2a6-7368-87e7-92f7-c06da578e855@openssl.org>
Message-ID: <ntg55h$2gb$1@blaine.gmane.org>

On 10/6/2016 10:11 AM, Matt Caswell wrote:
> make install_html_docs

That somewhat worked.

1 - I get 100's of errors of the form

/usr/bin/pod2html: -: cannot resolve L<SSL_get_error(3)> in paragraph 11.

2 - The links, typically in "SEE ALSO" are not links.

3 - The back navigation at the bottom of the page is missing.

I suspect that these are all related, probably to some configuration 
option that's missing.



From MHeimlich at Steelcloud.com  Mon Oct 10 14:11:53 2016
From: MHeimlich at Steelcloud.com (Matthew Heimlich)
Date: Mon, 10 Oct 2016 14:11:53 +0000
Subject: [openssl-users] Building an application with OpenSSL
	and	FIPS	support.
In-Reply-To: <20161010124406.GB26450@openssl.org>
References: <f96bb34681594427a15ed6daf3bdfe50@SC-EXCH01.Steelcloud.com>
 <CAEW9rAj9iHzKDm+giQ6Jz6RmtH=fptGC=C1q6HzpYGByS2qTQg@mail.gmail.com>
 <1475872620756.37526@Steelcloud.com>,<20161010124406.GB26450@openssl.org>
Message-ID: <1476108713755.68758@Steelcloud.com>

$openssl version

returns:

OpenSSL 1.0.2j-fips

My FIPS module version is openssl-fips-2.0.13

$OPENSSL_FIPS=1 openssl md5 /dev/null

returns:

Error setting digest md5
140066569107136:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180:

$OPENSSL_FIPS=1 openssl sha1 /dev/null

returns:

SHA1(/dev/null)= da39a3ee5e6b4b0d3255bfef95601890afd80709

Do that appears to be working correctly.

Thanks,

Matt Heimlich

________________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Dr. Stephen Henson <steve at openssl.org>
Sent: Monday, October 10, 2016 8:44 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Building an application with OpenSSL and   FIPS    support.

On Fri, Oct 07, 2016, Matthew Heimlich wrote:

> Which returns
>
>
> Attempting to set FIPS mode to 1...
> Last error was: 2d06b06f
> FIPS_mode_set failed: 2d06b06f
> FIPS mode is: 0???
>
> So it would appear that my FIPS mode is never even being set, and walking through the code would seem to confirm this. In addition, the error code doesn't seem to be present in the FIPS documentation, but errstr informs me that it is
>
>
> error:2D06B06F:FIPS routines:DSA_BUILTIN_PARAMGEN2:fingerprint does not match nonpic relocated???
>
> Any tips on where to go from here?
>

Which versions of the FIPS module and OpenSSL are you using?

In the FIPS capable OpenSSL try this:

OPENSSL_FIPS=1 openssl md5 /dev/null
OPENSSL_FIPS=1 openssl sha1 /dev/null

Please give details of any errors you get.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From bkaduk at akamai.com  Mon Oct 10 19:05:29 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Mon, 10 Oct 2016 14:05:29 -0500
Subject: [openssl-users] pod to html
In-Reply-To: <ntg55h$2gb$1@blaine.gmane.org>
References: <nt5kc9$re4$1@blaine.gmane.org>
 <8df8e2a6-7368-87e7-92f7-c06da578e855@openssl.org>
 <ntg55h$2gb$1@blaine.gmane.org>
Message-ID: <51ced234-846c-a00c-fbca-ae1b307b9cd4@akamai.com>

On 10/10/2016 08:30 AM, Ken Goldman wrote:
> On 10/6/2016 10:11 AM, Matt Caswell wrote:
>> make install_html_docs
>
> That somewhat worked.
>
> 1 - I get 100's of errors of the form
>
> /usr/bin/pod2html: -: cannot resolve L<SSL_get_error(3)> in paragraph 11.
>

Trying the install locally, at least some of these are "well-known",
resulting from links that cross the boundaries amongst apps/, crypto/,
and ssl/ -- doc/apps/errstr.pod links to SSL_load_error_strings as the
first "cannot resolve" error I see.  I forget why this is not trivial to
fix, though.

> 2 - The links, typically in "SEE ALSO" are not links.
>

Maybe you should post some of the generated HTML?

To reuse my errstr example, errstr.html has a SEE ALSO that is:

> <h1 id="SEE-ALSO">SEE ALSO</h1>
>
> <p><a href="../../crypto/err.html">err</a>, <a
> href="../../crypto/ERR_load_crypto_strings.html">ERR_load_crypto_strings</a>,
> <a>SSL_load_error_strings</a></p>
>

which clearly has HTML links, except for the aforementioned
SSL_load_error_strings.

> 3 - The back navigation at the bottom of the page is missing.
>
> I suspect that these are all related, probably to some configuration
> option that's missing.
>
>

Looking at
view-source:https://www.openssl.org/docs/manmaster/apps/errstr.html ,
the "You are here" hierarchy is in a <footer>, which seems to not be
referenced by anything in the openssl.git tree.  However, if we look in
git://git.openssl.org/openssl-web.git, there is a bin/mk-manpages script
that inserts precisely that footer.  So I would suggest you look in the
openssl-web repo if you are attempting to precisely reproduce the
openssl.org website and/or its manpages.

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/575bc064/attachment.html>

From bero at lindev.ch  Mon Oct 10 22:56:06 2016
From: bero at lindev.ch (Bernhard Rosenkraenzer)
Date: Tue, 11 Oct 2016 00:56:06 +0200
Subject: [openssl-users] =?utf-8?q?Porting_to_OpenSSL_1=2E1?=
Message-ID: <731b-57fc1c80-f-5d204880@92959338>


Hi,
I'm porting some code to OpenSSL 1.1 -- for the most part, it's going well, but there's some things I'm not sure about:

- What replaces a direct access to "sha1_hash" in an X509? (found in Qt 5.7)

So far, haven't come up with a proper alternative to this. Should the code be refactored to use X509_issuer_and_serial_hash (which isn't quite the same, but should still give a unique hash)?
[this is from qHash -- so the purpose really is to get a unique hash of the contents]

- What's the best way to copy an EVP_PKEY?

Also from Qt 5.7:
rsa = RSA_new();
memcpy(rsa, EVP_PKEY_get1_RSA(pkey), sizeof(RSA));
[breaks because sizeof(RSA) is no longer known]
for EC, there's EC_KEY_dup -- for RSA and DSA, not so much.

- What's the proper successor to NETSCAPE_X509? (from kdelibs4support)
I presume this (the method KSSLCertificate::toNetscape()) can just be deleted because nothing should be using Netscape x509 anymore?


Outside of those, all problems I've run into so far were fairly easy to solve.

ttyl
bero
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161011/5809482a/attachment.html>

From matt at openssl.org  Mon Oct 10 23:19:11 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 11 Oct 2016 00:19:11 +0100
Subject: [openssl-users] Porting to OpenSSL 1.1
In-Reply-To: <731b-57fc1c80-f-5d204880@92959338>
References: <731b-57fc1c80-f-5d204880@92959338>
Message-ID: <cc19518c-e683-7048-8761-3256213fb4a2@openssl.org>



On 10/10/16 23:56, Bernhard Rosenkraenzer wrote:
> Hi,
> I'm porting some code to OpenSSL 1.1 -- for the most part, it's going
> well, but there's some things I'm not sure about:
> 
> - What replaces a direct access to "sha1_hash" in an X509? (found in Qt 5.7)

You could use X509_digest() to calculate this value.

> 
> So far, haven't come up with a proper alternative to this. Should the
> code be refactored to use X509_issuer_and_serial_hash (which isn't quite
> the same, but should still give a unique hash)?
> [this is from qHash -- so the purpose really is to get a unique hash of
> the contents]
> 
> - What's the best way to copy an EVP_PKEY?

Do you really need a *copy*? EVP_PKEYs are ref counted, so normally you
just get a new ref using EVP_PKEY_up_ref().

> 
> Also from Qt 5.7:
> rsa = RSA_new();
> memcpy(rsa, EVP_PKEY_get1_RSA(pkey), sizeof(RSA));

Again, do you really need a *copy*? RSA objects are ref-counted.
EVP_PKEY_get1_RSA() gets you a new ref on the RSA.

> [breaks because sizeof(RSA) is no longer known]
> for EC, there's EC_KEY_dup -- for RSA and DSA, not so much.
> 
> - What's the proper successor to NETSCAPE_X509? (from kdelibs4support)
> I presume this (the method KSSLCertificate::toNetscape()) can just be
> deleted because nothing should be using Netscape x509 anymore?

This is an obsolete format that is no longer used so there is no
successor. It was removed in commit 0bc2f3655.

Matt



From astib at mag0.net  Tue Oct 11 05:56:38 2016
From: astib at mag0.net (Ales Stibal)
Date: Tue, 11 Oct 2016 07:56:38 +0200
Subject: [openssl-users] socket change with SSL_set_fd
In-Reply-To: <75a8c4a1-e833-cb94-8690-cc30f1c46499@mag0.net>
References: <75a8c4a1-e833-cb94-8690-cc30f1c46499@mag0.net>
Message-ID: <2cda7853-227e-80ad-f2fa-7c65c31ac75e@mag0.net>

Sorry for bumping/reposting, but does have anyone experience with 
changing SSL object's socket on the background?
I would appreciate any feedback.

Thanks,
  Ales

On 7.10.2016 11:05, Ales Stibal wrote:
> Hi folks,
> I have a small, but important question which affects my project design.
>
> May I change underlying socket for SSL with SSL_set_fd when socket was 
> already set and used before?
>
> I believe it should not be problem, since in theory it's just the 
> transport channel for OpenSSL where to write, or read from.
> Am I correct?
>
> Many thanks,
>   Ales
>


From openssl-users at dukhovni.org  Tue Oct 11 06:24:54 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 11 Oct 2016 02:24:54 -0400
Subject: [openssl-users] socket change with SSL_set_fd
In-Reply-To: <2cda7853-227e-80ad-f2fa-7c65c31ac75e@mag0.net>
References: <75a8c4a1-e833-cb94-8690-cc30f1c46499@mag0.net>
 <2cda7853-227e-80ad-f2fa-7c65c31ac75e@mag0.net>
Message-ID: <CD880E26-10A6-4A6C-AA7A-751B7BB2FF77@dukhovni.org>


> On Oct 11, 2016, at 1:56 AM, Ales Stibal <astib at mag0.net> wrote:
> 
> Sorry for bumping/reposting, but does have anyone experience with changing SSL object's socket on the background?
> I would appreciate any feedback.

If it is not documented to work, then you can't rely on it working,
even if it happens to work at present.  If you need a flexible
interface between the SSL layer and the underlying network, consider
the bio pair approach discussed in a recent thread.

It is true that OpenSSL documentation has not been, and still is not,
as comprehensive as it should be.  Nevertheless one should depend only
on documented behaviour.  Where it is clear that the documentation
is failing to describe essential features of the API, please file a
documentation issue on Github, or better yet, where the intent is
clear, contribute a documentation patch (pull-request).

-- 
	Viktor.


From rich at kde.org  Tue Oct 11 08:33:59 2016
From: rich at kde.org (Richard Moore)
Date: Tue, 11 Oct 2016 09:33:59 +0100
Subject: [openssl-users] Porting to OpenSSL 1.1
In-Reply-To: <731b-57fc1c80-f-5d204880@92959338>
References: <731b-57fc1c80-f-5d204880@92959338>
Message-ID: <CAMp7mVtPbZ035S5eiFbQNTkRMfX64MyP=3X584jUB37W4O7pRA@mail.gmail.com>

Hi Bero,

Just based on the questions it sounds like you might be trying to port Qt.
I've already done this, and the branch is here:
https://github.com/richmoore/qtbase/commits/openssl11

It'll be added as a new backend once the configure changes that are
underway are completed. See
https://wiki.qt.io/Qt_Network_Workshop_2016#OpenSSL for a road map (or ask!)

Regards

Rich.


On 10 October 2016 at 23:56, Bernhard Rosenkraenzer <bero at lindev.ch> wrote:

> Hi,
> I'm porting some code to OpenSSL 1.1 -- for the most part, it's going
> well, but there's some things I'm not sure about:
>
> - What replaces a direct access to "sha1_hash" in an X509? (found in Qt
> 5.7)
>
> So far, haven't come up with a proper alternative to this. Should the code
> be refactored to use X509_issuer_and_serial_hash (which isn't quite the
> same, but should still give a unique hash)?
> [this is from qHash -- so the purpose really is to get a unique hash of
> the contents]
>
> - What's the best way to copy an EVP_PKEY?
>
> Also from Qt 5.7:
> rsa = RSA_new();
> memcpy(rsa, EVP_PKEY_get1_RSA(pkey), sizeof(RSA));
> [breaks because sizeof(RSA) is no longer known]
> for EC, there's EC_KEY_dup -- for RSA and DSA, not so much.
>
> - What's the proper successor to NETSCAPE_X509? (from kdelibs4support)
> I presume this (the method KSSLCertificate::toNetscape()) can just be
> deleted because nothing should be using Netscape x509 anymore?
>
>
> Outside of those, all problems I've run into so far were fairly easy to
> solve.
>
> ttyl
> bero
> --
> 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/20161011/f9e237a1/attachment.html>

From steve at openssl.org  Tue Oct 11 14:31:28 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 11 Oct 2016 14:31:28 +0000
Subject: [openssl-users] Porting to OpenSSL 1.1
In-Reply-To: <731b-57fc1c80-f-5d204880@92959338>
References: <731b-57fc1c80-f-5d204880@92959338>
Message-ID: <20161011143128.GA13368@openssl.org>

On Tue, Oct 11, 2016, Bernhard Rosenkraenzer wrote:

> 
> 
> Also from Qt 5.7:
> rsa = RSA_new();
> memcpy(rsa, EVP_PKEY_get1_RSA(pkey), sizeof(RSA));
> [breaks because sizeof(RSA) is no longer known]
> for EC, there's EC_KEY_dup -- for RSA and DSA, not so much.
> 

That wouldn't work because the RSA structure contains pointers and you just
end up copying the "top level". Well it might appear to work but you could end
up accessing freed memory or leaking when the parent structure is freed.

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

From juergen at eisfair.org  Tue Oct 11 14:25:26 2016
From: juergen at eisfair.org (Juergen Edner)
Date: Tue, 11 Oct 2016 16:25:26 +0200
Subject: [openssl-users] OpenSSL - unable to get certificate CRL
Message-ID: <20161011142554.267C41A308E@mail.marwe.net>

Hi,
I hope you can help me to understand why OpenSSL doesn't act as expected
when I try to verify a certificate chain.
On my server the certificate files are stored in the following
directory structure:

/usr/local/ssl/certs     -> certificate files
              /crl       -> CRL files
              /csr       ...
              ...

In both directories symbolic hash links are pointing to the
original files (.0 for certificates, .r0 for CRLs)

When I now execute the following command an "error 3 at 0 depth
lookup:unable to get certificate CRL" error is displayed.

# openssl verify -verbose -CApath /usr/local/ssl/certs -purpose any
-crl_check /usr/local/ssl/certs/cert-to-check.pem

Due to the fact that I couldn't explain this behaviour I used strace
for a deeper analysis and found out the the program searches the CRL
file in the ../certs directory instead of the ../crl one.

...
stat64("/usr/local/ssl/certs/95f6ee89.r0", 0xbfc2f3ac) = -1 ENOENT
(No such file or directory)
..

For test purposes I've created the symbolic link to the CRL at the
given location and the verification succeed and shows "OK".

Can anyone tell me if this is the normal behaviour or how I could
force OpenSSL to search the CRLs in the right directory?  Is there
any entry in the openssl.cnf file missing?

Thanks
Juergen
-- 


From steve at openssl.org  Tue Oct 11 14:35:22 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 11 Oct 2016 14:35:22 +0000
Subject: [openssl-users] Building an application with OpenSSL
	and	FIPS	support.
In-Reply-To: <1476108713755.68758@Steelcloud.com>
References: <f96bb34681594427a15ed6daf3bdfe50@SC-EXCH01.Steelcloud.com>
 <CAEW9rAj9iHzKDm+giQ6Jz6RmtH=fptGC=C1q6HzpYGByS2qTQg@mail.gmail.com>
 <1475872620756.37526@Steelcloud.com>
 <20161010124406.GB26450@openssl.org>
 <1476108713755.68758@Steelcloud.com>
Message-ID: <20161011143522.GB13368@openssl.org>

On Mon, Oct 10, 2016, Matthew Heimlich wrote:

> $openssl version
> 
> returns:
> 
> OpenSSL 1.0.2j-fips
> 
> My FIPS module version is openssl-fips-2.0.13
> 
> $OPENSSL_FIPS=1 openssl md5 /dev/null
> 
> returns:
> 
> Error setting digest md5
> 140066569107136:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180:
> 
> $OPENSSL_FIPS=1 openssl sha1 /dev/null
> 
> returns:
> 
> SHA1(/dev/null)= da39a3ee5e6b4b0d3255bfef95601890afd80709
> 
> Do that appears to be working correctly.
> 

Can you give more details of the steps you are using to link your application?

If you're linking to the OpenSSL shared libraries then you don't need to use
fipsld at all. I'd suggest you try that as a first step and see if your
application works.

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

From rsalz at akamai.com  Tue Oct 11 16:47:28 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 11 Oct 2016 16:47:28 +0000
Subject: [openssl-users] socket change with SSL_set_fd
In-Reply-To: <2cda7853-227e-80ad-f2fa-7c65c31ac75e@mag0.net>
References: <75a8c4a1-e833-cb94-8690-cc30f1c46499@mag0.net>
 <2cda7853-227e-80ad-f2fa-7c65c31ac75e@mag0.net>
Message-ID: <3f08dfd85fe34c508372669b4f352e18@usma1ex-dag1mb1.msg.corp.akamai.com>


> Sorry for bumping/reposting, but does have anyone experience with
> changing SSL object's socket on the background?

Is the new socket connected to the exact same process, library, and state on the other side?  Then it will probably work (but why)

If you're talking about moving the TLS connection somewhere else, no.

From ajaygargnsit at gmail.com  Tue Oct 11 19:06:21 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Wed, 12 Oct 2016 00:36:21 +0530
Subject: [openssl-users] Questions on internal-buffers being used
Message-ID: <CAHP4M8WU69VGGN-H_p3WaLxPm2C7rjAk9a__dX1_ww+rKQf39A@mail.gmail.com>

Hi All.


a)
In the call,

                      int BIO_new_bio_pair(BIO **bio1, size_t
writebuf1, BIO **bio2, size_t writebuf2);

are internal-buffers malloc'ed for each of "bio1" and "bio2"?

If yes, is there a way to pass buffers from the application-layer?
I ask this, because not all systems possess dynamic-memory allocation
(or at least "malloc" is not available on all systems).

b)
Irrespective of the values of "writebuf1" and "writebuf2" in a), I see
that everything works perfect.
So, there's got to be some internal-buffer that manages the complete
ssl-packet, most probably instantiated via the call

                      BIO* BIO_new(BIO_f_ssl());

Here too, is it possible to pass the buffer from application-layer
(because of same reasons as above)?


Will be grateful for pointers.

Thanks and Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/120ca16e/attachment-0001.html>

From bkaduk at akamai.com  Tue Oct 11 19:29:05 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 11 Oct 2016 14:29:05 -0500
Subject: [openssl-users] Questions on internal-buffers being used
In-Reply-To: <CAHP4M8WU69VGGN-H_p3WaLxPm2C7rjAk9a__dX1_ww+rKQf39A@mail.gmail.com>
References: <CAHP4M8WU69VGGN-H_p3WaLxPm2C7rjAk9a__dX1_ww+rKQf39A@mail.gmail.com>
Message-ID: <2c6682c5-4e5b-2392-025f-be68ae74380e@akamai.com>

On 10/11/2016 02:06 PM, Ajay Garg wrote:
> Hi All.
>
>
> a)
> In the call,
> int BIO_new_bio_pair(BIO **bio1, size_t writebuf1, BIO **bio2, size_t
> writebuf2); are internal-buffers malloc'ed for each of "bio1" and "bio2"?
> If yes, is there a way to pass buffers from the application-layer? I
> ask this, because not all systems possess dynamic-memory allocation
> (or at least "malloc" is not available on all systems).
> b) Irrespective of the values of "writebuf1" and "writebuf2" in a), I
> see that everything works perfect. So, there's got to be some
> internal-buffer that manages the complete ssl-packet, most probably
> instantiated via the call BIO* BIO_new(BIO_f_ssl());
> Here too, is it possible to pass the buffer from application-layer
> (because of same reasons as above)?


You should be able to produce the desired effect with BIO_new_mem_buf()
(twice) and attaching the resulting BIOs to each other with
BIO_make_bio_pair().

-Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161011/6822f034/attachment.html>

From Keonho.Lee at telit.com  Wed Oct 12 00:17:37 2016
From: Keonho.Lee at telit.com (Keonho Lee)
Date: Wed, 12 Oct 2016 00:17:37 +0000
Subject: [openssl-users] Is there any tool for verification of cryptography?
Message-ID: <AM3PR06MB11719CA9B806111D2A7EEFB69FDD0@AM3PR06MB1171.eurprd06.prod.outlook.com>

Hi All,

I'd like to verify all of cryptographic algorithms on OpenSSL.
But I could not get any way like tool.
Do you have any tools for this?

BR,
KH.Lee.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autosig_Image_01.jpg
Type: image/jpg
Size: 2771 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autosig_Image_07.gif
Type: image/gif
Size: 1089 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0006.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autosig_Image_04.gif
Type: image/gif
Size: 1059 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0007.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autosig_Image_05.gif
Type: image/gif
Size: 643 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0008.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Image_01.gif
Type: image/gif
Size: 25012 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0009.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autosig_Image_02.JPG
Type: image/jpg
Size: 8465 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autosig_Image_06.gif
Type: image/gif
Size: 1091 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0010.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: autosig_Image_03.gif
Type: image/gif
Size: 1111 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/47dbe042/attachment-0011.gif>

From chris.gray at kiffer.be  Wed Oct 12 12:43:50 2016
From: chris.gray at kiffer.be (chris.gray at kiffer.be)
Date: Wed, 12 Oct 2016 13:43:50 +0100
Subject: [openssl-users] X.509 Attribute Certificate status
Message-ID: <c8c10fbceb2272274b8bc22637c58f20.squirrel@koningbalthazar.be>

Hi there,

What is the current status of ACs (as defined in X.509 and RFC 575s5) in
OpenSSL? When I did some work using them a few years back (10?) there was
no real support in the mainline; now I have a use case where they look
like a good solution but only if they are well-supported by the tools we
and our customers use (which includes OpenSSL).

Thanks for any indications

Chris Gray



From MHeimlich at Steelcloud.com  Wed Oct 12 17:55:01 2016
From: MHeimlich at Steelcloud.com (Matthew Heimlich)
Date: Wed, 12 Oct 2016 17:55:01 +0000
Subject: [openssl-users] Building an application with
	OpenSSL	and	FIPS	support.
In-Reply-To: <20161011143522.GB13368@openssl.org>
References: <f96bb34681594427a15ed6daf3bdfe50@SC-EXCH01.Steelcloud.com>
 <CAEW9rAj9iHzKDm+giQ6Jz6RmtH=fptGC=C1q6HzpYGByS2qTQg@mail.gmail.com>
 <1475872620756.37526@Steelcloud.com> <20161010124406.GB26450@openssl.org>
 <1476108713755.68758@Steelcloud.com>,<20161011143522.GB13368@openssl.org>
Message-ID: <1476294902524.14094@Steelcloud.com>

I recompiled with dynamic libraries and after linking to them the program runs without issue. I'll keep trying to hunt down the issues with the static libs. Thanks for the help.

Thanks,

Matt Heimlich
Linux Security Engineer
SteelCloud LLC
703.999.4346

________________________________________
From: openssl-users <openssl-users-bounces at openssl.org> on behalf of Dr. Stephen Henson <steve at openssl.org>
Sent: Tuesday, October 11, 2016 10:35 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Building an application with OpenSSL       and     FIPS    support.

On Mon, Oct 10, 2016, Matthew Heimlich wrote:

> $openssl version
>
> returns:
>
> OpenSSL 1.0.2j-fips
>
> My FIPS module version is openssl-fips-2.0.13
>
> $OPENSSL_FIPS=1 openssl md5 /dev/null
>
> returns:
>
> Error setting digest md5
> 140066569107136:error:060A80A3:digital envelope routines:FIPS_DIGESTINIT:disabled for fips:fips_md.c:180:
>
> $OPENSSL_FIPS=1 openssl sha1 /dev/null
>
> returns:
>
> SHA1(/dev/null)= da39a3ee5e6b4b0d3255bfef95601890afd80709
>
> Do that appears to be working correctly.
>

Can you give more details of the steps you are using to link your application?

If you're linking to the OpenSSL shared libraries then you don't need to use
fipsld at all. I'd suggest you try that as a first step and see if your
application works.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From rsalz at openssl.org  Wed Oct 12 21:25:45 2016
From: rsalz at openssl.org (Rich Salz)
Date: Wed, 12 Oct 2016 17:25:45 -0400
Subject: [openssl-users] Some policy changes: RT retiring; use GitHub
Message-ID: <20161012212545.GA8928@openssl.org>


A new blog post gives more details:
	https://www.openssl.org/blog/blog/2016/10/12/f2f-rt-github/

Effective immediately, RT is being retired, please create GitHub issues
instead.  The website has been update; the README and CONTRIBUTING files
in each release branch will be done soon.  There'll be another post on
closing old tickets soon.

GitHub pull requests are also now the only real way to request changes.
In addition, the dev team will use GitHub for all its own PR's. Our
private repo will only be done for security fixes that cannot start out
immediately "in public."

We're excited by these changes, and hope that they provide increased
transparency, and increased engagement with our community.  We hope
you're excited too!

-Rich Salz,
Dev Team Member

From ethan.rahn at gmail.com  Thu Oct 13 01:34:54 2016
From: ethan.rahn at gmail.com (Ethan Rahn)
Date: Wed, 12 Oct 2016 18:34:54 -0700
Subject: [openssl-users] Seeking to understand difference in RSA key gen
 between X9.31 and FIPS 186-4
Message-ID: <CAEW9rAiKRSNNpFdY9yuJYiL=yGg=PH9wea-fX1g9sHPD_XmddA@mail.gmail.com>

Hey Openssl-User's,

I'm trying to understand the difference between how primes are generated in
RSA X9.31 ANSI standards ( which I don't have access to ) and FIPS 186-4 (
found here: http://csrc.nist.gov/groups/STM/cavp/documents/dss2/rsa2vs.pdf )

In the code at crypto/bn/bn_x931p.c::BN_X931_generate_prime_ex you can see
that X_p1 and X_p2 are set to be 101 bit long random numbers. The FIPS
186-4 standard specifies under Table B.1 that for a 1024 bit modulus, p1
and p2 must be greater than 100 bits. So that's fine. But for 2048 and 3072
bit modulii ( sp? ) the minimum bit length of p1 and p2 will not be met.

Granted, ANSI X9.31 was written a long time ago, so maybe they didn't cover
2048 and 3072 bit numbers at the time. The concern that I have is that this
code doesn't appear to be meeting the newest recommendations. I'm not
enough of a crypto enthusiast to understand what the consequences of this
are, but does anyone else have any insights? Is my understanding of this
even correct, in that the FIPS 186-4 standards are not being met?

( I'm also assuming here that since the NIST CAVP recommendations for RSA
link to the FIPS document that they are worth following, individual
opinions expressed on this mailing list over FIPS itself non-withstanding ).

Cheers,

Ethan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161012/79ba49f8/attachment.html>

From ajaygargnsit at gmail.com  Thu Oct 13 10:04:26 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Thu, 13 Oct 2016 15:34:26 +0530
Subject: [openssl-users] Questions on internal-buffers being used
In-Reply-To: <2c6682c5-4e5b-2392-025f-be68ae74380e@akamai.com>
References: <CAHP4M8WU69VGGN-H_p3WaLxPm2C7rjAk9a__dX1_ww+rKQf39A@mail.gmail.com>
 <2c6682c5-4e5b-2392-025f-be68ae74380e@akamai.com>
Message-ID: <CAHP4M8UV8k1SbX7cunY+snWBimcO2bJ_2Gxf4-LxuCG9qhp7Sw@mail.gmail.com>

Thanks Ben for the reply.

I tried the following, and the code hits the block as commented ::


###########################################################################
static char inter_bio_buf[1000];
static char network_bio_buf[1000];

{
        BIO *inter_bio_buf_bio = NULL, *network_bio_buf_bio = NULL;

        inter_bio_buf_bio = BIO_new_mem_buf(inter_bio_buf,
sizeof(inter_bio_buf));
        if(inter_bio_buf_bio == NULL)
        {
            /* Control does not reach here. */
        }

        network_bio_buf_bio = BIO_new_mem_buf(network_bio_buf,
sizeof(network_bio_buf));
        if(network_bio_buf_bio == NULL)
        {
            /* Control does not reach here. */
        }

        if(!BIO_make_bio_pair(inter_bio_buf_bio, network_bio_buf_bio))
        {
            /* CONTROL REACHES HERE. */
        }
}
############################################################################

What am I doing wrong?

On Wed, Oct 12, 2016 at 12:59 AM, Benjamin Kaduk <bkaduk at akamai.com> wrote:

> On 10/11/2016 02:06 PM, Ajay Garg wrote:
>
> Hi All.
>
>
> a)
> In the call,
>
>                       int BIO_new_bio_pair(BIO **bio1, size_t writebuf1, BIO **bio2, size_t writebuf2);
>
> are internal-buffers malloc'ed for each of "bio1" and "bio2"?
>
> If yes, is there a way to pass buffers from the application-layer?
> I ask this, because not all systems possess dynamic-memory allocation (or at least "malloc" is not available on all systems).
>
>
> b)
> Irrespective of the values of "writebuf1" and "writebuf2" in a), I see that everything works perfect.
> So, there's got to be some internal-buffer that manages the complete ssl-packet, most probably instantiated via the call
>
>                       BIO* BIO_new(BIO_f_ssl());
>
>
> Here too, is it possible to pass the buffer from application-layer (because of same reasons as above)?
>
>
>
> You should be able to produce the desired effect with BIO_new_mem_buf()
> (twice) and attaching the resulting BIOs to each other with
> BIO_make_bio_pair().
>
> -Ben
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161013/58ff6f7b/attachment.html>

From rsalz at openssl.org  Thu Oct 13 18:51:04 2016
From: rsalz at openssl.org (Rich Salz)
Date: Thu, 13 Oct 2016 14:51:04 -0400
Subject: [openssl-users] Closing old tickets
Message-ID: <20161013185104.GA32050@openssl.org>

Here is the list of old RT tickets that we are closing.  We sent email
to all of the originators, and it included the following text:

If you still think it is important for us to consider, please open an
issue on GitHub.  Don't be shy!  We are closing issues based purely
on the date, and the fact that despite several passes through our RT
tickets, we haven't closed them yet.

 480 Support for local ip address binding for connect BIO's.
1052 openssl ca: generate subjectAltName from config
1416 [PATCH] display UPN if in subjectAltName
1425 Request: make X509_NAME_oneline() use same formatter as X509_NAME_print_ex()
1482 [PATCH] add "ciphertext stealing" support to the EVP library
1518 [PATCH] Securing private RSA keys
1927 [PATCH] openssl ocsp app to autodetect ocsp_uri and issuer
1928 interface bug on Windows 64
1975 [PATCH 13/14] Add support for CPU usage reporting.
2288 [PATCH] Support optional caching of the certificate chain when using external session caching
2298 Build failure on WinCE platform openssl-1.0.0 & 1.0.0a
2330 No debug-mingw build target. just mingw and ming64.
2365 Limitations of ENGINE interface hamper performance on modern hardware
2389 [PATCH] Supporting the -md and -sigopt options in OCSP utility
2408 Enhancement: Additions to timestamp support
2415 possible insignificant bugs in md_rand.c?
2436 pkcs12 enhancements
2463 [PATCH]: OpenSSL 1.0.0d: Add abbility to load server certificate by ENGINE.
2525 [PATCH] Enhancement: Output Format for req Keys
2552 [PATCH] add ability to print root certificate 'issuer' field when using openssl verify
2562 Adding cfi/fpo records to asm (fix backtrace when debugging)
2568 enhancement request: remove ECC engine support's limitation
2574 [PATCH] ECC point coordinate blinding
2582 [PATCH]  Efficient and side channel analysis resistant 512-bit and 1024-bit modular exponentiation for optimizing RSA1024 and RSA2048 on x86_64 platforms")
2595 Capitalize X509 subject key STREET according to rfc1779
2599 Support for SHA256 and other MDs in X509 SubjectKeyIdentifier - PATCH
2601 Support for use of sha256 for certificate comparisons - PATCH
2617 pkeyutl fails depending on order of options - PATCH
2635 1/n-1 record splitting technique for CVE-2011-3389
2641 Move the libraries needed for static linking to Libs.private
2659 Problem with DH Exchange with the Oakley Groups (RFC 2412)
2665 s_client support for starttls ldap
2666 Enhancement request/Bug request (bit of both)
2752 objects.txt - update of extended key usage 
2753 [PATCH] let application explicitly seed RNG on Unix
2754 Ugly interaction of (openssl x509)'s option -x509toreq with -outform/-text/-noout
2766 TLS 1.2 Compliance - IDEA cipher not disabled
2768 Bug: internal_verify() hides errors from callbacks after X509_V_ERR_UNABLE_TO_VERIFY_LEAF_SIGNATURE
2770 openssl cryptodev fixes
2784 [PATCH]  Eefficient implementations of SHA256 and SHA512, using the Simultaneous Message Scheduling method
2787 [PATCH] enc: compress before compress/base64 is applied
2818 [PATCH] Cipher list TLSv1.2 as token; ciphers(1) update
2833 BIO_CTRL_DGRAM_QUERY_MTU handling is wrong due to bad getsockopt() use
2834 bug report: i2d(sign(10)) results in 2573 encoded
2850 [PATCH] Efficient and side channel analysis resistant 1024-bit modular exponentiation, for optimizing RSA2048 on AVX2 capable x86_64 platforms
2851 cms command - Request to handle S/MIME v3.2 mail
2868 [PATCH] CA - change order of gencrl and revoke
2873 -noemailDN only affects Subject DN
2878 [PATCH] s_client -fd
2880 Modification of the capi engine to support loading key from CERT_SYSTEM_STORE_LOCAL_MACHINE
2881 [PATCH] TLS 1 & 1.1 client ciphersuites incorrectly truncated
2884 bug in eng_cryptodev?
2886 openssl cms cmsout serial number output format
2902 [PATCH] add strings for SSL state related to Next Protocol Negotiation 
2913 Incorrect salt length indication for RSA-PSS signatures
2924 X509_verify_cert() fails unsafe if check_issued() fails
2927 Domain names that exceed 61 characters
2933 Days wrong if -enddate is passed to openssl ca
2947 leap year date handling
2953 s_server to show connection duration and transfer speed
2957 genpkey for DH key generation does not honor recommended private length
2961 [PATCH] Enhance DH Paramgen to allow setting of "recommended private key size"
2965 [PATCH] dgst: Prepend digest type when reading from stdin, too
2976 openssl x509 is hardcoded to require CSR in PEM format
2987 "openssl speed" bug with the -multi option on multi-core/processor environments
2990 Bug Report:openssl timezone issue
2995 [PATCH] - Added ability to set the iteration count for the enc function of the openssl commandline tool.
3010 Dynamic engine error handling crash
3012 bug report - excess free
3015 Bug with encoding / decoding Implicitly tagged, Optional GENERAL_NAMEs??
3032 Possible openssl bug - EVP_CIPHER_CTX_iv_length dont report correct value after EVP_CTRL_GCM_SET_IVLEN
3043 Bug Report d2i_PKCS8PrivateKey_bio() doesn't work for DH keys
3045 bug report: AES XTS fails for data unit size > 4KB
3050 x509 PEM certificate input parsing bug
3054 [PATCH] Efficient and side channel analysis resistant 1024-bit and 2048-bit modular exponentiation, optimizing RSA, DSA and DH of compatible sizes, for AVX2 capable x86_64 platforms
3056 Add secure DSA nonce flag.
3064 [PATCH] small_prime_generation
3069 An enhancement to EC key generation to enable compact point representation
3088 openssl crl - verify a CRL signature
3101 [PATCH] Add CMP (RFC 4210) implementation
3113 OpenSSL???s DH implementation uses an unnecessarily long exponent, leading to significant performance loss 
3117 [PATCH] A fast vectorized implementation of binary elliptic curves on x86-64 processors
3135 Not all items displayed by list-cipher-commands are in OBJ_sn2nid()
3153 Native issetugid function not used under Solaris
3166 RE: Possible bug/leak in OpenSSL ssl/bio_ssl.c:ssl_ctrl(BIO_CTRL_POP)
3168 PKCS12 bug when using same file for export password and key passphrase
3183 SSL_set_SSL_CTX() should apply more settings from the SSL_CTX being switched to
3222 [PATCH] asn1,evp: Add delete functions for app methods
3226 [PATCH] crypto/srp/srp_lib.c: add/correct some error handling
3240 [PATCH] Efficient 1024-bit and 2048-bit modular exponentiation for AVX512 capable x86_64 processors
3256 [PATCH] RSA512+SHA512 incompatibility results in errors
3258 Enable large Discrete Logarithm Diffie-Hellman groups
3266 [PATCH] Add the SYSTEM cipher keyword
3276 Possible Bug/Opportunity for Improvement when loading ECDSA Key/Cert (Feature Request?)
3282 [PATCH] Fix PKCS8/PKCS12 EncryptedPrivateKeyInfo decryption when password is empty
3349 Bug report: X509_check_akid() identifies non-self-signed certificate as its own issuer
3391 [PATCH] NULL function pointer call in n_ssl3_mac (ssl/s3_enc.c)
3421 [PATCH] return appropriate error if RDRAND not available
3427 crypto/bio/b_print.c: 2 useless if conditions ?
3451 [PATCH] Validity period in hours for x509
3463 [PATCH] Add support of no_application_protocol alert in ALPN protocol selection
3464 openssl s_client waiting for input on Windows
3471 [PATCH] md5-asm-aarch64-29regs 
3477 [PATCH] RFC3447 multi-prime RSA functionality and additional acceleration via AVX2 instructions
3491 Cert signing request verification false positive.
3502 nameConstraints bypass bug
3507 [PATCH] Fix memory leaks.
3513 bug report - 1.0.1i x509req challenge password
3514 BUG: openssl fails to downgrade tls protocol version during SSL handshake, when client tries to resume tls1.2 session
3517 Cipher suites should be case-insensitive
3518 Move RC4 and MD5 ciphers to LOW, post-1.0.2
3523 bug report: s_client writes to STDERR
3529 [PATCH] ASN1 generation: allow bit strings ending with zero regardless of length
3553 AES Key Wrapping with Inverse Functions
3555 OCSP Stapling Enhancement (diff included)
3561 bug report: openssl prints wrong pre_master secret in debug mode
3578 Bug report, verify using CApath not working any more
3590 [PATCH]  Fast modular exponentiation with the new VPMADD52 instructions
3591 [PATCH v2] Implement Maximum Fragment Length Negotiation (RFC 4366).
3598 Windows Phone & OpenSSL.
3604 [PATCH] User can specify the public exponent in genrsa
3624 Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8]
3627 Enhancement request: add more "Protocol" options for SSL_CONF_CTX
3632 Enhancement request: CONF_modules_load_file(): please include filename in error message
3633 Enhancement request: CONF_modules_load_file(): please add a CONF_MFLAGS_LOAD_USER_FILE
3636 BIO_read() (enc_read()) with 0 length
3641 [PATCH] EC_KEY_generate always overwrites private key  All OS  1.0.1j
3644 Encoding of EC private key is broken in all version
3648 BUG: Undefined behavior in easy_tls.c
3649 Unnecessary engine lookup in EVP_DigestInit_ex
3655 Inconsistency in d2i_SSL_SESSION
3659 BUG: EVP_DigestVerifyFinal does not take a const pointer
3660 Memory leak in s_server.c
3667 [PATCH] Faster GLV elliptic curves
3679 Memory leak in ssl_cert_dup (ssl/ssl_cert.c)
3681 function pointers in BIO set_callback
3697 Bug in s_client with loading of default certificates
3698 Bug: Ref count issue in SSL_new may cause a crash in SSL_free if REF_CHECK is defined
3702 openssl verify improvement
3712 TLS Renegotiation with Java is broken
3721 [PATCH] Additional checking of self-signed certificates
3729 [PATCH] Add support for iovec-based IO in OpenSSL
3736 [PATCH] fix parallel install with dir creation
3737 [PATCH] fix parallel generation of obj headers
3741 [PATCH] Better side-channel security for ECC table lookups
3743 [PATCH] Make it possible to only install libs
3746 -nameopt utf8 alone does not work , problem is tht crypto/asn1/a_strex.c returns -1
3748 do_name_ex in crypto/asn1/a_strex.c does not treat case 0 in XN_FLAG_SEP_MASK
3762 bug report: x509 -x509toreq does not copy extensions
3763 bug report: pkeyutl option order
3764 Missing message Alert on ssl23_get_server_hello negotiation failure
3765 Crash in PEM write functions with generated EC_KEY on Windows
3791 Problems configuring for OSX 10.8.5 (x86_64)
3794 Missing symbols for padlock_aes_block during link in Master
3797 [PATCH] evp: fix memory corruption on absent payload

From noloader at gmail.com  Fri Oct 14 02:26:47 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 13 Oct 2016 22:26:47 -0400
Subject: [openssl-users] What define(s) does enable-ec_nistp_64_gcc_128
	translate to?
Message-ID: <CAH8yC8mXwm=Mn85SK8V-8svC4Lh=RnRCwWoo=mJi_VhCucyi=w@mail.gmail.com>

I'm working on OS X and I want to audit for configure-time use of
enable-ec_nistp_64_gcc_128.

Grepping the sources shows 1 relevant hit, but I don't see a define:

$ grep -IR 'enable-ec_nistp_64_gcc_128' *
CHANGES:     Specify "enable-ec_nistp_64_gcc_128" on the Configure (or
config) command
INSTALL:  enable-ec_nistp_64_gcc_128
crypto/ec/asm/ecp_nistz256-x86_64.pl:#    "enable-ec_nistp_64_gcc_128";

What define or defines does `enable-ec_nistp_64_gcc_128` translate
into? Is there anything set in <opensslconf.h>? Or how can I audit for
it?

*****

openssl-1.1.0b$ KERNEL_BITS=64 ./config shared no-ssl2 no-comp
enable-ec_nistp_64_gcc_128 --prefix=/usr/local --openssldir=/usr/local
Operating system: x86_64-apple-darwinDarwin Kernel Version 12.6.0: Wed
Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64
Configuring for darwin64-x86_64-cc
Configuring OpenSSL version 1.1.0b (0x0x1010002fL)
***** Deprecated options: no-ssl2
    no-asan         [default]  OPENSSL_NO_ASAN
    no-comp         [option]   OPENSSL_NO_COMP (skip dir)
    no-crypto-mdebug [default]  OPENSSL_NO_CRYPTO_MDEBUG
    no-crypto-mdebug-backtrace [default]  OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    no-egd          [default]  OPENSSL_NO_EGD
    no-fuzz-afl     [default]  OPENSSL_NO_FUZZ_AFL
    no-fuzz-libfuzzer [default]  OPENSSL_NO_FUZZ_LIBFUZZER
    no-heartbeats   [default]  OPENSSL_NO_HEARTBEATS
    no-md2          [default]  OPENSSL_NO_MD2 (skip dir)
    no-msan         [default]  OPENSSL_NO_MSAN
    no-rc5          [default]  OPENSSL_NO_RC5 (skip dir)
    no-sctp         [default]  OPENSSL_NO_SCTP
    no-ssl-trace    [default]  OPENSSL_NO_SSL_TRACE
    no-ssl3         [default]  OPENSSL_NO_SSL3
    no-ssl3-method  [default]  OPENSSL_NO_SSL3_METHOD
    no-ubsan        [default]  OPENSSL_NO_UBSAN
    no-unit-test    [default]  OPENSSL_NO_UNIT_TEST
    no-weak-ssl-ciphers [default]  OPENSSL_NO_WEAK_SSL_CIPHERS
    no-zlib         [default]
    no-zlib-dynamic [default]
Configuring for darwin64-x86_64-cc
CC            =cc
...

From rsalz at akamai.com  Fri Oct 14 12:38:03 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 14 Oct 2016 12:38:03 +0000
Subject: [openssl-users] What define(s) does
	enable-ec_nistp_64_gcc_128	translate to?
In-Reply-To: <CAH8yC8mXwm=Mn85SK8V-8svC4Lh=RnRCwWoo=mJi_VhCucyi=w@mail.gmail.com>
References: <CAH8yC8mXwm=Mn85SK8V-8svC4Lh=RnRCwWoo=mJi_VhCucyi=w@mail.gmail.com>
Message-ID: <9835491f344a414b897b2f13d761bd13@usma1ex-dag1mb1.msg.corp.akamai.com>

; g grep -i ec.nistp.64.gcc


--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz



From ag4ve.us at gmail.com  Fri Oct 14 14:43:19 2016
From: ag4ve.us at gmail.com (shawn wilson)
Date: Fri, 14 Oct 2016 10:43:19 -0400
Subject: [openssl-users] Check if key is unlocked
In-Reply-To: <CAH_OBidoiX-Zf+BSX1JMifYxnzb4Rp903atDJE76edGiXQkpYg@mail.gmail.com>
References: <CAH_OBid9wf01nprkZyt1NGT=MUVkA+C3anJ6ux6E9KG45xeQug@mail.gmail.com>
 <CAH_OBifioz6PWzEy2A8fZFp2a3VoWPbXTwERO4eCkQkRdi_B5A@mail.gmail.com>
 <CAH_OBidoiX-Zf+BSX1JMifYxnzb4Rp903atDJE76edGiXQkpYg@mail.gmail.com>
Message-ID: <CAH_OBieQ6+dJsX95UdS7+wHSYpcYdpa3yqnQ=TB1uGk43TagDg@mail.gmail.com>

Is there a way to to check (from a script) if a key in the agent is
unlocked?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161014/4967dfaa/attachment.html>

From rsalz at akamai.com  Fri Oct 14 14:45:15 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 14 Oct 2016 14:45:15 +0000
Subject: [openssl-users] Check if key is unlocked
In-Reply-To: <CAH_OBieQ6+dJsX95UdS7+wHSYpcYdpa3yqnQ=TB1uGk43TagDg@mail.gmail.com>
References: <CAH_OBid9wf01nprkZyt1NGT=MUVkA+C3anJ6ux6E9KG45xeQug@mail.gmail.com>
 <CAH_OBifioz6PWzEy2A8fZFp2a3VoWPbXTwERO4eCkQkRdi_B5A@mail.gmail.com>
 <CAH_OBidoiX-Zf+BSX1JMifYxnzb4Rp903atDJE76edGiXQkpYg@mail.gmail.com>
 <CAH_OBieQ6+dJsX95UdS7+wHSYpcYdpa3yqnQ=TB1uGk43TagDg@mail.gmail.com>
Message-ID: <abf364d2a40c45a08d127e34b496e07a@usma1ex-dag1mb1.msg.corp.akamai.com>

> Is there a way to to check (from a script) if a key in the agent is unlocked? 

Agent?  Do you mean ssh?  This is openssl :)

From David.Turner at tracsis.com  Fri Oct 14 15:48:27 2016
From: David.Turner at tracsis.com (David Turner)
Date: Fri, 14 Oct 2016 15:48:27 +0000
Subject: [openssl-users] Programmatically determine latest versions
Message-ID: <VI1PR04MB1598A9CE5563EECD0AE697B582DF0@VI1PR04MB1598.eurprd04.prod.outlook.com>

Hi,

Is there a straightforward way to programmatically determine the current set of latest released versions of OpenSSL?

The context is that we perform automatic security audits of some of our systems and one of the tickboxes is "uses the latest version of OpenSSL". At the moment we check the website (and some mirrors) and do a bit of munging of HTML to try and extract the latest version number, but this is not terribly pleasant. It would be awesome if there were a JSON document (or similar) that contained roughly the same information as the HTML table at https://www.openssl.org/source/. Is there such a document? For instance, is the list of tags in Github appropriately reliable?

If not, could such a document be created?

Many thanks,



-- 
David Turner 
Principal Developer 
Operations & Planning Systems Division 
Tracsis 

Tracsis Operations and Planning Systems Division is a Division of Tracsis plc and comprises Tracsis plc (05019106), Tracsis Rail Consultancy Limited 05047148), Safety Information Systems Limited trading as COMPASS (02588404) and Datasys Limited (04225250), all subsidiaries of Tracsis plc with a registered office at Leeds Innovation Centre,103 Clarendon Road, Leeds, LS2 9DF. VAT Registration No: 945 7876 61.





From matt at openssl.org  Fri Oct 14 16:01:58 2016
From: matt at openssl.org (Matt Caswell)
Date: Fri, 14 Oct 2016 17:01:58 +0100
Subject: [openssl-users] Programmatically determine latest versions
In-Reply-To: <VI1PR04MB1598A9CE5563EECD0AE697B582DF0@VI1PR04MB1598.eurprd04.prod.outlook.com>
References: <VI1PR04MB1598A9CE5563EECD0AE697B582DF0@VI1PR04MB1598.eurprd04.prod.outlook.com>
Message-ID: <673631c6-f22c-6395-c5c9-67c10628ffe4@openssl.org>



On 14/10/16 16:48, David Turner wrote:
> Hi,
> 
> Is there a straightforward way to programmatically determine the
> current set of latest released versions of OpenSSL?
> 
> The context is that we perform automatic security audits of some of
> our systems and one of the tickboxes is "uses the latest version of
> OpenSSL". At the moment we check the website (and some mirrors) and
> do a bit of munging of HTML to try and extract the latest version
> number, but this is not terribly pleasant. It would be awesome if
> there were a JSON document (or similar) that contained roughly the
> same information as the HTML table at
> https://www.openssl.org/source/. Is there such a document? For
> instance, is the list of tags in Github appropriately reliable?

Yes - I'd suggest git tags would be your best bet. We have no plans to
alter the format and our release scripts automatically generate the
tags, so they should always be there.

Matt


From bkaduk at akamai.com  Fri Oct 14 16:38:30 2016
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Fri, 14 Oct 2016 11:38:30 -0500
Subject: [openssl-users] Questions on internal-buffers being used
In-Reply-To: <CAHP4M8UV8k1SbX7cunY+snWBimcO2bJ_2Gxf4-LxuCG9qhp7Sw@mail.gmail.com>
References: <CAHP4M8WU69VGGN-H_p3WaLxPm2C7rjAk9a__dX1_ww+rKQf39A@mail.gmail.com>
 <2c6682c5-4e5b-2392-025f-be68ae74380e@akamai.com>
 <CAHP4M8UV8k1SbX7cunY+snWBimcO2bJ_2Gxf4-LxuCG9qhp7Sw@mail.gmail.com>
Message-ID: <f08e6d57-a11b-0ca6-0d3f-b35fc063fe58@akamai.com>

Showing the contents of the error queue would help, but it seems most
likely that what is going on is that I overlooked the fact that
BIO_new_mem_buf() makes a read-only BIO.  I'm not sure offhand that
there's a way to get a writeable BIO using application-supplied buffers;
maybe someone else on the list knows.

-Ben

On 10/13/2016 05:04 AM, Ajay Garg wrote:
> Thanks Ben for the reply.
>
> I tried the following, and the code hits the block as commented ::
>
>
> ###########################################################################
> static char inter_bio_buf[1000];
> static char network_bio_buf[1000];
>
> {
>         BIO *inter_bio_buf_bio = NULL, *network_bio_buf_bio = NULL;
>
>         inter_bio_buf_bio = BIO_new_mem_buf(inter_bio_buf,
> sizeof(inter_bio_buf));
>         if(inter_bio_buf_bio == NULL)
>         {
>             /* Control does not reach here. */
>         }
>
>         network_bio_buf_bio = BIO_new_mem_buf(network_bio_buf,
> sizeof(network_bio_buf));
>         if(network_bio_buf_bio == NULL)
>         {
>             /* Control does not reach here. */
>         }
>
>         if(!BIO_make_bio_pair(inter_bio_buf_bio, network_bio_buf_bio))
>         {
>             /* CONTROL REACHES HERE. */
>         }
> }
> ############################################################################
>
> What am I doing wrong?
>
> On Wed, Oct 12, 2016 at 12:59 AM, Benjamin Kaduk <bkaduk at akamai.com
> <mailto:bkaduk at akamai.com>> wrote:
>
>     On 10/11/2016 02:06 PM, Ajay Garg wrote:
>>     Hi All.
>>
>>
>>     a)
>>     In the call,
>>     int BIO_new_bio_pair(BIO **bio1, size_t writebuf1, BIO **bio2,
>>     size_t writebuf2); are internal-buffers malloc'ed for each of
>>     "bio1" and "bio2"?
>>     If yes, is there a way to pass buffers from the
>>     application-layer? I ask this, because not all systems possess
>>     dynamic-memory allocation (or at least "malloc" is not available
>>     on all systems).
>>     b) Irrespective of the values of "writebuf1" and "writebuf2" in
>>     a), I see that everything works perfect. So, there's got to be
>>     some internal-buffer that manages the complete ssl-packet, most
>>     probably instantiated via the call BIO* BIO_new(BIO_f_ssl());
>>     Here too, is it possible to pass the buffer from
>>     application-layer (because of same reasons as above)?
>
>
>     You should be able to produce the desired effect with
>     BIO_new_mem_buf() (twice) and attaching the resulting BIOs to each
>     other with BIO_make_bio_pair().
>
>     -Ben
>
>     --
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DQMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=yIux2i-e8M_BBOxWlCVHTS64upD1U_SZKodwVOZEwVk&s=wUc5DIv6EgcKaU921dtXrZxxtZnY6A8gCDQF9Zt-tSs&e=>
>
>
>
>
> -- 
> Regards,
> Ajay
>
>

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

From jjain at vmware.com  Fri Oct 14 19:56:21 2016
From: jjain at vmware.com (Jayant Jain)
Date: Fri, 14 Oct 2016 19:56:21 +0000
Subject: [openssl-users] openssl errors with 1.0.2h in a running
	application
In-Reply-To: <CO2PR05MB2440AA730BD0A7FD765981ACC9DF0@CO2PR05MB2440.namprd05.prod.outlook.com>
References: <CO2PR05MB2440AA730BD0A7FD765981ACC9DF0@CO2PR05MB2440.namprd05.prod.outlook.com>
Message-ID: <CO2PR05MB244090B5A81790F9C675B070C9DF0@CO2PR05MB2440.namprd05.prod.outlook.com>

Using openssl 1.0.2h with FIPS , we get the following two errors intermittently

2D07107B:FIPS routines:FIPS_drbg_generate:in error state

error code:   0x2d071086  fips_drbg_lib.c line 391.  (FIPS Self test failed, DRBG)

This hits the application midway. After having established a TLS session, and having received and transmitted decent number of bytes, the connection gets broken and then on trying to connect again we get the above error and the library never recovers.. One has to restart the application.

Any clues to where we should be looking

Thanks
________________________________
From: Jayant Jain
Sent: Friday, October 14, 2016 12:35:36 PM
To: openssl-users at openssl.org
Cc: Jayant Jain
Subject: openssl errors with 1.0.2h in a running application


Using openssl 1.0.2h with FIPS , we get the following two errors intermittently


2D07107B:FIPS routines:FIPS_drbg_generate:in error state


error code:   0x2d071086  fips_drbg_lib.c line 391.  (FIPS Self test failed, DRBG)

This hits the application midway. After having established a TLS session, and having received and transmitted decent number of bytes, the connection gets broken and then on trying to connect again we get the above error and the library never recovers.. One has to restart the application.

Any clues to where we should be looking

Thanks


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

From Craig_Weeks at trendmicro.com  Fri Oct 14 20:17:02 2016
From: Craig_Weeks at trendmicro.com (Craig_Weeks at trendmicro.com)
Date: Fri, 14 Oct 2016 20:17:02 +0000
Subject: [openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul
Message-ID: <D61A2A25686C654F89CE8D10509E05E101B80D6B@SJDCEXMBX03.us.trendnet.org>

We are integrating 1.0.2f into a single product that is built for a Pentium-based platform and a Mips-based platform, both running on VxWorks.  The Pentium-based version compiles and links without error.  But the Mips-based version fails with undefined references to _Stoul.  If I search the 2 libcrypto.a files for 'toul' I see this:

Mips-based:
nm vendor/openssl/62/install/lib/libcrypto.a | grep -i toul
         U _Stoul
         U _Stoul
         U _Stoul
         U _Stoul
         U _Stoul
         U _Stoul
         U _Stoul
         U _Stoul
         U _Stoul

Pentium-based:
nm vendor/openssl/69/install/lib/libcrypto.a | grep -i toul
         U strtoul
         U strtoul
         U strtoul

What can I do to get libcrypto.a to reference a function that will actually be resolved by the library files I use?

Craig Weeks | Senior Software Engineer, Support Response Team (SRT)

craig_weeks at trendmicro.com

14231 Tandem Blvd, Austin TX 78728

www.trendmicro.com

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>


From rsalz at akamai.com  Fri Oct 14 20:38:10 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 14 Oct 2016 20:38:10 +0000
Subject: [openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul
In-Reply-To: <D61A2A25686C654F89CE8D10509E05E101B80D6B@SJDCEXMBX03.us.trendnet.org>
References: <D61A2A25686C654F89CE8D10509E05E101B80D6B@SJDCEXMBX03.us.trendnet.org>
Message-ID: <2f7b606493764b6196d05258103178f3@usma1ex-dag1mb1.msg.corp.akamai.com>

"Stoul" doesn't appear in OpenSSL source.  It sounds like some header/runtime integration issue.  Try your 'nm' command with -o to see the filename.

From Craig_Weeks at trendmicro.com  Fri Oct 14 21:16:40 2016
From: Craig_Weeks at trendmicro.com (Craig_Weeks at trendmicro.com)
Date: Fri, 14 Oct 2016 21:16:40 +0000
Subject: [openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul
In-Reply-To: <2f7b606493764b6196d05258103178f3@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <D61A2A25686C654F89CE8D10509E05E101B80D6B@SJDCEXMBX03.us.trendnet.org>
 <2f7b606493764b6196d05258103178f3@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <D61A2A25686C654F89CE8D10509E05E101B80D93@SJDCEXMBX03.us.trendnet.org>

I think  you are right about some kind of munging of the .c source via some header file.  I just don't know exactly how to track that down.  Here are the files that reference _Stoul in libcrypto.a:

ec_pmeth.c
rsa_pmeth.c 
dsa_pmeth.c
dh_pmeth.c
b_sock.c
asn1_gen.c
a_strnid.c
ocsp_ht.c
ts_conf.c

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>


From rsalz at akamai.com  Fri Oct 14 21:20:38 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 14 Oct 2016 21:20:38 +0000
Subject: [openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul
In-Reply-To: <D61A2A25686C654F89CE8D10509E05E101B80D93@SJDCEXMBX03.us.trendnet.org>
References: <D61A2A25686C654F89CE8D10509E05E101B80D6B@SJDCEXMBX03.us.trendnet.org>
 <2f7b606493764b6196d05258103178f3@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D61A2A25686C654F89CE8D10509E05E101B80D93@SJDCEXMBX03.us.trendnet.org>
Message-ID: <f7f088e15f3742db833ac20dc2d8c537@usma1ex-dag1mb1.msg.corp.akamai.com>

Stoul is usually a C++ function.  Are you sure you're using the right compiler?  Add -lm to your link libraries?

That's all I've got.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz



From ag4ve.us at gmail.com  Sat Oct 15 07:55:49 2016
From: ag4ve.us at gmail.com (shawn wilson)
Date: Sat, 15 Oct 2016 03:55:49 -0400
Subject: [openssl-users] Check if key is unlocked
In-Reply-To: <abf364d2a40c45a08d127e34b496e07a@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAH_OBid9wf01nprkZyt1NGT=MUVkA+C3anJ6ux6E9KG45xeQug@mail.gmail.com>
 <CAH_OBifioz6PWzEy2A8fZFp2a3VoWPbXTwERO4eCkQkRdi_B5A@mail.gmail.com>
 <CAH_OBidoiX-Zf+BSX1JMifYxnzb4Rp903atDJE76edGiXQkpYg@mail.gmail.com>
 <CAH_OBieQ6+dJsX95UdS7+wHSYpcYdpa3yqnQ=TB1uGk43TagDg@mail.gmail.com>
 <abf364d2a40c45a08d127e34b496e07a@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAH_OBid3mdHuZFJdRwV9Ttqr09ncvrKjEU1xinLaFhixi4GD9w@mail.gmail.com>

Blah, auto complete bit me - sorry, wrong ml / ot :(

On Oct 14, 2016 10:45, "Salz, Rich" <rsalz at akamai.com> wrote:

> > Is there a way to to check (from a script) if a key in the agent is
> unlocked?
>
> Agent?  Do you mean ssh?  This is openssl :)
> --
> 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/20161015/5e31dc56/attachment.html>

From ajaygargnsit at gmail.com  Sat Oct 15 12:43:28 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sat, 15 Oct 2016 18:13:28 +0530
Subject: [openssl-users] Where to find definitions of certain functions
Message-ID: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>

Hi All.

I plan to integrate openssl in our client-side-framework, so that we can
remove all the unneeded stuff (as the TLS-versions, and
certificate-management is controlled by the server only, which is only a
limited subset amongst the vast feature-set of openssl).

As part of this, I am first bringing in *all* code into our framework, to
the extent that the code compiles as the first stage.
My progress is going mostly fine, however I am stuck as I am unable to
retrieve the definitions of certain symbols (macros I guess), such as ::

                                          ASN1_OCTET_STRING_free
                                          ASN1_OCTET_STRING_new


There are others too, but I guess that if I can be known how to retrieve
the above definitions, then others will follow similarly.
So, will be grateful to hear from you experts :)


Thanks and Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161015/95889c91/attachment.html>

From matt at openssl.org  Sat Oct 15 12:50:57 2016
From: matt at openssl.org (Matt Caswell)
Date: Sat, 15 Oct 2016 13:50:57 +0100
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
Message-ID: <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>



On 15/10/16 13:43, Ajay Garg wrote:
> Hi All.
> 
> I plan to integrate openssl in our client-side-framework, so that we can
> remove all the unneeded stuff (as the TLS-versions, and
> certificate-management is controlled by the server only, which is only a
> limited subset amongst the vast feature-set of openssl).
> 
> As part of this, I am first bringing in *all* code into our framework,
> to the extent that the code compiles as the first stage.
> My progress is going mostly fine, however I am stuck as I am unable to
> retrieve the definitions of certain symbols (macros I guess), such as ::
> 
>                                           ASN1_OCTET_STRING_free
>                                           ASN1_OCTET_STRING_new
> 
> 
> There are others too, but I guess that if I can be known how to retrieve
> the above definitions, then others will follow similarly.
> So, will be grateful to hear from you experts :)

See:

https://github.com/openssl/openssl/blob/master/crypto/asn1/tasn_typ.c

Matt



From ajaygargnsit at gmail.com  Sat Oct 15 15:05:22 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sat, 15 Oct 2016 20:35:22 +0530
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
Message-ID: <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>

Thanks Matt.


That helped.


However, I am now searching for symbols like ASN_TIME_it, but I get nothing
useful ::

*grep -r ASN1_TIME_it ~/openssl/openssl/*
/home/ajay/openssl/openssl/util/libeay.num:ASN1_TIME_it    2715
EXIST:!EXPORT_VAR_AS_FUNCTION:VARIABLE:
/home/ajay/openssl/openssl/util/libeay.num:ASN1_TIME_it    2715
EXIST:EXPORT_VAR_AS_FUNCTION:FUNCTION:

*grep -r ASN1_TIME\( ~/openssl/openssl/*
/home/ajay/openssl/openssl/crypto/asn1/a_time.c:int i2d_ASN1_TIME(ASN1_TIME
*a, unsigned char **pp)


How to search for such symbols in the cloned source-code?

On Sat, Oct 15, 2016 at 6:20 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 15/10/16 13:43, Ajay Garg wrote:
> > Hi All.
> >
> > I plan to integrate openssl in our client-side-framework, so that we can
> > remove all the unneeded stuff (as the TLS-versions, and
> > certificate-management is controlled by the server only, which is only a
> > limited subset amongst the vast feature-set of openssl).
> >
> > As part of this, I am first bringing in *all* code into our framework,
> > to the extent that the code compiles as the first stage.
> > My progress is going mostly fine, however I am stuck as I am unable to
> > retrieve the definitions of certain symbols (macros I guess), such as ::
> >
> >                                           ASN1_OCTET_STRING_free
> >                                           ASN1_OCTET_STRING_new
> >
> >
> > There are others too, but I guess that if I can be known how to retrieve
> > the above definitions, then others will follow similarly.
> > So, will be grateful to hear from you experts :)
>
> See:
>
> https://github.com/openssl/openssl/blob/master/crypto/asn1/tasn_typ.c
>
> Matt
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161015/e9e5f146/attachment.html>

From rsalz at akamai.com  Sat Oct 15 15:38:51 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 15 Oct 2016 15:38:51 +0000
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
Message-ID: <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>

> grep -r ASN1_TIME\( ~/openssl/openssl/
> /home/ajay/openssl/openssl/crypto/asn1/a_time.c:int i2d_ASN1_TIME(ASN1_TIME *a, unsigned char **pp)

> How to search for such symbols in the cloned source-code?

Much of the ASN1 data structures are created by macros and it will not be immediately obvious to newcomers how it works.

Your best bet is to use "nm -o" on the library and find the file, and then work backward from there.


From ajaygargnsit at gmail.com  Sat Oct 15 15:43:21 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sat, 15 Oct 2016 21:13:21 +0530
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>

Hardly helps :(

*nm -o /usr/lib/i386-linux-gnu/libcrypto.a  | grep ASN1_TIME_t*
nm: ebcdic.o: no symbols
/usr/lib/i386-linux-gnu/libcrypto.a:a_time.o:00000230 T
ASN1_TIME_to_generalizedtime
/usr/lib/i386-linux-gnu/libcrypto.a:ocsp_srv.o:         U
ASN1_TIME_to_generalizedtime

On Sat, Oct 15, 2016 at 9:08 PM, Salz, Rich <rsalz at akamai.com> wrote:

> > grep -r ASN1_TIME\( ~/openssl/openssl/
> > /home/ajay/openssl/openssl/crypto/asn1/a_time.c:int
> i2d_ASN1_TIME(ASN1_TIME *a, unsigned char **pp)
>
> > How to search for such symbols in the cloned source-code?
>
> Much of the ASN1 data structures are created by macros and it will not be
> immediately obvious to newcomers how it works.
>
> Your best bet is to use "nm -o" on the library and find the file, and then
> work backward from there.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161015/c5dcfe10/attachment-0001.html>

From rsalz at akamai.com  Sat Oct 15 17:25:47 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 15 Oct 2016 17:25:47 +0000
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
Message-ID: <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>

> Hardly helps :(

? /usr/lib/i386-linux-gnu/libcrypto.a:a_time.o:00000230 T ASN1_TIME_to_generalizedtime

Sure it does.  You know it's in a_time.c, which is crypto/asn1/a_time.c  And if you look in that file you see "IMPLEMENT_ASN1_FJUNCTIONS" with an ASN1_TIME argument.  So, start digging.



From ajaygargnsit at gmail.com  Sun Oct 16 13:18:43 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sun, 16 Oct 2016 18:48:43 +0530
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
 <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAHP4M8U9hbO-LesE0A22csnV3q3WOqeuDsR9Sy9hSZXMv-FBcQ@mail.gmail.com>

Thanks Salz.

I get a lot of linking-errors like ::

ex_data.c:(.text+0xaa6): undefined reference to `sk_num'
ex_data.c:(.text+0xb06): undefined reference to `sk_value'
ex_data.c:(.text+0xc5e): undefined reference to `sk_free'


Doing,



*nm -o /usr/lib/i386-linux-gnu/libssl.a | grep
sk_num*/usr/lib/i386-linux-gnu/libssl.a:s3_srvr.o:
U sk_num
/usr/lib/i386-linux-gnu/libssl.a:s3_clnt.o:         U sk_num
/usr/lib/i386-linux-gnu/libssl.a:s3_lib.o:         U sk_num
/usr/lib/i386-linux-gnu/libssl.a:s23_clnt.o:         U sk_num
/usr/lib/i386-linux-gnu/libssl.a:t1_lib.o:         U sk_num
/usr/lib/i386-linux-gnu/libssl.a:d1_srtp.o:         U sk_num
/usr/lib/i386-linux-gnu/libssl.a:ssl_lib.o:         U sk_num
/usr/lib/i386-linux-gnu/libssl.a:ssl_cert.o:         U sk_num
/usr/lib/i386-linux-gnu/libssl.a:ssl_ciph.o:         U sk_num


Now, if I see, for example in "openssl/ssl/s3_clnt.c", I do not get any
strings for "sk_num", but I do get the strings of the form
"sk_SSL_COMP_num".


Also, I tried doing the following, but could not see any correlation :



*grep -r "define SSL_COMP"
~/openssl/openssl/*/home/ajay/openssl/openssl/crypto/symhacks.h:#
define SSL_COMP_get_compression_methods        SSL_COMP_get_compress_methods
/home/ajay/openssl/openssl/crypto/symhacks.h:#  define
SSL_COMP_set0_compression_methods       SSL_COMP_set0_compress_methods
/home/ajay/openssl/openssl/crypto/symhacks.h:#  define
SSL_COMP_free_compression_methods       SSL_COMP_free_compress_methods
/home/ajay/openssl/openssl/ssl/ssl_ciph.c:#define SSL_COMP_NULL_IDX       0
/home/ajay/openssl/openssl/ssl/ssl_ciph.c:#define SSL_COMP_ZLIB_IDX       1
/home/ajay/openssl/openssl/ssl/ssl_ciph.c:#define SSL_COMP_NUM_IDX        2



What's this mystery?



On Sat, Oct 15, 2016 at 10:55 PM, Salz, Rich <rsalz at akamai.com> wrote:

> > Hardly helps :(
>
> ? /usr/lib/i386-linux-gnu/libcrypto.a:a_time.o:00000230 T
> ASN1_TIME_to_generalizedtime
>
> Sure it does.  You know it's in a_time.c, which is crypto/asn1/a_time.c
> And if you look in that file you see "IMPLEMENT_ASN1_FJUNCTIONS" with an
> ASN1_TIME argument.  So, start digging.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161016/b1069a19/attachment.html>

From rsalz at akamai.com  Sun Oct 16 14:40:33 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 16 Oct 2016 14:40:33 +0000
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <CAHP4M8U9hbO-LesE0A22csnV3q3WOqeuDsR9Sy9hSZXMv-FBcQ@mail.gmail.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
 <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8U9hbO-LesE0A22csnV3q3WOqeuDsR9Sy9hSZXMv-FBcQ@mail.gmail.com>
Message-ID: <cd0c024adae542deb4a5bc1d1189ac37@usma1ex-dag1mb1.msg.corp.akamai.com>

> ex_data.c:(.text+0xaa6): undefined reference to `sk_num'

Something seems wrong in your build environment.  Make sure you are starting with a completely empty build tree.
	-rich salz


From ajaygargnsit at gmail.com  Sun Oct 16 15:05:48 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Sun, 16 Oct 2016 20:35:48 +0530
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <cd0c024adae542deb4a5bc1d1189ac37@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
 <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8U9hbO-LesE0A22csnV3q3WOqeuDsR9Sy9hSZXMv-FBcQ@mail.gmail.com>
 <cd0c024adae542deb4a5bc1d1189ac37@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAHP4M8Vd18nwcd+2Q90ecSHNDCRxMPEan1toXc4Y8i-0OLgV1g@mail.gmail.com>

I am bringing in the relevant sources from the cloned openssl-repository,
and comping each "c unit" separately.
Also, I am not using Makefiles, rather compiling each "c unit" using gcc
using first-principles.

Could that be an issue?

On Sun, Oct 16, 2016 at 8:10 PM, Salz, Rich <rsalz at akamai.com> wrote:

> > ex_data.c:(.text+0xaa6): undefined reference to `sk_num'
>
> Something seems wrong in your build environment.  Make sure you are
> starting with a completely empty build tree.
>         -rich salz
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161016/712b3a28/attachment.html>

From rsalz at akamai.com  Sun Oct 16 16:39:08 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 16 Oct 2016 16:39:08 +0000
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <CAHP4M8Vd18nwcd+2Q90ecSHNDCRxMPEan1toXc4Y8i-0OLgV1g@mail.gmail.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
 <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8U9hbO-LesE0A22csnV3q3WOqeuDsR9Sy9hSZXMv-FBcQ@mail.gmail.com>
 <cd0c024adae542deb4a5bc1d1189ac37@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8Vd18nwcd+2Q90ecSHNDCRxMPEan1toXc4Y8i-0OLgV1g@mail.gmail.com>
Message-ID: <37578516c14b451d882c71eb795360f3@usma1ex-dag1mb1.msg.corp.akamai.com>


> Also, I am not using Makefiles, rather compiling each "c unit" using gcc using first-principles.
> Could that be an issue?

Probably.

Only "make" is supported.  You are on your own.


From crodster2k at yahoo.com  Sun Oct 16 19:06:56 2016
From: crodster2k at yahoo.com (Rob Butler)
Date: Sun, 16 Oct 2016 19:06:56 +0000 (UTC)
Subject: [openssl-users] openssl s_client B as first char sends heartbeat
References: <1035780419.866821.1476644816279.ref@mail.yahoo.com>
Message-ID: <1035780419.866821.1476644816279@mail.yahoo.com>

Hello,
I've come across something strange. ?When using openssl s_client and trying to send B (uppercase only) as the first character on any line it causes a heartbeat to be sent. ?Is this a bug or a feature? ?Any way to escape it to send the uppercase B without sending the heartbeat?
ThanksRob
openssl s_client -connect www.google.com:443
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161016/f88a1e72/attachment-0001.html>

From crodster2k at yahoo.com  Sun Oct 16 19:11:13 2016
From: crodster2k at yahoo.com (Rob Butler)
Date: Sun, 16 Oct 2016 19:11:13 +0000 (UTC)
Subject: [openssl-users] openssl s_client B as first char sends heartbeat
References: <92408853.873087.1476645074049.ref@mail.yahoo.com>
Message-ID: <92408853.873087.1476645074049@mail.yahoo.com>

Hello,
I've come across something strange. ?When using openssl s_client and trying to send B (uppercase only) as the first character on any line it causes a heartbeat to be sent. ?Is this a bug or a feature? ?Any way to escape it to send the uppercase B without sending the heartbeat?
ThanksRob
Sorry for the resend. ?Last one got sent before email was complete.
openssl s_client -connect?www.google.com:443
...
BHEARTBEATING140736923497480:error:1413B16D:SSL routines:tls1_heartbeat:peer does not accept heartbeats:t1_lib.c:3974:
or?
openssl s_client -connect?www.google.com:443
...
BYEHEARTBEATING140736923497480:error:1413B16D:SSL routines:tls1_heartbeat:peer does not accept heartbeats:t1_lib.c:3974:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161016/8bd136b1/attachment.html>

From rsalz at akamai.com  Sun Oct 16 20:12:02 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 16 Oct 2016 20:12:02 +0000
Subject: [openssl-users] openssl s_client B as first char sends heartbeat
In-Reply-To: <92408853.873087.1476645074049@mail.yahoo.com>
References: <92408853.873087.1476645074049.ref@mail.yahoo.com>
 <92408853.873087.1476645074049@mail.yahoo.com>
Message-ID: <0675024e00e342d9a8c668fd10791ec8@usma1ex-dag1mb1.msg.corp.akamai.com>

Use the ?nocommands flag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161016/c5172dec/attachment.html>

From ajaygargnsit at gmail.com  Mon Oct 17 03:15:54 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 17 Oct 2016 08:45:54 +0530
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <37578516c14b451d882c71eb795360f3@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
 <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8U9hbO-LesE0A22csnV3q3WOqeuDsR9Sy9hSZXMv-FBcQ@mail.gmail.com>
 <cd0c024adae542deb4a5bc1d1189ac37@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8Vd18nwcd+2Q90ecSHNDCRxMPEan1toXc4Y8i-0OLgV1g@mail.gmail.com>
 <37578516c14b451d882c71eb795360f3@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAHP4M8VCAahUVwiHr1a7jtFRZcH_nwdReiHYYFOSp+p00G_Qxg@mail.gmail.com>

Aahhhhh... I guess I was being an idiot.

I just realize that the recommended/best/easier way is to compile openssl
as a separate library (enabling/disabling/removing features as required),
and then link this library to our application-binary.


Thanks a ton Salz, you have saved me a LOT of hours :)


Thanks and Regards,
Ajay

On Sun, Oct 16, 2016 at 10:09 PM, Salz, Rich <rsalz at akamai.com> wrote:

>
> > Also, I am not using Makefiles, rather compiling each "c unit" using gcc
> using first-principles.
> > Could that be an issue?
>
> Probably.
>
> Only "make" is supported.  You are on your own.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161017/15a690ab/attachment.html>

From Craig_Weeks at trendmicro.com  Mon Oct 17 14:00:06 2016
From: Craig_Weeks at trendmicro.com (Craig_Weeks at trendmicro.com)
Date: Mon, 17 Oct 2016 14:00:06 +0000
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <CAHP4M8VCAahUVwiHr1a7jtFRZcH_nwdReiHYYFOSp+p00G_Qxg@mail.gmail.com>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
 <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8U9hbO-LesE0A22csnV3q3WOqeuDsR9Sy9hSZXMv-FBcQ@mail.gmail.com>
 <cd0c024adae542deb4a5bc1d1189ac37@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8Vd18nwcd+2Q90ecSHNDCRxMPEan1toXc4Y8i-0OLgV1g@mail.gmail.com>
 <37578516c14b451d882c71eb795360f3@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8VCAahUVwiHr1a7jtFRZcH_nwdReiHYYFOSp+p00G_Qxg@mail.gmail.com>
Message-ID: <D61A2A25686C654F89CE8D10509E05E101B81077@SJDCEXMBX03.us.trendnet.org>

I?m interested in the rest of this story.  Does compiling a separate library for linking work for you now?  Our product runs on two platforms: one Pentium-based and one Mips-based. The Pentium build works fine but the Mips build fails at link time with unresolved function references.

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Ajay Garg
Sent: Sunday, October 16, 2016 10:16 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Where to find definitions of certain functions

Aahhhhh... I guess I was being an idiot.
I just realize that the recommended/best/easier way is to compile openssl as a separate library (enabling/disabling/removing features as required), and then link this library to our application-binary.

Thanks a ton Salz, you have saved me a LOT of hours :)

Thanks and Regards,
Ajay

On Sun, Oct 16, 2016 at 10:09 PM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:

> Also, I am not using Makefiles, rather compiling each "c unit" using gcc using first-principles.
> Could that be an issue?

Probably.

Only "make" is supported.  You are on your own.

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



--
Regards,
Ajay

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161017/6ce56a15/attachment-0001.html>

From levitte at openssl.org  Mon Oct 17 14:12:30 2016
From: levitte at openssl.org (Richard Levitte)
Date: Mon, 17 Oct 2016 16:12:30 +0200 (CEST)
Subject: [openssl-users] openssl s_client B as first char sends heartbeat
In-Reply-To: <0675024e00e342d9a8c668fd10791ec8@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <92408853.873087.1476645074049.ref@mail.yahoo.com>
 <92408853.873087.1476645074049@mail.yahoo.com>
 <0675024e00e342d9a8c668fd10791ec8@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20161017.161230.717634073755018839.levitte@openssl.org>

In message <0675024e00e342d9a8c668fd10791ec8 at usma1ex-dag1mb1.msg.corp.akamai.com> on Sun, 16 Oct 2016 20:12:02 +0000, "Salz, Rich" <rsalz at akamai.com> said:

rsalz> Use the ?nocommands flag.

Another way, which also works with OpenSSL versions before 1.1.0, is
-ign_eof

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/

From ajaygargnsit at gmail.com  Mon Oct 17 14:42:07 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 17 Oct 2016 20:12:07 +0530
Subject: [openssl-users] Where to find definitions of certain functions
In-Reply-To: <D61A2A25686C654F89CE8D10509E05E101B81077@SJDCEXMBX03.us.trendnet.org>
References: <CAHP4M8V6DEpKS_7ZK2pT_kjmBtK3aDe6zNrm3i-99oBOiQzHHA@mail.gmail.com>
 <4a7c0977-81a0-8e3d-2b67-85cafc409118@openssl.org>
 <CAHP4M8UqmLBT4_gdVWdHj4ogWuFv2iCHGHRFLFyROx2y431xiw@mail.gmail.com>
 <1dd4462ed7624384a1dfa1a58eb332ea@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8WRSJ6Z5PyFu0ip_mnxVGWsweKvk3k84UUD7BQe1AbZXQ@mail.gmail.com>
 <abc996d8ec1f4bc9a242c8067a05d20b@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8U9hbO-LesE0A22csnV3q3WOqeuDsR9Sy9hSZXMv-FBcQ@mail.gmail.com>
 <cd0c024adae542deb4a5bc1d1189ac37@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8Vd18nwcd+2Q90ecSHNDCRxMPEan1toXc4Y8i-0OLgV1g@mail.gmail.com>
 <37578516c14b451d882c71eb795360f3@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAHP4M8VCAahUVwiHr1a7jtFRZcH_nwdReiHYYFOSp+p00G_Qxg@mail.gmail.com>
 <D61A2A25686C654F89CE8D10509E05E101B81077@SJDCEXMBX03.us.trendnet.org>
Message-ID: <CAHP4M8W3aQ_6dVMLvM__zkZTb8XCz_m3OPEf_6oAMwS8wCftyA@mail.gmail.com>

I guess we need to look at OpenWrt for MIPS-versions of the libraries.

We do have a device running on MIPS, and linking the OpenWrt-versions of
libcrypto.a and libssl.a (with our framework-binary) works like a charm.


Thanks and Regards,
Ajay

On Mon, Oct 17, 2016 at 7:30 PM, Craig_Weeks at trendmicro.com <
Craig_Weeks at trendmicro.com> wrote:

> I?m interested in the rest of this story.  Does compiling a separate
> library for linking work for you now?  Our product runs on two platforms:
> one Pentium-based and one Mips-based. The Pentium build works fine but the
> Mips build fails at link time with unresolved function references.
>
>
>
> *From:* openssl-users [mailto:openssl-users-bounces at openssl.org] *On
> Behalf Of *Ajay Garg
> *Sent:* Sunday, October 16, 2016 10:16 PM
> *To:* openssl-users at openssl.org
> *Subject:* Re: [openssl-users] Where to find definitions of certain
> functions
>
>
>
> Aahhhhh... I guess I was being an idiot.
>
> I just realize that the recommended/best/easier way is to compile openssl
> as a separate library (enabling/disabling/removing features as required),
> and then link this library to our application-binary.
>
> Thanks a ton Salz, you have saved me a LOT of hours :)
>
> Thanks and Regards,
>
> Ajay
>
>
>
> On Sun, Oct 16, 2016 at 10:09 PM, Salz, Rich <rsalz at akamai.com> wrote:
>
>
> > Also, I am not using Makefiles, rather compiling each "c unit" using gcc
> using first-principles.
> > Could that be an issue?
>
> Probably.
>
> Only "make" is supported.  You are on your own.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>
> --
>
> Regards,
> Ajay
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidential
> and may be subject to copyright or other intellectual property protection.
> If you are not the intended recipient, you are not authorized to use or
> disclose this information, and we request that you notify us by reply mail or
> telephone and delete the original message from your mail system.
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Regards,
Ajay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161017/68ebaa59/attachment.html>

From kim.grasman at gmail.com  Tue Oct 18 10:13:32 2016
From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=)
Date: Tue, 18 Oct 2016 12:13:32 +0200
Subject: [openssl-users] Architecture-specific headers
Message-ID: <CANt7B+d39jFy1CVLOCskMHekP9tVjc28iC5RN3XFmdpBX6ciHQ@mail.gmail.com>

Hi all,

I'm working on building OpenSSL 1.0.2 for both Windows x86 and AMD64,
i.e. the VC-WIN32 and VC-WIN64A platforms.

Everything seems to work pretty well, but one thing is worrying -- the
opensslconf.h header comes out different between the two builds.

I'm assuming this only affects implementation details in OpenSSL and
not the public API? I don't have to publish and maintain
architecture-specific headers, do I?

Attaching a diff from a recent build for reference.

Thanks,
- Kim
-------------- next part --------------
--- x86\inc32\openssl\opensslconf.h	2016-10-18 10:19:26.000000000 +0200
+++ x64\inc32\openssl\opensslconf.h	2016-10-18 10:34:34.000000000 +0200
@@ -2,14 +2,14 @@
 /* WARNING: Generated automatically from opensslconf.h.in by Configure. */
 
 #ifdef  __cplusplus
 extern "C" {
 #endif
 /* OpenSSL was configured with the following options: */
-#ifndef OPENSSL_SYSNAME_WIN32
-# define OPENSSL_SYSNAME_WIN32
+#ifndef OPENSSL_SYSNAME_WIN64A
+# define OPENSSL_SYSNAME_WIN64A
 #endif
 #ifndef OPENSSL_DOING_MAKEDEPEND
 
 
 #ifndef OPENSSL_NO_EC_NISTP_64_GCC_128
 # define OPENSSL_NO_EC_NISTP_64_GCC_128
@@ -155,41 +155,41 @@
 #endif
 #if !defined(RC4_CHUNK)
 /*
  * This enables code handling data aligned at natural CPU word
  * boundary. See crypto/rc4/rc4_enc.c for further details.
  */
-#undef RC4_CHUNK
+#define RC4_CHUNK unsigned long long
 #endif
 #endif
 
 #if (defined(HEADER_NEW_DES_H) || defined(HEADER_DES_H)) && !defined(DES_LONG)
 /* If this is set to 'unsigned int' on a DEC Alpha, this gives about a
  * %20 speed up (longs are 8 bytes, int's are 4). */
 #ifndef DES_LONG
-#define DES_LONG unsigned long
+#define DES_LONG unsigned int
 #endif
 #endif
 
 #if defined(HEADER_BN_H) && !defined(CONFIG_HEADER_BN_H)
 #define CONFIG_HEADER_BN_H
-#define BN_LLONG
+#undef BN_LLONG
 
 /* Should we define BN_DIV2W here? */
 
 /* Only one for the following should be defined */
 #undef SIXTY_FOUR_BIT_LONG
-#undef SIXTY_FOUR_BIT
-#define THIRTY_TWO_BIT
+#define SIXTY_FOUR_BIT
+#undef THIRTY_TWO_BIT
 #endif
 
 #if defined(HEADER_RC4_LOCL_H) && !defined(CONFIG_HEADER_RC4_LOCL_H)
 #define CONFIG_HEADER_RC4_LOCL_H
 /* if this is defined data[i] is used instead of *data, this is a %20
  * speedup on x86 */
-#define RC4_INDEX
+#undef RC4_INDEX
 #endif
 
 #if defined(HEADER_BF_LOCL_H) && !defined(CONFIG_HEADER_BF_LOCL_H)
 #define CONFIG_HEADER_BF_LOCL_H
 #undef BF_PTR
 #endif /* HEADER_BF_LOCL_H */

From Michael.Wojcik at microfocus.com  Tue Oct 18 12:21:29 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 18 Oct 2016 12:21:29 +0000
Subject: [openssl-users] Architecture-specific headers
In-Reply-To: <CANt7B+d39jFy1CVLOCskMHekP9tVjc28iC5RN3XFmdpBX6ciHQ@mail.gmail.com>
References: <CANt7B+d39jFy1CVLOCskMHekP9tVjc28iC5RN3XFmdpBX6ciHQ@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015E6AB9CC@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Kim Gr?sman
> Sent: Tuesday, October 18, 2016 04:14
> 
> Everything seems to work pretty well, but one thing is worrying -- the
> opensslconf.h header comes out different between the two builds.
> 
> I'm assuming this only affects implementation details in OpenSSL and
> not the public API? I don't have to publish and maintain
> architecture-specific headers, do I?

opensslconf.h is generated from the configuration settings and platform characteristics, and applications must be compiled using the opensslconf.h that corresponds to the build they link to (or one that's equivalent).

Sometimes you can get away with using the wrong opensslconf.h, but this can cause hard-to-find errors. One project I know of went for several years using the wrong opensslconf.h, and it was only discovered when a different project used some other OpenSSL features and got incorrect results on some platforms.

So, in short: You do in fact have to publish and maintain one architecture-specific header.

Michael Wojcik 
Distinguished Engineer, Micro Focus 




From kim.grasman at gmail.com  Tue Oct 18 13:04:00 2016
From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=)
Date: Tue, 18 Oct 2016 15:04:00 +0200
Subject: [openssl-users] Architecture-specific headers
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015E6AB9CC@prvxmb03.microfocus.com>
References: <CANt7B+d39jFy1CVLOCskMHekP9tVjc28iC5RN3XFmdpBX6ciHQ@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6AB9CC@prvxmb03.microfocus.com>
Message-ID: <CANt7B+dfRjvN8xOApZm93ea0bTEJiULNV3hpODchSnuASgBaPw@mail.gmail.com>

Hi Michael,

On Tue, Oct 18, 2016 at 2:21 PM, Michael Wojcik
<Michael.Wojcik at microfocus.com> wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Kim Gr?sman
>> Sent: Tuesday, October 18, 2016 04:14
>>
>> Everything seems to work pretty well, but one thing is worrying -- the
>> opensslconf.h header comes out different between the two builds.
>>
>> I'm assuming this only affects implementation details in OpenSSL and
>> not the public API? I don't have to publish and maintain
>> architecture-specific headers, do I?
>
> opensslconf.h is generated from the configuration settings and platform characteristics, and applications must be compiled using the opensslconf.h that corresponds to the build they link to (or one that's equivalent).
>
> Sometimes you can get away with using the wrong opensslconf.h, but this can cause hard-to-find errors. One project I know of went for several years using the wrong opensslconf.h, and it was only discovered when a different project used some other OpenSSL features and got incorrect results on some platforms.
>
> So, in short: You do in fact have to publish and maintain one architecture-specific header.

Thanks, I was afraid so. We're compiling for 6 different targets, so
this will turn into an exciting problem :-)

I'll try to think up a way forward with this.

Any chance that OpenSSL 1.1 is different in this regard?

Thank you,
- Kim

From rsalz at akamai.com  Tue Oct 18 13:11:28 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 18 Oct 2016 13:11:28 +0000
Subject: [openssl-users] Architecture-specific headers
In-Reply-To: <CANt7B+dfRjvN8xOApZm93ea0bTEJiULNV3hpODchSnuASgBaPw@mail.gmail.com>
References: <CANt7B+d39jFy1CVLOCskMHekP9tVjc28iC5RN3XFmdpBX6ciHQ@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6AB9CC@prvxmb03.microfocus.com>
 <CANt7B+dfRjvN8xOApZm93ea0bTEJiULNV3hpODchSnuASgBaPw@mail.gmail.com>
Message-ID: <5745c0f484eb4ffba27f8e300b260f54@usma1ex-dag1mb1.msg.corp.akamai.com>


> Any chance that OpenSSL 1.1 is different in this regard?

No.

Except that the install-top is simpler to configure.

From Michael.Wojcik at microfocus.com  Tue Oct 18 13:31:20 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 18 Oct 2016 13:31:20 +0000
Subject: [openssl-users] Architecture-specific headers
In-Reply-To: <CANt7B+dfRjvN8xOApZm93ea0bTEJiULNV3hpODchSnuASgBaPw@mail.gmail.com>
References: <CANt7B+d39jFy1CVLOCskMHekP9tVjc28iC5RN3XFmdpBX6ciHQ@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6AB9CC@prvxmb03.microfocus.com>
 <CANt7B+dfRjvN8xOApZm93ea0bTEJiULNV3hpODchSnuASgBaPw@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015E6ABCC9@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Kim Gr?sman
> Sent: Tuesday, October 18, 2016 07:04
> 
> On Tue, Oct 18, 2016 at 2:21 PM, Michael Wojcik
> <Michael.Wojcik at microfocus.com> wrote:
> >
> > So, in short: You do in fact have to publish and maintain one architecture-
> specific header.
> 
> Thanks, I was afraid so. We're compiling for 6 different targets, so
> this will turn into an exciting problem :-)

I don't know what your build system looks like, but it wasn't a terribly difficult problem for us. Don't you already have platform-specific headers? You have platform-specific libraries...

I deal with 11 platforms for OpenSSL currently - most of which have multiple flavors (bitness and threadedness; fortunately at the moment we're not doing both debug and release builds as well). Not that big a deal to build all of them and harvest opensslconf.h alongside the shared objects / DLLs.

> Any chance that OpenSSL 1.1 is different in this regard?

I don't see how it could be. Other OpenSSL headers need to know information about the configuration used to build OpenSSL, and the attributes of the platform such as endianness. Some of the settings in opensslconf.h are necessary for correctness; others greatly affect performance. There are also convenience settings like the default OPENSSLDIR. That information is required at compile time and has to come from somewhere.

Michael Wojcik 
Distinguished Engineer, Micro Focus 




From kim.grasman at gmail.com  Tue Oct 18 13:40:06 2016
From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=)
Date: Tue, 18 Oct 2016 15:40:06 +0200
Subject: [openssl-users] Architecture-specific headers
In-Reply-To: <5745c0f484eb4ffba27f8e300b260f54@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CANt7B+d39jFy1CVLOCskMHekP9tVjc28iC5RN3XFmdpBX6ciHQ@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6AB9CC@prvxmb03.microfocus.com>
 <CANt7B+dfRjvN8xOApZm93ea0bTEJiULNV3hpODchSnuASgBaPw@mail.gmail.com>
 <5745c0f484eb4ffba27f8e300b260f54@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CANt7B+cLMGdXeU_SbooK6D3iErqtrwuGOd6urgZqXKytD43gFQ@mail.gmail.com>

On Tue, Oct 18, 2016 at 3:11 PM, Salz, Rich <rsalz at akamai.com> wrote:
>
>> Any chance that OpenSSL 1.1 is different in this regard?
>
> No.
>
> Except that the install-top is simpler to configure.

Thanks, Rich. Yeah, I'm looking forward to the 1.1 build system!

- Kim

From kim.grasman at gmail.com  Tue Oct 18 13:54:14 2016
From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=)
Date: Tue, 18 Oct 2016 15:54:14 +0200
Subject: [openssl-users] Architecture-specific headers
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015E6ABCC9@prvxmb03.microfocus.com>
References: <CANt7B+d39jFy1CVLOCskMHekP9tVjc28iC5RN3XFmdpBX6ciHQ@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6AB9CC@prvxmb03.microfocus.com>
 <CANt7B+dfRjvN8xOApZm93ea0bTEJiULNV3hpODchSnuASgBaPw@mail.gmail.com>
 <B550B44BF8AF314BB00C4E2AC1C18088015E6ABCC9@prvxmb03.microfocus.com>
Message-ID: <CANt7B+cZHR_XvsKgnqmb-oJkDaRBxAgMCfZ7vWGeu2TJQWjCzQ@mail.gmail.com>

On Tue, Oct 18, 2016 at 3:31 PM, Michael Wojcik
<Michael.Wojcik at microfocus.com> wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of Kim Gr?sman
>> Sent: Tuesday, October 18, 2016 07:04
>>
>> On Tue, Oct 18, 2016 at 2:21 PM, Michael Wojcik
>> <Michael.Wojcik at microfocus.com> wrote:
>> >
>> > So, in short: You do in fact have to publish and maintain one architecture-
>> specific header.
>>
>> Thanks, I was afraid so. We're compiling for 6 different targets, so
>> this will turn into an exciting problem :-)
>
> I don't know what your build system looks like, but it wasn't a terribly difficult problem for us. Don't you already have platform-specific headers? You have platform-specific libraries...

No platform-specific headers in third-parties, no.

> I deal with 11 platforms for OpenSSL currently - most of which have multiple flavors (bitness and threadedness; fortunately at the moment we're not doing
> both debug and release builds as well). Not that big a deal to build all of them and harvest opensslconf.h alongside the shared objects / DLLs.

That makes sense to me -- we already build the library paths based on
all the relevant properties, so if I publish opensslconf.h together
with the libraries, I should be able to add the same suffix to the
include path.

Thanks for talking me through it!

- Kim

From Craig_Weeks at trendmicro.com  Tue Oct 18 20:05:07 2016
From: Craig_Weeks at trendmicro.com (Craig_Weeks at trendmicro.com)
Date: Tue, 18 Oct 2016 20:05:07 +0000
Subject: [openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul
In-Reply-To: <f7f088e15f3742db833ac20dc2d8c537@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <D61A2A25686C654F89CE8D10509E05E101B80D6B@SJDCEXMBX03.us.trendnet.org>
 <2f7b606493764b6196d05258103178f3@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D61A2A25686C654F89CE8D10509E05E101B80D93@SJDCEXMBX03.us.trendnet.org>
 <f7f088e15f3742db833ac20dc2d8c537@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <D61A2A25686C654F89CE8D10509E05E101B81A38@SJDCEXMBX03.us.trendnet.org>

Ok, I see *how* this is happening, but I don't understand why.  In the version of stdlib.h that I am including I see:

*-*-*-*-*-*-*-*-*-*
#if defined(__cplusplus) && !defined(_NO_CPP_INLINES)
[snip]
#else /* defined(__cplusplus) && !defined(_NO_CPP_INLINES) */
_C_LIB_DECL
		/* DECLARATIONS AND MACRO OVERRIDES, FOR C */
typedef int _Cmpfun(const void *, const void *);

int atexit(void (*)(void));
void * bsearch(const void *, const void *, size_t, size_t, _Cmpfun *);
void qsort(void *, size_t, size_t, _Cmpfun *);

double atof(const char *);
int atoi(const char *);
long atol(const char *);
double strtod(const char *_Restrict, char **_Restrict);
unsigned long strtoul(const char *_Restrict, char **_Restrict, int);

#define atof(str)	_Stod(str, 0, 0)
#define atoi(str)	(int)_Stoul(str, 0, 10)
#define atol(str)	(long)_Stoul(str, 0, 10)
#define strtod(str, endptr)	_Stod(str, endptr, 0)
#define strtoul(str, endptr, base)	_Stoul(str, endptr, base)
[snip]
#endif
*-*-*-*-*-*-*-*-*-*

So, for C code this header maps strtoul() (see parse_tagging() in crypto/asn1/asn1_gen.c for an example) to _Stroul().  That is definitely "helping" me more than I want but I don't know how to make it stop.

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich
Sent: Friday, October 14, 2016 4:21 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul

Stoul is usually a C++ function.  Are you sure you're using the right compiler?  Add -lm to your link libraries?

That's all I've got.

--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz


-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>


From Michael.Wojcik at microfocus.com  Tue Oct 18 22:05:39 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 18 Oct 2016 22:05:39 +0000
Subject: [openssl-users] OpenSSL 1.0.2.f undefined reference: _Stoul
In-Reply-To: <D61A2A25686C654F89CE8D10509E05E101B81A38@SJDCEXMBX03.us.trendnet.org>
References: <D61A2A25686C654F89CE8D10509E05E101B80D6B@SJDCEXMBX03.us.trendnet.org>
 <2f7b606493764b6196d05258103178f3@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D61A2A25686C654F89CE8D10509E05E101B80D93@SJDCEXMBX03.us.trendnet.org>
 <f7f088e15f3742db833ac20dc2d8c537@usma1ex-dag1mb1.msg.corp.akamai.com>
 <D61A2A25686C654F89CE8D10509E05E101B81A38@SJDCEXMBX03.us.trendnet.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015E6ABEEE@prvxmb03.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Craig_Weeks at trendmicro.com
> Sent: Tuesday, October 18, 2016 14:05
> 
> Ok, I see *how* this is happening, but I don't understand why.  In the
> version of stdlib.h that I am including I see:
> [omitted] 
> 
> So, for C code this header maps strtoul() (see parse_tagging() in
> crypto/asn1/asn1_gen.c for an example) to _Stroul().  That is definitely
> "helping" me more than I want but I don't know how to make it stop.

This looks like a conflict between your standard C headers and standard C library - that is, it appears the former came from one source, and the latter from another (or a sufficiently-different version).

strtoul is defined by the C standard. It's part of the standard library. However, an implementation can provide it as a macro (with some caveats I won't get into). stdlib.h is also defined by the C standard.

In this case, you have a stdlib.h which defines strtoul as a function-like macro that becomes an invocation of the function _Stoul. That function is not defined by the C standard, but it's in a part of the namespace that's reserved to implementors, so we can guess that it's part of the implementation this stdlib.h comes from.

However: You're building on a system that splits the C standard library up into header and library components. (Most do, but it's possible to conform to the standard using other arrangements.) And whatever your build system is finding to be the linkage component of the C standard library does not implement this _Stoul.

So OpenSSL is building with C library headers that don't match the C library linkage library. (On Windows, the latter would be either a static library or an import library - a .LIB file of some sort. On Linux and UNIX platforms, it would be a shared object or library of some sort - most often an ELF shared object, though AIX, for example, uses an archive library containing XCOFF shared objects.) The most likely cause is conflicting software installed on your system, but it may be that the OpenSSL Configure process is locating the wrong files due to some environmental quirk in your setup.

Historical note: The name "_Stoul" suggests your stdlib.h is descended from the one written by P. J. Plauger, one of the major players in C and C++ standardization:

http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/CUJ/1992/9205/plauger/plauger.htm

Plauger's implementation is widely used by commercial C implementations. GCC, however, has its own C library implementation, which does not have a "_Stoul". So perhaps you're compiling with vendor-supplied headers and linking against glibc?

Here's a quick test. See if this compiles and runs successfully, using the machine and toolchain you're using for OpenSSL:

	#include <stdlib.h>
	int main(void) {return strtoul("0", NULL, 10);}

If that complains about a missing _Stoul, you have the same problem as the OpenSSL build is seeing in your environment. If it works, then your environment is OK, and OpenSSL Configure picked up something weird. EIther way it may help you isolate the issue.

Michael Wojcik 
Distinguished Engineer, Micro Focus 




From mirko.dziadzka at gmail.com  Wed Oct 19 14:57:33 2016
From: mirko.dziadzka at gmail.com (Mirko Dziadzka)
Date: Wed, 19 Oct 2016 16:57:33 +0200
Subject: [openssl-users] openssl-1.0.2j does not compile with 'no-des' option
Message-ID: <7C2E3212-6731-4160-AD09-F2AF766F0A2E@gmail.com>

Hi

Using CentOS 6 (64bit) and MacOS 10.12, I?m trying to compile openssl-1.0.2j with the no-des option

$ tar xzf openssl-1.0.2j.tar.gz
$ cd openssl-1.0.2j
$ ./config shared no-des no-comp no-engine 
# on MacOS
# ./Configure darwin64-x86_64-cc shared no-des no-comp no-engine 
?
$ make depend
$ make

I always get

make[2]: Entering directory ??./openssl-1.0.2j/apps'
../libcrypto.so: undefined reference to `EVP_des_ede3_wrap?

It work?s fine when I remove the ?no-dsa? option or when I switch back to openssl-1.0.1

Is this a Bug or do I need some other magic option?

    Mirko

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

From koldaevav at gmail.com  Wed Oct 19 17:57:45 2016
From: koldaevav at gmail.com (Anton Koldaev)
Date: Wed, 19 Oct 2016 10:57:45 -0700
Subject: [openssl-users] SSL_write:: shutdown while in init
Message-ID: <CAJXnuBCcgW0frU_BPDAqRG5M4cdC37rK44_xfpGtjK1NB3oRiA@mail.gmail.com>

We're using aws-ruby-sdk <https://github.com/aws/aws-sdk-ruby> (~> 1.8 for
older ruby support) to upload files to AWS S3. It worked fine until we
upgraded from openssl 1.0.1-4ubuntu5.31 to 1.0.2g-1ubuntu4.5.

I know that there was a recent change
<https://github.com/openssl/openssl/commit/64193c8218540499984cd63cda41f3cd491f3f59>
which was supposed only
<https://github.com/openssl/openssl/issues/710#issuecomment-253897666> to
provide a proper error handling but we didn't actually have failed uploads
at all on older openssl version. And we're using the same aws-sdk as before.

Here's how the exception looks:
https://gist.github.com/iroller/ed362dd8627020e9ad79b6ec15548014

Any suggestions on whether it's something fixed in newer versions of
openssl or should I look into downgrading to an earlier version of openssl?


-- 
Best regards,
Koldaev Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161019/a30f8c60/attachment.html>

From rossimattia92 at gmail.com  Mon Oct 24 17:15:03 2016
From: rossimattia92 at gmail.com (Mattia Rossi)
Date: Mon, 24 Oct 2016 19:15:03 +0200
Subject: [openssl-users] TLS handshake fail in libssl1.0.2j
Message-ID: <CADKc5xAn=n0wb017feZJiG=Vd6fRrwcww6gKwhHZNdAYecg-cg@mail.gmail.com>

Hi all,

it's the first time i ask question here, i have a small PHP script
that send mail with SMTP to 'sendm.cert.legalmail.it' on port 465 with
TLS, on ubuntu server 16.04 i have the last update of libssl1.0.2j but
i can't open a socket to that host the handshake fail with this error:

> Warning: fsockopen(): SSL operation failed with code 1. OpenSSL Error messages:
> error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure in /tmp/connect.php on line 12
> PHP Warning:  fsockopen(): Failed to enable crypto in /tmp/connect.php on line 12

> Warning: fsockopen(): Failed to enable crypto in /tmp/connect.php on line 12
> PHP Warning:  fsockopen(): unable to connect to ssl://sendm.cert.legalmail.it:465 (Unknown error) in /tmp/connect.php on line 12


downgrade to 1.0.2h fix all problems, other host seems to be no
affected to the same issue.

It's a bug of openssl? (i don't think so) or it's a bug of the mail provider?

Thanks for the support, ask me more i some info are missing!

From elizatom at yahoo.com  Tue Oct 25 05:36:21 2016
From: elizatom at yahoo.com (shanthi thomas)
Date: Tue, 25 Oct 2016 05:36:21 +0000 (UTC)
Subject: [openssl-users] openssl dgst -sha256 - result differs from
 Bouncycastle SHA256 digest for same input
References: <1968580821.217357.1477373781353.ref@mail.yahoo.com>
Message-ID: <1968580821.217357.1477373781353@mail.yahoo.com>

Hi,? ? I read that this happens because openssl is treating the input as characters as opposed to binary data. But how do I rectify it so that openssl gives the same digest output as BouncyCastle??
thanks,Elizabeth
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161025/b9fb14ac/attachment.html>

From joshi.sanjaya at gmail.com  Tue Oct 25 08:01:14 2016
From: joshi.sanjaya at gmail.com (Sanjaya Joshi)
Date: Tue, 25 Oct 2016 13:31:14 +0530
Subject: [openssl-users] Clarification regarding CVE-2016-2178 for openssl
	1.0.2 i and 1.0.2 j
Message-ID: <CANK1Yiqz6ahocuCeAk-NwfOkpU80ZE82pw5LnbL-BZfES5RHBQ@mail.gmail.com>

Hello,

1)
In openssl1.0.2i, the release note says, there is a fix for CVE-2016-2178:

"
  *) Constant time flag not preserved in DSA signing

     Operations in the DSA signing algorithm should run in constant time in
     order to avoid side channel attacks. A flaw in the OpenSSL DSA
     implementation means that a non-constant time codepath is followed for
     certain operations. This has been demonstrated through a cache-timing
     attack to be sufficient for an attacker to recover the private DSA key.

     This issue was reported by C?sar Pereida (Aalto University), Billy
Brumley
     (Tampere University of Technology), and Yuval Yarom (The University of
     Adelaide and NICTA).
     (CVE-2016-2178)
     [C?sar Pereida]
"

2)
And the related code diff in git is:
https://git.openssl.org/?p=openssl.git;a=commitdiff;h=399944622df7bd81af62e67ea967c470534090e2

3)
But when i download the source code (1.0.2i and 1.0.2j), i cannot see those
fixes.

Could you please clarify a bit about this. Is this intended or i just need
to apply the patches myself ?

Regards,
Sanjaya
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161025/bd674e76/attachment.html>

From kristianonline28 at gmail.com  Tue Oct 25 08:45:23 2016
From: kristianonline28 at gmail.com (Kristian)
Date: Tue, 25 Oct 2016 10:45:23 +0200
Subject: [openssl-users] openssl dgst -sha256 - result differs from
 Bouncycastle SHA256 digest for same input
In-Reply-To: <1968580821.217357.1477373781353@mail.yahoo.com>
References: <1968580821.217357.1477373781353.ref@mail.yahoo.com>
 <1968580821.217357.1477373781353@mail.yahoo.com>
Message-ID: <CAO5HUhObPq1o+D-xq2XR89dHnnP0E-TVtd4KzwVrP=d8hMrCwA@mail.gmail.com>

Maybe different encodings like here:
http://stackoverflow.com/questions/6839969/md5-hash-with-different-results

2016-10-25 7:36 GMT+02:00 shanthi thomas <elizatom at yahoo.com>:

> Hi,
>     I read that this happens because openssl is treating the input as
> characters as opposed to binary data. But how do I rectify it so that
> openssl gives the same digest output as BouncyCastle?
>
> thanks,
> Elizabeth
>
> --
> 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/20161025/fa576769/attachment.html>

From matt at openssl.org  Tue Oct 25 08:55:43 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 25 Oct 2016 09:55:43 +0100
Subject: [openssl-users] Clarification regarding CVE-2016-2178 for
 openssl 1.0.2 i and 1.0.2 j
In-Reply-To: <CANK1Yiqz6ahocuCeAk-NwfOkpU80ZE82pw5LnbL-BZfES5RHBQ@mail.gmail.com>
References: <CANK1Yiqz6ahocuCeAk-NwfOkpU80ZE82pw5LnbL-BZfES5RHBQ@mail.gmail.com>
Message-ID: <92d5ec21-f792-6976-b5d9-94d2796779f1@openssl.org>



On 25/10/16 09:01, Sanjaya Joshi wrote:
> Hello,
> 
> 1)
> In openssl1.0.2i, the release note says, there is a fix for CVE-2016-2178:
> 
> "
>   *) Constant time flag not preserved in DSA signing
> 
>      Operations in the DSA signing algorithm should run in constant time in
>      order to avoid side channel attacks. A flaw in the OpenSSL DSA
>      implementation means that a non-constant time codepath is followed for
>      certain operations. This has been demonstrated through a cache-timing
>      attack to be sufficient for an attacker to recover the private DSA key.
> 
>      This issue was reported by C?sar Pereida (Aalto University), Billy
> Brumley
>      (Tampere University of Technology), and Yuval Yarom (The University of
>      Adelaide and NICTA).
>      (CVE-2016-2178)
>      [C?sar Pereida]
> "
> 
> 2)
> And the related code diff in git
> is: https://git.openssl.org/?p=openssl.git;a=commitdiff;h=399944622df7bd81af62e67ea967c470534090e2
> 
> 3)
> But when i download the source code (1.0.2i and 1.0.2j), i cannot see
> those fixes.
> 
> Could you please clarify a bit about this. Is this intended or i just
> need to apply the patches myself ?

Well, firstly the link you give above is the master version of the fix,
not the 1.0.2 version. Secondly, in 1.0.2, there were two relevant commits:

https://github.com/openssl/openssl/commit/621eaf49a289bfac26d4cbcdb7396e796784c534

and

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

Matt


From jeantinguelyawais at gmail.com  Tue Oct 25 21:46:22 2016
From: jeantinguelyawais at gmail.com (Jean Tinguely Awais)
Date: Tue, 25 Oct 2016 23:46:22 +0200
Subject: [openssl-users] Use of openssl
Message-ID: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>

Hello,
 I've a free certificate from startssl for my email address. Now I would
like to create a certificate for one of my internet domain. How can I do
that? Can I use openssl? Is there a free service like cacert.org that allow
to deploy free class IV certificates that are recognized?
Sorry for my poor question. Thank you for your reply.
Best regards.
Jean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161025/cd913181/attachment.html>

From noloader at gmail.com  Tue Oct 25 22:04:39 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 25 Oct 2016 18:04:39 -0400
Subject: [openssl-users] Use of openssl
In-Reply-To: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
References: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
Message-ID: <CAH8yC8mm7JNCOvXNh96XvAi8aViEDgCd8TgE-Y6YACu=Fu=AGw@mail.gmail.com>

>  I've a free certificate from startssl for my email address. Now I would
> like to create a certificate for one of my internet domain. How can I do
> that? Can I use openssl? Is there a free service like cacert.org that allow
> to deploy free class IV certificates that are recognized?
> Sorry for my poor question. Thank you for your reply.

The three free services I am aware of are (1) CaCert, (2) StartCom,
and (3) Let's Encrypt.

CaCert is kind of dead because their roots are still using MD5. Nobody
trusts them, especially after Flame and Stuxnet.

StartCom has directions on their website. I don't recall what the
process is, but I've used it in the past. You might want to review the
instructions StartCom provides.

Let's Encrypt is new and has become very popular. I don't know the
process because I have never used them. They will likely suffer more
"unable to get local issuer certificate" problems than StartCom,
especially on older mobile devices.

You can ask users to install the Let's Encrypt Root CA to overcome the
"unable to get local issuer certificate" problem. Asking users to do
anything is usually a slippery slope, and it will probably create user
grief and generate support emails.

Jeff

From rsalz at akamai.com  Tue Oct 25 22:53:26 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 25 Oct 2016 22:53:26 +0000
Subject: [openssl-users] Use of openssl
In-Reply-To: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
References: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
Message-ID: <a881e49163664ffa9d2d7fce79d6a6ad@usma1ex-dag1mb1.msg.corp.akamai.com>

Check out www.letsencrypt.org<http://www.letsencrypt.org>

--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161025/a3a56dfa/attachment.html>

From rsalz at akamai.com  Tue Oct 25 22:54:52 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 25 Oct 2016 22:54:52 +0000
Subject: [openssl-users] Use of openssl
In-Reply-To: <CAH8yC8mm7JNCOvXNh96XvAi8aViEDgCd8TgE-Y6YACu=Fu=AGw@mail.gmail.com>
References: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
 <CAH8yC8mm7JNCOvXNh96XvAi8aViEDgCd8TgE-Y6YACu=Fu=AGw@mail.gmail.com>
Message-ID: <8b83de9b584d4654946b8a960ecd121a@usma1ex-dag1mb1.msg.corp.akamai.com>


> StartCom has directions on their website. I don't recall what the process is,
> but I've used it in the past. You might want to review the instructions
> StartCom provides.

StartCom, owned by WoSign, has issues with firefox.
 
> Let's Encrypt is new and has become very popular. I don't know the process
> because I have never used them. They will likely suffer more "unable to get
> local issuer certificate" problems than StartCom, especially on older mobile
> devices.

Should not be an issue, since LE has a cross-signed CA cert with someone that is in the trust stores.

From marcus.james at gmail.com  Wed Oct 26 01:43:10 2016
From: marcus.james at gmail.com (James Marcus)
Date: Tue, 25 Oct 2016 21:43:10 -0400
Subject: [openssl-users] rpmbuild openssl-1.0.1u
Message-ID: <CAM54t=ZzFTH478b7d21VjCNcFX+LVVbvNZ=niOBAc6dm4zGVHA@mail.gmail.com>

Hi,
I'm trying to build a rpm for openssl-1.0.1u on CentOS 7 x86_64.  To get
the rpmbuild to run, I had to remove several comments in changelog, because
they weren't formatted correctly. The second problem I ran into is one
during the rpm staging:

The tail end of the output from rpmbuild -ba openssl.spec is:

+ cp -pr README
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/share/doc/openssl-1.0.1u
+ exit 0


RPM build errors:
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/bin/ssleay
    File not found by glob:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/lib/*.so*
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/dss1.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/md2.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/md4.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/md5.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/mdc2.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/ripemd160.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/sha.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/sha1.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/sha224.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/sha256.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/sha384.1ssl.gz
    Explicit %attr() mode not applicaple to symlink:
/root/rpmbuild/BUILDROOT/openssl-1.0.1u-1.x86_64/usr/man/man1/sha512.1ssl.gz

I'm assuming its related to this line in the openssl.spec file?

# Make backwards-compatibility symlink to ssleay

ln -sf /usr/bin/openssl $RPM_BUILD_ROOT/usr/bin/ssleay


Has anyone else ran into this problem?


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

From jb-openssl at wisemo.com  Wed Oct 26 02:15:22 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 26 Oct 2016 04:15:22 +0200
Subject: [openssl-users] Use of openssl
In-Reply-To: <8b83de9b584d4654946b8a960ecd121a@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
 <CAH8yC8mm7JNCOvXNh96XvAi8aViEDgCd8TgE-Y6YACu=Fu=AGw@mail.gmail.com>
 <8b83de9b584d4654946b8a960ecd121a@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <7ceae6ba-b5ea-ccbf-f7f9-f1c13239cf54@wisemo.com>

On 26/10/2016 00:54, Salz, Rich wrote:
>> StartCom has directions on their website. I don't recall what the process is,
>> but I've used it in the past. You might want to review the instructions
>> StartCom provides.
> StartCom, owned by WoSign, has issues with firefox.
>   
More precisely:

Due to certificate mismanagement and lying by the (soon to be
replaced) CEO of WoSign and StartCom, both Mozilla (Firefox,
Thunderbird etc.) and Apple have decided to distrust WoSign
and StartCom, with some temporary exceptions for old
certificates.  There many threads on
news://news.mozilla.org/mozilla.dev.security.policyabout this,
going at least back to a post on 2016-06-30 .

They are basically dead for now.

>> Let's Encrypt is new and has become very popular. I don't know the process
>> because I have never used them. They will likely suffer more "unable to get
>> local issuer certificate" problems than StartCom, especially on older mobile
>> devices.
> Should not be an issue, since LE has a cross-signed CA cert with someone that is in the trust stores.
More problematic is the need to run automated tools to get fresh LE
certificates every 2 to 3 months.  This is easy for some situations,
not easy for others.

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 devang.kubavat at in.abb.com  Wed Oct 26 06:23:08 2016
From: devang.kubavat at in.abb.com (Devang Kubavat)
Date: Wed, 26 Oct 2016 06:23:08 +0000
Subject: [openssl-users] Different size of openssl libraries
Message-ID: <DB5PR06MB17679A08A44E2D80DABF3D5AB2AB0@DB5PR06MB1767.eurprd06.prod.outlook.com>

Hi,

I am trying to build openssl 1.0.2j. for windows. Everytime I different size of libraries.
Is it depends on path ?

Best Regards
Devang

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

From jvp at forthepolls.org  Wed Oct 26 15:50:32 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Wed, 26 Oct 2016 08:50:32 -0700
Subject: [openssl-users] free certs: bad idea
 wosign/startcom/startssl/startencrypt; good alt's
In-Reply-To: <8b83de9b584d4654946b8a960ecd121a@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
 <CAH8yC8mm7JNCOvXNh96XvAi8aViEDgCd8TgE-Y6YACu=Fu=AGw@mail.gmail.com>
 <8b83de9b584d4654946b8a960ecd121a@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <5810D0C8.8010100@forthepolls.org>

this is a re-worked report i prepared that some might find useful.*

CAUTION:* there are several seriously troubling events surrounding WoSign *^1 * 
(AKA startcom, AKA startssl, and AKA startencrypt) and any of their 
affiliated/subsidiary businesses:

 1. wosign purchased startcom/startssl/startencrypt [DBA's of 'Start Commercial
    LTD' (an Israeli company); hereinafter '*startcom*'] last year. although
    obfuscation by the parties makes determining the actual control-transfer
    date impossible, the change-over may have begun in 2014. both companies long
    completely and publicly denied any change of control even as late as
    2016.JUL despite it being a matter of public record that:
     1.   the entire stock issuance from 15 startcom shareholders including
        founder Revital (AKA 'Eddy') Nigg's majority ownership was transferred
        in 2015.NOV;
     2.   beneficiary of the stock deal was 'StartCom CA Limited' a UK company
        (09744347);
     3.   the UK company is wholly-owned by 'StartCom CA Limited' (yes, exactly
        the same name again) a Hong Kong company (CRN 2271553) with a sole
        director being Wang *^1 *; and
     4.   the Hong Kong entity is then owned by wosign.
 2. in fact, to-date neither firm has actually admitted what has happened re
    transfer of control, domiciling of operations, and changes in management
    personnel. this reticence is despite some aspects of the transactions
    becoming common knowledge in the security community;
 3. wosign attempted (rather poorly it turned out) to make it appear that wosign
    was actually a subsidiary of startcom and startcom's remnant personnel and
    former shareholders abetted this *^2 *;
 4. startcom is an Israeli company and -- as one would expect -- was subjected
    to strict auditing and monitoring by the Israeli government to the benefit
    of all the recipients of their certs ... until the ownership change that is;
 5. wosign is a mainland Chinese (PRC) company which completely controls
    startcom operations in IL, UK, CN, and US;
 6. earlier this year and last wosign -- amongst other deceptive actions -- 
    tried to circumvent certain mandated changes to certificate authority (CA)
    practice by back-/forward-dating certs and issuing certs with duplicate
    serial numbers while their CA compliance auditors Ernst and Young (Hong
    Kong) were complicit in covering up these and other forbidden practices *^3 *;
 7. in response to all these discoveries, mozilla's firefox version 51 and all
    look-alikes using their gecko engine have stopped accepting any new (issued
    on/after 2016.OCT.21) certs that trace back to
    wosign/startcom/startssl/startencrypt root/intermediate/cross-signed certs
    and have banned Hong Kong Ernst and Young CPA's from certifying any CA audits;
 8. unless wosign and its subsidiaries come up with new root certificates and
    provide acceptable audit results for their CP/CPS/operations by 2017.MAR,
    all of wosign-affiliated root/intermediate/cross-signed certs will be
    removed from mozilla's certificate store; and
 9. mozilla has stated that if it detects any further fraud such as exhibited in
    Item 6, /supra/, all security updates to all its software versions will
    immediately remove wosign-based "trusted" certs from the mozilla root
    certificate store on the device being updated which will cause the universe
    of wosign-issued certs to become un-trusted in the mozilla browser family no
    matter when they were issued.

*OBVIOUS CONCLUSION: *do not just walk away from wosign, startcom, qihoo, et 
alii but *RUN! *i can think of nothing worse than trusting a PRC firm with my 
sites' security. OK, if that hyperbole is not enough, try my personal idea of 
what should be network no-go and it pretty much lies in the swath West of Japan 
and East of Germany.

*THE ALTERNATIVE: *the immediate free cert replacement avenue is through 
letsencrypt.org that uses the cert issuance/renewal protocol ACME. although 
letsencrypt will not be found in most (if any) browser "trusted" root 
certificate stores, they use cross-signed intermediate CA certs from a root that 
is. there are an ever-growing number of open-source scripts (bash, perl, python, 
go, ...) available to automate the process which one can even customize for your 
particular needs.

there are letsencrypt plug-ins/modules for apache to make your set-up less 
painful. you can use the nginx process with a lua module to /really /fully 
automate _/everything!/_ if you want to go /de luxe/ there is the openresty 
bundle that combines nginx with lua and adds a host of other nginx "add-in" 
enhancements automatically and some more rarely required that one specifies.

if you have looked at openresty or other bundles before and been turned off 
because there was nothing for your favorite distro/pkg-mgr and the thoughts of 
maintaining a 2kb configure line immediately switched your focus over to happy 
hour, look again! with openresty repo's are in, security patches are quick in 
coming, development is on-going 24/7, the "community" is lively, and the 
original/lead developer still has his hand firmly on the tiller.

one very important plus with the nginx set-up is that tls cert operation under 
lua will actually boot-strap the ACME cert process for each domain and all of 
the permitted sub-domains you authorize in the nginx config file. so, what did i 
just mean?

let us say that you have a new domain 'qwe.com' and want to use the sub-domains 
www, billing, mail, sales, and support. obviously, you have to get the DNS going 
as a separate project (3 minutes). you have to create an on-disk directory tree 
that accommodates the storage of the issued certs and a directory where the lua 
process will operate with the letsencrypt server token process that verifies 
domain control coming through DNS (2 minutes). then, you have a small config 
block in the nginx 'http' section authorizing the sub-directories (2 minutes), 
you drop in a 'server' section for whatever should be done (2 minutes: assuming 
you have an already-established server processing block), and you add to the 
server block a 'location' section for the token process (1 minute). now, you 
re-start nginx *AND YOU ARE DONE (10 minutes total)! *now that you have a 
template, adding on an additional domain should probably run half or less of 
that time.

when the first request comes in for, say, 'www.qwe.com'; nginx calls the lua 
module that completes the whole cert process for getting the cert for that FQDN 
and then services the request ... all without connection interruption. then 
'qwe.com' comes in and it adds that too. then 'support.qwe.com' and so forth 
until all your configured sub-domains are covered. you probably see it now: 
using this simple set-up you can segregate sub-domain access between HTTP and 
HTTPS with that tiny lua sub-domain authorization block. also, by authorizing 
(temporarily or otherwise) nginx to answer for sub-domains for other servers 
such as SMTP[S], IMAP[S], and so forth you will create your own customized 
server certs for apps running any other service you might like on whatever 
sub-domain you please by just making a single request for each server's sub-domain.

cert renewal is also automatic. with no special config, nginx will renew the 
cert when it falls within a remaining window of 30 days.


Thank you,

Johann

_*NOTES:*_

 1. '*WoSign CA Limited*' (hereinafter '*wosign*') has been around in a very
    minor way for, perhaps, as long as a decade. its only known owner is Wang
    Gao Hua (AKA: Richard Wang). it is a demonstrable fact that the PRC
    government is intensely interested in expanding its scope of operation in
    the international security venue and that its multi-faceted security
    apparatus has both overtly and covertly been found to acquire vested
    interests in technology ventures amenable to such an expansion. therefore,
    it is quite imaginable that the PRC government financially facilitated
    Wang's acquisition of startcom for its own purposes. it is all the more
    conceivable given that Wang was not known to be a very wealthy individual or
    well connected with sources of institutional financing.
 2. when i discovered the startling startcom Chinese connection in 2016.JAN and
    asked startcom what was going on, after a long hiatus and several info
    requests i received what was apparently a "canned" response (in re: 'Qihoo"
    since i never made reference to "hosting service" or other network
    security/service offerings such as might come from Qihoo's stable of
    products). moreover, the somewhat fractured English was not up to the
    standard always displayed by startcom in previous correspondence:
    via: 	183.37.145.226 (no rDNS) registered as follows:
    netname: 	CHINANET-GD
    descr: 	CHINANET Guangdong province network
    descr: 	Data Communication Division
    descr: 	China Telecom
    country: 	CN

    /L//ike every big company (IBM, Cisco, Oracle, Microsoft etc.) that has set
    up branch offices and R&D centers in China, StartCom is the No. 6 biggest CA
    in the world and today has also setup branch office and R&D center in
    China///^*1* /, our Chinese R&D team chose Qihoo 360 ^*4*   to provide
    secure hosting service since this company is the No.1 Antivirus and web
    security provider in China and in the world that public listed in
    NYSE///^*5* /.///
    /
    /
    //
    /We are always trying to improve and try support continued growth which
    isn't always easy to sustain. With that we hope to provide you and all our
    customers a useful service.//
    /
    //

    /-- Best regards, Ms. Yael Luft,CVO StartCom Ltd./

    //
 3. Certificate Authority (CA) auditors must certify to several different
    standards (some of which are country-specific) and the most prominent of
    such are:
      * European Telecommunications Standards Institute (*ETSI; *most
        specifically 'TS 102 042'; originally EU-centric and now recognized in
        c. a third of all nations and all of the OECD);
      * Internet Engineering Task Force (*IETF*; most specific policy-wise
        (CP/CPS) 'RFC 3647'; founded by the US and now an independent voluntary
        standards setter);
      * Webtrust Organization (*WEBTRUST*; principally 'WebTrust Principles and
        Criteria for Certification Authorities ? SSL Baseline with Network
        Security ? Version 2.0'; a network security consortium of commercial
        firms, CPA's, engineers, other standards setters ...);
      * American Institute of Certified Public Accountants (*AICPA*; various
        practice and audit guidelines for businesses, non-profits, and
        governments promulgated through standards boards and US Federal and
        State regulations; an US accountancy professional standards-setting,
        certifier of individuals to practice, and continuing education
        organization);
      * National Institute of Science and Technology (*NIST*; issues various
        publications establishing acceptable modes of operation of public and
        private entities; the lead US agency for standards issuance in
        concordance and co-operation with many other Departments and agencies of
        the US government);

 4. Qihoo 360 is -- like all PRC ISP's, hosting providers, hard-/soft-ware
    vendors, ASN operators, et cetera -- permitted to exist while being
    continuously monitored by the PRC National Defense Council which is a
    second-tier security agency just below the PRC military high command. Not
    only are these permitted firms monitored, but their numbers are severely
    restricted to make that monitoring more easily accomplished. moreover, any
    products of such PRC businesses have to be suspect given their government's
    penchant for intrusive and paramount control of any internal business
    process. of course, the PRC's raids on foreign business and government
    systems should make anyone shrink from any security association with any
    company on mainland china and that includes Hong Kong. Qihoo is addressed
    herein solely because it seems as if there is a Wang business relationship
    and concomitant risk exposure.
 5. pursuant to a privatization agreement back in 2015,  Qihoo 360 Technology
    Co. Ltd. ("Qihoo 360",  a Cayman Islands company) went out of existence and
    its NYSE QIHU ADR's (AKA: ADS's) were permanently suspended from trading on
    2016.JUL.15. although the 2015 announcement mentioned some minority
    financing of the transaction by PRC-controlled subsidiaries of international
    (foreign) banks, the actual finalized financing and even the actual
    ownership of the privatized entity are still totally unknown. since Qihoo
    was originally allowed to thrive within PRC through the PRC military giving
    them a virtual monopoly on many networking services (which they mostly still
    enjoy), it is not a stretch to assume that the military now possesses a
    directly vested interest together with the enhanced control such an interest
    cloaked in secrecy would represent.

On 2016.Oct.25 15:54, Salz, Rich wrote:
>> StartCom has directions on their website. I don't recall what the process is,
>> but I've used it in the past. You might want to review the instructions
>> StartCom provides.
> StartCom, owned by WoSign, has issues with firefox.
>   
>> Let's Encrypt is new and has become very popular. I don't know the process
>> because I have never used them. They will likely suffer more "unable to get
>> local issuer certificate" problems than StartCom, especially on older mobile
>> devices.
> Should not be an issue, since LE has a cross-signed CA cert with someone that is in the trust stores.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161026/3baf8a51/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3825 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161026/3baf8a51/attachment-0001.bin>

From rsalz at akamai.com  Wed Oct 26 15:59:52 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 26 Oct 2016 15:59:52 +0000
Subject: [openssl-users] free certs: bad idea
 wosign/startcom/startssl/startencrypt; good alt's
In-Reply-To: <5810D0C8.8010100@forthepolls.org>
References: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
 <CAH8yC8mm7JNCOvXNh96XvAi8aViEDgCd8TgE-Y6YACu=Fu=AGw@mail.gmail.com>
 <8b83de9b584d4654946b8a960ecd121a@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5810D0C8.8010100@forthepolls.org>
Message-ID: <5af73aa2820c434aa2e5ef820387f6a7@usma1ex-dag1mb1.msg.corp.akamai.com>

Folks might find this article, *and the things it links to* as useful starting points.
   https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/

I am not sure if general discussion of CA trust issues is appropriate for openssl-users.
--
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: richsalz at jabber.at Twitter: RichSalz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161026/0635ccdd/attachment.html>

From michael at dataenter.co.at  Wed Oct 26 20:06:23 2016
From: michael at dataenter.co.at (Michael Kocum)
Date: Wed, 26 Oct 2016 22:06:23 +0200
Subject: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL client
Message-ID: <39EC7181F50D02449CC431A407F5684B526C933E@NTDEMKEXCH.dataenter.co.at>

1.1.0b fails to negotiate from an old program that uses OpenSSL.
The same old program can connect to 1.0.2h without any problem.

Here is the debug log of the server. Maybe someone can point me in the right direction what the problem might be.

openssl s_server -debug -state -bugs -serverpref -tlsextdebug -accept 25 -cert selfsigned.pem
Using default temp DH parameters
ACCEPT
SSL_accept:before SSL initialization
read from 0x14fffe0 [0x1509b53] (5 bytes => 5 (0x5))
0000 - 80 c8 01 03 01                                    .....
read from 0x14fffe0 [0x1509b58] (197 bytes => 197 (0xC5))
0000 - 00 9f 00 00 00 20 00 c0-14 00 c0 0a 00 00 39 00   ..... ........9.
0010 - 00 38 00 c0 0f 00 c0 05-00 00 35 00 00 88 00 00   .8........5.....
0020 - 87 00 00 84 00 c0 12 00-c0 08 00 00 16 00 00 13   ................
0030 - 00 c0 0d 00 c0 03 00 00-0a 07 00 c0 00 c0 13 00   ................
0040 - c0 09 00 00 33 00 00 32-00 c0 0e 00 c0 04 00 00   ....3..2........
0050 - 2f 00 00 9a 00 00 99 00-00 45 00 00 44 00 00 96   /........E..D...
0060 - 00 00 41 00 00 07 05 00-80 03 00 80 00 c0 11 00   ..A.............
0070 - c0 07 00 c0 0c 00 c0 02-00 00 05 00 00 04 01 00   ................
0080 - 80 00 00 15 00 00 12 00-00 09 06 00 40 00 00 14   ............ at ...
0090 - 00 00 11 00 00 08 00 00-06 04 00 80 00 00 03 02   ................
00a0 - 00 80 00 00 ff 30 16 85-97 e0 9f e3 aa b1 07 47   .....0.........G
00b0 - 99 a5 7c 38 20 cd 51 39-a1 14 2f 60 50 87 26 62   ..|8 .Q9../`P.&b
00c0 - 0e c8 73 53 86                                    ..sS.
SSL_accept:before SSL initialization
SSL_accept:SSLv3/TLS read client hello
SSL_accept:SSLv3/TLS write server hello
SSL_accept:SSLv3/TLS write certificate
SSL_accept:SSLv3/TLS write key exchange
write to 0x14fffe0 [0x1512d58] (1281 bytes => 1281 (0x501))
0000 - 16 03 01 00 51 02 00 00-4d 03 01 2c 21 40 97 a5   ....Q...M..,!@..
0010 - 67 b2 a4 a7 63 cc f0 58-af 24 a4 ca 61 d8 fa bf   g...c..X.$..a...
0020 - a8 50 84 29 20 54 70 1e-f5 8e c2 20 bf ad ba d7   .P.) Tp.... ....
0030 - fa 23 5b 77 eb 0f 30 a2-49 61 f9 ca 9f 28 3f 14   .#[w..0.Ia...(?.
0040 - bb d7 cd cf 5c 1b 69 d8-6b db 0e f7 c0 14 00 00   ....\.i.k.......
0050 - 05 ff 01 00 01 00 16 03-01 03 6e 0b 00 03 6a 00   ..........n...j.
0060 - 03 67 00 03 64 30 82 03-60 30 82 02 48 02 09 00   .g..d0..`0..H...
0070 - c0 99 99 49 38 26 56 04-30 0d 06 09 2a 86 48 86   ...I8&V.0...*.H.
0080 - f7 0d 01 01 05 05 00 30-72 31 0b 30 09 06 03 55   .......0r1.0...U
0090 - 04 06 13 02 41 54 31 0b-30 09 06 03 55 04 08 13   ....AT1.0...U...
00a0 - 02 41 54 31 0b 30 09 06-03 55 04 07 13 02 41 54   .AT1.0...U....AT
00b0 - 31 0d 30 0b 06 03 55 04-0a 13 04 54 45 53 54 31   1.0...U....TEST1
00c0 - 0d 30 0b 06 03 55 04 0b-13 04 54 45 53 54 31 0d   .0...U....TEST1.
00d0 - 30 0b 06 03 55 04 03 13-04 54 45 53 54 31 1c 30   0...U....TEST1.0
00e0 - 1a 06 09 2a 86 48 86 f7-0d 01 09 01 16 0d 74 65   ...*.H........te
00f0 - 73 74 40 74 65 73 74 2e-63 6f 6d 30 1e 17 0d 31   st at test.com0...1
0100 - 33 30 31 31 30 31 37 31-38 34 33 5a 17 0d 31 37   30110171843Z..17
0110 - 30 31 30 39 31 37 31 38-34 33 5a 30 72 31 0b 30   0109171843Z0r1.0
0120 - 09 06 03 55 04 06 13 02-41 54 31 0b 30 09 06 03   ...U....AT1.0...
0130 - 55 04 08 13 02 41 54 31-0b 30 09 06 03 55 04 07   U....AT1.0...U..
0140 - 13 02 41 54 31 0d 30 0b-06 03 55 04 0a 13 04 54   ..AT1.0...U....T
0150 - 45 53 54 31 0d 30 0b 06-03 55 04 0b 13 04 54 45   EST1.0...U....TE
0160 - 53 54 31 0d 30 0b 06 03-55 04 03 13 04 54 45 53   ST1.0...U....TES
0170 - 54 31 1c 30 1a 06 09 2a-86 48 86 f7 0d 01 09 01   T1.0...*.H......
0180 - 16 0d 74 65 73 74 40 74-65 73 74 2e 63 6f 6d 30   ..test at test.com0
0190 - 82 01 22 30 0d 06 09 2a-86 48 86 f7 0d 01 01 01   .."0...*.H......
01a0 - 05 00 03 82 01 0f 00 30-82 01 0a 02 82 01 01 00   .......0........
01b0 - d3 32 55 70 37 65 9c 8d-63 cf 8c 65 fb ac cf 44   .2Up7e..c..e...D
01c0 - 70 33 64 ae 9c db e6 3a-1d c5 be 66 f1 9a d0 79   p3d....:...f...y
01d0 - c3 6b 54 23 0e 3a 62 56-75 b2 c5 73 38 7c 02 4f   .kT#.:bVu..s8|.O
01e0 - ee 54 e3 99 e9 23 23 c8-ed f9 56 ea 0d 58 4f c0   .T...##...V..XO.
01f0 - 39 ea 55 57 7d e4 6a 24-25 c3 50 f0 49 79 f7 8a   9.UW}.j$%.P.Iy..
0200 - 3d f1 a4 dc 5f 0f 3f e4-1c 1c 24 0b 7c 8a 70 ef   =..._.?...$.|.p.
0210 - 22 80 bd 63 1d 3f 59 fd-aa 38 1d d4 9b be e8 f8   "..c.?Y..8......
0220 - b3 6b cd 4f 0b 6f f4 91-db 3c 0a 57 c1 d4 78 f7   .k.O.o...<.W..x.
0230 - 55 b1 f5 d4 f8 e6 27 6e-a6 24 8d d5 b0 59 ad 57   U.....'n.$...Y.W
0240 - 74 78 16 cf 96 4f f3 1b-0f f7 00 2e f2 10 78 a1   tx...O........x.
0250 - 46 2a 70 00 f1 17 ae 9f-c8 79 5f 2c e9 fd bb 93   F*p......y_,....
0260 - 1d e1 61 08 35 e7 8a 8a-93 16 70 ea d7 34 33 41   ..a.5.....p..43A
0270 - 60 74 ab 9d 0c f3 19 a0-e5 0b 89 54 6f eb e7 de   `t.........To...
0280 - 6e 09 b3 fd 8e e7 c4 6c-91 1b a7 c6 d4 72 39 09   n......l.....r9.
0290 - 74 f4 8c c5 6a 44 01 8a-e0 68 44 55 ea 7d 4e 13   t...jD...hDU.}N.
02a0 - 9f 2f ac fc 8a 39 e7 ee-d4 ce 04 00 10 cf 50 6b   ./...9........Pk
02b0 - 02 03 01 00 01 30 0d 06-09 2a 86 48 86 f7 0d 01   .....0...*.H....
02c0 - 01 05 05 00 03 82 01 01-00 01 5e a3 08 b1 67 4f   ..........^...gO
02d0 - bc 31 ae 14 3f bf c2 25-5f b3 e2 78 56 60 34 f7   .1..?..%_..xV`4.
02e0 - de ae ad 16 cb a0 b9 3d-66 50 98 e6 33 75 09 63   .......=fP..3u.c
02f0 - 43 02 fd d9 d0 ad 6d 32-8e 54 ef 62 fe cb 05 58   C.....m2.T.b...X
0300 - 3d 85 75 88 80 db 5e 8b-14 36 eb a6 a0 a1 c7 18   =.u...^..6......
0310 - 8b 87 77 a0 9e dc 6d ca-12 77 2a 8e d6 17 5c 02   ..w...m..w*...\.
0320 - 30 c7 e8 06 fe 2c f9 a5-86 37 84 3d ff f0 ae 48   0....,...7.=...H
0330 - a0 42 5a a0 a3 0e ef fd-49 dc 4d e5 20 91 6b d5   .BZ.....I.M. .k.
0340 - 77 b0 74 61 9f 52 7b 85-26 e1 31 fa 97 b2 17 1b   w.ta.R{.&.1.....
0350 - 93 25 8d 78 ed 45 03 95-04 9f 61 73 7a 34 06 14   .%.x.E....asz4..
0360 - 91 aa 40 1f 3d 99 ec 05-d0 c7 25 a0 26 3d 0d 58   .. at .=.....%.&=.X
0370 - 0f 95 d8 e2 6d 96 5c fc-20 16 03 43 14 54 7a dc   ....m.\. ..C.Tz.
0380 - 8d ca 9f 62 86 b1 f0 4a-fc 5b 0e 56 fb 97 6d 43   ...b...J.[.V..mC
0390 - d9 68 66 47 53 7c 63 d4-61 51 05 ba 9f 2b 8d 8a   .hfGS|c.aQ...+..
03a0 - c1 61 51 33 e2 ed 7f db-52 ce 47 0f 84 33 b8 12   .aQ3....R.G..3..
03b0 - 0c c7 fe 75 9c b2 ab 6a-01 39 05 62 9d 77 d4 f4   ...u...j.9.b.w..
03c0 - fd 38 89 a4 11 1b 02 e4-e7 16 03 01 01 2a 0c 00   .8...........*..
03d0 - 01 26 03 00 1d 20 4f b4-34 86 a8 a0 0a 45 5b 80   .&... O.4....E[.
03e0 - b0 79 9e bf 4b 91 ed ae-2c b7 ee 64 ff 39 78 c8   .y..K...,..d.9x.
03f0 - a0 e7 37 e6 a5 13 01 00-1a 9f 48 8e 91 73 55 3e   ..7.......H..sU>
0400 - 86 16 04 7e a9 b2 49 16-d6 f6 b3 c2 17 d1 4e 11   ...~..I.......N.
0410 - c4 67 7c 81 e6 49 a2 04-d7 bc 42 04 8c 2a 0f da   .g|..I....B..*..
0420 - a0 75 7d 80 98 5b 1a 0f-e2 48 55 06 95 38 0d a6   .u}..[...HU..8..
0430 - 84 f0 42 37 6b ee ca e9-e5 7e 13 11 d7 f9 3e f4   ..B7k....~....>.
0440 - b2 ae f1 01 e6 56 ab 7b-46 3b bd 66 de aa ad d7   .....V.{F;.f....
0450 - 41 59 2b 80 2d 76 98 a0-82 c8 d1 00 05 e8 11 da   AY+.-v..........
0460 - c3 4b c5 15 23 c0 ba 66-8c 9b fc 80 33 c4 e8 f9   .K..#..f....3...
0470 - 1f c7 82 ba b1 58 0c 87-54 42 b4 ce ed 66 4e 4e   .....X..TB...fNN
0480 - 3e 51 d4 9f 5f 1e 20 18-b1 5e 6a b9 bb e7 6c b2   >Q.._. ..^j...l.
0490 - 2d 27 52 90 70 9f b0 97-cb 6d 23 0b 9d 1c e6 9d   -'R.p....m#.....
04a0 - 71 2a ab 9b a9 42 c9 16-ce a1 86 63 96 fe b2 b6   q*...B.....c....
04b0 - 49 69 5c 80 7b 9d 3d 40-a8 4a 70 51 0a a1 99 a8   Ii\.{.=@.JpQ....
04c0 - b8 72 52 39 6b 8c c6 91-13 36 fb d5 fe 7d 2b db   .rR9k....6...}+.
04d0 - 45 3d 73 d9 be de fd 40-19 ed ec 41 84 d5 17 a7   E=s.... at ...A....
04e0 - 6e 32 05 51 5b e6 56 44-40 2b e8 54 d9 36 cc bb   n2.Q[.VD at +.T.6..
04f0 - 77 17 cd f3 7c e7 00 60-16 03 01 00 04 0e         w...|..`......
0501 - <SPACES/NULS>
SSL_accept:SSLv3/TLS write server done
read from 0x14fffe0 [0x1509b53] (5 bytes => 5 (0x5))
0000 - 15 03 01 00 02                                    .....
read from 0x14fffe0 [0x1509b58] (2 bytes => 2 (0x2))
0000 - 02 50                                             .P
SSL3 alert read:fatal:internal error
SSL_accept:error in SSLv3/TLS write server done
ERROR
0:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:ssl\record\rec_layer_s3.c:1382:SSL alert number 80
shutting down SSL
CONNECTION CLOSED

--
Michael Kocum [DataEnter]
michael at dataenter.co.at



From rsalz at akamai.com  Wed Oct 26 20:27:53 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 26 Oct 2016 20:27:53 +0000
Subject: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL
	client
In-Reply-To: <39EC7181F50D02449CC431A407F5684B526C933E@NTDEMKEXCH.dataenter.co.at>
References: <39EC7181F50D02449CC431A407F5684B526C933E@NTDEMKEXCH.dataenter.co.at>
Message-ID: <5487dfd3a70748258def0f6b0873e1b5@usma1ex-dag1mb1.msg.corp.akamai.com>

The old version is probably using DH keys that are too small.


From fremeneric at gmail.com  Wed Oct 26 20:37:44 2016
From: fremeneric at gmail.com (Eric Tremblay)
Date: Wed, 26 Oct 2016 16:37:44 -0400
Subject: [openssl-users] Enabling FIPS on an custom embedded system.
Message-ID: <CANbhLgwmCgAbRGyqFk=Gs25V29jMWj-_Ob3+PWPichVXXq5FEQ@mail.gmail.com>

Hi all,



I have built the FIPS module into our Platform but I am stuck at the point
to enable it.



We need FIPS to be enabled ? Platform wide ? not just for one application.



I have read the documentation and search on the web for answer but it seem
that I would have

to modify a package or write a small application just to enable FIPS.



Is there another way to enable it on startup of Linux ?  or maybe something
in OpenSSH ?



I also read about the OPENSSL_Config in the User Guide but I?m not sure
if/who and how it is called.



I am working with OpenSSL 1.0.2j and FIPS 2.0.9.



Thanks



Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161026/01adb380/attachment-0001.html>

From marquess at openssl.com  Wed Oct 26 21:04:07 2016
From: marquess at openssl.com (Steve Marquess)
Date: Wed, 26 Oct 2016 17:04:07 -0400
Subject: [openssl-users] Enabling FIPS on an custom embedded system.
In-Reply-To: <CANbhLgwmCgAbRGyqFk=Gs25V29jMWj-_Ob3+PWPichVXXq5FEQ@mail.gmail.com>
References: <CANbhLgwmCgAbRGyqFk=Gs25V29jMWj-_Ob3+PWPichVXXq5FEQ@mail.gmail.com>
Message-ID: <a9ed4a6f-27cb-6fda-6a5c-4b74a5433779@openssl.com>

On 10/26/2016 04:37 PM, Eric Tremblay wrote:
> Hi all,____
> 
> __ __
> 
> I have built the FIPS module into our Platform but I am stuck at the
> point to enable it.____
> 
> __ __
> 
> We need FIPS to be enabled ? Platform wide ? not just for one
> application.____
> 
> __ __
> 
> I have read the documentation and search on the web for answer but it
> seem that I would have ____
> 
> to modify a package or write a small application just to enable FIPS.____
> 
> __ __
> 
> Is there another way to enable it on startup of Linux ?  or maybe
> something in OpenSSH ?____
> 
> __ __
> 
> I also read about the OPENSSL_Config in the User Guide but I?m not sure
> if/who and how it is called.____
> 
> __ __
> 
> I am working with OpenSSL 1.0.2j and FIPS 2.0.9.____
> 
> __ __
> 
> Thanks____
> 
> __ __
> 
> Eric
> 
> 
> 


Hmmm ... where to start.

First there is really no such thing as "enabling FIPS" for a platform.
The FIPS module is executable code that runs in the context of a
process, and to be righteous FIPS-wise each process (that uses
cryptography) must invoke the FIPS_mode_set() call that performs the
mandatory POST (Power Up Self Test). Note that is true even when the
FIPS module is embedded in a shared library (the "FIPS enabled"
OpenSSL), as each process using said shared library maps writable data
into its own private address space.

So to make the sweeping claim that a "platform" is FIPS enabled, you
must make sure that *every* process for that platform enables FIPS mode
via a FIPS_mode_set() call (whether directly or indirectly). Note that
for your typical general purpose (e.g. Windows or Linux-like) operating
system that is an essentially unachievable goal, as not all of the many
crypto-using applications are readily converted to use the FIPS enabled
OpenSSL (for instance OpenSSH needs non-trivial hacks). Likewise
kernel-mode crypto can't be addressed with the OpenSSL FIPS module.

For that reason the wise and prudent vendor does not attempt to "enable
FIPS" for an entire platform (for Level 1 validations), but rather only
makes claims about specific individual applications running on that
platform.

In the case where all processes of interest are compatible with the FIPS
capable OpenSSL (specifically, not referencing any other crypto
implementations, or non-approved cryptographic operations), then
OPENSSL_config() can in principle be used to indirectly call
FIPS_mode_set() for each such application. That is only *after* every
such application/process has *first* been modified for compatibility
with the FIPS capable OpenSSL. Very few applications not already
designed to support the OpenSSL FIPS module will be compatible without
some degree of modification.

-Steve M.

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

From fremeneric at gmail.com  Wed Oct 26 22:06:20 2016
From: fremeneric at gmail.com (Eric Tremblay)
Date: Wed, 26 Oct 2016 18:06:20 -0400
Subject: [openssl-users] Enabling FIPS on an custom embedded system.
In-Reply-To: <a9ed4a6f-27cb-6fda-6a5c-4b74a5433779@openssl.com>
References: <CANbhLgwmCgAbRGyqFk=Gs25V29jMWj-_Ob3+PWPichVXXq5FEQ@mail.gmail.com>
 <a9ed4a6f-27cb-6fda-6a5c-4b74a5433779@openssl.com>
Message-ID: <CANbhLgzZYB5LnE+fe8zdAi119xgHxDBH31k=T+O00N5OAzg39g@mail.gmail.com>

Hi Steve,

Thanks for the quick reply.

That is what I had understand from my reading but wasn't sure.

My next question is about OpenSSH.  There is no official support in OpenSSH
for FIPS at the moment right ?

Thanks

Eric



On Wed, Oct 26, 2016 at 5:04 PM, Steve Marquess <marquess at openssl.com>
wrote:

> On 10/26/2016 04:37 PM, Eric Tremblay wrote:
> > Hi all,____
> >
> > __ __
> >
> > I have built the FIPS module into our Platform but I am stuck at the
> > point to enable it.____
> >
> > __ __
> >
> > We need FIPS to be enabled ? Platform wide ? not just for one
> > application.____
> >
> > __ __
> >
> > I have read the documentation and search on the web for answer but it
> > seem that I would have ____
> >
> > to modify a package or write a small application just to enable FIPS.____
> >
> > __ __
> >
> > Is there another way to enable it on startup of Linux ?  or maybe
> > something in OpenSSH ?____
> >
> > __ __
> >
> > I also read about the OPENSSL_Config in the User Guide but I?m not sure
> > if/who and how it is called.____
> >
> > __ __
> >
> > I am working with OpenSSL 1.0.2j and FIPS 2.0.9.____
> >
> > __ __
> >
> > Thanks____
> >
> > __ __
> >
> > Eric
> >
> >
> >
>
>
> Hmmm ... where to start.
>
> First there is really no such thing as "enabling FIPS" for a platform.
> The FIPS module is executable code that runs in the context of a
> process, and to be righteous FIPS-wise each process (that uses
> cryptography) must invoke the FIPS_mode_set() call that performs the
> mandatory POST (Power Up Self Test). Note that is true even when the
> FIPS module is embedded in a shared library (the "FIPS enabled"
> OpenSSL), as each process using said shared library maps writable data
> into its own private address space.
>
> So to make the sweeping claim that a "platform" is FIPS enabled, you
> must make sure that *every* process for that platform enables FIPS mode
> via a FIPS_mode_set() call (whether directly or indirectly). Note that
> for your typical general purpose (e.g. Windows or Linux-like) operating
> system that is an essentially unachievable goal, as not all of the many
> crypto-using applications are readily converted to use the FIPS enabled
> OpenSSL (for instance OpenSSH needs non-trivial hacks). Likewise
> kernel-mode crypto can't be addressed with the OpenSSL FIPS module.
>
> For that reason the wise and prudent vendor does not attempt to "enable
> FIPS" for an entire platform (for Level 1 validations), but rather only
> makes claims about specific individual applications running on that
> platform.
>
> In the case where all processes of interest are compatible with the FIPS
> capable OpenSSL (specifically, not referencing any other crypto
> implementations, or non-approved cryptographic operations), then
> OPENSSL_config() can in principle be used to indirectly call
> FIPS_mode_set() for each such application. That is only *after* every
> such application/process has *first* been modified for compatibility
> with the FIPS capable OpenSSL. Very few applications not already
> designed to support the OpenSSL FIPS module will be compatible without
> some degree of modification.
>
> -Steve M.
>
> --
> Steve Marquess
> OpenSSL Validation Services, Inc.
> 1829 Mount Ephraim Road
> Adamstown, MD  21710
> USA
> +1 877 673 6775 s/b
> +1 301 874 2571 direct
> marquess at openssl.com
> gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161026/67311bf5/attachment.html>

From scott_n at xypro.com  Wed Oct 26 22:22:36 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 26 Oct 2016 22:22:36 +0000
Subject: [openssl-users] Enabling FIPS on an custom embedded system.
In-Reply-To: <CANbhLgzZYB5LnE+fe8zdAi119xgHxDBH31k=T+O00N5OAzg39g@mail.gmail.com>
References: <CANbhLgwmCgAbRGyqFk=Gs25V29jMWj-_Ob3+PWPichVXXq5FEQ@mail.gmail.com>
 <a9ed4a6f-27cb-6fda-6a5c-4b74a5433779@openssl.com>
 <CANbhLgzZYB5LnE+fe8zdAi119xgHxDBH31k=T+O00N5OAzg39g@mail.gmail.com>
Message-ID: <D358E5B1511A314F8160ADC6F375498778F8A348@XYSVEX02.XYPRO-23.LOCAL>

No.   You can check with the OpenSSH mailing list, but I?m pretty darned sure the answer is no.


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





From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Eric Tremblay
Sent: Wednesday, October 26, 2016 3:06 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Enabling FIPS on an custom embedded system.

Hi Steve,

Thanks for the quick reply.

That is what I had understand from my reading but wasn't sure.

My next question is about OpenSSH.  There is no official support in OpenSSH for FIPS at the moment right ?

Thanks

Eric



On Wed, Oct 26, 2016 at 5:04 PM, Steve Marquess <marquess at openssl.com<mailto:marquess at openssl.com>> wrote:
On 10/26/2016 04:37 PM, Eric Tremblay wrote:
> Hi all,____
>
> __ __
>
> I have built the FIPS module into our Platform but I am stuck at the
> point to enable it.____
>
> __ __
>
> We need FIPS to be enabled ? Platform wide ? not just for one
> application.____
>
> __ __
>
> I have read the documentation and search on the web for answer but it
> seem that I would have ____
>
> to modify a package or write a small application just to enable FIPS.____
>
> __ __
>
> Is there another way to enable it on startup of Linux ?  or maybe
> something in OpenSSH ?____
>
> __ __
>
> I also read about the OPENSSL_Config in the User Guide but I?m not sure
> if/who and how it is called.____
>
> __ __
>
> I am working with OpenSSL 1.0.2j and FIPS 2.0.9.____
>
> __ __
>
> Thanks____
>
> __ __
>
> Eric
>
>
>


Hmmm ... where to start.

First there is really no such thing as "enabling FIPS" for a platform.
The FIPS module is executable code that runs in the context of a
process, and to be righteous FIPS-wise each process (that uses
cryptography) must invoke the FIPS_mode_set() call that performs the
mandatory POST (Power Up Self Test). Note that is true even when the
FIPS module is embedded in a shared library (the "FIPS enabled"
OpenSSL), as each process using said shared library maps writable data
into its own private address space.

So to make the sweeping claim that a "platform" is FIPS enabled, you
must make sure that *every* process for that platform enables FIPS mode
via a FIPS_mode_set() call (whether directly or indirectly). Note that
for your typical general purpose (e.g. Windows or Linux-like) operating
system that is an essentially unachievable goal, as not all of the many
crypto-using applications are readily converted to use the FIPS enabled
OpenSSL (for instance OpenSSH needs non-trivial hacks). Likewise
kernel-mode crypto can't be addressed with the OpenSSL FIPS module.

For that reason the wise and prudent vendor does not attempt to "enable
FIPS" for an entire platform (for Level 1 validations), but rather only
makes claims about specific individual applications running on that
platform.

In the case where all processes of interest are compatible with the FIPS
capable OpenSSL (specifically, not referencing any other crypto
implementations, or non-approved cryptographic operations), then
OPENSSL_config() can in principle be used to indirectly call
FIPS_mode_set() for each such application. That is only *after* every
such application/process has *first* been modified for compatibility
with the FIPS capable OpenSSL. Very few applications not already
designed to support the OpenSSL FIPS module will be compatible without
some degree of modification.

-Steve M.

--
Steve Marquess
OpenSSL Validation Services, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775<tel:%2B1%20877%20673%206775> s/b
+1 301 874 2571<tel:%2B1%20301%20874%202571> direct
marquess at openssl.com<mailto:marquess at openssl.com>
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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

From matt at openssl.org  Wed Oct 26 22:48:28 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 26 Oct 2016 23:48:28 +0100
Subject: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL
 client
In-Reply-To: <39EC7181F50D02449CC431A407F5684B526C933E@NTDEMKEXCH.dataenter.co.at>
References: <39EC7181F50D02449CC431A407F5684B526C933E@NTDEMKEXCH.dataenter.co.at>
Message-ID: <90f95a90-34ad-2cd2-28fb-c54af179396c@openssl.org>



On 26/10/16 21:06, Michael Kocum wrote:
> 1.1.0b fails to negotiate from an old program that uses OpenSSL.
> The same old program can connect to 1.0.2h without any problem.
> 
> Here is the debug log of the server. Maybe someone can point me in the right direction what the problem might be.
> 
> openssl s_server -debug -state -bugs -serverpref -tlsextdebug -accept 25 -cert selfsigned.pem
> Using default temp DH parameters
> ACCEPT
> SSL_accept:before SSL initialization
> read from 0x14fffe0 [0x1509b53] (5 bytes => 5 (0x5))
> 0000 - 80 c8 01 03 01                                    .....
> read from 0x14fffe0 [0x1509b58] (197 bytes => 197 (0xC5))
> 0000 - 00 9f 00 00 00 20 00 c0-14 00 c0 0a 00 00 39 00   ..... ........9.
> 0010 - 00 38 00 c0 0f 00 c0 05-00 00 35 00 00 88 00 00   .8........5.....
> 0020 - 87 00 00 84 00 c0 12 00-c0 08 00 00 16 00 00 13   ................
> 0030 - 00 c0 0d 00 c0 03 00 00-0a 07 00 c0 00 c0 13 00   ................
> 0040 - c0 09 00 00 33 00 00 32-00 c0 0e 00 c0 04 00 00   ....3..2........
> 0050 - 2f 00 00 9a 00 00 99 00-00 45 00 00 44 00 00 96   /........E..D...
> 0060 - 00 00 41 00 00 07 05 00-80 03 00 80 00 c0 11 00   ..A.............
> 0070 - c0 07 00 c0 0c 00 c0 02-00 00 05 00 00 04 01 00   ................
> 0080 - 80 00 00 15 00 00 12 00-00 09 06 00 40 00 00 14   ............ at ...
> 0090 - 00 00 11 00 00 08 00 00-06 04 00 80 00 00 03 02   ................
> 00a0 - 00 80 00 00 ff 30 16 85-97 e0 9f e3 aa b1 07 47   .....0.........G
> 00b0 - 99 a5 7c 38 20 cd 51 39-a1 14 2f 60 50 87 26 62   ..|8 .Q9../`P.&b
> 00c0 - 0e c8 73 53 86                                    ..sS.

The above indicates that the client has sent an SSLv2 Compatible
ClientHello, although has indicated support for TLSv1.0. OpenSSL 1.1.0
doesn't support SSLv2, but it *does* still support the (very old) SSLv2
Compat ClientHello format. Unfortunately an SSLv2 compat hello does
*not* have an extensions section, which is important for communicating
info such as supported curves etc when using EC based ciphersuites.


> SSL_accept:before SSL initialization
> SSL_accept:SSLv3/TLS read client hello
> SSL_accept:SSLv3/TLS write server hello
> SSL_accept:SSLv3/TLS write certificate
> SSL_accept:SSLv3/TLS write key exchange
> write to 0x14fffe0 [0x1512d58] (1281 bytes => 1281 (0x501))
> 0000 - 16 03 01 00 51 02 00 00-4d 03 01 2c 21 40 97 a5   ....Q...M..,!@..
> 0010 - 67 b2 a4 a7 63 cc f0 58-af 24 a4 ca 61 d8 fa bf   g...c..X.$..a...
> 0020 - a8 50 84 29 20 54 70 1e-f5 8e c2 20 bf ad ba d7   .P.) Tp.... ....
> 0030 - fa 23 5b 77 eb 0f 30 a2-49 61 f9 ca 9f 28 3f 14   .#[w..0.Ia...(?.
> 0040 - bb d7 cd cf 5c 1b 69 d8-6b db 0e f7 c0 14 00 00   ....\.i.k.......
> 0050 - 05 ff 01 00 01 00 

This is the ServerHello that the server is sending back to the client.
The "c0 14" near the end of line 0040 indicates that the server has
selected TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as the ciphersuite.


>                          16 03-01 03 6e 0b 00 03 6a 00   ..........n...j.
> 0060 - 03 67 00 03 64 30 82 03-60 30 82 02 48 02 09 00   .g..d0..`0..H...
...snip...lots of uninteresting lines

This is Certificate message sent from server to client.


>                                   16 03 01 01 2a 0c 00   .8...........*..
> 03d0 - 01 26 03 00 1d 20 4f b4-34 86 a8 a0 0a 45 5b 80   .&... O.4....E[.
> 03e0 - b0 79 9e bf 4b 91 ed ae-2c b7 ee 64 ff 39 78 c8   .y..K...,..d.9x.
> 03f0 - a0 e7 37 e6 a5 13 01 00-1a 9f 48 8e 91 73 55 3e   ..7.......H..sU>
> 0400 - 86 16 04 7e a9 b2 49 16-d6 f6 b3 c2 17 d1 4e 11   ...~..I.......N.
> 0410 - c4 67 7c 81 e6 49 a2 04-d7 bc 42 04 8c 2a 0f da   .g|..I....B..*..
> 0420 - a0 75 7d 80 98 5b 1a 0f-e2 48 55 06 95 38 0d a6   .u}..[...HU..8..
> 0430 - 84 f0 42 37 6b ee ca e9-e5 7e 13 11 d7 f9 3e f4   ..B7k....~....>.
> 0440 - b2 ae f1 01 e6 56 ab 7b-46 3b bd 66 de aa ad d7   .....V.{F;.f....
> 0450 - 41 59 2b 80 2d 76 98 a0-82 c8 d1 00 05 e8 11 da   AY+.-v..........
> 0460 - c3 4b c5 15 23 c0 ba 66-8c 9b fc 80 33 c4 e8 f9   .K..#..f....3...
> 0470 - 1f c7 82 ba b1 58 0c 87-54 42 b4 ce ed 66 4e 4e   .....X..TB...fNN
> 0480 - 3e 51 d4 9f 5f 1e 20 18-b1 5e 6a b9 bb e7 6c b2   >Q.._. ..^j...l.
> 0490 - 2d 27 52 90 70 9f b0 97-cb 6d 23 0b 9d 1c e6 9d   -'R.p....m#.....
> 04a0 - 71 2a ab 9b a9 42 c9 16-ce a1 86 63 96 fe b2 b6   q*...B.....c....
> 04b0 - 49 69 5c 80 7b 9d 3d 40-a8 4a 70 51 0a a1 99 a8   Ii\.{.=@.JpQ....
> 04c0 - b8 72 52 39 6b 8c c6 91-13 36 fb d5 fe 7d 2b db   .rR9k....6...}+.
> 04d0 - 45 3d 73 d9 be de fd 40-19 ed ec 41 84 d5 17 a7   E=s.... at ...A....
> 04e0 - 6e 32 05 51 5b e6 56 44-40 2b e8 54 d9 36 cc bb   n2.Q[.VD at +.T.6..
> 04f0 - 77 17 cd f3 7c e7 00 60-

This is the ServerKeyExchange

The "00 1d" on line 03d0 tells you the curve that the server has
selected. That corresponds to Curve 25519!!!! This is a modern curve
which an old client will not understand. The server has selected it
because it didn't get an extension from the client saying what curves it
supports, so it just picked one.

This is very likely to be your problem. To test the theory, try adding
"-named_curve P-256" onto your s_server line. P-256 is a much more
widely supported curve.

Matt


>                                16 03 01 00 04 0e         w...|..`......
> 0501 - <SPACES/NULS>
> SSL_accept:SSLv3/TLS write server done
> read from 0x14fffe0 [0x1509b53] (5 bytes => 5 (0x5))
> 0000 - 15 03 01 00 02                                    .....
> read from 0x14fffe0 [0x1509b58] (2 bytes => 2 (0x2))
> 0000 - 02 50                                             .P
> SSL3 alert read:fatal:internal error
> SSL_accept:error in SSLv3/TLS write server done
> ERROR
> 0:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:ssl\record\rec_layer_s3.c:1382:SSL alert number 80
> shutting down SSL
> CONNECTION CLOSED
> 
> --
> Michael Kocum [DataEnter]
> michael at dataenter.co.at
> 
> 

From michael at dataenter.co.at  Thu Oct 27 06:58:26 2016
From: michael at dataenter.co.at (Michael Kocum)
Date: Thu, 27 Oct 2016 08:58:26 +0200
Subject: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL
	client
Message-ID: <39EC7181F50D02449CC431A407F5684B526C96FC@NTDEMKEXCH.dataenter.co.at>

>This is very likely to be your problem. To test the theory, try adding
>"-named_curve P-256" onto your s_server line. P-256 is a much more
>widely supported curve.

Yes, this fixed the problem. 

Thank you for your support in this case.

--
Michael Kocum [DataEnter]
michael at dataenter.co.at



From leikong at msn.com  Thu Oct 27 08:24:05 2016
From: leikong at msn.com (Lei Kong)
Date: Thu, 27 Oct 2016 08:24:05 +0000
Subject: [openssl-users] SSL_set_verify with a context?
In-Reply-To: <BN1PR01MB021D1C132285A9F9A40C87FA8AA0@BN1PR01MB021.prod.exchangelabs.com>
References: <BN1PR01MB021D1C132285A9F9A40C87FA8AA0@BN1PR01MB021.prod.exchangelabs.com>
Message-ID: <BN1PR01MB021CC74F74F7E3830D3C9F1A8AA0@BN1PR01MB021.prod.exchangelabs.com>

What I am trying to achieve is to allow some minor certificate chain validation errors, e.g. "CRL unavailable", based on my per-session configuration. I am think of using my verify callback to record the errors.

void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *));

int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);


Given the above interfaces, it seems I cannot set the callback with a context, which is needed to link a callback instance to my SSL session for error tracking. Yes, I can use SSL_get_verify_result to get the error afterwards, but is it guaranteed that the most severe error is always returned by SSL_get_verify_result? For example, I don't want "unable to get CRL" to mask other more important errors.


I would rather avoid repeating validating the whole chain manually after default validation is completed, is it possible to achieve my goal without repeating chain validation manually?


Any comment will be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161027/c7753865/attachment.html>

From marquess at openssl.com  Thu Oct 27 12:12:18 2016
From: marquess at openssl.com (Steve Marquess)
Date: Thu, 27 Oct 2016 08:12:18 -0400
Subject: [openssl-users] Enabling FIPS on an custom embedded system.
In-Reply-To: <CANbhLgzZYB5LnE+fe8zdAi119xgHxDBH31k=T+O00N5OAzg39g@mail.gmail.com>
References: <CANbhLgwmCgAbRGyqFk=Gs25V29jMWj-_Ob3+PWPichVXXq5FEQ@mail.gmail.com>
 <a9ed4a6f-27cb-6fda-6a5c-4b74a5433779@openssl.com>
 <CANbhLgzZYB5LnE+fe8zdAi119xgHxDBH31k=T+O00N5OAzg39g@mail.gmail.com>
Message-ID: <254b2cf6-be00-4236-43c1-d1316e7da4fa@openssl.com>

On 10/26/2016 06:06 PM, Eric Tremblay wrote:
> Hi Steve,
> 
> Thanks for the quick reply.
> 
> That is what I had understand from my reading but wasn't sure.
> 
> My next question is about OpenSSH.  There is no official support in
> OpenSSH for FIPS at the moment right ?
> 
> Thanks
> 
> Eric
> 

No, and there never will be; as I understand it the OpenSSH project has
taken the position that FIPS 140 isn't a desirable feature for OpenSSH.
TBH they have a point; from any technical perspective (e.g. security,
performance, maintainability) FIPS support is a negative. Ditto x.509
where the OpenSSH project has implemented a much simpler and more robust
certificate scheme.

You can find a rather old patch at
http://openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch, but
note that OpenSSH has evolved considerably since then.

There is another issue to consider as well. The only sane reason to use
FIPS 140 validated software is for deployment in environments where such
validation is a mandatory policy requirement. The US DoD is the largest
such environment, and there x.509 is also a mandate. Roumen Petrov has
for years maintained patches to add x.509 support to OpenSSH
(http://roumenpetrov.info/openssh/), but hacking OpenSSH for both FIPS
140 and x.509 is not a project for the faint-hearted, and since OpenSSH
is unlikely to ever add either feature officially you're left with a
long maintenance tail.

-Steve M.

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

From Lander at fit.be  Thu Oct 27 14:05:15 2016
From: Lander at fit.be (Lander Bulckaen)
Date: Thu, 27 Oct 2016 14:05:15 +0000
Subject: [openssl-users] Help
Message-ID: <1BF0BB099673884291E8E8CB1C42CAFD033C662519@FITSERV01.fit.local>

Hy,

Goal: add an xml file as attachment to a MIME message and sign the MIME message with the primary key (.p12 file).

The result must be like what you see below...?

Which openssl commands must I use in commandline?
(I already searched for ita bout 2 months but still not found any solution...!)

Date: Fri Jul 01 10:26:15 CEST 2016
From: michel.dombret at nbb.be
To:
Message-ID: <28456974.01467361575985.JavaMail.feronan at PC0020881>
Subject: NBB signed file
MIME-Version: 1.0
Content-Type: multipart/signed;
                boundary="----=_Part_1_6142443.1467361575963";
                protocol="application/pkcs7-signature"; micalg=sha1

------=_Part_1_6142443.1467361575963
Content-Type: multipart/mixed;
                boundary="----=_Part_0_25389802.1467361575861"

------=_Part_0_25389802.1467361575861
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Message created by Offline Signing Tool of National bank of BELGIUM
------=_Part_0_25389802.1467361575861
Content-Type: application/octet-stream; name=RequestFeedbacks.xml
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=RequestFeedbacks.xml

<?xml version="1.0" encoding="UTF-8"?>
<Request>
            <Version>V01</Version>
            <Criteria>
            <DocDate>
                        <From>2016-08-01</From>
                        <To>2016-08-15</To>
            </DocDate>
            <DocType>ALL</DocType>
            <UnrequestedDocOnly>true</UnrequestedDocOnly>
            </Criteria>
</Request>

------=_Part_0_25389802.1467361575861--

------=_Part_1_6142443.1467361575963
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBXMw
ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3Vy
ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0wNzA0MDMxMzE2MDRa
Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV
BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xCzAJBgNVBAsT
AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkBFhNwcjAzaGtldHRp
bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXENutQ5VnJDP0Q1waji
85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b6d/ErcVBweBORvRo
MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+pEkCdxM3ELZRZM6Rp
7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/1sOuga0jf80sNpuQm9hysHRG
fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUmwCKhbgEYjnIxQ
71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G
X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvVMB4GA1UdEQQXMBWB
E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+ADCcE5+oIz0Kts4f
OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI+UU2QiyaUfXSMvuLct3yZX0Pc6+
8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+762HW04TNhgQUUkMaEn/T
HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNWSt8NsEmba/7ZD3
XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+89MT56qfrDbfiJtRvICWXTYBh0tdki
057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+2TyF
BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjSlXkk0yvnF6
vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+CzeSpmDJNtKnU/nm
ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjoNICBKYO
VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJKoZI
hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1
c3NlbHMxITAfBgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBT
ZWN1cml0eSBNYW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZI
hvcNAQkBFg1kc21vcHNAbmJiLmJlMB4XDTA1MDUyMzA4NDkzMFoXDTI1MDUxODA4NDkzMFowgbUx
CzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAfBgNV
BAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBNYW5h
Z2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1kc21v
cHNAbmJiLmJlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt+wnMwqwqr8q7m20/ly+
HZl7RznDuxKX1muAdmFxwm+LXTQtvNbwEom8xmpwLAy0tn+P+RKElWRTc06z8sqisHL282hULh/G
Otufmf6eQOzW3UsX6xZWa1Un9Y0BwLncm+CmNFYTcmhNUkr6PT1Lzu277BiiBrjxqs22jEd0ibOs
vKlv0xXGh0qXRcltd0IEpcPneod0L/HCsm65d9fuS584LShsBbPcaVO4Zg5N8Zi9+lAslkxsgDen
txvM+ZZuhtS6vAAUKOq6IgPa9Mgih2wrWOtrPRyj7aUHalODBbgAzHz0enNszVhGM0sw4fcETkDQ
AysOpFnClGcKk2FhdNb9Z3uCw80YZrd3NAGCfnYWR/SL0Flq6T+2BOur/gRDrL++NeDiJ38JUyK+
nMcBuieECYYFusaYUDSEzUHe2KIBfdd1Y2cvi6+sINCt+0939Naw+ZNITy6iOkUdXLgGdvS1YVa3
SEbmV9tIdTJhb2stp0prgUPMc5XOq3KGaKpKuqnos1XCfHc6JTE2l7OQc9PHnk7dsHBIvvHLQt3A
Z+XIj6pd70qtKKU/BsFk8fv09UAw6jWFTIdz9Msz6h1ieFstA4I3bzYLFwALirTFuR1SRH/9xl3s
6nUs78jJ5/ANE0HV3AiSMCJ2TvHfzDSZ1Efm+H5oTCn4vmvlPBEXnEMCAwEAAaOCAUswggFHMB0G
A1UdDgQWBBS4kquLf8ZfvlLTQZ8suRukZcYlRTAYBgNVHREEETAPgQ1kc21vcHNAbmJiLmJlMA8G
A1UdEwEB/wQFMAMBAf8wgeoGA1UdIwSB4jCB34AUuJKri3/GX75S00GfLLkbpGXGJUWhgbukgbgw
gbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAf
BgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBN
YW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1k
c21vcHNAbmJiLmJlggkAklGjqlmMoxgwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IC
AQA2hzYYNkQW3bJBy00n3ZegqggLA3IplHr/NhQZ6ppvOu+E4K993/1UNsv2hGIto1te3AD6AwUk
A1jstQi42e9WtG0c29gST7+AtAsn3clzRWnNXzIMaeTz+k0XNk6YdiiERNBShn5o8sUeiYxmWJQ6
ovicqBsBVkdknwifwa0CRG7kz6dMy7BWOY2mt8qFh6yIbhTox3HFVE2cdbs3k6cr9eOUv6xbkoCo
GcUWzu90Gqbpyny95ix/ZLiauCs8nGXwbbICo1CG2xZ7TJMfCAU1J55eYAaSmDkV843Q4Jr1cyPm
VPWhQDfWzA1bTsAB8Q4pwKVjq28jhDJZtKSS0FblgC96kMxlwajCSyzykhrsaVdwCaU++1KrwPDB
Y5VtZhyn55Cpgs/3gQ8L4BskrLdRpdVDvO4ER35gvAaQTRP8NwOzepGico34VpVa1prz+ZB+CvvM
KYN85i2jzFdvS2yag3jaCC+t2Xp0GKL2ZmF7oWDKkiWXwYjWJ/XiTZ3AdsBJPDvmOYxAuUeH/ADm
WRoNHCwaUbNr0vxEXLZam8bFyXe0TohiRGczUfSgQDzuAbAjKE2HQSeObI0w1ZWxzmvS1+xo/HDn
pZBd60fHaH/QpBwp0JnBxouRt/daxB0MuckGaEBx3qn925Ac5pzM+6K1N1uKF3mTxiM4Ocd9nWpM
1TGCApgwggKUAgEBMIG8MIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV
BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xITAfBgNVBAsT
GERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3VyZSBFbWFpbCBDQTEc
MBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZQICAKgwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDEwODI2MTVaMCMGCSqGSIb3DQEJ
BDEWBBRs4Ik9waWLNU/4OZ9TfT4yZZ0EljBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzANBgkq
hkiG9w0BAQEFAASCAQCSP5/h1v6feRr+ekK19tlI4zvm1Wy7hUtN+XmbWLJHOxSU4wJUBRj6ptph
Mb7AOm1JYy8+wWRQhgOcIegD74eXZoYfws+O3ADZ//feXYJAF/jqAyhs0r9CoGw2eUUeZR4KYILy
ZG5I3lcFJLDPHcElSe3NgRBOmfuFWD/mSLE2B2S+PqbnbugYPSN7mCSOqMZODPBlop9wczBUD1BI
K+kM1fP28541RfCFS6tGUXamWnKOdbxoHbPmnQDT1zzcbRIUvnLCV6MZ4KFNAXf5YxwggV3jjPiQ
vyzr8EdFzmaWpoOFEtCLmQw4hpSEPJO8yGxQ5/29MWg6Ypy62bjMfs54AAAAAAAA
------=_Part_1_6142443.1467361575963--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161027/e32771f5/attachment-0001.html>

From beldmit at gmail.com  Thu Oct 27 17:08:49 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Thu, 27 Oct 2016 20:08:49 +0300
Subject: [openssl-users] Help
In-Reply-To: <1BF0BB099673884291E8E8CB1C42CAFD033C662519@FITSERV01.fit.local>
References: <1BF0BB099673884291E8E8CB1C42CAFD033C662519@FITSERV01.fit.local>
Message-ID: <CADqLbzLbVCP0c7uLDRO4H++=h9gJ+Ewur3TH-Pc-qc=Hr9hQAA@mail.gmail.com>

Hello

You should use the XMLSec library and the corresponding command-line tool.

On Thu, Oct 27, 2016 at 5:05 PM, Lander Bulckaen <Lander at fit.be> wrote:

> Hy,
>
>
>
> Goal: add an xml file as attachment to a MIME message and *sign the MIME
> message* with the primary key (.p12 file).
>
>
>
> The result must be like what you see below??
>
>
>
> Which openssl commands must I use in commandline?
>
> (I already searched for ita bout 2 months but still not found any
> solution?!)
>
>
>
> Date: Fri Jul 01 10:26:15 CEST 2016
>
> From: michel.dombret at nbb.be
>
> To:
>
> Message-ID: <28456974.01467361575985.JavaMail.feronan at PC0020881>
>
> Subject: NBB signed file
>
> MIME-Version: 1.0
>
> Content-Type: multipart/signed;
>
>                 boundary="----=_Part_1_6142443.1467361575963";
>
>                 protocol="application/pkcs7-signature"; micalg=sha1
>
>
>
> ------=_Part_1_6142443.1467361575963
>
> Content-Type: multipart/mixed;
>
>                 boundary="----=_Part_0_25389802.1467361575861"
>
>
>
> ------=_Part_0_25389802.1467361575861
>
> Content-Type: text/plain; charset=us-ascii
>
> Content-Transfer-Encoding: 7bit
>
>
>
> Message created by Offline Signing Tool of National bank of BELGIUM
>
> ------=_Part_0_25389802.1467361575861
>
> Content-Type: application/octet-stream; name=RequestFeedbacks.xml
>
> Content-Transfer-Encoding: 7bit
>
> Content-Disposition: attachment; filename=RequestFeedbacks.xml
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <Request>
>
>             <Version>V01</Version>
>
>             <Criteria>
>
>             <DocDate>
>
>                         <From>2016-08-01</From>
>
>                         <To>2016-08-15</To>
>
>             </DocDate>
>
>             <DocType>ALL</DocType>
>
>             <UnrequestedDocOnly>true</UnrequestedDocOnly>
>
>             </Criteria>
>
> </Request>
>
>
>
> ------=_Part_0_25389802.1467361575861--
>
>
>
> ------=_Part_1_6142443.1467361575963
>
> Content-Type: application/pkcs7-signature; name=smime.p7s
>
> Content-Transfer-Encoding: base64
>
> Content-Disposition: attachment; filename=smime.p7s
>
>
>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
> AQAAoIIMtzCCBXMw
>
> ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTER
> MA8GA1UECBMIQnJ1
>
> c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBC
> YW5rIG9mIEJlbGdp
>
> dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UE
> AxMTTkJCIFNlY3Vy
>
> ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0w
> NzA0MDMxMzE2MDRa
>
> Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
> c3NlbHMxETAPBgNV
>
> BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
> dW0xCzAJBgNVBAsT
>
> AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkB
> FhNwcjAzaGtldHRp
>
> bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXEN
> utQ5VnJDP0Q1waji
>
> 85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b
> 6d/ErcVBweBORvRo
>
> MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+
> pEkCdxM3ELZRZM6Rp
>
> 7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/
> 1sOuga0jf80sNpuQm9hysHRG
>
> fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUm
> wCKhbgEYjnIxQ
>
> 71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/
> wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G
>
> X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvV
> MB4GA1UdEQQXMBWB
>
> E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQG
> CCsGAQUFBwMCBggr
>
> BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+
> ADCcE5+oIz0Kts4f
>
> OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI
> +UU2QiyaUfXSMvuLct3yZX0Pc6+
>
> 8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+
> 762HW04TNhgQUUkMaEn/T
>
> HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNW
> St8NsEmba/7ZD3
>
> XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+
> 89MT56qfrDbfiJtRvICWXTYBh0tdki
>
> 057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+
> 2TyF
>
> BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjS
> lXkk0yvnF6
>
> vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+
> CzeSpmDJNtKnU/nm
>
> ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjo
> NICBKYO
>
> VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJ
> KoZI
>
> hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczER
> MA8GA1UEBxMIQnJ1
>
> c3NlbHMxITAfBgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8G
> A1UECxMYRGF0YSBT
>
> ZWN1cml0eSBNYW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWls
> IENBMRwwGgYJKoZI
>
> hvcNAQkBFg1kc21vcHNAbmJiLmJlMB4XDTA1MDUyMzA4NDkzMFoXDTI1MDUx
> ODA4NDkzMFowgbUx
>
> CzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1
> c3NlbHMxITAfBgNV
>
> BAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBT
> ZWN1cml0eSBNYW5h
>
> Z2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZI
> hvcNAQkBFg1kc21v
>
> cHNAbmJiLmJlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt+
> wnMwqwqr8q7m20/ly+
>
> HZl7RznDuxKX1muAdmFxwm+LXTQtvNbwEom8xmpwLAy0tn+P+
> RKElWRTc06z8sqisHL282hULh/G
>
> Otufmf6eQOzW3UsX6xZWa1Un9Y0BwLncm+CmNFYTcmhNUkr6PT1Lzu277BiiBrjx
> qs22jEd0ibOs
>
> vKlv0xXGh0qXRcltd0IEpcPneod0L/HCsm65d9fuS584LShsBbPcaVO4Zg5N
> 8Zi9+lAslkxsgDen
>
> txvM+ZZuhtS6vAAUKOq6IgPa9Mgih2wrWOtrPRyj7aUHalODBbgAzHz0enNszVhGM
> 0sw4fcETkDQ
>
> AysOpFnClGcKk2FhdNb9Z3uCw80YZrd3NAGCfnYWR/SL0Flq6T+2BOur/
> gRDrL++NeDiJ38JUyK+
>
> nMcBuieECYYFusaYUDSEzUHe2KIBfdd1Y2cvi6+sINCt+0939Naw+
> ZNITy6iOkUdXLgGdvS1YVa3
>
> SEbmV9tIdTJhb2stp0prgUPMc5XOq3KGaKpKuqnos1XCfHc6JTE2l7OQc9PH
> nk7dsHBIvvHLQt3A
>
> Z+XIj6pd70qtKKU/BsFk8fv09UAw6jWFTIdz9Msz6h1ieF
> stA4I3bzYLFwALirTFuR1SRH/9xl3s
>
> 6nUs78jJ5/ANE0HV3AiSMCJ2TvHfzDSZ1Efm+H5oTCn4vmvlPBEXnEMCAwEAAaOCAUs
> wggFHMB0G
>
> A1UdDgQWBBS4kquLf8ZfvlLTQZ8suRukZcYlRTAYBgNVHREEETAPgQ1kc21v
> cHNAbmJiLmJlMA8G
>
> A1UdEwEB/wQFMAMBAf8wgeoGA1UdIwSB4jCB34AUuJKri3/
> GX75S00GfLLkbpGXGJUWhgbukgbgw
>
> gbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMI
> QnJ1c3NlbHMxITAf
>
> BgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0
> YSBTZWN1cml0eSBN
>
> YW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJ
> KoZIhvcNAQkBFg1k
>
> c21vcHNAbmJiLmJlggkAklGjqlmMoxgwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4
> IC
>
> AQA2hzYYNkQW3bJBy00n3ZegqggLA3IplHr/NhQZ6ppvOu+E4K993/
> 1UNsv2hGIto1te3AD6AwUk
>
> A1jstQi42e9WtG0c29gST7+AtAsn3clzRWnNXzIMaeTz+
> k0XNk6YdiiERNBShn5o8sUeiYxmWJQ6
>
> ovicqBsBVkdknwifwa0CRG7kz6dMy7BWOY2mt8qFh6yIbhTox3HFVE2cdbs3
> k6cr9eOUv6xbkoCo
>
> GcUWzu90Gqbpyny95ix/ZLiauCs8nGXwbbICo1CG2xZ7TJMfCA
> U1J55eYAaSmDkV843Q4Jr1cyPm
>
> VPWhQDfWzA1bTsAB8Q4pwKVjq28jhDJZtKSS0FblgC96kMxlwajCSyzykhrs
> aVdwCaU++1KrwPDB
>
> Y5VtZhyn55Cpgs/3gQ8L4BskrLdRpdVDvO4ER35gvAaQTRP8NwOzepGico34VpVa1prz+ZB+
> CvvM
>
> KYN85i2jzFdvS2yag3jaCC+t2Xp0GKL2ZmF7oWDKkiWXwYjWJ/
> XiTZ3AdsBJPDvmOYxAuUeH/ADm
>
> WRoNHCwaUbNr0vxEXLZam8bFyXe0TohiRGczUfSgQDzuAbAjKE2HQSeObI0w
> 1ZWxzmvS1+xo/HDn
>
> pZBd60fHaH/QpBwp0JnBxouRt/daxB0MuckGaEBx3qn925Ac5pzM+
> 6K1N1uKF3mTxiM4Ocd9nWpM
>
> 1TGCApgwggKUAgEBMIG8MIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
> c3NlbHMxETAPBgNV
>
> BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
> dW0xITAfBgNVBAsT
>
> GERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3Vy
> ZSBFbWFpbCBDQTEc
>
> MBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZQICAKgwCQYFKw4DAhoFAKCB
> sTAYBgkqhkiG9w0B
>
> CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDEwODI2MTVa
> MCMGCSqGSIb3DQEJ
>
> BDEWBBRs4Ik9waWLNU/4OZ9TfT4yZZ0EljBSBgkqhkiG9w0BC
> Q8xRTBDMAoGCCqGSIb3DQMHMA4G
>
> CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH
> BgUrDgMCBzANBgkq
>
> hkiG9w0BAQEFAASCAQCSP5/h1v6feRr+ekK19tlI4zvm1Wy7hUtN+
> XmbWLJHOxSU4wJUBRj6ptph
>
> Mb7AOm1JYy8+wWRQhgOcIegD74eXZoYfws+O3ADZ//feXYJAF/
> jqAyhs0r9CoGw2eUUeZR4KYILy
>
> ZG5I3lcFJLDPHcElSe3NgRBOmfuFWD/mSLE2B2S+PqbnbugYPSN7mCSOqMZODPBlop9wcz
> BUD1BI
>
> K+kM1fP28541RfCFS6tGUXamWnKOdbxoHbPmnQDT1zzcbRIUvnLCV6MZ4KFNAX
> f5YxwggV3jjPiQ
>
> vyzr8EdFzmaWpoOFEtCLmQw4hpSEPJO8yGxQ5/29MWg6Ypy62bjMfs54AAAAAAAA
>
> ------=_Part_1_6142443.1467361575963--
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161027/32ee40c3/attachment-0001.html>

From leikong at msn.com  Thu Oct 27 18:53:37 2016
From: leikong at msn.com (Lei Kong)
Date: Thu, 27 Oct 2016 18:53:37 +0000
Subject: [openssl-users] SSL_set_verify with a context?
In-Reply-To: <BN1PR01MB021CC74F74F7E3830D3C9F1A8AA0@BN1PR01MB021.prod.exchangelabs.com>
References: <BN1PR01MB021D1C132285A9F9A40C87FA8AA0@BN1PR01MB021.prod.exchangelabs.com>,
 <BN1PR01MB021CC74F74F7E3830D3C9F1A8AA0@BN1PR01MB021.prod.exchangelabs.com>
Message-ID: <BN1PR01MB021DAF0E2E4588D5FE7D937A8AA0@BN1PR01MB021.prod.exchangelabs.com>

I am using the following link ssl to my container structure, so is it possible to  get ssl from x509_ctx in verify_callback?
    SSL_set_app_data(ssl, this);

    int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);


________________________________
From: Lei Kong <leikong at msn.com>
Sent: Thursday, October 27, 2016 1:24:05 AM
To: openssl-users at openssl.org
Subject: SSL_set_verify with a context?


What I am trying to achieve is to allow some minor certificate chain validation errors, e.g. "CRL unavailable", based on my per-session configuration. I am think of using my verify callback to record the errors.

void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *));

int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);


Given the above interfaces, it seems I cannot set the callback with a context, which is needed to link a callback instance to my SSL session for error tracking. Yes, I can use SSL_get_verify_result to get the error afterwards, but is it guaranteed that the most severe error is always returned by SSL_get_verify_result? For example, I don't want "unable to get CRL" to mask other more important errors.


I would rather avoid repeating validating the whole chain manually after default validation is completed, is it possible to achieve my goal without repeating chain validation manually?


Any comment will be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161027/d98d6b37/attachment.html>

From Ryan.Pfeifle at nice.com  Thu Oct 27 19:54:34 2016
From: Ryan.Pfeifle at nice.com (Ryan Pfeifle)
Date: Thu, 27 Oct 2016 12:54:34 -0700
Subject: [openssl-users] SSL_set_verify with a context?
In-Reply-To: <BN1PR01MB021DAF0E2E4588D5FE7D937A8AA0@BN1PR01MB021.prod.exchangelabs.com>
References: <BN1PR01MB021D1C132285A9F9A40C87FA8AA0@BN1PR01MB021.prod.exchangelabs.com>, 
 <BN1PR01MB021CC74F74F7E3830D3C9F1A8AA0@BN1PR01MB021.prod.exchangelabs.com>
 <BN1PR01MB021DAF0E2E4588D5FE7D937A8AA0@BN1PR01MB021.prod.exchangelabs.com>
Message-ID: <65F4BC02FEB6AB43BF582425A3915E7B040F2E8A964C@omega>

You can use X509_STORE_CTX_get_app_data() and type-cast the returned pointer to SSL*.





Ryan Pfeifle
Software Engineer

[cid:2cada4cd821843daa7153d792a28ea74]<http://www.NICE.com>
VPI is now part of NICE<http://www.NICE.com>


Tel: 1.805.389.5200 x5297


E-mail: Ryan.Pfeifle at nice.com

<http://www.nice.com/Interactions>




The information transmitted in this message is intended only for the addressee and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete this material from any computer.

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Lei Kong
Sent: Thursday, October 27, 2016 11:54 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] SSL_set_verify with a context?

I am using the following link ssl to my container structure, so is it possible to  get ssl from x509_ctx in verify_callback?
    SSL_set_app_data(ssl, this);

    int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);

________________________________
From: Lei Kong <leikong at msn.com<mailto:leikong at msn.com>>
Sent: Thursday, October 27, 2016 1:24:05 AM
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: SSL_set_verify with a context?


What I am trying to achieve is to allow some minor certificate chain validation errors, e.g. "CRL unavailable", based on my per-session configuration. I am think of using my verify callback to record the errors.

void SSL_set_verify(SSL *s, int mode, int (*verify_callback)(int, X509_STORE_CTX *));

int verify_callback(int preverify_ok, X509_STORE_CTX *x509_ctx);



Given the above interfaces, it seems I cannot set the callback with a context, which is needed to link a callback instance to my SSL session for error tracking. Yes, I can use SSL_get_verify_result to get the error afterwards, but is it guaranteed that the most severe error is always returned by SSL_get_verify_result? For example, I don't want "unable to get CRL" to mask other more important errors.



I would rather avoid repeating validating the whole chain manually after default validation is completed, is it possible to achieve my goal without repeating chain validation manually?



Any comment will be appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161027/7f2e8440/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vpi_logo-sm.jpg
Type: image/jpeg
Size: 24783 bytes
Desc: vpi_logo-sm.jpg
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161027/7f2e8440/attachment-0001.jpg>

From hellonotelling at gmail.com  Fri Oct 28 01:22:31 2016
From: hellonotelling at gmail.com (Hello Notelling)
Date: Thu, 27 Oct 2016 18:22:31 -0700
Subject: [openssl-users] Money
Message-ID: <CAGrG7NZVmswQbq-Vc8HA7CJphAO7yOBvGwiuEGFaER5YzNB--w@mail.gmail.com>

I need a way to gain lots of money fast so could you hook me up with some
one that's seeking gold as i will happily distribute through the country
legally and illegally
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161027/d5a30ee3/attachment.html>

From jb-openssl at wisemo.com  Fri Oct 28 08:21:45 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 28 Oct 2016 10:21:45 +0200
Subject: [openssl-users] free certs: bad idea
 wosign/startcom/startssl/startencrypt; good alt's
In-Reply-To: <5810D0C8.8010100@forthepolls.org>
References: <CANjbsKyOBA0qNA1tj+tsjVpRhHoUfm0ZNSsLsFowfQucrK0h_Q@mail.gmail.com>
 <CAH8yC8mm7JNCOvXNh96XvAi8aViEDgCd8TgE-Y6YACu=Fu=AGw@mail.gmail.com>
 <8b83de9b584d4654946b8a960ecd121a@usma1ex-dag1mb1.msg.corp.akamai.com>
 <5810D0C8.8010100@forthepolls.org>
Message-ID: <13cf969a-ba2a-132f-ee35-e4a86ac203c3@wisemo.com>

Please note that the below summary contains a few exaggerations.  For 
instance the duplicate serial numbers seem to have been a software bug 
that issued N certificates with the same serial on busy days, while the 
backdating seemed much less excusable.  The person posting this seems 
also to be extremely US centric in his thinking, for instance 
referencing local US standards NIST and AICPA, rather than their 
international or Asian counterparts.  There is much more balanced 
information at the URL posted by Mr. Salz.

On 26/10/2016 17:50, Johann v. Preu?en wrote:
> this is a re-worked report i prepared that some might find useful.*
>
> CAUTION:* there are several seriously troubling events surrounding 
> WoSign *^1 * (AKA startcom, AKA startssl, and AKA startencrypt) and 
> any of their affiliated/subsidiary businesses:
>
>  1. wosign purchased startcom/startssl/startencrypt [DBA's of 'Start
>     Commercial LTD' (an Israeli company); hereinafter '*startcom*']
>     last year. although obfuscation by the parties makes determining
>     the actual control-transfer date impossible, the change-over may
>     have begun in 2014. both companies long completely and publicly
>     denied any change of control even as late as 2016.JUL despite it
>     being a matter of public record that:
>      1.  the entire stock issuance from 15 startcom shareholders
>         including founder Revital (AKA 'Eddy') Nigg's majority
>         ownership was transferred in 2015.NOV;
>      2.  beneficiary of the stock deal was 'StartCom CA Limited' a UK
>         company (09744347);
>      3.  the UK company is wholly-owned by 'StartCom CA Limited' (yes,
>         exactly the same name again) a Hong Kong company (CRN 2271553)
>         with a sole director being Wang *^1 *; and
>      4.  the Hong Kong entity is then owned by wosign.
>  2. in fact, to-date neither firm has actually admitted what has
>     happened re transfer of control, domiciling of operations, and
>     changes in management personnel. this reticence is despite some
>     aspects of the transactions becoming common knowledge in the
>     security community;
>  3. wosign attempted (rather poorly it turned out) to make it appear
>     that wosign was actually a subsidiary of startcom and startcom's
>     remnant personnel and former shareholders abetted this *^2 *;
>  4. startcom is an Israeli company and -- as one would expect -- was
>     subjected to strict auditing and monitoring by the Israeli
>     government to the benefit of all the recipients of their certs ...
>     until the ownership change that is;
>  5. wosign is a mainland Chinese (PRC) company which completely
>     controls startcom operations in IL, UK, CN, and US;
>  6. earlier this year and last wosign -- amongst other deceptive
>     actions --  tried to circumvent certain mandated changes to
>     certificate authority (CA) practice by back-/forward-dating certs
>     and issuing certs with duplicate serial numbers while their CA
>     compliance auditors Ernst and Young (Hong Kong) were complicit in
>     covering up these and other forbidden practices *^3 *;
>  7. in response to all these discoveries, mozilla's firefox version 51
>     and all look-alikes using their gecko engine have stopped
>     accepting any new (issued on/after 2016.OCT.21) certs that trace
>     back to wosign/startcom/startssl/startencrypt
>     root/intermediate/cross-signed certs and have banned Hong Kong
>     Ernst and Young CPA's from certifying any CA audits;
>  8. unless wosign and its subsidiaries come up with new root
>     certificates and provide acceptable audit results for their
>     CP/CPS/operations by 2017.MAR, all of wosign-affiliated
>     root/intermediate/cross-signed certs will be removed from
>     mozilla's certificate store; and
>  9. mozilla has stated that if it detects any further fraud such as
>     exhibited in Item 6, /supra/, all security updates to all its
>     software versions will immediately remove wosign-based "trusted"
>     certs from the mozilla root certificate store on the device being
>     updated which will cause the universe of wosign-issued certs to
>     become un-trusted in the mozilla browser family no matter when
>     they were issued.
>
> *OBVIOUS CONCLUSION: *do not just walk away from wosign, startcom, 
> qihoo, et alii but *RUN! *i can think of nothing worse than trusting a 
> PRC firm with my sites' security. OK, if that hyperbole is not enough, 
> try my personal idea of what should be network no-go and it pretty 
> much lies in the swath West of Japan and East of Germany.
>
> *THE ALTERNATIVE: *the immediate free cert replacement avenue is 
> through letsencrypt.org that uses the cert issuance/renewal protocol 
> ACME. although letsencrypt will not be found in most (if any) browser 
> "trusted" root certificate stores, they use cross-signed intermediate 
> CA certs from a root that is. there are an ever-growing number of 
> open-source scripts (bash, perl, python, go, ...) available to 
> automate the process which one can even customize for your particular 
> needs.
>
> there are letsencrypt plug-ins/modules for apache to make your set-up 
> less painful. you can use the nginx process with a lua module to 
> /really /fully automate _/everything!/_ if you want to go /de luxe/ 
> there is the openresty bundle that combines nginx with lua and adds a 
> host of other nginx "add-in" enhancements automatically and some more 
> rarely required that one specifies.
>
> if you have looked at openresty or other bundles before and been 
> turned off because there was nothing for your favorite distro/pkg-mgr 
> and the thoughts of maintaining a 2kb configure line immediately 
> switched your focus over to happy hour, look again! with openresty 
> repo's are in, security patches are quick in coming, development is 
> on-going 24/7, the "community" is lively, and the original/lead 
> developer still has his hand firmly on the tiller.
>
> one very important plus with the nginx set-up is that tls cert 
> operation under lua will actually boot-strap the ACME cert process for 
> each domain and all of the permitted sub-domains you authorize in the 
> nginx config file. so, what did i just mean?
>
> let us say that you have a new domain 'qwe.com' and want to use the 
> sub-domains www, billing, mail, sales, and support. obviously, you 
> have to get the DNS going as a separate project (3 minutes). you have 
> to create an on-disk directory tree that accommodates the storage of 
> the issued certs and a directory where the lua process will operate 
> with the letsencrypt server token process that verifies domain control 
> coming through DNS (2 minutes). then, you have a small config block in 
> the nginx 'http' section authorizing the sub-directories (2 minutes), 
> you drop in a 'server' section for whatever should be done (2 minutes: 
> assuming you have an already-established server processing block), and 
> you add to the server block a 'location' section for the token process 
> (1 minute). now, you re-start nginx *AND YOU ARE DONE (10 minutes 
> total)! *now that you have a template, adding on an additional domain 
> should probably run half or less of that time.
>
> when the first request comes in for, say, 'www.qwe.com'; nginx calls 
> the lua module that completes the whole cert process for getting the 
> cert for that FQDN and then services the request ... all without 
> connection interruption. then 'qwe.com' comes in and it adds that too. 
> then 'support.qwe.com' and so forth until all your configured 
> sub-domains are covered. you probably see it now: using this simple 
> set-up you can segregate sub-domain access between HTTP and HTTPS with 
> that tiny lua sub-domain authorization block. also, by authorizing 
> (temporarily or otherwise) nginx to answer for sub-domains for other 
> servers such as SMTP[S], IMAP[S], and so forth you will create your 
> own customized server certs for apps running any other service you 
> might like on whatever sub-domain you please by just making a single 
> request for each server's sub-domain.
>
> cert renewal is also automatic. with no special config, nginx will 
> renew the cert when it falls within a remaining window of 30 days.
>
>
> Thank you,
>
> Johann
>
> _*NOTES:*_
>
>  1. '*WoSign CA Limited*' (hereinafter '*wosign*') has been around in
>     a very minor way for, perhaps, as long as a decade. its only known
>     owner is Wang Gao Hua (AKA: Richard Wang). it is a demonstrable
>     fact that the PRC government is intensely interested in expanding
>     its scope of operation in the international security venue and
>     that its multi-faceted security apparatus has both overtly and
>     covertly been found to acquire vested interests in technology
>     ventures amenable to such an expansion. therefore, it is quite
>     imaginable that the PRC government financially facilitated Wang's
>     acquisition of startcom for its own purposes. it is all the more
>     conceivable given that Wang was not known to be a very wealthy
>     individual or well connected with sources of institutional financing.
>  2. when i discovered the startling startcom Chinese connection in
>     2016.JAN and asked startcom what was going on, after a long hiatus
>     and several info requests i received what was apparently a
>     "canned" response (in re: 'Qihoo" since i never made reference to
>     "hosting service" or other network security/service offerings such
>     as might come from Qihoo's stable of products). moreover, the
>     somewhat fractured English was not up to the standard always
>     displayed by startcom in previous correspondence:
>     via: 	183.37.145.226 (no rDNS) registered as follows:
>     netname: 	CHINANET-GD
>     descr: 	CHINANET Guangdong province network
>     descr: 	Data Communication Division
>     descr: 	China Telecom
>     country: 	CN
>
>     /L//ike every big company (IBM, Cisco, Oracle, Microsoft etc.)
>     that has set up branch offices and R&D centers in China, StartCom
>     is the No. 6 biggest CA in the world and today has also setup
>     branch office and R&D center in China///^*1* /, our Chinese R&D
>     team chose Qihoo 360 ^*4*   to provide secure hosting service
>     since this company is the No.1 Antivirus and web security provider
>     in China and in the world that public listed in NYSE///^*5* /.///
>     /
>     /
>     //
>     /We are always trying to improve and try support continued growth
>     which isn't always easy to sustain. With that we hope to provide
>     you and all our customers a useful service.//
>     /
>     //
>     /-- Best regards, Ms. Yael Luft,CVO StartCom Ltd./
>     //
>  3. Certificate Authority (CA) auditors must certify to several
>     different standards (some of which are country-specific) and the
>     most prominent of such are:
>       * European Telecommunications Standards Institute (*ETSI; *most
>         specifically 'TS 102 042'; originally EU-centric and now
>         recognized in c. a third of all nations and all of the OECD);
>       * Internet Engineering Task Force (*IETF*; most specific
>         policy-wise (CP/CPS) 'RFC 3647'; founded by the US and now an
>         independent voluntary standards setter);
>       * Webtrust Organization (*WEBTRUST*; principally 'WebTrust
>         Principles and Criteria for Certification Authorities ? SSL
>         Baseline with Network Security ? Version 2.0'; a network
>         security consortium of commercial firms, CPA's, engineers,
>         other standards setters ...);
>       * American Institute of Certified Public Accountants (*AICPA*;
>         various practice and audit guidelines for businesses,
>         non-profits, and governments promulgated through standards
>         boards and US Federal and State regulations; an US accountancy
>         professional standards-setting, certifier of individuals to
>         practice, and continuing education organization);
>       * National Institute of Science and Technology (*NIST*; issues
>         various publications establishing acceptable modes of
>         operation of public and private entities; the lead US agency
>         for standards issuance in concordance and co-operation with
>         many other Departments and agencies of the US government);
>
>  4. Qihoo 360 is -- like all PRC ISP's, hosting providers,
>     hard-/soft-ware vendors, ASN operators, et cetera -- permitted to
>     exist while being continuously monitored by the PRC National
>     Defense Council which is a second-tier security agency just below
>     the PRC military high command. Not only are these permitted firms
>     monitored, but their numbers are severely restricted to make that
>     monitoring more easily accomplished. moreover, any products of
>     such PRC businesses have to be suspect given their government's
>     penchant for intrusive and paramount control of any internal
>     business process. of course, the PRC's raids on foreign business
>     and government systems should make anyone shrink from any security
>     association with any company on mainland china and that includes
>     Hong Kong. Qihoo is addressed herein solely because it seems as if
>     there is a Wang business relationship and concomitant risk exposure.
>  5. pursuant to a privatization agreement back in 2015,  Qihoo 360
>     Technology Co. Ltd. ("Qihoo 360",  a Cayman Islands company) went
>     out of existence and its NYSE QIHU ADR's (AKA: ADS's) were
>     permanently suspended from trading on 2016.JUL.15. although the
>     2015 announcement mentioned some minority financing of the
>     transaction by PRC-controlled subsidiaries of international
>     (foreign) banks, the actual finalized financing and even the
>     actual ownership of the privatized entity are still totally
>     unknown. since Qihoo was originally allowed to thrive within PRC
>     through the PRC military giving them a virtual monopoly on many
>     networking services (which they mostly still enjoy), it is not a
>     stretch to assume that the military now possesses a directly
>     vested interest together with the enhanced control such an
>     interest cloaked in secrecy would represent.
>
> On 2016.Oct.25 15:54, Salz, Rich wrote:
>>> StartCom has directions on their website. I don't recall what the process is,
>>> but I've used it in the past. You might want to review the instructions
>>> StartCom provides.
>> StartCom, owned by WoSign, has issues with firefox.
>>   
>>> Let's Encrypt is new and has become very popular. I don't know the process
>>> because I have never used them. They will likely suffer more "unable to get
>>> local issuer certificate" problems than StartCom, especially on older mobile
>>> devices.
>> Should not be an issue, since LE has a cross-signed CA cert with someone that is in the trust stores.
>
>
>



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  Fri Oct 28 08:31:27 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 28 Oct 2016 10:31:27 +0200
Subject: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL
 client
In-Reply-To: <90f95a90-34ad-2cd2-28fb-c54af179396c@openssl.org>
References: <39EC7181F50D02449CC431A407F5684B526C933E@NTDEMKEXCH.dataenter.co.at>
 <90f95a90-34ad-2cd2-28fb-c54af179396c@openssl.org>
Message-ID: <9dc1081b-09b8-9d47-85a1-edcb63f0b80e@wisemo.com>

On 27/10/2016 00:48, Matt Caswell wrote:
> On 26/10/16 21:06, Michael Kocum wrote:
>> 1.1.0b fails to negotiate from an old program that uses OpenSSL.
>> The same old program can connect to 1.0.2h without any problem.
>>
>> Here is the debug log of the server. Maybe someone can point me in the right direction what the problem might be.
>>
>> openssl s_server -debug -state -bugs -serverpref -tlsextdebug -accept 25 -cert selfsigned.pem
>> Using default temp DH parameters
>> ACCEPT
>> SSL_accept:before SSL initialization
>> read from 0x14fffe0 [0x1509b53] (5 bytes => 5 (0x5))
>> 0000 - 80 c8 01 03 01                                    .....
>> read from 0x14fffe0 [0x1509b58] (197 bytes => 197 (0xC5))
>> 0000 - 00 9f 00 00 00 20 00 c0-14 00 c0 0a 00 00 39 00   ..... ........9.
>> 0010 - 00 38 00 c0 0f 00 c0 05-00 00 35 00 00 88 00 00   .8........5.....
>> 0020 - 87 00 00 84 00 c0 12 00-c0 08 00 00 16 00 00 13   ................
>> 0030 - 00 c0 0d 00 c0 03 00 00-0a 07 00 c0 00 c0 13 00   ................
>> 0040 - c0 09 00 00 33 00 00 32-00 c0 0e 00 c0 04 00 00   ....3..2........
>> 0050 - 2f 00 00 9a 00 00 99 00-00 45 00 00 44 00 00 96   /........E..D...
>> 0060 - 00 00 41 00 00 07 05 00-80 03 00 80 00 c0 11 00   ..A.............
>> 0070 - c0 07 00 c0 0c 00 c0 02-00 00 05 00 00 04 01 00   ................
>> 0080 - 80 00 00 15 00 00 12 00-00 09 06 00 40 00 00 14   ............ at ...
>> 0090 - 00 00 11 00 00 08 00 00-06 04 00 80 00 00 03 02   ................
>> 00a0 - 00 80 00 00 ff 30 16 85-97 e0 9f e3 aa b1 07 47   .....0.........G
>> 00b0 - 99 a5 7c 38 20 cd 51 39-a1 14 2f 60 50 87 26 62   ..|8 .Q9../`P.&b
>> 00c0 - 0e c8 73 53 86                                    ..sS.
> The above indicates that the client has sent an SSLv2 Compatible
> ClientHello, although has indicated support for TLSv1.0. OpenSSL 1.1.0
> doesn't support SSLv2, but it *does* still support the (very old) SSLv2
> Compat ClientHello format. Unfortunately an SSLv2 compat hello does
> *not* have an extensions section, which is important for communicating
> info such as supported curves etc when using EC based ciphersuites.
>
>
>> SSL_accept:before SSL initialization
>> SSL_accept:SSLv3/TLS read client hello
>> SSL_accept:SSLv3/TLS write server hello
>> SSL_accept:SSLv3/TLS write certificate
>> SSL_accept:SSLv3/TLS write key exchange
>> write to 0x14fffe0 [0x1512d58] (1281 bytes => 1281 (0x501))
>> 0000 - 16 03 01 00 51 02 00 00-4d 03 01 2c 21 40 97 a5   ....Q...M..,!@..
>> 0010 - 67 b2 a4 a7 63 cc f0 58-af 24 a4 ca 61 d8 fa bf   g...c..X.$..a...
>> 0020 - a8 50 84 29 20 54 70 1e-f5 8e c2 20 bf ad ba d7   .P.) Tp.... ....
>> 0030 - fa 23 5b 77 eb 0f 30 a2-49 61 f9 ca 9f 28 3f 14   .#[w..0.Ia...(?.
>> 0040 - bb d7 cd cf 5c 1b 69 d8-6b db 0e f7 c0 14 00 00   ....\.i.k.......
>> 0050 - 05 ff 01 00 01 00
> This is the ServerHello that the server is sending back to the client.
> The "c0 14" near the end of line 0040 indicates that the server has
> selected TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as the ciphersuite.
>
>
>>                           16 03-01 03 6e 0b 00 03 6a 00   ..........n...j.
>> 0060 - 03 67 00 03 64 30 82 03-60 30 82 02 48 02 09 00   .g..d0..`0..H...
> ...snip...lots of uninteresting lines
>
> This is Certificate message sent from server to client.
>
>
>>                                    16 03 01 01 2a 0c 00   .8...........*..
>> 03d0 - 01 26 03 00 1d 20 4f b4-34 86 a8 a0 0a 45 5b 80   .&... O.4....E[.
>> 03e0 - b0 79 9e bf 4b 91 ed ae-2c b7 ee 64 ff 39 78 c8   .y..K...,..d.9x.
>> 03f0 - a0 e7 37 e6 a5 13 01 00-1a 9f 48 8e 91 73 55 3e   ..7.......H..sU>
>> 0400 - 86 16 04 7e a9 b2 49 16-d6 f6 b3 c2 17 d1 4e 11   ...~..I.......N.
>> 0410 - c4 67 7c 81 e6 49 a2 04-d7 bc 42 04 8c 2a 0f da   .g|..I....B..*..
>> 0420 - a0 75 7d 80 98 5b 1a 0f-e2 48 55 06 95 38 0d a6   .u}..[...HU..8..
>> 0430 - 84 f0 42 37 6b ee ca e9-e5 7e 13 11 d7 f9 3e f4   ..B7k....~....>.
>> 0440 - b2 ae f1 01 e6 56 ab 7b-46 3b bd 66 de aa ad d7   .....V.{F;.f....
>> 0450 - 41 59 2b 80 2d 76 98 a0-82 c8 d1 00 05 e8 11 da   AY+.-v..........
>> 0460 - c3 4b c5 15 23 c0 ba 66-8c 9b fc 80 33 c4 e8 f9   .K..#..f....3...
>> 0470 - 1f c7 82 ba b1 58 0c 87-54 42 b4 ce ed 66 4e 4e   .....X..TB...fNN
>> 0480 - 3e 51 d4 9f 5f 1e 20 18-b1 5e 6a b9 bb e7 6c b2   >Q.._. ..^j...l.
>> 0490 - 2d 27 52 90 70 9f b0 97-cb 6d 23 0b 9d 1c e6 9d   -'R.p....m#.....
>> 04a0 - 71 2a ab 9b a9 42 c9 16-ce a1 86 63 96 fe b2 b6   q*...B.....c....
>> 04b0 - 49 69 5c 80 7b 9d 3d 40-a8 4a 70 51 0a a1 99 a8   Ii\.{.=@.JpQ....
>> 04c0 - b8 72 52 39 6b 8c c6 91-13 36 fb d5 fe 7d 2b db   .rR9k....6...}+.
>> 04d0 - 45 3d 73 d9 be de fd 40-19 ed ec 41 84 d5 17 a7   E=s.... at ...A....
>> 04e0 - 6e 32 05 51 5b e6 56 44-40 2b e8 54 d9 36 cc bb   n2.Q[.VD at +.T.6..
>> 04f0 - 77 17 cd f3 7c e7 00 60-
> This is the ServerKeyExchange
>
> The "00 1d" on line 03d0 tells you the curve that the server has
> selected. That corresponds to Curve 25519!!!! This is a modern curve
> which an old client will not understand. The server has selected it
> because it didn't get an extension from the client saying what curves it
> supports, so it just picked one.
>
> This is very likely to be your problem. To test the theory, try adding
> "-named_curve P-256" onto your s_server line. P-256 is a much more
> widely supported curve.
>
> Matt
Would it make sense for OpenSSL 1.1.0c to use a more conservative
list of presumed supported curves when the other side does not
provide a list.  More generally, I have found that it is often
useful to heuristically adjust server side negotiation options
based on clues found in the initial handshake messages.  For
instance, using weaker EDH keys when the request matches the
particulars of some specific old SSL clients, or using a SHA-256
server certificate only if the client seems able to handle that.

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 surendar at datrium.com  Fri Oct 28 08:53:13 2016
From: surendar at datrium.com (Surendar Chandra)
Date: Fri, 28 Oct 2016 01:53:13 -0700
Subject: [openssl-users] EVP_aes_256_wrap() in FIPS-140 mode?
Message-ID: <38161AE8-F952-45A6-B707-35006365909C@datrium.com>

I cannot seem to use EVP_aes_256_wrap() in FIPS mode. I saw some earlier discussions on using low level APIs; but I am using the EVP method. Is it supported? I am using 1.0.2h/2.0.12.

Thanks much
-S

From rsalz at akamai.com  Fri Oct 28 11:05:38 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 28 Oct 2016 11:05:38 +0000
Subject: [openssl-users] 1.1.0b fails to negotiate with an old OpenSSL
 client
In-Reply-To: <9dc1081b-09b8-9d47-85a1-edcb63f0b80e@wisemo.com>
References: <39EC7181F50D02449CC431A407F5684B526C933E@NTDEMKEXCH.dataenter.co.at>
 <90f95a90-34ad-2cd2-28fb-c54af179396c@openssl.org>
 <9dc1081b-09b8-9d47-85a1-edcb63f0b80e@wisemo.com>
Message-ID: <543fc51134214a09b12a6a2d92b23906@usma1ex-dag1mb1.msg.corp.akamai.com>


> More generally, I have found that it is often useful to heuristically adjust
> server side negotiation options based on clues found in the initial handshake

YES!

See https://github.com/openssl/openssl/pull/1597


From Lander at fit.be  Fri Oct 28 11:31:44 2016
From: Lander at fit.be (Lander Bulckaen)
Date: Fri, 28 Oct 2016 11:31:44 +0000
Subject: [openssl-users] Help
In-Reply-To: <CADqLbzLbVCP0c7uLDRO4H++=h9gJ+Ewur3TH-Pc-qc=Hr9hQAA@mail.gmail.com>
References: <1BF0BB099673884291E8E8CB1C42CAFD033C662519@FITSERV01.fit.local>
 <CADqLbzLbVCP0c7uLDRO4H++=h9gJ+Ewur3TH-Pc-qc=Hr9hQAA@mail.gmail.com>
Message-ID: <1BF0BB099673884291E8E8CB1C42CAFD033C662ACC@FITSERV01.fit.local>

Dear Dmitry,



The result must be as mentionned below?



Van: openssl-users [mailto:openssl-users-bounces at openssl.org] Namens Dmitry Belyavsky
Verzonden: donderdag 27 oktober 2016 19:09
Aan: openssl-users at openssl.org
Onderwerp: Re: [openssl-users] Help



Hello

You should use the XMLSec library and the corresponding command-line tool.



On Thu, Oct 27, 2016 at 5:05 PM, Lander Bulckaen <Lander at fit.be<mailto:Lander at fit.be>> wrote:

   Hy,



   Goal: add an xml file as attachment to a MIME message and sign the MIME message with the primary key (.p12 file).



   The result must be like what you see below??



   Which openssl commands must I use in commandline?

   (I already searched for ita bout 2 months but still not found any solution?!)



   Date: Fri Jul 01 10:26:15 CEST 2016

   From: michel.dombret at nbb.be<mailto:michel.dombret at nbb.be>

   To:

   Message-ID: <28456974.01467361575985.JavaMail.feronan at PC0020881<mailto:28456974.01467361575985.JavaMail.feronan at PC0020881>>

   Subject: NBB signed file

   MIME-Version: 1.0

   Content-Type: multipart/signed;

                   boundary="----=_Part_1_6142443.1467361575963";

                   protocol="application/pkcs7-signature"; micalg=sha1



   ------=_Part_1_6142443.1467361575963

   Content-Type: multipart/mixed;

                   boundary="----=_Part_0_25389802.1467361575861"



   ------=_Part_0_25389802.1467361575861

   Content-Type: text/plain; charset=us-ascii

   Content-Transfer-Encoding: 7bit



   Message created by Offline Signing Tool of National bank of BELGIUM

   ------=_Part_0_25389802.1467361575861

   Content-Type: application/octet-stream; name=RequestFeedbacks.xml

   Content-Transfer-Encoding: 7bit

   Content-Disposition: attachment; filename=RequestFeedbacks.xml



   <?xml version="1.0" encoding="UTF-8"?>

   <Request>

               <Version>V01</Version>

               <Criteria>

               <DocDate>

                           <From>2016-08-01</From>

                           <To>2016-08-15</To>

               </DocDate>

               <DocType>ALL</DocType>

               <UnrequestedDocOnly>true</UnrequestedDocOnly>

               </Criteria>

   </Request>



   ------=_Part_0_25389802.1467361575861--



   ------=_Part_1_6142443.1467361575963

   Content-Type: application/pkcs7-signature; name=smime.p7s

   Content-Transfer-Encoding: base64

   Content-Disposition: attachment; filename=smime.p7s



   MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBXMw

   ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1

   c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp

   dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3Vy

   ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0wNzA0MDMxMzE2MDRa

   Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV

   BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xCzAJBgNVBAsT

   AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkBFhNwcjAzaGtldHRp

   bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXENutQ5VnJDP0Q1waji

   85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b6d/ErcVBweBORvRo

   MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+pEkCdxM3ELZRZM6Rp

   7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/1sOuga0jf80sNpuQm9hysHRG

   fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUmwCKhbgEYjnIxQ

   71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G

   X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvVMB4GA1UdEQQXMBWB

   E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr

   BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+ADCcE5+oIz0Kts4f

   OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI+UU2QiyaUfXSMvuLct3yZX0Pc6+

   8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+762HW04TNhgQUUkMaEn/T

   HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNWSt8NsEmba/7ZD3

   XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+89MT56qfrDbfiJtRvICWXTYBh0tdki

   057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+2TyF

   BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjSlXkk0yvnF6

   vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+CzeSpmDJNtKnU/nm

   ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjoNICBKYO

   VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJKoZI

   hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1

   c3NlbHMxITAfBgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBT

   ZWN1cml0eSBNYW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZI

   hvcNAQkBFg1kc21vcHNAbmJiLmJlMB4XDTA1MDUyMzA4NDkzMFoXDTI1MDUxODA4NDkzMFowgbUx

   CzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAfBgNV

   BAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBNYW5h

   Z2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1kc21v

   cHNAbmJiLmJlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt+wnMwqwqr8q7m20/ly+

   HZl7RznDuxKX1muAdmFxwm+LXTQtvNbwEom8xmpwLAy0tn+P+RKElWRTc06z8sqisHL282hULh/G

   Otufmf6eQOzW3UsX6xZWa1Un9Y0BwLncm+CmNFYTcmhNUkr6PT1Lzu277BiiBrjxqs22jEd0ibOs

   vKlv0xXGh0qXRcltd0IEpcPneod0L/HCsm65d9fuS584LShsBbPcaVO4Zg5N8Zi9+lAslkxsgDen

   txvM+ZZuhtS6vAAUKOq6IgPa9Mgih2wrWOtrPRyj7aUHalODBbgAzHz0enNszVhGM0sw4fcETkDQ

   AysOpFnClGcKk2FhdNb9Z3uCw80YZrd3NAGCfnYWR/SL0Flq6T+2BOur/gRDrL++NeDiJ38JUyK+

   nMcBuieECYYFusaYUDSEzUHe2KIBfdd1Y2cvi6+sINCt+0939Naw+ZNITy6iOkUdXLgGdvS1YVa3

   SEbmV9tIdTJhb2stp0prgUPMc5XOq3KGaKpKuqnos1XCfHc6JTE2l7OQc9PHnk7dsHBIvvHLQt3A

   Z+XIj6pd70qtKKU/BsFk8fv09UAw6jWFTIdz9Msz6h1ieFstA4I3bzYLFwALirTFuR1SRH/9xl3s

   6nUs78jJ5/ANE0HV3AiSMCJ2TvHfzDSZ1Efm+H5oTCn4vmvlPBEXnEMCAwEAAaOCAUswggFHMB0G

   A1UdDgQWBBS4kquLf8ZfvlLTQZ8suRukZcYlRTAYBgNVHREEETAPgQ1kc21vcHNAbmJiLmJlMA8G

   A1UdEwEB/wQFMAMBAf8wgeoGA1UdIwSB4jCB34AUuJKri3/GX75S00GfLLkbpGXGJUWhgbukgbgw

   gbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAf

   BgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBN

   YW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1k

   c21vcHNAbmJiLmJlggkAklGjqlmMoxgwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IC

   AQA2hzYYNkQW3bJBy00n3ZegqggLA3IplHr/NhQZ6ppvOu+E4K993/1UNsv2hGIto1te3AD6AwUk

   A1jstQi42e9WtG0c29gST7+AtAsn3clzRWnNXzIMaeTz+k0XNk6YdiiERNBShn5o8sUeiYxmWJQ6

   ovicqBsBVkdknwifwa0CRG7kz6dMy7BWOY2mt8qFh6yIbhTox3HFVE2cdbs3k6cr9eOUv6xbkoCo

   GcUWzu90Gqbpyny95ix/ZLiauCs8nGXwbbICo1CG2xZ7TJMfCAU1J55eYAaSmDkV843Q4Jr1cyPm

   VPWhQDfWzA1bTsAB8Q4pwKVjq28jhDJZtKSS0FblgC96kMxlwajCSyzykhrsaVdwCaU++1KrwPDB

   Y5VtZhyn55Cpgs/3gQ8L4BskrLdRpdVDvO4ER35gvAaQTRP8NwOzepGico34VpVa1prz+ZB+CvvM

   KYN85i2jzFdvS2yag3jaCC+t2Xp0GKL2ZmF7oWDKkiWXwYjWJ/XiTZ3AdsBJPDvmOYxAuUeH/ADm

   WRoNHCwaUbNr0vxEXLZam8bFyXe0TohiRGczUfSgQDzuAbAjKE2HQSeObI0w1ZWxzmvS1+xo/HDn

   pZBd60fHaH/QpBwp0JnBxouRt/daxB0MuckGaEBx3qn925Ac5pzM+6K1N1uKF3mTxiM4Ocd9nWpM

   1TGCApgwggKUAgEBMIG8MIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV

   BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xITAfBgNVBAsT

   GERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3VyZSBFbWFpbCBDQTEc

   MBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZQICAKgwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B

   CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDEwODI2MTVaMCMGCSqGSIb3DQEJ

   BDEWBBRs4Ik9waWLNU/4OZ9TfT4yZZ0EljBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G

   CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzANBgkq

   hkiG9w0BAQEFAASCAQCSP5/h1v6feRr+ekK19tlI4zvm1Wy7hUtN+XmbWLJHOxSU4wJUBRj6ptph

   Mb7AOm1JYy8+wWRQhgOcIegD74eXZoYfws+O3ADZ//feXYJAF/jqAyhs0r9CoGw2eUUeZR4KYILy

   ZG5I3lcFJLDPHcElSe3NgRBOmfuFWD/mSLE2B2S+PqbnbugYPSN7mCSOqMZODPBlop9wczBUD1BI

   K+kM1fP28541RfCFS6tGUXamWnKOdbxoHbPmnQDT1zzcbRIUvnLCV6MZ4KFNAXf5YxwggV3jjPiQ

   vyzr8EdFzmaWpoOFEtCLmQw4hpSEPJO8yGxQ5/29MWg6Ypy62bjMfs54AAAAAAAA

   ------=_Part_1_6142443.1467361575963--


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







   --

   SY, Dmitry Belyavsky

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

From beldmit at gmail.com  Fri Oct 28 12:51:50 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Fri, 28 Oct 2016 15:51:50 +0300
Subject: [openssl-users] Help
In-Reply-To: <1BF0BB099673884291E8E8CB1C42CAFD033C662ACC@FITSERV01.fit.local>
References: <1BF0BB099673884291E8E8CB1C42CAFD033C662519@FITSERV01.fit.local>
 <CADqLbzLbVCP0c7uLDRO4H++=h9gJ+Ewur3TH-Pc-qc=Hr9hQAA@mail.gmail.com>
 <1BF0BB099673884291E8E8CB1C42CAFD033C662ACC@FITSERV01.fit.local>
Message-ID: <CADqLbz+thdxt4-qWBxDQ60ppr16cu5BvRDL3Ew8-2-dMVG79_g@mail.gmail.com>

Sorry, my fault.

I think you should use the openssl smime command, but it doesn't work with
PKCS12, so you will have to extract the private and public keys using the
openssl pkcs12 command.

28 ???. 2016 ?. 2:34 PM ???????????? "Lander Bulckaen" <Lander at fit.be>
???????:

> Dear Dmitry,
>
>
>
> The result must be as mentionned below?
>
>
>
> *Van:* openssl-users [mailto:openssl-users-bounces at openssl.org] *Namens *Dmitry
> Belyavsky
> *Verzonden:* donderdag 27 oktober 2016 19:09
> *Aan:* openssl-users at openssl.org
> *Onderwerp:* Re: [openssl-users] Help
>
>
>
> Hello
>
> You should use the XMLSec library and the corresponding command-line tool.
>
>
>
> On Thu, Oct 27, 2016 at 5:05 PM, Lander Bulckaen <Lander at fit.be> wrote:
>
> Hy,
>
>
>
> Goal: add an xml file as attachment to a MIME message and *sign the MIME
> message* with the primary key (.p12 file).
>
>
>
> The result must be like what you see below??
>
>
>
> Which openssl commands must I use in commandline?
>
> (I already searched for ita bout 2 months but still not found any
> solution?!)
>
>
>
> Date: Fri Jul 01 10:26:15 CEST 2016
>
> From: michel.dombret at nbb.be
>
> To:
>
> Message-ID: <28456974.01467361575985.JavaMail.feronan at PC0020881>
>
> Subject: NBB signed file
>
> MIME-Version: 1.0
>
> Content-Type: multipart/signed;
>
>                 boundary="----=_Part_1_6142443.1467361575963";
>
>                 protocol="application/pkcs7-signature"; micalg=sha1
>
>
>
> ------=_Part_1_6142443.1467361575963
>
> Content-Type: multipart/mixed;
>
>                 boundary="----=_Part_0_25389802.1467361575861"
>
>
>
> ------=_Part_0_25389802.1467361575861
>
> Content-Type: text/plain; charset=us-ascii
>
> Content-Transfer-Encoding: 7bit
>
>
>
> Message created by Offline Signing Tool of National bank of BELGIUM
>
> ------=_Part_0_25389802.1467361575861
>
> Content-Type: application/octet-stream; name=RequestFeedbacks.xml
>
> Content-Transfer-Encoding: 7bit
>
> Content-Disposition: attachment; filename=RequestFeedbacks.xml
>
>
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <Request>
>
>             <Version>V01</Version>
>
>             <Criteria>
>
>             <DocDate>
>
>                         <From>2016-08-01</From>
>
>                         <To>2016-08-15</To>
>
>             </DocDate>
>
>             <DocType>ALL</DocType>
>
>             <UnrequestedDocOnly>true</UnrequestedDocOnly>
>
>             </Criteria>
>
> </Request>
>
>
>
> ------=_Part_0_25389802.1467361575861--
>
>
>
> ------=_Part_1_6142443.1467361575963
>
> Content-Type: application/pkcs7-signature; name=smime.p7s
>
> Content-Transfer-Encoding: base64
>
> Content-Disposition: attachment; filename=smime.p7s
>
>
>
> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEH
> AQAAoIIMtzCCBXMw
>
> ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTER
> MA8GA1UECBMIQnJ1
>
> c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBC
> YW5rIG9mIEJlbGdp
>
> dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UE
> AxMTTkJCIFNlY3Vy
>
> ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0w
> NzA0MDMxMzE2MDRa
>
> Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
> c3NlbHMxETAPBgNV
>
> BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
> dW0xCzAJBgNVBAsT
>
> AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkB
> FhNwcjAzaGtldHRp
>
> bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXEN
> utQ5VnJDP0Q1waji
>
> 85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b
> 6d/ErcVBweBORvRo
>
> MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+
> pEkCdxM3ELZRZM6Rp
>
> 7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/
> 1sOuga0jf80sNpuQm9hysHRG
>
> fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUm
> wCKhbgEYjnIxQ
>
> 71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/
> wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G
>
> X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvV
> MB4GA1UdEQQXMBWB
>
> E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQG
> CCsGAQUFBwMCBggr
>
> BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+
> ADCcE5+oIz0Kts4f
>
> OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI
> +UU2QiyaUfXSMvuLct3yZX0Pc6+
>
> 8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+
> 762HW04TNhgQUUkMaEn/T
>
> HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNW
> St8NsEmba/7ZD3
>
> XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+
> 89MT56qfrDbfiJtRvICWXTYBh0tdki
>
> 057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+
> 2TyF
>
> BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjS
> lXkk0yvnF6
>
> vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+
> CzeSpmDJNtKnU/nm
>
> ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjo
> NICBKYO
>
> VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJ
> KoZI
>
> hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczER
> MA8GA1UEBxMIQnJ1
>
> c3NlbHMxITAfBgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8G
> A1UECxMYRGF0YSBT
>
> ZWN1cml0eSBNYW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWls
> IENBMRwwGgYJKoZI
>
> hvcNAQkBFg1kc21vcHNAbmJiLmJlMB4XDTA1MDUyMzA4NDkzMFoXDTI1MDUx
> ODA4NDkzMFowgbUx
>
> CzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1
> c3NlbHMxITAfBgNV
>
> BAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBT
> ZWN1cml0eSBNYW5h
>
> Z2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZI
> hvcNAQkBFg1kc21v
>
> cHNAbmJiLmJlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt+
> wnMwqwqr8q7m20/ly+
>
> HZl7RznDuxKX1muAdmFxwm+LXTQtvNbwEom8xmpwLAy0tn+P+
> RKElWRTc06z8sqisHL282hULh/G
>
> Otufmf6eQOzW3UsX6xZWa1Un9Y0BwLncm+CmNFYTcmhNUkr6PT1Lzu277BiiBrjx
> qs22jEd0ibOs
>
> vKlv0xXGh0qXRcltd0IEpcPneod0L/HCsm65d9fuS584LShsBbPcaVO4Zg5N
> 8Zi9+lAslkxsgDen
>
> txvM+ZZuhtS6vAAUKOq6IgPa9Mgih2wrWOtrPRyj7aUHalODBbgAzHz0enNszVhGM
> 0sw4fcETkDQ
>
> AysOpFnClGcKk2FhdNb9Z3uCw80YZrd3NAGCfnYWR/SL0Flq6T+2BOur/
> gRDrL++NeDiJ38JUyK+
>
> nMcBuieECYYFusaYUDSEzUHe2KIBfdd1Y2cvi6+sINCt+0939Naw+
> ZNITy6iOkUdXLgGdvS1YVa3
>
> SEbmV9tIdTJhb2stp0prgUPMc5XOq3KGaKpKuqnos1XCfHc6JTE2l7OQc9PH
> nk7dsHBIvvHLQt3A
>
> Z+XIj6pd70qtKKU/BsFk8fv09UAw6jWFTIdz9Msz6h1ieF
> stA4I3bzYLFwALirTFuR1SRH/9xl3s
>
> 6nUs78jJ5/ANE0HV3AiSMCJ2TvHfzDSZ1Efm+H5oTCn4vmvlPBEXnEMCAwEAAaOCAUs
> wggFHMB0G
>
> A1UdDgQWBBS4kquLf8ZfvlLTQZ8suRukZcYlRTAYBgNVHREEETAPgQ1kc21v
> cHNAbmJiLmJlMA8G
>
> A1UdEwEB/wQFMAMBAf8wgeoGA1UdIwSB4jCB34AUuJKri3/
> GX75S00GfLLkbpGXGJUWhgbukgbgw
>
> gbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMI
> QnJ1c3NlbHMxITAf
>
> BgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0
> YSBTZWN1cml0eSBN
>
> YW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJ
> KoZIhvcNAQkBFg1k
>
> c21vcHNAbmJiLmJlggkAklGjqlmMoxgwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4
> IC
>
> AQA2hzYYNkQW3bJBy00n3ZegqggLA3IplHr/NhQZ6ppvOu+E4K993/
> 1UNsv2hGIto1te3AD6AwUk
>
> A1jstQi42e9WtG0c29gST7+AtAsn3clzRWnNXzIMaeTz+
> k0XNk6YdiiERNBShn5o8sUeiYxmWJQ6
>
> ovicqBsBVkdknwifwa0CRG7kz6dMy7BWOY2mt8qFh6yIbhTox3HFVE2cdbs3
> k6cr9eOUv6xbkoCo
>
> GcUWzu90Gqbpyny95ix/ZLiauCs8nGXwbbICo1CG2xZ7TJMfCA
> U1J55eYAaSmDkV843Q4Jr1cyPm
>
> VPWhQDfWzA1bTsAB8Q4pwKVjq28jhDJZtKSS0FblgC96kMxlwajCSyzykhrs
> aVdwCaU++1KrwPDB
>
> Y5VtZhyn55Cpgs/3gQ8L4BskrLdRpdVDvO4ER35gvAaQTRP8NwOzepGico34VpVa1prz+ZB+
> CvvM
>
> KYN85i2jzFdvS2yag3jaCC+t2Xp0GKL2ZmF7oWDKkiWXwYjWJ/
> XiTZ3AdsBJPDvmOYxAuUeH/ADm
>
> WRoNHCwaUbNr0vxEXLZam8bFyXe0TohiRGczUfSgQDzuAbAjKE2HQSeObI0w
> 1ZWxzmvS1+xo/HDn
>
> pZBd60fHaH/QpBwp0JnBxouRt/daxB0MuckGaEBx3qn925Ac5pzM+
> 6K1N1uKF3mTxiM4Ocd9nWpM
>
> 1TGCApgwggKUAgEBMIG8MIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
> c3NlbHMxETAPBgNV
>
> BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
> dW0xITAfBgNVBAsT
>
> GERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3Vy
> ZSBFbWFpbCBDQTEc
>
> MBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZQICAKgwCQYFKw4DAhoFAKCB
> sTAYBgkqhkiG9w0B
>
> CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDEwODI2MTVa
> MCMGCSqGSIb3DQEJ
>
> BDEWBBRs4Ik9waWLNU/4OZ9TfT4yZZ0EljBSBgkqhkiG9w0BC
> Q8xRTBDMAoGCCqGSIb3DQMHMA4G
>
> CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAH
> BgUrDgMCBzANBgkq
>
> hkiG9w0BAQEFAASCAQCSP5/h1v6feRr+ekK19tlI4zvm1Wy7hUtN+
> XmbWLJHOxSU4wJUBRj6ptph
>
> Mb7AOm1JYy8+wWRQhgOcIegD74eXZoYfws+O3ADZ//feXYJAF/
> jqAyhs0r9CoGw2eUUeZR4KYILy
>
> ZG5I3lcFJLDPHcElSe3NgRBOmfuFWD/mSLE2B2S+PqbnbugYPSN7mCSOqMZODPBlop9wcz
> BUD1BI
>
> K+kM1fP28541RfCFS6tGUXamWnKOdbxoHbPmnQDT1zzcbRIUvnLCV6MZ4KFNAX
> f5YxwggV3jjPiQ
>
> vyzr8EdFzmaWpoOFEtCLmQw4hpSEPJO8yGxQ5/29MWg6Ypy62bjMfs54AAAAAAAA
>
> ------=_Part_1_6142443.1467361575963--
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>
>
> --
>
> SY, Dmitry Belyavsky
>
> --
> 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/20161028/65a7794a/attachment-0001.html>

From Lander at fit.be  Fri Oct 28 12:55:43 2016
From: Lander at fit.be (Lander Bulckaen)
Date: Fri, 28 Oct 2016 12:55:43 +0000
Subject: [openssl-users] Help
In-Reply-To: <CADqLbz+thdxt4-qWBxDQ60ppr16cu5BvRDL3Ew8-2-dMVG79_g@mail.gmail.com>
References: <1BF0BB099673884291E8E8CB1C42CAFD033C662519@FITSERV01.fit.local>
 <CADqLbzLbVCP0c7uLDRO4H++=h9gJ+Ewur3TH-Pc-qc=Hr9hQAA@mail.gmail.com>
 <1BF0BB099673884291E8E8CB1C42CAFD033C662ACC@FITSERV01.fit.local>
 <CADqLbz+thdxt4-qWBxDQ60ppr16cu5BvRDL3Ew8-2-dMVG79_g@mail.gmail.com>
Message-ID: <1BF0BB099673884291E8E8CB1C42CAFD033C662BEB@FITSERV01.fit.local>

Dear,

Yes I know.

I already extracted both keys from the .p12 file.

My biggest problem is how you can add the original file (in this case ?RequestFeedbacks.xml?) as attachment? (the signature ?smime.p7s? is already attached)

Thanks for you quick reply and support!

Kind regards,
Lander

Van: openssl-users [mailto:openssl-users-bounces at openssl.org] Namens Dmitry Belyavsky
Verzonden: vrijdag 28 oktober 2016 14:52
Aan: openssl-users at openssl.org
Onderwerp: Re: [openssl-users] Help


Sorry, my fault.

I think you should use the openssl smime command, but it doesn't work with PKCS12, so you will have to extract the private and public keys using the openssl pkcs12 command.

28 ???. 2016 ?. 2:34 PM ???????????? "Lander Bulckaen" <Lander at fit.be<mailto:Lander at fit.be>> ???????:
Dear Dmitry,

The result must be as mentionned below?

Van: openssl-users [mailto:openssl-users-bounces at openssl.org<mailto:openssl-users-bounces at openssl.org>] Namens Dmitry Belyavsky
Verzonden: donderdag 27 oktober 2016 19:09
Aan: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Onderwerp: Re: [openssl-users] Help

Hello
You should use the XMLSec library and the corresponding command-line tool.

On Thu, Oct 27, 2016 at 5:05 PM, Lander Bulckaen <Lander at fit.be<mailto:Lander at fit.be>> wrote:
Hy,

Goal: add an xml file as attachment to a MIME message and sign the MIME message with the primary key (.p12 file).

The result must be like what you see below??

Which openssl commands must I use in commandline?
(I already searched for ita bout 2 months but still not found any solution?!)

Date: Fri Jul 01 10:26:15 CEST 2016
From: michel.dombret at nbb.be<mailto:michel.dombret at nbb.be>
To:
Message-ID: <28456974.01467361575985.JavaMail.feronan at PC0020881<mailto:28456974.01467361575985.JavaMail.feronan at PC0020881>>
Subject: NBB signed file
MIME-Version: 1.0
Content-Type: multipart/signed;
                boundary="----=_Part_1_6142443.1467361575963";
                protocol="application/pkcs7-signature"; micalg=sha1

------=_Part_1_6142443.1467361575963
Content-Type: multipart/mixed;
                boundary="----=_Part_0_25389802.1467361575861"

------=_Part_0_25389802.1467361575861
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Message created by Offline Signing Tool of National bank of BELGIUM
------=_Part_0_25389802.1467361575861
Content-Type: application/octet-stream; name=RequestFeedbacks.xml
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=RequestFeedbacks.xml

<?xml version="1.0" encoding="UTF-8"?>
<Request>
            <Version>V01</Version>
            <Criteria>
            <DocDate>
                        <From>2016-08-01</From>
                        <To>2016-08-15</To>
            </DocDate>
            <DocType>ALL</DocType>
            <UnrequestedDocOnly>true</UnrequestedDocOnly>
            </Criteria>
</Request>

------=_Part_0_25389802.1467361575861--

------=_Part_1_6142443.1467361575963
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBXMw
ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3Vy
ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0wNzA0MDMxMzE2MDRa
Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV
BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xCzAJBgNVBAsT
AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkBFhNwcjAzaGtldHRp
bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXENutQ5VnJDP0Q1waji
85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b6d/ErcVBweBORvRo
MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+pEkCdxM3ELZRZM6Rp
7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/1sOuga0jf80sNpuQm9hysHRG
fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUmwCKhbgEYjnIxQ
71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G
X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvVMB4GA1UdEQQXMBWB
E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+ADCcE5+oIz0Kts4f
OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI+UU2QiyaUfXSMvuLct3yZX0Pc6+
8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+762HW04TNhgQUUkMaEn/T
HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNWSt8NsEmba/7ZD3
XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+89MT56qfrDbfiJtRvICWXTYBh0tdki
057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+2TyF
BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjSlXkk0yvnF6
vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+CzeSpmDJNtKnU/nm
ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjoNICBKYO
VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJKoZI
hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1
c3NlbHMxITAfBgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBT
ZWN1cml0eSBNYW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZI
hvcNAQkBFg1kc21vcHNAbmJiLmJlMB4XDTA1MDUyMzA4NDkzMFoXDTI1MDUxODA4NDkzMFowgbUx
CzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAfBgNV
BAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBNYW5h
Z2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1kc21v
cHNAbmJiLmJlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt+wnMwqwqr8q7m20/ly+
HZl7RznDuxKX1muAdmFxwm+LXTQtvNbwEom8xmpwLAy0tn+P+RKElWRTc06z8sqisHL282hULh/G
Otufmf6eQOzW3UsX6xZWa1Un9Y0BwLncm+CmNFYTcmhNUkr6PT1Lzu277BiiBrjxqs22jEd0ibOs
vKlv0xXGh0qXRcltd0IEpcPneod0L/HCsm65d9fuS584LShsBbPcaVO4Zg5N8Zi9+lAslkxsgDen
txvM+ZZuhtS6vAAUKOq6IgPa9Mgih2wrWOtrPRyj7aUHalODBbgAzHz0enNszVhGM0sw4fcETkDQ
AysOpFnClGcKk2FhdNb9Z3uCw80YZrd3NAGCfnYWR/SL0Flq6T+2BOur/gRDrL++NeDiJ38JUyK+
nMcBuieECYYFusaYUDSEzUHe2KIBfdd1Y2cvi6+sINCt+0939Naw+ZNITy6iOkUdXLgGdvS1YVa3
SEbmV9tIdTJhb2stp0prgUPMc5XOq3KGaKpKuqnos1XCfHc6JTE2l7OQc9PHnk7dsHBIvvHLQt3A
Z+XIj6pd70qtKKU/BsFk8fv09UAw6jWFTIdz9Msz6h1ieFstA4I3bzYLFwALirTFuR1SRH/9xl3s
6nUs78jJ5/ANE0HV3AiSMCJ2TvHfzDSZ1Efm+H5oTCn4vmvlPBEXnEMCAwEAAaOCAUswggFHMB0G
A1UdDgQWBBS4kquLf8ZfvlLTQZ8suRukZcYlRTAYBgNVHREEETAPgQ1kc21vcHNAbmJiLmJlMA8G
A1UdEwEB/wQFMAMBAf8wgeoGA1UdIwSB4jCB34AUuJKri3/GX75S00GfLLkbpGXGJUWhgbukgbgw
gbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAf
BgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBN
YW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1k
c21vcHNAbmJiLmJlggkAklGjqlmMoxgwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IC
AQA2hzYYNkQW3bJBy00n3ZegqggLA3IplHr/NhQZ6ppvOu+E4K993/1UNsv2hGIto1te3AD6AwUk
A1jstQi42e9WtG0c29gST7+AtAsn3clzRWnNXzIMaeTz+k0XNk6YdiiERNBShn5o8sUeiYxmWJQ6
ovicqBsBVkdknwifwa0CRG7kz6dMy7BWOY2mt8qFh6yIbhTox3HFVE2cdbs3k6cr9eOUv6xbkoCo
GcUWzu90Gqbpyny95ix/ZLiauCs8nGXwbbICo1CG2xZ7TJMfCAU1J55eYAaSmDkV843Q4Jr1cyPm
VPWhQDfWzA1bTsAB8Q4pwKVjq28jhDJZtKSS0FblgC96kMxlwajCSyzykhrsaVdwCaU++1KrwPDB
Y5VtZhyn55Cpgs/3gQ8L4BskrLdRpdVDvO4ER35gvAaQTRP8NwOzepGico34VpVa1prz+ZB+CvvM
KYN85i2jzFdvS2yag3jaCC+t2Xp0GKL2ZmF7oWDKkiWXwYjWJ/XiTZ3AdsBJPDvmOYxAuUeH/ADm
WRoNHCwaUbNr0vxEXLZam8bFyXe0TohiRGczUfSgQDzuAbAjKE2HQSeObI0w1ZWxzmvS1+xo/HDn
pZBd60fHaH/QpBwp0JnBxouRt/daxB0MuckGaEBx3qn925Ac5pzM+6K1N1uKF3mTxiM4Ocd9nWpM
1TGCApgwggKUAgEBMIG8MIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV
BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xITAfBgNVBAsT
GERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3VyZSBFbWFpbCBDQTEc
MBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZQICAKgwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDEwODI2MTVaMCMGCSqGSIb3DQEJ
BDEWBBRs4Ik9waWLNU/4OZ9TfT4yZZ0EljBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzANBgkq
hkiG9w0BAQEFAASCAQCSP5/h1v6feRr+ekK19tlI4zvm1Wy7hUtN+XmbWLJHOxSU4wJUBRj6ptph
Mb7AOm1JYy8+wWRQhgOcIegD74eXZoYfws+O3ADZ//feXYJAF/jqAyhs0r9CoGw2eUUeZR4KYILy
ZG5I3lcFJLDPHcElSe3NgRBOmfuFWD/mSLE2B2S+PqbnbugYPSN7mCSOqMZODPBlop9wczBUD1BI
K+kM1fP28541RfCFS6tGUXamWnKOdbxoHbPmnQDT1zzcbRIUvnLCV6MZ4KFNAXf5YxwggV3jjPiQ
vyzr8EdFzmaWpoOFEtCLmQw4hpSEPJO8yGxQ5/29MWg6Ypy62bjMfs54AAAAAAAA
------=_Part_1_6142443.1467361575963--

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



--
SY, Dmitry Belyavsky

--
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/20161028/66e0fc06/attachment-0001.html>

From hugobarretto at gmail.com  Fri Oct 28 13:10:57 2016
From: hugobarretto at gmail.com (Hugo N.Barretto)
Date: Fri, 28 Oct 2016 10:10:57 -0300
Subject: [openssl-users] Fwd: osf-contact SignatureValue
In-Reply-To: <5781ca3f6f5d4eaa8c93190bdd76045d@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAPWVoeJ4eN5Fn1tRhFGVuHRYdowVULa-ei=XVxRSHWNyWQ=tFg@mail.gmail.com>
 <5781ca3f6f5d4eaa8c93190bdd76045d@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAPWVoe+=SaY5EhVrqqM7i+zx5yVFSs7mff-HVVwjmERARcO5iw@mail.gmail.com>

---------- Forwarded message ----------
From: Salz, Rich <rsalz at akamai.com>
Date: Thu, Oct 27, 2016 at 10:27 PM
Subject: RE: osf-contact SignatureValue
To: "Hugo N.Barretto" <hugobarretto at gmail.com>, "info at opensslfoundation.org"
<info at opensslfoundation.org>


Probably more useful to ask your questions on the openssl-users mailing
list; see https://mta.openssl.org



--

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: richsalz at jabber.at Twitter: RichSalz



*From:* Hugo N.Barretto [mailto:hugobarretto at gmail.com]
*Sent:* Thursday, October 27, 2016 7:45 PM
*To:* info at opensslfoundation.org
*Subject:* osf-contact SignatureValue



Hi!. Mr/Mrs.



Please I'd like to elimnate a great doubt mine. I'm for a long time trying
urderstand how openssl works on browser, but yet i do not find out it.



I know calculate digestValue and also encrypt in base64, then i obtain my
desired result in command line inside the prompt.



Is there some way to get this value, executing this commands through do
browser? Using JavaScript for example?



If possible send to me some light that open my mind to solve this problem!!
Thankssss so much. Hugo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161028/234b29cf/attachment.html>

From graeme.perrow at sap.com  Fri Oct 28 17:16:20 2016
From: graeme.perrow at sap.com (Perrow, Graeme)
Date: Fri, 28 Oct 2016 17:16:20 +0000
Subject: [openssl-users] Cannot initialize FIPS library in 1.0.2j but 1.0.2i
	is OK
Message-ID: <3e9f9b2fe1794d2786efb5e7d50e1be3@DEWDFE13DE14.global.corp.sap>

I'm seeing a problem where my application cannot initialize the FIPS library (i.e. the call to FIPS_mode_set fails) when using 1.0.2j libraries. The error I get is: "FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232:" However if I build 1.0.2i libraries, everything is fine. I am using the same script to build both versions, and completely wiping the directories and re-creating from the .tar.gz files each time.

The weirdest thing is that if I build my application for 1.0.2i but replace 1.0.2i with the 1.0.2j code (just modifying the version number in the header files), everything works. If I build it for 1.0.2j but actually use 1.0.2i (again just changing the version number), it fails.

This is on 64-bit Linux. Other platforms (32-bit and 64-bit Windows, 32-bit Linux, Solaris, HP) are all working fine.

This seems to be a problem with *my* code but I have no idea how I could possibly cause this to happen. Any ideas?

Graeme

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

From hellonotelling at gmail.com  Sat Oct 29 10:59:53 2016
From: hellonotelling at gmail.com (Hello Notelling)
Date: Sat, 29 Oct 2016 03:59:53 -0700
Subject: [openssl-users] openssl-users Digest, Vol 23, Issue 35
In-Reply-To: <CAGrG7Nb2KE_TKEWibHc1phGj7OghajseSRTm8a3txmEfvYB7tw@mail.gmail.com>
References: <mailman.1313.1477659497.1801.openssl-users@openssl.org>
 <CAGrG7Nb2KE_TKEWibHc1phGj7OghajseSRTm8a3txmEfvYB7tw@mail.gmail.com>
Message-ID: <CAGrG7NZWnrhd_4Jw9Noe-6x4hsAG_m4e17q91FEDAihmvMnn+g@mail.gmail.com>

Your query is currently being processed by our team. Your query number
is#000001

On 28 Oct 2016 1:58 p.m., <openssl-users-request at openssl.org> wrote:

Send openssl-users mailing list submissions to
        openssl-users at openssl.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://mta.openssl.org/mailman/listinfo/openssl-users
or, via email, send a message with subject or body 'help' to
        openssl-users-request at openssl.org

You can reach the person managing the list at
        openssl-users-owner at openssl.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of openssl-users digest..."


Today's Topics:

   1. Re: Help (Lander Bulckaen)


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

Message: 1
Date: Fri, 28 Oct 2016 12:55:43 +0000
From: Lander Bulckaen <Lander at fit.be>
To: "openssl-users at openssl.org" <openssl-users at openssl.org>
Subject: Re: [openssl-users] Help
Message-ID:
        <1BF0BB099673884291E8E8CB1C42CAFD033C662BEB at FITSERV01.fit.local>
Content-Type: text/plain; charset="utf-8"

Dear,

Yes I know.

I already extracted both keys from the .p12 file.

My biggest problem is how you can add the original file (in this case
?RequestFeedbacks.xml?) as attachment? (the signature ?smime.p7s? is
already attached)

Thanks for you quick reply and support!

Kind regards,
Lander

Van: openssl-users [mailto:openssl-users-bounces at openssl.org] Namens Dmitry
Belyavsky
Verzonden: vrijdag 28 oktober 2016 14:52
Aan: openssl-users at openssl.org
Onderwerp: Re: [openssl-users] Help


Sorry, my fault.

I think you should use the openssl smime command, but it doesn't work with
PKCS12, so you will have to extract the private and public keys using the
openssl pkcs12 command.

28 ???. 2016 ?. 2:34 PM ???????????? "Lander Bulckaen" <Lander at fit.be
<mailto:Lander at fit.be>> ???????:
Dear Dmitry,

The result must be as mentionned below?

Van: openssl-users [mailto:openssl-users-bounces at openssl.org<mailto:openssl-
users-bounces at openssl.org>] Namens Dmitry Belyavsky
Verzonden: donderdag 27 oktober 2016 19:09
Aan: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Onderwerp: Re: [openssl-users] Help

Hello
You should use the XMLSec library and the corresponding command-line tool.

On Thu, Oct 27, 2016 at 5:05 PM, Lander Bulckaen <Lander at fit.be<mailto:
Lander at fit.be>> wrote:
Hy,

Goal: add an xml file as attachment to a MIME message and sign the MIME
message with the primary key (.p12 file).

The result must be like what you see below??

Which openssl commands must I use in commandline?
(I already searched for ita bout 2 months but still not found any
solution?!)

Date: Fri Jul 01 10:26:15 CEST 2016
From: michel.dombret at nbb.be<mailto:michel.dombret at nbb.be>
To:
Message-ID: <28456974.01467361575985.JavaMail.feronan at PC0020881<mailto:
28456974.01467361575985.JavaMail.feronan at PC0020881>>
Subject: NBB signed file
MIME-Version: 1.0
Content-Type: multipart/signed;
                boundary="----=_Part_1_6142443.1467361575963";
                protocol="application/pkcs7-signature"; micalg=sha1

------=_Part_1_6142443.1467361575963
Content-Type: multipart/mixed;
                boundary="----=_Part_0_25389802.1467361575861"

------=_Part_0_25389802.1467361575861
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Message created by Offline Signing Tool of National bank of BELGIUM
------=_Part_0_25389802.1467361575861
Content-Type: application/octet-stream; name=RequestFeedbacks.xml
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=RequestFeedbacks.xml

<?xml version="1.0" encoding="UTF-8"?>
<Request>
            <Version>V01</Version>
            <Criteria>
            <DocDate>
                        <From>2016-08-01</From>
                        <To>2016-08-15</To>
            </DocDate>
            <DocType>ALL</DocType>
            <UnrequestedDocOnly>true</UnrequestedDocOnly>
            </Criteria>
</Request>

------=_Part_0_25389802.1467361575861--

------=_Part_1_6142443.1467361575963
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMtzCCBXMw
ggNboAMCAQICAgCoMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1
c3NlbHMxETAPBgNVBAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdp
dW0xITAfBgNVBAsTGERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3Vy
ZSBFbWFpbCBDQTEcMBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZTAeFw0wNzA0MDMxMzE2MDRa
Fw0xNzAzMzExMzE2MDRaMIGiMQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV
BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xCzAJBgNVBAsT
AlBSMRkwFwYDVQQDFBBUJlQgUFIwM0hLRVRUSU5UMSIwIAYJKoZIhvcNAQkBFhNwcjAzaGtldHRp
bnRAbmJiLmJlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAwXENutQ5VnJDP0Q1waji
85ewXgm3P0qY6YMUR3LyiJgJRaXjT36UdbgDnqrObguedfGvNKirQ3mpa74b6d/ErcVBweBORvRo
MFtJmIsqFgu6wVSgz+iSiuO/ssUsIWiT+5NzYOVhDGHMbMklPebUanzO2K+pEkCdxM3ELZRZM6Rp
7vw8TiW9gVH2ENw7uFcT8IAbjxjo6mZo/c3VImK/WuCEdbHIa50/1sOuga0jf80sNpuQm9hysHRG
fM/ZMt40w74wrTcbGo7ZrVcERErxSjm0maFwhJ7EsfdUj4bUFOIAvy3yqWqexUmwCKhbgEYjnIxQ
71K2dKVx/PL/Q0kv1wIDAQABo4GdMIGaMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAUuJKri3/G
X75S00GfLLkbpGXGJUUwHQYDVR0OBBYEFHVLViGBjbswdpC7YaMtP43ZRrvVMB4GA1UdEQQXMBWB
E3ByMDNoa2V0dGludEBuYmIuYmUwCwYDVR0PBAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr
BgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAgEAMNN/pSlrU7v32ONDluvSULI+ADCcE5+oIz0Kts4f
OdnFtBngDypkK0DSqA+yKwxRNhEvyHjmpkhcPsVVxH18m6mDI+UU2QiyaUfXSMvuLct3yZX0Pc6+
8inDu4zxfAN4Ni78yfIxWsGR+hYLAyik+5Kw/lhhxBIHB183KLaVva+762HW04TNhgQUUkMaEn/T
HAH/U+IFQHHeRUylgsgMgFPzXVcFTXe+PBAwbEOITwoDf2Y7YbVyKdEA8JsVNWSt8NsEmba/7ZD3
XId+O2sTwnzWu7lkyIIA+/h4/ewOpvu28o3MQF48dUNeE+89MT56qfrDbfiJtRvICWXTYBh0tdki
057G2VAZr7b9/W16HxKreSelI0rdYH0mG0S0Iy6YrdEQn9vAruHvGqIPl5Mu65fLg+28R0c+2TyF
BJ2DT/lckPZjTu6Y6cVMUahA2ZcsAWFizYT7PV4HTvpqhhWwCtuKcvCunsvCHMCbjSlXkk0yvnF6
vGJG31oTw1SsajbBVGfRuwWss1Y39Z/eNBO7nfrXZRJs9QLVwN016mY70Q/+CzeSpmDJNtKnU/nm
ob2BXdEG+eg0m9oLPNPQJjObS8Di8CKAE9xFteGqAt4ff0daQtIFZucqAhBpRXu9zJFjoNICBKYO
VIzFHFl3KNj+7u4BWiRl96udiGwVgrNoc3Iwggc8MIIFJKADAgECAgkAklGjqlmMoxgwDQYJKoZI
hvcNAQEFBQAwgbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1
c3NlbHMxITAfBgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBT
ZWN1cml0eSBNYW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZI
hvcNAQkBFg1kc21vcHNAbmJiLmJlMB4XDTA1MDUyMzA4NDkzMFoXDTI1MDUxODA4NDkzMFowgbUx
CzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAfBgNV
BAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBNYW5h
Z2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1kc21v
cHNAbmJiLmJlMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAt+wnMwqwqr8q7m20/ly+
HZl7RznDuxKX1muAdmFxwm+LXTQtvNbwEom8xmpwLAy0tn+P+RKElWRTc06z8sqisHL282hULh/G
Otufmf6eQOzW3UsX6xZWa1Un9Y0BwLncm+CmNFYTcmhNUkr6PT1Lzu277BiiBrjxqs22jEd0ibOs
vKlv0xXGh0qXRcltd0IEpcPneod0L/HCsm65d9fuS584LShsBbPcaVO4Zg5N8Zi9+lAslkxsgDen
txvM+ZZuhtS6vAAUKOq6IgPa9Mgih2wrWOtrPRyj7aUHalODBbgAzHz0enNszVhGM0sw4fcETkDQ
AysOpFnClGcKk2FhdNb9Z3uCw80YZrd3NAGCfnYWR/SL0Flq6T+2BOur/gRDrL++NeDiJ38JUyK+
nMcBuieECYYFusaYUDSEzUHe2KIBfdd1Y2cvi6+sINCt+0939Naw+ZNITy6iOkUdXLgGdvS1YVa3
SEbmV9tIdTJhb2stp0prgUPMc5XOq3KGaKpKuqnos1XCfHc6JTE2l7OQc9PHnk7dsHBIvvHLQt3A
Z+XIj6pd70qtKKU/BsFk8fv09UAw6jWFTIdz9Msz6h1ieFstA4I3bzYLFwALirTFuR1SRH/9xl3s
6nUs78jJ5/ANE0HV3AiSMCJ2TvHfzDSZ1Efm+H5oTCn4vmvlPBEXnEMCAwEAAaOCAUswggFHMB0G
A1UdDgQWBBS4kquLf8ZfvlLTQZ8suRukZcYlRTAYBgNVHREEETAPgQ1kc21vcHNAbmJiLmJlMA8G
A1UdEwEB/wQFMAMBAf8wgeoGA1UdIwSB4jCB34AUuJKri3/GX75S00GfLLkbpGXGJUWhgbukgbgw
gbUxCzAJBgNVBAYTAkJFMREwDwYDVQQIEwhCcnVzc2VsczERMA8GA1UEBxMIQnJ1c3NlbHMxITAf
BgNVBAoTGE5hdGlvbmFsIEJhbmsgb2YgQmVsZ2l1bTEhMB8GA1UECxMYRGF0YSBTZWN1cml0eSBN
YW5hZ2VtZW50MRwwGgYDVQQDExNOQkIgU2VjdXJlIEVtYWlsIENBMRwwGgYJKoZIhvcNAQkBFg1k
c21vcHNAbmJiLmJlggkAklGjqlmMoxgwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IC
AQA2hzYYNkQW3bJBy00n3ZegqggLA3IplHr/NhQZ6ppvOu+E4K993/1UNsv2hGIto1te3AD6AwUk
A1jstQi42e9WtG0c29gST7+AtAsn3clzRWnNXzIMaeTz+k0XNk6YdiiERNBShn5o8sUeiYxmWJQ6
ovicqBsBVkdknwifwa0CRG7kz6dMy7BWOY2mt8qFh6yIbhTox3HFVE2cdbs3k6cr9eOUv6xbkoCo
GcUWzu90Gqbpyny95ix/ZLiauCs8nGXwbbICo1CG2xZ7TJMfCAU1J55eYAaSmDkV843Q4Jr1cyPm
VPWhQDfWzA1bTsAB8Q4pwKVjq28jhDJZtKSS0FblgC96kMxlwajCSyzykhrsaVdwCaU++1KrwPDB
Y5VtZhyn55Cpgs/3gQ8L4BskrLdRpdVDvO4ER35gvAaQTRP8NwOzepGico34VpVa1prz+ZB+CvvM
KYN85i2jzFdvS2yag3jaCC+t2Xp0GKL2ZmF7oWDKkiWXwYjWJ/XiTZ3AdsBJPDvmOYxAuUeH/ADm
WRoNHCwaUbNr0vxEXLZam8bFyXe0TohiRGczUfSgQDzuAbAjKE2HQSeObI0w1ZWxzmvS1+xo/HDn
pZBd60fHaH/QpBwp0JnBxouRt/daxB0MuckGaEBx3qn925Ac5pzM+6K1N1uKF3mTxiM4Ocd9nWpM
1TGCApgwggKUAgEBMIG8MIG1MQswCQYDVQQGEwJCRTERMA8GA1UECBMIQnJ1c3NlbHMxETAPBgNV
BAcTCEJydXNzZWxzMSEwHwYDVQQKExhOYXRpb25hbCBCYW5rIG9mIEJlbGdpdW0xITAfBgNVBAsT
GERhdGEgU2VjdXJpdHkgTWFuYWdlbWVudDEcMBoGA1UEAxMTTkJCIFNlY3VyZSBFbWFpbCBDQTEc
MBoGCSqGSIb3DQEJARYNZHNtb3BzQG5iYi5iZQICAKgwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0B
CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA3MDEwODI2MTVaMCMGCSqGSIb3DQEJ
BDEWBBRs4Ik9waWLNU/4OZ9TfT4yZZ0EljBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCBzANBgkq
hkiG9w0BAQEFAASCAQCSP5/h1v6feRr+ekK19tlI4zvm1Wy7hUtN+XmbWLJHOxSU4wJUBRj6ptph
Mb7AOm1JYy8+wWRQhgOcIegD74eXZoYfws+O3ADZ//feXYJAF/jqAyhs0r9CoGw2eUUeZR4KYILy
ZG5I3lcFJLDPHcElSe3NgRBOmfuFWD/mSLE2B2S+PqbnbugYPSN7mCSOqMZODPBlop9wczBUD1BI
K+kM1fP28541RfCFS6tGUXamWnKOdbxoHbPmnQDT1zzcbRIUvnLCV6MZ4KFNAXf5YxwggV3jjPiQ
vyzr8EdFzmaWpoOFEtCLmQw4hpSEPJO8yGxQ5/29MWg6Ypy62bjMfs54AAAAAAAA
------=_Part_1_6142443.1467361575963--

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



--
SY, Dmitry Belyavsky

--
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/20161028/66e0fc06/attachment.html>

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

Subject: Digest Footer

_______________________________________________
openssl-users mailing list
openssl-users at openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-users


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

End of openssl-users Digest, Vol 23, Issue 35
*********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161029/831a15c0/attachment-0001.html>

From doctor at doctor.nl2k.ab.ca  Sun Oct 30 11:39:07 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Sun, 30 Oct 2016 05:39:07 -0600
Subject: [openssl-users] openssl-1.0.2-stable-SNAP-20161030 isue test
	failures
Message-ID: <20161030113907.GA80336@doctor.nl2k.ab.ca>

make test  yield

Test X509v3_check_*
../util/shlib_wrap.sh ./v3nametest
../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value 0, received -1
** test_dtls1_not_bleeding failed **
--------
test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1
** test_dtls1_not_bleeding_empty_payload failed **
--------
test_tls1_not_bleeding failed: expected return value 0, received -1
** test_tls1_not_bleeding failed **
--------
test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1
** test_tls1_not_bleeding_empty_payload failed **
--------
4 tests failed
*** Error code 1


not present in openssl-1.0.2-stable-SNAP-20161029 .

Please fix.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 

From ernst.maurer at gmail.com  Mon Oct 31 11:41:34 2016
From: ernst.maurer at gmail.com (Ernst Maurer)
Date: Mon, 31 Oct 2016 11:41:34 +0000
Subject: [openssl-users] libraries after the build for WIn platform
Message-ID: <CA+cSMc2E_YpvwurLu+YbHiYFS+T6YG6aChLvgYpeXVAywGTpVA@mail.gmail.com>

hi

I'm not using openssl daily , just need to build and link it with another
library.
that lib requires libeay32.lib and ssleay32.lib.
Are these  ones from OpenSSL distribution?
I've tried two options:
1. download a few pre-built versions of the  binaries
2. build own binaries from latest git

both cases don't contain these lib (and dll) files.
please assist

Rgds,
Ernst
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161031/363aa03f/attachment.html>

From doctor at doctor.nl2k.ab.ca  Mon Oct 31 14:29:38 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 31 Oct 2016 08:29:38 -0600
Subject: [openssl-users] Still seeing test failure in openssl 1.0.2 SNAPHOT
	20161031
Message-ID: <20161031142938.GA97772@doctor.nl2k.ab.ca>

I saw this yesterday as well

../util/shlib_wrap.sh ./heartbeat_test
test_dtls1_not_bleeding failed: expected return value 0, received -1
** test_dtls1_not_bleeding failed **
--------
test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1
** test_dtls1_not_bleeding_empty_payload failed **
--------
test_tls1_not_bleeding failed: expected return value 0, received -1
** test_tls1_not_bleeding failed **
--------
test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1
** test_tls1_not_bleeding_empty_payload failed **
--------
4 tests failed
*** Error code 1

Stop.
make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test
*** Error code 1

Please fix

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Time for the USA to hold a referendum on its republic and vote to dissolve!! 

From huy-cong.vu at wandercraft.eu  Mon Oct 31 17:08:56 2016
From: huy-cong.vu at wandercraft.eu (Huy Cong Vu)
Date: Mon, 31 Oct 2016 18:08:56 +0100 (CET)
Subject: [openssl-users] Generate and use ECDH certificate on a simple
	server-client model
Message-ID: <1782934283.398055.1477933736037.JavaMail.zimbra@wandercraft.eu>

Hi, 
I'm trying to establish a TLS/SSL connection between 2 back-end using OpenSSL library. 
The algorithm I would like to use is ECDHE-RSA-AES256-SHA. 
At first, I want to generate 2 pairs of ECDH-RSA certificate/key, 1 for the server & 1 for the client using a root CA as a signed authority. To simplify everthing, I want to insert a fixed ECDH parameters into the RSA certificate. For that I came up with the following solution 
Here are the commands I used to generate these 2 certificate: 

#Root CA 
openssl genrsa -out rootCA.key 2048 -aes256 
openssl req -x509 -new -nodes -key rootCA.key -days 36500 -out rootCA.pem 

#ECDH params 
openssl ecparam -out ecparam.pem -name prime256v1 
openssl genpkey -paramfile ecparam.pem -out eckey.pem 

#ECDH certificate client 
openssl genrsa -out rsaclient.key 2048 -aes256 
openssl pkey -in eckey.pem -pubout -out ecpubkeyclient.pem 
openssl req -new -key rsaclient.key -out rsaclient.csr -days 36500 

#signed ECDH certificate client 
openssl x509 -req -in rsaclient.csr -CAkey rootCA.key -CA rootCA.pem -force_pubkey ecpubkeyclient.pem -out eccertclient.pem -CAcreateserial 

#ECDH certificate server 
openssl genrsa -out rsaserver.key 2048 -aes256 
openssl pkey -in eckey.pem -pubout -out ecpubkeyserver.pem 
openssl req -new -key rsaserver.key -out rsaserver.csr -days 36500 

#signed ECDH certificate server 
openssl x509 -req -in rsaserver.csr -CAkey rootCA.key -CA rootCA.pem -force_pubkey ecpubkeyserver.pem -out eccertserver.pem -CAcreateserial 

If I understand correctly, I will obtain: 
Root key: rootCA.key 
Root certificate: rootCA.pem 
ECDH client: eccertclient.pem 
ECDH client private key: rsaclient.key 
ECDH server: eccertserver.pem 
ECDH server private key: rsaserver.key 

However, when I used SSL_CTX_check_private_key to check between eccertserver.pem & rsaserver.key, an error was occured. 
Is there anything I did was wrong when I use the commands. 
Any help would be appriciate, thanks in advance. 
Best regards, 

-- 

Huy Cong 
06 69 07 97 82 
Wandercraft SAS 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161031/16848491/attachment.html>