From Thorsten.Albers at vector.com  Fri Dec  5 01:59:07 2014
From: Thorsten.Albers at vector.com (Albers, Thorsten)
Date: Fri, 5 Dec 2014 06:59:07 +0000
Subject: [openssl-users] generate TLS OCSP responses for a time in the past
 using -attime not possible?
Message-ID: <47B16FDD4CC7C442BE5E57FD525F69FE012688174E@vistrex4.vi.vector.int>

Hi,

for test purposes I would like to create OCSP responses for a time in the past, let's say for 5 days in the past. In the documentation for the ocsp command there is a list of verification options a client might use / request.

I would have expected that a command could look like following:

openssl ocsp -sha256 -issuer Root_A_cert.cer -cert Sub1_A_cert.cer -reqout Sub1_OCSPRequest.bin -text -attime <old timestamp>

with <old timestamp> being a time in the past.

But all I get is openssl telling me that the 'attime' is no valid parameter. Am I doing something wrong, or is this not implemented yet?

Gru?,
Thorsten

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141205/13e4780e/attachment.html>

From hablutzel1 at gmail.com  Fri Dec  5 03:02:59 2014
From: hablutzel1 at gmail.com (Jaime Hablutzel Egoavil)
Date: Fri, 5 Dec 2014 03:02:59 -0500
Subject: [openssl-users] generate TLS OCSP responses for a time in the
 past using -attime not possible?
In-Reply-To: <47B16FDD4CC7C442BE5E57FD525F69FE012688174E@vistrex4.vi.vector.int>
References: <47B16FDD4CC7C442BE5E57FD525F69FE012688174E@vistrex4.vi.vector.int>
Message-ID: <CAFxNpv8Rw0zvLM1BHVDoDiX1660kxbUzAuoyy3oszpcZ1QCyXw@mail.gmail.com>

Maybe not an straight answer to your question but go and read the openssl
source code, it is not really hard to understand and you can check all the
supported parameters

Enviado desde mi Android.
El dic 5, 2014 2:03 AM, "Albers, Thorsten" <Thorsten.Albers at vector.com>
escribi?:

>  Hi,
>
>
>
> for test purposes I would like to create OCSP responses for a time in the
> past, let?s say for 5 days in the past. In the documentation for the ocsp
> command there is a list of verification options a client might use /
> request.
>
>
>
> I would have expected that a command could look like following:
>
>
>
> openssl ocsp -sha256 -issuer Root_A_cert.cer -cert Sub1_A_cert.cer -reqout
> Sub1_OCSPRequest.bin -text -attime <old timestamp>
>
>
>
> with <old timestamp> being a time in the past.
>
>
>
> But all I get is openssl telling me that the ?attime? is no valid
> parameter. Am I doing something wrong, or is this not implemented yet?
>
>
>
> Gru?,
>
> Thorsten
>
>
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at mta.opensslfoundation.net
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141205/da279429/attachment.html>

From Walter.H at mathemainzel.info  Fri Dec  5 04:33:30 2014
From: Walter.H at mathemainzel.info (Walter H.)
Date: Fri, 05 Dec 2014 10:33:30 +0100
Subject: [openssl-users] generate TLS OCSP responses for a time in the
 past using -attime not possible?
In-Reply-To: <47B16FDD4CC7C442BE5E57FD525F69FE012688174E@vistrex4.vi.vector.int>
References: <47B16FDD4CC7C442BE5E57FD525F69FE012688174E@vistrex4.vi.vector.int>
Message-ID: <54817BEA.9000004@mathemainzel.info>

It works like this, as I do it like this:

openssl ocsp -index db.list -CA ca.pem -rsigner ocsprsp.pem -rkey 
ocsprsp.key -nmin 45 -resp_key_id -noverify -reqin reqin.bin -respout 
reqout.bin

db.list is generated by using openssl with the ca parameter
ca.pem is the certificate that signed the OCSP responder certificate and 
the certificate that is in db.list
ocsprsp.pem and ocsprsp.key are the OCSP responder certificate
reqin.bin is the OCSP request, that comes typically with a http request
respout.bin is the OCSP response that is typically sent out with a http 
response



On 05.12.2014 07:59, Albers, Thorsten wrote:
>
> Hi,
>
> for test purposes I would like to create OCSP responses for a time in 
> the past, let's say for 5 days in the past. In the documentation for 
> the ocsp command there is a list of verification options a client 
> might use / request.
>
> I would have expected that a command could look like following:
>
> openssl ocsp -sha256 -issuer Root_A_cert.cer -cert Sub1_A_cert.cer 
> -reqout Sub1_OCSPRequest.bin -text -attime <old timestamp>
>
> with <old timestamp> being a time in the past.
>
> But all I get is openssl telling me that the 'attime' is no valid 
> parameter. Am I doing something wrong, or is this not implemented yet?
>
> Gru?,
>
> Thorsten
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141205/97c6f9d6/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141205/97c6f9d6/attachment-0001.bin>

From TrimbleB at michigan.gov  Fri Dec  5 05:03:32 2014
From: TrimbleB at michigan.gov (Trimble, Brian (Treasury))
Date: Fri, 5 Dec 2014 10:03:32 +0000
Subject: [openssl-users] (no subject)
Message-ID: <1322ec85eaaf412b8250f8949b1ce058@CY1PR09MB0379.namprd09.prod.outlook.com>



Brian K. Trimble
Technical Services Architect
[Description: Description: cid:image001.png at 01CDD6AC.EC04A9E0]
5015 S Cedar, Suite 260, Lansing, MI 48910
Office: (517) 272-5527, Cell: (517) 290-5703, Text: 5172905703 at vtext.com<mailto:5172905703 at vtext.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141205/bc520f88/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 4005 bytes
Desc: image001.png
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141205/bc520f88/attachment.png>

From matt at openssl.org  Fri Dec  5 07:00:44 2014
From: matt at openssl.org (Matt Caswell)
Date: Fri, 05 Dec 2014 12:00:44 +0000
Subject: [openssl-users] generate TLS OCSP responses for a time in the
 past using -attime not possible?
In-Reply-To: <47B16FDD4CC7C442BE5E57FD525F69FE012688174E@vistrex4.vi.vector.int>
References: <47B16FDD4CC7C442BE5E57FD525F69FE012688174E@vistrex4.vi.vector.int>
Message-ID: <54819E6C.2090002@openssl.org>


On 05/12/14 06:59, Albers, Thorsten wrote:
>
> Hi,
>
>  
>
> for test purposes I would like to create OCSP responses for a time in
> the past, let?s say for 5 days in the past. In the documentation for
> the ocsp command there is a list of verification options a client
> might use / request.
>
>  
>
> I would have expected that a command could look like following:
>
>  
>
> openssl ocsp -sha256 -issuer Root_A_cert.cer -cert Sub1_A_cert.cer
> -reqout Sub1_OCSPRequest.bin -text -attime <old timestamp>
>
>  
>
> with <old timestamp> being a time in the past.
>
>  
>
> But all I get is openssl telling me that the ?attime? is no valid
> parameter. Am I doing something wrong, or is this not implemented yet?
>
>
-attime for ocsp is only implemented in version 1.0.2 (not yet released)
and above.

Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141205/48cd6575/attachment.html>

From jeremy.farrell at oracle.com  Fri Dec  5 13:47:41 2014
From: jeremy.farrell at oracle.com (Jeremy Farrell)
Date: Fri, 5 Dec 2014 10:47:41 -0800 (PST)
Subject: [openssl-users] OpenSSL with 64bit Instruction-Set and
	libraries for Windows?
In-Reply-To: <5481DB06.6010500@infotech.de>
References: <5481DB06.6010500@infotech.de>
Message-ID: <c53f9523-8a18-477e-b854-2d54a6ee477f@default>

I'm not sure what you're missing, but 64-bit Windows (both x64 and Itanium) has been working fine for many years (since early in the 0.9.8 series at least). Shining Light ship an x64 binary package. Many of the comments in INSTALL.W64 are out of date.

I use a site-specific build process with unusual tools, but it's based closely on INSTALL.W64. What command sequence are you using exactly? I don't understand "The compiled libraries remain being build against the 32-bit versions"; do you mean that you are doing a shared build, but the resulting DLLs are 32-bit?

Regards,
                jjf

> From: Christian Weber [mailto:weber at infotech.de]
> Sent: Friday, December 05, 2014 4:19 PM
> 
> Dear folks,
> 
> as far as i can see, there is no true 64-bit support for building
> openssl (current version 1.0.1j).
> 
> The contained file INSTALL.W64 states Win64 support as "initial".
> Following the build instructions i get a resulting makefile which is
> almost identical with the
> one generated for VC-WIN32.
> 
> The compiled libraries remain being build against the 32-bit versions.
> 
> So what am i missing? Is there any real support for Win64?
> 
> Thanks in advance
> 
> --
> Christian Weber
> Security Software
> Abteilungsleiter Entwicklung
> mailto:Weber at InfoTech.de
> --
> Infotech Gesellschaft f?r
> Informations- und Datentechnik mbH
> Tel. +49-2361-9130-0
> Fax +49-2361-9130-105
> 
> Gesch?ftsf?hrer
> Rainer Hans
> 
> Gerichtsstand Recklinghausen
> Amtsgericht Recklinghausen HRB 1912
> USt.-IdNr. DE-811565628

From 0.openssl at iam.tj  Fri Dec  5 14:34:13 2014
From: 0.openssl at iam.tj (TJ)
Date: Fri, 05 Dec 2014 19:34:13 +0000
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
Message-ID: <548208B5.4040809@iam.tj>

On 26/11/14 02:05, Salz, Rich wrote:> We will soon be freezing the mailing list memberships for a couple of days.
>
> We are moving to a new server and upgrading the mail infrastructure

Are you aware that the headers for the mailman configuration are inconsistent; some specify the previous
openssl.org email addresses whilst others use the mta.opensslfoundation.net address.

It's playing havock with procmail filters!

openssl-dev:

List-Id: For those working on the code <openssl-dev.openssl.org>
List-Unsubscribe: <https://mta.opensslfoundation.net/mailman/options/openssl-dev>,
  <mailto:openssl-dev-request at openssl.org?subject=unsubscribe>
List-Archive: <http://mta.opensslfoundation.net/pipermail/openssl-dev/>
List-Post: <mailto:openssl-dev at openssl.org>
List-Help: <mailto:openssl-dev-request at openssl.org?subject=help>
List-Subscribe: <https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev>,
  <mailto:openssl-dev-request at openssl.org?subject=subscribe>
Errors-To: openssl-dev-bounces at openssl.org
Sender: "openssl-dev" <openssl-dev-bounces at openssl.org>

openssl-users:

List-Id: "For users of the software;
  open list" <openssl-users.mta.opensslfoundation.net>
List-Unsubscribe: <https://mta.opensslfoundation.net/mailman/options/openssl-users>,
  <mailto:openssl-users-request at mta.opensslfoundation.net?subject=unsubscribe>
List-Archive: <http://mta.opensslfoundation.net/pipermail/openssl-users/>
List-Post: <mailto:openssl-users at mta.opensslfoundation.net>
List-Help: <mailto:openssl-users-request at mta.opensslfoundation.net?subject=help>
List-Subscribe: <https://mta.opensslfoundation.net/mailman/listinfo/openssl-users>,
  <mailto:openssl-users-request at mta.opensslfoundation.net?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============4545139689028662303=="
Errors-To: openssl-users-bounces at mta.opensslfoundation.net
Sender: "openssl-users" <openssl-users-bounces at openssl.org>

openssl-announce:

List-Id: "Announcements;
  moderated" <openssl-announce.mta.opensslfoundation.net>
X-List-Administrivia: yes
Errors-To: openssl-announce-bounces at mta.opensslfoundation.net
Sender: "openssl-announce" <openssl-announce-bounces at mta.opensslfoundation.net>

From weber at infotech.de  Fri Dec  5 15:16:58 2014
From: weber at infotech.de (Christian Weber)
Date: Fri, 05 Dec 2014 21:16:58 +0100
Subject: [openssl-users] OpenSSL with 64bit Instruction-Set and
 libraries for Windows? (solved)
In-Reply-To: <c53f9523-8a18-477e-b854-2d54a6ee477f@default>
References: <5481DB06.6010500@infotech.de>
 <c53f9523-8a18-477e-b854-2d54a6ee477f@default>
Message-ID: <548212BA.9090108@infotech.de>

Thanks for the response,

meanwhile i have managed to generate 'pure' 64-bit openssl versions. In 
my case the configuration of the ide (VC2013) was simply wrong.
I'm using the ide for viewing the code and for debugging purposes. When 
building the toolkit, the ide was used, too (makefile project).

After switching to the proper platform (destination and sdk) and 
integrating the do_win64 script, the toolkit built flawlwssly.
The dependencies are correct now whilst the referenced windows api dlls 
are still in the same place, e.g. \windows\system32\kernel32.dll.
Semmingly the dlls do contain the code for multiple platforms like fat 
libraries under osx.

Thank you
--
Christian Weber

From weber at infotech.de  Fri Dec  5 15:16:58 2014
From: weber at infotech.de (Christian Weber)
Date: Fri, 05 Dec 2014 21:16:58 +0100
Subject: [openssl-users] OpenSSL with 64bit Instruction-Set and
 libraries for Windows? (solved)
In-Reply-To: <c53f9523-8a18-477e-b854-2d54a6ee477f@default>
References: <5481DB06.6010500@infotech.de>
 <c53f9523-8a18-477e-b854-2d54a6ee477f@default>
Message-ID: <548212BA.9090108@infotech.de>

Thanks for the response,

meanwhile i have managed to generate 'pure' 64-bit openssl versions. In 
my case the configuration of the ide (VC2013) was simply wrong.
I'm using the ide for viewing the code and for debugging purposes. When 
building the toolkit, the ide was used, too (makefile project).

After switching to the proper platform (destination and sdk) and 
integrating the do_win64 script, the toolkit built flawlwssly.
The dependencies are correct now whilst the referenced windows api dlls 
are still in the same place, e.g. \windows\system32\kernel32.dll.
Semmingly the dlls do contain the code for multiple platforms like fat 
libraries under osx.

Thank you
--
Christian Weber

From kurt at roeckx.be  Fri Dec  5 15:46:13 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 5 Dec 2014 21:46:13 +0100
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <548208B5.4040809@iam.tj>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj>
Message-ID: <20141205204613.GA25436@roeckx.be>

On Fri, Dec 05, 2014 at 07:34:13PM +0000, TJ wrote:
> On 26/11/14 02:05, Salz, Rich wrote:> We will soon be freezing the mailing list memberships for a couple of days.
> >
> >We are moving to a new server and upgrading the mail infrastructure
> 
> Are you aware that the headers for the mailman configuration are inconsistent; some specify the previous
> openssl.org email addresses whilst others use the mta.opensslfoundation.net address.

They should all have been changed from mta.opensslfoundation.net
to openssl.org.


Kurt


From Walter.H at mathemainzel.info  Fri Dec  5 15:57:05 2014
From: Walter.H at mathemainzel.info (Walter H.)
Date: Fri, 05 Dec 2014 21:57:05 +0100
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <20141205204613.GA25436@roeckx.be>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj> <20141205204613.GA25436@roeckx.be>
Message-ID: <54821C21.4040806@mathemainzel.info>

On 05.12.2014 21:46, Kurt Roeckx wrote:
> On Fri, Dec 05, 2014 at 07:34:13PM +0000, TJ wrote:
>> On 26/11/14 02:05, Salz, Rich wrote:>  We will soon be freezing the mailing list memberships for a couple of days.
>>> We are moving to a new server and upgrading the mail infrastructure
>> Are you aware that the headers for the mailman configuration are inconsistent; some specify the previous
>> openssl.org email addresses whilst others use the mta.opensslfoundation.net address.
> They should all have been changed from mta.opensslfoundation.net
> to openssl.org.
>
now, what is the email adress in the To for List
which I can use to sort in at my IMAP server?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141205/c5fd5705/attachment.bin>

From kurt at roeckx.be  Fri Dec  5 16:46:12 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 5 Dec 2014 22:46:12 +0100
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <54821C21.4040806@mathemainzel.info>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj> <20141205204613.GA25436@roeckx.be>
 <54821C21.4040806@mathemainzel.info>
Message-ID: <20141205214612.GB27314@roeckx.be>

On Fri, Dec 05, 2014 at 09:57:05PM +0100, Walter H. wrote:
> On 05.12.2014 21:46, Kurt Roeckx wrote:
> >On Fri, Dec 05, 2014 at 07:34:13PM +0000, TJ wrote:
> >>On 26/11/14 02:05, Salz, Rich wrote:>  We will soon be freezing the mailing list memberships for a couple of days.
> >>>We are moving to a new server and upgrading the mail infrastructure
> >>Are you aware that the headers for the mailman configuration are inconsistent; some specify the previous
> >>openssl.org email addresses whilst others use the mta.opensslfoundation.net address.
> >They should all have been changed from mta.opensslfoundation.net
> >to openssl.org.
> >
> now, what is the email adress in the To for List
> which I can use to sort in at my IMAP server?

The recommended way to sort is based on the List-Id.  The name of
the list will stay openssl-users at openssl.org as it always was,
ignore the mta.opensslfoundation.net mails you saw.


Kurt


From philipp_subx at redfish-solutions.com  Fri Dec  5 16:50:00 2014
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Fri, 5 Dec 2014 14:50:00 -0700
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <54821C21.4040806@mathemainzel.info>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj> <20141205204613.GA25436@roeckx.be>
 <54821C21.4040806@mathemainzel.info>
Message-ID: <614A0642-B62E-436A-8DE2-D359DE54ABD0@redfish-solutions.com>

On Dec 5, 2014, at 1:57 PM, Walter H. <Walter.H at mathemainzel.info> wrote:

> On 05.12.2014 21:46, Kurt Roeckx wrote:
>> On Fri, Dec 05, 2014 at 07:34:13PM +0000, TJ wrote:
>>> On 26/11/14 02:05, Salz, Rich wrote:>  We will soon be freezing the mailing list memberships for a couple of days.
>>>> We are moving to a new server and upgrading the mail infrastructure
>>> Are you aware that the headers for the mailman configuration are inconsistent; some specify the previous
>>> openssl.org email addresses whilst others use the mta.opensslfoundation.net address.
>> They should all have been changed from mta.opensslfoundation.net
>> to openssl.org.
>> 
> now, what is the email adress in the To for List
> which I can use to sort in at my IMAP server?


I would use the List-Id: value, actually.

<openssl-users.openssl.org>
<openssl-users.mta.opensslfoundation.net>

Sometimes multiple lists are copied, sometimes the list is Bcc?d.

-Philip


From kurt at roeckx.be  Fri Dec  5 17:08:59 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Fri, 5 Dec 2014 23:08:59 +0100
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <614A0642-B62E-436A-8DE2-D359DE54ABD0@redfish-solutions.com>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj> <20141205204613.GA25436@roeckx.be>
 <54821C21.4040806@mathemainzel.info>
 <614A0642-B62E-436A-8DE2-D359DE54ABD0@redfish-solutions.com>
Message-ID: <20141205220858.GA28474@roeckx.be>

On Fri, Dec 05, 2014 at 02:50:00PM -0700, Philip Prindeville wrote:
> On Dec 5, 2014, at 1:57 PM, Walter H. <Walter.H at mathemainzel.info> wrote:
> 
> > On 05.12.2014 21:46, Kurt Roeckx wrote:
> >> On Fri, Dec 05, 2014 at 07:34:13PM +0000, TJ wrote:
> >>> On 26/11/14 02:05, Salz, Rich wrote:>  We will soon be freezing the mailing list memberships for a couple of days.
> >>>> We are moving to a new server and upgrading the mail infrastructure
> >>> Are you aware that the headers for the mailman configuration are inconsistent; some specify the previous
> >>> openssl.org email addresses whilst others use the mta.opensslfoundation.net address.
> >> They should all have been changed from mta.opensslfoundation.net
> >> to openssl.org.
> >> 
> > now, what is the email adress in the To for List
> > which I can use to sort in at my IMAP server?
> 
> 
> I would use the List-Id: value, actually.
> 
> <openssl-users.openssl.org>
> <openssl-users.mta.opensslfoundation.net>
> 
> Sometimes multiple lists are copied, sometimes the list is Bcc'd.

The 2nd one was temporary, use the first one.


Kurt


From reichert at numachi.com  Fri Dec  5 17:03:54 2014
From: reichert at numachi.com (Brian Reichert)
Date: Fri, 5 Dec 2014 17:03:54 -0500
Subject: [openssl-users] help clear up my misconception about s_client and
	protcols vs ciphersuites
Message-ID: <20141205220354.GB78110@numachi.com>

I'm using openssl s_client 1.0.1e-fips to test a Java-based webapp.
The webapp is showing errors that are cleared up when I update the
OpenJDK package on the server:

  javax.net.ssl.SSLException: java.lang.RuntimeException: Could not generate
  DH keypair

I'm trying to cobble some simple testing tools, using s_client, and
have found behavior that I can't explain.  I'm hoping someone can
provide a clue as to what I'm doing wrong. :)

This fails, and generates the Java exception on the server:

  # openssl s_client -connect localhost:8100 -cipher DEFAULT < /dev/null ; echo $?
  CONNECTED(00000003)
  140593476523848:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:744:
  ---
  no peer certificate available
  ---
  No client certificate CA names sent
  ---
  SSL handshake has read 7 bytes and written 249 bytes
  ---
  New, (NONE), Cipher is (NONE)
  Secure Renegotiation IS NOT supported
  Compression: NONE
  Expansion: NONE
  ---
  1

This succeeds:

  # openssl s_client -connect localhost:8100 -cipher ALL < /dev/null ; echo $?
  CONNECTED(00000003)
  [trimming certificate info]
  ---
  No client certificate CA names sent
  Server Temp Key: DH, 768 bits
  ---
  SSL handshake has read 1279 bytes and written 430 bytes
  ---
  New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA256
  Server public key is 1024 bit
  Secure Renegotiation IS supported
  Compression: NONE
  Expansion: NONE
  SSL-Session:
      Protocol  : TLSv1.2
      Cipher    : DHE-RSA-AES256-SHA256
      Session-ID:
  54822C7267D791574E057DCFB0AC9DF10D675F6C1329BC5DCE3939E82CFD1803
      Session-ID-ctx:
      Master-Key:
  410C247EFB00532F4EC685CAC1E5D9235697E2ACAB0522BD1B0CFCB997514A50A18033D6A2D7605452344E19A34C7987
      Key-Arg   : None
      Krb5 Principal: None
      PSK identity: None
      PSK identity hint: None
      Start Time: 1417817202
      Timeout   : 300 (sec)
      Verify return code: 10 (certificate has expired)
  ---
  DONE
  0

That shows me, if I read this correctly, that 

- I've established a TLSv1.2 session
- using DHE-RSA-AES256-SHA256
- even though this is in the DEFAULT ciphersuite, ALL allows something
  useful to occur

But, if I try to force s_client to expressly use TLSv1.2, the
original error shows up again:

  # openssl s_client -connect localhost:8100 -cipher ALL -tls1_2 < /dev/null ; echo $?
  [identical output as my first invocation]

Or even expressly disabling all other protocols:

  # openssl s_client -connect localhost:8100 -cipher ALL -no_ssl2 -no_ssl3 -no_tls1 -no_tls1_1 -tls1_2 < /dev/null ; echo $?

I guess I'm misusing this tool somehow, and would appreciate a clue...

-- 
Brian Reichert				<reichert at numachi.com>
BSD admin/developer at large	

From Walter.H at mathemainzel.info  Sat Dec  6 04:08:30 2014
From: Walter.H at mathemainzel.info (Walter H.)
Date: Sat, 06 Dec 2014 10:08:30 +0100
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <20141205220858.GA28474@roeckx.be>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj> <20141205204613.GA25436@roeckx.be>
 <54821C21.4040806@mathemainzel.info>
 <614A0642-B62E-436A-8DE2-D359DE54ABD0@redfish-solutions.com>
 <20141205220858.GA28474@roeckx.be>
Message-ID: <5482C78E.6040000@mathemainzel.info>

On 05.12.2014 23:08, Kurt Roeckx wrote:
> On Fri, Dec 05, 2014 at 02:50:00PM -0700, Philip Prindeville wrote:
>> On Dec 5, 2014, at 1:57 PM, Walter H.<Walter.H at mathemainzel.info>  wrote:
>>
>>> On 05.12.2014 21:46, Kurt Roeckx wrote:
>>>> On Fri, Dec 05, 2014 at 07:34:13PM +0000, TJ wrote:
>>>>> On 26/11/14 02:05, Salz, Rich wrote:>   We will soon be freezing the mailing list memberships for a couple of days.
>>>>>> We are moving to a new server and upgrading the mail infrastructure
>>>>> Are you aware that the headers for the mailman configuration are inconsistent; some specify the previous
>>>>> openssl.org email addresses whilst others use the mta.opensslfoundation.net address.
>>>> They should all have been changed from mta.opensslfoundation.net
>>>> to openssl.org.
>>>>
>>> now, what is the email adress in the To for List
>>> which I can use to sort in at my IMAP server?
>>
>> I would use the List-Id: value, actually.
>>
>> <openssl-users.openssl.org>
>> <openssl-users.mta.opensslfoundation.net>
>>
>> Sometimes multiple lists are copied, sometimes the list is Bcc'd.
> The 2nd one was temporary, use the first one.
>
>
> Kurt
then have a try;

by the way: some mails that were sent/received by some through this 
list, don't contain the List-Id ...

Walter


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141206/09778404/attachment.bin>

From kurt at roeckx.be  Sat Dec  6 04:36:16 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sat, 6 Dec 2014 10:36:16 +0100
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <5482C78E.6040000@mathemainzel.info>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj> <20141205204613.GA25436@roeckx.be>
 <54821C21.4040806@mathemainzel.info>
 <614A0642-B62E-436A-8DE2-D359DE54ABD0@redfish-solutions.com>
 <20141205220858.GA28474@roeckx.be>
 <5482C78E.6040000@mathemainzel.info>
Message-ID: <20141206093616.GA3955@roeckx.be>

On Sat, Dec 06, 2014 at 10:08:30AM +0100, Walter H. wrote:
> On 05.12.2014 23:08, Kurt Roeckx wrote:
> >On Fri, Dec 05, 2014 at 02:50:00PM -0700, Philip Prindeville wrote:
> >>On Dec 5, 2014, at 1:57 PM, Walter H.<Walter.H at mathemainzel.info>  wrote:
> >>
> >>>On 05.12.2014 21:46, Kurt Roeckx wrote:
> >>>>On Fri, Dec 05, 2014 at 07:34:13PM +0000, TJ wrote:
> >>>>>On 26/11/14 02:05, Salz, Rich wrote:>   We will soon be freezing the mailing list memberships for a couple of days.
> >>>>>>We are moving to a new server and upgrading the mail infrastructure
> >>>>>Are you aware that the headers for the mailman configuration are inconsistent; some specify the previous
> >>>>>openssl.org email addresses whilst others use the mta.opensslfoundation.net address.
> >>>>They should all have been changed from mta.opensslfoundation.net
> >>>>to openssl.org.
> >>>>
> >>>now, what is the email adress in the To for List
> >>>which I can use to sort in at my IMAP server?
> >>
> >>I would use the List-Id: value, actually.
> >>
> >><openssl-users.openssl.org>
> >><openssl-users.mta.opensslfoundation.net>
> >>
> >>Sometimes multiple lists are copied, sometimes the list is Bcc'd.
> >The 2nd one was temporary, use the first one.
> >
> >
> >Kurt
> then have a try;
> 
> by the way: some mails that were sent/received by some through this list,
> don't contain the List-Id ...

We just changed from majordomo that doesn't support List-Id's to
mailman that does.  All the mails since the move to mailman should
have had a List-Id, but at some point it contained
mta.opensslfoundation.net and was changed to openssl.org


Kurt


From hoomanfazaeli at gmail.com  Mon Dec  8 09:36:28 2014
From: hoomanfazaeli at gmail.com (Hooman Fazaeli)
Date: Mon, 08 Dec 2014 18:06:28 +0330
Subject: [openssl-users] Strange SSL_read behavior
Message-ID: <5485B76C.3000600@gmail.com>

Hi,

I have two (unrelated) questions and would appreciate if anybody
provides some answers:

1. The SSL_read in my http server app always reads the first byte of
    http request, instead of the whole. To read the rest, I should do
    further SSL_reads:

     while (SSL_read(...) > 0)
            copy read data to request buffer;

    I have seen this pattern with firefox, IE and opera as client.

    I know that openssl has received the whole request record because I
    do not write any data to the read bio of the SSL object between
    SSL_read calls in the loop.

    So, the question is, why SSL_read does not return all the data in
    the first call?

2. Is there any patch around to add support of custom TLS extensions to 1.0.1j?


-- 
Best regards
Hooman Fazaeli

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141208/50e6455e/attachment.html>

From dthompson at prinpay.com  Mon Dec  8 20:01:45 2014
From: dthompson at prinpay.com (Dave Thompson)
Date: Mon, 8 Dec 2014 20:01:45 -0500
Subject: [openssl-users] Strange SSL_read behavior: 1/N-1
Message-ID: <001e01d0134b$b5adb700$21092500$@prinpay.com>

> From: openssl-users On Behalf Of Hooman Fazaeli
> Sent: Monday, December 08, 2014 09:36

> 1. The SSL_read in my http server app always reads the first byte of 
>?? http request, instead of the whole. To read the rest, I should do 
>?? further SSL_reads: <snip>
>?? I have seen this pattern with firefox, IE and opera as client. 

This is/was the consensus mitigation for BEAST in 2011. 
Senders (browsers etc) break a record of N bytes into 
two SSL records, 1 byte then N-1; this makes the IV for 
the second record (e.g. session cookies) unpredictable.
Although SSL/TLS is defined as a stream service and an 
implementation could recombine these, OpenSSL doesn?t.

This mitigation is only needed for CBC ciphers in protocols 
below TLS1.1. I don't know if (all? some?) browsers only 
implement when needed, but you could try to make sure 
your server supports at least 1.1 (and OpenSSL 1.0.1* 
can support 1.2 as well), and supports and possibly prefers
RC4 (which is the other mitigation for IV, but now itself 
vulnerable to other attacks e.g. Paterson et al at RHUL).

But given that SSL/TLS is a stream service and any implementation 
*must* fragment a record over 16K and *may* choose to fragment 
a smaller record for any reason it likes, your receiver should be 
doing the read-until-complete or in some cases read-until-timeout 
loop anyway. Note TCP (and plaintext HTTP) has this same feature 
and HTTP/TCP does actually fragment in numerous real cases 
including at sizes of realistic HTTP requests. HTTP is carefully 
designed so that both requests and responses are delimited 
either by a distinct close or length header(s) precisely so that 
it works robustly and reliably over such stream channels.



From graeme.perrow at sap.com  Tue Dec  9 11:46:19 2014
From: graeme.perrow at sap.com (Perrow, Graeme)
Date: Tue, 9 Dec 2014 16:46:19 +0000
Subject: [openssl-users] Building a DLL that includes the FIPS static
	libraries
Message-ID: <6378BFFB8601BD438AD9AF3CA610548E55DFAB12@DEWDFEMB16B.global.corp.sap>

I am trying to build a Windows DLL that includes the static OpenSSL FIPS libraries. I built the FIPS libraries using the "perl Configure fips --with-fipslibdir=... -no-shared" and then "nmake -f ms\nt.mak". I'm using openssl-fips-2.0.5, openssl-1.0.1j, and MS Visual Studio 2010.

Now I'm trying to link the resulting libraries into my DLL. I've followed the instructions in the FIPS 2.0 User's Guide, setting a bunch of environment variables (FIPS_LINK, FIPS_CC, FIPS_CC_ARGS, etc.) and then called fipslink.pl. But I'm getting a "First stage Link failure".

It reports "Integrity check OK" and then compiles fips_premain.c, but when linking the DLL I get a bunch of "locally defined symbol _time64 imported" warnings (as well as strncmp, _errno, abort, fprintf, and others), and then some unresolved external symbols including:

__imp_strncpy
__imp_qsort
__imp_wcsstr
__imp_vsnwprintf

All of the errors come from libeayfips32.lib, libeaycompat32.lib, and ssleay32.lib.

I've played around with /NODEFAULTLIB:msvcrt and /NODEFAULTLIB:libcmtd, and building with /MT or /MD or neither, but I keep getting linker errors each time. What am I missing?

Thanks
Graeme Perrow


From Michael.Wojcik at microfocus.com  Tue Dec  9 12:03:49 2014
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 9 Dec 2014 17:03:49 +0000
Subject: [openssl-users] Strange SSL_read behavior: 1/N-1
In-Reply-To: <001e01d0134b$b5adb700$21092500$@prinpay.com>
References: <001e01d0134b$b5adb700$21092500$@prinpay.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088012E5F548E@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Dave Thompson
> Sent: Monday, December 08, 2014 20:02
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Strange SSL_read behavior: 1/N-1
> 
> But given that SSL/TLS is a stream service and any implementation
> *must* fragment a record over 16K and *may* choose to fragment a smaller
> record for any reason it likes, your receiver should be doing the read-until-
> complete or in some cases read-until-timeout loop anyway.

Absolutely. This is one of the basic requirements of TCP. OpenSSL exposes it to callers because hiding it can leave an application blocked forever (if an incomplete record is never completed), and the application has to decide how to deal with that case.

There are variations on this pattern, such as the non-blocking-check-for-readability approach (often combined with multiplexing), but they all boil down to receiving until the record is complete or some other condition occurs (error or timeout or application decides to give up or whatever).

> Note TCP (and
> plaintext HTTP) has this same feature and HTTP/TCP does actually fragment
> in numerous real cases including at sizes of realistic HTTP requests. HTTP is
> carefully designed so that both requests and responses are delimited either
> by a distinct close or length header(s) precisely so that it works robustly and
> reliably over such stream channels.

Actually HTTP/1.1 has *five* mechanisms for delimiting messages:

- If the message cannot have a body, then it ends at the body delimiter (CRLF CRLF).
- The Content-length header.
- The Chunked transfer encoding, in which the end of the message is indicated by a zero-length chunk, possibly followed by trailers. This may now be the most common way HTTP messages with bodies are delimited, since it has useful advantages over Content-length.
- Closing the conversation. This is only allowed on the server side, because RFC 2616 incorrectly asserts that use by the client would prevent receiving a response. (In fact the client could perform a half-close, when the transport is TCP; RFC 2616 ignores this possibility.)
- Using a self-delimiting message encoding such as mime-multipart. I've never seen this used in the real world.

I mention only to emphasize Dave's point, which is that TCP, and other stream services, delegate determining record boundaries to the application protocol, and that is often quite a complicated process.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com

From amarendra.godbole at gmail.com  Tue Dec  9 14:07:01 2014
From: amarendra.godbole at gmail.com (Amarendra Godbole)
Date: Tue, 9 Dec 2014 11:07:01 -0800
Subject: [openssl-users] CVE-2014- and OpenSSL?
Message-ID: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>

So Adam Langley writes "SSLv3 decoding function was used with TLS,
then the POODLE attack would work, even against TLS connections." on
his the latest POODLE affecting TLS 1.x.
(https://www.imperialviolet.org/).

I also received a notification from Symantec's DeepSight, that states:
"OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure
Vulnerability".

However, I could not find more information on OpenSSL's web-site about
POODLE-biting-again. Did I miss any notification? Thanks.

-Amarendra

From rsalz at akamai.com  Tue Dec  9 14:26:16 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Dec 2014 14:26:16 -0500
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>

> I also received a notification from Symantec's DeepSight, that states:
> "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure
> Vulnerability".

Did Symantic really label it an OpenSSL CVE?  That's wrong.

OpenSSL does not have this defect.

	/r$


From bwats9999 at gmail.com  Tue Dec  9 14:44:03 2014
From: bwats9999 at gmail.com (Brian Watson)
Date: Tue, 9 Dec 2014 13:44:03 -0600
Subject: [openssl-users] Help with using a dynamic engine with SSL_CTX
Message-ID: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>

Hi,
   I am doing the following:

1. I have a dynamic engine that I would like to use to produce random
numbers on Android (aosp).
2. I can successfully load the dynamic engine by using the Android
OpenSSLEngine.getInstance() which takes care of loading the engine and I
can see that the binding is there via bind_engine and bind_helper via some
debug prints that I have put in the engine. I follow this up by calling
ENGINE_set_default() for ENGINE_METHOD_RAND. I am using the Apache Harmony
jsse library.
3. Some time later there is a call to SSL_CTX_new() which starts the
process of establishing the TLS session, etc.
4. I would like to see my random number generator get invoked to provide
random numbers when needed, but for some reason the ssleay one is being
called.
5. I can open an adb shell and run the openssl command and explicitly load
the engine via:

openssl engine dynamic ?pre SO_PATH:/system/lib/ssl/engines/MyEngine.so
?pre ID:myengine ?pre LOAD. With this I see my random number generator get
used, but when I try to do this programatically it doesn't get called.


I have a couple of questions:


1. Should this work even when using the SSL_CTX... api's?

2. Am I setting up the engine too soon and then the SSL_CTX.. commands
clear them out?


I've looked around a lot so any help would be greatly appreciated!


Thanks,

   BW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141209/a0f1822c/attachment.html>

From rituparna.mitra at hp.com  Tue Dec  9 14:46:43 2014
From: rituparna.mitra at hp.com (Mitra, Rituparna (STSD))
Date: Tue, 9 Dec 2014 19:46:43 +0000
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
Message-ID: <29708C6ADBFC724F9F92546A0AE135AC334FA5D6@G4W3229.americas.hpqcorp.net>

Hi,

>> OpenSSL does not have this defect.

Does this mean that openssl is not vulnerable to this issue even if TLS 1.0/TLS 1.1 are enabled? 
Are all versions of openssl (0.9.8* and 1.0.1*) free from impact?

Thanks,
RMitra


-----Original Message-----
From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich
Sent: Wednesday, December 10, 2014 12:56 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] CVE-2014- and OpenSSL?

> I also received a notification from Symantec's DeepSight, that states:
> "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure 
> Vulnerability".

Did Symantic really label it an OpenSSL CVE?  That's wrong.

OpenSSL does not have this defect.

	/r$

_______________________________________________
openssl-users mailing list
openssl-users at openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

From rsalz at akamai.com  Tue Dec  9 14:52:16 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Dec 2014 14:52:16 -0500
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <29708C6ADBFC724F9F92546A0AE135AC334FA5D6@G4W3229.americas.hpqcorp.net>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
 <29708C6ADBFC724F9F92546A0AE135AC334FA5D6@G4W3229.americas.hpqcorp.net>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BED9@USMBX1.msg.corp.akamai.com>

> Does this mean that openssl is not vulnerable to this issue even if TLS 1.0/TLS 1.1 are enabled?
> Are all versions of openssl (0.9.8* and 1.0.1*) free from impact?

OpenSSL does not have this defect.



From alvherre at alvh.no-ip.org  Tue Dec  9 14:48:23 2014
From: alvherre at alvh.no-ip.org (Alvaro Herrera)
Date: Tue, 9 Dec 2014 16:48:23 -0300
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <20141206093616.GA3955@roeckx.be>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj> <20141205204613.GA25436@roeckx.be>
 <54821C21.4040806@mathemainzel.info>
 <614A0642-B62E-436A-8DE2-D359DE54ABD0@redfish-solutions.com>
 <20141205220858.GA28474@roeckx.be>
 <5482C78E.6040000@mathemainzel.info>
 <20141206093616.GA3955@roeckx.be>
Message-ID: <20141209194823.GA1774@alvh.no-ip.org>

Kurt Roeckx wrote:

> Kurt
> 
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

The footer still says mta.opensslfoundation.net ... is this intentional?

-- 
?lvaro Herrera

From rsalz at akamai.com  Tue Dec  9 15:05:09 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Dec 2014 15:05:09 -0500
Subject: [openssl-users] Freeze to mailing list memberships
In-Reply-To: <20141209194823.GA1774@alvh.no-ip.org>
References: <2A0EFB9C05D0164E98F19BB0AF3708C71D53CC4007@USMBX1.msg.corp.akamai.com>
 <548208B5.4040809@iam.tj> <20141205204613.GA25436@roeckx.be>
 <54821C21.4040806@mathemainzel.info>
 <614A0642-B62E-436A-8DE2-D359DE54ABD0@redfish-solutions.com>
 <20141205220858.GA28474@roeckx.be> <5482C78E.6040000@mathemainzel.info>
 <20141206093616.GA3955@roeckx.be> <20141209194823.GA1774@alvh.no-ip.org>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEF8@USMBX1.msg.corp.akamai.com>

> > openssl-users mailing list
> > openssl-users at openssl.org
> > https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
> 
> The footer still says mta.opensslfoundation.net ... is this intentional?

Yes, until we make some more DNS changes as we move our infrastructure forward.

From beldmit at gmail.com  Tue Dec  9 14:52:09 2014
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Tue, 9 Dec 2014 23:52:09 +0400
Subject: [openssl-users] Help with using a dynamic engine with SSL_CTX
In-Reply-To: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>
References: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>
Message-ID: <CADqLbzLs6JjwaSx=cNudqz=7gpv9_c5QenSXajV1bqYotTFEDg@mail.gmail.com>

Hello!

Do you set your RNG as default when the engine is loaded?

On Tue, Dec 9, 2014 at 10:44 PM, Brian Watson <bwats9999 at gmail.com> wrote:

> Hi,
>    I am doing the following:
>
> 1. I have a dynamic engine that I would like to use to produce random
> numbers on Android (aosp).
> 2. I can successfully load the dynamic engine by using the Android
> OpenSSLEngine.getInstance() which takes care of loading the engine and I
> can see that the binding is there via bind_engine and bind_helper via some
> debug prints that I have put in the engine. I follow this up by calling
> ENGINE_set_default() for ENGINE_METHOD_RAND. I am using the Apache Harmony
> jsse library.
> 3. Some time later there is a call to SSL_CTX_new() which starts the
> process of establishing the TLS session, etc.
> 4. I would like to see my random number generator get invoked to provide
> random numbers when needed, but for some reason the ssleay one is being
> called.
> 5. I can open an adb shell and run the openssl command and explicitly load
> the engine via:
>
> openssl engine dynamic ?pre SO_PATH:/system/lib/ssl/engines/MyEngine.so
> ?pre ID:myengine ?pre LOAD. With this I see my random number generator get
> used, but when I try to do this programatically it doesn't get called.
>
>
> I have a couple of questions:
>
>
> 1. Should this work even when using the SSL_CTX... api's?
>
> 2. Am I setting up the engine too soon and then the SSL_CTX.. commands
> clear them out?
>
>
> I've looked around a lot so any help would be greatly appreciated!
>
>
> Thanks,
>
>    BW
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141209/cdb66f1a/attachment.html>

From arthur_tsang at hotmail.com  Tue Dec  9 15:30:58 2014
From: arthur_tsang at hotmail.com (Arthur Tsang)
Date: Tue, 9 Dec 2014 12:30:58 -0800
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
Message-ID: <CAHCRzeiiKoruBgxHdVqxe88V_ouu=sBCD__DvsyCFre3+r2L-w@mail.gmail.com>

Hi Rich,

do we have some formal announcement that openssl is not vulnerable for
POODLE in TLS?  or can you explain why Openssl is not affected?  if
symantec is issuing notification like that, i guess, a lot of management
will demand explanations.  Thanks,

Thanks,
Arthur

On Tue, Dec 9, 2014 at 11:26 AM, Salz, Rich <rsalz at akamai.com> wrote:

> > I also received a notification from Symantec's DeepSight, that states:
> > "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure
> > Vulnerability".
>
> Did Symantic really label it an OpenSSL CVE?  That's wrong.
>
> OpenSSL does not have this defect.
>
>         /r$
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>


-- 
Thanks,
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141209/32d34f54/attachment.html>

From noloader at gmail.com  Tue Dec  9 15:46:02 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Tue, 9 Dec 2014 15:46:02 -0500
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
Message-ID: <CAH8yC8nz04ZnHxm2QkpDKiGTryrx+PsDo5aYwSTcxW7Ad_2dFA@mail.gmail.com>

On Tue, Dec 9, 2014 at 2:07 PM, Amarendra Godbole
<amarendra.godbole at gmail.com> wrote:
> So Adam Langley writes "SSLv3 decoding function was used with TLS,
> then the POODLE attack would work, even against TLS connections." on
> his the latest POODLE affecting TLS 1.x.
> (https://www.imperialviolet.org/).
>
> I also received a notification from Symantec's DeepSight, that states:
> "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure
> Vulnerability".
>
> However, I could not find more information on OpenSSL's web-site about
> POODLE-biting-again. Did I miss any notification? Thanks.
Here's some more reading:
https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls

There's nothing specific to OpenSSL. Its a design defect in the
protocols (its been well known that TLS 1.0 had the same oracle as
SSLv3 since only the IV changed between them).

Its not surprising that a PoC demonstrates it against TLS 1.0. Many
have been been waiting for it.

It looks like Ubuntu is going to have to enable TLS 1.1 and 1.2 in
12.04 LTS for clients.
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576.

From rsalz at akamai.com  Tue Dec  9 15:49:11 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 9 Dec 2014 15:49:11 -0500
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <CAHCRzeiiKoruBgxHdVqxe88V_ouu=sBCD__DvsyCFre3+r2L-w@mail.gmail.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
 <CAHCRzeiiKoruBgxHdVqxe88V_ouu=sBCD__DvsyCFre3+r2L-w@mail.gmail.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BF35@USMBX1.msg.corp.akamai.com>

Ask Symantec why they labeled it as an openssl CVE; it is not.  Read AGL?s blog post[1].  Two specific implementations are identified and a different crypto library (NSS) is implicated.

This is about as formal a statement as you?re going to get. ?

[1] https://www.imperialviolet.org/2014/12/08/poodleagain.html

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141209/34507d98/attachment-0001.html>

From amarendra.godbole at gmail.com  Tue Dec  9 15:54:55 2014
From: amarendra.godbole at gmail.com (Amarendra Godbole)
Date: Tue, 9 Dec 2014 12:54:55 -0800
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
Message-ID: <CAC1DtRnyPXE4z0KortBq5O0BMQcF66EgY5oX0MxGy5Jke-+iJQ@mail.gmail.com>

On Tue, Dec 9, 2014 at 11:26 AM, Salz, Rich <rsalz at akamai.com> wrote:
>> I also received a notification from Symantec's DeepSight, that states:
>> "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure
>> Vulnerability".
>
> Did Symantic really label it an OpenSSL CVE?  That's wrong.
>
> OpenSSL does not have this defect.
[...]

Possible - these are automated feeds, and things can get mixed up.

Thanks for the clarification.

-Amarendra

From matt at openssl.org  Tue Dec  9 16:00:18 2014
From: matt at openssl.org (Matt Caswell)
Date: Tue, 09 Dec 2014 21:00:18 +0000
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <CAHCRzeiiKoruBgxHdVqxe88V_ouu=sBCD__DvsyCFre3+r2L-w@mail.gmail.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
 <CAHCRzeiiKoruBgxHdVqxe88V_ouu=sBCD__DvsyCFre3+r2L-w@mail.gmail.com>
Message-ID: <548762E2.4000002@openssl.org>


On 09/12/14 20:30, Arthur Tsang wrote:
> Hi Rich,
>
> do we have some formal announcement that openssl is not vulnerable for
> POODLE in TLS?  or can you explain why Openssl is not affected?  if
> symantec is issuing notification like that, i guess, a lot of
> management will demand explanations.  Thanks,
>
>
Adam Langley's post provides a good explanation of this problem:
https://www.imperialviolet.org/2014/12/08/poodleagain.html

The specification of SSLv3 did not specify the format of padding bytes
to be used when encrypting data. This led to an oracle attack.

TLS on the other hand *does* specify this, and therefore (if you
implement it correctly) is not vulnerable to this oracle attack. A TLS
library needs to check the padding bytes are correctly formatted and
fail if not. The problem is that it is possible to implement a TLS
library and still use the SSLv3 decryption routines when working with
TLS (i.e. don't check the padding bytes). This *will* work, although it
is not compliant with the spec. If you fail to check the padding bytes
then your TLS implementation is vulnerable to the same POODLE oracle attack.

I can confirm that OpenSSL is compliant with the spec and *does* check
the padding bytes. It is therefore is not vulnerable to this issue.

Matt


From bwats9999 at gmail.com  Tue Dec  9 15:19:50 2014
From: bwats9999 at gmail.com (Brian Watson)
Date: Tue, 9 Dec 2014 14:19:50 -0600
Subject: [openssl-users] Help with using a dynamic engine with SSL_CTX
In-Reply-To: <CADqLbzLs6JjwaSx=cNudqz=7gpv9_c5QenSXajV1bqYotTFEDg@mail.gmail.com>
References: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>
 <CADqLbzLs6JjwaSx=cNudqz=7gpv9_c5QenSXajV1bqYotTFEDg@mail.gmail.com>
Message-ID: <CAGhNzw369cPV1CTB0PhYnw_=Ym9VkSFAYyo_C4yV32WSQPFihg@mail.gmail.com>

I thought that's what the following does:

ENGINE_set_default(engine, ENGINE_METHOD_RAND).

I'm also trying to figure out in rand_lib.c and RAND_get_rand_method() what
causes default_RAND_meth to change.

Thanks,
   BW

On Tue, Dec 9, 2014 at 1:52 PM, Dmitry Belyavsky <beldmit at gmail.com> wrote:

> Hello!
>
> Do you set your RNG as default when the engine is loaded?
>
> On Tue, Dec 9, 2014 at 10:44 PM, Brian Watson <bwats9999 at gmail.com> wrote:
>
>> Hi,
>>    I am doing the following:
>>
>> 1. I have a dynamic engine that I would like to use to produce random
>> numbers on Android (aosp).
>> 2. I can successfully load the dynamic engine by using the Android
>> OpenSSLEngine.getInstance() which takes care of loading the engine and I
>> can see that the binding is there via bind_engine and bind_helper via some
>> debug prints that I have put in the engine. I follow this up by calling
>> ENGINE_set_default() for ENGINE_METHOD_RAND. I am using the Apache Harmony
>> jsse library.
>> 3. Some time later there is a call to SSL_CTX_new() which starts the
>> process of establishing the TLS session, etc.
>> 4. I would like to see my random number generator get invoked to provide
>> random numbers when needed, but for some reason the ssleay one is being
>> called.
>> 5. I can open an adb shell and run the openssl command and explicitly
>> load the engine via:
>>
>> openssl engine dynamic ?pre SO_PATH:/system/lib/ssl/engines/MyEngine.so
>> ?pre ID:myengine ?pre LOAD. With this I see my random number generator get
>> used, but when I try to do this programatically it doesn't get called.
>>
>>
>> I have a couple of questions:
>>
>>
>> 1. Should this work even when using the SSL_CTX... api's?
>>
>> 2. Am I setting up the engine too soon and then the SSL_CTX.. commands
>> clear them out?
>>
>>
>> I've looked around a lot so any help would be greatly appreciated!
>>
>>
>> Thanks,
>>
>>    BW
>>
>> _______________________________________________
>> openssl-users mailing list
>> openssl-users at openssl.org
>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>
>>
>
>
> --
> SY, Dmitry Belyavsky
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141209/cd005962/attachment.html>

From tina.s.olson at lmco.com  Tue Dec  9 15:43:21 2014
From: tina.s.olson at lmco.com (Olson, Tina S)
Date: Tue, 9 Dec 2014 20:43:21 +0000
Subject: [openssl-users] Please unsubscribe me from these emails.
Message-ID: <822B552AD88FC84887C69FEF75A0A0083E0AA350@HDXDSP33.us.lmco.com>



Tina Olson
Systems Integration Analyst-Staff, EBS
Lockheed Martin Corporation
Telecommuter - Valley Forge, PA
O 484-369-6001 | M 484-557-1003 | E Tina.S.Olson at lmco.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141209/cf117f45/attachment.html>

From arthur_tsang at hotmail.com  Tue Dec  9 16:58:54 2014
From: arthur_tsang at hotmail.com (Arthur Tsang)
Date: Tue, 9 Dec 2014 13:58:54 -0800
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <548762E2.4000002@openssl.org>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BEB3@USMBX1.msg.corp.akamai.com>
 <CAHCRzeiiKoruBgxHdVqxe88V_ouu=sBCD__DvsyCFre3+r2L-w@mail.gmail.com>
 <548762E2.4000002@openssl.org>
Message-ID: <CAHCRzegLq95QR4SnJf7O-zxJ7Qxo471+B2obZzHQCQxQUZOJQA@mail.gmail.com>

thanks for the clarification.

On Tue, Dec 9, 2014 at 1:00 PM, Matt Caswell <matt at openssl.org> wrote:

>
> On 09/12/14 20:30, Arthur Tsang wrote:
> > Hi Rich,
> >
> > do we have some formal announcement that openssl is not vulnerable for
> > POODLE in TLS?  or can you explain why Openssl is not affected?  if
> > symantec is issuing notification like that, i guess, a lot of
> > management will demand explanations.  Thanks,
> >
> >
> Adam Langley's post provides a good explanation of this problem:
> https://www.imperialviolet.org/2014/12/08/poodleagain.html
>
> The specification of SSLv3 did not specify the format of padding bytes
> to be used when encrypting data. This led to an oracle attack.
>
> TLS on the other hand *does* specify this, and therefore (if you
> implement it correctly) is not vulnerable to this oracle attack. A TLS
> library needs to check the padding bytes are correctly formatted and
> fail if not. The problem is that it is possible to implement a TLS
> library and still use the SSLv3 decryption routines when working with
> TLS (i.e. don't check the padding bytes). This *will* work, although it
> is not compliant with the spec. If you fail to check the padding bytes
> then your TLS implementation is vulnerable to the same POODLE oracle
> attack.
>
> I can confirm that OpenSSL is compliant with the spec and *does* check
> the padding bytes. It is therefore is not vulnerable to this issue.
>
> Matt
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>


-- 
Thanks,
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141209/5ff861f3/attachment-0001.html>

From beldmit at gmail.com  Wed Dec 10 02:06:02 2014
From: beldmit at gmail.com (Dmitry Belyavsky)
Date: Wed, 10 Dec 2014 10:06:02 +0300
Subject: [openssl-users] Help with using a dynamic engine with SSL_CTX
In-Reply-To: <CAGhNzw369cPV1CTB0PhYnw_=Ym9VkSFAYyo_C4yV32WSQPFihg@mail.gmail.com>
References: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>
 <CADqLbzLs6JjwaSx=cNudqz=7gpv9_c5QenSXajV1bqYotTFEDg@mail.gmail.com>
 <CAGhNzw369cPV1CTB0PhYnw_=Ym9VkSFAYyo_C4yV32WSQPFihg@mail.gmail.com>
Message-ID: <CADqLbzJKNVkMmZhS0tppznae_-T2Y+w9-QVO764ZHKHbAZUPJw@mail.gmail.com>

Hello Brian,

Do you call ENGINE_set_RAND function?

On Tue, Dec 9, 2014 at 11:19 PM, Brian Watson <bwats9999 at gmail.com> wrote:

> I thought that's what the following does:
>
> ENGINE_set_default(engine, ENGINE_METHOD_RAND).
>
> I'm also trying to figure out in rand_lib.c and RAND_get_rand_method()
> what causes default_RAND_meth to change.
>
> Thanks,
>    BW
>
> On Tue, Dec 9, 2014 at 1:52 PM, Dmitry Belyavsky <beldmit at gmail.com>
> wrote:
>
>> Hello!
>>
>> Do you set your RNG as default when the engine is loaded?
>>
>> On Tue, Dec 9, 2014 at 10:44 PM, Brian Watson <bwats9999 at gmail.com>
>> wrote:
>>
>>> Hi,
>>>    I am doing the following:
>>>
>>> 1. I have a dynamic engine that I would like to use to produce random
>>> numbers on Android (aosp).
>>> 2. I can successfully load the dynamic engine by using the Android
>>> OpenSSLEngine.getInstance() which takes care of loading the engine and I
>>> can see that the binding is there via bind_engine and bind_helper via some
>>> debug prints that I have put in the engine. I follow this up by calling
>>> ENGINE_set_default() for ENGINE_METHOD_RAND. I am using the Apache Harmony
>>> jsse library.
>>> 3. Some time later there is a call to SSL_CTX_new() which starts the
>>> process of establishing the TLS session, etc.
>>> 4. I would like to see my random number generator get invoked to provide
>>> random numbers when needed, but for some reason the ssleay one is being
>>> called.
>>> 5. I can open an adb shell and run the openssl command and explicitly
>>> load the engine via:
>>>
>>> openssl engine dynamic ?pre SO_PATH:/system/lib/ssl/engines/MyEngine.so
>>> ?pre ID:myengine ?pre LOAD. With this I see my random number generator get
>>> used, but when I try to do this programatically it doesn't get called.
>>>
>>>
>>> I have a couple of questions:
>>>
>>>
>>> 1. Should this work even when using the SSL_CTX... api's?
>>>
>>> 2. Am I setting up the engine too soon and then the SSL_CTX.. commands
>>> clear them out?
>>>
>>>
>>> I've looked around a lot so any help would be greatly appreciated!
>>>
>>>
>>> Thanks,
>>>
>>>    BW
>>>
>>> _______________________________________________
>>> openssl-users mailing list
>>> openssl-users at openssl.org
>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>
>>>
>>
>>
>> --
>> SY, Dmitry Belyavsky
>>
>> _______________________________________________
>> openssl-users mailing list
>> openssl-users at openssl.org
>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>
>>
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>


-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141210/b46cfb67/attachment.html>

From bwats9999 at gmail.com  Wed Dec 10 09:25:35 2014
From: bwats9999 at gmail.com (Brian Watson)
Date: Wed, 10 Dec 2014 08:25:35 -0600
Subject: [openssl-users] Help with using a dynamic engine with SSL_CTX
In-Reply-To: <CADqLbzJKNVkMmZhS0tppznae_-T2Y+w9-QVO764ZHKHbAZUPJw@mail.gmail.com>
References: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>
 <CADqLbzLs6JjwaSx=cNudqz=7gpv9_c5QenSXajV1bqYotTFEDg@mail.gmail.com>
 <CAGhNzw369cPV1CTB0PhYnw_=Ym9VkSFAYyo_C4yV32WSQPFihg@mail.gmail.com>
 <CADqLbzJKNVkMmZhS0tppznae_-T2Y+w9-QVO764ZHKHbAZUPJw@mail.gmail.com>
Message-ID: <CAGhNzw1hX+ywkTECg0_fzTBf7C4EWfgKF3wArzYUQ3zO0-0phw@mail.gmail.com>

I didn't call that one, but I'll give it a try. I also read that if someone
subsequently calls ENGINE_load_builtin_engines()that it'll reset things
back to how they were so I'll look at that also.

Thanks,
  BW

On Wed, Dec 10, 2014 at 1:06 AM, Dmitry Belyavsky <beldmit at gmail.com> wrote:

> Hello Brian,
>
> Do you call ENGINE_set_RAND function?
>
> On Tue, Dec 9, 2014 at 11:19 PM, Brian Watson <bwats9999 at gmail.com> wrote:
>
>> I thought that's what the following does:
>>
>> ENGINE_set_default(engine, ENGINE_METHOD_RAND).
>>
>> I'm also trying to figure out in rand_lib.c and RAND_get_rand_method()
>> what causes default_RAND_meth to change.
>>
>> Thanks,
>>    BW
>>
>> On Tue, Dec 9, 2014 at 1:52 PM, Dmitry Belyavsky <beldmit at gmail.com>
>> wrote:
>>
>>> Hello!
>>>
>>> Do you set your RNG as default when the engine is loaded?
>>>
>>> On Tue, Dec 9, 2014 at 10:44 PM, Brian Watson <bwats9999 at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>    I am doing the following:
>>>>
>>>> 1. I have a dynamic engine that I would like to use to produce random
>>>> numbers on Android (aosp).
>>>> 2. I can successfully load the dynamic engine by using the Android
>>>> OpenSSLEngine.getInstance() which takes care of loading the engine and I
>>>> can see that the binding is there via bind_engine and bind_helper via some
>>>> debug prints that I have put in the engine. I follow this up by calling
>>>> ENGINE_set_default() for ENGINE_METHOD_RAND. I am using the Apache Harmony
>>>> jsse library.
>>>> 3. Some time later there is a call to SSL_CTX_new() which starts the
>>>> process of establishing the TLS session, etc.
>>>> 4. I would like to see my random number generator get invoked to
>>>> provide random numbers when needed, but for some reason the ssleay one is
>>>> being called.
>>>> 5. I can open an adb shell and run the openssl command and explicitly
>>>> load the engine via:
>>>>
>>>> openssl engine dynamic ?pre SO_PATH:/system/lib/ssl/engines/MyEngine.so
>>>> ?pre ID:myengine ?pre LOAD. With this I see my random number generator get
>>>> used, but when I try to do this programatically it doesn't get called.
>>>>
>>>>
>>>> I have a couple of questions:
>>>>
>>>>
>>>> 1. Should this work even when using the SSL_CTX... api's?
>>>>
>>>> 2. Am I setting up the engine too soon and then the SSL_CTX.. commands
>>>> clear them out?
>>>>
>>>>
>>>> I've looked around a lot so any help would be greatly appreciated!
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>    BW
>>>>
>>>> _______________________________________________
>>>> openssl-users mailing list
>>>> openssl-users at openssl.org
>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>
>>>>
>>>
>>>
>>> --
>>> SY, Dmitry Belyavsky
>>>
>>> _______________________________________________
>>> openssl-users mailing list
>>> openssl-users at openssl.org
>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>
>>>
>>
>> _______________________________________________
>> openssl-users mailing list
>> openssl-users at openssl.org
>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>
>>
>
>
> --
> SY, Dmitry Belyavsky
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141210/93ee2ae1/attachment.html>

From bwats9999 at gmail.com  Wed Dec 10 11:35:34 2014
From: bwats9999 at gmail.com (Brian Watson)
Date: Wed, 10 Dec 2014 10:35:34 -0600
Subject: [openssl-users] Help with using a dynamic engine with SSL_CTX
In-Reply-To: <CAGhNzw1hX+ywkTECg0_fzTBf7C4EWfgKF3wArzYUQ3zO0-0phw@mail.gmail.com>
References: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>
 <CADqLbzLs6JjwaSx=cNudqz=7gpv9_c5QenSXajV1bqYotTFEDg@mail.gmail.com>
 <CAGhNzw369cPV1CTB0PhYnw_=Ym9VkSFAYyo_C4yV32WSQPFihg@mail.gmail.com>
 <CADqLbzJKNVkMmZhS0tppznae_-T2Y+w9-QVO764ZHKHbAZUPJw@mail.gmail.com>
 <CAGhNzw1hX+ywkTECg0_fzTBf7C4EWfgKF3wArzYUQ3zO0-0phw@mail.gmail.com>
Message-ID: <CAGhNzw17UN6kpU0TOppuWCjMGBFJe-mX6MOv4+6w9s5L8VTdTQ@mail.gmail.com>

I checked and ENGINE_set_RAND function is being called. What I can't figure
out is the following:

1. RAND_get_rand_method() is called to get the random method and in a
normal case default_RAND_METHOD would be null which would cause code to
call ENGINE_get_rand() to be called to get the random method for the engine
associated for RAND.
2. In my particular case something has already caused default_RAND_METHOD
to be populated before I load my engine and the only place I see that it
can get reset is via RAND_set_rand_method() which can be called by
RAND_cleanup() and ENGINE_cleanup().

Any ideas?

On Wed, Dec 10, 2014 at 8:25 AM, Brian Watson <bwats9999 at gmail.com> wrote:

> I didn't call that one, but I'll give it a try. I also read that if
> someone subsequently calls ENGINE_load_builtin_engines()that it'll reset
> things back to how they were so I'll look at that also.
>
> Thanks,
>   BW
>
> On Wed, Dec 10, 2014 at 1:06 AM, Dmitry Belyavsky <beldmit at gmail.com>
> wrote:
>
>> Hello Brian,
>>
>> Do you call ENGINE_set_RAND function?
>>
>> On Tue, Dec 9, 2014 at 11:19 PM, Brian Watson <bwats9999 at gmail.com>
>> wrote:
>>
>>> I thought that's what the following does:
>>>
>>> ENGINE_set_default(engine, ENGINE_METHOD_RAND).
>>>
>>> I'm also trying to figure out in rand_lib.c and RAND_get_rand_method()
>>> what causes default_RAND_meth to change.
>>>
>>> Thanks,
>>>    BW
>>>
>>> On Tue, Dec 9, 2014 at 1:52 PM, Dmitry Belyavsky <beldmit at gmail.com>
>>> wrote:
>>>
>>>> Hello!
>>>>
>>>> Do you set your RNG as default when the engine is loaded?
>>>>
>>>> On Tue, Dec 9, 2014 at 10:44 PM, Brian Watson <bwats9999 at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>    I am doing the following:
>>>>>
>>>>> 1. I have a dynamic engine that I would like to use to produce random
>>>>> numbers on Android (aosp).
>>>>> 2. I can successfully load the dynamic engine by using the Android
>>>>> OpenSSLEngine.getInstance() which takes care of loading the engine and I
>>>>> can see that the binding is there via bind_engine and bind_helper via some
>>>>> debug prints that I have put in the engine. I follow this up by calling
>>>>> ENGINE_set_default() for ENGINE_METHOD_RAND. I am using the Apache Harmony
>>>>> jsse library.
>>>>> 3. Some time later there is a call to SSL_CTX_new() which starts the
>>>>> process of establishing the TLS session, etc.
>>>>> 4. I would like to see my random number generator get invoked to
>>>>> provide random numbers when needed, but for some reason the ssleay one is
>>>>> being called.
>>>>> 5. I can open an adb shell and run the openssl command and explicitly
>>>>> load the engine via:
>>>>>
>>>>> openssl engine dynamic ?pre
>>>>> SO_PATH:/system/lib/ssl/engines/MyEngine.so ?pre ID:myengine ?pre LOAD.
>>>>> With this I see my random number generator get used, but when I try to do
>>>>> this programatically it doesn't get called.
>>>>>
>>>>>
>>>>> I have a couple of questions:
>>>>>
>>>>>
>>>>> 1. Should this work even when using the SSL_CTX... api's?
>>>>>
>>>>> 2. Am I setting up the engine too soon and then the SSL_CTX.. commands
>>>>> clear them out?
>>>>>
>>>>>
>>>>> I've looked around a lot so any help would be greatly appreciated!
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>>    BW
>>>>>
>>>>> _______________________________________________
>>>>> openssl-users mailing list
>>>>> openssl-users at openssl.org
>>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> SY, Dmitry Belyavsky
>>>>
>>>> _______________________________________________
>>>> openssl-users mailing list
>>>> openssl-users at openssl.org
>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> openssl-users mailing list
>>> openssl-users at openssl.org
>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>
>>>
>>
>>
>> --
>> SY, Dmitry Belyavsky
>>
>> _______________________________________________
>> openssl-users mailing list
>> openssl-users at openssl.org
>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141210/7a21d745/attachment-0001.html>

From doctor at doctor.nl2k.ab.ca  Wed Dec 10 11:51:15 2014
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Wed, 10 Dec 2014 09:51:15 -0700
Subject: [openssl-users] More POODLE issues
Message-ID: <20141210164918.GA24166@doctor.nl2k.ab.ca>

Now POODLE  is hitting  TLS

http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html

Any fixes in the works?

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Merry Christmas 2014 and Happy New Year 2015

From rsalz at akamai.com  Wed Dec 10 11:58:01 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 10 Dec 2014 11:58:01 -0500
Subject: [openssl-users] [openssl-dev] More POODLE issues
In-Reply-To: <20141210164918.GA24166@doctor.nl2k.ab.ca>
References: <20141210164918.GA24166@doctor.nl2k.ab.ca>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C1D0@USMBX1.msg.corp.akamai.com>

> Now POODLE  is hitting  TLS
> 
> http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-
> itbwcw.html
> 
> Any fixes in the works?

As has already been covered in the openssl-dev list.  OpenSSL does not have this defect.

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz

From kurt at roeckx.be  Wed Dec 10 11:59:09 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Wed, 10 Dec 2014 17:59:09 +0100
Subject: [openssl-users] [openssl-dev] More POODLE issues
In-Reply-To: <20141210164918.GA24166@doctor.nl2k.ab.ca>
References: <20141210164918.GA24166@doctor.nl2k.ab.ca>
Message-ID: <20141210165909.GA2038@roeckx.be>

On Wed, Dec 10, 2014 at 09:51:15AM -0700, The Doctor wrote:
> Now POODLE  is hitting  TLS
> 
> http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html
> 
> Any fixes in the works?

As already said previously, openssl is not affected by this.


kurt


From npentako at Brocade.com  Wed Dec 10 17:45:07 2014
From: npentako at Brocade.com (Vyas Pentakota)
Date: Wed, 10 Dec 2014 22:45:07 +0000
Subject: [openssl-users] Any way to create a large encrypted finish message?
Message-ID: <29fbb719c2a648bdbade48fa66d2ccce@BRMWP-EXMB12.corp.brocade.com>

Hi
I am working on issue involving openssl TLS 1.2 finish message decryption. I was wondering if anyone can tell me how I can generate "encrypted handshake message" (client finish message) record larger than 64 bytes  only using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA.
Your suggestion is greatly appreciated.
Thank you
Vyas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141210/0ab17fe2/attachment.html>

From oyljerry at gmail.com  Thu Dec 11 04:04:53 2014
From: oyljerry at gmail.com (Jerry OELoo)
Date: Thu, 11 Dec 2014 17:04:53 +0800
Subject: [openssl-users] What is release date for openssl 1.0.2
Message-ID: <CAEKwp_FABexfuH-EtAbW76Yu4Dm_DvUPi_FcOVwzNReWRFDsow@mail.gmail.com>

Hi All:
I wonder when openssl 1.0.2 will officially release? Is there any
exact schedule? Thanks!

-- 
Rejoice,I Desire!

From matt at openssl.org  Thu Dec 11 04:56:58 2014
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Dec 2014 09:56:58 +0000
Subject: [openssl-users] What is release date for openssl 1.0.2
In-Reply-To: <CAEKwp_FABexfuH-EtAbW76Yu4Dm_DvUPi_FcOVwzNReWRFDsow@mail.gmail.com>
References: <CAEKwp_FABexfuH-EtAbW76Yu4Dm_DvUPi_FcOVwzNReWRFDsow@mail.gmail.com>
Message-ID: <54896A6A.5040401@openssl.org>


On 11/12/14 09:04, Jerry OELoo wrote:
> Hi All:
> I wonder when openssl 1.0.2 will officially release? Is there any
> exact schedule? Thanks!
>
There is no official date that I can give you. We had hoped to have
already released it, however we have had some issues that have delayed
it. I currently expect it to be very early in the New Year.

Matt

From KThirumal at inautix.co.in  Thu Dec 11 05:20:36 2014
From: KThirumal at inautix.co.in (Thirumal, Karthikeyan)
Date: Thu, 11 Dec 2014 10:20:36 +0000
Subject: [openssl-users] Error: A call to SSPI failed ...
Message-ID: <55A0598A7539EC4BAB296D8BBA5AC122866C59F9@WTPCPMBMEM06.ams.bnymellon.net>

Dear team,
Can someone tell me why the error is happening as SSPI failed ? Am seeing this new today and when I searched the internet - it says whenever there is a BAD formed request or when there is no client certificate - we may get this error. Can someone shed more light here ?

12/11/2014  12:50:06.161
ByteCount: 69
SSL Authentication failed A call to SSPI failed, see inner exception.

12/11/2014  12:50:06.161
ByteCount: 25
SSL Authentication failed

Thanks & Regards
________________________
Karthikeyan Thirumal
ADD-Web-NXP-India, Application Development Delivery
iNautix Technologies India Pvt. Ltd., A BNY Mellon Company.
Extn (Internal): 612-10650
Direct Line: (+1) 615-381-0650
Email: kthirumal at inautix.co.in<mailto:kthirumal at inautix.co.in>

Information Classification: Internal Use Only


******************************************************
This message and any files or attachments sent with this message contain confidential information and is intended only for the individual named.  If you are not the named addressee, you should not disseminate, distribute, copy or use any part of this email.  If you have received this message in error, please delete it and all copies from your system and notify the sender immediately by return Email.

Email transmission cannot be guaranteed to be secure or error-free as information can be intercepted, corrupted, lost, destroyed, late, incomplete or may contain viruses.  The sender, therefore, does not accept liability for any errors or omissions in the contents of this message, which arise as a result of email transmission.
******************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/638f1703/attachment-0001.html>

From gayathri.annur at gmail.com  Thu Dec 11 06:07:41 2014
From: gayathri.annur at gmail.com (Gayathri Manoj)
Date: Thu, 11 Dec 2014 16:37:41 +0530
Subject: [openssl-users] CVE-2011-1473 fixed version
Message-ID: <CAKqy4TMC7Lkz6_Az29CrSk_vouSQDr8CgPV-QJB0sxfQFzNQfw@mail.gmail.com>

Hi All,

Please let me know in which version CVE-2011-1473 got fixed.
Is openssl-1.x is vulnerable to this issue?

Thanks,
Gayathri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/3ab06ad5/attachment.html>

From noloader at gmail.com  Thu Dec 11 06:16:45 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 11 Dec 2014 06:16:45 -0500
Subject: [openssl-users] CVE-2011-1473 fixed version
In-Reply-To: <CAKqy4TMC7Lkz6_Az29CrSk_vouSQDr8CgPV-QJB0sxfQFzNQfw@mail.gmail.com>
References: <CAKqy4TMC7Lkz6_Az29CrSk_vouSQDr8CgPV-QJB0sxfQFzNQfw@mail.gmail.com>
Message-ID: <CAH8yC8kWdpv+aijaKeX_Gh=t5mad+heR2rVWf8E8kO5iNFyqWA@mail.gmail.com>

On Thu, Dec 11, 2014 at 6:07 AM, Gayathri Manoj
<gayathri.annur at gmail.com> wrote:
> Hi All,
>
> Please let me know in which version CVE-2011-1473 got fixed.
> Is openssl-1.x is vulnerable to this issue?
>
https://www.openssl.org/news/vulnerabilities.html

From thulasi.goriparthi at gmail.com  Thu Dec 11 06:23:04 2014
From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi)
Date: Thu, 11 Dec 2014 16:53:04 +0530
Subject: [openssl-users] Any way to create a large encrypted finish
	message?
In-Reply-To: <29fbb719c2a648bdbade48fa66d2ccce@BRMWP-EXMB12.corp.brocade.com>
References: <29fbb719c2a648bdbade48fa66d2ccce@BRMWP-EXMB12.corp.brocade.com>
Message-ID: <CAB7O4Gy_U=KZbFJng58qZXRjAv=xmue5rhxmqvADuLNppZRcPg@mail.gmail.com>

One can't change the encrypted finished size unless one is using variable
padding. encrypted finished size depends on 3 parameters: protocol version,
cipher type, MAC type,

Protocol version decides if explicit IV is included in the record and
unencrypted finished message size.
For SSL3 and TLS1.0, there wouldn't be any explicit IV.
For SSL3, unencrypted finished size would be of 40 bytes (4 (handshake
header) + 16(MD5 hash)+20(SHA hash) ) and for other protocols it will be 16
bytes(4(handshake header) + 12 bytes(xor of MD5 and SHA1 hashes))

Cipher Type decides, if the data needs to be padded or not. If it is block
cipher, there would be 1 block of must padding of block length(16 for AES,
8 for DES). It also decides explicit IV length.

MAC(hash)  type decides the length of the MAC tag that will be appended to
the unencrypted data before padding.

For TLS1.2,  AES256-SHA/AES128-SHA,  encrypted finished message consists
of  16 byte explicit IV + 16 byte finished message + 20 byte hash + 16 byte
must padding. so, it will be of 68 bytes.

For DES-CBC3-SHA, it will be 8 byte explicit IV + 16 byte finished message
+ 20 byte hash + 8 byte must padding. i.e it will be 52 bytes.

Thanks,
Thulasi.

On 11 December 2014 at 04:15, Vyas Pentakota <npentako at brocade.com> wrote:

>  Hi
>
> I am working on issue involving openssl TLS 1.2 finish message decryption.
> I was wondering if anyone can tell me how I can generate ?encrypted
> handshake message? (client finish message) record larger than 64 bytes
>  only using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA.
>
> Your suggestion is greatly appreciated.
>
> Thank you
>
> Vyas
>
>
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/1ee346e7/attachment.html>

From gayathri.annur at gmail.com  Thu Dec 11 06:35:37 2014
From: gayathri.annur at gmail.com (Gayathri Manoj)
Date: Thu, 11 Dec 2014 17:05:37 +0530
Subject: [openssl-users] CVE-2011-1473 fixed version
In-Reply-To: <CAH8yC8kWdpv+aijaKeX_Gh=t5mad+heR2rVWf8E8kO5iNFyqWA@mail.gmail.com>
References: <CAKqy4TMC7Lkz6_Az29CrSk_vouSQDr8CgPV-QJB0sxfQFzNQfw@mail.gmail.com>
 <CAH8yC8kWdpv+aijaKeX_Gh=t5mad+heR2rVWf8E8kO5iNFyqWA@mail.gmail.com>
Message-ID: <CAKqy4TP7a-cjozHSdtao0u-VuirLRuhVt8kmR=ApL=OVqJVwTQ@mail.gmail.com>

Hi Jeffrey,

In this its not mentioned.

Thanks,
Gayathri

On Thu, Dec 11, 2014 at 4:46 PM, Jeffrey Walton <noloader at gmail.com> wrote:

> On Thu, Dec 11, 2014 at 6:07 AM, Gayathri Manoj
> <gayathri.annur at gmail.com> wrote:
> > Hi All,
> >
> > Please let me know in which version CVE-2011-1473 got fixed.
> > Is openssl-1.x is vulnerable to this issue?
> >
> https://www.openssl.org/news/vulnerabilities.html
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/be3fbc26/attachment.html>

From noloader at gmail.com  Thu Dec 11 06:46:38 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 11 Dec 2014 06:46:38 -0500
Subject: [openssl-users] CVE-2011-1473 fixed version
In-Reply-To: <CAKqy4TP7a-cjozHSdtao0u-VuirLRuhVt8kmR=ApL=OVqJVwTQ@mail.gmail.com>
References: <CAKqy4TMC7Lkz6_Az29CrSk_vouSQDr8CgPV-QJB0sxfQFzNQfw@mail.gmail.com>
 <CAH8yC8kWdpv+aijaKeX_Gh=t5mad+heR2rVWf8E8kO5iNFyqWA@mail.gmail.com>
 <CAKqy4TP7a-cjozHSdtao0u-VuirLRuhVt8kmR=ApL=OVqJVwTQ@mail.gmail.com>
Message-ID: <CAH8yC8mmLKg-h9L0ri3iA=dzpyQD1YY6LxWj-PbFUT=fa0rteg@mail.gmail.com>

On Thu, Dec 11, 2014 at 6:35 AM, Gayathri Manoj
<gayathri.annur at gmail.com> wrote:
> Hi Jeffrey,
>
> In this its not mentioned.
>
Then its not applicable or has not been fixed.

> On Thu, Dec 11, 2014 at 4:46 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>>
>> On Thu, Dec 11, 2014 at 6:07 AM, Gayathri Manoj
>> <gayathri.annur at gmail.com> wrote:
>> > Hi All,
>> >
>> > Please let me know in which version CVE-2011-1473 got fixed.
>> > Is openssl-1.x is vulnerable to this issue?
>> >
>> https://www.openssl.org/news/vulnerabilities.html

From matt at openssl.org  Thu Dec 11 06:47:25 2014
From: matt at openssl.org (Matt Caswell)
Date: Thu, 11 Dec 2014 11:47:25 +0000
Subject: [openssl-users] CVE-2011-1473 fixed version
In-Reply-To: <CAKqy4TP7a-cjozHSdtao0u-VuirLRuhVt8kmR=ApL=OVqJVwTQ@mail.gmail.com>
References: <CAKqy4TMC7Lkz6_Az29CrSk_vouSQDr8CgPV-QJB0sxfQFzNQfw@mail.gmail.com>
 <CAH8yC8kWdpv+aijaKeX_Gh=t5mad+heR2rVWf8E8kO5iNFyqWA@mail.gmail.com>
 <CAKqy4TP7a-cjozHSdtao0u-VuirLRuhVt8kmR=ApL=OVqJVwTQ@mail.gmail.com>
Message-ID: <5489844D.2040602@openssl.org>


On 11/12/14 11:35, Gayathri Manoj wrote:
> Hi Jeffrey,
>
> In this its not mentioned.
>
> Thanks,
> Gayathri
>
> On Thu, Dec 11, 2014 at 4:46 PM, Jeffrey Walton <noloader at gmail.com
> <mailto:noloader at gmail.com>> wrote:
>
>     On Thu, Dec 11, 2014 at 6:07 AM, Gayathri Manoj
>     <gayathri.annur at gmail.com <mailto:gayathri.annur at gmail.com>> wrote:
>     > Hi All,
>     >
>     > Please let me know in which version CVE-2011-1473 got fixed.
>     > Is openssl-1.x is vulnerable to this issue?
>     >
>

I wasn't involved at the time, but reading about it now CVE-2011-1473
essentially says (as I understand it) that if you fire lots of SSL
handshakes at a server it could cause a DoS because it is much cheaper
on the client side than it is on the server side. This isn't a "flaw" in
OpenSSL per se, this is a problem at a protocol level. There are some
possible mitigations, and there is an interesting discussion on the
issue here:

http://vincent.bernat.im/en/blog/2011-ssl-dos-mitigation.html#rate_limiting_ssl_handshakes

In answer to your question CVE-2011-1473 has not been "fixed" in OpenSSL
and there are no plans to do so. The answer to this is going to be more
about what DoS mitigations you are using within your infrastructure,
what ciphersuites you choose to use, etc.

Matt

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/65f9143e/attachment-0001.html>

From thulasi.goriparthi at gmail.com  Thu Dec 11 06:39:52 2014
From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi)
Date: Thu, 11 Dec 2014 17:09:52 +0530
Subject: [openssl-users] Any way to create a large encrypted finish
	message?
In-Reply-To: <CAB7O4Gy_U=KZbFJng58qZXRjAv=xmue5rhxmqvADuLNppZRcPg@mail.gmail.com>
References: <29fbb719c2a648bdbade48fa66d2ccce@BRMWP-EXMB12.corp.brocade.com>
 <CAB7O4Gy_U=KZbFJng58qZXRjAv=xmue5rhxmqvADuLNppZRcPg@mail.gmail.com>
Message-ID: <CAB7O4GyU_NetSqrd-9z0eKjBDtTv5Y0deMCfX5rx3QS8RyKvWw@mail.gmail.com>

A correction regarding padding.

On 11 December 2014 at 16:53, Thulasi Goriparthi <
thulasi.goriparthi at gmail.com> wrote:

> One can't change the encrypted finished size unless one is using variable
> padding. encrypted finished size depends on 3 parameters: protocol version,
> cipher type, MAC type,
>
> Protocol version decides if explicit IV is included in the record and
> unencrypted finished message size.
> For SSL3 and TLS1.0, there wouldn't be any explicit IV.
> For SSL3, unencrypted finished size would be of 40 bytes (4 (handshake
> header) + 16(MD5 hash)+20(SHA hash) ) and for other protocols it will be 16
> bytes(4(handshake header) + 12 bytes(xor of MD5 and SHA1 hashes))
>
> Cipher Type decides, if the data needs to be padded or not. If it is block
> cipher, there would be 1 block of must padding of block length(16 for AES,
> 8 for DES). It also decides explicit IV length.
>
> MAC(hash)  type decides the length of the MAC tag that will be appended to
> the unencrypted data before padding.
>
> For TLS1.2,  AES256-SHA/AES128-SHA,  encrypted finished message consists
> of  16 byte explicit IV + 16 byte finished message + 20 byte hash + 16 byte
> must padding. so, it will be of 68 bytes.
>
> In this case, there would only be 12 bytes of padding as record is already
36 bytes, making it 64 bytes.


> For DES-CBC3-SHA, it will be 8 byte explicit IV + 16 byte finished message
> + 20 byte hash + 8 byte must padding. i.e it will be 52 bytes.
>
> Same here,there would only be 12 bytes of padding as record is already 36
bytes, making it 64 bytes.

> Thanks,
> Thulasi.
>
> On 11 December 2014 at 04:15, Vyas Pentakota <npentako at brocade.com> wrote:
>
>>  Hi
>>
>> I am working on issue involving openssl TLS 1.2 finish message
>> decryption. I was wondering if anyone can tell me how I can generate
>> ?encrypted handshake message? (client finish message) record larger than 64
>> bytes  only using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA.
>>
>> Your suggestion is greatly appreciated.
>>
>> Thank you
>>
>> Vyas
>>
>>
>>
>> _______________________________________________
>> openssl-users mailing list
>> openssl-users at openssl.org
>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/222c52a4/attachment.html>

From richmoore44 at gmail.com  Thu Dec 11 07:45:51 2014
From: richmoore44 at gmail.com (Richard Moore)
Date: Thu, 11 Dec 2014 12:45:51 +0000
Subject: [openssl-users] Error: A call to SSPI failed ...
In-Reply-To: <55A0598A7539EC4BAB296D8BBA5AC122866C59F9@WTPCPMBMEM06.ams.bnymellon.net>
References: <55A0598A7539EC4BAB296D8BBA5AC122866C59F9@WTPCPMBMEM06.ams.bnymellon.net>
Message-ID: <CAMp7mVutFetAobEMbBEOm1n0Tq9RZFb+j+60QkO+uM0rLfa-3w@mail.gmail.com>

On 11 December 2014 at 10:20, Thirumal, Karthikeyan <KThirumal at inautix.co.in
> wrote:

>  Dear team,
>
> Can someone tell me why the error is happening as SSPI failed ? Am seeing
> this new today and when I searched the internet - it says whenever there is
> a BAD formed request or when there is no client certificate - we may get
> this error. Can someone shed more light here ?
>
>
>
> 12/11/2014  12:50:06.161
>
> ByteCount: 69
>
> SSL Authentication failed A call to SSPI failed, see inner exception.
>
>
>
>
>
Since this is an error from .net you're asking the wrong place. This list
is for users of openssl.

Regards

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/ece3d85a/attachment.html>

From jan.m.danielsson at gmail.com  Thu Dec 11 10:02:10 2014
From: jan.m.danielsson at gmail.com (Jan Danielsson)
Date: Thu, 11 Dec 2014 16:02:10 +0100
Subject: [openssl-users] Hashing public keys in EVP_PKEY's
Message-ID: <5489B1F2.20706@gmail.com>

Hello,

   If I would want to use the hash of a EVP_PKEY to uniquely identify
the key (regardless of whether it contains the private key or not), what
would be the best way to do this?  (I.e. how do I deterministically hash
the public key of a EVP_PKEY?).

   Performance is not a major concern.

   The system has buffers which contain keys which are base64 encoded
versions of what i2d_{RSA,DSA,EC}_PUBKEY() outputs.  Internally in the
applications these are made into EVP_PKEY's again by
d2i_{RSA,DSA,EC_KEY}_PUBKEY() + EVP_PKEY_assign_{RSA,DSA,EC_KEY}().

   How bit-by-bit identical are buffers produced by:

   out = NULL;
   switch(EVP_PKEY_type(pkey->type)) {
     case EVP_PKEY_RSA:
       len = i2d_RSA_PUBKEY(pkey->pkey.rsa, &out);
       break;
     case EVP_PKEY_DSA:
       len = i2d_DSA_PUBKEY(pkey->pkey.dsa, &out);
       break;
     case EVP_PKEY_EC:
       len = i2d_EC_PUBKEY(pkey->pkey.ec, &out);
       break;
     default:
       return SOHERR_BAD_PARAM;
   }

   .. ?

   I'm assuming it'll be pretty safe to hash the rsa buffer (..?) but I
feel like the DSA and EC buffers are a little more sketchy (because of
potential parameter issues).

   I browsed around in the source tree and found this:

-----------------
   int X509_pubkey_digest(const X509 *data, const EVP_MD *type, unsigned
char *md, unsigned int *len)
   {
     ASN1_BIT_STRING *key;
     key = X509_get0_pubkey_bitstr(data);
     if(!key) return 0;
     return EVP_Digest(key->data, key->length, md, len, type, NULL);
   }
-----------------

   Apart from that it uses an X509, it looks like exactly what I need,
and it made me realize that the deterministic properly I'm looking for
is internally called "bitstream".

   I tried to follow the clues from x509_get0_pubkey_bitstr(), but I
quickly got confused in the ASN1 code.  :)

   Is it safe to hash the output from i2d_*_PUBKEY?  Is it
super-deterministic as long as one doesn't change parameters around for
DSA and EC?

-- 
Kind Regards,
Jan

From openssl-users at dukhovni.org  Thu Dec 11 10:39:54 2014
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 11 Dec 2014 15:39:54 +0000
Subject: [openssl-users] Hashing public keys in EVP_PKEY's
In-Reply-To: <5489B1F2.20706@gmail.com>
References: <5489B1F2.20706@gmail.com>
Message-ID: <20141211153953.GB25666@mournblade.imrryr.org>

On Thu, Dec 11, 2014 at 04:02:10PM +0100, Jan Danielsson wrote:

>    If I would want to use the hash of a EVP_PKEY to uniquely identify
> the key (regardless of whether it contains the private key or not), what
> would be the best way to do this?  (I.e. how do I deterministically hash
> the public key of a EVP_PKEY?).

Be careful to produce a hash of a full SPKI structure (algorithm
oid, parameters, key bits) and not just the key bits.  Without the
algorithm and parameter context, there is I think a likelihood of
attacks depending on how the hashes are to be used.

> -----------------
>    int X509_pubkey_digest(const X509 *data, const EVP_MD *type, unsigned
> char *md, unsigned int *len)
>    {
>      ASN1_BIT_STRING *key;
>      key = X509_get0_pubkey_bitstr(data);
>      if(!key) return 0;
>      return EVP_Digest(key->data, key->length, md, len, type, NULL);
>    }
> -----------------

This is used to compute the SHA-1 keybits hash for "authority key
identifier" computations, but is NOT the appropriate hash to use
in general.  It is exactly the "key-bits only" digest I am suggesting
you avoid.

Instead, use i2d_PUBKEY() and compute the appropriate digest of
that.

-- 
	Viktor.

From victor.savino at jpmchase.com  Thu Dec 11 10:52:57 2014
From: victor.savino at jpmchase.com (Savino, Victor)
Date: Thu, 11 Dec 2014 15:52:57 +0000
Subject: [openssl-users] Using s_client under z/OS installation
Message-ID: <2E9A184DE1017B4780AD87EF736F7B997C7B9777@SEGCMX045.exchad.jpmchase.net>

I am trying to use the s_client feature to retrieve certificates from other SMPT servers. The s_client connection works to other z/OS systems, but fails to any ASCII based mail server. Tracing the connections show that the EHLO goes out in EBCDIC and the responding server claims unknown command. This make sense on the surface.

Is there a way to force the outbound to ASCII data stream (supported by z/OS on other connections), or is there a way to install OPENSSL using ASCII under the z/OS OMVS umbrella?

Thanks for your help,

Victor Savino| z/OS Network Engineer Lead | GTI ECS Enterprise Software Engineering (ESE) Network
J.P. Morgan Chase & Co. | 575 Wahignton Blvd, Jersey City NJ  07310, US | Office:  201-595-5044
(victor.savino at jpmchase.com)


This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.

This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/83994783/attachment-0001.html>

From Michael.Wojcik at microfocus.com  Thu Dec 11 12:08:01 2014
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 11 Dec 2014 17:08:01 +0000
Subject: [openssl-users] Using s_client under z/OS installation
In-Reply-To: <2E9A184DE1017B4780AD87EF736F7B997C7B9777@SEGCMX045.exchad.jpmchase.net>
References: <2E9A184DE1017B4780AD87EF736F7B997C7B9777@SEGCMX045.exchad.jpmchase.net>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088012E5FFB77@Rock-Exchange1.microfocus.com>

A quick look at apps/s_client.c in the 1.0.1j sources suggests that it does EBCDIC-ASCII translation if it was compiled with CHARSET_EBCDIC.

What version are you using? Was it built with CHARSET_EBCDIC defined?

Michael Wojcik
Technology Specialist, Micro Focus


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Savino, Victor
Sent: Thursday, December 11, 2014 10:53
To: 'openssl-users at openssl.org'
Subject: [openssl-users] Using s_client under z/OS installation

I am trying to use the s_client feature to retrieve certificates from other SMPT servers. The s_client connection works to other z/OS systems, but fails to any ASCII based mail server. Tracing the connections show that the EHLO goes out in EBCDIC and the responding server claims unknown command. This make sense on the surface.

Is there a way to force the outbound to ASCII data stream (supported by z/OS on other connections), or is there a way to install OPENSSL using ASCII under the z/OS OMVS umbrella?




This message has been scanned for malware by Websense. www.websense.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/da4528cb/attachment.html>

From victor.savino at jpmchase.com  Thu Dec 11 14:25:27 2014
From: victor.savino at jpmchase.com (Savino, Victor)
Date: Thu, 11 Dec 2014 19:25:27 +0000
Subject: [openssl-users] Using s_client under z/OS installation
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088012E5FFB77@Rock-Exchange1.microfocus.com>
References: <2E9A184DE1017B4780AD87EF736F7B997C7B9777@SEGCMX045.exchad.jpmchase.net>
 <B550B44BF8AF314BB00C4E2AC1C18088012E5FFB77@Rock-Exchange1.microfocus.com>
Message-ID: <2E9A184DE1017B4780AD87EF736F7B997C7B988E@SEGCMX045.exchad.jpmchase.net>

Thanks for the quick response.

I compiled it with the EBCDIC option. I think that is my problem. The EHLO goes out in EBCDIC to an ASCII server. So then I receive an invalid command response, makes sense.

When I point to another z/OS system to retrieve the certs it goes out EBCDIC and responds properly with the cert chain. But in this dual EBCDIC example both sides are talking the same language.

When I trace inbound to z/OS from an ASCII machine, z/OS recognizes the ASCII and does its magic.

What I need to happen is the z/OS version to be sent in ASCII so the other side can read it.

I hope I am making sense.

Thanks for your help on this.

Victor Savino| z/OS Network Engineer Lead | GTI ECS Enterprise Software Engineering (ESE) Network
J.P. Morgan Chase & Co. | 575 Wahignton Blvd, Jersey City NJ  07310, US | Office:  201-595-5044
(victor.savino at jpmchase.com)

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Michael Wojcik
Sent: Thursday, December 11, 2014 12:08 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Using s_client under z/OS installation

A quick look at apps/s_client.c in the 1.0.1j sources suggests that it does EBCDIC-ASCII translation if it was compiled with CHARSET_EBCDIC.

What version are you using? Was it built with CHARSET_EBCDIC defined?

Michael Wojcik
Technology Specialist, Micro Focus


From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Savino, Victor
Sent: Thursday, December 11, 2014 10:53
To: 'openssl-users at openssl.org'
Subject: [openssl-users] Using s_client under z/OS installation

I am trying to use the s_client feature to retrieve certificates from other SMPT servers. The s_client connection works to other z/OS systems, but fails to any ASCII based mail server. Tracing the connections show that the EHLO goes out in EBCDIC and the responding server claims unknown command. This make sense on the surface.

Is there a way to force the outbound to ASCII data stream (supported by z/OS on other connections), or is there a way to install OPENSSL using ASCII under the z/OS OMVS umbrella?




This message has been scanned for malware by Websense. www.websense.com<http://www.websense.com/>

This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries and affiliates.

This transmission may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. Although this transmission and any attachments are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by JPMorgan Chase & Co., its subsidiaries and affiliates, as applicable, for any loss or damage arising in any way from its use. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you.

Please refer to http://www.jpmorgan.com/pages/disclosures for disclosures relating to European legal entities.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/b7419707/attachment.html>

From noloader at gmail.com  Thu Dec 11 16:25:35 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Thu, 11 Dec 2014 16:25:35 -0500
Subject: [openssl-users] CVE-2011-1473 fixed version
In-Reply-To: <5489844D.2040602@openssl.org>
References: <CAKqy4TMC7Lkz6_Az29CrSk_vouSQDr8CgPV-QJB0sxfQFzNQfw@mail.gmail.com>
 <CAH8yC8kWdpv+aijaKeX_Gh=t5mad+heR2rVWf8E8kO5iNFyqWA@mail.gmail.com>
 <CAKqy4TP7a-cjozHSdtao0u-VuirLRuhVt8kmR=ApL=OVqJVwTQ@mail.gmail.com>
 <5489844D.2040602@openssl.org>
Message-ID: <CAH8yC8=Jhk9ZDmkxMGnaAykpVpLSbPTooOiwUHAf39yW1a40BQ@mail.gmail.com>

> I wasn't involved at the time, but reading about it now CVE-2011-1473
> essentially says (as I understand it) that if you fire lots of SSL
> handshakes at a server it could cause a DoS because it is much cheaper on
> the client side than it is on the server side.
That's pretty disingenuous. You can open lots of connections to a
server and eventually the server will exhaust resources. Sigh....

I've got an improvement on the attack: use a botnet to have
compromised hosts open one or two connections each to evade
firewalls....

From npentako at Brocade.com  Thu Dec 11 21:46:50 2014
From: npentako at Brocade.com (Vyas Pentakota)
Date: Fri, 12 Dec 2014 02:46:50 +0000
Subject: [openssl-users] Any way to create a large encrypted
	finish	message?
In-Reply-To: <CAB7O4GyU_NetSqrd-9z0eKjBDtTv5Y0deMCfX5rx3QS8RyKvWw@mail.gmail.com>
References: <29fbb719c2a648bdbade48fa66d2ccce@BRMWP-EXMB12.corp.brocade.com>
 <CAB7O4Gy_U=KZbFJng58qZXRjAv=xmue5rhxmqvADuLNppZRcPg@mail.gmail.com>
 <CAB7O4GyU_NetSqrd-9z0eKjBDtTv5Y0deMCfX5rx3QS8RyKvWw@mail.gmail.com>
Message-ID: <d4d12abfeb1644c19b027672380a2a79@BRMWP-EXMB12.corp.brocade.com>

Thanks Thulasi, for the clarification. Does this apply to all TLS implementations or just openssl?
Vyas

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Thulasi Goriparthi
Sent: Thursday, December 11, 2014 3:40 AM
To: openssl-users at openssl org
Subject: Re: [openssl-users] Any way to create a large encrypted finish message?

A correction regarding padding.

On 11 December 2014 at 16:53, Thulasi Goriparthi <thulasi.goriparthi at gmail.com<mailto:thulasi.goriparthi at gmail.com>> wrote:
One can't change the encrypted finished size unless one is using variable padding. encrypted finished size depends on 3 parameters: protocol version, cipher type, MAC type,
Protocol version decides if explicit IV is included in the record and unencrypted finished message size.
For SSL3 and TLS1.0, there wouldn't be any explicit IV.
For SSL3, unencrypted finished size would be of 40 bytes (4 (handshake header) + 16(MD5 hash)+20(SHA hash) ) and for other protocols it will be 16 bytes(4(handshake header) + 12 bytes(xor of MD5 and SHA1 hashes))
Cipher Type decides, if the data needs to be padded or not. If it is block cipher, there would be 1 block of must padding of block length(16 for AES, 8 for DES). It also decides explicit IV length.
MAC(hash)  type decides the length of the MAC tag that will be appended to the unencrypted data before padding.

For TLS1.2,  AES256-SHA/AES128-SHA,  encrypted finished message consists of  16 byte explicit IV + 16 byte finished message + 20 byte hash + 16 byte must padding. so, it will be of 68 bytes.
In this case, there would only be 12 bytes of padding as record is already 36 bytes, making it 64 bytes.

For DES-CBC3-SHA, it will be 8 byte explicit IV + 16 byte finished message + 20 byte hash + 8 byte must padding. i.e it will be 52 bytes.
Same here,there would only be 12 bytes of padding as record is already 36 bytes, making it 64 bytes.
Thanks,
Thulasi.

On 11 December 2014 at 04:15, Vyas Pentakota <npentako at brocade.com<mailto:npentako at brocade.com>> wrote:
Hi
I am working on issue involving openssl TLS 1.2 finish message decryption. I was wondering if anyone can tell me how I can generate ?encrypted handshake message? (client finish message) record larger than 64 bytes  only using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA.
Your suggestion is greatly appreciated.
Thank you
Vyas


_______________________________________________
openssl-users mailing list
openssl-users at openssl.org<mailto:openssl-users at openssl.org>
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141212/bb566c8a/attachment.html>

From rsalz at akamai.com  Thu Dec 11 22:14:17 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 11 Dec 2014 22:14:17 -0500
Subject: [openssl-users] Any way to create a large
	encrypted	finish	message?
In-Reply-To: <d4d12abfeb1644c19b027672380a2a79@BRMWP-EXMB12.corp.brocade.com>
References: <29fbb719c2a648bdbade48fa66d2ccce@BRMWP-EXMB12.corp.brocade.com>
 <CAB7O4Gy_U=KZbFJng58qZXRjAv=xmue5rhxmqvADuLNppZRcPg@mail.gmail.com>
 <CAB7O4GyU_NetSqrd-9z0eKjBDtTv5Y0deMCfX5rx3QS8RyKvWw@mail.gmail.com>
 <d4d12abfeb1644c19b027672380a2a79@BRMWP-EXMB12.corp.brocade.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C76B@USMBX1.msg.corp.akamai.com>

> Thanks Thulasi, for the clarification. Does this apply to all TLS implementations or just openssl?

It's protocol definitions, not implementations.

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz


From thevoog at voog.ca  Thu Dec 11 23:03:32 2014
From: thevoog at voog.ca (Chris Eltervoog)
Date: Thu, 11 Dec 2014 21:03:32 -0700
Subject: [openssl-users] eng_cryptodev question
Message-ID: <20141211210332.eeb34916bcd0f3b3f2a731314e331348.f607bceee4.mailapi@email13.secureserver.net>

I have implemented a H/W encryption driver and have integrated it with cryptodev.  In eng_cryptodev.c there is an array digests[].  In that array it defines CRYPTO_MD5 to have a keylen of 16.  In cryptodev, the xform.c file definedes MD5 to have a keylen of 0.    Why is the keylen not zero for the MD5 entry in this table?
 
Cryptodev also defines the keylen in a structure.  The keylen is zero there.  A comparison happens on session creation.  This difference causes a check in the session creation to fail and cryptodev always selects the s/w crypto engine. If I change the eng_cryptodev digests[] entry for CRYPTO_MD5 to have a keylen of zero the MD5 hashing works, however Key generation output changes.  If you run the openssl test case for key generation it will fail.  It seems that the files generated are smaller. I don't see how this change has this side affect with key generation.
 
 
Chris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141211/06e52a53/attachment.html>

From jb-openssl at wisemo.com  Fri Dec 12 10:23:01 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 12 Dec 2014 11:23:01 +0100
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <CAH8yC8nz04ZnHxm2QkpDKiGTryrx+PsDo5aYwSTcxW7Ad_2dFA@mail.gmail.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <CAH8yC8nz04ZnHxm2QkpDKiGTryrx+PsDo5aYwSTcxW7Ad_2dFA@mail.gmail.com>
Message-ID: <548AC205.30707@wisemo.com>

On 09/12/2014 21:46, Jeffrey Walton wrote:
> On Tue, Dec 9, 2014 at 2:07 PM, Amarendra Godbole
> <amarendra.godbole at gmail.com> wrote:
>> So Adam Langley writes "SSLv3 decoding function was used with TLS,
>> then the POODLE attack would work, even against TLS connections." on
>> his the latest POODLE affecting TLS 1.x.
>> (https://www.imperialviolet.org/).
>>
>> I also received a notification from Symantec's DeepSight, that states:
>> "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure
>> Vulnerability".
>>
>> However, I could not find more information on OpenSSL's web-site about
>> POODLE-biting-again. Did I miss any notification? Thanks.
> Here's some more reading:
> https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
>
> There's nothing specific to OpenSSL. Its a design defect in the
> protocols (its been well known that TLS 1.0 had the same oracle as
> SSLv3 since only the IV changed between them).
>
> Its not surprising that a PoC demonstrates it against TLS 1.0. Many
> have been been waiting for it.
>
> It looks like Ubuntu is going to have to enable TLS 1.1 and 1.2 in
> 12.04 LTS for clients.
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576.
> _______________________________________________
Stop spreading FUD and lies.  This is NOT a protocol weakness in any TLS 
version,
it is an implementation *bug* affecting multiple TLS implementations, 
specifically
those that don't implement the *required* checks of the padding during
decryption.

So far, there have been public reports about which server side TLS 
implementation
have this particular bug, OpenSSL is in the clear, some (which?) NSS 
versions are
insecure, F5 and A10 load balancing devices need a recently released 
patch for
this specific issue.

I have seen no reports on which client side TLS implementations have the 
bug.

P.S.

Also, Mr. Langley seems to blindly reiterate an over-interpretation of 
the well known
dangers of bad mac-then-pad-then-encrypt to ban all mac-before-encrypt 
schemes
in favor of the much more fragile "Authenticated Encryption" modes such 
as GCM.

If you read the original paper that warned against mac-then-encrypt, its 
proofs
explicitly depended on the possibility that multiple related encrypted 
strings would
decrypt to the same mac+data and be accepted as identical, thus 
providing the oracle
used in the POODLE and BEAST attacks, amongst others.

Thus any Mac-then-encrypt scheme which guarantees that any change in the
encrypted value will cause the mac check to fail (within the strength of 
the mac),
should in my opinion remain at least as safe as encrypt-then-mac, and in my
opinion be even safer, since the attacker can no longer observe and 
probe the
mac protection independently of the encryption itself.  SSLv3 and TLS 
have always
done this right for stream ciphers, its just that the specific stream 
cipher RC4 has
its own (unrelated) problems.

One scheme, that I personally like, is to do 
pad-then-macprefix-then-encrypt.  By
including the padding in the mac calculation (as if part of the data), 
the classic
oracle vulnerability goes away.  By putting the high entropy keyed mac 
first, the
predictable IV problem in CBC cipher modes (and similar) is solved in a 
stronger
way than by sending an unencrypted IV (like TLS 1.2 does).  I suspect 
(but have
not done the math yet) that this is as strong as AuthEnc modes with perfect
block ciphers, and stronger than those in the eventuality of either the 
cipher or
mac having unexpected weaknesses.  Despite these improvements, this scheme
has the same implementation and size costs as the broken SSLv3 scheme, using
the same implementation functions.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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.opensslfoundation.net/pipermail/openssl-users/attachments/20141212/debc4229/attachment-0001.html>

From jb-openssl at wisemo.com  Fri Dec 12 10:28:14 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 12 Dec 2014 11:28:14 +0100
Subject: [openssl-users] Error: A call to SSPI failed ...
In-Reply-To: <CAMp7mVutFetAobEMbBEOm1n0Tq9RZFb+j+60QkO+uM0rLfa-3w@mail.gmail.com>
References: <55A0598A7539EC4BAB296D8BBA5AC122866C59F9@WTPCPMBMEM06.ams.bnymellon.net>
 <CAMp7mVutFetAobEMbBEOm1n0Tq9RZFb+j+60QkO+uM0rLfa-3w@mail.gmail.com>
Message-ID: <548AC33E.7030905@wisemo.com>

On 11/12/2014 13:45, Richard Moore wrote:
> On 11 December 2014 at 10:20, Thirumal, Karthikeyan 
> <KThirumal at inautix.co.in <mailto:KThirumal at inautix.co.in>> wrote:
>
>     Dear team,
>
>     Can someone tell me why the error is happening as SSPI failed ? Am
>     seeing this new today and when I searched the internet ? it says
>     whenever there is a BAD formed request or when there is no client
>     certificate ? we may get this error. Can someone shed more light
>     here ?
>
>     12/11/2014  12:50:06.161
>
>     ByteCount: 69
>
>     SSL Authentication failed A call to SSPI failed, see inner exception.
>
>
>
> Since this is an error from .net you're asking the wrong place. This 
> list is for users of openssl.
>
More specifically, this is an error from Microsoft SCHANNEL,
which is their SSL-library, called via their SSPI API (a
GSSAPI variant).

"See inner exception" means you should scroll down in the
error reportfrom .NET to see the real error code.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 thulasi.goriparthi at gmail.com  Fri Dec 12 12:53:33 2014
From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi)
Date: Fri, 12 Dec 2014 18:23:33 +0530
Subject: [openssl-users] Help with using a dynamic engine with SSL_CTX
In-Reply-To: <CAGhNzw17UN6kpU0TOppuWCjMGBFJe-mX6MOv4+6w9s5L8VTdTQ@mail.gmail.com>
References: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>
 <CADqLbzLs6JjwaSx=cNudqz=7gpv9_c5QenSXajV1bqYotTFEDg@mail.gmail.com>
 <CAGhNzw369cPV1CTB0PhYnw_=Ym9VkSFAYyo_C4yV32WSQPFihg@mail.gmail.com>
 <CADqLbzJKNVkMmZhS0tppznae_-T2Y+w9-QVO764ZHKHbAZUPJw@mail.gmail.com>
 <CAGhNzw1hX+ywkTECg0_fzTBf7C4EWfgKF3wArzYUQ3zO0-0phw@mail.gmail.com>
 <CAGhNzw17UN6kpU0TOppuWCjMGBFJe-mX6MOv4+6w9s5L8VTdTQ@mail.gmail.com>
Message-ID: <CAB7O4Gy27j4S6bNjMq+6NGgUGMYHkhAif1yMpFaHXv_+bUm+jw@mail.gmail.com>

I had similar trouble a while ago.

I understood that if crypto/ssl application need to use RAND method before
the intended engine is loaded, default_RAND_method would be populated with
RAND_SSLeay().

ENGINE_set_RAND wouldn't overwrite this as rand wrappers prefer
default_RAND_method than engine's default RAND method.

So, One need to explicitly call either
RAND_set_rand_method(rand_method_pointer) if one can directly access
engine's rand method or RAND_set_rand_engine(e) where e is preferred
engine's reference.

Thanks,
Thulasi.

On 10 December 2014 at 22:05, Brian Watson <bwats9999 at gmail.com> wrote:
>
> I checked and ENGINE_set_RAND function is being called. What I can't
> figure out is the following:
>
> 1. RAND_get_rand_method() is called to get the random method and in a
> normal case default_RAND_METHOD would be null which would cause code to
> call ENGINE_get_rand() to be called to get the random method for the engine
> associated for RAND.
> 2. In my particular case something has already caused default_RAND_METHOD
> to be populated before I load my engine and the only place I see that it
> can get reset is via RAND_set_rand_method() which can be called by
> RAND_cleanup() and ENGINE_cleanup().
>
> Any ideas?
>
> On Wed, Dec 10, 2014 at 8:25 AM, Brian Watson <bwats9999 at gmail.com> wrote:
>
>> I didn't call that one, but I'll give it a try. I also read that if
>> someone subsequently calls ENGINE_load_builtin_engines()that it'll reset
>> things back to how they were so I'll look at that also.
>>
>> Thanks,
>>   BW
>>
>> On Wed, Dec 10, 2014 at 1:06 AM, Dmitry Belyavsky <beldmit at gmail.com>
>> wrote:
>>
>>> Hello Brian,
>>>
>>> Do you call ENGINE_set_RAND function?
>>>
>>> On Tue, Dec 9, 2014 at 11:19 PM, Brian Watson <bwats9999 at gmail.com>
>>> wrote:
>>>
>>>> I thought that's what the following does:
>>>>
>>>> ENGINE_set_default(engine, ENGINE_METHOD_RAND).
>>>>
>>>> I'm also trying to figure out in rand_lib.c and RAND_get_rand_method()
>>>> what causes default_RAND_meth to change.
>>>>
>>>> Thanks,
>>>>    BW
>>>>
>>>> On Tue, Dec 9, 2014 at 1:52 PM, Dmitry Belyavsky <beldmit at gmail.com>
>>>> wrote:
>>>>
>>>>> Hello!
>>>>>
>>>>> Do you set your RNG as default when the engine is loaded?
>>>>>
>>>>> On Tue, Dec 9, 2014 at 10:44 PM, Brian Watson <bwats9999 at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>    I am doing the following:
>>>>>>
>>>>>> 1. I have a dynamic engine that I would like to use to produce random
>>>>>> numbers on Android (aosp).
>>>>>> 2. I can successfully load the dynamic engine by using the Android
>>>>>> OpenSSLEngine.getInstance() which takes care of loading the engine and I
>>>>>> can see that the binding is there via bind_engine and bind_helper via some
>>>>>> debug prints that I have put in the engine. I follow this up by calling
>>>>>> ENGINE_set_default() for ENGINE_METHOD_RAND. I am using the Apache Harmony
>>>>>> jsse library.
>>>>>> 3. Some time later there is a call to SSL_CTX_new() which starts the
>>>>>> process of establishing the TLS session, etc.
>>>>>> 4. I would like to see my random number generator get invoked to
>>>>>> provide random numbers when needed, but for some reason the ssleay one is
>>>>>> being called.
>>>>>> 5. I can open an adb shell and run the openssl command and explicitly
>>>>>> load the engine via:
>>>>>>
>>>>>> openssl engine dynamic ?pre
>>>>>> SO_PATH:/system/lib/ssl/engines/MyEngine.so ?pre ID:myengine ?pre LOAD.
>>>>>> With this I see my random number generator get used, but when I try to do
>>>>>> this programatically it doesn't get called.
>>>>>>
>>>>>>
>>>>>> I have a couple of questions:
>>>>>>
>>>>>>
>>>>>> 1. Should this work even when using the SSL_CTX... api's?
>>>>>>
>>>>>> 2. Am I setting up the engine too soon and then the SSL_CTX..
>>>>>> commands clear them out?
>>>>>>
>>>>>>
>>>>>> I've looked around a lot so any help would be greatly appreciated!
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>    BW
>>>>>>
>>>>>> _______________________________________________
>>>>>> openssl-users mailing list
>>>>>> openssl-users at openssl.org
>>>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> SY, Dmitry Belyavsky
>>>>>
>>>>> _______________________________________________
>>>>> openssl-users mailing list
>>>>> openssl-users at openssl.org
>>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> openssl-users mailing list
>>>> openssl-users at openssl.org
>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>
>>>>
>>>
>>>
>>> --
>>> SY, Dmitry Belyavsky
>>>
>>> _______________________________________________
>>> openssl-users mailing list
>>> openssl-users at openssl.org
>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>
>>>
>>
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141212/8166d14d/attachment.html>

From Michael.Wojcik at microfocus.com  Fri Dec 12 12:54:00 2014
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 12 Dec 2014 12:54:00 +0000
Subject: [openssl-users] CVE-2011-1473 fixed version
In-Reply-To: <CAH8yC8=Jhk9ZDmkxMGnaAykpVpLSbPTooOiwUHAf39yW1a40BQ@mail.gmail.com>
References: <CAKqy4TMC7Lkz6_Az29CrSk_vouSQDr8CgPV-QJB0sxfQFzNQfw@mail.gmail.com>
 <CAH8yC8kWdpv+aijaKeX_Gh=t5mad+heR2rVWf8E8kO5iNFyqWA@mail.gmail.com>
 <CAKqy4TP7a-cjozHSdtao0u-VuirLRuhVt8kmR=ApL=OVqJVwTQ@mail.gmail.com>
 <5489844D.2040602@openssl.org>
 <CAH8yC8=Jhk9ZDmkxMGnaAykpVpLSbPTooOiwUHAf39yW1a40BQ@mail.gmail.com>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088012E5FFF10@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Jeffrey Walton
> Sent: Thursday, December 11, 2014 16:26
> To: OpenSSL Users List
> Subject: Re: [openssl-users] CVE-2011-1473 fixed version
> 
> > I wasn't involved at the time, but reading about it now CVE-2011-1473
> > essentially says (as I understand it) that if you fire lots of SSL
> > handshakes at a server it could cause a DoS because it is much cheaper
> > on the client side than it is on the server side.
> That's pretty disingenuous. You can open lots of connections to a server and
> eventually the server will exhaust resources. Sigh....
> 
> I've got an improvement on the attack: use a botnet to have compromised
> hosts open one or two connections each to evade firewalls....

Well, yes, except that we've had mitigations for simple connection-flood DoS attacks since the mid-1990s (RED in 1993, SYN Cookies in 1996, and so on). Protocol-specific DoS attacks are more sophisticated and in general more difficult to defend against, so they merit separate discussion.

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com

From noloader at gmail.com  Fri Dec 12 20:31:31 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 12 Dec 2014 15:31:31 -0500
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <548AC205.30707@wisemo.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <CAH8yC8nz04ZnHxm2QkpDKiGTryrx+PsDo5aYwSTcxW7Ad_2dFA@mail.gmail.com>
 <548AC205.30707@wisemo.com>
Message-ID: <CAH8yC8nkkTkJnxqY09+3V=bWBYEr1Hkv7PMgBEhQ6Z+OUg-n2g@mail.gmail.com>

On Fri, Dec 12, 2014 at 5:23 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
> On 09/12/2014 21:46, Jeffrey Walton wrote:
>
> On Tue, Dec 9, 2014 at 2:07 PM, Amarendra Godbole
> <amarendra.godbole at gmail.com> wrote:
>
> So Adam Langley writes "SSLv3 decoding function was used with TLS,
> then the POODLE attack would work, even against TLS connections." on
> his the latest POODLE affecting TLS 1.x.
> (https://www.imperialviolet.org/).
>
> I also received a notification from Symantec's DeepSight, that states:
> "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure
> Vulnerability".
>
> However, I could not find more information on OpenSSL's web-site about
> POODLE-biting-again. Did I miss any notification? Thanks.
>
> Here's some more reading:
> https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
>
> There's nothing specific to OpenSSL. Its a design defect in the
> protocols (its been well known that TLS 1.0 had the same oracle as
> SSLv3 since only the IV changed between them).
>
> Its not surprising that a PoC demonstrates it against TLS 1.0. Many
> have been been waiting for it.
>
> It looks like Ubuntu is going to have to enable TLS 1.1 and 1.2 in
> 12.04 LTS for clients.
> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576
> .
> _______________________________________________
>
> Stop spreading FUD and lies.  This is NOT a protocol weakness in any TLS
> version,
> it is an implementation *bug* affecting multiple TLS implementations,
> specifically
> those that don't implement the *required* checks of the padding during
> decryption.
The cryptographers would disagree with you. The various attacks
against the design defects appear to offer proof by counter example.

Here's the analysis by Krawczyk: "The Order of Encryption and
Authentication for Protecting Communications",
http://www.iacr.org/archive/crypto2001/21390309.pdf.

Here's his recent remarks on the TLS WG mailing list where he
revisited his conclusions, and called out SSL/TLS as being
unconditionally insecure (due to a misunderstanding in the way padding
was applied). From
http://www.ietf.org/mail-archive/web/tls/current/msg13677.html:

    So the math in the paper is correct - the
    conclusion that TLS does it right is wrong.
    It doesn't.

You should probably share your insights on the TLS WG mailing list.
You can join here: https://www.ietf.org/mailman/listinfo/tls.

Jeff

From bwats9999 at gmail.com  Fri Dec 12 22:25:58 2014
From: bwats9999 at gmail.com (Brian Watson)
Date: Fri, 12 Dec 2014 16:25:58 -0600
Subject: [openssl-users] Help with using a dynamic engine with SSL_CTX
In-Reply-To: <CAB7O4Gy27j4S6bNjMq+6NGgUGMYHkhAif1yMpFaHXv_+bUm+jw@mail.gmail.com>
References: <CAGhNzw0C_80KFm4DffB8_164NfhvuMny1BG3Ha-27HB09+DO3g@mail.gmail.com>
 <CADqLbzLs6JjwaSx=cNudqz=7gpv9_c5QenSXajV1bqYotTFEDg@mail.gmail.com>
 <CAGhNzw369cPV1CTB0PhYnw_=Ym9VkSFAYyo_C4yV32WSQPFihg@mail.gmail.com>
 <CADqLbzJKNVkMmZhS0tppznae_-T2Y+w9-QVO764ZHKHbAZUPJw@mail.gmail.com>
 <CAGhNzw1hX+ywkTECg0_fzTBf7C4EWfgKF3wArzYUQ3zO0-0phw@mail.gmail.com>
 <CAGhNzw17UN6kpU0TOppuWCjMGBFJe-mX6MOv4+6w9s5L8VTdTQ@mail.gmail.com>
 <CAB7O4Gy27j4S6bNjMq+6NGgUGMYHkhAif1yMpFaHXv_+bUm+jw@mail.gmail.com>
Message-ID: <CAGhNzw2=aaSXi=yoYj-qwSPLtTxAYe2ygc5AN2_q+XsS-a=DPA@mail.gmail.com>

Ok, thanks and good to know! I also ran a test as follows:

1. adb shell
2. openssl
3. OpenSSL> engine dynamic ?pre
SO_PATH:/system/lib/ssl/engines/libsslengine.so ?pre ID:sslengine ?pre LOAD
4. OpenSSL> rand -hex 512
5. I checked debug output and default_RAND_method was null which caused it
to be populated when RAND_bytes() called RAND_get_rand_method().
6. OpenSSL> engine dynamic ?pre
SO_PATH:/system/lib/ssl/engines/libsslengine.so ?pre ID:sslengine ?pre LOAD
7. OpenSSL > rand -hex 512
8. I checked debug output and default_RAND_method again and this time it
has something valid and thus doesn't get populated even though a new engine
could have been loaded.

Each time the engine is loaded it calls:
ENGINE_set_RAND() and
ENGINE_set_default() for ENGINE_METHOD_RAND

With the original issue I was trying to get working I have read where
Android preloads classes (some of these use openssl) at startup via
something called Zygote and one of these classes is used by my code. I see
the RNG get populated during startup by a class that's preloaded by Zygote
via some static initialization and then later on my software uses this
class. I think this is how the RNG got populated so soon. I'm just touching
the surface of this and It's just not 100% clear to me how this Zygote
preloading of classes and forking of processes works with regards to the
variables I'm seeing.

I'm going to go the route of calling the RAND_set_rand_method().

Thanks.

On Fri, Dec 12, 2014 at 6:53 AM, Thulasi Goriparthi <
thulasi.goriparthi at gmail.com> wrote:
>
> I had similar trouble a while ago.
>
> I understood that if crypto/ssl application need to use RAND method before
> the intended engine is loaded, default_RAND_method would be populated with
> RAND_SSLeay().
>
> ENGINE_set_RAND wouldn't overwrite this as rand wrappers prefer
> default_RAND_method than engine's default RAND method.
>
> So, One need to explicitly call either
> RAND_set_rand_method(rand_method_pointer) if one can directly access
> engine's rand method or RAND_set_rand_engine(e) where e is preferred
> engine's reference.
>
> Thanks,
> Thulasi.
>
> On 10 December 2014 at 22:05, Brian Watson <bwats9999 at gmail.com> wrote:
>>
>> I checked and ENGINE_set_RAND function is being called. What I can't
>> figure out is the following:
>>
>> 1. RAND_get_rand_method() is called to get the random method and in a
>> normal case default_RAND_METHOD would be null which would cause code to
>> call ENGINE_get_rand() to be called to get the random method for the engine
>> associated for RAND.
>> 2. In my particular case something has already caused default_RAND_METHOD
>> to be populated before I load my engine and the only place I see that it
>> can get reset is via RAND_set_rand_method() which can be called by
>> RAND_cleanup() and ENGINE_cleanup().
>>
>> Any ideas?
>>
>> On Wed, Dec 10, 2014 at 8:25 AM, Brian Watson <bwats9999 at gmail.com>
>> wrote:
>>
>>> I didn't call that one, but I'll give it a try. I also read that if
>>> someone subsequently calls ENGINE_load_builtin_engines()that it'll
>>> reset things back to how they were so I'll look at that also.
>>>
>>> Thanks,
>>>   BW
>>>
>>> On Wed, Dec 10, 2014 at 1:06 AM, Dmitry Belyavsky <beldmit at gmail.com>
>>> wrote:
>>>
>>>> Hello Brian,
>>>>
>>>> Do you call ENGINE_set_RAND function?
>>>>
>>>> On Tue, Dec 9, 2014 at 11:19 PM, Brian Watson <bwats9999 at gmail.com>
>>>> wrote:
>>>>
>>>>> I thought that's what the following does:
>>>>>
>>>>> ENGINE_set_default(engine, ENGINE_METHOD_RAND).
>>>>>
>>>>> I'm also trying to figure out in rand_lib.c and RAND_get_rand_method()
>>>>> what causes default_RAND_meth to change.
>>>>>
>>>>> Thanks,
>>>>>    BW
>>>>>
>>>>> On Tue, Dec 9, 2014 at 1:52 PM, Dmitry Belyavsky <beldmit at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello!
>>>>>>
>>>>>> Do you set your RNG as default when the engine is loaded?
>>>>>>
>>>>>> On Tue, Dec 9, 2014 at 10:44 PM, Brian Watson <bwats9999 at gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>    I am doing the following:
>>>>>>>
>>>>>>> 1. I have a dynamic engine that I would like to use to produce
>>>>>>> random numbers on Android (aosp).
>>>>>>> 2. I can successfully load the dynamic engine by using the Android
>>>>>>> OpenSSLEngine.getInstance() which takes care of loading the engine and I
>>>>>>> can see that the binding is there via bind_engine and bind_helper via some
>>>>>>> debug prints that I have put in the engine. I follow this up by calling
>>>>>>> ENGINE_set_default() for ENGINE_METHOD_RAND. I am using the Apache Harmony
>>>>>>> jsse library.
>>>>>>> 3. Some time later there is a call to SSL_CTX_new() which starts the
>>>>>>> process of establishing the TLS session, etc.
>>>>>>> 4. I would like to see my random number generator get invoked to
>>>>>>> provide random numbers when needed, but for some reason the ssleay one is
>>>>>>> being called.
>>>>>>> 5. I can open an adb shell and run the openssl command and
>>>>>>> explicitly load the engine via:
>>>>>>>
>>>>>>> openssl engine dynamic ?pre
>>>>>>> SO_PATH:/system/lib/ssl/engines/MyEngine.so ?pre ID:myengine ?pre LOAD.
>>>>>>> With this I see my random number generator get used, but when I try to do
>>>>>>> this programatically it doesn't get called.
>>>>>>>
>>>>>>>
>>>>>>> I have a couple of questions:
>>>>>>>
>>>>>>>
>>>>>>> 1. Should this work even when using the SSL_CTX... api's?
>>>>>>>
>>>>>>> 2. Am I setting up the engine too soon and then the SSL_CTX..
>>>>>>> commands clear them out?
>>>>>>>
>>>>>>>
>>>>>>> I've looked around a lot so any help would be greatly appreciated!
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>    BW
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> openssl-users mailing list
>>>>>>> openssl-users at openssl.org
>>>>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> SY, Dmitry Belyavsky
>>>>>>
>>>>>> _______________________________________________
>>>>>> openssl-users mailing list
>>>>>> openssl-users at openssl.org
>>>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> openssl-users mailing list
>>>>> openssl-users at openssl.org
>>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> SY, Dmitry Belyavsky
>>>>
>>>> _______________________________________________
>>>> openssl-users mailing list
>>>> openssl-users at openssl.org
>>>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> openssl-users mailing list
>> openssl-users at openssl.org
>> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>>
>>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141212/64b9f4d2/attachment.html>

From oyljerry at gmail.com  Mon Dec 15 10:15:08 2014
From: oyljerry at gmail.com (Jerry OELoo)
Date: Mon, 15 Dec 2014 18:15:08 +0800
Subject: [openssl-users]  How to get current using openssl version
Message-ID: <CAEKwp_H+ALusPRFwjrz2KWodZLgkQSgW=qwQ48upD9eveHEeKQ@mail.gmail.com>

Hi All:
I am installing openssl in local path, and when I use
SSLeay_version(SSLEAY_VERSION); to get version, it will return "SSL
version: OpenSSL 1.0.1f 6 Jan 2014", But installed version is 1.0.1j.

It seems to get system installed version not my manually installed
version, So How can I get it.
PS. I have added include path to gcc: -I./openssl/include/openssl


-- 
Rejoice,I Desire!

From rsalz at akamai.com  Mon Dec 15 14:21:46 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 15 Dec 2014 09:21:46 -0500
Subject: [openssl-users] How to get current using openssl version
In-Reply-To: <CAEKwp_H+ALusPRFwjrz2KWodZLgkQSgW=qwQ48upD9eveHEeKQ@mail.gmail.com>
References: <CAEKwp_H+ALusPRFwjrz2KWodZLgkQSgW=qwQ48upD9eveHEeKQ@mail.gmail.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7CB6D@USMBX1.msg.corp.akamai.com>

> It seems to get system installed version not my manually installed version, So
> How can I get it.
> PS. I have added include path to gcc: -I./openssl/include/openssl

You probably need some better combination of -L and -l flags; -I only sets the path for #include statements.
Some intro documentation on Linux software development might be useful
	/r$
--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz



From chris.bare at gmail.com  Mon Dec 15 14:37:26 2014
From: chris.bare at gmail.com (Chris Bare)
Date: Mon, 15 Dec 2014 09:37:26 -0500
Subject: [openssl-users] How to get current using openssl version
In-Reply-To: <CAEKwp_H+ALusPRFwjrz2KWodZLgkQSgW=qwQ48upD9eveHEeKQ@mail.gmail.com>
References: <CAEKwp_H+ALusPRFwjrz2KWodZLgkQSgW=qwQ48upD9eveHEeKQ@mail.gmail.com>
Message-ID: <CAHR5+EEQHhQ1hzRUnxAPETjJb070JAs2Wy76YbR8gztzCqTXVQ@mail.gmail.com>

Try setting LD_LIBRARY_PATH to your local installation before running your
program:

export LD_LIBRARY_PATH=/alternate/path/usr/lib

On Mon, Dec 15, 2014 at 5:15 AM, Jerry OELoo <oyljerry at gmail.com> wrote:
>
> Hi All:
> I am installing openssl in local path, and when I use
> SSLeay_version(SSLEAY_VERSION); to get version, it will return "SSL
> version: OpenSSL 1.0.1f 6 Jan 2014", But installed version is 1.0.1j.
>
> It seems to get system installed version not my manually installed
> version, So How can I get it.
> PS. I have added include path to gcc: -I./openssl/include/openssl
>
>
> --
> Rejoice,I Desire!
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>


-- 
Chris Bare
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141215/3ba15b48/attachment-0001.html>

From jb-openssl at wisemo.com  Mon Dec 15 17:24:15 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 15 Dec 2014 18:24:15 +0100
Subject: [openssl-users] CVE-2014- and OpenSSL?
In-Reply-To: <CAH8yC8nkkTkJnxqY09+3V=bWBYEr1Hkv7PMgBEhQ6Z+OUg-n2g@mail.gmail.com>
References: <CAC1DtR=bjDOs+b8FiYqY8uF3hkrAriexkGmm7QcKtmB7t4awMg@mail.gmail.com>
 <CAH8yC8nz04ZnHxm2QkpDKiGTryrx+PsDo5aYwSTcxW7Ad_2dFA@mail.gmail.com>
 <548AC205.30707@wisemo.com>
 <CAH8yC8nkkTkJnxqY09+3V=bWBYEr1Hkv7PMgBEhQ6Z+OUg-n2g@mail.gmail.com>
Message-ID: <548F193F.7060209@wisemo.com>

On 12-12-2014 21:31, Jeffrey Walton wrote:
> On Fri, Dec 12, 2014 at 5:23 AM, Jakob Bohm <jb-openssl at wisemo.com> wrote:
>> On 09/12/2014 21:46, Jeffrey Walton wrote:
>>
>> On Tue, Dec 9, 2014 at 2:07 PM, Amarendra Godbole
>> <amarendra.godbole at gmail.com> wrote:
>>
>> So Adam Langley writes "SSLv3 decoding function was used with TLS,
>> then the POODLE attack would work, even against TLS connections." on
>> his the latest POODLE affecting TLS 1.x.
>> (https://www.imperialviolet.org/).
>>
>> I also received a notification from Symantec's DeepSight, that states:
>> "OpenSSL CVE-2014-8730 Man In The Middle Information Disclosure
>> Vulnerability".
>>
>> However, I could not find more information on OpenSSL's web-site about
>> POODLE-biting-again. Did I miss any notification? Thanks.
>>
>> Here's some more reading:
>> https://community.qualys.com/blogs/securitylabs/2014/12/08/poodle-bites-tls
>>
>> There's nothing specific to OpenSSL. Its a design defect in the
>> protocols (its been well known that TLS 1.0 had the same oracle as
>> SSLv3 since only the IV changed between them).
>>
>> Its not surprising that a PoC demonstrates it against TLS 1.0. Many
>> have been been waiting for it.
>>
>> It looks like Ubuntu is going to have to enable TLS 1.1 and 1.2 in
>> 12.04 LTS for clients.
>> https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576
>> .
>> _______________________________________________
>>
>> Stop spreading FUD and lies.  This is NOT a protocol weakness in any TLS
>> version,
>> it is an implementation *bug* affecting multiple TLS implementations,
>> specifically
>> those that don't implement the *required* checks of the padding during
>> decryption.
> The cryptographers would disagree with you. The various attacks
> against the design defects appear to offer proof by counter example.
>
> Here's the analysis by Krawczyk: "The Order of Encryption and
> Authentication for Protecting Communications",
> http://www.iacr.org/archive/crypto2001/21390309.pdf.
>
> Here's his recent remarks on the TLS WG mailing list where he
> revisited his conclusions, and called out SSL/TLS as being
> unconditionally insecure (due to a misunderstanding in the way padding
> was applied). From
> http://www.ietf.org/mail-archive/web/tls/current/msg13677.html:
>
>      So the math in the paper is correct - the
>      conclusion that TLS does it right is wrong.
>      It doesn't.
He is saying exactly what I said (padding before mac is safe, TLS with
CBC does thatwrong).  The only thing I said was right was the SSL case
with no padding at all (stream ciphers, in casethere was a good one in
SSL 3).

Now the POODLE against TLS 1.0 is NOT about all that.  It is about
*broken* TLS 1.0implementations that fail to implement the indirect
protection of the padding specified in the TLS 1.0 RFC.Specifically,
those implementations fail to implement that only a single padding
content value is authenticfor each given padding size, and at most 32
padding size/value pairs are valid for any given authenticatedmessage
size.

This indirect protection in TLS 1.0 greatly reduces the power of the
padding oracle, since the chance thatan interesting plaintext snippet
matches one of the 32 permitted values is a lot less than the chance of
matching one of the 2**61 permitted values in SSL 3 padding.  These
numbers are for 64 bit block size,for 128 bit block size, the numbers
are 16 vs 2**124 .  Variations in how the attacker detects "acceptance
as padding" could change the numbers to 256 or 1 for *correct* TLS 1.0
pad checks versus 2**64 or 2**56for SSL 3.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2860 Soborg, 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  Mon Dec 15 18:41:48 2014
From: marquess at openssl.com (Steve Marquess)
Date: Mon, 15 Dec 2014 13:41:48 -0500
Subject: [openssl-users] Call for HP Proliant wizard
Message-ID: <548F2B6C.3080202@openssl.com>

We've had some reliability and performance issues with the systems
running various OpenSSL related services (www, git, E-mail, etc.).
Earlier this year we purchased a shiny new high-dollar (for us!) HP
DL360 server that is running in Munich (hosting courtesy of SpaceNet
AG). We've been moving services to that system in fits and starts as
time and distractions permit, most recently E-mail services.

Alas we're experiencing an apparent hardware issue (critical but
otherwise unspecified "BIOS/Hardware Health" failure) that has twice
crashed that system. Not good for our plan to use that hardware to
support all OpenSSL services.

We have the extra cost support from HP ("Care Pack"), but that is
turning out to be of limited value in resolving an issue with no
immediately obvious "smoking gun" symptoms. None of us here are very
familiar with the formidable jungle of HP acronyms, jargon, and
proprietary tools.

I know there are a lot of amazingly experienced people in the OpenSSL
community and following this list. If you're familiar with the HP Proliant
ecosystem (and the likes of "iLO 4", "Active Health System", "SPP") and
would be willing to do a little hand-holding then please drop me a line.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc


From openssl-users at openssl.org  Mon Dec 15 18:30:46 2014
From: openssl-users at openssl.org (openssl-users at openssl.org)
Date: Mon, 15 Dec 2014 18:30:46 +0000 (UTC)
Subject: Devolução de cheque favor entrar em contato.0076554 (92887)
Message-ID: <20141215183046.48435243232@luizapossi.com.br>

Spam detection software, running on the system "mta",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  Prezado Cliente, Informo que seu Cheque foi devolvido pela
   2 vez, o Motivo descrito no verso do cheque ? o 12, "Cheque sem Fundo". Estou
   enviando uma copia do cheque estou a sua disposi??o para resolver o mais
  breve poss?vel. [...] 

Content analysis details:   (13.7 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                            See
                            http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                             for more information.
                            [URIs: informacheque.info]
 0.0 HTML_MESSAGE           BODY: HTML included in message
 0.0 T_KHOP_FOREIGN_CLICK   No description available.
 1.1 MIME_HTML_ONLY         BODY: Message only has text/html MIME parts
 1.0 HTML_IMAGE_ONLY_16     BODY: HTML: images with 1200-1600 bytes of words
 1.9 URIBL_JP_SURBL         Contains an URL listed in the JP SURBL blocklist
                            [URIs: informacheque.info]
 1.7 URIBL_WS_SURBL         Contains an URL listed in the WS SURBL blocklist
                            [URIs: informacheque.info]
 0.0 URIBL_SC_SURBL         Contains an URL listed in the SC SURBL blocklist
                            [URIs: informacheque.info]
 0.3 HTML_SHORT_LINK_IMG_2  HTML is very short with a linked image
 0.1 SUBJECT_NEEDS_ENCODING No description available.
 0.0 FORGED_OUTLOOK_HTML    Outlook can't send HTML message only
 1.1 SUBJ_ILLEGAL_CHARS     Subject: has too many raw illegal characters
 0.0 T_REMOTE_IMAGE         Message contains an external image
 3.0 TO_EQ_FM_HTML_ONLY     To == From and HTML only
 3.5 TO_NO_BRKTS_MSFT       To: misformatted and supposed Microsoft tool

The original message was not completely plain text, and may be unsafe to
open with some email clients; in particular, it may contain a virus,
or confirm that your address can receive spam.  If you wish to view
it, it may be safer to save it to a file and open it with an editor.

-------------- next part --------------
An embedded message was scrubbed...
From: openssl-users at openssl.org
Subject: Devolu??o de cheque favor entrar em contato.0076554 (92887)
Date: Mon, 15 Dec 2014 18:30:46 +0000 (UTC)
Size: 2833
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141215/efbc4dd3/attachment.mht>

From karenschnite at niu.edu  Mon Dec 15 19:07:05 2014
From: karenschnite at niu.edu (Karen Schnite)
Date: Mon, 15 Dec 2014 13:07:05 -0600
Subject: [openssl-users]
 =?iso-8859-1?q?Devolu=E7=E3o_de_cheque_favor_entr?=
 =?iso-8859-1?q?ar_em_contato=2E0076554_=2892887=29_=28Working_remotely=29?=
Message-ID: <548EDCF9020000F50007200D@smtp2.gw.niu.edu>

I am working remotely Tuesday Oct. 12th and will be in the office Wednesday after 12 noon.

Karen

Karen E. Schnite
Public Opinion Laboratory
Northern Illinois University
148 N. Third Street
DeKalb, IL 60115

815-753-0950
fax 815-753-2305

Visit our web page at  www.pol.niu.edu

From karenschnite at niu.edu  Mon Dec 15 19:07:05 2014
From: karenschnite at niu.edu (Karen Schnite)
Date: Mon, 15 Dec 2014 13:07:05 -0600
Subject: [openssl-users]
 =?iso-8859-1?q?Devolu=E7=E3o_de_cheque_favor_entr?=
 =?iso-8859-1?q?ar_em_contato=2E0076554_=2892887=29_=28I_will_be_in_meetin?=
 =?iso-8859-1?q?gs_most_of_the_day_with_no_access_to_email=2E=29?=
Message-ID: <548EDCF9020000F50007200A@smtp2.gw.niu.edu>

I will be in meetings most of the day with no access to email.
I will be responding to emails after 3 PM today.

Karen

Karen E. Schnite
Public Opinion Laboratory
Northern Illinois University
148 N. Third Street
DeKalb, IL 60115

815-753-0950
fax 815-753-2305

Visit our web page at  www.pol.niu.edu

From karenschnite at niu.edu  Mon Dec 15 19:07:05 2014
From: karenschnite at niu.edu (Karen Schnite)
Date: Mon, 15 Dec 2014 13:07:05 -0600
Subject: [openssl-users]
 =?iso-8859-1?q?Devolu=E7=E3o_de_cheque_favor_entr?=
 =?iso-8859-1?q?ar_em_contato=2E0076554_=2892887=29_=28Out_of_Office=29?=
Message-ID: <548EDCF9020000F500072007@smtp2.gw.niu.edu>

Spam detection software, running on the system "mta",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  I am currently away from my office. Please contact Mindy Schneiderman
   at 815.753.0039 or schneiderman at niu.edu during my absence. Thank you, Karen
   E Schnite Project Manager Northern Illinois University Public Opinion Laboratory
   [...] 

Content analysis details:   (5.3 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                            See
                            http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                             for more information.
                            [URIs: niu.edu]
 0.0 URIBL_SC_SURBL         Contains an URL listed in the SC SURBL blocklist
                            [URIs: informacheque.info]
 1.7 URIBL_WS_SURBL         Contains an URL listed in the WS SURBL blocklist
                            [URIs: informacheque.info]
 1.9 URIBL_JP_SURBL         Contains an URL listed in the JP SURBL blocklist
                            [URIs: informacheque.info]
 1.7 URIBL_DBL_SPAM         Contains an URL listed in the DBL blocklist
                            [URIs: informacheque.info]


-------------- next part --------------
An embedded message was scrubbed...
From: "Karen Schnite" <karenschnite at niu.edu>
Subject: Re: Devolu??o de cheque favor entrar em contato.0076554 (92887) (Out of Office)
Date: Mon, 15 Dec 2014 13:07:05 -0600
Size: 4170
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141215/e67d88ad/attachment-0001.mht>

From karenschnite at niu.edu  Mon Dec 15 19:07:05 2014
From: karenschnite at niu.edu (Karen Schnite)
Date: Mon, 15 Dec 2014 13:07:05 -0600
Subject: [openssl-users]
 =?iso-8859-1?q?Devolu=E7=E3o_de_cheque_favor_entr?=
 =?iso-8859-1?q?ar_em_contato=2E0076554_=2892887=29_=28Out_of_office=29?=
Message-ID: <548EDCF9020000F500072004@smtp2.gw.niu.edu>

Spam detection software, running on the system "mta",
has identified this incoming email as possible spam.  The original
message has been attached to this so you can view it or label
similar future email.  If you have any questions, see
@@CONTACT_ADDRESS@@ for details.

Content preview:  I am no longer with NIU or the Public Opinion Laboratory.
  I may be reached via email (karenschnite at gmail.com) or 847.404.2814 To reach
   the POL, please contact Mindy Schneiderman at 815.753.0039 or schneiderman at niu.edu
   [...] 

Content analysis details:   (5.3 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 0.0 URIBL_BLOCKED          ADMINISTRATOR NOTICE: The query to URIBL was blocked.
                            See
                            http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
                             for more information.
                            [URIs: openssl.org]
 0.0 URIBL_SC_SURBL         Contains an URL listed in the SC SURBL blocklist
                            [URIs: informacheque.info]
 1.7 URIBL_WS_SURBL         Contains an URL listed in the WS SURBL blocklist
                            [URIs: informacheque.info]
 1.9 URIBL_JP_SURBL         Contains an URL listed in the JP SURBL blocklist
                            [URIs: informacheque.info]
 1.7 URIBL_DBL_SPAM         Contains an URL listed in the DBL blocklist
                            [URIs: informacheque.info]


-------------- next part --------------
An embedded message was scrubbed...
From: "Karen Schnite" <karenschnite at niu.edu>
Subject: Re: Devolu??o de cheque favor entrar em contato.0076554 (92887) (Out of office)
Date: Mon, 15 Dec 2014 13:07:05 -0600
Size: 4200
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141215/bf109265/attachment.mht>

From carlo.agopian at digitalinsight.com  Mon Dec 15 19:09:01 2014
From: carlo.agopian at digitalinsight.com (Agopian, Carlo)
Date: Mon, 15 Dec 2014 19:09:01 +0000
Subject: [openssl-users] =?iso-8859-1?q?Automatic_reply=3A_Devolu=E7=E3o_d?=
 =?iso-8859-1?q?e_cheque_favor_entrar_em_contato=2E0076554_=2892887=29?=
In-Reply-To: <20141215183046.48435243232@luizapossi.com.br>
References: <20141215183046.48435243232@luizapossi.com.br>
Message-ID: <0f653a616efe4897a7fdeeca92de9afa@BY2PR01MB377.prod.exchangelabs.com>

I'm currently out of office with limited access to email and voicemail.  I'll be back in the office on Wednesday 12/17.

Carlo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141215/057ce97c/attachment.html>

From Richard.Dwan at neul.com  Tue Dec 16 11:45:41 2014
From: Richard.Dwan at neul.com (Richard Dwan)
Date: Tue, 16 Dec 2014 11:45:41 +0000
Subject: [openssl-users] Greetings from a new openssl user and the
	inevitable request for help
Message-ID: <267db9ac3be74f529a0c593150a65bc4@THHSTE15D1BE4.hs20.net>

Hello,

I have just joined the many people who are using openssl and I want to say thank you to the developers for creating and maintaining this library; I greatly appreciate the time and effort you all must have put into this.

I really should say I am attempting to join the many people who use openssl; I am attempting to update an unmaintained UDP encrypted communication library that I am told used to work (but have not seen evidence of this myself) and appears to have always used openssl but I do not know what version.
I have successfully managed to compile and link to a current openssl library (openssl-1.0.1j.tar.gz) but have been unable to determine what are the likely causes of the following error messages:

139924302898976:error:1411C146:SSL routines:tls1_prf:unsupported digest type:t1_enc.c:276:
139924302898976:error:140D308A:SSL routines:TLS1_SETUP_KEY_BLOCK:cipher or hash unavailable:t1_enc.c:602:

There is a long thread of discussion about these error messages being encountered by a Joan Moreau which appears to blame the O/S install or compilation options (http://www.devheads.net/server/postfix/user/smtps-465.htm)
I am using CentOS 6.6 (updated with "sudo yum update"), configured, compiled and deployed openssl using the downloaded source following the instructions on http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html
Invoking "openssl version -a" gives me the following
OpenSSL 1.0.1j 15 Oct 2014
built on: Thu Dec 11 14:23:36 GMT 2014
platform: linux-x86_64
options:  bn(64,64) rc4(16x,int) des(idx,cisc,16,int) idea(int) blowfish(idx)
compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -DTERMIO -O3 -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
OPENSSLDIR: "/etc/ssl"

I am testing the library using a demo client/server (which appears to have been used by the original author to develop the library) with a private RSA key and public self-signed certificate.  I have re-created a key and certificate to check to make sure there was no problem with them (the original demo key and certificate resulted in the same error messages).

The key uses:
  Private-Key: (2048 bit)

The certificate uses:
  Signature Algorithm: sha1WithRSAEncryption
  Public Key Algorithm: rsaEncryption
  Public-Key: (2048 bit)
  Signature Algorithm: sha1WithRSAEncryption

Both the modulus and public exponents match

I would be very grateful if anyone could suggest any useful lines of inquiry whilst I try to use gdb to determine the call chain that results in these error messages.

Thank you for any help you can provide,
Richard

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141216/f63f9fe0/attachment.html>

From oyljerry at gmail.com  Wed Dec 17 08:08:24 2014
From: oyljerry at gmail.com (Jerry OELoo)
Date: Wed, 17 Dec 2014 16:08:24 +0800
Subject: [openssl-users] Why can not get certificate chain if certificate
	expire
Message-ID: <CAEKwp_GZNO=rvVGaL+sRv54hK9XCRHCdLM4oCoUgN1v5ZbNRcg@mail.gmail.com>

Hi All:
I am using openssl api to get website's certificate chain. Now, For
normal website, it works fine.
Now I encounter a website which certificate is expire,
https://soknad.sparebank1.no

I use X509_STORE_CTX_get1_chain() to get certificate chain, and from
online help (https://www.openssl.org/docs/ssl/SSL_CTX_set_cert_verify_callback.html)
I use callback to always return 1
SSL_CTX_set_cert_verify_callback(ctx, client_cert_verify_cb, NULL);

But I find that I can only get website certificate, I could not get
its' issuer "VeriSign Class 3 Extended Validation SSL SGC CA", and
root CA "VeriSign Class 3 Public Primary Certification Authority - G5"

Now I want to get full certificate chain, How can I get it?

-- 
Rejoice,I Desire!

From richmoore44 at gmail.com  Wed Dec 17 09:49:40 2014
From: richmoore44 at gmail.com (Richard Moore)
Date: Wed, 17 Dec 2014 09:49:40 +0000
Subject: [openssl-users] Why can not get certificate chain if
	certificate expire
In-Reply-To: <CAEKwp_GZNO=rvVGaL+sRv54hK9XCRHCdLM4oCoUgN1v5ZbNRcg@mail.gmail.com>
References: <CAEKwp_GZNO=rvVGaL+sRv54hK9XCRHCdLM4oCoUgN1v5ZbNRcg@mail.gmail.com>
Message-ID: <CAMp7mVsDr5VZv67bQet4cfdthEuZGUTP3GrB5352fDOWW9cxMw@mail.gmail.com>

On 17 December 2014 at 08:08, Jerry OELoo <oyljerry at gmail.com> wrote:
>
> Hi All:
> I am using openssl api to get website's certificate chain. Now, For
> normal website, it works fine.
> Now I encounter a website which certificate is expire,
> https://soknad.sparebank1.no
>
>
The server is misconfigured and is only transmitting the leaf certificate -
it's missing the intermediates. So you're getting all the certificates it's
sending - one.

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141217/bc4f3acb/attachment.html>

From oyljerry at gmail.com  Thu Dec 18 02:08:23 2014
From: oyljerry at gmail.com (Jerry OELoo)
Date: Thu, 18 Dec 2014 10:08:23 +0800
Subject: [openssl-users] Why can not get certificate chain if
	certificate expire
In-Reply-To: <CAMp7mVsDr5VZv67bQet4cfdthEuZGUTP3GrB5352fDOWW9cxMw@mail.gmail.com>
References: <CAEKwp_GZNO=rvVGaL+sRv54hK9XCRHCdLM4oCoUgN1v5ZbNRcg@mail.gmail.com>
 <CAMp7mVsDr5VZv67bQet4cfdthEuZGUTP3GrB5352fDOWW9cxMw@mail.gmail.com>
Message-ID: <CAEKwp_GBLN-qr4o4KBzsQSTE+-F4QYs4vd=2EhzrSedWxaGM7w@mail.gmail.com>

Hi Rich:
But why browser Chrome can show all certificate path? How did it do? Thanks!

On Wed, Dec 17, 2014 at 5:49 PM, Richard Moore <richmoore44 at gmail.com> wrote:
>
>
> On 17 December 2014 at 08:08, Jerry OELoo <oyljerry at gmail.com> wrote:
>>
>> Hi All:
>> I am using openssl api to get website's certificate chain. Now, For
>> normal website, it works fine.
>> Now I encounter a website which certificate is expire,
>> https://soknad.sparebank1.no
>>
>
> The server is misconfigured and is only transmitting the leaf certificate -
> it's missing the intermediates. So you're getting all the certificates it's
> sending - one.
>
> Rich.
>
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>



-- 
Rejoice,I Desire!

From richmoore44 at gmail.com  Thu Dec 18 15:03:38 2014
From: richmoore44 at gmail.com (Richard Moore)
Date: Thu, 18 Dec 2014 15:03:38 +0000
Subject: [openssl-users] Why can not get certificate chain if
	certificate expire
In-Reply-To: <CAEKwp_GBLN-qr4o4KBzsQSTE+-F4QYs4vd=2EhzrSedWxaGM7w@mail.gmail.com>
References: <CAEKwp_GZNO=rvVGaL+sRv54hK9XCRHCdLM4oCoUgN1v5ZbNRcg@mail.gmail.com>
 <CAMp7mVsDr5VZv67bQet4cfdthEuZGUTP3GrB5352fDOWW9cxMw@mail.gmail.com>
 <CAEKwp_GBLN-qr4o4KBzsQSTE+-F4QYs4vd=2EhzrSedWxaGM7w@mail.gmail.com>
Message-ID: <CAMp7mVue36gSiND85ssKy30kufOi=t4ezp9M3DUJeze5bEX0+A@mail.gmail.com>

On 18 December 2014 at 02:08, Jerry OELoo <oyljerry at gmail.com> wrote:
>
> Hi Rich:
> But why browser Chrome can show all certificate path? How did it do?
> Thanks!
>
>
Browsers fix up mistakes like this in various ways - Firefox caches
intermediates and attempts to fix things by using them if the chain is
missing. IE tries fetching them from windows update (indeed it does this
for rarely used root certificates too), it is also possible to fetch the
intermediates by downloading them from the location indicated in the AIA
extension if present in the leaf certificate. I'm not quite sure which
mechanism (or combination of mechanisms) is being used in the current
version of Chrome but it's like a variant on one of these,

Cheers

Rich.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141218/a0d9c398/attachment.html>

From prabhat.puroshottam at outlook.com  Thu Dec 18 21:00:07 2014
From: prabhat.puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 19 Dec 2014 02:30:07 +0530
Subject: [openssl-users] OpenSSL performance issue
Message-ID: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>

Hi,

I think my last email was somehow lost in transition between the mail
servers so I am starting afresh if somebody can help. If you have
already taken pains to read through this mail, kindly skip to the bottom
of the mail. Thanks for your patience.

?
First let me state upfront that I am relatively very new to OpenSSL.
Also please forgive me if this is not the correct mailing list? for this issue.
?
We have a product which uses OpenSSL to connect and transfer 
application level data. There are two ways to connect, and get the application
level data from *Agent* to *Client*
?
1. Client (C/C++) -> Agent (C/C++)
2. Client (C/C++) -> Proxy Server (Java) -> Agent (C/C++)
?
*Client* and *Agent* are implemented in C, while *Proxy Server* uses Java code 
(This shouldn't really matter). But might be helpful for you to know.
The issue is, connecting *Client* to *Agent* is very fast (that is relatively). 
While connecting *Client* to *Proxy Server* is very slow - that is orders of 
magnitudes slow.
?
I was trying to determine the root cause. From my analysis is appears that, 
maximum time on the *Client* side is taken by SSL_Connect during connection 
establishment, while the actual application level data transfer takes very 
small time. Similarly, on the *Proxy Server* side (Java Code), maximum time 
is taken in the first read/write whichever happens first. Further, I don't 
think this is a network latency issue, as the problem is very pronounced 
and all the three boxes are on the same network. Also, the *Client* code 
seems to be similar, whether we connect to *Agent* (method 1 above) or 
*Proxy Server* (method 2 above). So, the issue is with *Proxy Server*, IMHO.
?
?
To further locate the issue, I did some tests using ssldump command,
?
***************************************
This is for *Client -> Agent*
***************************************
?
1 1? 0.0023 (0.0002)? C>S? Handshake
????? ClientHello
??????? Version 3.1
??????? cipher suites
??????? TLS_DHE_RSA_WITH_AES_256_CBC_SHA
??????? TLS_DHE_DSS_WITH_AES_256_CBC_SHA
??????? TLS_RSA_WITH_AES_256_CBC_SHA
??????? TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
??????? TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
??????? TLS_RSA_WITH_3DES_EDE_CBC_SHA
??????? TLS_DHE_RSA_WITH_AES_128_CBC_SHA
??????? TLS_DHE_DSS_WITH_AES_128_CBC_SHA
??????? TLS_RSA_WITH_AES_128_CBC_SHA
??????? TLS_RSA_WITH_IDEA_CBC_SHA
??????? TLS_RSA_WITH_RC4_128_SHA
??????? Unknown value 0xff
??????? compression methods
????????????????? NULL
1 2? 0.0091 (0.0068)? S>C? Handshake
????? ServerHello
??????? Version 3.1
??????? session_id[0]=
?
??????? cipherSuite???????? TLS_RSA_WITH_AES_256_CBC_SHA
??????? compressionMethod?????????????????? NULL
1 3? 0.0091 (0.0000)? S>C? Handshake
????? Certificate
1 4? 0.0091 (0.0000)? S>C? Handshake
????? CertificateRequest
??????? certificate_types?????????????????? rsa_sign
??????? certificate_types?????????????????? dss_sign
????? ServerHelloDone
1 5? 0.0104 (0.0013)? C>S? Handshake
????? Certificate
1 6? 0.0104 (0.0000)? C>S? Handshake
????? ClientKeyExchange
1 7? 0.0104 (0.0000)? C>S? ChangeCipherSpec
1 8? 0.0104 (0.0000)? C>S? Handshake
1 9? 0.0159 (0.0054)? S>C? Handshake
????? TLS_RSA_WITH_RC4_128_MD51 10 0.0159 (0.0000)? S>C? ChangeCipherSpec
1 11 0.0159 (0.0000)? S>C? Handshake
1 12 0.0163 (0.0004)? C>S? application_data
1 13 0.0174 (0.0011)? S>C? application_data
1 14 0.0176 (0.0001)? C>S? application_data
1 15 0.0186 (0.0010)? S>C? application_data
1 16 0.0189 (0.0002)? C>S? application_data
1 17 0.0200 (0.0010)? S>C? application_data
1 18 0.0203 (0.0002)? C>S? application_data
1??? 0.0205 (0.0002)? C>S? TCP FIN
1 19 0.0207 (0.0001)? S>C? Alert
1??? 0.0209 (0.0001)? S>C? TCP FIN
?
?
***************************************
This is for *Client -> Proxy Server*
***************************************
?
1 1? 0.0025 (0.0025)? C>S? Handshake
????? ClientHello
??????? Version 3.1
??????? cipher suites
??????? TLS_DHE_RSA_WITH_AES_256_CBC_SHA
??????? TLS_DHE_DSS_WITH_AES_256_CBC_SHA
??????? TLS_RSA_WITH_AES_256_CBC_SHA
??????? TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
??????? TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
??????? TLS_RSA_WITH_3DES_EDE_CBC_SHA
??????? TLS_DHE_RSA_WITH_AES_128_CBC_SHA
??????? TLS_DHE_DSS_WITH_AES_128_CBC_SHA
??????? TLS_RSA_WITH_AES_128_CBC_SHA
??????? TLS_RSA_WITH_IDEA_CBC_SHA
??????? TLS_RSA_WITH_RC4_128_SHA
??????? Unknown value 0xff
??????? compression methods
????????????????? NULL
1 2? 3.2949 (3.2923)? S>C? Handshake
????? ServerHello
??????? Version 3.1
??????? session_id[32]=
????????? 54 76 ca 2c bd 84 37 f9 98 7a b1 57 1f 61 9a 3d
????????? 40 89 58 89 e6 14 5f 39 8b 96 62 87 8f a9 30 8f
??????? cipherSuite???????? TLS_DHE_RSA_WITH_AES_256_CBC_SHA
??????? compressionMethod?????????????????? NULL
????? Certificate
????? ServerKeyExchange
????? ServerHelloDone
1 3? 3.3135 (0.0186)? C>S? Handshake
????? ClientKeyExchange
??????? DiffieHellmanClientPublicValue[96]=
????????? 9c 38 d3 b5 10 3f 4d a6 54 a9 84 02 b3 f2 25 79
????????? e1 f0 6e 6f 56 35 44 73 13 40 4e c0 6b 2a e7 64
????????? ff 4a a0 7a 34 82 1e d9 35 70 d1 43 f8 c5 18 c4
????????? 56 54 a6 32 33 bc 1a 35 62 fe 36 cc 33 f4 a0 15
????????? 6d 7a ea 5e a6 f5 d6 d7 21 45 16 30 08 2b bc e9
????????? 4c 25 32 64 b3 a3 b9 21 db 26 b1 6c 4c 92 34 aa
1 4? 3.3135 (0.0000)? C>S? ChangeCipherSpec
1 5? 3.3135 (0.0000)? C>S? Handshake
1 6? 3.3241 (0.0106)? S>C? ChangeCipherSpec
1 7? 3.3638 (0.0396)? S>C? Handshake
1 8? 3.3638 (0.0000)? S>C? application_data
1 9? 3.3646 (0.0007)? C>S? application_data
1 10 3.3646 (0.0000)? C>S? application_data
1 11 3.4196 (0.0549)? S>C? application_data
1 12 3.4196 (0.0000)? S>C? application_data
1 13 3.4270 (0.0073)? C>S? application_data
1 14 3.4271 (0.0000)? C>S? application_data
1 15 3.4271 (0.0000)? C>S? application_data
1 16 3.4646 (0.0375)? S>C? application_data
1 17 3.4646 (0.0000)? S>C? application_data
1 18 3.4649 (0.0002)? C>S? application_data
1 19 3.4649 (0.0000)? C>S? application_data
1??? 3.4652 (0.0003)? C>S? TCP FIN
1 20 3.4657 (0.0005)? S>C? Alert
1??? 3.4658 (0.0000)? S>C? TCP FIN
?
************************************************************
?
As you can see the big time difference between the two executions - which 
actually involve the same application level data. The largest chunk of 
time is spent waiting for handshake from *Proxy Server*. The response time 
of *Proxy Server* in replying back with ServerHello, varies greatly 
between 1.5 to 11 seconds across different runs. In the present case it is 
nearly 3.3 seconds - which IMO is not acceptable.


*****************************************************
Above this was previous content.


> From: owner-openssl-users at openssl.org On Behalf Of Dave Thompson

> does Proxy code do between accepting on the [SSL]ServerSocket 
> (which is Java's way of representing the listen-ing socket) and the 
> first read or write -- apparently write? One particular thing, is it 
> using BufferedReader/Writer on the socket streams? Java code 
> often does buffered because it is more efficient than going to OS 
> each time (at least for real I/O rather than ByteArray Streams).
> In that case for output you need .flush() to actually send. 
> Or you could try doing .startHandshake() explicitly as soon as 
> convenient after the .accept() and see what difference that 
> makes (although it may only move the problem elsewhere).

Thanks Dave for your pointer. The code is actually using 
BufferedReader/Writer. Further, I actually tried adding 
startHandshake() explicitly after socket accept(). However, what I 
observed is that now startHandshake() gets blocked and takes up 
the same amount of time as the first read/write used to take. After
this change, the actual read/write calls become very fast including 
the first call. So the problem it appears is in the SSL handshake 
response code from the java side. 

I am pretty sure the issue is not related to OpenSSL but in the 
java side. Further, since it is startHandshake() that is blocking for this
much time, it is not a problem with *our* Java Code. But just to be 
sure could it have anything to do with ciphers/encryption/keys etc. 
Any other pointers/help is highly appreciated.


Thanks, for reading through such a lengthy email. If anybody can kindly 
provide his inputs, or even point me in the right direction, I shall be 
highly grateful. Any other comments or suggestions are also highly 
welcome. Thanks for your patience,
?
Prabhat.

 		 	   		  

From rsalz at akamai.com  Thu Dec 18 21:24:39 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Dec 2014 16:24:39 -0500
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0FAB7@USMBX1.msg.corp.akamai.com>

> *Client* and *Agent* are implemented in C, while *Proxy Server* uses Java
> code (This shouldn't really matter). But might be helpful for you to know.
> The issue is, connecting *Client* to *Agent* is very fast (that is relatively).
> While connecting *Client* to *Proxy Server* is very slow - that is orders of
> magnitudes slow.

Why do you say it shouldn't matter?  The new Java proxy server is most likely the cause.  Do some packet captures, between Client<>Agent and Clinet<>Proxy. L ook at the timing, and see if the client ends up waiting for packets from the proxy.

From kurt at roeckx.be  Thu Dec 18 21:36:08 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Thu, 18 Dec 2014 22:36:08 +0100
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
Message-ID: <20141218213608.GA1870@roeckx.be>

On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote:
> ***************************************
> This is for *Client -> Agent*
> ***************************************
[...]
> ??????? Version 3.1
[...]
> ??????? cipherSuite???????? TLS_RSA_WITH_AES_256_CBC_SHA
[...]
> ***************************************
> This is for *Client -> Proxy Server*
> ***************************************
> ??????? cipherSuite???????? TLS_DHE_RSA_WITH_AES_256_CBC_SHA

So the differnce here is that jave picks a DHE ciphersuite while
otherwise you didn't.  DHE gives you forward secrecy but is
slower.

You're also not using session resumption which might speed up the
whole process.  It at least looks like that proxy server might
support that.

You also seem to be using an old version of openssl that only
supports TLSv1, I suggest you upgrade.


Kurt


From prabhat.puroshottam at outlook.com  Thu Dec 18 22:48:38 2014
From: prabhat.puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 19 Dec 2014 04:18:38 +0530
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0FAB7@USMBX1.msg.corp.akamai.com>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>,
 <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0FAB7@USMBX1.msg.corp.akamai.com>
Message-ID: <COL131-W73003EEEE21C3ABF4EEAB5EE6A0@phx.gbl>

> Why do you say it shouldn't matter? The new Java proxy server is most likely the cause. Do some packet captures, between Client<>Agent and Clinet<>Proxy. L ook at the timing, and see if the client ends up waiting for packets from the proxy.

Sorry may be I wasn't able to convey it. The java proxy server is our code as well.
The problem isn't application data transfer, but that Java Server takes inordinate
amount of time before sending ServerHello. The application data transfer itself takes
very less time.
 		 	   		  

From prabhat.puroshottam at outlook.com  Thu Dec 18 23:00:01 2014
From: prabhat.puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 19 Dec 2014 04:30:01 +0530
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <20141218213608.GA1870@roeckx.be>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>,
 <20141218213608.GA1870@roeckx.be>
Message-ID: <COL131-W415787E129BDE5513013D2EE6A0@phx.gbl>

> So the differnce here is that jave picks a DHE ciphersuite while
> otherwise you didn't. DHE gives you forward secrecy but is
> slower.

Being relatively new to OpenSSL and security programming in general,
obviously I need to read into these, but could it cause the delay in
sending ServerHello by Java Server. From your above statement I can make
out that it might make overall communication slower, but I believe
application data transfer is not the concern (at least not now), but only
inordinate delay while performing SSL handshake.


> You're also not using session resumption which might speed up the
> whole process. It at least looks like that proxy server might
> support that.

Thanks, that was the next step I was going to work on. Would you be so
kind as to point out to me how you figured out that proxy server might
support session resumption? Sorry if this is a very naive question.


 		 	   		  

From prabhat.puroshottam at outlook.com  Thu Dec 18 22:58:08 2014
From: prabhat.puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 19 Dec 2014 04:28:08 +0530
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <20141218213608.GA1870@roeckx.be>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>,
 <20141218213608.GA1870@roeckx.be>
Message-ID: <COL131-W3AB3B1AD5B3061F390CB9EE6A0@phx.gbl>

> So the differnce here is that jave picks a DHE ciphersuite while
> otherwise you didn't. DHE gives you forward secrecy but is
> slower.

Being relatively new to OpenSSL and security programming in general, 
obviously I need to read into these, but could it cause the delay in 
sending ServerHello by Java Server. From your above statement I can make
out that it might make overall communication slower, but I believe
application data transfer is not the concern (at least not now), but only
inordinate delay while performing SSL handshake.


> You're also not using session resumption which might speed up the
> whole process. It at least looks like that proxy server might
> support that.

Thanks, that was the next step I was going to work on. Would you be so
kind as to point out to me how you figured out that proxy server might
support session resumption? Sorry if this is a very naive question.


 		 	   		  

From prabhat.puroshottam at outlook.com  Thu Dec 18 23:10:10 2014
From: prabhat.puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 19 Dec 2014 04:40:10 +0530
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
Message-ID: <COL131-W8288E4D8E3A5036B159007EE6A0@phx.gbl>

I am trying to summarize the problem again, since the previous 
mail seems confusing to some of you. It might help you quickly understand
the problem I am facing:

We have a product, where Client connects to Server (Proxy Server in my 
earlier mail). Client is implemented in C and uses OpenSSL, while Server is 
implemented using Java code with BufferedInputStream and 
BufferedOutputStream. The following are my observations:

1. There is "inordinate" delay during connection establishment.
2. Using ssldump it was found that SSL handshake response from Server is 
??? taking most of the time. Rest of the application data transfer and 
??? processing hardly takes fraction of a second. The response from SSL 
??? handshake by Server comes after anywhere between 2 to 13 seconds 
??? after initial response sent by Client.
3. Subsequent analysis of the code showed that it was the first Buffered 
?? Read/Write which was taking "inordinate" amount of time.
4. Understanding that first Buffered Read/Write was hung on SSL connection 
??? completion, I introduced SSLConnect::startHandshake() so that I can 
??? explicitly see where is the problem. It was observed that now 
??? startHandshake() blocked for as much time as first Read/Write did. 
??? Further none of the Read/Write calls block, and returned data almost 
??? immediately.

I would like to understand why startHandshake() is taking so long. I 
understand that it is a asynchronous call, but still the time delay is too much
IMO. Is it something to do with the socket configuration/cipher/encryption 
used? Using ssldump I found there was absolutely no data transfer 
between the sending of client's hello request and subsequent response 
from server, so apparently all the time startHandshake() is busy doing 
something or may be nothing - what I have no idea. FWIW, this is not a 
network latency issue, 1) all the boxes are on the same network, 2) all 
other data transfers combined takes less than 0.4s.

Can somebody kindly suggest what might be wrong or what can be done to 
fix this? Could it be some Socket or SSL setting, encryption/cipher used, or 
something else?


-Prabhat

 		 	   		  

From rsalz at akamai.com  Thu Dec 18 23:14:54 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 18 Dec 2014 18:14:54 -0500
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <COL131-W8288E4D8E3A5036B159007EE6A0@phx.gbl>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <COL131-W8288E4D8E3A5036B159007EE6A0@phx.gbl>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0FB15@USMBX1.msg.corp.akamai.com>

> I would like to understand why startHandshake() is taking so long.


Somebody else pointed out the differences in ciphers.  You should take the time to understand that message.

From prabhat.puroshottam at outlook.com  Thu Dec 18 22:56:31 2014
From: prabhat.puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 19 Dec 2014 04:26:31 +0530
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <20141218213608.GA1870@roeckx.be>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>,
 <20141218213608.GA1870@roeckx.be>
Message-ID: <COL131-W85CDC0895B9005BA67F9EDEE6A0@phx.gbl>



----------------------------------------
> Date: Thu, 18 Dec 2014 22:36:08 +0100
> From: kurt at roeckx.be
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] OpenSSL performance issue
>
> On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote:
>> ***************************************
>> This is for *Client -> Agent*
>> ***************************************
> [...]
>>         Version 3.1
> [...]
>>         cipherSuite         TLS_RSA_WITH_AES_256_CBC_SHA
> [...]
>> ***************************************
>> This is for *Client -> Proxy Server*
>> ***************************************
>>         cipherSuite         TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>
> So the differnce here is that jave picks a DHE ciphersuite while
> otherwise you didn't. DHE gives you forward secrecy but is
> slower.

Being relatively new to OpenSSL and security programming in general, 
obviously I need to read into these, but could it cause the delay in 
sending ServerHello by Java Server. From your above statement I can make
out that it might make overall communication slower, but I believe
application data transfer is not the concern (at least not now), but only
inordinate delay while performing SSL handshake.


> You're also not using session resumption which might speed up the
> whole process. It at least looks like that proxy server might
> support that.

Thanks, that was the next step I was going to work on. Would you be so
kind as to point out to me how you figured out that proxy server might
support session resumption? Sorry if this is a very naive question.


 		 	   		  

From prabhat.puroshottam at outlook.com  Thu Dec 18 22:57:01 2014
From: prabhat.puroshottam at outlook.com (Prabhat Puroshottam)
Date: Fri, 19 Dec 2014 04:27:01 +0530
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <20141218213608.GA1870@roeckx.be>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>,
 <20141218213608.GA1870@roeckx.be>
Message-ID: <COL131-W39D2C430F68E66792131B7EE6A0@phx.gbl>



----------------------------------------
> Date: Thu, 18 Dec 2014 22:36:08 +0100
> From: kurt at roeckx.be
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] OpenSSL performance issue
>
> On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote:
>> ***************************************
>> This is for *Client -> Agent*
>> ***************************************
> [...]
>>         Version 3.1
> [...]
>>         cipherSuite         TLS_RSA_WITH_AES_256_CBC_SHA
> [...]
>> ***************************************
>> This is for *Client -> Proxy Server*
>> ***************************************
>>         cipherSuite         TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>
> So the differnce here is that jave picks a DHE ciphersuite while
> otherwise you didn't. DHE gives you forward secrecy but is
> slower.

Being relatively new to OpenSSL and security programming in general, 
obviously I need to read into these, but could it cause the delay in 
sending ServerHello by Java Server. From your above statement I can make
out that it might make overall communication slower, but I believe
application data transfer is not the concern (at least not now), but only
inordinate delay while performing SSL handshake.


> You're also not using session resumption which might speed up the
> whole process. It at least looks like that proxy server might
> support that.

Thanks, that was the next step I was going to work on. Would you be so
kind as to point out to me how you figured out that proxy server might
support session resumption? Sorry if this is a very naive question.


 		 	   		  

From Michael.Wojcik at microfocus.com  Fri Dec 19 02:27:03 2014
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 19 Dec 2014 02:27:03 +0000
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <20141218213608.GA1870@roeckx.be>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <20141218213608.GA1870@roeckx.be>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088012E6286C8@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Kurt Roeckx
> Sent: Thursday, December 18, 2014 16:36
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] OpenSSL performance issue
> 
> So the differnce here is that jave picks a DHE ciphersuite while otherwise you
> didn't.  DHE gives you forward secrecy but is slower.

And if DH parameters have not been set, OpenSSL will have to generate them on the fly, which can be *very* slow (relative to normal conversation establishment).

The OP might benefit from reading

https://wiki.openssl.org/index.php/Diffie_Hellman
https://wiki.openssl.org/index.php/Diffie-Hellman_parameters

-- 
Michael Wojcik
Technology Specialist, Micro Focus



This message has been scanned for malware by Websense. www.websense.com

From dthompson at prinpay.com  Fri Dec 19 10:50:25 2014
From: dthompson at prinpay.com (Dave Thompson)
Date: Fri, 19 Dec 2014 05:50:25 -0500
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <B550B44BF8AF314BB00C4E2AC1C18088012E6286C8@Rock-Exchange1.microfocus.com>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <20141218213608.GA1870@roeckx.be>
 <B550B44BF8AF314BB00C4E2AC1C18088012E6286C8@Rock-Exchange1.microfocus.com>
Message-ID: <001501d01b79$9acd8f60$d068ae20$@prinpay.com>

> From: openssl-users On Behalf Of Michael Wojcik
> Sent: Thursday, December 18, 2014 21:27

> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> Behalf
> > Of Kurt Roeckx
> > Sent: Thursday, December 18, 2014 16:36
> > To: openssl-users at openssl.org
> > Subject: Re: [openssl-users] OpenSSL performance issue
> >
> > So the differnce here is that jave picks a DHE ciphersuite while
otherwise
> you
> > didn't.  DHE gives you forward secrecy but is slower.
> 
> And if DH parameters have not been set, OpenSSL will have to generate
> them on the fly, which can be *very* slow (relative to normal conversation
> establishment).
> 
I think this is new in trunk; in all released versions of OpenSSL server 
it won't use DHE/A and or ECDHE/A if parameters have not been set.

And the case here is OpenSSL client to Java proxy acting as server.
JSSE server uses hardcoded parameters, from some standard -- 
I vaguely recall it being Oakley but don't remember details.



From dthompson at prinpay.com  Fri Dec 19 10:50:25 2014
From: dthompson at prinpay.com (Dave Thompson)
Date: Fri, 19 Dec 2014 05:50:25 -0500
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <20141218213608.GA1870@roeckx.be>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <20141218213608.GA1870@roeckx.be>
Message-ID: <001601d01b79$9c589c30$d509d490$@prinpay.com>

> From: openssl-users On Behalf Of Kurt Roeckx
> Sent: Thursday, December 18, 2014 16:36

> On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote:
> > ***************************************
> > This is for *Client -> Agent*
> > ***************************************
> [...]
> > ??????? Version 3.1
> [...]
> > ??????? cipherSuite???????? TLS_RSA_WITH_AES_256_CBC_SHA
> [...]
> > ***************************************
> > This is for *Client -> Proxy Server*
> > ***************************************
> > ??????? cipherSuite???????? TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> 
> So the differnce here is that jave picks a DHE ciphersuite while
> otherwise you didn't.  DHE gives you forward secrecy but is
> slower.
> 
Good catch, I missed that. But, it shouldn't be many *seconds* 
unless this is very poor hardware. Especially since Java 7 
(and IIRC 6) uses, as you can see later in the trace, 768 bits.
(Except export suites use 512 per RFC. Java 8 defaults DHE 
to 1024 and offers some new options for better.)

Although that reminds me, on the *first* session in a process, 
there might be delay to initialize SecureRandom, depending on 
the platform and options/environment. But not for all sessions.

To OP: assuming this delay happens on non-initial sessions 
more than rarely, can you try putting jconsole or the newer 
(but more complicated) "Java Mission Control" tools on 
the JVM running the proxy server while driving it with 
as many requests as you can, to get some (rough) idea 
what's going on: is it CPU bound? which threads? if you can 
capture stacks, which methods? Is it swapping?

One other thought: normally JSSE server uses a key manager 
that is preloaded from a JKS. Are you using an unusual 
key manager like a PKCS#11 "token", or even a custom one 
that does something costly like fetching from LDAP?

> You're also not using session resumption which might speed up the
> whole process.  It at least looks like that proxy server might
> support that.
> 
I assumed OP's traces are the first session. Besides OpenSSL 
client doesn't cache by default; you must code to enable it.

> You also seem to be using an old version of openssl that only
> supports TLSv1, I suggest you upgrade.
> 
Good in general, but very unlikely to change JSSE-server performance.



From jb-openssl at wisemo.com  Fri Dec 19 11:11:46 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 19 Dec 2014 12:11:46 +0100
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <COL131-W8288E4D8E3A5036B159007EE6A0@phx.gbl>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <COL131-W8288E4D8E3A5036B159007EE6A0@phx.gbl>
Message-ID: <549407F2.6040204@wisemo.com>

On 19/12/2014 00:10, Prabhat Puroshottam wrote:
> I am trying to summarize the problem again, since the previous
> mail seems confusing to some of you. It might help you quickly understand
> the problem I am facing:
>
> We have a product, where Client connects to Server (Proxy Server in my
> earlier mail). Client is implemented in C and uses OpenSSL, while Server is
> implemented using Java code with BufferedInputStream and
> BufferedOutputStream. The following are my observations:
>
> 1. There is "inordinate" delay during connection establishment.
> 2. Using ssldump it was found that SSL handshake response from Server is
>      taking most of the time. Rest of the application data transfer and
>      processing hardly takes fraction of a second. The response from SSL
>      handshake by Server comes after anywhere between 2 to 13 seconds
>      after initial response sent by Client.
> 3. Subsequent analysis of the code showed that it was the first Buffered
>     Read/Write which was taking "inordinate" amount of time.
> 4. Understanding that first Buffered Read/Write was hung on SSL connection
>      completion, I introduced SSLConnect::startHandshake() so that I can
>      explicitly see where is the problem. It was observed that now
>      startHandshake() blocked for as much time as first Read/Write did.
>      Further none of the Read/Write calls block, and returned data almost
>      immediately.
>
> I would like to understand why startHandshake() is taking so long. I
> understand that it is a asynchronous call, but still the time delay is too much
> IMO. Is it something to do with the socket configuration/cipher/encryption
> used? Using ssldump I found there was absolutely no data transfer
> between the sending of client's hello request and subsequent response
> from server, so apparently all the time startHandshake() is busy doing
> something or may be nothing - what I have no idea. FWIW, this is not a
> network latency issue, 1) all the boxes are on the same network, 2) all
> other data transfers combined takes less than 0.4s.
>
> Can somebody kindly suggest what might be wrong or what can be done to
> fix this? Could it be some Socket or SSL setting, encryption/cipher used, or
> something else?
>
 From the traces in your previous questions, and the answers you have 
already
given, I guess this is what happens:

1. The difference is in how long the Java code spends during the initial key
   exchange.

2. The SSL code in the proxy, (but not the one in your own server) is 
configured
   to support Ephemeral Diffie-Hellman (DHE) handshake, which is safer, but
   potentially slower.  The slowness of DHE happens only during the 
handshake,
   because the data transmission part is the same.  For example
   RSA_AES256_SHA256 and DHE_RSA_AES_SHA256 use the same transmission
   phase, but different handshakes.  The safety of DHE is that it 
protects you
   if someone "tapes" the encrypted connection and later steal the private
   key of the proxy/server.

3. The slowest part of doing a DHE exchange is choosing a (non-secret) 
prime,
  which can be used again and again for many connections.  This is only done
  by the server end of a TLS/SSL connection.  The prime (and a few related
  numbers is known as the "DH group parameters".

4. If you were to enable DHE in an OpenSSL based server/proxy, the standard
  solution is to choose the non-secret prime during server startup, 
before any
  connection arrives.  Some programs even choose it while configuring the
  server program, storing the prime in a file.

5. From the long time spent by the Java code generating its ServerHello, I
  suspect it is generating the prime during the handshake, and choosing a
  new prime for each connection, thus wasting a lot of time.

6. Maybe there is a way to tell the Java SSL library to generate the DH
  group parameters for needed key lengths (1024, 2048 or whatever you
  need) during proxy startup, so it is ready by the time the client 
connects.

7. If you upgrade to OpenSSL 1.0.1 or later (remember to only use the
  latest letter-suffix security update of whatever version), you could also
  use an ECDHE_RSA_xxx crypto mode, these don't currently allow the
  server/proxy to generate their own group parameters, but force you
  to choose from a short list of parameters generated by professional
  spying agencies such as the NSA (the "NIST curves") or someone else
  (the "X9.62 curves", the "SECG curves" and the "WTLS curves").  So
  your computers don't spend time generating the parameters, and
  you just have to trust the professionals who chose them for you.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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.opensslfoundation.net/pipermail/openssl-users/attachments/20141219/6fbe42c7/attachment.html>

From jb-openssl at wisemo.com  Fri Dec 19 11:19:35 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 19 Dec 2014 12:19:35 +0100
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <549407F2.6040204@wisemo.com>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <COL131-W8288E4D8E3A5036B159007EE6A0@phx.gbl> <549407F2.6040204@wisemo.com>
Message-ID: <549409C7.9010605@wisemo.com>

On 19/12/2014 12:11, Jakob Bohm wrote:
> On 19/12/2014 00:10, Prabhat Puroshottam wrote:
>> I am trying to summarize the problem again, since the previous
>> mail seems confusing to some of you. It might help you quickly understand
>> the problem I am facing:
>>
>> We have a product, where Client connects to Server (Proxy Server in my
>> earlier mail). Client is implemented in C and uses OpenSSL, while Server is
>> implemented using Java code with BufferedInputStream and
>> BufferedOutputStream. The following are my observations:
>>
>> 1. There is "inordinate" delay during connection establishment.
>> 2. Using ssldump it was found that SSL handshake response from Server is
>>      taking most of the time. Rest of the application data transfer and
>>      processing hardly takes fraction of a second. The response from SSL
>>      handshake by Server comes after anywhere between 2 to 13 seconds
>>      after initial response sent by Client.
>> 3. Subsequent analysis of the code showed that it was the first Buffered
>>     Read/Write which was taking "inordinate" amount of time.
>> 4. Understanding that first Buffered Read/Write was hung on SSL connection
>>      completion, I introduced SSLConnect::startHandshake() so that I can
>>      explicitly see where is the problem. It was observed that now
>>      startHandshake() blocked for as much time as first Read/Write did.
>>      Further none of the Read/Write calls block, and returned data almost
>>      immediately.
>>
>> I would like to understand why startHandshake() is taking so long. I
>> understand that it is a asynchronous call, but still the time delay is too much
>> IMO. Is it something to do with the socket configuration/cipher/encryption
>> used? Using ssldump I found there was absolutely no data transfer
>> between the sending of client's hello request and subsequent response
>> from server, so apparently all the time startHandshake() is busy doing
>> something or may be nothing - what I have no idea. FWIW, this is not a
>> network latency issue, 1) all the boxes are on the same network, 2) all
>> other data transfers combined takes less than 0.4s.
>>
>> Can somebody kindly suggest what might be wrong or what can be done to
>> fix this? Could it be some Socket or SSL setting, encryption/cipher used, or
>> something else?
>>
> From the traces in your previous questions, and the answers you have 
> already
> given, I guess this is what happens:
>
> 1. The difference is in how long the Java code spends during the 
> initial key
>   exchange.
>
> 2. The SSL code in the proxy, (but not the one in your own server) is 
> configured
>   to support Ephemeral Diffie-Hellman (DHE) handshake, which is safer, but
>   potentially slower.  The slowness of DHE happens only during the 
> handshake,
>   because the data transmission part is the same.  For example
>   RSA_AES256_SHA256 and DHE_RSA_AES_SHA256 use the same transmission
>   phase, but different handshakes.  The safety of DHE is that it 
> protects you
>   if someone "tapes" the encrypted connection and later steal the private
>   key of the proxy/server.
>
> 3. The slowest part of doing a DHE exchange is choosing a (non-secret) 
> prime,
>  which can be used again and again for many connections.  This is only 
> done
>  by the server end of a TLS/SSL connection.  The prime (and a few related
>  numbers is known as the "DH group parameters".
>
> 4. If you were to enable DHE in an OpenSSL based server/proxy, the 
> standard
>  solution is to choose the non-secret prime during server startup, 
> before any
>  connection arrives.  Some programs even choose it while configuring the
>  server program, storing the prime in a file.
>
> 5. From the long time spent by the Java code generating its ServerHello, I
>  suspect it is generating the prime during the handshake, and choosing a
>  new prime for each connection, thus wasting a lot of time.
Dave Thompson (who knows more than I do) pointed out that if this is the
SSL library included with Oracle Java, then it doesn't do that, but it does
waste time on another operation (random number generator setup),
which is the same for all handshake methods.
>
> 6. Maybe there is a way to tell the Java SSL library to generate the DH
>  group parameters for needed key lengths (1024, 2048 or whatever you
>  need) during proxy startup, so it is ready by the time the client 
> connects.
>
If the problem is really initializing the Java secure random number 
generator,
you could probably force it to initialize earlier by simply adding Java code
that asks for one byte of cryptographically strong bits, then throws it 
away,
thus forcing the Java runtime to initialize its random number library at 
that
time (before the connection arrives).
> 7. If you upgrade to OpenSSL 1.0.1 or later (remember to only use the
>  latest letter-suffix security update of whatever version), you could also
>  use an ECDHE_RSA_xxx crypto mode, these don't currently allow the
>  server/proxy to generate their own group parameters, but force you
>  to choose from a short list of parameters generated by professional
>  spying agencies such as the NSA (the "NIST curves") or someone else
>  (the "X9.62 curves", the "SECG curves" and the "WTLS curves"). So
>  your computers don't spend time generating the parameters, and
>  you just have to trust the professionals who chose them for you.


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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.opensslfoundation.net/pipermail/openssl-users/attachments/20141219/f6034ad6/attachment-0001.html>

From benjamin10 at gmx.at  Fri Dec 19 12:13:59 2014
From: benjamin10 at gmx.at (Benjamin)
Date: Fri, 19 Dec 2014 13:13:59 +0100
Subject: [openssl-users] Creating a Certificate with CA=TRUE
Message-ID: <54941687.8000305@gmx.at>

An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141219/000df28b/attachment.html>

From jb-openssl at wisemo.com  Fri Dec 19 13:52:53 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 19 Dec 2014 14:52:53 +0100
Subject: [openssl-users] Creating a Certificate with CA=TRUE
In-Reply-To: <54941687.8000305@gmx.at>
References: <54941687.8000305@gmx.at>
Message-ID: <54942DB5.3010902@wisemo.com>

On 19/12/2014 13:13, Benjamin wrote:
> Hello everyone!
> I am quite new to two things: this mailing list and making and working 
> with certificates
>
> I want to run a small owncloud on my raspberry pi and tried to make a 
> crt which I can also use with my mobile devices. Here is the problem:
> When i make a certificate either with this instruction:
> http://wiki.ubuntuusers.de/CA
> or this one:
> https://www.prshanmu.com/2009/03/generating-ssl-certificates-with-x509v3-extensions.html
>
> i have the problem that the cacert has "basicconstriants CA=TRUE" but 
> when i make a cert by request i got a new cert (as far as i knew, that 
> which i should use for my nginx webserver) which has CA=FALSE. This is 
> no problem normally but my Android phone only accepts Certs with 
> CA=TRUE and actually i don?t know how to make such a certificate?Of 
> course, i could use the cacert itself but isn?t this insecure and 
> inadequate?
>
I very much doubt that Android only accepts certificates with CA=TRUE.

Unless of cause you are accidentally using an Android command to
install the "public certificate" of a CA, rather than a command
to install the "private key+public certificate" of a certificate
for the Android itself.  I seem to recall that the Android user
interfaces for these things are a bit confusingly named.

It should be perfectly safe (for the CA) to install the "public
certificate" (with CA=TRUE) of the CA on your phone, PC, posted
on your Google+ profile and any other place you think of, since
this is the whole point (notice how the big names go to extreme
lengths to get theirs included in every browser, OS, Phone etc.
sold).  Only the matching "private key" of your mini-CA needs to
be kept in a very secret and locked down place, such as on a
separate CA boot-SD that you only boot from when issuing new
certificates or refreshing your CRL.

> Thanks, best Benjamin!

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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 reichert at numachi.com  Fri Dec 19 15:17:43 2014
From: reichert at numachi.com (Brian Reichert)
Date: Fri, 19 Dec 2014 10:17:43 -0500
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
Message-ID: <20141219151743.GC4505@numachi.com>

On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote:
> As you can see the big time difference between the two executions - which 
> actually involve the same application level data. The largest chunk of 
> time is spent waiting for handshake from *Proxy Server*. The response time 
> of *Proxy Server* in replying back with ServerHello, varies greatly 
> between 1.5 to 11 seconds across different runs. In the present case it is 
> nearly 3.3 seconds - which IMO is not acceptable.

Is Client providing a certicate?  Perhaps Proxy is spending time
checking CRLs.  That would involve Proxy reaching out to one or
more URLs, with the attendant latencies of DNS resolution, TCP
session setup, and HTTP requests.

Do you have any intrumentation showing you what activity Proxy is
doing between ClientHEllo and ServerHello?

> Thanks, for reading through such a lengthy email. If anybody can kindly 
> provide his inputs, or even point me in the right direction, I shall be 
> highly grateful. Any other comments or suggestions are also highly 
> welcome. Thanks for your patience,
> ?
> Prabhat.
> 
>  		 	   		  
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

-- 
Brian Reichert				<reichert at numachi.com>
BSD admin/developer at large	

From matt at openssl.org  Fri Dec 19 15:32:35 2014
From: matt at openssl.org (Matt Caswell)
Date: Fri, 19 Dec 2014 15:32:35 +0000
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <20141219151743.GC4505@numachi.com>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <20141219151743.GC4505@numachi.com>
Message-ID: <54944513.7060305@openssl.org>


On 19/12/14 15:17, Brian Reichert wrote:
> On Fri, Dec 19, 2014 at 02:30:07AM +0530, Prabhat Puroshottam wrote:
>> As you can see the big time difference between the two executions - which 
>> actually involve the same application level data. The largest chunk of 
>> time is spent waiting for handshake from *Proxy Server*. The response time 
>> of *Proxy Server* in replying back with ServerHello, varies greatly 
>> between 1.5 to 11 seconds across different runs. In the present case it is 
>> nearly 3.3 seconds - which IMO is not acceptable.
> Is Client providing a certicate?  Perhaps Proxy is spending time
> checking CRLs.  That would involve Proxy reaching out to one or
> more URLs, with the attendant latencies of DNS resolution, TCP
> session setup, and HTTP requests.
>
Client certificates are not provided as part of the ClientHello, so I
don't think this is the problem.

Matt


From steve at openssl.org  Fri Dec 19 16:36:55 2014
From: steve at openssl.org (Dr. Stephen Henson)
Date: Fri, 19 Dec 2014 16:36:55 +0000
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <001501d01b79$9acd8f60$d068ae20$@prinpay.com>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <20141218213608.GA1870@roeckx.be>
 <B550B44BF8AF314BB00C4E2AC1C18088012E6286C8@Rock-Exchange1.microfocus.com>
 <001501d01b79$9acd8f60$d068ae20$@prinpay.com>
Message-ID: <20141219163655.GA31648@openssl.org>

On Fri, Dec 19, 2014, Dave Thompson wrote:

> > From: openssl-users On Behalf Of Michael Wojcik
> > Sent: Thursday, December 18, 2014 21:27
> 
> > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On
> > Behalf
> > > Of Kurt Roeckx
> > > Sent: Thursday, December 18, 2014 16:36
> > > To: openssl-users at openssl.org
> > > Subject: Re: [openssl-users] OpenSSL performance issue
> > >
> > > So the differnce here is that jave picks a DHE ciphersuite while
> otherwise
> > you
> > > didn't.  DHE gives you forward secrecy but is slower.
> > 
> > And if DH parameters have not been set, OpenSSL will have to generate
> > them on the fly, which can be *very* slow (relative to normal conversation
> > establishment).
> > 
> I think this is new in trunk; in all released versions of OpenSSL server 
> it won't use DHE/A and or ECDHE/A if parameters have not been set.
> 

I'm not aware of any version of OpenSSL that generates DH parameters on the
fly. If no DH parameters are set then ephemeral DH ciphersuites are disabled.

It's a similar story for ECDH. OpenSSL 1.0.2+ supports "auto ECDH" which 
will look up ECDH parameters on the fly but that's just look up which is a
cheap operation.

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

From Michael.Wojcik at microfocus.com  Fri Dec 19 17:28:23 2014
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 19 Dec 2014 17:28:23 +0000
Subject: [openssl-users] OpenSSL performance issue
In-Reply-To: <20141219163655.GA31648@openssl.org>
References: <COL131-W436C88FB115FD95E949C8BEE6A0@phx.gbl>
 <20141218213608.GA1870@roeckx.be>
 <B550B44BF8AF314BB00C4E2AC1C18088012E6286C8@Rock-Exchange1.microfocus.com>
 <001501d01b79$9acd8f60$d068ae20$@prinpay.com>
 <20141219163655.GA31648@openssl.org>
Message-ID: <B550B44BF8AF314BB00C4E2AC1C18088012E628D79@Rock-Exchange1.microfocus.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Dr. Stephen Henson
> Sent: Friday, December 19, 2014 11:37
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] OpenSSL performance issue
> 
> On Fri, Dec 19, 2014, Dave Thompson wrote:
> 
> > > From: openssl-users On Behalf Of Michael Wojcik
> > > Sent: Thursday, December 18, 2014 21:27
> >
> > >
> > > And if DH parameters have not been set, OpenSSL will have to
> > > generate them on the fly, which can be *very* slow (relative to
> > > normal conversation establishment).
> > >
> > I think this is new in trunk; in all released versions of OpenSSL
> > server it won't use DHE/A and or ECDHE/A if parameters have not been set.
> >
> 
> I'm not aware of any version of OpenSSL that generates DH parameters on
> the fly. If no DH parameters are set then ephemeral DH ciphersuites are
> disabled.
> 
> It's a similar story for ECDH. OpenSSL 1.0.2+ supports "auto ECDH" which will
> look up ECDH parameters on the fly but that's just look up which is a cheap
> operation.

Thanks for the correction. There's a comment somewhere in our OpenSSL-invoking code about DH parameters being generated on the fly, but I guess that was based on a misunderstanding. (The code actually sets DH parameters; the comment was something along the lines of "we want to do this to avoid possible runtime delays when using DH suites".)

-- 
Michael Wojcik
Technology Specialist, Micro Focus




This message has been scanned for malware by Websense. www.websense.com

From noloader at gmail.com  Fri Dec 19 20:43:08 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Fri, 19 Dec 2014 15:43:08 -0500
Subject: [openssl-users] Creating a Certificate with CA=TRUE
In-Reply-To: <54941687.8000305@gmx.at>
References: <54941687.8000305@gmx.at>
Message-ID: <CAH8yC8kAQnA+hp+rr1EeytmbbEXwwwJNK3mjK0+PyrdWdtJerA@mail.gmail.com>

On Fri, Dec 19, 2014 at 7:13 AM, Benjamin <benjamin10 at gmx.at> wrote:
> Hello everyone!
> I am quite new to two things: this mailing list and making and working with
> certificates
>
> I want to run a small owncloud on my raspberry pi and tried to make a crt
> which I can also use with my mobile devices. Here is the problem:
> When i make a certificate either with this instruction:
> http://wiki.ubuntuusers.de/CA
> or this one:
> https://www.prshanmu.com/2009/03/generating-ssl-certificates-with-x509v3-extensions.html
>
> i have the problem that the cacert has "basicconstriants CA=TRUE" but when i
> make a cert by request i got a new cert (as far as i knew, that which i
> should use for my nginx webserver) which has CA=FALSE. This is no problem
> normally but my Android phone only accepts Certs with CA=TRUE and actually i
> don?t know how to make such a certificate?Of course, i could use the cacert
> itself but isn?t this insecure and inadequate?

You can't install self signed certificates (CA=FALSE). You can install
client certificates and CA certificates. See
https://support.google.com/nexus/answer/2844832?hl=en.

What you should do is create a CA, sign the web server's certificate
with your CA, and then install the CA on your Android device.

The problem (of the Internet of Things and self-signed certifcates
intersecting with Browsers) was recently brought up on the Web App Sec
mailing list (see
http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0203.html).
There's nothing available at the moment - the Browsers only support
the CA Zoo security model.

Jeff

From benjamin10 at gmx.at  Sat Dec 20 10:08:01 2014
From: benjamin10 at gmx.at (Benjamin Draxlbauer)
Date: Sat, 20 Dec 2014 11:08:01 +0100
Subject: [openssl-users] Creating a Certificate with CA=TRUE
In-Reply-To: <CAH8yC8kAQnA+hp+rr1EeytmbbEXwwwJNK3mjK0+PyrdWdtJerA@mail.gmail.com>
References: <54941687.8000305@gmx.at>
 <CAH8yC8kAQnA+hp+rr1EeytmbbEXwwwJNK3mjK0+PyrdWdtJerA@mail.gmail.com>
Message-ID: <058FF4CD-85A6-4CF5-8FFD-F1DE8A665F18@gmx.at>

Okay thanks a lot for the quick replies! 
I hope i got that right : it is sufficiently secure and unproblematic to create a CA and use this CA (lets call it root-crt) certificate on my webserver and smartphone and wherever it is needes. In short: you can use the cacert.pem which is produced by ../CA.pl -newca. 
And the /private/cakey.pem should  be stored in a secret place on a external device which is offline (sd card usb etc. in my cellar). 

Is this right?

Thanks for support! 

Am 19. Dezember 2014 21:43:08 MEZ, schrieb Jeffrey Walton <noloader at gmail.com>:
>On Fri, Dec 19, 2014 at 7:13 AM, Benjamin <benjamin10 at gmx.at> wrote:
>> Hello everyone!
>> I am quite new to two things: this mailing list and making and
>working with
>> certificates
>>
>> I want to run a small owncloud on my raspberry pi and tried to make a
>crt
>> which I can also use with my mobile devices. Here is the problem:
>> When i make a certificate either with this instruction:
>> http://wiki.ubuntuusers.de/CA
>> or this one:
>>
>https://www.prshanmu.com/2009/03/generating-ssl-certificates-with-x509v3-extensions.html
>>
>> i have the problem that the cacert has "basicconstriants CA=TRUE" but
>when i
>> make a cert by request i got a new cert (as far as i knew, that which
>i
>> should use for my nginx webserver) which has CA=FALSE. This is no
>problem
>> normally but my Android phone only accepts Certs with CA=TRUE and
>actually i
>> don?t know how to make such a certificate?Of course, i could use the
>cacert
>> itself but isn?t this insecure and inadequate?
>
>You can't install self signed certificates (CA=FALSE). You can install
>client certificates and CA certificates. See
>https://support.google.com/nexus/answer/2844832?hl=en.
>
>What you should do is create a CA, sign the web server's certificate
>with your CA, and then install the CA on your Android device.
>
>The problem (of the Internet of Things and self-signed certifcates
>intersecting with Browsers) was recently brought up on the Web App Sec
>mailing list (see
>http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0203.html).
>There's nothing available at the moment - the Browsers only support
>the CA Zoo security model.
>
>Jeff
>_______________________________________________
>openssl-users mailing list
>openssl-users at openssl.org
>https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141220/8c5b4022/attachment.html>

From noloader at gmail.com  Sat Dec 20 20:32:22 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 20 Dec 2014 15:32:22 -0500
Subject: [openssl-users] Creating a Certificate with CA=TRUE
In-Reply-To: <058FF4CD-85A6-4CF5-8FFD-F1DE8A665F18@gmx.at>
References: <54941687.8000305@gmx.at>
 <CAH8yC8kAQnA+hp+rr1EeytmbbEXwwwJNK3mjK0+PyrdWdtJerA@mail.gmail.com>
 <058FF4CD-85A6-4CF5-8FFD-F1DE8A665F18@gmx.at>
Message-ID: <CAH8yC8=UnM0o8S5Dw7Vq8-oNQyqwkLYjK3P88d2EZayviW8iuw@mail.gmail.com>

On Sat, Dec 20, 2014 at 5:08 AM, Benjamin Draxlbauer <benjamin10 at gmx.at> wrote:
> Okay thanks a lot for the quick replies!
> I hope i got that right : it is sufficiently secure and unproblematic to
> create a CA and use this CA (lets call it root-crt) certificate on my
> webserver and smartphone and wherever it is needes. In short: you can use
> the cacert.pem which is produced by ../CA.pl -newca.
> And the /private/cakey.pem should be stored in a secret place on a external
> device which is offline (sd card usb etc. in my cellar).
Using a private PKI (i.e., a  CA you own/manage) is the only solution
I am aware. In the past, you could usually install a self signed in a
cert store and then get a browser to trust it. But that's pretty much
a thing of the past since the CAs and Browsers collude in the
CA/Browser (CA/B) forum; and the CAs want nothing to do with that
because it affects their bottom line (see https://cabforum.org/).

When generating your CSR, be sure to put all the hostnames in the
Subject Alt Name (SAN) and not the Common Name (CN). The IETF and
their RFCs are lenient about hostnames in the CN, but Browser *don't*
follow the IETF. Browsers follow the CA/B Baseline Requirements (and
EV Guidelines), and there are a few extra rules. So the bottom line
is: hostnames in the SAN, and not the CN. Follow it, and you won't
have troubles with browsers.

As for what a hostname is, I usually put anything in there that I use
to address the device. Here, "address the device" means anything I
type in the browser's address bar or ping from the command line. That
include hostname, FQDN and IP addresss (if using static IPs). So if I
had a raspberry pi on my local network (my local network include a
Active Directory with a domain called 'home.pvt'), then the DNS names
listed in the SAN would include:

    * raspberry
    * raspberry.localdomain
    * raspberry.home.pvt
    * 192.168.1.xxx

*If* you be connecting to the raspberry pi from the raspberry pi, then
include localhost in the SAN.

Finally, here's a modified OpenSSL CONF file to help you with
generating the CSR with multiple SANs:
http://stackoverflow.com/a/25274959/608639. You should modify the
names under the section [ alternate_names ].

Jeff

> Am 19. Dezember 2014 21:43:08 MEZ, schrieb Jeffrey Walton
> <noloader at gmail.com>:
>>
>> On Fri, Dec 19, 2014 at 7:13 AM, Benjamin <benjamin10 at gmx.at> wrote:
>>>
>>>  Hello everyone!
>>>  I am quite new to two things: this mailing list and making and working
>>> with
>>>  certificates
>>>
>>>  I want to run a small owncloud on my raspberry pi and tried to make a
>>> crt
>>>  which I can also use with my mobile devices. Here is the problem:
>>>  When i make a certificate either with this instruction:
>>>  http://wiki.ubuntuusers.de/CA
>>>  or this one:
>>>
>>> https://www.prshanmu.com/2009/03/generating-ssl-certificates-with-x509v3-extensions.html
>>>
>>>  i have the problem that the cacert has "basicconstriants CA=TRUE" but
>>> when i
>>>  make a cert by request i got a new cert (as far as i knew, that which i
>>>  should use for my nginx webserver) which has CA=FALSE. This is no
>>> problem
>>>  normally but my Android phone only accepts Certs with CA=TRUE and
>>> actually i
>>>  don?t know how to make such a certificate?Of course, i could use the
>>> cacert
>>>  itself but isn?t this insecure and inadequate?
>>
>>
>> You can't install self signed certificates (CA=FALSE). You can install
>> client certificates and CA certificates. See
>> https://support.google.com/nexus/answer/2844832?hl=en.
>>
>> What you should do is create a CA, sign the web server's certificate
>> with your CA, and then install the CA on your Android device.
>>
>> The problem (of the Internet of Things and self-signed certifcates
>> intersecting with Browsers) was recently brought up on the Web App Sec
>> mailing list (see
>> http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0203.html).
>> There's nothing available at the moment - the Browsers only support
>> the CA Zoo security model.
>>

From noloader at gmail.com  Sun Dec 21 02:05:52 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Sat, 20 Dec 2014 21:05:52 -0500
Subject: [openssl-users] Is there a public OpenSSL github with prebuilt
	binaries?
Message-ID: <CAH8yC8mV1f7qdR-6b07uKiBk3siBYAVUrhBbgsHv4dMwc3zsyQ@mail.gmail.com>

Is there an official OpenSSL github account with prebuilt binaries for
platforms like iOS and Android?

If so, where is it?

If not, should there be?

From rsalz at akamai.com  Sun Dec 21 02:26:13 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 20 Dec 2014 21:26:13 -0500
Subject: [openssl-users] Is there a public OpenSSL github with
	prebuilt	binaries?
In-Reply-To: <CAH8yC8mV1f7qdR-6b07uKiBk3siBYAVUrhBbgsHv4dMwc3zsyQ@mail.gmail.com>
References: <CAH8yC8mV1f7qdR-6b07uKiBk3siBYAVUrhBbgsHv4dMwc3zsyQ@mail.gmail.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0FE01@USMBX1.msg.corp.akamai.com>


> Is there an official OpenSSL github account with prebuilt binaries for
> platforms like iOS and Android?
> 
> If so, where is it?

There's this: https://www.openssl.org/about/binaries.html 
 
> If not, should there be?

If someone wants to step forward we can add them to that page.


From openssl-users at dukhovni.org  Sun Dec 21 04:52:36 2014
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 21 Dec 2014 04:52:36 +0000
Subject: [openssl-users] Is there a public OpenSSL github with prebuilt
 binaries?
In-Reply-To: <CAH8yC8mV1f7qdR-6b07uKiBk3siBYAVUrhBbgsHv4dMwc3zsyQ@mail.gmail.com>
References: <CAH8yC8mV1f7qdR-6b07uKiBk3siBYAVUrhBbgsHv4dMwc3zsyQ@mail.gmail.com>
Message-ID: <20141221045235.GQ24649@mournblade.imrryr.org>

On Sat, Dec 20, 2014 at 09:05:52PM -0500, Jeffrey Walton wrote:

> Is there an official OpenSSL github account with prebuilt binaries for
> platforms like iOS and Android?
> 
> If so, where is it?

Prebuilt binaries of security toolkits should in my view come only
from the platform vendor (whom you can't avoid trusting).  I don't
think the OpenSSL team should either directly or indirectly endorse
anyone's pre-built binaries.

-- 
	Viktor.

From oyljerry at gmail.com  Mon Dec 22 10:52:43 2014
From: oyljerry at gmail.com (Jerry OELoo)
Date: Mon, 22 Dec 2014 18:52:43 +0800
Subject: [openssl-users]  How to display root certificate in command line
Message-ID: <CAEKwp_EMTAWZhcHTkQvsJZOusbjHvC_FrvW1N5Qs4a4Lw897ZQ@mail.gmail.com>

Hi All:
I have used openssl command line to get some website's certificate
chain. Now, I want to show root certificate information. but I do not
find any command argument to do it.

openssl s_client -showcerts -CApath /etc/ssl/certs -connect
studentexclusives.hsbc.co.uk:443

I use -CApath to set root certificate path.

>From below, I can get full certificate path. 3 certificates

CONNECTED(00000003)
depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU
= "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign
Class 3 Public Primary Certification Authority - G5
verify return:1
depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU
= Terms of use at https://www.verisign.com/rpa (c)10, CN = VeriSign
Class 3 Secure Server CA - G3
verify return:1
depth=0 C = GB, ST = London, L = London, O = HSBC Holdings plc, OU =
HTSE, CN = studentexclusives.hsbc.co.uk
verify return:1


But in certificate chain, I only get 2 certificates information (I
think this two are return by website.)

---
Certificate chain
 0 s:/C=GB/ST=London/L=London/O=HSBC Holdings
plc/OU=HTSE/CN=studentexclusives.hsbc.co.uk
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure
Server CA - G3
-----BEGIN CERTIFICATE-----
MIIFUDCCBDigAwIBAgIQTw4Fx5Xv3tBjt8gNVOKAjjANBgkqhkiG9w0BAQUFADCB
tTELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2Ug
YXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMm
VmVyaVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwHhcNMTMwODA2
MDAwMDAwWhcNMTUwODA3MjM1OTU5WjCBgTELMAkGA1UEBhMCR0IxDzANBgNVBAgT
BkxvbmRvbjEPMA0GA1UEBxQGTG9uZG9uMRowGAYDVQQKFBFIU0JDIEhvbGRpbmdz
IHBsYzENMAsGA1UECxQESFRTRTElMCMGA1UEAxQcc3R1ZGVudGV4Y2x1c2l2ZXMu
aHNiYy5jby51azCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOpGrR8P
hBbnPeewbha7UitdVHL+Zk7HCQ9Hi67+1GI8HgX+eMRk2w/LHL7gYSNr9ZelIPap
ZfTDwBnHyUUH3SAf5ajg5vVFtROCYr9LLFXEW/97Qy6Anh1efJo15eoBXUYVYhBW
IMjU6sO9T+kRBMgxoqtVM4WVmy4pN3NqHqF/8D4k+Y+fcBt2Nm3D/YwI+4H7Bt+P
ap5oj5uALFdcr+dbO76FomAAJ3vjTw10lBCCdfnKmOjBayAVoz/qz91Fy1BYY9jA
l9p1EXml1bYSPJaxfejiyKjHni64cBAMtHyhknlJYDs47mnyp5FLpg3nmxtGCNMR
jXPtxRLDrFMAuGsCAwEAAaOCAYwwggGIMCcGA1UdEQQgMB6CHHN0dWRlbnRleGNs
dXNpdmVzLmhzYmMuY28udWswCQYDVR0TBAIwADAOBgNVHQ8BAf8EBAMCBaAwHQYD
VR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUFBwMCMEMGA1UdIAQ8MDowOAYKYIZIAYb4
RQEHNjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3Bz
MB8GA1UdIwQYMBaAFA1EXBZTRMGCfh0gqyX0AWPYvnmlMEUGA1UdHwQ+MDwwOqA4
oDaGNGh0dHA6Ly9TVlJTZWN1cmUtRzMtY3JsLnZlcmlzaWduLmNvbS9TVlJTZWN1
cmVHMy5jcmwwdgYIKwYBBQUHAQEEajBoMCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz
cC52ZXJpc2lnbi5jb20wQAYIKwYBBQUHMAKGNGh0dHA6Ly9TVlJTZWN1cmUtRzMt
YWlhLnZlcmlzaWduLmNvbS9TVlJTZWN1cmVHMy5jZXIwDQYJKoZIhvcNAQEFBQAD
ggEBAFVoAhJ7Xv0hcv7fkR/mLE+OVhzgkwhTcANZmAuEQwo3ZwHICXg3p/ZjuRe6
4EV1CqSq1RwswG2GtOHFZ+CaC9Fi3lIDVRzaudLkYCF7mtLZls7DF3/HsoJ6muYX
P0X3IsQ6hnc6a3ChdyN+IJymW/KRRUtHKmA/BQS8hOGpdmxvZIdgIkrHoAO3EXfk
SkESma7BMDeW0DOeGuDhUrvn2N6UdyWSA2cdk6d4fQxWawqOiUtYT+o2oX3imDrg
cDKU9HB3eqd0K5nwDFIFlbsZHs6gIGJVJeGVuk07Px5ucOZBFc/UMBBRI3bm2HW4
sjn3tNB8AITr3v3+Evf4vMnbaIs=
-----END CERTIFICATE-----
 1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure
Server CA - G3
   i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
Primary Certification Authority - G5
-----BEGIN CERTIFICATE-----
MIIF7DCCBNSgAwIBAgIQbsx6pacDIAm4zrz06VLUkTANBgkqhkiG9w0BAQUFADCB
yjELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQL
ExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQLEzEoYykgMjAwNiBWZXJp
U2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYDVQQDEzxW
ZXJpU2lnbiBDbGFzcyAzIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0
aG9yaXR5IC0gRzUwHhcNMTAwMjA4MDAwMDAwWhcNMjAwMjA3MjM1OTU5WjCBtTEL
MAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZW
ZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg
aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykxMDEvMC0GA1UEAxMmVmVy
aVNpZ24gQ2xhc3MgMyBTZWN1cmUgU2VydmVyIENBIC0gRzMwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQCxh4QfwgxF9byrJZenraI+nLr2wTm4i8rCrFbG
5btljkRPTc5v7QlK1K9OEJxoiy6Ve4mbE8riNDTB81vzSXtig0iBdNGIeGwCU/m8
f0MmV1gzgzszChew0E6RJK2GfWQS3HRKNKEdCuqWHQsV/KNLO85jiND4LQyUhhDK
tpo9yus3nABINYYpUHjoRWPNGUFP9ZXse5jUxHGzUL4os4+guVOc9cosI6n9FAbo
GLSa6Dxugf3kzTU2s1HTaewSulZub5tXxYsU5w7HnO1KVGrJTcW/EbGuHGeBy0RV
M5l/JJs/U0V/hhrzPPptf4H1uErT9YU3HLWm0AnkGHs4TvoPAgMBAAGjggHfMIIB
2zA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnZlcmlz
aWduLmNvbTASBgNVHRMBAf8ECDAGAQH/AgEAMHAGA1UdIARpMGcwZQYLYIZIAYb4
RQEHFwMwVjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL2Nw
czAqBggrBgEFBQcCAjAeGhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMDQG
A1UdHwQtMCswKaAnoCWGI2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTMtZzUu
Y3JsMA4GA1UdDwEB/wQEAwIBBjBtBggrBgEFBQcBDARhMF+hXaBbMFkwVzBVFglp
bWFnZS9naWYwITAfMAcGBSsOAwIaBBSP5dMahqyNjmvDz4Bq1EgYLHsZLjAlFiNo
dHRwOi8vbG9nby52ZXJpc2lnbi5jb20vdnNsb2dvLmdpZjAoBgNVHREEITAfpB0w
GzEZMBcGA1UEAxMQVmVyaVNpZ25NUEtJLTItNjAdBgNVHQ4EFgQUDURcFlNEwYJ+
HSCrJfQBY9i+eaUwHwYDVR0jBBgwFoAUf9Nlp8Ld7LvwMAnzQzn6Aq8zMTMwDQYJ
KoZIhvcNAQEFBQADggEBAAyDJO/dwwzZWJz+NrbrioBL0aP3nfPMU++CnqOh5pfB
WJ11bOAdG0z60cEtBcDqbrIicFXZIDNAMwfCZYP6j0M3m+oOmmxw7vacgDvZN/R6
bezQGH1JSsqZxxkoor7YdyT3hSaGbYcFQEFn0Sc67dxIHSLNCwuLvPSxe/20majp
dirhGi2HbnTTiN0eIsbfFrYrghQKlFzyUOyvzv9iNw2tZdMGQVPtAhTItVgooazg
W+yzf5VK+wPIrSbb5mZ4EkrZn0L74ZjmQoObj49nJOhhGbXdzbULJgWOw27EyHW4
Rs/iGAZeqa6ogZpHFt4MKGwlJ7net4RYxh84HqTEy2Y=
-----END CERTIFICATE-----
---

Now I want to also display root certificate "VeriSign Class 3 Public
Primary Certification Authority - G5" information, How can I show it?

Thanks!

-- 
Rejoice,I Desire!

From jaya.nageswar at gmail.com  Mon Dec 22 10:50:36 2014
From: jaya.nageswar at gmail.com (Jaya Nageswar)
Date: Mon, 22 Dec 2014 16:20:36 +0530
Subject: [openssl-users] Differences in openssl 0.9.8 and 1.0.1x for private
	pem key file
Message-ID: <CAGdAg4e4AAbAFWWW5LG_Twwrkjz-okbVrTgzwUMGoD072fTisQ@mail.gmail.com>

Dear openssl community,




In our application, we have been using openssl 0.9.8 and trying to move to
openssl 1.0.1x as 0.9.8 is going to be EOS by December 2015. We have a
sample application where we try to read a  sample pem key file, create an
EVP_PKEY indirectly using PEM_read_bio_PrivateKey(BIO *bio, NULL, NULL,
NULL) defined in crypto/pem/pem_pkey.c. Once we have the EVP_PKEY, we try
to create pem key files encrypted using different ciphers like (RC2, RC4
etc.). As per the latest openssl (1.0.1x), the method
PEM_write_bio_PrivateKey defined in crypto/pem/pem_pkey.c gets called in
the call flow while writing the pem key to a file.



The output of the application is different for openssl 0.9.8 and 1.0.1x.
This may be due to the following observations.



1. The structure evp_pkey_st at evp.h for EVP_PKEY got additional members
(members const EVP_PKEY_ASN1_METHOD *ameth and ENGINE *engine) got added in
openssl 1.0.1x versions

2. The logic in PEM_read_bio_PrivateKey n crypto/pem/pem_pkey.c got changed
a little bit and the the data related new membebrs ameth for the structure
evp_pkey_st (EVP_PKEY) is getting populated in the else if ((slen =
pem_check_suffix(nm, "PRIVATE KEY")) > 0) condition.

3. A new method PEM_write_bio_PrivateKey got added(in 1.0.1x) instead of a
MACRO ( IMPLEMENT_PEM_write_cb(crypto/pem/pem_all in 0.9.8) which will
indirectly call PEM_ASN1_write_bio.

The new method PEM_write_bio_PrivateKey in openssl 1.0.1x calls this
PEM_ASN1_write_bio in the else condition. However the if condition of this
method has a different call and it is always getting satisfied and hence my
output is getting changed.



I am using the following private key pem file.



-----BEGIN RSA PRIVATE KEY-----



MIIBOQIBAAJBAJNw3CZ0Z15+zkvkigtY1vH75Ow0FIFS3li3sj3OQY5pwYWE/PlE

5FEZxogIi5SEtEY/ZXgy5nGiCAILq8p1ynUCAwEAAQJAeIy+c3KZUdm8MrEZbU2l

8RRTiAzM9zAaO892HLKXRyhTL4l3v+wKt7Y/Yd+q1VUHXLr8VXJ8r/Gjr6NCofBO

AQIhAMJTTxqkoomY9hWeHSy5Y9FMG5+qI2IroayqfyyoLIBJAiEAwjw9fk0f+Ntz

TvRR5K4HcpnQLf3XebaHt0tI/RVakM0CIFdjX497uhxmzUOrdzNFq73TnBiRSpg7

Rtl/UvGiL2EBAiBQPZah0La+ldoC6gfS0tocy9ImzdDwZSmX3TAf7WxmmQIgJRiG

wXMpWytUHRvxPD9scrNyCQ96q7x5w88+yWzXFtE=



-----END RSA PRIVATE KEY-----



I have highlighted the executing part of the code for the methods
PEM_read_bio_PrivateKey and PEM_write_bio_PrivateKey in the openssl 1.0.1x
version.



EVP_PKEY *PEM_read_bio_PrivateKey(BIO *bp, EVP_PKEY **x, pem_password_cb
*cb, void *u)

                {

                char *nm=NULL;

                const unsigned char *p=NULL;

                unsigned char *data=NULL;

                long len;

                int slen;

                EVP_PKEY *ret=NULL;



                if (!PEM_bytes_read_bio(&data, &len, &nm,
PEM_STRING_EVP_PKEY, bp, cb, u))

                                return NULL;

                p = data;



                if (strcmp(nm,PEM_STRING_PKCS8INF) == 0) {

                                PKCS8_PRIV_KEY_INFO *p8inf;

                                p8inf=d2i_PKCS8_PRIV_KEY_INFO(NULL, &p,
len);

                                if(!p8inf) goto p8err;

                                ret = EVP_PKCS82PKEY(p8inf);

                                if(x) {

                                                if(*x)
EVP_PKEY_free((EVP_PKEY *)*x);

                                                *x = ret;

                                }

                                PKCS8_PRIV_KEY_INFO_free(p8inf);

                } else if (strcmp(nm,PEM_STRING_PKCS8) == 0) {

                                PKCS8_PRIV_KEY_INFO *p8inf;

                                X509_SIG *p8;

                                int klen;

                                char psbuf[PEM_BUFSIZE];

                                p8 = d2i_X509_SIG(NULL, &p, len);

                                if(!p8) goto p8err;

                                if (cb) klen=cb(psbuf,PEM_BUFSIZE,0,u);

                                else
klen=PEM_def_callback(psbuf,PEM_BUFSIZE,0,u);

                                if (klen <= 0) {


PEMerr(PEM_F_PEM_READ_BIO_PRIVATEKEY,


PEM_R_BAD_PASSWORD_READ);

                                                X509_SIG_free(p8);

                                                goto err;

                                }

                                p8inf = PKCS8_decrypt(p8, psbuf, klen);

                                X509_SIG_free(p8);

                                if(!p8inf) goto p8err;

                                ret = EVP_PKCS82PKEY(p8inf);

                                if(x) {

                                                if(*x)
EVP_PKEY_free((EVP_PKEY *)*x);

                                                *x = ret;

                                }

                                PKCS8_PRIV_KEY_INFO_free(p8inf);

              *  } else if ((slen = pem_check_suffix(nm, "PRIVATE KEY")) >
0)*

*                                {*

*                                const EVP_PKEY_ASN1_METHOD *ameth;*

*                                ameth = EVP_PKEY_asn1_find_str(NULL, nm,
slen);*

*                                if (!ameth || !ameth->old_priv_decode)*

*                                                goto p8err;*

*
ret=d2i_PrivateKey(ameth->pkey_id,x,&p,len);*

*                                }*

p8err:

                if (ret == NULL)


PEMerr(PEM_F_PEM_READ_BIO_PRIVATEKEY,ERR_R_ASN1_LIB);

err:

                OPENSSL_free(nm);

                OPENSSL_cleanse(data, len);

                OPENSSL_free(data);

                return(ret);

                }



int PEM_write_bio_PrivateKey(BIO *bp, EVP_PKEY *x, const EVP_CIPHER *enc,

                                               unsigned char *kstr, int
klen,

                                               pem_password_cb *cb, void *u)

                {

                char pem_str[80];

            *    if (!x->ameth || x->ameth->priv_encode)*

*                                return PEM_write_bio_PKCS8PrivateKey(bp,
x, enc,*

*
(char *)kstr, klen,*

*
cb, u);*



                BIO_snprintf(pem_str, 80, "%s PRIVATE KEY",
x->ameth->pem_str);

                return PEM_ASN1_write_bio((i2d_of_void *)i2d_PrivateKey,


pem_str,bp,x,enc,kstr,klen,cb,u);

                }



I am expecting that the else part of the PEM_write_bio_PrivateKey  should
be executed to get the output similar to the 0.9.8. However the if
condition is getting satisfied and it is not getting to the else condition.

I tried to explain the problem to the best of my abilities. However I can
provide more details about it if required.



I would like to know if there is any bug in the latest openssl (1.0.1x)
regarding the reading/writing the private pem key files.

I appreciate any assistance from the openssl experts on this problem. Thank
you in advance and hoping to get reply soon.


Regards,

-Jay.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141222/3f3baa01/attachment-0001.html>

From dthompson at prinpay.com  Mon Dec 22 12:57:48 2014
From: dthompson at prinpay.com (Dave Thompson)
Date: Mon, 22 Dec 2014 07:57:48 -0500
Subject: [openssl-users] Differences in openssl 0.9.8 and 1.0.1x for
	private	pem key file
In-Reply-To: <CAGdAg4e4AAbAFWWW5LG_Twwrkjz-okbVrTgzwUMGoD072fTisQ@mail.gmail.com>
References: <CAGdAg4e4AAbAFWWW5LG_Twwrkjz-okbVrTgzwUMGoD072fTisQ@mail.gmail.com>
Message-ID: <000c01d01de6$e56f3ae0$b04db0a0$@prinpay.com>

> From: openssl-users On Behalf Of Jaya Nageswar
> Sent: Monday, December 22, 2014 05:51

> In our application, we have been using openssl 0.9.8 and trying to move to 
> openssl 1.0.1x as 0.9.8 is going to be EOS by December 2015. We have a 
> sample application where we try to read a  sample pem key file, create an 
> EVP_PKEY indirectly using PEM_read_bio_PrivateKey [and] try to create 
> pem key files encrypted using different ciphers like (RC2, RC4 etc.). 
 
<snip lots of mechanism>

The mechanism was refactored some, but the visible change is deliberate.

There have long been routines for the algorithm-specific "traditional" 
formats PEM_read/write_RSAPrivateKey/DSAPrivateKey/ECPrivateKey 
AND for the newer standard and algorithm-generic PKCS8 format
PEM_read/write_PKCS8PrivateKey.

Through 0.9.8 PEM_write_PrivateKey used (the appropriate one of) 
traditional formats; in 1.0.0 and later it changed to use PKCS8. 
If you want to continue writing traditional formats in 1.0.0+ call 
specifically _write_RSAPrivateKey, _write_DSAPrivateKey, etc.
using the algorithm-specific struct from (instead of) EVP_PKEY.

At least for now; there is another thread started just a few days ago 
about all PEM formats used by OpenSSL suggesting the traditional
privatekey forms are obsolete and maybe should be deleted!

Note all PEM_read_xyzPrivateKey routines can read *either* 
format, legacy or PKCS8, distinguished by the BEGIN line, although 
if e.g. you _read_RSAPrivateKey and the file is PKCS8 for *another* 
algorithm that's an error; if you _read_PKCS8PrivateKey it accepts 
any algorithm into an EVP_PKEY.

If you are writing differently-encrypted privatekey files because 
you are concerned with key security, note one reason PKCS8
encrypted is preferred over traditional encrypted formats is
that PKCS8 allows and OpenSSL uses a much stronger PBE 
key derivation compared to the older and weaker but 
now set in stone and unchangeable one for traditional.

On checking I see the PEM_most manpage has not 
been updated for this change.



From 133mmx at gmail.com  Mon Dec 22 12:59:30 2014
From: 133mmx at gmail.com (Orc Erc)
Date: Mon, 22 Dec 2014 14:59:30 +0200
Subject: [openssl-users] pkcs11 engine client side authentication
Message-ID: <CAGAASwu59OFeq4E8PQQTVxU1UBHh-QKJYg1EVw+_NO3PW5z84Q@mail.gmail.com>

Hi All,

I need to authenticate my client with a smartcard in ssl connection. So i
am using pkcs11 engine.

I have called the functions below, i have successfully read the certificate
from smart card. But while connecting to server client does not send any
certificate. It happens one side ssl connection, i need two side ssl
connection

I think, this happened because i didn't give the key id. Is there anyone
who knows assigning the key id?


set_pin("123456");
set_module("/usr/lib/libakisp11.so");

ENGINE_load_dynamic();
e = ENGINE_new();

result |= !bind_helper(e);
result |= !ENGINE_init(e);
result |= !ENGINE_register_complete(e);
result |= !ENGINE_set_default(e, ENGINE_METHOD_ALL);

//get certificate
ENGINE_ctrl(e, 205, 0, cert_params, NULL);

SSL_use_certificate(mConn->sslHandle, cert_params->cert);
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141222/e9b8025d/attachment.html>

From jb-openssl at wisemo.com  Mon Dec 22 14:03:28 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 22 Dec 2014 15:03:28 +0100
Subject: [openssl-users] How to display root certificate in command line
In-Reply-To: <CAEKwp_EMTAWZhcHTkQvsJZOusbjHvC_FrvW1N5Qs4a4Lw897ZQ@mail.gmail.com>
References: <CAEKwp_EMTAWZhcHTkQvsJZOusbjHvC_FrvW1N5Qs4a4Lw897ZQ@mail.gmail.com>
Message-ID: <549824B0.6030401@wisemo.com>

On 22/12/2014 11:52, Jerry OELoo wrote:
> Hi All:
> I have used openssl command line to get some website's certificate
> chain. Now, I want to show root certificate information. but I do not
> find any command argument to do it.
>
> openssl s_client -showcerts -CApath /etc/ssl/certs -connect
> studentexclusives.hsbc.co.uk:443
>
> I use -CApath to set root certificate path.
>
>  From below, I can get full certificate path. 3 certificates
>
> CONNECTED(00000003)
> depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU
> = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign
> Class 3 Public Primary Certification Authority - G5
> verify return:1
> depth=1 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU
> = Terms of use at https://www.verisign.com/rpa (c)10, CN = VeriSign
> Class 3 Secure Server CA - G3
> verify return:1
> depth=0 C = GB, ST = London, L = London, O = HSBC Holdings plc, OU =
> HTSE, CN = studentexclusives.hsbc.co.uk
> verify return:1
>
>
> But in certificate chain, I only get 2 certificates information (I
> think this two are return by website.)
>
> ---
> Certificate chain
>   0 s:/C=GB/ST=London/L=London/O=HSBC Holdings
> plc/OU=HTSE/CN=studentexclusives.hsbc.co.uk
>     i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
> at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure
> Server CA - G3
> -----BEGIN CERTIFICATE-----
> ...
> -----END CERTIFICATE-----
>   1 s:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use
> at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 Secure
> Server CA - G3
>     i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006
> VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public
> Primary Certification Authority - G5
> -----BEGIN CERTIFICATE-----
> ...
> -----END CERTIFICATE-----
> ---
>
> Now I want to also display root certificate "VeriSign Class 3 Public
> Primary Certification Authority - G5" information, How can I show it?
>
> Thanks!
>
This means the web server did not send it, but expects your
client/browser to find it (by name) in your local root certificates
store, such as /etc/ssl/certs.

Look in that directory for "/C=US/O=VeriSign, Inc./OU=VeriSign Trust
Network/OU=(c) 2006 VeriSign, Inc. - For authorized use
only/CN=VeriSign Class 3 Public Primary Certification Authority - G5"
and dump that filedirectly with

   openssl x509 -text -in /etc/ssl/certs/somefile.pem

Unfortunately no currently released version of s_client knows how to
dump out the constructed verification chain, there is only an option
to dump the server supplied certificates (regardless if those were
used by the client or not).  Hopefully some future version will have
options to dump either or both lists.

Enjoy

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


From jb-openssl at wisemo.com  Mon Dec 22 14:15:52 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 22 Dec 2014 15:15:52 +0100
Subject: [openssl-users] Differences in openssl 0.9.8 and 1.0.1x for
 private pem key file
In-Reply-To: <000c01d01de6$e56f3ae0$b04db0a0$@prinpay.com>
References: <CAGdAg4e4AAbAFWWW5LG_Twwrkjz-okbVrTgzwUMGoD072fTisQ@mail.gmail.com>
 <000c01d01de6$e56f3ae0$b04db0a0$@prinpay.com>
Message-ID: <54982798.6070406@wisemo.com>

On 22/12/2014 13:57, Dave Thompson wrote:
>
> At least for now; there is another thread started just a few days ago
> about all PEM formats used by OpenSSL suggesting the traditional
> privatekey forms are obsolete and maybe should be deleted!
Please don't do that until 5+ years after 0.9.8 end-of-life. Because
private keyswritten by 0.9.8 to securely stored offline media will
be using the old formatand need to be usable down the line.  Most
certificates expire after 5 years orless though a few private keys
may be needed much later:

1. Decryption certificates/keys may be needed to decrypt data long
  after the certificateexpired (in fact, as long as the data remains
  relevant, think 30+ years for mortgagecontracts, 50+ years for
  life insurance, and 140+ years for copyright disputes).

2. A few certs (e.g. CA roots and Android developer certs) have very
  long (30+ years)certificate lifetimes, but those tend to be used
  regularly over that period, givingplenty of opportunity to convert
  the private key files.

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://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.opensslfoundation.net/pipermail/openssl-users/attachments/20141222/a96f2ed7/attachment.html>

From rsalz at akamai.com  Mon Dec 22 15:01:17 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Mon, 22 Dec 2014 10:01:17 -0500
Subject: [openssl-users] How to display root certificate in command line
In-Reply-To: <CAEKwp_EMTAWZhcHTkQvsJZOusbjHvC_FrvW1N5Qs4a4Lw897ZQ@mail.gmail.com>
References: <CAEKwp_EMTAWZhcHTkQvsJZOusbjHvC_FrvW1N5Qs4a4Lw897ZQ@mail.gmail.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236983@USMBX1.msg.corp.akamai.com>



> But in certificate chain, I only get 2 certificates information (I think this two
> are return by website.)

That's right.  The server returns up to, but not including, the root.  The client is supposed to have the root stored somewhere as an out-of-band trust anchor.  This is the way TLS/SSL works.

From marquess at opensslfoundation.com  Mon Dec 22 15:56:30 2014
From: marquess at opensslfoundation.com (Steve Marquess)
Date: Mon, 22 Dec 2014 10:56:30 -0500
Subject: [openssl-users] OpenSSL mail outage tomorrow 1200-1400UTC
Message-ID: <54983F2E.4040708@opensslfoundation.com>

We've been experiencing some issues with the system that handles
@openssl.org E-mail and the mailing lists. The hardware vendor will be
swapping the system board Tuesday Dec. 23 beginning at 1200UTC. The
outage is expected to take approximately two hours.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at openssl.com
marquess at opensslfoundation.net
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From philipp_subx at redfish-solutions.com  Mon Dec 22 23:57:59 2014
From: philipp_subx at redfish-solutions.com (Philip Prindeville)
Date: Mon, 22 Dec 2014 16:57:59 -0700
Subject: [openssl-users] OpenSSL mail outage tomorrow 1200-1400UTC
In-Reply-To: <54983F2E.4040708@opensslfoundation.com>
References: <54983F2E.4040708@opensslfoundation.com>
Message-ID: <5498B007.1000009@redfish-solutions.com>

And that's back up and working, right?  I've not seen any messages 
today, but then again it's the holidays...


On 12/22/2014 08:56 AM, Steve Marquess wrote:
> We've been experiencing some issues with the system that handles
> @openssl.org E-mail and the mailing lists. The hardware vendor will be
> swapping the system board Tuesday Dec. 23 beginning at 1200UTC. The
> outage is expected to take approximately two hours.
>
> -Steve M.
>


From matt at openssl.org  Tue Dec 23 00:13:40 2014
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Dec 2014 00:13:40 +0000
Subject: [openssl-users] OpenSSL mail outage tomorrow 1200-1400UTC
In-Reply-To: <5498B007.1000009@redfish-solutions.com>
References: <54983F2E.4040708@opensslfoundation.com>
 <5498B007.1000009@redfish-solutions.com>
Message-ID: <5498B3B4.90608@openssl.org>


On 22/12/14 23:57, Philip Prindeville wrote:
> And that's back up and working, right?  I've not seen any messages
> today, but then again it's the holidays...

As far as I am aware all mail has been working today. I've seen emails
on openssl-dev and openssl-commits, and they are both run from the same
server.

Matt


From openssl at openssl.org  Tue Dec 23 23:13:58 2014
From: openssl at openssl.org (OpenSSL)
Date: Wed, 24 Dec 2014 00:13:58 +0100
Subject: [openssl-users] OpenSSL 1.0.0 End Of Life Announcement
Message-ID: <20141223231358.GA11866@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

OpenSSL 1.0.0 End Of Life Announcement
======================================

The OpenSSL Project is today making the following announcement:

Support for version 1.0.0 will cease on 31st December 2015.

No further releases of 1.0.0 will be made after that date. Security fixes only
will be applied to 1.0.0 until then.

Further details about the OpenSSL Release Strategy can be found here:
https://www.openssl.org/about/releasestrat.html

Yours,

The OpenSSL Project Team

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUmfUFAAoJENnE0m0OYESRxwsH/iTt11CUTKXj7IEJ6glp2TO4
EH8EaF1QJdh7nEDe71JHciEzLOJctEW+c8DSJUb54VmhxUAehSALQ4iU/SQGnlOK
YZlg3jYhEE0WSfd+UtLsh6I5xK2l11z3fb3ncOlaqCHZMsuatFJRyZtKIKSIIFdG
e/TaYmaZnBgTw3wQ9ThaVkeWGFTHtwlOyBIgbw9jF9DC7B/KRwpk7230/6Yv7Tz+
XDqeruYLiSj2IxW+hD1lWqoetLfHAWhvxSELjUxfH6BR5E/+kliDgHWlji/VfFl3
tl9OcAKbqUUVNMxYKDxgh7mkvdcATHrBoQ7spbR98EKG6QeNtVTYEEaCGFrYBIs=
=tmun
-----END PGP SIGNATURE-----

From matt at openssl.org  Tue Dec 23 23:49:51 2014
From: matt at openssl.org (Matt Caswell)
Date: Tue, 23 Dec 2014 23:49:51 +0000
Subject: [openssl-users] OpenSSL Release Strategy and Blog
Message-ID: <5499FF9F.6040205@openssl.org>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement
contained a link to the recently published OpenSSL Release Strategy that
is available here:
https://www.openssl.org/about/releasestrat.html

I have put up a blog post on the thinking behind this strategy on the
newly created OpenSSL Blog that you may (or may not!) find interesting.
It can be found here:
https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/

Matt


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJUmf+fAAoJENnE0m0OYESRtyoH+gPCygFa106fcsqTk2WhgUJi
p9beEKsYTmBm7lgVcB4CrWBFPcXeEoVDnYCsv3dPngSaJo0h9NIzeJT6BjERXyxo
wXOhm0EN6qbfCsecng6UWVdOorGUIe93+k7ZcyZ+21U9ydd60jIxJpBAK7QKO1jC
2T9W26VtGtgR2D7XxuZ7m8a+2WKTC+snpKKfUERZJ/eM306fnYJnIEvLw6ntupLe
agv2kxYm3tKWi7LQcKn/OUo2JgcU60o+8M0s/KBshSe/R/EV1a5brUH7sHFH6wgS
riHYTHvJ3QnDk1vwHlS2CPzdazMnhxBuXUJJ7d940BtsAHnL4l7Waf0e3e+YHsM=
=SUZf
-----END PGP SIGNATURE-----


From kgoldman at us.ibm.com  Wed Dec 24 20:01:10 2014
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Wed, 24 Dec 2014 15:01:10 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <5499FF9F.6040205@openssl.org>
References: <5499FF9F.6040205@openssl.org>
Message-ID: <m7f625$1io$1@ger.gmane.org>

> Version 1.1.0 will (moderately) break source compatibility (for example we will make most structures opaque etc).

I as a user, I have two points of concern"

1 - Will the RSA structure be opaque?  I have a continuing need to 
construct an RSA structure from binary arrays of public and private key 
parts and vice versa.

Will I lose that?

2 - The SHA contexts are already opaque, but I have to cheat and look 
into them anyway.  The use case is "live migration."  I have a hash 
operation in progress, and I have to serialize the context to move to 
another machine.

Any alternative to looking into the structure?



From rsalz at akamai.com  Wed Dec 24 21:35:17 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Dec 2014 16:35:17 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <m7f625$1io$1@ger.gmane.org>
References: <5499FF9F.6040205@openssl.org> <m7f625$1io$1@ger.gmane.org>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D12@USMBX1.msg.corp.akamai.com>

> 1 - Will the RSA structure be opaque?  I have a continuing need to construct
> an RSA structure from binary arrays of public and private key parts and vice
> versa.
> 
> Will I lose that?

Maybe.  Proposing new "constructors" that met your needs is probably a good thing to do.

> 2 - The SHA contexts are already opaque, but I have to cheat and look into
> them anyway.  The use case is "live migration."  I have a hash operation in
> progress, and I have to serialize the context to move to another machine.
> 
> Any alternative to looking into the structure?

Not at the time.


From steve at openssl.org  Wed Dec 24 21:55:29 2014
From: steve at openssl.org (Dr. Stephen Henson)
Date: Wed, 24 Dec 2014 21:55:29 +0000
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <m7f625$1io$1@ger.gmane.org>
References: <5499FF9F.6040205@openssl.org>
 <m7f625$1io$1@ger.gmane.org>
Message-ID: <20141224215529.GA23836@openssl.org>

On Wed, Dec 24, 2014, Ken Goldman wrote:

> >Version 1.1.0 will (moderately) break source compatibility (for example we will make most structures opaque etc).
> 
> I as a user, I have two points of concern"
> 
> 1 - Will the RSA structure be opaque?  I have a continuing need to
> construct an RSA structure from binary arrays of public and private
> key parts and vice versa.
> 
> Will I lose that?
> 

RSA is something which most probably will be opaque along with DSA, DH and
the associated methods.

So you wont be able to access the structure directly. However I think it is
pretty certain there will be new utility functions to access the public and
private key components of RSA (and DSA, DH) structures.

The reason I say that is that you need that functionality to make ENGINE
work.

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

From richmoore44 at gmail.com  Wed Dec 24 22:18:50 2014
From: richmoore44 at gmail.com (Richard Moore)
Date: Wed, 24 Dec 2014 22:18:50 +0000
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <20141224215529.GA23836@openssl.org>
References: <5499FF9F.6040205@openssl.org> <m7f625$1io$1@ger.gmane.org>
 <20141224215529.GA23836@openssl.org>
Message-ID: <CAMp7mVtgTfNh8WxxxqWO3yEdkVF=k_cbo1JyDSXNpKAVzcsmbQ@mail.gmail.com>

What I'd find useful would be a branch for me to test with so that I can
let you know areas where we're having to get into the guts of an openssl
structure right now that will be opaque in future. IIRC last time I tried
using the define to minimise the exposed api (I forget what it was called)
there were some parts of the Qt code that could not be implemented.

Note that I think the goal of minimising the exposed api rather than having
people using the implementation details is a good thing long term, despite
the fact I'm sure it'll cause me short term pain maintaining code using
openssl.

Cheers

Rich.


On 24 December 2014 at 21:55, Dr. Stephen Henson <steve at openssl.org> wrote:

> On Wed, Dec 24, 2014, Ken Goldman wrote:
>
> > >Version 1.1.0 will (moderately) break source compatibility (for example
> we will make most structures opaque etc).
> >
> > I as a user, I have two points of concern"
> >
> > 1 - Will the RSA structure be opaque?  I have a continuing need to
> > construct an RSA structure from binary arrays of public and private
> > key parts and vice versa.
> >
> > Will I lose that?
> >
>
> RSA is something which most probably will be opaque along with DSA, DH and
> the associated methods.
>
> So you wont be able to access the structure directly. However I think it is
> pretty certain there will be new utility functions to access the public and
> private key components of RSA (and DSA, DH) structures.
>
> The reason I say that is that you need that functionality to make ENGINE
> work.
>
> Steve.
> --
> Dr Stephen N. Henson. OpenSSL project core developer.
> Commercial tech support now available see: http://www.openssl.org
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141224/aa4ff5a4/attachment.html>

From noloader at gmail.com  Wed Dec 24 22:46:46 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Wed, 24 Dec 2014 17:46:46 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <20141224215529.GA23836@openssl.org>
References: <5499FF9F.6040205@openssl.org> <m7f625$1io$1@ger.gmane.org>
 <20141224215529.GA23836@openssl.org>
Message-ID: <CAH8yC8miCPbCMHAdRQ68A0TA0=UWefZLVVVvhLFs_NuSbkMkRg@mail.gmail.com>

On Wed, Dec 24, 2014 at 4:55 PM, Dr. Stephen Henson <steve at openssl.org> wrote:
> On Wed, Dec 24, 2014, Ken Goldman wrote:
>
>> >Version 1.1.0 will (moderately) break source compatibility (for example we will make most structures opaque etc).
>>
>> I as a user, I have two points of concern"
>>
>> 1 - Will the RSA structure be opaque?  I have a continuing need to
>> construct an RSA structure from binary arrays of public and private
>> key parts and vice versa.
>>
>> Will I lose that?
>>
>
> RSA is something which most probably will be opaque along with DSA, DH and
> the associated methods.
Here's another counterpoint: when those structures are made opaque,
that means we have to go to the memory manager for a struct that could
otherwise be stack based. And we have to free it. That can slow things
down considerably.

I don't mind the extra cycles spent on parameter validation and return
value checking. Crypto software is high integrity software, so little
details like the CompSci 101 stuff needs to be done. But I despise
having to go to the memory manager for something like a BN_CTX that
could live on the stack.

Jeff

From rsalz at akamai.com  Thu Dec 25 02:16:50 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Dec 2014 21:16:50 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <CAH8yC8miCPbCMHAdRQ68A0TA0=UWefZLVVVvhLFs_NuSbkMkRg@mail.gmail.com>
References: <5499FF9F.6040205@openssl.org> <m7f625$1io$1@ger.gmane.org>
 <20141224215529.GA23836@openssl.org>
 <CAH8yC8miCPbCMHAdRQ68A0TA0=UWefZLVVVvhLFs_NuSbkMkRg@mail.gmail.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D1A@USMBX1.msg.corp.akamai.com>

> But I despise having to go to the
> memory manager for something like a BN_CTX that could live on the stack.

Sorry, but that's the way it's gonna be.  There are plenty of things to despise in OpenSSL, I wouldn't have put "must allocate structures from the heap" anywhere near the top of my list :)
 

From rsalz at akamai.com  Thu Dec 25 02:23:43 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 24 Dec 2014 21:23:43 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <CAMp7mVtgTfNh8WxxxqWO3yEdkVF=k_cbo1JyDSXNpKAVzcsmbQ@mail.gmail.com>
References: <5499FF9F.6040205@openssl.org> <m7f625$1io$1@ger.gmane.org>
 <20141224215529.GA23836@openssl.org>
 <CAMp7mVtgTfNh8WxxxqWO3yEdkVF=k_cbo1JyDSXNpKAVzcsmbQ@mail.gmail.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D1B@USMBX1.msg.corp.akamai.com>


> What I'd find useful would be a branch for me to test with

Well, the release doc says our goal is year-end release with a previous mid-year.  Once 1.0.2 goes out, I would assume that 'master' will get a lot of activity in that area, and you can try with that.

>Note that I think the goal of minimising the exposed api rather than having people using the implementation details is a good thing long term, despite the fact I'm sure it'll cause me short term pain maintaining code using openssl.

Thanks.  We know it's going to be inconvenient, which is why we're announcing it early and I expect we'll be having an ongoing discussion with the community about it. But the basic concept is set. 

From tran.minh.duc at intel.com  Thu Dec 25 03:24:09 2014
From: tran.minh.duc at intel.com (Tran, Minh Duc SG)
Date: Thu, 25 Dec 2014 03:24:09 +0000
Subject: [openssl-users] unsubscribe openssl-users
Message-ID: <5E0E14BE40820E45B51715B43331073EC61F51@PGSMSX103.gar.corp.intel.com>

unsubscribe openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141225/13dd9b1c/attachment.html>

From kgoldman at us.ibm.com  Fri Dec 26 02:43:11 2014
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 25 Dec 2014 21:43:11 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D12@USMBX1.msg.corp.akamai.com>
References: <5499FF9F.6040205@openssl.org> <m7f625$1io$1@ger.gmane.org>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D12@USMBX1.msg.corp.akamai.com>
Message-ID: <m7ihvt$6qk$1@ger.gmane.org>

On 12/24/2014 4:35 PM, Salz, Rich wrote:
>> 1 - Will the RSA structure be opaque?  I have a continuing need to construct
>> an RSA structure from binary arrays of public and private key parts and vice
>> versa.
>>
>> Will I lose that?
>
> Maybe.  Proposing new "constructors" that met your needs is probably a good thing to do.

Where's a good place to propose them?  Here's what I currently use:

Generate a key pair and return n,p,q,d
Generate the public key structure from n,e
Generate the private key structure from n,e,d


From kgoldman at us.ibm.com  Fri Dec 26 02:46:45 2014
From: kgoldman at us.ibm.com (Ken Goldman)
Date: Thu, 25 Dec 2014 21:46:45 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <CAH8yC8miCPbCMHAdRQ68A0TA0=UWefZLVVVvhLFs_NuSbkMkRg@mail.gmail.com>
References: <5499FF9F.6040205@openssl.org> <m7f625$1io$1@ger.gmane.org>
 <20141224215529.GA23836@openssl.org>
 <CAH8yC8miCPbCMHAdRQ68A0TA0=UWefZLVVVvhLFs_NuSbkMkRg@mail.gmail.com>
Message-ID: <m7ii6j$6qk$2@ger.gmane.org>

On 12/24/2014 5:46 PM, Jeffrey Walton wrote:

> Here's another counterpoint: when those structures are made opaque,
> that means we have to go to the memory manager for a struct that could
> otherwise be stack based. And we have to free it. That can slow things
> down considerably.

My intuition says that a malloc will be down in the noise compared to 
the RSA operation itself.

When I profile, I find that my entire program takes negligible time 
compared to an RSA operation.




From rsalz at akamai.com  Fri Dec 26 13:50:59 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 26 Dec 2014 08:50:59 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <m7ihvt$6qk$1@ger.gmane.org>
References: <5499FF9F.6040205@openssl.org> <m7f625$1io$1@ger.gmane.org>
 <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D12@USMBX1.msg.corp.akamai.com>
 <m7ihvt$6qk$1@ger.gmane.org>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D28@USMBX1.msg.corp.akamai.com>

> Where's a good place to propose them?  Here's what I currently use:

Well, watch the openssl-dev list.  Check on master periodically.  No specific plans yet other than the preview release.

> Generate a key pair and return n,p,q,d
> Generate the public key structure from n,e Generate the private key
> structure from n,e,d

Seems reasonable.  Of course you'll get BIGNUM*, not BIGNUM :)

	/r$

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz



From jb-openssl at wisemo.com  Sun Dec 28 00:31:38 2014
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Sun, 28 Dec 2014 01:31:38 +0100
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <5499FF9F.6040205@openssl.org>
References: <5499FF9F.6040205@openssl.org>
Message-ID: <549F4F6A.9010507@wisemo.com>

On 24-12-2014 00:49, Matt Caswell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement
> contained a link to the recently published OpenSSL Release Strategy that
> is available here:
> https://www.openssl.org/about/releasestrat.html
>
> I have put up a blog post on the thinking behind this strategy on the
> newly created OpenSSL Blog that you may (or may not!) find interesting.
> It can be found here:
> https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/

I am afraid that this is a somewhat rush decision, with insufficient
consideration for the impact on others:

1. Because this was announced during the Xmas/New year holidays, many
  parties will not see this until the beginning of 2015.

2. The decision that 1.0.0 and 1.0.1 should both be classed as a STS
  releases seems new, and is unlikely to have been anticipated by many
  "users".  Many will have naturally assumed that 1.0.0 would last as
  long as 0.9.8 lasted.

   So announcing the imminent death of 1.0.0 at the same time as 0.9.8
  is going to be a nasty surprise to anyone who already froze their
  projects on the 1.0.0 series rather than the new and more unstable
  1.0.1 series.

3. The 1.0.x binary compatibility promise seems to not have been
  completely kept.  As recently as just this December, As a practical
  example: I had an OS upgrade partially fail due to the presence of
  a self-compiled up to date 1.0.1* library that conflicted with an
  OS supplied 1.0.x library that was frozen earlier while relying on
  your promise.

   Also the 1.0.1 changelog includes at least one change of binary
  flag values to get a different compatibility behavior than
  previous 1.0.1 releases, thus there is not even binary
  compatibility within 1.0.1 .

4. LTS release periods have an absolute need to overlap, such that
  at any given date, there is at least one active LTS release known
  not to end within the next many years, otherwise the whole concept
  is useless.  On any given day of the year (except, perhaps, holidays),
  a project somewhere is going to look at available tool and library
  releases and decide which one is most likely to be supportable for
  the next N years, then irreversibly freeze on that version.  So if
  OpenSSL has no active long term release with at least 3 to 5 years
  left, then OpenSSL is not viable or projects will have to incur the
  cost of having security-novices backport security fixes manually
  to an unsupported version for the remainder of the needed N years.

   Accordingly the policy should be that there will always be at least
  one LTS release which is at least one year old and has at least 5
  years left before security support ends.  For comparison, Microsoft
  usually promises security fixes for 10 years after release, non-
  critical fixes for only 5, and people still complain loudly when the
  10 year period is up for e.g. NT 4.0 and XP.

   Since you have already announced the upcoming end of 0.9.8, you
  must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1)
  as the new LTS release, and you need to deal with the fact that
  since the 0.9.8 end-of-life announcement, you have been unclear
  which of the two existing 1.0.x releases would be LTS-security,
  causing some projects (not mine, fortunately) to irreversibly
  pick a different one than you did.

5. Since its original release as part of SSLeay, libcrypt has become
  the dominant BSD-licensed library of raw crypto primitives for all
  sorts of uses, such as (but not at all limited to), openssh, the
  SRP reference implementation, the NTP cryptographic support etc.

   Limiting the capabilities, transparency or other aspects at this
  point in time is way, way too late.  It is as futile as when the
  ANSI/ISO C committee tried to remove the UNIX-like file handle APIs
  (io.h) in favor of the FILE* API (stdio.h) at a time when the C
  language was about the current age of OpenSSL.

   The best you can do is to split libcrypt into two or tree well
  defined layers, that can be mixed in applications but do not break
  their layering internally.  These could be: rawalgs (non-opaque
  software primitives, bignums etc.  with CPU acceleration but
  nothing more fancy), EVP-api (opaque structures with hidden heap
  allocations, engine and FIPS support, but no forced loading of
  unused algorithms, except for the all-or-nothing-ness of fips and
  other engine blobs), and NID-API (algorithms referable by numeric
  IDs, large bundles of algorithms loaded by master-init functions,
  automatic X.509 checking/use based on embedded algorithm OIDs etc.).

   Ideally, the rawalgs level should never make its own heap
  allocations, except in compatibility functions for older APIs that
  did, and should be usable in deeply embedded systems, such as OS
  loaders and door locks.

Enjoy

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


From rsalz at akamai.com  Sun Dec 28 06:31:53 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 28 Dec 2014 01:31:53 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <549F4F6A.9010507@wisemo.com>
References: <5499FF9F.6040205@openssl.org> <549F4F6A.9010507@wisemo.com>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D4A@USMBX1.msg.corp.akamai.com>

Thanks for the detailed and thoughtful reply.

I just want to emphasize that it was not a hasty decision; we talked about it a great deal, and we discussed the impacts as best as we could.

Our minds are pretty made up.  Not everyone will be happy with all aspects.  Luckily, they have the source and can take on the burden for themselves if necessary.

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz



From kurt at roeckx.be  Sun Dec 28 11:26:34 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Sun, 28 Dec 2014 12:26:34 +0100
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <549F4F6A.9010507@wisemo.com>
References: <5499FF9F.6040205@openssl.org>
 <549F4F6A.9010507@wisemo.com>
Message-ID: <20141228112634.GA26337@roeckx.be>

On Sun, Dec 28, 2014 at 01:31:38AM +0100, Jakob Bohm wrote:
> 3. The 1.0.x binary compatibility promise seems to not have been
>  completely kept.  As recently as just this December, As a practical
>  example: I had an OS upgrade partially fail due to the presence of
>  a self-compiled up to date 1.0.1* library that conflicted with an
>  OS supplied 1.0.x library that was frozen earlier while relying on
>  your promise.

Can you give more details about this?  Please note the binary
compatibility will only work if you used the same options to build
the library.  (This is one of the reasons to make more structures
opaque.)

>   Also the 1.0.1 changelog includes at least one change of binary
>  flag values to get a different compatibility behavior than
>  previous 1.0.1 releases, thus there is not even binary
>  compatibility within 1.0.1 .

I assume you're talking about SSL_OP_NO_TLSv1_1?  It's unfortunate
that SSL_OP_ALL already contained that in 1.0.0 while 1.0.0
doesn't even know anything about TLS 1.1.  But that only affects
people who compiled with 1.0.1 or 1.0.1a headers.

>  must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1)
>  as the new LTS release, and you need to deal with the fact that
>  since the 0.9.8 end-of-life announcement, you have been unclear
>  which of the two existing 1.0.x releases would be LTS-security,
>  causing some projects (not mine, fortunately) to irreversibly
>  pick a different one than you did.

I think people should stop using both 0.9.8 and 1.0.0 as soon as
possible since they do not support TLS 1.2.  You really want to use
TLS 1.2.

>   The best you can do is to split libcrypt into two or tree well
>  defined layers, that can be mixed in applications but do not break
>  their layering internally.  These could be: rawalgs (non-opaque
>  software primitives, bignums etc.  with CPU acceleration but
>  nothing more fancy)

I don't think we intend to remove functions like AES_* yet but
might deprecate them in favour APIs that exist for a very long
time.  Please note that for instance using the AES functions you
do not have AESNI acceleration but by using the EVP interfance you
do.


Kurt


From richmoore44 at gmail.com  Sun Dec 28 16:42:48 2014
From: richmoore44 at gmail.com (Richard Moore)
Date: Sun, 28 Dec 2014 16:42:48 +0000
Subject: [openssl-users] Problems verifying OCSP signatures
Message-ID: <CAMp7mVuSsa-bMwZHw9WSzvhRV=J2=ZXy4GB89PQRUQEXs4Fepg@mail.gmail.com>

Hi All,

I'm trying to get some code to verify the signature of an OCSP response to
work properly and I'm hitting quite a few road blocks. I've also been
talking
to the curl developers who are having the same problems and I wondered if
anyone can help us.

I've tried 3 different ways of handling the verification and none of them
seem
to work reliably. All 3 work properly for checking the OCSP status of
www.google.com, but they all fail when testing revoked.grc.com and tn123.org
.
I'm sure I must be doing something wrong, but I've no idea what and there
seems to be very little documentation in this area. I've put the 3
approaches
I've tried below in case anyone has any ideas. Note that the reason all the
openssl symbols has a q_XXX prefix is just due to a dlopen shim and doesn't
change the behaviour of the functions at all.

If anyone has any suggestions of what I'm doing wrong then please let me
know.

Thanks

Rich.

/**
 * This version takes the whole issuer chain, and adds them as
intermediates.
 * It also sets up the CA store.
 */
bool QSslOcspReply::hasValidSignature1(const QList<QSslCertificate>
&issuers) const
{
    // Create the certificate store
    X509_STORE *certStore = q_X509_STORE_new();
    if (!certStore) {
        qWarning() << "Unable to create certificate store";
        return false;
    }

    // Build a stack to put the issuer in
    STACK_OF(X509) *intermediates = 0;
    intermediates = (STACK_OF(X509) *) q_sk_new_null();

    if (!intermediates) {
        q_X509_STORE_free(certStore);
        return false;
    }

#if OPENSSL_VERSION_NUMBER >= 0x10000000L
    foreach (const QSslCertificate &cert, issuers)
        q_sk_push( (_STACK *)intermediates, reinterpret_cast<X509
*>(cert.handle()));
#else
    foreach (const QSslCertificate &cert, issuers)
        q_sk_push( (STACK *)intermediates, reinterpret_cast<X509
*>(cert.handle()));
#endif

    foreach (const QSslCertificate &caCertificate,
QSslSocket::defaultCaCertificates())
        q_X509_STORE_add_cert(certStore, (X509 *)caCertificate.handle());

    int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
certStore, OCSP_TRUSTOTHER);

    // A verify result is a failure if it is 0 or less
    if (verifyResult <= 0) {
        unsigned long errnum = q_ERR_get_error();
        const char *error = q_ERR_error_string(errnum, 0);

        qDebug() << "OCSP response verification failed" << verifyResult;
        qDebug() << "Error was: " << error;
        // ### TODO: Fix mem leak
        return false;
    }
    qDebug() << "OCSP response verification good";

#if OPENSSL_VERSION_NUMBER >= 0x10000000L
    q_sk_free( (_STACK *) intermediates);
#else
    q_sk_free( (STACK *) intermediates);
#endif
    q_X509_STORE_free(certStore);

    return true;
}

/**
 * This version takes the whole issuer chain, and adds them as
intermediates.
 * It does not set up any CAs.
 */
bool QSslOcspReply::hasValidSignature2(const QList<QSslCertificate>
&issuers) const
{
    // Create the certificate store
    X509_STORE *certStore = q_X509_STORE_new();
    if (!certStore) {
        qWarning() << "Unable to create certificate store";
        return false;
    }

    // Build a stack to put the issuer in
    STACK_OF(X509) *intermediates = 0;
    intermediates = (STACK_OF(X509) *) q_sk_new_null();

    if (!intermediates) {
        q_X509_STORE_free(certStore);
        return false;
    }

#if OPENSSL_VERSION_NUMBER >= 0x10000000L
    foreach (const QSslCertificate &cert, issuers)
        q_sk_push( (_STACK *)intermediates, reinterpret_cast<X509
*>(cert.handle()));
#else
    foreach (const QSslCertificate &cert, issuers)
        q_sk_push( (STACK *)intermediates, reinterpret_cast<X509
*>(cert.handle()));
#endif

    int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
certStore, OCSP_TRUSTOTHER);

    // A verify result is a failure if it is 0 or less
    if (verifyResult <= 0) {
        unsigned long errnum = q_ERR_get_error();
        const char *error = q_ERR_error_string(errnum, 0);

        qDebug() << "OCSP response verification failed" << verifyResult;
        qDebug() << "Error was: " << error;
        // ### TODO: Fix mem leak
        return false;
    }
    qDebug() << "OCSP response verification good";

#if OPENSSL_VERSION_NUMBER >= 0x10000000L
    q_sk_free( (_STACK *) intermediates);
#else
    q_sk_free( (STACK *) intermediates);
#endif
    q_X509_STORE_free(certStore);

    return true;
}

/**
 * This version takes the just the actual issuer, and adds it as an
intermediate.
 * It does not set up any CAs.
 */
bool QSslOcspReply::hasValidSignature3(const QSslCertificate &issuer) const
{
    // Create the certificate store
    X509_STORE *certStore = q_X509_STORE_new();
    if (!certStore) {
        qWarning() << "Unable to create certificate store";
        return false;
    }

    // Build a stack to put the issuer in
    STACK_OF(X509) *intermediates = 0;
    intermediates = (STACK_OF(X509) *) q_sk_new_null();

    if (!intermediates) {
        q_X509_STORE_free(certStore);
        return false;
    }

#if OPENSSL_VERSION_NUMBER >= 0x10000000L
    q_sk_push( (_STACK *)intermediates, reinterpret_cast<X509
*>(issuer.handle()));
#else
    q_sk_push( (STACK *)intermediates, reinterpret_cast<X509
*>(issuer.handle()));
#endif

    int verifyResult = q_OCSP_basic_verify(d->basicresp, intermediates,
certStore, OCSP_TRUSTOTHER);

    // A verify result is a failure if it is 0 or less
    if (verifyResult <= 0) {
        unsigned long errnum = q_ERR_get_error();
        const char *error = q_ERR_error_string(errnum, 0);

        qDebug() << "OCSP response verification failed" << verifyResult;
        qDebug() << "Error was: " << error;
        // ### TODO: Fix mem leak
        return false;
    }
    qDebug() << "OCSP response verification good";

#if OPENSSL_VERSION_NUMBER >= 0x10000000L
    q_sk_free( (_STACK *) intermediates);
#else
    q_sk_free( (STACK *) intermediates);
#endif
    q_X509_STORE_free(certStore);

    return true;
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141228/a116b024/attachment.html>

From matt at openssl.org  Mon Dec 29 00:37:13 2014
From: matt at openssl.org (Matt Caswell)
Date: Mon, 29 Dec 2014 00:37:13 +0000
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <549F4F6A.9010507@wisemo.com>
References: <5499FF9F.6040205@openssl.org> <549F4F6A.9010507@wisemo.com>
Message-ID: <54A0A239.8080304@openssl.org>



On 28/12/14 00:31, Jakob Bohm wrote:
> On 24-12-2014 00:49, Matt Caswell wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement
>> contained a link to the recently published OpenSSL Release Strategy that
>> is available here:
>> https://www.openssl.org/about/releasestrat.html
>>
>> I have put up a blog post on the thinking behind this strategy on the
>> newly created OpenSSL Blog that you may (or may not!) find interesting.
>> It can be found here:
>> https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/
> 
> I am afraid that this is a somewhat rush decision, with insufficient
> consideration for the impact on others:

Not at all. This decision has been under consideration for some
considerable period of time with much discussion of the impacts.

> 
> 1. Because this was announced during the Xmas/New year holidays, many
>  parties will not see this until the beginning of 2015.
> 
> 2. The decision that 1.0.0 and 1.0.1 should both be classed as a STS
>  releases seems new, and is unlikely to have been anticipated by many
>  "users".  Many will have naturally assumed that 1.0.0 would last as
>  long as 0.9.8 lasted.
> 
>   So announcing the imminent death of 1.0.0 at the same time as 0.9.8
>  is going to be a nasty surprise to anyone who already froze their
>  projects on the 1.0.0 series rather than the new and more unstable
>  1.0.1 series.

1.0.0 will have been around for over 5.5 years by the time it is finally
retired. That's quite a healthy lifetime for any product. We are giving
a whole year of notice before it is withdrawn.

We have committed to continue to support 1.0.1 for another 2 years - and
it has already been out for over 2.5 years.

Calling either of these STS releases seems quite unfair.

> 
> 3. The 1.0.x binary compatibility promise seems to not have been
>  completely kept.  As recently as just this December, As a practical
>  example: I had an OS upgrade partially fail due to the presence of
>  a self-compiled up to date 1.0.1* library that conflicted with an
>  OS supplied 1.0.x library that was frozen earlier while relying on
>  your promise.

I'm not sure what you are referring to here. However as Kurt has pointed
out the same options have to be applied for binary compatibility to work.

> 
>   Also the 1.0.1 changelog includes at least one change of binary
>  flag values to get a different compatibility behavior than
>  previous 1.0.1 releases, thus there is not even binary
>  compatibility within 1.0.1 .
> 
> 4. LTS release periods have an absolute need to overlap, such that
>  at any given date, there is at least one active LTS release known
>  not to end within the next many years, otherwise the whole concept
>  is useless.  On any given day of the year (except, perhaps, holidays),
>  a project somewhere is going to look at available tool and library
>  releases and decide which one is most likely to be supportable for
>  the next N years, then irreversibly freeze on that version.  So if
>  OpenSSL has no active long term release with at least 3 to 5 years
>  left, then OpenSSL is not viable or projects will have to incur the
>  cost of having security-novices backport security fixes manually
>  to an unsupported version for the remainder of the needed N years.
> 
>   Accordingly the policy should be that there will always be at least
>  one LTS release which is at least one year old and has at least 5
>  years left before security support ends.
>  For comparison, Microsoft
>  usually promises security fixes for 10 years after release, non-
>  critical fixes for only 5, and people still complain loudly when the
>  10 year period is up for e.g. NT 4.0 and XP.


We are simply unable to provide that level of support - we just don't
have the resources to do it. We're not Microsoft or anything remotely
like it in terms of resources.

At the same time as we have a set of users demanding long term support,
we also have other users demanding the latest functionality and releases
much more frequently. No matter what we decide we are never going to
please everyone. This is our best attempt at balancing all of the
various demands.

We were keenly aware of the impacts that it would have and these
decisions have caused us much debate about how best to balance things.
No decisions were taken lightly.

> 
>   Since you have already announced the upcoming end of 0.9.8, you
>  must choose one of the stabilized 1.0.x releases (1.0.0 or 1.0.1)
>  as the new LTS release, and you need to deal with the fact that
>  since the 0.9.8 end-of-life announcement, you have been unclear
>  which of the two existing 1.0.x releases would be LTS-security,
>  causing some projects (not mine, fortunately) to irreversibly
>  pick a different one than you did.
> 
> 5. Since its original release as part of SSLeay, libcrypt has become
>  the dominant BSD-licensed library of raw crypto primitives for all
>  sorts of uses, such as (but not at all limited to), openssh, the
>  SRP reference implementation, the NTP cryptographic support etc.
> 
>   Limiting the capabilities, transparency or other aspects at this
>  point in time is way, way too late.

I respectfully disagree. I firmly believe it as an absolute must have
for us to be able to take the library forward. Without it we will be
continually hampered by our inability to change anything. With all of
the internals exposed we can do very little to improve things.

At the same time as doing this though we are also intending to make a
1.0.x release available for the next 5 years - so anyone who absolutely
cannot make the changes required (which actually I do not believe will
be that difficult) will still have support for quite some time to come.

Matt


From rsalz at akamai.com  Mon Dec 29 04:55:14 2014
From: rsalz at akamai.com (Salz, Rich)
Date: Sun, 28 Dec 2014 23:55:14 -0500
Subject: [openssl-users] OpenSSL Release Strategy and Blog
In-Reply-To: <54A0A239.8080304@openssl.org>
References: <5499FF9F.6040205@openssl.org> <549F4F6A.9010507@wisemo.com>
 <54A0A239.8080304@openssl.org>
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D55236D71@USMBX1.msg.corp.akamai.com>

 >  For comparison, Microsoft

I'm not quite sure how we should respond to any paragraph that begins with those words. :) 

> I respectfully disagree.

We, the OpenSSL dev team, all do.  The release strategy document is the strong consensus of the entire team. 

--  
Principal Security Engineer, Akamai Technologies
IM: rsalz at jabber.me Twitter: RichSalz

From oyljerry at gmail.com  Mon Dec 29 08:32:16 2014
From: oyljerry at gmail.com (Jerry OELoo)
Date: Mon, 29 Dec 2014 16:32:16 +0800
Subject: [openssl-users] Why construct so wierd certificate chain for one
	web site
Message-ID: <CAEKwp_HFduiCsh6ybHNuKgQJwNVoYxTpRwG=p6kTZhX7_oG7QA@mail.gmail.com>

Hi.
I am using X509_STORE_CTX_get1_chain() to construct certificate chain
base on local root ca store. Now it works fine.

But when I access this website, https://www.sgetvous.societegenerale.fr/
I get a very strange result.

Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[20]
Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[27]
Peer cert subject[/OU=Domain Control Validated/OU=Gandi Standard
Wildcard SSL/CN=*.talkspirit.com] depth[0] error[27]

as above, CN points to *.talkspirit.com, what's this?

But https://www.ssllabs.com/ssltest/analyze.html?d=www.sgetvous.societegenerale.fr
query result is same as browser shown, certificate is signed by
VeriSign.

What's the problem, Thanks!


-- 
Rejoice,I Desire!

From noloader at gmail.com  Mon Dec 29 08:43:44 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 29 Dec 2014 03:43:44 -0500
Subject: [openssl-users] Why construct so wierd certificate chain for
 one web site
In-Reply-To: <CAEKwp_HFduiCsh6ybHNuKgQJwNVoYxTpRwG=p6kTZhX7_oG7QA@mail.gmail.com>
References: <CAEKwp_HFduiCsh6ybHNuKgQJwNVoYxTpRwG=p6kTZhX7_oG7QA@mail.gmail.com>
Message-ID: <CAH8yC8k5MsGZTu5qBYEyJUkDhxkofRqaSm=_OEccLNEfGtY66Q@mail.gmail.com>

On Mon, Dec 29, 2014 at 3:32 AM, Jerry OELoo <oyljerry at gmail.com> wrote:
> Hi.
> I am using X509_STORE_CTX_get1_chain() to construct certificate chain
> base on local root ca store. Now it works fine.
>
> But when I access this website, https://www.sgetvous.societegenerale.fr/
> I get a very strange result.
>
> Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[20]
> Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[27]
> Peer cert subject[/OU=Domain Control Validated/OU=Gandi Standard
> Wildcard SSL/CN=*.talkspirit.com] depth[0] error[27]
>
> as above, CN points to *.talkspirit.com, what's this?
>

Use TLS with SNI rather than SSLv3.

*****

riemann::Desktop$ openssl s_client -tls1 -connect
www.sgetvous.societegenerale.fr:443 -servername
www.sgetvous.societegenerale.fr | openssl x509 -text -noout
depth=0 C = FR, ST = Ile de France, L = PARIS, O = Societe Generale,
OU = Securite Production, CN = www.sgetvous.societegenerale.fr
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = FR, ST = Ile de France, L = PARIS, O = Societe Generale,
OU = Securite Production, CN = www.sgetvous.societegenerale.fr
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = FR, ST = Ile de France, L = PARIS, O = Societe Generale,
OU = Securite Production, CN = www.sgetvous.societegenerale.fr
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            40:3a:0b:8f:89:ce:cc:c1:df:89:0c:f1:66:db:16:79
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network,
OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign
Class 3 Secure Server CA - G3
        Validity
            Not Before: Nov 27 00:00:00 2014 GMT
            Not After : Nov 27 23:59:59 2016 GMT
        Subject: C=FR, ST=Ile de France, L=PARIS, O=Societe Generale,
OU=Securite Production, CN=www.sgetvous.societegenerale.fr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9d:53:1b:28:a8:f4:ff:9a:13:08:f5:5e:6c:f7:
                    0a:e9:6a:a5:da:7c:de:13:97:ef:d9:40:41:2e:6b:
                    0f:32:49:f0:74:95:93:ed:ac:8e:eb:d3:fc:97:3e:
                    38:e6:bf:d7:2b:6d:b3:65:bb:3e:f4:d3:60:8e:d6:
                    04:1e:cc:1f:de:e8:5a:7a:55:b6:c2:18:e6:e1:8a:
                    bd:c1:0d:d7:c0:ee:5e:d6:d9:2e:8b:cf:18:8a:27:
                    a6:d4:bd:2d:74:9b:e1:53:60:e2:9d:d4:28:4f:74:
                    a7:ec:40:33:99:c4:8c:9d:c9:23:74:ae:fa:70:6d:
                    5d:5b:3f:6f:57:fb:53:4a:bd:f5:ed:38:ba:70:17:
                    03:94:50:0d:42:11:22:ef:ce:c8:4d:4c:d5:01:15:
                    1f:46:13:31:e0:8e:39:45:70:e4:c9:cd:5c:aa:35:
                    e9:84:ea:df:15:01:b7:db:46:05:39:ef:0e:3e:fc:
                    73:80:3e:4b:8f:5a:7e:47:fc:51:7a:5d:cd:12:d2:
                    b1:70:d4:b4:ff:ff:a3:b4:12:70:c6:b4:9b:46:57:
                    c1:57:5a:de:a3:45:ba:1d:4c:7e:f2:04:66:e0:0a:
                    c3:6b:43:a6:44:ab:d3:f4:38:89:71:b6:b2:0a:44:
                    2a:77:bb:ba:f2:bc:2d:e6:63:fa:70:a5:e4:c5:d6:
                    9d:67
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:www.sgetvous.societegenerale.fr
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies:
                Policy: 2.16.840.1.113733.1.7.54
                  CPS: https://d.symcb.com/cps
                  User Notice:
                    Explicit Text: https://d.symcb.com/rpa

            X509v3 Authority Key Identifier:

keyid:0D:44:5C:16:53:44:C1:82:7E:1D:20:AB:25:F4:01:63:D8:BE:79:A5

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://sd.symcb.com/sd.crl

            Authority Information Access:
                OCSP - URI:http://sd.symcd.com
                CA Issuers - URI:http://sd.symcb.com/sd.crt

    Signature Algorithm: sha1WithRSAEncryption
         6b:70:99:e4:13:a1:70:63:2f:0b:99:b7:a3:7e:e5:53:6c:84:
         11:31:5e:cb:0b:9d:0e:28:7a:ad:21:6b:24:25:63:cf:a9:d0:
         51:18:3d:22:01:26:a8:21:11:63:7d:a0:f1:ba:7c:72:27:6e:
         e7:af:60:45:9e:5b:7b:c5:f1:50:6a:8f:fe:68:d1:e8:bd:c6:
         3a:58:78:91:ea:ce:1d:4d:7d:9d:8c:b1:63:70:6a:c2:e0:e5:
         4e:ef:66:60:b2:43:28:e9:45:5e:88:4a:8e:01:b0:da:73:61:
         bc:9e:52:c7:37:f4:ee:da:36:b0:4f:4a:49:11:b0:b5:1b:c2:
         98:7b:0a:a5:cb:e7:07:20:8d:cb:e0:00:bc:b9:15:bc:2e:5c:
         88:95:8c:d8:84:3c:b2:1c:a6:9a:c0:9b:b7:3f:63:e1:68:ba:
         0f:80:24:65:6f:c0:ca:a4:18:50:22:2b:50:02:2f:ff:fe:e9:
         11:b3:a5:54:34:01:f1:7a:13:53:80:31:f9:1b:37:7e:56:df:
         49:c2:ef:b8:7c:f1:c9:c9:ee:18:64:60:e5:3a:34:cf:2f:71:
         6e:fa:40:3c:db:91:85:62:45:74:e9:31:c0:66:0e:eb:f2:c2:
         6d:83:f4:40:47:e0:6e:d0:29:67:3e:89:70:cb:1c:ee:aa:9f:
         8d:23:77:51



*****

riemann::Desktop$ openssl s_client -tls1 -connect
www.sgetvous.societegenerale.fr:443 -servername
www.sgetvous.societegenerale.fr | openssl x509 -text -noout
depth=0 C = FR, ST = Ile de France, L = PARIS, O = Societe Generale,
OU = Securite Production, CN = www.sgetvous.societegenerale.fr
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = FR, ST = Ile de France, L = PARIS, O = Societe Generale,
OU = Securite Production, CN = www.sgetvous.societegenerale.fr
verify error:num=27:certificate not trusted
verify return:1
depth=0 C = FR, ST = Ile de France, L = PARIS, O = Societe Generale,
OU = Securite Production, CN = www.sgetvous.societegenerale.fr
verify error:num=21:unable to verify the first certificate
verify return:1
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            40:3a:0b:8f:89:ce:cc:c1:df:89:0c:f1:66:db:16:79
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network,
OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign
Class 3 Secure Server CA - G3
        Validity
            Not Before: Nov 27 00:00:00 2014 GMT
            Not After : Nov 27 23:59:59 2016 GMT
        Subject: C=FR, ST=Ile de France, L=PARIS, O=Societe Generale,
OU=Securite Production, CN=www.sgetvous.societegenerale.fr
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:9d:53:1b:28:a8:f4:ff:9a:13:08:f5:5e:6c:f7:
                    0a:e9:6a:a5:da:7c:de:13:97:ef:d9:40:41:2e:6b:
                    0f:32:49:f0:74:95:93:ed:ac:8e:eb:d3:fc:97:3e:
                    38:e6:bf:d7:2b:6d:b3:65:bb:3e:f4:d3:60:8e:d6:
                    04:1e:cc:1f:de:e8:5a:7a:55:b6:c2:18:e6:e1:8a:
                    bd:c1:0d:d7:c0:ee:5e:d6:d9:2e:8b:cf:18:8a:27:
                    a6:d4:bd:2d:74:9b:e1:53:60:e2:9d:d4:28:4f:74:
                    a7:ec:40:33:99:c4:8c:9d:c9:23:74:ae:fa:70:6d:
                    5d:5b:3f:6f:57:fb:53:4a:bd:f5:ed:38:ba:70:17:
                    03:94:50:0d:42:11:22:ef:ce:c8:4d:4c:d5:01:15:
                    1f:46:13:31:e0:8e:39:45:70:e4:c9:cd:5c:aa:35:
                    e9:84:ea:df:15:01:b7:db:46:05:39:ef:0e:3e:fc:
                    73:80:3e:4b:8f:5a:7e:47:fc:51:7a:5d:cd:12:d2:
                    b1:70:d4:b4:ff:ff:a3:b4:12:70:c6:b4:9b:46:57:
                    c1:57:5a:de:a3:45:ba:1d:4c:7e:f2:04:66:e0:0a:
                    c3:6b:43:a6:44:ab:d3:f4:38:89:71:b6:b2:0a:44:
                    2a:77:bb:ba:f2:bc:2d:e6:63:fa:70:a5:e4:c5:d6:
                    9d:67
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Subject Alternative Name:
                DNS:www.sgetvous.societegenerale.fr
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies:
                Policy: 2.16.840.1.113733.1.7.54
                  CPS: https://d.symcb.com/cps
                  User Notice:
                    Explicit Text: https://d.symcb.com/rpa

            X509v3 Authority Key Identifier:

keyid:0D:44:5C:16:53:44:C1:82:7E:1D:20:AB:25:F4:01:63:D8:BE:79:A5

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://sd.symcb.com/sd.crl

            Authority Information Access:
                OCSP - URI:http://sd.symcd.com
                CA Issuers - URI:http://sd.symcb.com/sd.crt

    Signature Algorithm: sha1WithRSAEncryption
         6b:70:99:e4:13:a1:70:63:2f:0b:99:b7:a3:7e:e5:53:6c:84:
         11:31:5e:cb:0b:9d:0e:28:7a:ad:21:6b:24:25:63:cf:a9:d0:
         51:18:3d:22:01:26:a8:21:11:63:7d:a0:f1:ba:7c:72:27:6e:
         e7:af:60:45:9e:5b:7b:c5:f1:50:6a:8f:fe:68:d1:e8:bd:c6:
         3a:58:78:91:ea:ce:1d:4d:7d:9d:8c:b1:63:70:6a:c2:e0:e5:
         4e:ef:66:60:b2:43:28:e9:45:5e:88:4a:8e:01:b0:da:73:61:
         bc:9e:52:c7:37:f4:ee:da:36:b0:4f:4a:49:11:b0:b5:1b:c2:
         98:7b:0a:a5:cb:e7:07:20:8d:cb:e0:00:bc:b9:15:bc:2e:5c:
         88:95:8c:d8:84:3c:b2:1c:a6:9a:c0:9b:b7:3f:63:e1:68:ba:
         0f:80:24:65:6f:c0:ca:a4:18:50:22:2b:50:02:2f:ff:fe:e9:
         11:b3:a5:54:34:01:f1:7a:13:53:80:31:f9:1b:37:7e:56:df:
         49:c2:ef:b8:7c:f1:c9:c9:ee:18:64:60:e5:3a:34:cf:2f:71:
         6e:fa:40:3c:db:91:85:62:45:74:e9:31:c0:66:0e:eb:f2:c2:
         6d:83:f4:40:47:e0:6e:d0:29:67:3e:89:70:cb:1c:ee:aa:9f:
         8d:23:77:51

From noloader at gmail.com  Mon Dec 29 08:49:02 2014
From: noloader at gmail.com (Jeffrey Walton)
Date: Mon, 29 Dec 2014 03:49:02 -0500
Subject: [openssl-users] Why construct so wierd certificate chain for
 one web site
In-Reply-To: <CAH8yC8k5MsGZTu5qBYEyJUkDhxkofRqaSm=_OEccLNEfGtY66Q@mail.gmail.com>
References: <CAEKwp_HFduiCsh6ybHNuKgQJwNVoYxTpRwG=p6kTZhX7_oG7QA@mail.gmail.com>
 <CAH8yC8k5MsGZTu5qBYEyJUkDhxkofRqaSm=_OEccLNEfGtY66Q@mail.gmail.com>
Message-ID: <CAH8yC8=k725z2_4ZcOUGqYChxz1QLupGtEaUoS=x_h=YYu8mww@mail.gmail.com>

On Mon, Dec 29, 2014 at 3:43 AM, Jeffrey Walton <noloader at gmail.com> wrote:
> On Mon, Dec 29, 2014 at 3:32 AM, Jerry OELoo <oyljerry at gmail.com> wrote:
>> Hi.
>> I am using X509_STORE_CTX_get1_chain() to construct certificate chain
>> base on local root ca store. Now it works fine.
>>
>> But when I access this website, https://www.sgetvous.societegenerale.fr/
>> I get a very strange result.
>>
>> Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[20]
>> Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[27]
>> Peer cert subject[/OU=Domain Control Validated/OU=Gandi Standard
>> Wildcard SSL/CN=*.talkspirit.com] depth[0] error[27]
>>
>> as above, CN points to *.talkspirit.com, what's this?
>>
>
> Use TLS with SNI rather than SSLv3.
>

My bad... Here's the SSLv3 try....

riemann::Desktop$ openssl s_client -ssl3 -connect
www.sgetvous.societegenerale.fr:443 | openssl x509 -text -noout
depth=1 C = FR, O = GANDI SAS, CN = Gandi Standard SSL CA
verify error:num=20:unable to get local issuer certificate
verify return:0
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            6a:71:4e:18:43:1a:1a:fd:d6:cb:1a:f2:0b:bd:bc:21
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=FR, O=GANDI SAS, CN=Gandi Standard SSL CA
        Validity
            Not Before: Aug 25 00:00:00 2014 GMT
            Not After : Sep  7 23:59:59 2016 GMT
        Subject: OU=Domain Control Validated, OU=Gandi Standard
Wildcard SSL, CN=*.talkspirit.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:ae:78:b4:36:77:fc:7b:a4:e7:05:54:24:e6:c3:
                    a1:c8:53:9b:00:9e:70:65:81:85:0e:8c:60:f4:f6:
                    03:18:f3:14:c7:14:3b:e4:a8:d1:2e:fc:73:a7:49:
                    76:c5:27:e9:5b:6b:a4:56:07:0d:93:a1:27:0b:c5:
                    d9:8e:bb:84:7b:c8:40:07:1c:29:88:f1:56:81:82:
                    b6:ea:20:4a:cf:ca:3c:fd:85:0e:ac:bd:74:10:71:
                    7a:66:76:64:3c:0b:51:47:32:c6:c2:32:82:a9:79:
                    69:5e:12:47:34:50:5f:30:62:5d:24:0e:9d:63:45:
                    c9:72:9e:75:07:b6:fe:0a:c6:e1:a4:10:a5:2a:57:
                    4c:0f:f2:79:c5:24:36:55:cc:e3:0c:32:b8:f4:61:
                    53:53:6f:75:dd:53:5a:2c:59:cf:b9:2a:2c:94:53:
                    8d:db:04:90:6d:bf:1b:2d:3f:35:aa:98:53:78:d6:
                    a3:c4:d8:62:ad:80:da:8a:28:b9:e4:00:fa:2b:e3:
                    f2:78:f8:5b:6f:71:9b:83:d1:84:98:ab:53:c5:73:
                    0e:4f:89:4d:9b:2f:0e:fb:ce:21:04:ed:32:08:6c:
                    a5:33:13:81:2a:b3:63:94:ae:15:2b:e6:eb:27:30:
                    4b:0a:6f:8d:32:63:5a:db:8c:89:04:76:60:98:c2:
                    43:0d
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:

keyid:B6:A8:FF:A2:A8:2F:D0:A6:CD:4B:B1:68:F3:E7:50:10:31:A7:79:21

            X509v3 Subject Key Identifier:
                AE:E1:E7:5F:C0:7F:3B:09:70:02:82:A0:24:21:A9:56:16:0D:92:68
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Certificate Policies:
                Policy: 1.3.6.1.4.1.6449.1.2.2.26
                  CPS: http://www.gandi.net/contracts/fr/ssl/cps/pdf/
                Policy: 2.23.140.1.2.1

            X509v3 CRL Distribution Points:

                Full Name:
                  URI:http://crl.gandi.net/GandiStandardSSLCA.crl

            Authority Information Access:
                CA Issuers - URI:http://crt.gandi.net/GandiStandardSSLCA.crt
                OCSP - URI:http://ocsp.gandi.net

            X509v3 Subject Alternative Name:
                DNS:*.talkspirit.com, DNS:talkspirit.com
    Signature Algorithm: sha1WithRSAEncryption
         b5:8e:b6:8a:84:c3:c8:76:a9:48:37:60:ed:70:c9:33:91:fe:
         ee:1a:60:7b:68:71:71:30:e1:a1:cd:b9:4e:c2:36:b3:50:cf:
         d6:20:9f:a1:e0:4e:12:9c:89:19:6c:ce:9a:b4:18:7d:f1:ca:
         e0:d8:21:ac:b5:d4:51:b3:25:af:3d:6e:5e:29:65:6a:22:ac:
         ec:8a:cd:50:d0:28:12:ee:2c:6d:a9:e5:98:c1:d6:6d:05:8e:
         9b:f2:38:7f:18:83:17:1f:35:b1:f9:66:6f:85:05:ca:32:39:
         d5:e0:6a:82:18:8b:3d:e7:b7:27:4f:8e:d2:b9:f4:da:69:2d:
         1d:0b:7f:69:cf:e2:5d:4c:66:e8:59:c0:be:8b:c2:22:31:4d:
         66:d7:e3:c0:a6:71:e6:d2:4b:fd:4b:00:f7:5c:b5:f1:9a:90:
         80:72:ba:19:ef:0b:0f:e9:8f:b5:dc:29:d3:0c:ff:ee:04:92:
         63:bd:93:de:98:72:f1:94:8d:22:6d:d7:c0:f4:0f:47:4f:7b:
         8c:5d:12:ea:72:00:fe:6c:76:9c:5a:78:6c:93:b5:47:e2:4f:
         a9:9e:fc:33:f8:8d:a2:db:01:07:eb:55:12:9c:7e:97:02:26:
         0a:0b:53:44:83:74:7c:8e:de:b7:87:d5:88:65:68:14:62:69:
         31:91:4f:3e

From matt at openssl.org  Mon Dec 29 09:20:22 2014
From: matt at openssl.org (Matt Caswell)
Date: Mon, 29 Dec 2014 09:20:22 +0000
Subject: [openssl-users] Why construct so wierd certificate chain for
 one web site
In-Reply-To: <CAEKwp_HFduiCsh6ybHNuKgQJwNVoYxTpRwG=p6kTZhX7_oG7QA@mail.gmail.com>
References: <CAEKwp_HFduiCsh6ybHNuKgQJwNVoYxTpRwG=p6kTZhX7_oG7QA@mail.gmail.com>
Message-ID: <54A11CD6.1030807@openssl.org>



On 29/12/14 08:32, Jerry OELoo wrote:
> Hi.
> I am using X509_STORE_CTX_get1_chain() to construct certificate chain
> base on local root ca store. Now it works fine.
> 
> But when I access this website, https://www.sgetvous.societegenerale.fr/
> I get a very strange result.
> 
> Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[20]
> Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[27]
> Peer cert subject[/OU=Domain Control Validated/OU=Gandi Standard
> Wildcard SSL/CN=*.talkspirit.com] depth[0] error[27]
> 
> as above, CN points to *.talkspirit.com, what's this?
> 
> But https://www.ssllabs.com/ssltest/analyze.html?d=www.sgetvous.societegenerale.fr
> query result is same as browser shown, certificate is signed by
> VeriSign.
> 
> What's the problem, Thanks!
> 
> 
You need to call SSL_set_tlsext_host_name. If I connect to the above
server using:
openssl s_client -connect www.sgetvous.societegenerale.fr:443

Then I get the above certificate. If however I connect using:
openssl s_client -connect www.sgetvous.societegenerale.fr:443
-servername www.sgetvous.societegenerale.fr

I get the correct one. The server is using SNI so needs to know the
hostname you are trying to connect to in order to provide you with the
correct certificate.

Matt

From oyljerry at gmail.com  Mon Dec 29 10:00:08 2014
From: oyljerry at gmail.com (Jerry OELoo)
Date: Mon, 29 Dec 2014 18:00:08 +0800
Subject: [openssl-users] Why construct so wierd certificate chain for
 one web site
In-Reply-To: <54A11CD6.1030807@openssl.org>
References: <CAEKwp_HFduiCsh6ybHNuKgQJwNVoYxTpRwG=p6kTZhX7_oG7QA@mail.gmail.com>
 <54A11CD6.1030807@openssl.org>
Message-ID: <CAEKwp_EW=wYCgAyLzqTrnHEyrwjeQvmRTEtFVxbS=cFVuv2tTA@mail.gmail.com>

Thanks Jeffrey & Matt

Now I have a more question, I do not want to make code use tlsv1
method and SSL_set_tlsext_host_name to query all website, I just want
to when encounter this issue, then I will construct tlsv1 and set sni
name to query certificate, So how can I get this kind of information,
or what is correct coding process when support sni and non-sni
webiste. Thanks!

On Mon, Dec 29, 2014 at 5:20 PM, Matt Caswell <matt at openssl.org> wrote:
>
>
> On 29/12/14 08:32, Jerry OELoo wrote:
>> Hi.
>> I am using X509_STORE_CTX_get1_chain() to construct certificate chain
>> base on local root ca store. Now it works fine.
>>
>> But when I access this website, https://www.sgetvous.societegenerale.fr/
>> I get a very strange result.
>>
>> Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[20]
>> Peer cert subject[/C=FR/O=GANDI SAS/CN=Gandi Standard SSL CA] depth[1] error[27]
>> Peer cert subject[/OU=Domain Control Validated/OU=Gandi Standard
>> Wildcard SSL/CN=*.talkspirit.com] depth[0] error[27]
>>
>> as above, CN points to *.talkspirit.com, what's this?
>>
>> But https://www.ssllabs.com/ssltest/analyze.html?d=www.sgetvous.societegenerale.fr
>> query result is same as browser shown, certificate is signed by
>> VeriSign.
>>
>> What's the problem, Thanks!
>>
>>
> You need to call SSL_set_tlsext_host_name. If I connect to the above
> server using:
> openssl s_client -connect www.sgetvous.societegenerale.fr:443
>
> Then I get the above certificate. If however I connect using:
> openssl s_client -connect www.sgetvous.societegenerale.fr:443
> -servername www.sgetvous.societegenerale.fr
>
> I get the correct one. The server is using SNI so needs to know the
> hostname you are trying to connect to in order to provide you with the
> correct certificate.
>
> Matt
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users



-- 
Rejoice,I Desire!

From zjedev at gmail.com  Mon Dec 29 17:37:49 2014
From: zjedev at gmail.com (Zeke Evans)
Date: Mon, 29 Dec 2014 10:37:49 -0700
Subject: [openssl-users] Does CVE-2014-3569 apply without the no-ssl3 build
	option
Message-ID: <CAABX9eojQpehwZuVos+R3v41u-KJnAng3_QN_8Dm2Wc1hOPcyA@mail.gmail.com>

Is an OpenSSL 1.0.1j build that does not use the no-ssl3 build option
still vulnerable to CVE-2014-3569?  It seems the SSLv3 handshake to a
no-ssl3 application scenario is just one way to exploit this and that
the ssl23_get_client_hello function causes this issue for any
unsupported or unrecognized version.

Thanks,
Zeke

From jaya.nageswar at gmail.com  Tue Dec 30 07:36:24 2014
From: jaya.nageswar at gmail.com (Jaya Nageswar)
Date: Tue, 30 Dec 2014 13:06:24 +0530
Subject: [openssl-users] Differences in openssl 0.9.8 and 1.0.1x for
 private pem key file
In-Reply-To: <000c01d01de6$e56f3ae0$b04db0a0$@prinpay.com>
References: <CAGdAg4e4AAbAFWWW5LG_Twwrkjz-okbVrTgzwUMGoD072fTisQ@mail.gmail.com>
 <000c01d01de6$e56f3ae0$b04db0a0$@prinpay.com>
Message-ID: <CAGdAg4eVK0O4SrNeMhq4_-Jb03=UzURAwOLtvtAwxwhRsGvrjw@mail.gmail.com>

Hi Dave,

Thank you very much for a prompt response. I very much appreciate your
inputs. I have a couple of follow up questions.

You mentioned that the output would be different between openssl 0.9.8 and
1.0.1x versions as the following methods are being used in the code flow
for the method PEM_write_bio_PrivateKey.

1.0.1x - PEM_write_bio_PKCS8PrivateKey
0.9.8 - PEM_ASN1_write_bio((i2d_of_void *)i2d_PrivateKey,...)

1. As I mentioned earlier, We have a sample application where we try to
read a  sample pem key file, create an
 EVP_PKEY indirectly using PEM_read_bio_PrivateKey and try to create pem
key files encrypted using different ciphers like (RC2, RC4    etc.) using
the method PEM_write_bio_PrivateKey. I am getting a different output in
1.0.1x while using the cipher RC2 by using the method
PEM_write_bio_PrivateKey.That is understandable as we use PKCS8 in 1.0.1x.
However if I try to use the cipher RC4 for
encyrption,PEM_write_bio_PKCS8PrivateKey is failing.Is there a known issue
or a bug for RC4.

2. Also Can I use the method PEM_ASN1_write_bio((i2d_of_void
*)i2d_PrivateKey,...) in 1.0.1x instead of the method
PEM_write_bio_PrivateKey if I want to have the same output similar to 0.9.8.

Thanks in advance for your hlep.

Regards,
-Jaya Nageswar.

On Mon, Dec 22, 2014 at 6:27 PM, Dave Thompson <dthompson at prinpay.com>
wrote:

> > From: openssl-users On Behalf Of Jaya Nageswar
> > Sent: Monday, December 22, 2014 05:51
>
> > In our application, we have been using openssl 0.9.8 and trying to move
> to
> > openssl 1.0.1x as 0.9.8 is going to be EOS by December 2015. We have a
> > sample application where we try to read a  sample pem key file, create an
> > EVP_PKEY indirectly using PEM_read_bio_PrivateKey [and] try to create
> > pem key files encrypted using different ciphers like (RC2, RC4 etc.).
>
> <snip lots of mechanism>
>
> The mechanism was refactored some, but the visible change is deliberate.
>
> There have long been routines for the algorithm-specific "traditional"
> formats PEM_read/write_RSAPrivateKey/DSAPrivateKey/ECPrivateKey
> AND for the newer standard and algorithm-generic PKCS8 format
> PEM_read/write_PKCS8PrivateKey.
>
> Through 0.9.8 PEM_write_PrivateKey used (the appropriate one of)
> traditional formats; in 1.0.0 and later it changed to use PKCS8.
> If you want to continue writing traditional formats in 1.0.0+ call
> specifically _write_RSAPrivateKey, _write_DSAPrivateKey, etc.
> using the algorithm-specific struct from (instead of) EVP_PKEY.
>
> At least for now; there is another thread started just a few days ago
> about all PEM formats used by OpenSSL suggesting the traditional
> privatekey forms are obsolete and maybe should be deleted!
>
> Note all PEM_read_xyzPrivateKey routines can read *either*
> format, legacy or PKCS8, distinguished by the BEGIN line, although
> if e.g. you _read_RSAPrivateKey and the file is PKCS8 for *another*
> algorithm that's an error; if you _read_PKCS8PrivateKey it accepts
> any algorithm into an EVP_PKEY.
>
> If you are writing differently-encrypted privatekey files because
> you are concerned with key security, note one reason PKCS8
> encrypted is preferred over traditional encrypted formats is
> that PKCS8 allows and OpenSSL uses a much stronger PBE
> key derivation compared to the older and weaker but
> now set in stone and unchangeable one for traditional.
>
> On checking I see the PEM_most manpage has not
> been updated for this change.
>
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141230/33a908a3/attachment.html>

From malatesh10 at gmail.com  Tue Dec 30 09:21:59 2014
From: malatesh10 at gmail.com (Malatesh Ankasapur)
Date: Tue, 30 Dec 2014 14:51:59 +0530
Subject: [openssl-users] gemalto smart card login
Message-ID: <CAFK0S4aWOe2Rky5W7uLoSwu-hUbZWYT9uw0=_+7heBjfWNpWCg@mail.gmail.com>

Hi All,


Gemelto smart card prompting error "No valid certificate found" in user
space and some time command.c through an error "No data to communicate". I
am working on customized ubuntu 11.04 for thin clients. Gemelto is working
fine on x86 standard ubuntu 14.04

But omnikey is working fine on same machine.

Thanks in advance

Regards,
Malatesh Ankasapur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141230/de526770/attachment.html>

From kurt at roeckx.be  Tue Dec 30 12:55:26 2014
From: kurt at roeckx.be (Kurt Roeckx)
Date: Tue, 30 Dec 2014 13:55:26 +0100
Subject: [openssl-users] Does CVE-2014-3569 apply without the no-ssl3
 build option
In-Reply-To: <CAABX9eojQpehwZuVos+R3v41u-KJnAng3_QN_8Dm2Wc1hOPcyA@mail.gmail.com>
References: <CAABX9eojQpehwZuVos+R3v41u-KJnAng3_QN_8Dm2Wc1hOPcyA@mail.gmail.com>
Message-ID: <20141230125526.GA5954@roeckx.be>

On Mon, Dec 29, 2014 at 10:37:49AM -0700, Zeke Evans wrote:
> Is an OpenSSL 1.0.1j build that does not use the no-ssl3 build option
> still vulnerable to CVE-2014-3569?  It seems the SSLv3 handshake to a
> no-ssl3 application scenario is just one way to exploit this and that
> the ssl23_get_client_hello function causes this issue for any
> unsupported or unrecognized version.

The can return NULL in case of no-ssl2 or no-ssl3 when receiving
SSLv2 or SSLv3.  But in case of SSLv2 that function isn't called,
it directly sets the method to SSLv2_server_method() in that case
if the previous if block.

Please note that s->verion can't be set to a unknown value but can
be set to an unsupported value.  SSL2_VERSION and SSL3_VERSION are
the only 2 options that are known but can be unsupported.  But as
stated above this doesn't affect SSLv2.

So in summary this only has an effect when build using no-ssl3.


Kurt


From marquess at opensslfoundation.com  Tue Dec 30 14:39:45 2014
From: marquess at opensslfoundation.com (Steve Marquess)
Date: Tue, 30 Dec 2014 09:39:45 -0500
Subject: [openssl-users] Another record-breaking donation from Smartisan
	Technology
Message-ID: <54A2B931.601@opensslfoundation.com>

In May of this year the OpenSSL project received what has been our
largest single donation to date, 1000000 RMB (roughly 160000 USD or
133000 EUR) from Smartisan Technology (http://www.smartisan.com/). That
donation, along with other donations from multiple sources, enabled us
to fund a new full time dedicated OpenSSL resource (Matt Caswell).

We have just received a *second* donation from Smartisan, also for one
million RMB and tied only with the earlier Smartisan donation as our
largest single donation ever. It gives me great pleasure to announce
that this donation, in combination with other donation funding received
and promised, has enabled us to add two additional full time OpenSSL
resources, Geoff Thorpe and Richard Levitte. We had been waiting and
hoping for enough donations to "close the gap" in covering one new
position; this one donation did that and more.

Richard will be starting immediately on a full time basis. Geoff is
still arranging a transition from his current employment commitments,
with an expected transition in about a month.

When the OpenSSL team met in D?sseldorf earlier this year we agreed to
embark on an extensive overhaul of OpenSSL (see
https://www.openssl.org/about/roadmap.html and
https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/).
Some of us were concerned that those goals were too ambitious. This
addition of two new full time resources -- nearly doubling our dedicated
manpower -- significantly improves our prospects.

Thank you Smartisan Technology, and CEO Mr. Yonghao Luo. I hope that in
roughly a year from now with the release of OpenSSL 1.1 you will be
pleased with what we have accomplished.

-Steve M.

-- 
Steve Marquess
OpenSSL Software Foundation, Inc.
1829 Mount Ephraim Road
Adamstown, MD  21710
USA
+1 877 673 6775 s/b
+1 301 874 2571 direct
marquess at opensslfoundation.com
marquess at openssl.com
gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc

From zjedev at gmail.com  Tue Dec 30 16:28:05 2014
From: zjedev at gmail.com (Zeke Evans)
Date: Tue, 30 Dec 2014 09:28:05 -0700
Subject: [openssl-users] Does CVE-2014-3569 apply without the no-ssl3
 build option
In-Reply-To: <20141230125526.GA5954@roeckx.be>
References: <CAABX9eojQpehwZuVos+R3v41u-KJnAng3_QN_8Dm2Wc1hOPcyA@mail.gmail.com>
 <20141230125526.GA5954@roeckx.be>
Message-ID: <CAABX9er_AQ6a8eupor2sZnqxyVcJZtkTZ0w8co_2ODOs4sXgeA@mail.gmail.com>

Thanks for clarifying.

On Tue, Dec 30, 2014 at 5:55 AM, Kurt Roeckx <kurt at roeckx.be> wrote:
> On Mon, Dec 29, 2014 at 10:37:49AM -0700, Zeke Evans wrote:
>> Is an OpenSSL 1.0.1j build that does not use the no-ssl3 build option
>> still vulnerable to CVE-2014-3569?  It seems the SSLv3 handshake to a
>> no-ssl3 application scenario is just one way to exploit this and that
>> the ssl23_get_client_hello function causes this issue for any
>> unsupported or unrecognized version.
>
> The can return NULL in case of no-ssl2 or no-ssl3 when receiving
> SSLv2 or SSLv3.  But in case of SSLv2 that function isn't called,
> it directly sets the method to SSLv2_server_method() in that case
> if the previous if block.
>
> Please note that s->verion can't be set to a unknown value but can
> be set to an unsupported value.  SSL2_VERSION and SSL3_VERSION are
> the only 2 options that are known but can be unsupported.  But as
> stated above this doesn't affect SSLv2.
>
> So in summary this only has an effect when build using no-ssl3.
>
>
> Kurt
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users

From bgiles at coyotesong.com  Tue Dec 30 21:53:10 2014
From: bgiles at coyotesong.com (Bear Giles)
Date: Tue, 30 Dec 2014 14:53:10 -0700
Subject: [openssl-users] can I parse PKCS8 file and decrypt it later?
Message-ID: <CALBNtw7dpx6L520swgHszfDiZ3GjUdfaJvYSoC5J35HP4CJPsw@mail.gmail.com>

Two questions actually.

I've been able to read and write most objects using both the PEM bio and
i2d/d2i functions. I know I can write an encrypted PKCS8 file
with PEM_write_bio_PKCS8PrivateKey().

How do I read encrypted PKCS8 files? I can read unencrypted files with
PKCS8_PRIV_KEY_INFO but have been stumped by the encrypted file. Obviously
'openssl pkcs8 ...' can do it but maybe I'm overlooking a source of
documentation. Otherwise it's a dive into the source code.

Second question - can I parse encrypted PKCS8 files without decrypting it?
I know the traditional keys have to be decrypted (and thus parameter-less
readers can't use encrypted files) but I thought PKCS8 was a container and
it was possible to parse the object without the password. Does this involve
X509_SIG?  I noticed that the i2d/d2i PKCS8 functions work with X509_SIG
objects.

Thanks,

Bear
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141230/65cdd28d/attachment.html>

From dthompson at prinpay.com  Tue Dec 30 22:19:27 2014
From: dthompson at prinpay.com (Dave Thompson)
Date: Tue, 30 Dec 2014 17:19:27 -0500
Subject: [openssl-users] Differences in openssl 0.9.8 and 1.0.1x for
	private pem key file
In-Reply-To: <CAGdAg4eVK0O4SrNeMhq4_-Jb03=UzURAwOLtvtAwxwhRsGvrjw@mail.gmail.com>
References: <CAGdAg4e4AAbAFWWW5LG_Twwrkjz-okbVrTgzwUMGoD072fTisQ@mail.gmail.com>
 <000c01d01de6$e56f3ae0$b04db0a0$@prinpay.com>
 <CAGdAg4eVK0O4SrNeMhq4_-Jb03=UzURAwOLtvtAwxwhRsGvrjw@mail.gmail.com>
Message-ID: <000601d0247e$ae554f10$0affed30$@prinpay.com>

> From: openssl-users On Behalf Of Jaya Nageswar
> Sent: Tuesday, December 30, 2014 02:36

> ... the output [is] different between openssl 0.9.8 and 1.0.1x versions as the following methods 
> are being used in the code flow for the method PEM_write_bio_PrivateKey.
> 1.0.1x - PEM_write_bio_PKCS8PrivateKey
> 0.9.8 - PEM_ASN1_write_bio((i2d_of_void *)i2d_PrivateKey,...)

Yes. To be complete, it's 0.9.8anything versus 1.0.0anything OR 1.0.1anything.

> 1. As I mentioned earlier, We have a sample application where we try to read 
> a  sample pem key file, create an EVP_PKEY indirectly using PEM_read_bio_PrivateKey 
> and try to create pem key files encrypted using different ciphers like (RC2, RC4    etc.) 
> using the method PEM_write_bio_PrivateKey. I am getting a different output in 1.0.1x 
> while using the cipher RC2 by using the method PEM_write_bio_PrivateKey.That is 
> understandable as we use PKCS8 in 1.0.1x. However if I try to use the cipher RC4 
> for encyrption,PEM_write_bio_PKCS8PrivateKey is failing.Is there a known issue or a bug for RC4.  

I don't see anything in RT (the bug tracker) but yes privatekey encryption doesn't work 
for RC4, apparently because it's a stream cipher with no IV. The symptoms vary:

- writing PKCS8 encrypted gives an error, in either DER or PEM (PKCS8 is encrypted 
in the DER, the PEM just base64's it). In 1.0.0+ PEM_write_PrivateKey maps to 
PEM_write_PKCS8PrivateKey and therefore gets this.

- writing traditional RSA/etc encrypted PEM (which encrypts at the PEM level) 
writes a file and returns success, but that file can't be decrypted because it has no IV.
In 0.9.8 PEM_write_PrivateKey maps to PEM_write_{RSA/etc}PrivateKey and gets this.

- for completeness remember there is no traditional encrypted DER format.

> 2. Also Can I use the method PEM_ASN1_write_bio((i2d_of_void *)i2d_PrivateKey,...) 
> in 1.0.1x instead of the method PEM_write_bio_PrivateKey if I want to have the same output similar to 0.9.8.

It looks like you can, but it's not documented that I can see and looks a bit fragile.

The long-documented way that works on all versions (so far!) is to call the correct 
per-algorithm routine PEM_write_{RSA,DSA,EC}PrivateKey .



From stenn at ntp.org  Tue Dec 30 21:59:22 2014
From: stenn at ntp.org (Harlan Stenn)
Date: Tue, 30 Dec 2014 21:59:22 +0000
Subject: [openssl-users] Another record-breaking donation from Smartisan
	Technology
In-Reply-To: Steve Marquess's (marquess@opensslfoundation.com) message
 dated Tue, 30 Dec 2014 09:39:45.  <54A2B931.601@opensslfoundation.com>
Message-ID: <E1Y64p0-000A9o-Ax@stenn.ntp.org>

That is just *awesome*!
-- 
Harlan Stenn <stenn at ntp.org>
http://networktimefoundation.org  - be a member!

From benjamin10 at gmx.at  Tue Dec 30 22:35:46 2014
From: benjamin10 at gmx.at (Benjamin)
Date: Tue, 30 Dec 2014 23:35:46 +0100
Subject: [openssl-users] Creating a Certificate with CA=TRUE
In-Reply-To: <058FF4CD-85A6-4CF5-8FFD-F1DE8A665F18@gmx.at>
References: <54941687.8000305@gmx.at>
 <CAH8yC8kAQnA+hp+rr1EeytmbbEXwwwJNK3mjK0+PyrdWdtJerA@mail.gmail.com>
 <058FF4CD-85A6-4CF5-8FFD-F1DE8A665F18@gmx.at>
Message-ID: <54A328C2.9090607@gmx.at>

Am 20.12.2014 um 11:08 schrieb Benjamin Draxlbauer:
> Okay thanks a lot for the quick replies!
> I hope i got that right : it is sufficiently secure and unproblematic 
> to create a CA and use this CA (lets call it root-crt) certificate on 
> my webserver and smartphone and wherever it is needes. In short: you 
> can use the cacert.pem which is produced by ../CA.pl <http://CA.pl> 
> -newca.
> And the /private/cakey.pem should be stored in a secret place on a 
> external device which is offline (sd card usb etc. in my cellar).
>
> Is this right?
>
> Thanks for support!
>
> Am 19. Dezember 2014 21:43:08 MEZ, schrieb Jeffrey Walton 
> <noloader at gmail.com>:
>
>     On Fri, Dec 19, 2014 at 7:13 AM, Benjamin <benjamin10 at gmx.at> wrote:
>
>         Hello everyone! I am quite new to two things: this mailing
>         list and making and working with certificates I want to run a
>         small owncloud on my raspberry pi and tried to make a crt
>         which I can also use with my mobile devices. Here is the
>         problem: When i make a certificate either with this
>         instruction: http://wiki.ubuntuusers.de/CA or this one:
>         https://www.prshanmu.com/2009/03/generating-ssl-certificates-with-x509v3-extensions.html
>         i have the problem that the cacert has "basicconstriants
>         CA=TRUE" but when i make a cert by request i got a new cert
>         (as far as i knew, that which i should use for my nginx
>         webserver) which has CA=FALSE. This is no problem normally but
>         my Android phone only accepts Certs with CA=TRUE and actually
>         i don?t know how to make such a certificate?Of course, i could
>         use the cacert itself but isn?t this insecure and inadequate? 
>
>
>     You can't install self signed certificates (CA=FALSE). You can install
>     client certificates and CA certificates. See
>     https://support.google.com/nexus/answer/2844832?hl=en.
>
>     What you should do is create a CA, sign the web server's certificate
>     with your CA, and then install the CA on your Android device.
>
>     The problem (of the Internet of Things and self-signed certifcates
>     intersecting with Browsers) was recently brought up on the Web App Sec
>     mailing list (see
>     http://lists.w3.org/Archives/Public/public-webappsec/2014Dec/0203.html).
>     There's nothing available at the moment - the Browsers only support
>     the CA Zoo security model.
>
>     Jeff
>     ------------------------------------------------------------------------
>
>     openssl-users mailing list
>     openssl-users at openssl.org
>     https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
>
>
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail 
> gesendet.
>
>
> _______________________________________________
> openssl-users mailing list
> openssl-users at openssl.org
> https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
Finally!
I followed these steps:
https://thomas-leister.de/internet/eine-eigene-openssl-ca-erstellen-und-zertifikate-ausstellen/
In short I did the following:

	openssl genrsa -aes256 -out ca-key.pem 2048
	openssl req -x509 -new -nodes -extensions v3_ca -key ca-key.pem -days 1024 -out ca-root.pem -sha512
		
		Country Name (2 letter code) [AU]:*xx*
		State or Province Name (full name) [Some-State]:*xx*
		Locality Name (eg, city) []:*xx*
		Organization Name (eg, company) [Internet Widgits Pty Ltd]:*xx*
		Organizational Unit Name (eg, section) []:*xx*
		Common Name (eg, YOUR name) []:*mydomainname.no-ip.org*
		Email Address []*: xxxxx**@xxxx.xxx*
imported the root-ca:
	sudo cp ca-root.pem /usr/share/ca-certificates/myca-root.crt
	sudo dpkg-reconfigure ca-certificates
	--> import to my android device
Created a new server cert:
	openssl genrsa -out zertifikat-key.pem 4096
	openssl req -new -key zertifikat-key.pem -out zertifikat.csr -sha512
	openssl x509 -req -in zertifikat.csr -CA ca-root.pem -CAkey ca-key.pem -CAcreateserial -out zertifikat-pub.pem -days 365 -sha512

  then imported the root certificate to my android device and then 
everything worked fine also in my smartphone!

I used as the CN my domain name?is this problematic?

I just want to ask a last time if this is secure enough:
I stored the root cert. and its private key in a secret place (offline 
usb device) and the public key and the server cert. is in a root-folder 
on the server. Of Course due to androids demand to have a CA certificate 
with basic constraints CA=True the root cert. is also on my android 
device but anyway i didn?t manage to create a cert which has this flag 
(also not with yast2-ca-management because it is not allowed to export a 
ca-authority (CA=true) which i understand in a way?) So do i have to 
consider further security actions to protect my server from attacks from 
outside?

Thanks for help! Benjamin.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141230/7af806ff/attachment.html>

From dthompson at prinpay.com  Tue Dec 30 22:48:08 2014
From: dthompson at prinpay.com (Dave Thompson)
Date: Tue, 30 Dec 2014 17:48:08 -0500
Subject: [openssl-users] can I parse PKCS8 file and decrypt it later?
In-Reply-To: <CALBNtw7dpx6L520swgHszfDiZ3GjUdfaJvYSoC5J35HP4CJPsw@mail.gmail.com>
References: <CALBNtw7dpx6L520swgHszfDiZ3GjUdfaJvYSoC5J35HP4CJPsw@mail.gmail.com>
Message-ID: <000701d02482$afcf4810$0f6dd830$@prinpay.com>

> From: openssl-users On Behalf Of Bear Giles
> Sent: Tuesday, December 30, 2014 16:53

> I've been able to read and write most objects using both the PEM bio 
> and i2d/d2i functions. I know I can write an encrypted PKCS8 file with 
> PEM_write_bio_PKCS8PrivateKey().
> How do I read encrypted PKCS8 files? I can read unencrypted files with 
> PKCS8_PRIV_KEY_INFO but have been stumped by the encrypted file. 
> 
For PKCS8 encrypted DER: d2i_PKCS8PrivateKey following the usual pattern.

All of the PEM_read_*PrivateKey routines can read *any* privatekey 
as long as the key type is "satisfactory" (and if encrypted the correct 
password is supplied, of course). Thus 
- PEM_read_RSAPrivateKey can read traditional-RSA or PKCS8-RSA 
- PEM_read_DSAPrivateKey can read traditional-DSA or PKCS8-DSA 
- PEM_read_ECPrivateKey can read traditional-EC or PKCS8-EC 
and the slightly less obvious one
- PEM_read_PrivateKey can read any traditional or any PKCS8

On the _write side you have to specify what file format you want, 
but on the _read side the BEGIN line says what file format it is
and you only need to specify what *key* you want from it.

> Obviously 'openssl pkcs8 ...' can do it but maybe I'm overlooking 
> a source of documentation. Otherwise it's a dive into the source code.

> Second question - can I parse encrypted PKCS8 files without decrypting it? 
> I know the traditional keys have to be decrypted (and thus parameter-less 
> readers can't use encrypted files) but I thought PKCS8 was a container and 
> it was possible to parse the object without the password. Does this involve X509_SIG?  
> I noticed that the i2d/d2i PKCS8 functions work with X509_SIG objects.

Using X509_SIG is kind of a crock; it is because "outer" (encrypted) PKCS8
is just AlgorithmIdentifier plus opaque encrypted data while an X.509 signature 
is just AlgorithmIdentifier plus opaque signature data, and this saved one struct!

Yes you can read in a PKCS8-encrypted file with PEM_read_PKCS8 or d2i_PKCS8 
without decrypting, and that's actually the first step of what _read_*PrivateKey 
or d2i_PKCS8PrivateKey does, but what good does that do you? There is SOME key, 
but you can't use it for anything. You don't even know its algorithm or size or 
anything that might be of use in deciding whether or when to use it.

If you just want to read the file because it might become inaccessible,
read the file into memory as-is and then PEM_read_bio_x or d2i_x_bio 
from a memory BIO that reads that memory.



From matt at openssl.org  Tue Dec 30 23:35:32 2014
From: matt at openssl.org (Matt Caswell)
Date: Tue, 30 Dec 2014 23:35:32 +0000
Subject: [openssl-users] Why construct so wierd certificate chain for
 one web site
In-Reply-To: <CAEKwp_EW=wYCgAyLzqTrnHEyrwjeQvmRTEtFVxbS=cFVuv2tTA@mail.gmail.com>
References: <CAEKwp_HFduiCsh6ybHNuKgQJwNVoYxTpRwG=p6kTZhX7_oG7QA@mail.gmail.com>
 <54A11CD6.1030807@openssl.org>
 <CAEKwp_EW=wYCgAyLzqTrnHEyrwjeQvmRTEtFVxbS=cFVuv2tTA@mail.gmail.com>
Message-ID: <54A336C4.50605@openssl.org>



On 29/12/14 10:00, Jerry OELoo wrote:
> Thanks Jeffrey & Matt
> 
> Now I have a more question, I do not want to make code use tlsv1
> method and SSL_set_tlsext_host_name to query all website, I just want
> to when encounter this issue, then I will construct tlsv1 and set sni
> name to query certificate, So how can I get this kind of information,
> or what is correct coding process when support sni and non-sni
> webiste. Thanks!

You do not need to use tlsv1 method to be able to call
SSL_set_tlsext_host_name - you can use SSLv23_method and it should work
fine.

The SNI hostname is sent as part of the initial ClientHello, i.e. before
you've done anything with the server - so you have limited options to
avoid it. I don't understand why you would want to.

Matt


From petros.fraser at gmail.com  Wed Dec 31 15:26:09 2014
From: petros.fraser at gmail.com (Peter Fraser)
Date: Wed, 31 Dec 2014 10:26:09 -0500
Subject: [openssl-users] Remove Anchor
Message-ID: <CAALr=Tsh-tNVDkwu+3UuQn9Wi=ZjNGdSRuXCwVFsW9zE2S-UEw@mail.gmail.com>

Hi All
Please let me know if I am posting to the correct list. I set up a reverse
proxy for my website using nginx and I had to export the certificate from
my web server to put on the proxy. On windows I exported the certs to a
.pfx file. On my Unix box, I used the command below to export all the certs
to a file. Then I manually removed the private key.

*openssl pkcs12 -in <file_name.pfx> -out outputfile.txt ?nodes*


Afterwards when I ran a test against it using ssllabs it said that my cert
contained an anchor. Does anyone know how to remove this anchor and leave
only the necessary certs for my proxy to use?


Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141231/bf06511f/attachment.html>

From nayak_purushotham at yahoo.com  Wed Dec 31 17:21:43 2014
From: nayak_purushotham at yahoo.com (Purushotham Nayak)
Date: Wed, 31 Dec 2014 17:21:43 +0000 (UTC)
Subject: [openssl-users] OpenSSL AES encryption using AES_* functions and
	EVP_* functions
Message-ID: <1293951861.3151372.1420046503174.JavaMail.yahoo@jws106131.mail.bf1.yahoo.com>

I have some data that was encrypted using the openssl (`AES_*`) functions. I want update this code to use the newer (EVP_*) functions which are FIPS compliant. But I should be able to decrypt data that was encrypted using the old code.
I've pasted below both the old and the new code. The encrypted/decrypted contents are different. i.e. I can't use them interchangeably. This means I can't upgrade the code without having to decrypt using the old code and then re-encrypt.
Are there any values for the parameters to EVP_BytesToKey so that aes_key derived is the same in both cases. Or is there any other way to accomplish the same using the (EVP_*) functions? I've tried several different values for `digest`, `rounds` and tried making IV NULL, but didn't really work i.e. it doesn't provide the same output as the old method. What algorithm is being used in AES_set_encrypt/decrypt_key function?
The code using the `AES_*` functions
? ? #include <stdio.h>? ? #include <openssl/aes.h>? ? #include <print_util.h>? ??? ? static const unsigned char user_key[] = {? ? ? ?0x00, 0x01, 0x02, 0x03,? ? ? ?0x10, 0x11, 0x12, 0x13,? ? ? ?0x20, 0x21, 0x22, 0x23,? ? ? ?0x30, 0x31, 0x32, 0x33? ? };? ??? ? int main()? ? {? ? ? ? unsigned char p_text[]="plain text";? ? ? ? unsigned char c_text[16];? ? ? ? unsigned char d_text[16];? ??? ? ? ? AES_KEY aes_key;? ??? ? ? ? AES_set_encrypt_key(user_key, 128, &aes_key);? ? ? ? AES_encrypt(p_text, c_text, &aes_key);? ??? ? ? ? printf("plain text = %s\n", p_text);? ? ? ? printbuf((char*)c_text, 16, "cipher text = ");? ??? ? ? ? AES_set_decrypt_key(user_key, 128, &aes_key);? ? ? ? AES_decrypt(c_text, d_text, &aes_key);? ? ? ? printf("plain text (decrypted) = %s \n", d_text);? ??? ? ? ? return 0;? ? }
The code using the `EVP_*` functions. (Encryption code is below and the decryption code is similar).
? ? #include <strings.h>? ? #include <openssl/evp.h>? ? #include <print_util.h>? ??? ? static const unsigned char user_key[16] = {? ? ? ?0x00, 0x01, 0x02, 0x03,? ? ? ?0x10, 0x11, 0x12, 0x13,? ? ? ?0x20, 0x21, 0x22, 0x23,? ? ? ?0x30, 0x31, 0x32, 0x33? ? };? ??? ? int main()? ? {? ? ? ? EVP_CIPHER_CTX *ctx = (EVP_CIPHER_CTX*)malloc(sizeof(EVP_CIPHER_CTX));? ? ? ? EVP_CIPHER_CTX_init(ctx);? ??? ? ? ? const EVP_CIPHER *cipher = EVP_aes_128_ecb(); // key size 128, mode ecb (not FIPS compliant?)? ? ? ? const EVP_MD *digest = EVP_md5();? ? ? ? int rounds = 10;? ? ? ? unsigned char aes_key[EVP_MAX_KEY_LENGTH];? ? ? ? unsigned char aes_iv[EVP_MAX_IV_LENGTH];? ??? ? ? ? EVP_BytesToKey(cipher, digest, NULL, user_key, 16, rounds, aes_key, aes_iv);? ??? ? ? ? EVP_EncryptInit(ctx, cipher, aes_key, aes_iv);? ??? ? ? ? unsigned char p_text[]="plain text"; int p_len = sizeof(p_text);? ? ? ? unsigned char c_text[16]; int c_len = 16;? ? ? ? int t_len;? ??? ? ? ? EVP_EncryptUpdate(ctx, c_text, &c_len, p_text, p_len);? ? ? ? EVP_EncryptFinal(ctx, (c_text + c_len), &t_len);? ??? ? ? ? c_len += t_len;? ??? ? ? ? printf("==> p_text: %s\n", p_text);? ? ? ? printbuf((char*)c_text, c_len, "==> c_text:");? ? }
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141231/0132282b/attachment.html>

From dthompson at prinpay.com  Wed Dec 31 19:45:08 2014
From: dthompson at prinpay.com (Dave Thompson)
Date: Wed, 31 Dec 2014 14:45:08 -0500
Subject: [openssl-users] OpenSSL AES encryption using AES_* functions
	and	EVP_* functions
In-Reply-To: <1293951861.3151372.1420046503174.JavaMail.yahoo@jws106131.mail.bf1.yahoo.com>
References: <1293951861.3151372.1420046503174.JavaMail.yahoo@jws106131.mail.bf1.yahoo.com>
Message-ID: <001a01d02532$4bca5c50$e35f14f0$@prinpay.com>

> From: openssl-users On Behalf Of Purushotham Nayak
> Sent: Wednesday, December 31, 2014 12:22

> I have some data that was encrypted using the openssl (`AES_*`) functions. 
> I want update this code to use the newer (EVP_*) functions which are 
> FIPS compliant. But I should be able to decrypt data that was encrypted 
> using the old code.

> I've pasted below both the old and the new code. The encrypted/decrypted 
> contents are different. i.e. I can't use them interchangeably. This means 
> I can't upgrade the code without having to decrypt using the old code 
> and then re-encrypt.

> Are there any values for the parameters to EVP_BytesToKey so that 
> aes_key derived is the same in both cases. Or is there any other way 
> to accomplish the same using the (EVP_*) functions? I've tried <snip>

What on earth makes you think EVP_BytesToKey is appropriate? 
EVP_BytesToKey is used for *password-based* encryption, where 
the key (and sometimes IV) is derived in a complicated way from 
a character string intended to be remembered by humans. 
(Even for that it is outdated and PKCS5_PBKDF2* is better.)

If you have an actual key, as you did in your old code, you simply pass 
that same actual key to EVP_EncryptInit as the actual key.

> What algorithm is being used in AES_set_encrypt/decrypt_key function?

The key scheduling defined in FIPS 197 (and before that Rijndael).
And so is EVP_EncryptInit* when used on an AES cipher.

> The code using the `AES_*` functions
<snip>
>    int main()
>    {
>        unsigned char p_text[]="plain text";
>        unsigned char c_text[16];
<snip set_encrypt_key>
>      AES_encrypt(p_text, c_text, &aes_key);
    
This old code allocates a buffer of 11 bytes to contain the plaintext and passes 
it to AES_encrypt which reads 16 bytes (always). The remaining 5 bytes are 
undefined by the C standard -- in fact the *behavior* is undefined by standard, 
although in practice nearly all implementations will read *some* values. 
*What* values they read may depend on your compiler, version, options, 
computer, operating system, and the phase of the moon, which means you 
probably can't duplicate it in the new code. You can still decrypt old values 
with the fixes described below, but you can't faithfully recreate them.

> The code using the `EVP_*` functions. (Encryption code is below and the decryption code is similar).
<snip>
>    int main()
>    {
>        EVP_CIPHER_CTX *ctx = (EVP_CIPHER_CTX*)malloc(sizeof(EVP_CIPHER_CTX));
>        EVP_CIPHER_CTX_init(ctx);

EVP_CIPHER_CTX_new() is simpler.
  
>        const EVP_CIPHER *cipher = EVP_aes_128_ecb(); // key size 128, mode ecb (not FIPS compliant?)

FIPS140 covers only the algorithm not the mode, so all modes are equally "compliant".
However ECB is frequently insecure and a Very Bad Idea if used for anything other 
than random data. See Wikipedia, or practically any good crypto reference.

<snip EVP_BytesToKey and related: just remove that>
    
>        EVP_EncryptInit(ctx, cipher, aes_key, aes_iv);

Pass the actual key, of the correct size. ECB does not use an IV, so you can pass NULL 
or any value of the correct size which will be ignored. Not using an IV is one of the 
(several) things that makes ECB frequently insecure, see above.
    
EVP will by default add and remove PKCS5 (or more exactly PKCS7) padding. 
To avoid that, and particularly to decrypt values from your old code which used 
some garbage data (see above) rather than valid padding, 
    EVP_CIPHER_CTX_set_padding (ctx, 0);

>        unsigned char p_text[]="plain text"; int p_len = sizeof(p_text);
>        unsigned char c_text[16]; int c_len = 16;
>        int t_len;
>        EVP_EncryptUpdate(ctx, c_text, &c_len, p_text, p_len);
>        EVP_EncryptFinal(ctx, (c_text + c_len), &t_len);
>        c_len += t_len;
 
Happy New Year.