From satya at attivonetworks.com  Fri Apr  1 00:40:08 2016
From: satya at attivonetworks.com (Satya Das)
Date: Fri, 1 Apr 2016 00:40:08 +0000
Subject: [openssl-users] Binaries exit with signature bytes
In-Reply-To: <BL2PR07MB24045F62BA7051E077F28A53D7870@BL2PR07MB2404.namprd07.prod.outlook.com>
References: <BL2PR07MB24046622F646EBA702705273D7830@BL2PR07MB2404.namprd07.prod.outlook.com>,
 <20160327015401.GB17179@openssl.org>
 <BL2PR07MB24045F62BA7051E077F28A53D7870@BL2PR07MB2404.namprd07.prod.outlook.com>
Message-ID: <BL2PR07MB2404EE719A95BA1A210CF28FD79A0@BL2PR07MB2404.namprd07.prod.outlook.com>

Forgot to mention that I am on fips module 2.0.11 fipsld building openssl 1.0.1e with distribution patches when I get the "libcrypto.so.10 is not cross-compiler aware" error. The symbols that incore is looking for are indeed not present (startX etc) in the shared object built. How can I fix this error ? 

-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Satya Das
Sent: Monday, March 28, 2016 5:48 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Binaries exit with signature bytes


>What platform are you building? Is it a native or cross compile?

>You'd get that behaviour if fipsld isn't linking the binaries properly.

Thanks Steve. I am on centos 6, native compile. I saw " /libcrypto.so is not cross-compiler aware." with fipsld linking until introducing -exe option to incore invocation. It builds fine with the modified fipsld but then I now have this run time error to deal with.

TIA.


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

From otisevans98 at gmail.com  Fri Apr  1 19:27:02 2016
From: otisevans98 at gmail.com (Otis Evans)
Date: Fri, 1 Apr 2016 14:27:02 -0500
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
Message-ID: <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>

923 Dunlap st
On Apr 1, 2016 1:02 PM, <otisevans98 at gmail.com> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * Attn:__here__is__your___$l???__Faceb??k__giftcard.
> __W?__N??d__Y??r__Shi?me?t__Inf?rmati??s__ Click_Here
> <http://mail.stunning.email/ct/t6k04w43v2/4CxPt1DbKd> *
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160401/4110a463/attachment.html>

From otisevans98 at gmail.com  Fri Apr  1 19:29:25 2016
From: otisevans98 at gmail.com (Otis Evans)
Date: Fri, 1 Apr 2016 14:29:25 -0500
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
Message-ID: <CAH32DDhREippp5_bL=3kXAnCx4NWgvd1W29GuYqBBohZO4VEzA@mail.gmail.com>

923 Dunlap st
On Apr 1, 2016 2:27 PM, "Otis Evans" <otisevans98 at gmail.com> wrote:

> 923 Dunlap st
> On Apr 1, 2016 1:02 PM, <otisevans98 at gmail.com> wrote:
>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> * Attn:__here__is__your___$l???__Faceb??k__giftcard.
>> __W?__N??d__Y??r__Shi?me?t__Inf?rmati??s__ Click_Here
>> <http://mail.stunning.email/ct/t6k04w43v2/4CxPt1DbKd> *
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160401/2e2077ed/attachment.html>

From jvp at forthepolls.org  Fri Apr  1 19:32:00 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Fri, 1 Apr 2016 12:32:00 -0700
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
Message-ID: <56FECCB0.7010406@forthepolls.org>

why is junk like this not being caught?

--
Thank you,

Johann v. Preu?en

On 2016.Apr.01 12:27, Otis Evans wrote:
>
> 923 Dunlap st
>
> On Apr 1, 2016 1:02 PM, <otisevans98 at gmail.com <mailto:otisevans98 at gmail.com>> 
> wrote:
>
>
>     /
>     Attn:__here__is__your___$l???__Faceb??k__giftcard.
>
>     __W?__N??d__Y??r__Shi?me?t__Inf?rmati??s__
>
>     Click_Here <http://mail.stunning.email/ct/t6k04w43v2/4CxPt1DbKd>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>     /
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160401/51ca77be/attachment.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/20160401/51ca77be/attachment.bin>

From ben at an3k.de  Fri Apr  1 20:54:25 2016
From: ben at an3k.de (Ben Humpert)
Date: Fri, 1 Apr 2016 22:54:25 +0200
Subject: [openssl-users] Properly manage CA-signed certificates that
	have expired
In-Reply-To: <CAH8yC8m0TayUaaNWtZVwiWtagvgXuzxQO9iqSiaTXX1i8tC=cw@mail.gmail.com>
References: <CAJdJdQmBBmwoc4unKMKYTo_51GxKfta7bTJh1y=rb=qHqZZKDQ@mail.gmail.com>
 <56FD4BAC.1040602@wisemo.com>
 <CAGbjqfEH8uviiBe6GcPj97Sg2vh3iaS_9gB0ArnMNRML9VDPjw@mail.gmail.com>
 <CAH8yC8m0TayUaaNWtZVwiWtagvgXuzxQO9iqSiaTXX1i8tC=cw@mail.gmail.com>
Message-ID: <CAGbjqfH0OaoQq-jhbNnjiXjcyYpSvXt3Gs37tbCTXg4RTYRwJQ@mail.gmail.com>

I see. Thank you very much Jakob and Jeffrey!

From philton at overlandstorage.com  Fri Apr  1 21:16:06 2016
From: philton at overlandstorage.com (Peter Hilton)
Date: Fri, 1 Apr 2016 21:16:06 +0000 (UTC)
Subject: [openssl-users] Building 1.0.2g with
References: <BLUPR10MB07241F3AB681A3A0C37DA466C7810@BLUPR10MB0724.namprd10.prod.outlook.com>
 <56F2B401.5050306@openssl.org>
 <C58E97D22BD22F448150018085826C5101A859B7F8@NA-MBX-01.mgc.mentorg.com>
 <56F9096E.5040008@wisemo.com>
Message-ID: <loom.20160401T213530-475@post.gmane.org>


Jakob Bohm <jb-openssl at ...> writes:

> 
> In 1.0.2 and later, most of the files in ${BUILD_DIR}/include/openssl
> are supposed to be copies/symlinks to file of the same name elsewhere
> in the OpenSSL source, for instance the ones you mentions should be
> links to files in subdirectories under ${BUILD_DIR}/crypt.
> 
> However in your case, I suspect the following sequence of events:
> 
> 1. configure or make depend sees that you have disabled some ciphers
>    and don't link header files for those ciphers.
> 
> 2. Other parts of the OpenSSL source code blindly include those header
>    files because they used to be present in ${BUILD_DIR}/include/openssl
>    even when disabled, omitting them only (if at all) in the installed
>    files under ${INSTALL_DIR}/include/openssl
> 
> If this theory holds, this would be a bug in the 1.0.2 tree, either
> in the build scripts or in the source files that include headers for
> disabled ciphers, whichever fix creates the smallest/simplest patch
> should be applied.
> 
>

Hi,
   I am seeing the same problem with 0.9.8zh.
config with no-idea and the symlink to the idea.h header file is
not created.  This breaks the compile in multiple places in crypto.
make depend does not create the link when no-idea is configured.

We are building openssl inside a customised build environment so I simply
create the symlink after config is run and prior to running the compile.

Just my pennies worth

cheers
pete

pete hilton
also at:-
 saruman at ruvolo-hilton.org
 




From rsalz at akamai.com  Sat Apr  2 15:24:39 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 2 Apr 2016 15:24:39 +0000
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <56FECCB0.7010406@forthepolls.org>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
Message-ID: <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>


> why is junk like this not being caught?

Almost all of it is.  Nothing is perfect.  Thanks for your understanding and patience. 

From noloader at gmail.com  Sat Apr  2 15:41:55 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 2 Apr 2016 11:41:55 -0400
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>

On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich <rsalz at akamai.com> wrote:
>
>> why is junk like this not being caught?
>
> Almost all of it is.  Nothing is perfect.  Thanks for your understanding and patience.

I was looking at some of it landing in my Inbox. Its all from Gmail
users. The headers are Gmail headers submitted via the web. The DKIM
signatures are OK. There are no headers to indicate its been
forwarded. The {from|return|reply to} address does not appear to
forged. Here's an example header from another Gmail user who contacted
me: http://pastebin.com/hRAtRt7S.

I've also had a couple of people contact me asking me to stop spamming
them. I looked at two of those headers, and it clearly appears to be
coming from me though I did not send it (and no evidence in my
Outbox).

I'm thinking there's a vulnerability in the Gmail or Google servers we
have not heard about.

Jeff

From ben at an3k.de  Sat Apr  2 22:30:15 2016
From: ben at an3k.de (Ben Humpert)
Date: Sun, 3 Apr 2016 00:30:15 +0200
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
Message-ID: <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>

Fun Fact: (For me) Gmail often marks completely legit emails from
mailing lists as spam and you manually have to mark them as "no spam".
The fun comes in when you notice that actual spam is not marked as
such at all.

Looks like strong encryption is much easier to develop than a decent
spam filter.

The main problem I guess is that neither Google nor any other major
email provider actually block other email providers who do not offer
SPF, SMTP2SMTP encryption or whatever else. If they would do so, we
would have solved most major (email) problems within a week or at
least a month. Either by forcing those to offer these security
features or by "killing" these providers indirectly.

2016-04-02 17:41 GMT+02:00 Jeffrey Walton <noloader at gmail.com>:
> On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich <rsalz at akamai.com> wrote:
>>
>>> why is junk like this not being caught?
>>
>> Almost all of it is.  Nothing is perfect.  Thanks for your understanding and patience.
>
> I was looking at some of it landing in my Inbox. Its all from Gmail
> users. The headers are Gmail headers submitted via the web. The DKIM
> signatures are OK. There are no headers to indicate its been
> forwarded. The {from|return|reply to} address does not appear to
> forged. Here's an example header from another Gmail user who contacted
> me: http://pastebin.com/hRAtRt7S.
>
> I've also had a couple of people contact me asking me to stop spamming
> them. I looked at two of those headers, and it clearly appears to be
> coming from me though I did not send it (and no evidence in my
> Outbox).
>
> I'm thinking there's a vulnerability in the Gmail or Google servers we
> have not heard about.
>
> Jeff
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From jvp at forthepolls.org  Sat Apr  2 23:29:01 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Sat, 2 Apr 2016 16:29:01 -0700
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
Message-ID: <570055BD.8020602@forthepolls.org>

i guess the reason for my original post was that i was so taken aback by the 
fact that the body had so many red flags:
1.) '$1000': this list certainly is about money, but it would seem unlikely that 
actual terms not coupled with something like [loss|cost] or the like would seem 
improbable;
2.) 'giftcard': seems like a very unlikely discussion element here;
3.) 'shipment': ditto;
4.) 'informations' (sic): i realize this list -- being international in scope -- 
will not exhibit perfect English usage at all times (even from native English 
speakers). however, poor English (even just spell-checked) combined with other 
filters could push the score high enough;
5.) links: examples are always very constructive, but it is certainly not much 
of an inconvenience to limit active anchors to major sandboxes or even one 
operated by openssl; and
6.) obfuscation: the worst and most-telling is the fact the content clearly was 
designed to bypass filters by couching the desired message within a highly 
unusual number of non-prose, non-technical symbols. in this blatant case  there 
was a complete lack of prose and that will just never occur in this list.

this list is active, but a very low-volume one and more intensive body checks 
that route questionable entries to some monitoring box would seem to be well 
worth the small resource utilization required.

moreover, i do not notice anyone from google's security team(s) chiming in here 
and it would seem that good old 'otisevans98' will skate without consequence for 
the foray against this list which is entirely about security. perhaps added body 
filtering and actual human intervention would serve the desired benefit of 
having such intrusions actually result in an abuse complaint to the MTA 
operator.<mailto:otisevans98 at gmail.com>

--
Thank you,

Johann v. Preu?en

On 2016.Apr.02 15:30, Ben Humpert wrote:
> Fun Fact: (For me) Gmail often marks completely legit emails from
> mailing lists as spam and you manually have to mark them as "no spam".
> The fun comes in when you notice that actual spam is not marked as
> such at all.
>
> Looks like strong encryption is much easier to develop than a decent
> spam filter.
>
> The main problem I guess is that neither Google nor any other major
> email provider actually block other email providers who do not offer
> SPF, SMTP2SMTP encryption or whatever else. If they would do so, we
> would have solved most major (email) problems within a week or at
> least a month. Either by forcing those to offer these security
> features or by "killing" these providers indirectly.
>
> 2016-04-02 17:41 GMT+02:00 Jeffrey Walton <noloader at gmail.com>:
>> On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich <rsalz at akamai.com> wrote:
>>>> why is junk like this not being caught?
>>> Almost all of it is.  Nothing is perfect.  Thanks for your understanding and patience.
>> I was looking at some of it landing in my Inbox. Its all from Gmail
>> users. The headers are Gmail headers submitted via the web. The DKIM
>> signatures are OK. There are no headers to indicate its been
>> forwarded. The {from|return|reply to} address does not appear to
>> forged. Here's an example header from another Gmail user who contacted
>> me: http://pastebin.com/hRAtRt7S.
>>
>> I've also had a couple of people contact me asking me to stop spamming
>> them. I looked at two of those headers, and it clearly appears to be
>> coming from me though I did not send it (and no evidence in my
>> Outbox).
>>
>> I'm thinking there's a vulnerability in the Gmail or Google servers we
>> have not heard about.
>>
>> Jeff
>> --
>> 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/20160402/8b3ad7f5/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/20160402/8b3ad7f5/attachment-0001.bin>

From mkrav at yahoo-inc.com  Sun Apr  3 07:56:51 2016
From: mkrav at yahoo-inc.com (Michael Kravchenko)
Date: Sun, 3 Apr 2016 07:56:51 +0000 (UTC)
Subject: [openssl-users] Cancelling handshake in the middle
References: <1699588141.1492703.1459670211956.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <1699588141.1492703.1459670211956.JavaMail.yahoo@mail.yahoo.com>

Hi,?

(My question is regarding a problem I discovered while developing a DTLS client, but I'm not sure that it's specific to DTLS)?

What is the proper way to cancel a handshake process in the middle? I have a client working with non-blocking BIO, which performs a series of SSL_connect() calls to establish connection to the server. Let's say that during the handshake process, the client, for some reason, decides to abort it. Ideally, I'd like the server to receive an alert message indicating that the client will not be finishing the handshake.?

SSL_shutdown() cannot be used here, since it works only after the handshake.?

I cannot find any public API call that could be used in this situation. ssl3_send_alert() is not a public API call.?

Any ideas on what would be the best way to proceed in this situation??

Thanks?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160403/5b210930/attachment.html>

From otisevans98 at gmail.com  Sun Apr  3 08:17:08 2016
From: otisevans98 at gmail.com (Otis Evans)
Date: Sun, 3 Apr 2016 03:17:08 -0500
Subject: [openssl-users] Cancelling handshake in the middle
In-Reply-To: <1699588141.1492703.1459670211956.JavaMail.yahoo@mail.yahoo.com>
References: <1699588141.1492703.1459670211956.JavaMail.yahoo.ref@mail.yahoo.com>
 <1699588141.1492703.1459670211956.JavaMail.yahoo@mail.yahoo.com>
Message-ID: <CAH32DDjCJ6NJE9HDjT8xZReOsDLO3hp+h8W_EjW8bd=v1EWZ5g@mail.gmail.com>

Explain more
On Apr 3, 2016 2:59 AM, "Michael Kravchenko" <mkrav at yahoo-inc.com> wrote:

> Hi,
>
> (My question is regarding a problem I discovered while developing a DTLS
> client, but I'm not sure that it's specific to DTLS)
>
> What is the proper way to cancel a handshake process in the middle? I have
> a client working with non-blocking BIO, which performs a series of
> SSL_connect() calls to establish connection to the server. Let's say that
> during the handshake process, the client, for some reason, decides to abort
> it. Ideally, I'd like the server to receive an alert message indicating
> that the client will not be finishing the handshake.
>
> SSL_shutdown() cannot be used here, since it works only after the
> handshake.
>
> I cannot find any public API call that could be used in this situation.
> ssl3_send_alert() is not a public API call.
>
> Any ideas on what would be the best way to proceed in this situation?
>
> Thanks
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160403/715dceb2/attachment.html>

From mkrav at yahoo-inc.com  Sun Apr  3 09:15:24 2016
From: mkrav at yahoo-inc.com (Michael Kravchenko)
Date: Sun, 3 Apr 2016 09:15:24 +0000 (UTC)
Subject: [openssl-users] Cancelling handshake in the middle
In-Reply-To: <CAH32DDjCJ6NJE9HDjT8xZReOsDLO3hp+h8W_EjW8bd=v1EWZ5g@mail.gmail.com>
References: <1699588141.1492703.1459670211956.JavaMail.yahoo.ref@mail.yahoo.com>
 <1699588141.1492703.1459670211956.JavaMail.yahoo@mail.yahoo.com>
 <CAH32DDjCJ6NJE9HDjT8xZReOsDLO3hp+h8W_EjW8bd=v1EWZ5g@mail.gmail.com>
Message-ID: <652732984.1486131.1459674924759.JavaMail.yahoo@mail.yahoo.com>

I have a client application that works with non-blocking BIO. The handshake loop looks, very roughly, like this:
? 1. call?SSL_connect()? 2. if the return value is -1 and?SSL_get_error() returns?WANT_READ or?WANT_WRITE, perform the relevant select() call? 3. go to 1 and repeat until SSL_connect() returns 1
Let's say, I want to add an option of breaking this loop early due to some external cause, e.g. - the client?application is closing. In this case, I'd like to let the server know that my client is exiting and will not be finishing the handshake process. What would be the proper API call to indicate this to the server? SSL_shutdown is not an option.
For TLS over TCP, closing the underlying TCP socket would probably do the trick, but in the case of DTLS over UDP (or other connection-less protocols) it would be better if the server received an alert message. If the DTLS client just exits silently in the middle of the handshake, the server will perform a series of timeouts/retransmissions as required by the DTLS standard, which can potentially take up to several minutes. This is why I am looking for an OpenSSL API call that could be used in the middle of handshake and would result in an alert message.
Hope this was more clear.
 

    On Sunday, April 3, 2016 11:17 AM, Otis Evans <otisevans98 at gmail.com> wrote:
 

 Explain moreOn Apr 3, 2016 2:59 AM, "Michael Kravchenko" <mkrav at yahoo-inc.com> wrote:

Hi,?

(My question is regarding a problem I discovered while developing a DTLS client, but I'm not sure that it's specific to DTLS)?

What is the proper way to cancel a handshake process in the middle? I have a client working with non-blocking BIO, which performs a series of SSL_connect() calls to establish connection to the server. Let's say that during the handshake process, the client, for some reason, decides to abort it. Ideally, I'd like the server to receive an alert message indicating that the client will not be finishing the handshake.?

SSL_shutdown() cannot be used here, since it works only after the handshake.?

I cannot find any public API call that could be used in this situation. ssl3_send_alert() is not a public API call.?

Any ideas on what would be the best way to proceed in this situation??

Thanks?

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




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

From sugu.ece28 at gmail.com  Mon Apr  4 13:26:29 2016
From: sugu.ece28 at gmail.com (Sugumar)
Date: Mon, 4 Apr 2016 06:26:29 -0700 (MST)
Subject: [openssl-users] Is SHA hashing algorithm reversable?
Message-ID: <1459776389932-65408.post@n7.nabble.com>

Hi,

I going to use SHA256 algorithm for storing my passwords in secure manner.
But after reading some documentations related to SHA i come to know it is
not reversable. 
Yes hashing means its not reversable only.
But i saw some online websites giving the original data by reversing the
hash data.
is it possible means what is the security of hashing?
I am totally confused pls clarify my doubt.



--
View this message in context: http://openssl.6102.n7.nabble.com/Is-SHA-hashing-algorithm-reversable-tp65408.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From swall at redcom.com  Mon Apr  4 14:42:52 2016
From: swall at redcom.com (Wall, Stephen)
Date: Mon, 4 Apr 2016 10:42:52 -0400
Subject: [openssl-users] Is SHA hashing algorithm reversable?
In-Reply-To: <1459776389932-65408.post@n7.nabble.com>
References: <1459776389932-65408.post@n7.nabble.com>
Message-ID: <401084E5E73F4241A44F3C9E6FD794280378A86FD8@exch-01>

> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf Of Sugumar
> Sent: Monday, April 04, 2016 9:26 AM
> To: openssl-users at openssl.org
> Subject: [openssl-users] Is SHA hashing algorithm reversable?
> 	
> Hi,
> 
> I going to use SHA256 algorithm for storing my passwords in secure
> manner.
> But after reading some documentations related to SHA i come to know it
> is
> not reversable.
> Yes hashing means its not reversable only.
> But i saw some online websites giving the original data by reversing
> the
> hash data.
> is it possible means what is the security of hashing?
> I am totally confused pls clarify my doubt.

Hashes are not reversible.  When used to store passwords, the passwords is hashed with a random 'salt', and both the resultant value and the salt are stored.  When testing if an entered password is correct, you hash the entered password with the stored salt, and if the result matches the stored value, the entered password was correct.  Also, generally, a plain hash is not used, it is repeated some large number of times, sometimes with addition data added in, to slow down and complicate cracking attempts.  Google (or any other search engine) can give you lots of links for properly hashing and storing passwords.

-spw

From michel.sales at free.fr  Mon Apr  4 14:56:05 2016
From: michel.sales at free.fr (Michel)
Date: Mon, 4 Apr 2016 16:56:05 +0200
Subject: [openssl-users] Is SHA hashing algorithm reversable?
In-Reply-To: <1459776389932-65408.post@n7.nabble.com>
References: <1459776389932-65408.post@n7.nabble.com>
Message-ID: <001801d18e82$1d2b6190$578224b0$@sales@free.fr>

Hi,

> But i saw some online websites giving the original data by reversing the
hash data.

If they can, this is NOT by reversing the hash data.

You will find lots of articles on the web to explain how it can be
'cracked',
for example :
https://crackstation.net/hashing-security.htm




From jb-openssl at wisemo.com  Mon Apr  4 16:03:11 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 4 Apr 2016 18:03:11 +0200
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
Message-ID: <5702903F.9090508@wisemo.com>

Key Fact: Not all e-mail is sent by or through 800 pound
gorilla providers such as Google.

Many organizations and businesses (including the OpenSSL
project) run their own e-mail servers and simply don't
have the manpower to track and implement every new
"anti-spam flagging" fad that comes along.

For example SMTP2SMTP encryption (aka SMTP with STARTTLS
and various configuration option choices) is default in
some MTA implementations, yet nearly impossible to add
in others.

Therefore setting up rules banning any domains not
implementing the latest "standard" anti-spam measures
would be extremely stifling and would force many more
people to send through surveillance-happy organizations
such as Google.

And anyway, this seems to be a case where the genuine
operator of an e-mail domain is failing to correctly
authenticate submissions by their own users, which no
amount of 3rd party automation (other than blacklisting
the failing provider, in this case gmail) could stop.


On 03/04/2016 00:30, Ben Humpert wrote:
> Fun Fact: (For me) Gmail often marks completely legit emails from
> mailing lists as spam and you manually have to mark them as "no spam".
> The fun comes in when you notice that actual spam is not marked as
> such at all.
>
> Looks like strong encryption is much easier to develop than a decent
> spam filter.
>
> The main problem I guess is that neither Google nor any other major
> email provider actually block other email providers who do not offer
> SPF, SMTP2SMTP encryption or whatever else. If they would do so, we
> would have solved most major (email) problems within a week or at
> least a month. Either by forcing those to offer these security
> features or by "killing" these providers indirectly.
>
> 2016-04-02 17:41 GMT+02:00 Jeffrey Walton <noloader at gmail.com>:
>> On Sat, Apr 2, 2016 at 11:24 AM, Salz, Rich <rsalz at akamai.com> wrote:
>>>> why is junk like this not being caught?
>>> Almost all of it is.  Nothing is perfect.  Thanks for your understanding and patience.
>> I was looking at some of it landing in my Inbox. Its all from Gmail
>> users. The headers are Gmail headers submitted via the web. The DKIM
>> signatures are OK. There are no headers to indicate its been
>> forwarded. The {from|return|reply to} address does not appear to
>> forged. Here's an example header from another Gmail user who contacted
>> me: http://pastebin.com/hRAtRt7S.
>>
>> I've also had a couple of people contact me asking me to stop spamming
>> them. I looked at two of those headers, and it clearly appears to be
>> coming from me though I did not send it (and no evidence in my
>> Outbox).
>>
>> I'm thinking there's a vulnerability in the Gmail or Google servers we
>> have not heard about.
>>
>> Jeff
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


-- 
Jakob Bohm, CIO, partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Soborg, Denmark. direct: +45 31 13 16 10 
<tel:+4531131610>
This message is only for its intended recipient, delete if misaddressed.
WiseMo - Remote Service Management for PCs, Phones and Embedded


Enjoy

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

From noloader at gmail.com  Mon Apr  4 16:08:56 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 4 Apr 2016 12:08:56 -0400
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <5702903F.9090508@wisemo.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
Message-ID: <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>

> And anyway, this seems to be a case where the genuine
> operator of an e-mail domain is failing to correctly
> authenticate submissions by their own users, which no
> amount of 3rd party automation (other than blacklisting
> the failing provider, in this case gmail) could stop.

Yeah, I'm guessing there was a vulnerability in one of the other
Google services, and that Google service was allowed to make web-based
email submissions on behalf of the user. Classic injection and failure
to validate sessions or parameters...

I'm also guessing Google fixed it because it has stopped.

Jeff

From openssl-users at dukhovni.org  Mon Apr  4 20:40:15 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 4 Apr 2016 20:40:15 +0000
Subject: [openssl-users] Is SHA hashing algorithm reversable?
In-Reply-To: <1459776389932-65408.post@n7.nabble.com>
References: <1459776389932-65408.post@n7.nabble.com>
Message-ID: <20160404204015.GB26423@mournblade.imrryr.org>

On Mon, Apr 04, 2016 at 06:26:29AM -0700, Sugumar wrote:

> I going to use SHA256 algorithm for storing my passwords in secure manner.
> But after reading some documentations related to SHA i come to know it is
> not reversable. 
> Yes hashing means its not reversable only.
> But i saw some online websites giving the original data by reversing the
> hash data.
> is it possible means what is the security of hashing?
> I am totally confused pls clarify my doubt.

Unsalted hashes (regardless of the algorithm) are vulnerable to
rainbow table assisted dictionary attacks.  This is a space/time
tradeoff that makes lookup a bit slower but reduces the storage
cost to manageable levels.

So there is no explicit inversion, just reasonably efficient guess
and compare dictionary attacks.

-- 
	Viktor.

From noloader at gmail.com  Mon Apr  4 20:46:15 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 4 Apr 2016 16:46:15 -0400
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <5702CE88.2000407@forthepolls.org>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org>
Message-ID: <CAH8yC8nLuuiDVBs_RDOU70FQue3TJN09EuUSS=KmGJf8Uc1-5w@mail.gmail.com>

On Mon, Apr 4, 2016 at 4:28 PM, Johann v. Preu?en <jvp at forthepolls.org> wrote:
> i am not certain i understand how it is google's fault that this
> owenevans98|Dawn was able to slip into the listserv database. this is, of
> course, assuming that this was not done via a simple sign-up. i also do not
> understand how prohibiting a posting (content, infra) that obfuscates a
> message within a host of symbols with a net zero percent of prose and 100%
> anchor description is responding to some sort of a "fad". this list is re
> problems and solutions that can only be conveyed in prose ... no prose == no
> message. and permitting private anchors is also a questionable security
> practice. it does not seem unreasonable to require anchors to be to
> recognized sandbox sites or -- much better -- to an openssl-operated one.

Yeah, this particular message looks like classic spam (headers
available at http://groups.google.com/forum/#!original/mailing.openssl.users/eXD0UYueasw/jsZtjTLPCQAJ).

When the spam was getting through, I checked some of the headers and
most were coming from Gmail users. See, for example,
http://pastebin.com/hRAtRt7S. That particular message likely had its
spam score lowered because of the DKIM signing.

I was also contacted offlist for the spam I was sending. I saw the
headers on two of the messages, and they clearly were from me and
submitted through Google's web interface. They looked just like the
headers in http://pastebin.com/hRAtRt7S. I did not send them, and they
did not show up in my Outbox.

Its the reason I'm guessing Google services had a vulnerability that
was silently patched.

Jeff

From jvp at forthepolls.org  Mon Apr  4 21:32:26 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Mon, 4 Apr 2016 14:32:26 -0700
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAH8yC8nLuuiDVBs_RDOU70FQue3TJN09EuUSS=KmGJf8Uc1-5w@mail.gmail.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org>
 <CAH8yC8nLuuiDVBs_RDOU70FQue3TJN09EuUSS=KmGJf8Uc1-5w@mail.gmail.com>
Message-ID: <5702DD6A.5070908@forthepolls.org>

right now our conversation is bi-directional since the listserv is off-line.

i also looked at the headers and they do seem to originate within google itself 
( bogon receipts). so, are you telling me that the mere fact that an email is 
addressed to the list will get it published without verifying that the sender is 
a subscriber?

everything else i mention relate to the needless exposure of the subscriber's 
real name and email addr and the permitting of private anchors. obviously, i 
believe that these practices greatly increase security risks for the subscriber 
and will subject them to a potential flood of noxious junk.

--
Thank you,

Johann v. Preu?en

On 2016.Apr.04 13:46, Jeffrey Walton wrote:
> On Mon, Apr 4, 2016 at 4:28 PM, Johann v. Preu?en <jvp at forthepolls.org> wrote:
>> i am not certain i understand how it is google's fault that this
>> owenevans98|Dawn was able to slip into the listserv database. this is, of
>> course, assuming that this was not done via a simple sign-up. i also do not
>> understand how prohibiting a posting (content, infra) that obfuscates a
>> message within a host of symbols with a net zero percent of prose and 100%
>> anchor description is responding to some sort of a "fad". this list is re
>> problems and solutions that can only be conveyed in prose ... no prose == no
>> message. and permitting private anchors is also a questionable security
>> practice. it does not seem unreasonable to require anchors to be to
>> recognized sandbox sites or -- much better -- to an openssl-operated one.
> Yeah, this particular message looks like classic spam (headers
> available at http://groups.google.com/forum/#!original/mailing.openssl.users/eXD0UYueasw/jsZtjTLPCQAJ).
>
> When the spam was getting through, I checked some of the headers and
> most were coming from Gmail users. See, for example,
> http://pastebin.com/hRAtRt7S. That particular message likely had its
> spam score lowered because of the DKIM signing.
>
> I was also contacted offlist for the spam I was sending. I saw the
> headers on two of the messages, and they clearly were from me and
> submitted through Google's web interface. They looked just like the
> headers in http://pastebin.com/hRAtRt7S. I did not send them, and they
> did not show up in my Outbox.
>
> Its the reason I'm guessing Google services had a vulnerability that
> was silently patched.
>
> Jeff


-------------- 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/20160404/ec678b04/attachment-0001.bin>

From jvp at forthepolls.org  Mon Apr  4 20:28:56 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Mon, 4 Apr 2016 13:28:56 -0700
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
Message-ID: <5702CE88.2000407@forthepolls.org>

i am not certain i understand how it is google's fault that this 
owenevans98|Dawn was able to slip into the listserv database. this is, of 
course, assuming that this was not done via a simple sign-up. i also do not 
understand how prohibiting a posting (content, infra) that obfuscates a message 
within a host of symbols with a net zero percent of prose and 100% anchor 
description is responding to some sort of a "fad". this list is re problems and 
solutions that can only be conveyed in prose ... no prose == no message. and 
permitting private anchors is also a questionable security practice. it does not 
seem unreasonable to require anchors to be to _recognized_ sandbox sites or -- 
much better -- to an openssl-operated one.

moreover, as i pointed out in a pm to Steve, this is a real security issue for 
openssl's list in that such a breach (if it is one) opens the names and email 
contact info of a broad range of security-responsible people that will 
invariably include some in the upper regions of the perm chain. these people are 
the very people that are targeted by malicious attempts (and some startling 
successes) to breach much more than an organization's email system.

yes, this person has seemingly stopped with postings, but i am hearing no 
assurance that they have even been eliminated from the subscription database. 
just being able to listen will garner a wealth of sensitive info obtainable re a 
most desirable crowd of people/victims.

even the most simplistic listserv app has the ability to withhold subscriber 
email addr's and still provide a secure pm capability. now that it is 
apparent|perceived that the list is vulnerable, i believe the prudent route to 
go is to keep those addr's and subscriber real-world names out of the 
"limelight". i see no reason why a sanitized subscriber profile available from a 
link within the person's public handle would not be adequate for identification 
purposes and would actually become an enhancement to the listserv app's 
usefulness to subscribers. this would certainly shield the subscriber in a 
reliably meaningful way, serve to protect a subscriber's own email system, and 
enhance the security of openssl's own listserv ops.

--
Thank you,

Johann v. Preu?en

*original anchor description (100% of the message content):*
Attn:__here__is__your___$l??
??
??
__Faceb????k__giftcard.

__W??__N????d__Y????r__Shi??me??t__Inf??rmati????s__

Click_Here

On 2016.Apr.04 09:08, Jeffrey Walton wrote:
>> And anyway, this seems to be a case where the genuine
>> operator of an e-mail domain is failing to correctly
>> authenticate submissions by their own users, which no
>> amount of 3rd party automation (other than blacklisting
>> the failing provider, in this case gmail) could stop.
> Yeah, I'm guessing there was a vulnerability in one of the other
> Google services, and that Google service was allowed to make web-based
> email submissions on behalf of the user. Classic injection and failure
> to validate sessions or parameters...
>
> I'm also guessing Google fixed it because it has stopped.
>
> Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160404/0de1ecea/attachment.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/20160404/0de1ecea/attachment.bin>

From abe.racioppo at gmail.com  Mon Apr  4 22:18:25 2016
From: abe.racioppo at gmail.com (Abe Racioppo)
Date: Mon, 4 Apr 2016 18:18:25 -0400
Subject: [openssl-users] CMS with Symmetric key
Message-ID: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>

Hey guys,

I'm trying to use the CMS operations in libcrypto but with a symmetric key
encryption key instead of x509.

I'm thinking I want to use a combination of

CMS_RecipientInfo_set0_pkey,
SMIME_write_CMS,
and
CMS_EncryptedData_encrypt.

Has anyone done this before and can give me some direction?  This is my
first time working with openssl and am getting kinda lost.

Thanks,

Abe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160404/072c4c6f/attachment.html>

From jvp at forthepolls.org  Mon Apr  4 22:21:23 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Mon, 4 Apr 2016 15:21:23 -0700
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <CAH8yC8mMZOGFcB3-nU084=s+pUjdrKwpYoWpE6ynpyd13SNPDg@mail.gmail.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org>
 <CAH8yC8nLuuiDVBs_RDOU70FQue3TJN09EuUSS=KmGJf8Uc1-5w@mail.gmail.com>
 <5702DD6A.5070908@forthepolls.org>
 <CAH8yC8mMZOGFcB3-nU084=s+pUjdrKwpYoWpE6ynpyd13SNPDg@mail.gmail.com>
Message-ID: <5702E8E3.7000607@forthepolls.org>

if this list was for tex-mex cooking recipes or ES vacation rentals, i would 
agree that expectations for privacy might be very low and individual subscribers 
are responsible to be as circumspect as they personally feel they must be.

however, this is a list of people in the fore-front of addressing global 
security issues and -- i would think -- subscribers would certainly want their 
personal info (U.S. Title XIII PII) to be as secure as the issues they are 
grappling with rather than having it published in the clear. the security issue 
re the subscriber email addr spreads beyond the actual person as well. suppose 
we have henrietta schmidt who is the email security officer for xyz corp who is 
addressed as h.schmidt at xyz.com. since most large firms and almost all gov 
agencies have rigid mailbox addressing schemes, it is quite possible to 
extrapolate from this one email addr to a much wider range. like xyz's CIO joe 
blow who is most likely to be found at j.blow at xyz.com or some close variant.

the payoffs for the successful breaching of systems of large firms and 
governments is huge and it does not require much imagination to deduce that the 
pantheon of perpetrators is large, their diligence is intense, and their numbers 
are not confined to a bunch of "script kiddies". quite plainly, i do not believe 
that openssl should be making their job easier.

--
Thank you,

Johann v. Preu?en

On 2016.Apr.04 14:49, Jeffrey Walton wrote:
> On Mon, Apr 4, 2016 at 5:32 PM, Johann v. Preu?en <jvp at forthepolls.org> wrote:
>> right now our conversation is bi-directional since the listserv is off-line.
>>
>> i also looked at the headers and they do seem to originate within google
>> itself ( bogon receipts). so, are you telling me that the mere fact that an
>> email is addressed to the list will get it published without verifying that
>> the sender is a subscriber?
>>
>> everything else i mention relate to the needless exposure of the
>> subscriber's real name and email addr and the permitting of private anchors.
>> obviously, i believe that these practices greatly increase security risks
>> for the subscriber and will subject them to a potential flood of noxious
>> junk.
> Yes, I agree Johann. The thing I would point out is there's usually no
> expectation of privacy with a mailing list, so users should not be
> surprised if their email address shows up in a traditional email
> header or an X-header somewhere.
>
> What piqued my interest was that sudden spurt of spam. Something was
> not right, but I could not finger it.
>
> Jeff


-------------- 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/20160404/60486efa/attachment-0001.bin>

From jb-openssl at wisemo.com  Mon Apr  4 22:36:25 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 5 Apr 2016 00:36:25 +0200
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <5702CE88.2000407@forthepolls.org>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org>
Message-ID: <5702EC69.3080303@wisemo.com>

On 04/04/2016 22:28, Johann v. Preu?en wrote:
> i am not certain i understand how it is google's fault that this 
> owenevans98|Dawn was able to slip into the listserv database. this is, 
> of course, assuming that this was not done via a simple sign-up. i 
> also do not understand how prohibiting a posting (content, infra) that 
> obfuscates a message within a host of symbols with a net zero percent 
> of prose and 100% anchor description is responding to some sort of a 
> "fad". this list is re problems and solutions that can only be 
> conveyed in prose ... no prose == no message. and permitting private 
> anchors is also a questionable security practice. it does not seem 
> unreasonable to require anchors to be to _recognized_ sandbox sites or 
> -- much better -- to an openssl-operated one.
>
No one (until about 2 hours ago) were discussing how the
particular "From" address got past the "you must be
subscribed to post" filter, maybe the spoofed From address
happened to be a subscriber, maybe there is a bug in the
list management software or configuration.

There was discussion of which generic "hard-reject" filters
should be applied and someone suggested prematurely
applying a number of recently "trendy" such rules promoted
by (ironically in this case) Google and others.  I was the
one who used the word "fad" to refer to such recently
promoted "hard-reject" rules and pointed out that many
smaller organizations will be unable to cause legitimate
mail/postings to comply with such rules anytime soon,
simply because it takes time to roll out new protocols to
all the worlds legitimate e-mail sending servers.

As for the suggestion to forbid links to servers other than
OpenSSL.org servers, this will be fatally flawed as it will
block discussions of such common OpenSSL related topics as:

- URLs of published security research (such as the home
  pages of new vulnerability descriptions).

- URLs of sites that publish OpenSSL related software, such
  as OpenSSH, stunnel, the Shining Light Windows binaries of
  OpenSSL etc.

- URLs that are showing interoperability problems with
  OpenSSL.

- URLs of independently published OpenSSL patches (that
  have not yet been accepted into the OpenSSL repositories).

- URLs necessitated by the byzantine legal rules regarding
  which web servers are allowed to publish cryptographic
  software written by which people for use by which other
  people.

These categories of non-openssl.org URLs occur frequently
in legitimate posts to this list and cannot be replaced by
some private openssl.org hosted equivalent of pastebin.com
etc.


> moreover, as i pointed out in a pm to Steve, this is a real security 
> issue for openssl's list in that such a breach (if it is one) opens 
> the names and email contact info of a broad range of 
> security-responsible people that will invariably include some in the 
> upper regions of the perm chain. these people are the very people that 
> are targeted by malicious attempts (and some startling successes) to 
> breach much more than an organization's email system.
You are now going way outside anything discussed previously,
please enlighten the list as to what you are possibly
talking about here.

So far the only known breach is an apparent breach of
*Google owned* e-mail servers, allowing perfect spoofing
of gmail.com addresses by causing the fake mail to be
sent by *exactly* the same servers with *exactly* the
same headers as legitimate mails by the legitimate user of
the spoofed e-mail address.

This does not expose any of the names of any e-mail
addresses stored by the OpenSSL organization, unless
that data can be extracted by e-mailing a command to
listserv from a spoofed administrator e-mail address and
any of those administrator e-mail addresses are actually
hosted by Google.

>
> yes, this person has seemingly stopped with postings, but i am hearing 
> no assurance that they have even been eliminated from the subscription 
> database. just being able to listen will garner a wealth of sensitive 
> info obtainable re a most desirable crowd of people/victims.
>
Posts by others indicate that the *spoofing* activity
seemed to have stopped for multiple gmail addresses,
including the e-mail address of one person posting such
an observation, indicating a likelihood that Google fixed
the underlying security issue.



> even the most simplistic listserv app has the ability to withhold 
> subscriber email addr's and still provide a secure pm capability. now 
> that it is apparent|perceived that the list is vulnerable, i believe 
> the prudent route to go is to keep those addr's and subscriber 
> real-world names out of the "limelight". i see no reason why a 
> sanitized subscriber profile available from a link within the person's 
> public handle would not be adequate for identification purposes and 
> would actually become an enhancement to the listserv app's usefulness 
> to subscribers. this would certainly shield the subscriber in a 
> reliably meaningful way, serve to protect a subscriber's own email 
> system, and enhance the security of openssl's own listserv ops.
The issue that the FROM addresses of OpenSSL e-mail list posters
(not other subscribers) can be seen by anyone receiving or
otherwise finding their postings is age-old and completely
unrelated to any issue related to this discussion (the spammer
in this case obviously did not know that this was a mailing
list, given the incorrect textual name used with the list
SMTP address).

Even if OpenSSL were to switch to a surveillance vulnerable
design where PMs between users would have to go through the
OpenSSL servers, the list administrators will probably remain
reachable using well known mandatory e-mail addresses such as
"Postmaster".  A similar issue would apply to most of the other
high value subscribers.

Any such people would already be required (in order to perform
their function safely at all) to employ security measures to
isolate their publicly known e-mail addresses from any e-mail
addresses that are not intended to be publicly known.  As an
example, all my (non-blocked) postings on this list use a
dedicated mail address and mail box which allows me to dismiss
e-mails on other subjects to this address as Spam while not
exposing other e-mail addresses used for more trusted uses, and
I obviously employ similar measures for any well known role
accounts I handle myself.



> *original anchor description (100% of the message content):*
> Attn:__here__is__your___$l??
??
??
__Faceb????k__giftcard.
>
> __W??__N????d__Y????r__Shi??me??t__Inf??rmati????s__
>
> Click_Here
>
> On 2016.Apr.04 09:08, Jeffrey Walton wrote:
>>> And anyway, this seems to be a case where the genuine
>>> operator of an e-mail domain is failing to correctly
>>> authenticate submissions by their own users, which no
>>> amount of 3rd party automation (other than blacklisting
>>> the failing provider, in this case gmail) could stop.
>> Yeah, I'm guessing there was a vulnerability in one of the other
>> Google services, and that Google service was allowed to make web-based
>> email submissions on behalf of the user. Classic injection and failure
>> to validate sessions or parameters...
>>
>> I'm also guessing Google fixed it because it has stopped.

Enjoy

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

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

From jb-openssl at wisemo.com  Mon Apr  4 22:42:15 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 5 Apr 2016 00:42:15 +0200
Subject: [openssl-users] CMS with Symmetric key
In-Reply-To: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
References: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
Message-ID: <5702EDC7.7060100@wisemo.com>

On 05/04/2016 00:18, Abe Racioppo wrote:
> Hey guys,
>
> I'm trying to use the CMS operations in libcrypto but with a symmetric 
> key encryption key instead of x509.
>
> I'm thinking I want to use a combination of
>
> CMS_RecipientInfo_set0_pkey,
> SMIME_write_CMS,
> and
> CMS_EncryptedData_encrypt.
>
> Has anyone done this before and can give me some direction?  This is 
> my first time working with openssl and am getting kinda lost.
>
The "CMS" operations implement the "CMS" standard, formerly
known as PKCS#7, which is based entirely on the use of X.509
certificates.

Unless you can point out a clause in the "CMS" format RFCs
that allow use without X.509 certificates, there is no reason
why the "CMS" part of the OpenSSL library should be able to
any such thing.

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 wiml at omnigroup.com  Mon Apr  4 22:58:04 2016
From: wiml at omnigroup.com (Wim Lewis)
Date: Mon, 4 Apr 2016 15:58:04 -0700
Subject: [openssl-users] CMS with Symmetric key
In-Reply-To: <5702EDC7.7060100@wisemo.com>
References: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
 <5702EDC7.7060100@wisemo.com>
Message-ID: <761210CD-57EC-4EAE-A285-D8347C8C4EC1@omnigroup.com>


On Apr 4, 2016, at 3:42 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> Unless you can point out a clause in the "CMS" format RFCs
> that allow use without X.509 certificates, there is no reason
> why the "CMS" part of the OpenSSL library should be able to
> any such thing.

The CMS RFC (RFC 5652) specifies password based key derivation (in addition to asymmetric-key crypto key transport or agreement, and also a symmetric-cryptography key transport mechanism). See section 6.2.

It looks like password based key derivation wasn't in the original PKCS#7, but was introduced in a 2001 specification (RFC 3211) and was folded into the 2002 revision of CMS (RFC 3369).



From jvp at forthepolls.org  Mon Apr  4 23:47:08 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Mon, 4 Apr 2016 16:47:08 -0700
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <5702EC69.3080303@wisemo.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
Message-ID: <5702FCFC.70409@forthepolls.org>

'/No one (until about 2 hours ago) were discussing how the //
//particular "From" address got past the "you must be //
//subscribed to post" filter/'
actually, i first posted on this issue c. 76 hours ago.

'/maybe the spoofed From address happened to be a subscriber/'
is it possible that openssl still does not know if the email addr is a real 
subscriber?

'/maybe there is a bug in the list management software or configuration/'
yes, i surely hope someone is looking into this possibility.

further, not only was owenevans98 able to post an original message (the subject 
of this thread), but there was a subsequent posting in reply to another thread. 
thus, the conclusion that owenevans98 was not only able to post but was|is 
receiving the listserv mailings is self-evident. the fact that this two-way comm 
path came into existence means that the listserv database was corrupted and that 
the original posting was not some slip-up in permitting an un-authorized 
one-time posting.

jakob, i appreciate your taking of the time to detail some of openssl's listserv 
practices and view-points. perhaps it is best to set forth the synopses of my views:

 1. make certain ' owenevans98' and any other illegitimate posters are not
    receiving listserv mailings;
 2. stop publishing the subscriber's protected PII in the clear; and
 3. control postings of anchors.

according to your comment quoted, supra, it seems that the step indicated in 
Item 1 has yet to be taken.

Item 2 can be implemented by inaugurating a subscriber-managed profile and 
merely publishing a user handle linked thereto. thus, you can shift the onus to 
the subscriber to reveal whatever info they wish rather than arbitrarily 
exposing to the world a subscriber's personal name, email addr, and work-force 
association.

in the case of Item 3, i understand all of the reasons for having links (not 
html anchors) in postings. it is a very minor inconvenience for someone who has  
a burning interest in viewing a link to copy the clear-text link into a browser 
versus clicking on an anchor description which could lead the subscriber far 
astray from what the description says. it also enhances the subscriber 
experience to visually see where the link is going instead of having the actual 
target obscured by a description that may be deceptive, merely misleading, or 
non-apparent (i.e., 'click here').

jakob, you also mention concern re MTA operators having some issues with changes 
you may make to the listserv ops. please note: none of the three (3) items, 
supra, i have suggested have any impact on other MTA operators as they are 
totally internal-control enhancement proc's.

i cannot understand why openssl's filtering missed the fact that the posting 
that is subject of this thread predominated in symbols and control characters, 
contained no actual message text, and still went through. hopefully, someone is 
also looking into why this happened.

--
Thank you,

Johann v. Preu?en

On 2016.Apr.04 15:36, Jakob Bohm wrote:
> On 04/04/2016 22:28, Johann v. Preu?en wrote:
>> i am not certain i understand how it is google's fault that this 
>> owenevans98|Dawn was able to slip into the listserv database. this is, of 
>> course, assuming that this was not done via a simple sign-up. i also do not 
>> understand how prohibiting a posting (content, infra) that obfuscates a 
>> message within a host of symbols with a net zero percent of prose and 100% 
>> anchor description is responding to some sort of a "fad". this list is re 
>> problems and solutions that can only be conveyed in prose ... no prose == no 
>> message. and permitting private anchors is also a questionable security 
>> practice. it does not seem unreasonable to require anchors to be to 
>> _recognized_ sandbox sites or -- much better -- to an openssl-operated one.
>>
> No one (until about 2 hours ago) were discussing how the
> particular "From" address got past the "you must be
> subscribed to post" filter, maybe the spoofed From address
> happened to be a subscriber, maybe there is a bug in the
> list management software or configuration.
>
> There was discussion of which generic "hard-reject" filters
> should be applied and someone suggested prematurely
> applying a number of recently "trendy" such rules promoted
> by (ironically in this case) Google and others.  I was the
> one who used the word "fad" to refer to such recently
> promoted "hard-reject" rules and pointed out that many
> smaller organizations will be unable to cause legitimate
> mail/postings to comply with such rules anytime soon,
> simply because it takes time to roll out new protocols to
> all the worlds legitimate e-mail sending servers.
>
> As for the suggestion to forbid links to servers other than
> OpenSSL.org servers, this will be fatally flawed as it will
> block discussions of such common OpenSSL related topics as:
>
> - URLs of published security research (such as the home
>  pages of new vulnerability descriptions).
>
> - URLs of sites that publish OpenSSL related software, such
>  as OpenSSH, stunnel, the Shining Light Windows binaries of
>  OpenSSL etc.
>
> - URLs that are showing interoperability problems with
>  OpenSSL.
>
> - URLs of independently published OpenSSL patches (that
>  have not yet been accepted into the OpenSSL repositories).
>
> - URLs necessitated by the byzantine legal rules regarding
>  which web servers are allowed to publish cryptographic
>  software written by which people for use by which other
>  people.
>
> These categories of non-openssl.org URLs occur frequently
> in legitimate posts to this list and cannot be replaced by
> some private openssl.org hosted equivalent of pastebin.com
> etc.
>
>
>> moreover, as i pointed out in a pm to Steve, this is a real security issue 
>> for openssl's list in that such a breach (if it is one) opens the names and 
>> email contact info of a broad range of security-responsible people that will 
>> invariably include some in the upper regions of the perm chain. these people 
>> are the very people that are targeted by malicious attempts (and some 
>> startling successes) to breach much more than an organization's email system.
> You are now going way outside anything discussed previously,
> please enlighten the list as to what you are possibly
> talking about here.
>
> So far the only known breach is an apparent breach of
> *Google owned* e-mail servers, allowing perfect spoofing
> of gmail.com addresses by causing the fake mail to be
> sent by *exactly* the same servers with *exactly* the
> same headers as legitimate mails by the legitimate user of
> the spoofed e-mail address.
>
> This does not expose any of the names of any e-mail
> addresses stored by the OpenSSL organization, unless
> that data can be extracted by e-mailing a command to
> listserv from a spoofed administrator e-mail address and
> any of those administrator e-mail addresses are actually
> hosted by Google.
>
>>
>> yes, this person has seemingly stopped with postings, but i am hearing no 
>> assurance that they have even been eliminated from the subscription database. 
>> just being able to listen will garner a wealth of sensitive info obtainable 
>> re a most desirable crowd of people/victims.
>>
> Posts by others indicate that the *spoofing* activity
> seemed to have stopped for multiple gmail addresses,
> including the e-mail address of one person posting such
> an observation, indicating a likelihood that Google fixed
> the underlying security issue.
>
>
>
>> even the most simplistic listserv app has the ability to withhold subscriber 
>> email addr's and still provide a secure pm capability. now that it is 
>> apparent|perceived that the list is vulnerable, i believe the prudent route 
>> to go is to keep those addr's and subscriber real-world names out of the 
>> "limelight". i see no reason why a sanitized subscriber profile available 
>> from a link within the person's public handle would not be adequate for 
>> identification purposes and would actually become an enhancement to the 
>> listserv app's usefulness to subscribers. this would certainly shield the 
>> subscriber in a reliably meaningful way, serve to protect a subscriber's own 
>> email system, and enhance the security of openssl's own listserv ops.
> The issue that the FROM addresses of OpenSSL e-mail list posters
> (not other subscribers) can be seen by anyone receiving or
> otherwise finding their postings is age-old and completely
> unrelated to any issue related to this discussion (the spammer
> in this case obviously did not know that this was a mailing
> list, given the incorrect textual name used with the list
> SMTP address).
>
> Even if OpenSSL were to switch to a surveillance vulnerable
> design where PMs between users would have to go through the
> OpenSSL servers, the list administrators will probably remain
> reachable using well known mandatory e-mail addresses such as
> "Postmaster".  A similar issue would apply to most of the other
> high value subscribers.
>
> Any such people would already be required (in order to perform
> their function safely at all) to employ security measures to
> isolate their publicly known e-mail addresses from any e-mail
> addresses that are not intended to be publicly known.  As an
> example, all my (non-blocked) postings on this list use a
> dedicated mail address and mail box which allows me to dismiss
> e-mails on other subjects to this address as Spam while not
> exposing other e-mail addresses used for more trusted uses, and
> I obviously employ similar measures for any well known role
> accounts I handle myself.
>
>
>
>> *original anchor description (100% of the message content):*
>> Attn:__here__is__your___$l??
??
??
__Faceb????k__giftcard.
>>
>> __W??__N????d__Y????r__Shi??me??t__Inf??rmati????s__
>>
>> Click_Here
>>
>> On 2016.Apr.04 09:08, Jeffrey Walton wrote:
>>>> And anyway, this seems to be a case where the genuine
>>>> operator of an e-mail domain is failing to correctly
>>>> authenticate submissions by their own users, which no
>>>> amount of 3rd party automation (other than blacklisting
>>>> the failing provider, in this case gmail) could stop.
>>> Yeah, I'm guessing there was a vulnerability in one of the other
>>> Google services, and that Google service was allowed to make web-based
>>> email submissions on behalf of the user. Classic injection and failure
>>> to validate sessions or parameters...
>>>
>>> I'm also guessing Google fixed it because it has stopped.
> Enjoy
>
> Jakob
> -- 
> Jakob Bohm, CIO, Partner, WiseMo A/S.https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160404/b2450cc1/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/20160404/b2450cc1/attachment-0001.bin>

From jb-openssl at wisemo.com  Tue Apr  5 00:39:29 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 5 Apr 2016 02:39:29 +0200
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <5702FCFC.70409@forthepolls.org>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
 <5702FCFC.70409@forthepolls.org>
Message-ID: <57030941.4020301@wisemo.com>

On 05/04/2016 01:47, Johann v. Preu?en wrote:
> '/No one (until about 2 hours ago) were discussing how the //
> //particular "From" address got past the "you must be //
> //subscribed to post" filter/'
> actually, i first posted on this issue c. 76 hours ago.
>

Not in this thread on openssl-users as far as I can tell.


> '/maybe the spoofed From address happened to be a subscriber/'
> is it possible that openssl still does not know if the email addr is a
> real subscriber?
>

I have no way of knowing since I am not one of the list admins.

> '/maybe there is a bug in the list management software or configuration/'
> yes, i surely hope someone is looking into this possibility.
>
> further, not only was owenevans98 able to post an original message (the
> subject of this thread), but there was a subsequent posting in reply to
> another thread. thus, the conclusion that owenevans98 was not only able
> to post but was|is receiving the listserv mailings is self-evident. the
> fact that this two-way comm path came into existence means that the
> listserv database was corrupted and that the original posting was not
> some slip-up in permitting an un-authorized one-time posting.

Which other thread was that?

>
> jakob, i appreciate your taking of the time to detail some of openssl's
> listserv practices and view-points. perhaps it is best to set forth the
> synopses of my views:

I am not a list admin or other official team member, I am just an
active list member who wants to avoid the list admins following bad
advice from people like you and Ben Humpert.

>
>  1. make certain ' owenevans98' and any other illegitimate posters are
>     not receiving listserv mailings;

Question is if owenevans97 is an illegitimate poster or a legitimate
poster whose e-mail address was spoofed.

Anyway, the OpenSSL mailings are all being indexed on the world wide
web by multiple organizations, where anyone can read them.

>  2. stop publishing the subscriber's protected PII in the clear; and

Again, I see no sign this is happening other than the age-old inclusion
of original from and reply addresses in postings (which is limited to
those who post, and doesn't affect those who only subscribe).

>  3. control postings of anchors.
>

I disagree.  A number of e-mail clients (MUAs) automatically turn
textual URLs into anchors and make it very difficult (if not
impossible) for the posting user to avoid this.  And people
professional enough to understand most of the stuff on OpenSSL mailing
list also know not to click on links in strange e-mails and forum posts.


> according to your comment quoted, supra, it seems that the step
> indicated in Item 1 has yet to be taken.

I wouldn't know.

>
> Item 2 can be implemented by inaugurating a subscriber-managed profile
> and merely publishing a user handle linked thereto. thus, you can shift
> the onus to the subscriber to reveal whatever info they wish rather than
> arbitrarily exposing to the world a subscriber's personal name, email
> addr, and work-force association.

Did you read and understand any of that which I wrote, or
are you just trolling?

>
> in the case of Item 3, i understand all of the reasons for having links
> (not html anchors) in postings. it is a very minor inconvenience for
> someone who has  a burning interest in viewing a link to copy the
> clear-text link into a browser versus clicking on an anchor description
> which could lead the subscriber far astray from what the description
> says. it also enhances the subscriber experience to visually see where
> the link is going instead of having the actual target obscured by a
> description that may be deceptive, merely misleading, or non-apparent
> (i.e., 'click here').
>
> jakob, you also mention concern re MTA operators having some issues with
> changes you may make to the listserv ops. please note: none of the three
> (3) items, supra, i have suggested have any impact on other MTA
> operators as they are totally internal-control enhancement proc's.

I am an MTA operator, I am not a listserv op.  I was posting concerns I
have as an MTA operator and list member with stupid changes suggested
by you and Ben Humpert.

>
> i cannot understand why openssl's filtering missed the fact that the
> posting that is subject of this thread predominated in symbols and
> control characters, contained no actual message text, and still went
> through. hopefully, someone is also looking into why this happened.
>

Did you read the brief but very clear message posted on 2016-04-02
15:24 UTC by Rich Salz (who is an OpenSSL team member and may have
access to the listserv configuration details not published to avoid
helping spammers)?


P.S.

Please don't CC list members on replies to the list, it causes
duplicate copies to reach them (since list membership is required to
post to the list anyway).

>
> On 2016.Apr.04 15:36, Jakob Bohm wrote:
>> On 04/04/2016 22:28, Johann v. Preu?en wrote:
>>> i am not certain i understand how it is google's fault that this
>>> owenevans98|Dawn was able to slip into the listserv database. this
>>> is, of course, assuming that this was not done via a simple sign-up.
>>> i also do not understand how prohibiting a posting (content, infra)
>>> that obfuscates a message within a host of symbols with a net zero
>>> percent of prose and 100% anchor description is responding to some
>>> sort of a "fad". this list is re problems and solutions that can only
>>> be conveyed in prose ... no prose == no message. and permitting
>>> private anchors is also a questionable security practice. it does not
>>> seem unreasonable to require anchors to be to _recognized_ sandbox
>>> sites or -- much better -- to an openssl-operated one.
>>>
>> No one (until about 2 hours ago) were discussing how the
>> particular "From" address got past the "you must be
>> subscribed to post" filter, maybe the spoofed From address
>> happened to be a subscriber, maybe there is a bug in the
>> list management software or configuration.
>>
>> There was discussion of which generic "hard-reject" filters
>> should be applied and someone suggested prematurely
>> applying a number of recently "trendy" such rules promoted
>> by (ironically in this case) Google and others.  I was the
>> one who used the word "fad" to refer to such recently
>> promoted "hard-reject" rules and pointed out that many
>> smaller organizations will be unable to cause legitimate
>> mail/postings to comply with such rules anytime soon,
>> simply because it takes time to roll out new protocols to
>> all the worlds legitimate e-mail sending servers.
>>
>> As for the suggestion to forbid links to servers other than
>> OpenSSL.org servers, this will be fatally flawed as it will
>> block discussions of such common OpenSSL related topics as:
>>
>> - URLs of published security research (such as the home
>>  pages of new vulnerability descriptions).
>>
>> - URLs of sites that publish OpenSSL related software, such
>>  as OpenSSH, stunnel, the Shining Light Windows binaries of
>>  OpenSSL etc.
>>
>> - URLs that are showing interoperability problems with
>>  OpenSSL.
>>
>> - URLs of independently published OpenSSL patches (that
>>  have not yet been accepted into the OpenSSL repositories).
>>
>> - URLs necessitated by the byzantine legal rules regarding
>>  which web servers are allowed to publish cryptographic
>>  software written by which people for use by which other
>>  people.
>>
>> These categories of non-openssl.org URLs occur frequently
>> in legitimate posts to this list and cannot be replaced by
>> some private openssl.org hosted equivalent of pastebin.com
>> etc.
>>
>>
>>> moreover, as i pointed out in a pm to Steve, this is a real security
>>> issue for openssl's list in that such a breach (if it is one) opens
>>> the names and email contact info of a broad range of
>>> security-responsible people that will invariably include some in the
>>> upper regions of the perm chain. these people are the very people
>>> that are targeted by malicious attempts (and some startling
>>> successes) to breach much more than an organization's email system.
>> You are now going way outside anything discussed previously,
>> please enlighten the list as to what you are possibly
>> talking about here.
>>
>> So far the only known breach is an apparent breach of
>> *Google owned* e-mail servers, allowing perfect spoofing
>> of gmail.com addresses by causing the fake mail to be
>> sent by *exactly* the same servers with *exactly* the
>> same headers as legitimate mails by the legitimate user of
>> the spoofed e-mail address.
>>
>> This does not expose any of the names of any e-mail
>> addresses stored by the OpenSSL organization, unless
>> that data can be extracted by e-mailing a command to
>> listserv from a spoofed administrator e-mail address and
>> any of those administrator e-mail addresses are actually
>> hosted by Google.
>>
>>>
>>> yes, this person has seemingly stopped with postings, but i am
>>> hearing no assurance that they have even been eliminated from the
>>> subscription database. just being able to listen will garner a wealth
>>> of sensitive info obtainable re a most desirable crowd of people/victims.
>>>
>> Posts by others indicate that the *spoofing* activity
>> seemed to have stopped for multiple gmail addresses,
>> including the e-mail address of one person posting such
>> an observation, indicating a likelihood that Google fixed
>> the underlying security issue.
>>
>>
>>
>>> even the most simplistic listserv app has the ability to withhold
>>> subscriber email addr's and still provide a secure pm capability. now
>>> that it is apparent|perceived that the list is vulnerable, i believe
>>> the prudent route to go is to keep those addr's and subscriber
>>> real-world names out of the "limelight". i see no reason why a
>>> sanitized subscriber profile available from a link within the
>>> person's public handle would not be adequate for identification
>>> purposes and would actually become an enhancement to the listserv
>>> app's usefulness to subscribers. this would certainly shield the
>>> subscriber in a reliably meaningful way, serve to protect a
>>> subscriber's own email system, and enhance the security of openssl's
>>> own listserv ops.
>> The issue that the FROM addresses of OpenSSL e-mail list posters
>> (not other subscribers) can be seen by anyone receiving or
>> otherwise finding their postings is age-old and completely
>> unrelated to any issue related to this discussion (the spammer
>> in this case obviously did not know that this was a mailing
>> list, given the incorrect textual name used with the list
>> SMTP address).
>>
>> Even if OpenSSL were to switch to a surveillance vulnerable
>> design where PMs between users would have to go through the
>> OpenSSL servers, the list administrators will probably remain
>> reachable using well known mandatory e-mail addresses such as
>> "Postmaster".  A similar issue would apply to most of the other
>> high value subscribers.
>>
>> Any such people would already be required (in order to perform
>> their function safely at all) to employ security measures to
>> isolate their publicly known e-mail addresses from any e-mail
>> addresses that are not intended to be publicly known.  As an
>> example, all my (non-blocked) postings on this list use a
>> dedicated mail address and mail box which allows me to dismiss
>> e-mails on other subjects to this address as Spam while not
>> exposing other e-mail addresses used for more trusted uses, and
>> I obviously employ similar measures for any well known role
>> accounts I handle myself.
>>
>>
>>
>>> *original anchor description (100% of the message content):*
>>> Attn:__here__is__your___$l??
??
??
__Faceb????k__giftcard.
>>>
>>> __W??__N????d__Y????r__Shi??me??t__Inf??rmati????s__
>>>
>>> Click_Here
>>>
>>> On 2016.Apr.04 09:08, Jeffrey Walton wrote:
>>>>> And anyway, this seems to be a case where the genuine
>>>>> operator of an e-mail domain is failing to correctly
>>>>> authenticate submissions by their own users, which no
>>>>> amount of 3rd party automation (other than blacklisting
>>>>> the failing provider, in this case gmail) could stop.
>>>> Yeah, I'm guessing there was a vulnerability in one of the other
>>>> Google services, and that Google service was allowed to make web-based
>>>> email submissions on behalf of the user. Classic injection and failure
>>>> to validate sessions or parameters...
>>>>
>>>> I'm also guessing Google fixed it because it has stopped.
>>



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 pgnet.dev at gmail.com  Tue Apr  5 00:42:52 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Mon, 4 Apr 2016 17:42:52 -0700
Subject: [openssl-users] Fwd: CONGRATULATION____REF#87670
In-Reply-To: <57030941.4020301@wisemo.com>
References: <2.1.2.1101043641.1923853.16665969690@gardensalive1.wc09.net>
 <CAJwAjj3n_rOA8nk2V_gUDFnet3jk8E1VznXTkfQy6GRz+YfjZg@gardensalive1.wc09.net>
 <CAH32DDhk0SS0Vq3f+g7=bJdiZD3n_inf019J+gd4jE72yLMdHA@mail.gmail.com>
 <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
 <5702FCFC.70409@forthepolls.org> <57030941.4020301@wisemo.com>
Message-ID: <cd67aaec-a0cc-0261-17f8-a7ed6c23f32e@gmail.com>

Is there nowhere else this interminable thread can be taken?  Some of us 
actually subscribe to this list to actually follow *openssl* use & issues.

Take it up with the list admins directly?

On 04/04/2016 05:39 PM, Jakob Bohm wrote:
> On 05/04/2016 01:47, Johann v. Preu?en wrote:
>> '/No one (until about 2 hours ago) were discussing how the //
>> //particular "From" address got past the "you must be //
>> //subscribed to post" filter/'
>> actually, i first posted on this issue c. 76 hours ago.
>>
>
> Not in this thread on openssl-users as far as I can tell.
>
>
>> '/maybe the spoofed From address happened to be a subscriber/'
>> is it possible that openssl still does not know if the email addr is a
>> real subscriber?
>>
>
> I have no way of knowing since I am not one of the list admins.
>
>> '/maybe there is a bug in the list management software or configuration/'
>> yes, i surely hope someone is looking into this possibility.
>>
>> further, not only was owenevans98 able to post an original message (the
>> subject of this thread), but there was a subsequent posting in reply to
>> another thread. thus, the conclusion that owenevans98 was not only able
>> to post but was|is receiving the listserv mailings is self-evident. the
>> fact that this two-way comm path came into existence means that the
>> listserv database was corrupted and that the original posting was not
>> some slip-up in permitting an un-authorized one-time posting.
>
> Which other thread was that?
>
>>
>> jakob, i appreciate your taking of the time to detail some of openssl's
>> listserv practices and view-points. perhaps it is best to set forth the
>> synopses of my views:
>
> I am not a list admin or other official team member, I am just an
> active list member who wants to avoid the list admins following bad
> advice from people like you and Ben Humpert.
>
>>
>>  1. make certain ' owenevans98' and any other illegitimate posters are
>>     not receiving listserv mailings;
>
> Question is if owenevans97 is an illegitimate poster or a legitimate
> poster whose e-mail address was spoofed.
>
> Anyway, the OpenSSL mailings are all being indexed on the world wide
> web by multiple organizations, where anyone can read them.
>
>>  2. stop publishing the subscriber's protected PII in the clear; and
>
> Again, I see no sign this is happening other than the age-old inclusion
> of original from and reply addresses in postings (which is limited to
> those who post, and doesn't affect those who only subscribe).
>
>>  3. control postings of anchors.
>>
>
> I disagree.  A number of e-mail clients (MUAs) automatically turn
> textual URLs into anchors and make it very difficult (if not
> impossible) for the posting user to avoid this.  And people
> professional enough to understand most of the stuff on OpenSSL mailing
> list also know not to click on links in strange e-mails and forum posts.
>
>
>> according to your comment quoted, supra, it seems that the step
>> indicated in Item 1 has yet to be taken.
>
> I wouldn't know.
>
>>
>> Item 2 can be implemented by inaugurating a subscriber-managed profile
>> and merely publishing a user handle linked thereto. thus, you can shift
>> the onus to the subscriber to reveal whatever info they wish rather than
>> arbitrarily exposing to the world a subscriber's personal name, email
>> addr, and work-force association.
>
> Did you read and understand any of that which I wrote, or
> are you just trolling?
>
>>
>> in the case of Item 3, i understand all of the reasons for having links
>> (not html anchors) in postings. it is a very minor inconvenience for
>> someone who has  a burning interest in viewing a link to copy the
>> clear-text link into a browser versus clicking on an anchor description
>> which could lead the subscriber far astray from what the description
>> says. it also enhances the subscriber experience to visually see where
>> the link is going instead of having the actual target obscured by a
>> description that may be deceptive, merely misleading, or non-apparent
>> (i.e., 'click here').
>>
>> jakob, you also mention concern re MTA operators having some issues with
>> changes you may make to the listserv ops. please note: none of the three
>> (3) items, supra, i have suggested have any impact on other MTA
>> operators as they are totally internal-control enhancement proc's.
>
> I am an MTA operator, I am not a listserv op.  I was posting concerns I
> have as an MTA operator and list member with stupid changes suggested
> by you and Ben Humpert.
>
>>
>> i cannot understand why openssl's filtering missed the fact that the
>> posting that is subject of this thread predominated in symbols and
>> control characters, contained no actual message text, and still went
>> through. hopefully, someone is also looking into why this happened.
>>
>
> Did you read the brief but very clear message posted on 2016-04-02
> 15:24 UTC by Rich Salz (who is an OpenSSL team member and may have
> access to the listserv configuration details not published to avoid
> helping spammers)?
>
>
> P.S.
>
> Please don't CC list members on replies to the list, it causes
> duplicate copies to reach them (since list membership is required to
> post to the list anyway).
>
>>
>> On 2016.Apr.04 15:36, Jakob Bohm wrote:
>>> On 04/04/2016 22:28, Johann v. Preu?en wrote:
>>>> i am not certain i understand how it is google's fault that this
>>>> owenevans98|Dawn was able to slip into the listserv database. this
>>>> is, of course, assuming that this was not done via a simple sign-up.
>>>> i also do not understand how prohibiting a posting (content, infra)
>>>> that obfuscates a message within a host of symbols with a net zero
>>>> percent of prose and 100% anchor description is responding to some
>>>> sort of a "fad". this list is re problems and solutions that can only
>>>> be conveyed in prose ... no prose == no message. and permitting
>>>> private anchors is also a questionable security practice. it does not
>>>> seem unreasonable to require anchors to be to _recognized_ sandbox
>>>> sites or -- much better -- to an openssl-operated one.
>>>>
>>> No one (until about 2 hours ago) were discussing how the
>>> particular "From" address got past the "you must be
>>> subscribed to post" filter, maybe the spoofed From address
>>> happened to be a subscriber, maybe there is a bug in the
>>> list management software or configuration.
>>>
>>> There was discussion of which generic "hard-reject" filters
>>> should be applied and someone suggested prematurely
>>> applying a number of recently "trendy" such rules promoted
>>> by (ironically in this case) Google and others.  I was the
>>> one who used the word "fad" to refer to such recently
>>> promoted "hard-reject" rules and pointed out that many
>>> smaller organizations will be unable to cause legitimate
>>> mail/postings to comply with such rules anytime soon,
>>> simply because it takes time to roll out new protocols to
>>> all the worlds legitimate e-mail sending servers.
>>>
>>> As for the suggestion to forbid links to servers other than
>>> OpenSSL.org servers, this will be fatally flawed as it will
>>> block discussions of such common OpenSSL related topics as:
>>>
>>> - URLs of published security research (such as the home
>>>  pages of new vulnerability descriptions).
>>>
>>> - URLs of sites that publish OpenSSL related software, such
>>>  as OpenSSH, stunnel, the Shining Light Windows binaries of
>>>  OpenSSL etc.
>>>
>>> - URLs that are showing interoperability problems with
>>>  OpenSSL.
>>>
>>> - URLs of independently published OpenSSL patches (that
>>>  have not yet been accepted into the OpenSSL repositories).
>>>
>>> - URLs necessitated by the byzantine legal rules regarding
>>>  which web servers are allowed to publish cryptographic
>>>  software written by which people for use by which other
>>>  people.
>>>
>>> These categories of non-openssl.org URLs occur frequently
>>> in legitimate posts to this list and cannot be replaced by
>>> some private openssl.org hosted equivalent of pastebin.com
>>> etc.
>>>
>>>
>>>> moreover, as i pointed out in a pm to Steve, this is a real security
>>>> issue for openssl's list in that such a breach (if it is one) opens
>>>> the names and email contact info of a broad range of
>>>> security-responsible people that will invariably include some in the
>>>> upper regions of the perm chain. these people are the very people
>>>> that are targeted by malicious attempts (and some startling
>>>> successes) to breach much more than an organization's email system.
>>> You are now going way outside anything discussed previously,
>>> please enlighten the list as to what you are possibly
>>> talking about here.
>>>
>>> So far the only known breach is an apparent breach of
>>> *Google owned* e-mail servers, allowing perfect spoofing
>>> of gmail.com addresses by causing the fake mail to be
>>> sent by *exactly* the same servers with *exactly* the
>>> same headers as legitimate mails by the legitimate user of
>>> the spoofed e-mail address.
>>>
>>> This does not expose any of the names of any e-mail
>>> addresses stored by the OpenSSL organization, unless
>>> that data can be extracted by e-mailing a command to
>>> listserv from a spoofed administrator e-mail address and
>>> any of those administrator e-mail addresses are actually
>>> hosted by Google.
>>>
>>>>
>>>> yes, this person has seemingly stopped with postings, but i am
>>>> hearing no assurance that they have even been eliminated from the
>>>> subscription database. just being able to listen will garner a wealth
>>>> of sensitive info obtainable re a most desirable crowd of
>>>> people/victims.
>>>>
>>> Posts by others indicate that the *spoofing* activity
>>> seemed to have stopped for multiple gmail addresses,
>>> including the e-mail address of one person posting such
>>> an observation, indicating a likelihood that Google fixed
>>> the underlying security issue.
>>>
>>>
>>>
>>>> even the most simplistic listserv app has the ability to withhold
>>>> subscriber email addr's and still provide a secure pm capability. now
>>>> that it is apparent|perceived that the list is vulnerable, i believe
>>>> the prudent route to go is to keep those addr's and subscriber
>>>> real-world names out of the "limelight". i see no reason why a
>>>> sanitized subscriber profile available from a link within the
>>>> person's public handle would not be adequate for identification
>>>> purposes and would actually become an enhancement to the listserv
>>>> app's usefulness to subscribers. this would certainly shield the
>>>> subscriber in a reliably meaningful way, serve to protect a
>>>> subscriber's own email system, and enhance the security of openssl's
>>>> own listserv ops.
>>> The issue that the FROM addresses of OpenSSL e-mail list posters
>>> (not other subscribers) can be seen by anyone receiving or
>>> otherwise finding their postings is age-old and completely
>>> unrelated to any issue related to this discussion (the spammer
>>> in this case obviously did not know that this was a mailing
>>> list, given the incorrect textual name used with the list
>>> SMTP address).
>>>
>>> Even if OpenSSL were to switch to a surveillance vulnerable
>>> design where PMs between users would have to go through the
>>> OpenSSL servers, the list administrators will probably remain
>>> reachable using well known mandatory e-mail addresses such as
>>> "Postmaster".  A similar issue would apply to most of the other
>>> high value subscribers.
>>>
>>> Any such people would already be required (in order to perform
>>> their function safely at all) to employ security measures to
>>> isolate their publicly known e-mail addresses from any e-mail
>>> addresses that are not intended to be publicly known.  As an
>>> example, all my (non-blocked) postings on this list use a
>>> dedicated mail address and mail box which allows me to dismiss
>>> e-mails on other subjects to this address as Spam while not
>>> exposing other e-mail addresses used for more trusted uses, and
>>> I obviously employ similar measures for any well known role
>>> accounts I handle myself.
>>>
>>>
>>>
>>>> *original anchor description (100% of the message content):*
>>>> Attn:__here__is__your___$l??
??
??
__Faceb????k__giftcard.
>>>>
>>>> __W??__N????d__Y????r__Shi??me??t__Inf??rmati????s__
>>>>
>>>> Click_Here
>>>>
>>>> On 2016.Apr.04 09:08, Jeffrey Walton wrote:
>>>>>> And anyway, this seems to be a case where the genuine
>>>>>> operator of an e-mail domain is failing to correctly
>>>>>> authenticate submissions by their own users, which no
>>>>>> amount of 3rd party automation (other than blacklisting
>>>>>> the failing provider, in this case gmail) could stop.
>>>>> Yeah, I'm guessing there was a vulnerability in one of the other
>>>>> Google services, and that Google service was allowed to make web-based
>>>>> email submissions on behalf of the user. Classic injection and failure
>>>>> to validate sessions or parameters...
>>>>>
>>>>> I'm also guessing Google fixed it because it has stopped.
>>>
>
>
>
> Enjoy
>
> Jakob

From openssl-users at dukhovni.org  Tue Apr  5 00:44:02 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 5 Apr 2016 00:44:02 +0000
Subject: [openssl-users] [THREAD CLOSED] (was: Fwd:
 CONGRATULATION____REF#87670)
In-Reply-To: <57030941.4020301@wisemo.com>
References: <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
 <5702FCFC.70409@forthepolls.org> <57030941.4020301@wisemo.com>
Message-ID: <20160405004402.GF26423@mournblade.imrryr.org>

A lot more non-productive ensued from the meta-discussion than the
from the original junk email.  Please move the junk mail discussion
to SPAM-L or, better yet, just it die.  This is the openssl-users
mailing list.

-- 
	Viktor.

From jb-openssl at wisemo.com  Tue Apr  5 00:52:24 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 5 Apr 2016 02:52:24 +0200
Subject: [openssl-users] [THREAD CLOSED]
In-Reply-To: <20160405004402.GF26423@mournblade.imrryr.org>
References: <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
 <5702FCFC.70409@forthepolls.org> <57030941.4020301@wisemo.com>
 <20160405004402.GF26423@mournblade.imrryr.org>
Message-ID: <57030C48.8030802@wisemo.com>

On 05/04/2016 02:44, Viktor Dukhovni wrote:
> A lot more non-productive ensued from the meta-discussion than the
> from the original junk email.  Please move the junk mail discussion
> to SPAM-L or, better yet, just it die.  This is the openssl-users
> mailing list.
>
Sorry to post this here, but you failed to provide any
address of said SPAM-L, nor yourself.  Try again.


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 pgnet.dev at gmail.com  Tue Apr  5 00:57:34 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Mon, 4 Apr 2016 17:57:34 -0700
Subject: [openssl-users] [THREAD CLOSED]
In-Reply-To: <57030C48.8030802@wisemo.com>
References: <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
 <5702FCFC.70409@forthepolls.org> <57030941.4020301@wisemo.com>
 <20160405004402.GF26423@mournblade.imrryr.org> <57030C48.8030802@wisemo.com>
Message-ID: <0b7c7566-c60b-f07c-12c2-e4b1a0545aa9@gmail.com>

> Sorry to post this here, but you failed to provide any
> address of said SPAM-L, nor yourself.  Try again.

http://bfy.tw/565B

From pgnet.dev at gmail.com  Tue Apr  5 02:21:34 2016
From: pgnet.dev at gmail.com (PGNet Dev)
Date: Mon, 4 Apr 2016 19:21:34 -0700
Subject: [openssl-users] [THREAD CLOSED]
In-Reply-To: <57031E1F.9080106@wisemo.com>
References: <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
 <5702FCFC.70409@forthepolls.org> <57030941.4020301@wisemo.com>
 <20160405004402.GF26423@mournblade.imrryr.org> <57030C48.8030802@wisemo.com>
 <0b7c7566-c60b-f07c-12c2-e4b1a0545aa9@gmail.com>
 <57031E1F.9080106@wisemo.com>
Message-ID: <833909b6-93d9-0f41-6eac-d22cec908112@gmail.com>



On 04/04/2016 07:08 PM, Jakob Bohm wrote:
> On 05/04/2016 02:57, PGNet Dev wrote:
>>> Sorry to post this here, but you failed to provide any
>>> address of said SPAM-L, nor yourself.  Try again.
>>
>> http://bfy.tw/565B
> Troll!
>
> I didn't ask what things in the entire world were
> historically named "SPAM-L" (first two Google results
> are messages that a list by that name was shut down in
> 2009, third is a page announcing a new generic mailing
> list unrelated to discussing things with the OpenSSL
> list administrators).
>
> I was asking where Victor wanted the discussion to be
> moved, since he gave a vague answer "SPAM-L" (which
> could refer to almost any spam discussion list) and
> didn't provide an address where those in the thread
> could ask him directly.
>
> And using an URL shortener to point to another URL
> shortener (which actually hides the final Google page
> with a non-removable popup) is spammy behavior.

Wow, you're special.

Do not email me directly/offlist again.

From rsalz at akamai.com  Tue Apr  5 03:34:10 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 5 Apr 2016 03:34:10 +0000
Subject: [openssl-users] CMS with Symmetric key
In-Reply-To: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
References: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
Message-ID: <206e0a0e41124cf5a2cbd38b4bb8d72e@usma1ex-dag1mb1.msg.corp.akamai.com>

> I'm trying to use the CMS operations in libcrypto but with a symmetric key encryption key instead of x509.

We don't support this.

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



From openssl-users at dukhovni.org  Tue Apr  5 03:52:55 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 4 Apr 2016 23:52:55 -0400
Subject: [openssl-users] CMS with Symmetric key
In-Reply-To: <206e0a0e41124cf5a2cbd38b4bb8d72e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
 <206e0a0e41124cf5a2cbd38b4bb8d72e@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <F546B3DF-9067-41DA-B8C6-F2DAEC4E673A@dukhovni.org>


> On Apr 4, 2016, at 11:34 PM, Salz, Rich <rsalz at akamai.com> wrote:
> 
>> I'm trying to use the CMS operations in libcrypto but with a symmetric key encryption key instead of x509.
> 
> We don't support this.

It looks like we do.  See crypto/cms/cms_pwri.c and the
undocumented "-pwri_password" option of the cms(1) command.

Documentation would of course be great...

-- 
	Viktor.


From ghanashyam.satpathy at gmail.com  Tue Apr  5 04:35:26 2016
From: ghanashyam.satpathy at gmail.com (ghanashyam satpathy)
Date: Tue, 5 Apr 2016 10:05:26 +0530
Subject: [openssl-users] Openssl-fips object module static library build
	with /MD option
Message-ID: <CAKn+8OLoGaUZHsusrkD+VLTmFrYto9xD7uuSioubkXU5VcjvNg@mail.gmail.com>

I have a question on compiling Openssl-fips object module as 64 bit static
library in win 8.1.

I am using following versions of source and compile instruction.
openssl-fips-2.0.12

 1. cd openssl-fips-2.0.12
 2. SET FIPSDIR=C:\tools\fips\opensslfips
 3. ms\do_fips no-asm

This turns out the build to be successful,however noticed it uses a
compilation arg /MD .
That turns out to be issue when I link this lib to my application.

openssl-1.0.1p

 1. cd openssl-1.0.1p
 2. perl Configure VC-WIN64A fips --with-fipsdir=C:\tools\fips\opensslfips
--prefix=C:\tools\fips\opensslBuild
 3. ms\do_win64A

Here I noticed the ms\nt.mak contains /MD too. As I used fips option to
configure.

4. nmake -f ms\nt.mak

Compiles OK, but with /MD option.
My application requirement is to generate all these static lib with /MT
option. How I can do that.
The existing fips-object module User Guide 2.0 does not help in this regard.

Would appreciate an early reply in this subject.

Thanks

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

From jb-openssl at wisemo.com  Tue Apr  5 04:52:15 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 5 Apr 2016 06:52:15 +0200
Subject: [openssl-users] [THREAD CLOSED]
In-Reply-To: <833909b6-93d9-0f41-6eac-d22cec908112@gmail.com>
References: <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
 <5702FCFC.70409@forthepolls.org> <57030941.4020301@wisemo.com>
 <20160405004402.GF26423@mournblade.imrryr.org> <57030C48.8030802@wisemo.com>
 <0b7c7566-c60b-f07c-12c2-e4b1a0545aa9@gmail.com>
 <57031E1F.9080106@wisemo.com>
 <833909b6-93d9-0f41-6eac-d22cec908112@gmail.com>
Message-ID: <5703447F.3060706@wisemo.com>

On 05/04/2016 04:21, PGNet Dev wrote:
>
>
> On 04/04/2016 07:08 PM, Jakob Bohm wrote:
>> On 05/04/2016 02:57, PGNet Dev wrote:
>>>> Sorry to post this here, but you failed to provide any
>>>> address of said SPAM-L, nor yourself.  Try again.
>>>
>>> http://bfy.tw/565B
>> Troll!
>>
>> I didn't ask what things in the entire world were
>> historically named "SPAM-L" (first two Google results
>> are messages that a list by that name was shut down in
>> 2009, third is a page announcing a new generic mailing
>> list unrelated to discussing things with the OpenSSL
>> list administrators).
>>
>> I was asking where Victor wanted the discussion to be
>> moved, since he gave a vague answer "SPAM-L" (which
>> could refer to almost any spam discussion list) and
>> didn't provide an address where those in the thread
>> could ask him directly.
>>
>> And using an URL shortener to point to another URL
>> shortener (which actually hides the final Google page
>> with a non-removable popup) is spammy behavior.
>
> Wow, you're special.
>
> Do not email me directly/offlist again.
Shut up troll, I was asking Victor what he meant, not
what you were guessing, and since this thread was
supposed to be closed, I wrote you directly.

And if you are actually Victor, you are hiding it
pretty well.

Enjoy

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


From openssl-users at dukhovni.org  Tue Apr  5 04:59:24 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 5 Apr 2016 00:59:24 -0400
Subject: [openssl-users] [THREAD CLOSED]
In-Reply-To: <5703447F.3060706@wisemo.com>
References: <56FECCB0.7010406@forthepolls.org>
 <f29d806af05c49df94da863a48d72103@usma1ex-dag1mb1.msg.corp.akamai.com>
 <CAH8yC8mb_YGfH22bMmOypZNsO9ZuSByMagaK+hY02idP-aeHQg@mail.gmail.com>
 <CAGbjqfEBrWPORcTTGXbd355dk=xJV8upa-EZG_59iavbLu8sGA@mail.gmail.com>
 <5702903F.9090508@wisemo.com>
 <CAH8yC8kQ0J1vxmFNLYGrNRtamv5rY1+ONePnAAnV_o+6ke-_UQ@mail.gmail.com>
 <5702CE88.2000407@forthepolls.org> <5702EC69.3080303@wisemo.com>
 <5702FCFC.70409@forthepolls.org> <57030941.4020301@wisemo.com>
 <20160405004402.GF26423@mournblade.imrryr.org> <57030C48.8030802@wisemo.com>
 <0b7c7566-c60b-f07c-12c2-e4b1a0545aa9@gmail.com>
 <57031E1F.9080106@wisemo.com>
 <833909b6-93d9-0f41-6eac-d22cec908112@gmail.com>
 <5703447F.3060706@wisemo.com>
Message-ID: <F0AA5BBD-9258-4031-92D9-E110D050DB87@dukhovni.org>


> On Apr 5, 2016, at 12:52 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> 
> Shut up troll, I was asking Victor what he meant, not
> what you were guessing, and since this thread was
> supposed to be closed, I wrote you directly.
> 
> And if you are actually Victor, you are hiding it
> pretty well.

I am Victor, and I strongly object to this tone.
When you're angry, do not vent on public lists, just
walk away from the thread...  [THREAD CLOSED] should
not have been ignored many messages earlier.

I am asking the list the list administrators that 
anyone posting new messages on this thread should be
unsubscribed regardless of any plausible merit in the
content.  Over and out.

-- 
	Viktor.


From sugu.ece28 at gmail.com  Tue Apr  5 06:14:25 2016
From: sugu.ece28 at gmail.com (Sugumar)
Date: Mon, 4 Apr 2016 23:14:25 -0700 (MST)
Subject: [openssl-users] Is SHA hashing algorithm reversable?
In-Reply-To: <20160404204015.GB26423@mournblade.imrryr.org>
References: <1459776389932-65408.post@n7.nabble.com>
 <20160404204015.GB26423@mournblade.imrryr.org>
Message-ID: <1459836865008-65439.post@n7.nabble.com>

Thanks for all the information provided. Really its very nice information.

And one more question, if i am using a salt with the password for computing
a hash value i need to store the salt for future reference and what about
the scenario when attacker gets that salt and hash. That time it may be
reversible right?

Please tell me the correct method to use a salt with password for storing a
passwords in a secure manner.



--
View this message in context: http://openssl.6102.n7.nabble.com/Is-SHA-hashing-algorithm-reversable-tp65408p65439.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From james.arivazhagan at gmail.com  Tue Apr  5 07:32:22 2016
From: james.arivazhagan at gmail.com (James)
Date: Tue, 5 Apr 2016 13:02:22 +0530
Subject: [openssl-users] Is SHA hashing algorithm reversable?
In-Reply-To: <1459836865008-65439.post@n7.nabble.com>
References: <1459776389932-65408.post@n7.nabble.com>
 <20160404204015.GB26423@mournblade.imrryr.org>
 <1459836865008-65439.post@n7.nabble.com>
Message-ID: <CAJLNLpeHEUoaJ+HQfC6xWi=qG-vuNySeuM7bLUb_KVKrCw1=fA@mail.gmail.com>

Hello Sugumar,
There are sites that store the commonly used strings and hashed strings.
For example for hello sha2 hash is this
2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

If you copy paste this in google, you would see hello

they dont do reverse of this hash but they hashed some commonly used
strings and kept in their DB, using this only they give the original string.

That is why we need to use a salt string along with your original string.

regards,
James

On Tue, Apr 5, 2016 at 11:44 AM, Sugumar <sugu.ece28 at gmail.com> wrote:

> Thanks for all the information provided. Really its very nice information.
>
> And one more question, if i am using a salt with the password for computing
> a hash value i need to store the salt for future reference and what about
> the scenario when attacker gets that salt and hash. That time it may be
> reversible right?
>
> Please tell me the correct method to use a salt with password for storing a
> passwords in a secure manner.
>
>
>
> --
> View this message in context:
> http://openssl.6102.n7.nabble.com/Is-SHA-hashing-algorithm-reversable-tp65408p65439.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160405/cf318920/attachment.html>

From sugu.ece28 at gmail.com  Tue Apr  5 08:22:50 2016
From: sugu.ece28 at gmail.com (Sugumar)
Date: Tue, 5 Apr 2016 01:22:50 -0700 (MST)
Subject: [openssl-users] Is SHA hashing algorithm reversable?
In-Reply-To: <CAJLNLpeHEUoaJ+HQfC6xWi=qG-vuNySeuM7bLUb_KVKrCw1=fA@mail.gmail.com>
References: <1459776389932-65408.post@n7.nabble.com>
 <20160404204015.GB26423@mournblade.imrryr.org>
 <1459836865008-65439.post@n7.nabble.com>
 <CAJLNLpeHEUoaJ+HQfC6xWi=qG-vuNySeuM7bLUb_KVKrCw1=fA@mail.gmail.com>
Message-ID: <1459844570008-65441.post@n7.nabble.com>

Hello,

Ya you are correct James.
But my doubt is what is the best method to hash the password securely with
salt.
I mean which method is preferred by openssl, 

HashValue = Hash(password + salt).
HashValue = Hash( Hash(password) + salt). or something else?
HashValue = Hash(password) + Hash(salt).

or this is up to the user decision?




--
View this message in context: http://openssl.6102.n7.nabble.com/Is-SHA-hashing-algorithm-reversable-tp65408p65441.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From steve at openssl.org  Tue Apr  5 11:39:05 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 5 Apr 2016 11:39:05 +0000
Subject: [openssl-users] CMS with Symmetric key
In-Reply-To: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
References: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
Message-ID: <20160405113905.GA22864@openssl.org>

On Mon, Apr 04, 2016, Abe Racioppo wrote:

> Hey guys,
> 
> I'm trying to use the CMS operations in libcrypto but with a symmetric key
> encryption key instead of x509.
> 
> I'm thinking I want to use a combination of
> 
> CMS_RecipientInfo_set0_pkey,
> SMIME_write_CMS,
> and
> CMS_EncryptedData_encrypt.
> 
> Has anyone done this before and can give me some direction?  This is my
> first time working with openssl and am getting kinda lost.
> 

You have several options here.

You can just use the encrypted data type with a key directly.

You can use the enveloped data type with a symmetric wrapping key.

You can use the enveloped data type with a password based recipient info.

Which you use depends on the application you have in mind.

In the first case you just call CMS_EncryptData_encrypt() followed by
SMIME_write_CMS().

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

From james.arivazhagan at gmail.com  Tue Apr  5 11:51:31 2016
From: james.arivazhagan at gmail.com (James)
Date: Tue, 5 Apr 2016 17:21:31 +0530
Subject: [openssl-users] Is SHA hashing algorithm reversable?
In-Reply-To: <1459844570008-65441.post@n7.nabble.com>
References: <1459776389932-65408.post@n7.nabble.com>
 <20160404204015.GB26423@mournblade.imrryr.org>
 <1459836865008-65439.post@n7.nabble.com>
 <CAJLNLpeHEUoaJ+HQfC6xWi=qG-vuNySeuM7bLUb_KVKrCw1=fA@mail.gmail.com>
 <1459844570008-65441.post@n7.nabble.com>
Message-ID: <CAJLNLpfC43Rtdj0GD-d16RwSW40o2DT9r5kQcF7Sp=NRcxv4ww@mail.gmail.com>

Hi,
I always use like this
Hash ( salt + password )
You can use like this also
Hash ( hash(salt) + password )
regards,
James

On Tue, Apr 5, 2016 at 1:52 PM, Sugumar <sugu.ece28 at gmail.com> wrote:

> Hello,
>
> Ya you are correct James.
> But my doubt is what is the best method to hash the password securely with
> salt.
> I mean which method is preferred by openssl,
>
> HashValue = Hash(password + salt).
> HashValue = Hash( Hash(password) + salt). or something else?
> HashValue = Hash(password) + Hash(salt).
>
> or this is up to the user decision?
>
>
>
>
> --
> View this message in context:
> http://openssl.6102.n7.nabble.com/Is-SHA-hashing-algorithm-reversable-tp65408p65441.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160405/cff156e4/attachment.html>

From satyakishore09 at gmail.com  Tue Apr  5 13:50:52 2016
From: satyakishore09 at gmail.com (kishore)
Date: Tue, 5 Apr 2016 19:20:52 +0530
Subject: [openssl-users] Fwd: undefined symbol: EC_KEY_new_by_curve_name
In-Reply-To: <CADSWym=n-4djpjeV0N-xhnnpg=Q_y5rvmAWi1JDpT4+tobUQCA@mail.gmail.com>
References: <CADSWym=n-4djpjeV0N-xhnnpg=Q_y5rvmAWi1JDpT4+tobUQCA@mail.gmail.com>
Message-ID: <CADSWymm2QnCfXzTfS0qnWUnVdFb3gJHGz-PVmG2GpejjS_xfXQ@mail.gmail.com>

Hi,
I'm trying to compile httpd 2.4.18 with openssl-1.0.2g(with
openssl-fips-2.0.12) on 64-bit RHEL machine.
I'm could compile and get it(httpd) running in http mode and while i'm
trying to run it in
HTTPS mode, server is unable to start saying


"httpd: Syntax error on line 128 of
/tmp/ossl/httpd/Release/conf/httpd.conf: Cannot load modules/mod_ssl.so
into server: /tmp/ossl/httpd/Release/modules/mod_ssl.so: undefined symbol:
EC_KEY_new_by_curve_name"

?I could get the same config up and running in 32-bit, but there seems to
be an issue with 64-bit.
Can someone help me with this?.

I have checked all pre reqs and basic checks for paths, all seems to be
pointing to proper libraries.


Thanks in Advance

~Kishore
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160405/007d7dc6/attachment-0001.html>

From dni.grosu at gmail.com  Tue Apr  5 14:41:59 2016
From: dni.grosu at gmail.com (danigrosu)
Date: Tue, 5 Apr 2016 07:41:59 -0700 (MST)
Subject: [openssl-users] OpenSSL RSA engine - RSA verify failure
Message-ID: <1459867319671-65447.post@n7.nabble.com>

Hi.
I am trying to build an OpenSSL RSA engine and the first step is to use the
"BN_mod_exp_mont" for the RSA modular exponentiation function, in RSA_METHOD 
structure.


***BEGINNING OF eng_rsax_test.c FILE***

/
#include <openssl/opensslconf.h>
#include <stdio.h>
#include <string.h>
#include <openssl/crypto.h>
#include <openssl/buffer.h>
#include <openssl/engine.h>
#ifndef OPENSSL_NO_RSA
#include <openssl/rsa.h>
#endif
#include <openssl/bn.h>
#include <openssl/err.h>

/* RSAX is available **ONLY* on x86_64 CPUs */
#undef COMPILE_RSAX

#if (defined(__x86_64) || defined(__x86_64__) || \
     defined(_M_AMD64) || defined (_M_X64)) && !defined(OPENSSL_NO_ASM)
#define COMPILE_RSAX
static ENGINE *ENGINE_rsax (void);
#endif

void ENGINE_load_rsax (void)
{
	ENGINE *toadd = ENGINE_rsax();
	if(!toadd) return;
	ENGINE_add(toadd);
	ENGINE_free(toadd);
	ERR_clear_error();

}

#ifdef COMPILE_RSAX
#define E_RSAX_LIB_NAME "rsax engine"

static int e_rsax_destroy(ENGINE *e);
static int e_rsax_init(ENGINE *e);
static int e_rsax_finish(ENGINE *e);
static int e_rsax_ctrl(ENGINE *e, int cmd, long i, void *p, void
(*f)(void));

#ifndef OPENSSL_NO_RSA
/* RSA stuff */
static int e_rsax_rsa_mod_exp(BIGNUM *r, const BIGNUM *I, RSA *rsa, BN_CTX
*ctx);
static int e_rsax_rsa_finish(RSA *r);
#endif

static const ENGINE_CMD_DEFN e_rsax_cmd_defns[] = {
	{0, NULL, NULL, 0}
	};

#ifndef OPENSSL_NO_RSA
/* Our internal RSA_METHOD that we provide pointers to */
static RSA_METHOD e_rsax_rsa =
	{
	"Intel RSA-X method",
	NULL,
	NULL,
	NULL,
	NULL,
	e_rsax_rsa_mod_exp,
	NULL,
	NULL,
	e_rsax_rsa_finish,
	RSA_FLAG_CACHE_PUBLIC|RSA_FLAG_CACHE_PRIVATE,
	NULL,
	NULL,
	NULL,
	NULL
	};
#endif

/* Constants used when creating the ENGINE */
static const char *engine_e_rsax_id = "rsax_dani";
static const char *engine_e_rsax_name = "RSAX engine support";

/* This internal function is used by ENGINE_rsax() */
static int bind_helper(ENGINE *e, const char *id)
	{
		printf("%s\n", id);
#ifndef OPENSSL_NO_RSA
	const RSA_METHOD *meth1;
#endif
	if(!ENGINE_set_id(e, engine_e_rsax_id) ||
			!ENGINE_set_name(e, engine_e_rsax_name) ||
#ifndef OPENSSL_NO_RSA
			!ENGINE_set_RSA(e, &e_rsax_rsa) ||
#endif
			!ENGINE_set_destroy_function(e, e_rsax_destroy) ||
			!ENGINE_set_init_function(e, e_rsax_init) ||
			!ENGINE_set_finish_function(e, e_rsax_finish) ||
			!ENGINE_set_ctrl_function(e, e_rsax_ctrl) ||
			!ENGINE_set_cmd_defns(e, e_rsax_cmd_defns))
		return 0;

#ifndef OPENSSL_NO_RSA
	meth1 = RSA_PKCS1_SSLeay();
	e_rsax_rsa.rsa_pub_enc = meth1->rsa_pub_enc;
	e_rsax_rsa.rsa_pub_dec = meth1->rsa_pub_dec;
	e_rsax_rsa.rsa_priv_enc = meth1->rsa_priv_enc;
	e_rsax_rsa.rsa_priv_dec = meth1->rsa_priv_dec;
	e_rsax_rsa.bn_mod_exp = meth1->bn_mod_exp;
	e_rsax_rsa.finish = meth1->finish;
#endif
	return 1;
	}
IMPLEMENT_DYNAMIC_BIND_FN(bind_helper)
IMPLEMENT_DYNAMIC_CHECK_FN()
static ENGINE *ENGINE_rsax(void)
	{
	ENGINE *ret = ENGINE_new();
	if(!ret)
		return NULL;
	if(!bind_helper(ret, engine_e_rsax_id))
		{
		ENGINE_free(ret);
		return NULL;
		}
	return ret;
	}


#ifndef OPENSSL_NO_RSA
/* Used to attach our own key-data to an RSA structure */
static int rsax_ex_data_idx = -1;
#endif

static int e_rsax_destroy(ENGINE *e)
	{
	return 1;
	}

/* (de)initialisation functions. */
static int e_rsax_init(ENGINE *e)
	{
#ifndef OPENSSL_NO_RSA
	if (rsax_ex_data_idx == -1)
		rsax_ex_data_idx = RSA_get_ex_new_index(0,
			NULL,
			NULL, NULL, NULL);
#endif
	if (rsax_ex_data_idx  == -1)
		return 0;
	return 1;
	}

static int e_rsax_finish(ENGINE *e)
	{
	return 1;
	}

static int e_rsax_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)(void))
	{
	int to_return = 1;

	switch(cmd)
		{
	/* The command isn't understood by this engine */
	default:
		to_return = 0;
		break;
		}

	return to_return;
	}


#ifndef OPENSSL_NO_RSA

#ifdef _WIN32
typedef unsigned __int64 UINT64;
#else
typedef unsigned long long UINT64;
#endif
typedef unsigned short UINT16;

struct mod_ctx_512 {
    UINT64 t[8][8];
    UINT64 m[8];
    UINT64 m1[8]; /* 2^278 % m */
    UINT64 m2[8]; /* 2^640 % m */
    UINT64 k1[2]; /* (- 1/m) % 2^128 */
};



typedef struct st_e_rsax_mod_ctx
{
  UINT64 type;
  union {
    struct mod_ctx_512 b512;
  } ctx;

} E_RSAX_MOD_CTX;

static int e_rsax_rsa_finish(RSA *rsa)
{
	E_RSAX_MOD_CTX *hptr = RSA_get_ex_data(rsa, rsax_ex_data_idx);
	if(!hptr) return 0;

	OPENSSL_free(hptr);
	RSA_set_ex_data(rsa, rsax_ex_data_idx, NULL);
	return 1;
}


#if 1
static int e_rsax_rsa_mod_exp(BIGNUM *r0, const BIGNUM *I, RSA *rsa, BN_CTX
*ctx)
{
	return BN_mod_exp_mont(r0, r0, I, rsa->n, ctx, rsa->_method_mod_p);
}

#endif

#endif /* !OPENSSL_NO_RSA */
#endif /* !COMPILE_RSAX *//

***END OF eng_rsax_test.c FILE***

The engine is built successfully after using these commands:
/cc -fPIC -o eng_rsax.o -c eng_rsax_test.c
cc -shared -o eng_rsax.so eng_rsax.o -lcrypto/

... but if I want to test the speed of the rsa implementation with:
/openssl speed rsa512 -engine `pwd`/eng_rsax.so/

it fails:
/engine "rsax_dani" set.
Doing 512 bit private rsa's for 10s: 774848 512 bit private RSA's in 10.01s
RSA verify failure.  No RSA verify will be done.
140017307215520:error:0407006A:rsa
routines:RSA_padding_check_PKCS1_type_1:block type is not 01:rsa_pk1.c:100:
140017307215520:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding
check failed:rsa_eay.c:721:
OpenSSL 1.0.1f 6 Jan 2014
built on: Mon Feb 29 18:11:15 UTC 2016
options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial)
blowfish(idx)/ 


So the signing part is working, but the verify part fails.
It appears that the PKCS1 paddind is wrong but how can I fix that?

Best wishes,
Dani Grosu




--
View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-RSA-engine-RSA-verify-failure-tp65447.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From uri at ll.mit.edu  Tue Apr  5 17:19:40 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Tue, 5 Apr 2016 17:19:40 +0000
Subject: [openssl-users] OpenSSL RSA engine - RSA verify failure
In-Reply-To: <1459867319671-65447.post@n7.nabble.com>
References: <1459867319671-65447.post@n7.nabble.com>
Message-ID: <D3296A39.29D9A%uri@ll.mit.edu>

Not sure I understand what you?re doing. But compiling/building eng_rsax.c
(provided by Intel) with the only mod being addition of dynamic bind,
produces the following result:

$ openssl engine rsax -t
(rsax) RSAX engine support
     [ available ]
$ sync
$ openssl speed rsa512 -engine rsax
engine "rsax" set.
Doing 512 bit private rsa's for 10s: 178316 512 bit private RSA's in 9.96s
Doing 512 bit public rsa's for 10s: 1936309 512 bit public RSA's in 9.99s
OpenSSL 1.0.2h-dev  xx XXX xxxx
built on: reproducible build, date unspecified
options:bn(64,64) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) idea(int)
blowfish(idx) 
compiler: clang -I. -I.. -I../include  -fPIC -fno-common -DOPENSSL_PIC
-DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch
x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM
                  sign    verify    sign/s verify/s
rsa  512 bits 0.000056s 0.000005s  17903.2 193824.7
$ 
$ openssl speed rsa512
Doing 512 bit private rsa's for 10s: 175940 512 bit private RSA's in 9.97s
Doing 512 bit public rsa's for 10s: 1884711 512 bit public RSA's in 9.98s
OpenSSL 1.0.2h-dev  xx XXX xxxx
built on: reproducible build, date unspecified
options:bn(64,64) rc4(ptr,int) des(idx,cisc,16,int) aes(partial) idea(int)
blowfish(idx) 
compiler: clang -I. -I.. -I../include  -fPIC -fno-common -DOPENSSL_PIC
-DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch
x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT
-DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM
-DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM
-DGHASH_ASM -DECP_NISTZ256_ASM
                  sign    verify    sign/s verify/s
rsa  512 bits 0.000057s 0.000005s  17646.9 188848.8




Perhaps it would make sense to (a) start with that eng_rsax.c code and get
it working by adding DYNAMIC_BIND, then (b) replace its assembly language
calls with BN calls?
-- 
Regards,
Uri Blumenthal





On 4/5/16, 10:41 , "openssl-users on behalf of danigrosu"
<openssl-users-bounces at openssl.org on behalf of dni.grosu at gmail.com> wrote:

>Hi.
>I am trying to build an OpenSSL RSA engine and the first step is to use
>the
>"BN_mod_exp_mont" for the RSA modular exponentiation function, in
>RSA_METHOD 
>structure.
>
>
>***BEGINNING OF eng_rsax_test.c FILE***
>. . . . . . . . . .
>
>***END OF eng_rsax_test.c FILE***
>
>The engine is built successfully after using these commands:
>/cc -fPIC -o eng_rsax.o -c eng_rsax_test.c
>cc -shared -o eng_rsax.so eng_rsax.o -lcrypto/
>
>... but if I want to test the speed of the rsa implementation with:
>/openssl speed rsa512 -engine `pwd`/eng_rsax.so/
>
>it fails:
>/engine "rsax_dani" set.
>Doing 512 bit private rsa's for 10s: 774848 512 bit private RSA's in
>10.01s
>RSA verify failure.  No RSA verify will be done.
>140017307215520:error:0407006A:rsa
>routines:RSA_padding_check_PKCS1_type_1:block type is not
>01:rsa_pk1.c:100:
>140017307215520:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding
>check failed:rsa_eay.c:721:
>OpenSSL 1.0.1f 6 Jan 2014
>built on: Mon Feb 29 18:11:15 UTC 2016
>options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial)
>blowfish(idx)/ 
>
>
>So the signing part is working, but the verify part fails.
>It appears that the PKCS1 paddind is wrong but how can I fix that?
>
>Best wishes,
>Dani Grosu
>
>
>
>
>--
>View this message in context:
>http://openssl.6102.n7.nabble.com/OpenSSL-RSA-engine-RSA-verify-failure-tp
>65447.html
>Sent from the OpenSSL - User mailing list archive at Nabble.com.
>-- 
>openssl-users mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4324 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160405/59caec80/attachment.bin>

From dni.grosu at gmail.com  Tue Apr  5 18:22:15 2016
From: dni.grosu at gmail.com (danigrosu)
Date: Tue, 5 Apr 2016 11:22:15 -0700 (MST)
Subject: [openssl-users] OpenSSL RSA engine - RSA verify failure
In-Reply-To: <D3296A39.29D9A%uri@ll.mit.edu>
References: <1459867319671-65447.post@n7.nabble.com>
 <D3296A39.29D9A%uri@ll.mit.edu>
Message-ID: <1459880535698-65450.post@n7.nabble.com>

Hi Uri Blumenthal,

I hace started from the Intel RSAX engine, and I just wanted to use
my own implementation of the rsa modular exponentiation. This 
project that I am working on intends to use a CUDA based 
implementation for modular computation.
In order to post a working example here, I just replaced the CUDA
part with the BN_mod_exp_mont function to reproduce the result,
that is "RSA verify failure". Of course, when I use the CUDA
implementation, I also get "RSA sign failure".

Best regards,
Dani Grosu



--
View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-RSA-engine-RSA-verify-failure-tp65447p65450.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From mangoo at wpkg.org  Wed Apr  6 12:16:37 2016
From: mangoo at wpkg.org (Tomasz Chmielewski)
Date: Wed, 06 Apr 2016 21:16:37 +0900
Subject: [openssl-users] openssl.spec build errors on CentOS 6?
Message-ID: <0c6006cb49520f913e75d0dfe67fb8f0@admin.virtall.com>

I'm trying to build openssl-1.0.2g on CentOS 6.7 64 bit, using the 
supplied openssl.spec. Unfortunately it fails as below. Is it possible 
to build openssl 1.0.2x with bundled openssl.spec on CentOS 6?

# rpmbuild -ba openssl.spec
(...)
symlinked /usr/lib/debug/usr/bin/openssl.debug to 
/usr/lib/debug/usr/bin/ssleay.debug
symlinked /usr/lib/debug/usr/lib64/libssl.so.1.0.0.debug to 
/usr/lib/debug/usr/lib64/libssl.so.debug
symlinked /usr/lib/debug/usr/lib64/libcrypto.so.1.0.0.debug to 
/usr/lib/debug/usr/lib64/libcrypto.so.debug
+ /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip 
/usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: openssl-1.0.2g-1.x86_64
error: File not found by glob: 
/root/rpmbuild/BUILDROOT/openssl-1.0.2g-1.x86_64/usr/lib/*.so*
Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.PvUXni
+ umask 022
+ cd /root/rpmbuild/BUILD
+ cd openssl-1.0.2g
+ 
DOCDIR=/root/rpmbuild/BUILDROOT/openssl-1.0.2g-1.x86_64/usr/share/doc/openssl-1.0.2g
+ export DOCDIR
+ rm -rf 
/root/rpmbuild/BUILDROOT/openssl-1.0.2g-1.x86_64/usr/share/doc/openssl-1.0.2g
+ /bin/mkdir -p 
/root/rpmbuild/BUILDROOT/openssl-1.0.2g-1.x86_64/usr/share/doc/openssl-1.0.2g
+ cp -pr CHANGES CHANGES.SSLeay LICENSE NEWS README 
/root/rpmbuild/BUILDROOT/openssl-1.0.2g-1.x86_64/usr/share/doc/openssl-1.0.2g
+ exit 0


RPM build errors:
     File not found by glob: 
/root/rpmbuild/BUILDROOT/openssl-1.0.2g-1.x86_64/usr/lib/*.so*




Tomasz Chmielewski
http://wpkg.org


From sandeepkiranp at gmail.com  Wed Apr  6 13:04:11 2016
From: sandeepkiranp at gmail.com (sandeep kiran p)
Date: Wed, 6 Apr 2016 18:34:11 +0530
Subject: [openssl-users] segv in 1.0.2 bn_power5
Message-ID: <CAAxGnDBhMeg85+XxOriVJXgm4UbRsSVP1oYD7uvz_xqs__OonQ@mail.gmail.com>

Hi,

Ours is a TLS proxy component where we act as MITM for certain traffic
between clients and servers for analysis. We recently migrated from 1.0.1q
to 1.0.2g after which we are seeing frequent crashes in the process all
with the following backtrace

#1  0x00007f877ea2427f in sigcrash (signo=11, info=<optimized out>,
ctx=0x7fff899b5f80)
#2  <signal handler called>
#3  bn_sqr8x_internal () at x86_64-mont5.s:1369
#4  0x00007f877b5a7ebf in bn_power5 () at x86_64-mont5.s:797
#5  0x0000000000000100 in ?? ()
#6  0x00007fff899b6530 in ?? ()
#7  0x00007f8786e9f140 in ?? ()
#8  0x0000000000000000 in ?? ()

The process is single threaded where we process packets as they come along.
When the process is lightly loaded (around 10 connections) things are fine.
We see the crash when we are processing say more than 40 connections.

Everything was working perfectly fine in 1.0.1.

Can someone hep us on what could have gone wrong with 1.0.2?

Thanks
Sandeep
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160406/bca80ae3/attachment-0001.html>

From director at openca.org  Wed Apr  6 13:54:21 2016
From: director at openca.org (Dr. Pala)
Date: Wed, 6 Apr 2016 10:54:21 -0300
Subject: [openssl-users] Block Ciphers in XTS mode (AES-XTS)
Message-ID: <5705150D.6060200@openca.org>

Hi all,

I am trying to solve a particular problem related to provide random 
access to encrypted files. AFAIK, I have two options. The first is to 
use CRT mode (read only) and the second is to use XTS (read and write).

Since I have never used the XTS mode before, does anybody have 
experience in using the XTS support in OpenSSL ? Do you have any 
particular recommendations for key re-usage in this case (i.e., shall I 
use one key per file or can I re-use the same key for different files) ?

Any examples that can guide me through the implementation effort ?

Thanks,
Max

-- 
Massimiliano Pala, PhD
Director at OpenCA Labs
twitter: @openca


From mcepl at cepl.eu  Wed Apr  6 16:18:18 2016
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl)
Date: Wed, 06 Apr 2016 18:18:18 +0200
Subject: [openssl-users] openssl.spec build errors on CentOS 6?
References: <0c6006cb49520f913e75d0dfe67fb8f0@admin.virtall.com>
Message-ID: <slrnngadma.9up.mcepl@mitmanek.ceplovi.cz>

On 2016-04-06, 12:16 GMT, Tomasz Chmielewski wrote:
> error: File not found by glob: 
> /root/rpmbuild/BUILDROOT/openssl-1.0.2g-1.x86_64/usr/lib/*.so*

This is something really really weird. x86_64 package should 
never ever write anything to /usr/lib/ , but only to /usr/lib64.  
You have to have something else screwed up in your 
configuration.

Mat?j

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
All of us could take a lesson from the weather. It pays no attention to
criticism.
  -- somewhere on the Intenret


From mangoo at wpkg.org  Wed Apr  6 17:10:42 2016
From: mangoo at wpkg.org (Tomasz Chmielewski)
Date: Thu, 07 Apr 2016 02:10:42 +0900
Subject: [openssl-users] openssl.spec build errors on CentOS 6?
In-Reply-To: <slrnngadma.9up.mcepl@mitmanek.ceplovi.cz>
References: <0c6006cb49520f913e75d0dfe67fb8f0@admin.virtall.com>
 <slrnngadma.9up.mcepl@mitmanek.ceplovi.cz>
Message-ID: <c39c72b9a8532b4317b71854d2ee43fd@admin.virtall.com>

On 2016-04-07 01:18, Mat?j Cepl wrote:
> On 2016-04-06, 12:16 GMT, Tomasz Chmielewski wrote:
>> error: File not found by glob:
>> /root/rpmbuild/BUILDROOT/openssl-1.0.2g-1.x86_64/usr/lib/*.so*
> 
> This is something really really weird. x86_64 package should
> never ever write anything to /usr/lib/ , but only to /usr/lib64.
> You have to have something else screwed up in your
> configuration.

Don't think it's something screwed in my configuration - I was able to 
reproduce it on two different servers.

Also, the paths in the .spec file are hardcoded to /usr/lib/, not 
/usr/lib64/ - correcting the spec to use /usr/lib64/ fixes this issue 
and the packages are built correctly.


Unfortunately it also turns out that the packages created with the 
bundled spec are not usable with CentOS 6 (built packages don't contain 
required files/symlinks/dependencies needed by other packages in CentOS 
6).


Tomasz Chmielewski
http://wpkg.org




From frode at bitwise.no  Wed Apr  6 18:22:51 2016
From: frode at bitwise.no (Frode Nilsen)
Date: Wed, 6 Apr 2016 20:22:51 +0200
Subject: [openssl-users] ECC private key length
Message-ID: <20160406182251.GA22615@localhost>

Hi,

When printing the contents of a PEM ECC keypair file for the secp160k1/r1/r2 curves, OpenSSL says the private key is 161 bits:

	$ openssl ecparam -name secp160k1 -genkey -out test.pem
	$ openssl ec -in test.pem -text -noout
	read EC key
	Private-Key: (161 bit)
	priv:
	    77:76:fb:ae:7a:0b:97:98:aa:c0:70:7d:af:28:14:
	    6d:4f:03:d9:b5
	pub: 
	    04:9b:98:38:4a:d0:e4:22:a2:3f:80:ce:02:90:02:
	    d3:35:51:dc:8f:7b:5e:30:7d:2d:5e:98:6f:4b:9b:
	    4b:c8:01:1c:2d:ce:39:37:04:c5:61
	ASN1 OID: secp160k1

However, following "priv:", there are only 20 bytes (160 bits). Why is this?

When printing the keypair for other curves, the number of bytes after "priv:" seem to always be the same or higher than the number of bits shown after "Private-Key:".

Thanks in advance,
Frode


From jason.vas.dias at gmail.com  Wed Apr  6 20:51:19 2016
From: jason.vas.dias at gmail.com (Jason Vas Dias)
Date: Wed, 6 Apr 2016 21:51:19 +0100
Subject: [openssl-users] is 1.0.2g meant to be buildable ? missing
	rc4_md5_enc implementation !
Message-ID: <CALyZvKzPNCj8oh=_RaFNTkfOS1kbXSdhNxX_Pbk6Zq7Jr-p1+A@mail.gmail.com>

please can anyone tell me:
Is the 1.0.2g release from :
   http://www.openssl.org/source/openssl-1.0.2g.tar.gz
meant to build ? Is this meant to be the latest stable release , or is
that 1.0.1s ?
The 1.0.2g release does not build, for the linux-x86_64:gcc 'threads
shared' configuration
(or any other AFAICS) because it lacks an implementation of
rc4_md4_enc() - there
are calls to it in crypto/evp/e_rc4_hmac_md5.c , but no definition of it :

$ grep -RIn --include '*.[ch]' rc4_md5_enc
crypto/evp/e_rc4_hmac_md5.c:80:void rc4_md5_enc(RC4_KEY *key, const
void *in0, void *out,
crypto/evp/e_rc4_hmac_md5.c:144:            rc4_md5_enc(&key->ks, in +
rc4_off, out + rc4_off,
crypto/evp/e_rc4_hmac_md5.c:188:            rc4_md5_enc(&key->ks, in +
rc4_off, out + rc4_off,
$ make
...
$ ( LIBDEPS="${LIBDEPS:--L.. -lssl  -L.. -lcrypto }";
LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
-march=x86-64 -mtune=native -O2 -g -fPIC -pipe }"; LIBPATH=`for x in
$LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;
LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; set -x;
LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o
gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o
s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
+ LD_LIBRARY_PATH=..:
+ gcc -DOPENSSL_THREADS -march=x86-64 -mtune=native -O2 -g -fPIC -pipe
-o openssl openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o
enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto
../libcrypto.a(e_rc4_hmac_md5.o): In function `rc4_hmac_md5_cipher':
/usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:144:
undefined reference to `rc4_md5_enc'
/usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:188:
undefined reference to `rc4_md5_enc'
collect2: error: ld returned 1 exit status

ie. the make fails because nowhere in any library or object file is
that function defined -
I have checked this with nm .

I guess my answer is that ! should be building 1.0.1s ?

From director at openca.org  Wed Apr  6 20:58:05 2016
From: director at openca.org (Dr. Pala)
Date: Wed, 6 Apr 2016 17:58:05 -0300
Subject: [openssl-users] Block Ciphers in XTS mode (AES-XTS) [SOLVED -
 almost ?]
In-Reply-To: <5705150D.6060200@openca.org>
References: <5705150D.6060200@openca.org>
Message-ID: <5705785D.8060706@openca.org>

Hi all,

well.. I did dig a little bit into the implementation code.. I wish who 
wrote the code would have put some comments to understand how to use the 
cipher properly.. I hope I did get it right. If anybody is interested in 
the code-tracking, here's some details:

    // Tracking down XTS code in OSSL
    //
    // crypto/evp/e_evp.c:
    //  EVP_AES_XTS_CTX (@line 85)
    //   aes_xts_ctrl (supports EVP_CTRL_COPY & EVP_CTRL_INIT only)
    (@line 1000)
    //   aes_xts_init_key (@line 1026)
    //   aes_xts_cipher (@line 1088) -> CRYPTO_xts128_encrypt
    //   define: BLOCK_CIPHER_custom (@line 1119)
    //
    // crypto/modes/modes.h: [TODO: check tweak, scratch]
    //  XTS128_CONTEXT (@line 144) -> struct xts128_context
    //  CRYPTO_xts128_encrypt (@line 146)
    //
    // crypto/modes/xts128.c:
    //   CRYPTO_xts128_encrypt (@line 61)
    //
    // crypto/modes/modes_lcl.h:
    //   struct xts128_context (@line 120)
    //

Now, for the interesting part, checking the code I noticed the use of a 
flag that checks for the size of the data to be encrypted that, for FIPS 
implementation, should not exceed 2^20 * block-size (in disk encryption 
that would be the size of the block, I suppose). Anyhow, that inspired 
me to try to see if, since there is no CRTL to set the size of the 
block, the implementation assumes that the size of the block is actually 
passed as the size of the data for each EVP_EncryptUpdate (or 
EVP_DecryptUpdate)... that seems to be the case. The test code that I 
generated is capable of decrypting the data at "block" boundaries (code 
follows).

Although I hoped for a more sophisticated and less error-prone 
interface, I guess I can work with this (but I hope someone would take 
charge of adding a little more of complexity to help with the details - 
maybe that work can also help CTR mode as well to be easier to use for 
random-access decryption).

Here's an initial (very simple) test implementation:

    // Init the CTX
    ctx = EVP_CIPHER_CTX_new();

    // Set cipher type and mode
    if (1 != EVP_EncryptInit_ex(ctx, EVP_aes_256_xts(), NULL, key, iv)

    // Total bytes to encrypt
    n_ops = 0;
    next_op_size = 0;
    remains = clear_len;

    enc_buf_curr = enc_buf;
    clear_buf_curr = clear_buf;

    // Encrypt plaintext
    while (remains > 0) {

       // Gets the size of the next chunk to be encrypted
       next_op_size = (block_size < remains ? block_size : remains);

       // Performs the encryption
       EVP_EncryptUpdate(ctx, enc_buf_curr, &tmp_len, clear_buf_curr,
    next_op_size);

       // Updates the number of ops
       n_ops++;

       // Updates the remaining data size to encrypt
       remains -= block_size;

       // Updates the pointer to the next enc buffer space
       enc_buf_curr += tmp_len;

       // Updates the pointer to the next clear buffer space
       clear_buf_curr += block_size;
    }

    // Finalize the Encryption
    EVP_EncryptFinal_ex(ctx, &enc_buf[ret_len], &tmp_len);

    // Now we can output the cyphertext (encrypted message)
    printf("Ciphertext %d:\n", ret_len);
    BIO_dump_fp(stdout, (char *)enc_buf, ret_len);
    printf("\n");

    // Let's free the OpenSSL CTX structure
    EVP_CIPHER_CTX_free(ctx);

Although this works, I noticed that the same data in different blocks 
result in the same ciphertext (really bad!). For example, with a block 
size of 64bytes (I know it is very small, but bear with me) and the 
following clear text input:

      char * text =
         // 128bits per row
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF"
         "0123456789ABCDEF";

The output is as follows:

    Encrypted Data:
    0000 - bb 56 4d ed dc 56 7c 3d-f8 c5 9d 58 34 d6 68 94 .VM..V|=...X4.h.
    0010 - f8 10 03 59 f0 a7 bb 79-e0 9c a3 33 bf b9 48 2d ...Y...y...3..H-
    0020 - 0f 23 c7 56 a8 b0 9c bf-aa a1 0e 4f 11 8b 18 14 .#.V.......O....
    0030 - 93 aa ca 02 ea 33 2f 92-b1 40 a2 01 c2 87 3f cc .....3/.. at ....?.
    0040 - bb 56 4d ed dc 56 7c 3d-f8 c5 9d 58 34 d6 68 94 .VM..V|=...X4.h.
    0050 - f8 10 03 59 f0 a7 bb 79-e0 9c a3 33 bf b9 48 2d ...Y...y...3..H-
    0060 - 0f 23 c7 56 a8 b0 9c bf-aa a1 0e 4f 11 8b 18 14 .#.V.......O....
    0070 - 93 aa ca 02 ea 33 2f 92-b1 40 a2 01 c2 87 3f cc .....3/.. at ....?.
    0080 - bb 56 4d ed dc 56 7c 3d-f8 c5 9d 58 34 d6 68 94 .VM..V|=...X4.h.
    0090 - f8 10 03 59 f0 a7 bb 79-e0 9c a3 33 bf b9 48 2d ...Y...y...3..H-
    00a0 - 0f 23 c7 56 a8 b0 9c bf-aa a1 0e 4f 11 8b 18 14 .#.V.......O....
    00b0 - 93 aa ca 02 ea 33 2f 92-b1 40 a2 01 c2 87 3f cc .....3/.. at ....?.
    00c0 - bb 56 4d ed dc 56 7c 3d-f8 c5 9d 58 34 d6 68 94 .VM..V|=...X4.h.
    00d0 - f8 10 03 59 f0 a7 bb 79-e0 9c a3 33 bf b9 48 2d ...Y...y...3..H-
    00e0 - 0f 23 c7 56 a8 b0 9c bf-aa a1 0e 4f 11 8b 18 14 .#.V.......O....
    00f0 - 93 aa ca 02 ea 33 2f 92-b1 40 a2 01 c2 87 3f cc .....3/.. at ....?.

Which, for what I know if XTS (that is very little, I admit), this 
should not be the case.. am I correct ? I was under the impression that 
the encryption should be tied to the position in the file (or Disk) - 
i.e., the block number. If so, does anybody know what I am actually 
missing here ? Am I supposed to, somehow, modify the plaintext before 
encrypting it (e.g., XOR with the block number ?).

Thanks,
Max

P.S.: I am cross-posting the message also to dev as this might have 
better chances to get an answer there... ?


On 4/6/16 10:54 AM, Dr. Pala wrote:
> Hi all,
>
> I am trying to solve a particular problem related to provide random 
> access to encrypted files. AFAIK, I have two options. The first is to 
> use CRT mode (read only) and the second is to use XTS (read and write).
>
> Since I have never used the XTS mode before, does anybody have 
> experience in using the XTS support in OpenSSL ? Do you have any 
> particular recommendations for key re-usage in this case (i.e., shall 
> I use one key per file or can I re-use the same key for different 
> files) ?
>
> Any examples that can guide me through the implementation effort ?
>
> Thanks,
> Max
>
>
> -- 
> Massimiliano Pala, PhD
> Director at OpenCA Labs
> twitter: @openca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160406/39b4b75c/attachment-0001.html>

From jason.vas.dias at gmail.com  Wed Apr  6 20:58:45 2016
From: jason.vas.dias at gmail.com (Jason Vas Dias)
Date: Wed, 6 Apr 2016 21:58:45 +0100
Subject: [openssl-users] is 1.0.2g meant to be buildable ? missing
 rc4_md5_enc implementation !
In-Reply-To: <CALyZvKzPNCj8oh=_RaFNTkfOS1kbXSdhNxX_Pbk6Zq7Jr-p1+A@mail.gmail.com>
References: <CALyZvKzPNCj8oh=_RaFNTkfOS1kbXSdhNxX_Pbk6Zq7Jr-p1+A@mail.gmail.com>
Message-ID: <CALyZvKz9-4J7uif5xkuSLAia7Cpr4DBa4phR7kGnEhX-m1XZ3w@mail.gmail.com>

Aha! I just saw rc4-md5-x86_64.pl - am I meant to run this manually to
produce the ASM
to compile to produce the object ? Why wasn't this run as part of the build ?
I am building with perl-5.22.1 , gcc-5.3.0, make-4.1 on Linux x86_64 LFS .


On 06/04/2016, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
> please can anyone tell me:
> Is the 1.0.2g release from :
>    http://www.openssl.org/source/openssl-1.0.2g.tar.gz
> meant to build ? Is this meant to be the latest stable release , or is
> that 1.0.1s ?
> The 1.0.2g release does not build, for the linux-x86_64:gcc 'threads
> shared' configuration
> (or any other AFAICS) because it lacks an implementation of
> rc4_md4_enc() - there
> are calls to it in crypto/evp/e_rc4_hmac_md5.c , but no definition of it :
>
> $ grep -RIn --include '*.[ch]' rc4_md5_enc
> crypto/evp/e_rc4_hmac_md5.c:80:void rc4_md5_enc(RC4_KEY *key, const
> void *in0, void *out,
> crypto/evp/e_rc4_hmac_md5.c:144:            rc4_md5_enc(&key->ks, in +
> rc4_off, out + rc4_off,
> crypto/evp/e_rc4_hmac_md5.c:188:            rc4_md5_enc(&key->ks, in +
> rc4_off, out + rc4_off,
> $ make
> ...
> $ ( LIBDEPS="${LIBDEPS:--L.. -lssl  -L.. -lcrypto }";
> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
> -march=x86-64 -mtune=native -O2 -g -fPIC -pipe }"; LIBPATH=`for x in
> $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;
> LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; set -x;
> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
> ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o
> dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
> rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o
> gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o
> s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
> pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
> rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
> + LD_LIBRARY_PATH=..:
> + gcc -DOPENSSL_THREADS -march=x86-64 -mtune=native -O2 -g -fPIC -pipe
> -o openssl openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o
> enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
> rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
> genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
> s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
> pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
> engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto
> ../libcrypto.a(e_rc4_hmac_md5.o): In function `rc4_hmac_md5_cipher':
> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:144:
> undefined reference to `rc4_md5_enc'
> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:188:
> undefined reference to `rc4_md5_enc'
> collect2: error: ld returned 1 exit status
>
> ie. the make fails because nowhere in any library or object file is
> that function defined -
> I have checked this with nm .
>
> I guess my answer is that ! should be building 1.0.1s ?
>

From jb-openssl at wisemo.com  Wed Apr  6 21:05:18 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 6 Apr 2016 23:05:18 +0200
Subject: [openssl-users] is 1.0.2g meant to be buildable ? missing
 rc4_md5_enc implementation !
In-Reply-To: <CALyZvKz9-4J7uif5xkuSLAia7Cpr4DBa4phR7kGnEhX-m1XZ3w@mail.gmail.com>
References: <CALyZvKzPNCj8oh=_RaFNTkfOS1kbXSdhNxX_Pbk6Zq7Jr-p1+A@mail.gmail.com>
 <CALyZvKz9-4J7uif5xkuSLAia7Cpr4DBa4phR7kGnEhX-m1XZ3w@mail.gmail.com>
Message-ID: <57057A0E.6040307@wisemo.com>

No, that script is run by the Makefile if relevant.

Given what others have reported recently, please check
what arguments you passed to config or configure (before
running make).

Also remember to do make depend.

On 06/04/2016 22:58, Jason Vas Dias wrote:
> Aha! I just saw rc4-md5-x86_64.pl - am I meant to run this manually to
> produce the ASM
> to compile to produce the object ? Why wasn't this run as part of the build ?
> I am building with perl-5.22.1 , gcc-5.3.0, make-4.1 on Linux x86_64 LFS .
>
>
> On 06/04/2016, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
>> please can anyone tell me:
>> Is the 1.0.2g release from :
>>     http://www.openssl.org/source/openssl-1.0.2g.tar.gz
>> meant to build ? Is this meant to be the latest stable release , or is
>> that 1.0.1s ?
>> The 1.0.2g release does not build, for the linux-x86_64:gcc 'threads
>> shared' configuration
>> (or any other AFAICS) because it lacks an implementation of
>> rc4_md4_enc() - there
>> are calls to it in crypto/evp/e_rc4_hmac_md5.c , but no definition of it :
>>
>> $ grep -RIn --include '*.[ch]' rc4_md5_enc
>> crypto/evp/e_rc4_hmac_md5.c:80:void rc4_md5_enc(RC4_KEY *key, const
>> void *in0, void *out,
>> crypto/evp/e_rc4_hmac_md5.c:144:            rc4_md5_enc(&key->ks, in +
>> rc4_off, out + rc4_off,
>> crypto/evp/e_rc4_hmac_md5.c:188:            rc4_md5_enc(&key->ks, in +
>> rc4_off, out + rc4_off,
>> $ make
>> ...
>> $ ( LIBDEPS="${LIBDEPS:--L.. -lssl  -L.. -lcrypto }";
>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
>> -march=x86-64 -mtune=native -O2 -g -fPIC -pipe }"; LIBPATH=`for x in
>> $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;
>> LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; set -x;
>> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>> ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o
>> dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
>> rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o
>> gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o
>> s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
>> pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
>> rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
>> + LD_LIBRARY_PATH=..:
>> + gcc -DOPENSSL_THREADS -march=x86-64 -mtune=native -O2 -g -fPIC -pipe
>> -o openssl openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o
>> enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
>> rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
>> genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
>> s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
>> pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
>> engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto
>> ../libcrypto.a(e_rc4_hmac_md5.o): In function `rc4_hmac_md5_cipher':
>> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:144:
>> undefined reference to `rc4_md5_enc'
>> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:188:
>> undefined reference to `rc4_md5_enc'
>> collect2: error: ld returned 1 exit status
>>
>> ie. the make fails because nowhere in any library or object file is
>> that function defined -
>> I have checked this with nm .
>>
>> I guess my answer is that ! should be building 1.0.1s ?
>>


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 jason.vas.dias at gmail.com  Wed Apr  6 21:36:12 2016
From: jason.vas.dias at gmail.com (Jason Vas Dias)
Date: Wed, 6 Apr 2016 22:36:12 +0100
Subject: [openssl-users] is 1.0.2g meant to be buildable ? missing
 rc4_md5_enc implementation !
In-Reply-To: <CALyZvKzP+MxPfvXyJ4tiHgLdUy07yRqGM2c4SnZtmDKCfGEwhQ@mail.gmail.com>
References: <CALyZvKzPNCj8oh=_RaFNTkfOS1kbXSdhNxX_Pbk6Zq7Jr-p1+A@mail.gmail.com>
 <CALyZvKz9-4J7uif5xkuSLAia7Cpr4DBa4phR7kGnEhX-m1XZ3w@mail.gmail.com>
 <57057A0E.6040307@wisemo.com>
 <CALyZvKzP+MxPfvXyJ4tiHgLdUy07yRqGM2c4SnZtmDKCfGEwhQ@mail.gmail.com>
Message-ID: <CALyZvKxQZw0vYuBGVcfxOi-DTEXJbDh9vv=tgboXoNaKzQLTfQ@mail.gmail.com>

Aha! Configure-ing with 'no-asm' fixed it. Apparently, my perl-5.22.1
installation is
lacking in some way . I'm surprised the make script did not complain
that it could
not generate the ASM before attempting to build openssl using the
deficient libcrypto .

Regards,
Jason

On 06/04/2016, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
> Thanks Jakob -
> But running the rc4-x86_64.pl script, even if by a Makefile, does not
> define
> the function either :
>
> $ ./rc4-x86_64.pl  > ../rc4-md5-x86_64.s
> $ cd ..
> $ as -o rc4-md5-x86_64.o rc4-md5-x86_64.s
> $ nm rc4-md5-x86_64.o
>                  U OPENSSL_ia32cap_P
> 0000000000000000 T RC4
> 0000000000000720 T RC4_options
> 0000000000000660 T private_RC4_set_key
>
> Do I need to pass 'no-asm' to Configure ?
>
> The Configure command I used was :
>
> $ LIBDIR=/usr/lib64 ./Configure --prefix=/usr threads shared
> linux-x86_64:gcc $CFLAGS_64 2>&1 | tee configure.log
>
> configure.log attached.
>
> And I did run 'make depend' - log attached.
>
> I used the command:
>
> $ make -j4 2>&1 | tee make.log
>
> to build OpenSSL and there is no occurence of the text ' rc4-x86_64'
> anywhere in
> that (v.large) log file , indicating no attempt was made to generate
> ASM for x86_64 ?
>
> Please, for practical everyday use, what is the latest / best stable OpenSSL
> ?
> 1.0.1s or 1.0.2g ?
>
> The last one I used extensively was 1.0.1g - but I'd like to build the
> latest stable release now.
>
> Thanks & Regards, Jason
>
>
>
> On 06/04/2016, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> No, that script is run by the Makefile if relevant.
>>
>> Given what others have reported recently, please check
>> what arguments you passed to config or configure (before
>> running make).
>>
>> Also remember to do make depend.
>>
>> On 06/04/2016 22:58, Jason Vas Dias wrote:
>>> Aha! I just saw rc4-md5-x86_64.pl - am I meant to run this manually to
>>> produce the ASM
>>> to compile to produce the object ? Why wasn't this run as part of the
>>> build ?
>>> I am building with perl-5.22.1 , gcc-5.3.0, make-4.1 on Linux x86_64 LFS
>>> .
>>>
>>>
>>> On 06/04/2016, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
>>>> please can anyone tell me:
>>>> Is the 1.0.2g release from :
>>>>     http://www.openssl.org/source/openssl-1.0.2g.tar.gz
>>>> meant to build ? Is this meant to be the latest stable release , or is
>>>> that 1.0.1s ?
>>>> The 1.0.2g release does not build, for the linux-x86_64:gcc 'threads
>>>> shared' configuration
>>>> (or any other AFAICS) because it lacks an implementation of
>>>> rc4_md4_enc() - there
>>>> are calls to it in crypto/evp/e_rc4_hmac_md5.c , but no definition of
>>>> it
>>>> :
>>>>
>>>> $ grep -RIn --include '*.[ch]' rc4_md5_enc
>>>> crypto/evp/e_rc4_hmac_md5.c:80:void rc4_md5_enc(RC4_KEY *key, const
>>>> void *in0, void *out,
>>>> crypto/evp/e_rc4_hmac_md5.c:144:            rc4_md5_enc(&key->ks, in +
>>>> rc4_off, out + rc4_off,
>>>> crypto/evp/e_rc4_hmac_md5.c:188:            rc4_md5_enc(&key->ks, in +
>>>> rc4_off, out + rc4_off,
>>>> $ make
>>>> ...
>>>> $ ( LIBDEPS="${LIBDEPS:--L.. -lssl  -L.. -lcrypto }";
>>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
>>>> -march=x86-64 -mtune=native -O2 -g -fPIC -pipe }"; LIBPATH=`for x in
>>>> $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;
>>>> LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; set -x;
>>>> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>>>> ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o
>>>> dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
>>>> rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o
>>>> gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o
>>>> s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
>>>> pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
>>>> rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
>>>> + LD_LIBRARY_PATH=..:
>>>> + gcc -DOPENSSL_THREADS -march=x86-64 -mtune=native -O2 -g -fPIC -pipe
>>>> -o openssl openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o
>>>> enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
>>>> rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
>>>> genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
>>>> s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
>>>> pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
>>>> engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto
>>>> ../libcrypto.a(e_rc4_hmac_md5.o): In function `rc4_hmac_md5_cipher':
>>>> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:144:
>>>> undefined reference to `rc4_md5_enc'
>>>> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:188:
>>>> undefined reference to `rc4_md5_enc'
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> ie. the make fails because nowhere in any library or object file is
>>>> that function defined -
>>>> I have checked this with nm .
>>>>
>>>> I guess my answer is that ! should be building 1.0.1s ?
>>>>
>>
>>
>> Enjoy
>>
>> Jakob
>> --
>> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
>> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
>> This public discussion message is non-binding and may contain errors.
>> WiseMo - Remote Service Management for PCs, Phones and Embedded
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>

From noloader at gmail.com  Wed Apr  6 21:49:19 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 6 Apr 2016 17:49:19 -0400
Subject: [openssl-users] is 1.0.2g meant to be buildable ? missing
 rc4_md5_enc implementation !
In-Reply-To: <CALyZvKxQZw0vYuBGVcfxOi-DTEXJbDh9vv=tgboXoNaKzQLTfQ@mail.gmail.com>
References: <CALyZvKzPNCj8oh=_RaFNTkfOS1kbXSdhNxX_Pbk6Zq7Jr-p1+A@mail.gmail.com>
 <CALyZvKz9-4J7uif5xkuSLAia7Cpr4DBa4phR7kGnEhX-m1XZ3w@mail.gmail.com>
 <57057A0E.6040307@wisemo.com>
 <CALyZvKzP+MxPfvXyJ4tiHgLdUy07yRqGM2c4SnZtmDKCfGEwhQ@mail.gmail.com>
 <CALyZvKxQZw0vYuBGVcfxOi-DTEXJbDh9vv=tgboXoNaKzQLTfQ@mail.gmail.com>
Message-ID: <CAH8yC8k3JrbTHV_rVg_EzcM4qmHQQFb6hHz3CwxiL8qeLzQ1CA@mail.gmail.com>

On Wed, Apr 6, 2016 at 5:36 PM, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
> Aha! Configure-ing with 'no-asm' fixed it. Apparently, my perl-5.22.1
> installation is
> lacking in some way . I'm surprised the make script did not complain
> that it could
> not generate the ASM before attempting to build openssl using the
> deficient libcrypto .

Sometimes either a (1) 'make clean' or (2) './config' clears it. Its
almost like you have to run through the procedure twice to get into a
good state on occasion.

Since its amd64/x86_64, ./config should have no problems, and should
allow you to use ASM.

Jeff

From vikas.tm at gmail.com  Thu Apr  7 13:23:50 2016
From: vikas.tm at gmail.com (Vikas TM)
Date: Thu, 7 Apr 2016 18:53:50 +0530
Subject: [openssl-users] glibc detected *** xxx: double free or
 corruption (!prev): 0x097b8750
In-Reply-To: <CAJe-LUiV792wMv7fNGsgi7f3TBQ_iBtM3QOdAqq-++6j+KbdXQ@mail.gmail.com>
References: <8ACFF8299C8F504F87EDE3DAA1FCA84D14F49592@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
 <CA+5R-ah1WbS-AL1HX5EieuMRodwgvEMfSkv=vNwrD7k+2cNnSQ@mail.gmail.com>
 <CAJe-LUiV792wMv7fNGsgi7f3TBQ_iBtM3QOdAqq-++6j+KbdXQ@mail.gmail.com>
Message-ID: <CA+5R-aj0trZmyKwKff7QF-7KFwpbk2W6o+7obTUWc9eLktXDJg@mail.gmail.com>

Hi Mike


I have integrated openSSL version 102d. While running secure FTP
connection, I have encountered double free or corruption issue.

The TLS negotiation is successful and file is also getting transferred to
partner machine. At the end while freeing all the memory, file transfer is
ended with ?double free or corruption issue?. I have tried almost all the
patch available in internet. Please let me know if you any solution.



Machine: Linux x86_64

Please find the GDB output below,



Breakpoint 1, ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:2995

2995        if (s == NULL || s->s3 == NULL)

(gdb) n

3009        ssl3_cleanup_key_block(s);

(gdb)

3010        if (s->s3->rbuf.buf != NULL)

(gdb)

3011            ssl3_release_read_buffer(s);

(gdb)

3012        if (s->s3->wbuf.buf != NULL)

(gdb)

3013            ssl3_release_write_buffer(s);

(gdb)

3014        if (s->s3->rrec.comp != NULL)

(gdb)

3017        if (s->s3->tmp.dh != NULL)

(gdb)

3021        if (s->s3->tmp.ecdh != NULL)

(gdb)

3025        if (s->s3->tmp.ca_names != NULL)

(gdb)

3027        if (s->s3->handshake_buffer) {

(gdb)

3030        if (s->s3->handshake_dgst)

(gdb)

3031            ssl3_free_digest_list(s);

(gdb)

3033        if (s->s3->alpn_selected)

(gdb)

3038        SSL_SRP_CTX_free(s);

(gdb)



3042        OPENSSL_cleanse(s->s3, sizeof *(s->s3));

(gdb) n

3047        OPENSSL_free(s->s3);

(gdb) p *(s->s3)

$1 = {flags = 1447178013, delay_buf_pop_ret = -1332182677, read_sequence =
"\311\343\376\032\067Ut\224", read_mac_secret_size = -557140059,

  read_mac_secret = "\363\t
8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332\363\003\031\060Ha{\226\262\317\355\f,=Obv\213\241\270\320\356\003\036:Wu\224\264\305\327\356\374",
write_sequence = "\023)@Xq\213\246", <incomplete sequence \302>,
write_mac_secret_size = 1008532959,

  write_mac_secret =
"M_r\206\243\261\310\340\371\023.Jg\205\260\304\325\347\373\016#9Ph\201\233\264\322\357\r,L]o\202\226\253\301\330\363\t#>Zw\225\264\324\345\374\n\036\063I`x\221\253\306\342\377\035<\\",
server_random =
"m\177\222\246\273\321\350\000\031\063Nj\207\245\304\344\365\a\032.CYp\210\241\273\326\362\017-Ll",

  client_random =
"}\217\242\266\313\341\370\020)C^z\227\265\324\364\005\027*>Si\200\230\261\313\346\002\037=\\|",
need_empty_fragments = -961372275,

  empty_fragment_done = 537457115, init_extra = -1972481223, rbuf = {buf =
0x4e4c5a7 <Address 0x4e4c5a7 out of bounds>, len = 1312433941, offset =
-1466926749,

    left = 318168001}, wbuf = {buf = 0x8c6c4d2f <Address 0x8c6c4d2f out of
bounds>, len = 3603083165, offset = 806879723, left = -1702993079}, rrec = {

    type = 351589815, length = 1581922085, off = 3097528691, data =
0x2206ebd1 <Address 0x2206ebd1 out of bounds>,

    input = 0x9c7c5d3f <Address 0x9c7c5d3f out of bounds>, comp =
0xe6d2bfad <Address 0xe6d2bfad out of bounds>, epoch = 1076367867,

    seq_num = "Ys\216\252\307\345\004$"}, wrec = {type = 1851410229, length
= 3367016835, off = 840367073, data = 0xac8c6d4f <Address 0xac8c6d4f out of
bounds>,

    input = 0xf6e2cfbd <Address 0xf6e2cfbd out of bounds>, comp =
0x5038210b <Address 0x5038210b out of bounds>, epoch = 3130950505,

    seq_num = "\327\365\024\064EWj~"}, alert_fragment = "\223\251",
alert_fragment_len = 1109789681, handshake_fragment = "_}\234\274",

  handshake_fragment_len = 116580301, wnum = 1615343899, wpend_tot =
-894528647, wpend_type = 1143211495, wpend_ret = -1904580779,

  wpend_buf = 0xe8d0b9a3 <Address 0xe8d0b9a3 out of bounds>,
handshake_buffer = 0x52361b01, handshake_dgst = 0xccac8d6f,
change_cipher_spec = 369291229,

  warn_alert = 1884832043, fatal_alert = -625040503, alert_dispatch =
1412699639, send_alert = "ew", renegotiate = -119486029,
total_renegotiations = 1648765713,

  num_renegotiations = -591618689, in_read_app_data = 638779373,
client_opaque_prf_input = 0x8068513b, client_opaque_prf_input_len =
3939414937,

  server_opaque_prf_input = 0x64442507, server_opaque_prf_input_len =
2929362805, tmp = {

    cert_verify_md =
"\303\331\363\b!;Vr\217\255\314\354\375\017\"6Kax\220\251\303\336\362\029\065Tt\205\227\252\279\323\351\000\030\061Kf\202\237\263\336\321\r\037\062F[q\210\240\271\323\346\n'Ed\204\225\247\281\316\323\371\020(A[v\222\257\314\354\f\035/BVk\201\230\270\212\343\373\032\067Ut\224\248\267\312\336\363\t
8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332",
<incomplete sequence \356>,

    finish_md =
"\003\031\060Ha{\226\262\319\356\f,=Obv\213\241\270\478\351\003\036:Wu\224\268\365\327\352\376\023)@Xq\213\246\302\347\365\034<M_r\206\233\261\311\340\361\023.Jg\205\244\304\325\357\371\016#9Ph\201\233\266\344\357\r,L]o\202\226\253\301\330\360\t#>Zw\225\264\327\345\364\n\036\063I`x\221\253\306\342\377\035<\\m\177\222\246\273\328\350\000\031\063Nj\207\245\304\344\365\a\032.",
finish_md_len = -2005903037,

    peer_finish_md =
"\241\273\326\366\017-Ll}\217\242\266\314\341\370\020)C^z\227\265\324\366\005\027*>Si\200\230\261\363\346\002\037=\\|\215\237\262\363\333\362\b
9Sn\212\247\305\344\004\025':Ncy\220\250\301\333\366\022/Ml\214\235\257\302\326\353\001\030\060Ic~\232\267\325\364\024%7J^s\211\240\270\321\353\006\"?]|\234\255\277\325\346\373\021(@Ys\216\252\307\345\004$5GZn\203\242\260",
<incomplete sequence \310>, peer_finish_md_len = 840367073, message_size =
2894884175, message_type = -152907843,

    new_cipher = 0x5038210b, dh = 0xba9e8369, ecdh = 0x3414f5d7, next_state
= 2120898373, reuse_message = -658462317, cert_req = 1109789681, ctype_num
= -1130594977,

    ctype = "\315\337\362\006\033\061H`y", ca_names = 0x442405e7,
use_rsa_tmp = -1904580779, key_block_length = -388974173,

    key_block = 0x52361b01 <Address 0x52361b01 out of bounds>, new_sym_enc
= 0xccac8d6f, new_hash = 0x1602efdd, new_mac_pkey_type = 1884832043,

    new_mac_secret_size = -625040503, new_compression = 0x543415f7 <Address
0x543415f7 out of bounds>, cert_request = -1635092635},

  previous_client_finished =
"\263\311\350\370\021+Fb\177\235\274\344\355\377\022&;Qh\200\241\263\326\352\a%Ddu\207\234\256\303\331\340\b!;Vr\217\255\314\364\375\027\"6Kax\220\251\303\336\362\029\065Tt\205\227\252\279",
previous_client_finished_len = 211 '\323',

  previous_server_finished =
"\351\000\032\061Kf\202\247\275\334\374\r\037\062F[q\210\240\271\325\356\n'Ed\204\325\247\272\316\363\371\020(A[v\222\257\315\354\f\035/BVk\201\230\260\311\343\376\032\067Ut\224\255\267\312\346",
<incomplete sequence \363>, previous_server_finished_len = 9 '\t',
send_connection_binding = -1568249007,

  next_proto_neg_seen = 486333887, is_probably_safari = 45 '-',
alpn_selected = 0xc0a8917b <Address 0xc0a8917b out of bounds>,
alpn_selected_len = 705623001}

(gdb) n

*** glibc detected *** vikftp: double free or corruption (!prev):
0x08736610 ***

Missing separate debuginfo for /lib/libgcc_s.so.1

======= Backtrace: =========

/lib/libc.so.6[0xf75b3a51]

/lib/libc.so.6(__libc_free+0x84)[0xf75b5224]

vikftp(CRYPTO_free+0x40)[0x820e9e8]

vikftp(ssl3_free+0x198)[0x82e15c1]

vikftp(tls1_free+0x3b)[0x823b034]

vikftp(SSL_free+0x1fd)[0x8230151]

vikftp[0x8165dac]

vikftp[0x815236b]

vikftp[0x8156afe]

vikftp[0x8154a3f]

vikftp[0x8154578]

vikftp(vikftp+0x2ea)[0x8150e6a]

vikftp(main+0x17f)[0x81f8173]

/lib/libc.so.6(__libc_start_main+0xdc)[0xf756589c]

vikftp[0x8094441]

======= Memory map: ========

08048000-0862c000 r-xp 00000000 fd:00 854843
/App/vikftp

0862c000-08670000 rwxp 005e4000 fd:00 854843
/App/vikftp

08670000-08765000 rwxp 08670000 00:00 0
[heap]

f6e00000-f6e21000 rwxp f6e00000 00:00 0

f6e21000-f6f00000 ---p f6e21000 00:00 0

f6f25000-f6f26000 rwxp f6f25000 00:00 0

f6f26000-f6f27000 rwxs 00000000 ca:02 1057441
/var/vik/tmp/AMCMMON

f6f27000-f6f28000 rwxs 00000000 ca:02 155213
                         /var/vik/tmp/AMLOG

f6f28000-f6f2f000 r-xs 00000000 ca:02 26686
/usr/lib/gconv/gconv-modules.cache

f6f2f000-f6f62000 r-xp 00000000 ca:02 30659
/usr/lib/locale/en_US.utf8/LC_CTYPE

f7491000-f74c6000 r-xs 00000000 ca:02 269730
/var/run/nscd/group

f74c6000-f74fb000 r-xs 00000000 ca:02 269729
/var/run/nscd/passwd

f74fb000-f753d000 rwxp f74fb000 00:00 0

f753d000-f754e000 r-xp 00000000 ca:02 26359
/lib/libaudit.so.0.0.0

f754e000-f7550000 rwxp 00010000 ca:02 26359
/lib/libaudit.so.0.0.0

f7550000-f768b000 r-xp 00000000 ca:02 25372
/lib/libc-2.4.so

f768b000-f768c000 rwxp 0013a000 ca:02 25372
/lib/libc-2.4.so

f768c000-f768d000 r-xp 0013b000 ca:02 25372
/lib/libc-2.4.so

f768d000-f768f000 rwxp 0013c000 ca:02 25372
/lib/libc-2.4.so

f768f000-f7693000 rwxp f768f000 00:00 0

f7693000-f76b8000 r-xp 00000000 ca:02 25380
/lib/libm-2.4.so

f76b8000-f76ba000 rwxp 00025000 ca:02 25380
/lib/libm-2.4.so

f76ba000-f76c4000 r-xp 00000000 ca:02 36150
/lib/libpam.so.0.81.5

f76c4000-f76c5000 rwxp 00009000 ca:02 36150
/lib/libpam.so.0.81.5

f76c5000-f76c8000 r-xp 00000000 ca:02 25378
/lib/libdl-2.4.so

f76c8000-f76ca000 rwxp 00002000 ca:02 25378
/lib/libdl-2.4.so

f76ca000-f76d3000 r-xp 00000000 ca:02 25376
/lib/libcrypt-2.4.so

f76d3000-f76d6000 rwxp 00008000 ca:02 25376
/lib/libcrypt-2.4.so

f76d6000-f76fd000 rwxp f76d6000 00:00 0

f770b000-f7715000 r-xp 00000000 ca:02 30823
/lib/libgcc_s.so.1

f7715000-f7716000 rwxp 00009000 ca:02 30823
/lib/libgcc_s.so.1

f7718000-f7719000 rwxp f7718000 00:00 0

f7719000-f7735000 r-xp 00000000 ca:02 25365
/lib/ld-2.4.so

f7735000-f7737000 rwxp 0001b000 ca:02 25365                              /l

Program received signal SIGABRT, Aborted.

0xffffe410 in ?? ()

(gdb) bt

#0  0xffffe410 in ?? ()

#1  0x00000006 in ?? ()

#2  0x0000704d in ?? ()

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

#4  0xf757a153 in abort () from /lib/libc.so.6

#5  0xf75ae08b in __libc_message () from /lib/libc.so.6

#6  0xf75b3a51 in malloc_printerr () from /lib/libc.so.6

#7  0xf75b5224 in free () from /lib/libc.so.6

#8  0x0820e9e8 in CRYPTO_free (str=0x8736610) at /102d/s/mem.c:442

#9  0x082e15c1 in ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:3047

#10 0x0823b034 in tls1_free (s=0x8736430) at /102d/s/t1_lib.c:217

#11 0x08230151 in SSL_free (s=0x8736430) at /102d/s/ssl_lib.c:639

#12 0x08165dac in closeConnection (pcx=0x86e0400, rsn=0x0, graceful=1
'\001') at /App/ftp.c:10098
On 25 Feb 2016 2:20 pm, "Mike Mohr" <akihana at gmail.com> wrote:

> You'll need to rebuild your application and openssl with debugging symbols
> and no optimization, then run it inside gdb to produce a more useful stack
> trace. Since you don't include any context or source code snippets it isn't
> really possible to help. Can you produce a reduced test case with source
> code which reproduces the bug?
>
> As long as politics is the shadow cast on society by big business, the
> attenuation of the shadow will not change the substance.
>
> John Dewey: The Later Works, 1925-1953; Volume 6, pp. 163
> On Feb 24, 2016 11:33 PM, "Vikas TM" <vikas.tm at gmail.com> wrote:
>
>> Hi,
>>
>> While running my application with openSSL 102d and I encountered double
>> free error or corruption.
>>
>> As per few threads suggestion, I have changed getpid() with
>> pthread_self() in CRYPTO_thread_id(). Still the result is same.
>>
>> Please let me know if any fix available to this issue.
>>
>> *** glibc detected *** xxx: double free or corruption (!prev): 0x097b8750
>> ***
>>
>> ======= Backtrace: =========
>>
>> /lib/libc.so.6[0x1768b6]
>>
>> /lib/libc.so.6(cfree+0x90)[0x179e00]
>>
>> xxx(CRYPTO_free+0x3a)[0x81b89be]
>>
>> xxx(ssl_cert_free+0x13f)[0x826fa23]
>>
>> xxx(SSL_free+0x14d)[0x81d7e08]
>>
>> Thanks & Regards,
>> Vikas
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160407/02e9d15d/attachment-0001.html>

From matt at openssl.org  Thu Apr  7 13:36:41 2016
From: matt at openssl.org (Matt Caswell)
Date: Thu, 7 Apr 2016 14:36:41 +0100
Subject: [openssl-users] glibc detected *** xxx: double free or
 corruption (!prev): 0x097b8750
In-Reply-To: <CA+5R-aj0trZmyKwKff7QF-7KFwpbk2W6o+7obTUWc9eLktXDJg@mail.gmail.com>
References: <8ACFF8299C8F504F87EDE3DAA1FCA84D14F49592@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
 <CA+5R-ah1WbS-AL1HX5EieuMRodwgvEMfSkv=vNwrD7k+2cNnSQ@mail.gmail.com>
 <CAJe-LUiV792wMv7fNGsgi7f3TBQ_iBtM3QOdAqq-++6j+KbdXQ@mail.gmail.com>
 <CA+5R-aj0trZmyKwKff7QF-7KFwpbk2W6o+7obTUWc9eLktXDJg@mail.gmail.com>
Message-ID: <57066269.10702@openssl.org>



On 07/04/16 14:23, Vikas TM wrote:
> Hi Mike
>  
> 
> I have integrated openSSL version 102d. While running secure FTP
> connection, I have encountered double free or corruption issue.

Are you running 1.0.2d as downloaded from the OpenSSL website with no
other patches applied? The line numbers below do not match up with the
git copy of 1.0.2d.

Matt

> 
> The TLS negotiation is successful and file is also getting transferred
> to partner machine. At the end while freeing all the memory, file
> transfer is ended with ?double free or corruption issue?. I have tried
> almost all the patch available in internet. Please let me know if you
> any solution.
> 
>  
> 
> Machine: Linux x86_64
> 
> Please find the GDB output below,
> 
>  
> 
> Breakpoint 1, ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:2995
> 
> 2995        if (s == NULL || s->s3 == NULL)
> 
> (gdb) n
> 
> 3009        ssl3_cleanup_key_block(s);
> 
> (gdb)
> 
> 3010        if (s->s3->rbuf.buf != NULL)
> 
> (gdb)
> 
> 3011            ssl3_release_read_buffer(s);
> 
> (gdb)
> 
> 3012        if (s->s3->wbuf.buf != NULL)
> 
> (gdb)
> 
> 3013            ssl3_release_write_buffer(s);
> 
> (gdb)
> 
> 3014        if (s->s3->rrec.comp != NULL)
> 
> (gdb)
> 
> 3017        if (s->s3->tmp.dh != NULL)
> 
> (gdb)
> 
> 3021        if (s->s3->tmp.ecdh != NULL)
> 
> (gdb)
> 
> 3025        if (s->s3->tmp.ca_names != NULL)
> 
> (gdb)
> 
> 3027        if (s->s3->handshake_buffer) {
> 
> (gdb)
> 
> 3030        if (s->s3->handshake_dgst)
> 
> (gdb)
> 
> 3031            ssl3_free_digest_list(s);
> 
> (gdb)
> 
> 3033        if (s->s3->alpn_selected)
> 
> (gdb)
> 
> 3038        SSL_SRP_CTX_free(s);
> 
> (gdb)
> 
>  
> 
> 3042        OPENSSL_cleanse(s->s3, sizeof *(s->s3));
> 
> (gdb) n
> 
> 3047        OPENSSL_free(s->s3);
> 
> (gdb) p *(s->s3)
> 
> $1 = {flags = 1447178013, delay_buf_pop_ret = -1332182677, read_sequence
> = "\311\343\376\032\067Ut\224", read_mac_secret_size = -557140059,
> 
>   read_mac_secret = "\363\t
> 8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332\363\003\031\060Ha{\226\262\317\355\f,=Obv\213\241\270\320\356\003\036:Wu\224\264\305\327\356\374",
> write_sequence = "\023)@Xq\213\246", <incomplete sequence \302>,
> write_mac_secret_size = 1008532959,
> 
>   write_mac_secret =
> "M_r\206\243\261\310\340\371\023.Jg\205\260\304\325\347\373\016#9Ph\201\233\264\322\357\r,L]o\202\226\253\301\330\363\t#>Zw\225\264\324\345\374\n\036\063I`x\221\253\306\342\377\035<\\",
> server_random =
> "m\177\222\246\273\321\350\000\031\063Nj\207\245\304\344\365\a\032.CYp\210\241\273\326\362\017-Ll",
> 
>   client_random =
> "}\217\242\266\313\341\370\020)C^z\227\265\324\364\005\027*>Si\200\230\261\313\346\002\037=\\|",
> need_empty_fragments = -961372275,
> 
>   empty_fragment_done = 537457115, init_extra = -1972481223, rbuf = {buf
> = 0x4e4c5a7 <Address 0x4e4c5a7 out of bounds>, len = 1312433941, offset
> = -1466926749,
> 
>     left = 318168001}, wbuf = {buf = 0x8c6c4d2f <Address 0x8c6c4d2f out
> of bounds>, len = 3603083165, offset = 806879723, left = -1702993079},
> rrec = {
> 
>     type = 351589815, length = 1581922085, off = 3097528691, data =
> 0x2206ebd1 <Address 0x2206ebd1 out of bounds>,
> 
>     input = 0x9c7c5d3f <Address 0x9c7c5d3f out of bounds>, comp =
> 0xe6d2bfad <Address 0xe6d2bfad out of bounds>, epoch = 1076367867,
> 
>     seq_num = "Ys\216\252\307\345\004$"}, wrec = {type = 1851410229,
> length = 3367016835, off = 840367073, data = 0xac8c6d4f <Address
> 0xac8c6d4f out of bounds>,
> 
>     input = 0xf6e2cfbd <Address 0xf6e2cfbd out of bounds>, comp =
> 0x5038210b <Address 0x5038210b out of bounds>, epoch = 3130950505,
> 
>     seq_num = "\327\365\024\064EWj~"}, alert_fragment = "\223\251",
> alert_fragment_len = 1109789681, handshake_fragment = "_}\234\274",
> 
>   handshake_fragment_len = 116580301, wnum = 1615343899, wpend_tot =
> -894528647, wpend_type = 1143211495, wpend_ret = -1904580779,
> 
>   wpend_buf = 0xe8d0b9a3 <Address 0xe8d0b9a3 out of bounds>,
> handshake_buffer = 0x52361b01, handshake_dgst = 0xccac8d6f,
> change_cipher_spec = 369291229,
> 
>   warn_alert = 1884832043, fatal_alert = -625040503, alert_dispatch =
> 1412699639, send_alert = "ew", renegotiate = -119486029,
> total_renegotiations = 1648765713,
> 
>   num_renegotiations = -591618689, in_read_app_data = 638779373,
> client_opaque_prf_input = 0x8068513b, client_opaque_prf_input_len =
> 3939414937,
> 
>   server_opaque_prf_input = 0x64442507, server_opaque_prf_input_len =
> 2929362805, tmp = {
> 
>     cert_verify_md =
> "\303\331\363\b!;Vr\217\255\314\354\375\017\"6Kax\220\251\303\336\362\029\065Tt\205\227\252\279\323\351\000\030\061Kf\202\237\263\336\321\r\037\062F[q\210\240\271\323\346\n'Ed\204\225\247\281\316\323\371\020(A[v\222\257\314\354\f\035/BVk\201\230\270\212\343\373\032\067Ut\224\248\267\312\336\363\t
> 8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332",
> <incomplete sequence \356>,
> 
>     finish_md =
> "\003\031\060Ha{\226\262\319\356\f,=Obv\213\241\270\478\351\003\036:Wu\224\268\365\327\352\376\023)@Xq\213\246\302\347\365\034<M_r\206\233\261\311\340\361\023.Jg\205\244\304\325\357\371\016#9Ph\201\233\266\344\357\r,L]o\202\226\253\301\330\360\t#>Zw\225\264\327\345\364\n\036\063I`x\221\253\306\342\377\035<\\m\177\222\246\273\328\350\000\031\063Nj\207\245\304\344\365\a\032.",
> finish_md_len = -2005903037,
> 
>     peer_finish_md =
> "\241\273\326\366\017-Ll}\217\242\266\314\341\370\020)C^z\227\265\324\366\005\027*>Si\200\230\261\363\346\002\037=\\|\215\237\262\363\333\362\b
> 9Sn\212\247\305\344\004\025':Ncy\220\250\301\333\366\022/Ml\214\235\257\302\326\353\001\030\060Ic~\232\267\325\364\024%7J^s\211\240\270\321\353\006\"?]|\234\255\277\325\346\373\021(@Ys\216\252\307\345\004$5GZn\203\242\260",
> <incomplete sequence \310>, peer_finish_md_len = 840367073, message_size
> = 2894884175, message_type = -152907843,
> 
>     new_cipher = 0x5038210b, dh = 0xba9e8369, ecdh = 0x3414f5d7,
> next_state = 2120898373, reuse_message = -658462317, cert_req =
> 1109789681, ctype_num = -1130594977,
> 
>     ctype = "\315\337\362\006\033\061H`y", ca_names = 0x442405e7,
> use_rsa_tmp = -1904580779, key_block_length = -388974173,
> 
>     key_block = 0x52361b01 <Address 0x52361b01 out of bounds>,
> new_sym_enc = 0xccac8d6f, new_hash = 0x1602efdd, new_mac_pkey_type =
> 1884832043,
> 
>     new_mac_secret_size = -625040503, new_compression = 0x543415f7
> <Address 0x543415f7 out of bounds>, cert_request = -1635092635},
> 
>   previous_client_finished =
> "\263\311\350\370\021+Fb\177\235\274\344\355\377\022&;Qh\200\241\263\326\352\a%Ddu\207\234\256\303\331\340\b!;Vr\217\255\314\364\375\027\"6Kax\220\251\303\336\362\029\065Tt\205\227\252\279",
> previous_client_finished_len = 211 '\323',
> 
>   previous_server_finished =
> "\351\000\032\061Kf\202\247\275\334\374\r\037\062F[q\210\240\271\325\356\n'Ed\204\325\247\272\316\363\371\020(A[v\222\257\315\354\f\035/BVk\201\230\260\311\343\376\032\067Ut\224\255\267\312\346",
> <incomplete sequence \363>, previous_server_finished_len = 9 '\t',
> send_connection_binding = -1568249007,
> 
>   next_proto_neg_seen = 486333887, is_probably_safari = 45 '-',
> alpn_selected = 0xc0a8917b <Address 0xc0a8917b out of bounds>,
> alpn_selected_len = 705623001}
> 
> (gdb) n
> 
> *** glibc detected *** vikftp: double free or corruption (!prev):
> 0x08736610 ***
> 
> Missing separate debuginfo for /lib/libgcc_s.so.1
> 
> ======= Backtrace: =========
> 
> /lib/libc.so.6[0xf75b3a51]
> 
> /lib/libc.so.6(__libc_free+0x84)[0xf75b5224]
> 
> vikftp(CRYPTO_free+0x40)[0x820e9e8]
> 
> vikftp(ssl3_free+0x198)[0x82e15c1]
> 
> vikftp(tls1_free+0x3b)[0x823b034]
> 
> vikftp(SSL_free+0x1fd)[0x8230151]
> 
> vikftp[0x8165dac]
> 
> vikftp[0x815236b]
> 
> vikftp[0x8156afe]
> 
> vikftp[0x8154a3f]
> 
> vikftp[0x8154578]
> 
> vikftp(vikftp+0x2ea)[0x8150e6a]
> 
> vikftp(main+0x17f)[0x81f8173]
> 
> /lib/libc.so.6(__libc_start_main+0xdc)[0xf756589c]
> 
> vikftp[0x8094441]
> 
> ======= Memory map: ========
> 
> 08048000-0862c000 r-xp 00000000 fd:00 854843                            
> /App/vikftp
> 
> 0862c000-08670000 rwxp 005e4000 fd:00 854843                            
> /App/vikftp
> 
> 08670000-08765000 rwxp 08670000 00:00 0                                 
> [heap]
> 
> f6e00000-f6e21000 rwxp f6e00000 00:00 0
> 
> f6e21000-f6f00000 ---p f6e21000 00:00 0
> 
> f6f25000-f6f26000 rwxp f6f25000 00:00 0
> 
> f6f26000-f6f27000 rwxs 00000000 ca:02 1057441                           
> /var/vik/tmp/AMCMMON
> 
> f6f27000-f6f28000 rwxs 00000000 ca:02 155213   
>                          /var/vik/tmp/AMLOG
> 
> f6f28000-f6f2f000 r-xs 00000000 ca:02 26686                             
> /usr/lib/gconv/gconv-modules.cache
> 
> f6f2f000-f6f62000 r-xp 00000000 ca:02 30659                             
> /usr/lib/locale/en_US.utf8/LC_CTYPE
> 
> f7491000-f74c6000 r-xs 00000000 ca:02 269730                            
> /var/run/nscd/group
> 
> f74c6000-f74fb000 r-xs 00000000 ca:02 269729                            
> /var/run/nscd/passwd
> 
> f74fb000-f753d000 rwxp f74fb000 00:00 0
> 
> f753d000-f754e000 r-xp 00000000 ca:02 26359                             
> /lib/libaudit.so.0.0.0
> 
> f754e000-f7550000 rwxp 00010000 ca:02 26359                             
> /lib/libaudit.so.0.0.0
> 
> f7550000-f768b000 r-xp 00000000 ca:02 25372                             
> /lib/libc-2.4.so <http://libc-2.4.so>
> 
> f768b000-f768c000 rwxp 0013a000 ca:02 25372                             
> /lib/libc-2.4.so <http://libc-2.4.so>
> 
> f768c000-f768d000 r-xp 0013b000 ca:02 25372                             
> /lib/libc-2.4.so <http://libc-2.4.so>
> 
> f768d000-f768f000 rwxp 0013c000 ca:02 25372                             
> /lib/libc-2.4.so <http://libc-2.4.so>
> 
> f768f000-f7693000 rwxp f768f000 00:00 0
> 
> f7693000-f76b8000 r-xp 00000000 ca:02 25380                             
> /lib/libm-2.4.so <http://libm-2.4.so>
> 
> f76b8000-f76ba000 rwxp 00025000 ca:02 25380                             
> /lib/libm-2.4.so <http://libm-2.4.so>
> 
> f76ba000-f76c4000 r-xp 00000000 ca:02 36150                             
> /lib/libpam.so.0.81.5
> 
> f76c4000-f76c5000 rwxp 00009000 ca:02 36150                             
> /lib/libpam.so.0.81.5
> 
> f76c5000-f76c8000 r-xp 00000000 ca:02 25378                             
> /lib/libdl-2.4.so <http://libdl-2.4.so>
> 
> f76c8000-f76ca000 rwxp 00002000 ca:02 25378                             
> /lib/libdl-2.4.so <http://libdl-2.4.so>
> 
> f76ca000-f76d3000 r-xp 00000000 ca:02 25376                             
> /lib/libcrypt-2.4.so <http://libcrypt-2.4.so>
> 
> f76d3000-f76d6000 rwxp 00008000 ca:02 25376                             
> /lib/libcrypt-2.4.so <http://libcrypt-2.4.so>
> 
> f76d6000-f76fd000 rwxp f76d6000 00:00 0
> 
> f770b000-f7715000 r-xp 00000000 ca:02 30823                             
> /lib/libgcc_s.so.1
> 
> f7715000-f7716000 rwxp 00009000 ca:02 30823                             
> /lib/libgcc_s.so.1
> 
> f7718000-f7719000 rwxp f7718000 00:00 0
> 
> f7719000-f7735000 r-xp 00000000 ca:02 25365                             
> /lib/ld-2.4.so <http://ld-2.4.so>
> 
> f7735000-f7737000 rwxp 0001b000 ca:02 25365                              /l
> 
> Program received signal SIGABRT, Aborted.
> 
> 0xffffe410 in ?? ()
> 
> (gdb) bt
> 
> #0  0xffffe410 in ?? ()
> 
> #1  0x00000006 in ?? ()
> 
> #2  0x0000704d in ?? ()
> 
> #3  0xf7578a30 in raise () from /lib/libc.so.6
> 
> #4  0xf757a153 in abort () from /lib/libc.so.6
> 
> #5  0xf75ae08b in __libc_message () from /lib/libc.so.6
> 
> #6  0xf75b3a51 in malloc_printerr () from /lib/libc.so.6
> 
> #7  0xf75b5224 in free () from /lib/libc.so.6
> 
> #8  0x0820e9e8 in CRYPTO_free (str=0x8736610) at /102d/s/mem.c:442
> 
> #9  0x082e15c1 in ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:3047
> 
> #10 0x0823b034 in tls1_free (s=0x8736430) at /102d/s/t1_lib.c:217
> 
> #11 0x08230151 in SSL_free (s=0x8736430) at /102d/s/ssl_lib.c:639
> 
> #12 0x08165dac in closeConnection (pcx=0x86e0400, rsn=0x0, graceful=1
> '\001') at /App/ftp.c:10098
> 
> On 25 Feb 2016 2:20 pm, "Mike Mohr" <akihana at gmail.com
> <mailto:akihana at gmail.com>> wrote:
> 
>     You'll need to rebuild your application and openssl with debugging
>     symbols and no optimization, then run it inside gdb to produce a
>     more useful stack trace. Since you don't include any context or
>     source code snippets it isn't really possible to help. Can you
>     produce a reduced test case with source code which reproduces the bug?
> 
>     As long as politics is the shadow cast on society by big business,
>     the attenuation of the shadow will not change the substance.
> 
>     John Dewey: The Later Works, 1925-1953; Volume 6, pp. 163
> 
>     On Feb 24, 2016 11:33 PM, "Vikas TM" <vikas.tm at gmail.com
>     <mailto:vikas.tm at gmail.com>> wrote:
> 
>         Hi,
> 
>         While running my application with openSSL 102d and I encountered
>         double free error or corruption.
> 
>         As per few threads suggestion, I have changed getpid() with
>         pthread_self() in CRYPTO_thread_id(). Still the result is same.
> 
>         Please let me know if any fix available to this issue.
> 
>         *** glibc detected *** xxx: double free or corruption (!prev):
>         0x097b8750 ***
> 
>         ======= Backtrace: =========
> 
>         /lib/libc.so.6[0x1768b6]
> 
>         /lib/libc.so.6(cfree+0x90)[0x179e00]
> 
>         xxx(CRYPTO_free+0x3a)[0x81b89be]
> 
>         xxx(ssl_cert_free+0x13f)[0x826fa23]
> 
>         xxx(SSL_free+0x14d)[0x81d7e08]
> 
>         Thanks & Regards,
>         Vikas
> 
> 
>         --
>         openssl-users mailing list
>         To unsubscribe:
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
>     --
>     openssl-users mailing list
>     To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> 
> 

From vikas.tm at gmail.com  Thu Apr  7 13:48:59 2016
From: vikas.tm at gmail.com (Vikas TM)
Date: Thu, 7 Apr 2016 19:18:59 +0530
Subject: [openssl-users] glibc detected *** xxx: double free or
 corruption (!prev): 0x097b8750
In-Reply-To: <57066269.10702@openssl.org>
References: <8ACFF8299C8F504F87EDE3DAA1FCA84D14F49592@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
 <CA+5R-ah1WbS-AL1HX5EieuMRodwgvEMfSkv=vNwrD7k+2cNnSQ@mail.gmail.com>
 <CAJe-LUiV792wMv7fNGsgi7f3TBQ_iBtM3QOdAqq-++6j+KbdXQ@mail.gmail.com>
 <CA+5R-aj0trZmyKwKff7QF-7KFwpbk2W6o+7obTUWc9eLktXDJg@mail.gmail.com>
 <57066269.10702@openssl.org>
Message-ID: <CA+5R-ahPRUbz6FYaqVVny_8x6h1P4DTiHqPn7Z91Qkw=CxmJcw@mail.gmail.com>

Hi Matt,

I was trying the patches available in the Internet. Due to that few blank
lines might have added or removed. But no major change in the code.

Thanks & Regards,
Vikas
On 7 Apr 2016 7:07 pm, "Matt Caswell" <matt at openssl.org> wrote:

>
>
> On 07/04/16 14:23, Vikas TM wrote:
> > Hi Mike
> >
> >
> > I have integrated openSSL version 102d. While running secure FTP
> > connection, I have encountered double free or corruption issue.
>
> Are you running 1.0.2d as downloaded from the OpenSSL website with no
> other patches applied? The line numbers below do not match up with the
> git copy of 1.0.2d.
>
> Matt
>
> >
> > The TLS negotiation is successful and file is also getting transferred
> > to partner machine. At the end while freeing all the memory, file
> > transfer is ended with ?double free or corruption issue?. I have tried
> > almost all the patch available in internet. Please let me know if you
> > any solution.
> >
> >
> >
> > Machine: Linux x86_64
> >
> > Please find the GDB output below,
> >
> >
> >
> > Breakpoint 1, ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:2995
> >
> > 2995        if (s == NULL || s->s3 == NULL)
> >
> > (gdb) n
> >
> > 3009        ssl3_cleanup_key_block(s);
> >
> > (gdb)
> >
> > 3010        if (s->s3->rbuf.buf != NULL)
> >
> > (gdb)
> >
> > 3011            ssl3_release_read_buffer(s);
> >
> > (gdb)
> >
> > 3012        if (s->s3->wbuf.buf != NULL)
> >
> > (gdb)
> >
> > 3013            ssl3_release_write_buffer(s);
> >
> > (gdb)
> >
> > 3014        if (s->s3->rrec.comp != NULL)
> >
> > (gdb)
> >
> > 3017        if (s->s3->tmp.dh != NULL)
> >
> > (gdb)
> >
> > 3021        if (s->s3->tmp.ecdh != NULL)
> >
> > (gdb)
> >
> > 3025        if (s->s3->tmp.ca_names != NULL)
> >
> > (gdb)
> >
> > 3027        if (s->s3->handshake_buffer) {
> >
> > (gdb)
> >
> > 3030        if (s->s3->handshake_dgst)
> >
> > (gdb)
> >
> > 3031            ssl3_free_digest_list(s);
> >
> > (gdb)
> >
> > 3033        if (s->s3->alpn_selected)
> >
> > (gdb)
> >
> > 3038        SSL_SRP_CTX_free(s);
> >
> > (gdb)
> >
> >
> >
> > 3042        OPENSSL_cleanse(s->s3, sizeof *(s->s3));
> >
> > (gdb) n
> >
> > 3047        OPENSSL_free(s->s3);
> >
> > (gdb) p *(s->s3)
> >
> > $1 = {flags = 1447178013, delay_buf_pop_ret = -1332182677, read_sequence
> > = "\311\343\376\032\067Ut\224", read_mac_secret_size = -557140059,
> >
> >   read_mac_secret = "\363\t
> >
> 8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332\363\003\031\060Ha{\226\262\317\355\f,=Obv\213\241\270\320\356\003\036:Wu\224\264\305\327\356\374",
> > write_sequence = "\023)@Xq\213\246", <incomplete sequence \302>,
> > write_mac_secret_size = 1008532959,
> >
> >   write_mac_secret =
> >
> "M_r\206\243\261\310\340\371\023.Jg\205\260\304\325\347\373\016#9Ph\201\233\264\322\357\r,L]o\202\226\253\301\330\363\t#>Zw\225\264\324\345\374\n\036\063I`x\221\253\306\342\377\035<\\",
> > server_random =
> >
> "m\177\222\246\273\321\350\000\031\063Nj\207\245\304\344\365\a\032.CYp\210\241\273\326\362\017-Ll",
> >
> >   client_random =
> >
> "}\217\242\266\313\341\370\020)C^z\227\265\324\364\005\027*>Si\200\230\261\313\346\002\037=\\|",
> > need_empty_fragments = -961372275,
> >
> >   empty_fragment_done = 537457115, init_extra = -1972481223, rbuf = {buf
> > = 0x4e4c5a7 <Address 0x4e4c5a7 out of bounds>, len = 1312433941, offset
> > = -1466926749,
> >
> >     left = 318168001}, wbuf = {buf = 0x8c6c4d2f <Address 0x8c6c4d2f out
> > of bounds>, len = 3603083165, offset = 806879723, left = -1702993079},
> > rrec = {
> >
> >     type = 351589815, length = 1581922085, off = 3097528691, data =
> > 0x2206ebd1 <Address 0x2206ebd1 out of bounds>,
> >
> >     input = 0x9c7c5d3f <Address 0x9c7c5d3f out of bounds>, comp =
> > 0xe6d2bfad <Address 0xe6d2bfad out of bounds>, epoch = 1076367867,
> >
> >     seq_num = "Ys\216\252\307\345\004$"}, wrec = {type = 1851410229,
> > length = 3367016835, off = 840367073, data = 0xac8c6d4f <Address
> > 0xac8c6d4f out of bounds>,
> >
> >     input = 0xf6e2cfbd <Address 0xf6e2cfbd out of bounds>, comp =
> > 0x5038210b <Address 0x5038210b out of bounds>, epoch = 3130950505,
> >
> >     seq_num = "\327\365\024\064EWj~"}, alert_fragment = "\223\251",
> > alert_fragment_len = 1109789681, handshake_fragment = "_}\234\274",
> >
> >   handshake_fragment_len = 116580301, wnum = 1615343899, wpend_tot =
> > -894528647, wpend_type = 1143211495, wpend_ret = -1904580779,
> >
> >   wpend_buf = 0xe8d0b9a3 <Address 0xe8d0b9a3 out of bounds>,
> > handshake_buffer = 0x52361b01, handshake_dgst = 0xccac8d6f,
> > change_cipher_spec = 369291229,
> >
> >   warn_alert = 1884832043, fatal_alert = -625040503, alert_dispatch =
> > 1412699639, send_alert = "ew", renegotiate = -119486029,
> > total_renegotiations = 1648765713,
> >
> >   num_renegotiations = -591618689, in_read_app_data = 638779373,
> > client_opaque_prf_input = 0x8068513b, client_opaque_prf_input_len =
> > 3939414937,
> >
> >   server_opaque_prf_input = 0x64442507, server_opaque_prf_input_len =
> > 2929362805, tmp = {
> >
> >     cert_verify_md =
> >
> "\303\331\363\b!;Vr\217\255\314\354\375\017\"6Kax\220\251\303\336\362\029\065Tt\205\227\252\279\323\351\000\030\061Kf\202\237\263\336\321\r\037\062F[q\210\240\271\323\346\n'Ed\204\225\247\281\316\323\371\020(A[v\222\257\314\354\f\035/BVk\201\230\270\212\343\373\032\067Ut\224\248\267\312\336\363\t
> >
> 8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332",
> > <incomplete sequence \356>,
> >
> >     finish_md =
> >
> "\003\031\060Ha{\226\262\319\356\f,=Obv\213\241\270\478\351\003\036:Wu\224\268\365\327\352\376\023)@Xq\213\246\302\347\365\034<M_r\206\233\261\311\340\361\023.Jg\205\244\304\325\357\371\016#9Ph\201\233\266\344\357\r,L]o\202\226\253\301\330\360\t#>Zw\225\264\327\345\364\n\036\063I`x\221\253\306\342\377\035<\\m\177\222\246\273\328\350\000\031\063Nj\207\245\304\344\365\a\032.",
> > finish_md_len = -2005903037,
> >
> >     peer_finish_md =
> >
> "\241\273\326\366\017-Ll}\217\242\266\314\341\370\020)C^z\227\265\324\366\005\027*>Si\200\230\261\363\346\002\037=\\|\215\237\262\363\333\362\b
> >
> 9Sn\212\247\305\344\004\025':Ncy\220\250\301\333\366\022/Ml\214\235\257\302\326\353\001\030\060Ic~\232\267\325\364\024%7J^s\211\240\270\321\353\006\"?]|\234\255\277\325\346\373\021(@Ys\216\252\307\345\004$5GZn\203\242\260",
> > <incomplete sequence \310>, peer_finish_md_len = 840367073, message_size
> > = 2894884175, message_type = -152907843,
> >
> >     new_cipher = 0x5038210b, dh = 0xba9e8369, ecdh = 0x3414f5d7,
> > next_state = 2120898373, reuse_message = -658462317, cert_req =
> > 1109789681, ctype_num = -1130594977,
> >
> >     ctype = "\315\337\362\006\033\061H`y", ca_names = 0x442405e7,
> > use_rsa_tmp = -1904580779, key_block_length = -388974173,
> >
> >     key_block = 0x52361b01 <Address 0x52361b01 out of bounds>,
> > new_sym_enc = 0xccac8d6f, new_hash = 0x1602efdd, new_mac_pkey_type =
> > 1884832043,
> >
> >     new_mac_secret_size = -625040503, new_compression = 0x543415f7
> > <Address 0x543415f7 out of bounds>, cert_request = -1635092635},
> >
> >   previous_client_finished =
> >
> "\263\311\350\370\021+Fb\177\235\274\344\355\377\022&;Qh\200\241\263\326\352\a%Ddu\207\234\256\303\331\340\b!;Vr\217\255\314\364\375\027\"6Kax\220\251\303\336\362\029\065Tt\205\227\252\279",
> > previous_client_finished_len = 211 '\323',
> >
> >   previous_server_finished =
> >
> "\351\000\032\061Kf\202\247\275\334\374\r\037\062F[q\210\240\271\325\356\n'Ed\204\325\247\272\316\363\371\020(A[v\222\257\315\354\f\035/BVk\201\230\260\311\343\376\032\067Ut\224\255\267\312\346",
> > <incomplete sequence \363>, previous_server_finished_len = 9 '\t',
> > send_connection_binding = -1568249007,
> >
> >   next_proto_neg_seen = 486333887, is_probably_safari = 45 '-',
> > alpn_selected = 0xc0a8917b <Address 0xc0a8917b out of bounds>,
> > alpn_selected_len = 705623001}
> >
> > (gdb) n
> >
> > *** glibc detected *** vikftp: double free or corruption (!prev):
> > 0x08736610 ***
> >
> > Missing separate debuginfo for /lib/libgcc_s.so.1
> >
> > ======= Backtrace: =========
> >
> > /lib/libc.so.6[0xf75b3a51]
> >
> > /lib/libc.so.6(__libc_free+0x84)[0xf75b5224]
> >
> > vikftp(CRYPTO_free+0x40)[0x820e9e8]
> >
> > vikftp(ssl3_free+0x198)[0x82e15c1]
> >
> > vikftp(tls1_free+0x3b)[0x823b034]
> >
> > vikftp(SSL_free+0x1fd)[0x8230151]
> >
> > vikftp[0x8165dac]
> >
> > vikftp[0x815236b]
> >
> > vikftp[0x8156afe]
> >
> > vikftp[0x8154a3f]
> >
> > vikftp[0x8154578]
> >
> > vikftp(vikftp+0x2ea)[0x8150e6a]
> >
> > vikftp(main+0x17f)[0x81f8173]
> >
> > /lib/libc.so.6(__libc_start_main+0xdc)[0xf756589c]
> >
> > vikftp[0x8094441]
> >
> > ======= Memory map: ========
> >
> > 08048000-0862c000 r-xp 00000000 fd:00 854843
> > /App/vikftp
> >
> > 0862c000-08670000 rwxp 005e4000 fd:00 854843
> > /App/vikftp
> >
> > 08670000-08765000 rwxp 08670000 00:00 0
> > [heap]
> >
> > f6e00000-f6e21000 rwxp f6e00000 00:00 0
> >
> > f6e21000-f6f00000 ---p f6e21000 00:00 0
> >
> > f6f25000-f6f26000 rwxp f6f25000 00:00 0
> >
> > f6f26000-f6f27000 rwxs 00000000 ca:02 1057441
> > /var/vik/tmp/AMCMMON
> >
> > f6f27000-f6f28000 rwxs 00000000 ca:02 155213
> >                          /var/vik/tmp/AMLOG
> >
> > f6f28000-f6f2f000 r-xs 00000000 ca:02 26686
> > /usr/lib/gconv/gconv-modules.cache
> >
> > f6f2f000-f6f62000 r-xp 00000000 ca:02 30659
> > /usr/lib/locale/en_US.utf8/LC_CTYPE
> >
> > f7491000-f74c6000 r-xs 00000000 ca:02 269730
> > /var/run/nscd/group
> >
> > f74c6000-f74fb000 r-xs 00000000 ca:02 269729
> > /var/run/nscd/passwd
> >
> > f74fb000-f753d000 rwxp f74fb000 00:00 0
> >
> > f753d000-f754e000 r-xp 00000000 ca:02 26359
> > /lib/libaudit.so.0.0.0
> >
> > f754e000-f7550000 rwxp 00010000 ca:02 26359
> > /lib/libaudit.so.0.0.0
> >
> > f7550000-f768b000 r-xp 00000000 ca:02 25372
> > /lib/libc-2.4.so <http://libc-2.4.so>
> >
> > f768b000-f768c000 rwxp 0013a000 ca:02 25372
> > /lib/libc-2.4.so <http://libc-2.4.so>
> >
> > f768c000-f768d000 r-xp 0013b000 ca:02 25372
> > /lib/libc-2.4.so <http://libc-2.4.so>
> >
> > f768d000-f768f000 rwxp 0013c000 ca:02 25372
> > /lib/libc-2.4.so <http://libc-2.4.so>
> >
> > f768f000-f7693000 rwxp f768f000 00:00 0
> >
> > f7693000-f76b8000 r-xp 00000000 ca:02 25380
> > /lib/libm-2.4.so <http://libm-2.4.so>
> >
> > f76b8000-f76ba000 rwxp 00025000 ca:02 25380
> > /lib/libm-2.4.so <http://libm-2.4.so>
> >
> > f76ba000-f76c4000 r-xp 00000000 ca:02 36150
> > /lib/libpam.so.0.81.5
> >
> > f76c4000-f76c5000 rwxp 00009000 ca:02 36150
> > /lib/libpam.so.0.81.5
> >
> > f76c5000-f76c8000 r-xp 00000000 ca:02 25378
> > /lib/libdl-2.4.so <http://libdl-2.4.so>
> >
> > f76c8000-f76ca000 rwxp 00002000 ca:02 25378
> > /lib/libdl-2.4.so <http://libdl-2.4.so>
> >
> > f76ca000-f76d3000 r-xp 00000000 ca:02 25376
> > /lib/libcrypt-2.4.so <http://libcrypt-2.4.so>
> >
> > f76d3000-f76d6000 rwxp 00008000 ca:02 25376
> > /lib/libcrypt-2.4.so <http://libcrypt-2.4.so>
> >
> > f76d6000-f76fd000 rwxp f76d6000 00:00 0
> >
> > f770b000-f7715000 r-xp 00000000 ca:02 30823
> > /lib/libgcc_s.so.1
> >
> > f7715000-f7716000 rwxp 00009000 ca:02 30823
> > /lib/libgcc_s.so.1
> >
> > f7718000-f7719000 rwxp f7718000 00:00 0
> >
> > f7719000-f7735000 r-xp 00000000 ca:02 25365
> > /lib/ld-2.4.so <http://ld-2.4.so>
> >
> > f7735000-f7737000 rwxp 0001b000 ca:02 25365
> /l
> >
> > Program received signal SIGABRT, Aborted.
> >
> > 0xffffe410 in ?? ()
> >
> > (gdb) bt
> >
> > #0  0xffffe410 in ?? ()
> >
> > #1  0x00000006 in ?? ()
> >
> > #2  0x0000704d in ?? ()
> >
> > #3  0xf7578a30 in raise () from /lib/libc.so.6
> >
> > #4  0xf757a153 in abort () from /lib/libc.so.6
> >
> > #5  0xf75ae08b in __libc_message () from /lib/libc.so.6
> >
> > #6  0xf75b3a51 in malloc_printerr () from /lib/libc.so.6
> >
> > #7  0xf75b5224 in free () from /lib/libc.so.6
> >
> > #8  0x0820e9e8 in CRYPTO_free (str=0x8736610) at /102d/s/mem.c:442
> >
> > #9  0x082e15c1 in ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:3047
> >
> > #10 0x0823b034 in tls1_free (s=0x8736430) at /102d/s/t1_lib.c:217
> >
> > #11 0x08230151 in SSL_free (s=0x8736430) at /102d/s/ssl_lib.c:639
> >
> > #12 0x08165dac in closeConnection (pcx=0x86e0400, rsn=0x0, graceful=1
> > '\001') at /App/ftp.c:10098
> >
> > On 25 Feb 2016 2:20 pm, "Mike Mohr" <akihana at gmail.com
> > <mailto:akihana at gmail.com>> wrote:
> >
> >     You'll need to rebuild your application and openssl with debugging
> >     symbols and no optimization, then run it inside gdb to produce a
> >     more useful stack trace. Since you don't include any context or
> >     source code snippets it isn't really possible to help. Can you
> >     produce a reduced test case with source code which reproduces the
> bug?
> >
> >     As long as politics is the shadow cast on society by big business,
> >     the attenuation of the shadow will not change the substance.
> >
> >     John Dewey: The Later Works, 1925-1953; Volume 6, pp. 163
> >
> >     On Feb 24, 2016 11:33 PM, "Vikas TM" <vikas.tm at gmail.com
> >     <mailto:vikas.tm at gmail.com>> wrote:
> >
> >         Hi,
> >
> >         While running my application with openSSL 102d and I encountered
> >         double free error or corruption.
> >
> >         As per few threads suggestion, I have changed getpid() with
> >         pthread_self() in CRYPTO_thread_id(). Still the result is same.
> >
> >         Please let me know if any fix available to this issue.
> >
> >         *** glibc detected *** xxx: double free or corruption (!prev):
> >         0x097b8750 ***
> >
> >         ======= Backtrace: =========
> >
> >         /lib/libc.so.6[0x1768b6]
> >
> >         /lib/libc.so.6(cfree+0x90)[0x179e00]
> >
> >         xxx(CRYPTO_free+0x3a)[0x81b89be]
> >
> >         xxx(ssl_cert_free+0x13f)[0x826fa23]
> >
> >         xxx(SSL_free+0x14d)[0x81d7e08]
> >
> >         Thanks & Regards,
> >         Vikas
> >
> >
> >         --
> >         openssl-users mailing list
> >         To unsubscribe:
> >         https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> >     --
> >     openssl-users mailing list
> >     To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160407/9c552977/attachment-0001.html>

From alex at samad.com.au  Fri Apr  8 05:39:20 2016
From: alex at samad.com.au (Alex Samad)
Date: Fri, 8 Apr 2016 15:39:20 +1000
Subject: [openssl-users] Question about timestamps
Message-ID: <CAJ+Q1PUxgxViQzfGsYhVT=chs7_HZfbk+xxAJj_K=TeNmiciMQ@mail.gmail.com>

Hi

I am trying to use a rfc3161 timestamp service to record timestamps.


Basically I have a sha of some files and I would like to sign the file.

basically I am using something like this

# Generate Query and send
$OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H
"Content-Type:application/timestamp-query" --data-binary "@-" $TSA >
"${FL}.tsr"

$OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt"


where FL = is file.

What I want to be able to do is verify the .tsr file

testing that with

openssl ts -verify -data SHA.sha -in SHA.sha.tsr


where SHA.sha is the original FL

but I get

Verification: FAILED
140221656393544:error:2107C080:PKCS7
routines:PKCS7_get0_signers:signer certificate not
found:pk7_smime.c:476:

from the text output
 cat *.txt
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: 2.16.840.1.113733.1.7.23.3
Hash Algorithm: sha256
Message data:
    0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6   .m.[.......WE.i.
    0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5   z.....U%..W7>\..
Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9
Time stamp: Apr  8 04:58:08 2016 GMT
Accuracy: 0x1E seconds, unspecified millis, unspecified micros
Ordering: no
Nonce: 0x8E67A9941BCB2570
TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
Network/CN=Symantec SHA256 TimeStamping Signer - G1
Extensions:




I am guessing my problem is the above certificate is not in the ssl
path. and currently I am unable to find it on the symantec site.

Am I doing the right think ?
I have also looked at global sign and similar issue, find the cert

what am i missing

A

From jb-openssl at wisemo.com  Fri Apr  8 05:49:57 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 8 Apr 2016 07:49:57 +0200
Subject: [openssl-users] Question about timestamps
In-Reply-To: <CAJ+Q1PUxgxViQzfGsYhVT=chs7_HZfbk+xxAJj_K=TeNmiciMQ@mail.gmail.com>
References: <CAJ+Q1PUxgxViQzfGsYhVT=chs7_HZfbk+xxAJj_K=TeNmiciMQ@mail.gmail.com>
Message-ID: <57074685.7010308@wisemo.com>

On 08/04/2016 07:39, Alex Samad wrote:
> Hi
>
> I am trying to use a rfc3161 timestamp service to record timestamps.
>
>
> Basically I have a sha of some files and I would like to sign the file.
>
> basically I am using something like this
>
> # Generate Query and send
> $OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H
> "Content-Type:application/timestamp-query" --data-binary "@-" $TSA >
> "${FL}.tsr"
>
> $OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt"
>
>
> where FL = is file.
>
> What I want to be able to do is verify the .tsr file
>
> testing that with
>
> openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>
>
> where SHA.sha is the original FL
>
> but I get
>
> Verification: FAILED
> 140221656393544:error:2107C080:PKCS7
> routines:PKCS7_get0_signers:signer certificate not
> found:pk7_smime.c:476:
>
> from the text output
>   cat *.txt
> Status info:
> Status: Granted.
> Status description: unspecified
> Failure info: unspecified
>
> TST info:
> Version: 1
> Policy OID: 2.16.840.1.113733.1.7.23.3
> Hash Algorithm: sha256
> Message data:
>      0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6   .m.[.......WE.i.
>      0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5   z.....U%..W7>\..
> Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9
> Time stamp: Apr  8 04:58:08 2016 GMT
> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
> Ordering: no
> Nonce: 0x8E67A9941BCB2570
> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
> Network/CN=Symantec SHA256 TimeStamping Signer - G1
> Extensions:
I think this certificate is the end entity certificate
for the Symantec time stamping server that responded to
your request.

If you dump the full contents of the TSR it should include
that certificate somewhere, plus a chain leading to a
public root which is hopefully in your list of trusted
certificates or at least available via some other secure
method.

>
>
>
> I am guessing my problem is the above certificate is not in the ssl
> path. and currently I am unable to find it on the symantec site.
>
> Am I doing the right think ?
> I have also looked at global sign and similar issue, find the cert
>
> what am i missing


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 alex at samad.com.au  Fri Apr  8 06:01:50 2016
From: alex at samad.com.au (Alex Samad)
Date: Fri, 8 Apr 2016 16:01:50 +1000
Subject: [openssl-users] Question about timestamps
In-Reply-To: <57074685.7010308@wisemo.com>
References: <CAJ+Q1PUxgxViQzfGsYhVT=chs7_HZfbk+xxAJj_K=TeNmiciMQ@mail.gmail.com>
 <57074685.7010308@wisemo.com>
Message-ID: <CAJ+Q1PWrVExh=xNS+hr2YJJDCfzd6LwSatnc=iDp17ySc2m9Yw@mail.gmail.com>

Okay, how do I dump the intermediaries then ?



On 8 April 2016 at 15:49, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> On 08/04/2016 07:39, Alex Samad wrote:
>>
>> Hi
>>
>> I am trying to use a rfc3161 timestamp service to record timestamps.
>>
>>
>> Basically I have a sha of some files and I would like to sign the file.
>>
>> basically I am using something like this
>>
>> # Generate Query and send
>> $OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H
>> "Content-Type:application/timestamp-query" --data-binary "@-" $TSA >
>> "${FL}.tsr"
>>
>> $OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt"
>>
>>
>> where FL = is file.
>>
>> What I want to be able to do is verify the .tsr file
>>
>> testing that with
>>
>> openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>>
>>
>> where SHA.sha is the original FL
>>
>> but I get
>>
>> Verification: FAILED
>> 140221656393544:error:2107C080:PKCS7
>> routines:PKCS7_get0_signers:signer certificate not
>> found:pk7_smime.c:476:
>>
>> from the text output
>>   cat *.txt
>> Status info:
>> Status: Granted.
>> Status description: unspecified
>> Failure info: unspecified
>>
>> TST info:
>> Version: 1
>> Policy OID: 2.16.840.1.113733.1.7.23.3
>> Hash Algorithm: sha256
>> Message data:
>>      0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
>> .m.[.......WE.i.
>>      0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
>> z.....U%..W7>\..
>> Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9
>> Time stamp: Apr  8 04:58:08 2016 GMT
>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
>> Ordering: no
>> Nonce: 0x8E67A9941BCB2570
>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
>> Network/CN=Symantec SHA256 TimeStamping Signer - G1
>> Extensions:
>
> I think this certificate is the end entity certificate
> for the Symantec time stamping server that responded to
> your request.
>
> If you dump the full contents of the TSR it should include
> that certificate somewhere, plus a chain leading to a
> public root which is hopefully in your list of trusted
> certificates or at least available via some other secure
> method.
>
>>
>>
>>
>> I am guessing my problem is the above certificate is not in the ssl
>> path. and currently I am unable to find it on the symantec site.
>>
>> Am I doing the right think ?
>> I have also looked at global sign and similar issue, find the cert
>>
>> what am i missing
>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From jb-openssl at wisemo.com  Fri Apr  8 06:26:21 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 8 Apr 2016 08:26:21 +0200
Subject: [openssl-users] Question about timestamps
In-Reply-To: <CAJ+Q1PWrVExh=xNS+hr2YJJDCfzd6LwSatnc=iDp17ySc2m9Yw@mail.gmail.com>
References: <CAJ+Q1PUxgxViQzfGsYhVT=chs7_HZfbk+xxAJj_K=TeNmiciMQ@mail.gmail.com>
 <57074685.7010308@wisemo.com>
 <CAJ+Q1PWrVExh=xNS+hr2YJJDCfzd6LwSatnc=iDp17ySc2m9Yw@mail.gmail.com>
Message-ID: <57074F0D.9060300@wisemo.com>

Try something like

$OPENSSL ts -reply -in ${FL}.tsr -text -noout

(Not sure if it accepts the -noout option or not).

On 08/04/2016 08:01, Alex Samad wrote:
> Okay, how do I dump the intermediaries then ?
>
>
>
> On 8 April 2016 at 15:49, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> On 08/04/2016 07:39, Alex Samad wrote:
>>> Hi
>>>
>>> I am trying to use a rfc3161 timestamp service to record timestamps.
>>>
>>>
>>> Basically I have a sha of some files and I would like to sign the file.
>>>
>>> basically I am using something like this
>>>
>>> # Generate Query and send
>>> $OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H
>>> "Content-Type:application/timestamp-query" --data-binary "@-" $TSA >
>>> "${FL}.tsr"
>>>
>>> $OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt"
>>>
>>>
>>> where FL = is file.
>>>
>>> What I want to be able to do is verify the .tsr file
>>>
>>> testing that with
>>>
>>> openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>>>
>>>
>>> where SHA.sha is the original FL
>>>
>>> but I get
>>>
>>> Verification: FAILED
>>> 140221656393544:error:2107C080:PKCS7
>>> routines:PKCS7_get0_signers:signer certificate not
>>> found:pk7_smime.c:476:
>>>
>>> from the text output
>>>    cat *.txt
>>> Status info:
>>> Status: Granted.
>>> Status description: unspecified
>>> Failure info: unspecified
>>>
>>> TST info:
>>> Version: 1
>>> Policy OID: 2.16.840.1.113733.1.7.23.3
>>> Hash Algorithm: sha256
>>> Message data:
>>>       0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
>>> .m.[.......WE.i.
>>>       0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
>>> z.....U%..W7>\..
>>> Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9
>>> Time stamp: Apr  8 04:58:08 2016 GMT
>>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
>>> Ordering: no
>>> Nonce: 0x8E67A9941BCB2570
>>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1
>>> Extensions:
>> I think this certificate is the end entity certificate
>> for the Symantec time stamping server that responded to
>> your request.
>>
>> If you dump the full contents of the TSR it should include
>> that certificate somewhere, plus a chain leading to a
>> public root which is hopefully in your list of trusted
>> certificates or at least available via some other secure
>> method.
>>

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 markus.reusch at raiffeisen.ch  Fri Apr  8 06:52:50 2016
From: markus.reusch at raiffeisen.ch (Markus Reusch)
Date: Fri, 8 Apr 2016 06:52:50 +0000
Subject: [openssl-users] Regarding s_client -proxy option
Message-ID: <afb631f639e74bf992aa5c03b25508c8@MAAGEST025.ad.raiffeisen.ch>

Hello all,

I am in search of the -proxy option for s_client. According to https://www.openssl.org/docs/manmaster/apps/s_client.html it should be implemented, but when compiling the latest stable version 1.0.2g I just get the message, that -proxy for s_client is an unknown option.
Searching all archives for all 4 mailing lists I found this:

https://mta.openssl.org/pipermail/openssl-dev/2015-May/001502.html

and this:

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

Can anybody tell me, if it is implemented or not or if the documentation is wrong? Or is there some special configure option that has to be used to get the -proxy option?

Thanks a lot in forward.


Cheers
Markus
*****************************************************
This e-mail may contain confidential material. It is intended only for the person or entity which it is addressed to. In case you should not be supposed to get this e-mail we ask you to delete it without taking notice of its content. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of The Swiss Raiffeisen Group. Therefore this e-mail does not represent a binding agreement nor an offer to deal. E-Mail transmission can be insecure and can contain errors. Information could be intercepted, corrupted, lost, destroyed, incomplete or may contain viruses. Neither The Swiss Raiffeisen Group nor the sender can accept any liability for any kind of damage as the result of viruses or transmission errors.
*****************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160408/542aa5e3/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5416 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160408/542aa5e3/attachment-0001.bin>

From openssl-users at dukhovni.org  Fri Apr  8 07:22:53 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 8 Apr 2016 03:22:53 -0400
Subject: [openssl-users] Regarding s_client -proxy option
In-Reply-To: <afb631f639e74bf992aa5c03b25508c8@MAAGEST025.ad.raiffeisen.ch>
References: <afb631f639e74bf992aa5c03b25508c8@MAAGEST025.ad.raiffeisen.ch>
Message-ID: <0D9846E6-8090-4B0D-9DD4-66AC35318B86@dukhovni.org>


> On Apr 8, 2016, at 2:52 AM, Markus Reusch <markus.reusch at raiffeisen.ch> wrote:
> 
> I am in search of the ?proxy option for s_client. According to https://www.openssl.org/docs/manmaster/apps/s_client.html it should be implemented

That's the documentation for the upcoming 1.1.0 release.  The related
1.0.2 document is:

   https://www.openssl.org/docs/man1.0.2/apps/s_client.html

which makes no mention of the "-proxy" option, refreshingly, not for
lack of documentation, but rather because it is in fact not available.

-- 
-- 
	Viktor.


From kenchow.cn at gmail.com  Fri Apr  8 07:31:54 2016
From: kenchow.cn at gmail.com (Ken Chow)
Date: Fri, 8 Apr 2016 15:31:54 +0800
Subject: [openssl-users] Execute failed when I tried to enable fips_mode.
Message-ID: <CAAQPBEbioMx0neXNJEysXCXhi+p5v3V5ky66RbfJ5ifcAifgyA@mail.gmail.com>

Dear all,

I am trying to compile a sample for testing openssl FIP mode, I have
successfully compiled executable file in ubuntu 14.04.

*Sample:*
/* test.c */
#include <stdio.h>
#include <openssl/crypto.h>
#include <openssl/err.h>
#include <openssl/fips.h>

int main()
{
#ifdef OPENSSL_FIPS
    if(!FIPS_mode_set(1))
    {
        fprintf(stderr, "MSG: \n");
        ERR_load_crypto_strings();
        ERR_print_errors_fp(stderr);
        exit(1);
    }
    else
        fprintf(stderr,"*** IN FIPS MODE ***\n");

#else
    fprintf(stderr, "NO DEFINE_FIPS !\n");
#endif
}

*The error message I got:*

MSG:
140270859593376:error:0F06D065:common libcrypto routines:FIPS_mode_set:fips
mode not supported:o_fips.c:92:


*Makefile for sample:*

# targets
BIN = test
OBJS= test.c

# openssl
OPENSSLDIR = /home/ken/Work/openssl-fips/compile_fips/ssl/

# relevant path
INCLUDES = -I$(OPENSSLDIR)/include/
INCLUDES += -I$(OPENSSLDIR)/fips2.0/include/
LFLAGS = -L$(OPENSSLDIR)/lib/

# compiler
CC = $(OPENSSLDIR)/fips2.0/bin/fipsld
export FIPSLD_CC=gcc
CFLAGS = -Wall

# for FIPS
FIPSMODULE = $(OPENSSLDIR)/fips2.0/lib/fipscanister.o

# librarys
LIBS = -lcrypto -lssl -ldl

$(BIN): $(OBJS) $(FIPSMODULE)
$(CC) $(CLFAGS) -o $@ $(OBJS) $(INCLUDES) $(LFLAGS) $(LIBS)

clean:
rm -rf $(BIN) *.o

*And the Makefile for building and installing openssl fips mode:*

#
all: openssl-1.0.1c/.built setenv

openssl-fips-2.0.12.tar.gz:
#wget http://www.openssl.org/source/openssl-fips-2.0.1.tar.gz
wget http://45.78.29.98/openssl-fips-2.0.12.tar.gz

openssl-1.0.2g.tar.gz:
#wget http://www.openssl.org/source/openssl-1.0.1c.tar.gz
wget http://45.78.29.98/openssl-1.0.2g.tar.gz

ssl/:
mkdir ssl

setenv:
env OPENSSL_FIPS=1

openssl-fips-2.0.12/.built: openssl-fips-2.0.12.tar.gz ssl/ setenv
gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -
cd openssl-fips-2.0.12 && \
export FIPSDIR=$$PWD/../ssl/fips2.0 && \
./config && \
make && \
make install && \
touch .built

openssl-1.0.1c/.built: openssl-fips-2.0.12/.built openssl-1.0.2g.tar.gz
gunzip  -c openssl-1.0.2g.tar.gz | tar xf -
cd openssl-1.0.2g && \
./config fips shared --openssldir=$$PWD/../ssl
--with-fipsdir=$$PWD/../ssl/fips2.0 && \
make depend && \
make && \
make install_sw &&\
touch .built

clean:
rm -rf openssl-fips-2.0.12 openssl-1.0.2g ssl


so, how should I enable openssl fips mode? thank you for you help.
<http://about.me/kenchowcn>


Ken Chow
about.me/kenchowcn
[image: Ken Chow on about.me]
  <http://about.me/kenchowcn>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160408/0af775ba/attachment.html>

From markus.reusch at raiffeisen.ch  Fri Apr  8 08:01:49 2016
From: markus.reusch at raiffeisen.ch (Markus Reusch)
Date: Fri, 8 Apr 2016 08:01:49 +0000
Subject: [openssl-users] Regarding s_client -proxy option
In-Reply-To: <0D9846E6-8090-4B0D-9DD4-66AC35318B86@dukhovni.org>
References: <afb631f639e74bf992aa5c03b25508c8@MAAGEST025.ad.raiffeisen.ch>
 <0D9846E6-8090-4B0D-9DD4-66AC35318B86@dukhovni.org>
Message-ID: <75778fb222bb4166831d87e2f85d4009@MAAGEST025.ad.raiffeisen.ch>

Hello Viktor,

from what I can see there is no number wether in the URL nor on the page itself, that shows this docu is meant for the upcoming version 1.1.0.
Though it's clear now.

Thanks a lot for the hint!

Cheers
Markus

-----Urspr?ngliche Nachricht-----
Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Viktor Dukhovni
Gesendet: Freitag, 8. April 2016 09:23
An: openssl-users at openssl.org
Betreff: Re: [openssl-users] Regarding s_client -proxy option


> On Apr 8, 2016, at 2:52 AM, Markus Reusch <markus.reusch at raiffeisen.ch> wrote:
> 
> I am in search of the ?proxy option for s_client. According to https://www.openssl.org/docs/manmaster/apps/s_client.html it should be implemented

That's the documentation for the upcoming 1.1.0 release.  The related
1.0.2 document is:

   https://www.openssl.org/docs/man1.0.2/apps/s_client.html

which makes no mention of the "-proxy" option, refreshingly, not for
lack of documentation, but rather because it is in fact not available.

-- 
-- 
	Viktor.

-- 
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
*****************************************************
This e-mail may contain confidential material. It is intended only for the person or entity which it is addressed to. In case you should not be supposed to get this e-mail we ask you to delete it without taking notice of its content. Any views or opinions expressed in this e-mail are those of the sender and do not necessarily coincide with those of The Swiss Raiffeisen Group. Therefore this e-mail does not represent a binding agreement nor an offer to deal. E-Mail transmission can be insecure and can contain errors. Information could be intercepted, corrupted, lost, destroyed, incomplete or may contain viruses. Neither The Swiss Raiffeisen Group nor the sender can accept any liability for any kind of damage as the result of viruses or transmission errors.
*****************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5416 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160408/7bef68c2/attachment-0001.bin>

From sandeepkiranp at gmail.com  Fri Apr  8 08:56:00 2016
From: sandeepkiranp at gmail.com (sandeep kiran p)
Date: Fri, 8 Apr 2016 14:26:00 +0530
Subject: [openssl-users] segv in 1.0.2 bn_power5
In-Reply-To: <CAAxGnDBhMeg85+XxOriVJXgm4UbRsSVP1oYD7uvz_xqs__OonQ@mail.gmail.com>
References: <CAAxGnDBhMeg85+XxOriVJXgm4UbRsSVP1oYD7uvz_xqs__OonQ@mail.gmail.com>
Message-ID: <CAAxGnDBstN3OTzPgivw9VAJsiP2J2wPZkzzhOOE+2Bt8JJv-Sw@mail.gmail.com>

Can anyone help me here?

Thanks
Sandeep

On Wed, Apr 6, 2016 at 6:34 PM, sandeep kiran p <sandeepkiranp at gmail.com>
wrote:

> Hi,
>
> Ours is a TLS proxy component where we act as MITM for certain traffic
> between clients and servers for analysis. We recently migrated from 1.0.1q
> to 1.0.2g after which we are seeing frequent crashes in the process all
> with the following backtrace
>
> #1  0x00007f877ea2427f in sigcrash (signo=11, info=<optimized out>,
> ctx=0x7fff899b5f80)
> #2  <signal handler called>
> #3  bn_sqr8x_internal () at x86_64-mont5.s:1369
> #4  0x00007f877b5a7ebf in bn_power5 () at x86_64-mont5.s:797
> #5  0x0000000000000100 in ?? ()
> #6  0x00007fff899b6530 in ?? ()
> #7  0x00007f8786e9f140 in ?? ()
> #8  0x0000000000000000 in ?? ()
>
> The process is single threaded where we process packets as they come
> along. When the process is lightly loaded (around 10 connections) things
> are fine. We see the crash when we are processing say more than 40
> connections.
>
> Everything was working perfectly fine in 1.0.1.
>
> Can someone hep us on what could have gone wrong with 1.0.2?
>
> Thanks
> Sandeep
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160408/4bae86e2/attachment.html>

From sharma.khushbu850 at gmail.com  Fri Apr  8 10:29:14 2016
From: sharma.khushbu850 at gmail.com (khushboo)
Date: Fri, 8 Apr 2016 03:29:14 -0700 (MST)
Subject: [openssl-users] "length" field of DH (dh_st) structure defined in
 dh.h file removed in boringssl
Message-ID: <1460111354748-65482.post@n7.nabble.com>

Hi,
    The "length" field of dh_st structure defined in "dh.h" file is removed
in BoringSSL. I am porting my application for BoringSSL but is giving this
error.

Also in dh.h field this field is mentioned as optional.

Could you please suggest what is the relevance of this field and what impact
does it have after getting removed in BoringSSL?

Thanks
Khushboo



--
View this message in context: http://openssl.6102.n7.nabble.com/length-field-of-DH-dh-st-structure-defined-in-dh-h-file-removed-in-boringssl-tp65482.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From sharma.khushbu850 at gmail.com  Fri Apr  8 11:30:31 2016
From: sharma.khushbu850 at gmail.com (khushbu sharma)
Date: Fri, 8 Apr 2016 17:00:31 +0530
Subject: [openssl-users] "length" field of DH (dh_st) structure defined in
 dh.h file removed in boringssl
Message-ID: <CAJ_4j44znCCL8mDKkLQt87sOYpVZeKKdSKe6JuM4-_TLBKM+Xg@mail.gmail.com>

Hi,
    The "length" field of dh_st structure defined in "dh.h" file is removed
in BoringSSL. I am porting my application for BoringSSL but is giving this
error.

Also in dh.h field this field is mentioned as optional.

Could you please suggest what is the relevance of this field and what
impact does it have after getting removed in BoringSSL?

Thanks
Khushboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160408/e5e58fed/attachment.html>

From marquess at openssl.com  Fri Apr  8 11:39:56 2016
From: marquess at openssl.com (Steve Marquess)
Date: Fri, 8 Apr 2016 07:39:56 -0400
Subject: [openssl-users] Execute failed when I tried to enable fips_mode.
In-Reply-To: <CAAQPBEbioMx0neXNJEysXCXhi+p5v3V5ky66RbfJ5ifcAifgyA@mail.gmail.com>
References: <CAAQPBEbioMx0neXNJEysXCXhi+p5v3V5ky66RbfJ5ifcAifgyA@mail.gmail.com>
Message-ID: <5707988C.7000202@openssl.com>

On 04/08/2016 03:31 AM, Ken Chow wrote:
> Dear all,
> 
> I am trying to compile a sample for testing openssl FIP mode, I have
> successfully compiled executable file in ubuntu 14.04.
> 
> *Sample:*
> /* test.c */
> #include <stdio.h>
> #include <openssl/crypto.h>
> #include <openssl/err.h>
> #include <openssl/fips.h>
> 
> int main()
> {
> #ifdef OPENSSL_FIPS 
>     if(!FIPS_mode_set(1)) 
>     {
>         fprintf(stderr, "MSG: \n");
>         ERR_load_crypto_strings();
>         ERR_print_errors_fp(stderr);
>         exit(1); 
>     } 
>     else
>         fprintf(stderr,"*** IN FIPS MODE ***\n");
> 
> #else
>     fprintf(stderr, "NO DEFINE_FIPS !\n");
> #endif 
> }
> /
> /
> *The error message I got:*
> /
> /
> MSG: 
> 140270859593376:error:0F06D065:common libcrypto
> routines:FIPS_mode_set:fips mode not supported:o_fips.c:92:
> ...

You linked your test program with a stock version of OpenSSL, not the
"FIPS capable" OpenSSL that contains the OpenSSL FIPS Object Module.

Building of the "FIPS capable" OpenSSL is discussed in the OpenSSL FIPS
User Guide:

  https://www.openssl.org/docs/fips/UserGuide-2.0.pdf

-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 Doug.Smith at lairdtech.com  Fri Apr  8 14:01:13 2016
From: Doug.Smith at lairdtech.com (Doug Smith)
Date: Fri, 8 Apr 2016 14:01:13 +0000
Subject: [openssl-users] openSSL ciphertstring for FIPS and TLS?
Message-ID: <3E7B61D5B6EED54E880707354143137301F4DAD9FC@USDC01MBX02.corp.lairdtech.com>

All,

Apologies in advance if this is the wrong mailing list to send this to.

Looking for some guidance on correctly setting the openSSL cipherstring for TLS operation in FIPS mode.

The openSSL wiki page "FIPS mode and TLS" and the cipherstring configuration for openSSL appear to be out of date.
https://wiki.openssl.org/index.php/FIPS_mode_and_TLS
The information on the page appears to need an update as the NIST documents relating to this subject have been revised since the page was last updated.
For example, see NIST documents: SP800-131Ar1 and SP800-52r1.

Thanks in advance,
Doug




From jeremy.farrell at oracle.com  Fri Apr  8 15:46:50 2016
From: jeremy.farrell at oracle.com (Jeremy Farrell)
Date: Fri, 8 Apr 2016 16:46:50 +0100
Subject: [openssl-users] Regarding s_client -proxy option
In-Reply-To: <75778fb222bb4166831d87e2f85d4009@MAAGEST025.ad.raiffeisen.ch>
References: <afb631f639e74bf992aa5c03b25508c8@MAAGEST025.ad.raiffeisen.ch>
 <0D9846E6-8090-4B0D-9DD4-66AC35318B86@dukhovni.org>
 <75778fb222bb4166831d87e2f85d4009@MAAGEST025.ad.raiffeisen.ch>
Message-ID: <5707D26A.4050705@oracle.com>

The page you looked at says "master manpages" in bold at the top of the 
right hand column with "1.0.2 version" as one of the links for several 
different versions below. The URL you gave includes "manmaster" where 
the one you needed has "man1.0.2". It seems clear to me, though I 
suppose the use of "master" is jargon which is not necessarily obvious 
to everyone - it could be taken to mean "authoritative" for example. 
Perhaps "development" or "future release" would be clearer.

On 08/04/2016 09:01, Markus Reusch wrote:
> Hello Viktor,
>
> from what I can see there is no number wether in the URL nor on the page itself, that shows this docu is meant for the upcoming version 1.1.0.
> Though it's clear now.
>
> Thanks a lot for the hint!
>
> Cheers
> Markus
>
> Von: Viktor Dukhovni
>
>> On Apr 8, 2016, at 2:52 AM, Markus Reusch <markus.reusch at raiffeisen.ch> wrote:
>>
>> I am in search of the ?proxy option for s_client. According to https://www.openssl.org/docs/manmaster/apps/s_client.html it should be implemented
> That's the documentation for the upcoming 1.1.0 release.  The related
> 1.0.2 document is:
>
>     https://www.openssl.org/docs/man1.0.2/apps/s_client.html
>
> which makes no mention of the "-proxy" option, refreshingly, not for
> lack of documentation, but rather because it is in fact not available.

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

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

From alex at samad.com.au  Fri Apr  8 20:36:52 2016
From: alex at samad.com.au (Alex Samad)
Date: Sat, 9 Apr 2016 06:36:52 +1000
Subject: [openssl-users] Question about timestamps
In-Reply-To: <57074F0D.9060300@wisemo.com>
References: <CAJ+Q1PUxgxViQzfGsYhVT=chs7_HZfbk+xxAJj_K=TeNmiciMQ@mail.gmail.com>
 <57074685.7010308@wisemo.com>
 <CAJ+Q1PWrVExh=xNS+hr2YJJDCfzd6LwSatnc=iDp17ySc2m9Yw@mail.gmail.com>
 <57074F0D.9060300@wisemo.com>
Message-ID: <CAJ+Q1PWQU+8OdmWHVz7OKuSTffu_LA=p09paKuQ6=rrc30EXXw@mail.gmail.com>

Hi

Yep I have tried the output to text. but does that verify the signature.

So what I think I have now is

my data to be signed
I make a request
send the request to the tsa
the tsa signs it adds signature
I have response.

Now I need to verify it

openssl ts -verify -data SHA.sha -in SHA.sha.tsr

but it seems to fail, I presume (newbie), because I don't have the
intermediary certs .

I presume symantec have signed it with a cert thats rooted in one of
their main CA's and I presume for me to verify I need the
intermediaries or atleast the sign cert's ca.


I have looked on symantecs site to no available

and I am working on guess work here





On 8 April 2016 at 16:26, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> Try something like
>
> $OPENSSL ts -reply -in ${FL}.tsr -text -noout
>
> (Not sure if it accepts the -noout option or not).
>
>
> On 08/04/2016 08:01, Alex Samad wrote:
>>
>> Okay, how do I dump the intermediaries then ?
>>
>>
>>
>> On 8 April 2016 at 15:49, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>>>
>>> On 08/04/2016 07:39, Alex Samad wrote:
>>>>
>>>> Hi
>>>>
>>>> I am trying to use a rfc3161 timestamp service to record timestamps.
>>>>
>>>>
>>>> Basically I have a sha of some files and I would like to sign the file.
>>>>
>>>> basically I am using something like this
>>>>
>>>> # Generate Query and send
>>>> $OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H
>>>> "Content-Type:application/timestamp-query" --data-binary "@-" $TSA >
>>>> "${FL}.tsr"
>>>>
>>>> $OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt"
>>>>
>>>>
>>>> where FL = is file.
>>>>
>>>> What I want to be able to do is verify the .tsr file
>>>>
>>>> testing that with
>>>>
>>>> openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>>>>
>>>>
>>>> where SHA.sha is the original FL
>>>>
>>>> but I get
>>>>
>>>> Verification: FAILED
>>>> 140221656393544:error:2107C080:PKCS7
>>>> routines:PKCS7_get0_signers:signer certificate not
>>>> found:pk7_smime.c:476:
>>>>
>>>> from the text output
>>>>    cat *.txt
>>>> Status info:
>>>> Status: Granted.
>>>> Status description: unspecified
>>>> Failure info: unspecified
>>>>
>>>> TST info:
>>>> Version: 1
>>>> Policy OID: 2.16.840.1.113733.1.7.23.3
>>>> Hash Algorithm: sha256
>>>> Message data:
>>>>       0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
>>>> .m.[.......WE.i.
>>>>       0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
>>>> z.....U%..W7>\..
>>>> Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9
>>>> Time stamp: Apr  8 04:58:08 2016 GMT
>>>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
>>>> Ordering: no
>>>> Nonce: 0x8E67A9941BCB2570
>>>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
>>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1
>>>> Extensions:
>>>
>>> I think this certificate is the end entity certificate
>>> for the Symantec time stamping server that responded to
>>> your request.
>>>
>>> If you dump the full contents of the TSR it should include
>>> that certificate somewhere, plus a chain leading to a
>>> public root which is hopefully in your list of trusted
>>> certificates or at least available via some other secure
>>> method.
>>>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From kenchow.cn at gmail.com  Sat Apr  9 09:29:45 2016
From: kenchow.cn at gmail.com (Ken Chow)
Date: Sat, 9 Apr 2016 17:29:45 +0800
Subject: [openssl-users] Execute failed when I tried to enable fips_mode.
In-Reply-To: <5707988C.7000202@openssl.com>
References: <CAAQPBEbioMx0neXNJEysXCXhi+p5v3V5ky66RbfJ5ifcAifgyA@mail.gmail.com>
 <5707988C.7000202@openssl.com>
Message-ID: <CAAQPBEbcsQZ-UZ2jYUXYESV0o+TxX9Kc9RujyjF5yY6Be51mDQ@mail.gmail.com>

It's working now, and I pushed the installation makefile and test program
on  https://github.com/kenchowcn/build-openssl-for-FIPS , although the
UserGuide2.0 is great, I still hope that can help.

Thank you so much Steve.

<http://about.me/kenchowcn>


Ken Chow
about.me/kenchowcn
[image: Ken Chow on about.me]
  <http://about.me/kenchowcn>

2016-04-08 19:39 GMT+08:00 Steve Marquess <marquess at openssl.com>:

> On 04/08/2016 03:31 AM, Ken Chow wrote:
> > Dear all,
> >
> > I am trying to compile a sample for testing openssl FIP mode, I have
> > successfully compiled executable file in ubuntu 14.04.
> >
> > *Sample:*
> > /* test.c */
> > #include <stdio.h>
> > #include <openssl/crypto.h>
> > #include <openssl/err.h>
> > #include <openssl/fips.h>
> >
> > int main()
> > {
> > #ifdef OPENSSL_FIPS
> >     if(!FIPS_mode_set(1))
> >     {
> >         fprintf(stderr, "MSG: \n");
> >         ERR_load_crypto_strings();
> >         ERR_print_errors_fp(stderr);
> >         exit(1);
> >     }
> >     else
> >         fprintf(stderr,"*** IN FIPS MODE ***\n");
> >
> > #else
> >     fprintf(stderr, "NO DEFINE_FIPS !\n");
> > #endif
> > }
> > /
> > /
> > *The error message I got:*
> > /
> > /
> > MSG:
> > 140270859593376:error:0F06D065:common libcrypto
> > routines:FIPS_mode_set:fips mode not supported:o_fips.c:92:
> > ...
>
> You linked your test program with a stock version of OpenSSL, not the
> "FIPS capable" OpenSSL that contains the OpenSSL FIPS Object Module.
>
> Building of the "FIPS capable" OpenSSL is discussed in the OpenSSL FIPS
> User Guide:
>
>   https://www.openssl.org/docs/fips/UserGuide-2.0.pdf
>
> -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/20160409/95f7d063/attachment.html>

From ajaygargnsit at gmail.com  Mon Apr 11 04:31:33 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 11 Apr 2016 10:01:33 +0530
Subject: [openssl-users] Are double-quotes valid characters in
	certifcates/keys?
Message-ID: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>

Hi.

Could not find a definitive answer on google, so thought it would be
best to ask the experts :)


Thanks and Regards,
Ajay

From noloader at gmail.com  Mon Apr 11 04:44:33 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 11 Apr 2016 00:44:33 -0400
Subject: [openssl-users] Are double-quotes valid characters in
	certifcates/keys?
In-Reply-To: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
References: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
Message-ID: <CAH8yC8k1zE3n5H_EYenwtGbn5AMXp-afLoq966+k-uwE-W_9ug@mail.gmail.com>

> Could not find a definitive answer on google, so thought it would be
> best to ask the experts :)

Its probably been discussed on the PKIX mailing list at some point
(http://mailarchive.ietf.org/arch/search/?email_list=pkix).

Keys don't use them. Certificates can use them based on the ASN.1 type.

However, I work on a C++ project, and the CA removed the CN we
requested. I'm guessing it was because of the "++" in the common name
(friendly name displayed to the user), which may have wreaked havoc on
some scripts. I've been waiting to see a BlackHat talk on it.

Jeff

From abe.racioppo at gmail.com  Mon Apr 11 11:34:19 2016
From: abe.racioppo at gmail.com (Abe Racioppo)
Date: Mon, 11 Apr 2016 07:34:19 -0400
Subject: [openssl-users] CMS with Symmetric key
In-Reply-To: <20160405113905.GA22864@openssl.org>
References: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
 <20160405113905.GA22864@openssl.org>
Message-ID: <CAK4g_tc+1KbwTxcDAEAS63JddeUWGFjFGq7a3Jzkq0SS++zuAA@mail.gmail.com>

Thank you for the responses.

I have implemented encryption that adds a secret key, and secret key id
using:
CMS_add0_recipient_key,
CMS_EncryptData_encrypt,
SMIME_write_CMS
The output file looks correct, but I need to decrypt it back to be sure.

I would like to be able to get the secret key id from the envelope data to
then search a database for the key, and then CMS_decrypt.  I have yet to
determine the most straightforward way of getting the key ids from the
envelope/wrapped content of cms.

Is there a combination if I have SMIME_read the cms from a file like:
  keyId =  cms->envelopedData->keyId?

Or do I need to handle a stack_of recipient infos in order to get the key
id from kekri0_get_id?

Thanks again,
Abe


On Tue, Apr 5, 2016 at 7:39 AM, Dr. Stephen Henson <steve at openssl.org>
wrote:

> On Mon, Apr 04, 2016, Abe Racioppo wrote:
>
> > Hey guys,
> >
> > I'm trying to use the CMS operations in libcrypto but with a symmetric
> key
> > encryption key instead of x509.
> >
> > I'm thinking I want to use a combination of
> >
> > CMS_RecipientInfo_set0_pkey,
> > SMIME_write_CMS,
> > and
> > CMS_EncryptedData_encrypt.
> >
> > Has anyone done this before and can give me some direction?  This is my
> > first time working with openssl and am getting kinda lost.
> >
>
> You have several options here.
>
> You can just use the encrypted data type with a key directly.
>
> You can use the enveloped data type with a symmetric wrapping key.
>
> You can use the enveloped data type with a password based recipient info.
>
> Which you use depends on the application you have in mind.
>
> In the first case you just call CMS_EncryptData_encrypt() followed by
> SMIME_write_CMS().
>
> 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
>



-- 
signature
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160411/18829fbe/attachment.html>

From bbrumley at gmail.com  Mon Apr 11 12:48:41 2016
From: bbrumley at gmail.com (Billy Brumley)
Date: Mon, 11 Apr 2016 15:48:41 +0300
Subject: [openssl-users] ECC private key length
In-Reply-To: <20160406182251.GA22615@localhost>
References: <20160406182251.GA22615@localhost>
Message-ID: <CAFeDd5ZEfV7PFiwfBoPXW2WthK_mNqVtVAOQrY1SBDDRMe9iMQ@mail.gmail.com>

It's because of the form of the group order for the curves you list.
They look roughly like 2**n + 2**(n/2). So while technically possible
to end up with 161 bits, with overwhelming probability you end up with
less.

BBB

On Wed, Apr 6, 2016 at 9:22 PM, Frode Nilsen <frode at bitwise.no> wrote:
> Hi,
>
> When printing the contents of a PEM ECC keypair file for the secp160k1/r1/r2 curves, OpenSSL says the private key is 161 bits:
>
>         $ openssl ecparam -name secp160k1 -genkey -out test.pem
>         $ openssl ec -in test.pem -text -noout
>         read EC key
>         Private-Key: (161 bit)
>         priv:
>             77:76:fb:ae:7a:0b:97:98:aa:c0:70:7d:af:28:14:
>             6d:4f:03:d9:b5
>         pub:
>             04:9b:98:38:4a:d0:e4:22:a2:3f:80:ce:02:90:02:
>             d3:35:51:dc:8f:7b:5e:30:7d:2d:5e:98:6f:4b:9b:
>             4b:c8:01:1c:2d:ce:39:37:04:c5:61
>         ASN1 OID: secp160k1
>
> However, following "priv:", there are only 20 bytes (160 bits). Why is this?
>
> When printing the keypair for other curves, the number of bytes after "priv:" seem to always be the same or higher than the number of bits shown after "Private-Key:".
>
> Thanks in advance,
> Frode
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From vikas.tm at gmail.com  Mon Apr 11 14:50:38 2016
From: vikas.tm at gmail.com (Vikas TM)
Date: Mon, 11 Apr 2016 20:20:38 +0530
Subject: [openssl-users] Received signal SIGSEGV in CRYPTO_add_lock()
Message-ID: <CA+5R-ajnBurf2gQ2E-22QESfNpNFNXjejirJY9NoZot-j-gd8Q@mail.gmail.com>

Hi,

It looks like there is issue in handling crypto locks. I encountered
segmentation fault in CRYPTO_add_lock() function referencing NULL pointer.
Please find GDB output below,

(gdb) run ftp://x.x.x.x:sample.txt

Starting program: /App/vikftp ftp://x.x.x.x:sample.txt

Missing separate debuginfo for /lib/ld-linux.so.2

Missing separate debuginfo for /lib/libdl.so.2

Missing separate debuginfo for /lib/libpam.so.0

Missing separate debuginfo for /lib/libm.so.6

Missing separate debuginfo for /lib/libc.so.6

Missing separate debuginfo for /lib/libaudit.so.0

process 22287 is executing new program: /App/vikftp

Missing separate debuginfo for /lib/ld-linux.so.2

Missing separate debuginfo for /lib/libdl.so.2

Missing separate debuginfo for /lib/libpam.so.0

Missing separate debuginfo for /lib/libm.so.6

Missing separate debuginfo for /lib/libc.so.6

Missing separate debuginfo for /lib/libaudit.so.0



Program received signal SIGSEGV, Segmentation fault.

0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3,
file=0x85d0030 "/102d/s/tasn_utl.c", line=118)

    at /102d/s/cryptlib.c:624

624             ret = *pointer + amount;

(gdb) bt

#0  0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3,
file=0x85d0030 "/102d/s/tasn_utl.c", line=118)

    at /102d/s/cryptlib.c:624

#1  0x08249d2a in asn1_do_lock (pval=0xff8eee90, op=-1, it=0x862cb1c) at
/102d/s/tasn_utl.c:118

#2  0x08246ed5 in asn1_item_combine_free (pval=0xff8eee90, it=0x862cb1c,
combine=0) at /102d/s/tasn_fre.c:146

#3  0x08246c40 in ASN1_item_free (val=0x1001, it=0x862cb1c) at
/102d/s/tasn_fre.c:72

#4  0x0825eeea in X509_free (a=0x1001) at /102d/s/x_x509.c:143

#5  0x082ee677 in ssl_cert_clear_certs (c=0x872e4e0) at
/102d/s/ssl_cert.c:431

#6  0x082ee7ed in ssl_cert_free (c=0x872e4e0) at /102d/s/ssl_cert.c:489

#7  0x0822f926 in SSL_free (s=0x872e340) at /102d/s/ssl_lib.c:627

#8  0x0816566c in closeConnection (pcx=0x86d8310, rsn=0x0, graceful=1
'\001') at /App/vikftp.c:10098

Please let me know if you have any solution.

Thanks & Regards,
Vikas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160411/19f39468/attachment.html>

From openssl-users at dukhovni.org  Mon Apr 11 15:26:23 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 11 Apr 2016 15:26:23 +0000
Subject: [openssl-users] Are double-quotes valid characters in
 certifcates/keys?
In-Reply-To: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
References: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
Message-ID: <20160411152623.GY26423@mournblade.imrryr.org>

On Mon, Apr 11, 2016 at 10:01:33AM +0530, Ajay Garg wrote:

[ Subject: Are double-quotes valid characters in certifcates/keys? ]

> Could not find a definitive answer on google, so thought it would be
> best to ask the experts :)

The question is ill-formed.  Are you asking about allowed characters
in some field of the underlying canonical ASN.1 DER form of a
certificate, or about some particular encoding of the certificate
(e.g. PEM)?

If the former, X.509v3 certificates are complicated objects, which
part of the certificate are you asking about?

As for keys, in their ASN.1 DER encoding they are "binary" data,
and all octets are a priori valid in a public key.  A public key
algorithm that prohibits 0x22 seems unlikely.

-- 
	Viktor.

From c at gryning.com  Mon Apr 11 15:30:54 2016
From: c at gryning.com (c^)
Date: Mon, 11 Apr 2016 16:30:54 +0100
Subject: [openssl-users] openssl-1.1.0 sha1 performance
Message-ID: <CAK-1ke=F0HSk5c_T3hCCkHeJHrQoc1Nzp6V=KaAQKvcf=s5O7w@mail.gmail.com>

Afternoon,

I have been running some speed tests of openssl 1.0.1, 1.0.2 and 1.1.0
versions against various compiler optimisations. Special interest was given
to the more commonly used primitives, rsa's, aes's etc.

I noticed that SHA1's have some significant performance improvements.
However the multiplier by which it improved by diminishes as you approach
8k/16k block sizes.

Any ideas why this tails off?

I noticed no other 'statistically significant' change in other primitives,
although freely admit i have not exhaustively checked.

openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 16 size blocks:
9225205 sha1's in 3.00s
openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 64 size blocks:
7275849 sha1's in 3.00s
openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 256 size blocks:
4821329 sha1's in 3.00s
openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 1024 size blocks:
2059373 sha1's in 3.00s
openssl-1.0.2g-native-speed.txt:Doing sha1 for 3s on 8192 size blocks:
327032 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 16 size blocks:
23362218 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 64 size blocks:
14131714 sha1's in 2.99s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 256 size blocks:
7166139 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 1024 size blocks:
2413233 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 8192 size blocks:
335803 sha1's in 3.00s
openssl-1.1.0-pre4-native-speed.txt:Doing sha1 for 3s on 16384 size blocks:
169210 sha1's in 3.00s

I assume the positive change was part of:
  *) Extensive assembler packs updates, most notably:

- x86[_64]:     AES-NI, PCLMULQDQ, RDRAND support;
- x86[_64]:     SSSE3 support (SHA1, vector-permutation AES);
- x86_64:       bit-sliced AES implementation;
- ARM:          NEON support, contemporary platforms optimizations;
- s390x:        z196 support;
- *:            GHASH and GF(2^m) multiplication implementations;

     [Andy Polyakov]

Has anyone else completed any similar tests?

Thank you,
CraigT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160411/876d75eb/attachment.html>

From marquess at openssl.com  Mon Apr 11 16:22:19 2016
From: marquess at openssl.com (Steve Marquess)
Date: Mon, 11 Apr 2016 12:22:19 -0400
Subject: [openssl-users] FIPS 140-2 web site error
Message-ID: <570BCF3B.3080006@openssl.com>

If you neither know nor care what FIPS 140-2 is, this is your lucky day.
Avert your eyes and move on, nothing to see here.

The entry for the ancestral OpenSSL FIPS Object Module v2.0 validation,
#1747, on the NIST CMVP web site appears to be the victim of some sort
of clerical error:

  http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747

As of the time of this message that entry is showing the vendor as
"Cleversafe, an IBM Company" instead of "OpenSSL Software Foundation".
That is wrong.

I'm assuming random error as April Fool's day is more than a week behind
us, and we haven't been offered the bazillion dollars and a pony it
would take for us to agree to relinquish that validation.

I've asked the accredited test lab to contact the CMVP to correct it.
Based on past experience that could take days to weeks.

-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 ajaygargnsit at gmail.com  Mon Apr 11 16:53:55 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Mon, 11 Apr 2016 22:23:55 +0530
Subject: [openssl-users] Are double-quotes valid characters in
	certifcates/keys?
In-Reply-To: <20160411152623.GY26423@mournblade.imrryr.org>
References: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
 <20160411152623.GY26423@mournblade.imrryr.org>
Message-ID: <CAHP4M8VzBj9-yVS7gkHxb6HPQV1c5-9RWSXJLD2A16ka167Nww@mail.gmail.com>

Hi All.

Thanks for the help.

The certificate is a ".crt.pem".
Key is a ".key".

Anyhow, earlier I was thinking of saving the certificate+key in a
file, where double-quotes were delimiters.
But, I have rejected that idea; instead saving them in their respective files :)

So, the question becomes obsolete.


Anyhow, I am thanks (and sorry at the same time) for everyone's time.



Thanks and Regards,
Ajay

On Mon, Apr 11, 2016 at 8:56 PM, Viktor Dukhovni
<openssl-users at dukhovni.org> wrote:
> On Mon, Apr 11, 2016 at 10:01:33AM +0530, Ajay Garg wrote:
>
> [ Subject: Are double-quotes valid characters in certifcates/keys? ]
>
>> Could not find a definitive answer on google, so thought it would be
>> best to ask the experts :)
>
> The question is ill-formed.  Are you asking about allowed characters
> in some field of the underlying canonical ASN.1 DER form of a
> certificate, or about some particular encoding of the certificate
> (e.g. PEM)?
>
> If the former, X.509v3 certificates are complicated objects, which
> part of the certificate are you asking about?
>
> As for keys, in their ASN.1 DER encoding they are "binary" data,
> and all octets are a priori valid in a public key.  A public key
> algorithm that prohibits 0x22 seems unlikely.
>
> --
>         Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay

From rsalz at akamai.com  Mon Apr 11 16:57:48 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 11 Apr 2016 16:57:48 +0000
Subject: [openssl-users] Are double-quotes valid characters
	in	certifcates/keys?
In-Reply-To: <CAHP4M8VzBj9-yVS7gkHxb6HPQV1c5-9RWSXJLD2A16ka167Nww@mail.gmail.com>
References: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
 <20160411152623.GY26423@mournblade.imrryr.org>
 <CAHP4M8VzBj9-yVS7gkHxb6HPQV1c5-9RWSXJLD2A16ka167Nww@mail.gmail.com>
Message-ID: <96fa6de1aae54ad4b11081fdf117858e@usma1ex-dag1mb1.msg.corp.akamai.com>

You can merge the two files into one.   As long as they are in PEM format, it will just work.

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



From sanumesh at in.ibm.com  Mon Apr 11 18:12:06 2016
From: sanumesh at in.ibm.com (Sandeep Umesh)
Date: Mon, 11 Apr 2016 23:42:06 +0530
Subject: [openssl-users] Need more information on CVE-2016-2842
In-Reply-To: <OFA3854EB2.426BECF4-ON00257F8E.0025AC3D-65257F8E.00262818@LocalDomain>
References: <OFA3854EB2.426BECF4-ON00257F8E.0025AC3D-65257F8E.00262818@LocalDomain>
Message-ID: <201604111812.u3BICEZf7995786@d28relay03.in.ibm.com>

Hello

Can someone please provide more information on CVE-2016-2842? Is this 
different from CVE-2016-0799 ? Looks like this CVE information is not 
captured in the advisory - 
http://openssl.org/news/secadv/20160301.txt 

Also, does this below patch fixes both CVE-2016-2842 and CVE-2016-0799 - 
https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73 


Thanks

Regards
Sandeep

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

From matt at openssl.org  Mon Apr 11 19:14:10 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 11 Apr 2016 20:14:10 +0100
Subject: [openssl-users] Need more information on CVE-2016-2842
In-Reply-To: <201604111812.u3BICEZf7995786@d28relay03.in.ibm.com>
References: <OFA3854EB2.426BECF4-ON00257F8E.0025AC3D-65257F8E.00262818@LocalDomain>
 <201604111812.u3BICEZf7995786@d28relay03.in.ibm.com>
Message-ID: <570BF782.7060706@openssl.org>



On 11/04/16 19:12, Sandeep Umesh wrote:
> Hello
> 
> Can someone please provide more information on CVE-2016-2842? Is this
> different from CVE-2016-0799 ? Looks like this CVE information is not
> captured in the advisory -
> _http://openssl.org/news/secadv/20160301.txt_
> 
> Also, does this below patch fixes both CVE-2016-2842 and CVE-2016-0799 -
> _https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73_


CVE-2016-2842 is an identifier that was not issued by the OpenSSL
Project and hence does not appear in the security advisory. The OpenSSL
Project assigned CVE-2016-0799 and gave it the description as it appears
in the advisory. Another organisation decided to split that into two
different CVEs and assigned CVE-2016-2842. Whether you think of it as
one CVE or two, the fix is the same, i.e. the commit that you identified
fixes both.

Matt

From jb-openssl at wisemo.com  Tue Apr 12 03:08:50 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 12 Apr 2016 05:08:50 +0200
Subject: [openssl-users] Question about timestamps
In-Reply-To: <CAJ+Q1PWQU+8OdmWHVz7OKuSTffu_LA=p09paKuQ6=rrc30EXXw@mail.gmail.com>
References: <CAJ+Q1PUxgxViQzfGsYhVT=chs7_HZfbk+xxAJj_K=TeNmiciMQ@mail.gmail.com>
 <57074685.7010308@wisemo.com>
 <CAJ+Q1PWrVExh=xNS+hr2YJJDCfzd6LwSatnc=iDp17ySc2m9Yw@mail.gmail.com>
 <57074F0D.9060300@wisemo.com>
 <CAJ+Q1PWQU+8OdmWHVz7OKuSTffu_LA=p09paKuQ6=rrc30EXXw@mail.gmail.com>
Message-ID: <570C66C2.5060902@wisemo.com>

My point was that the -text output would *show* you if
the missing certs were included in the time stamp response
somewhere, and where.

If they are indeed inside the response, then the question
would be why the "openssl ts -verify" command didn't find
them automatically.

If they are not inside the response, then the question
would be why Symantec didn't include them like other
tsa-s do.

On 08/04/2016 22:36, Alex Samad wrote:
> Hi
>
> Yep I have tried the output to text. but does that verify the signature.
>
> So what I think I have now is
>
> my data to be signed
> I make a request
> send the request to the tsa
> the tsa signs it adds signature
> I have response.
>
> Now I need to verify it
>
> openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>
> but it seems to fail, I presume (newbie), because I don't have the
> intermediary certs .
>
> I presume symantec have signed it with a cert thats rooted in one of
> their main CA's and I presume for me to verify I need the
> intermediaries or atleast the sign cert's ca.
>
>
> I have looked on symantecs site to no available
>
> and I am working on guess work here
>
>
>
>
>
> On 8 April 2016 at 16:26, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> Try something like
>>
>> $OPENSSL ts -reply -in ${FL}.tsr -text -noout
>>
>> (Not sure if it accepts the -noout option or not).
>>
>>
>> On 08/04/2016 08:01, Alex Samad wrote:
>>> Okay, how do I dump the intermediaries then ?
>>>
>>>
>>>
>>> On 8 April 2016 at 15:49, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>>>> On 08/04/2016 07:39, Alex Samad wrote:
>>>>> Hi
>>>>>
>>>>> I am trying to use a rfc3161 timestamp service to record timestamps.
>>>>>
>>>>>
>>>>> Basically I have a sha of some files and I would like to sign the file.
>>>>>
>>>>> basically I am using something like this
>>>>>
>>>>> # Generate Query and send
>>>>> $OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H
>>>>> "Content-Type:application/timestamp-query" --data-binary "@-" $TSA >
>>>>> "${FL}.tsr"
>>>>>
>>>>> $OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt"
>>>>>
>>>>>
>>>>> where FL = is file.
>>>>>
>>>>> What I want to be able to do is verify the .tsr file
>>>>>
>>>>> testing that with
>>>>>
>>>>> openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>>>>>
>>>>>
>>>>> where SHA.sha is the original FL
>>>>>
>>>>> but I get
>>>>>
>>>>> Verification: FAILED
>>>>> 140221656393544:error:2107C080:PKCS7
>>>>> routines:PKCS7_get0_signers:signer certificate not
>>>>> found:pk7_smime.c:476:
>>>>>
>>>>> from the text output
>>>>>     cat *.txt
>>>>> Status info:
>>>>> Status: Granted.
>>>>> Status description: unspecified
>>>>> Failure info: unspecified
>>>>>
>>>>> TST info:
>>>>> Version: 1
>>>>> Policy OID: 2.16.840.1.113733.1.7.23.3
>>>>> Hash Algorithm: sha256
>>>>> Message data:
>>>>>        0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
>>>>> .m.[.......WE.i.
>>>>>        0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
>>>>> z.....U%..W7>\..
>>>>> Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9
>>>>> Time stamp: Apr  8 04:58:08 2016 GMT
>>>>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
>>>>> Ordering: no
>>>>> Nonce: 0x8E67A9941BCB2570
>>>>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
>>>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1
>>>>> Extensions:
>>>> I think this certificate is the end entity certificate
>>>> for the Symantec time stamping server that responded to
>>>> your request.
>>>>
>>>> If you dump the full contents of the TSR it should include
>>>> that certificate somewhere, plus a chain leading to a
>>>> public root which is hopefully in your list of trusted
>>>> certificates or at least available via some other secure
>>>> method.
>>>>

Enjoy

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

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

From jb-openssl at wisemo.com  Tue Apr 12 03:19:44 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 12 Apr 2016 05:19:44 +0200
Subject: [openssl-users] Are double-quotes valid characters in
 certifcates/keys?
In-Reply-To: <96fa6de1aae54ad4b11081fdf117858e@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
 <20160411152623.GY26423@mournblade.imrryr.org>
 <CAHP4M8VzBj9-yVS7gkHxb6HPQV1c5-9RWSXJLD2A16ka167Nww@mail.gmail.com>
 <96fa6de1aae54ad4b11081fdf117858e@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <570C6950.4030403@wisemo.com>

On 11/04/2016 18:57, Salz, Rich wrote:
> You can merge the two files into one.   As long as they are in PEM format, it will just work.
>
Except when you want more people (usually everybody) access to
the CRT, but few people (usually one or two trusted server
processes) access to the private KEY.

Then using two different files will make a lot of sense.

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 sanumesh at in.ibm.com  Tue Apr 12 05:35:54 2016
From: sanumesh at in.ibm.com (Sandeep Umesh)
Date: Tue, 12 Apr 2016 11:05:54 +0530
Subject: [openssl-users] Need more information on CVE-2016-2842
In-Reply-To: <570BF782.7060706@openssl.org>
References: <OFA3854EB2.426BECF4-ON00257F8E.0025AC3D-65257F8E.00262818@LocalDomain>
 <201604111812.u3BICEZf7995786@d28relay03.in.ibm.com>
 <570BF782.7060706@openssl.org>
Message-ID: <201604120536.u3C5ZxxP57344076@d28relay01.in.ibm.com>

Thanks for the information Matt.

Regards
Sandeep




From:   Matt Caswell <matt at openssl.org>
To:     openssl-users at openssl.org
Date:   04/12/2016 12:44 AM
Subject:        Re: [openssl-users] Need more information on CVE-2016-2842
Sent by:        "openssl-users" <openssl-users-bounces at openssl.org>





On 11/04/16 19:12, Sandeep Umesh wrote:
> Hello
> 
> Can someone please provide more information on CVE-2016-2842? Is this
> different from CVE-2016-0799 ? Looks like this CVE information is not
> captured in the advisory -
> _http://openssl.org/news/secadv/20160301.txt_
> 
> Also, does this below patch fixes both CVE-2016-2842 and CVE-2016-0799 -
> 
_https://git.openssl.org/?p=openssl.git;a=commit;h=578b956fe741bf8e84055547b1e83c28dd902c73_


CVE-2016-2842 is an identifier that was not issued by the OpenSSL
Project and hence does not appear in the security advisory. The OpenSSL
Project assigned CVE-2016-0799 and gave it the description as it appears
in the advisory. Another organisation decided to split that into two
different CVEs and assigned CVE-2016-2842. Whether you think of it as
one CVE or two, the fix is the same, i.e. the commit that you identified
fixes both.

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




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

From alex at samad.com.au  Tue Apr 12 07:30:07 2016
From: alex at samad.com.au (Alex Samad)
Date: Tue, 12 Apr 2016 17:30:07 +1000
Subject: [openssl-users] Question about timestamps
In-Reply-To: <570C66C2.5060902@wisemo.com>
References: <CAJ+Q1PUxgxViQzfGsYhVT=chs7_HZfbk+xxAJj_K=TeNmiciMQ@mail.gmail.com>
 <57074685.7010308@wisemo.com>
 <CAJ+Q1PWrVExh=xNS+hr2YJJDCfzd6LwSatnc=iDp17ySc2m9Yw@mail.gmail.com>
 <57074F0D.9060300@wisemo.com>
 <CAJ+Q1PWQU+8OdmWHVz7OKuSTffu_LA=p09paKuQ6=rrc30EXXw@mail.gmail.com>
 <570C66C2.5060902@wisemo.com>
Message-ID: <CAJ+Q1PVoHym4zbVbgzThHsPo62RvJxsTXRk_yfiJanqRPPSCcQ@mail.gmail.com>

Oh sorry I am new to the TS side of things and I am putting things
together piece meal.

On 12 April 2016 at 13:08, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> My point was that the -text output would *show* you if
> the missing certs were included in the time stamp response
> somewhere, and where.
>
> If they are indeed inside the response, then the question
> would be why the "openssl ts -verify" command didn't find
> them automatically.
>
> If they are not inside the response, then the question
> would be why Symantec didn't include them like other
> tsa-s do.
>
> On 08/04/2016 22:36, Alex Samad wrote:
>
> Hi
>
> Yep I have tried the output to text. but does that verify the signature.
>
> So what I think I have now is
>
> my data to be signed
> I make a request
> send the request to the tsa
> the tsa signs it adds signature
> I have response.
>
> Now I need to verify it
>
> openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>
> but it seems to fail, I presume (newbie), because I don't have the
> intermediary certs .
>
> I presume symantec have signed it with a cert thats rooted in one of
> their main CA's and I presume for me to verify I need the
> intermediaries or atleast the sign cert's ca.
>
>
> I have looked on symantecs site to no available
>
> and I am working on guess work here
>
>
>
>
>
> On 8 April 2016 at 16:26, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>
> Try something like
>
> $OPENSSL ts -reply -in ${FL}.tsr -text -noout
>
> (Not sure if it accepts the -noout option or not).
>
>
> On 08/04/2016 08:01, Alex Samad wrote:
>
> Okay, how do I dump the intermediaries then ?
>
>
>
> On 8 April 2016 at 15:49, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>
> On 08/04/2016 07:39, Alex Samad wrote:
>
> Hi
>
> I am trying to use a rfc3161 timestamp service to record timestamps.
>
>
> Basically I have a sha of some files and I would like to sign the file.
>
> basically I am using something like this
>
> # Generate Query and send
> $OPENSSL ts -query -data "$FL" -sha256 | $CURL -s -H
> "Content-Type:application/timestamp-query" --data-binary "@-" $TSA >
> "${FL}.tsr"
>
> $OPENSSL ts -reply -in "${FL}.tsr" -text > "${FL}.ts.txt"
>
>
> where FL = is file.
>
> What I want to be able to do is verify the .tsr file
>
> testing that with
>
> openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>
>
> where SHA.sha is the original FL
>
> but I get
>
> Verification: FAILED
> 140221656393544:error:2107C080:PKCS7
> routines:PKCS7_get0_signers:signer certificate not
> found:pk7_smime.c:476:
>
> from the text output
>    cat *.txt
> Status info:
> Status: Granted.
> Status description: unspecified
> Failure info: unspecified
>
> TST info:
> Version: 1
> Policy OID: 2.16.840.1.113733.1.7.23.3
> Hash Algorithm: sha256
> Message data:
>       0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
> .m.[.......WE.i.
>       0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
> z.....U%..W7>\..
> Serial number: 0xBEAF663E1CD2F0D029C1A641AD2F9137A5F097C9
> Time stamp: Apr  8 04:58:08 2016 GMT
> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
> Ordering: no
> Nonce: 0x8E67A9941BCB2570
> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
> Network/CN=Symantec SHA256 TimeStamping Signer - G1
> Extensions:
>
> I think this certificate is the end entity certificate
> for the Symantec time stamping server that responded to
> your request.
>
> If you dump the full contents of the TSR it should include
> that certificate somewhere, plus a chain leading to a
> public root which is hopefully in your list of trusted
> certificates or at least available via some other secure
> method.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

From chris at twoten.is  Tue Apr 12 08:45:29 2016
From: chris at twoten.is (Chris Puttick)
Date: Tue, 12 Apr 2016 09:45:29 +0100 (BST)
Subject: [openssl-users] SSL errors connecting to some websites
In-Reply-To: <1189588500.27298.1460448744151.JavaMail.zimbra@twoten.is>
Message-ID: <1484571251.28156.1460450729096.JavaMail.zimbra@twoten.is>

Hi

Our schools filtering product utilises OpenSSL with Squid; we're seeing issues connecting to some sites which seem OpenSSL related. Two sites with known issues are:

https://www.spellanywhere.co.uk/

https://www.mymaths.co.uk/

Connecting to either of these Squid returns the error:

(71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
Handshake with SSL server failed: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error

Running openssl tests direct from a schools box (OpenSSL 1.0.1) gets:

# openssl s_client -connect www.spellanywhere.co.uk:443
CONNECTED(00000003)
3073661128:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:734:

Attempting to disable protocols for testing gets:

openssl s_client -no_tls1 -no_tls1_1 -no_tls1_2 -connect www.spellanywhere.co.uk:443
CONNECTED(00000003)
3074005192:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:734:

and eventually

openssl s_client -no_tls1 -no_tls1_1 -no_tls1_2 -no_ssl3 -no_ssl2 -connect www.spellanywhere.co.uk:443
CONNECTED(00000003)
3073534152:error:140740BF:SSL routines:SSL23_CLIENT_HELLO:no protocols available:s23_clnt.c:385:

While forcing dtls with 

openssl s_client -dtls1 -connect www.spellanywhere.co.uk:443

seems to establish a tunnel as expected. 

Using curl or wget on the same boxes to those sites works as expected. Tests on a local box with OpenSSL 1.0.2e return similar results, although the disabled protocols test returns a different error:

openssl s_client -no_tls1 -no_tls1_1 -no_tls1_2 -no_ssl3 -no_ssl2 -connect www.spellanywhere.co.uk:443
CONNECTED(00000003)
139735616550552:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:735:

Is this some sort of SSL handshake fallback error? Is there anything we can do in terms of configuration? Are we barking up the wrong tree?

All input/questions welcome.

Thanks

Chris


---
Chris Puttick
CEO & Chief Asst to the duck
TwoTen
http://twoten.is
Making the Internet better. For kids.
+44 7908 997 146
@putt1ck
Two Ten Web Limited, Regd Company no. 7774762 Regd office Unit 6, Southill, Cornbury Park, Charlbury, Oxfordshire OX7 3EW United Kingdom


From matt at openssl.org  Tue Apr 12 09:13:36 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 12 Apr 2016 10:13:36 +0100
Subject: [openssl-users] SSL errors connecting to some websites
In-Reply-To: <1484571251.28156.1460450729096.JavaMail.zimbra@twoten.is>
References: <1484571251.28156.1460450729096.JavaMail.zimbra@twoten.is>
Message-ID: <570CBC40.2050803@openssl.org>



On 12/04/16 09:45, Chris Puttick wrote:
> Hi
> 
> Our schools filtering product utilises OpenSSL with Squid; we're seeing issues connecting to some sites which seem OpenSSL related. Two sites with known issues are:
> 
> https://www.spellanywhere.co.uk/
> 
> https://www.mymaths.co.uk/
> 
> Connecting to either of these Squid returns the error:
> 
> (71) Protocol error (TLS code: SQUID_ERR_SSL_HANDSHAKE)
> Handshake with SSL server failed: error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error

It seems these servers require connections to supply SNI information.
Supplying the servername option to s_client adds it:

# openssl s_client -connect www.spellanywhere.co.uk:443 -servername
www.spellanywhere.co.uk

I am able to create successful connections to both of the sites you list
above with OpenSSL 1.0.1 using the above option.

Unfortunately I am unfamiliar with Squid configuration, so I can't
advise as to whether this is the problem with your squid setup, and if
it is - how you fix it.

Matt



> 
> Running openssl tests direct from a schools box (OpenSSL 1.0.1) gets:
> 
> # openssl s_client -connect www.spellanywhere.co.uk:443
> CONNECTED(00000003)
> 3073661128:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:734:
> 
> Attempting to disable protocols for testing gets:
> 
> openssl s_client -no_tls1 -no_tls1_1 -no_tls1_2 -connect www.spellanywhere.co.uk:443
> CONNECTED(00000003)
> 3074005192:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:734:
> 
> and eventually
> 
> openssl s_client -no_tls1 -no_tls1_1 -no_tls1_2 -no_ssl3 -no_ssl2 -connect www.spellanywhere.co.uk:443
> CONNECTED(00000003)
> 3073534152:error:140740BF:SSL routines:SSL23_CLIENT_HELLO:no protocols available:s23_clnt.c:385:
> 
> While forcing dtls with 
> 
> openssl s_client -dtls1 -connect www.spellanywhere.co.uk:443
> 
> seems to establish a tunnel as expected. 
> 
> Using curl or wget on the same boxes to those sites works as expected. Tests on a local box with OpenSSL 1.0.2e return similar results, although the disabled protocols test returns a different error:
> 
> openssl s_client -no_tls1 -no_tls1_1 -no_tls1_2 -no_ssl3 -no_ssl2 -connect www.spellanywhere.co.uk:443
> CONNECTED(00000003)
> 139735616550552:error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol:s23_clnt.c:735:
> 
> Is this some sort of SSL handshake fallback error? Is there anything we can do in terms of configuration? Are we barking up the wrong tree?
> 
> All input/questions welcome.
> 
> Thanks
> 
> Chris
> 
> 
> ---
> Chris Puttick
> CEO & Chief Asst to the duck
> TwoTen
> http://twoten.is
> Making the Internet better. For kids.
> +44 7908 997 146
> @putt1ck
> Two Ten Web Limited, Regd Company no. 7774762 Regd office Unit 6, Southill, Cornbury Park, Charlbury, Oxfordshire OX7 3EW United Kingdom
> 

From rsalz at akamai.com  Tue Apr 12 13:38:05 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 12 Apr 2016 13:38:05 +0000
Subject: [openssl-users] Are double-quotes valid characters in
 certifcates/keys?
In-Reply-To: <570C6950.4030403@wisemo.com>
References: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
 <20160411152623.GY26423@mournblade.imrryr.org>
 <CAHP4M8VzBj9-yVS7gkHxb6HPQV1c5-9RWSXJLD2A16ka167Nww@mail.gmail.com>
 <96fa6de1aae54ad4b11081fdf117858e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <570C6950.4030403@wisemo.com>
Message-ID: <1cb69451e94e40448428225422f5d24a@usma1ex-dag1mb1.msg.corp.akamai.com>


> Except when you want more people (usually everybody) access to the CRT,
> but few people (usually one or two trusted server
> processes) access to the private KEY.
> 
> Then using two different files will make a lot of sense.

Oh yes, absolutely!  Don't give out the private kkey :)

From vikas.tm at gmail.com  Tue Apr 12 14:12:10 2016
From: vikas.tm at gmail.com (Vikas TM)
Date: Tue, 12 Apr 2016 19:42:10 +0530
Subject: [openssl-users] Received signal SIGSEGV in CRYPTO_add_lock()
In-Reply-To: <CA+5R-aj2R2Uq++xc-chvvfyq8ZJmb6-bL=Yj_yG0KQ+Lf8Wb1g@mail.gmail.com>
References: <CA+5R-ajnBurf2gQ2E-22QESfNpNFNXjejirJY9NoZot-j-gd8Q@mail.gmail.com>
 <CA+5R-aj2R2Uq++xc-chvvfyq8ZJmb6-bL=Yj_yG0KQ+Lf8Wb1g@mail.gmail.com>
Message-ID: <CA+5R-agWjfJShSS-tothHdJ-PeYyNVOpYaPsUK-nZ-3jaxqFGQ@mail.gmail.com>

Hi,

I am not very clear with solution provided in the following link,
http://lists.globus.org/pipermail/gt-user/2007-December/005317.html

Appreciated if you help me in resolving this issue.

Thanks & Regards,
Vikas
On 11 Apr 2016 8:20 pm, "Vikas TM" <vikas.tm at gmail.com> wrote:

> Hi,
>
> It looks like there is issue in handling crypto locks. I encountered
> segmentation fault in CRYPTO_add_lock() function referencing NULL pointer.
> Please find GDB output below,
>
> (gdb) run ftp://x.x.x.x:sample.txt
>
> Starting program: /App/vikftp ftp://x.x.x.x:sample.txt
>
> Missing separate debuginfo for /lib/ld-linux.so.2
>
> Missing separate debuginfo for /lib/libdl.so.2
>
> Missing separate debuginfo for /lib/libpam.so.0
>
> Missing separate debuginfo for /lib/libm.so.6
>
> Missing separate debuginfo for /lib/libc.so.6
>
> Missing separate debuginfo for /lib/libaudit.so.0
>
> process 22287 is executing new program: /App/vikftp
>
> Missing separate debuginfo for /lib/ld-linux.so.2
>
> Missing separate debuginfo for /lib/libdl.so.2
>
> Missing separate debuginfo for /lib/libpam.so.0
>
> Missing separate debuginfo for /lib/libm.so.6
>
> Missing separate debuginfo for /lib/libc.so.6
>
> Missing separate debuginfo for /lib/libaudit.so.0
>
>
>
> Program received signal SIGSEGV, Segmentation fault.
>
> 0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3,
> file=0x85d0030 "/102d/s/tasn_utl.c", line=118)
>
>     at /102d/s/cryptlib.c:624
>
> 624             ret = *pointer + amount;
>
> (gdb) bt
>
> #0  0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3,
> file=0x85d0030 "/102d/s/tasn_utl.c", line=118)
>
>     at /102d/s/cryptlib.c:624
>
> #1  0x08249d2a in asn1_do_lock (pval=0xff8eee90, op=-1, it=0x862cb1c) at
> /102d/s/tasn_utl.c:118
>
> #2  0x08246ed5 in asn1_item_combine_free (pval=0xff8eee90, it=0x862cb1c,
> combine=0) at /102d/s/tasn_fre.c:146
>
> #3  0x08246c40 in ASN1_item_free (val=0x1001, it=0x862cb1c) at
> /102d/s/tasn_fre.c:72
>
> #4  0x0825eeea in X509_free (a=0x1001) at /102d/s/x_x509.c:143
>
> #5  0x082ee677 in ssl_cert_clear_certs (c=0x872e4e0) at
> /102d/s/ssl_cert.c:431
>
> #6  0x082ee7ed in ssl_cert_free (c=0x872e4e0) at /102d/s/ssl_cert.c:489
>
> #7  0x0822f926 in SSL_free (s=0x872e340) at /102d/s/ssl_lib.c:627
>
> #8  0x0816566c in closeConnection (pcx=0x86d8310, rsn=0x0, graceful=1
> '\001') at /App/vikftp.c:10098
>
> Please let me know if you have any solution.
>
> Thanks & Regards,
> Vikas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160412/88885922/attachment-0001.html>

From Michael.Wojcik at microfocus.com  Tue Apr 12 15:24:20 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 12 Apr 2016 15:24:20 +0000
Subject: [openssl-users] Received signal SIGSEGV in CRYPTO_add_lock()
In-Reply-To: <CA+5R-agWjfJShSS-tothHdJ-PeYyNVOpYaPsUK-nZ-3jaxqFGQ@mail.gmail.com>
References: <CA+5R-ajnBurf2gQ2E-22QESfNpNFNXjejirJY9NoZot-j-gd8Q@mail.gmail.com>
 <CA+5R-aj2R2Uq++xc-chvvfyq8ZJmb6-bL=Yj_yG0KQ+Lf8Wb1g@mail.gmail.com>
 <CA+5R-agWjfJShSS-tothHdJ-PeYyNVOpYaPsUK-nZ-3jaxqFGQ@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DC9D204@Rock-Exchange1.microfocus.com>

Why do you think that message is relevant to your problem?

You haven't told us anything useful about the problem you're experiencing, like what version of OpenSSL you're using. If you want good answers, ask good questions.

What we can see below:

- Obviously the parameter being passed to CRYPTO_add_lock is bogus. The problem isn't with locks; it's with attempting to operate on garbage data. The most likely causes are heap or stack corruption, or use-after-free.

- The value being passed to X509_free isn't a valid pointer either.

My guess is that your application frees something when it shouldn't. Maybe you're calling SSL_free twice. It appears that the CERT* passed to ssl_cert_clear_certs contains bogus data, and a use-after-free is a likely cause.

Since you're running on Linux (which I only know because of the gdb module list - again, you haven't provided even the most basic information with your question), I'd suggest running the application under Valgrind.

Michael Wojcik
Technology Specialist, Micro Focus


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Vikas TM
Sent: Tuesday, April 12, 2016 10:12
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Received signal SIGSEGV in CRYPTO_add_lock()


Hi,

I am not very clear with solution provided in the following link,
http://lists.globus.org/pipermail/gt-user/2007-December/005317.html

Appreciated if you help me in resolving this issue.

Thanks & Regards,
Vikas
On 11 Apr 2016 8:20 pm, "Vikas TM" <vikas.tm at gmail.com<mailto:vikas.tm at gmail.com>> wrote:

Hi,

It looks like there is issue in handling crypto locks. I encountered segmentation fault in CRYPTO_add_lock() function referencing NULL pointer. Please find GDB output below,

(gdb) run ftp://x.x.x.x:sample.txt

Starting program: /App/vikftp ftp://x.x.x.x:sample.txt

Missing separate debuginfo for /lib/ld-linux.so.2

Missing separate debuginfo for /lib/libdl.so.2

Missing separate debuginfo for /lib/libpam.so.0

Missing separate debuginfo for /lib/libm.so.6

Missing separate debuginfo for /lib/libc.so.6

Missing separate debuginfo for /lib/libaudit.so.0

process 22287 is executing new program: /App/vikftp

Missing separate debuginfo for /lib/ld-linux.so.2

Missing separate debuginfo for /lib/libdl.so.2

Missing separate debuginfo for /lib/libpam.so.0

Missing separate debuginfo for /lib/libm.so.6

Missing separate debuginfo for /lib/libc.so.6

Missing separate debuginfo for /lib/libaudit.so.0



Program received signal SIGSEGV, Segmentation fault.

0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3, file=0x85d0030 "/102d/s/tasn_utl.c", line=118)

    at /102d/s/cryptlib.c:624

624             ret = *pointer + amount;

(gdb) bt

#0  0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3, file=0x85d0030 "/102d/s/tasn_utl.c", line=118)

    at /102d/s/cryptlib.c:624

#1  0x08249d2a in asn1_do_lock (pval=0xff8eee90, op=-1, it=0x862cb1c) at /102d/s/tasn_utl.c:118

#2  0x08246ed5 in asn1_item_combine_free (pval=0xff8eee90, it=0x862cb1c, combine=0) at /102d/s/tasn_fre.c:146

#3  0x08246c40 in ASN1_item_free (val=0x1001, it=0x862cb1c) at /102d/s/tasn_fre.c:72

#4  0x0825eeea in X509_free (a=0x1001) at /102d/s/x_x509.c:143

#5  0x082ee677 in ssl_cert_clear_certs (c=0x872e4e0) at /102d/s/ssl_cert.c:431

#6  0x082ee7ed in ssl_cert_free (c=0x872e4e0) at /102d/s/ssl_cert.c:489

#7  0x0822f926 in SSL_free (s=0x872e340) at /102d/s/ssl_lib.c:627

#8  0x0816566c in closeConnection (pcx=0x86d8310, rsn=0x0, graceful=1 '\001') at /App/vikftp.c:10098

Please let me know if you have any solution.

Thanks & Regards,
Vikas


Click here<https://www.mailcontrol.com/sr/+Cj70KMYCabGX2PQPOmvUgItITKVa7z0gs7YiNqVkgRsY23LiAnRcH9UaLfxQWXam!Wtb8ydoXseRLY+cWrx9g==> to report this email as spam.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160412/8069fc25/attachment.html>

From ajaygargnsit at gmail.com  Tue Apr 12 16:34:07 2016
From: ajaygargnsit at gmail.com (Ajay Garg)
Date: Tue, 12 Apr 2016 22:04:07 +0530
Subject: [openssl-users] Are double-quotes valid characters in
	certifcates/keys?
In-Reply-To: <1cb69451e94e40448428225422f5d24a@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <CAHP4M8VLY26JKUfGtNan95mPyWJnUUJgax=AV=68SvUt4naLmg@mail.gmail.com>
 <20160411152623.GY26423@mournblade.imrryr.org>
 <CAHP4M8VzBj9-yVS7gkHxb6HPQV1c5-9RWSXJLD2A16ka167Nww@mail.gmail.com>
 <96fa6de1aae54ad4b11081fdf117858e@usma1ex-dag1mb1.msg.corp.akamai.com>
 <570C6950.4030403@wisemo.com>
 <1cb69451e94e40448428225422f5d24a@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <CAHP4M8Upr3YNs1bkhBpYxmZvS5O=C=peSR+fXmUuH74uoz6jMg@mail.gmail.com>

Thanks everyone for the quick and generous help !!
I am really thankful to everyone's time.


Thanks and Regards,
Ajay

On Tue, Apr 12, 2016 at 7:08 PM, Salz, Rich <rsalz at akamai.com> wrote:
>
>> Except when you want more people (usually everybody) access to the CRT,
>> but few people (usually one or two trusted server
>> processes) access to the private KEY.
>>
>> Then using two different files will make a lot of sense.
>
> Oh yes, absolutely!  Don't give out the private kkey :)
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users



-- 
Regards,
Ajay

From steve at openssl.org  Tue Apr 12 19:18:36 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Tue, 12 Apr 2016 19:18:36 +0000
Subject: [openssl-users] CMS with Symmetric key
In-Reply-To: <CAK4g_tc+1KbwTxcDAEAS63JddeUWGFjFGq7a3Jzkq0SS++zuAA@mail.gmail.com>
References: <CAK4g_tdY61+0RrJ+zpddjw8qV9-6iE5VhZyeemD9F8GsHAdn0A@mail.gmail.com>
 <20160405113905.GA22864@openssl.org>
 <CAK4g_tc+1KbwTxcDAEAS63JddeUWGFjFGq7a3Jzkq0SS++zuAA@mail.gmail.com>
Message-ID: <20160412191836.GA4765@openssl.org>

On Mon, Apr 11, 2016, Abe Racioppo wrote:

> Thank you for the responses.
> 
> I have implemented encryption that adds a secret key, and secret key id
> using:
> CMS_add0_recipient_key,
> CMS_EncryptData_encrypt,
> SMIME_write_CMS
> The output file looks correct, but I need to decrypt it back to be sure.
> 

Ah CMS_EncryptedData_encrypt() just creates the encrypted data type. If you
want to use enveloped data you use CMS_encrypt() first then
CMS_add0_recipient_key() and finally SMIME_write_CMS().

> I would like to be able to get the secret key id from the envelope data to
> then search a database for the key, and then CMS_decrypt.  I have yet to
> determine the most straightforward way of getting the key ids from the
> envelope/wrapped content of cms.
> 
> Is there a combination if I have SMIME_read the cms from a file like:
>   keyId =  cms->envelopedData->keyId?
> 
> Or do I need to handle a stack_of recipient infos in order to get the key
> id from kekri0_get_id?
> 

Yes. You need to use CMS_get0_RecipientInfos() as there can be multiple
recipients of different types.

For each recipient info you check the type with:

	CMS_RecipientInfo_type(ri) == CMS_RECIPINFO_KEY

For each match retrieve the key ID using CMS_RecipientInfo_kekri_get0_id().

If the id doesn't match a value in you database continue to the next recipient
info. If no matches return an error.

If you do get a match then call CMS_RecipientInfo_set0_key().

Finally call CMS_decrypt(): setting the key and certificate parameters to
NULL.

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

From mcepl at cepl.eu  Tue Apr 12 20:51:50 2016
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl)
Date: Tue, 12 Apr 2016 22:51:50 +0200
Subject: [openssl-users] lh_CONF_VALUE_new parameters?
Message-ID: <slrnngqnv6.74l.mcepl@mitmanek.ceplovi.cz>

Hi,

I am trying to make M2Crypto build on Windows again
(https://gitlab.com/m2crypto/m2crypto/merge_requests/26). I have
replaced by POSIX's poll by WSAPoll( I know about
https://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/ but we
don't play with the error values, which is a mistake, I know, so
we shouldn't be affected).

The second problem is that VC++ compiler crashes on problems
with CONF_VALUE. Originally M2Crypto had this
(https://gitlab.com/m2crypto/m2crypto/blob/master/SWIG/_x509.i#L514):

    #if OPENSSL_VERSION_NUMBER >= 0x10000000L
    LHASH_OF(CONF_VALUE)
    #else
    LHASH
    #endif
    *x509v3_lhash() {
        return lh_new(NULL, NULL); /* Should probably be lh_CONF_VALUE_new but won't compile. */
    }

Apparently, using lh_new(NULL, NULL) is not good enough for VC++
and it crashes on it
(https://ci.appveyor.com/project/mcepl/m2crypto-nngqn/build/job/e7q2ogndlje2x2h9)

After a deep dive into lhash(3) and some examples on github,
I have created this:

    /*
    typedef struct
            {
            char *section;
            char *name;
            char *value;
            } CONF_VALUE;

     */

    unsigned long CONF_VALUE_hash(const CONF_VALUE *v) {
        char *v_key, *hash_hex;

        v_key = strncat(v1->section, v1->name, 1024);
        v_key = strncat(v1_key, v1->value, 2048);

        return *(unsigned long *) SHA256(v_key, strlen(v_key), hash_hex);
    }
    static IMPLEMENT_LHASH_HASH_FN(CONF_VALUE_hash, const CONF_VALUE*);

    int CONF_VALUE_cmp(const CONF_VALUE *v1, const CONF_VALUE *v2) {
        char *v1_key, *v2_key;

        v1_key = strncat(v1->section, v1->name, 1024);
        v1_key = strncat(v1_key, v1->value, 2048);

        v2_key = strncat(v2->section, v2->name, 1024);
        v2_key = strncat(v2_key, v2->value, 2048);

        return strncmp(v1_key, v2_key, 2048);
    }
    static IMPLEMENT_LHASH_COMP_FN(CONF_VALUE_cmp, const CONF_VALUE*);

    #if OPENSSL_VERSION_NUMBER >= 0x10000000L
    LHASH_OF(CONF_VALUE)
    #else
    LHASH
    #endif
    *x509v3_lhash() {
        return lh_CONF_VALUE_new(CONF_VALUE_hash, CONF_VALUE_cmp);
    }

but gcc still fails to compile with error:

    SWIG/_x509.i:554: Error: Macro 'lh_CONF_VALUE_new' expects 
    no arguments

lh_CONF_VALUE_new with arguments is however exactly what I found 
on the Internet (and in crypt/conf/conf_api.c, which seems to be 
the only use of lh_CONF_VALUE_new in OpenSSL tree).

Using openssl-1.0.1e-56.el7.x86_64 on RHEL-7.

Could anybody enlighten me, how to make lh_CONF_VALUE_new 
working, please?

Thank you,

Mat?j

--
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC

You either die a hero or you live long enough to see yourself become the villain.
  -- Harvey Dent in The Dark Knight


From noloader at gmail.com  Wed Apr 13 01:50:11 2016
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 12 Apr 2016 21:50:11 -0400
Subject: [openssl-users] Perform self tests after installation?
Message-ID: <CAH8yC8=RkjpJdxGop0JjccJF4xEeJoCW-rXVbTOFvwEMkxTkjQ@mail.gmail.com>

Is it possible to perform the self tests after an installation? If so,
how do we do it (I'm interested in both 1.0.x and 1.1.x)?

'make test' works from the build directory, and I don't recall seeing
an 'openssl test' command that could work after installation.

I'm guessing not, but I want to ensure I'm not missing something.

From wim.delvaux at adaptiveplanet.com  Wed Apr 13 11:04:10 2016
From: wim.delvaux at adaptiveplanet.com (wim delvaux)
Date: Wed, 13 Apr 2016 13:04:10 +0200
Subject: [openssl-users] issue with using openssl_seal/openssl_open calls
Message-ID: <CACFydqtc8dH9b9OTe2DJsAMYpJ_vUzKNEem=EDD8Qu+Y5pRLww@mail.gmail.com>

Here it the code

http://pasted.co/5ab2f9cf

I encrypted a simple text file of 23 bytes which yields a binary file of 32
bytes (does that sound OK ?)

The problem is that i get the following error while decrypting things

140350823843504:error:0406506C:rsa routines:RSA_EAY_PRIVATE_DECRYPT:data
greater than mod len:rsa_eay.c:518:

happens on the openinit

Keys seem ok

$ cat priv
-----BEGIN ENCRYPTED PRIVATE KEY-----
MIIFDjBABgkqhkiG9w0BBQ0wMzAbBgkqhkiG9w0BBQwwDgQIZEIWKYNmNVYCAggA
--snip--
3pybWIfq8MjxXMAsCPoW4OIA2MSSD+q5iqhAVJXo9GyiQkwOzRKkoYbUgOTWbncV
j2I=
-----END ENCRYPTED PRIVATE KEY-----
u19809 at gcv ~/projects/AP/Touch-n-Go/NFC Reader Service/RaspberryPI
$ cat pub
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0Ysq2lWawes7Be6FReHe
--snip--
m+o5CS9QYXDIy8U1HduHMeaFz2QNYAUH6mHRFuGdPgiQ4L6/DXwaQ78lknHlrP4M
WQIDAQAB
-----END PUBLIC KEY-----

Help !

thx

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

From mgagnon at opentext.com  Wed Apr 13 15:03:15 2016
From: mgagnon at opentext.com (Mike Gagnon)
Date: Wed, 13 Apr 2016 15:03:15 +0000
Subject: [openssl-users] TLS 1.2 Client hello missing SessionTicket
Message-ID: <C0820C3135563D48BD856A0ADC7A87E85835594D@otwlxg22.opentext.net>

Hi Folks,

I'm working on an issue where something seems to be going wrong with our internal state after a while, and one of our sessions will have suddenly lost its SessionTicket during the Client Hello.

To debug the issue, I'm wondering if someone can point me to the right internal variable in openssl that I might want to put a data breakpoint on so I can see the call stack that led to the problem.  A wireshark trace shows that the SessionTicket length is zero when the problem occurs.

Thanks for any suggestions,

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

From kurt.w.heberlein at hpe.com  Wed Apr 13 21:54:35 2016
From: kurt.w.heberlein at hpe.com (Heberlein, Kurt William)
Date: Wed, 13 Apr 2016 21:54:35 +0000
Subject: [openssl-users] openssl-1.0.1r fips anomaly
Message-ID: <DF4PR84MB0297D27BB873707EE574693CD1960@DF4PR84MB0297.NAMPRD84.PROD.OUTLOOK.COM>

Hi,
  I'm trying to dig through a problem where building the FIPS capable version of OpenSSL-1.0.1r is not generating the correct code.

I have done the following:
Created the fips canister according to the instructions in the User Guide, and installed it.
Then in the openssl source, I use ./config fips no-ec2m shared --with-fipsdir=/usr/local/ssl/fips-2.0 --with-fipslibdir=/usr/local/ssl/fips-2.0/lib/
    I always get a libcrypto.a that fails FIPS_mode_set as not supported.
If I leave the shared parameter off, I get the desired FIPS support, but in non-PIC code.  Since my need is to produce a .so of my own with the libcrypto.a statically linked into it that doesn't work.

Digging into this a little, I see the FIPS_mode_set() definition in crypto/o_fips.c is gated by finding a definition of OPENSSL_FIPS.    I do see that in the generated opensslconf.h.
I can't quite see why the shared versus non-shared would create a problem.     I didn't have this trouble with the earlier version 1.0.1j of openssl, or at least I didn't see it.. was PIC code still generated at that release for non-shared?

As an aside, I did notice an anomaly in crypto/cryptlib.h near line 72:
#include <openssl/crypto.h>
#include <openssl/buffer.h>
#include <openssl/bio.h>
#include <openssl/err.h>
#include <openssl/opensslconf.h>

However, in crypto.h decisions are made based on the definition of OPENSSL_FIPS, which is not defined until opensslconf.h is read at line 76, so the behavior of crypto.h seems to be not as intended.
Thoughts, flames?
Thanks, -Kurt



Kurt Heberlein
Master Technologist
3PAR R&D
   HPE Storage
   www.hpe.com/storage<http://www.hpe.com/storage>

   +1 512 319 4462 (office)
   +1 510 685 1141 (mobile)

    kurt dot w dot heberlein at-sign hpe dot com

   [cid:image001.png at 01D195A5.27BD87D0]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160413/e0221611/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9864 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160413/e0221611/attachment-0001.png>

From rsalz at akamai.com  Thu Apr 14 16:57:56 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 14 Apr 2016 16:57:56 +0000
Subject: [openssl-users] API question; v3_asid/v3_addr
Message-ID: <f583e20aef574e55a5761812440daec9@usma1ex-dag1mb1.msg.corp.akamai.com>

Do you use the v3_asid_xxx or v3_addr_xxx API's?  Please let me know.

(They are not going away, we just need to know if they're internal-only or if people are using them.)

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

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

From c at gryning.com  Fri Apr 15 14:29:16 2016
From: c at gryning.com (c^)
Date: Fri, 15 Apr 2016 15:29:16 +0100
Subject: [openssl-users] 1.1.0-pre4: openssl speed chacha
Message-ID: <CAK-1ke=KRi2DCji7TwQeJVf6mrkrheu6FQerLpwWW-T3m=6a+A@mail.gmail.com>

Hi there,

I don't seem to be able to benchmark chacha, nor does it appear in the list
when I test all.
Is this expected?

I can see it in 'openssl ciphers -V "ALL"' and also negotiate from a client.

Thanks
CraigT
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160415/70647e35/attachment.html>

From dni.grosu at gmail.com  Sun Apr 17 08:26:29 2016
From: dni.grosu at gmail.com (danigrosu)
Date: Sun, 17 Apr 2016 01:26:29 -0700 (MST)
Subject: [openssl-users] Unable to load/add a dynamic engine
Message-ID: <1460881589415-65563.post@n7.nabble.com>

Hi. I am using the OpenSSL 1.0.1f and I built a RSA engine using CUDA code.
I want to load this engine dynamically, i.e. when I type /# openssl engine/,
I want
to see my engine id on the list, but all I see is this:
/(rsax) RSAX engine support
(dynamic) Dynamic engine loading support/ where the rsax is builtin

I have modified the openssl.cnf file by adding the following lines:
/openssl_conf = openssl_def
[openssl_def]
engines = engine_section

[engine_section]
foo = gpu_section

[gpu_section]
dynamic_path =
/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/librsax_gpu.so
engine_id = rsax_gpu
default_algorithms = RSA
init = 1		/

I tried this: /# openssl speed rsa512 -engine rsax_gpu/ and everything went
well.

Please tell me why I can't load dynamically the engine?



--
View this message in context: http://openssl.6102.n7.nabble.com/Unable-to-load-add-a-dynamic-engine-tp65563.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From james.arivazhagan at gmail.com  Mon Apr 18 05:32:40 2016
From: james.arivazhagan at gmail.com (James)
Date: Mon, 18 Apr 2016 11:02:40 +0530
Subject: [openssl-users] Regarding TLS 1.3
Message-ID: <CAJLNLpfAhWa7QuxwUBug4WTnw0U1izuCODyXHZ36gB22_M+c7Q@mail.gmail.com>

Hi there,
In the below link I could see TLS 1.3 support will be added in future
releases
 https://www.openssl.org/policies/roadmap.html

I think the support is not yet added. From when it will be added

regards,
James Arivazhagan Ponnusamy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/4278b096/attachment.html>

From matt at openssl.org  Mon Apr 18 07:56:13 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 18 Apr 2016 08:56:13 +0100
Subject: [openssl-users] Regarding TLS 1.3
In-Reply-To: <CAJLNLpfAhWa7QuxwUBug4WTnw0U1izuCODyXHZ36gB22_M+c7Q@mail.gmail.com>
References: <CAJLNLpfAhWa7QuxwUBug4WTnw0U1izuCODyXHZ36gB22_M+c7Q@mail.gmail.com>
Message-ID: <5714931D.6080302@openssl.org>



On 18/04/16 06:32, James wrote:
> Hi there,
> In the below link I could see TLS 1.3 support will be added in future
> releases
>  https://www.openssl.org/policies/roadmap.html
> 
> I think the support is not yet added. From when it will be added 

TLS1.3 will not be in the next release which is currently in beta (i.e.
1.1.0). I hope that it will be in the release after that but we have not
yet got a timescale for that.

Matt


From james.sqawz at gmail.com  Mon Apr 18 12:46:50 2016
From: james.sqawz at gmail.com (james sqawz)
Date: Mon, 18 Apr 2016 18:16:50 +0530
Subject: [openssl-users] ssl connect failed
Message-ID: <CANz_a=rU5rhnEQGm0uG4g1GJNn7-XnZiUWSG7xDk6WdCBowtzA@mail.gmail.com>

Hi all,

Thanks for the providing the forum for discussion on TLS/OPENSSL related
issue.

I am very new to openssl.

Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
For that purpose I send connect request to the server,but connection is
getting failed.

Following fields are abscent in my ssl packet.

Extension: server name present
Extension:application layer protocol negotiation

Apart from that I did not set path of Server Certificate.

Shall these impact my connect request.
Can somebody help.

Thanks
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/b8bef704/attachment.html>

From dni.grosu at gmail.com  Mon Apr 18 11:50:49 2016
From: dni.grosu at gmail.com (danigrosu)
Date: Mon, 18 Apr 2016 04:50:49 -0700 (MST)
Subject: [openssl-users] ssl connect failed
In-Reply-To: <CANz_a=rU5rhnEQGm0uG4g1GJNn7-XnZiUWSG7xDk6WdCBowtzA@mail.gmail.com>
References: <CANz_a=rU5rhnEQGm0uG4g1GJNn7-XnZiUWSG7xDk6WdCBowtzA@mail.gmail.com>
Message-ID: <CAGYz=CygqnxFgQ9t+7BSJff038VTCphDpJRYzqn-0gcz9QGSkw@mail.gmail.com>

Hi.

Are you using the Apache server?

On 18 April 2016 at 14:46, james sqawz [via OpenSSL] <
ml-node+s6102n65566h85 at n7.nabble.com> wrote:

> Hi all,
>
> Thanks for the providing the forum for discussion on TLS/OPENSSL related
> issue.
>
> I am very new to openssl.
>
> Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
> For that purpose I send connect request to the server,but connection is
> getting failed.
>
> Following fields are abscent in my ssl packet.
>
> Extension: server name present
> Extension:application layer protocol negotiation
>
> Apart from that I did not set path of Server Certificate.
>
> Shall these impact my connect request.
> Can somebody help.
>
> Thanks
> James
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
> ------------------------------
> If you reply to this email, your message will be added to the discussion
> below:
> http://openssl.6102.n7.nabble.com/ssl-connect-failed-tp65566.html
> To unsubscribe from OpenSSL - User, click here
> <http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3&code=ZG5pLmdyb3N1QGdtYWlsLmNvbXwzfC0xOTcxNTAwNzE2>
> .
> NAML
> <http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>
>




--
View this message in context: http://openssl.6102.n7.nabble.com/ssl-connect-failed-tp65566p65567.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/ffeb33cb/attachment-0001.html>

From james.sqawz at gmail.com  Mon Apr 18 12:58:48 2016
From: james.sqawz at gmail.com (james sqawz)
Date: Mon, 18 Apr 2016 18:28:48 +0530
Subject: [openssl-users] openssl-users Digest, Vol 17, Issue 24
In-Reply-To: <mailman.3961.1460983925.1813.openssl-users@openssl.org>
References: <mailman.3961.1460983925.1813.openssl-users@openssl.org>
Message-ID: <CANz_a=oHR4WhpkESZMCJdGFGXq88XN4eQ5T3sPO0uQYCN2e8sQ@mail.gmail.com>

@danigrosu

Not exactly Apache server.
But from some different client it properly responded with "SERVER HELLO" .

Thanks

On Mon, Apr 18, 2016 at 6:22 PM, <openssl-users-request at openssl.org> wrote:

> Send openssl-users mailing list submissions to
>         openssl-users at openssl.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> or, via email, send a message with subject or body 'help' to
>         openssl-users-request at openssl.org
>
> You can reach the person managing the list at
>         openssl-users-owner at openssl.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of openssl-users digest..."
>
>
> Today's Topics:
>
>    1. API question; v3_asid/v3_addr (Salz, Rich)
>    2. 1.1.0-pre4: openssl speed chacha (c^)
>    3. Unable to load/add a dynamic engine (danigrosu)
>    4. Regarding TLS 1.3 (James)
>    5. Re: Regarding TLS 1.3 (Matt Caswell)
>    6. ssl connect failed (james sqawz)
>    7. Re: ssl connect failed (danigrosu)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 14 Apr 2016 16:57:56 +0000
> From: "Salz, Rich" <rsalz at akamai.com>
> To: "openssl-dev at openssl.org" <openssl-dev at openssl.org>,
>         "openssl-users at openssl.org" <openssl-users at openssl.org>
> Subject: [openssl-users] API question; v3_asid/v3_addr
> Message-ID:
>         <
> f583e20aef574e55a5761812440daec9 at usma1ex-dag1mb1.msg.corp.akamai.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Do you use the v3_asid_xxx or v3_addr_xxx API's?  Please let me know.
>
> (They are not going away, we just need to know if they're internal-only or
> if people are using them.)
>
> --
> Senior Architect, Akamai Technologies
> IM: richsalz at jabber.at Twitter: RichSalz
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20160414/052eaa82/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 15 Apr 2016 15:29:16 +0100
> From: "c^" <c at gryning.com>
> To: openssl-users at openssl.org
> Subject: [openssl-users] 1.1.0-pre4: openssl speed chacha
> Message-ID:
>         <CAK-1ke=KRi2DCji7TwQeJVf6mrkrheu6FQerLpwWW-T3m=
> 6a+A at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi there,
>
> I don't seem to be able to benchmark chacha, nor does it appear in the list
> when I test all.
> Is this expected?
>
> I can see it in 'openssl ciphers -V "ALL"' and also negotiate from a
> client.
>
> Thanks
> CraigT
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20160415/70647e35/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Sun, 17 Apr 2016 01:26:29 -0700 (MST)
> From: danigrosu <dni.grosu at gmail.com>
> To: openssl-users at openssl.org
> Subject: [openssl-users] Unable to load/add a dynamic engine
> Message-ID: <1460881589415-65563.post at n7.nabble.com>
> Content-Type: text/plain; charset=us-ascii
>
> Hi. I am using the OpenSSL 1.0.1f and I built a RSA engine using CUDA code.
> I want to load this engine dynamically, i.e. when I type /# openssl
> engine/,
> I want
> to see my engine id on the list, but all I see is this:
> /(rsax) RSAX engine support
> (dynamic) Dynamic engine loading support/ where the rsax is builtin
>
> I have modified the openssl.cnf file by adding the following lines:
> /openssl_conf = openssl_def
> [openssl_def]
> engines = engine_section
>
> [engine_section]
> foo = gpu_section
>
> [gpu_section]
> dynamic_path =
> /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/librsax_gpu.so
> engine_id = rsax_gpu
> default_algorithms = RSA
> init = 1                /
>
> I tried this: /# openssl speed rsa512 -engine rsax_gpu/ and everything went
> well.
>
> Please tell me why I can't load dynamically the engine?
>
>
>
> --
> View this message in context:
> http://openssl.6102.n7.nabble.com/Unable-to-load-add-a-dynamic-engine-tp65563.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 18 Apr 2016 11:02:40 +0530
> From: James <james.arivazhagan at gmail.com>
> To: openssl-users at openssl.org
> Subject: [openssl-users] Regarding TLS 1.3
> Message-ID:
>         <
> CAJLNLpfAhWa7QuxwUBug4WTnw0U1izuCODyXHZ36gB22_M+c7Q at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi there,
> In the below link I could see TLS 1.3 support will be added in future
> releases
>  https://www.openssl.org/policies/roadmap.html
>
> I think the support is not yet added. From when it will be added
>
> regards,
> James Arivazhagan Ponnusamy
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/4278b096/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Mon, 18 Apr 2016 08:56:13 +0100
> From: Matt Caswell <matt at openssl.org>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Regarding TLS 1.3
> Message-ID: <5714931D.6080302 at openssl.org>
> Content-Type: text/plain; charset=windows-1252
>
>
>
> On 18/04/16 06:32, James wrote:
> > Hi there,
> > In the below link I could see TLS 1.3 support will be added in future
> > releases
> >  https://www.openssl.org/policies/roadmap.html
> >
> > I think the support is not yet added. From when it will be added
>
> TLS1.3 will not be in the next release which is currently in beta (i.e.
> 1.1.0). I hope that it will be in the release after that but we have not
> yet got a timescale for that.
>
> Matt
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 18 Apr 2016 18:16:50 +0530
> From: james sqawz <james.sqawz at gmail.com>
> To: openssl-users at openssl.org
> Subject: [openssl-users] ssl connect failed
> Message-ID:
>         <CANz_a=
> rU5rhnEQGm0uG4g1GJNn7-XnZiUWSG7xDk6WdCBowtzA at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi all,
>
> Thanks for the providing the forum for discussion on TLS/OPENSSL related
> issue.
>
> I am very new to openssl.
>
> Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
> For that purpose I send connect request to the server,but connection is
> getting failed.
>
> Following fields are abscent in my ssl packet.
>
> Extension: server name present
> Extension:application layer protocol negotiation
>
> Apart from that I did not set path of Server Certificate.
>
> Shall these impact my connect request.
> Can somebody help.
>
> Thanks
> James
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/b8bef704/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 7
> Date: Mon, 18 Apr 2016 04:50:49 -0700 (MST)
> From: danigrosu <dni.grosu at gmail.com>
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] ssl connect failed
> Message-ID:
>         <CAGYz=
> CygqnxFgQ9t+7BSJff038VTCphDpJRYzqn-0gcz9QGSkw at mail.gmail.com>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi.
>
> Are you using the Apache server?
>
> On 18 April 2016 at 14:46, james sqawz [via OpenSSL] <
> ml-node+s6102n65566h85 at n7.nabble.com> wrote:
>
> > Hi all,
> >
> > Thanks for the providing the forum for discussion on TLS/OPENSSL related
> > issue.
> >
> > I am very new to openssl.
> >
> > Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
> > For that purpose I send connect request to the server,but connection is
> > getting failed.
> >
> > Following fields are abscent in my ssl packet.
> >
> > Extension: server name present
> > Extension:application layer protocol negotiation
> >
> > Apart from that I did not set path of Server Certificate.
> >
> > Shall these impact my connect request.
> > Can somebody help.
> >
> > Thanks
> > James
> >
> > --
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> > ------------------------------
> > If you reply to this email, your message will be added to the discussion
> > below:
> > http://openssl.6102.n7.nabble.com/ssl-connect-failed-tp65566.html
> > To unsubscribe from OpenSSL - User, click here
> > <
> http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=3&code=ZG5pLmdyb3N1QGdtYWlsLmNvbXwzfC0xOTcxNTAwNzE2
> >
> > .
> > NAML
> > <
> http://openssl.6102.n7.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml
> >
> >
>
>
>
>
> --
> View this message in context:
> http://openssl.6102.n7.nabble.com/ssl-connect-failed-tp65566p65567.html
> Sent from the OpenSSL - User mailing list archive at Nabble.com.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/ffeb33cb/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 17, Issue 24
> *********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/a6ace247/attachment.html>

From dni.grosu at gmail.com  Mon Apr 18 12:08:00 2016
From: dni.grosu at gmail.com (danigrosu)
Date: Mon, 18 Apr 2016 05:08:00 -0700 (MST)
Subject: [openssl-users] openssl-users Digest, Vol 17, Issue 24
In-Reply-To: <CANz_a=oHR4WhpkESZMCJdGFGXq88XN4eQ5T3sPO0uQYCN2e8sQ@mail.gmail.com>
References: <CANz_a=oHR4WhpkESZMCJdGFGXq88XN4eQ5T3sPO0uQYCN2e8sQ@mail.gmail.com>
Message-ID: <CAGYz=CzFqeuB4Ydg=kPVicPZ7-m3-wNaBL_bbLAk1RQKn+sD9g@mail.gmail.com>

So the problem is on client side since you receive server hello.
Please give some more details. What are you trying to do and
especially how.

Regards,
Dani Grosu




--
View this message in context: http://openssl.6102.n7.nabble.com/Re-openssl-users-Digest-Vol-17-Issue-24-tp65568p65570.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/9953d252/attachment-0001.html>

From beldmit at gmail.com  Mon Apr 18 14:55:30 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 18 Apr 2016 17:55:30 +0300
Subject: [openssl-users] EVP_EncryptUpdate and EVP_CIPHER callback do_cipher
Message-ID: <CADqLbzKQB9BLasniryQjUrrp_3fjD0oGe4reA+7FLVhsMbc8NQ@mail.gmail.com>

Hello,

Could anybody explain how to deal with the output length in the
EVP_EncryptUpdate?

The function EVP_EncryptUpdate has the outl output parameter, which is
designed for returning the length of the resulting ciphertext. Then
internally it calls the do_cipher callback which does not take such a
parameter.

Is there a way to return an expected buffer length from the callback?
It may be necessary when we call the EVP_EncryptUpdate some times, and we
get the case when ctx->buf from the previous calls has enough bytes to be
processed together with the input buffer so the output is longer then the
input.

Thank you!

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

From matt at openssl.org  Mon Apr 18 15:00:58 2016
From: matt at openssl.org (Matt Caswell)
Date: Mon, 18 Apr 2016 16:00:58 +0100
Subject: [openssl-users] EVP_EncryptUpdate and EVP_CIPHER callback
 do_cipher
In-Reply-To: <CADqLbzKQB9BLasniryQjUrrp_3fjD0oGe4reA+7FLVhsMbc8NQ@mail.gmail.com>
References: <CADqLbzKQB9BLasniryQjUrrp_3fjD0oGe4reA+7FLVhsMbc8NQ@mail.gmail.com>
Message-ID: <5714F6AA.5030701@openssl.org>



On 18/04/16 15:55, Dmitry Belyavsky wrote:
> Hello,
> 
> Could anybody explain how to deal with the output length in the
> EVP_EncryptUpdate?
> 
> The function EVP_EncryptUpdate has the outl output parameter, which is
> designed for returning the length of the resulting ciphertext. Then
> internally it calls the do_cipher callback which does not take such a
> parameter.
> 
> Is there a way to return an expected buffer length from the callback?
> It may be necessary when we call the EVP_EncryptUpdate some times, and
> we get the case when ctx->buf from the previous calls has enough bytes
> to be processed together with the input buffer so the output is longer
> then the input.

The man page advises that the size of the output buffer should be:

inl + cipher_block_size - 1

This should cater for all eventualities.

Matt

From beldmit at gmail.com  Mon Apr 18 15:04:35 2016
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Mon, 18 Apr 2016 18:04:35 +0300
Subject: [openssl-users] EVP_EncryptUpdate and EVP_CIPHER callback
	do_cipher
In-Reply-To: <5714F6AA.5030701@openssl.org>
References: <CADqLbzKQB9BLasniryQjUrrp_3fjD0oGe4reA+7FLVhsMbc8NQ@mail.gmail.com>
 <5714F6AA.5030701@openssl.org>
Message-ID: <CADqLbzJmKRVBMOPEGpj21qn_b32W8OwCBGWCGAuLB1=rNcP6VA@mail.gmail.com>

Dear Matt,

On Mon, Apr 18, 2016 at 6:00 PM, Matt Caswell <matt at openssl.org> wrote:

>
>
> On 18/04/16 15:55, Dmitry Belyavsky wrote:
> > Hello,
> >
> > Could anybody explain how to deal with the output length in the
> > EVP_EncryptUpdate?
> >
> > The function EVP_EncryptUpdate has the outl output parameter, which is
> > designed for returning the length of the resulting ciphertext. Then
> > internally it calls the do_cipher callback which does not take such a
> > parameter.
> >
> > Is there a way to return an expected buffer length from the callback?
> > It may be necessary when we call the EVP_EncryptUpdate some times, and
> > we get the case when ctx->buf from the previous calls has enough bytes
> > to be processed together with the input buffer so the output is longer
> > then the input.
>
> The man page advises that the size of the output buffer should be:
>
> inl + cipher_block_size - 1
>
> This should cater for all eventualities.
>

Thank you!

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

From Tristan.Leask at enghouse.com  Mon Apr 18 15:01:22 2016
From: Tristan.Leask at enghouse.com (Tristan Leask)
Date: Mon, 18 Apr 2016 15:01:22 +0000
Subject: [openssl-users] FIPS compile issue with Perl on Windows
Message-ID: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>

Hi All,

I am currently trying to setup an automated build process for a cloned copy of the code.  I can run through the process manually by issuing all the commands required from a command line without issue.  If I then take all these commands and put them into a CI job using Jenkins, I then see the following type of error...
set ASM=ml64 /c /Cp /Cx /Zi
	perl crypto\modes\asm\ghash-x86_64.pl tmp32dll\ghash-x86_64.asm
	perl util\fipsas.pl . tmp32dll\ghash-x86_64.asm norunasm /MD /Ox -DOPENSSL_FIPSCANISTER -DOPENSSL_THREADS  -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DOPENSSL_USE_APPLINK -I. -DOPENSSL_NO_RC5 -DOPENSSL_NO_MD2 -DOPENSSL_NO_KRB5 -DOPENSSL_FIPS -DOPENSSL_NO_JPAKE -DOPENSSL_NO_STATIC_ENGINE
	ml64 /c /Cp /Cx /Zi /Fotmp32dll\ghash-x86_64.obj tmp32dll\ghash-x86_64.asm
 Assembling: tmp32dll\ghash-x86_64.asm
tmp32dll\ghash-x86_64.asm(868
tmp32dll\ghash-x86_64.asm(868) : error A2008:syntax errortmp32dll\ghash-x86_64.asm(1012)e
tmp32dll\ghash-x86_64.asm(1012) : fatal error A1010:unmatched block nesting : gcm_gMicrosoft (R) Macro Assembler (x64) Version 14.00.23026.0
Copyright (C) Microsoft Corporation.  All rights reserved.

NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64\ml64.EXE"' : return code '0x1'

I have done some digging and I am sure I am running into the issue discussed here...
https://rt.openssl.org/Ticket/Display.html?id=2963&user=guest&pass=guest

This is to do with Perl not being able to flush the STDOUT pipe to disk fast enough before the ml compiler tries to pick the ASM file up.

In the link mentioned, it is talked about modifying the perl script to change how STDOUT works, however when you are compiling FIPS you aren't meant to modify the code shipped in the tarball, so how does one work around this issue apart from just compiling the code manually all the time?

I am running Visual Studio 2015 and ActivePerl-5.22.1.2201-MSWin32-x64-299574, and I am trying to compile openssl-1.0.2g and openssl-fips-2.0.12.

Thanks


From marquess at openssl.com  Mon Apr 18 16:08:32 2016
From: marquess at openssl.com (Steve Marquess)
Date: Mon, 18 Apr 2016 12:08:32 -0400
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
Message-ID: <57150680.7070700@openssl.com>

On 04/18/2016 11:01 AM, Tristan Leask wrote:
> Hi All,
> 
> I am currently trying to setup an automated build process for a
> cloned copy of the code.  ...
> 
> In the link mentioned, it is talked about modifying the perl script
> to change how STDOUT works, however when you are compiling FIPS you
> aren't meant to modify the code shipped in the tarball, so how does
> one work around this issue apart from just compiling the code
> manually all the time?

There is really no point in trying to automate the build of the FIPS
module (fipscanister.o). As noted you can't change the source code
(contents of the tarball) at all, plus you're constrained by the
requirements of the Security Policy to build the module with precisely
the commands:

  gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
  cd openssl-fips-2.0.12
  ./config
  make

The Security Policy doesn't expressly prohibit you from embedding those
commands in a script, but IMHO you gain nothing but grief by doing so.
Build it manually, once, with some sort of record as a CYA for your file
cabinet.

Once you have the one and only copy of fipscanister.o you need (per
platform), you can then use normal software engineering best practice
for building OpenSSL proper (e.g. 1.0.2g) and your application code, and
automation would make more sense.

-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 tristan.leask at enghouse.com  Mon Apr 18 20:05:19 2016
From: tristan.leask at enghouse.com (Leaky)
Date: Mon, 18 Apr 2016 13:05:19 -0700 (MST)
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <57150680.7070700@openssl.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com>
Message-ID: <1461009919874-65577.post@n7.nabble.com>

>> plus you're constrained by the
>> requirements of the Security Policy to build the module with precisely
>> the commands:
>>
>>  gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
>>  cd openssl-fips-2.0.12
>>  ./config
>>  make

Silly question... I know that you should only run the above commands, but
can you deviate from the unzip tool, i.e. use 7zip?

I managed to get it to work without editing anything, but I am now wondering
if my process to compile the FIPS canister is bad purely because i am
storing the deflated tarball on our SVN and using that uncompressed code to
build from.  Putting aside the fact that this is automated, and that it is
best to "run once and use many", should my script work with the raw tarball
straight from the web, and not a locally expanded copy?







--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-compile-issue-with-Perl-on-Windows-tp65574p65577.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From marquess at openssl.com  Mon Apr 18 23:51:23 2016
From: marquess at openssl.com (Steve Marquess)
Date: Mon, 18 Apr 2016 19:51:23 -0400
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <1461009919874-65577.post@n7.nabble.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com> <1461009919874-65577.post@n7.nabble.com>
Message-ID: <571572FB.6040508@openssl.com>

On 04/18/2016 04:05 PM, Leaky wrote:
>>> plus you're constrained by the
>>> requirements of the Security Policy to build the module with precisely
>>> the commands:
>>>
>>>  gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
>>>  cd openssl-fips-2.0.12
>>>  ./config
>>>  make
> 
> Silly question... I know that you should only run the above commands, but
> can you deviate from the unzip tool, i.e. use 7zip?
> 
> I managed to get it to work without editing anything, but I am now wondering
> if my process to compile the FIPS canister is bad purely because i am
> storing the deflated tarball on our SVN and using that uncompressed code to
> build from.  Putting aside the fact that this is automated, and that it is
> best to "run once and use many", should my script work with the raw tarball
> straight from the web, and not a locally expanded copy?

This is a mistake I've seen many times ("storing the deflated tarball on
our SVN"). You're thinking like a software engineer, when you should be
thinking like Alice down in the FIPS 140-2 rabbit hole.

There is no point in attempting to do the usual configuration management
and software version control on the contents of the
openssl-fips-2.0.12.tar.gz tarball. You CANNOT change the content; there
can be no changes to manage!!!

The Security Policy is quite specific on the requirements, which make no
allowance for the common sense (to a software engineer) fact that there
are equivalent multiple ways to accomplish each step (such as unzipping
the tarball). You are also specifically required to begin with the
official tarball. Per the Security Policy, you *must* do:

  gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -

and *not* any functionally equivalent alternative such as:

  tar -zxf openssl-fips-2.0.12.tar.gz

or even worse, a checkout of the expanded contents from your version
management system.

This is why I recommend you build the FIPS module once, manually,
exactly per the documented requirements. It doesn't make sense, from the
software engineering viewpoint, but is what the FIPS 140-2 validation
bureaucracy insists on.

-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 jb-openssl at wisemo.com  Tue Apr 19 00:25:39 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 19 Apr 2016 02:25:39 +0200
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <571572FB.6040508@openssl.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com> <1461009919874-65577.post@n7.nabble.com>
 <571572FB.6040508@openssl.com>
Message-ID: <57157B03.1050300@wisemo.com>

On 19/04/2016 01:51, Steve Marquess wrote:
> On 04/18/2016 04:05 PM, Leaky wrote:
>>>> plus you're constrained by the
>>>> requirements of the Security Policy to build the module with precisely
>>>> the commands:
>>>>
>>>>   gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
>>>>   cd openssl-fips-2.0.12
>>>>   ./config
>>>>   make
>> Silly question... I know that you should only run the above commands, but
>> can you deviate from the unzip tool, i.e. use 7zip?
>>
>> I managed to get it to work without editing anything, but I am now wondering
>> if my process to compile the FIPS canister is bad purely because i am
>> storing the deflated tarball on our SVN and using that uncompressed code to
>> build from.  Putting aside the fact that this is automated, and that it is
>> best to "run once and use many", should my script work with the raw tarball
>> straight from the web, and not a locally expanded copy?
> This is a mistake I've seen many times ("storing the deflated tarball on
> our SVN"). You're thinking like a software engineer, when you should be
> thinking like Alice down in the FIPS 140-2 rabbit hole.
>
> There is no point in attempting to do the usual configuration management
> and software version control on the contents of the
> openssl-fips-2.0.12.tar.gz tarball. You CANNOT change the content; there
> can be no changes to manage!!!
Almost true.  If it wasn't banned by the FIPS security policy, checking in
the uncompressed tarball could be used to efficiently manage and track new
upstream releases of the tarball and to document which exact upstream FIPS
cannister source code (and hence corresponding validation date) was
incorporated into which product version (an aspect of FIPS compliance which
someone might want to audit

But alas, as you clarify below, this is not permitted by the OpenSSL FIPS
security policy directly incorporated into the validation.

The slightly less efficient idea of putting the compressed tarball into
the configuration control repository (which in this case *is* tracking the
build configuration, not the code versions) is probably (I am not sure)
againstthe policy that the tarball must be taken "securely" from the
physical CD mailed out by the OpenSSL foundation.

So the thing that can probably be put into a repository is the binary
FIPSCannister.o file along with copies of any documents certifying how,
where, from what and by whom said FIPS cannister was built.

Of cause, one could, purely for debugging/documentation purposes, include
a copy of the FIPS Cannister source code in the repository, one just
cannot compile anything releasable from it.

>
> The Security Policy is quite specific on the requirements, which make no
> allowance for the common sense (to a software engineer) fact that there
> are equivalent multiple ways to accomplish each step (such as unzipping
> the tarball). You are also specifically required to begin with the
> official tarball. Per the Security Policy, you *must* do:
>
>    gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -
>
> and *not* any functionally equivalent alternative such as:
>
>    tar -zxf openssl-fips-2.0.12.tar.gz
>
> or even worse, a checkout of the expanded contents from your version
> management system.
>
> This is why I recommend you build the FIPS module once, manually,
> exactly per the documented requirements. It doesn't make sense, from the
> software engineering viewpoint, but is what the FIPS 140-2 validation
> bureaucracy insists on.
>
> -Steve M.
>
>


Enjoy

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


From openssl-users at dukhovni.org  Tue Apr 19 02:44:05 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 19 Apr 2016 02:44:05 +0000
Subject: [openssl-users] [openssl-dev] where is PEM_read_bio_X509_AUX()
In-Reply-To: <HE1PR08MB04277D28737D4BB19AAF8997D66C0@HE1PR08MB0427.eurprd08.prod.outlook.com>
References: <HE1PR08MB04277D28737D4BB19AAF8997D66C0@HE1PR08MB0427.eurprd08.prod.outlook.com>
Message-ID: <20160419024404.GS26423@mournblade.imrryr.org>

[ Redirecting to openssl-users at openssl.org ]

On Tue, Apr 19, 2016 at 01:11:38AM +0000, CHOW Anthony wrote:

> I am trying to do ?openssl verify ?CAfile server.pem? and the command hang.

It is supposed to hang (reading standard input) when (incorrectly)
invoked this way.  You've left out the CAfile filename.  The correct
way to verify a certificate is:

    $ trusted=ta.pem
    $ untrusted=intermediate.pem
    $ subject=server.pem
    $ openssl verify -CAfile $trusted -untrusted $untrusted $subject

where 

 * "ta.pem" contains your trust-anchor (root CA) certificates,
 * "intermediate.pem" contains any intermediate certificates needed to
    build a trust path from a root down to the server certificate,
 * "server.pem" contains the subject certificate to be verified.

Leave out the "-untrusted $untrusted" option if you're verifying
a certificate that is directly issued by a trust-anchor.

With a sufficiently recent version of OpenSSL replace "-CAfile
$trusted" with "-trusted $trusted" to make sure you're not
inadvertently using any of the default trust-anchors installed on
your system.

-- 
	Viktor.

From alex at samad.com.au  Tue Apr 19 03:55:55 2016
From: alex at samad.com.au (Alex Samad)
Date: Tue, 19 Apr 2016 13:55:55 +1000
Subject: [openssl-users] help with timestamping
Message-ID: <CAJ+Q1PX6BP7Lok50xZ2kkz5DAYQyOQzd8kbJy=wkcyG7vqUcyQ@mail.gmail.com>

Hi

I have a SHA.sha file

/usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H
Content-Type:application/timestamp-query --data-binary @-
http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr

/usr/bin/openssl ts -reply -in SHA.sha.tsr -text  > SHA.sha.ts.txt


cat SHA.sha.ts.txt
Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified

TST info:
Version: 1
Policy OID: 2.16.840.1.113733.1.7.23.3
Hash Algorithm: sha256
Message data:
    0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6   .m.[.......WE.i.
    0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5   z.....U%..W7>\..
Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB
Time stamp: Apr 19 03:52:25 2016 GMT
Accuracy: 0x1E seconds, unspecified millis, unspecified micros
Ordering: no
Nonce: 0x580E59D87F396B25
TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
Network/CN=Symantec SHA256 TimeStamping Signer - G1
Extensions:


But when I go to verify it

 openssl ts -verify -data SHA.sha -in SHA.sha.tsr
Verification: FAILED
140569777235784:error:2107C080:PKCS7
routines:PKCS7_get0_signers:signer certificate not
found:pk7_smime.c:476:

is this because I didn't provide a cert to sign it with ?

I just want to verify the timestamp.

Thanks

From jb-openssl at wisemo.com  Tue Apr 19 04:29:52 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 19 Apr 2016 06:29:52 +0200
Subject: [openssl-users] help with timestamping
In-Reply-To: <CAJ+Q1PX6BP7Lok50xZ2kkz5DAYQyOQzd8kbJy=wkcyG7vqUcyQ@mail.gmail.com>
References: <CAJ+Q1PX6BP7Lok50xZ2kkz5DAYQyOQzd8kbJy=wkcyG7vqUcyQ@mail.gmail.com>
Message-ID: <5715B440.8000706@wisemo.com>

On 19/04/2016 05:55, Alex Samad wrote:
> Hi
>
> I have a SHA.sha file
>
> /usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H
> Content-Type:application/timestamp-query --data-binary @-
> http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr
>
> /usr/bin/openssl ts -reply -in SHA.sha.tsr -text  > SHA.sha.ts.txt
>
>
> cat SHA.sha.ts.txt
> Status info:
> Status: Granted.
> Status description: unspecified
> Failure info: unspecified
>
> TST info:
> Version: 1
> Policy OID: 2.16.840.1.113733.1.7.23.3
> Hash Algorithm: sha256
> Message data:
>      0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6   .m.[.......WE.i.
>      0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5   z.....U%..W7>\..
> Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB
> Time stamp: Apr 19 03:52:25 2016 GMT
> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
> Ordering: no
> Nonce: 0x580E59D87F396B25
> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
> Network/CN=Symantec SHA256 TimeStamping Signer - G1
> Extensions:
>
>
> But when I go to verify it
>
>   openssl ts -verify -data SHA.sha -in SHA.sha.tsr
> Verification: FAILED
> 140569777235784:error:2107C080:PKCS7
> routines:PKCS7_get0_signers:signer certificate not
> found:pk7_smime.c:476:
>
> is this because I didn't provide a cert to sign it with ?
No, it is because it cannot find the certificate that Symantec
used to sign the response, specifically the certificate with
Subject name "/C=US/O=Symantec Corporation/OU=Symantec Trust
Network/CN=Symantec SHA256 TimeStamping Signer - G1".

I am kind of disappointed in how little detail is included in
the output from ts -reply -text, I expected it to output all
the fields, similar to what other openssl commands do when
passed the -text option.

So I guess the next step would be to dump SHA.sha.tsr using
Peter Gutmann's dumpasn1.c program, something like

openssl base64 -d -in SHA.sha.tsr -out SHA.sha.tsr.bin
dumpasn1 -v SHA.sha.tsr.bin


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 marquess at openssl.com  Tue Apr 19 12:00:44 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 19 Apr 2016 08:00:44 -0400
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <57157B03.1050300@wisemo.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com> <1461009919874-65577.post@n7.nabble.com>
 <571572FB.6040508@openssl.com> <57157B03.1050300@wisemo.com>
Message-ID: <57161DEC.1070207@openssl.com>

On 04/18/2016 08:25 PM, Jakob Bohm wrote:
> On 19/04/2016 01:51, Steve Marquess wrote:
>> On 04/18/2016 04:05 PM, Leaky wrote:
>>>>> plus you're constrained by the
>>>>> requirements of the Security Policy to build the module with precisely
>>>>> the commands:
>>>>>
>>>>>   gunzip -c openssl-fips-2.0.12.tar.gz | tar xvf -
>>>>>   cd openssl-fips-2.0.12
>>>>>   ./config
>>>>>   make
>>> Silly question... I know that you should only run the above commands,
>>> but
>>> can you deviate from the unzip tool, i.e. use 7zip?
>>>
>>> ...
>>
>> There is no point in attempting to do the usual configuration management
>> and software version control on the contents of the
>> openssl-fips-2.0.12.tar.gz tarball. You CANNOT change the content; there
>> can be no changes to manage!!!
> Almost true.  If it wasn't banned by the FIPS security policy, checking in
> the uncompressed tarball could be used to efficiently manage and track new
> upstream releases of the tarball and to document which exact upstream FIPS
> cannister source code (and hence corresponding validation date) was
> incorporated into which product version (an aspect of FIPS compliance which
> someone might want to audit

Well, the righteous way to track the "exact upstream FIPS cannister
source code" is by the SHA1 digest of the tarball that is documented in
the Security Policy.

> 
> But alas, as you clarify below, this is not permitted by the OpenSSL FIPS
> security policy directly incorporated into the validation.
> 
> The slightly less efficient idea of putting the compressed tarball into
> the configuration control repository (which in this case *is* tracking the
> build configuration, not the code versions) is probably (I am not sure)
> againstthe policy that the tarball must be taken "securely" from the
> physical CD mailed out by the OpenSSL foundation.

Per the CMVP internal storage and transmission of the official tarball
within the end user organization is not subject to any special
requirements, once that organization has received the official
snail-mailed CD disk. So for instance the east coast office of vendor
XYZ could copy the openssl-fips-2.0.12.tar.gz tarball off of the
official CD onto the corporate internal network, where it could be
retrieved and used by the west coast office. So by that logic you could
stash the complete tarball in an internal repository.

That doesn't make a lot of sense, but hey it's FIPS 140-2. The CMVP was
most insistent on the snail-mailed CD requirement during the #1747
validation -- resolution of that "secure distribution" issue held up the
validation by a couple of months -- but I can't help but notice that
several "Alternative Scenario 1A/1B" validations granted since then
(which are supposedly carbon copy clones) have been allowed to omit the
snail-mail CD requirement. So even the CMVP itself is confused by this
requirement.

> So the thing that can probably be put into a repository is the binary
> FIPSCannister.o file along with copies of any documents certifying how,
> where, from what and by whom said FIPS cannister was built.

Exactly, and this is my recommendation (per section 5.5 of the FIPS
module User Guide).

-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 tristan.leask at enghouse.com  Tue Apr 19 11:44:56 2016
From: tristan.leask at enghouse.com (Leaky)
Date: Tue, 19 Apr 2016 04:44:56 -0700 (MST)
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <57157B03.1050300@wisemo.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com> <1461009919874-65577.post@n7.nabble.com>
 <571572FB.6040508@openssl.com> <57157B03.1050300@wisemo.com>
Message-ID: <1461066296179-65591.post@n7.nabble.com>

> The Security Policy is quite specific on the requirements, which make no
> allowance for the common sense (to a software engineer) fact that there
> are equivalent multiple ways to accomplish each step (such as unzipping
> the tarball). You are also specifically required to begin with the
> official tarball. Per the Security Policy, you *must* do:
>
>    gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -
>
> and *not* any functionally equivalent alternative such as:
>
>    tar -zxf openssl-fips-2.0.12.tar.gz
>

Thanks, but I am still scratching my head as to if that is even possible on
Windows, which would mean you can't actually compile the FIPS canister on
Windows and meet the security policy.



--
View this message in context: http://openssl.6102.n7.nabble.com/FIPS-compile-issue-with-Perl-on-Windows-tp65574p65591.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From jb-openssl at wisemo.com  Tue Apr 19 13:16:13 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 19 Apr 2016 15:16:13 +0200
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <1461066296179-65591.post@n7.nabble.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com> <1461009919874-65577.post@n7.nabble.com>
 <571572FB.6040508@openssl.com> <57157B03.1050300@wisemo.com>
 <1461066296179-65591.post@n7.nabble.com>
Message-ID: <57162F9D.6000905@wisemo.com>

On 19/04/2016 13:44, Leaky wrote:
>> The Security Policy is quite specific on the requirements, which make no
>> allowance for the common sense (to a software engineer) fact that there
>> are equivalent multiple ways to accomplish each step (such as unzipping
>> the tarball). You are also specifically required to begin with the
>> official tarball. Per the Security Policy, you *must* do:
>>
>>     gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -
>>
>> and *not* any functionally equivalent alternative such as:
>>
>>     tar -zxf openssl-fips-2.0.12.tar.gz
>>
> Thanks, but I am still scratching my head as to if that is even possible on
> Windows, which would mean you can't actually compile the FIPS canister on
> Windows and meet the security policy.
>
There are Windows ports of gzip, gunzip and tar.  For example in the CYGWIN
distribution (from https://cygwin.com) or MingW32 (those 2 are free), there
are also commercial versions such as MKS.

If you use the CYGWIN variant, but run under the Windows CMD shell, you 
will
have to crate a .CMD equivalent of the gunzip shell script. Instead of the
long winded code to output messages about what gunzip is, the following one
line file should do the trick (there is no lf or crlf at the end of the
line!), save this as gunzip.cmd somewhere on your PATH.

@x:\SOMEPATH\CYGWIN\bin\gzip.exe -d %*

(x:\DOMEPATH\CYGWIN is obviously whereever you installed CYGWIN)

Similarly create tar.cmd


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 marquess at openssl.com  Tue Apr 19 14:31:46 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 19 Apr 2016 10:31:46 -0400
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <57162F9D.6000905@wisemo.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com> <1461009919874-65577.post@n7.nabble.com>
 <571572FB.6040508@openssl.com> <57157B03.1050300@wisemo.com>
 <1461066296179-65591.post@n7.nabble.com> <57162F9D.6000905@wisemo.com>
Message-ID: <57164152.30102@openssl.com>

On 04/19/2016 09:16 AM, Jakob Bohm wrote:
> On 19/04/2016 13:44, Leaky wrote:
>>> The Security Policy is quite specific on the requirements, which make no
>>> allowance for the common sense (to a software engineer) fact that there
>>> are equivalent multiple ways to accomplish each step (such as unzipping
>>> the tarball). You are also specifically required to begin with the
>>> official tarball. Per the Security Policy, you *must* do:
>>>
>>>     gunzip -c openssl-fips-2.0.12.tar.gz | tar xf -
>>>
>>> and *not* any functionally equivalent alternative such as:
>>>
>>>     tar -zxf openssl-fips-2.0.12.tar.gz
>>>
>> Thanks, but I am still scratching my head as to if that is even
>> possible on
>> Windows, which would mean you can't actually compile the FIPS canister on
>> Windows and meet the security policy.
>>
> There are Windows ports of gzip, gunzip and tar.  For example in the CYGWIN
> distribution (from https://cygwin.com) or MingW32 (those 2 are free), there
> are also commercial versions such as MKS.
> 
> If you use the CYGWIN variant, but run under the Windows CMD shell, you
> will
> have to crate a .CMD equivalent of the gunzip shell script. Instead of the
> long winded code to output messages about what gunzip is, the following one
> line file should do the trick (there is no lf or crlf at the end of the
> line!), save this as gunzip.cmd somewhere on your PATH.
> 
> @x:\SOMEPATH\CYGWIN\bin\gzip.exe -d %*
> 
> (x:\DOMEPATH\CYGWIN is obviously whereever you installed CYGWIN)
> 
> Similarly create tar.cmd

Good catch, Jakob. I missed the Windows part.

As documented in Appendix A of the Security Policy, for Windows the
required canonical build commands are:

  ms\do_fips no-asm

or

  ms\do_fips

instead of the "./config ...; make" used for *nix style platforms. The

  gunzip -c openssl-fips-2.0.N.tar.gz | tar xf -
  cd openssl-fips-2.0.N

is still required, which as you noted can be done with a third party
"gunzip", e.g. from Cygwin.

Note that from a software engineering viewpoint it doesn't make much
sense to require that a "gunzip" command be installed and used when
another equivalent method of expanding the tarball is available, but the
CMVP required the specification of fixed build commands from the very
first validation.

No requirement that a specific version of "gunzip" be used, so the use
of a script would appear to be permitted.

Confusing, for sure...

-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 jb-openssl at wisemo.com  Tue Apr 19 14:43:44 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 19 Apr 2016 16:43:44 +0200
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <57164152.30102@openssl.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com> <1461009919874-65577.post@n7.nabble.com>
 <571572FB.6040508@openssl.com> <57157B03.1050300@wisemo.com>
 <1461066296179-65591.post@n7.nabble.com> <57162F9D.6000905@wisemo.com>
 <57164152.30102@openssl.com>
Message-ID: <57164420.5070007@wisemo.com>

On 19/04/2016 16:31, Steve Marquess wrote:
> On 04/19/2016 09:16 AM, Jakob Bohm wrote:
>> On 19/04/2016 13:44, Leaky wrote:
>>> Thanks, but I am still scratching my head as to if that is even
>>> possible on
>>> Windows, which would mean you can't actually compile the FIPS canister on
>>> Windows and meet the security policy.
>>>
>> There are Windows ports of gzip, gunzip and tar.  For example in the CYGWIN
>> distribution (from https://cygwin.com) or MingW32 (those 2 are free), there
>> are also commercial versions such as MKS.
>>
>> If you use the CYGWIN variant, but run under the Windows CMD shell, you
>> will
>> have to crate a .CMD equivalent of the gunzip shell script. Instead of the
>> long winded code to output messages about what gunzip is, the following one
>> line file should do the trick (there is no lf or crlf at the end of the
>> line!), save this as gunzip.cmd somewhere on your PATH.
>>
>> @x:\SOMEPATH\CYGWIN\bin\gzip.exe -d %*
>>
>> (x:\DOMEPATH\CYGWIN is obviously whereever you installed CYGWIN)
>>
>> Similarly create tar.cmd
> Good catch, Jakob. I missed the Windows part.
I missed it too, Leaky caught it

> As documented in Appendix A of the Security Policy, for Windows the
> required canonical build commands are:
>
>    ms\do_fips no-asm
>
> or
>
>    ms\do_fips
>
> instead of the "./config ...; make" used for *nix style platforms. The
>
>    gunzip -c openssl-fips-2.0.N.tar.gz | tar xf -
>    cd openssl-fips-2.0.N
>
> is still required, which as you noted can be done with a third party
> "gunzip", e.g. from Cygwin.
>
> Note that from a software engineering viewpoint it doesn't make much
> sense to require that a "gunzip" command be installed and used when
> another equivalent method of expanding the tarball is available, but the
> CMVP required the specification of fixed build commands from the very
> first validation.
>
> No requirement that a specific version of "gunzip" be used, so the use
> of a script would appear to be permitted.
Note that the official GNU gunzip is (as mentioned) a shell script.

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 marquess at openssl.com  Tue Apr 19 15:12:11 2016
From: marquess at openssl.com (Steve Marquess)
Date: Tue, 19 Apr 2016 11:12:11 -0400
Subject: [openssl-users] FIPS compile issue with Perl on Windows
In-Reply-To: <57164420.5070007@wisemo.com>
References: <56f25e9aee1b4fcd9ad8cfb724d7dec0@UK-MAIL-001.edge.local>
 <57150680.7070700@openssl.com> <1461009919874-65577.post@n7.nabble.com>
 <571572FB.6040508@openssl.com> <57157B03.1050300@wisemo.com>
 <1461066296179-65591.post@n7.nabble.com> <57162F9D.6000905@wisemo.com>
 <57164152.30102@openssl.com> <57164420.5070007@wisemo.com>
Message-ID: <57164ACB.6030307@openssl.com>

On 04/19/2016 10:43 AM, Jakob Bohm wrote:
> On 19/04/2016 16:31, Steve Marquess wrote:
>> On 04/19/2016 09:16 AM, Jakob Bohm wrote:
>>> On 19/04/2016 13:44, Leaky wrote:
>>>> Thanks, but I am still scratching my head as to if that is even
>>>> possible on
>>>> Windows, which would mean you can't actually compile the FIPS
>>>> canister on
>>>> Windows and meet the security policy.
>>>>...
> 
>> As documented in Appendix A of the Security Policy, for Windows the
>> required canonical build commands are:
>>
>>    ms\do_fips no-asm
>>
>> or
>>
>>    ms\do_fips
>>
>> instead of the "./config ...; make" used for *nix style platforms. The
>>
>>    gunzip -c openssl-fips-2.0.N.tar.gz | tar xf -
>>    cd openssl-fips-2.0.N
>>
>> is still required, which as you noted can be done with a third party
>> "gunzip", e.g. from Cygwin.
>>
>> Note that from a software engineering viewpoint it doesn't make much
>> sense to require that a "gunzip" command be installed and used when
>> another equivalent method of expanding the tarball is available, but the
>> CMVP required the specification of fixed build commands from the very
>> first validation.
>>
>> No requirement that a specific version of "gunzip" be used, so the use
>> of a script would appear to be permitted.
> Note that the official GNU gunzip is (as mentioned) a shell script.

My point was that even more generally use of various command definitions
appears to be allowed. For example, we have sometimes used such scripts
and/or "CC=gcc" style aliases for formal platform testing. Cross
compilations in particular generally aren't possible without such
command redefinitions; for those you're usually replacing multiple
native (to the build system) commands with those in the cross-compile
toolkit.

Use of command redefinitions to affect the behavior of the compiler (as
by adding compiler options) is rather more of a dark gray area.

-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 openssl at openssl.org  Tue Apr 19 15:14:35 2016
From: openssl at openssl.org (OpenSSL)
Date: Tue, 19 Apr 2016 15:14:35 +0000
Subject: [openssl-users] OpenSSL version 1.1.0 pre release 5 published
Message-ID: <20160419151435.GA24258@openssl.org>

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


   OpenSSL version 1.1.0 pre release 5 (beta)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   http://www.openssl.org/

   OpenSSL 1.1.0 is currently in beta. OpenSSL 1.1.0 pre release 5 has now
   been made available. For details of changes and known issues see the
   release notes at:

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

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   http://www.openssl.org/source/mirror.html):

     * http://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.0-pre5.tar.gz
      Size: 5289112
      SHA1 checksum: 1cbc066e471c831ae8c0661abb80361b4d211a70
      SHA256 checksum: 25acbdfa5e0259ed20159670e88ddb4257970f80ce923427bd201133e6e580db

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.0-pre5.tar.gz
    openssl sha256 openssl-1.1.0-pre5.tar.gz

   Please download and check this beta release as soon as possible.
   Bug reports should go to rt at openssl.org. Please check the release
   notes and mailing lists to avoid duplicate reports of known issues.

   Yours,

   The OpenSSL Project Team.

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

iQEcBAEBAgAGBQJXFkd3AAoJENnE0m0OYESRpHgIAIZpsbqsYSpoHzkT8TtJ8C83
I8pi4lgq3vWvQddKpM+iUqgeOzUUeQaCqFZmdoF2nvD+cqxlG58q9hUvm8hmbxF+
FN9a1n4WlihR626cipxBbOQz4WfFw7zmszCSYuEPT5MMFRQQR0fRgGidn6eBbAQk
37q6RDWHpwHvqIwNgwxH3qzmoV+jzqGYfZIBV/JrT2KL4M4x6L/Y5/g9WrubkHQe
oi/QjIKsXNA+bb+E0zUzhA1Yxvgz+x/VJ96yrGFrzotqLzuHR6w2TVSh4Mx/LxS0
LAdEn8h62Ts04HMyS1+9Tj6pAmJf3cq2EtR6QA+vzNgqfmA8K0jPCdzUSklgqzE=
=Wv2a
-----END PGP SIGNATURE-----

From openssl-users at openssl.org  Tue Apr 19 17:11:53 2016
From: openssl-users at openssl.org (openssl-users at openssl.org)
Date: Tue, 19 Apr 2016 17:11:53 +0000 (UTC)
Subject: [openssl-users] Banco do Brasil - Chamado 332016501 (Comunicado)
	(62759)
Message-ID: <20160419171205.C97F42FC69@valterzago1005.valterzago1005.g8.internal.cloudapp.net>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160419/29d427a9/attachment.html>

From openssl-users at openssl.org  Tue Apr 19 22:04:53 2016
From: openssl-users at openssl.org (openssl-users at openssl.org)
Date: Tue, 19 Apr 2016 22:04:53 +0000 (UTC)
Subject: Cielo - Confirme sua participação (Premiação Nº 00003881) (21989)
Message-ID: <20160419221502.77E8C4289D@valterzago1003.valterzago1003.g1.internal.cloudapp.net>

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

From scott_n at xypro.com  Tue Apr 19 23:05:28 2016
From: scott_n at xypro.com (Scott Neugroschl)
Date: Tue, 19 Apr 2016 23:05:28 +0000
Subject: [openssl-users] Spam
Message-ID: <D358E5B1511A314F8160ADC6F3754987343A490E@XYSVEX02.XYPRO-23.LOCAL>

Can the spam filters on the listserv be updated?   Got two today in Spanish and Portuguese for monetary scams.  Anyone else getting these?

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



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

From googleersatz at oliverniebuhr.de  Tue Apr 19 23:40:00 2016
From: googleersatz at oliverniebuhr.de (Oliver Niebuhr)
Date: Wed, 20 Apr 2016 01:40:00 +0200
Subject: [openssl-users] Spam
In-Reply-To: <D358E5B1511A314F8160ADC6F3754987343A490E@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F3754987343A490E@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <5716C1D0.6000100@oliverniebuhr.de>

Am 20.04.2016 um 01:05 schrieb Scott Neugroschl:
> Can the spam filters on the listserv be updated?   Got two today in
> Spanish and Portuguese for monetary scams.  Anyone else getting these?
> 
>  
> 
> ---
> 
> Scott Neugroschl | XYPRO Technology Corporation
> 
> 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805
> 583-2874|Fax 805 583-0124 |

Morning.

Yeah I got those too. I think like everyone else who subscribed to that
List and has no specific Filters set up :)

I am an Admin for some Mailman Lists myself - there is no way to block
everything with 100 Percent efficency - except if you disallow
non-members to send Message to $List.

It always depends on the local Mailing List Policy.

Greetings
Oliver


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

From jvp at forthepolls.org  Wed Apr 20 00:55:58 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Tue, 19 Apr 2016 17:55:58 -0700
Subject: [openssl-users] Spam
In-Reply-To: <5716C1D0.6000100@oliverniebuhr.de>
References: <D358E5B1511A314F8160ADC6F3754987343A490E@XYSVEX02.XYPRO-23.LOCAL>
 <5716C1D0.6000100@oliverniebuhr.de>
Message-ID: <5716D39E.6050001@forthepolls.org>

i have posted my thoughts on unacceptable list access previously and it sank to 
the level of a frequent poster denigrating other users since they took exception 
to his self-professed role of protecting list admins in order "to avoid the list 
admins following bad advice from people" who might have differing opinions from 
his own. hopefully, that will not happen here.

in re the recent Brazilian Portuguese (note the 'R$' symbol for ISO BRL rather 
than Euro) spam: what was wrong with that posting that should have been caught:

  * the IP of origin 52.165.41.104 is an MS delegation without rDNS and --
    obviously -- no SPF/TXT RR and
  * the claimed domain 'cloudapp.net' does not exist in whois (not a 100%
    indication of non-existence) or DNS (a 100% 'reject' indicator).

i have not used mailman for some time, but these two (2) simple errors would 
have been blocked by normal 'postscreen' checks and should never have gotten as 
far as mailman in any case. checking the EHLO format is in the ?s range and a 
DNS check should take < 100ms. thus, these types of errors could be quickly and 
easily eliminated with a '521' without any RBL or list-serve processing at all.

the wider problem case is how non-subscribers are given two-way access to the 
list that exposes so much subscriber info (name, professional affiliation, email 
addr, ...) to whomever. i cannot fathom why the list does not make use of 
aliases so that each subscriber can control what they want to make public via 
their alias profile.

Thank you,

Johann v. Preu?en


On 2016.Apr.19 16:40, Oliver Niebuhr wrote:
> Am 20.04.2016 um 01:05 schrieb Scott Neugroschl:
>> Can the spam filters on the listserv be updated?   Got two today in
>> Spanish and Portuguese for monetary scams.  Anyone else getting these?
>>
>>   
>>
>> ---
>>
>> Scott Neugroschl | XYPRO Technology Corporation
>>
>> 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805
>> 583-2874|Fax 805 583-0124 |
> Morning.
>
> Yeah I got those too. I think like everyone else who subscribed to that
> List and has no specific Filters set up :)
>
> I am an Admin for some Mailman Lists myself - there is no way to block
> everything with 100 Percent efficency - except if you disallow
> non-members to send Message to $List.
>
> It always depends on the local Mailing List Policy.
>
> Greetings
> Oliver
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160419/162e293d/attachment.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/20160419/162e293d/attachment.bin>

From openssl-users at dukhovni.org  Wed Apr 20 01:13:12 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 20 Apr 2016 01:13:12 +0000
Subject: [openssl-users] THREAD CLOSED: (was: Spam)
In-Reply-To: <5716D39E.6050001@forthepolls.org>
References: <D358E5B1511A314F8160ADC6F3754987343A490E@XYSVEX02.XYPRO-23.LOCAL>
 <5716C1D0.6000100@oliverniebuhr.de>
 <5716D39E.6050001@forthepolls.org>
Message-ID: <20160420011312.GF26423@mournblade.imrryr.org>

Folks, we're here to discuss using OpenSSL, not email list management.
Junk mail is a a negligible issue for this list.  Discussion of junk
mail causes a lot more distraction that the junk mail itself.

Therefore, unless the list becomes substantially dominated by junk
mail, please keep your thoughts about junk email off this list.

Thanks.

-- 
	Viktor.

From rsalz at akamai.com  Wed Apr 20 02:03:27 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 20 Apr 2016 02:03:27 +0000
Subject: [openssl-users] Spam
In-Reply-To: <5716D39E.6050001@forthepolls.org>
References: <D358E5B1511A314F8160ADC6F3754987343A490E@XYSVEX02.XYPRO-23.LOCAL>
 <5716C1D0.6000100@oliverniebuhr.de> <5716D39E.6050001@forthepolls.org>
Message-ID: <731c7763e63a4085b4291e110dfee4a7@usma1ex-dag1mb1.msg.corp.akamai.com>


> the wider problem case is how non-subscribers are given two-way access to the list that exposes so much subscriber info (name, professional affiliation, email addr, ...) to whomever. i cannot fathom why the list does not make use of aliases so that each subscriber can control what they want to make public via their alias profile.

List membership is not public .  Only members can post to the list.  Not sure what else you think we are doing wrong.

From jvp at forthepolls.org  Wed Apr 20 06:55:53 2016
From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=)
Date: Tue, 19 Apr 2016 23:55:53 -0700
Subject: [openssl-users] Spam and posting controls
In-Reply-To: <731c7763e63a4085b4291e110dfee4a7@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <D358E5B1511A314F8160ADC6F3754987343A490E@XYSVEX02.XYPRO-23.LOCAL>
 <5716C1D0.6000100@oliverniebuhr.de> <5716D39E.6050001@forthepolls.org>
 <731c7763e63a4085b4291e110dfee4a7@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <571727F9.3020307@forthepolls.org>

Mr. Salz:

despite mr dukhovni's assertion that spam is not a problem and that people that 
are concerned about it are a problem, i contend that the seeming laxness of list 
controls is the core problem and spam is just an indicating vector. to wit:

'/List membership is not public/' which may be true until someone busts into the 
list and become privy to all of the personal data of posters. such intrusions 
will continue until someone addresses these breeches for what they are: security 
lapses.

'/Only members can post to the list/' is obviously not true when the same party 
which has prompted this thread posted to the list twice in a short time-frame 
(and this has happened before) from IP's without rDNS, from a bogus 
email/domain, and via an unknown MTA. these glitches can be easily caught in 
postfix when it is set up with a pretty minimalist approach to security.

my comment re aliases goes to the concern that a list that is all about 
HTTP/SMTP security and identity surety is freely dispersing so much personally 
identifiable subscriber information (PII) that is of such a high order of 
sensitivity that it is protected under U.S. Title XIII with parallel Canadian 
codes, even more stringent EU reg's such as 'Directive 95/46/EC' and the 
newly-enacted 'General Data Protection Regulation' ('GDPR'), and some EU Member 
regulations with stronger protections than those embodied in 95/46/EC (such as 
Nederland 'Wet bescherming persoonsgegevens' and UK 'Data Protection Act' 
amongst others).

in reality, openssl has no choice but to eventually comply with GDPR which would 
prohibit what is currently being done. so, it would be best to just get on with 
adapting all openssl systems to meet higher ethical and regulatory standards 
before they are embarrassingly imposed or, much worse, be shown to have operated 
in such a way that system breeches at subscriber firms could be traced back to 
openssl.


Thank you,

Johann v. Preu?en


On 2016.Apr.19 19:03, Salz, Rich wrote:
>> the wider problem case is how non-subscribers are given two-way access to the list that exposes so much subscriber info (name, professional affiliation, email addr, ...) to whomever. i cannot fathom why the list does not make use of aliases so that each subscriber can control what they want to make public via their alias profile.
> List membership is not public .  Only members can post to the list.  Not sure what else you think we are doing wrong.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160419/3484a586/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/20160419/3484a586/attachment-0001.bin>

From james.sqawz at gmail.com  Wed Apr 20 09:53:07 2016
From: james.sqawz at gmail.com (james sqawz)
Date: Wed, 20 Apr 2016 15:23:07 +0530
Subject: [openssl-users] ssl connect failed
In-Reply-To: <CANz_a=rU5rhnEQGm0uG4g1GJNn7-XnZiUWSG7xDk6WdCBowtzA@mail.gmail.com>
References: <CANz_a=rU5rhnEQGm0uG4g1GJNn7-XnZiUWSG7xDk6WdCBowtzA@mail.gmail.com>
Message-ID: <CANz_a=r22Dn4LQ7fMv3YOVXf=ca+GJTAhszC9r6zChc4k2=E7w@mail.gmail.com>

Hi all,

I want to add two extension field in CLIENT HELLO request.

Extension: next protocol  negotiation
Extension:application layer protocol negotiation

For that purpose which API/function of openssl I will call?

Thanks
Pranab


On Mon, Apr 18, 2016 at 6:16 PM, james sqawz <james.sqawz at gmail.com> wrote:

> Hi all,
>
> Thanks for the providing the forum for discussion on TLS/OPENSSL related
> issue.
>
> I am very new to openssl.
>
> Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
> For that purpose I send connect request to the server,but connection is
> getting failed.
>
> Following fields are abscent in my ssl packet.
>
> Extension: server name present
> Extension:application layer protocol negotiation
>
> Apart from that I did not set path of Server Certificate.
>
> Shall these impact my connect request.
> Can somebody help.
>
> Thanks
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160420/af59bc70/attachment.html>

From weber at infotech.de  Wed Apr 20 11:50:41 2016
From: weber at infotech.de (weber at infotech.de)
Date: Wed, 20 Apr 2016 13:50:41 +0200
Subject: [openssl-users] Anyone using cert verification with indirect crls?
Message-ID: <57176D11.9040608@infotech.de>

Dear OpenSSL users,

currently using openssl version 1.0.1d on Win32 and Linux and we're 
about to use
indirect crls. The main intent is to keep the RCAs secrets in a vault.

Since we found no commandline support for this, we wrote a class to 
generate the needed
crls. Verifying a end-entity cert we found some unexpected behavior. The 
put a request to the
opessl-dev list yesterday (subject "[openssl-dev] Possible deficiency 
verifying with indirect crl")
which is currently without response.

Next surprise arose when it came to path validation of the crl issuers 
cert. Firstly the chain
could not be built since the method to access the trusted certs list was 
not in place. So we
copied the method and the pointer to the stack of trusted certs into the 
temporary context
within the function check_crl_path.

Did i miss something or is anyone interested in discussing these 
measures or even successfully
using verification with indirect crls?

BTW: The current version, 1.0.1g, seems to make no difference in 
behavior since the relevant
portions of the code seem to be untouched.

Thanks in advance
--
Christian Weber




From dni.grosu at gmail.com  Wed Apr 20 11:12:37 2016
From: dni.grosu at gmail.com (danigrosu)
Date: Wed, 20 Apr 2016 04:12:37 -0700 (MST)
Subject: [openssl-users] Unable to load/add a dynamic engine
In-Reply-To: <1460881589415-65563.post@n7.nabble.com>
References: <1460881589415-65563.post@n7.nabble.com>
Message-ID: <1461150757721-65618.post@n7.nabble.com>

Sorry for replying to this, but no one working with OpenSSL engines here?

Regards,
Dani Grosu
danigrosu wrote
> Hi. I am using the OpenSSL 1.0.1f and I built a RSA engine using CUDA
> code.
> I want to load this engine dynamically, i.e. when I type 
/
> # openssl engine
/
> , I want
> to see my engine id on the list, but all I see is this:
/
> (rsax) RSAX engine support
> (dynamic) Dynamic engine loading support
/
>  where the rsax is builtin
> 
> I have modified the openssl.cnf file by adding the following lines:
/
> openssl_conf = openssl_def
> [openssl_def]
> engines = engine_section
> 
> [engine_section]
> foo = gpu_section
> 
> [gpu_section]
> dynamic_path =
> /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/librsax_gpu.so
> engine_id = rsax_gpu
> default_algorithms = RSA
> init = 1		
/
> 
> I tried this: 
/
> # openssl speed rsa512 -engine rsax_gpu
/
>  and everything went well.
> 
> Please tell me why I can't load dynamically the engine?





--
View this message in context: http://openssl.6102.n7.nabble.com/Unable-to-load-add-a-dynamic-engine-tp65563p65618.html
Sent from the OpenSSL - User mailing list archive at Nabble.com.

From vincent.bentley at du3.co.uk  Wed Apr 20 20:21:31 2016
From: vincent.bentley at du3.co.uk (Vincent Bentley)
Date: Wed, 20 Apr 2016 21:21:31 +0100
Subject: [openssl-users] Anyone willing or able to rescue the Ubsec engine?
Message-ID: <5717E4CB.6010406@du3.co.uk>

I recently started a small business and I can't afford new enterprise
hardware just yet. However, I do make good use of older enterprise kit
and currently have more than twenty BCM5823 crypto accelerators in use.
I think that there may well be a lot of these cards still in use and
it's going to be a nasty surprise for many when they update OpenSSL and
find the performance has dropped.

I was really upset to hear that support for ubsec has already been
pulled and I wondered if anyone else was willing or able to help keep
support for this device in OpenSSL for two more years, to April 2018? I
realise why the OpenSSL project wanted to drop support for old
accelerators and I am grateful that they kept them in for so long.

I have one spare working BCM5823 and at least one BCM5821 to donate to a
rescue effort if required. I also have one Dell PowerEdge 840 tower
server with the necessary 64-bit PCI-X slots, 64-bit CPU for any
developer volunteering from the UK for this rescue if needed. The PE840
is too heavy to ship outside the UK.

I know SHA-1 is getting old but it is still a mandatory implementation
for DNSSEC. Lots of organisations have legacy tape libraries encrypted
in 3DES. These are just two applications where older enterprise servers
might be found chugging away with a Broadcom accelerator inside.

Rich Salz suggested posting here to see what the response would be. I
suspect that like me, many people that use ubsec don't subscribe to the
openssl mailing lists and won't notice for some time.

The bad news for ubsec users:
https://github.com/openssl/openssl/commit/766579ec893e8028288c7215090a6fa3bd424fa0

-Vince-

From matt at openssl.org  Wed Apr 20 21:34:40 2016
From: matt at openssl.org (Matt Caswell)
Date: Wed, 20 Apr 2016 22:34:40 +0100
Subject: [openssl-users] Anyone willing or able to rescue the Ubsec
 engine?
In-Reply-To: <5717E4CB.6010406@du3.co.uk>
References: <5717E4CB.6010406@du3.co.uk>
Message-ID: <5717F5F0.5080803@openssl.org>



On 20/04/16 21:21, Vincent Bentley wrote:
> I recently started a small business and I can't afford new enterprise
> hardware just yet. However, I do make good use of older enterprise kit
> and currently have more than twenty BCM5823 crypto accelerators in use.
> I think that there may well be a lot of these cards still in use and
> it's going to be a nasty surprise for many when they update OpenSSL and
> find the performance has dropped.
> 
> I was really upset to hear that support for ubsec has already been
> pulled and I wondered if anyone else was willing or able to help keep
> support for this device in OpenSSL for two more years, to April 2018? I
> realise why the OpenSSL project wanted to drop support for old
> accelerators and I am grateful that they kept them in for so long.
> 
> I have one spare working BCM5823 and at least one BCM5821 to donate to a
> rescue effort if required. I also have one Dell PowerEdge 840 tower
> server with the necessary 64-bit PCI-X slots, 64-bit CPU for any
> developer volunteering from the UK for this rescue if needed. The PE840
> is too heavy to ship outside the UK.
> 
> I know SHA-1 is getting old but it is still a mandatory implementation
> for DNSSEC. Lots of organisations have legacy tape libraries encrypted
> in 3DES. These are just two applications where older enterprise servers
> might be found chugging away with a Broadcom accelerator inside.
> 
> Rich Salz suggested posting here to see what the response would be. I
> suspect that like me, many people that use ubsec don't subscribe to the
> openssl mailing lists and won't notice for some time.
> 
> The bad news for ubsec users:
> https://github.com/openssl/openssl/commit/766579ec893e8028288c7215090a6fa3bd424fa0

That's interesting. I did attempt to do some research on who was
actually using this and came up with nothing recent, and no-one spoke up
for the engine when it was proposed that we drop it.

The good news is that support remains within the 1.0.2 version. Since
1.0.2 is a Long Term Support release, this means that a version of
OpenSSL will support ubsec until 31st December 2019.

If you must have it work in 1.1.0 and beyond then there is no reason why
you could not support this engine yourself in an external repo and have
it work with 1.1.0. I wouldn't think it would be that hard to do. Just
extract the code in the state that it was in at the point that the above
commit removed it. You will probably need to do some tweaks to get it to
build with subsequent changes (a number of structures have gone opaque
since then which probably means some adjustments will be needed). I can
give you some pointers with what needs to be done if that is the case.
Then you just need to build it as a .so and drop it into the
OPENSSL_ENGINES directory.

Matt

From vincent.bentley at du3.co.uk  Wed Apr 20 23:08:30 2016
From: vincent.bentley at du3.co.uk (Vincent Bentley)
Date: Thu, 21 Apr 2016 00:08:30 +0100
Subject: [openssl-users] Anyone willing or able to rescue the Ubsec
 engine?
In-Reply-To: <5717F5F0.5080803@openssl.org>
References: <5717E4CB.6010406@du3.co.uk> <5717F5F0.5080803@openssl.org>
Message-ID: <57180BEE.4080803@du3.co.uk>

Thanks Matt,

I am pleased that ubsec is still in 1.0.2 and hopefully those systems
that I am tied to that are currently using 1.0.1 don't leapfrog 1.0.2
into 1.1.0 before I am ready.

I have a couple of busy months ahead but I will try to get a dedicated
Jenkins box built on that spare PE840 with the Broadcom hardware in and
start getting familiar with the code.

-Vince-

On 20/04/16 22:34, Matt Caswell wrote:
> 
> The good news is that support remains within the 1.0.2 version. Since
> 1.0.2 is a Long Term Support release, this means that a version of
> OpenSSL will support ubsec until 31st December 2019.
> 
> If you must have it work in 1.1.0 and beyond then there is no reason why
> you could not support this engine yourself in an external repo and have
> it work with 1.1.0. I wouldn't think it would be that hard to do. Just
> extract the code in the state that it was in at the point that the above
> commit removed it. You will probably need to do some tweaks to get it to
> build with subsequent changes (a number of structures have gone opaque
> since then which probably means some adjustments will be needed). I can
> give you some pointers with what needs to be done if that is the case.
> Then you just need to build it as a .so and drop it into the
> OPENSSL_ENGINES directory.
> 
> Matt
> 

From anthony.chow at al-enterprise.com  Wed Apr 20 22:44:27 2016
From: anthony.chow at al-enterprise.com (CHOW Anthony)
Date: Wed, 20 Apr 2016 22:44:27 +0000
Subject: [openssl-users] FW: Using Ansible to bootstrap a CA env.
Message-ID: <HE1PR08MB04271673DE89DE1ACF32A2E7D66D0@HE1PR08MB0427.eurprd08.prod.outlook.com>


Has anyone uses debops.pki with Ansible and OpenSSL to bootstrap a CA environment?

I have a few question on the location of the file.

Are they anything else for bootstrapping a CA environment?  I need to set something up for the development and test group so they will have a consistent environment to test the software.

Thanks,

Anthony.

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

From alex at samad.com.au  Thu Apr 21 04:44:44 2016
From: alex at samad.com.au (Alex Samad)
Date: Thu, 21 Apr 2016 14:44:44 +1000
Subject: [openssl-users] help with timestamping
In-Reply-To: <5715B440.8000706@wisemo.com>
References: <CAJ+Q1PX6BP7Lok50xZ2kkz5DAYQyOQzd8kbJy=wkcyG7vqUcyQ@mail.gmail.com>
 <5715B440.8000706@wisemo.com>
Message-ID: <CAJ+Q1PWFy8fm4HGa0kjxz-YTW4r+fTUFBE9F2KEbD7oQ+6U6JQ@mail.gmail.com>

Okay thats good. so I am on the right track

thanks

On 19 April 2016 at 14:29, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> On 19/04/2016 05:55, Alex Samad wrote:
>>
>> Hi
>>
>> I have a SHA.sha file
>>
>> /usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H
>> Content-Type:application/timestamp-query --data-binary @-
>> http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr
>>
>> /usr/bin/openssl ts -reply -in SHA.sha.tsr -text  > SHA.sha.ts.txt
>>
>>
>> cat SHA.sha.ts.txt
>> Status info:
>> Status: Granted.
>> Status description: unspecified
>> Failure info: unspecified
>>
>> TST info:
>> Version: 1
>> Policy OID: 2.16.840.1.113733.1.7.23.3
>> Hash Algorithm: sha256
>> Message data:
>>      0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
>> .m.[.......WE.i.
>>      0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
>> z.....U%..W7>\..
>> Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB
>> Time stamp: Apr 19 03:52:25 2016 GMT
>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
>> Ordering: no
>> Nonce: 0x580E59D87F396B25
>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
>> Network/CN=Symantec SHA256 TimeStamping Signer - G1
>> Extensions:
>>
>>
>> But when I go to verify it
>>
>>   openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>> Verification: FAILED
>> 140569777235784:error:2107C080:PKCS7
>> routines:PKCS7_get0_signers:signer certificate not
>> found:pk7_smime.c:476:
>>
>> is this because I didn't provide a cert to sign it with ?
>
> No, it is because it cannot find the certificate that Symantec
> used to sign the response, specifically the certificate with
> Subject name "/C=US/O=Symantec Corporation/OU=Symantec Trust
> Network/CN=Symantec SHA256 TimeStamping Signer - G1".
>
> I am kind of disappointed in how little detail is included in
> the output from ts -reply -text, I expected it to output all
> the fields, similar to what other openssl commands do when
> passed the -text option.
>
> So I guess the next step would be to dump SHA.sha.tsr using
> Peter Gutmann's dumpasn1.c program, something like
>
> openssl base64 -d -in SHA.sha.tsr -out SHA.sha.tsr.bin
> dumpasn1 -v SHA.sha.tsr.bin
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From tim.j.culhane at gmail.com  Thu Apr 21 07:06:56 2016
From: tim.j.culhane at gmail.com (Tim Culhane)
Date: Thu, 21 Apr 2016 08:06:56 +0100
Subject: [openssl-users] missing symbolic links under include directory
Message-ID: <004001d19b9c$644ce720$2ce6b560$@gmail.com>

Hi all,

My company makes calls to functions in the openssl source and thus includes
header files defined in the openssl library.

Typically these header files were gathered together in a simgle place, under
include/openssl by way of symbolic links to the real header file locations.

At present I'm updating the version of openssl our products used from 1.0.1g
to 1.0.2g, the latest stable release.

I noticed that when I unpacked the source code for openssl 1.0.2g that there
were no symbolic links under the include/openssl directory.

These were present in versions of openssl as late as 1.0.1q.

>From looking through the mailing list archive, I believe this was a
deliberate change in how openssl is packaged. Is this correct?

It appears that the configure or config script now needs to be run followed
by make depend in order to regenerate the symbolic links.

My issue is that our products check out the openssl source from a local git
repository and the products build on both linux and sparc.

Therefore, if I commit the latest openssl source code to our git repository
it must already contain the symbolic links required.

If I run config or configure followed by make depend before committing the
source code to git, will I be generating any operating specific files or
code?

In other words, if I do config on sparc followed by make depend and then
commit the source to git, would there be any issues when I later checked out
the
files from git and built them on linux?

Many thanks for any clarification you can provide.

Tim


From thomas.francis.jr at pobox.com  Thu Apr 21 13:00:46 2016
From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.)
Date: Thu, 21 Apr 2016 09:00:46 -0400
Subject: [openssl-users] missing symbolic links under include directory
In-Reply-To: <004001d19b9c$644ce720$2ce6b560$@gmail.com>
References: <004001d19b9c$644ce720$2ce6b560$@gmail.com>
Message-ID: <8A185D46-DD7B-4CF9-B00D-05A53257A388@pobox.com>


> On Apr 21, 2016, at 3:06 AM, Tim Culhane <tim.j.culhane at gmail.com> wrote:
> 
> Hi all,
> 
> My company makes calls to functions in the openssl source and thus includes
> header files defined in the openssl library.
> 
> Typically these header files were gathered together in a simgle place, under
> include/openssl by way of symbolic links to the real header file locations.
> 
> At present I'm updating the version of openssl our products used from 1.0.1g
> to 1.0.2g, the latest stable release.
> 
> I noticed that when I unpacked the source code for openssl 1.0.2g that there
> were no symbolic links under the include/openssl directory.
> 
> These were present in versions of openssl as late as 1.0.1q.
> From looking through the mailing list archive, I believe this was a
> deliberate change in how openssl is packaged. Is this correct?
> 
> It appears that the configure or config script now needs to be run followed
> by make depend in order to regenerate the symbolic links.

You must run the configure script (and possibly make depend) to get the links created properly.  My understanding is the deliberate change was more in the way of correcting archives that were made incorrectly; you?ve always (at least as long as I?ve been using OpenSSL, which has been almost 20 years) had to do this.

It?s worth noting that configuring openssl will remove all of those links before creating them again, too, so as far as the symlinks go, having them around isn?t too bad, it?s just extra work.

> My issue is that our products check out the openssl source from a local git
> repository and the products build on both linux and sparc.
> 
> Therefore, if I commit the latest openssl source code to our git repository
> it must already contain the symbolic links required.

Why?  You should not keep installed headers in source control ? you should use a binary repository (and keep the binaries and headers together) instead.  OR, see below...

> If I run config or configure followed by make depend before committing the
> source code to git, will I be generating any operating specific files or
> code?

Yes.  What?s worse is that if you commit all the files, when you try to configure OpenSSL on the second platform, it?ll tell you that it?s already been configured for the first platform and stop.

> In other words, if I do config on sparc followed by make depend and then
> commit the source to git, would there be any issues when I later checked out
> the
> files from git and built them on linux?

Again, yes, there will be problems.  If you want to build OpenSSL out of your source control on a regular basis, you should store the source files exactly as they exist in the tarball.  Remove those headers from your source control ? you don?t need them in order to build; they?re just wasting space in your source control. :)

This means that each time you pull the code from source control, you configure and build the code as normal (which I assume you?re already doing ? if not, OpenSSL probably isn?t working as it?s supposed to be working).

If you don?t want to build OpenSSL all the time (and unless you maintain your own patches, I strongly recommend against building it all the time), then don?t keep it under source control at all.  Keep it in some kind of binary repository which you update only when you need to upgrade OpenSSL (or add a patch, a new platform, etc).  Then use that for deploying OpenSSL to your build systems as needed (presumably only once per build system).  If you use some kind of system imaging to spin up new VMs for building, then make sure the OpenSSL installation is part of that system, so it gets installed with the new VM, not as part of your build process.  That has the additional benefit of reducing your build times. :)  If you need to have multiple versions of OpenSSL installed, simply configure each version to be installed to a different location (and install them to different locations), and adjust your other builds to look for the version they want in the version-specific location.  That has the additional benefit of making it clear to everyone what version of OpenSSL is used by what build.

TOM

<snip>

From jcardenas at correo.uts.edu.co  Thu Apr 21 16:38:05 2016
From: jcardenas at correo.uts.edu.co (=?iso-8859-1?Q?Juan_Sebasti=E1n_C=E1rdenas_Arenas?=)
Date: Thu, 21 Apr 2016 16:38:05 +0000
Subject: [openssl-users] Problem with OSCP Server Response
In-Reply-To: <BN3PR0601MB1204DB7E5A45C34731E7BEAABF910@BN3PR0601MB1204.namprd06.prod.outlook.com>
References: <BN3PR0601MB1204DB7E5A45C34731E7BEAABF910@BN3PR0601MB1204.namprd06.prod.outlook.com>
Message-ID: <BN3PR0601MB120438C9E11C6038216C5E80BF6E0@BN3PR0601MB1204.namprd06.prod.outlook.com>

Good Morning

My name is Juan Sebastian Cardenas, I'm a Systems engineer from Colombia

I am implementing an internal PKI for the organization where I work using openssl

The idea is to generate certificates and digital signatures to members of the organization so that they can sign documents of the office suite and eliminate the use of paper

I have success in creating the keys and certificates from a ca root and an intermediary, I am using the intermediary to sign certificates of users and the server OCSP

When creating user certificates I am defining the URI of OCSP server so that it can verify the validity of the certificate

And finally I am exporting user certificates to a pkcs12 format (.p12) to install the certificate and key user on the user's computer

After installing the pkcs12 key on user's computer, I can use the programs of the office suite (word, excel, power point, etc..) to sign documents using the installed digital signature, however, only makes the connection to the OCSP server once and then no longer allow any verification or validation.

In reviewing the response from the OCSP server:
Invalid request
Reply Error: malformedRequest (1)

And then in the Office program, I can?t use the digital signature to sign documents anymore, and present the message the selected certificate can not be verified. Check the network connection (as had already been able to connect the first time)

Ask them please guide me regarding this specific error check with the OCSP server response.

Thanks for all your help


Juan Sebastian Cardenas Arenas

Docente TC - Direcci?n de Investigaciones
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160421/3964e9d6/attachment.html>

From leikong at msn.com  Thu Apr 21 20:50:55 2016
From: leikong at msn.com (Lei Kong)
Date: Thu, 21 Apr 2016 13:50:55 -0700
Subject: [openssl-users] OpenSSL in Linux kernel
In-Reply-To: <BLU178-W20BD793DA13B284027A378A86E0@phx.gbl>
References: <BLU178-W20BD793DA13B284027A378A86E0@phx.gbl>
Message-ID: <BLU178-W4869EC33CFE52364193E27A86E0@phx.gbl>

Can SSL library be used in Linux kernel mode?
Thanks.
            
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160421/3f73e7aa/attachment-0001.html>

From rsalz at akamai.com  Thu Apr 21 21:00:07 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 21 Apr 2016 21:00:07 +0000
Subject: [openssl-users] OpenSSL in Linux kernel
In-Reply-To: <BLU178-W4869EC33CFE52364193E27A86E0@phx.gbl>
References: <BLU178-W20BD793DA13B284027A378A86E0@phx.gbl>
 <BLU178-W4869EC33CFE52364193E27A86E0@phx.gbl>
Message-ID: <6b1a470c9b3b4b748c7e31bd8e3d3394@usma1ex-dag1mb1.msg.corp.akamai.com>


> Can?SSL library be used in Linux kernel mode?

The crypto libraries can, and are in some places, in the kernel.

If you want to put the SSL/TLS protocol into the kernel, you will need to do some work, just as writing a BIO type that works in the kernel and perhaps malloc/free routines, probably some other stuff.

That would be cool to see :)??????????? 

From openssl-users at dukhovni.org  Thu Apr 21 21:07:23 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 21 Apr 2016 21:07:23 +0000
Subject: [openssl-users] OpenSSL in Linux kernel
In-Reply-To: <6b1a470c9b3b4b748c7e31bd8e3d3394@usma1ex-dag1mb1.msg.corp.akamai.com>
References: <BLU178-W20BD793DA13B284027A378A86E0@phx.gbl>
 <BLU178-W4869EC33CFE52364193E27A86E0@phx.gbl>
 <6b1a470c9b3b4b748c7e31bd8e3d3394@usma1ex-dag1mb1.msg.corp.akamai.com>
Message-ID: <20160421210723.GS26423@mournblade.imrryr.org>

On Thu, Apr 21, 2016 at 09:00:07PM +0000, Salz, Rich wrote:
> 
> > Can?SSL library be used in Linux kernel mode?
> 
> The crypto libraries can, and are in some places, in the kernel.
> 
> If you want to put the SSL/TLS protocol into the kernel, you will need to do some work, just as writing a BIO type that works in the kernel and perhaps malloc/free routines, probably some other stuff.
> 
> That would be cool to see :)??????????? 

It might not be so simple.  The kernel is preemptable and must not
block.  libssl is not designed with the kernel in mind.

-- 
	Viktor.

From mcepl at cepl.eu  Thu Apr 21 21:13:44 2016
From: mcepl at cepl.eu (=?UTF-8?Q?Mat=C4=9Bj?= Cepl)
Date: Thu, 21 Apr 2016 23:13:44 +0200
Subject: [openssl-users] OpenSSL in Linux kernel
References: <BLU178-W20BD793DA13B284027A378A86E0@phx.gbl>
 <BLU178-W4869EC33CFE52364193E27A86E0@phx.gbl>
Message-ID: <slrnnhigk8.c1v.mcepl@mitmanek.ceplovi.cz>

On 2016-04-21, 20:50 GMT, Lei Kong wrote:
> Can SSL library be used in Linux kernel mode?

A bit of problem is that the OpenSSL?s license is incompatible 
with GPLv2.

Mat?j

-- 
https://matej.ceplovi.cz/blog/, Jabber: mcepl at ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB  25C3 E09F EF25 D964 84AC
 
How many Bavarian Illuminati does it take to screw in a light
bulb?
Three: one to screw it in, and one to confuse the issue.


From c.holper at ades.at  Fri Apr 22 18:22:24 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Fri, 22 Apr 2016 20:22:24 +0200
Subject: [openssl-users] Verify signature without certificate included in it
Message-ID: <571A6BE0.2030606@ades.at>

hi!

I am using openssl-smime for signing outgoing messages and verifying 
incoming.
My question is about verifying.

If the partner signs a message where the certificate is included in the 
signature all is OK.
If he signes only with issuer and serial included in the signature i get 
an error ("signer certificate not found").

If I parse the signature with openssl-asn1parse I can see the content of 
the signature. So I see whats included.

Do not know how to describe it in a better way. Is there a name for 
signatures with/without certificate-information?

How can I get the signature get verifyed if there is no certificate 
included in it?

Thanks for help!
Chris


From alex at samad.com.au  Fri Apr 22 22:54:38 2016
From: alex at samad.com.au (Alex Samad)
Date: Sat, 23 Apr 2016 08:54:38 +1000
Subject: [openssl-users] help with timestamping
In-Reply-To: <5715B440.8000706@wisemo.com>
References: <CAJ+Q1PX6BP7Lok50xZ2kkz5DAYQyOQzd8kbJy=wkcyG7vqUcyQ@mail.gmail.com>
 <5715B440.8000706@wisemo.com>
Message-ID: <CAJ+Q1PWJT3DY-poqSKr=6ytM0SRgZjdpKTc9oKKGnFefee1hxg@mail.gmail.com>

Here is a dump.

I can see the CN - but I could see that before.

There is also a RSA - maybe a signature or maybe is the public key for the cert.

I would expect to see some signed data (sha + symantec cert + time)
and also the public cert ( and maybe the intermediaries..)


    <30 82 03 AB>
  0 939: SEQUENCE {
    <30 03>
  4   3:   SEQUENCE {
    <02 01>
  6   1:     INTEGER 0
       :     }
    <30 82 03 A2>
  9 930:   SEQUENCE {
    <06 09>
 13   9:     OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
       :       (PKCS #7)
    <A0 82 03 93>
 24 915:     [0] {
    <30 82 03 8F>
 28 911:       SEQUENCE {
    <02 01>
 32   1:         INTEGER 3
    <31 0D>
 35  13:         SET {
    <30 0B>
 37  11:           SEQUENCE {
    <06 09>
 39   9:             OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
       :               (NIST Algorithm)
       :             }
       :           }
    <30 82 01 1B>
 50 283:         SEQUENCE {
    <06 0B>
 54  11:           OBJECT IDENTIFIER tSTInfo (1 2 840 113549 1 9 16 1 4)
       :             (S/MIME Content Types)
    <A0 82 01 0A>
 67 266:           [0] {
    <04 82 01 06>
 71 262:             OCTET STRING, encapsulates {
    <30 82 01 02>
 75 258:               SEQUENCE {
    <02 01>
 79   1:                 INTEGER 1
    <06 0B>
 82  11:                 OBJECT IDENTIFIER '2 16 840 1 113733 1 7 23 3'
    <30 31>
 95  49:                 SEQUENCE {
    <30 0D>
 97  13:                   SEQUENCE {
    <06 09>
 99   9:                     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
       :                       (NIST Algorithm)
    <05 00>
110   0:                     NULL
       :                     }
    <04 20>
112  32:                   OCTET STRING
       :                     8C 6D 95 5B E0 CD 8B C9    .m.[....
       :                     DF 8C AB 57 45 C4 69 E6    ...WE.i.
       :                     7A B9 CE CB 14 8F 55 25    z.....U%
       :                     91 2E 57 37 3E 5C B8 D5
       :                   }
    <02 14>
146  20:                 INTEGER
       :                   57 0B 9C 3A 11 CA 31 8E    W..:..1.
       :                   24 78 D3 68 0C 0F EF D9    $x.h....
       :                   23 8E 06 AB                #...
    <18 0F>
168  15:                 GeneralizedTime 19/04/2016 03:52:25 GMT
    <30 03>
185   3:                 SEQUENCE {
    <02 01>
187   1:                   INTEGER 30
       :                   }
    <02 08>
190   8:                 INTEGER 58 0E 59 D8 7F 39 6B 25
    <A0 81 86>
200 134:                 [0] {
    <A4 81 83>
203 131:                   [4] {
    <30 81 80>
206 128:                     SEQUENCE {
    <31 0B>
209  11:                       SET {
    <30 09>
211   9:                         SEQUENCE {
    <06 03>
213   3:                           OBJECT IDENTIFIER countryName (2 5 4 6)
       :                             (X.520 DN component)
    <13 02>
218   2:                           PrintableString 'US'
       :                           }
       :                         }
    <31 1D>
222  29:                       SET {
    <30 1B>
224  27:                         SEQUENCE {
    <06 03>
226   3:                           OBJECT IDENTIFIER organizationName (2 5 4 10)
       :                             (X.520 DN component)
    <13 14>
231  20:                           PrintableString 'Symantec Corporation'
       :                           }
       :                         }
    <31 1F>
253  31:                       SET {
    <30 1D>
255  29:                         SEQUENCE {
    <06 03>
257   3:                           OBJECT IDENTIFIER
       :                             organizationalUnitName (2 5 4 11)
       :                             (X.520 DN component)
    <13 16>
262  22:                           PrintableString 'Symantec Trust Network'
       :                           }
       :                         }
    <31 31>
286  49:                       SET {
    <30 2F>
288  47:                         SEQUENCE {
    <06 03>
290   3:                           OBJECT IDENTIFIER commonName (2 5 4 3)
       :                             (X.520 DN component)
    <13 28>
295  40:                           PrintableString 'Symantec SHA256
TimeStamping Signer - G1'
       :                           }
       :                         }
       :                       }
       :                     }
       :                   }
       :                 }
       :               }
       :             }
       :           }
    <31 82 02 5A>
337 602:         SET {
    <30 82 02 56>
341 598:           SEQUENCE {
    <02 01>
345   1:             INTEGER 1
    <30 81 8B>
348 139:             SEQUENCE {
    <30 77>
351 119:               SEQUENCE {
    <31 0B>
353  11:                 SET {
    <30 09>
355   9:                   SEQUENCE {
    <06 03>
357   3:                     OBJECT IDENTIFIER countryName (2 5 4 6)
       :                       (X.520 DN component)
    <13 02>
362   2:                     PrintableString 'US'
       :                     }
       :                   }
    <31 1D>
366  29:                 SET {
    <30 1B>
368  27:                   SEQUENCE {
    <06 03>
370   3:                     OBJECT IDENTIFIER organizationName (2 5 4 10)
       :                       (X.520 DN component)
    <13 14>
375  20:                     PrintableString 'Symantec Corporation'
       :                     }
       :                   }
    <31 1F>
397  31:                 SET {
    <30 1D>
399  29:                   SEQUENCE {
    <06 03>
401   3:                     OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
       :                       (X.520 DN component)
    <13 16>
406  22:                     PrintableString 'Symantec Trust Network'
       :                     }
       :                   }
    <31 28>
430  40:                 SET {
    <30 26>
432  38:                   SEQUENCE {
    <06 03>
434   3:                     OBJECT IDENTIFIER commonName (2 5 4 3)
       :                       (X.520 DN component)
    <13 1F>
439  31:                     PrintableString 'Symantec SHA256 TimeStamping CA'
       :                     }
       :                   }
       :                 }
    <02 10>
472  16:               INTEGER 54 F3 7D A1 71 67 51 BC 6A 8D 0A D2 74
B2 8B 13
       :               }
    <30 0B>
490  11:             SEQUENCE {
    <06 09>
492   9:               OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
       :                 (NIST Algorithm)
       :               }
    <A0 81 A4>
503 164:             [0] {
    <30 1A>
506  26:               SEQUENCE {
    <06 09>
508   9:                 OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3)
       :                   (PKCS #9)
    <31 0D>
519  13:                 SET {
    <06 0B>
521  11:                   OBJECT IDENTIFIER tSTInfo (1 2 840 113549 1 9 16 1 4)
       :                     (S/MIME Content Types)
       :                   }
       :                 }
    <30 1C>
534  28:               SEQUENCE {
    <06 09>
536   9:                 OBJECT IDENTIFIER signingTime (1 2 840 113549 1 9 5)
       :                   (PKCS #9)
    <31 0F>
547  15:                 SET {
    <17 0D>
549  13:                   UTCTime 19/04/2016 03:52:25 GMT
       :                   }
       :                 }
    <30 2F>
564  47:               SEQUENCE {
    <06 09>
566   9:                 OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
       :                   (PKCS #9)
    <31 22>
577  34:                 SET {
    <04 20>
579  32:                   OCTET STRING
       :                     98 1B CF E1 5D 96 79 D6    ....].y.
       :                     47 53 3E 27 A1 0C 57 4E    GS>'..WN
       :                     62 48 8E 43 F8 B5 17 D4    bH.C....
       :                     1C 8F 9A 86 ED D7 A6 B4
       :                   }
       :                 }
    <30 37>
613  55:               SEQUENCE {
    <06 0B>
615  11:                 OBJECT IDENTIFIER
       :                   signingCertificateV2 (1 2 840 113549 1 9 16 2 47)
       :                   (S/MIME Authenticated Attributes)
    <31 28>
628  40:                 SET {
    <30 26>
630  38:                   SEQUENCE {
    <30 24>
632  36:                     SEQUENCE {
    <30 22>
634  34:                       SEQUENCE {
    <04 20>
636  32:                         OCTET STRING
       :                           82 D5 56 DB DB 5D AD 5F    ..V..]._
       :                           A0 7B B6 07 26 A6 D8 6E    .{..&..n
       :                           73 0B 5B B7 29 88 5B B6    s.[.).[.
       :                           DE 4F F2 75 29 02 2C FC
       :                         }
       :                       }
       :                     }
       :                   }
       :                 }
       :               }
    <30 0B>
670  11:             SEQUENCE {
    <06 09>
672   9:               OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
       :                 (PKCS #1)
       :               }
    <04 82 01 00>
683 256:             OCTET STRING
       :               77 60 BE 64 F1 4C 04 B9    w`.d.L..
       :               4D 64 39 59 DC 53 27 02    Md9Y.S'.
       :               06 1F 0C C7 31 EC 5B A2    ....1.[.
       :               79 FB CA A3 07 DE D3 E6    y.......
       :               88 CE 84 37 4C 20 EF DF    ...7L ..
       :               9B BB D4 0B 6F DC 42 05    ....o.B.
       :               DA 8D 22 EF 24 A8 46 68    ..".$.Fh
       :               79 DA CB B5 A9 CD F6 7E    y......~
       :               D5 B8 D4 DD B4 44 5F 40    .....D_@
       :               0A A2 59 C8 3B 2C 52 6F    ..Y.;,Ro
       :               BE 88 6C D3 A4 F6 3C B1    ..l...<.
       :               52 27 25 E3 E9 6F 4A 2B    R'%..oJ+
       :               C6 C4 CD EA 73 65 6C 04    ....sel.
       :               9A A4 79 4E A4 95 F4 F7    ..yN....
       :               1C C6 2E E8 D3 4B 01 8F    .....K..
       :               F2 0B 80 6C 28 67 3E 10    ...l(g>.
       :               D7 76 1E C5 4E BF 87 37    .v..N..7
       :               CB 99 51 81 74 5C 50 57    ..Q.t\PW
       :               80 3F 5D 3E 84 76 12 0A    .?]>.v..
       :               B0 A3 99 DF E5 3B A4 8F    .....;..
       :               DE 04 50 A8 E6 D0 00 6D    ..P....m
       :               61 21 B1 A9 A9 D6 05 79    a!.....y
       :               0A 00 FA D5 1D A6 D6 F8    ........
       :               6A 22 07 E5 BC 01 C1 E0    j"......
       :               10 09 BD 92 09 B5 B7 29    .......)
       :               8B 6A 4D 28 C4 63 7A 4C    .jM(.czL
       :               8E 7A AF 87 5D BE A4 BD    .z..]...
       :               C1 20 9A D0 82 57 03 21    . ...W.!
       :               F3 E2 6F F5 44 22 F9 27    ..o.D".'
       :               41 9C 66 27 BB 52 39 E2    A.f'.R9.
       :               4B C8 2B 82 58 AC 0E AF    K.+.X...
       :               8D AE A5 C7 A5 1A A3 5E
       :             }
       :           }
       :         }
       :       }
       :     }
       :   }

On 19 April 2016 at 14:29, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> On 19/04/2016 05:55, Alex Samad wrote:
>>
>> Hi
>>
>> I have a SHA.sha file
>>
>> /usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H
>> Content-Type:application/timestamp-query --data-binary @-
>> http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr
>>
>> /usr/bin/openssl ts -reply -in SHA.sha.tsr -text  > SHA.sha.ts.txt
>>
>>
>> cat SHA.sha.ts.txt
>> Status info:
>> Status: Granted.
>> Status description: unspecified
>> Failure info: unspecified
>>
>> TST info:
>> Version: 1
>> Policy OID: 2.16.840.1.113733.1.7.23.3
>> Hash Algorithm: sha256
>> Message data:
>>      0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
>> .m.[.......WE.i.
>>      0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
>> z.....U%..W7>\..
>> Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB
>> Time stamp: Apr 19 03:52:25 2016 GMT
>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
>> Ordering: no
>> Nonce: 0x580E59D87F396B25
>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
>> Network/CN=Symantec SHA256 TimeStamping Signer - G1
>> Extensions:
>>
>>
>> But when I go to verify it
>>
>>   openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>> Verification: FAILED
>> 140569777235784:error:2107C080:PKCS7
>> routines:PKCS7_get0_signers:signer certificate not
>> found:pk7_smime.c:476:
>>
>> is this because I didn't provide a cert to sign it with ?
>
> No, it is because it cannot find the certificate that Symantec
> used to sign the response, specifically the certificate with
> Subject name "/C=US/O=Symantec Corporation/OU=Symantec Trust
> Network/CN=Symantec SHA256 TimeStamping Signer - G1".
>
> I am kind of disappointed in how little detail is included in
> the output from ts -reply -text, I expected it to output all
> the fields, similar to what other openssl commands do when
> passed the -text option.
>
> So I guess the next step would be to dump SHA.sha.tsr using
> Peter Gutmann's dumpasn1.c program, something like
>
> openssl base64 -d -in SHA.sha.tsr -out SHA.sha.tsr.bin
> dumpasn1 -v SHA.sha.tsr.bin
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From nospam001-lists at jankoh.mooo.com  Sat Apr 23 01:57:55 2016
From: nospam001-lists at jankoh.mooo.com (Jan Kohnert)
Date: Sat, 23 Apr 2016 03:57:55 +0200
Subject: [openssl-users] i2d_PKCS7_bio() very slow for large file when
	reading in memory
Message-ID: <5664520.8aEQkn2sHV@kohni>

Hello,

this is my very first post on this list, so thanks for letting me in. :)

I have question regarding i2d_PKCS7_bio() in Version 1.0.1c, 1.0.2g and 
maybe 
newer versions.

The code looks as follows (all error checking and other stuff removed 
for reading purposes):

----------------------------------
// init, keys, certs, stuff...

// read file
BIO *bioCryptedData = NULL;
bioCryptedData = BIO_new_file( dataFile, "r" );

// infile DER to internal format
PKCS7 *cryptData = NULL;
d2i_PKCS7_bio( bioCryptedData, &cryptData );

// decrypt
BIO *bioSignedData = NULL;
bioSignedData = BIO_new( BIO_s_mem() );
PKCS7_decrypt(cryptData, m_PKey, NULL, bioSignedData, NULL);

// sigfile DER to internal format
PKCS7 *signedData = NULL;
d2i_PKCS7_bio( bioSignedData, &signedData );

// verify
BIO *bioClearText = NULL;
bioClearText = BIO_new_file( clearFile, "w" ) );
PKCS7_verify(signedData, NULL, m_VeriStore, NULL, bioClearText, NULL);

// do stuff with the decrypted file, close bio's etc...
----------------------------------

My problem occurs in the second call of d2i_PKCS7_bio() within memory: 
while the entire rest of the code runs in seconds even for larger 
(>60MB; >150MB) files, this single line takes about 10min for a 65MB 
file. Basically I see one difference between the first and the second 
call: the first call reads from a file-BIO, the second from a 
memory-BIO. But could that one difference slow things down *that* much? 
Or am I missing something obvious? I really don't want to save the 
signed file, since I only need the verified one.

Thanks a lot for any suggestions.

Best regards Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160423/bdff2516/attachment-0001.html>

From steve at openssl.org  Sat Apr 23 03:33:09 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 23 Apr 2016 03:33:09 +0000
Subject: [openssl-users] Verify signature without certificate included
 in it
In-Reply-To: <571A6BE0.2030606@ades.at>
References: <571A6BE0.2030606@ades.at>
Message-ID: <20160423033309.GA18744@openssl.org>

On Fri, Apr 22, 2016, c.holper at ades.at wrote:

> hi!
> 
> I am using openssl-smime for signing outgoing messages and verifying
> incoming.
> My question is about verifying.
> 
> If the partner signs a message where the certificate is included in
> the signature all is OK.
> If he signes only with issuer and serial included in the signature i
> get an error ("signer certificate not found").
> 
> If I parse the signature with openssl-asn1parse I can see the
> content of the signature. So I see whats included.
> 
> Do not know how to describe it in a better way. Is there a name for
> signatures with/without certificate-information?
> 
> How can I get the signature get verifyed if there is no certificate
> included in it?
> 

The certificate contains the public key used to verify the signature.
If the certificate isn't included in the message itself it can be supplied
separately either with the API or the command line.

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

From steve at openssl.org  Sat Apr 23 03:39:26 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Sat, 23 Apr 2016 03:39:26 +0000
Subject: [openssl-users] Problem with OSCP Server Response
In-Reply-To: <BN3PR0601MB120438C9E11C6038216C5E80BF6E0@BN3PR0601MB1204.namprd06.prod.outlook.com>
References: <BN3PR0601MB1204DB7E5A45C34731E7BEAABF910@BN3PR0601MB1204.namprd06.prod.outlook.com>
 <BN3PR0601MB120438C9E11C6038216C5E80BF6E0@BN3PR0601MB1204.namprd06.prod.outlook.com>
Message-ID: <20160423033926.GB18744@openssl.org>

On Thu, Apr 21, 2016, Juan Sebasti?n C?rdenas Arenas wrote:

> Good Morning
> 
> My name is Juan Sebastian Cardenas, I'm a Systems engineer from Colombia
> 
> I am implementing an internal PKI for the organization where I work using openssl
> 
> The idea is to generate certificates and digital signatures to members of the organization so that they can sign documents of the office suite and eliminate the use of paper
> 
> I have success in creating the keys and certificates from a ca root and an intermediary, I am using the intermediary to sign certificates of users and the server OCSP
> 
> When creating user certificates I am defining the URI of OCSP server so that it can verify the validity of the certificate
> 
> And finally I am exporting user certificates to a pkcs12 format (.p12) to install the certificate and key user on the user's computer
> 
> After installing the pkcs12 key on user's computer, I can use the programs of the office suite (word, excel, power point, etc..) to sign documents using the installed digital signature, however, only makes the connection to the OCSP server once and then no longer allow any verification or validation.
> 
> In reviewing the response from the OCSP server:
> Invalid request
> Reply Error: malformedRequest (1)
> 
> And then in the Office program, I can?t use the digital signature to sign documents anymore, and present the message the selected certificate can not be verified. Check the network connection (as had already been able to connect the first time)
> 
> Ask them please guide me regarding this specific error check with the OCSP server response.
> 

Are you using the OpenSSL "ocsp" utility as a server? That is only intended
for test and debugging use. For example it is inefficient and can only handle
single requests at one time.

It isn't clear from your message what the cause is. It is possible that the
requests are using GET format which the ocsp utility doesn't support.

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

From rsalz at akamai.com  Sat Apr 23 03:45:47 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 23 Apr 2016 03:45:47 +0000
Subject: [openssl-users] Problem with OSCP Server Response
In-Reply-To: <20160423033926.GB18744@openssl.org>
References: <BN3PR0601MB1204DB7E5A45C34731E7BEAABF910@BN3PR0601MB1204.namprd06.prod.outlook.com>
 <BN3PR0601MB120438C9E11C6038216C5E80BF6E0@BN3PR0601MB1204.namprd06.prod.outlook.com>
 <20160423033926.GB18744@openssl.org>
Message-ID: <b62df7f570bd4a7881afa1c2c78da992@usma1ex-dag1mb1.msg.corp.akamai.com>



> It isn't clear from your message what the cause is. It is possible that the
> requests are using GET format which the ocsp utility doesn't support.

It does support GET in master.

From c.holper at ades.at  Sat Apr 23 16:36:35 2016
From: c.holper at ades.at (c.holper at ades.at)
Date: Sat, 23 Apr 2016 18:36:35 +0200
Subject: [openssl-users] Verify signature without certificate included
	in it
In-Reply-To: <571A6BE0.2030606@ades.at>
References: <571A6BE0.2030606@ades.at>
Message-ID: <571BA493.1000703@ades.at>

Ahh... i see.
-certfile

Thanks!

Chris


On 2016-04-22 20:22, c.holper at ades.at wrote:
> hi!
>
> I am using openssl-smime for signing outgoing messages and verifying 
> incoming.
> My question is about verifying.
>
> If the partner signs a message where the certificate is included in 
> the signature all is OK.
> If he signes only with issuer and serial included in the signature i 
> get an error ("signer certificate not found").
>
> If I parse the signature with openssl-asn1parse I can see the content 
> of the signature. So I see whats included.
>
> Do not know how to describe it in a better way. Is there a name for 
> signatures with/without certificate-information?
>
> How can I get the signature get verifyed if there is no certificate 
> included in it?
>
> Thanks for help!
> Chris
>


From joseph_bossle at baxter.com  Mon Apr 25 12:01:53 2016
From: joseph_bossle at baxter.com (Bossle, Jody)
Date: Mon, 25 Apr 2016 12:01:53 +0000
Subject: [openssl-users] Build for Windows 2012 R2
Message-ID: <C57EBFDA8FCB084992E779F17C82BA0943D71151@DM2PRD9201MB029.026d.mgd.msft.net>

I am attempting to build the OpenSSL dlls for Windows 2012 R2.  I have MS Visual Studio 2015 Enterprise and ActivePerl installed.  During the "nmake -f ms\ntdll.mak" process I get an error message the "windows.h" file cannot be found.  I have several copies of "windows.h" on my computer: 1 each for Windows 7 and Windows 8.1, and 2 for different versions of Window 10.  I'm assuming the Windows 8.1 version would be compatible with Windows 2012 R2, however I am not sure where to put the "windows.h" file so it will be picked up during the build.  Any guidance would be greatly appreciated.

[cid:image001.png at 01D1331E.96FD6780]

Joseph A. Bossle III, "Jody"
Sr. Technical Consultant / Global Information Technology
Baxter International Inc.
One Baxter Parkway / Deerfield, Illinois 60015
T 224.270.3563  /  M 630.650.9413
joseph_bossle at baxter.com<mailto:john_sample at baxter.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160425/a7bc1082/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5416 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160425/a7bc1082/attachment.png>

From Michael.Wojcik at microfocus.com  Mon Apr 25 15:22:40 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Mon, 25 Apr 2016 15:22:40 +0000
Subject: [openssl-users] Build for Windows 2012 R2
In-Reply-To: <C57EBFDA8FCB084992E779F17C82BA0943D71151@DM2PRD9201MB029.026d.mgd.msft.net>
References: <C57EBFDA8FCB084992E779F17C82BA0943D71151@DM2PRD9201MB029.026d.mgd.msft.net>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DCA3D01@Rock-Exchange1.microfocus.com>

[Apologies for top-posting - Outlook doesn't handle HTML email correctly.]

The standard Windows SDK and MSVC headers need to be on the INCLUDE path.

That is, you need to run the build from a shell that has the INCLUDE environment variable set to a list of directories (delimited by semicolons) that includes directories containing the Windows SDK headers, such as windows.h, and the standard C library headers.

The PATH and LIB environment variables also need to be set appropriately

This is part of the normal Windows build environment - it's the equivalent of, say, having the build tools on the path and the system headers installed on a UNIX or Linux system - so it's not explicit in the OpenSSL documentation. It's assumed that you're building OpenSSL in an environment suitable for building other applications on your system.

Visual Studio has shortcuts for "command prompt" windows with INCLUDE, LIB, and PATH set appropriately, in its start-menu entries. It also has command scripts that set up the appropriate environment.

Michael Wojcik
Technology Specialist, Micro Focus


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Bossle, Jody
Sent: Monday, April 25, 2016 08:02
To: openssl-users at openssl.org
Subject: [openssl-users] Build for Windows 2012 R2

I am attempting to build the OpenSSL dlls for Windows 2012 R2.  I have MS Visual Studio 2015 Enterprise and ActivePerl installed.  During the ?nmake -f ms\ntdll.mak? process I get an error message the ?windows.h? file cannot be found.  I have several copies of ?windows.h? on my computer: 1 each for Windows 7 and Windows 8.1, and 2 for different versions of Window 10.  I?m assuming the Windows 8.1 version would be compatible with Windows 2012 R2, however I am not sure where to put the ?windows.h? file so it will be picked up during the build.  Any guidance would be greatly appreciated.

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

From joseph_bossle at baxter.com  Tue Apr 26 02:19:41 2016
From: joseph_bossle at baxter.com (Bossle, Jody)
Date: Tue, 26 Apr 2016 02:19:41 +0000
Subject: [openssl-users] Build for Windows 2012 R2
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015DCA3D01@Rock-Exchange1.microfocus.com>
References: <C57EBFDA8FCB084992E779F17C82BA0943D71151@DM2PRD9201MB029.026d.mgd.msft.net>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA3D01@Rock-Exchange1.microfocus.com>
Message-ID: <C57EBFDA8FCB084992E779F17C82BA0943D724E3@DM2PRD9201MB029.026d.mgd.msft.net>

Michael,

Thanks for the information and I have been able to make progress using the VS2015 x64 command prompts.  Unfortunately, I am running into a new error which is captured in a OpenSSL developer thread (see below), but a solution was never posted.  Any additional ideas?

http://openssl.6102.n7.nabble.com/Hypothesis-to-explain-quot-error-A2088-END-directive-required-at-end-of-file-quot-td42328.html

[cid:image001.png at 01D1331E.96FD6780]

Joseph A. Bossle III, "Jody"
Sr. Technical Consultant / Global Information Technology
Baxter International Inc.
One Baxter Parkway / Deerfield, Illinois 60015
T 224.270.3563  /  M 630.650.9413
joseph_bossle at baxter.com<mailto:john_sample at baxter.com>

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik
Sent: Monday, April 25, 2016 10:23 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Build for Windows 2012 R2

[Apologies for top-posting - Outlook doesn't handle HTML email correctly.]

The standard Windows SDK and MSVC headers need to be on the INCLUDE path.

That is, you need to run the build from a shell that has the INCLUDE environment variable set to a list of directories (delimited by semicolons) that includes directories containing the Windows SDK headers, such as windows.h, and the standard C library headers.

The PATH and LIB environment variables also need to be set appropriately

This is part of the normal Windows build environment - it's the equivalent of, say, having the build tools on the path and the system headers installed on a UNIX or Linux system - so it's not explicit in the OpenSSL documentation. It's assumed that you're building OpenSSL in an environment suitable for building other applications on your system.

Visual Studio has shortcuts for "command prompt" windows with INCLUDE, LIB, and PATH set appropriately, in its start-menu entries. It also has command scripts that set up the appropriate environment.

Michael Wojcik
Technology Specialist, Micro Focus


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Bossle, Jody
Sent: Monday, April 25, 2016 08:02
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: [openssl-users] Build for Windows 2012 R2

I am attempting to build the OpenSSL dlls for Windows 2012 R2.  I have MS Visual Studio 2015 Enterprise and ActivePerl installed.  During the "nmake -f ms\ntdll.mak" process I get an error message the "windows.h" file cannot be found.  I have several copies of "windows.h" on my computer: 1 each for Windows 7 and Windows 8.1, and 2 for different versions of Window 10.  I'm assuming the Windows 8.1 version would be compatible with Windows 2012 R2, however I am not sure where to put the "windows.h" file so it will be picked up during the build.  Any guidance would be greatly appreciated.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/b27b02ac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 5416 bytes
Desc: image001.png
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/b27b02ac/attachment.png>

From openssl-users at dukhovni.org  Tue Apr 26 04:55:54 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Tue, 26 Apr 2016 04:55:54 +0000
Subject: [openssl-users] [Bug] OpenSSL does not send short messages
In-Reply-To: <CAHPaHkruKuGPn=ZD6jcDm6TrfO2hFzkDYRZVuSDV9WdisT2ZvQ@mail.gmail.com>
References: <CAHPaHkruKuGPn=ZD6jcDm6TrfO2hFzkDYRZVuSDV9WdisT2ZvQ@mail.gmail.com>
Message-ID: <20160426045554.GG26423@mournblade.imrryr.org>

[ This question belongs on openssl-users, not openssl-dev.  Please
  reply only to openssl-users. ]

On Tue, Apr 26, 2016 at 05:17:46AM +0200, Alex Hultman wrote:

> SSL_write followed by SSL_shutdown does not actually send the data passed
> to SSL_write if the total data size sent is less than (on my system) 7-8
> bytes.

This does not happen in "openssl s_client".  You're likely doing
something wrong.

In one window I start an openssl server:

    $ cipher=ADH-DES-CBC3-SHA
    $ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or later
    $ openssl s_server -quiet -cipher "$cipher$seclev" -nocert -accept 12345

I another window I start a client:

    $ cipher=ADH-DES-CBC3-SHA
    $ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or later
    echo XXX | openssl s_client -debug -no_ign_eof -cipher "$cipher$seclev" -connect localhost:12345

On the server side I see the expected output:

    XXX

On the client side after lots of handshake messages:

    >>> ??? [length 0005]
	17 03 03 00 24
    write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29))
    0000 - 17 03 03 00 24 c2 19 ea-c6 f1 a8 c7 74 31 50 3d   ....$.......t1P=
    0010 - a1 2f fb f0 d5 4d 2e 85-e0 6a 18 86 27 6a 09 1d   ./...M...j..'j..
    0020 - de 98 4e 69 05 57 0f 4c-93                        ..Ni.W.L.
    DONE
    >>> ??? [length 0005]
	15 03 03 00 24
    write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29))
    0000 - 15 03 03 00 24 d2 94 f8-11 dd 69 81 f7 ab cc 8c   ....$.....i.....
    0010 - c4 13 4c 80 24 d7 50 10-b9 62 74 d7 21 86 16 78   ..L.$.P..bt.!..x
    0020 - b4 83 87 da 5e 2f d9 5d-34                        ....^/.]4
    >>> TLS 1.2Alert [length 0002], warning close_notify
	01 00

The first of these is the "XXX" encrypted to 16 bytes, and padded
with a 20-byte SHA1 MAC (the server and client negotiated TLS 1.2
with Encrypt-then-Mac).  The second is the encrypted shutdown alert.

> Is this known behavior?

No.

-- 
	Viktor.

From alexhultman at gmail.com  Tue Apr 26 05:09:54 2016
From: alexhultman at gmail.com (Alex Hultman)
Date: Tue, 26 Apr 2016 07:09:54 +0200
Subject: [openssl-users] [Bug] OpenSSL does not send short messages
In-Reply-To: <CAHPaHkp43OATGi1QMQt0_gZnKjfKWyhG7XNyi3tGfbNj097s5A@mail.gmail.com>
References: <CAHPaHkruKuGPn=ZD6jcDm6TrfO2hFzkDYRZVuSDV9WdisT2ZvQ@mail.gmail.com>
 <20160426045554.GG26423@mournblade.imrryr.org>
 <CAHPaHkp43OATGi1QMQt0_gZnKjfKWyhG7XNyi3tGfbNj097s5A@mail.gmail.com>
Message-ID: <CAHPaHkoHU4V1VL5wTS6RHB5PVA+NZFZsZmMAUwjddr86Zfubbw@mail.gmail.com>

Yes you are correct. I'm doing things wrong - it seems to be Chrome and
Curl that report "no received data" because it actually does work in
Firefox. Well, thanks for taking the time.

2016-04-26 7:05 GMT+02:00 Alex Hultman <alexhultman at gmail.com>:

> Yes you are correct. I'm doing things wrong - it seems to be Chrome and
> Curl that report "no received data" because it actually does work in
> Firefox. Well, thanks for taking the time.
>
> 2016-04-26 6:55 GMT+02:00 Viktor Dukhovni <openssl-users at dukhovni.org>:
>
>> [ This question belongs on openssl-users, not openssl-dev.  Please
>>   reply only to openssl-users. ]
>>
>> On Tue, Apr 26, 2016 at 05:17:46AM +0200, Alex Hultman wrote:
>>
>> > SSL_write followed by SSL_shutdown does not actually send the data
>> passed
>> > to SSL_write if the total data size sent is less than (on my system) 7-8
>> > bytes.
>>
>> This does not happen in "openssl s_client".  You're likely doing
>> something wrong.
>>
>> In one window I start an openssl server:
>>
>>     $ cipher=ADH-DES-CBC3-SHA
>>     $ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or
>> later
>>     $ openssl s_server -quiet -cipher "$cipher$seclev" -nocert -accept
>> 12345
>>
>> I another window I start a client:
>>
>>     $ cipher=ADH-DES-CBC3-SHA
>>     $ seclev= # Make that seclev=":@SECLEVEL=0" with OpenSSL 1.1.0 or
>> later
>>     echo XXX | openssl s_client -debug -no_ign_eof -cipher
>> "$cipher$seclev" -connect localhost:12345
>>
>> On the server side I see the expected output:
>>
>>     XXX
>>
>> On the client side after lots of handshake messages:
>>
>>     >>> ??? [length 0005]
>>         17 03 03 00 24
>>     write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29))
>>     0000 - 17 03 03 00 24 c2 19 ea-c6 f1 a8 c7 74 31 50 3d
>>  ....$.......t1P=
>>     0010 - a1 2f fb f0 d5 4d 2e 85-e0 6a 18 86 27 6a 09 1d
>>  ./...M...j..'j..
>>     0020 - de 98 4e 69 05 57 0f 4c-93                        ..Ni.W.L.
>>     DONE
>>     >>> ??? [length 0005]
>>         15 03 03 00 24
>>     write to 0x7f7f8bd003d0 [0x7f7f8c80b203] (41 bytes => 41 (0x29))
>>     0000 - 15 03 03 00 24 d2 94 f8-11 dd 69 81 f7 ab cc 8c
>>  ....$.....i.....
>>     0010 - c4 13 4c 80 24 d7 50 10-b9 62 74 d7 21 86 16 78
>>  ..L.$.P..bt.!..x
>>     0020 - b4 83 87 da 5e 2f d9 5d-34                        ....^/.]4
>>     >>> TLS 1.2Alert [length 0002], warning close_notify
>>         01 00
>>
>> The first of these is the "XXX" encrypted to 16 bytes, and padded
>> with a 20-byte SHA1 MAC (the server and client negotiated TLS 1.2
>> with Encrypt-then-Mac).  The second is the encrypted shutdown alert.
>>
>> > Is this known behavior?
>>
>> No.
>>
>> --
>>         Viktor.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/5f883619/attachment-0001.html>

From johannes.rath at swissbit.com  Tue Apr 26 08:08:23 2016
From: johannes.rath at swissbit.com (Johannes Rath)
Date: Tue, 26 Apr 2016 08:08:23 +0000
Subject: [openssl-users] Using engine to create a digest fails
Message-ID: <34D7EB7E6BF0D94EAF0DB6AE94376B5FF96728@SBDEEX2010.sbitdom.lan>


Hi all,

I am trying to create a digest using a key stored on a smart card, but it fails:

jor at jorVirtualUbuntu1404:/mnt/Projects/TestOpenSC$ openssl dgst -engine pkcs11  -sign 45 -keyform engine -passin pass:1234 -out test.sig test.txt
engine "pkcs11" set.
Error setting context
140074800309920:error:260C0065:engine routines:ENGINE_get_pkey_meth:unimplemented public key method:tb_pkmeth.c:127:
140074800309920:error:0609D09C:digital envelope routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164:
jor at jorVirtualUbuntu1404:/mnt/Projects/TestOpenSC$ openssl version  -a
OpenSSL 1.0.1f 6 Jan 2014
built on: Mon Feb 29 18:11:15 UTC 2016
platform: debian-amd64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
OPENSSLDIR: "/usr/lib/ssl"

Any ideas?

Regards

Johannes

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

From Michael.Wojcik at microfocus.com  Tue Apr 26 12:34:10 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 26 Apr 2016 12:34:10 +0000
Subject: [openssl-users] Build for Windows 2012 R2
In-Reply-To: <C57EBFDA8FCB084992E779F17C82BA0943D724E3@DM2PRD9201MB029.026d.mgd.msft.net>
References: <C57EBFDA8FCB084992E779F17C82BA0943D71151@DM2PRD9201MB029.026d.mgd.msft.net>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA3D01@Rock-Exchange1.microfocus.com>
 <C57EBFDA8FCB084992E779F17C82BA0943D724E3@DM2PRD9201MB029.026d.mgd.msft.net>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DCA415F@Rock-Exchange1.microfocus.com>

I don't know why that message wasn't answered, because it's a well-known issue. I would have mentioned it in my previous note but it slipped my mind.

You get that error when you try to use the Microsoft assembler (ml.exe or ml64.exe). For OpenSSL on Windows, you now must use nasm, which is an open-source assembler. You can get it at www.nasm.us<http://www.nasm.us>. Just download it, install it (which I think is just unzipping an archive), and put it in the path.

Michael Wojcik
Technology Specialist, Micro Focus


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Bossle, Jody
Sent: Monday, April 25, 2016 22:20
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Build for Windows 2012 R2

Michael,

Thanks for the information and I have been able to make progress using the VS2015 x64 command prompts.  Unfortunately, I am running into a new error which is captured in a OpenSSL developer thread (see below), but a solution was never posted.  Any additional ideas?

http://openssl.6102.n7.nabble.com/Hypothesis-to-explain-quot-error-A2088-END-directive-required-at-end-of-file-quot-td42328.html



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

From hanno at hboeck.de  Tue Apr 26 13:28:31 2016
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 26 Apr 2016 15:28:31 +0200
Subject: [openssl-users] BIO_read hangs,
	how can I know if the server wants to send data?
Message-ID: <20160426152831.70ff2b24@pc1>

Hi,

I have a problem here using OpenSSL, maybe I have some fundamental
misunderstanding of how the api is supposed to be used.

What I want to do: Send a couple of HTTP requests over one connection
(with HTTP/1.1, keep-alive enabled).
Seems simple enough: I send a HTTP request and then read what the
server sends, then send the next.

However: How do I know when the server has stopped sending?
I have attached a code sample (it's missing lots of error checking in
the initialization phase, but that's just for simplification of the
code and shouldn't matter for now).

The relevant part is here:
	for (i = 0; i < 5; i++) {
		printf("calling BIO_write\n");
		r = BIO_write(bio, request, strlen(request));
		printf("%i bytes written\n", r);
		do {
			printf("calling BIO_read\n");
			r = BIO_read(bio, buf, 1024);
			printf("%i bytes read\n", r);
		} while (r > 0);
	}

Now when I run this code it sends one write and reads a couple of
times. However when it's done BIO_read will block the program execution
and not return until a timeout.

So I need a way to know that there's nothing to read before calling
BIO_read. Searching the docs I thought SSL_pending() might be what I
need. However it always returns zero, no matter if the server has
something to send or not.

Another sidenote: I have set the timeout of the context to 2, but it
still hangs for much longer, so the timeout value doesn't seem to have
any effect.

I also tried a number of other things, including using SSL_read/write,
BIO_puts/gets (I didn't really find any good explanation when to use
which of the three), using a nonblocking bio (but that was totally
confusing) etc.

Any help apprechiated.

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http-test-multiple.c
Type: text/x-c++src
Size: 681 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/a45b616b/attachment.c>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/a45b616b/attachment.sig>

From matt at openssl.org  Tue Apr 26 14:05:34 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 26 Apr 2016 15:05:34 +0100
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <20160426152831.70ff2b24@pc1>
References: <20160426152831.70ff2b24@pc1>
Message-ID: <571F75AE.2000106@openssl.org>

Hi Hanno

On 26/04/16 14:28, Hanno B?ck wrote:
> Hi,
> 
> I have a problem here using OpenSSL, maybe I have some fundamental
> misunderstanding of how the api is supposed to be used.
> 
> What I want to do: Send a couple of HTTP requests over one connection
> (with HTTP/1.1, keep-alive enabled).
> Seems simple enough: I send a HTTP request and then read what the
> server sends, then send the next.
> 
> However: How do I know when the server has stopped sending?
> I have attached a code sample (it's missing lots of error checking in
> the initialization phase, but that's just for simplification of the
> code and shouldn't matter for now).

There are a few ways of doing this:

1) Track it at the application protocol layer. For example read the
"Content-Length" HTTP header and wait until you've received that amount
of data. This is probably the best way. The other ways below only tell
you whether the network *currently* has any data to provide to you - not
whether the server has finished sending.

2) Use non-blocking IO

3) Check the underlying file descriptor to see if is readable at the
moment. So for example you can call BIO_get_fd(), and then call
"select", or "poll" or similar on the file descriptor to see if it
readable. You may need to use SSL_pending()/SSL_has_pending() in
combination with this (see below).


> The relevant part is here:
> 	for (i = 0; i < 5; i++) {
> 		printf("calling BIO_write\n");
> 		r = BIO_write(bio, request, strlen(request));
> 		printf("%i bytes written\n", r);
> 		do {
> 			printf("calling BIO_read\n");
> 			r = BIO_read(bio, buf, 1024);
> 			printf("%i bytes read\n", r);
> 		} while (r > 0);
> 	}
> 
> Now when I run this code it sends one write and reads a couple of
> times. However when it's done BIO_read will block the program execution
> and not return until a timeout.
> 
> So I need a way to know that there's nothing to read before calling
> BIO_read. Searching the docs I thought SSL_pending() might be what I
> need. However it always returns zero, no matter if the server has
> something to send or not.

SSL_pending() only tells you whether OpenSSL has read data from the
network and processed it, but has not yet provided it to you. This might
happen, for example if OpenSSL received a record of application data but
you only read part of it in the last SSL_read call. Compare with
SSL_has_pending() (only in 1.1.0).


> 
> Another sidenote: I have set the timeout of the context to 2, but it
> still hangs for much longer, so the timeout value doesn't seem to have
> any effect.

SSL_CTX_set_timeout() sets the timeout of the *session*. It has nothing
to do with the connection.

Matt


From stm at pdflib.com  Tue Apr 26 14:25:48 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Tue, 26 Apr 2016 16:25:48 +0200
Subject: [openssl-users] How to plug in different digest algorithm
 implementation into the PKCS7 functions?
Message-ID: <4cc37198-8cfc-6fab-353c-2844e62812f6@pdflib.com>

Hi,

I'm trying to plug my own digest algorithm implementation into the PKCS7 
functions for creating a signature (using OpenSSL 1.0.2). The hash 
computation shall be performed on a hardware device.

For that purpose I wanted to supply my own EVP_MD data structure to 
PKCS7_add_signature(). A rough sketch of my code for replacing the 
standard SHA-256 implementation looks like this:

     static const EVP_MD my_digest_impl =
     {
         NID_sha256,
         ...
         /* contains function pointers for my own implementation */
     };

     PKCS7 *p7 = PKCS7_new();

     PKCS7_set_type(p7, NID_pkcs7_signed);

     PKCS7_SIGNER_INFO *si = PKCS7_add_signature(p7, cert, pkey, 
&my_digest_impl);

     PKCS7_content_new(sig_parms->p7, NID_pkcs7_data);

     PKCS7_set_detached(p7, 1);

     BIO *p7bio = PKCS7_dataInit(p7, NULL);
     ...

When I debug through this code, I can see that OpenSSL does not call the 
"init" function pointer of the "my_digest_impl" structure, but it calls 
OpenSSL's standard SHA-256 init function "init256". The stack looks like 
this:

init256() at .../openssl-src/crypto/evp/m_sha1.c:107	
EVP_DigestInit_ex() at .../openssl-src/crypto/evp/digest.c:256	
md_ctrl() at .../openssl-src/crypto/evp/bio_md.c:220	
BIO_ctrl() at .../openssl-src/crypto/bio/bio_lib.c:370	
PKCS7_bio_add_digest() at .../openssl-src/crypto/pkcs7/pk7_doit.c:122	
PKCS7_dataInit() at .../openssl-src/crypto/pkcs7/pk7_doit.c:319	
...

How can I plug in my own digest implementation? Do I need to implement a 
full OpenSSL engine for this purpose?

Thanks

--
Stephan

From Michael.Wojcik at microfocus.com  Tue Apr 26 15:09:23 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 26 Apr 2016 15:09:23 +0000
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <571F75AE.2000106@openssl.org>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Matt Caswell
> Sent: Tuesday, April 26, 2016 10:06
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] BIO_read hangs, how can I know if the server
> wants to send data?
> 
> On 26/04/16 14:28, Hanno B?ck wrote:
> >
> > What I want to do: Send a couple of HTTP requests over one connection
> > (with HTTP/1.1, keep-alive enabled).
> > Seems simple enough: I send a HTTP request and then read what the
> > server sends, then send the next.
> >
> > However: How do I know when the server has stopped sending?
> > I have attached a code sample (it's missing lots of error checking in
> > the initialization phase, but that's just for simplification of the
> > code and shouldn't matter for now).
> 
> There are a few ways of doing this:
> 
> 1) Track it at the application protocol layer. For example read the
> "Content-Length" HTTP header and wait until you've received that amount
> of data. This is probably the best way. The other ways below only tell
> you whether the network *currently* has any data to provide to you - not
> whether the server has finished sending.

A couple of points:

- This problem applies to any TCP-based application, regardless of whether TLS is used. TCP is a full-duplex byte-stream protocol. It does not provide any record-boundary or flow-direction indicators. I would strongly recommend consulting a good TCP communications reference such as Stevens' /UNIX Network Programming/ or Comer's /Internetworking with TCP/IP/.

- You can't rely on the presence of a Content-length header in the server's response. For HTTP/1.1, the ways in which a response can be delimited are:
	- Some request types, such as HEAD, do not allow a message body in the response, regardless of what header lines were present. In this case the response is delimited by the blank line that follows the head.
	- Some response types, notably the 1xx range, do not allow a message body in the response, and are delimited by the blank line at the end of the head.
	- A response can be delimited by terminating the connection.
	- A response can include a message body which is exactly the number of octets specified in the optional Content-length header.
	- A response can be delimited by using a self-delimiting transfer encoding. In practice, this means using the "chunked" transfer-encoding, and indicating the end of the message body with a zero-length chunk. If trailers are allowed, the actual end of the response is the end of the trailers. If the chunked T-E is used, any Content-length header MUST be ignored.
	- A response can be delimited by using a self-delimiting Content-type, such as MIME multipart types, if the client accepts such content.

Thus determining the end of an HTTP message is not trivial. See RFC 2616 for details.

It's even worse for HTTP/2, but then HTTP/2 is worse in many ways.

In practice, interactive HTTP user agents (browsers) use a combination of methods and heuristics, because they have to deal with broken servers, broken code running under servers, broken intermediary nodes (gateways and proxies), network problems, etc. Thus they try to apply the rules for determining the end of the response, but they also try to render data as it's received, and after a while they'll time out and decide that a message has ended.

-- 
Michael Wojcik
Technology Specialist, Micro Focus


From hanno at hboeck.de  Tue Apr 26 16:12:43 2016
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 26 Apr 2016 18:12:43 +0200
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
Message-ID: <20160426181243.151efddb@pc1>

Thanks for both your answers, that was very helpful (although it
probably means what I'm trying to do is more complicated than I
thought)...

One more question you might be able to answer:
When I run my test code and connect to google.com I get the following
bytes read for each BIO_read call:
1024
365
289

When I run these against my own server (relatively standard
apache2.4+openssl setup) I get very different numbers:
240
287
2
588
2
41
2
115
2
12
2
110
2
69
2
20
2
6
2
34
2
17
2
12
2
37
2
290
2
6
5

Why is this so much more split up? And to what correspond these
BIO_read chunks on the protocol level? Are these TLS records? TCP
packets? Is there something horribly wrong with my server config
because it splits them up in so many small parts?

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/9b390c73/attachment.sig>

From rsalz at akamai.com  Tue Apr 26 16:19:06 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 26 Apr 2016 16:19:06 +0000
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <20160426181243.151efddb@pc1>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1>
Message-ID: <0431608ac33d48698a8c9c1995d40438@usma1ex-dag1mb1.msg.corp.akamai.com>

One thing you could do is do raw tcp reads and see what the read() call returns, at least for your local server.

It would well be network characteristics.

From matt at openssl.org  Tue Apr 26 16:23:49 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 26 Apr 2016 17:23:49 +0100
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <20160426181243.151efddb@pc1>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1>
Message-ID: <571F9615.6050907@openssl.org>



On 26/04/16 17:12, Hanno B?ck wrote:
> Why is this so much more split up? And to what correspond these
> BIO_read chunks on the protocol level? Are these TLS records? TCP
> packets? Is there something horribly wrong with my server config
> because it splits them up in so many small parts?


Odd. OpenSSL should read and process whole records in one go. As long as
the size that you pass to BIO_read is bigger than the record size you
should get passed back to your code a whole record in one go.

You might want to do a wireshark capture and see what app data record
sizes are being passed back.

Matt




From karl at denninger.net  Tue Apr 26 16:22:13 2016
From: karl at denninger.net (Karl Denninger)
Date: Tue, 26 Apr 2016 11:22:13 -0500
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <20160426181243.151efddb@pc1>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1>
Message-ID: <6000eca4-5e57-80cb-5381-6c85f996023f@denninger.net>

On 4/26/2016 11:12, Hanno B?ck wrote:
> Thanks for both your answers, that was very helpful (although it
> probably means what I'm trying to do is more complicated than I
> thought)...
>
> One more question you might be able to answer:
> When I run my test code and connect to google.com I get the following
> bytes read for each BIO_read call:
> 1024
> 365
> 289
>
> When I run these against my own server (relatively standard
> apache2.4+openssl setup) I get very different numbers:
> 240
> 287
> 2
> 588
> 2
> 41
> 2
> 115
> 2
> 12
> 2
> 110
> 2
> 69
> 2
> 20
> 2
> 6
> 2
> 34
> 2
> 17
> 2
> 12
> 2
> 37
> 2
> 290
> 2
> 6
> 5
>
> Why is this so much more split up? And to what correspond these
> BIO_read chunks on the protocol level? Are these TLS records? TCP
> packets? Is there something horribly wrong with my server config
> because it splits them up in so many small parts?
>
>
>
It's split up due to the vagaries of TCP and how it delivers packets.

In short a local network connection will tend to deliver smaller packets
of data than a distant one, all things being equal -- but they never
are.  All you're guaranteed with TCP is a byte-stream that is coherent,
as was noted in the earlier reply, but you are not guaranteed how many
bytes will come at once.  When select() receives a ready state for
reading or a blocking read returns there could be zero (if there's an
error, exception, or in the case of SSL a possible protocol
renegotiation) or more bytes available to read.

There is nothing wrong with either your server or the other end, it's
just how it works.  Typically the difference is a matter of how things
match up between how many bytes are received and buffered in your
protocol stack before you read them .vs. how fast the other end can
write them and get them to you, which for a wide-area connection usually
involves a lot of routers in the middle.  With TCP there are additional
confounding factors, since the protocol itself implements window control
(size of outstanding transmissions that are allowed), sACK can come into
play, latency of the circuit and routing points in the middle get
involved, etc.  For wide-area connections (think Internet) slow-start
congestion control (which helps avoid a fast server blasting data at a
rate that could otherwise cause a buffer overflow somewhere in the
middle, thus requiring a retransmit) also plays a part.

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

From rainer.jung at kippdata.de  Tue Apr 26 16:31:31 2016
From: rainer.jung at kippdata.de (Rainer Jung)
Date: Tue, 26 Apr 2016 18:31:31 +0200
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <20160426181243.151efddb@pc1>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1>
Message-ID: <571F97E3.7000808@kippdata.de>

Am 26.04.2016 um 18:12 schrieb Hanno B?ck:
> Thanks for both your answers, that was very helpful (although it
> probably means what I'm trying to do is more complicated than I
> thought)...
>
> One more question you might be able to answer:
> When I run my test code and connect to google.com I get the following
> bytes read for each BIO_read call:
> 1024
> 365
> 289
>
> When I run these against my own server (relatively standard
> apache2.4+openssl setup) I get very different numbers:
> 240
> 287
> 2
> 588
> 2
> 41
> 2
> 115
> 2
> 12
> 2
> 110
> 2
> 69
> 2
> 20
> 2
> 6
> 2
> 34
> 2
> 17
> 2
> 12
> 2
> 37
> 2
> 290
> 2
> 6
> 5
>
> Why is this so much more split up? And to what correspond these
> BIO_read chunks on the protocol level? Are these TLS records? TCP
> packets? Is there something horribly wrong with my server config
> because it splits them up in so many small parts?

The second pattern looks like "Transfer-Encoding: chunked". In this 
mode, a response is sent in chunks and each chunk is preceded by a hex 
number telling how big the next chunk is. The last chunk is followed by 
a "0" indicating no more chunks are expected. So the "2" is the size of 
the chunk size (two hex digits), next comes the chunk itself.

That sort of encoding is typically used for dynamic content, when the 
final size of the response is not known in advance to avoid needing to 
buffer the whole response before sending it. It does not use a 
content-length header. Another case might be a transformation during 
response delivery that changes the size in a way that is not easy to 
calculate in advance, like compression.

Since it is a bit of pattern guessing, you should check this by looking 
at the http response headers.

Still one could ask whether it is actually efficient to send the 
response in such small parts, but that's more a question on the sender.

Regards,

Rainer

From matt at openssl.org  Tue Apr 26 16:40:40 2016
From: matt at openssl.org (Matt Caswell)
Date: Tue, 26 Apr 2016 17:40:40 +0100
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <6000eca4-5e57-80cb-5381-6c85f996023f@denninger.net>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1>
 <6000eca4-5e57-80cb-5381-6c85f996023f@denninger.net>
Message-ID: <571F9A08.5020603@openssl.org>



On 26/04/16 17:22, Karl Denninger wrote:
> It's split up due to the vagaries of TCP and how it delivers packets.
> 
> In short a local network connection will tend to deliver smaller packets
> of data than a distant one, all things being equal -- but they never
> are.  All you're guaranteed with TCP is a byte-stream that is coherent,
> as was noted in the earlier reply, but you are not guaranteed how many
> bytes will come at once.  When select() receives a ready state for
> reading or a blocking read returns there could be zero (if there's an
> error, exception, or in the case of SSL a possible protocol
> renegotiation) or more bytes available to read.
> 
> There is nothing wrong with either your server or the other end, it's
> just how it works.  Typically the difference is a matter of how things
> match up between how many bytes are received and buffered in your
> protocol stack before you read them .vs. how fast the other end can
> write them and get them to you, which for a wide-area connection usually
> involves a lot of routers in the middle.  With TCP there are additional
> confounding factors, since the protocol itself implements window control
> (size of outstanding transmissions that are allowed), sACK can come into
> play, latency of the circuit and routing points in the middle get
> involved, etc.  For wide-area connections (think Internet) slow-start
> congestion control (which helps avoid a fast server blasting data at a
> rate that could otherwise cause a buffer overflow somewhere in the
> middle, thus requiring a retransmit) also plays a part.


While that is true I don't think it explains the behaviour. A single TLS
record may get split up into multiple small TCP packets (dependent on
the vagaries of the network as you point out). But OpenSSL won't return
app data to the application until it has read the entire TLS record.

Matt


From hanno at hboeck.de  Tue Apr 26 16:48:08 2016
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 26 Apr 2016 18:48:08 +0200
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <571F97E3.7000808@kippdata.de>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1> <571F97E3.7000808@kippdata.de>
Message-ID: <20160426184808.70f239e9@pc1>

On Tue, 26 Apr 2016 18:31:31 +0200
Rainer Jung <rainer.jung at kippdata.de> wrote:

> The second pattern looks like "Transfer-Encoding: chunked". In this 
> mode, a response is sent in chunks and each chunk is preceded by a
> hex number telling how big the next chunk is. The last chunk is
> followed by a "0" indicating no more chunks are expected. So the "2"
> is the size of the chunk size (two hex digits), next comes the chunk
> itself.
> 
> That sort of encoding is typically used for dynamic content, when the 
> final size of the response is not known in advance to avoid needing
> to buffer the whole response before sending it. It does not use a 
> content-length header. Another case might be a transformation during 
> response delivery that changes the size in a way that is not easy to 
> calculate in advance, like compression.

Thanks, that was it. if I look at the data coming that's exactly how it
looks like. (I still wonder why apache does that - for a 404 error
page - but at least now I know what's going on)

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/b4aab656/attachment.sig>

From Michael.Wojcik at microfocus.com  Tue Apr 26 16:48:00 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 26 Apr 2016 16:48:00 +0000
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <20160426181243.151efddb@pc1>
References: <20160426152831.70ff2b24@pc1>	<571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DCA44A1@Rock-Exchange1.microfocus.com>

> From: Hanno B?ck [mailto:hanno at hboeck.de]
> Sent: Tuesday, April 26, 2016 12:13
> To: Michael Wojcik
> Cc: openssl-users at openssl.org
> Subject: Re: [openssl-users] BIO_read hangs, how can I know if the server
> wants to send data?
> 
> Thanks for both your answers, that was very helpful (although it
> probably means what I'm trying to do is more complicated than I
> thought)...

My suggestion: Use an HTTP library such as libcurl. libcurl already supports integration with OpenSSL. Don't reinvent the HTTP wheel.

> One more question you might be able to answer:
> When I run my test code and connect to google.com I get the following
> bytes read for each BIO_read call:
> 1024
> 365
> 289

So Google is sending three TLS records with application data. That means it's doing the Right Thing: coalescing outbound data into a few messages. Without a wire trace, we can only guess what those three are.

> When I run these against my own server (relatively standard
> apache2.4+openssl setup) I get very different numbers:
> 240
> 287
> 2
> 588
> 2
> 41
> 2

Ugh. Apache is doing the Wrong Thing. It's sending data as it generates it, instead of coalescing. Those two-octet messages are almost certainly the CR LF pairs that terminate lines of the HTTP header.

Why is this wrong? Because sending short TCP packets is inefficient, and can trigger Nagle / Delayed ACK Interaction, which rate-limits the traffic. An application can prevent NDAI by disabling Nagle, but in most cases that's just a sign that the application developer doesn't know how to use TCP properly.

The problem is reduced a bit by using TLS, because the TLS record and encryption overhead make some smaller packets bigger than the MSS, and thus not affected by Nagle. But it's still bad. (And from the application developer's point of view, TLS libraries typically make the problem harder to resolve, due to a lack of a gather-send operation.)
 
> Why is this so much more split up? And to what correspond these
> BIO_read chunks on the protocol level? Are these TLS records? TCP
> packets? Is there something horribly wrong with my server config
> because it splits them up in so many small parts?

I don't know enough about Apache configuration to say. (If Apache routinely does this, though, it's no wonder there are all those benchmarks showing better performance with Nginx. This is Sockets 101 stuff.)

In any case it's not "horribly wrong". It's just costing you bandwidth and latency.

-- 
Michael Wojcik
Technology Specialist, Micro Focus


From Michael.Wojcik at microfocus.com  Tue Apr 26 16:58:48 2016
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 26 Apr 2016 16:58:48 +0000
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
References: <20160426152831.70ff2b24@pc1>	<571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1> 
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088015DCA44F1@Rock-Exchange1.microfocus.com>

> From: Michael Wojcik
> Sent: Tuesday, April 26, 2016 12:39
> To: openssl-users at openssl.org
> Subject: RE: [openssl-users] BIO_read hangs, how can I know if the server
> wants to send data?
> 
> Ugh. Apache is doing the Wrong Thing. It's sending data as it generates it,
> instead of coalescing. Those two-octet messages are almost certainly the CR
> LF pairs that terminate lines of the HTTP header.

Rainer Jung has pointed out this is may well be a chunked message body. I was thinking we were still looking at the HTTP header here.

If it's a chunked message body, that's more understandable, but it's still the wrong thing for Apache to be doing. With TCP you always, always, always want to present all the associated outbound data to the stack at once, to avoid the overhead of sending small packets and Nagle / Delayed ACK. It appears that Apache is writing the chunk header and then the chunk data, which is precisely what it should NOT do.

Though actually that said I don't think this is chunked TE, because the chunk header must be at least 3 octets: at least one hex digit, CR, and LF.

But, again, this is just a performance and efficiency hit - it won't break anything - and if it's on the Apache side, there probably isn't much you can do about it. Maybe it's tunable in the Apache configuration but it seems like an odd thing to make configurable, and even odder to make wrong by default.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



From hanno at hboeck.de  Tue Apr 26 17:47:14 2016
From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=)
Date: Tue, 26 Apr 2016 19:47:14 +0200
Subject: [openssl-users] BIO_read hangs,
 how can I know if the server wants to send data?
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088015DCA44F1@Rock-Exchange1.microfocus.com>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA44F1@Rock-Exchange1.microfocus.com>
Message-ID: <20160426194714.30d71d8f@pc1>

Hello,

On Tue, 26 Apr 2016 16:58:48 +0000
Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:

> But, again, this is just a performance and efficiency hit - it won't
> break anything - and if it's on the Apache side, there probably isn't
> much you can do about it. Maybe it's tunable in the Apache
> configuration but it seems like an odd thing to make configurable,
> and even odder to make wrong by default.

First of all: Before you continue speculating, my server is not doing
anything secret, just connect to it :-) (the one behind hboeck.de)

It's definitely chunking, if I manually connect via openssl s_client I
can see.

The reason is (as Rainer pointed out in a private mail) server side
includes used in the error pages. So it seems Apache's server side
includes implementation causes lots of small chunks.

This essentially means my error pages are serverd horribly inefficient.
However I think that doesn't matter too much, as they should only be
served on errors and errors should be hopefully scarce. This does not
happen with static content. Also with PHP content I still get chunked
encoding, but not these many small chunks.

I think we're getting pretty far away from openssl, so I hope nobody is
annoyed by offtopic discussion (and I think we can close it here), just
as people were speculating and it seemed to have generated quite
some interest I wanted to give a final answer what the cause was.

-- 
Hanno B?ck
https://hboeck.de/

mail/jabber: hanno at hboeck.de
GPG: BBB51E42
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/a699f296/attachment.sig>

From danchik at rebelbase.com  Tue Apr 26 20:20:30 2016
From: danchik at rebelbase.com (Dan S)
Date: Tue, 26 Apr 2016 13:20:30 -0700
Subject: [openssl-users] Loading of CA chain into store from mem for
	verification
Message-ID: <CAF0rXS_J8EOBPsDdorrJUS1cH65VPvx9mP7Rw3+xSRWYNOHsGA@mail.gmail.com>

Hello,


Instead of using SSL_CTX_load_verify_locations with a file, we load the
data from dll resource (multiple certs separated by -----BEGIN
CERTIFICATE----- -----END CERTIFICATE-----):
    ...
    if(pdata = (BYTE *)LockResource( hglobal )) { // BYTE *pdata, hglobal
is initialized with LoadResource
        if(cabio=BIO_new_mem_buf(pdata, -1)) { // create io to mem buffer
            PEM_read_bio_X509(cabio, &cacert, 0, NULL); // load cert to add
to store later
            BIO_free_all(cabio);
        }
    }
    ...
everything seems good so far, data is correct, and cacert is initialized.

Later we add it to the store:
    ...
    if(cacert) {
        X509_STORE *store = SSL_CTX_get_cert_store(ctx);  // ctx created
earlier with SSL_CTX_new with TLSv1_2_method
        if(NULL != store) {
            if(!(res=X509_STORE_add_cert(store, cacert))) {
                // set some error info here and break out to free variables
before exit
                break;
        }
        SSL_CTX_set_cert_store(ctx, store); // Not sure if we were working
on store in ctx or on copy of it
        // if we dont set it back, when cert verified it produces
X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY as if it never had the ca chain
        // if we do set it back, the verification crashes with memory
access in X509_VERIFY_PARAM_inherit (x509_vpm.c)
    }
    ...

Is it that the PEM_read_bio_X509 can only load one cert at a time (why did
it report success on load then)?
Or is it that only one cert at a time can be added to store?
Neither explains the crash (since all calls seemingly succeeded)

Any thoughts please?
Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160426/bc95731d/attachment-0001.html>

From nospam001-lists at jankoh.mooo.com  Tue Apr 26 22:24:53 2016
From: nospam001-lists at jankoh.mooo.com (Jan Kohnert)
Date: Wed, 27 Apr 2016 00:24:53 +0200
Subject: [openssl-users] i2d_PKCS7_bio() very slow for large file when
	reading in memory
In-Reply-To: <5664520.8aEQkn2sHV@kohni>
References: <5664520.8aEQkn2sHV@kohni>
Message-ID: <11905957.HbcaOcXK1q@kohni>

Am Samstag, 23. April 2016, 03:57:55 schrieb Jan Kohnert:
> I have question regarding i2d_PKCS7_bio() in Version 1.0.1c, 
1.0.2g and
> maybe newer versions.

[code skipped]

Nobody any idea? Shall I compose a minimal compilable example 
to make anyone able to dig this a little more? I still don't have a 
clue what makes the function hang so long?

Thanks again!

-- 
MfG Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160427/82ad388e/attachment.html>

From jb-openssl at wisemo.com  Wed Apr 27 02:10:24 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 27 Apr 2016 04:10:24 +0200
Subject: [openssl-users] Using engine to create a digest fails
In-Reply-To: <34D7EB7E6BF0D94EAF0DB6AE94376B5FF96728@SBDEEX2010.sbitdom.lan>
References: <34D7EB7E6BF0D94EAF0DB6AE94376B5FF96728@SBDEEX2010.sbitdom.lan>
Message-ID: <6008ea44-79c4-7e0f-beef-84d1fb93bee1@wisemo.com>

On 26/04/2016 10:08, Johannes Rath wrote:
>
> Hi all,
>
> I am trying to create a digest using a key stored on a smart card, but 
> it fails:
>
> jor at jorVirtualUbuntu1404:/mnt/Projects/TestOpenSC$ openssl dgst 
> -engine pkcs11  -sign 45 -keyform engine -passin pass:1234 -out 
> test.sig test.txt
>
> engine "pkcs11" set.
>
> Error setting context
>
> 140074800309920:error:260C0065:engine 
> routines:ENGINE_get_pkey_meth:unimplemented public key 
> method:tb_pkmeth.c:127:
>
> 140074800309920:error:0609D09C:digital envelope 
> routines:INT_CTX_NEW:unsupported algorithm:pmeth_lib.c:164:
>
> jor at jorVirtualUbuntu1404:/mnt/Projects/TestOpenSC$ openssl version  -a
>
> OpenSSL 1.0.1f 6 Jan 2014
>
> built on: Mon Feb 29 18:11:15 UTC 2016
>
> platform: debian-amd64
>
> options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) blowfish(idx)
>
> compiler: cc -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
> -DDSO_DLFCN -DHAVE_DLFCN_H -m64 -DL_ENDIAN -DTERMIO -g -O2 
> -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-Bsymbolic-functions 
> -Wl,-z,relro -Wa,--noexecstack -Wall -DMD32_REG_T=int 
> -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 
> -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM 
> -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
>
> OPENSSLDIR: "/usr/lib/ssl"
>
> Any ideas?
>
You have not specified the digest algorithm to sign, so the dgst
command defaults to the outdated MD5 algorithm, which your
smartcard probably refuses to use.

I am assuming that this 1.0.1f is from an Ubuntu package with all
the later security fixes merged back in, similar to the 1.0.1e
package in Debian Wheezy.

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  Wed Apr 27 04:53:34 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 27 Apr 2016 06:53:34 +0200
Subject: [openssl-users] help with timestamping
In-Reply-To: <CAJ+Q1PWJT3DY-poqSKr=6ytM0SRgZjdpKTc9oKKGnFefee1hxg@mail.gmail.com>
References: <CAJ+Q1PX6BP7Lok50xZ2kkz5DAYQyOQzd8kbJy=wkcyG7vqUcyQ@mail.gmail.com>
 <5715B440.8000706@wisemo.com>
 <CAJ+Q1PWJT3DY-poqSKr=6ytM0SRgZjdpKTc9oKKGnFefee1hxg@mail.gmail.com>
Message-ID: <0ba87a40-3f78-478e-e96c-6a5c6c20e62c@wisemo.com>

OK, It looks like this signing service is (quite unusually)
not providing the certificate in its message, which is quite
unusual.

All it provides is some information /about/ that certificate,
specifically it provides the following info:

The certificate was issued to C=US, O=Symantec Corporation,
OU=Symantec Trust Network,
CN=Symantec SHA256 TimeStamping Signer - G1

The certificate was issued by C=US, O=Symantec Corporation,
OU=Symantec Trust Network, CN=Symantec SHA256 TimeStamping CA

The certificate serial number (in hex) is
54 F3 7D A1 71 67 51 BC 6A 8D 0A D2 74 B2 8B 13

The certificate fingerprint (SHA-256) is
82 D5 56 DB DB 5D AD 5FA0 7B B6 07 26 A6 D8 6E
73 0B 5B B7 29 88 5B B6DE 4F F2 75 29 02 2C FC

Someone with knowledge of the Symantec/Verisign/Thawte/GeoTrust/
TrustCenter repository web site may be able to use this
information to download the missing certificates, but there
is no information in this file that would allow a computer
to do this.

I wonder if changing some parameter in the timestamp request
would cause the Symantec server to return a more complete
timestamp token.

Or maybe something else is failing.


On 23/04/2016 00:54, Alex Samad wrote:
> Here is a dump.
>
> I can see the CN - but I could see that before.
>
> There is also a RSA - maybe a signature or maybe is the public key for the cert.
>
> I would expect to see some signed data (sha + symantec cert + time)
> and also the public cert ( and maybe the intermediaries..)
>
>
>      <30 82 03 AB>
>    0 939: SEQUENCE {
>      <30 03>
>    4   3:   SEQUENCE {
>      <02 01>
>    6   1:     INTEGER 0
>         :     }
>      <30 82 03 A2>
>    9 930:   SEQUENCE {
>      <06 09>
>   13   9:     OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
>         :       (PKCS #7)
>      <A0 82 03 93>
>   24 915:     [0] {
>      <30 82 03 8F>
>   28 911:       SEQUENCE {
>      <02 01>
>   32   1:         INTEGER 3
>      <31 0D>
>   35  13:         SET {
>      <30 0B>
>   37  11:           SEQUENCE {
>      <06 09>
>   39   9:             OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
>         :               (NIST Algorithm)
>         :             }
>         :           }
>      <30 82 01 1B>
>   50 283:         SEQUENCE {
>      <06 0B>
>   54  11:           OBJECT IDENTIFIER tSTInfo (1 2 840 113549 1 9 16 1 4)
>         :             (S/MIME Content Types)
>      <A0 82 01 0A>
>   67 266:           [0] {
>      <04 82 01 06>
>   71 262:             OCTET STRING, encapsulates {
>      <30 82 01 02>
>   75 258:               SEQUENCE {
>      <02 01>
>   79   1:                 INTEGER 1
>      <06 0B>
>   82  11:                 OBJECT IDENTIFIER '2 16 840 1 113733 1 7 23 3'
>      <30 31>
>   95  49:                 SEQUENCE {
>      <30 0D>
>   97  13:                   SEQUENCE {
>      <06 09>
>   99   9:                     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
>         :                       (NIST Algorithm)
>      <05 00>
> 110   0:                     NULL
>         :                     }
>      <04 20>
> 112  32:                   OCTET STRING
>         :                     8C 6D 95 5B E0 CD 8B C9    .m.[....
>         :                     DF 8C AB 57 45 C4 69 E6    ...WE.i.
>         :                     7A B9 CE CB 14 8F 55 25    z.....U%
>         :                     91 2E 57 37 3E 5C B8 D5
>         :                   }
>      <02 14>
> 146  20:                 INTEGER
>         :                   57 0B 9C 3A 11 CA 31 8E    W..:..1.
>         :                   24 78 D3 68 0C 0F EF D9    $x.h....
>         :                   23 8E 06 AB                #...
>      <18 0F>
> 168  15:                 GeneralizedTime 19/04/2016 03:52:25 GMT
>      <30 03>
> 185   3:                 SEQUENCE {
>      <02 01>
> 187   1:                   INTEGER 30
>         :                   }
>      <02 08>
> 190   8:                 INTEGER 58 0E 59 D8 7F 39 6B 25
>      <A0 81 86>
> 200 134:                 [0] {
>      <A4 81 83>
> 203 131:                   [4] {
>      <30 81 80>
> 206 128:                     SEQUENCE {
>      <31 0B>
> 209  11:                       SET {
>      <30 09>
> 211   9:                         SEQUENCE {
>      <06 03>
> 213   3:                           OBJECT IDENTIFIER countryName (2 5 4 6)
>         :                             (X.520 DN component)
>      <13 02>
> 218   2:                           PrintableString 'US'
>         :                           }
>         :                         }
>      <31 1D>
> 222  29:                       SET {
>      <30 1B>
> 224  27:                         SEQUENCE {
>      <06 03>
> 226   3:                           OBJECT IDENTIFIER organizationName (2 5 4 10)
>         :                             (X.520 DN component)
>      <13 14>
> 231  20:                           PrintableString 'Symantec Corporation'
>         :                           }
>         :                         }
>      <31 1F>
> 253  31:                       SET {
>      <30 1D>
> 255  29:                         SEQUENCE {
>      <06 03>
> 257   3:                           OBJECT IDENTIFIER
>         :                             organizationalUnitName (2 5 4 11)
>         :                             (X.520 DN component)
>      <13 16>
> 262  22:                           PrintableString 'Symantec Trust Network'
>         :                           }
>         :                         }
>      <31 31>
> 286  49:                       SET {
>      <30 2F>
> 288  47:                         SEQUENCE {
>      <06 03>
> 290   3:                           OBJECT IDENTIFIER commonName (2 5 4 3)
>         :                             (X.520 DN component)
>      <13 28>
> 295  40:                           PrintableString 'Symantec SHA256
> TimeStamping Signer - G1'
>         :                           }
>         :                         }
>         :                       }
>         :                     }
>         :                   }
>         :                 }
>         :               }
>         :             }
>         :           }
>      <31 82 02 5A>
> 337 602:         SET {
>      <30 82 02 56>
> 341 598:           SEQUENCE {
>      <02 01>
> 345   1:             INTEGER 1
>      <30 81 8B>
> 348 139:             SEQUENCE {
>      <30 77>
> 351 119:               SEQUENCE {
>      <31 0B>
> 353  11:                 SET {
>      <30 09>
> 355   9:                   SEQUENCE {
>      <06 03>
> 357   3:                     OBJECT IDENTIFIER countryName (2 5 4 6)
>         :                       (X.520 DN component)
>      <13 02>
> 362   2:                     PrintableString 'US'
>         :                     }
>         :                   }
>      <31 1D>
> 366  29:                 SET {
>      <30 1B>
> 368  27:                   SEQUENCE {
>      <06 03>
> 370   3:                     OBJECT IDENTIFIER organizationName (2 5 4 10)
>         :                       (X.520 DN component)
>      <13 14>
> 375  20:                     PrintableString 'Symantec Corporation'
>         :                     }
>         :                   }
>      <31 1F>
> 397  31:                 SET {
>      <30 1D>
> 399  29:                   SEQUENCE {
>      <06 03>
> 401   3:                     OBJECT IDENTIFIER organizationalUnitName (2 5 4 11)
>         :                       (X.520 DN component)
>      <13 16>
> 406  22:                     PrintableString 'Symantec Trust Network'
>         :                     }
>         :                   }
>      <31 28>
> 430  40:                 SET {
>      <30 26>
> 432  38:                   SEQUENCE {
>      <06 03>
> 434   3:                     OBJECT IDENTIFIER commonName (2 5 4 3)
>         :                       (X.520 DN component)
>      <13 1F>
> 439  31:                     PrintableString 'Symantec SHA256 TimeStamping CA'
>         :                     }
>         :                   }
>         :                 }
>      <02 10>
> 472  16:               INTEGER 54 F3 7D A1 71 67 51 BC 6A 8D 0A D2 74
> B2 8B 13
>         :               }
>      <30 0B>
> 490  11:             SEQUENCE {
>      <06 09>
> 492   9:               OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
>         :                 (NIST Algorithm)
>         :               }
>      <A0 81 A4>
> 503 164:             [0] {
>      <30 1A>
> 506  26:               SEQUENCE {
>      <06 09>
> 508   9:                 OBJECT IDENTIFIER contentType (1 2 840 113549 1 9 3)
>         :                   (PKCS #9)
>      <31 0D>
> 519  13:                 SET {
>      <06 0B>
> 521  11:                   OBJECT IDENTIFIER tSTInfo (1 2 840 113549 1 9 16 1 4)
>         :                     (S/MIME Content Types)
>         :                   }
>         :                 }
>      <30 1C>
> 534  28:               SEQUENCE {
>      <06 09>
> 536   9:                 OBJECT IDENTIFIER signingTime (1 2 840 113549 1 9 5)
>         :                   (PKCS #9)
>      <31 0F>
> 547  15:                 SET {
>      <17 0D>
> 549  13:                   UTCTime 19/04/2016 03:52:25 GMT
>         :                   }
>         :                 }
>      <30 2F>
> 564  47:               SEQUENCE {
>      <06 09>
> 566   9:                 OBJECT IDENTIFIER messageDigest (1 2 840 113549 1 9 4)
>         :                   (PKCS #9)
>      <31 22>
> 577  34:                 SET {
>      <04 20>
> 579  32:                   OCTET STRING
>         :                     98 1B CF E1 5D 96 79 D6    ....].y.
>         :                     47 53 3E 27 A1 0C 57 4E    GS>'..WN
>         :                     62 48 8E 43 F8 B5 17 D4    bH.C....
>         :                     1C 8F 9A 86 ED D7 A6 B4
>         :                   }
>         :                 }
>      <30 37>
> 613  55:               SEQUENCE {
>      <06 0B>
> 615  11:                 OBJECT IDENTIFIER
>         :                   signingCertificateV2 (1 2 840 113549 1 9 16 2 47)
>         :                   (S/MIME Authenticated Attributes)
>      <31 28>
> 628  40:                 SET {
>      <30 26>
> 630  38:                   SEQUENCE {
>      <30 24>
> 632  36:                     SEQUENCE {
>      <30 22>
> 634  34:                       SEQUENCE {
>      <04 20>
> 636  32:                         OCTET STRING
>         :                           82 D5 56 DB DB 5D AD 5F    ..V..]._
>         :                           A0 7B B6 07 26 A6 D8 6E    .{..&..n
>         :                           73 0B 5B B7 29 88 5B B6    s.[.).[.
>         :                           DE 4F F2 75 29 02 2C FC
>         :                         }
>         :                       }
>         :                     }
>         :                   }
>         :                 }
>         :               }
>      <30 0B>
> 670  11:             SEQUENCE {
>      <06 09>
> 672   9:               OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
>         :                 (PKCS #1)
>         :               }
>      <04 82 01 00>
> 683 256:             OCTET STRING
>         :               77 60 BE 64 F1 4C 04 B9    w`.d.L..
>         :               4D 64 39 59 DC 53 27 02    Md9Y.S'.
>         :               06 1F 0C C7 31 EC 5B A2    ....1.[.
>         :               79 FB CA A3 07 DE D3 E6    y.......
>         :               88 CE 84 37 4C 20 EF DF    ...7L ..
>         :               9B BB D4 0B 6F DC 42 05    ....o.B.
>         :               DA 8D 22 EF 24 A8 46 68    ..".$.Fh
>         :               79 DA CB B5 A9 CD F6 7E    y......~
>         :               D5 B8 D4 DD B4 44 5F 40    .....D_@
>         :               0A A2 59 C8 3B 2C 52 6F    ..Y.;,Ro
>         :               BE 88 6C D3 A4 F6 3C B1    ..l...<.
>         :               52 27 25 E3 E9 6F 4A 2B    R'%..oJ+
>         :               C6 C4 CD EA 73 65 6C 04    ....sel.
>         :               9A A4 79 4E A4 95 F4 F7    ..yN....
>         :               1C C6 2E E8 D3 4B 01 8F    .....K..
>         :               F2 0B 80 6C 28 67 3E 10    ...l(g>.
>         :               D7 76 1E C5 4E BF 87 37    .v..N..7
>         :               CB 99 51 81 74 5C 50 57    ..Q.t\PW
>         :               80 3F 5D 3E 84 76 12 0A    .?]>.v..
>         :               B0 A3 99 DF E5 3B A4 8F    .....;..
>         :               DE 04 50 A8 E6 D0 00 6D    ..P....m
>         :               61 21 B1 A9 A9 D6 05 79    a!.....y
>         :               0A 00 FA D5 1D A6 D6 F8    ........
>         :               6A 22 07 E5 BC 01 C1 E0    j"......
>         :               10 09 BD 92 09 B5 B7 29    .......)
>         :               8B 6A 4D 28 C4 63 7A 4C    .jM(.czL
>         :               8E 7A AF 87 5D BE A4 BD    .z..]...
>         :               C1 20 9A D0 82 57 03 21    . ...W.!
>         :               F3 E2 6F F5 44 22 F9 27    ..o.D".'
>         :               41 9C 66 27 BB 52 39 E2    A.f'.R9.
>         :               4B C8 2B 82 58 AC 0E AF    K.+.X...
>         :               8D AE A5 C7 A5 1A A3 5E
>         :             }
>         :           }
>         :         }
>         :       }
>         :     }
>         :   }
>
> On 19 April 2016 at 14:29, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> On 19/04/2016 05:55, Alex Samad wrote:
>>> Hi
>>>
>>> I have a SHA.sha file
>>>
>>> /usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H
>>> Content-Type:application/timestamp-query --data-binary @-
>>> http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr
>>>
>>> /usr/bin/openssl ts -reply -in SHA.sha.tsr -text  > SHA.sha.ts.txt
>>>
>>>
>>> cat SHA.sha.ts.txt
>>> Status info:
>>> Status: Granted.
>>> Status description: unspecified
>>> Failure info: unspecified
>>>
>>> TST info:
>>> Version: 1
>>> Policy OID: 2.16.840.1.113733.1.7.23.3
>>> Hash Algorithm: sha256
>>> Message data:
>>>       0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
>>> .m.[.......WE.i.
>>>       0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
>>> z.....U%..W7>\..
>>> Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB
>>> Time stamp: Apr 19 03:52:25 2016 GMT
>>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
>>> Ordering: no
>>> Nonce: 0x580E59D87F396B25
>>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1
>>> Extensions:
>>>
>>>
>>> But when I go to verify it
>>>
>>>    openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>>> Verification: FAILED
>>> 140569777235784:error:2107C080:PKCS7
>>> routines:PKCS7_get0_signers:signer certificate not
>>> found:pk7_smime.c:476:
>>>
>>> is this because I didn't provide a cert to sign it with ?
>> No, it is because it cannot find the certificate that Symantec
>> used to sign the response, specifically the certificate with
>> Subject name "/C=US/O=Symantec Corporation/OU=Symantec Trust
>> Network/CN=Symantec SHA256 TimeStamping Signer - G1".
>>
>> I am kind of disappointed in how little detail is included in
>> the output from ts -reply -text, I expected it to output all
>> the fields, similar to what other openssl commands do when
>> passed the -text option.
>>
>> So I guess the next step would be to dump SHA.sha.tsr using
>> Peter Gutmann's dumpasn1.c program, something like
>>
>> openssl base64 -d -in SHA.sha.tsr -out SHA.sha.tsr.bin
>> dumpasn1 -v SHA.sha.tsr.bin
>>
>>


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  Wed Apr 27 05:08:00 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 27 Apr 2016 07:08:00 +0200
Subject: [openssl-users] Apache inefficient chunking [was: BIO_read
 hangs, how can I know if the server wants to send data?]
In-Reply-To: <20160426194714.30d71d8f@pc1>
References: <20160426152831.70ff2b24@pc1> <571F75AE.2000106@openssl.org>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA4343@Rock-Exchange1.microfocus.com>
 <20160426181243.151efddb@pc1>
 <B550B44BF8AF314BB00C4E2AC1C18088015DCA44F1@Rock-Exchange1.microfocus.com>
 <20160426194714.30d71d8f@pc1>
Message-ID: <51ed9494-c4cb-bc0b-1df3-7c5f0d754549@wisemo.com>

On 26/04/2016 19:47, Hanno B?ck wrote:
> Hello,
>
> On Tue, 26 Apr 2016 16:58:48 +0000
> Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
>
>> But, again, this is just a performance and efficiency hit - it won't
>> break anything - and if it's on the Apache side, there probably isn't
>> much you can do about it. Maybe it's tunable in the Apache
>> configuration but it seems like an odd thing to make configurable,
>> and even odder to make wrong by default.
> First of all: Before you continue speculating, my server is not doing
> anything secret, just connect to it :-) (the one behind hboeck.de)
>
> It's definitely chunking, if I manually connect via openssl s_client I
> can see.
>
> The reason is (as Rainer pointed out in a private mail) server side
> includes used in the error pages. So it seems Apache's server side
> includes implementation causes lots of small chunks.
>
> This essentially means my error pages are serverd horribly inefficient.
> However I think that doesn't matter too much, as they should only be
> served on errors and errors should be hopefully scarce. This does not
> happen with static content. Also with PHP content I still get chunked
> encoding, but not these many small chunks.
>
> I think we're getting pretty far away from openssl, so I hope nobody is
> annoyed by offtopic discussion (and I think we can close it here), just
> as people were speculating and it seemed to have generated quite
> some interest I wanted to give a final answer what the cause was.
>
>

We are not getting that far off topic as this is also the
mailing list for the Apache mod_ssl module, which seems to
be closely involved with this inefficient behavior.

One could of cause speculate if the missing coalescing of
SSL records is a bug in mod_ssl or in some other part of
Apache httpd.

Enjoy

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

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

From jb-openssl at wisemo.com  Wed Apr 27 05:14:21 2016
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Wed, 27 Apr 2016 07:14:21 +0200
Subject: [openssl-users] i2d_PKCS7_bio() very slow for large file when
 reading in memory
In-Reply-To: <5664520.8aEQkn2sHV@kohni>
References: <5664520.8aEQkn2sHV@kohni>
Message-ID: <a215601e-d52f-db98-d4ed-10a06413f261@wisemo.com>

On 23/04/2016 03:57, Jan Kohnert wrote:
>
> Hello,
>
> this is my very first post on this list, so thanks for letting me in. :)
>
> I have question regarding i2d_PKCS7_bio() in Version 1.0.1c, 1.0.2g 
> and maybe
>
> newer versions.
>
> The code looks as follows (all error checking and other stuff removed
>
> for reading purposes):
>
> ----------------------------------
>
> // init, keys, certs, stuff...
>
> // read file
>
> BIO *bioCryptedData = NULL;
>
> bioCryptedData = BIO_new_file( dataFile, "r" );
>
> // infile DER to internal format
>
> PKCS7 *cryptData = NULL;
>
> d2i_PKCS7_bio( bioCryptedData, &cryptData );
>
> // decrypt
>
> BIO *bioSignedData = NULL;
>
> bioSignedData = BIO_new( BIO_s_mem() );
>
> PKCS7_decrypt(cryptData, m_PKey, NULL, bioSignedData, NULL);
>
> // sigfile DER to internal format
>
> PKCS7 *signedData = NULL;
>
> d2i_PKCS7_bio( bioSignedData, &signedData );
>
> // verify
>
> BIO *bioClearText = NULL;
>
> bioClearText = BIO_new_file( clearFile, "w" ) );
>
> PKCS7_verify(signedData, NULL, m_VeriStore, NULL, bioClearText, NULL);
>
> // do stuff with the decrypted file, close bio's etc...
>
> ----------------------------------
>
> My problem occurs in the second call of d2i_PKCS7_bio() within memory:
>
> while the entire rest of the code runs in seconds even for larger
>
> (>60MB; >150MB) files, this single line takes about 10min for a 65MB
>
> file. Basically I see one difference between the first and the second
>
> call: the first call reads from a file-BIO, the second from a
>
> memory-BIO. But could that one difference slow things down *that* much?
>
> Or am I missing something obvious? I really don't want to save the
>
> signed file, since I only need the verified one.
>
>
Just to get a more relevant speed comparison, since the two
calls are parsing very different data, could you try the
test again going via a file, just to double check the
following:

1. Does parsing the same data also take 10 minutes when
   from a file?

2. Is the signed data encoded in some inefficient way (such
   as indefinite or chunked BER), which may slow down the
   BER/DER parser?

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 RESHEFS at il.ibm.com  Wed Apr 27 12:03:58 2016
From: RESHEFS at il.ibm.com (Reshef Sharvit)
Date: Wed, 27 Apr 2016 12:03:58 +0000
Subject: [openssl-users] openssl and nginx 1.8.1
Message-ID: <201604271204.u3RC43Eg016306@d06av02.portsmouth.uk.ibm.com>

An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160427/9319f411/attachment.html>

From rsalz at akamai.com  Wed Apr 27 16:45:31 2016
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 27 Apr 2016 16:45:31 +0000
Subject: [openssl-users] Are you using "TLS proxy certificates"?
Message-ID: <0215c1be002346f1a1496350f4a48b61@usma1ex-dag1mb1.msg.corp.akamai.com>

If so, please let us know.  Replies to me will be summarized for the lists.

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

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

From danny.dejong at student.uva.nl  Thu Apr 28 05:44:53 2016
From: danny.dejong at student.uva.nl (Danny)
Date: Thu, 28 Apr 2016 07:44:53 +0200
Subject: [openssl-users] ECDSA Certificate does not work
Message-ID: <CA+SHYrv65Qjps2V-hbe2mBky9vRxtmp_3O=DG+hiSxys9Je1ew@mail.gmail.com>

Dear OpenSSL users,

I've been trying to get an ECDSA certificate to work with a postfix
installation lately.
, however, it seems that when I try to use the aECDSA protocol with a
client the server gives "no shared cipher" errors.

I had created the certificate like the following:

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out
private/ec-email-server.pem
openssl req -new -x509 -key private/ec-email-server.pem -out
certs/ec-email-server.pem -days 365

Now, when I test the certificate with s_server and s_client like:

openssl s_server -accept 123 -cert /etc/ssl/certs/ec-email-server.pem
-key /etc/ssl/private/ec-email-server.pem
openssl s_client -connect localhost:123

I still get "no shared cipher" errors.
I'm guessing openssl restricts the ciphers to those ciphers that use
ECDSA as authentication.
However, maybe openssl doesn't allow me (for some reason) to use ECDSA.
I'm using Debian and my openssl version is:
OpenSSL 1.0.1k 8 Jan 2015

Does anyone know where the issue lies?
Thank you

From openssl-users at dukhovni.org  Thu Apr 28 06:24:08 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Apr 2016 06:24:08 +0000
Subject: [openssl-users] ECDSA Certificate does not work
In-Reply-To: <CA+SHYrv65Qjps2V-hbe2mBky9vRxtmp_3O=DG+hiSxys9Je1ew@mail.gmail.com>
References: <CA+SHYrv65Qjps2V-hbe2mBky9vRxtmp_3O=DG+hiSxys9Je1ew@mail.gmail.com>
Message-ID: <20160428062407.GG3300@mournblade.imrryr.org>

On Thu, Apr 28, 2016 at 07:44:53AM +0200, Danny wrote:
> Dear OpenSSL users,
> 
> I've been trying to get an ECDSA certificate to work with a postfix
> installation lately.
> , however, it seems that when I try to use the aECDSA protocol with a
> client the server gives "no shared cipher" errors.
> 
> I had created the certificate like the following:
> 
> openssl ecparam -name secp521r1 -genkey -param_enc explicit -out
> private/ec-email-server.pem

TLS does not support explicit EC parameters.  You must use a named
curve by OID.  The "-param_enc explicit" option must not be used.

You must also enable ECDHE in s_server to use ECDSA, since neither
RSA key transport nor DHE are possible.

-- 
	Viktor.

From openssl-users at dukhovni.org  Thu Apr 28 06:31:06 2016
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 28 Apr 2016 06:31:06 +0000
Subject: [openssl-users] ECDSA Certificate does not work
In-Reply-To: <CA+SHYrv65Qjps2V-hbe2mBky9vRxtmp_3O=DG+hiSxys9Je1ew@mail.gmail.com>
References: <CA+SHYrv65Qjps2V-hbe2mBky9vRxtmp_3O=DG+hiSxys9Je1ew@mail.gmail.com>
Message-ID: <20160428063106.GH3300@mournblade.imrryr.org>

On Thu, Apr 28, 2016 at 07:44:53AM +0200, Danny wrote:

> I've been trying to get an ECDSA certificate to work with a Postfix
> installation lately.

See also http://www.postfix.org/postfix-tls.1.html, which does all
the magic to create RSA and/or ECDSA keys for Postfix 3.1 or later.

    # postfix tls new-server-cert -a ecdsa -b secp521r1

-- 
	Viktor.

From wouter.verhelst at fedict.be  Thu Apr 28 12:04:30 2016
From: wouter.verhelst at fedict.be (Wouter Verhelst)
Date: Thu, 28 Apr 2016 14:04:30 +0200
Subject: [openssl-users] X509_ALGOR_get_md?
Message-ID: <5721FC4E.7080201@fedict.be>

Hi,

I note that OpenSSL provides a function X509_ALGOR_set_md() to set the 
message digest algorithm to be used on a signature, but it doesn't seem 
to provide a corresponding X509_ALGOR_get_md() function.

Is this correct, or did I miss something? If I didn't miss anything, 
then how can I figure out which hashing algorithm was used for a given 
X.509 certificate?

Thanks,

-- 
Wouter Verhelst

From stm at pdflib.com  Thu Apr 28 13:08:16 2016
From: stm at pdflib.com (=?UTF-8?Q?Stephan_M=c3=bchlstrasser?=)
Date: Thu, 28 Apr 2016 15:08:16 +0200
Subject: [openssl-users] How to plug in different digest algorithm
 implementation into the PKCS7 functions?
In-Reply-To: <4cc37198-8cfc-6fab-353c-2844e62812f6@pdflib.com>
References: <4cc37198-8cfc-6fab-353c-2844e62812f6@pdflib.com>
Message-ID: <8df0cac8-1f84-5500-f5a7-f3e3348fe890@pdflib.com>

Am 26.04.16 um 16:25 schrieb Stephan M?hlstrasser:
> Hi,
>
> I'm trying to plug my own digest algorithm implementation into the PKCS7
> functions for creating a signature (using OpenSSL 1.0.2). The hash
> computation shall be performed on a hardware device.
>
> For that purpose I wanted to supply my own EVP_MD data structure to
> PKCS7_add_signature(). A rough sketch of my code for replacing the
> standard SHA-256 implementation looks like this:
>
>     static const EVP_MD my_digest_impl =
>     {
>         NID_sha256,
>         ...
>         /* contains function pointers for my own implementation */
>     };
>
>     PKCS7 *p7 = PKCS7_new();
>
>     PKCS7_set_type(p7, NID_pkcs7_signed);
>
>     PKCS7_SIGNER_INFO *si = PKCS7_add_signature(p7, cert, pkey,
> &my_digest_impl);
>
>     PKCS7_content_new(sig_parms->p7, NID_pkcs7_data);
>
>     PKCS7_set_detached(p7, 1);
>
>     BIO *p7bio = PKCS7_dataInit(p7, NULL);
>     ...
>
>...
> How can I plug in my own digest implementation? Do I need to implement a
> full OpenSSL engine for this purpose?

I was able to implement this requirement now by calling BIO_set_md() on 
the BIO that is created by PKCS7_dataInit(). The code for replacing the 
digest function looks like this (error checking omitted):

static const EVP_MD my_digest_impl =
{
      NID_sha256,
      ...
      /* contains function pointers for my own implementation */
};

EVP_MD_CTX *ctx;
BIO *p7bio = PKCS7_dataInit(p7, NULL);

BIO_get_md_ctx(p7bio, &ctx)

ctx->flags |= EVP_MD_CTX_FLAG_NO_INIT;

BIO_set_md(sig_parms->p7bio, &my_digest_impl);

ctx->update = my_digest_impl.update;
ctx->md_data = OPENSSL_malloc(my_digest_impl.ctx_size);

/* ... Now the ctx->md_data member is initialized with data specific to 
the hardware device ... */

my_digest_impl.init(ctx);

The use of the EVP_MD_CTX_FLAG_NO_INIT flag is necessary, because 
otherwise the digests init() function would be called from BIO_set_md() 
without the necessary information for initializing the hardware device. 
With the flag being set the data can be assigned to the md_data member 
after the call to BIO_set_md() and then the digest's init() function can 
be called.

I'd appreciate any comments if there's a problem with this approach. So 
far this seems to be working fine.

-- 
Stephan


From openssl at openssl.org  Thu Apr 28 13:20:13 2016
From: openssl at openssl.org (OpenSSL)
Date: Thu, 28 Apr 2016 14:20:13 +0100 (BST)
Subject: [openssl-users] Forthcoming OpenSSL releases
Message-ID: <alpine.LFD.2.20.1604281419530.24508@localhost.localdomain>

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

Forthcoming OpenSSL releases
============================

The OpenSSL project team would like to announce the forthcoming release of
OpenSSL versions 1.0.2h, 1.0.1t.

These releases will be made available on 3rd May 2016 between approximately
1200-1500 UTC.  They will fix several security defects with maximum severity
"high".

Please see the following page for further details of severity levels:
https://www.openssl.org/policies/secpolicy.html

Please also note that, as per our previous announcements, support for 1.0.1
will end on 31st December 2016.

Yours

The OpenSSL Project Team
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJXIgXGAAoJEAEKUEB8TIy9XK0IAI/LuJqMK0oC4MXuNqKJAtGZ
SYiUWCn0GDqsfucgyOX/OdHjMvkyIPW4Vbt8jZ1HzEmW3DRIalstOgE4MnObZe5a
W5ecH1r8cLDTdVMGmSV3u/W1UP6kZScHa5af23emteCmC8zS7s+PDBctEJAPACZm
n4olGIHA0yOes79lOsU+nnPzfSaAtNWSCHV/BRLy/Ia5c7oeR2PWnGOvY8oIQllL
UNTkNr3qx9n06zjBtHh4dF+bW78eAwLUlY0wUcb2kYRAVeJfXCrJr8nvYIULBMlg
pA+WO/GMdoG697qZ5Y6EnNR16X8Hpse5d03LH3EZQ62Gr8Dh3NodWyRMFaIkig0=
=cJ4f
-----END PGP SIGNATURE-----

From danny.dejong at student.uva.nl  Thu Apr 28 14:12:12 2016
From: danny.dejong at student.uva.nl (Danny)
Date: Thu, 28 Apr 2016 16:12:12 +0200
Subject: [openssl-users] ECDSA Certificate does not work
In-Reply-To: <20160428063106.GH3300@mournblade.imrryr.org>
References: <CA+SHYrv65Qjps2V-hbe2mBky9vRxtmp_3O=DG+hiSxys9Je1ew@mail.gmail.com>
 <20160428063106.GH3300@mournblade.imrryr.org>
Message-ID: <CA+SHYrtb9L8yMgy56dVyDa9rh3nN82aOaB_Yav6FjCUyxiWOaw@mail.gmail.com>

AH!
Thanks man.
My postfix server seems to work now with ciphers-sets using ECDSA!
I just wish openssl would have complained about it (or had given me a
warning or something).

Anyway, I'm using Postfix 2.11, but either way, I like it when I can
do things manually. :P

Thanks.

On 4/28/16, Viktor Dukhovni <openssl-users at dukhovni.org> wrote:
> On Thu, Apr 28, 2016 at 07:44:53AM +0200, Danny wrote:
>
>> I've been trying to get an ECDSA certificate to work with a Postfix
>> installation lately.
>
> See also http://www.postfix.org/postfix-tls.1.html, which does all
> the magic to create RSA and/or ECDSA keys for Postfix 3.1 or later.
>
>     # postfix tls new-server-cert -a ecdsa -b secp521r1
>
> --
> 	Viktor.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>

From alex at samad.com.au  Fri Apr 29 01:25:43 2016
From: alex at samad.com.au (Alex Samad)
Date: Fri, 29 Apr 2016 11:25:43 +1000
Subject: [openssl-users] help with timestamping
In-Reply-To: <0ba87a40-3f78-478e-e96c-6a5c6c20e62c@wisemo.com>
References: <CAJ+Q1PX6BP7Lok50xZ2kkz5DAYQyOQzd8kbJy=wkcyG7vqUcyQ@mail.gmail.com>
 <5715B440.8000706@wisemo.com>
 <CAJ+Q1PWJT3DY-poqSKr=6ytM0SRgZjdpKTc9oKKGnFefee1hxg@mail.gmail.com>
 <0ba87a40-3f78-478e-e96c-6a5c6c20e62c@wisemo.com>
Message-ID: <CAJ+Q1PVkJUwQY42etZUL=Hg9zDegCvm2NbtKMB1G_ho=zGSPkw@mail.gmail.com>

Okay I have the cert from sym

-----BEGIN CERTIFICATE-----
MIIFSzCCBDOgAwIBAgIQVPN9oXFnUbxqjQrSdLKLEzANBgkqhkiG9w0BAQsFADB3
MQswCQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAd
BgNVBAsTFlN5bWFudGVjIFRydXN0IE5ldHdvcmsxKDAmBgNVBAMTH1N5bWFudGVj
IFNIQTI1NiBUaW1lU3RhbXBpbmcgQ0EwHhcNMTYwMTEyMDAwMDAwWhcNMjcwNDEx
MjM1OTU5WjCBgDELMAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBv
cmF0aW9uMR8wHQYDVQQLExZTeW1hbnRlYyBUcnVzdCBOZXR3b3JrMTEwLwYDVQQD
EyhTeW1hbnRlYyBTSEEyNTYgVGltZVN0YW1waW5nIFNpZ25lciAtIEcxMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAn/vfjx+nz54+GsvraK3PJxzugVWp
hwhY5YFNCRTg7dDz1A8/IbYeDjTU8WgKb32Pidny6qfYJTikjDbK7ijPM/h1Pdid
z5LdVuP2sHlUZrVFgkNE0mqxqxeiw+XvAOon8yeIDoc89m68qez2uy5qdwYivfq4
f8MkB/c/u0yw/0PLk8oSqpUkAJCyKzai0t3Ss9GZMt3P9MxzFkmDfyTr7XhG0+5f
bEJlG2eN8CYaDl6HblqPoIJ+bp/NJt69Ye9EXkWLqJTTHAQyof+kp6KqdwHbKt4P
TJI2xmmsXISArSX17TDDaB0X2wpNmjR4WQGbawKFOOIncaIUVDBgkyBIIwIDAQAB
o4IBxzCCAcMwDAYDVR0TAQH/BAIwADBmBgNVHSAEXzBdMFsGC2CGSAGG+EUBBxcD
MEwwIwYIKwYBBQUHAgEWF2h0dHBzOi8vZC5zeW1jYi5jb20vY3BzMCUGCCsGAQUF
BwICMBkaF2h0dHBzOi8vZC5zeW1jYi5jb20vcnBhMEAGA1UdHwQ5MDcwNaAzoDGG
L2h0dHA6Ly90cy1jcmwud3Muc3ltYW50ZWMuY29tL3NoYTI1Ni10c3MtY2EuY3Js
MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMIMA4GA1UdDwEB/wQEAwIHgDB3BggrBgEF
BQcBAQRrMGkwKgYIKwYBBQUHMAGGHmh0dHA6Ly90cy1vY3NwLndzLnN5bWFudGVj
LmNvbTA7BggrBgEFBQcwAoYvaHR0cDovL3RzLWFpYS53cy5zeW1hbnRlYy5jb20v
c2hhMjU2LXRzcy1jYS5jZXIwKAYDVR0RBCEwH6QdMBsxGTAXBgNVBAMTEFRpbWVT
dGFtcC0yMDQ4LTQwHQYDVR0OBBYEFO1rYM87WPg+Msy/pOir6OqiUEJ/MB8GA1Ud
IwQYMBaAFK9j1sqjToVy4Ke8QfMpojh/gHViMA0GCSqGSIb3DQEBCwUAA4IBAQCi
jV5dHe5O0pP9T+X0babwiUVVuwjKqyShFiTJTxfBn/TdAprCR8Cp3IiJd8GGhvHV
SZbz+x6Y1skdNSOImYpi4XWoTXinPewkgBWeaNQ6pMJM3HFslp2OHgwubFIBnlaQ
P6Jeks222kEaJIOheqNf/o07bznRP0FfVhwnDOV8BdhnNojlsMLDBKNaVrgSBI7U
nCRrG2a0vqAa4bXN7ONEpLE855LzWN3f6LFYS3BLzpAAzNyj0dJudRZURALvG1RE
Y+i1cMi5R5pbRcRudpoYsfcQM8gLUfVVjP0hHkGPTj6QXYAByLwkfoZoFBUUNDV0
SbeHUinWll6ioxbUsNN7
-----END CERTIFICATE-----


openssl x509 -in newsym1.cer -noout -subject
subject= /C=US/O=Symantec Corporation/OU=Symantec Trust
Network/CN=Symantec SHA256 TimeStamping Signer - G1


Still getting

 openssl ts -verify -data SHA.sha -in SHA.sha.tsr  -CApath newsym1.cer
Verification: FAILED
139630315571016:error:2107C080:PKCS7
routines:PKCS7_get0_signers:signer certificate not
found:pk7_smime.c:476:





On 27 April 2016 at 14:53, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> OK, It looks like this signing service is (quite unusually)
> not providing the certificate in its message, which is quite
> unusual.
>
> All it provides is some information /about/ that certificate,
> specifically it provides the following info:
>
> The certificate was issued to C=US, O=Symantec Corporation,
> OU=Symantec Trust Network,
> CN=Symantec SHA256 TimeStamping Signer - G1
>
> The certificate was issued by C=US, O=Symantec Corporation,
> OU=Symantec Trust Network, CN=Symantec SHA256 TimeStamping CA
>
> The certificate serial number (in hex) is
> 54 F3 7D A1 71 67 51 BC 6A 8D 0A D2 74 B2 8B 13
>
> The certificate fingerprint (SHA-256) is
> 82 D5 56 DB DB 5D AD 5FA0 7B B6 07 26 A6 D8 6E
> 73 0B 5B B7 29 88 5B B6DE 4F F2 75 29 02 2C FC
>
> Someone with knowledge of the Symantec/Verisign/Thawte/GeoTrust/
> TrustCenter repository web site may be able to use this
> information to download the missing certificates, but there
> is no information in this file that would allow a computer
> to do this.
>
> I wonder if changing some parameter in the timestamp request
> would cause the Symantec server to return a more complete
> timestamp token.
>
> Or maybe something else is failing.
>
>
>
> On 23/04/2016 00:54, Alex Samad wrote:
>>
>> Here is a dump.
>>
>> I can see the CN - but I could see that before.
>>
>> There is also a RSA - maybe a signature or maybe is the public key for the
>> cert.
>>
>> I would expect to see some signed data (sha + symantec cert + time)
>> and also the public cert ( and maybe the intermediaries..)
>>
>>
>>      <30 82 03 AB>
>>    0 939: SEQUENCE {
>>      <30 03>
>>    4   3:   SEQUENCE {
>>      <02 01>
>>    6   1:     INTEGER 0
>>         :     }
>>      <30 82 03 A2>
>>    9 930:   SEQUENCE {
>>      <06 09>
>>   13   9:     OBJECT IDENTIFIER signedData (1 2 840 113549 1 7 2)
>>         :       (PKCS #7)
>>      <A0 82 03 93>
>>   24 915:     [0] {
>>      <30 82 03 8F>
>>   28 911:       SEQUENCE {
>>      <02 01>
>>   32   1:         INTEGER 3
>>      <31 0D>
>>   35  13:         SET {
>>      <30 0B>
>>   37  11:           SEQUENCE {
>>      <06 09>
>>   39   9:             OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
>>         :               (NIST Algorithm)
>>         :             }
>>         :           }
>>      <30 82 01 1B>
>>   50 283:         SEQUENCE {
>>      <06 0B>
>>   54  11:           OBJECT IDENTIFIER tSTInfo (1 2 840 113549 1 9 16 1 4)
>>         :             (S/MIME Content Types)
>>      <A0 82 01 0A>
>>   67 266:           [0] {
>>      <04 82 01 06>
>>   71 262:             OCTET STRING, encapsulates {
>>      <30 82 01 02>
>>   75 258:               SEQUENCE {
>>      <02 01>
>>   79   1:                 INTEGER 1
>>      <06 0B>
>>   82  11:                 OBJECT IDENTIFIER '2 16 840 1 113733 1 7 23 3'
>>      <30 31>
>>   95  49:                 SEQUENCE {
>>      <30 0D>
>>   97  13:                   SEQUENCE {
>>      <06 09>
>>   99   9:                     OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3
>> 4 2 1)
>>         :                       (NIST Algorithm)
>>      <05 00>
>> 110   0:                     NULL
>>         :                     }
>>      <04 20>
>> 112  32:                   OCTET STRING
>>         :                     8C 6D 95 5B E0 CD 8B C9    .m.[....
>>         :                     DF 8C AB 57 45 C4 69 E6    ...WE.i.
>>         :                     7A B9 CE CB 14 8F 55 25    z.....U%
>>         :                     91 2E 57 37 3E 5C B8 D5
>>         :                   }
>>      <02 14>
>> 146  20:                 INTEGER
>>         :                   57 0B 9C 3A 11 CA 31 8E    W..:..1.
>>         :                   24 78 D3 68 0C 0F EF D9    $x.h....
>>         :                   23 8E 06 AB                #...
>>      <18 0F>
>> 168  15:                 GeneralizedTime 19/04/2016 03:52:25 GMT
>>      <30 03>
>> 185   3:                 SEQUENCE {
>>      <02 01>
>> 187   1:                   INTEGER 30
>>         :                   }
>>      <02 08>
>> 190   8:                 INTEGER 58 0E 59 D8 7F 39 6B 25
>>      <A0 81 86>
>> 200 134:                 [0] {
>>      <A4 81 83>
>> 203 131:                   [4] {
>>      <30 81 80>
>> 206 128:                     SEQUENCE {
>>      <31 0B>
>> 209  11:                       SET {
>>      <30 09>
>> 211   9:                         SEQUENCE {
>>      <06 03>
>> 213   3:                           OBJECT IDENTIFIER countryName (2 5 4 6)
>>         :                             (X.520 DN component)
>>      <13 02>
>> 218   2:                           PrintableString 'US'
>>         :                           }
>>         :                         }
>>      <31 1D>
>> 222  29:                       SET {
>>      <30 1B>
>> 224  27:                         SEQUENCE {
>>      <06 03>
>> 226   3:                           OBJECT IDENTIFIER organizationName (2 5
>> 4 10)
>>         :                             (X.520 DN component)
>>      <13 14>
>> 231  20:                           PrintableString 'Symantec Corporation'
>>         :                           }
>>         :                         }
>>      <31 1F>
>> 253  31:                       SET {
>>      <30 1D>
>> 255  29:                         SEQUENCE {
>>      <06 03>
>> 257   3:                           OBJECT IDENTIFIER
>>         :                             organizationalUnitName (2 5 4 11)
>>         :                             (X.520 DN component)
>>      <13 16>
>> 262  22:                           PrintableString 'Symantec Trust
>> Network'
>>         :                           }
>>         :                         }
>>      <31 31>
>> 286  49:                       SET {
>>      <30 2F>
>> 288  47:                         SEQUENCE {
>>      <06 03>
>> 290   3:                           OBJECT IDENTIFIER commonName (2 5 4 3)
>>         :                             (X.520 DN component)
>>      <13 28>
>> 295  40:                           PrintableString 'Symantec SHA256
>> TimeStamping Signer - G1'
>>         :                           }
>>         :                         }
>>         :                       }
>>         :                     }
>>         :                   }
>>         :                 }
>>         :               }
>>         :             }
>>         :           }
>>      <31 82 02 5A>
>> 337 602:         SET {
>>      <30 82 02 56>
>> 341 598:           SEQUENCE {
>>      <02 01>
>> 345   1:             INTEGER 1
>>      <30 81 8B>
>> 348 139:             SEQUENCE {
>>      <30 77>
>> 351 119:               SEQUENCE {
>>      <31 0B>
>> 353  11:                 SET {
>>      <30 09>
>> 355   9:                   SEQUENCE {
>>      <06 03>
>> 357   3:                     OBJECT IDENTIFIER countryName (2 5 4 6)
>>         :                       (X.520 DN component)
>>      <13 02>
>> 362   2:                     PrintableString 'US'
>>         :                     }
>>         :                   }
>>      <31 1D>
>> 366  29:                 SET {
>>      <30 1B>
>> 368  27:                   SEQUENCE {
>>      <06 03>
>> 370   3:                     OBJECT IDENTIFIER organizationName (2 5 4 10)
>>         :                       (X.520 DN component)
>>      <13 14>
>> 375  20:                     PrintableString 'Symantec Corporation'
>>         :                     }
>>         :                   }
>>      <31 1F>
>> 397  31:                 SET {
>>      <30 1D>
>> 399  29:                   SEQUENCE {
>>      <06 03>
>> 401   3:                     OBJECT IDENTIFIER organizationalUnitName (2 5
>> 4 11)
>>         :                       (X.520 DN component)
>>      <13 16>
>> 406  22:                     PrintableString 'Symantec Trust Network'
>>         :                     }
>>         :                   }
>>      <31 28>
>> 430  40:                 SET {
>>      <30 26>
>> 432  38:                   SEQUENCE {
>>      <06 03>
>> 434   3:                     OBJECT IDENTIFIER commonName (2 5 4 3)
>>         :                       (X.520 DN component)
>>      <13 1F>
>> 439  31:                     PrintableString 'Symantec SHA256 TimeStamping
>> CA'
>>         :                     }
>>         :                   }
>>         :                 }
>>      <02 10>
>> 472  16:               INTEGER 54 F3 7D A1 71 67 51 BC 6A 8D 0A D2 74
>> B2 8B 13
>>         :               }
>>      <30 0B>
>> 490  11:             SEQUENCE {
>>      <06 09>
>> 492   9:               OBJECT IDENTIFIER sha-256 (2 16 840 1 101 3 4 2 1)
>>         :                 (NIST Algorithm)
>>         :               }
>>      <A0 81 A4>
>> 503 164:             [0] {
>>      <30 1A>
>> 506  26:               SEQUENCE {
>>      <06 09>
>> 508   9:                 OBJECT IDENTIFIER contentType (1 2 840 113549 1 9
>> 3)
>>         :                   (PKCS #9)
>>      <31 0D>
>> 519  13:                 SET {
>>      <06 0B>
>> 521  11:                   OBJECT IDENTIFIER tSTInfo (1 2 840 113549 1 9
>> 16 1 4)
>>         :                     (S/MIME Content Types)
>>         :                   }
>>         :                 }
>>      <30 1C>
>> 534  28:               SEQUENCE {
>>      <06 09>
>> 536   9:                 OBJECT IDENTIFIER signingTime (1 2 840 113549 1 9
>> 5)
>>         :                   (PKCS #9)
>>      <31 0F>
>> 547  15:                 SET {
>>      <17 0D>
>> 549  13:                   UTCTime 19/04/2016 03:52:25 GMT
>>         :                   }
>>         :                 }
>>      <30 2F>
>> 564  47:               SEQUENCE {
>>      <06 09>
>> 566   9:                 OBJECT IDENTIFIER messageDigest (1 2 840 113549 1
>> 9 4)
>>         :                   (PKCS #9)
>>      <31 22>
>> 577  34:                 SET {
>>      <04 20>
>> 579  32:                   OCTET STRING
>>         :                     98 1B CF E1 5D 96 79 D6    ....].y.
>>         :                     47 53 3E 27 A1 0C 57 4E    GS>'..WN
>>         :                     62 48 8E 43 F8 B5 17 D4    bH.C....
>>         :                     1C 8F 9A 86 ED D7 A6 B4
>>         :                   }
>>         :                 }
>>      <30 37>
>> 613  55:               SEQUENCE {
>>      <06 0B>
>> 615  11:                 OBJECT IDENTIFIER
>>         :                   signingCertificateV2 (1 2 840 113549 1 9 16 2
>> 47)
>>         :                   (S/MIME Authenticated Attributes)
>>      <31 28>
>> 628  40:                 SET {
>>      <30 26>
>> 630  38:                   SEQUENCE {
>>      <30 24>
>> 632  36:                     SEQUENCE {
>>      <30 22>
>> 634  34:                       SEQUENCE {
>>      <04 20>
>> 636  32:                         OCTET STRING
>>         :                           82 D5 56 DB DB 5D AD 5F    ..V..]._
>>         :                           A0 7B B6 07 26 A6 D8 6E    .{..&..n
>>         :                           73 0B 5B B7 29 88 5B B6    s.[.).[.
>>         :                           DE 4F F2 75 29 02 2C FC
>>         :                         }
>>         :                       }
>>         :                     }
>>         :                   }
>>         :                 }
>>         :               }
>>      <30 0B>
>> 670  11:             SEQUENCE {
>>      <06 09>
>> 672   9:               OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1
>> 1)
>>         :                 (PKCS #1)
>>         :               }
>>      <04 82 01 00>
>> 683 256:             OCTET STRING
>>         :               77 60 BE 64 F1 4C 04 B9    w`.d.L..
>>         :               4D 64 39 59 DC 53 27 02    Md9Y.S'.
>>         :               06 1F 0C C7 31 EC 5B A2    ....1.[.
>>         :               79 FB CA A3 07 DE D3 E6    y.......
>>         :               88 CE 84 37 4C 20 EF DF    ...7L ..
>>         :               9B BB D4 0B 6F DC 42 05    ....o.B.
>>         :               DA 8D 22 EF 24 A8 46 68    ..".$.Fh
>>         :               79 DA CB B5 A9 CD F6 7E    y......~
>>         :               D5 B8 D4 DD B4 44 5F 40    .....D_@
>>         :               0A A2 59 C8 3B 2C 52 6F    ..Y.;,Ro
>>         :               BE 88 6C D3 A4 F6 3C B1    ..l...<.
>>         :               52 27 25 E3 E9 6F 4A 2B    R'%..oJ+
>>         :               C6 C4 CD EA 73 65 6C 04    ....sel.
>>         :               9A A4 79 4E A4 95 F4 F7    ..yN....
>>         :               1C C6 2E E8 D3 4B 01 8F    .....K..
>>         :               F2 0B 80 6C 28 67 3E 10    ...l(g>.
>>         :               D7 76 1E C5 4E BF 87 37    .v..N..7
>>         :               CB 99 51 81 74 5C 50 57    ..Q.t\PW
>>         :               80 3F 5D 3E 84 76 12 0A    .?]>.v..
>>         :               B0 A3 99 DF E5 3B A4 8F    .....;..
>>         :               DE 04 50 A8 E6 D0 00 6D    ..P....m
>>         :               61 21 B1 A9 A9 D6 05 79    a!.....y
>>         :               0A 00 FA D5 1D A6 D6 F8    ........
>>         :               6A 22 07 E5 BC 01 C1 E0    j"......
>>         :               10 09 BD 92 09 B5 B7 29    .......)
>>         :               8B 6A 4D 28 C4 63 7A 4C    .jM(.czL
>>         :               8E 7A AF 87 5D BE A4 BD    .z..]...
>>         :               C1 20 9A D0 82 57 03 21    . ...W.!
>>         :               F3 E2 6F F5 44 22 F9 27    ..o.D".'
>>         :               41 9C 66 27 BB 52 39 E2    A.f'.R9.
>>         :               4B C8 2B 82 58 AC 0E AF    K.+.X...
>>         :               8D AE A5 C7 A5 1A A3 5E
>>         :             }
>>         :           }
>>         :         }
>>         :       }
>>         :     }
>>         :   }
>>
>> On 19 April 2016 at 14:29, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>>>
>>> On 19/04/2016 05:55, Alex Samad wrote:
>>>>
>>>> Hi
>>>>
>>>> I have a SHA.sha file
>>>>
>>>> /usr/bin/openssl ts -query -data SHA.sha -sha256 | /usr/bin/curl -s -H
>>>> Content-Type:application/timestamp-query --data-binary @-
>>>> http://sha256timestamp.ws.symantec.com/sha256/timestamp > SHA.sha.tsr
>>>>
>>>> /usr/bin/openssl ts -reply -in SHA.sha.tsr -text  > SHA.sha.ts.txt
>>>>
>>>>
>>>> cat SHA.sha.ts.txt
>>>> Status info:
>>>> Status: Granted.
>>>> Status description: unspecified
>>>> Failure info: unspecified
>>>>
>>>> TST info:
>>>> Version: 1
>>>> Policy OID: 2.16.840.1.113733.1.7.23.3
>>>> Hash Algorithm: sha256
>>>> Message data:
>>>>       0000 - 8c 6d 95 5b e0 cd 8b c9-df 8c ab 57 45 c4 69 e6
>>>> .m.[.......WE.i.
>>>>       0010 - 7a b9 ce cb 14 8f 55 25-91 2e 57 37 3e 5c b8 d5
>>>> z.....U%..W7>\..
>>>> Serial number: 0x570B9C3A11CA318E2478D3680C0FEFD9238E06AB
>>>> Time stamp: Apr 19 03:52:25 2016 GMT
>>>> Accuracy: 0x1E seconds, unspecified millis, unspecified micros
>>>> Ordering: no
>>>> Nonce: 0x580E59D87F396B25
>>>> TSA: DirName:/C=US/O=Symantec Corporation/OU=Symantec Trust
>>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1
>>>> Extensions:
>>>>
>>>>
>>>> But when I go to verify it
>>>>
>>>>    openssl ts -verify -data SHA.sha -in SHA.sha.tsr
>>>> Verification: FAILED
>>>> 140569777235784:error:2107C080:PKCS7
>>>> routines:PKCS7_get0_signers:signer certificate not
>>>> found:pk7_smime.c:476:
>>>>
>>>> is this because I didn't provide a cert to sign it with ?
>>>
>>> No, it is because it cannot find the certificate that Symantec
>>> used to sign the response, specifically the certificate with
>>> Subject name "/C=US/O=Symantec Corporation/OU=Symantec Trust
>>> Network/CN=Symantec SHA256 TimeStamping Signer - G1".
>>>
>>> I am kind of disappointed in how little detail is included in
>>> the output from ts -reply -text, I expected it to output all
>>> the fields, similar to what other openssl commands do when
>>> passed the -text option.
>>>
>>> So I guess the next step would be to dump SHA.sha.tsr using
>>> Peter Gutmann's dumpasn1.c program, something like
>>>
>>> openssl base64 -d -in SHA.sha.tsr -out SHA.sha.tsr.bin
>>> dumpasn1 -v SHA.sha.tsr.bin
>>>
>>>
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From shubham13099 at iiitd.ac.in  Fri Apr 29 06:48:42 2016
From: shubham13099 at iiitd.ac.in (Shubham Chauhan)
Date: Fri, 29 Apr 2016 12:18:42 +0530
Subject: [openssl-users] Illegal Parameter (47) fatal error in Session
	Resumption
Message-ID: <CAP=zTkMOL5392AYQECszejiwrb7o41HZZLpv79h6txPktO1GJw@mail.gmail.com>

While working on different ways of session management I came across this
error.

I had a single file consisting of a recently negotiated SSL session (stored
using PEM_write_SSL_SESSION()).
I used that text file to initialize the Client Hello message with that
session_id. I also added the session_id from the file, to the context on
the server side, so that a session resumption based on the stored
session_id could take place.
Well, the idea was to use a previously negotiated session id, from both
ends, i.e. client (through client hello) and server (reciprocating through
server hello).
I ensured using the same protocol at all levels, i.e. SSLv3.

The Client Hello got successfully initialized by the session_id.
The next message was a "Server Hello, Change Cipher Spec, Encrypted
Handshake Message" which also responded with the same session id.
The third message a fatal error message => (Level: Fatal (2), Description:
Illegal Parameter (47))

I don't understand why the error popped up. Previously I have run tests, to
reuse a session stored from a file (server-side), which worked fine.


-- 
Regards
Shubham Chauhan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160429/bb80d12b/attachment.html>

From steve at openssl.org  Fri Apr 29 15:13:25 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 29 Apr 2016 15:13:25 +0000
Subject: [openssl-users] X509_ALGOR_get_md?
In-Reply-To: <5721FC4E.7080201@fedict.be>
References: <5721FC4E.7080201@fedict.be>
Message-ID: <20160429151325.GA12313@openssl.org>

On Thu, Apr 28, 2016, Wouter Verhelst wrote:

> Hi,
> 
> I note that OpenSSL provides a function X509_ALGOR_set_md() to set
> the message digest algorithm to be used on a signature, but it
> doesn't seem to provide a corresponding X509_ALGOR_get_md()
> function.
> 
> Is this correct, or did I miss something? If I didn't miss anything,
> then how can I figure out which hashing algorithm was used for a
> given X.509 certificate?
> 

You can retrieve the OID used in the X509_ALGOR structure using
X509_ALGOR_get0(). If that OID corresponds to a digest directly you can call
EVP_get_digestbyobj() on it.

In many cases the OID you get will be a signature algorithm. In that case
you convert it to a NID using OBJ_obj2nid() and call OBJ_find_sigid_algs() to
get the digest NID and finally EVP_get_digestbynid().

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

From steve at openssl.org  Fri Apr 29 15:23:02 2016
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 29 Apr 2016 15:23:02 +0000
Subject: [openssl-users] i2d_PKCS7_bio() very slow for large file when
 reading in memory
In-Reply-To: <11905957.HbcaOcXK1q@kohni>
References: <5664520.8aEQkn2sHV@kohni>
 <11905957.HbcaOcXK1q@kohni>
Message-ID: <20160429152302.GB12313@openssl.org>

On Wed, Apr 27, 2016, Jan Kohnert wrote:

> Am Samstag, 23. April 2016, 03:57:55 schrieb Jan Kohnert:
> > I have question regarding i2d_PKCS7_bio() in Version 1.0.1c, 
> 1.0.2g and
> > maybe newer versions.
> 
> [code skipped]
> 
> Nobody any idea? Shall I compose a minimal compilable example 
> to make anyone able to dig this a little more? I still don't have a 
> clue what makes the function hang so long???
> 

Memory BIOs can be very inefficient when they contain a lot of data and it is
read in small chunks: each read copies the remaining data to the start of the 
memory block. If your message uses indefinite length encoding that could well
happen.

If you read the data into a block of memory and call d2i_CMS_ContentInfo() on
it you shouldn't get this problem. Alternatively if you have to use a memory
BIO you can retrieve the pointer to the contained memory block using
BIO_get_mem_data() and call d2i_CMS_ContentInfo() on the result.

A third option of to make the BIO read only and call d2i_CMS_bio() on that:
read only memory BIOs are handled more efficiently.

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

From jason.vas.dias at gmail.com  Wed Apr  6 21:23:36 2016
From: jason.vas.dias at gmail.com (Jason Vas Dias)
Date: Wed, 06 Apr 2016 21:23:36 -0000
Subject: [openssl-users] is 1.0.2g meant to be buildable ? missing
 rc4_md5_enc implementation !
In-Reply-To: <57057A0E.6040307@wisemo.com>
References: <CALyZvKzPNCj8oh=_RaFNTkfOS1kbXSdhNxX_Pbk6Zq7Jr-p1+A@mail.gmail.com>
 <CALyZvKz9-4J7uif5xkuSLAia7Cpr4DBa4phR7kGnEhX-m1XZ3w@mail.gmail.com>
 <57057A0E.6040307@wisemo.com>
Message-ID: <CALyZvKzP+MxPfvXyJ4tiHgLdUy07yRqGM2c4SnZtmDKCfGEwhQ@mail.gmail.com>

Thanks Jakob -
But running the rc4-x86_64.pl script, even if by a Makefile, does not define
the function either :

$ ./rc4-x86_64.pl  > ../rc4-md5-x86_64.s
$ cd ..
$ as -o rc4-md5-x86_64.o rc4-md5-x86_64.s
$ nm rc4-md5-x86_64.o
                 U OPENSSL_ia32cap_P
0000000000000000 T RC4
0000000000000720 T RC4_options
0000000000000660 T private_RC4_set_key

Do I need to pass 'no-asm' to Configure ?

The Configure command I used was :

$ LIBDIR=/usr/lib64 ./Configure --prefix=/usr threads shared
linux-x86_64:gcc $CFLAGS_64 2>&1 | tee configure.log

configure.log attached.

And I did run 'make depend' - log attached.

I used the command:

$ make -j4 2>&1 | tee make.log

to build OpenSSL and there is no occurence of the text ' rc4-x86_64' anywhere in
that (v.large) log file , indicating no attempt was made to generate
ASM for x86_64 ?

Please, for practical everyday use, what is the latest / best stable OpenSSL ?
1.0.1s or 1.0.2g ?

The last one I used extensively was 1.0.1g - but I'd like to build the
latest stable release now.

Thanks & Regards, Jason



On 06/04/2016, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> No, that script is run by the Makefile if relevant.
>
> Given what others have reported recently, please check
> what arguments you passed to config or configure (before
> running make).
>
> Also remember to do make depend.
>
> On 06/04/2016 22:58, Jason Vas Dias wrote:
>> Aha! I just saw rc4-md5-x86_64.pl - am I meant to run this manually to
>> produce the ASM
>> to compile to produce the object ? Why wasn't this run as part of the
>> build ?
>> I am building with perl-5.22.1 , gcc-5.3.0, make-4.1 on Linux x86_64 LFS
>> .
>>
>>
>> On 06/04/2016, Jason Vas Dias <jason.vas.dias at gmail.com> wrote:
>>> please can anyone tell me:
>>> Is the 1.0.2g release from :
>>>     http://www.openssl.org/source/openssl-1.0.2g.tar.gz
>>> meant to build ? Is this meant to be the latest stable release , or is
>>> that 1.0.1s ?
>>> The 1.0.2g release does not build, for the linux-x86_64:gcc 'threads
>>> shared' configuration
>>> (or any other AFAICS) because it lacks an implementation of
>>> rc4_md4_enc() - there
>>> are calls to it in crypto/evp/e_rc4_hmac_md5.c , but no definition of it
>>> :
>>>
>>> $ grep -RIn --include '*.[ch]' rc4_md5_enc
>>> crypto/evp/e_rc4_hmac_md5.c:80:void rc4_md5_enc(RC4_KEY *key, const
>>> void *in0, void *out,
>>> crypto/evp/e_rc4_hmac_md5.c:144:            rc4_md5_enc(&key->ks, in +
>>> rc4_off, out + rc4_off,
>>> crypto/evp/e_rc4_hmac_md5.c:188:            rc4_md5_enc(&key->ks, in +
>>> rc4_off, out + rc4_off,
>>> $ make
>>> ...
>>> $ ( LIBDEPS="${LIBDEPS:--L.. -lssl  -L.. -lcrypto }";
>>> LDCMD="${LDCMD:-gcc}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS
>>> -march=x86-64 -mtune=native -O2 -g -fPIC -pipe }"; LIBPATH=`for x in
>>> $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`;
>>> LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; set -x;
>>> LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o
>>> ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o
>>> dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o
>>> rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o
>>> gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o
>>> s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
>>> pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o
>>> rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} )
>>> + LD_LIBRARY_PATH=..:
>>> + gcc -DOPENSSL_THREADS -march=x86-64 -mtune=native -O2 -g -fPIC -pipe
>>> -o openssl openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o
>>> enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
>>> rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o
>>> genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o
>>> s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o
>>> pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
>>> engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto
>>> ../libcrypto.a(e_rc4_hmac_md5.o): In function `rc4_hmac_md5_cipher':
>>> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:144:
>>> undefined reference to `rc4_md5_enc'
>>> /usr/build/linux/openssl-1.0.2g/crypto/evp/e_rc4_hmac_md5.c:188:
>>> undefined reference to `rc4_md5_enc'
>>> collect2: error: ld returned 1 exit status
>>>
>>> ie. the make fails because nowhere in any library or object file is
>>> that function defined -
>>> I have checked this with nm .
>>>
>>> I guess my answer is that ! should be building 1.0.1s ?
>>>
>
>
> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make.depend.log
Type: text/x-log
Size: 37651 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160406/2ea43267/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.log
Type: text/x-log
Size: 17028 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160406/2ea43267/attachment-0003.bin>

From vikas.tm at gmail.com  Mon Apr 11 14:18:54 2016
From: vikas.tm at gmail.com (Vikas TM)
Date: Mon, 11 Apr 2016 14:18:54 -0000
Subject: [openssl-users] glibc detected *** xxx: double free or
 corruption (!prev): 0x097b8750
In-Reply-To: <CA+5R-ahJrO8rVgbO1qreFGjsKgxSOMfYzPt8nmbRLNpCAPnwoQ@mail.gmail.com>
References: <8ACFF8299C8F504F87EDE3DAA1FCA84D14F49592@chn-hclt-mbs06.HCLT.CORP.HCL.IN>
 <CA+5R-ah1WbS-AL1HX5EieuMRodwgvEMfSkv=vNwrD7k+2cNnSQ@mail.gmail.com>
 <CAJe-LUiV792wMv7fNGsgi7f3TBQ_iBtM3QOdAqq-++6j+KbdXQ@mail.gmail.com>
 <CA+5R-aj0trZmyKwKff7QF-7KFwpbk2W6o+7obTUWc9eLktXDJg@mail.gmail.com>
 <57066269.10702@openssl.org>
 <CA+5R-ahPRUbz6FYaqVVny_8x6h1P4DTiHqPn7Z91Qkw=CxmJcw@mail.gmail.com>
 <CA+5R-ajSiup1GHeD-T821_jMAP8Kxfu=MCogUYZFPeCW9OjiaA@mail.gmail.com>
 <CA+5R-ahpq45e56XJ_nGgyWxZejqL8UM9VLvmtMJAYV=pzNUaiw@mail.gmail.com>
 <CA+5R-ahJrO8rVgbO1qreFGjsKgxSOMfYzPt8nmbRLNpCAPnwoQ@mail.gmail.com>
Message-ID: <CA+5R-aiBjCeum4mesUbUiGtYRC0Qw1_bev5dwgJArGM0oT88ug@mail.gmail.com>

Hi Matt,

It looks like handling crypto lock mechanism issue. I defined NO SRP. Now I
am getting segmentation fault in CRYPTO_add_lock() function referencing
NULL pointer. Please find GDB output below,

(gdb) run ftp://x.x.x.x:sample.txt

Starting program: /App/vikftp ftp://x.x.x.x:sample.txt

Missing separate debuginfo for /lib/ld-linux.so.2

Missing separate debuginfo for /lib/libdl.so.2

Missing separate debuginfo for /lib/libpam.so.0

Missing separate debuginfo for /lib/libm.so.6

Missing separate debuginfo for /lib/libc.so.6

Missing separate debuginfo for /lib/libaudit.so.0

process 22287 is executing new program: /App/vikftp

Missing separate debuginfo for /lib/ld-linux.so.2

Missing separate debuginfo for /lib/libdl.so.2

Missing separate debuginfo for /lib/libpam.so.0

Missing separate debuginfo for /lib/libm.so.6

Missing separate debuginfo for /lib/libc.so.6

Missing separate debuginfo for /lib/libaudit.so.0



Program received signal SIGSEGV, Segmentation fault.

0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3,
file=0x85d0030 "/102d/s/tasn_utl.c", line=118)

    at /102d/s/cryptlib.c:624

624             ret = *pointer + amount;

(gdb) bt

#0  0x08205766 in CRYPTO_add_lock (pointer=0x1011, amount=-1, type=3,
file=0x85d0030 "/102d/s/tasn_utl.c", line=118)

    at /102d/s/cryptlib.c:624

#1  0x08249d2a in asn1_do_lock (pval=0xff8eee90, op=-1, it=0x862cb1c) at
/102d/s/tasn_utl.c:118

#2  0x08246ed5 in asn1_item_combine_free (pval=0xff8eee90, it=0x862cb1c,
combine=0) at /102d/s/tasn_fre.c:146

#3  0x08246c40 in ASN1_item_free (val=0x1001, it=0x862cb1c) at
/102d/s/tasn_fre.c:72

#4  0x0825eeea in X509_free (a=0x1001) at /102d/s/x_x509.c:143

#5  0x082ee677 in ssl_cert_clear_certs (c=0x872e4e0) at
/102d/s/ssl_cert.c:431

#6  0x082ee7ed in ssl_cert_free (c=0x872e4e0) at /102d/s/ssl_cert.c:489

#7  0x0822f926 in SSL_free (s=0x872e340) at /102d/s/ssl_lib.c:627

#8  0x0816566c in closeConnection (pcx=0x86d8310, rsn=0x0, graceful=1
'\001') at /App/vikftp.c:10098

Please let me know if you have any solution.
Thanks & Regards,
Vikas
On 7 Apr 2016 7:18 pm, "Vikas TM" <vikas.tm at gmail.com> wrote:

Hi Matt,

I was trying the patches available in the Internet. Due to that few blank
lines might have added or removed. But no major change in the code.

Thanks & Regards,
Vikas
On 7 Apr 2016 7:07 pm, "Matt Caswell" <matt at openssl.org> wrote:

>
>
> On 07/04/16 14:23, Vikas TM wrote:
> > Hi Mike
> >
> >
> > I have integrated openSSL version 102d. While running secure FTP
> > connection, I have encountered double free or corruption issue.
>
> Are you running 1.0.2d as downloaded from the OpenSSL website with no
> other patches applied? The line numbers below do not match up with the
> git copy of 1.0.2d.
>
> Matt
>
> >
> > The TLS negotiation is successful and file is also getting transferred
> > to partner machine. At the end while freeing all the memory, file
> > transfer is ended with ?double free or corruption issue?. I have tried
> > almost all the patch available in internet. Please let me know if you
> > any solution.
> >
> >
> >
> > Machine: Linux x86_64
> >
> > Please find the GDB output below,
> >
> >
> >
> > Breakpoint 1, ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:2995
> >
> > 2995        if (s == NULL || s->s3 == NULL)
> >
> > (gdb) n
> >
> > 3009        ssl3_cleanup_key_block(s);
> >
> > (gdb)
> >
> > 3010        if (s->s3->rbuf.buf != NULL)
> >
> > (gdb)
> >
> > 3011            ssl3_release_read_buffer(s);
> >
> > (gdb)
> >
> > 3012        if (s->s3->wbuf.buf != NULL)
> >
> > (gdb)
> >
> > 3013            ssl3_release_write_buffer(s);
> >
> > (gdb)
> >
> > 3014        if (s->s3->rrec.comp != NULL)
> >
> > (gdb)
> >
> > 3017        if (s->s3->tmp.dh != NULL)
> >
> > (gdb)
> >
> > 3021        if (s->s3->tmp.ecdh != NULL)
> >
> > (gdb)
> >
> > 3025        if (s->s3->tmp.ca_names != NULL)
> >
> > (gdb)
> >
> > 3027        if (s->s3->handshake_buffer) {
> >
> > (gdb)
> >
> > 3030        if (s->s3->handshake_dgst)
> >
> > (gdb)
> >
> > 3031            ssl3_free_digest_list(s);
> >
> > (gdb)
> >
> > 3033        if (s->s3->alpn_selected)
> >
> > (gdb)
> >
> > 3038        SSL_SRP_CTX_free(s);
> >
> > (gdb)
> >
> >
> >
> > 3042        OPENSSL_cleanse(s->s3, sizeof *(s->s3));
> >
> > (gdb) n
> >
> > 3047        OPENSSL_free(s->s3);
> >
> > (gdb) p *(s->s3)
> >
> > $1 = {flags = 1447178013, delay_buf_pop_ret = -1332182677, read_sequence
> > = "\311\343\376\032\067Ut\224", read_mac_secret_size = -557140059,
> >
> >   read_mac_secret = "\363\t
> >
> 8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332\363\003\031\060Ha{\226\262\317\355\f,=Obv\213\241\270\320\356\003\036:Wu\224\264\305\327\356\374",
> > write_sequence = "\023)@Xq\213\246", <incomplete sequence \302>,
> > write_mac_secret_size = 1008532959,
> >
> >   write_mac_secret =
> >
> "M_r\206\243\261\310\340\371\023.Jg\205\260\304\325\347\373\016#9Ph\201\233\264\322\357\r,L]o\202\226\253\301\330\363\t#>Zw\225\264\324\345\374\n\036\063I`x\221\253\306\342\377\035<\\",
> > server_random =
> >
> "m\177\222\246\273\321\350\000\031\063Nj\207\245\304\344\365\a\032.CYp\210\241\273\326\362\017-Ll",
> >
> >   client_random =
> >
> "}\217\242\266\313\341\370\020)C^z\227\265\324\364\005\027*>Si\200\230\261\313\346\002\037=\\|",
> > need_empty_fragments = -961372275,
> >
> >   empty_fragment_done = 537457115, init_extra = -1972481223, rbuf = {buf
> > = 0x4e4c5a7 <Address 0x4e4c5a7 out of bounds>, len = 1312433941, offset
> > = -1466926749,
> >
> >     left = 318168001}, wbuf = {buf = 0x8c6c4d2f <Address 0x8c6c4d2f out
> > of bounds>, len = 3603083165, offset = 806879723, left = -1702993079},
> > rrec = {
> >
> >     type = 351589815, length = 1581922085, off = 3097528691, data =
> > 0x2206ebd1 <Address 0x2206ebd1 out of bounds>,
> >
> >     input = 0x9c7c5d3f <Address 0x9c7c5d3f out of bounds>, comp =
> > 0xe6d2bfad <Address 0xe6d2bfad out of bounds>, epoch = 1076367867,
> >
> >     seq_num = "Ys\216\252\307\345\004$"}, wrec = {type = 1851410229,
> > length = 3367016835, off = 840367073, data = 0xac8c6d4f <Address
> > 0xac8c6d4f out of bounds>,
> >
> >     input = 0xf6e2cfbd <Address 0xf6e2cfbd out of bounds>, comp =
> > 0x5038210b <Address 0x5038210b out of bounds>, epoch = 3130950505,
> >
> >     seq_num = "\327\365\024\064EWj~"}, alert_fragment = "\223\251",
> > alert_fragment_len = 1109789681, handshake_fragment = "_}\234\274",
> >
> >   handshake_fragment_len = 116580301, wnum = 1615343899, wpend_tot =
> > -894528647, wpend_type = 1143211495, wpend_ret = -1904580779,
> >
> >   wpend_buf = 0xe8d0b9a3 <Address 0xe8d0b9a3 out of bounds>,
> > handshake_buffer = 0x52361b01, handshake_dgst = 0xccac8d6f,
> > change_cipher_spec = 369291229,
> >
> >   warn_alert = 1884832043, fatal_alert = -625040503, alert_dispatch =
> > 1412699639, send_alert = "ew", renegotiate = -119486029,
> > total_renegotiations = 1648765713,
> >
> >   num_renegotiations = -591618689, in_read_app_data = 638779373,
> > client_opaque_prf_input = 0x8068513b, client_opaque_prf_input_len =
> > 3939414937,
> >
> >   server_opaque_prf_input = 0x64442507, server_opaque_prf_input_len =
> > 2929362805, tmp = {
> >
> >     cert_verify_md =
> >
> "\303\331\363\b!;Vr\217\255\314\354\375\017\"6Kax\220\251\303\336\362\029\065Tt\205\227\252\279\323\351\000\030\061Kf\202\237\263\336\321\r\037\062F[q\210\240\271\323\346\n'Ed\204\225\247\281\316\323\371\020(A[v\222\257\314\354\f\035/BVk\201\230\270\212\343\373\032\067Ut\224\248\267\312\336\363\t
> >
> 8Qk\206\242\277\335\377\034-?Rf{\221\253\300\337\353\016*Ge\204\244\265\307\332",
> > <incomplete sequence \356>,
> >
> >     finish_md =
> >
> "\003\031\060Ha{\226\262\319\356\f,=Obv\213\241\270\478\351\003\036:Wu\224\268\365\327\352\376\023)@Xq\213\246\302\347\365\034<M_r\206\233\261\311\340\361\023.Jg\205\244\304\325\357\371\016#9Ph\201\233\266\344\357\r,L]o\202\226\253\301\330\360\t#>Zw\225\264\327\345\364\n\036\063I`x\221\253\306\342\377\035<\\m\177\222\246\273\328\350\000\031\063Nj\207\245\304\344\365\a\032.",
> > finish_md_len = -2005903037,
> >
> >     peer_finish_md =
> >
> "\241\273\326\366\017-Ll}\217\242\266\314\341\370\020)C^z\227\265\324\366\005\027*>Si\200\230\261\363\346\002\037=\\|\215\237\262\363\333\362\b
> >
> 9Sn\212\247\305\344\004\025':Ncy\220\250\301\333\366\022/Ml\214\235\257\302\326\353\001\030\060Ic~\232\267\325\364\024%7J^s\211\240\270\321\353\006\"?]|\234\255\277\325\346\373\021(@Ys\216\252\307\345\004$5GZn\203\242\260",
> > <incomplete sequence \310>, peer_finish_md_len = 840367073, message_size
> > = 2894884175, message_type = -152907843,
> >
> >     new_cipher = 0x5038210b, dh = 0xba9e8369, ecdh = 0x3414f5d7,
> > next_state = 2120898373, reuse_message = -658462317, cert_req =
> > 1109789681, ctype_num = -1130594977,
> >
> >     ctype = "\315\337\362\006\033\061H`y", ca_names = 0x442405e7,
> > use_rsa_tmp = -1904580779, key_block_length = -388974173,
> >
> >     key_block = 0x52361b01 <Address 0x52361b01 out of bounds>,
> > new_sym_enc = 0xccac8d6f, new_hash = 0x1602efdd, new_mac_pkey_type =
> > 1884832043,
> >
> >     new_mac_secret_size = -625040503, new_compression = 0x543415f7
> > <Address 0x543415f7 out of bounds>, cert_request = -1635092635},
> >
> >   previous_client_finished =
> >
> "\263\311\350\370\021+Fb\177\235\274\344\355\377\022&;Qh\200\241\263\326\352\a%Ddu\207\234\256\303\331\340\b!;Vr\217\255\314\364\375\027\"6Kax\220\251\303\336\362\029\065Tt\205\227\252\279",
> > previous_client_finished_len = 211 '\323',
> >
> >   previous_server_finished =
> >
> "\351\000\032\061Kf\202\247\275\334\374\r\037\062F[q\210\240\271\325\356\n'Ed\204\325\247\272\316\363\371\020(A[v\222\257\315\354\f\035/BVk\201\230\260\311\343\376\032\067Ut\224\255\267\312\346",
> > <incomplete sequence \363>, previous_server_finished_len = 9 '\t',
> > send_connection_binding = -1568249007,
> >
> >   next_proto_neg_seen = 486333887, is_probably_safari = 45 '-',
> > alpn_selected = 0xc0a8917b <Address 0xc0a8917b out of bounds>,
> > alpn_selected_len = 705623001}
> >
> > (gdb) n
> >
> > *** glibc detected *** vikftp: double free or corruption (!prev):
> > 0x08736610 ***
> >
> > Missing separate debuginfo for /lib/libgcc_s.so.1
> >
> > ======= Backtrace: =========
> >
> > /lib/libc.so.6[0xf75b3a51]
> >
> > /lib/libc.so.6(__libc_free+0x84)[0xf75b5224]
> >
> > vikftp(CRYPTO_free+0x40)[0x820e9e8]
> >
> > vikftp(ssl3_free+0x198)[0x82e15c1]
> >
> > vikftp(tls1_free+0x3b)[0x823b034]
> >
> > vikftp(SSL_free+0x1fd)[0x8230151]
> >
> > vikftp[0x8165dac]
> >
> > vikftp[0x815236b]
> >
> > vikftp[0x8156afe]
> >
> > vikftp[0x8154a3f]
> >
> > vikftp[0x8154578]
> >
> > vikftp(vikftp+0x2ea)[0x8150e6a]
> >
> > vikftp(main+0x17f)[0x81f8173]
> >
> > /lib/libc.so.6(__libc_start_main+0xdc)[0xf756589c]
> >
> > vikftp[0x8094441]
> >
> > ======= Memory map: ========
> >
> > 08048000-0862c000 r-xp 00000000 fd:00 854843
> > /App/vikftp
> >
> > 0862c000-08670000 rwxp 005e4000 fd:00 854843
> > /App/vikftp
> >
> > 08670000-08765000 rwxp 08670000 00:00 0
> > [heap]
> >
> > f6e00000-f6e21000 rwxp f6e00000 00:00 0
> >
> > f6e21000-f6f00000 ---p f6e21000 00:00 0
> >
> > f6f25000-f6f26000 rwxp f6f25000 00:00 0
> >
> > f6f26000-f6f27000 rwxs 00000000 ca:02 1057441
> > /var/vik/tmp/AMCMMON
> >
> > f6f27000-f6f28000 rwxs 00000000 ca:02 155213
> >                          /var/vik/tmp/AMLOG
> >
> > f6f28000-f6f2f000 r-xs 00000000 ca:02 26686
> > /usr/lib/gconv/gconv-modules.cache
> >
> > f6f2f000-f6f62000 r-xp 00000000 ca:02 30659
> > /usr/lib/locale/en_US.utf8/LC_CTYPE
> >
> > f7491000-f74c6000 r-xs 00000000 ca:02 269730
> > /var/run/nscd/group
> >
> > f74c6000-f74fb000 r-xs 00000000 ca:02 269729
> > /var/run/nscd/passwd
> >
> > f74fb000-f753d000 rwxp f74fb000 00:00 0
> >
> > f753d000-f754e000 r-xp 00000000 ca:02 26359
> > /lib/libaudit.so.0.0.0
> >
> > f754e000-f7550000 rwxp 00010000 ca:02 26359
> > /lib/libaudit.so.0.0.0
> >
> > f7550000-f768b000 r-xp 00000000 ca:02 25372
> > /lib/libc-2.4.so <http://libc-2.4.so>
> >
> > f768b000-f768c000 rwxp 0013a000 ca:02 25372
> > /lib/libc-2.4.so <http://libc-2.4.so>
> >
> > f768c000-f768d000 r-xp 0013b000 ca:02 25372
> > /lib/libc-2.4.so <http://libc-2.4.so>
> >
> > f768d000-f768f000 rwxp 0013c000 ca:02 25372
> > /lib/libc-2.4.so <http://libc-2.4.so>
> >
> > f768f000-f7693000 rwxp f768f000 00:00 0
> >
> > f7693000-f76b8000 r-xp 00000000 ca:02 25380
> > /lib/libm-2.4.so <http://libm-2.4.so>
> >
> > f76b8000-f76ba000 rwxp 00025000 ca:02 25380
> > /lib/libm-2.4.so <http://libm-2.4.so>
> >
> > f76ba000-f76c4000 r-xp 00000000 ca:02 36150
> > /lib/libpam.so.0.81.5
> >
> > f76c4000-f76c5000 rwxp 00009000 ca:02 36150
> > /lib/libpam.so.0.81.5
> >
> > f76c5000-f76c8000 r-xp 00000000 ca:02 25378
> > /lib/libdl-2.4.so <http://libdl-2.4.so>
> >
> > f76c8000-f76ca000 rwxp 00002000 ca:02 25378
> > /lib/libdl-2.4.so <http://libdl-2.4.so>
> >
> > f76ca000-f76d3000 r-xp 00000000 ca:02 25376
> > /lib/libcrypt-2.4.so <http://libcrypt-2.4.so>
> >
> > f76d3000-f76d6000 rwxp 00008000 ca:02 25376
> > /lib/libcrypt-2.4.so <http://libcrypt-2.4.so>
> >
> > f76d6000-f76fd000 rwxp f76d6000 00:00 0
> >
> > f770b000-f7715000 r-xp 00000000 ca:02 30823
> > /lib/libgcc_s.so.1
> >
> > f7715000-f7716000 rwxp 00009000 ca:02 30823
> > /lib/libgcc_s.so.1
> >
> > f7718000-f7719000 rwxp f7718000 00:00 0
> >
> > f7719000-f7735000 r-xp 00000000 ca:02 25365
> > /lib/ld-2.4.so <http://ld-2.4.so>
> >
> > f7735000-f7737000 rwxp 0001b000 ca:02 25365
> /l
> >
> > Program received signal SIGABRT, Aborted.
> >
> > 0xffffe410 in ?? ()
> >
> > (gdb) bt
> >
> > #0  0xffffe410 in ?? ()
> >
> > #1  0x00000006 in ?? ()
> >
> > #2  0x0000704d in ?? ()
> >
> > #3  0xf7578a30 in raise () from /lib/libc.so.6
> >
> > #4  0xf757a153 in abort () from /lib/libc.so.6
> >
> > #5  0xf75ae08b in __libc_message () from /lib/libc.so.6
> >
> > #6  0xf75b3a51 in malloc_printerr () from /lib/libc.so.6
> >
> > #7  0xf75b5224 in free () from /lib/libc.so.6
> >
> > #8  0x0820e9e8 in CRYPTO_free (str=0x8736610) at /102d/s/mem.c:442
> >
> > #9  0x082e15c1 in ssl3_free (s=0x8736430) at /102d/s/s3_lib.c:3047
> >
> > #10 0x0823b034 in tls1_free (s=0x8736430) at /102d/s/t1_lib.c:217
> >
> > #11 0x08230151 in SSL_free (s=0x8736430) at /102d/s/ssl_lib.c:639
> >
> > #12 0x08165dac in closeConnection (pcx=0x86e0400, rsn=0x0, graceful=1
> > '\001') at /App/ftp.c:10098
> >
> > On 25 Feb 2016 2:20 pm, "Mike Mohr" <akihana at gmail.com
> > <mailto:akihana at gmail.com>> wrote:
> >
> >     You'll need to rebuild your application and openssl with debugging
> >     symbols and no optimization, then run it inside gdb to produce a
> >     more useful stack trace. Since you don't include any context or
> >     source code snippets it isn't really possible to help. Can you
> >     produce a reduced test case with source code which reproduces the
> bug?
> >
> >     As long as politics is the shadow cast on society by big business,
> >     the attenuation of the shadow will not change the substance.
> >
> >     John Dewey: The Later Works, 1925-1953; Volume 6, pp. 163
> >
> >     On Feb 24, 2016 11:33 PM, "Vikas TM" <vikas.tm at gmail.com
> >     <mailto:vikas.tm at gmail.com>> wrote:
> >
> >         Hi,
> >
> >         While running my application with openSSL 102d and I encountered
> >         double free error or corruption.
> >
> >         As per few threads suggestion, I have changed getpid() with
> >         pthread_self() in CRYPTO_thread_id(). Still the result is same.
> >
> >         Please let me know if any fix available to this issue.
> >
> >         *** glibc detected *** xxx: double free or corruption (!prev):
> >         0x097b8750 ***
> >
> >         ======= Backtrace: =========
> >
> >         /lib/libc.so.6[0x1768b6]
> >
> >         /lib/libc.so.6(cfree+0x90)[0x179e00]
> >
> >         xxx(CRYPTO_free+0x3a)[0x81b89be]
> >
> >         xxx(ssl_cert_free+0x13f)[0x826fa23]
> >
> >         xxx(SSL_free+0x14d)[0x81d7e08]
> >
> >         Thanks & Regards,
> >         Vikas
> >
> >
> >         --
> >         openssl-users mailing list
> >         To unsubscribe:
> >         https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> >     --
> >     openssl-users mailing list
> >     To unsubscribe:
> https://mta.openssl.org/mailman/listinfo/openssl-users
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160411/e4edf5ae/attachment-0001.html>

From james.sqawz at gmail.com  Mon Apr 18 14:04:31 2016
From: james.sqawz at gmail.com (james sqawz)
Date: Mon, 18 Apr 2016 14:04:31 -0000
Subject: [openssl-users] ssl connect failed
In-Reply-To: <CANz_a=rU5rhnEQGm0uG4g1GJNn7-XnZiUWSG7xDk6WdCBowtzA@mail.gmail.com>
References: <CANz_a=rU5rhnEQGm0uG4g1GJNn7-XnZiUWSG7xDk6WdCBowtzA@mail.gmail.com>
Message-ID: <CANz_a=oLUCLB9noEaFjNNg=7fQap_CDVaMxamvk0GG52H-a8iw@mail.gmail.com>

*attaching screen shot of not working pcap


On Mon, Apr 18, 2016 at 6:16 PM, james sqawz <james.sqawz at gmail.com> wrote:

> Hi all,
>
> Thanks for the providing the forum for discussion on TLS/OPENSSL related
> issue.
>
> I am very new to openssl.
>
> Currently I am trying to implement HTTP over TLS.(TLS Version 1.2)
> For that purpose I send connect request to the server,but connection is
> getting failed.
>
> Following fields are abscent in my ssl packet.
>
> Extension: server name present
> Extension:application layer protocol negotiation
>
> Apart from that I did not set path of Server Certificate.
>
> Shall these impact my connect request.
> Can somebody help.
>
> Thanks
> James
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/8673580d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not_working_log.7z
Type: application/octet-stream
Size: 495350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20160418/8673580d/attachment-0001.obj>