From rsalz at akamai.com  Tue May  1 01:19:05 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 1 May 2018 01:19:05 +0000
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <080A1B7F-D97E-4192-884D-6D20DEF283E5@dukhovni.org>
References: <20180429104326.GA21314@roeckx.be>
 <A60CBF9A-4C9A-4CC8-A995-1F0CCE2EA7F7@akamai.com>
 <8EC62B1C-7FD7-45EB-B03D-9C7B03B96F76@akamai.com>
 <0e7eb0d1-a0cf-fceb-b997-d2223b5694e7@blastwave.org>
 <042FBF10-B77A-4441-A5E4-02218D0AA379@akamai.com>
 <3b56faa2-b145-1496-001e-38ecff7729fe@blastwave.org>
 <080A1B7F-D97E-4192-884D-6D20DEF283E5@dukhovni.org>
Message-ID: <AEAEB651-D693-4800-BB82-0E4C80DC30E4@akamai.com>

>    Interoperability issues with middle-boxes or existing software written for TLS 1.2.
 
Facebook, Google, and Mozilla did lots of testing with TLS 1.3 and middleboxes.  If something was missed, the whole Internet will have problems.  Existing software is the question we are trying to answer.


From openssl at openssl.org  Tue May  1 13:06:36 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 1 May 2018 13:06:36 +0000
Subject: [openssl-users] OpenSSL version 1.1.1 pre release 6 published
Message-ID: <20180501130636.GA9299@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


   OpenSSL version 1.1.1 pre release 6 (beta)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 6 has now
   been made available. For details of changes and known issues see the
   release notes at:

        https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.1-pre6.tar.gz
      Size: 8286337
      SHA1 checksum: d9aa6121ea9e8bfc4632566c72b376620c68ece3
      SHA256 checksum: 01f91c5370fe210f7172d863c5bdc5dee2450c3faa98b4af2627ee6f7e128d87

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.1-pre6.tar.gz
    openssl sha256 openssl-1.1.1-pre6.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

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

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJa6GGbAAoJENnE0m0OYESRnqwH/jMNw6OXpGYriZphZxLNDBlR
YGJcNypVPcW1y5aDPlhBp9GUTAot4NPtbYpbBegPdvWaI4tA5O3+2gnCRh3xoE9e
k704SlJP+mmBOJSL2/9xSH1tJHNrSmXkHOpfZCr4nKJfayFDnl/H+vf6yNz3CzeB
Oys/VDpLPrV2ev10QNpeypu37es4shNSIRU1OEjH+iDrmTBzt9LzU6dS1rYjtuiV
QK/rdKV8ql0SFNIsrpLHNCT2EMfRqT/kbLcqObrczNBSunZXQF98W4XVhp7dlFBT
GrE8gc/KY8YGfX6kF+1Vy+9vDDKNwaLyzRKXMKUZRLnxkSBbZBREerfwaQT7m0o=
=O0aC
-----END PGP SIGNATURE-----

From john.sha.jiang at gmail.com  Wed May  2 02:48:00 2018
From: john.sha.jiang at gmail.com (John Jiang)
Date: Wed, 2 May 2018 10:48:00 +0800
Subject: [openssl-users] OpenSSL version 1.1.1 pre release 6 published
In-Reply-To: <20180501130636.GA9299@openssl.org>
References: <20180501130636.GA9299@openssl.org>
Message-ID: <CAJbO6CQAhQTfHJp2Q-99NVggJW0SJGwx9Ob73=iLhjWP7avSVQ@mail.gmail.com>

Hi,
I don't see the link for openssl-1.1.1-pre6.tar.gz on page
https://www.openssl.org/source/

Thanks,
John

2018-05-01 21:06 GMT+08:00 OpenSSL <openssl at openssl.org>:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>
>    OpenSSL version 1.1.1 pre release 6 (beta)
>    ===========================================
>
>    OpenSSL - The Open Source toolkit for SSL/TLS
>    https://www.openssl.org/
>
>    OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 6 has now
>    been made available. For details of changes and known issues see the
>    release notes at:
>
>         https://www.openssl.org/news/openssl-1.1.1-notes.html
>
>    Note: This OpenSSL pre-release has been provided for testing ONLY.
>    It should NOT be used for security critical purposes.
>
>    The beta release is available for download via HTTP and FTP from the
>    following master locations (you can find the various FTP mirrors under
>    https://www.openssl.org/source/mirror.html):
>
>      * https://www.openssl.org/source/
>      * ftp://ftp.openssl.org/source/
>
>    The distribution file name is:
>
>     o openssl-1.1.1-pre6.tar.gz
>       Size: 8286337
>       SHA1 checksum: d9aa6121ea9e8bfc4632566c72b376620c68ece3
>       SHA256 checksum: 01f91c5370fe210f7172d863c5bdc5
> dee2450c3faa98b4af2627ee6f7e128d87
>
>    The checksums were calculated using the following commands:
>
>     openssl sha1 openssl-1.1.1-pre6.tar.gz
>     openssl sha256 openssl-1.1.1-pre6.tar.gz
>
>    Please download and check this beta release as soon as possible.
>    To report a bug, open an issue on GitHub:
>
>     https://github.com/openssl/openssl/issues
>
>    Please check the release notes and mailing lists to avoid duplicate
>    reports of known issues. (Of course, the source is also available
>    on GitHub.)
>
>    Yours,
>
>    The OpenSSL Project Team.
>
> -----BEGIN PGP SIGNATURE-----
>
> iQEcBAEBCAAGBQJa6GGbAAoJENnE0m0OYESRnqwH/jMNw6OXpGYriZphZxLNDBlR
> YGJcNypVPcW1y5aDPlhBp9GUTAot4NPtbYpbBegPdvWaI4tA5O3+2gnCRh3xoE9e
> k704SlJP+mmBOJSL2/9xSH1tJHNrSmXkHOpfZCr4nKJfayFDnl/H+vf6yNz3CzeB
> Oys/VDpLPrV2ev10QNpeypu37es4shNSIRU1OEjH+iDrmTBzt9LzU6dS1rYjtuiV
> QK/rdKV8ql0SFNIsrpLHNCT2EMfRqT/kbLcqObrczNBSunZXQF98W4XVhp7dlFBT
> GrE8gc/KY8YGfX6kF+1Vy+9vDDKNwaLyzRKXMKUZRLnxkSBbZBREerfwaQT7m0o=
> =O0aC
> -----END PGP SIGNATURE-----
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180502/25bd1f13/attachment.html>

From john.sha.jiang at gmail.com  Wed May  2 05:53:49 2018
From: john.sha.jiang at gmail.com (John Jiang)
Date: Wed, 2 May 2018 13:53:49 +0800
Subject: [openssl-users] OpenSSL version 1.1.1 pre release 6 published
In-Reply-To: <CAJbO6CQAhQTfHJp2Q-99NVggJW0SJGwx9Ob73=iLhjWP7avSVQ@mail.gmail.com>
References: <20180501130636.GA9299@openssl.org>
 <CAJbO6CQAhQTfHJp2Q-99NVggJW0SJGwx9Ob73=iLhjWP7avSVQ@mail.gmail.com>
Message-ID: <CAJbO6CQvGSAZsxRoxexfjC7KRy0Mttf8eKwoqAwha84r5WMgEA@mail.gmail.com>

Anyway, I can download it via
https://www.openssl.org/source/openssl-1.1.1-pre6.tar.gz

John

2018-05-02 10:48 GMT+08:00 John Jiang <john.sha.jiang at gmail.com>:

> Hi,
> I don't see the link for openssl-1.1.1-pre6.tar.gz on page
> https://www.openssl.org/source/
>
> Thanks,
> John
>
>
> 2018-05-01 21:06 GMT+08:00 OpenSSL <openssl at openssl.org>:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>>
>>    OpenSSL version 1.1.1 pre release 6 (beta)
>>    ===========================================
>>
>>    OpenSSL - The Open Source toolkit for SSL/TLS
>>    https://www.openssl.org/
>>
>>    OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 6 has now
>>    been made available. For details of changes and known issues see the
>>    release notes at:
>>
>>         https://www.openssl.org/news/openssl-1.1.1-notes.html
>>
>>    Note: This OpenSSL pre-release has been provided for testing ONLY.
>>    It should NOT be used for security critical purposes.
>>
>>    The beta release is available for download via HTTP and FTP from the
>>    following master locations (you can find the various FTP mirrors under
>>    https://www.openssl.org/source/mirror.html):
>>
>>      * https://www.openssl.org/source/
>>      * ftp://ftp.openssl.org/source/
>>
>>    The distribution file name is:
>>
>>     o openssl-1.1.1-pre6.tar.gz
>>       Size: 8286337
>>       SHA1 checksum: d9aa6121ea9e8bfc4632566c72b376620c68ece3
>>       SHA256 checksum: 01f91c5370fe210f7172d863c5bdc5
>> dee2450c3faa98b4af2627ee6f7e128d87
>>
>>    The checksums were calculated using the following commands:
>>
>>     openssl sha1 openssl-1.1.1-pre6.tar.gz
>>     openssl sha256 openssl-1.1.1-pre6.tar.gz
>>
>>    Please download and check this beta release as soon as possible.
>>    To report a bug, open an issue on GitHub:
>>
>>     https://github.com/openssl/openssl/issues
>>
>>    Please check the release notes and mailing lists to avoid duplicate
>>    reports of known issues. (Of course, the source is also available
>>    on GitHub.)
>>
>>    Yours,
>>
>>    The OpenSSL Project Team.
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQEcBAEBCAAGBQJa6GGbAAoJENnE0m0OYESRnqwH/jMNw6OXpGYriZphZxLNDBlR
>> YGJcNypVPcW1y5aDPlhBp9GUTAot4NPtbYpbBegPdvWaI4tA5O3+2gnCRh3xoE9e
>> k704SlJP+mmBOJSL2/9xSH1tJHNrSmXkHOpfZCr4nKJfayFDnl/H+vf6yNz3CzeB
>> Oys/VDpLPrV2ev10QNpeypu37es4shNSIRU1OEjH+iDrmTBzt9LzU6dS1rYjtuiV
>> QK/rdKV8ql0SFNIsrpLHNCT2EMfRqT/kbLcqObrczNBSunZXQF98W4XVhp7dlFBT
>> GrE8gc/KY8YGfX6kF+1Vy+9vDDKNwaLyzRKXMKUZRLnxkSBbZBREerfwaQT7m0o=
>> =O0aC
>> -----END PGP SIGNATURE-----
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180502/a04154f5/attachment.html>

From eldiener at tropicsoft.com  Wed May  2 12:19:40 2018
From: eldiener at tropicsoft.com (Edward Diener)
Date: Wed, 2 May 2018 08:19:40 -0400
Subject: [openssl-users] OPENSSL_VERSION_NUMBER representation
Message-ID: <pcca8k$ejs$1@blaine.gmane.org>

The latest documentation for OPENSSL_VERSION_NUMBER at 
https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.html 
says that it is 9 hex digits, with the last nibble being a status 
identifier, while every use I have seen of it in header files treats it 
as 8 hex digits. Can anybody straighten me out on this ?

Also the latest documentation give it as

MNNFFPPS: major minor fix patch status

where the examples in that documentation clearly show it as

MMNNFFPPS: major minor fix patch status

Can anybody straighten me out on this ?

I would like to use the OPENSSL_VERSION_NUMBER at compile time to choose 
between functionality for version 1.1.0 and version 1.0.x but the 
confusion in my mind of how OPENSSL_VERSION_NUMBER actually is specified 
is making that impossible.


From tmraz at redhat.com  Wed May  2 12:30:42 2018
From: tmraz at redhat.com (Tomas Mraz)
Date: Wed, 02 May 2018 14:30:42 +0200
Subject: [openssl-users] OPENSSL_VERSION_NUMBER representation
In-Reply-To: <pcca8k$ejs$1@blaine.gmane.org>
References: <pcca8k$ejs$1@blaine.gmane.org>
Message-ID: <1525264242.3064.27.camel@redhat.com>

On Wed, 2018-05-02 at 08:19 -0400, Edward Diener wrote:
> The latest documentation for OPENSSL_VERSION_NUMBER at 
> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.h
> tml 
> says that it is 9 hex digits, with the last nibble being a status 
> identifier, while every use I have seen of it in header files treats
> it 
> as 8 hex digits. Can anybody straighten me out on this ?
> 
> Also the latest documentation give it as
> 
> MNNFFPPS: major minor fix patch status
> 
> where the examples in that documentation clearly show it as
> 
> MMNNFFPPS: major minor fix patch status
> 
> Can anybody straighten me out on this ?

That's because 0x1 and 0x01 are the same numbers.

For example version 1.1.0a: 0x01010001f == 0x1010001f

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


From eldiener at tropicsoft.com  Thu May  3 02:54:18 2018
From: eldiener at tropicsoft.com (Edward Diener)
Date: Wed, 2 May 2018 22:54:18 -0400
Subject: [openssl-users] OPENSSL_VERSION_NUMBER representation
In-Reply-To: <1525264242.3064.27.camel@redhat.com>
References: <pcca8k$ejs$1@blaine.gmane.org>
 <1525264242.3064.27.camel@redhat.com>
Message-ID: <pcdtgi$a7a$1@blaine.gmane.org>

On 5/2/2018 8:30 AM, Tomas Mraz wrote:
> On Wed, 2018-05-02 at 08:19 -0400, Edward Diener wrote:
>> The latest documentation for OPENSSL_VERSION_NUMBER at
>> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_VERSION_NUMBER.h
>> tml
>> says that it is 9 hex digits, with the last nibble being a status
>> identifier, while every use I have seen of it in header files treats
>> it
>> as 8 hex digits. Can anybody straighten me out on this ?
>>
>> Also the latest documentation give it as
>>
>> MNNFFPPS: major minor fix patch status
>>
>> where the examples in that documentation clearly show it as
>>
>> MMNNFFPPS: major minor fix patch status
>>
>> Can anybody straighten me out on this ?
> 
> That's because 0x1 and 0x01 are the same numbers.
> 
> For example version 1.1.0a: 0x01010001f == 0x1010001f
> 

Thanks ! I guess version 16 of openssl isn't planned for anytime soon <g>.


From morthalaanilreddy at gmail.com  Thu May  3 07:06:40 2018
From: morthalaanilreddy at gmail.com (Anil kumar Reddy)
Date: Thu, 3 May 2018 09:06:40 +0200
Subject: [openssl-users] How to prove a Certificate is Signed or not
Message-ID: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>

 Hi everyone,

I am new to opennssl and now I am completely confused. Please help me out
to solve my issue.

I have implemented a code to sign the given CSR certificate (certReq.pem),
then generate openssl signed Certificate (SignedCertificate.pem) using the
details of certReq,pem. The code is like self signing, but I have added new
functions to enter additional issuer details. Now I have two private keys
one from CA, another from CSR, one CSR (certReq.pem) and Signed Certificate
(SignedCertificate.pem). In SignedCertificate.pem, the subject details and
the issuer details are different. There is no problem with codes.

The issue is:
I am unable to find out the exact command lines or c/c++ program functions
to prove the SignedCertificate.pem is signed or not. I have spent more than
one day on researching, but I am end up with confusion. I do not have any
digital certificate chain.


Could anyone kindly provide any information regarding this.

Thanks in advance,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180503/ebaecfcc/attachment.html>

From d3ck0r at gmail.com  Thu May  3 07:36:49 2018
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 3 May 2018 00:36:49 -0700
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
Message-ID: <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>

https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
this routine does cert validation but I don't thkn that's what you want

this verified on a connection....
https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274

which boils down to....
SSL_get_peer_certificate ,  SSL_get_verify_result

On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <
morthalaanilreddy at gmail.com> wrote:

> Hi everyone,
>
> I am new to opennssl and now I am completely confused. Please help me out
> to solve my issue.
>
> I have implemented a code to sign the given CSR certificate (certReq.pem),
> then generate openssl signed Certificate (SignedCertificate.pem) using the
> details of certReq,pem. The code is like self signing, but I have added new
> functions to enter additional issuer details. Now I have two private keys
> one from CA, another from CSR, one CSR (certReq.pem) and Signed Certificate
> (SignedCertificate.pem). In SignedCertificate.pem, the subject details and
> the issuer details are different. There is no problem with codes.
>
> The issue is:
> I am unable to find out the exact command lines or c/c++ program functions
> to prove the SignedCertificate.pem is signed or not. I have spent more than
> one day on researching, but I am end up with confusion. I do not have any
> digital certificate chain.
>
>
> Could anyone kindly provide any information regarding this.
>
> Thanks in advance,
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180503/e296ca32/attachment.html>

From morthalaanilreddy at gmail.com  Thu May  3 08:23:19 2018
From: morthalaanilreddy at gmail.com (morthalan)
Date: Thu, 3 May 2018 01:23:19 -0700 (MST)
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
Message-ID: <1525335799770-0.post@n7.nabble.com>

No, technically not. I am just searching for a simple method just to check a
certificate is signed by CA or not. 
Because. Something like signing check, I am not quite sure, I do not have
proper knowledge on Openssl.


d3x0r wrote
> https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
> this routine does cert validation but I don't thkn that's what you want
> 
> this verified on a connection....
> https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274
> 
> which boils down to....
> SSL_get_peer_certificate ,  SSL_get_verify_result
> 
> On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <

> morthalaanilreddy@

>> wrote:
> 
>> Hi everyone,
>>
>> I am new to opennssl and now I am completely confused. Please help me out
>> to solve my issue.
>>
>> I have implemented a code to sign the given CSR certificate
>> (certReq.pem),
>> then generate openssl signed Certificate (SignedCertificate.pem) using
>> the
>> details of certReq,pem. The code is like self signing, but I have added
>> new
>> functions to enter additional issuer details. Now I have two private keys
>> one from CA, another from CSR, one CSR (certReq.pem) and Signed
>> Certificate
>> (SignedCertificate.pem). In SignedCertificate.pem, the subject details
>> and
>> the issuer details are different. There is no problem with codes.
>>
>> The issue is:
>> I am unable to find out the exact command lines or c/c++ program
>> functions
>> to prove the SignedCertificate.pem is signed or not. I have spent more
>> than
>> one day on researching, but I am end up with confusion. I do not have any
>> digital certificate chain.
>>
>>
>> Could anyone kindly provide any information regarding this.
>>
>> Thanks in advance,
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


d3x0r wrote
> https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
> this routine does cert validation but I don't thkn that's what you want
> 
> this verified on a connection....
> https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274
> 
> which boils down to....
> SSL_get_peer_certificate ,  SSL_get_verify_result
> 
> On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <

> morthalaanilreddy@

>> wrote:
> 
>> Hi everyone,
>>
>> I am new to opennssl and now I am completely confused. Please help me out
>> to solve my issue.
>>
>> I have implemented a code to sign the given CSR certificate
>> (certReq.pem),
>> then generate openssl signed Certificate (SignedCertificate.pem) using
>> the
>> details of certReq,pem. The code is like self signing, but I have added
>> new
>> functions to enter additional issuer details. Now I have two private keys
>> one from CA, another from CSR, one CSR (certReq.pem) and Signed
>> Certificate
>> (SignedCertificate.pem). In SignedCertificate.pem, the subject details
>> and
>> the issuer details are different. There is no problem with codes.
>>
>> The issue is:
>> I am unable to find out the exact command lines or c/c++ program
>> functions
>> to prove the SignedCertificate.pem is signed or not. I have spent more
>> than
>> one day on researching, but I am end up with confusion. I do not have any
>> digital certificate chain.
>>
>>
>> Could anyone kindly provide any information regarding this.
>>
>> Thanks in advance,
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


d3x0r wrote
> https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
> this routine does cert validation but I don't thkn that's what you want
> 
> this verified on a connection....
> https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274
> 
> which boils down to....
> SSL_get_peer_certificate ,  SSL_get_verify_result
> 
> On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <

> morthalaanilreddy@

>> wrote:
> 
>> Hi everyone,
>>
>> I am new to opennssl and now I am completely confused. Please help me out
>> to solve my issue.
>>
>> I have implemented a code to sign the given CSR certificate
>> (certReq.pem),
>> then generate openssl signed Certificate (SignedCertificate.pem) using
>> the
>> details of certReq,pem. The code is like self signing, but I have added
>> new
>> functions to enter additional issuer details. Now I have two private keys
>> one from CA, another from CSR, one CSR (certReq.pem) and Signed
>> Certificate
>> (SignedCertificate.pem). In SignedCertificate.pem, the subject details
>> and
>> the issuer details are different. There is no problem with codes.
>>
>> The issue is:
>> I am unable to find out the exact command lines or c/c++ program
>> functions
>> to prove the SignedCertificate.pem is signed or not. I have spent more
>> than
>> one day on researching, but I am end up with confusion. I do not have any
>> digital certificate chain.
>>
>>
>> Could anyone kindly provide any information regarding this.
>>
>> Thanks in advance,
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users





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

From darshanmody at avaya.com  Thu May  3 08:42:50 2018
From: darshanmody at avaya.com (Mody, Darshan (Darshan))
Date: Thu, 3 May 2018 08:42:50 +0000
Subject: [openssl-users] disable session id reuse
Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A41FE1B@AZ-FFEXMB03.global.avaya.com>

Hi,

While doing a openssl s_time command I find that by default it tries for Session Id Reuse. "Now timing with session id reuse."

In case if we don't want openssl to reuse session id's how can we configure openssl in the application for the same.

The application here is acting as a server.

I have set  SSL_CTX_set_session_cache_mode to SSL_SESS_CACHE_OFF

Thanks
Darshan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180503/dae94674/attachment.html>

From d3ck0r at gmail.com  Thu May  3 08:56:37 2018
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 3 May 2018 01:56:37 -0700
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
Message-ID: <CAA2GJqVgJVykDzHqDCrzovPzkPBfWqajXgp9mZ=EXV3=S-v-kw@mail.gmail.com>

Or using the javascript interface

https://www.npmjs.com/package/sack.vfs#interface

https://github.com/d3x0r/sack.vfs/blob/master/tests/tlsTest.js#L28

if( vfs.TLS.validate( {cert:signedCert3, chain:signedCert2+cert} ) )
    console.log( "Chain is valid." );

On Thu, May 3, 2018 at 12:36 AM, J Decker <d3ck0r at gmail.com> wrote:

> https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
> this routine does cert validation but I don't thkn that's what you want
>
> this verified on a connection.... https://github.
> com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274
>
> which boils down to....
> SSL_get_peer_certificate ,  SSL_get_verify_result
>
> On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <
> morthalaanilreddy at gmail.com> wrote:
>
>> Hi everyone,
>>
>> I am new to opennssl and now I am completely confused. Please help me out
>> to solve my issue.
>>
>> I have implemented a code to sign the given CSR certificate
>> (certReq.pem), then generate openssl signed Certificate
>> (SignedCertificate.pem) using the details of certReq,pem. The code is like
>> self signing, but I have added new functions to enter additional issuer
>> details. Now I have two private keys one from CA, another from CSR, one CSR
>> (certReq.pem) and Signed Certificate (SignedCertificate.pem). In
>> SignedCertificate.pem, the subject details and the issuer details are
>> different. There is no problem with codes.
>>
>> The issue is:
>> I am unable to find out the exact command lines or c/c++ program
>> functions to prove the SignedCertificate.pem is signed or not. I have spent
>> more than one day on researching, but I am end up with confusion. I do not
>> have any digital certificate chain.
>>
>>
>> Could anyone kindly provide any information regarding this.
>>
>> Thanks in advance,
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180503/b2f18c66/attachment-0001.html>

From levitte at openssl.org  Thu May  3 09:24:48 2018
From: levitte at openssl.org (Richard Levitte)
Date: Thu, 03 May 2018 11:24:48 +0200 (CEST)
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <1525335799770-0.post@n7.nabble.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
Message-ID: <20180503.112448.1286710673559008677.levitte@openssl.org>

openssl verify -CAfile your_ca_cert.pem SignedCertificate.pem

Hope that helped

Cheers,
Richard

In message <1525335799770-0.post at n7.nabble.com> on Thu, 3 May 2018 01:23:19 -0700 (MST), morthalan <morthalaanilreddy at gmail.com> said:

morthalaanilreddy> No, technically not. I am just searching for a simple method just to check a
morthalaanilreddy> certificate is signed by CA or not. 
morthalaanilreddy> Because. Something like signing check, I am not quite sure, I do not have
morthalaanilreddy> proper knowledge on Openssl.
morthalaanilreddy> 
morthalaanilreddy> 
morthalaanilreddy> d3x0r wrote
morthalaanilreddy> > https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
morthalaanilreddy> > this routine does cert validation but I don't thkn that's what you want
morthalaanilreddy> > 
morthalaanilreddy> > this verified on a connection....
morthalaanilreddy> > https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274
morthalaanilreddy> > 
morthalaanilreddy> > which boils down to....
morthalaanilreddy> > SSL_get_peer_certificate ,  SSL_get_verify_result
morthalaanilreddy> > 
morthalaanilreddy> > On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <
morthalaanilreddy> 
morthalaanilreddy> > morthalaanilreddy@
morthalaanilreddy> 
morthalaanilreddy> >> wrote:
morthalaanilreddy> > 
morthalaanilreddy> >> Hi everyone,
morthalaanilreddy> >>
morthalaanilreddy> >> I am new to opennssl and now I am completely confused. Please help me out
morthalaanilreddy> >> to solve my issue.
morthalaanilreddy> >>
morthalaanilreddy> >> I have implemented a code to sign the given CSR certificate
morthalaanilreddy> >> (certReq.pem),
morthalaanilreddy> >> then generate openssl signed Certificate (SignedCertificate.pem) using
morthalaanilreddy> >> the
morthalaanilreddy> >> details of certReq,pem. The code is like self signing, but I have added
morthalaanilreddy> >> new
morthalaanilreddy> >> functions to enter additional issuer details. Now I have two private keys
morthalaanilreddy> >> one from CA, another from CSR, one CSR (certReq.pem) and Signed
morthalaanilreddy> >> Certificate
morthalaanilreddy> >> (SignedCertificate.pem). In SignedCertificate.pem, the subject details
morthalaanilreddy> >> and
morthalaanilreddy> >> the issuer details are different. There is no problem with codes.
morthalaanilreddy> >>
morthalaanilreddy> >> The issue is:
morthalaanilreddy> >> I am unable to find out the exact command lines or c/c++ program
morthalaanilreddy> >> functions
morthalaanilreddy> >> to prove the SignedCertificate.pem is signed or not. I have spent more
morthalaanilreddy> >> than
morthalaanilreddy> >> one day on researching, but I am end up with confusion. I do not have any
morthalaanilreddy> >> digital certificate chain.
morthalaanilreddy> >>
morthalaanilreddy> >>
morthalaanilreddy> >> Could anyone kindly provide any information regarding this.
morthalaanilreddy> >>
morthalaanilreddy> >> Thanks in advance,
morthalaanilreddy> >>
morthalaanilreddy> >> --
morthalaanilreddy> >> openssl-users mailing list
morthalaanilreddy> >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
morthalaanilreddy> >>
morthalaanilreddy> >>
morthalaanilreddy> > 
morthalaanilreddy> > -- 
morthalaanilreddy> > openssl-users mailing list
morthalaanilreddy> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
morthalaanilreddy> 
morthalaanilreddy> 
morthalaanilreddy> d3x0r wrote
morthalaanilreddy> > https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
morthalaanilreddy> > this routine does cert validation but I don't thkn that's what you want
morthalaanilreddy> > 
morthalaanilreddy> > this verified on a connection....
morthalaanilreddy> > https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274
morthalaanilreddy> > 
morthalaanilreddy> > which boils down to....
morthalaanilreddy> > SSL_get_peer_certificate ,  SSL_get_verify_result
morthalaanilreddy> > 
morthalaanilreddy> > On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <
morthalaanilreddy> 
morthalaanilreddy> > morthalaanilreddy@
morthalaanilreddy> 
morthalaanilreddy> >> wrote:
morthalaanilreddy> > 
morthalaanilreddy> >> Hi everyone,
morthalaanilreddy> >>
morthalaanilreddy> >> I am new to opennssl and now I am completely confused. Please help me out
morthalaanilreddy> >> to solve my issue.
morthalaanilreddy> >>
morthalaanilreddy> >> I have implemented a code to sign the given CSR certificate
morthalaanilreddy> >> (certReq.pem),
morthalaanilreddy> >> then generate openssl signed Certificate (SignedCertificate.pem) using
morthalaanilreddy> >> the
morthalaanilreddy> >> details of certReq,pem. The code is like self signing, but I have added
morthalaanilreddy> >> new
morthalaanilreddy> >> functions to enter additional issuer details. Now I have two private keys
morthalaanilreddy> >> one from CA, another from CSR, one CSR (certReq.pem) and Signed
morthalaanilreddy> >> Certificate
morthalaanilreddy> >> (SignedCertificate.pem). In SignedCertificate.pem, the subject details
morthalaanilreddy> >> and
morthalaanilreddy> >> the issuer details are different. There is no problem with codes.
morthalaanilreddy> >>
morthalaanilreddy> >> The issue is:
morthalaanilreddy> >> I am unable to find out the exact command lines or c/c++ program
morthalaanilreddy> >> functions
morthalaanilreddy> >> to prove the SignedCertificate.pem is signed or not. I have spent more
morthalaanilreddy> >> than
morthalaanilreddy> >> one day on researching, but I am end up with confusion. I do not have any
morthalaanilreddy> >> digital certificate chain.
morthalaanilreddy> >>
morthalaanilreddy> >>
morthalaanilreddy> >> Could anyone kindly provide any information regarding this.
morthalaanilreddy> >>
morthalaanilreddy> >> Thanks in advance,
morthalaanilreddy> >>
morthalaanilreddy> >> --
morthalaanilreddy> >> openssl-users mailing list
morthalaanilreddy> >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
morthalaanilreddy> >>
morthalaanilreddy> >>
morthalaanilreddy> > 
morthalaanilreddy> > -- 
morthalaanilreddy> > openssl-users mailing list
morthalaanilreddy> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
morthalaanilreddy> 
morthalaanilreddy> 
morthalaanilreddy> d3x0r wrote
morthalaanilreddy> > https://github.com/d3x0r/sack.vfs/blob/master/src/tls_interface.cc#L1538
morthalaanilreddy> > this routine does cert validation but I don't thkn that's what you want
morthalaanilreddy> > 
morthalaanilreddy> > this verified on a connection....
morthalaanilreddy> > https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L274
morthalaanilreddy> > 
morthalaanilreddy> > which boils down to....
morthalaanilreddy> > SSL_get_peer_certificate ,  SSL_get_verify_result
morthalaanilreddy> > 
morthalaanilreddy> > On Thu, May 3, 2018 at 12:06 AM, Anil kumar Reddy <
morthalaanilreddy> 
morthalaanilreddy> > morthalaanilreddy@
morthalaanilreddy> 
morthalaanilreddy> >> wrote:
morthalaanilreddy> > 
morthalaanilreddy> >> Hi everyone,
morthalaanilreddy> >>
morthalaanilreddy> >> I am new to opennssl and now I am completely confused. Please help me out
morthalaanilreddy> >> to solve my issue.
morthalaanilreddy> >>
morthalaanilreddy> >> I have implemented a code to sign the given CSR certificate
morthalaanilreddy> >> (certReq.pem),
morthalaanilreddy> >> then generate openssl signed Certificate (SignedCertificate.pem) using
morthalaanilreddy> >> the
morthalaanilreddy> >> details of certReq,pem. The code is like self signing, but I have added
morthalaanilreddy> >> new
morthalaanilreddy> >> functions to enter additional issuer details. Now I have two private keys
morthalaanilreddy> >> one from CA, another from CSR, one CSR (certReq.pem) and Signed
morthalaanilreddy> >> Certificate
morthalaanilreddy> >> (SignedCertificate.pem). In SignedCertificate.pem, the subject details
morthalaanilreddy> >> and
morthalaanilreddy> >> the issuer details are different. There is no problem with codes.
morthalaanilreddy> >>
morthalaanilreddy> >> The issue is:
morthalaanilreddy> >> I am unable to find out the exact command lines or c/c++ program
morthalaanilreddy> >> functions
morthalaanilreddy> >> to prove the SignedCertificate.pem is signed or not. I have spent more
morthalaanilreddy> >> than
morthalaanilreddy> >> one day on researching, but I am end up with confusion. I do not have any
morthalaanilreddy> >> digital certificate chain.
morthalaanilreddy> >>
morthalaanilreddy> >>
morthalaanilreddy> >> Could anyone kindly provide any information regarding this.
morthalaanilreddy> >>
morthalaanilreddy> >> Thanks in advance,
morthalaanilreddy> >>
morthalaanilreddy> >> --
morthalaanilreddy> >> openssl-users mailing list
morthalaanilreddy> >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
morthalaanilreddy> >>
morthalaanilreddy> >>
morthalaanilreddy> > 
morthalaanilreddy> > -- 
morthalaanilreddy> > openssl-users mailing list
morthalaanilreddy> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
morthalaanilreddy> 
morthalaanilreddy> 
morthalaanilreddy> 
morthalaanilreddy> 
morthalaanilreddy> 
morthalaanilreddy> --
morthalaanilreddy> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
morthalaanilreddy> 

From morthalaanilreddy at gmail.com  Thu May  3 09:50:43 2018
From: morthalaanilreddy at gmail.com (morthalan)
Date: Thu, 3 May 2018 02:50:43 -0700 (MST)
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <20180503.112448.1286710673559008677.levitte@openssl.org>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
 <20180503.112448.1286710673559008677.levitte@openssl.org>
Message-ID: <1525341043613-0.post@n7.nabble.com>

But In my case, I do not have any root certificate. I have only one signed
certificate (SignedCertificate.pem) and one certificate signing request
(certReq.pem) . So when I use it as below

openssl verify -CAfile SignedCertificate.pem SignedCertificate.pem

I am getting error  "error 20 at 0 depth lookup:unable to get local issuer
certificate".
I believe it is for verifying certificate chain trust. Correct me if I am
wrong. Is there anyway to manipulate it?


Richard Levitte - VMS Whacker-2 wrote
> openssl verify -CAfile your_ca_cert.pem SignedCertificate.pem
> 
> Hope that helped
> 
> Cheers,
> Richard
> 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users





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

From d3ck0r at gmail.com  Thu May  3 10:20:11 2018
From: d3ck0r at gmail.com (J Decker)
Date: Thu, 3 May 2018 03:20:11 -0700
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <1525341043613-0.post@n7.nabble.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
 <20180503.112448.1286710673559008677.levitte@openssl.org>
 <1525341043613-0.post@n7.nabble.com>
Message-ID: <CAA2GJqUuQMOUk3OEnFPBxBghYa0KJ2L32aV+xdSO_jDnGF6L6w@mail.gmail.com>

a root cert is the self signed cert.


On Thu, May 3, 2018 at 2:50 AM, morthalan <morthalaanilreddy at gmail.com>
wrote:

> But In my case, I do not have any root certificate. I have only one signed
> certificate (SignedCertificate.pem) and one certificate signing request
> (certReq.pem) . So when I use it as below
>
> openssl verify -CAfile SignedCertificate.pem SignedCertificate.pem
>
> I am getting error  "error 20 at 0 depth lookup:unable to get local issuer
> certificate".
> I believe it is for verifying certificate chain trust. Correct me if I am
> wrong. Is there anyway to manipulate it?
>
>
> Richard Levitte - VMS Whacker-2 wrote
> > openssl verify -CAfile your_ca_cert.pem SignedCertificate.pem
> >
> > Hope that helped
> >
> > Cheers,
> > Richard
> >
> > openssl-users mailing list
> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
>
>
>
> --
> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180503/73e1592f/attachment.html>

From rsalz at akamai.com  Thu May  3 11:18:48 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 3 May 2018 11:18:48 +0000
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <1525335799770-0.post@n7.nabble.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
Message-ID: <01B09B33-4BEB-49B3-8EE8-B8D9E7494EC2@akamai.com>



?On 5/3/18, 4:24 AM, "morthalan" <morthalaanilreddy at gmail.com> wrote:

    No, technically not. I am just searching for a simple method just to check a
    certificate is signed by CA or not. 
    Because. Something like signing check, I am not quite sure, I do not have
    proper knowledge on Openssl.
    

If you have a cert, and a list of CA's that you trust, look at the verify command.
 


From morthalaanilreddy at gmail.com  Thu May  3 12:26:44 2018
From: morthalaanilreddy at gmail.com (morthalan)
Date: Thu, 3 May 2018 05:26:44 -0700 (MST)
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <CAA2GJqUuQMOUk3OEnFPBxBghYa0KJ2L32aV+xdSO_jDnGF6L6w@mail.gmail.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
 <20180503.112448.1286710673559008677.levitte@openssl.org>
 <1525341043613-0.post@n7.nabble.com>
 <CAA2GJqUuQMOUk3OEnFPBxBghYa0KJ2L32aV+xdSO_jDnGF6L6w@mail.gmail.com>
Message-ID: <1525350404121-0.post@n7.nabble.com>

Sorry for the insufficient explanation on what I did.

I have implemented one c++ code(csrReq.cpp) to generate certificate signing
request(certReq.pem) along with private key(csrPkey.pem). Another c++ code
(signcode.cpp)is to read the user data from certReq.pem and generate the
Signed Certificate(SignedCertificate.pem).

Here the public key will be included in certReq.pem. So signcode.cpp will
take the public from from certReq.pem then generate  SignedCertificate.pem
using it. 

After the generation of SignedCertificate.pem. I would like to write
function to verify the SignedCertificate.pem, whether it is signed or not.

Is there any possibility to check the signature of SignedCertificate.pem.



d3x0r wrote
> a root cert is the self signed cert.
> 
> 
> On Thu, May 3, 2018 at 2:50 AM, morthalan &lt;

> morthalaanilreddy@

> &gt;
> wrote:
> 
>> But In my case, I do not have any root certificate. I have only one
>> signed
>> certificate (SignedCertificate.pem) and one certificate signing request
>> (certReq.pem) . So when I use it as below
>>
>> openssl verify -CAfile SignedCertificate.pem SignedCertificate.pem
>>
>> I am getting error  "error 20 at 0 depth lookup:unable to get local
>> issuer
>> certificate".
>> I believe it is for verifying certificate chain trust. Correct me if I am
>> wrong. Is there anyway to manipulate it?
>>
>>
>> Richard Levitte - VMS Whacker-2 wrote
>> > openssl verify -CAfile your_ca_cert.pem SignedCertificate.pem
>> >
>> > Hope that helped
>> >
>> > Cheers,
>> > Richard
>> >
>> > openssl-users mailing list
>> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>>
>>
>>
>>
>> --
>> Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users





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

From rsalz at akamai.com  Thu May  3 12:45:35 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 3 May 2018 12:45:35 +0000
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <1525350404121-0.post@n7.nabble.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
 <20180503.112448.1286710673559008677.levitte@openssl.org>
 <1525341043613-0.post@n7.nabble.com>
 <CAA2GJqUuQMOUk3OEnFPBxBghYa0KJ2L32aV+xdSO_jDnGF6L6w@mail.gmail.com>
 <1525350404121-0.post@n7.nabble.com>
Message-ID: <3AF315DC-BDBE-4B96-B884-F71E803F9357@akamai.com>

>    After the generation of SignedCertificate.pem. I would like to write
    function to verify the SignedCertificate.pem, whether it is signed or not.
  
That is still not an accurate description.  By definition, a certificate is *signed data.*  It appears as a bitstring in the X509 data structure.

Is this want you want to do?  You have a certificate, and a CA key or certificate.  You want to know if the CA's public key generated the signature that is in the certificate that you have.  Look at the X509_verify function.  You will need to take your CA cert (or key) and make a key object, but start with that first manpage and follow the references.



From felipe at felipegasper.com  Thu May  3 11:43:19 2018
From: felipe at felipegasper.com (Felipe Gasper)
Date: Thu, 3 May 2018 07:43:19 -0400
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <01B09B33-4BEB-49B3-8EE8-B8D9E7494EC2@akamai.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
 <01B09B33-4BEB-49B3-8EE8-B8D9E7494EC2@akamai.com>
Message-ID: <3FFEC0A7-0D0C-4DF9-8497-021DC4565283@felipegasper.com>

You could:

- Check subject and issuer for sameness.
- Verify the signature with the certificate?s own key. A positive verification indicates self-signed.

> On May 3, 2018, at 7:18 AM, Salz, Rich via openssl-users <openssl-users at openssl.org> wrote:
> 
> 
> 
> ?On 5/3/18, 4:24 AM, "morthalan" <morthalaanilreddy at gmail.com> wrote:
> 
>    No, technically not. I am just searching for a simple method just to check a
>    certificate is signed by CA or not. 
>    Because. Something like signing check, I am not quite sure, I do not have
>    proper knowledge on Openssl.
> 
> 
> If you have a cert, and a list of CA's that you trust, look at the verify command.
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From morthalaanilreddy at gmail.com  Thu May  3 13:02:16 2018
From: morthalaanilreddy at gmail.com (morthalan)
Date: Thu, 3 May 2018 06:02:16 -0700 (MST)
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <3AF315DC-BDBE-4B96-B884-F71E803F9357@akamai.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
 <20180503.112448.1286710673559008677.levitte@openssl.org>
 <1525341043613-0.post@n7.nabble.com>
 <CAA2GJqUuQMOUk3OEnFPBxBghYa0KJ2L32aV+xdSO_jDnGF6L6w@mail.gmail.com>
 <1525350404121-0.post@n7.nabble.com>
 <3AF315DC-BDBE-4B96-B884-F71E803F9357@akamai.com>
Message-ID: <1525352536903-0.post@n7.nabble.com>

I got two Ideas. I can verify the certificate by comparing the issuer name

char *s = X509_NAME_oneline(X509_get_subject_name(cert), NULL, 0);
char *i = X509_NAME_oneline(X509_get_issuer_name(cert), NULL, 0);
int rc = strcmp(s, i);

verifying with public key 

EVP_PKEY *caPubkey = X509_get_pubkey(signCert);
X509_REQ_verify(certreq, caPubkey);

thanks for the suggestions.





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

From Michael.Wojcik at microfocus.com  Thu May  3 13:03:23 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 3 May 2018 13:03:23 +0000
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <1525341043613-0.post@n7.nabble.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
 <CAA2GJqUisBGZzDdfkusb1cuFwjBiu7KJNtQ_VEvRRnsZxER+tw@mail.gmail.com>
 <1525335799770-0.post@n7.nabble.com>
 <20180503.112448.1286710673559008677.levitte@openssl.org>
 <1525341043613-0.post@n7.nabble.com>
Message-ID: <SN1PR18MB21123E5DA1D919CDDD8943D1F9870@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of morthalan
> Sent: Thursday, May 03, 2018 05:51
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] How to prove a Certificate is Signed or not
>
> But In my case, I do not have any root certificate. I have only one signed
> certificate (SignedCertificate.pem) and one certificate signing request
> (certReq.pem) .

To process the CSR and create the entity certificate (what you're calling the "signed certificate", which is redundant, since all certificates are signed), you have to use the CA private key.

The CA private key has a corresponding public key, which you would have generated alongside the private key.

Verifying the signature on the entity certificate requires that public key. The APIs that verify the signature receive the public key as part of the issuer certificate. You *must* have a CA certificate containing the public key that corresponds to the private key (you used to sign the entity certificate) in order to verify the signature on the entity certificate. It's not optional.

Certificate verification also examines other aspects of the certificate used by the issuer to sign the entity certificate, such as its validity dates. So that's another reason why you *must* have the issuer certificate.

But then you can't process a CSR without a CA certificate, because when you issue the entity certificate, it has to refer to the CA certificate used to issue it. So if you've generated an entity certificate, there's a corresponding issuing certificate somewhere.

I would strongly recommend you find an introduction to X.509 PKI somewhere online before proceeding. X.509 is hideously complicated and fraught with difficulties. Trying to code for it without the basic technical background will be an exercise in frustration and likely lead to errors that greatly weaken the security of your application.

--
Michael Wojcik
Distinguished Engineer, Micro Focus





From bhat.jayalakshmi at gmail.com  Thu May  3 14:09:33 2018
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Thu, 3 May 2018 19:39:33 +0530
Subject: [openssl-users] Building FIP enabled OpenSSL fails in Yocto-ARM
	build
Message-ID: <CALq8RvJ++ZCtq8RfGfZbicDxxMkMKSYEzTUnq2hO8ESTSqoe-Q@mail.gmail.com>

Hi All,

I am building FIPS supported OpenSSL in yocto for ARM architecture. I tried
using openssl-fips-2.0.13 and openssl-fips-2.0.4


I am building FIPS externally with the below environmental  settings
------------------------ ------------------------ ------------------------
------------------------ ------------------------
PATH=/yocto/gcc/gcc-linaro-4.9-2016.02-x86_64_arm-linux-gnueabihf/bin:$PATH

export PATH
export FIPS_SIG=/yocto/openssl-fips-2.0.4/util/incore
export MACHINE=armv71
export RELEASE=4.9.13
export SYSTEM=Linux
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-
export HOSTCC=gcc
export FIPSDIR=/yocto/meta/recipes-connectivity/openssl/fips2.0

Build commands for FIPS library

./config -mfloat-abi=hard
make
make install
------------------------

Then I am building OpenSSL 1.0.2h with the below environment settings

export FIPSDIR="/yocto/meta/recipes-connectivity/openssl/fips2.0"
export FIPSLIBDIR="/yocto/meta/recipes-connectivity/openssl/fips2.0/lib/"
export
FIPS_SIG="/yocto/meta/recipes-connectivity/openssl/fips2.0/bin/incore"

Build command to build OpenSSL.

perl ./Configure ${EXTRA_OECONF} fips shared --with-fipsdir=${FIPSDIR}
--prefix=$useprefix --openssldir=${libdir}/ssl --libdir=`basename
${libdir}` $target

Build is successful. without any error.  But when I try executing

export OPENSSL_FIPS=1
openssl -v

I am getting

3069334736:error:2D06B06F:FIPS
routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:244

I am not understand what could be going wrong. Any help is appreciated

Regards
Jayalakshmi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180503/33df9cdf/attachment-0001.html>

From openssl-users at dukhovni.org  Thu May  3 15:11:23 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 3 May 2018 11:11:23 -0400
Subject: [openssl-users] How to prove a Certificate is Signed or not
In-Reply-To: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
References: <CAPvigMJ+cBOPnwg3RoYFr6yxRrzxHu8Su9X51X-+sCBO4V5VHw@mail.gmail.com>
Message-ID: <63C0F220-1730-4D57-876B-15F65F45050E@dukhovni.org>



> On May 3, 2018, at 3:06 AM, Anil kumar Reddy <morthalaanilreddy at gmail.com> wrote:
> 
> The issue is:
> I am unable to find out the exact command lines or c/c++ program functions to prove the SignedCertificate.pem is signed or not. I have spent more than one day on researching, but I am end up with confusion. I do not have any digital certificate chain. 

To verify the signature on a single certificate using a known issuer
public key you call:

	X509_verify(X509 *cert, EVP_PKEY *pkey)

with return values <= 0 indicating failure.  To verify a certificate
chain against a set of trust anchors you call:

	X509_verify_cert(X509_STORE_CTX *ctx)

where "ctx" is populated with the certificate chain, trust anchors,
CRLs, verification parameters, including some types of subject names
to check...  This is what most applications use to check that something
is signed by a trusted certificate with the right identity and purpose.

-- 
	Viktor.


From bhat.jayalakshmi at gmail.com  Thu May  3 15:25:39 2018
From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat)
Date: Thu, 3 May 2018 20:55:39 +0530
Subject: [openssl-users] Building FIP enabled OpenSSL fails in Yocto-ARM
	build
In-Reply-To: <CALq8RvJ++ZCtq8RfGfZbicDxxMkMKSYEzTUnq2hO8ESTSqoe-Q@mail.gmail.com>
References: <CALq8RvJ++ZCtq8RfGfZbicDxxMkMKSYEzTUnq2hO8ESTSqoe-Q@mail.gmail.com>
Message-ID: <CALq8RvJQj-rY0NU4586ckpCgdpw=G5ALgqNTgMmDhXLLs22=Vg@mail.gmail.com>

Hi All,

In addition to the my previous mail, this is additional info

objdump -t libcrypto.so.1.0.0 | grep FIPS_signature
001ad8b0 l     O .data  00000014              FIPS_signature

readelf -a libcrypto.so.1.0.0 | grep FIPS_signature
11812: 001ad8b0    20 OBJECT  LOCAL  DEFAULT   23 FIPS_signature


Regards
Jayalakshmi

On Thu, May 3, 2018 at 7:39 PM, Jayalakshmi bhat <bhat.jayalakshmi at gmail.com
> wrote:

> Hi All,
>
> I am building FIPS supported OpenSSL in yocto for ARM architecture. I
> tried using openssl-fips-2.0.13 and openssl-fips-2.0.4
>
>
> I am building FIPS externally with the below environmental  settings
> ------------------------ ------------------------ ------------------------
> ------------------------ ------------------------
> PATH=/yocto/gcc/gcc-linaro-4.9-2016.02-x86_64_arm-linux-
> gnueabihf/bin:$PATH
>
> export PATH
> export FIPS_SIG=/yocto/openssl-fips-2.0.4/util/incore
> export MACHINE=armv71
> export RELEASE=4.9.13
> export SYSTEM=Linux
> export ARCH=arm
> export CROSS_COMPILE=arm-linux-gnueabihf-
> export HOSTCC=gcc
> export FIPSDIR=/yocto/meta/recipes-connectivity/openssl/fips2.0
>
> Build commands for FIPS library
>
> ./config -mfloat-abi=hard
> make
> make install
> ------------------------
>
> Then I am building OpenSSL 1.0.2h with the below environment settings
>
> export FIPSDIR="/yocto/meta/recipes-connectivity/openssl/fips2.0"
> export FIPSLIBDIR="/yocto/meta/recipes-connectivity/openssl/fips2.0/lib/"
> export FIPS_SIG="/yocto/meta/recipes-connectivity/openssl/fips2.0/
> bin/incore"
>
> Build command to build OpenSSL.
>
> perl ./Configure ${EXTRA_OECONF} fips shared --with-fipsdir=${FIPSDIR}
> --prefix=$useprefix --openssldir=${libdir}/ssl --libdir=`basename
> ${libdir}` $target
>
> Build is successful. without any error.  But when I try executing
>
> export OPENSSL_FIPS=1
> openssl -v
>
> I am getting
>
> 3069334736:error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint
> does not match:fips.c:244
>
> I am not understand what could be going wrong. Any help is appreciated
>
> Regards
> Jayalakshmi
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180503/13b308d7/attachment.html>

From jzburda at gmail.com  Fri May  4 00:16:21 2018
From: jzburda at gmail.com (Lunessia)
Date: Thu, 3 May 2018 19:16:21 -0500
Subject: [openssl-users] Unable to install OpenSSL
Message-ID: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>

Hello everyone,
I've been having various troubles with installing and compiling OpenSSL.
I started with 1.1.1-pre6, and my Perl client will tell me that I don't
have NASM even if I have it installed (If I use VC-WIN64A) or output "If
you want to report a building issue, please include the output from this
command: Perl configdata.pl <http://configdata.pm> --dump" when I use
VC-WIN64I
With 1.0.2o, Perl compiles the program, but however, I can't use Dmake to
compile it, as Dmake will state:

"dmake.exe:  makefile:  line 275:  Warning: -- Found non-white space
character after '[' in [@[ -n "$(THIS)" ] && $(CLEARENV) && $(MAKE) $(THIS)
-e $(BUILDENV)].
dmake.exe:  makefile:  line 307:  Warning: -- Found non-white space
character after '[' in [[ -z "$(FIPSCANLIB)" ] || $(CC) $(CFLAG) -Iinclude \
                -DFINGERPRINT_PREMAIN_DSO_LOAD -o $@  \
                $(FIPSLIBDIR)fips_premain.c $(FIPSLIBDIR)fipscanister.o \
                libcrypto.a $(EX_LIBS)].
dmake.exe:  makefile:  line 307:  Error: -- New group recipe begin found
within group recipe."

Here are my programs:
A make implementation: Dmake from Perl
Perl 5 with core modules: ActivePerl 5.22.4.2205 with text::template
installed
ANSI C Compiler: MinGW from Perl
A development environment in the form of in the form of development
libraries and C header files: (I'm guessing) Visual Studio 2017 (I can't
use Nmake with it for some reason)
Netwide Assembler: NASM 2.13.03
Operating system: Windows 10 x64

Some of these were found either by the .exe version or by the installer
version.
Also attached is the configdata.pl dump. The makefile has not updated, so I
will not include that unless asked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180503/a91ce273/attachment-0001.html>
-------------- next part --------------
Command line (with current working directory = .):

    C:\Perl64\bin\perl.exe Configure VC-WIN64I

Perl information:

    C:\Perl64\bin\perl.exe
    5.22.4 for MSWin32-x64-multi-thread

Enabled features:

    aria
    asm
    async
    autoalginit
    autoerrinit
    autoload-config
    bf
    blake2
    camellia
    capieng
    cast
    chacha
    cmac
    cms
    comp
    ct
    deprecated
    des
    dgram
    dh
    dsa
    dso
    dtls
    dynamic-engine
    ec
    ec2m
    ecdh
    ecdsa
    engine
    err
    filenames
    gost
    hw(-.+)?
    idea
    makedepend
    md4
    mdc2
    multiblock
    nextprotoneg
    ocb
    ocsp
    pic
    poly1305
    posix-io
    psk
    rc2
    rc4
    rdrand
    rfc3779
    rmd160
    scrypt
    seed
    shared
    siphash
    sm2
    sm3
    sm4
    sock
    srp
    srtp
    sse2
    ssl
    static-engine
    stdio
    tests
    threads
    tls
    ts
    ui-console
    whirlpool
    tls1
    tls1-method
    tls1_1
    tls1_1-method
    tls1_2
    tls1_2-method
    tls1_3
    dtls1
    dtls1-method
    dtls1_2
    dtls1_2-method

Disabled features:

    afalgeng                [not-linux]
    asan                    [default]   OPENSSL_NO_ASAN
    crypto-mdebug           [default]   OPENSSL_NO_CRYPTO_MDEBUG
    crypto-mdebug-backtrace [default]   OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE
    devcryptoeng            [default]   OPENSSL_NO_DEVCRYPTOENG
    ec_nistp_64_gcc_128     [default]   OPENSSL_NO_EC_NISTP_64_GCC_128
    egd                     [default]   OPENSSL_NO_EGD
    external-tests          [default]   OPENSSL_NO_EXTERNAL_TESTS
    fuzz-libfuzzer          [default]   OPENSSL_NO_FUZZ_LIBFUZZER
    fuzz-afl                [default]   OPENSSL_NO_FUZZ_AFL
    heartbeats              [default]   OPENSSL_NO_HEARTBEATS
    md2                     [default]   OPENSSL_NO_MD2 (skip crypto\md2)
    msan                    [default]   OPENSSL_NO_MSAN
    rc5                     [default]   OPENSSL_NO_RC5 (skip crypto\rc5)
    sctp                    [default]   OPENSSL_NO_SCTP
    ssl-trace               [default]   OPENSSL_NO_SSL_TRACE
    tls13downgrade          [default]   OPENSSL_NO_TLS13DOWNGRADE
    ubsan                   [default]   OPENSSL_NO_UBSAN
    unit-test               [default]   OPENSSL_NO_UNIT_TEST
    weak-ssl-ciphers        [default]   OPENSSL_NO_WEAK_SSL_CIPHERS
    zlib                    [default]
    zlib-dynamic            [default]
    ssl3                    [default]   OPENSSL_NO_SSL3
    ssl3-method             [default]   OPENSSL_NO_SSL3_METHOD

Config target attributes:

    AR => "lib",
    ARFLAGS => "/nologo",
    AS => "ias",
    ASFLAGS => "-d debug",
    CC => "cl",
    CFLAGS => "/W3 /wd4090 /nologo /O2",
    CPP => "\$(CC) /EP /C",
    HASHBANGPERL => "/usr/bin/env perl",
    LD => "link",
    LDFLAGS => "/nologo /debug",
    MT => "mt",
    MTFLAGS => "-nologo",
    RANLIB => "CODE(0x4bcc078)",
    RC => "rc",
    aes_asm_src => "aes_core.c aes_cbc.c aes-ia64.s",
    aes_obj => "aes_core.o aes_cbc.o aes-ia64.o",
    apps_aux_src => "win32_init.c",
    apps_init_src => "../ms/applink.c",
    apps_obj => "win32_init.o",
    aroutflag => "/out:",
    asoutflag => "-o ",
    bf_asm_src => "bf_enc.c",
    bf_obj => "bf_enc.o",
    bin_cflags => "/Zi /Fdapp.pdb",
    bin_lflags => "/subsystem:console /opt:ref",
    bn_asm_src => "bn_asm.c ia64-mont.s",
    bn_obj => "bn_asm.o ia64-mont.o",
    bn_ops => "EXPORT_VAR_AS_FN SIXTY_FOUR_BIT",
    build_file => "makefile",
    build_scheme => [ "unified", "windows", "VC-common" ],
    cast_asm_src => "c_enc.c",
    cast_obj => "c_enc.o",
    cflags => "/Gs0 /GF /Gy /MD",
    chacha_asm_src => "chacha_enc.c",
    chacha_obj => "chacha_enc.o",
    cmll_asm_src => "camellia.c cmll_misc.c cmll_cbc.c",
    cmll_obj => "camellia.o cmll_misc.o cmll_cbc.o",
    coutflag => "/Fo",
    cppflags => "",
    cpuid_asm_src => "ia64cpuid.s",
    cpuid_obj => "ia64cpuid.o",
    defines => [ "OPENSSL_SYS_WIN32", "WIN32_LEAN_AND_MEAN", "UNICODE", "_UNICODE", "_CRT_SECURE_NO_DEPRECATE", "_WINSOCK_DEPRECATED_NO_WARNINGS", "OPENSSL_USE_APPLINK" ],
    des_asm_src => "des_enc.c fcrypt_b.c",
    des_obj => "des_enc.o fcrypt_b.o",
    disable => [  ],
    dso_cflags => "/Zi /Fddso.pdb",
    dso_extension => "",
    dso_scheme => "win32",
    ec_asm_src => "",
    ec_obj => "",
    enable => [  ],
    ex_libs => "ws2_32.lib gdi32.lib advapi32.lib crypt32.lib user32.lib",
    exe_extension => "",
    includes => [  ],
    keccak1600_asm_src => "keccak1600.c",
    keccak1600_obj => "keccak1600.o",
    ldoutflag => "/out:",
    lflags => "",
    lib_cflags => "/Zi /Fdossl_static.pdb",
    lib_cppflags => "",
    lib_defines => [ "L_ENDIAN" ],
    md5_asm_src => "",
    md5_obj => "",
    modes_asm_src => "ghash-ia64.s",
    modes_obj => "ghash-ia64.o",
    module_cflags => "",
    module_cxxflags => "",
    module_ldflags => "/dll",
    mtinflag => "-manifest ",
    mtoutflag => "-outputresource:",
    multilib => "-ia64",
    padlock_asm_src => "",
    padlock_obj => "",
    perlasm_scheme => "ias",
    poly1305_asm_src => "",
    poly1305_obj => "",
    rc4_asm_src => "rc4_enc.c rc4_skey.c",
    rc4_obj => "rc4_enc.o rc4_skey.o",
    rc5_asm_src => "rc5_enc.c",
    rc5_obj => "rc5_enc.o",
    rcoutflag => "/fo",
    rmd160_asm_src => "",
    rmd160_obj => "",
    sha1_asm_src => "sha1-ia64.s sha256-ia64.s sha512-ia64.s",
    sha1_obj => "sha1-ia64.o sha256-ia64.o sha512-ia64.o",
    shared_cflag => "",
    shared_defines => [  ],
    shared_extension => "",
    shared_extension_simple => "",
    shared_ldflag => "/dll",
    shared_rcflag => "",
    shared_target => "win-shared",
    sys_id => "WIN64I",
    thread_defines => [  ],
    thread_scheme => "winthreads",
    unistd => "<unistd.h>",
    uplink_aux_src => "../ms/uplink.c uplink-ia64.s",
    uplink_obj => "../ms/uplink.o uplink-ia64.o",
    wp_asm_src => "wp_block.c",
    wp_obj => "wp_block.o",

Recorded environment:

    AR =
    ARFLAGS =
    AS =
    ASFLAGS =
    BUILDFILE =
    CC =
    CFLAGS =
    CPP =
    CPPDEFINES =
    CPPFLAGS =
    CPPINCLUDES =
    CROSS_COMPILE =
    CXX =
    CXXFLAGS =
    HASHBANGPERL =
    LD =
    LDFLAGS =
    LDLIBS =
    MT =
    MTFLAGS =
    OPENSSL_LOCAL_CONFIG_DIR =
    PERL =
    RANLIB =
    RC =
    RCFLAGS =
    RM =
    WINDRES =
    __CNF_CFLAGS =
    __CNF_CPPDEFINES =
    __CNF_CPPFLAGS =
    __CNF_CPPINCLUDES =
    __CNF_CXXFLAGS =
    __CNF_LDFLAGS =
    __CNF_LDLIBS =

Makevars:

    AR              = lib
    ARFLAGS         = /nologo
    AS              = ias
    ASFLAGS         = -d debug
    CC              = cl
    CFLAGS          = /W3 /wd4090 /nologo /O2
    CPP             = $(CC) /EP /C
    CPPDEFINES      =
    CPPFLAGS        =
    CPPINCLUDES     =
    CXXFLAGS        =
    HASHBANGPERL    = /usr/bin/env perl
    LD              = link
    LDFLAGS         = /nologo /debug
    LDLIBS          =
    MT              = mt
    MTFLAGS         = -nologo
    RC              = rc

NOTE: These variables only represent the configuration view.  The build file
template may have processed these variables further, please have a look at the
build file for more exact data:
    makefile

build file:

    makefile

build file templates:

    Configurations\common0.tmpl
    Configurations\windows-makefile.tmpl
    Configurations\common.tmpl

From jb-openssl at wisemo.com  Fri May  4 00:56:36 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Fri, 4 May 2018 02:56:36 +0200
Subject: [openssl-users] Unable to install OpenSSL
In-Reply-To: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
References: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
Message-ID: <ca6bd762-9f02-73f7-843d-f9c8ee663a43@wisemo.com>

On 04/05/2018 02:16, Lunessia wrote:
> Hello everyone,
> I've been having various troubles with installing and compiling OpenSSL.
> I started with 1.1.1-pre6, and my Perl client will tell me that I 
> don't have NASM even if I have it installed (If I use VC-WIN64A) or 
> output "If you want to report a building issue, please include the 
> output from this command: Perl configdata.pl <http://configdata.pm> 
> --dump" when I use VC-WIN64I
> With 1.0.2o, Perl compiles the program, but however, I can't use Dmake 
> to compile it, as Dmake will state:
>
Please note that VC-WIN64I is for Itanium processors (supported only
on Windows Server 2008 and 2008 R2, with some historic support on old
versions of Windows Server 2003 and Windows XP).

Enjoy

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


From jzburda at gmail.com  Fri May  4 22:55:13 2018
From: jzburda at gmail.com (Lunessia)
Date: Fri, 4 May 2018 17:55:13 -0500
Subject: [openssl-users] Unable to install OpenSSL
In-Reply-To: <ca6bd762-9f02-73f7-843d-f9c8ee663a43@wisemo.com>
References: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
 <ca6bd762-9f02-73f7-843d-f9c8ee663a43@wisemo.com>
Message-ID: <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA@mail.gmail.com>

Thanks for the reply. If I sidestep VC-WIN64A with No-ASM, I'll get the
same "If you want to report a building issue" error

On Thu, May 3, 2018 at 7:56 PM, Jakob Bohm <jb-openssl at wisemo.com> wrote:

> On 04/05/2018 02:16, Lunessia wrote:
>
>> Hello everyone,
>> I've been having various troubles with installing and compiling OpenSSL.
>> I started with 1.1.1-pre6, and my Perl client will tell me that I don't
>> have NASM even if I have it installed (If I use VC-WIN64A) or output "If
>> you want to report a building issue, please include the output from this
>> command: Perl configdata.pl <http://configdata.pm> --dump" when I use
>> VC-WIN64I
>> With 1.0.2o, Perl compiles the program, but however, I can't use Dmake to
>> compile it, as Dmake will state:
>>
>> Please note that VC-WIN64I is for Itanium processors (supported only
> on Windows Server 2008 and 2008 R2, with some historic support on old
> versions of Windows Server 2003 and Windows XP).
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 S?borg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180504/75024eba/attachment.html>

From jeremy.farrell at oracle.com  Sat May  5 18:29:28 2018
From: jeremy.farrell at oracle.com (Jeremy Farrell)
Date: Sat, 5 May 2018 19:29:28 +0100
Subject: [openssl-users] Unable to install OpenSSL
In-Reply-To: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
References: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
Message-ID: <864e7c07-540a-f7d2-b76f-bd919a814f9f@oracle.com>

On 04/05/2018 01:16, Lunessia wrote:
> I've been having various troubles with installing and compiling OpenSSL.
> I started with 1.1.1-pre6, and my Perl client will tell me that I 
> don't have NASM even if I have it installed (If I use VC-WIN64A)

Is NASM on your execution path? If not, try with it added to the path.

> or output "If you want to report a building issue, please include the 
> output from this command: Perl configdata.pl <http://configdata.pm> 
> --dump" when I use VC-WIN64I

As others have pointed out, that would configure to build for Itanium 
which you don't want to do - VC-WIN64A is the one you want for x64.

> With 1.0.2o, Perl compiles the program, but however, I can't use Dmake 
> to compile it, as Dmake will state:
>
> "dmake.exe:? makefile:? line 275:? Warning: -- Found non-white space 
> character after '[' in [@[ -n "$(THIS)" ] && $(CLEARENV) && $(MAKE) 
> $(THIS) -e $(BUILDENV)].
> dmake.exe:? makefile:? line 307:? Warning: -- Found non-white space 
> character after '[' in [[ -z "$(FIPSCANLIB)" ] || $(CC) $(CFLAG) 
> -Iinclude \
> ??????????????? -DFINGERPRINT_PREMAIN_DSO_LOAD -o $@? \
> ??????????????? $(FIPSLIBDIR)fips_premain.c $(FIPSLIBDIR)fipscanister.o \
> ??????????????? libcrypto.a $(EX_LIBS)].
> dmake.exe:? makefile:? line 307:? Error: -- New group recipe begin 
> found within group recipe."

I don't know anything about dmake, but this suggests it's not close 
enough to the expected version of make. I wouldn't be surprised if the 
VC builds effectively require nmake - they're certainly more likely to 
work with nmake.

> Here are my programs:
> A make implementation: Dmake from Perl
> Perl 5 with core modules: ActivePerl 5.22.4.2205 with text::template 
> installed
> ANSI C Compiler: MinGW from Perl
> A development environment in the form of in the form of development 
> libraries and C header files: (I'm guessing) Visual Studio 2017 (I 
> can't use Nmake with it for some reason)
> Netwide Assembler: NASM 2.13.03
> Operating system: Windows 10 x64

I'd find out what's stopping nmake working and fix it; then try with 
NASM on the path, configure with VC-WIN64A, and build with nmake.

Regards,
 ????????????????????????? jjf

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

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

From digant.kubavat at gmail.com  Sun May  6 08:11:46 2018
From: digant.kubavat at gmail.com (Devang Kubavat)
Date: Sun, 6 May 2018 13:41:46 +0530
Subject: [openssl-users] disable session id reuse
In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A41FE1B@AZ-FFEXMB03.global.avaya.com>
References: <25D2EC755404B4409F263AC6D050FEBB2A41FE1B@AZ-FFEXMB03.global.avaya.com>
Message-ID: <B33E763A-9EF2-4E45-AD3E-4E410BC67A50@gmail.com>

Hi Darshan, 

In Addition, Make sure that you should disable the session ticket based session resumption using SSL_OP_NO_TICKET. 

By default SSL_OP_NO_TICKET is not disabled. 

Thanks
Devang
Sent from my iPhone

> On 03-May-2018, at 2:12 PM, Mody, Darshan (Darshan) <darshanmody at avaya.com> wrote:
> 
> Hi,
>  
> While doing a openssl s_time command I find that by default it tries for Session Id Reuse. ?Now timing with session id reuse.?
>  
> In case if we don?t want openssl to reuse session id?s how can we configure openssl in the application for the same.
>  
> The application here is acting as a server.
>  
> I have set  SSL_CTX_set_session_cache_mode to SSL_SESS_CACHE_OFF
>  
> Thanks
> Darshan
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180506/57a56724/attachment-0001.html>

From levitte at openssl.org  Sun May  6 08:17:45 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 06 May 2018 10:17:45 +0200 (CEST)
Subject: [openssl-users] Unable to install OpenSSL
In-Reply-To: <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA@mail.gmail.com>
References: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
 <ca6bd762-9f02-73f7-843d-f9c8ee663a43@wisemo.com>
 <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA@mail.gmail.com>
Message-ID: <20180506.101745.1782907238858002272.levitte@openssl.org>

In message <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA at mail.gmail.com> on Fri, 4 May 2018 17:55:13 -0500, Lunessia <jzburda at gmail.com> said:

jzburda> Thanks for the reply. If I sidestep VC-WIN64A with No-ASM,
jzburda> I'll get the same "If you want to report a building issue" error

You mean this?

    **********************************************************************
    ***                                                                ***
    ***   If you want to report a building issue, please include the   ***
    ***   output from this command:                                    ***
    ***                                                                ***
    ***     perl configdata.pm --dump                                  ***
    ***                                                                ***
    **********************************************************************

That's not an error, it's simply a boxed message.  It's made prominent
so no one will miss it (people do miss such message, you'd be
surprised)

Cheers,
Richard

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

From darshanmody at avaya.com  Sun May  6 13:57:44 2018
From: darshanmody at avaya.com (Mody, Darshan (Darshan))
Date: Sun, 6 May 2018 13:57:44 +0000
Subject: [openssl-users] disable session id reuse
In-Reply-To: <B33E763A-9EF2-4E45-AD3E-4E410BC67A50@gmail.com>
References: <25D2EC755404B4409F263AC6D050FEBB2A41FE1B@AZ-FFEXMB03.global.avaya.com>
 <B33E763A-9EF2-4E45-AD3E-4E410BC67A50@gmail.com>
Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A431091@AZ-FFEXMB03.global.avaya.com>

Hi

We do set SSL_CTX_set_options(ctx, SSL_OP_NO_TICKET); while initializing Context

Thanks
Darshan

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Devang Kubavat
Sent: Sunday, May 6, 2018 1:42 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] disable session id reuse

Hi Darshan,

In Addition, Make sure that you should disable the session ticket based session resumption using SSL_OP_NO_TICKET.

By default SSL_OP_NO_TICKET is not disabled.

Thanks
Devang
Sent from my iPhone

On 03-May-2018, at 2:12 PM, Mody, Darshan (Darshan) <darshanmody at avaya.com<mailto:darshanmody at avaya.com>> wrote:
Hi,

While doing a openssl s_time command I find that by default it tries for Session Id Reuse. ?Now timing with session id reuse.?

In case if we don?t want openssl to reuse session id?s how can we configure openssl in the application for the same.

The application here is acting as a server.

I have set  SSL_CTX_set_session_cache_mode to SSL_SESS_CACHE_OFF

Thanks
Darshan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=6EwdsImPOhlHS6cQdur-UNtSfmU8P5PrY6_Yr_tCo2U&s=SJPsG8EXG55k4n7fzDiMayd1OUlyHCWP2JzifuoOKg0&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180506/402323f6/attachment.html>

From jzburda at gmail.com  Mon May  7 03:16:57 2018
From: jzburda at gmail.com (Lunessia)
Date: Sun, 6 May 2018 22:16:57 -0500
Subject: [openssl-users] Unable to install OpenSSL
In-Reply-To: <20180506.101745.1782907238858002272.levitte@openssl.org>
References: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
 <ca6bd762-9f02-73f7-843d-f9c8ee663a43@wisemo.com>
 <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA@mail.gmail.com>
 <20180506.101745.1782907238858002272.levitte@openssl.org>
Message-ID: <CAMq1nJQnQcK89U9-u3kr3BG=utMga+-3Wf-t_32fh-ej9u2yOw@mail.gmail.com>

 Jeremy Farrell> Is NASM on your execution path? If not, try with it added
to the path.

I tried added NASM to both my system and user paths, and it'll still throw
that error

I just realized it did make a make file. However, now I get this (this was
done by sidestepping NASM)
"        rc /folibcrypto.res "libcrypto.rc"
'rc' is not recognized as an internal or external command,
operable program or batch file.
NMAKE : fatal error U1077: 'rc' : return code '0x1'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
14.0\VC\BIN\nmake.exe"' : return code '0x2'
Stop."

On Sun, May 6, 2018 at 3:17 AM, Richard Levitte <levitte at openssl.org> wrote:

> In message <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA@
> mail.gmail.com> on Fri, 4 May 2018 17:55:13 -0500, Lunessia <
> jzburda at gmail.com> said:
>
> jzburda> Thanks for the reply. If I sidestep VC-WIN64A with No-ASM,
> jzburda> I'll get the same "If you want to report a building issue" error
>
> You mean this?
>
>     **********************************************************************
>     ***                                                                ***
>     ***   If you want to report a building issue, please include the   ***
>     ***   output from this command:                                    ***
>     ***                                                                ***
>     ***     perl configdata.pm --dump                                  ***
>     ***                                                                ***
>     **********************************************************************
>
> That's not an error, it's simply a boxed message.  It's made prominent
> so no one will miss it (people do miss such message, you'd be
> surprised)
>
> Cheers,
> Richard
>
> --
> Richard Levitte         levitte at openssl.org
> OpenSSL Project         http://www.openssl.org/~levitte/
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180506/7f947d7c/attachment.html>

From jzburda at gmail.com  Mon May  7 03:27:51 2018
From: jzburda at gmail.com (Lunessia)
Date: Sun, 6 May 2018 22:27:51 -0500
Subject: [openssl-users] Unable to install OpenSSL
In-Reply-To: <CAMq1nJQnQcK89U9-u3kr3BG=utMga+-3Wf-t_32fh-ej9u2yOw@mail.gmail.com>
References: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
 <ca6bd762-9f02-73f7-843d-f9c8ee663a43@wisemo.com>
 <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA@mail.gmail.com>
 <20180506.101745.1782907238858002272.levitte@openssl.org>
 <CAMq1nJQnQcK89U9-u3kr3BG=utMga+-3Wf-t_32fh-ej9u2yOw@mail.gmail.com>
Message-ID: <CAMq1nJSNtZ19xe8Jb8Ka2gP11jzoKwPCOf2Ya+c5+Ca0qVuMkQ@mail.gmail.com>

I figured out the NASM part. I added the EXE at first. Now the entire
folder is targeted.

On Sun, May 6, 2018 at 10:16 PM, Lunessia <jzburda at gmail.com> wrote:

> Jeremy Farrell> Is NASM on your execution path? If not, try with it added
> to the path.
>
> I tried added NASM to both my system and user paths, and it'll still throw
> that error
>
> I just realized it did make a make file. However, now I get this (this was
> done by sidestepping NASM)
> "        rc /folibcrypto.res "libcrypto.rc"
> 'rc' is not recognized as an internal or external command,
> operable program or batch file.
> NMAKE : fatal error U1077: 'rc' : return code '0x1'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
> Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
> Stop."
>
> On Sun, May 6, 2018 at 3:17 AM, Richard Levitte <levitte at openssl.org>
> wrote:
>
>> In message <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA at mail.
>> gmail.com> on Fri, 4 May 2018 17:55:13 -0500, Lunessia <jzburda at gmail.com>
>> said:
>>
>> jzburda> Thanks for the reply. If I sidestep VC-WIN64A with No-ASM,
>> jzburda> I'll get the same "If you want to report a building issue" error
>>
>> You mean this?
>>
>>     ************************************************************
>> **********
>>     ***                                                                ***
>>     ***   If you want to report a building issue, please include the   ***
>>     ***   output from this command:                                    ***
>>     ***                                                                ***
>>     ***     perl configdata.pm --dump
>> ***
>>     ***                                                                ***
>>     ************************************************************
>> **********
>>
>> That's not an error, it's simply a boxed message.  It's made prominent
>> so no one will miss it (people do miss such message, you'd be
>> surprised)
>>
>> Cheers,
>> Richard
>>
>> --
>> Richard Levitte         levitte at openssl.org
>> OpenSSL Project         http://www.openssl.org/~levitte/
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180506/2163ad5a/attachment-0001.html>

From jzburda at gmail.com  Mon May  7 04:04:17 2018
From: jzburda at gmail.com (Lunessia)
Date: Sun, 6 May 2018 23:04:17 -0500
Subject: [openssl-users] Unable to install OpenSSL
In-Reply-To: <CAMq1nJSNtZ19xe8Jb8Ka2gP11jzoKwPCOf2Ya+c5+Ca0qVuMkQ@mail.gmail.com>
References: <CAMq1nJRsV3QgP8vDaMB1qE1Mm3mqBV_kxrRp3U+wu7+o1VbNAQ@mail.gmail.com>
 <ca6bd762-9f02-73f7-843d-f9c8ee663a43@wisemo.com>
 <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA@mail.gmail.com>
 <20180506.101745.1782907238858002272.levitte@openssl.org>
 <CAMq1nJQnQcK89U9-u3kr3BG=utMga+-3Wf-t_32fh-ej9u2yOw@mail.gmail.com>
 <CAMq1nJSNtZ19xe8Jb8Ka2gP11jzoKwPCOf2Ya+c5+Ca0qVuMkQ@mail.gmail.com>
Message-ID: <CAMq1nJSwA08YqMuZ_9piAEOtaHsh2zxZZV27aG+fD1-3A1ZvNw@mail.gmail.com>

I also solved the RC issue by installing Windows 10 SDK tools and taking
the x64 bit architecture folder that contains RC and injecting that into my
system path too. I'll send a final message when the make completes, but I
have a feeling this issue is closed!

On Sun, May 6, 2018 at 10:27 PM, Lunessia <jzburda at gmail.com> wrote:

> I figured out the NASM part. I added the EXE at first. Now the entire
> folder is targeted.
>
> On Sun, May 6, 2018 at 10:16 PM, Lunessia <jzburda at gmail.com> wrote:
>
>> Jeremy Farrell> Is NASM on your execution path? If not, try with it
>> added to the path.
>>
>> I tried added NASM to both my system and user paths, and it'll still
>> throw that error
>>
>> I just realized it did make a make file. However, now I get this (this
>> was done by sidestepping NASM)
>> "        rc /folibcrypto.res "libcrypto.rc"
>> 'rc' is not recognized as an internal or external command,
>> operable program or batch file.
>> NMAKE : fatal error U1077: 'rc' : return code '0x1'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
>> Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2'
>> Stop."
>>
>> On Sun, May 6, 2018 at 3:17 AM, Richard Levitte <levitte at openssl.org>
>> wrote:
>>
>>> In message <CAMq1nJRCGqt9jSrKupXen5-LuJmjHzFfp8FM9Phyu61nKa92RA at mail.gm
>>> ail.com> on Fri, 4 May 2018 17:55:13 -0500, Lunessia <jzburda at gmail.com>
>>> said:
>>>
>>> jzburda> Thanks for the reply. If I sidestep VC-WIN64A with No-ASM,
>>> jzburda> I'll get the same "If you want to report a building issue" error
>>>
>>> You mean this?
>>>
>>>     ************************************************************
>>> **********
>>>     ***
>>> ***
>>>     ***   If you want to report a building issue, please include the
>>>  ***
>>>     ***   output from this command:
>>> ***
>>>     ***
>>> ***
>>>     ***     perl configdata.pm --dump
>>> ***
>>>     ***
>>> ***
>>>     ************************************************************
>>> **********
>>>
>>> That's not an error, it's simply a boxed message.  It's made prominent
>>> so no one will miss it (people do miss such message, you'd be
>>> surprised)
>>>
>>> Cheers,
>>> Richard
>>>
>>> --
>>> Richard Levitte         levitte at openssl.org
>>> OpenSSL Project         http://www.openssl.org/~levitte/
>>> --
>>> openssl-users mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180506/015ae6d5/attachment.html>

From raghuasit at gmail.com  Wed May  9 07:51:52 2018
From: raghuasit at gmail.com (Raghavendra a)
Date: Wed, 9 May 2018 13:21:52 +0530
Subject: [openssl-users] freeing of X509_CRL object.
In-Reply-To: <CAGfGnO+OWWsPV+1Ers_raC2gvea8DpBxQDp9WuuhJKueP6QqSw@mail.gmail.com>
References: <CAGfGnO+OWWsPV+1Ers_raC2gvea8DpBxQDp9WuuhJKueP6QqSw@mail.gmail.com>
Message-ID: <CAGfGnOJN2VX9-N-KoKLY=W+3+aHaK8khmhpMEiraxe0mpoofvw@mail.gmail.com>

Someone please answer below query.

On Mon, May 7, 2018 at 2:12 PM, Raghavendra a <raghuasit at gmail.com> wrote:

> Hi,
>
> I my program , converting X509_CRL object to string format using
> *X509_CRL_print* and BIO_get_mem_data. After that if i use*
> X509_CRL_free(_x509crl) *it is crashing below reason
>
> *.*
>
>
>
>
>
>
>
> *Valgrind output:==31919== Invalid read of size 4==31919==    at
> 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155)==31919==    by
> 0xB355537: asn1_do_lock (tasn_utl.c:79)==31919==    by 0xB352767:
> asn1_item_embed_free (tasn_fre.c:88)==31919==    by 0xB3528D4:
> ASN1_item_free (tasn_fre.c:20)*
> not sure if *X509_CRL_print *using nested pointers of *x509_CRL object*
> and freeing them, external freeing of X509_CRL again leading to double free?
> Please help on this issue.
>
>
> Regards,
> Raghavendra
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180509/44512c37/attachment.html>

From csutherl at redhat.com  Thu May 10 13:10:00 2018
From: csutherl at redhat.com (Coty Sutherland)
Date: Thu, 10 May 2018 09:10:00 -0400
Subject: [openssl-users] Help with OpenSSL's OCSP responder serving
	pre-produced responses
Message-ID: <CA+d8oJZV+8QsTaxUsK8D0iqf22Dy+en9_N3E=+_c5e6e-9f2NQ@mail.gmail.com>

Hi,

Can anyone tell me how to serve pre-produced responses with OpenSSL's
OCSP responder? My current understanding is that what I'm doing should
work, but it doesn't. The pre-produced response correctly prints to
stdout...but it doesn't actually go back to the client (instead
openssl sends an RST).

Here's what I'm doing:

1) Setup a OCSP responder

openssl ocsp -index ca.db -port 8088 -rsigner ca.pem -CA ca.pem -text

2) Create a pre-produced response object for later use

openssl ocsp -issuer ca.pem -cert revoked.test.example.com.crt -text
-url http://127.0.0.1:8088
-respout resp_revoked_first.out

3) Start responder with pre-produced response

openssl ocsp -port 8088 -text -respin resp_revoked_first.out

4) Make a request and get error response (Error querying OCSP responder)

openssl ocsp -issuer ca.pem -cert revoked.test.example.com.crt -text
-url http://127.0.0.1:8088

Thoughts? Am I doing something stupid?



TIA,
Coty

From darshanmody at avaya.com  Thu May 10 16:30:48 2018
From: darshanmody at avaya.com (Mody, Darshan (Darshan))
Date: Thu, 10 May 2018 16:30:48 +0000
Subject: [openssl-users] disable session id reuse
In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A431091@AZ-FFEXMB03.global.avaya.com>
References: <25D2EC755404B4409F263AC6D050FEBB2A41FE1B@AZ-FFEXMB03.global.avaya.com>
 <B33E763A-9EF2-4E45-AD3E-4E410BC67A50@gmail.com>
 <25D2EC755404B4409F263AC6D050FEBB2A431091@AZ-FFEXMB03.global.avaya.com>
Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A44851C@AZ-FFEXMB03.global.avaya.com>

Hi All

Any suggestion on the problem?

Thanks
Darshan

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Mody, Darshan (Darshan)
Sent: Sunday, May 6, 2018 7:28 PM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] disable session id reuse

Hi

We do set SSL_CTX_set_options(ctx, SSL_OP_NO_TICKET); while initializing Context

Thanks
Darshan

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Devang Kubavat
Sent: Sunday, May 6, 2018 1:42 PM
To: openssl-users at openssl.org<mailto:openssl-users at openssl.org>
Subject: Re: [openssl-users] disable session id reuse

Hi Darshan,

In Addition, Make sure that you should disable the session ticket based session resumption using SSL_OP_NO_TICKET.

By default SSL_OP_NO_TICKET is not disabled.

Thanks
Devang
Sent from my iPhone

On 03-May-2018, at 2:12 PM, Mody, Darshan (Darshan) <darshanmody at avaya.com<mailto:darshanmody at avaya.com>> wrote:
Hi,

While doing a openssl s_time command I find that by default it tries for Session Id Reuse. ?Now timing with session id reuse.?

In case if we don?t want openssl to reuse session id?s how can we configure openssl in the application for the same.

The application here is acting as a server.

I have set  SSL_CTX_set_session_cache_mode to SSL_SESS_CACHE_OFF

Thanks
Darshan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=6EwdsImPOhlHS6cQdur-UNtSfmU8P5PrY6_Yr_tCo2U&s=SJPsG8EXG55k4n7fzDiMayd1OUlyHCWP2JzifuoOKg0&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180510/15f93196/attachment-0001.html>

From raghuasit at gmail.com  Fri May 11 09:53:15 2018
From: raghuasit at gmail.com (Raghavendra a)
Date: Fri, 11 May 2018 15:23:15 +0530
Subject: [openssl-users] freeing of X509_CRL object
Message-ID: <CAGfGnOL62mbXGk9AKtNiA+6R1AcqASfgQskSnn8+HOHZU+GTxQ@mail.gmail.com>

Hi All,

In my program,
converting X509_CRL object to string format using *X509_CRL_print* and
BIO_get_mem_data.  after that if de-allocate * _x509crl * using
*X509_CRL_free.
*it is crashing with below reason

*.*







*Valgrind output:==31919== Invalid read of size 4==31919==    at 0xB475EF2:
CRYPTO_atomic_add (threads_pthread.c:155)==31919==    by 0xB355537:
asn1_do_lock (tasn_utl.c:79)==31919==    by 0xB352767: asn1_item_embed_free
(tasn_fre.c:88)==31919==    by 0xB3528D4: ASN1_item_free (tasn_fre.c:20)*
not sure if *X509_CRL_print *de-allocates some part of _x509crl ,  external
freeing of X509_CRL again leading to double free?
Please help on this issue.


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

From rsalz at akamai.com  Fri May 11 10:10:22 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 11 May 2018 10:10:22 +0000
Subject: [openssl-users] freeing of X509_CRL object
In-Reply-To: <CAGfGnOL62mbXGk9AKtNiA+6R1AcqASfgQskSnn8+HOHZU+GTxQ@mail.gmail.com>
References: <CAGfGnOL62mbXGk9AKtNiA+6R1AcqASfgQskSnn8+HOHZU+GTxQ@mail.gmail.com>
Message-ID: <7159BE42-15E8-463B-8E4C-041BF4B0C6B7@akamai.com>

The print routine does not free anything.

From: Raghavendra a <raghuasit at gmail.com>
Reply-To: openssl-users <openssl-users at openssl.org>
Date: Friday, May 11, 2018 at 5:53 AM
To: openssl-users <openssl-users at openssl.org>
Subject: [openssl-users] freeing of X509_CRL object

Hi All,
In my program,
converting X509_CRL object to string format using X509_CRL_print and BIO_get_mem_data.  after that if de-allocate  _x509crl  using X509_CRL_free.  it is crashing with below reason.
Valgrind output:
==31919== Invalid read of size 4
==31919==    at 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155)
==31919==    by 0xB355537: asn1_do_lock (tasn_utl.c:79)
==31919==    by 0xB352767: asn1_item_embed_free (tasn_fre.c:88)
==31919==    by 0xB3528D4: ASN1_item_free (tasn_fre.c:20)
not sure if X509_CRL_print de-allocates some part of _x509crl ,  external freeing of X509_CRL again leading to double free?
Please help on this issue.

Regards,
Raghavendra



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

From raghuasit at gmail.com  Fri May 11 10:22:03 2018
From: raghuasit at gmail.com (Raghavendra a)
Date: Fri, 11 May 2018 15:52:03 +0530
Subject: [openssl-users] freeing of X509_CRL object
In-Reply-To: <7159BE42-15E8-463B-8E4C-041BF4B0C6B7@akamai.com>
References: <CAGfGnOL62mbXGk9AKtNiA+6R1AcqASfgQskSnn8+HOHZU+GTxQ@mail.gmail.com>
 <7159BE42-15E8-463B-8E4C-041BF4B0C6B7@akamai.com>
Message-ID: <CAGfGnOLSMkOgnbufrpe4qF6jPQeCY8nMduUkkptiKThzdJekCg@mail.gmail.com>

Hi Rich,

Thanks for information.
Any idea, why *is X509_CRL_free* reporting below error with valgrind?










*Valgrind output:==31919== Invalid read of size 4==31919==    at 0xB475EF2:
CRYPTO_atomic_add (threads_pthread.c:155)==31919==    by 0xB355537:
asn1_do_lock (tasn_utl.c:79)==31919==    by 0xB352767: asn1_item_embed_free
(tasn_fre.c:88)==31919==    by 0xB3528D4: ASN1_item_free (tasn_fre.c:20)*

Regards,
Raghavendra


On Fri, May 11, 2018 at 3:40 PM, Salz, Rich via openssl-users <
openssl-users at openssl.org> wrote:

> The print routine does not free anything.
>
>
>
> *From: *Raghavendra a <raghuasit at gmail.com>
> *Reply-To: *openssl-users <openssl-users at openssl.org>
> *Date: *Friday, May 11, 2018 at 5:53 AM
> *To: *openssl-users <openssl-users at openssl.org>
> *Subject: *[openssl-users] freeing of X509_CRL object
>
>
>
> Hi All,
>
> In my program,
>
> converting X509_CRL object to string format using *X509_CRL_print* and
> BIO_get_mem_data.  after that if de-allocate*  _x509crl * using *X509_CRL_free.
> *it is crashing with below reason*.*
>
>
>
>
>
>
> *Valgrind output: ==31919== Invalid read of size 4 ==31919==    at
> 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155) ==31919==    by
> 0xB355537: asn1_do_lock (tasn_utl.c:79) ==31919==    by 0xB352767:
> asn1_item_embed_free (tasn_fre.c:88) ==31919==    by 0xB3528D4:
> ASN1_item_free (tasn_fre.c:20)*
>
> not sure if * X509_CRL_print *de-allocates some part of _x509crl ,
> external freeing of X509_CRL again leading to double free?
>
> Please help on this issue.
>
>
>
> Regards,
>
> Raghavendra
>
>
>
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180511/47384024/attachment.html>

From rsalz at akamai.com  Fri May 11 11:51:13 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Fri, 11 May 2018 11:51:13 +0000
Subject: [openssl-users] freeing of X509_CRL object
In-Reply-To: <CAGfGnOLSMkOgnbufrpe4qF6jPQeCY8nMduUkkptiKThzdJekCg@mail.gmail.com>
References: <CAGfGnOL62mbXGk9AKtNiA+6R1AcqASfgQskSnn8+HOHZU+GTxQ@mail.gmail.com>
 <7159BE42-15E8-463B-8E4C-041BF4B0C6B7@akamai.com>
 <CAGfGnOLSMkOgnbufrpe4qF6jPQeCY8nMduUkkptiKThzdJekCg@mail.gmail.com>
Message-ID: <8AF4C4EA-BF19-4CCC-B857-9D7B34A0FC20@akamai.com>

Something else is going wrong.  Is that the only valgrind error?   Are you sure you didn?t free the object in your code?

From: Raghavendra a <raghuasit at gmail.com>
Date: Friday, May 11, 2018 at 6:22 AM
To: Rich Salz <rsalz at akamai.com>, openssl-users <openssl-users at openssl.org>
Subject: Re: [openssl-users] freeing of X509_CRL object

Hi Rich,
Thanks for information.
Any idea, why is X509_CRL_free reporting below error with valgrind?

Valgrind output:
==31919== Invalid read of size 4
==31919==    at 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155)
==31919==    by 0xB355537: asn1_do_lock (tasn_utl.c:79)
==31919==    by 0xB352767: asn1_item_embed_free (tasn_fre.c:88)
==31919==    by 0xB3528D4: ASN1_item_free (tasn_fre.c:20)


Regards,
Raghavendra


On Fri, May 11, 2018 at 3:40 PM, Salz, Rich via openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>> wrote:
The print routine does not free anything.

From: Raghavendra a <raghuasit at gmail.com<mailto:raghuasit at gmail.com>>
Reply-To: openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Date: Friday, May 11, 2018 at 5:53 AM
To: openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Subject: [openssl-users] freeing of X509_CRL object

Hi All,
In my program,
converting X509_CRL object to string format using X509_CRL_print and BIO_get_mem_data.  after that if de-allocate  _x509crl  using X509_CRL_free.  it is crashing with below reason.
Valgrind output:
==31919== Invalid read of size 4
==31919==    at 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155)
==31919==    by 0xB355537: asn1_do_lock (tasn_utl.c:79)
==31919==    by 0xB352767: asn1_item_embed_free (tasn_fre.c:88)
==31919==    by 0xB3528D4: ASN1_item_free (tasn_fre.c:20)
not sure if X509_CRL_print de-allocates some part of _x509crl ,  external freeing of X509_CRL again leading to double free?
Please help on this issue.

Regards,
Raghavendra




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=4cUZMk1U7D4tMKrZ53Zr2Sdx_PYdB1UlZxh1L5dbRxU&s=JmKoop4-SO14yQPJtfttNOklBqfEKTCBlWU--64FlHg&e=>

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

From deicool at gmail.com  Sat May 12 17:01:26 2018
From: deicool at gmail.com (Deepak Goel)
Date: Sat, 12 May 2018 22:31:26 +0530
Subject: [openssl-users] SSLv3 error in Ubuntu/Apache2
Message-ID: <CA+b7NVVTxy6pQ=M8PMkdHAOb==4tOgqjaXKVtOSqCjZeqbGgAQ@mail.gmail.com>

Hello

I am trying to use Apache2 on Ubuntu. When I try running Apache2, it throws
up an error:

SSLv3 not supported by this version of OpenSSL. I tried installing latest
version of OpenSSL by using (sudo apt-get install openssl) on Ubuntu.
However the same error persist.

Any idea how do I resolve the error?


Deepak
"The greatness of a nation can be judged by the way its animals are
treated. Please stop cruelty to Animals, become a Vegan"

+91 73500 12833
deicool at gmail.com

Facebook: https://www.facebook.com/deicool
LinkedIn: www.linkedin.com/in/deicool

"Plant a Tree, Go Green"

Make In India : http://www.makeinindia.com/home
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180512/0949a201/attachment.html>

From skneizys at ferrilli.com  Sat May 12 17:32:42 2018
From: skneizys at ferrilli.com (Steven Kneizys)
Date: Sat, 12 May 2018 13:32:42 -0400
Subject: [openssl-users] SSLv3 error in Ubuntu/Apache2
In-Reply-To: <CA+b7NVVTxy6pQ=M8PMkdHAOb==4tOgqjaXKVtOSqCjZeqbGgAQ@mail.gmail.com>
References: <CA+b7NVVTxy6pQ=M8PMkdHAOb==4tOgqjaXKVtOSqCjZeqbGgAQ@mail.gmail.com>
Message-ID: <CAKzUzBPjH9oKvV8Z9wHseeB4=OZuoTYfX5ZVmfW=it+jSJcijw@mail.gmail.com>

Running a server or even a client that uses SSLv3 is an insecure protocol
(man in the middle POODLE attack is possible).  You really don't want to
have that on your server!  Perhaps if you explain why you believe you need
it folks can help with a secure strategy to assist.  See this for reference:

https://askubuntu.com/questions/537481/disable-sslv3-in-apache2-on-a-clean-install-of-ubuntu-14-04-1-server

HTH,

Steve...

On Sat, May 12, 2018 at 1:01 PM, Deepak Goel <deicool at gmail.com> wrote:

> Hello
>
> I am trying to use Apache2 on Ubuntu. When I try running Apache2, it
> throws up an error:
>
> SSLv3 not supported by this version of OpenSSL. I tried installing latest
> version of OpenSSL by using (sudo apt-get install openssl) on Ubuntu.
> However the same error persist.
>
> Any idea how do I resolve the error?
>
>
> Deepak
> "The greatness of a nation can be judged by the way its animals are
> treated. Please stop cruelty to Animals, become a Vegan"
>
> +91 73500 12833
> deicool at gmail.com
>
> Facebook: https://www.facebook.com/deicool
> LinkedIn: www.linkedin.com/in/deicool
>
> "Plant a Tree, Go Green"
>
> Make In India : http://www.makeinindia.com/home
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
>


-- 
Steve Kneizys
Senior Business Process Engineer

*Relationships are at the heart of what we do*



*24/7 Emergency Service: 888.864.3282 <888.864.3282>*
*Direct: 610.256.1396    Web: www.Ferrilli.com <http://www.ferrilli.com/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180512/d7ad3097/attachment.html>

From jb-openssl at wisemo.com  Mon May 14 05:53:43 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Mon, 14 May 2018 07:53:43 +0200
Subject: [openssl-users] SSLv3 error in Ubuntu/Apache2
In-Reply-To: <CA+b7NVVTxy6pQ=M8PMkdHAOb==4tOgqjaXKVtOSqCjZeqbGgAQ@mail.gmail.com>
References: <CA+b7NVVTxy6pQ=M8PMkdHAOb==4tOgqjaXKVtOSqCjZeqbGgAQ@mail.gmail.com>
Message-ID: <c9e2b1ed-8aa9-64f5-38cc-ef319fd9aa39@wisemo.com>

On 12/05/2018 19:01, Deepak Goel wrote:
> Hello
>
> I am trying to use Apache2 on Ubuntu. When I try running Apache2, it 
> throws up an error:
>
> SSLv3 not supported by this version of OpenSSL. I tried installing 
> latest version of OpenSSL by using (sudo apt-get install openssl) on 
> Ubuntu. However the same error persist.
>
> Any idea how do I resolve the error?
Please check if you Apache configuration explicitly requests use of
the mostly outdated SSLv3.? Such a configuration setting may be
left over from years ago when SSLv3 was still a good thing to use.

SSLv3 is has many protocol design security holes that cannot be
fixedwithout switching to a later SSL version, such as TLS
1.0/1.1/1.2 etc.? These bugs are not in OpenSSL, but in the
protocol standard itself.

Unfortunately there are still a few old web browsers that only
support SSLv3, but only if you absolutely have to support those
should you set up a way to use SSLv3 on your web server.

Enjoy

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


From raghuasit at gmail.com  Tue May 15 06:58:18 2018
From: raghuasit at gmail.com (Raghavendra a)
Date: Tue, 15 May 2018 12:28:18 +0530
Subject: [openssl-users] freeing of X509_CRL object
In-Reply-To: <8AF4C4EA-BF19-4CCC-B857-9D7B34A0FC20@akamai.com>
References: <CAGfGnOL62mbXGk9AKtNiA+6R1AcqASfgQskSnn8+HOHZU+GTxQ@mail.gmail.com>
 <7159BE42-15E8-463B-8E4C-041BF4B0C6B7@akamai.com>
 <CAGfGnOLSMkOgnbufrpe4qF6jPQeCY8nMduUkkptiKThzdJekCg@mail.gmail.com>
 <8AF4C4EA-BF19-4CCC-B857-9D7B34A0FC20@akamai.com>
Message-ID: <CAGfGnO+vxcJOpELChMPT2Yz90p_6BLPFYRZV45krhFNHT6pekA@mail.gmail.com>

Hi,

Yes, I am freeing * _x509crl * using *X509_CRL_free*  after using in
*X509_CRL_print*.
Above valgrind error is for free operation, is it wrong?

Regards,
Raghavendra

On Fri, May 11, 2018 at 5:21 PM, Salz, Rich <rsalz at akamai.com> wrote:

> Something else is going wrong.  Is that the only valgrind error?   Are you
> sure you didn?t free the object in your code?
>
>
>
> *From: *Raghavendra a <raghuasit at gmail.com>
> *Date: *Friday, May 11, 2018 at 6:22 AM
> *To: *Rich Salz <rsalz at akamai.com>, openssl-users <
> openssl-users at openssl.org>
> *Subject: *Re: [openssl-users] freeing of X509_CRL object
>
>
>
> Hi Rich,
>
> Thanks for information.
>
> Any idea, why *is X509_CRL_free* reporting below error with valgrind?
>
>
>
>
>
>
>
>
>
>
> *Valgrind output: ==31919== Invalid read of size 4 ==31919==    at
> 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155) ==31919==    by
> 0xB355537: asn1_do_lock (tasn_utl.c:79) ==31919==    by 0xB352767:
> asn1_item_embed_free (tasn_fre.c:88) ==31919==    by 0xB3528D4:
> ASN1_item_free (tasn_fre.c:20) *
>
>
>
> Regards,
>
> Raghavendra
>
>
>
>
>
> On Fri, May 11, 2018 at 3:40 PM, Salz, Rich via openssl-users <
> openssl-users at openssl.org> wrote:
>
> The print routine does not free anything.
>
>
>
> *From: *Raghavendra a <raghuasit at gmail.com>
> *Reply-To: *openssl-users <openssl-users at openssl.org>
> *Date: *Friday, May 11, 2018 at 5:53 AM
> *To: *openssl-users <openssl-users at openssl.org>
> *Subject: *[openssl-users] freeing of X509_CRL object
>
>
>
> Hi All,
>
> In my program,
>
> converting X509_CRL object to string format using *X509_CRL_print* and
> BIO_get_mem_data.  after that if de-allocate*  _x509crl * using *X509_CRL_free.
> *it is crashing with below reason*.*
>
>
>
>
>
>
> *Valgrind output: ==31919== Invalid read of size 4 ==31919==    at
> 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155) ==31919==    by
> 0xB355537: asn1_do_lock (tasn_utl.c:79) ==31919==    by 0xB352767:
> asn1_item_embed_free (tasn_fre.c:88) ==31919==    by 0xB3528D4:
> ASN1_item_free (tasn_fre.c:20)*
>
> not sure if *X509_CRL_print *de-allocates some part of _x509crl ,
> external freeing of X509_CRL again leading to double free?
>
> Please help on this issue.
>
>
>
> Regards,
>
> Raghavendra
>
>
>
>
>
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=4cUZMk1U7D4tMKrZ53Zr2Sdx_PYdB1UlZxh1L5dbRxU&s=JmKoop4-SO14yQPJtfttNOklBqfEKTCBlWU--64FlHg&e=>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180515/8ca95a5d/attachment-0001.html>

From rsalz at akamai.com  Tue May 15 14:33:25 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 15 May 2018 14:33:25 +0000
Subject: [openssl-users] freeing of X509_CRL object
In-Reply-To: <CAGfGnO+vxcJOpELChMPT2Yz90p_6BLPFYRZV45krhFNHT6pekA@mail.gmail.com>
References: <CAGfGnOL62mbXGk9AKtNiA+6R1AcqASfgQskSnn8+HOHZU+GTxQ@mail.gmail.com>
 <7159BE42-15E8-463B-8E4C-041BF4B0C6B7@akamai.com>
 <CAGfGnOLSMkOgnbufrpe4qF6jPQeCY8nMduUkkptiKThzdJekCg@mail.gmail.com>
 <8AF4C4EA-BF19-4CCC-B857-9D7B34A0FC20@akamai.com>
 <CAGfGnO+vxcJOpELChMPT2Yz90p_6BLPFYRZV45krhFNHT6pekA@mail.gmail.com>
Message-ID: <D2BA7072-16E5-49ED-91B0-4F60267190D1@akamai.com>

Based on the information you provided, I don?t have any other advice.  The print routine does not free the CRL. You must be free?ing it twice.  Perhaps run under a debugger with a breakpoint

From: Raghavendra a <raghuasit at gmail.com>
Date: Tuesday, May 15, 2018 at 2:58 AM
To: Rich Salz <rsalz at akamai.com>
Cc: openssl-users <openssl-users at openssl.org>
Subject: Re: [openssl-users] freeing of X509_CRL object

Hi,
Yes, I am freeing _x509crl  using X509_CRL_free  after using in X509_CRL_print.
Above valgrind error is for free operation, is it wrong?
Regards,
Raghavendra

On Fri, May 11, 2018 at 5:21 PM, Salz, Rich <rsalz at akamai.com<mailto:rsalz at akamai.com>> wrote:
Something else is going wrong.  Is that the only valgrind error?   Are you sure you didn?t free the object in your code?

From: Raghavendra a <raghuasit at gmail.com<mailto:raghuasit at gmail.com>>
Date: Friday, May 11, 2018 at 6:22 AM
To: Rich Salz <rsalz at akamai.com<mailto:rsalz at akamai.com>>, openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Subject: Re: [openssl-users] freeing of X509_CRL object

Hi Rich,
Thanks for information.
Any idea, why is X509_CRL_free reporting below error with valgrind?

Valgrind output:
==31919== Invalid read of size 4
==31919==    at 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155)
==31919==    by 0xB355537: asn1_do_lock (tasn_utl.c:79)
==31919==    by 0xB352767: asn1_item_embed_free (tasn_fre.c:88)
==31919==    by 0xB3528D4: ASN1_item_free (tasn_fre.c:20)

Regards,
Raghavendra


On Fri, May 11, 2018 at 3:40 PM, Salz, Rich via openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>> wrote:
The print routine does not free anything.

From: Raghavendra a <raghuasit at gmail.com<mailto:raghuasit at gmail.com>>
Reply-To: openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Date: Friday, May 11, 2018 at 5:53 AM
To: openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Subject: [openssl-users] freeing of X509_CRL object

Hi All,
In my program,
converting X509_CRL object to string format using X509_CRL_print and BIO_get_mem_data.  after that if de-allocate  _x509crl  using X509_CRL_free.  it is crashing with below reason.
Valgrind output:
==31919== Invalid read of size 4
==31919==    at 0xB475EF2: CRYPTO_atomic_add (threads_pthread.c:155)
==31919==    by 0xB355537: asn1_do_lock (tasn_utl.c:79)
==31919==    by 0xB352767: asn1_item_embed_free (tasn_fre.c:88)
==31919==    by 0xB3528D4: ASN1_item_free (tasn_fre.c:20)
not sure if X509_CRL_print de-allocates some part of _x509crl ,  external freeing of X509_CRL again leading to double free?
Please help on this issue.

Regards,
Raghavendra




--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=4cUZMk1U7D4tMKrZ53Zr2Sdx_PYdB1UlZxh1L5dbRxU&s=JmKoop4-SO14yQPJtfttNOklBqfEKTCBlWU--64FlHg&e=>


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

From guerinp at talasi.fr  Wed May 16 15:19:33 2018
From: guerinp at talasi.fr (=?UTF-8?Q?Patrice_Gu=c3=a9rin?=)
Date: Wed, 16 May 2018 17:19:33 +0200
Subject: [openssl-users] PKCS7 signature process
Message-ID: <49a2da24-817a-35c4-f9b3-49eeddda7e56@magic.fr>

Hello OpenSSL-users

In the purpose of signing pdf files, I've found a difference of 
behaviour that I can't explain between two ways of computing signatures.
The first one leads to an error in the way that Adobe says that the file 
was modified after signing, the second does not.

First Method:
 ??? BIO* BioMem = BIO_new( BIO_s_mem() );
 ??? while ( Data )
BIO_write( BioMem , Data, DataLen );
 ??? MyPKCS7 = PKCS7_sign( Certificate, PrivateKey,NULL, BioMem , 
PKCS7_DETACHED | PKCS7_BINARY );
 ??? PKCS7_final( MyPKCS7, BioMem , PKCS7_DETACHED | PKCS7_BINARY );
 ??? BIO* BioOut = BIO_new( BIO_s_mem() );
 ??? i2d_PKCS7_bio( BioOut , MyPKCS7 );
 ??? char*??? OutBuf = NULL;
 ??? int OutLen = BIO_get_mem_data( BioOut , &OutBuf );

Second Method:
 ??? BIO* BioMem = BIO_new( BIO_s_mem() );
 ??? MyPKCS7 = PKCS7_sign( Certificate, PrivateKey,NULL, BioMem , 
PKCS7_DETACHED | PKCS7_BINARY );
 ??? while ( Data )
 ??? ??? BIO_write( BioMem , Data, DataLen );
 ??? PKCS7_final( MyPKCS7, BioMem , PKCS7_DETACHED | PKCS7_BINARY );
 ??? BIO* BioOut = BIO_new( BIO_s_mem() );
 ??? i2d_PKCS7_bio( BioOut , MyPKCS7 );
 ??? char*??? OutBuf = NULL;
 ??? int OutLen = BIO_get_mem_data( BioOut , &OutBuf );

It seems that the order between PKCS7_sign et BIO_Write that feeds the 
memory BIO has an importance.

Can anybody explains why the first method is incorrect ?

Thank you in advance
Patrice.

From luis.pinto.martins at gmail.com  Wed May 16 17:55:57 2018
From: luis.pinto.martins at gmail.com (=?UTF-8?Q?Lu=C3=ADs_Martins?=)
Date: Wed, 16 May 2018 18:55:57 +0100
Subject: [openssl-users] EVP AES Wrap
Message-ID: <CAHeZdFyV2AyAucvLhVrCWQt5iDfoUWS5C1zdw4kGi_-LXGSrNA@mail.gmail.com>

Hi,

    I'm trying to use the EVP AES wrap implementations from openssl (e.g.
EVP_aes_128/192/256_wrap()) but I'm getting the following error in
EVP_EncryptInit_ex() f:
    error:0607B0AA:digital envelope routines:EVP_CipherInit_ex:wrap mode
not allowed
    I've search the documentation for examples or guidance but I couldn't
find anything related to this.
    Any experienced the same issue ?

    My pseudo code is:

        EVP_CIPHER_CTX ctx;
        EVP_CIPHER_CTX_init(&ctx);
        if (EVP_EncryptInit_ex(&ctx, EVP_aes_128_wrap(), 0,
keyEncriptionKey, iv) != 1)
             // process error
        if ( EVP_EncryptUpdate(&ctx, bufferOut, &processedSize, plaintext,
plaintextSize) != 1)
             // process error
        if (EVP_EncryptFinal_ex(&ctx, bufferOut + processedSize, &tmpSize)
!= 1)
             // process error
        EVP_CIPHER_CTX_cleanup(&ctx);

Regards,
Lu?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180516/84ba4e50/attachment.html>

From matt at openssl.org  Thu May 17 09:08:59 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 17 May 2018 10:08:59 +0100
Subject: [openssl-users] EVP AES Wrap
In-Reply-To: <CAHeZdFyV2AyAucvLhVrCWQt5iDfoUWS5C1zdw4kGi_-LXGSrNA@mail.gmail.com>
References: <CAHeZdFyV2AyAucvLhVrCWQt5iDfoUWS5C1zdw4kGi_-LXGSrNA@mail.gmail.com>
Message-ID: <91a9c5ea-a3e0-f5f6-e4e4-5e191d7dd12c@openssl.org>



On 16/05/18 18:55, Lu?s Martins wrote:
> Hi,
> 
> ??? I'm trying to use the EVP AES wrap implementations from openssl
> (e.g. EVP_aes_128/192/256_wrap()) but I'm getting the following error in
> EVP_EncryptInit_ex() f:
> ??? error:0607B0AA:digital envelope routines:EVP_CipherInit_ex:wrap mode
> not allowed
> ??? I've search the documentation for examples or guidance but I
> couldn't find anything related to this.
> ??? Any experienced the same issue ?

You need to enable wrap mode:

EVP_CIPHER_CTX_set_flags(&ctx, EVP_CIPHER_CTX_FLAG_WRAP_ALLOW);

The EVP encrypt routines set an expectation about how long the output
might be for a given input:

"EVP_EncryptUpdate() encrypts B<inl> bytes from the buffer B<in> and
writes the encrypted version to B<out>. This function can be called
multiple times to encrypt successive blocks of data. The amount
of data written depends on the block alignment of the encrypted data:
as a result the amount of data written may be anything from zero bytes
to (inl + cipher_block_size - 1) so B<out> should contain sufficient
room."

The wrap modes do not obey this rule and may return more data, so you
have to explicitly enable the mode to say that you are prepared for the
output.

Matt


> 
> ??? My pseudo code is:
> 
> ?? ? ?? EVP_CIPHER_CTX ctx;
> ??????? EVP_CIPHER_CTX_init(&ctx);
> ??????? if (EVP_EncryptInit_ex(&ctx, EVP_aes_128_wrap(), 0,
> keyEncriptionKey, iv) != 1)
> ???????????? // process error
> ??????? if ( EVP_EncryptUpdate(&ctx, bufferOut, &processedSize,
> plaintext, plaintextSize) != 1)
> ???????????? // process error
> ??????? if (EVP_EncryptFinal_ex(&ctx, bufferOut + processedSize,
> &tmpSize) != 1)
> ???????????? // process error
> ??????? EVP_CIPHER_CTX_cleanup(&ctx);
> 
> Regards,
> Lu?s
> 
> 

From luis.pinto.martins at gmail.com  Thu May 17 10:12:40 2018
From: luis.pinto.martins at gmail.com (=?UTF-8?Q?Lu=C3=ADs_Martins?=)
Date: Thu, 17 May 2018 11:12:40 +0100
Subject: [openssl-users] EVP AES Wrap
In-Reply-To: <91a9c5ea-a3e0-f5f6-e4e4-5e191d7dd12c@openssl.org>
References: <CAHeZdFyV2AyAucvLhVrCWQt5iDfoUWS5C1zdw4kGi_-LXGSrNA@mail.gmail.com>
 <91a9c5ea-a3e0-f5f6-e4e4-5e191d7dd12c@openssl.org>
Message-ID: <CAHeZdFxfcG8NOzQhrXZ9XFHppMoYYuOQ+Bp1=2Xff0JPvfSiJw@mail.gmail.com>

Thanks Matt, it works fine now.

Regards,
Lu?s


On Thu, May 17, 2018 at 10:09 AM Matt Caswell <matt at openssl.org> wrote:

>
>
> On 16/05/18 18:55, Lu?s Martins wrote:
> > Hi,
> >
> >     I'm trying to use the EVP AES wrap implementations from openssl
> > (e.g. EVP_aes_128/192/256_wrap()) but I'm getting the following error in
> > EVP_EncryptInit_ex() f:
> >     error:0607B0AA:digital envelope routines:EVP_CipherInit_ex:wrap mode
> > not allowed
> >     I've search the documentation for examples or guidance but I
> > couldn't find anything related to this.
> >     Any experienced the same issue ?
>
> You need to enable wrap mode:
>
> EVP_CIPHER_CTX_set_flags(&ctx, EVP_CIPHER_CTX_FLAG_WRAP_ALLOW);
>
> The EVP encrypt routines set an expectation about how long the output
> might be for a given input:
>
> "EVP_EncryptUpdate() encrypts B<inl> bytes from the buffer B<in> and
> writes the encrypted version to B<out>. This function can be called
> multiple times to encrypt successive blocks of data. The amount
> of data written depends on the block alignment of the encrypted data:
> as a result the amount of data written may be anything from zero bytes
> to (inl + cipher_block_size - 1) so B<out> should contain sufficient
> room."
>
> The wrap modes do not obey this rule and may return more data, so you
> have to explicitly enable the mode to say that you are prepared for the
> output.
>
> Matt
>
>
> >
> >     My pseudo code is:
> >
> >         EVP_CIPHER_CTX ctx;
> >         EVP_CIPHER_CTX_init(&ctx);
> >         if (EVP_EncryptInit_ex(&ctx, EVP_aes_128_wrap(), 0,
> > keyEncriptionKey, iv) != 1)
> >              // process error
> >         if ( EVP_EncryptUpdate(&ctx, bufferOut, &processedSize,
> > plaintext, plaintextSize) != 1)
> >              // process error
> >         if (EVP_EncryptFinal_ex(&ctx, bufferOut + processedSize,
> > &tmpSize) != 1)
> >              // process error
> >         EVP_CIPHER_CTX_cleanup(&ctx);
> >
> > Regards,
> > Lu?s
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180517/4617c48c/attachment.html>

From philippe.anctil at gmail.com  Fri May 18 15:22:14 2018
From: philippe.anctil at gmail.com (Philippe Anctil)
Date: Fri, 18 May 2018 11:22:14 -0400
Subject: [openssl-users] test make_verify fails on brand new red hat
	enterprise 7 box
Message-ID: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>

Hi,

I have been compiling openssl libraries on RHEL5 for a while without issue.
My build for 1.0.2k fails on a new RHEL7 server. I have narrowed down the
cause to the make_verify test.



make verify_test # from test dir

The following command should have some OK's and some failures
There are definitly a few expired certificates
../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo
../certs/demo/*.pem
../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd,
CN = Test CA (1024 bit)
error 20 at 0 depth lookup:unable to get local issuer certificate
../certs/demo/dsa-ca.pem: C = AU, ST = Some-State, O = Internet Widgits Pty
Ltd, CN = CA
error 20 at 0 depth lookup:unable to get local issuer certificate
140692788688576:error:0B06E06B:x509 certificate
routines:X509_get_pubkey_parameters:unable to find parameters in
chain:x509_vfy.c:2108:
../certs/demo/dsa-pca.pem: C = AU, ST = Some-State, O = Internet Widgits
Pty Ltd, CN = PCA
error 18 at 0 depth lookup:self signed certificate
C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = PCA
error 10 at 0 depth lookup:certificate has expired
OK
../certs/demo/pca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd,
CN = Test PCA (1024 bit)
error 18 at 0 depth lookup:self signed certificate
C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK
make: *** [test_verify] Error 2



It seems to boil down to the following



OPENSSL_CONF= LD_LIBRARY_PATH=.. ../apps/openssl verify -CApath
../certs/demo ../certs/demo/ca-cert.pem

WARNING: can't open config file:
../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd,
CN = Test CA (1024 bit)
error 20 at 0 depth lookup:unable to get local issuer certificate

echo $?

2



Doing the same on my RHEL5 box.



OPENSSL_CONF= LD_LIBRARY_PATH=.. ../apps/openssl verify -CApath
../certs/demo ../certs/demo/ca-cert.pem
WARNING: can't open config file:
../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd,
CN = Test PCA (1024 bit)
error 10 at 1 depth lookup:certificate has expired
C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test CA (1024 bit)
error 10 at 0 depth lookup:certificate has expired
OK

echo $?

0



Any clue why openssl verify does not work on RHEL7?
ca-cert.pem is issued by pca-cert.pem (matching Authority Key Identifier).
Both are under ../certs/demo.

Thanks.


-- 
Philippe Anctil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180518/77f2622b/attachment-0001.html>

From openssl-users at dukhovni.org  Fri May 18 15:53:33 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Fri, 18 May 2018 11:53:33 -0400
Subject: [openssl-users] test make_verify fails on brand new red hat
 enterprise 7 box
In-Reply-To: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>
References: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>
Message-ID: <6C02857F-C6A9-4A22-A934-425655CA6A19@dukhovni.org>



> On May 18, 2018, at 11:22 AM, Philippe Anctil <philippe.anctil at gmail.com> wrote:
> 
> Hi,
> 
> I have been compiling openssl libraries on RHEL5 for a while without issue. My build for 1.0.2k fails on a new RHEL7 server. I have narrowed down the cause to the make_verify test. 

All tests pass when I build 1.0.2p.  There is no "verify_test" in any version
of 1.0.2 I can find, including 1.0.2k.  Perhaps that test is part of Redhat
specific patches to OpenSSL.  You'll need to solve this with whoever authored
that test.

-- 
	Viktor.


From philippe.anctil at gmail.com  Fri May 18 16:03:01 2018
From: philippe.anctil at gmail.com (Philippe Anctil)
Date: Fri, 18 May 2018 12:03:01 -0400
Subject: [openssl-users] test make_verify fails on brand new red hat
 enterprise 7 box
In-Reply-To: <6C02857F-C6A9-4A22-A934-425655CA6A19@dukhovni.org>
References: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>
 <6C02857F-C6A9-4A22-A934-425655CA6A19@dukhovni.org>
Message-ID: <CAOPjdVN+d2Yy0yCGnrdgjZMu1eJJCGE6VCuX7GzVN1buDj8R_Q@mail.gmail.com>

I am compiling from openssl.org source.

pwd

.../openssl-1.0.2k/test

grep -A 4 'test_verify:' Makefile

test_verify: ../apps/openssl$(EXE_EXT)
        @echo "The following command should have some OK's and some
failures"
        @echo "There are definitly a few expired certificates"
        ../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo
../certs/demo/*.pem






2018-05-18 11:53 GMT-04:00 Viktor Dukhovni <openssl-users at dukhovni.org>:

>
>
> > On May 18, 2018, at 11:22 AM, Philippe Anctil <philippe.anctil at gmail.com>
> wrote:
> >
> > Hi,
> >
> > I have been compiling openssl libraries on RHEL5 for a while without
> issue. My build for 1.0.2k fails on a new RHEL7 server. I have narrowed
> down the cause to the make_verify test.
>
> All tests pass when I build 1.0.2p.  There is no "verify_test" in any
> version
> of 1.0.2 I can find, including 1.0.2k.  Perhaps that test is part of Redhat
> specific patches to OpenSSL.  You'll need to solve this with whoever
> authored
> that test.
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



-- 
Philippe Anctil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180518/2a1edaa4/attachment.html>

From matt at openssl.org  Fri May 18 16:11:31 2018
From: matt at openssl.org (Matt Caswell)
Date: Fri, 18 May 2018 17:11:31 +0100
Subject: [openssl-users] test make_verify fails on brand new red hat
 enterprise 7 box
In-Reply-To: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>
References: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>
Message-ID: <c1bce64b-1c3a-440d-8775-5f8f5a9f9108@openssl.org>



On 18/05/18 16:22, Philippe Anctil wrote:
> Hi,
> 
> I have been compiling openssl libraries on RHEL5 for a while without
> issue. My build for 1.0.2k fails on a new RHEL7 server. I have narrowed
> down the cause to the make_verify test.?
> 
> 
> 
> make verify_test # from test dir

I think you meant "make test_verify"

> It seems to boil down to the following
> 
> 
> 
> OPENSSL_CONF= LD_LIBRARY_PATH=.. ../apps/openssl verify -CApath
> ../certs/demo ../certs/demo/ca-cert.pem
> 
> WARNING: can't open config file:
> ../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty
> Ltd, CN = Test CA (1024 bit)
> error 20 at 0 depth lookup:unable to get local issuer certificate
> 
> echo $?
> 
> 2

So what does your certs/demo directory look like? Do you have the
necessary symbolic links (created during "make" somewhere I think). Are
all permissions and file sizes as expected? Mine looks like this:

$ ls -l
total 16
lrwxrwxrwx 1 matt matt   11 May 18 17:10 3f77a2b5.0 -> ca-cert.pem
-rw-r--r-- 1 matt matt 1953 May 18 16:47 ca-cert.pem
lrwxrwxrwx 1 matt matt   10 May 18 17:10 cbdbd8bc.0 -> dsa-ca.pem
lrwxrwxrwx 1 matt matt   11 May 18 17:10 de4fa23b.0 -> dsa-pca.pem
-rw-r--r-- 1 matt matt 2264 May 18 16:47 dsa-ca.pem
-rw-r--r-- 1 matt matt 2674 May 18 16:47 dsa-pca.pem
lrwxrwxrwx 1 matt matt   12 May 18 17:10 e83ef475.0 -> pca-cert.pem
-rw-r--r-- 1 matt matt 1953 May 18 16:47 pca-cert.pem


Matt

From philippe.anctil at gmail.com  Fri May 18 16:51:55 2018
From: philippe.anctil at gmail.com (Philippe Anctil)
Date: Fri, 18 May 2018 12:51:55 -0400
Subject: [openssl-users] test make_verify fails on brand new red hat
 enterprise 7 box
In-Reply-To: <c1bce64b-1c3a-440d-8775-5f8f5a9f9108@openssl.org>
References: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>
 <c1bce64b-1c3a-440d-8775-5f8f5a9f9108@openssl.org>
Message-ID: <CAOPjdVOvdH7hwi+Xf_bQkmmwLB18rLx4rYiGATKn6rS3Z_5NvQ@mail.gmail.com>

>
>
> So what does your certs/demo directory look like? Do you have the
> necessary symbolic links (created during "make" somewhere I think).
>


Links are missing.

The problem has something to do with the default path to openssl.conf. In
my case it is based on the build prefix I used.
If the path does not exist, make rehash will create links happily.
If the dir exists but my build account does not have access permissions,
make rehash is unhappy and refuses to create links.

rm rehash.time
make rehash

Doing certs/demo
140097379800768:error:0200100D:system library:fopen:Permission
denied:bss_file.c:175:fopen('/usr/local/.../openssl/ssl/openssl.cnf','rb')
140097379800768:error:2006D002:BIO routines:BIO_new_file:system
lib:bss_file.c:184:
140097379800768:error:0E078002:configuration file routines:DEF_LOAD:system
lib:conf_def.c:203:
140367544841920:error:0200100D:system library:fopen:Permission
denied:bss_file.c:175:fopen('/usr/local/.../openssl/ssl/openssl.cnf','rb')
140367544841920:error:2006D002:BIO routines:BIO_new_file:system
lib:bss_file.c:184:
140367544841920:error:0E078002:configuration file routines:DEF_LOAD:system
lib:conf_def.c:203:
WARNING: Skipping duplicate certificate dsa-ca.pem
140697328998080:error:0200100D:system library:fopen:Permission
denied:bss_file.c:175:fopen('/usr/local/.../openssl/ssl/openssl.cnf','rb')
140697328998080:error:2006D002:BIO routines:BIO_new_file:system
lib:bss_file.c:184:
140697328998080:error:0E078002:configuration file routines:DEF_LOAD:system
lib:conf_def.c:203:
WARNING: Skipping duplicate certificate dsa-pca.pem
139717812614848:error:0200100D:system library:fopen:Permission
denied:bss_file.c:175:fopen('/usr/local/.../openssl/ssl/openssl.cnf','rb')
139717812614848:error:2006D002:BIO routines:BIO_new_file:system
lib:bss_file.c:184:
139717812614848:error:0E078002:configuration file routines:DEF_LOAD:system
lib:conf_def.c:203:
WARNING: Skipping duplicate certificate pca-cert.pem



I don't know why openssl handles both errors in a different way. In general
the build does not care about the inaccessible config. That behavior suits
me.

Maybe the build should detect the problem with make rehash. Or force an
OPENSSL_CONF value that will make it happy. Here's the workaround I applied
to my build script.

...
rm rehash.time
make OPENSSL_CONF= rehash

make test


Problem nailed. Thank you for your help!


-- 
Philippe Anctil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180518/86f51317/attachment.html>

From alexhultman at gmail.com  Fri May 18 23:20:42 2018
From: alexhultman at gmail.com (Alex H)
Date: Sat, 19 May 2018 01:20:42 +0200
Subject: [openssl-users] Receive throttling on SSL sockets
Message-ID: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>

How do you properly implement receive throttling on SSL sockets without
hindering writing?

As opposed to raw TCP sockets, an SSL socket cannot be receive-throttled
simply by stop polling for readable events on the underlying raw TCP
socket. SSL_write still could require reading of data so simply stop
polling for readable would potentially hinder writing of data which is not
okay.

Is there any such receive-throttling functionality in the SSL protocol
itself? I don't see how SSL_peek would solve the issue since I would still
be buffering (potentially uncontrolled amount of) data in a BIO.

Even if I would _only_ enable readable polling when _absolutely needed_ as
per SSL_write error, I still cannot guarantee not reading a chunk of data
(which I would then need to buffer up in a BIO since the application is not
expecting it).

How are we supposed to solve this issue without potentially building up
backpressure?

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

From rsalz at akamai.com  Sat May 19 02:56:51 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 19 May 2018 02:56:51 +0000
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
Message-ID: <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>

TLS is a bidirectional protocol.  You can?t throttle only one side.

From: Alex H <alexhultman at gmail.com>
Reply-To: openssl-users <openssl-users at openssl.org>
Date: Friday, May 18, 2018 at 7:21 PM
To: openssl-users <openssl-users at openssl.org>
Subject: [openssl-users] Receive throttling on SSL sockets

How do you properly implement receive throttling on SSL sockets without hindering writing?

As opposed to raw TCP sockets, an SSL socket cannot be receive-throttled simply by stop polling for readable events on the underlying raw TCP socket. SSL_write still could require reading of data so simply stop polling for readable would potentially hinder writing of data which is not okay.

Is there any such receive-throttling functionality in the SSL protocol itself? I don't see how SSL_peek would solve the issue since I would still be buffering (potentially uncontrolled amount of) data in a BIO.

Even if I would _only_ enable readable polling when _absolutely needed_ as per SSL_write error, I still cannot guarantee not reading a chunk of data (which I would then need to buffer up in a BIO since the application is not expecting it).

How are we supposed to solve this issue without potentially building up backpressure?

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/100da722/attachment.html>

From alexhultman at gmail.com  Sat May 19 09:02:52 2018
From: alexhultman at gmail.com (Alex H)
Date: Sat, 19 May 2018 11:02:52 +0200
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
Message-ID: <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>

Okay that's a good theoretical answer but practically not very useful.

I know for instance Node.js to implement their Streams interface with both
TCP and SSL sockets. They both have pause / resume functions for
receive-throttling and I've tested it with SSL and it seems to work somehow.

One solution (I guess?) would be to stop polling for readable until
SSL_write demands data then immediately stop polling for readable again
once SSL_write is happy. In the case of getting unwanted data while
throttling then SSL_peek can be used instead of SSL_read. That would not
guarantee no buildup but would work for the most part, right?

Do you see any flaw with this? Could it still fail due to mass buildup when
throttling for long?

Den l?r 19 maj 2018 04:57Salz, Rich via openssl-users <
openssl-users at openssl.org> skrev:

> TLS is a bidirectional protocol.  You can?t throttle only one side.
>
>
>
> *From: *Alex H <alexhultman at gmail.com>
> *Reply-To: *openssl-users <openssl-users at openssl.org>
> *Date: *Friday, May 18, 2018 at 7:21 PM
> *To: *openssl-users <openssl-users at openssl.org>
> *Subject: *[openssl-users] Receive throttling on SSL sockets
>
>
>
> How do you properly implement receive throttling on SSL sockets without
> hindering writing?
>
>
>
> As opposed to raw TCP sockets, an SSL socket cannot be receive-throttled
> simply by stop polling for readable events on the underlying raw TCP
> socket. SSL_write still could require reading of data so simply stop
> polling for readable would potentially hinder writing of data which is not
> okay.
>
>
>
> Is there any such receive-throttling functionality in the SSL protocol
> itself? I don't see how SSL_peek would solve the issue since I would still
> be buffering (potentially uncontrolled amount of) data in a BIO.
>
>
>
> Even if I would _only_ enable readable polling when _absolutely needed_ as
> per SSL_write error, I still cannot guarantee not reading a chunk of data
> (which I would then need to buffer up in a BIO since the application is not
> expecting it).
>
>
>
> How are we supposed to solve this issue without potentially building up
> backpressure?
>
>
>
> Thanks
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/a61ca8be/attachment.html>

From alexhultman at gmail.com  Sat May 19 11:01:46 2018
From: alexhultman at gmail.com (Alex H)
Date: Sat, 19 May 2018 13:01:46 +0200
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
Message-ID: <CAHPaHkpB7Ea3vJMf+cP2MYU+HWpmc2JaHsrTBAVUsUuQDrM8XQ@mail.gmail.com>

I think the best solution would be to simply state in the documentation of
my implementation that "throttling receives on SSL sockets will
significantly reduce data receive but will not guarantee a total halt".

Agree?

What do you think of the way Node.js handles this? They _must_ be using
some kind of internal backup queue for cases like these, right?

2018-05-19 11:02 GMT+02:00 Alex H <alexhultman at gmail.com>:

> Okay that's a good theoretical answer but practically not very useful.
>
> I know for instance Node.js to implement their Streams interface with both
> TCP and SSL sockets. They both have pause / resume functions for
> receive-throttling and I've tested it with SSL and it seems to work somehow.
>
> One solution (I guess?) would be to stop polling for readable until
> SSL_write demands data then immediately stop polling for readable again
> once SSL_write is happy. In the case of getting unwanted data while
> throttling then SSL_peek can be used instead of SSL_read. That would not
> guarantee no buildup but would work for the most part, right?
>
> Do you see any flaw with this? Could it still fail due to mass buildup
> when throttling for long?
>
> Den l?r 19 maj 2018 04:57Salz, Rich via openssl-users <
> openssl-users at openssl.org> skrev:
>
>> TLS is a bidirectional protocol.  You can?t throttle only one side.
>>
>>
>>
>> *From: *Alex H <alexhultman at gmail.com>
>> *Reply-To: *openssl-users <openssl-users at openssl.org>
>> *Date: *Friday, May 18, 2018 at 7:21 PM
>> *To: *openssl-users <openssl-users at openssl.org>
>> *Subject: *[openssl-users] Receive throttling on SSL sockets
>>
>>
>>
>> How do you properly implement receive throttling on SSL sockets without
>> hindering writing?
>>
>>
>>
>> As opposed to raw TCP sockets, an SSL socket cannot be receive-throttled
>> simply by stop polling for readable events on the underlying raw TCP
>> socket. SSL_write still could require reading of data so simply stop
>> polling for readable would potentially hinder writing of data which is not
>> okay.
>>
>>
>>
>> Is there any such receive-throttling functionality in the SSL protocol
>> itself? I don't see how SSL_peek would solve the issue since I would still
>> be buffering (potentially uncontrolled amount of) data in a BIO.
>>
>>
>>
>> Even if I would _only_ enable readable polling when _absolutely needed_
>> as per SSL_write error, I still cannot guarantee not reading a chunk of
>> data (which I would then need to buffer up in a BIO since the application
>> is not expecting it).
>>
>>
>>
>> How are we supposed to solve this issue without potentially building up
>> backpressure?
>>
>>
>>
>> Thanks
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/5cbbc22b/attachment-0001.html>

From rsalz at akamai.com  Sat May 19 12:48:22 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Sat, 19 May 2018 12:48:22 +0000
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
Message-ID: <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>

There are TLS control messages which could flow in either direction, spontaneously.  Renegotiation (pre TLS 1.3), tickets (TLS 1.3), and so on.

I cannot comment on if your proposal would work or not, sorry.

From: Alex H <alexhultman at gmail.com>
Date: Saturday, May 19, 2018 at 5:03 AM
To: Rich Salz <rsalz at akamai.com>, openssl-users <openssl-users at openssl.org>
Subject: Re: [openssl-users] Receive throttling on SSL sockets

Okay that's a good theoretical answer but practically not very useful.

I know for instance Node.js to implement their Streams interface with both TCP and SSL sockets. They both have pause / resume functions for receive-throttling and I've tested it with SSL and it seems to work somehow.

One solution (I guess?) would be to stop polling for readable until SSL_write demands data then immediately stop polling for readable again once SSL_write is happy. In the case of getting unwanted data while throttling then SSL_peek can be used instead of SSL_read. That would not guarantee no buildup but would work for the most part, right?

Do you see any flaw with this? Could it still fail due to mass buildup when throttling for long?

Den l?r 19 maj 2018 04:57Salz, Rich via openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>> skrev:
TLS is a bidirectional protocol.  You can?t throttle only one side.

From: Alex H <alexhultman at gmail.com<mailto:alexhultman at gmail.com>>
Reply-To: openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Date: Friday, May 18, 2018 at 7:21 PM
To: openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>>
Subject: [openssl-users] Receive throttling on SSL sockets

How do you properly implement receive throttling on SSL sockets without hindering writing?

As opposed to raw TCP sockets, an SSL socket cannot be receive-throttled simply by stop polling for readable events on the underlying raw TCP socket. SSL_write still could require reading of data so simply stop polling for readable would potentially hinder writing of data which is not okay.

Is there any such receive-throttling functionality in the SSL protocol itself? I don't see how SSL_peek would solve the issue since I would still be buffering (potentially uncontrolled amount of) data in a BIO.

Even if I would _only_ enable readable polling when _absolutely needed_ as per SSL_write error, I still cannot guarantee not reading a chunk of data (which I would then need to buffer up in a BIO since the application is not expecting it).

How are we supposed to solve this issue without potentially building up backpressure?

Thanks
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=FtaD7Zbj35pGUXqlS9M4iUkkFSwd55Jyb--utisnk_w&s=RlwtO6T51DUEJML9UBzKu164P3a2abJNnZSSPQIzXQI&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/0aca101b/attachment.html>

From Michael.Wojcik at microfocus.com  Sat May 19 13:51:51 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sat, 19 May 2018 13:51:51 +0000
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
 <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>
Message-ID: <SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users
> Sent: Saturday, May 19, 2018 08:48
> To: Alex H; openssl-users at openssl.org
> Subject: Re: [openssl-users] Receive throttling on SSL sockets

> There are TLS control messages which could flow in either direction, spontaneously.  Renegotiation (pre TLS 1.3),
> tickets (TLS 1.3), and so on.

Right. And TCP is an ordered byte-stream protocol. That means to receive a control message from the peer, the local stack *must* have received everything transmitted prior to it. (Modulo SACK, but SACK'd data preceeded by a gap is invisible to the application, so we should ignore it.)

And if that data fills the receive window so the peer can't send the control message, then the application *must* receive the data from the local stack. Peeking won't help in this case, because the control message is still stuck on the peer, waiting for the window to open. (Of course this is one reason why FTP used a separate control connection, for example - so that control messages didn't sit behind a lot of application data. That led to a number of other difficulties, so it wasn't a widely used design.)

In short:  When you get SSL_WANT_READ, you have to receive and buffer data. You can try peeking, but it's not guaranteed to be able to get far enough to find the control message, and SSL_peek is just buffering data within OpenSSL, so you're not doing any throttling that way.

This will be true of any TCP-based TLS implementation. It's not an OpenSSL implementation, and whatever else Node.js is doing, it must be buffering TLS traffic somewhere when it has to receive a control message.

Post-handshake control message flows don't happen that frequently; relatively short-lived conversations may never see one (until the final close_notify alert). So throttling may often work. But in the general case, sooner or later you'll have to buffer at the application level.

Michael Wojcik
Distinguished Engineer, Micro Focus



From openssl at jordan.maileater.net  Sat May 19 18:07:50 2018
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Sat, 19 May 2018 11:07:50 -0700
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
 <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>
 <SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <2c6c0689-686a-d8cd-d99b-91c64a5859e8@jordan.maileater.net>

On 5/19/2018 6:51 AM, Michael Wojcik wrote:
> Right. And TCP is an ordered byte-stream protocol. That means to
> receive a control message from the peer, the local stack *must* have
> received everything transmitted prior to it. (Modulo SACK, but SACK'd
> data preceeded by a gap is invisible to the application, so we should
> ignore it.)

And yet TCP itself moves ACKs when there's no window available.

TLS could (but as far as I can tell does not) have such a mechanism.? It
could have a window, like TCP, where the receiver would say "you can
send me 64K of data", and the sender wouldn't be allowed to send data
(but could send control messages) when that window is exhausted, until
the receiver reopens the window.? It could have control messages like
XON and XOFF that say "please stop sending me data (but control is OK)"
and "resume sending data".

Each scheme has its problems (mostly around how much data can be in
flight at any one time), but they're both clearly possible.

It does seem like some sort of flow control would be desirable, so that
the receiver doesn't have to have some way to handle arbitrarily large
amounts of data to keep the connection healthy.

Maybe in TLS 1.4.

-- 
Jordan Brown, Oracle Solaris

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

From alexhultman at gmail.com  Sat May 19 18:15:21 2018
From: alexhultman at gmail.com (Alex H)
Date: Sat, 19 May 2018 20:15:21 +0200
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <2c6c0689-686a-d8cd-d99b-91c64a5859e8@jordan.maileater.net>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
 <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>
 <SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com>
 <2c6c0689-686a-d8cd-d99b-91c64a5859e8@jordan.maileater.net>
Message-ID: <CAHPaHkoaC1+nq-dJPzEG=wb_TwtQuSJOL5j0qPGw3aG+wNS3hQ@mail.gmail.com>

Yeah TCP is really the same as TLS in terms of being "bidirectional". Even
if you stop polling for readable and never call recv, you will still
receive ACKS for whatever you write.

A receive window for TLS implemented completely ontop of TCP would solve
this issue and allow applications to truly throttle data receives without
hindering their own writes or forcing them to buffer up data.

2018-05-19 20:07 GMT+02:00 Jordan Brown <openssl at jordan.maileater.net>:

> On 5/19/2018 6:51 AM, Michael Wojcik wrote:
>
> Right. And TCP is an ordered byte-stream protocol. That means to receive a
> control message from the peer, the local stack *must* have received
> everything transmitted prior to it. (Modulo SACK, but SACK'd data preceeded
> by a gap is invisible to the application, so we should ignore it.)
>
>
> And yet TCP itself moves ACKs when there's no window available.
>
> TLS could (but as far as I can tell does not) have such a mechanism.  It
> could have a window, like TCP, where the receiver would say "you can send
> me 64K of data", and the sender wouldn't be allowed to send data (but could
> send control messages) when that window is exhausted, until the receiver
> reopens the window.  It could have control messages like XON and XOFF that
> say "please stop sending me data (but control is OK)" and "resume sending
> data".
>
> Each scheme has its problems (mostly around how much data can be in flight
> at any one time), but they're both clearly possible.
>
> It does seem like some sort of flow control would be desirable, so that
> the receiver doesn't have to have some way to handle arbitrarily large
> amounts of data to keep the connection healthy.
>
> Maybe in TLS 1.4.
>
> --
> Jordan Brown, Oracle Solaris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/60bdf90a/attachment.html>

From Michael.Wojcik at microfocus.com  Sat May 19 19:42:20 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sat, 19 May 2018 19:42:20 +0000
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <2c6c0689-686a-d8cd-d99b-91c64a5859e8@jordan.maileater.net>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
 <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>
 <SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com>
 <2c6c0689-686a-d8cd-d99b-91c64a5859e8@jordan.maileater.net>
Message-ID: <SN1PR18MB21121F86F9B874C30C78F2CCF9970@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: Jordan Brown [mailto:openssl at jordan.maileater.net]
> Sent: Saturday, May 19, 2018 14:08
> To: openssl-users at openssl.org; Michael Wojcik; Alex H
> Subject: Re: [openssl-users] Receive throttling on SSL sockets

> TLS could (but as far as I can tell does not) have such a mechanism.  It could have a window, like TCP, where the receiver
> would say "you can send me 64K of data", and the sender wouldn't be allowed to send data (but could send control
> messages) when that window is exhausted, until the receiver reopens the window.  It could have control messages like
> XON and XOFF that say "please stop sending me data (but control is OK)" and "resume sending data".

Hey, if we're all bored with reinventing TCP on top of UDP, we can reinvent TCP on top of TCP!

> It does seem like some sort of flow control would be desirable, so that the receiver doesn't have to have some way to
> handle arbitrarily large amounts of data to keep the connection healthy.
> Maybe in TLS 1.4.

Good lord, isn't TLS complicated enough already? How many pages is the new edition of /Bulletproof TLS/? (I don't know because I have it in Kindle form. But it's long. Loooooong.)

Flow control really, really, *really* seems like an application-layer task to me in the case of TLS. I think adding it to TLS itself would be a mistake.

Michael Wojcik
Distinguished Engineer, Micro Focus




From alexhultman at gmail.com  Sat May 19 19:53:13 2018
From: alexhultman at gmail.com (Alex H)
Date: Sat, 19 May 2018 21:53:13 +0200
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <SN1PR18MB21121F86F9B874C30C78F2CCF9970@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
 <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>
 <SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com>
 <2c6c0689-686a-d8cd-d99b-91c64a5859e8@jordan.maileater.net>
 <SN1PR18MB21121F86F9B874C30C78F2CCF9970@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <CAHPaHkpMgvzgmWQRg0aRByKW5SbRV=6__jsg0CSKG31koS_NKQ@mail.gmail.com>

>  Flow control really, really, *really* seems like an application-layer
task to me in the case of TLS. I think adding it to TLS itself would be a
mistake.

This whole thread of messages kind of already concluded that this is not
possible currently. You simply cannot implement proper flow control since
doing so would potentially throttle writes, not just reads. You need a TLS
data window to do it properly.

2018-05-19 21:42 GMT+02:00 Michael Wojcik <Michael.Wojcik at microfocus.com>:

> > From: Jordan Brown [mailto:openssl at jordan.maileater.net]
> > Sent: Saturday, May 19, 2018 14:08
> > To: openssl-users at openssl.org; Michael Wojcik; Alex H
> > Subject: Re: [openssl-users] Receive throttling on SSL sockets
>
> > TLS could (but as far as I can tell does not) have such a mechanism.  It
> could have a window, like TCP, where the receiver
> > would say "you can send me 64K of data", and the sender wouldn't be
> allowed to send data (but could send control
> > messages) when that window is exhausted, until the receiver reopens the
> window.  It could have control messages like
> > XON and XOFF that say "please stop sending me data (but control is OK)"
> and "resume sending data".
>
> Hey, if we're all bored with reinventing TCP on top of UDP, we can
> reinvent TCP on top of TCP!
>
> > It does seem like some sort of flow control would be desirable, so that
> the receiver doesn't have to have some way to
> > handle arbitrarily large amounts of data to keep the connection healthy.
> > Maybe in TLS 1.4.
>
> Good lord, isn't TLS complicated enough already? How many pages is the new
> edition of /Bulletproof TLS/? (I don't know because I have it in Kindle
> form. But it's long. Loooooong.)
>
> Flow control really, really, *really* seems like an application-layer task
> to me in the case of TLS. I think adding it to TLS itself would be a
> mistake.
>
> Michael Wojcik
> Distinguished Engineer, Micro Focus
>
>
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/0567b9a2/attachment.html>

From openssl at jordan.maileater.net  Sat May 19 20:18:10 2018
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Sat, 19 May 2018 13:18:10 -0700
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <SN1PR18MB21121F86F9B874C30C78F2CCF9970@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
 <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>
 <SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com>
 <2c6c0689-686a-d8cd-d99b-91c64a5859e8@jordan.maileater.net>
 <SN1PR18MB21121F86F9B874C30C78F2CCF9970@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <bdea5d0d-b6e2-fd24-dd6f-03cd455f6f16@jordan.maileater.net>

I should make it clear that I don't have a stake here.? Lack of flow
control hasn't caused me problems personally, and I'm not responsible
for implementing and maintaining a TLS infrastructure.? This is purely
an intellectual exercise for me.

There were comments suggesting that, because TLS is an
ordered-byte-stream protocol that needs control messages in both
directions at all times, TLS couldn't support flow control.? That seems
clearly wrong; it clearly could.? (As you say, we could just layer TCP
on top of it.)

Should it?? My mild feeling is "yes", since it's already got a record
and control message structure and so it wouldn't be necessary to invent
another protocol on top of it.? Yes, that makes TLS more complicated,
but would it be any more complicated than an additional
application-visible layer would be?? It seems like the answer is that
any complexity from a TLS-layer implementation would be primarily in the
TLS implementation, whereas an additional layer would necessarily impose
complexity on the application, over and above the complexity of the flow
control implementation itself.

-- 
Jordan Brown, Oracle Solaris

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

From levitte at openssl.org  Sun May 20 07:27:30 2018
From: levitte at openssl.org (Richard Levitte)
Date: Sun, 20 May 2018 09:27:30 +0200 (CEST)
Subject: [openssl-users] test make_verify fails on brand new red hat
 enterprise 7 box
In-Reply-To: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>
References: <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA@mail.gmail.com>
Message-ID: <20180520.092730.543276058398739915.levitte@openssl.org>

You need to do this in the top directory first:

    make rehash

Cheers,
Richard

In message <CAOPjdVOmXSHuM5yfNnN_Vm85AysGDSj41jKGd5ZKAZ7jL75LDA at mail.gmail.com> on Fri, 18 May 2018 11:22:14 -0400, Philippe Anctil <philippe.anctil at gmail.com> said:

philippe.anctil> Hi,
philippe.anctil> 
philippe.anctil> I have been compiling openssl libraries on RHEL5 for
philippe.anctil> a while without issue. My build for 1.0.2k fails on a
philippe.anctil> new RHEL7 server. I have narrowed down the cause to
philippe.anctil> the make_verify test.
philippe.anctil> 
philippe.anctil> make verify_test # from test dir
philippe.anctil> 
philippe.anctil> The following command should have some OK's and some failures
philippe.anctil> There are definitly a few expired certificates
philippe.anctil> ../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo ../certs/demo/*.pem
philippe.anctil> ../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test CA (1024
philippe.anctil> bit)
philippe.anctil> error 20 at 0 depth lookup:unable to get local issuer certificate
philippe.anctil> ../certs/demo/dsa-ca.pem: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = CA
philippe.anctil> error 20 at 0 depth lookup:unable to get local issuer certificate
philippe.anctil> 140692788688576:error:0B06E06B:x509 certificate routines:X509_get_pubkey_parameters:unable
philippe.anctil> to find parameters in chain:x509_vfy.c:2108:
philippe.anctil> ../certs/demo/dsa-pca.pem: C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = PCA
philippe.anctil> error 18 at 0 depth lookup:self signed certificate
philippe.anctil> C = AU, ST = Some-State, O = Internet Widgits Pty Ltd, CN = PCA
philippe.anctil> error 10 at 0 depth lookup:certificate has expired
philippe.anctil> OK
philippe.anctil> ../certs/demo/pca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024
philippe.anctil> bit)
philippe.anctil> error 18 at 0 depth lookup:self signed certificate
philippe.anctil> C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024 bit)
philippe.anctil> error 10 at 0 depth lookup:certificate has expired
philippe.anctil> OK
philippe.anctil> make: *** [test_verify] Error 2
philippe.anctil> 
philippe.anctil> It seems to boil down to the following
philippe.anctil> 
philippe.anctil> OPENSSL_CONF= LD_LIBRARY_PATH=.. ../apps/openssl verify -CApath ../certs/demo
philippe.anctil> ../certs/demo/ca-cert.pem
philippe.anctil> 
philippe.anctil> WARNING: can't open config file:
philippe.anctil> ../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test CA (1024
philippe.anctil> bit)
philippe.anctil> error 20 at 0 depth lookup:unable to get local issuer certificate
philippe.anctil> 
philippe.anctil> echo $?
philippe.anctil> 
philippe.anctil> 2
philippe.anctil> 
philippe.anctil> Doing the same on my RHEL5 box.
philippe.anctil> 
philippe.anctil> OPENSSL_CONF= LD_LIBRARY_PATH=.. ../apps/openssl verify -CApath ../certs/demo
philippe.anctil> ../certs/demo/ca-cert.pem
philippe.anctil> WARNING: can't open config file:
philippe.anctil> ../certs/demo/ca-cert.pem: C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test PCA (1024
philippe.anctil> bit)
philippe.anctil> error 10 at 1 depth lookup:certificate has expired
philippe.anctil> C = AU, ST = Queensland, O = CryptSoft Pty Ltd, CN = Test CA (1024 bit)
philippe.anctil> error 10 at 0 depth lookup:certificate has expired
philippe.anctil> OK
philippe.anctil> 
philippe.anctil> echo $?
philippe.anctil> 
philippe.anctil> 0
philippe.anctil> 
philippe.anctil> Any clue why openssl verify does not work on RHEL7?
philippe.anctil> ca-cert.pem is issued by pca-cert.pem (matching Authority Key Identifier). Both are under
philippe.anctil> ../certs/demo.
philippe.anctil> 
philippe.anctil> Thanks.
philippe.anctil> 
philippe.anctil> --
philippe.anctil> Philippe Anctil

From Michael.Wojcik at microfocus.com  Sun May 20 15:23:19 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Sun, 20 May 2018 15:23:19 +0000
Subject: [openssl-users] Receive throttling on SSL sockets
In-Reply-To: <CAHPaHkpMgvzgmWQRg0aRByKW5SbRV=6__jsg0CSKG31koS_NKQ@mail.gmail.com>
References: <CAHPaHkpmpzLKAwFbjzWmpswVd9irAkcUzRM+zWrbthSRcucnJQ@mail.gmail.com>
 <5065C45C-83C3-40D9-8914-EF85D77805D3@akamai.com>
 <CAHPaHkoPQbJz15ZseEwBCVLK-7EEppjvb5xGEdJYQ6fq8--SHw@mail.gmail.com>
 <DA85C83F-2A17-4DD8-BC10-D1D06394D401@akamai.com>
 <SN1PR18MB2112A9B914F9C2254DD726B0F9970@SN1PR18MB2112.namprd18.prod.outlook.com>
 <2c6c0689-686a-d8cd-d99b-91c64a5859e8@jordan.maileater.net>
 <SN1PR18MB21121F86F9B874C30C78F2CCF9970@SN1PR18MB2112.namprd18.prod.outlook.com>
 <CAHPaHkpMgvzgmWQRg0aRByKW5SbRV=6__jsg0CSKG31koS_NKQ@mail.gmail.com>
Message-ID: <SN1PR18MB2112845A8035BFF5B41078A6F9960@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Alex H
> Sent: Saturday, May 19, 2018 15:53
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] Receive throttling on SSL sockets

> >  Flow control really, really, *really* seems like an application-layer task to me in the case of TLS. I think adding it to TLS
> > itself would be a mistake.

> This whole thread of messages kind of already concluded that this is not possible currently.

I don't believe it did. It concluded that the server can't impose flow control by itself.

> You simply cannot implement proper flow control since doing so would potentially throttle writes, not just reads. You
> need a TLS data window to do it properly.

If the client and server both participate in flow control - that is, if they implement the window announcements and output throttling at the application level - then there's no need to do it in TLS.

A cooperating client and server can implement any sort of traffic shaping they want.

What's not possible in TLS is throttling implemented solely by one side, without cooperation from the peer application.


In any case, this has drifted far afield from the purpose of openssl-users. I pesonally don't think flow control should be part of TLS, but I don't care strongly enough to, for example, argue against it on the IETF TLS mailing list.

Michael Wojcik
Distinguished Engineer, Micro Focus




From marazewskajoanna at gmail.com  Mon May 21 18:22:07 2018
From: marazewskajoanna at gmail.com (Joanna Marazewska)
Date: Mon, 21 May 2018 20:22:07 +0200
Subject: [openssl-users] (no subject)
Message-ID: <CAB+wj=JqLHUg0Vwkm5e6-sbUw0MaOEQmUswjEZz6qDGC+PwqOw@mail.gmail.com>


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

From Michal.Trojnara at stunnel.org  Mon May 21 21:35:39 2018
From: Michal.Trojnara at stunnel.org (Michal Trojnara)
Date: Mon, 21 May 2018 23:35:39 +0200
Subject: [openssl-users] stunnel 5.45 released
Message-ID: <839876ee-89a9-0d5f-ddbc-af63e130cd9c@stunnel.org>

Dear Users,

I have released version 5.45 of stunnel.

Version 5.45, 2018.05.21, urgency: MEDIUM
* New feature sponsored by https://loadbalancer.org/
  - Implemented delayed deallocation of service sections
    after configuration file reload.
* Other new features
  - OpenSSL DLLs updated to version 1.0.2o.
  - Deprecated the sslVersion option.
  - The "socket" option is now also available in service sections.
  - Implemented try-restart in the SysV init script (thx to
    Peter Pentchev).
  - TLS 1.3 compliant session handling for OpenSSL 1.1.1.
  - Default "failover" value changed from "rr" to "prio".
  - New "make check" tests.
* Bugfixes
  - A service no longer refuses to start if binding fails for
    some (but not all) addresses:ports.
  - Fixed compression handling with OpenSSL 1.1.0 and later.
  - _beginthread() replaced with safer _beginthreadex().
  - Fixed exception handling in libwrap.
  - Fixed exec+connect services.
  - Fixed automatic resolver delaying.
  - Fixed a Gentoo cross-compilation bug (thx to Joe Harvell).
  - A number of "make check" framework fixes.
  - Fixed false postive memory leak logs.
  - Build fixes for OpenSSL versions down to 0.9.7.
  - Fixed (again) round-robin failover in the FORK threading model.

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

SHA-256 hashes:
548244839b8a4bf4dffea46c97893b203d1b9eed118c3dd6a9ac4d8d02592ee3
stunnel-5.45.tar.gz
fc13a224c7ec1290035efe8317c53d62a0980a5ab2efe8930b06aae269fbe873
stunnel-5.45-win32-installer.exe
29025eaed007c62856f16c7a8a22f9713eee9762ed95009f6f91f729c35c0bc0
stunnel-5.45-android.zip

Best regards,
    Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180521/90daee07/attachment.sig>

From luis.pinto.martins at gmail.com  Mon May 21 21:34:11 2018
From: luis.pinto.martins at gmail.com (=?UTF-8?Q?Lu=C3=ADs_Martins?=)
Date: Mon, 21 May 2018 22:34:11 +0100
Subject: [openssl-users] Build Openssl + FIPS - recursive fipsld
Message-ID: <CAHeZdFy0OGf35DDRZNN8DqnCUTo0dVDhmo3voVxRPHFAmzYDoQ@mail.gmail.com>

Hi,

    I'm trying to build openssl with FIPS module on Ubuntu 14.04 32 bits,
but during one of the steps the fipsld tool starts being called recursively.

    It happens on this step:
sh -c ( :; LIBDEPS="${LIBDEPS:--L.. -lssl  -L.. -lcrypto -ldl
-L/usr/local/lib -lz}";
LDCMD="${LDCMD:-/usr/local/ssl/fips2.0/bin/fipsld}";
LDFLAGS="${LDFLAGS:--DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
-DHAVE_DLFCN_H -fPIC -O3 -fomit-frame-pointer -Wall
-I/usr/local/ssl/fips2.0/include}"; LIBPATH=`for x in $LIBDEPS; do echo $x;
done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e
's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS}
-o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o
dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o
rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o
s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o
version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o
pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o
${LIBDEPS} )
fipsld -e /usr/local/ssl/fips2.0/bin/fipsld -DZLIB -DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -O3 -fomit-frame-pointer
-Wall -I/usr/local/ssl/fips2.0/include -o openssl openssl.o verify.o
asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o
pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o
x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o
apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto -ldl
-L/usr/local/lib -lz
fipsld -e /usr/local/ssl/fips2.0/bin/fipsld
/usr/local/ssl/fips2.0/lib//fipscanister.o
/usr/local/ssl/fips2.0/lib/fips_premain.c -DZLIB -DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -O3 -fomit-frame-pointer
-Wall -I/usr/local/ssl/fips2.0/include -o openssl openssl.o verify.o
asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o
pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o
x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o
apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto -ldl
-L/usr/local/lib -lz
fipsld -e /usr/local/ssl/fips2.0/bin/fipsld
/usr/local/ssl/fips2.0/lib/fips_premain.c
/usr/local/ssl/fips2.0/lib//fipscanister.o
/usr/local/ssl/fips2.0/lib/fips_premain.c -DZLIB -DOPENSSL_THREADS
-D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fPIC -O3 -fomit-frame-pointer
-Wall -I/usr/local/ssl/fips2.0/include -o openssl openssl.o verify.o
asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o
pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o
x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o
apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o
pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o
engine.o ocsp.o prime.o ts.o srp.o -L.. -lssl -L.. -lcrypto -ldl
-L/usr/local/lib -lz

    It keeps calling fipsld recursively, with each call adding one more
"/usr/local/ssl/fips2.0/lib/fips_premain.c" to the command.
    Any idea what am I missing ?

    My build steps are:

export FIPSDIR="/usr/local/ssl/fips2.0"
export MACHINE=linux-generic32
export CC="/usr/local/ssl/fips2.0/bin/fipsld"
export FIPSLD_CC="gcc"
export FIPS_SIG="/tmp/openssl-fips-2.0.16/util/incore"

# build openssl fips module
cd /tmp/
curl -O https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz
gunzip -c openssl-fips-2.0.16.tar.gz | tar xf -
cd openssl-fips-2.0.16
./config
make
make install

# build openssl
cd /tmp
curl -O https://www.openssl.org/source/openssl-1.0.2n.tar.gz
tar -zxf openssl-1.0.2n.tar.gz
cd /tmp/openssl-1.0.2n
./Configure \
    --prefix=/usr/local \
    linux-generic32 \
    -fPIC \
    no-shared \
    no-capieng \
    fips \
    --with-fipsdir="/usr/local/ssl/fips2.0" \
    zlib \
    no-zlib-dynamic \
    --with-zlib-include="/usr/local/include" \
    --with-zlib-lib="/usr/local/lib"
make all -j1
make build_libs

--
Lu?s
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180521/7bfbcd28/attachment-0001.html>

From chetan.quest at gmail.com  Wed May 23 02:52:45 2018
From: chetan.quest at gmail.com (Chetan Quest)
Date: Wed, 23 May 2018 08:22:45 +0530
Subject: [openssl-users] RC5 Incompatibility Issue
Message-ID: <CAKZV2gsRPk+_+g2KzmN7QzakD70DkJaR0iMUqd9YvVvtofa2FQ@mail.gmail.com>

Hi OpenSSL users,


I am working in a project to replace my old third party crypto library with
openSSL crypto library. I have requirement to maintain the compatibility
across the library. i.e. any IP encrypted with older crypto library should
be decrypted by openSSL library. I am facing issue in RC5 algorithm even if
I am using all the parameters (word size, rounds and key length) same. The
older library currently in use is RSA library. They are out of business now
and I have to replace it with openSSL.


OpenSSL library being used is: openssl-1.1.0-stable-SNAP-20180501


Please let me know if I am missing something (any setting/ unknown
parameter etc) or if there is an issue with RC5. Any pointer in this
direction is really appreciated.


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

From redpath at us.ibm.com  Wed May 23 10:41:51 2018
From: redpath at us.ibm.com (redpath)
Date: Wed, 23 May 2018 03:41:51 -0700 (MST)
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness of PK
Message-ID: <1527072111537-0.post@n7.nabble.com>

My question is:
   I have this handy function to create a Private and Public key
But what is the magic I put around it to make sure it is random not the same
Private and Public key when I run this program each time?

I am using openSSL on OSX and Android. I am not familiar with the random API
seeding
though I can pick the UUID of the device or whatever.

* I am sure there is some standard call unless of course the Initialization
of openSSL does the random seed nicely?*

Thanks in advance.



===========
/**
 * Compile for testmipluginSecurity.c
 * Self Testing
 *   cc -o main -DTEST -Wno-deprecated-declarations main.c -lcrypto

 * Origin: r redpath
 * Project: wouldn't you like to know
 ************************/
#include <string.h>
#include <stdlib.h>
#include <memory.h>
#include <stdio.h>

#include <openssl/bio.h>
#include <openssl/ssl.h>
#include <openssl/err.h>
#include <openssl/pem.h>
#include <openssl/conf.h>
#include <openssl/x509v3.h>
#include <openssl/rand.h>
#include <openssl/aes.h>
/**
#ifndef OPENSSL_NO_ENGINE
#include <openssl/engine.h>
#endif
**/

void init_openssl(void){

    ERR_load_BIO_strings();
    ERR_load_crypto_strings();
    OpenSSL_add_all_algorithms();
    OpenSSL_add_all_ciphers();
    OpenSSL_add_all_digests();
}


/****************
 * Create Public and Private Key and return the PEMs as string data
 * origin: redpath
PEM_write_bio_PUBKEY (Traditional PEM format). Notice BEGIN PUBLIC KEY
PEM_write_bio_RSAPublicKey (PKCS PEM format). Notice BEGIN RSA PUBLIC KEY

PEM_write_bio_PrivateKey (PEM). Notice BEGIN PRIVATE KEY
PEM_write_bio_PKCS8PrivateKey (PEM). Notice BEGIN PRIVATE KEY
PEM_write_bio_RSAPrivateKey (PEM). Notice BEGIN RSA PRIVATE KEY
 *****************/
void createRSAkeyPair(char **private, char **public){
   EVP_PKEY* evp= EVP_PKEY_new();
   RSA      *rsa= RSA_generate_key(2048,RSA_F4,NULL,NULL);
   int    keylen;
   char *pem_key;

   EVP_PKEY_assign_RSA(evp,rsa);
    BIO *bio = BIO_new(BIO_s_mem());
      PEM_write_bio_RSAPrivateKey(bio, rsa, NULL, NULL, 0, NULL, NULL);
      keylen = BIO_pending(bio);
      pem_key = calloc(keylen+1, 1); /* Null-terminate */
      BIO_read(bio, pem_key, keylen);
      *private = pem_key;
    BIO_free(bio);

    bio = BIO_new(BIO_s_mem());
      //PEM_write_bio_RSAPublicKey(bio,rsa); // (PKCS PEM format).
      PEM_write_bio_PUBKEY(bio, evp);  //(Traditional PEM format).
      keylen = BIO_pending(bio);
      pem_key = calloc(keylen+1, 1); /* Null-terminate */
      BIO_read(bio, pem_key, keylen);
      *public = pem_key;
    BIO_free(bio);
    EVP_PKEY_free(evp);
}


#if defined TEST

int main(int argc, char **argv){
   unsigned char key[16];
   unsigned char iv[16];
   char *private, *public;
   X509 *x;
   char *pem;
   size_t g_length;

   init_openssl();
   
   createRSAkeyPair(&private, &public);
   printf("%s",private);
   printf("\n\n");
   printf("%s",public);

}

#endif



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

From john.sha.jiang at gmail.com  Wed May 23 11:39:05 2018
From: john.sha.jiang at gmail.com (John Jiang)
Date: Wed, 23 May 2018 19:39:05 +0800
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <20180429104326.GA21314@roeckx.be>
References: <20180429104326.GA21314@roeckx.be>
Message-ID: <CAJbO6CQPpPM10JGKdN1msxQHr92Y0Go6kqNUch4JhprE6TTQog@mail.gmail.com>

Hi,
If just using s_server and s_client, can I test the TLS 1.3 features, likes
HelloRetryRequest and resumption?

2018-04-29 18:43 GMT+08:00 Kurt Roeckx <kurt at roeckx.be>:

> The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> 1.3 brings a lot of changes that might cause incompatibility. For
> an overview see https://wiki.openssl.org/index.php/TLS1.3
>
> We are considering if we should enable TLS 1.3 by default or not,
> or when it should be enabled. For that, we would like to know how
> applications behave with the latest beta release.
>
> When testing this, it's important that both sides of the
> connection support the same TLS 1.3 draft version. OpenSSL
> currently implements draft 26. We would like to see tests
> for OpenSSL acting as client and server.
>
> https://github.com/tlswg/tls13-spec/wiki/Implementations lists
> other TLS 1.3 implementations and the draft they currently
> support. Note that the versions listed there might not be for the
> latest release. It also lists some https test servers.
>
> We would really like to see a diverse set of applictions being
> tested. Please report any results you have to us.
>
>
> Kurt
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180523/d9c836f2/attachment.html>

From matt at openssl.org  Wed May 23 12:33:36 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 23 May 2018 13:33:36 +0100
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <CAJbO6CQPpPM10JGKdN1msxQHr92Y0Go6kqNUch4JhprE6TTQog@mail.gmail.com>
References: <20180429104326.GA21314@roeckx.be>
 <CAJbO6CQPpPM10JGKdN1msxQHr92Y0Go6kqNUch4JhprE6TTQog@mail.gmail.com>
Message-ID: <aa3c3d55-8a88-0be5-ef2f-6c3da0b0f99b@openssl.org>



On 23/05/18 12:39, John Jiang wrote:
> Hi,
> If just using s_server and s_client, can I test the TLS 1.3 features,
> likes HelloRetryRequest and resumption?

Yes.

To create a normal (full handshake) TLSv1.3 connection just use
s_server/s_client in the normal way, e.g.

$ openssl s_server -cert cert.pem -key key.pem
$ openssl s_client

To test resumption first create a full handshake TLSv1.3 connection and
save the session:

$ openssl s_server -cert cert.pem -key key.pem
$ openssl s_client -sess_out session.pem

Close the s_client instance by entering "Q" followed by enter. Then
(without closing the s_server instance) resume the session:

$ openssl s_client -sess_in session.pem


A HelloRetryRequest will occur if the key share provided by the client
is not acceptable to the server. By default the client will send an
X25519 key share, so if the server does not accept that group then an
HRR will result, e.g.

$ openssl s_server -cert cert.pem -key key.pem -groups P-256
$ openssl s_client


Of course a HelloRetryRequest all happens at the protocol layer and is
invisible as far as a user of the command line apps is concerned. You
will have to look at what happens "on the wire" to actually see it in
action - for example by using wireshark. Alternatively you can compile
OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag
to s_server or s_client to see what protocol messages are being exchanged.

Matt



> 
> 2018-04-29 18:43 GMT+08:00 Kurt Roeckx <kurt at roeckx.be
> <mailto:kurt at roeckx.be>>:
> 
>     The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>     1.3 brings a lot of changes that might cause incompatibility. For
>     an overview see https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>
> 
>     We are considering if we should enable TLS 1.3 by default or not,
>     or when it should be enabled. For that, we would like to know how
>     applications behave with the latest beta release.
> 
>     When testing this, it's important that both sides of the
>     connection support the same TLS 1.3 draft version. OpenSSL
>     currently implements draft 26. We would like to see tests
>     for OpenSSL acting as client and server.
> 
>     https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations> lists
>     other TLS 1.3 implementations and the draft they currently
>     support. Note that the versions listed there might not be for the
>     latest release. It also lists some https test servers.
> 
>     We would really like to see a diverse set of applictions being
>     tested. Please report any results you have to us.
> 
> 
>     Kurt
> 
>     -- 
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 
> 

From matt at openssl.org  Wed May 23 13:19:07 2018
From: matt at openssl.org (Matt Caswell)
Date: Wed, 23 May 2018 14:19:07 +0100
Subject: [openssl-users] Facing issue while reading RSA private key (DER
	format)
In-Reply-To: <3FA58A84-AD1B-47BC-8D62-64989AD06998@contoso.com>
References: <3FA58A84-AD1B-47BC-8D62-64989AD06998@contoso.com>
Message-ID: <cda341ff-db16-8cca-91bf-2a0f72d7a0dd@openssl.org>



On 23/05/18 12:10, Ruchi Tyagi wrote:
> Hi,
> 
> ?
> 
> I am working on a project where we are trying to Replace RSA Bsafe
> crypto C library with openssl. I have a RSA key pair (attaching the key
> files) generated using RSA Bsafe library.
> 
> I am ?able to read the public key using the below call
> 
> ?
> 
> rsa = d2i_RSA_PUBKEY(NULL, &public_key_bytes, public_key_length);

RSA public keys typically come in either PKCS#1 format or
SubjectPublicKeyInfo format. You need to ensure you use the correct
function for the format. Your public key is in SubjectPublicKeyInfo
format, and this is the correct function for reading that format - so it
succeeds.

> 
> ?
> 
> but while decryption , I am getting NULL ?rsa? .
> 
> ?
> 
> rsa = d2i_RSAPrivateKey(NULL, &p, size);

RSA private keys typically come in either traditional or PKCS#8 format.
Your private key is in PKCS#8 format, but this function is for reading
traditional format keys - hence the failure.

If you use the function d2i_AutoPrivateKey() then it will automatically
try to detect the format. It returns an EVP_PKEY *object which is the
preferred internal object for working with public/private keys. If you
must have it as an "RSA *" object you can do that with
EVP_PKEY_get1_RSA() (or EVP_PKEY_get0_RSA() if you don't want to up the
ref count on the RSA object).

Matt


> 
> ?
> 
> ?
> 
> It seems that I am not using the right call or missing something.
> 
> ?
> 
> Please help me in resolving this issue.
> 
> ?
> 
> Thanks & Regards,
> 
> Ruchi
> 
> 
> 
> _______________________________________________
> osf-contact mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/osf-contact
> 

From redpath at us.ibm.com  Wed May 23 16:54:22 2018
From: redpath at us.ibm.com (redpath)
Date: Wed, 23 May 2018 09:54:22 -0700 (MST)
Subject: [openssl-users] how to seed PRNG
In-Reply-To: <2FE443C983E334469F56B9FB09CFD32A014B4ABE@SMBFISBOM01.FNFIS.COM>
References: <2FE443C983E334469F56B9FB09CFD32A014B4ABE@SMBFISBOM01.FNFIS.COM>
Message-ID: <1527094462466-0.post@n7.nabble.com>

Ya me too did you ever get the info on this?



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

From redpath at us.ibm.com  Wed May 23 17:08:01 2018
From: redpath at us.ibm.com (redpath)
Date: Wed, 23 May 2018 10:08:01 -0700 (MST)
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness
	of PK
In-Reply-To: <1527072111537-0.post@n7.nabble.com>
References: <1527072111537-0.post@n7.nabble.com>
Message-ID: <1527095281847-0.post@n7.nabble.com>

SO if I add this RAND usage below, em I seeding to assure a different RSA key
pair each time run of
creating a RSA pair.

I would certainly replace the time with the UUID of the device to be unique
to the device.
You would have to acquire the device to know the seeding. Hey  keep the Time
one too.

void init_openssl(void){
    if (initialized!=0)
      return;
    initialized= 1;
    ERR_load_BIO_strings();
    ERR_load_crypto_strings();
    OpenSSL_add_all_algorithms();
    OpenSSL_add_all_ciphers();
    OpenSSL_add_all_digests();

    unsigned long Time=(unsigned long)time(NULL);
    RAND_add(&Time,sizeof(Time),0);  //better than nothing for a starting
point
}



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

From openssl-users at dukhovni.org  Wed May 23 17:33:18 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 23 May 2018 13:33:18 -0400
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness
 of PK
In-Reply-To: <1527095281847-0.post@n7.nabble.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
Message-ID: <B2EA16A3-2274-4B8F-8672-C24D630C3A8C@dukhovni.org>



> On May 23, 2018, at 1:08 PM, redpath <redpath at us.ibm.com> wrote:
> 
> SO if I add this RAND usage below, em I seeding to assure a different RSA key
> pair each time run of
> creating a RSA pair.
> 
> I would certainly replace the time with the UUID of the device to be unique
> to the device.
> You would have to acquire the device to know the seeding. Hey  keep the Time
> one too.

NO.  Seeding exclusively in this way is a terrible idea and MUST NOT be
done.  You need considerably more randomness than found in a timestamp
or a device serial number.

It is not enough for keys to be unique, they need to be computationally
unpredictable.

If the device is generating keys it needs a decent source of randomness.
Otherwise, keys might need to be generated elsewhere and loaded onto the
device.

-- 
-- 
	Viktor.


From rsalz at akamai.com  Wed May 23 18:20:40 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 23 May 2018 18:20:40 +0000
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness
 of PK
In-Reply-To: <1527095281847-0.post@n7.nabble.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
Message-ID: <A1C6CBE7-4AEF-4DBE-BB8D-623DC0EFFA8C@akamai.com>

What version of OpenSSL are you using?

Using the time to seed the RNG is horrible; DO NOT DO THAT.

Not trying to be insulting, but if you think time is a good source, then you really don't know what you're doing for RNG's.  Consider looking at the master branch, with its highly-improve seeding and RNG code.


From Michael.Wojcik at microfocus.com  Wed May 23 18:39:29 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 23 May 2018 18:39:29 +0000
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure
 Randomness	of PK
In-Reply-To: <1527095281847-0.post@n7.nabble.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
Message-ID: <SN1PR18MB211287AFC01F53C9B1803588F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of redpath
> Sent: Wednesday, May 23, 2018 13:08
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] PEM_write_bio_RSAPrivateKey assure
> Randomness of PK
>
> SO if I add this RAND usage below, em I seeding to assure a different RSA key
> pair each time run of creating a RSA pair.

You'll get a *different* key pair (with high probability) each time, provided you wait at least a second between generating keys. That is, if you get anything at all; you may not, if there isn't enough entropy in the pool.

You'll also get completely pointless keys, because the wall-clock time contains little entropy.

As Viktor wrote: DO NOT DO THIS. If you don't understand why, stop trying to use cryptography until you've learned enough about the subject to be a bit less dangerous.

> I would certainly replace the time with the UUID of the device to be unique
> to the device. You would have to acquire the device to know the seeding.

Or get the UUID through any other means, such as a malicious app.

And generating two key pairs after seeding with UUID || time means the CPRNG state differs only by the 32 bits in time - and most of those will be the same, unless a *long* time has passed. So the joint information of the pairs is high, which is a Bad Thing.

And UUIDs are only 128 bits, so the total seed size is 160 bits; and neither the UUID nor the time are completely random (far from it), so you only have a small amount of entropy. DO NOT DO THIS.

There's no point in using a real cipher if you're going to starve your CPRNG. Just use a toy cipher - it's less work for you, and you won't be making false promises of security.

If you want to do this right:

1) Learn something about cryptography.
2) Gather sufficient entropy from suitable sources. If nothing else, have the user scribble on the touchscreen and track pointer movement. It's still easy to overestimate the entropy of that sort of thing, but it's better than nothing, and indeed better than what many people do for seeding.

Oh, and asking questions about OpenSSL, a smart move is to mention what version of OpenSSL you're using, platform details, and something about the problem you're trying to solve.

--
Michael Wojcik
Distinguished Engineer, Micro Focus

From public at enkore.de  Wed May 23 18:47:41 2018
From: public at enkore.de (Marian Beermann)
Date: Wed, 23 May 2018 20:47:41 +0200
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness
 of PK
In-Reply-To: <SN1PR18MB211287AFC01F53C9B1803588F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
 <SN1PR18MB211287AFC01F53C9B1803588F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <0276078b-f719-ec92-7a43-61b765eb94cf@enkore.de>

On 23.05.2018 20:39, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of redpath
>> Sent: Wednesday, May 23, 2018 13:08
>> To: openssl-users at openssl.org
>> Subject: Re: [openssl-users] PEM_write_bio_RSAPrivateKey assure
>> Randomness of PK
>>
>> SO if I add this RAND usage below, em I seeding to assure a different RSA key
>> pair each time run of creating a RSA pair.
> 
> You'll get a *different* key pair (with high probability) each time, provided you wait at least a second between generating keys. That is, if you get anything at all; you may not, if there isn't enough entropy in the pool.
> 
> You'll also get completely pointless keys, because the wall-clock time contains little entropy.
> 
> As Viktor wrote: DO NOT DO THIS. If you don't understand why, stop trying to use cryptography until you've learned enough about the subject to be a bit less dangerous.
> 

... if this is code going in the general direction of "production 
deployment", then get a crypto-person on board, or at least get them to 
review and sign off the code. Otherwise this *will* end in a debacle.

-Marian

From redpath at us.ibm.com  Wed May 23 18:52:52 2018
From: redpath at us.ibm.com (redpath)
Date: Wed, 23 May 2018 11:52:52 -0700 (MST)
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure
	Randomness	of PK
In-Reply-To: <SN1PR18MB211287AFC01F53C9B1803588F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
 <SN1PR18MB211287AFC01F53C9B1803588F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <1527101572304-0.post@n7.nabble.com>

Well what I was alluding to is this the correct use of the RAND_add function 
to seed the Key generation. Its a bit confusing certainly. I will use more
than the UUID
of the device but you have to have the device in hand to know that and know
it came from 
a device.

I certainly will use better than time and UUID, just need to know calling
this seed of the rand function
is the right thing to do to effect the  Key generation?

Then second all I need to do is solve the random seeding to be less than a
toy input for entropy, this is just an example that I must use RAND_add

So my correct usage of RAND_add validate? and second I will find a good
input for it.
Just let me know, thanks for taking the quick time to address this.


Thanks




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

From rsalz at akamai.com  Wed May 23 18:59:54 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 23 May 2018 18:59:54 +0000
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness
 of PK
In-Reply-To: <1527101572304-0.post@n7.nabble.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
 <SN1PR18MB211287AFC01F53C9B1803588F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>
 <1527101572304-0.post@n7.nabble.com>
Message-ID: <785C3585-663B-4481-84D2-AED36225E7F9@akamai.com>

>    Well what I was alluding to is this the correct use of the RAND_add function 
    to seed the Key generation. Its a bit confusing certainly.

You are calling the API correctly.  That should have been clear from the manpage.

You still did not tell us what version of OpenSSL you are using.


From redpath at us.ibm.com  Wed May 23 20:01:52 2018
From: redpath at us.ibm.com (redpath)
Date: Wed, 23 May 2018 13:01:52 -0700 (MST)
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness
	of PK
In-Reply-To: <785C3585-663B-4481-84D2-AED36225E7F9@akamai.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
 <SN1PR18MB211287AFC01F53C9B1803588F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>
 <1527101572304-0.post@n7.nabble.com>
 <785C3585-663B-4481-84D2-AED36225E7F9@akamai.com>
Message-ID: <1527105712195-0.post@n7.nabble.com>

Oh I am using 	openssl-1.0.2o just for development

But I certainly will take a recommendation of version. 
Thats always appreciated.



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

From Michael.Wojcik at microfocus.com  Wed May 23 21:54:41 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 23 May 2018 21:54:41 +0000
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure
 Randomness	of PK
In-Reply-To: <1527105712195-0.post@n7.nabble.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
 <SN1PR18MB211287AFC01F53C9B1803588F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>
 <1527101572304-0.post@n7.nabble.com>
 <785C3585-663B-4481-84D2-AED36225E7F9@akamai.com>
 <1527105712195-0.post@n7.nabble.com>
Message-ID: <SN1PR18MB21127CFBB4C13C81D7E672D0F96B0@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of redpath
> Sent: Wednesday, May 23, 2018 16:02
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] PEM_write_bio_RSAPrivateKey assure
> Randomness of PK
>
> Oh I am using         openssl-1.0.2o just for development
>
> But I certainly will take a recommendation of version.

1.0.2 is currently a Long-Term Support (LTS) release, but support ends at the end of 2019. 1.1.1 is the new LTS release, and since 1.1 introduced a number of API changes and new features, I think it's worthwhile moving to 1.1.1 (at the latest fix level) as soon as is convenient.

That said, 1.0.2o is fine as well - just keep in mind that at some point you'll need to change to the 1.1 API, and you may need to move sooner to get features you want. As Rich mentioned, 1.1 has some improvements regarding random seeding, so it may be worth doing that now.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From wiml at omnigroup.com  Wed May 23 22:43:35 2018
From: wiml at omnigroup.com (Wim Lewis)
Date: Wed, 23 May 2018 15:43:35 -0700
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness
	of PK
In-Reply-To: <1527095281847-0.post@n7.nabble.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
Message-ID: <DA508E21-6FC2-4E90-9993-17EFAB245BDD@omnigroup.com>


On 23. ma? 2018, at 10:08 f.h., redpath <redpath at us.ibm.com> wrote:
> SO if I add this RAND usage below, em I seeding to assure a different RSA key
> pair each time run of creating a RSA pair.
> 
> I would certainly replace the time with the UUID of the device to be unique
> to the device. You would have to acquire the device to know the seeding. Hey  keep the Time
> one too.


Attempting to provide a more useful response ...

That is the right way to add entropy to the pool, but (as everyone else has said) neither the current time nor the device's UUID provide enough entropy to satisfy any cryptographic requirements. Adding them to the random pool won't hurt, but you should set the entropy-estimate argument equal to zero (like you did in your example).

Depending on your OpenSSL version *and the platform it's running on*, OpenSSL may automatically seed the random pool from the platform's random-number source(s). It does this by calling RAND_poll(), which is documented in the same manual page as RAND_add(). So, normally you do not need to worry about explicitly seeding the random number generator.

However, if you're running on an embedded device, or running immediately after bootup, or some other situation in which OpenSSL can't get good entropy from the system, you may need to figure out how to supply some yourself. That's pretty difficult to do.



From john.sha.jiang at gmail.com  Thu May 24 09:58:24 2018
From: john.sha.jiang at gmail.com (John Jiang)
Date: Thu, 24 May 2018 17:58:24 +0800
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <aa3c3d55-8a88-0be5-ef2f-6c3da0b0f99b@openssl.org>
References: <20180429104326.GA21314@roeckx.be>
 <CAJbO6CQPpPM10JGKdN1msxQHr92Y0Go6kqNUch4JhprE6TTQog@mail.gmail.com>
 <aa3c3d55-8a88-0be5-ef2f-6c3da0b0f99b@openssl.org>
Message-ID: <CAJbO6CRLszUrFBrmhBamRpQ_EEBo5yZ9Vj_rPXOqfYjANH_W2A@mail.gmail.com>

Hi Matt,
Thanks for your reply!

2018-05-23 20:33 GMT+08:00 Matt Caswell <matt at openssl.org>:

>
> To test resumption first create a full handshake TLSv1.3 connection and
> save the session:
>
> $ openssl s_server -cert cert.pem -key key.pem
> $ openssl s_client -sess_out session.pem
>
> Close the s_client instance by entering "Q" followed by enter. Then
> (without closing the s_server instance) resume the session:
>
> $ openssl s_client -sess_in session.pem
>
This way looks the same to test resumption on TLS 1.2.

The followings are some logs from my test.
The first connection:
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID:
    Session-ID-ctx:
    Master-Key:
B4A20A467729A8179ECE5912AD87A0E5A784B8573A6F98CB414498142A10A37593B10DE254197A98E05CE65BDD664776
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1527153377
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

The second connection:
---
Reused, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID:
601F249C2033D5E5DF23D3380E6A2D81B335AF420D59849BB2023C415D0553C5
    Session-ID-ctx:
    Master-Key:
68695BD547856C14E04C747CE884F876B1564DADC66F28CD24B95DF3240FE0C0F93F59ED650B5EE45F6D3EA40A71C993
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 54 03 c8 0e e6 75 f3 ef-3f 7a 73 89 bc 87 69 ab
T....u..?zs...i.
    0010 - cf e6 ff d1 f9 d8 24 36-0d e5 67 52 30 7c ea 0c
......$6..gR0|..
    0020 - c8 a2 67 ad 24 f6 29 cc-2c 95 48 36 e8 87 f6 4e
..g.$.).,.H6...N
    0030 - c1 e8 44 a7 49 9d d6 61-36 32 37 80 01 1a 67 38
..D.I..a627...g8
    0040 - ee b7 fb 83 d8 fc 66 69-51 29 3e c4 81 38 c5 2f
......fiQ)>..8./
    0050 - 62 a2 fe 65 76 20 91 b4-fb 7b e3 eb 06 fa b7 d6   b..ev
...{......
    0060 - 1a 1e 2e b5 e0 ea c1 a3-d2 bf 12 bf 38 94 29 10
............8.).
    0070 - 79 52 de 5d ef 30 d6 a7-01 a5 74 05 69 d1 31 61
yR.].0....t.i.1a
    0080 - a8 05 ac 83 d1 ab 17 82-c0 cc 1d 23 96 4e d2 af
...........#.N..
    0090 - 74 56 aa f2 24 8c 02 f9-90 b3 e1 65 8f 81 12 a1
tV..$......e....
    00a0 - 79 36 72 a1 cf 0e a7 f0-fb b5 d0 42 81 5f ca 13
y6r........B._..
    00b0 - 24 97 a3 92 40 07 bd 5b-2c 3e 9d e8 af 3e f0 56
$... at ..[,>...>.V
    00c0 - 9d 00 86 b2 30 fe 4b 68-c0 2e 17 d6 aa a7 5f 5b
....0.Kh......_[
    00d0 - 3f 0f 30 81 a4 2b a1 fd-f6 b5 8c 3c 4e 03 cb de
?.0..+.....<N...

    Start Time: 1527153377
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

Should I see PSK identity here? Or, it is the TLS session ticket.



> A HelloRetryRequest will occur if the key share provided by the client
> is not acceptable to the server. By default the client will send an
> X25519 key share, so if the server does not accept that group then an
> HRR will result, e.g.
>
> $ openssl s_server -cert cert.pem -key key.pem -groups P-256
> $ openssl s_client
>
It looks option "-groups" just specifies the most preferable named groups,
but other groups still could be negotiated. Right?


Of course a HelloRetryRequest all happens at the protocol layer and is
> invisible as far as a user of the command line apps is concerned. You
> will have to look at what happens "on the wire" to actually see it in
> action - for example by using wireshark. Alternatively you can compile
> OpenSSL with the "enable-ssl-trace" option, and pass the "-trace" flag
> to s_server or s_client to see what protocol messages are being exchanged.
>
I found interesting things from trace logs.

BTW, the TLS 1.3 wiki [1] stats that the TLS 1.3 cipher suites are named:
TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256
TLS13-AES-128-CCM-8-SHA256
TLS13-AES-128-CCM-SHA256
But with version 1.1.1-pre6, they are using the formal names,
like TLS_AES_256_GCM_SHA384.

[1] https://wiki.openssl.org/index.php/TLS1.3

Thanks!


>
> Matt
>
>
>
> >
> > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx <kurt at roeckx.be
> > <mailto:kurt at roeckx.be>>:
> >
> >     The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
> >     1.3 brings a lot of changes that might cause incompatibility. For
> >     an overview see https://wiki.openssl.org/index.php/TLS1.3
> >     <https://wiki.openssl.org/index.php/TLS1.3>
> >
> >     We are considering if we should enable TLS 1.3 by default or not,
> >     or when it should be enabled. For that, we would like to know how
> >     applications behave with the latest beta release.
> >
> >     When testing this, it's important that both sides of the
> >     connection support the same TLS 1.3 draft version. OpenSSL
> >     currently implements draft 26. We would like to see tests
> >     for OpenSSL acting as client and server.
> >
> >     https://github.com/tlswg/tls13-spec/wiki/Implementations
> >     <https://github.com/tlswg/tls13-spec/wiki/Implementations> lists
> >     other TLS 1.3 implementations and the draft they currently
> >     support. Note that the versions listed there might not be for the
> >     latest release. It also lists some https test servers.
> >
> >     We would really like to see a diverse set of applictions being
> >     tested. Please report any results you have to us.
> >
> >
> >     Kurt
> >
> >     --
> >     openssl-users mailing list
> >     To unsubscribe:
> >     https://mta.openssl.org/mailman/listinfo/openssl-users
> >     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> >
> >
> >
> >
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180524/2ecf7b01/attachment-0001.html>

From matt at openssl.org  Thu May 24 10:40:08 2018
From: matt at openssl.org (Matt Caswell)
Date: Thu, 24 May 2018 11:40:08 +0100
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <CAJbO6CRLszUrFBrmhBamRpQ_EEBo5yZ9Vj_rPXOqfYjANH_W2A@mail.gmail.com>
References: <20180429104326.GA21314@roeckx.be>
 <CAJbO6CQPpPM10JGKdN1msxQHr92Y0Go6kqNUch4JhprE6TTQog@mail.gmail.com>
 <aa3c3d55-8a88-0be5-ef2f-6c3da0b0f99b@openssl.org>
 <CAJbO6CRLszUrFBrmhBamRpQ_EEBo5yZ9Vj_rPXOqfYjANH_W2A@mail.gmail.com>
Message-ID: <bed8c1ac-a5a4-9034-efb1-7198a1491496@openssl.org>



On 24/05/18 10:58, John Jiang wrote:
> Should I see PSK identity here? Or, it is the TLS session ticket.

It's the session ticket.


>     A HelloRetryRequest will occur if the key share provided by the client
>     is not acceptable to the server. By default the client will send an
>     X25519 key share, so if the server does not accept that group then an
>     HRR will result, e.g.
> 
>     $ openssl s_server -cert cert.pem -key key.pem -groups P-256
>     $ openssl s_client
> 
> It looks option "-groups" just specifies the most preferable named groups,
> but other groups still could be negotiated. Right?

No, it restricts the groups acceptable to the server.

> 
> I found interesting things from trace logs.
> 
> BTW, the TLS 1.3 wiki [1] stats that the TLS 1.3 cipher suites are named:
> TLS13-AES-256-GCM-SHA384
> TLS13-CHACHA20-POLY1305-SHA256
> TLS13-AES-128-GCM-SHA256
> TLS13-AES-128-CCM-8-SHA256
> TLS13-AES-128-CCM-SHA256
> But with version 1.1.1-pre6, they are using the formal names,
> like TLS_AES_256_GCM_SHA384.

Ah, right thanks - we renamed them to the standard names a while ago. I
fixed the wiki.

Matt



> 
> [1] https://wiki.openssl.org/index.php/TLS1.3
> 
> Thanks!
> ?
> 
> 
>     Matt
> 
> 
> 
>     > 
>     > 2018-04-29 18:43 GMT+08:00 Kurt Roeckx <kurt at roeckx.be <mailto:kurt at roeckx.be>
>     > <mailto:kurt at roeckx.be <mailto:kurt at roeckx.be>>>:
>     > 
>     >? ? ?The upcomming OpenSSL 1.1.1 release will have TLS 1.3 support. TLS
>     >? ? ?1.3 brings a lot of changes that might cause incompatibility. For
>     >? ? ?an overview see https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>
>     >? ? ?<https://wiki.openssl.org/index.php/TLS1.3
>     <https://wiki.openssl.org/index.php/TLS1.3>>
>     > 
>     >? ? ?We are considering if we should enable TLS 1.3 by default or not,
>     >? ? ?or when it should be enabled. For that, we would like to know how
>     >? ? ?applications behave with the latest beta release.
>     > 
>     >? ? ?When testing this, it's important that both sides of the
>     >? ? ?connection support the same TLS 1.3 draft version. OpenSSL
>     >? ? ?currently implements draft 26. We would like to see tests
>     >? ? ?for OpenSSL acting as client and server.
>     > 
>     >? ? ?https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations>
>     >? ? ?<https://github.com/tlswg/tls13-spec/wiki/Implementations
>     <https://github.com/tlswg/tls13-spec/wiki/Implementations>> lists
>     >? ? ?other TLS 1.3 implementations and the draft they currently
>     >? ? ?support. Note that the versions listed there might not be for the
>     >? ? ?latest release. It also lists some https test servers.
>     > 
>     >? ? ?We would really like to see a diverse set of applictions being
>     >? ? ?tested. Please report any results you have to us.
>     > 
>     > 
>     >? ? ?Kurt
>     > 
>     >? ? ?-- 
>     >? ? ?openssl-users mailing list
>     >? ? ?To unsubscribe:
>     >? ? ?https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
>     >? ? ?<https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>>
>     >
>     >
>     >
>     >
>     -- 
>     openssl-users mailing list
>     To unsubscribe:
>     https://mta.openssl.org/mailman/listinfo/openssl-users
>     <https://mta.openssl.org/mailman/listinfo/openssl-users>
> 
> 
> 
> 

From redpath at us.ibm.com  Thu May 24 10:50:15 2018
From: redpath at us.ibm.com (redpath)
Date: Thu, 24 May 2018 03:50:15 -0700 (MST)
Subject: [openssl-users] PEM_write_bio_RSAPrivateKey assure Randomness
	of PK
In-Reply-To: <DA508E21-6FC2-4E90-9993-17EFAB245BDD@omnigroup.com>
References: <1527072111537-0.post@n7.nabble.com>
 <1527095281847-0.post@n7.nabble.com>
 <DA508E21-6FC2-4E90-9993-17EFAB245BDD@omnigroup.com>
Message-ID: <1527159015569-0.post@n7.nabble.com>

I thought the new openSSL did the pool hence why I started this post as I
wanted to assure that
use of the function is correct for key generation effect; then next step to
figure out some entropy.

thanks a whole bunch




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

From ben.wilson at digicert.com  Thu May 24 18:44:39 2018
From: ben.wilson at digicert.com (Ben Wilson)
Date: Thu, 24 May 2018 18:44:39 +0000
Subject: [openssl-users] Proper syntax for -header host switch
Message-ID: <DM6PR14MB2202D30D75D821367E35FAEDF16A0@DM6PR14MB2202.namprd14.prod.outlook.com>

All,

 

Does anyone know what the proper syntax is for the undocumented -header host
switch?  I'm getting some different responses/behaviors when I try these:

 

-header "Host" "ocsp.example.com" 

-header 'Host' 'ocsp.example.com' 

-header Host ocsp.example.com 

 

Thanks,

 

Ben

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

From rsalz at akamai.com  Thu May 24 19:21:11 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 24 May 2018 19:21:11 +0000
Subject: [openssl-users] Proper syntax for -header host switch
Message-ID: <C9FE4F18-B81D-4C1C-B0C0-6763E1CF3CEA@akamai.com>

In 1.1.0 and later, the flag takes a single parameter in name=value.  Yes that?s strange, but it means that in the common case you don?t need to do any quoting:
                -header Host=ocsp.example.com

In 1.0.2 it takes two parameters
                -header Host ocsp.example.com

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

From openssl-users at dukhovni.org  Thu May 24 19:24:08 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 24 May 2018 15:24:08 -0400
Subject: [openssl-users] Proper syntax for -header host switch
In-Reply-To: <C9FE4F18-B81D-4C1C-B0C0-6763E1CF3CEA@akamai.com>
References: <C9FE4F18-B81D-4C1C-B0C0-6763E1CF3CEA@akamai.com>
Message-ID: <1BA3BAF7-A856-43BE-A208-717FCC6D9908@dukhovni.org>



> On May 24, 2018, at 3:21 PM, Salz, Rich via openssl-users <openssl-users at openssl.org> wrote:
> 
> In 1.1.0 and later, the flag takes a single parameter in name=value.  Yes that?s strange, but it means that in the common case you don?t need to do any quoting:
>                 -header Host=ocsp.example.com

In 1.1.0 and later it is documented:

   https://www.openssl.org/docs/man1.1.0/apps/ocsp.html 

-- 
-- 
	Viktor.


From rsalz at akamai.com  Thu May 24 19:28:59 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 24 May 2018 19:28:59 +0000
Subject: [openssl-users] Proper syntax for -header host switch
In-Reply-To: <1BA3BAF7-A856-43BE-A208-717FCC6D9908@dukhovni.org>
References: <C9FE4F18-B81D-4C1C-B0C0-6763E1CF3CEA@akamai.com>
 <1BA3BAF7-A856-43BE-A208-717FCC6D9908@dukhovni.org>
Message-ID: <8D6B7165-4501-4A5B-815D-73494C9A9F4E@akamai.com>

>    In 1.1.0 and later it is documented:
  
And in 1.0.2 it was documented in January, 2017.



From openssl at jordan.maileater.net  Fri May 25 03:08:17 2018
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Thu, 24 May 2018 20:08:17 -0700
Subject: [openssl-users] Proper syntax for -header host switch
In-Reply-To: <DM6PR14MB2202D30D75D821367E35FAEDF16A0@DM6PR14MB2202.namprd14.prod.outlook.com>
References: <DM6PR14MB2202D30D75D821367E35FAEDF16A0@DM6PR14MB2202.namprd14.prod.outlook.com>
Message-ID: <e422c717-f8b7-6fd8-13de-32a3f3f68f5f@jordan.maileater.net>

On 5/24/2018 11:44 AM, Ben Wilson wrote:
> -header "Host" "ocsp.example.com"
> -header 'Host' 'ocsp.example.com'
> -header Host ocsp.example.com


I don't know anything about the option, but I do know shell syntax.?
Those three variants are identical when presented to the shell.

Quotes are only necessary - and only make a difference - if the string
has characters in it that are special to the shell.? Letters and periods
are not special to the shell.

In all three cases, the program will see three arguments:

    -header
    Host
    oscp.example.com

-- 
Jordan Brown, Oracle Solaris

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

From Michael.Wojcik at microfocus.com  Fri May 25 11:30:03 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Fri, 25 May 2018 11:30:03 +0000
Subject: [openssl-users] Proper syntax for -header host switch
In-Reply-To: <e422c717-f8b7-6fd8-13de-32a3f3f68f5f@jordan.maileater.net>
References: <DM6PR14MB2202D30D75D821367E35FAEDF16A0@DM6PR14MB2202.namprd14.prod.outlook.com>
 <e422c717-f8b7-6fd8-13de-32a3f3f68f5f@jordan.maileater.net>
Message-ID: <SN1PR18MB2112FA4DCE875FBF683B8383F9690@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jordan Brown
> Sent: Thursday, May 24, 2018 23:08
> Subject: Re: [openssl-users] Proper syntax for -header host switch

> On 5/24/2018 11:44 AM, Ben Wilson wrote:
> > -header "Host" "ocsp.example.com"
> > -header 'Host' 'ocsp.example.com'
> > -header Host ocsp.example.com

> I don't know anything about the option, but I do know shell syntax.  Those three variants are identical when
> presented to the shell.

True for standard Linux/UNIX shells; not necessarily true on other platforms.

The Windows cmd.exe interpreter, for example, does not perform dequoting or argument splitting - those are performed by the application, typically in the C startup code, and the Microsoft C startup code doesn't recognize the single-quote character.

Of course on Windows you have the option of using a UNIX shell such as bash, in which case you'll get the behavior Jordan describes. But it's not universal. For that matter, on Linux or UNIX a user could be running some oddball shell that doesn't support one of those quote characters - it'd be a strange thing to do, but it's possible. Or be running something like bash, but have IFS set to include the "." character.

The basic point is solid - those three variants may well be indistinguishable to the application (almost certainly if running on UNIX or Linux). But it's not 100% guaranteed.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From openssl at jordan.maileater.net  Fri May 25 17:52:47 2018
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Fri, 25 May 2018 10:52:47 -0700
Subject: [openssl-users] Proper syntax for -header host switch
In-Reply-To: <SN1PR18MB2112FA4DCE875FBF683B8383F9690@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <DM6PR14MB2202D30D75D821367E35FAEDF16A0@DM6PR14MB2202.namprd14.prod.outlook.com>
 <e422c717-f8b7-6fd8-13de-32a3f3f68f5f@jordan.maileater.net>
 <SN1PR18MB2112FA4DCE875FBF683B8383F9690@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <70c3cf55-5520-8f64-77d3-1832882f3186@jordan.maileater.net>

On 5/25/2018 4:30 AM, Michael Wojcik wrote:
>> On 5/24/2018 11:44 AM, Ben Wilson wrote:
>>> -header "Host" "ocsp.example.com"
>>> -header 'Host' 'ocsp.example.com'
>>> -header Host ocsp.example.com
>> I don't know anything about the option, but I do know shell syntax.  Those three variants are identical when
>> presented to the shell.
> True for standard Linux/UNIX shells; not necessarily true on other platforms.

Yes.? I tried to stay simple :-)

-- 
Jordan Brown, Oracle Solaris

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

From director at openca.org  Sun May 27 00:14:15 2018
From: director at openca.org (Dr. Pala)
Date: Sat, 26 May 2018 18:14:15 -0600
Subject: [openssl-users] d2i_PUBKEY() and X509_get0_pubkey_bitstr() output
	differences
Message-ID: <facf7c71-ee38-90a1-7f34-af7bb646aee0@openca.org>

Hi all,

I have a small question - I am trying to calculate the HASH over a 
public key, and I want it to be reliable across different environments. 
In particular, I would like to be able to calculate an HASH over the 
public key (e.g., loaded from the keypair file) and or a key in a 
certificate and get the same value (given that they are the same keys :D).

It seems that by using the d2i_PUBKEY(), I get some extra data and that 
does not allow me to calculate correctly the HASH.

in particular, here's the output i2d_PUBKEY() and X509_get0_pubkey_bitstr():

    *[DEBUG] Cert Key Bit String X509_get0_pubkey_bitstr**()**:*
    30:82:01:0A:02:82:01:01:00:BD:ED:42:7E:D4:2D:BD:7C:EC:CB:E6:
    B2:93:0D:E1:E1:A8:81:0C:01:A5:71:24:D6:65:D3:56:FD:D1:A6:53:
    F3:3F:F6:80:68:16:BF:7E:A9:2C:E2:10:10:77:FC:EF:35:52:4E:A9:
    0D:15:AF:8F:2C:2D:30:BC:60:C3:31:EE:6C:CC:66:86:5E:DA:46:45:
    D3:31:2D:0E:D1:C0:96:63:0C:C2:D1:CF:C6:47:C3:97:9A:DA:95:E9:
    98:92:3B:AB:14:CF:58:5B:B8:50:EB:25:0F:CA:25:07:E7:A4:B0:FA:
    50:B5:1E:6B:DE:D8:F7:BE:BA:35:9A:E9:D9:5A:05:22:F0:18:2C:BD:
    FC:DF:E7:38:70:E0:8D:DD:C3:53:EE:B4:21:26:66:84:8A:29:5C:11:
    12:59:C8:09:E4:C2:49:BA:3F:CC:3D:15:22:0F:EC:F6:6C:8F:41:BA:
    A7:7B:D0:66:C9:4A:89:1A:73:E9:E8:67:17:20:00:8F:4C:70:A3:A0:
    85:05:C9:60:CD:18:17:F4:28:BA:59:F2:49:88:C9:87:1B:61:98:E8:
    55:AD:A7:C2:B0:81:6C:63:C2:4E:92:6C:7B:45:F4:A5:57:C7:CD:E0:
    28:83:E7:F4:AB:E1:E2:79:71:31:F5:AE:05:A4:32:AB:61:7A:82:74:
    33:30:AF:32:FF:02:03:01:00:01:

    *[DEBUG] i2d_PUBKEY() Bit String:*
    00:00:00:00:00:00:00:00:2A:86:48:86:F7:0D:01:01:01:05:00:03:
    82:01:0F:00:30:82:01:0A:02:82:01:01:00:BD:ED:42:7E:D4:2D:BD:
    7C:EC:CB:E6:B2:93:0D:E1:E1:A8:81:0C:01:A5:71:24:D6:65:D3:56:
    FD:D1:A6:53:F3:3F:F6:80:68:16:BF:7E:A9:2C:E2:10:10:77:FC:EF:
    35:52:4E:A9:0D:15:AF:8F:2C:2D:30:BC:60:C3:31:EE:6C:CC:66:86:
    5E:DA:46:45:D3:31:2D:0E:D1:C0:96:63:0C:C2:D1:CF:C6:47:C3:97:
    9A:DA:95:E9:98:92:3B:AB:14:CF:58:5B:B8:50:EB:25:0F:CA:25:07:
    E7:A4:B0:FA:50:B5:1E:6B:DE:D8:F7:BE:BA:35:9A:E9:D9:5A:05:22:
    F0:18:2C:BD:FC:DF:E7:38:70:E0:8D:DD:C3:53:EE:B4:21:26:66:84:
    8A:29:5C:11:12:59:C8:09:E4:C2:49:BA:3F:CC:3D:15:22:0F:EC:F6:
    6C:8F:41:BA:A7:7B:D0:66:C9:4A:89:1A:73:E9:E8:67:17:20:00:8F:
    4C:70:A3:A0:85:05:C9:60:CD:18:17:F4:28:BA:59:F2:49:88:C9:87:
    1B:61:98:E8:55:AD:A7:C2:B0:81:6C:63:C2:4E:92:6C:7B:45:F4:A5:
    57:C7:CD:E0:28:83:E7:F4:AB:E1:E2:79:71:31:F5:AE:05:A4:32:AB:
    61:7A:82:74:33:30:AF:32:FF:02:03:01:00:01:

Now, the output of the i2d_PUBKEY() has an extra 24 Bytes at the 
beginning (the match starts from 30:82010A... ) - what are those bytes? 
I guess some extra encoding that is needed... but is there a way to 
obtain the same values that does not depend on the type or size of the 
keys ? Is the 24 Bytes a constant size or ... ? Is there any 
documentation that would help me... ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180526/c7f06a1d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: njgnnbedbaaedlhm.png
Type: image/png
Size: 3146 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180526/c7f06a1d/attachment-0001.png>

From openssl at foocrypt.net  Sun May 27 03:09:51 2018
From: openssl at foocrypt.net (openssl at foocrypt.net)
Date: Sat, 26 May 2018 21:09:51 -0600
Subject: [openssl-users] =?utf-8?q?Independent_review_of_the=C2=A0Defence_?=
 =?utf-8?q?Trade_Controls_Act_2012=C2=A0=28Cth=29=2C_call_for_information_?=
 =?utf-8?q?for_submission_as_a_case_study_from_the_openssl_community=2E?=
Message-ID: <2afd17ef27515d5a9abd9c9ffa79b2a4@foocrypt.net>

Greetings

Currently down here in the land down under, the Defence Trade Controls 
Act 2012 (Cth) is currently under going an independent review by Dr 
Vivian Thom AM. Responses by stake holders is due by close of business, 
31st of May, 2018 as per the guidelines and submission requirements set 
out @

http://www.defence.gov.au/publications/reviews/tradecontrols/Default.asp

[ That includes the DSGL listing of cryptology as 'Duel-Use' technology 
]

<--

Overview

The Defence Trade Controls Act introduced offences which commenced 
operation on 2 April 2016 for the unauthorised supply, and in certain 
instances publication, of defence technology, and for the brokering of 
defence goods and technology without a permit. The Act also provided for 
a review of its operation to begin as soon as possible after 2 April 
2018.
The review will include an assessment of whether the Act is fit for 
purpose, particularly whether it adequately safeguards national defence 
capability and prevents trade and collaboration that could unwittingly 
advance the military capabilities of potential adversaries. The Review 
will also identify gaps in the Act?s controls, any unintended 
consequences arising from the Act, such as unnecessary regulatory 
burden, and other relevant matters.

Consultation

Interested parties are invited to submit written comment during the 
consultation period. The closing date for submissions is 31 May 2018.

While submissions may be made electronically or by post, electronic 
lodgement is preferred.

Submissions will be published on this website as they are received. 
Comments on submissions can be made to Dr Thom by email to 
dtcact.review at defence.gov.au

All information (including name and address details) contained in 
submissions will be uploaded to this website and publicly available, 
unless you indicate you would like all or part of your submission to 
remain in confidence. Automatically generated confidentiality statements 
in emails do not suffice for this purpose. Respondents who would like 
all or part of their submission to remain in confidence should provide 
this information marked as such in a separate attachment. The 
Secretariat may edit submissions before publishing where they contain 
offensive material.

The Department is required to comply with the Freedom of Information Act 
1982 (FOI Act) and any submissions provided for the review may be the 
subject of an FOI request. The FOI Act includes various exemptions for 
disclosing information, including where material was provided in 
confidence or where it constitutes personal information. All requests 
for access to submissions will be handled in accordance with the FOI 
Act.

-->

FooCrypt is current finalising a submission as per the request to stake 
holders containing a number of high level case studies regarding 
'FooCrypt,0.0.1,Core | FooCrypt, A Tale Of Cynical Cyclical 
Encryption.'.

This is an informal request to the openssl community to see if other 
community members have experienced issues which could be included in a 
case study along with our response into Dr Thom.

If any members of the openssl community wish to provide information for 
a case study submission via the FooCrypt submission, please do so by 
close of business [ 17:30 hours ], 30th of May, 2018 AEST, so that a 
summarised overview of the attachments can be performed.

Please note that it is the intent to provide the information in an 'as 
is' state from what we receive via email.

Please provide a pdf document containing the information you wish to 
pass onto Dr Thom.

Each pdf document will be summarised as a simple table of index.

          Author : Date : Location : Document Number.

Obfuscation of any identifiable details is acceptable in your 
submission.

Response can be submitted to : openssl at foocrypt.net or 
dtca_openssl at foocrypt.net


--


Regards,

Mark A. Lane

openssl at foocrypt.net

FooCrypt,0.0.1,Core @ https://foocrypt.net/





From openssl-users at dukhovni.org  Sun May 27 04:59:00 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Sun, 27 May 2018 00:59:00 -0400
Subject: [openssl-users] d2i_PUBKEY() and X509_get0_pubkey_bitstr()
 output differences
In-Reply-To: <facf7c71-ee38-90a1-7f34-af7bb646aee0@openca.org>
References: <facf7c71-ee38-90a1-7f34-af7bb646aee0@openca.org>
Message-ID: <574356C1-C36A-4057-95F2-BCF00E3BF6BA@dukhovni.org>



> On May 26, 2018, at 8:14 PM, Dr. Pala <director at openca.org> wrote:
> 
>  have a small question - I am trying to calculate the HASH over a public key, and I want it to be reliable across different environments. In particular, I would like to be able to calculate an HASH over the public key (e.g., loaded from the keypair file) and or a key in a certificate and get the same value (given that they are the same keys :D).
> 
> It seems that by using the d2i_PUBKEY(), I get some extra data and that does not allow me to calculate correctly the HASH.
> 
> in particular, here's the output i2d_PUBKEY() and X509_get0_pubkey_bitstr()

You're using the wrong function.  i2d_PUBKEY() encodes just the public key bits, but not the SPKI algorithm oid and parameters (which is what you want in almost all cases).

The right function is i2d_X509_PUBKEY().  For example, see:

https://github.com/vdukhovni/postfix/blob/master/postfix/src/tls/tls_fprint.c#L351

-- 
	Viktor.


From dclarke at blastwave.org  Sun May 27 18:29:32 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Sun, 27 May 2018 14:29:32 -0400
Subject: [openssl-users] openssl-1.1.1-pre6 throws plenty of "Warning:
 -xarch=v9 is deprecated, use -m64 -xarch=sparc instead"
Message-ID: <6f004097-43f4-4439-c6cd-54a5f6d695df@blastwave.org>



On Solaris 10 sparc with Oracle Studio 12.6 this is perhaps merely an
annoyance.

If I entirely leave Configurations/10-main.conf untouched and go with
the cflags suggested then I get warnings on every compile :

.
.
.
cc  -I. -Icrypto/include -Iinclude -KPIC -xarch=v9 -xstrconst -Xa -xO5 
-xdepend -DFILIO_H -DB_ENDIAN -DBN_DIV2W -DOPENSSL_PIC 
-DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m 
-DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM 
-DECP_NISTZ256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" 
-DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -D_REENTRANT -DNDEBUG   -c 
-o crypto/cms/cms_io.o crypto/cms/cms_io.c
cc: Warning: -xarch=v9 is deprecated, use -m64 -xarch=sparc instead


May be best to change cflags for solaris64-sparcv9-cc slightly.


Dennis


From dclarke at blastwave.org  Sun May 27 18:58:21 2018
From: dclarke at blastwave.org (Dennis Clarke)
Date: Sun, 27 May 2018 14:58:21 -0400
Subject: [openssl-users] openssl-1.1.1-pre6 requires -lrt for final link on
 Solaris 10 for clock_gettime
Message-ID: <6386a0e1-e471-15c0-4720-4599fb2d324c@blastwave.org>


Minor issue with link here on Solaris 10 sparc :

.
.
.
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: 
symbol PBE2PARAM_it: relocation bound to a symbol with STV_PROTECTED 
visibility
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: 
symbol PBKDF2PARAM_it: relocation bound to a symbol with STV_PROTECTED 
visibility
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: 
symbol SCRYPT_PARAMS_it: relocation bound to a symbol with STV_PROTECTED 
visibility
ld: warning: relocation warning: R_SPARC_COPY: file ./libcrypto.so: 
symbol PBEPARAM_it: relocation bound to a symbol with STV_PROTECTED 
visibility
Undefined                       first referenced
  symbol                             in file
clock_gettime                       ./libcrypto.so
ld: fatal: symbol referencing errors. No output written to apps/openssl
gmake[1]: *** [Makefile:2245: apps/openssl] Error 2
gmake[1]: Leaving directory 
'/usr/local/build/openssl-1.1.1-pre6_sparcv9.001'
gmake: *** [Makefile:169: all] Error 2
$

So looks like -lrt is needed here.

Dennis


From j at w1.fi  Mon May 28 12:28:13 2018
From: j at w1.fi (Jouni Malinen)
Date: Mon, 28 May 2018 15:28:13 +0300
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <20180429104326.GA21314@roeckx.be>
References: <20180429104326.GA21314@roeckx.be>
Message-ID: <20180528122813.GA10166@w1.fi>

On Sun, Apr 29, 2018 at 12:43:26PM +0200, Kurt Roeckx wrote:
> We are considering if we should enable TLS 1.3 by default or not,
> or when it should be enabled. For that, we would like to know how
> applications behave with the latest beta release.

It looks like couple of TLS 1.3 changes result in breaking functionality
for various EAP methods that are based on TLS unless significant changes
in both the EAP method definition and implementations are done before
enabling the new TLS version. This seems to have an impact to at least
EAP-TLS, EAP-PEAP, EAP-TTLS, and EAP-FAST.

As far as wpa_supplicant (EAP peer) and hostapd (EAP server)
implementations are concerned, I've prepared changes to make EAP-TLS
work with TLS 1.3, but the other EAP methods are still failing for
various known (and to some extend, unknown) issues. Anyway, I'm
currently explicitly disabling TLS 1.3 support with OpenSSL by default
in these application due to these issues and the expected
interoperability issues and as such, the OpenSSL 1.1.1 release default
behavior regarding TLS 1.3 support should not have impact for these
applications. That said, other EAP implementations may want to do
something similar or face possibility of breaking functionality if
OpenSSL 1.1.1 does go out with TLS 1.3 enabled by default and both ends
of the EAP connection have TLS 1.3 enabled.

-- 
Jouni Malinen                                            PGP id EFC895FA

From Michal.Trojnara at stunnel.org  Mon May 28 21:27:22 2018
From: Michal.Trojnara at stunnel.org (Michal Trojnara)
Date: Mon, 28 May 2018 23:27:22 +0200
Subject: [openssl-users] stunnel 5.46 released
Message-ID: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>

Dear Users,

I have released version 5.46 of stunnel.

Version 5.46, 2018.05.28, urgency: MEDIUM
* New features
  - The default cipher list was updated to a safer value:
    "HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK".
* Bugfixes
  - Default accept address restored to INADDR_ANY.

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

SHA-256 hashes:
76aab48c28743d78e4b2f6b2dfe49994b6ca74126046c179444f699fae7a84c7
stunnel-5.46.tar.gz
721cc4d7c385743df767a32a53c11477def2440ae20ad4538d8e685f7b7d6538
stunnel-5.46-win32-installer.exe
d08a3b3598868064db08d6f0e3a97e3c49dedbf6c8d7f348a613b832eca16dd6
stunnel-5.46-android.zip

Best regards,
    Mike



From openssl-users at dukhovni.org  Mon May 28 23:48:19 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Mon, 28 May 2018 19:48:19 -0400
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
Message-ID: <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>



> On May 28, 2018, at 5:27 PM, Michal Trojnara <Michal.Trojnara at stunnel.org> wrote:
> 
>  - The default cipher list was updated to a safer value:
>    "HIGH:!aNULL:!SSLv2:!DH:!kDHEPSK".

I am rather puzzled as to why you chose to eliminate
not just fixed DH, but also the ephemeral finite-field
DH key exchange.  What's wrong with the DHE ciphers?

I would have chosen:

	HIGH:!aNULL:!kDH:!kECDH:!MD5

which excludes the *fixed* DH/ECDH ciphers and MD5
(and thus also SSLv2).  This does not eliminate
ephemeral finite-field DH, not sure why you're doing
that...

-- 
-- 
	Viktor.


From sampei02 at tiscali.it  Tue May 29 07:47:48 2018
From: sampei02 at tiscali.it (Sampei)
Date: Tue, 29 May 2018 09:47:48 +0200
Subject: [openssl-users] database openssl
Message-ID: <a394da529f40241da81e8892c5dd6e23@tiscali.it>

  
I'm using Linux server to create temporary CA and I know openssl
maintains a text database of issued certificates and their status. 
Now
I need to migrate this server to another one, so I ask myself how can I
export this db. 
thanks  


Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318

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

From janjust at nikhef.nl  Tue May 29 08:43:43 2018
From: janjust at nikhef.nl (Jan Just Keijser)
Date: Tue, 29 May 2018 10:43:43 +0200
Subject: [openssl-users] database openssl
In-Reply-To: <a394da529f40241da81e8892c5dd6e23@tiscali.it>
References: <a394da529f40241da81e8892c5dd6e23@tiscali.it>
Message-ID: <1283ec38-fefc-a8ce-845d-b79b79952cdc@nikhef.nl>

Hi,

On 29/05/18 09:47, Sampei wrote:
> I'm using Linux server to create temporary CA and I know openssl maintains a text database of issued certificates and their 
> status.
> Now I need to migrate this server to another one, so I ask myself how can I export this db.
> thanks
>

the openssl CA "database" usually consists of two files. The location of these files is specified in the openssl.cnf file. The 
files are
 ? serial?? - containing the last issued serial number
 ? index.txt? - containing the list of all issued, expired and revoked certificates.

As I said, the location of these files is depending on how you set up your temporary CA.

HTH,

JJK


From jb-openssl at wisemo.com  Tue May 29 11:12:57 2018
From: jb-openssl at wisemo.com (Jakob Bohm)
Date: Tue, 29 May 2018 13:12:57 +0200
Subject: [openssl-users] database openssl
In-Reply-To: <1283ec38-fefc-a8ce-845d-b79b79952cdc@nikhef.nl>
References: <a394da529f40241da81e8892c5dd6e23@tiscali.it>
 <1283ec38-fefc-a8ce-845d-b79b79952cdc@nikhef.nl>
Message-ID: <b7356d4f-4869-a57f-efc4-1023413ec42b@wisemo.com>

On 29/05/2018 10:43, Jan Just Keijser wrote:
> Hi,
>
> On 29/05/18 09:47, Sampei wrote:
>> I'm using Linux server to create temporary CA and I know openssl 
>> maintains a text database of issued certificates and their status.
>> Now I need to migrate this server to another one, so I ask myself how 
>> can I export this db.
>> thanks
>>
>
> the openssl CA "database" usually consists of two files. The location 
> of these files is specified in the openssl.cnf file. The files are
> ? serial?? - containing the last issued serial number
> ? index.txt? - containing the list of all issued, expired and revoked 
> certificates.
>
> As I said, the location of these files is depending on how you set up 
> your temporary CA.
>
Additionally, the openssl ca command stores the complete value of each
issued certificate in a subdirectory specified in openssl.cnf, this
may be needed/useful when importing to other CA software.

Also note that unless a special setting is included (I forget where),
the openssl ca database will be in a different (older) format that
only remembers the most recently issued certificate for a given
subject distinguished name.

Enjoy

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


From openssl at openssl.org  Tue May 29 12:38:25 2018
From: openssl at openssl.org (OpenSSL)
Date: Tue, 29 May 2018 12:38:25 +0000
Subject: [openssl-users] OpenSSL version 1.1.1 pre release 7 published
Message-ID: <20180529123825.GA8160@openssl.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


   OpenSSL version 1.1.1 pre release 7 (beta)
   ===========================================

   OpenSSL - The Open Source toolkit for SSL/TLS
   https://www.openssl.org/

   OpenSSL 1.1.1 is currently in beta. OpenSSL 1.1.1 pre release 7 has now
   been made available. For details of changes and known issues see the
   release notes at:

        https://www.openssl.org/news/openssl-1.1.1-notes.html

   Note: This OpenSSL pre-release has been provided for testing ONLY.
   It should NOT be used for security critical purposes.

   The beta release is available for download via HTTP and FTP from the
   following master locations (you can find the various FTP mirrors under
   https://www.openssl.org/source/mirror.html):

     * https://www.openssl.org/source/
     * ftp://ftp.openssl.org/source/

   The distribution file name is:

    o openssl-1.1.1-pre7.tar.gz
      Size: 8308876
      SHA1 checksum: 1879b688f9e36665f82bda8cac4f392029683bd0
      SHA256 checksum: e4a54e1eba2900004a2e39cde62aeaf1f1fa0442169f849faf14e735136ad6cc

   The checksums were calculated using the following commands:

    openssl sha1 openssl-1.1.1-pre7.tar.gz
    openssl sha256 openssl-1.1.1-pre7.tar.gz

   Please download and check this beta release as soon as possible.
   To report a bug, open an issue on GitHub:

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

   Please check the release notes and mailing lists to avoid duplicate
   reports of known issues. (Of course, the source is also available
   on GitHub.)

   Yours,

   The OpenSSL Project Team.

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAlsNRX8ACgkQ2cTSbQ5g
RJG5OwgAhQ1fmHrG57u3jCfhKn7r2t1c6CxnSfZRn7hRc1He772R3iwi9A3i6AO3
9BlEj16V8bQ/2DF6vH31FzBnPjfnP8QENDC3btwdQOdufkQLyeqvgMIjdj42VFS6
E803eCRE1fN6w0LZzVoP8TarWCIifD+Wb3c9VfFsTDWzfQ2TMQz3SKsVqhRA9m0e
+xKpkFkJNHw7MQw5B7EomuJYwCVZpERDQAJMlh78uQK5SCoLFw3f14+2C0IzLIBn
6fKVbC546TJgflWoR2uGjOSgYKZqxysya1ZcKfGTOuRy4YiBMkCxX/n0GNEEJFoy
gKxJYtMXHCmudlcEjvqcXqO0schzRw==
=HTbt
-----END PGP SIGNATURE-----

From rsalz at akamai.com  Tue May 29 15:12:19 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 29 May 2018 15:12:19 +0000
Subject: [openssl-users] Blog post on the new LTS release
Message-ID: <BBC9E321-9305-4142-8186-824929C34315@akamai.com>

We just posted a new blog entry on long-term support, the different phases, and so on.  It?s here:
    https://www.openssl.org/blog/blog/2018/05/18/new-lts/

TL;DR is that the upcoming 1.1.1 will be our next LTS release.



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

From tincanteksup at gmail.com  Tue May 29 15:27:46 2018
From: tincanteksup at gmail.com (tincanteksup)
Date: Tue, 29 May 2018 16:27:46 +0100
Subject: [openssl-users] Unexpected difference between version 10x and 11x
Message-ID: <b0793961-8121-7d1e-a877-4232732e4346@gmail.com>

Hi,

Certificate included here is only for testing.

I use EasyRSA to build my PKI -- This all works well.

So, now I have a client cert but, depending on which version of openssl
I use, I get different output in the Issuer line from the same cert.

The difference is:

openssl 101f:
Issuer: C=00, ST=home, L=tct, O=tct.org, OU=tct.v304.secp384r1.20180529, 
CN=Easy-RSA CA/emailAddress=me at example.net

openssl 110h
Issuer: C = 00, ST = home, L = tct, O = tct.org, OU = 
tct.v304.secp384r1.20180529, CN = Easy-RSA CA, emailAddress = me at example.net

Note the extra spaces which are inserted around '='
(cat of the original certificate does not show those spaces)

My question: Is this change intentional ?

I did not feel confident to report this as a bug without asking here first.

Thanks for your time and any help/advice you can offer.
tct



**********

Please find full details of output below:


$ cat tct.v304.secp384r1.c01.crt
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             48:07:85:ec:c8:78:e6:e3:ac:91:54:b3:91:07:83:d5
     Signature Algorithm: ecdsa-with-SHA256
         Issuer: C=00, ST=home, L=tct, O=tct.org, 
OU=tct.v304.secp384r1.20180529, CN=Easy-RSA CA/emailAddress=me at example.net
         Validity
             Not Before: May 29 14:01:00 2018 GMT
             Not After : May 28 14:01:00 2028 GMT
         Subject: C=00, ST=home, L=tct, O=tct.org, 
OU=tct.v304.secp384r1.20180529, 
CN=tct.v304.secp384r1.c01/emailAddress=me at example.net
         Subject Public Key Info:
             Public Key Algorithm: id-ecPublicKey
                 Public-Key: (384 bit)
                 pub:
                     04:b2:d4:42:ab:b7:bd:ba:d6:52:b6:9a:ca:30:50:
                     48:34:5b:72:bf:77:60:c3:7b:4b:fb:18:0f:90:27:
                     a3:bf:f6:db:8b:47:be:04:1f:2a:10:b2:de:7f:6b:
                     f5:e3:5b:12:11:8e:08:85:7c:5b:e8:27:3c:07:fc:
                     2f:cf:96:50:65:96:60:38:4e:49:ed:d5:b4:23:8e:
                     7a:64:d8:29:af:e2:c8:4a:49:31:2f:fe:3b:50:99:
                     a1:7d:3b:30:bd:c4:d4
                 ASN1 OID: secp384r1
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             X509v3 Subject Key Identifier:
                 08:C1:03:47:D4:8E:FD:47:80:6B:33:33:D9:53:97:AF:75:BB:72:20
             X509v3 Authority Key Identifier:
 
keyid:3D:05:4B:95:5E:EF:C9:CF:73:00:3B:84:25:F6:65:35:8F:57:A8:F7
 
DirName:/C=00/ST=home/L=tct/O=tct.org/OU=tct.v304.secp384r1.20180529/CN=Easy-RSA 
CA/emailAddress=me at example.net
                 serial:E7:DD:3B:6D:9E:E9:FD:58

             X509v3 Extended Key Usage:
                 TLS Web Client Authentication
             X509v3 Key Usage:
                 Digital Signature
     Signature Algorithm: ecdsa-with-SHA256
          30:64:02:30:4e:39:9a:4b:b0:f9:86:23:00:a1:82:76:8f:ed:
          e5:3f:20:af:a8:64:f1:b2:10:98:75:ab:64:31:38:a5:bf:a2:
          ca:be:18:54:12:b5:8c:1d:c9:91:8a:e6:09:c5:16:a3:02:30:
          5b:32:d4:7a:d0:2e:97:86:65:51:4f:60:16:51:71:bd:ca:7a:
          90:31:5c:0d:62:19:1e:86:29:0c:94:32:1f:33:ce:db:db:b9:
          1e:40:0b:55:17:f1:6c:9e:ff:d2:52:03
-----BEGIN CERTIFICATE-----
MIIDljCCAx2gAwIBAgIQSAeF7Mh45uOskVSzkQeD1TAKBggqhkjOPQQDAjCBlzEL
MAkGA1UEBhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UE
ChMHdGN0Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5
MRQwEgYDVQQDEwtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJARYObWVAZXhhbXBs
ZS5uZXQwHhcNMTgwNTI5MTQwMTAwWhcNMjgwNTI4MTQwMTAwWjCBojELMAkGA1UE
BhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UEChMHdGN0
Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5MR8wHQYD
VQQDExZ0Y3QudjMwNC5zZWNwMzg0cjEuYzAxMR0wGwYJKoZIhvcNAQkBFg5tZUBl
eGFtcGxlLm5ldDB2MBAGByqGSM49AgEGBSuBBAAiA2IABLLUQqu3vbrWUraayjBQ
SDRbcr93YMN7S/sYD5Ano7/224tHvgQfKhCy3n9r9eNbEhGOCIV8W+gnPAf8L8+W
UGWWYDhOSe3VtCOOemTYKa/iyEpJMS/+O1CZoX07ML3E1KOCAR8wggEbMAkGA1Ud
EwQCMAAwHQYDVR0OBBYEFAjBA0fUjv1HgGszM9lTl691u3IgMIHMBgNVHSMEgcQw
gcGAFD0FS5Ve78nPcwA7hCX2ZTWPV6j3oYGdpIGaMIGXMQswCQYDVQQGEwIwMDEN
MAsGA1UECBMEaG9tZTEMMAoGA1UEBxMDdGN0MRAwDgYDVQQKEwd0Y3Qub3JnMSQw
IgYDVQQLExt0Y3QudjMwNC5zZWNwMzg0cjEuMjAxODA1MjkxFDASBgNVBAMTC0Vh
c3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAOfdO22e
6f1YMBMGA1UdJQQMMAoGCCsGAQUFBwMCMAsGA1UdDwQEAwIHgDAKBggqhkjOPQQD
AgNnADBkAjBOOZpLsPmGIwChgnaP7eU/IK+oZPGyEJh1q2QxOKW/osq+GFQStYwd
yZGK5gnFFqMCMFsy1HrQLpeGZVFPYBZRcb3KepAxXA1iGR6GKQyUMh8zztvbuR5A
C1UX8Wye/9JSAw==
-----END CERTIFICATE-----



**********

Now usiing openssl v101f I get

$ openssl x509 -in 
/home/arby/sources/easyrsa/ersa304-1/pki/issued/tct.v304.secp384r1.c01.crt 
-textCertificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             48:07:85:ec:c8:78:e6:e3:ac:91:54:b3:91:07:83:d5
     Signature Algorithm: ecdsa-with-SHA256
         Issuer: C=00, ST=home, L=tct, O=tct.org, 
OU=tct.v304.secp384r1.20180529, CN=Easy-RSA CA/emailAddress=me at example.net
         Validity
             Not Before: May 29 14:01:00 2018 GMT
             Not After : May 28 14:01:00 2028 GMT
         Subject: C=00, ST=home, L=tct, O=tct.org, 
OU=tct.v304.secp384r1.20180529, 
CN=tct.v304.secp384r1.c01/emailAddress=me at example.net
         Subject Public Key Info:
             Public Key Algorithm: id-ecPublicKey
                 Public-Key: (384 bit)
                 pub:
                     04:b2:d4:42:ab:b7:bd:ba:d6:52:b6:9a:ca:30:50:
                     48:34:5b:72:bf:77:60:c3:7b:4b:fb:18:0f:90:27:
                     a3:bf:f6:db:8b:47:be:04:1f:2a:10:b2:de:7f:6b:
                     f5:e3:5b:12:11:8e:08:85:7c:5b:e8:27:3c:07:fc:
                     2f:cf:96:50:65:96:60:38:4e:49:ed:d5:b4:23:8e:
                     7a:64:d8:29:af:e2:c8:4a:49:31:2f:fe:3b:50:99:
                     a1:7d:3b:30:bd:c4:d4
                 ASN1 OID: secp384r1
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             X509v3 Subject Key Identifier:
                 08:C1:03:47:D4:8E:FD:47:80:6B:33:33:D9:53:97:AF:75:BB:72:20
             X509v3 Authority Key Identifier:
 
keyid:3D:05:4B:95:5E:EF:C9:CF:73:00:3B:84:25:F6:65:35:8F:57:A8:F7
 
DirName:/C=00/ST=home/L=tct/O=tct.org/OU=tct.v304.secp384r1.20180529/CN=Easy-RSA 
CA/emailAddress=me at example.net
                 serial:E7:DD:3B:6D:9E:E9:FD:58

             X509v3 Extended Key Usage:
                 TLS Web Client Authentication
             X509v3 Key Usage:
                 Digital Signature
     Signature Algorithm: ecdsa-with-SHA256
          30:64:02:30:4e:39:9a:4b:b0:f9:86:23:00:a1:82:76:8f:ed:
          e5:3f:20:af:a8:64:f1:b2:10:98:75:ab:64:31:38:a5:bf:a2:
          ca:be:18:54:12:b5:8c:1d:c9:91:8a:e6:09:c5:16:a3:02:30:
          5b:32:d4:7a:d0:2e:97:86:65:51:4f:60:16:51:71:bd:ca:7a:
          90:31:5c:0d:62:19:1e:86:29:0c:94:32:1f:33:ce:db:db:b9:
          1e:40:0b:55:17:f1:6c:9e:ff:d2:52:03
-----BEGIN CERTIFICATE-----
MIIDljCCAx2gAwIBAgIQSAeF7Mh45uOskVSzkQeD1TAKBggqhkjOPQQDAjCBlzEL
MAkGA1UEBhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UE
ChMHdGN0Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5
MRQwEgYDVQQDEwtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJARYObWVAZXhhbXBs
ZS5uZXQwHhcNMTgwNTI5MTQwMTAwWhcNMjgwNTI4MTQwMTAwWjCBojELMAkGA1UE
BhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UEChMHdGN0
Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5MR8wHQYD
VQQDExZ0Y3QudjMwNC5zZWNwMzg0cjEuYzAxMR0wGwYJKoZIhvcNAQkBFg5tZUBl
eGFtcGxlLm5ldDB2MBAGByqGSM49AgEGBSuBBAAiA2IABLLUQqu3vbrWUraayjBQ
SDRbcr93YMN7S/sYD5Ano7/224tHvgQfKhCy3n9r9eNbEhGOCIV8W+gnPAf8L8+W
UGWWYDhOSe3VtCOOemTYKa/iyEpJMS/+O1CZoX07ML3E1KOCAR8wggEbMAkGA1Ud
EwQCMAAwHQYDVR0OBBYEFAjBA0fUjv1HgGszM9lTl691u3IgMIHMBgNVHSMEgcQw
gcGAFD0FS5Ve78nPcwA7hCX2ZTWPV6j3oYGdpIGaMIGXMQswCQYDVQQGEwIwMDEN
MAsGA1UECBMEaG9tZTEMMAoGA1UEBxMDdGN0MRAwDgYDVQQKEwd0Y3Qub3JnMSQw
IgYDVQQLExt0Y3QudjMwNC5zZWNwMzg0cjEuMjAxODA1MjkxFDASBgNVBAMTC0Vh
c3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAOfdO22e
6f1YMBMGA1UdJQQMMAoGCCsGAQUFBwMCMAsGA1UdDwQEAwIHgDAKBggqhkjOPQQD
AgNnADBkAjBOOZpLsPmGIwChgnaP7eU/IK+oZPGyEJh1q2QxOKW/osq+GFQStYwd
yZGK5gnFFqMCMFsy1HrQLpeGZVFPYBZRcb3KepAxXA1iGR6GKQyUMh8zztvbuR5A
C1UX8Wye/9JSAw==
-----END CERTIFICATE-----


**********

Now using openssl 110h

$ openssl x509 -in /root/tct.v304.secp384r1.c01.crt -text
Certificate:
     Data:
         Version: 3 (0x2)
         Serial Number:
             48:07:85:ec:c8:78:e6:e3:ac:91:54:b3:91:07:83:d5
     Signature Algorithm: ecdsa-with-SHA256
         Issuer: C = 00, ST = home, L = tct, O = tct.org, OU = 
tct.v304.secp384r1.20180529, CN = Easy-RSA CA, emailAddress = me at example.net
         Validity
             Not Before: May 29 14:01:00 2018 GMT
             Not After : May 28 14:01:00 2028 GMT
         Subject: C = 00, ST = home, L = tct, O = tct.org, OU = 
tct.v304.secp384r1.20180529, CN = tct.v304.secp384r1.c01, emailAddress = 
me at example.net
         Subject Public Key Info:
             Public Key Algorithm: id-ecPublicKey
                 Public-Key: (384 bit)
                 pub:
                     04:b2:d4:42:ab:b7:bd:ba:d6:52:b6:9a:ca:30:50:
                     48:34:5b:72:bf:77:60:c3:7b:4b:fb:18:0f:90:27:
                     a3:bf:f6:db:8b:47:be:04:1f:2a:10:b2:de:7f:6b:
                     f5:e3:5b:12:11:8e:08:85:7c:5b:e8:27:3c:07:fc:
                     2f:cf:96:50:65:96:60:38:4e:49:ed:d5:b4:23:8e:
                     7a:64:d8:29:af:e2:c8:4a:49:31:2f:fe:3b:50:99:
                     a1:7d:3b:30:bd:c4:d4
                 ASN1 OID: secp384r1
                 NIST CURVE: P-384
         X509v3 extensions:
             X509v3 Basic Constraints:
                 CA:FALSE
             X509v3 Subject Key Identifier:
                 08:C1:03:47:D4:8E:FD:47:80:6B:33:33:D9:53:97:AF:75:BB:72:20
             X509v3 Authority Key Identifier:
 
keyid:3D:05:4B:95:5E:EF:C9:CF:73:00:3B:84:25:F6:65:35:8F:57:A8:F7
 
DirName:/C=00/ST=home/L=tct/O=tct.org/OU=tct.v304.secp384r1.20180529/CN=Easy-RSA 
CA/emailAddress=me at example.net
                 serial:E7:DD:3B:6D:9E:E9:FD:58

             X509v3 Extended Key Usage:
                 TLS Web Client Authentication
             X509v3 Key Usage:
                 Digital Signature
     Signature Algorithm: ecdsa-with-SHA256
          30:64:02:30:4e:39:9a:4b:b0:f9:86:23:00:a1:82:76:8f:ed:
          e5:3f:20:af:a8:64:f1:b2:10:98:75:ab:64:31:38:a5:bf:a2:
          ca:be:18:54:12:b5:8c:1d:c9:91:8a:e6:09:c5:16:a3:02:30:
          5b:32:d4:7a:d0:2e:97:86:65:51:4f:60:16:51:71:bd:ca:7a:
          90:31:5c:0d:62:19:1e:86:29:0c:94:32:1f:33:ce:db:db:b9:
          1e:40:0b:55:17:f1:6c:9e:ff:d2:52:03
-----BEGIN CERTIFICATE-----
MIIDljCCAx2gAwIBAgIQSAeF7Mh45uOskVSzkQeD1TAKBggqhkjOPQQDAjCBlzEL
MAkGA1UEBhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UE
ChMHdGN0Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5
MRQwEgYDVQQDEwtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJARYObWVAZXhhbXBs
ZS5uZXQwHhcNMTgwNTI5MTQwMTAwWhcNMjgwNTI4MTQwMTAwWjCBojELMAkGA1UE
BhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UEChMHdGN0
Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5MR8wHQYD
VQQDExZ0Y3QudjMwNC5zZWNwMzg0cjEuYzAxMR0wGwYJKoZIhvcNAQkBFg5tZUBl
eGFtcGxlLm5ldDB2MBAGByqGSM49AgEGBSuBBAAiA2IABLLUQqu3vbrWUraayjBQ
SDRbcr93YMN7S/sYD5Ano7/224tHvgQfKhCy3n9r9eNbEhGOCIV8W+gnPAf8L8+W
UGWWYDhOSe3VtCOOemTYKa/iyEpJMS/+O1CZoX07ML3E1KOCAR8wggEbMAkGA1Ud
EwQCMAAwHQYDVR0OBBYEFAjBA0fUjv1HgGszM9lTl691u3IgMIHMBgNVHSMEgcQw
gcGAFD0FS5Ve78nPcwA7hCX2ZTWPV6j3oYGdpIGaMIGXMQswCQYDVQQGEwIwMDEN
MAsGA1UECBMEaG9tZTEMMAoGA1UEBxMDdGN0MRAwDgYDVQQKEwd0Y3Qub3JnMSQw
IgYDVQQLExt0Y3QudjMwNC5zZWNwMzg0cjEuMjAxODA1MjkxFDASBgNVBAMTC0Vh
c3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAOfdO22e
6f1YMBMGA1UdJQQMMAoGCCsGAQUFBwMCMAsGA1UdDwQEAwIHgDAKBggqhkjOPQQD
AgNnADBkAjBOOZpLsPmGIwChgnaP7eU/IK+oZPGyEJh1q2QxOKW/osq+GFQStYwd
yZGK5gnFFqMCMFsy1HrQLpeGZVFPYBZRcb3KepAxXA1iGR6GKQyUMh8zztvbuR5A
C1UX8Wye/9JSAw==
-----END CERTIFICATE-----


**********


From bkaduk at akamai.com  Tue May 29 18:46:26 2018
From: bkaduk at akamai.com (Benjamin Kaduk)
Date: Tue, 29 May 2018 13:46:26 -0500
Subject: [openssl-users] Call for testing TLS 1.3
In-Reply-To: <20180528122813.GA10166@w1.fi>
References: <20180429104326.GA21314@roeckx.be> <20180528122813.GA10166@w1.fi>
Message-ID: <20180529184626.GI13834@akamai.com>

(For those who are not Jouni, there is some spec work needed for
TLS 1.3/EAP integration as well, occurring in the IETF EMU working group.
I assume Jouni is on the mailing list and knows this already)

-Ben

On Mon, May 28, 2018 at 03:28:13PM +0300, Jouni Malinen wrote:
> On Sun, Apr 29, 2018 at 12:43:26PM +0200, Kurt Roeckx wrote:
> > We are considering if we should enable TLS 1.3 by default or not,
> > or when it should be enabled. For that, we would like to know how
> > applications behave with the latest beta release.
> 
> It looks like couple of TLS 1.3 changes result in breaking functionality
> for various EAP methods that are based on TLS unless significant changes
> in both the EAP method definition and implementations are done before
> enabling the new TLS version. This seems to have an impact to at least
> EAP-TLS, EAP-PEAP, EAP-TTLS, and EAP-FAST.
> 
> As far as wpa_supplicant (EAP peer) and hostapd (EAP server)
> implementations are concerned, I've prepared changes to make EAP-TLS
> work with TLS 1.3, but the other EAP methods are still failing for
> various known (and to some extend, unknown) issues. Anyway, I'm
> currently explicitly disabling TLS 1.3 support with OpenSSL by default
> in these application due to these issues and the expected
> interoperability issues and as such, the OpenSSL 1.1.1 release default
> behavior regarding TLS 1.3 support should not have impact for these
> applications. That said, other EAP implementations may want to do
> something similar or face possibility of breaking functionality if
> OpenSSL 1.1.1 does go out with TLS 1.3 enabled by default and both ends
> of the EAP connection have TLS 1.3 enabled.
> 
> -- 
> Jouni Malinen                                            PGP id EFC895FA
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

From Michael.Wojcik at microfocus.com  Tue May 29 20:18:10 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Tue, 29 May 2018 20:18:10 +0000
Subject: [openssl-users] Blog post on the new LTS release
In-Reply-To: <BBC9E321-9305-4142-8186-824929C34315@akamai.com>
References: <BBC9E321-9305-4142-8186-824929C34315@akamai.com>
Message-ID: <SN1PR18MB211237604F6112093CDDF654F96D0@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich via openssl-users
> Sent: Tuesday, May 29, 2018 11:12
> To: openssl-users; openssl-announce at openssl.org
> Subject: [openssl-users] Blog post on the new LTS release

> We just posted a new blog entry on long-term support, the different phases, and so on.  It?s here:

This didn't show up in my RSS client. Is the RSS feed not working, or is it just my client?

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From rsalz at akamai.com  Tue May 29 20:22:56 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Tue, 29 May 2018 20:22:56 +0000
Subject: [openssl-users] Blog post on the new LTS release
In-Reply-To: <SN1PR18MB211237604F6112093CDDF654F96D0@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <BBC9E321-9305-4142-8186-824929C34315@akamai.com>
 <SN1PR18MB211237604F6112093CDDF654F96D0@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <FD4D5D07-FC18-4AFA-91E2-DA59F6F445D9@akamai.com>

>    This didn't show up in my RSS client. Is the RSS feed not working, or is it just my client?
  
It probably sat in draft form for too long, and went out with the old date.  Oops.


From scott_n at xypro.com  Tue May 29 22:58:55 2018
From: scott_n at xypro.com (Scott Neugroschl)
Date: Tue, 29 May 2018 22:58:55 +0000
Subject: [openssl-users] PRNG is not seeded
Message-ID: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>

Hi,

I'm using PRNGD to seed my random numbers (I'm on a system without /dev/random and /dev/urandom).   I occasionally get the dreaded "PRNG is not seeded" error.

I know this is caused by a lack of available entropy in the system; but what can I do to address this?  Is it just a matter of waiting until enough entropy has been collected?  Is there any kind of workaround?

Thanks

ScottN

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

From rsalz at akamai.com  Wed May 30 01:38:28 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Wed, 30 May 2018 01:38:28 +0000
Subject: [openssl-users] PRNG is not seeded
Message-ID: <BCD1FEC6-7CC7-4F98-8985-85CE7748E577@akamai.com>

>I know this is caused by a lack of available entropy in the system; but what can I do to address this?  Is it just a matter of waiting until enough entropy has been collected?  Is there any kind of workaround?

Assuming you don?t have another source of randomness that you can add in, then you should wait.  IF you don?t, you run the risk that your random numbers (session keys, RSA or other long-term keys, etc) could be guessed by an attacker.

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

From openssl at foocrypt.net  Wed May 30 01:40:46 2018
From: openssl at foocrypt.net (FooCrypt)
Date: Wed, 30 May 2018 11:40:46 +1000
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>

Hi Scott

I don?t know your OS or environment, have you tried the ?openssl rand? functionality as a random source to seed your entropy issues ?

openssl rand 102400 > some named pipe file that you can call as your random source.

perhaps rather than pseudo random, try a hardware device ?



> On 30 May 2018, at 8:58 AM, Scott Neugroschl <scott_n at xypro.com> wrote:
> 
> Hi,
>  
> I?m using PRNGD to seed my random numbers (I?m on a system without /dev/random and /dev/urandom).   I occasionally get the dreaded ?PRNG is not seeded? error.
>  
> I know this is caused by a lack of available entropy in the system; but what can I do to address this?  Is it just a matter of waiting until enough entropy has been collected?  Is there any kind of workaround?
>  
> Thanks
>  
> ScottN
>  
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From Mark.Shnaider at docusign.com  Wed May 30 06:45:34 2018
From: Mark.Shnaider at docusign.com (Mark Shnaider)
Date: Wed, 30 May 2018 06:45:34 +0000
Subject: [openssl-users] Test SSL connection
Message-ID: <DM5PR04MB3753D78EB6AE007D2899E5F88E6C0@DM5PR04MB3753.namprd04.prod.outlook.com>

Hello,
I use  OpenSSL version is openssl-1.1.0h(Windows) and
I run following command from apps directory
openssl s_server -accept 443 -www
The server in this case use certificate "server.pem"
On client computer I run command
openssl s_client -connect 10.65.48.108:443
On client computer I  get error :
Verify return code: 21 (unable to verify the first certificate)
What is wrong?
Thanks for any help
Mark



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

From Walter.H at mathemainzel.info  Wed May 30 08:16:47 2018
From: Walter.H at mathemainzel.info (Walter H.)
Date: Wed, 30 May 2018 10:16:47 +0200
Subject: [openssl-users] Test SSL connection
In-Reply-To: <DM5PR04MB3753D78EB6AE007D2899E5F88E6C0@DM5PR04MB3753.namprd04.prod.outlook.com>
References: <DM5PR04MB3753D78EB6AE007D2899E5F88E6C0@DM5PR04MB3753.namprd04.prod.outlook.com>
Message-ID: <5B0E5DEF.7010002@mathemainzel.info>

On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote:
>
> Hello,
>
> I use  OpenSSL version is openssl-1.1.0h(Windows) and
>
> I run following command from apps directory
>
> |openssl s_server -accept 443 -www|
>
> The server in this case use certificate "server.pem"
>
> On client computer I run command
>
> openssl s_client -connect 10.65.48.108:443
>
> On client computer I  get error :
>
> Verify return code: 21 (unable to verify the first certificate)
>
> What is wrong?
>
> Thanks for any help
>
> Mark
>
very probable, that the client doesn't have the root ca certificate of 
the ca certificate that signed server.pem

you should have at least the following

ca.pem  - the root ca
server.pem - the server ssl/tls certificate

Walter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180530/7b146d15/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3491 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180530/7b146d15/attachment.bin>

From tincanteksup at gmail.com  Wed May 30 12:17:47 2018
From: tincanteksup at gmail.com (tincanteksup)
Date: Wed, 30 May 2018 13:17:47 +0100
Subject: [openssl-users] Unexpected difference between version 10x and
	11x
In-Reply-To: <b0793961-8121-7d1e-a877-4232732e4346@gmail.com>
References: <b0793961-8121-7d1e-a877-4232732e4346@gmail.com>
Message-ID: <086c72f8-b511-f6be-06a6-e8ceae7cfd82@gmail.com>

After some RTFM, I found space_ec .. which confirms that this change was 
intentional.

Thanks


On 29/05/18 16:27, tincanteksup wrote:
> Hi,
> 
> Certificate included here is only for testing.
> 
> I use EasyRSA to build my PKI -- This all works well.
> 
> So, now I have a client cert but, depending on which version of openssl
> I use, I get different output in the Issuer line from the same cert.
> 
> The difference is:
> 
> openssl 101f:
> Issuer: C=00, ST=home, L=tct, O=tct.org, OU=tct.v304.secp384r1.20180529, 
> CN=Easy-RSA CA/emailAddress=me at example.net
> 
> openssl 110h
> Issuer: C = 00, ST = home, L = tct, O = tct.org, OU = 
> tct.v304.secp384r1.20180529, CN = Easy-RSA CA, emailAddress = 
> me at example.net
> 
> Note the extra spaces which are inserted around '='
> (cat of the original certificate does not show those spaces)
> 
> My question: Is this change intentional ?
> 
> I did not feel confident to report this as a bug without asking here first.
> 
> Thanks for your time and any help/advice you can offer.
> tct
> 
> 
> 
> **********
> 
> Please find full details of output below:
> 
> 
> $ cat tct.v304.secp384r1.c01.crt
> Certificate:
>  ??? Data:
>  ??????? Version: 3 (0x2)
>  ??????? Serial Number:
>  ??????????? 48:07:85:ec:c8:78:e6:e3:ac:91:54:b3:91:07:83:d5
>  ??? Signature Algorithm: ecdsa-with-SHA256
>  ??????? Issuer: C=00, ST=home, L=tct, O=tct.org, 
> OU=tct.v304.secp384r1.20180529, CN=Easy-RSA CA/emailAddress=me at example.net
>  ??????? Validity
>  ??????????? Not Before: May 29 14:01:00 2018 GMT
>  ??????????? Not After : May 28 14:01:00 2028 GMT
>  ??????? Subject: C=00, ST=home, L=tct, O=tct.org, 
> OU=tct.v304.secp384r1.20180529, 
> CN=tct.v304.secp384r1.c01/emailAddress=me at example.net
>  ??????? Subject Public Key Info:
>  ??????????? Public Key Algorithm: id-ecPublicKey
>  ??????????????? Public-Key: (384 bit)
>  ??????????????? pub:
>  ??????????????????? 04:b2:d4:42:ab:b7:bd:ba:d6:52:b6:9a:ca:30:50:
>  ??????????????????? 48:34:5b:72:bf:77:60:c3:7b:4b:fb:18:0f:90:27:
>  ??????????????????? a3:bf:f6:db:8b:47:be:04:1f:2a:10:b2:de:7f:6b:
>  ??????????????????? f5:e3:5b:12:11:8e:08:85:7c:5b:e8:27:3c:07:fc:
>  ??????????????????? 2f:cf:96:50:65:96:60:38:4e:49:ed:d5:b4:23:8e:
>  ??????????????????? 7a:64:d8:29:af:e2:c8:4a:49:31:2f:fe:3b:50:99:
>  ??????????????????? a1:7d:3b:30:bd:c4:d4
>  ??????????????? ASN1 OID: secp384r1
>  ??????? X509v3 extensions:
>  ??????????? X509v3 Basic Constraints:
>  ??????????????? CA:FALSE
>  ??????????? X509v3 Subject Key Identifier:
>                  
> 08:C1:03:47:D4:8E:FD:47:80:6B:33:33:D9:53:97:AF:75:BB:72:20
>  ??????????? X509v3 Authority Key Identifier:
> 
> keyid:3D:05:4B:95:5E:EF:C9:CF:73:00:3B:84:25:F6:65:35:8F:57:A8:F7
> 
> DirName:/C=00/ST=home/L=tct/O=tct.org/OU=tct.v304.secp384r1.20180529/CN=Easy-RSA 
> CA/emailAddress=me at example.net
>  ??????????????? serial:E7:DD:3B:6D:9E:E9:FD:58
> 
>  ??????????? X509v3 Extended Key Usage:
>  ??????????????? TLS Web Client Authentication
>  ??????????? X509v3 Key Usage:
>  ??????????????? Digital Signature
>  ??? Signature Algorithm: ecdsa-with-SHA256
>  ???????? 30:64:02:30:4e:39:9a:4b:b0:f9:86:23:00:a1:82:76:8f:ed:
>  ???????? e5:3f:20:af:a8:64:f1:b2:10:98:75:ab:64:31:38:a5:bf:a2:
>  ???????? ca:be:18:54:12:b5:8c:1d:c9:91:8a:e6:09:c5:16:a3:02:30:
>  ???????? 5b:32:d4:7a:d0:2e:97:86:65:51:4f:60:16:51:71:bd:ca:7a:
>  ???????? 90:31:5c:0d:62:19:1e:86:29:0c:94:32:1f:33:ce:db:db:b9:
>  ???????? 1e:40:0b:55:17:f1:6c:9e:ff:d2:52:03
> -----BEGIN CERTIFICATE-----
> MIIDljCCAx2gAwIBAgIQSAeF7Mh45uOskVSzkQeD1TAKBggqhkjOPQQDAjCBlzEL
> MAkGA1UEBhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UE
> ChMHdGN0Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5
> MRQwEgYDVQQDEwtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJARYObWVAZXhhbXBs
> ZS5uZXQwHhcNMTgwNTI5MTQwMTAwWhcNMjgwNTI4MTQwMTAwWjCBojELMAkGA1UE
> BhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UEChMHdGN0
> Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5MR8wHQYD
> VQQDExZ0Y3QudjMwNC5zZWNwMzg0cjEuYzAxMR0wGwYJKoZIhvcNAQkBFg5tZUBl
> eGFtcGxlLm5ldDB2MBAGByqGSM49AgEGBSuBBAAiA2IABLLUQqu3vbrWUraayjBQ
> SDRbcr93YMN7S/sYD5Ano7/224tHvgQfKhCy3n9r9eNbEhGOCIV8W+gnPAf8L8+W
> UGWWYDhOSe3VtCOOemTYKa/iyEpJMS/+O1CZoX07ML3E1KOCAR8wggEbMAkGA1Ud
> EwQCMAAwHQYDVR0OBBYEFAjBA0fUjv1HgGszM9lTl691u3IgMIHMBgNVHSMEgcQw
> gcGAFD0FS5Ve78nPcwA7hCX2ZTWPV6j3oYGdpIGaMIGXMQswCQYDVQQGEwIwMDEN
> MAsGA1UECBMEaG9tZTEMMAoGA1UEBxMDdGN0MRAwDgYDVQQKEwd0Y3Qub3JnMSQw
> IgYDVQQLExt0Y3QudjMwNC5zZWNwMzg0cjEuMjAxODA1MjkxFDASBgNVBAMTC0Vh
> c3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAOfdO22e
> 6f1YMBMGA1UdJQQMMAoGCCsGAQUFBwMCMAsGA1UdDwQEAwIHgDAKBggqhkjOPQQD
> AgNnADBkAjBOOZpLsPmGIwChgnaP7eU/IK+oZPGyEJh1q2QxOKW/osq+GFQStYwd
> yZGK5gnFFqMCMFsy1HrQLpeGZVFPYBZRcb3KepAxXA1iGR6GKQyUMh8zztvbuR5A
> C1UX8Wye/9JSAw==
> -----END CERTIFICATE-----
> 
> 
> 
> **********
> 
> Now usiing openssl v101f I get
> 
> $ openssl x509 -in 
> /home/arby/sources/easyrsa/ersa304-1/pki/issued/tct.v304.secp384r1.c01.crt 
> -textCertificate:
>  ??? Data:
>  ??????? Version: 3 (0x2)
>  ??????? Serial Number:
>  ??????????? 48:07:85:ec:c8:78:e6:e3:ac:91:54:b3:91:07:83:d5
>  ??? Signature Algorithm: ecdsa-with-SHA256
>  ??????? Issuer: C=00, ST=home, L=tct, O=tct.org, 
> OU=tct.v304.secp384r1.20180529, CN=Easy-RSA CA/emailAddress=me at example.net
>  ??????? Validity
>  ??????????? Not Before: May 29 14:01:00 2018 GMT
>  ??????????? Not After : May 28 14:01:00 2028 GMT
>  ??????? Subject: C=00, ST=home, L=tct, O=tct.org, 
> OU=tct.v304.secp384r1.20180529, 
> CN=tct.v304.secp384r1.c01/emailAddress=me at example.net
>  ??????? Subject Public Key Info:
>  ??????????? Public Key Algorithm: id-ecPublicKey
>  ??????????????? Public-Key: (384 bit)
>  ??????????????? pub:
>  ??????????????????? 04:b2:d4:42:ab:b7:bd:ba:d6:52:b6:9a:ca:30:50:
>  ??????????????????? 48:34:5b:72:bf:77:60:c3:7b:4b:fb:18:0f:90:27:
>  ??????????????????? a3:bf:f6:db:8b:47:be:04:1f:2a:10:b2:de:7f:6b:
>  ??????????????????? f5:e3:5b:12:11:8e:08:85:7c:5b:e8:27:3c:07:fc:
>  ??????????????????? 2f:cf:96:50:65:96:60:38:4e:49:ed:d5:b4:23:8e:
>  ??????????????????? 7a:64:d8:29:af:e2:c8:4a:49:31:2f:fe:3b:50:99:
>  ??????????????????? a1:7d:3b:30:bd:c4:d4
>  ??????????????? ASN1 OID: secp384r1
>  ??????? X509v3 extensions:
>  ??????????? X509v3 Basic Constraints:
>  ??????????????? CA:FALSE
>  ??????????? X509v3 Subject Key Identifier:
>                  
> 08:C1:03:47:D4:8E:FD:47:80:6B:33:33:D9:53:97:AF:75:BB:72:20
>  ??????????? X509v3 Authority Key Identifier:
> 
> keyid:3D:05:4B:95:5E:EF:C9:CF:73:00:3B:84:25:F6:65:35:8F:57:A8:F7
> 
> DirName:/C=00/ST=home/L=tct/O=tct.org/OU=tct.v304.secp384r1.20180529/CN=Easy-RSA 
> CA/emailAddress=me at example.net
>  ??????????????? serial:E7:DD:3B:6D:9E:E9:FD:58
> 
>  ??????????? X509v3 Extended Key Usage:
>  ??????????????? TLS Web Client Authentication
>  ??????????? X509v3 Key Usage:
>  ??????????????? Digital Signature
>  ??? Signature Algorithm: ecdsa-with-SHA256
>  ???????? 30:64:02:30:4e:39:9a:4b:b0:f9:86:23:00:a1:82:76:8f:ed:
>  ???????? e5:3f:20:af:a8:64:f1:b2:10:98:75:ab:64:31:38:a5:bf:a2:
>  ???????? ca:be:18:54:12:b5:8c:1d:c9:91:8a:e6:09:c5:16:a3:02:30:
>  ???????? 5b:32:d4:7a:d0:2e:97:86:65:51:4f:60:16:51:71:bd:ca:7a:
>  ???????? 90:31:5c:0d:62:19:1e:86:29:0c:94:32:1f:33:ce:db:db:b9:
>  ???????? 1e:40:0b:55:17:f1:6c:9e:ff:d2:52:03
> -----BEGIN CERTIFICATE-----
> MIIDljCCAx2gAwIBAgIQSAeF7Mh45uOskVSzkQeD1TAKBggqhkjOPQQDAjCBlzEL
> MAkGA1UEBhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UE
> ChMHdGN0Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5
> MRQwEgYDVQQDEwtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJARYObWVAZXhhbXBs
> ZS5uZXQwHhcNMTgwNTI5MTQwMTAwWhcNMjgwNTI4MTQwMTAwWjCBojELMAkGA1UE
> BhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UEChMHdGN0
> Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5MR8wHQYD
> VQQDExZ0Y3QudjMwNC5zZWNwMzg0cjEuYzAxMR0wGwYJKoZIhvcNAQkBFg5tZUBl
> eGFtcGxlLm5ldDB2MBAGByqGSM49AgEGBSuBBAAiA2IABLLUQqu3vbrWUraayjBQ
> SDRbcr93YMN7S/sYD5Ano7/224tHvgQfKhCy3n9r9eNbEhGOCIV8W+gnPAf8L8+W
> UGWWYDhOSe3VtCOOemTYKa/iyEpJMS/+O1CZoX07ML3E1KOCAR8wggEbMAkGA1Ud
> EwQCMAAwHQYDVR0OBBYEFAjBA0fUjv1HgGszM9lTl691u3IgMIHMBgNVHSMEgcQw
> gcGAFD0FS5Ve78nPcwA7hCX2ZTWPV6j3oYGdpIGaMIGXMQswCQYDVQQGEwIwMDEN
> MAsGA1UECBMEaG9tZTEMMAoGA1UEBxMDdGN0MRAwDgYDVQQKEwd0Y3Qub3JnMSQw
> IgYDVQQLExt0Y3QudjMwNC5zZWNwMzg0cjEuMjAxODA1MjkxFDASBgNVBAMTC0Vh
> c3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAOfdO22e
> 6f1YMBMGA1UdJQQMMAoGCCsGAQUFBwMCMAsGA1UdDwQEAwIHgDAKBggqhkjOPQQD
> AgNnADBkAjBOOZpLsPmGIwChgnaP7eU/IK+oZPGyEJh1q2QxOKW/osq+GFQStYwd
> yZGK5gnFFqMCMFsy1HrQLpeGZVFPYBZRcb3KepAxXA1iGR6GKQyUMh8zztvbuR5A
> C1UX8Wye/9JSAw==
> -----END CERTIFICATE-----
> 
> 
> **********
> 
> Now using openssl 110h
> 
> $ openssl x509 -in /root/tct.v304.secp384r1.c01.crt -text
> Certificate:
>  ??? Data:
>  ??????? Version: 3 (0x2)
>  ??????? Serial Number:
>  ??????????? 48:07:85:ec:c8:78:e6:e3:ac:91:54:b3:91:07:83:d5
>  ??? Signature Algorithm: ecdsa-with-SHA256
>  ??????? Issuer: C = 00, ST = home, L = tct, O = tct.org, OU = 
> tct.v304.secp384r1.20180529, CN = Easy-RSA CA, emailAddress = 
> me at example.net
>  ??????? Validity
>  ??????????? Not Before: May 29 14:01:00 2018 GMT
>  ??????????? Not After : May 28 14:01:00 2028 GMT
>  ??????? Subject: C = 00, ST = home, L = tct, O = tct.org, OU = 
> tct.v304.secp384r1.20180529, CN = tct.v304.secp384r1.c01, emailAddress = 
> me at example.net
>  ??????? Subject Public Key Info:
>  ??????????? Public Key Algorithm: id-ecPublicKey
>  ??????????????? Public-Key: (384 bit)
>  ??????????????? pub:
>  ??????????????????? 04:b2:d4:42:ab:b7:bd:ba:d6:52:b6:9a:ca:30:50:
>  ??????????????????? 48:34:5b:72:bf:77:60:c3:7b:4b:fb:18:0f:90:27:
>  ??????????????????? a3:bf:f6:db:8b:47:be:04:1f:2a:10:b2:de:7f:6b:
>  ??????????????????? f5:e3:5b:12:11:8e:08:85:7c:5b:e8:27:3c:07:fc:
>  ??????????????????? 2f:cf:96:50:65:96:60:38:4e:49:ed:d5:b4:23:8e:
>  ??????????????????? 7a:64:d8:29:af:e2:c8:4a:49:31:2f:fe:3b:50:99:
>  ??????????????????? a1:7d:3b:30:bd:c4:d4
>  ??????????????? ASN1 OID: secp384r1
>  ??????????????? NIST CURVE: P-384
>  ??????? X509v3 extensions:
>  ??????????? X509v3 Basic Constraints:
>  ??????????????? CA:FALSE
>  ??????????? X509v3 Subject Key Identifier:
>                  
> 08:C1:03:47:D4:8E:FD:47:80:6B:33:33:D9:53:97:AF:75:BB:72:20
>  ??????????? X509v3 Authority Key Identifier:
> 
> keyid:3D:05:4B:95:5E:EF:C9:CF:73:00:3B:84:25:F6:65:35:8F:57:A8:F7
> 
> DirName:/C=00/ST=home/L=tct/O=tct.org/OU=tct.v304.secp384r1.20180529/CN=Easy-RSA 
> CA/emailAddress=me at example.net
>  ??????????????? serial:E7:DD:3B:6D:9E:E9:FD:58
> 
>  ??????????? X509v3 Extended Key Usage:
>  ??????????????? TLS Web Client Authentication
>  ??????????? X509v3 Key Usage:
>  ??????????????? Digital Signature
>  ??? Signature Algorithm: ecdsa-with-SHA256
>  ???????? 30:64:02:30:4e:39:9a:4b:b0:f9:86:23:00:a1:82:76:8f:ed:
>  ???????? e5:3f:20:af:a8:64:f1:b2:10:98:75:ab:64:31:38:a5:bf:a2:
>  ???????? ca:be:18:54:12:b5:8c:1d:c9:91:8a:e6:09:c5:16:a3:02:30:
>  ???????? 5b:32:d4:7a:d0:2e:97:86:65:51:4f:60:16:51:71:bd:ca:7a:
>  ???????? 90:31:5c:0d:62:19:1e:86:29:0c:94:32:1f:33:ce:db:db:b9:
>  ???????? 1e:40:0b:55:17:f1:6c:9e:ff:d2:52:03
> -----BEGIN CERTIFICATE-----
> MIIDljCCAx2gAwIBAgIQSAeF7Mh45uOskVSzkQeD1TAKBggqhkjOPQQDAjCBlzEL
> MAkGA1UEBhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UE
> ChMHdGN0Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5
> MRQwEgYDVQQDEwtFYXN5LVJTQSBDQTEdMBsGCSqGSIb3DQEJARYObWVAZXhhbXBs
> ZS5uZXQwHhcNMTgwNTI5MTQwMTAwWhcNMjgwNTI4MTQwMTAwWjCBojELMAkGA1UE
> BhMCMDAxDTALBgNVBAgTBGhvbWUxDDAKBgNVBAcTA3RjdDEQMA4GA1UEChMHdGN0
> Lm9yZzEkMCIGA1UECxMbdGN0LnYzMDQuc2VjcDM4NHIxLjIwMTgwNTI5MR8wHQYD
> VQQDExZ0Y3QudjMwNC5zZWNwMzg0cjEuYzAxMR0wGwYJKoZIhvcNAQkBFg5tZUBl
> eGFtcGxlLm5ldDB2MBAGByqGSM49AgEGBSuBBAAiA2IABLLUQqu3vbrWUraayjBQ
> SDRbcr93YMN7S/sYD5Ano7/224tHvgQfKhCy3n9r9eNbEhGOCIV8W+gnPAf8L8+W
> UGWWYDhOSe3VtCOOemTYKa/iyEpJMS/+O1CZoX07ML3E1KOCAR8wggEbMAkGA1Ud
> EwQCMAAwHQYDVR0OBBYEFAjBA0fUjv1HgGszM9lTl691u3IgMIHMBgNVHSMEgcQw
> gcGAFD0FS5Ve78nPcwA7hCX2ZTWPV6j3oYGdpIGaMIGXMQswCQYDVQQGEwIwMDEN
> MAsGA1UECBMEaG9tZTEMMAoGA1UEBxMDdGN0MRAwDgYDVQQKEwd0Y3Qub3JnMSQw
> IgYDVQQLExt0Y3QudjMwNC5zZWNwMzg0cjEuMjAxODA1MjkxFDASBgNVBAMTC0Vh
> c3ktUlNBIENBMR0wGwYJKoZIhvcNAQkBFg5tZUBleGFtcGxlLm5ldIIJAOfdO22e
> 6f1YMBMGA1UdJQQMMAoGCCsGAQUFBwMCMAsGA1UdDwQEAwIHgDAKBggqhkjOPQQD
> AgNnADBkAjBOOZpLsPmGIwChgnaP7eU/IK+oZPGyEJh1q2QxOKW/osq+GFQStYwd
> yZGK5gnFFqMCMFsy1HrQLpeGZVFPYBZRcb3KepAxXA1iGR6GKQyUMh8zztvbuR5A
> C1UX8Wye/9JSAw==
> -----END CERTIFICATE-----
> 
> 
> **********
> 

From Michael.Wojcik at microfocus.com  Wed May 30 13:55:54 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 30 May 2018 13:55:54 +0000
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
References: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
 <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
Message-ID: <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of FooCrypt
> Sent: Tuesday, May 29, 2018 21:41
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] PRNG is not seeded
>
> > On 30 May 2018, at 8:58 AM, Scott Neugroschl <scott_n at xypro.com>
> wrote:
> >
> > I?m using PRNGD to seed my random numbers (I?m on a system without
> > /dev/random and /dev/urandom).   I occasionally get the dreaded ?PRNG is
> > not seeded? error.
>
> I don?t know your OS or environment, have you tried the ?openssl rand?
> functionality as a random source to seed your entropy issues ?

Where would openssl rand be getting its entropy from, in this case? You have a circular dependency: openssl needs entropy, so it tries to get it from PRNGD; and you're asking openssl to put entropy into PRNGD.

> perhaps rather than pseudo random, try a hardware device ?

Now, this is a case where you might use openssl rand, in conjunction with engine, to get entropy from another source. That could be a useful hack if you can't easily change PRNGD or the application to read entropy from the device.

For example, I think I successfully used openssl with the pkcs11 engine to get entropy from a NitroKey device a couple of years back, when I was playing around with cheap HSMs.

Whether something like the NitroKey (which is an inexpensive USB-attached HSM in a thumbdrive form factor) would be useful in this case is something Scott would have to determine.

If it is, it'd be cleaner if he could change the application to load the pkcs11 engine and use its RNG directly, or at least get entropy from it to seed OpenSSL's PRNG.

> > I know this is caused by a lack of available entropy in the system; but what
> > can I do to address this?  Is it just a matter of waiting until enough entropy
> > has been collected?  Is there any kind of workaround?

Depends on what sources PRNGD uses (I haven't looked), what the device is, what the application is... If the device has sensors you can read, you might be able to gather some entropy by reading noise from them (though this is somewhat fraught - you don't want to overestimate the amount of entropy, and both sensors and sensor APIs are often vulnerable to attack).

Sometimes applications ask users to generate some entropy by asking them to  bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it really depends on what your device and application are.

This topic is discussed at some length in the technical literature; see for example section 3 of RFC 4086.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From openssl at foocrypt.net  Wed May 30 14:45:43 2018
From: openssl at foocrypt.net (FooCrypt)
Date: Thu, 31 May 2018 00:45:43 +1000
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
 <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
 <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <0115EDFD-94F0-4114-A83A-24352C9B74F6@foocrypt.net>


> On 30 May 2018, at 11:55 PM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of FooCrypt
>> Sent: Tuesday, May 29, 2018 21:41
>> To: openssl-users at openssl.org
>> Subject: Re: [openssl-users] PRNG is not seeded
>> 
>>> On 30 May 2018, at 8:58 AM, Scott Neugroschl <scott_n at xypro.com>
>> wrote:
>>> 
>>> I?m using PRNGD to seed my random numbers (I?m on a system without
>>> /dev/random and /dev/urandom).   I occasionally get the dreaded ?PRNG is
>>> not seeded? error.
>> 
>> I don?t know your OS or environment, have you tried the ?openssl rand?
>> functionality as a random source to seed your entropy issues ?
> 
> Where would openssl rand be getting its entropy from, in this case? You have a circular dependency: openssl needs entropy, so it tries to get it from PRNGD; and you're asking openssl to put entropy into PRNGD.
> 

Usage: rand [options] num
where options are
-out file             - write to file
-engine e             - use engine e, possibly a hardware device.
-rand file:file:... - seed PRNG from files
-base64               - base64 encode output
-hex                  - hex encode output


RAND(1) describes the multiplicity of sources that can all be used together in some detail.

DESCRIPTION
       The rand command outputs num pseudo-random bytes after seeding the random number generator once.  As in other openssl command line tools, PRNG seeding uses the file
       $HOME/.rnd or .rnd in addition to the files given in the -rand option.  A new $HOME/.rnd or .rnd file will be written back if enough seeding was obtained from these sources.

ls -la ~/.rnd
	-rw-------  1 XXXXX  XXXXX  1024 30 May 10:45 .rnd

Make some .rnd?s

	dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024

Make an engine

	Microphones work wonders and you can play with the sound, count, etc?.etc?.etc...

>> perhaps rather than pseudo random, try a hardware device ?
> 
> Now, this is a case where you might use openssl rand, in conjunction with engine, to get entropy from another source. That could be a useful hack if you can't easily change PRNGD or the application to read entropy from the device.
> 
> For example, I think I successfully used openssl with the pkcs11 engine to get entropy from a NitroKey device a couple of years back, when I was playing around with cheap HSMs.
> 
> Whether something like the NitroKey (which is an inexpensive USB-attached HSM in a thumbdrive form factor) would be useful in this case is something Scott would have to determine.
> 
> If it is, it'd be cleaner if he could change the application to load the pkcs11 engine and use its RNG directly, or at least get entropy from it to seed OpenSSL's PRNG.
> 
>>> I know this is caused by a lack of available entropy in the system; but what
>>> can I do to address this?  Is it just a matter of waiting until enough entropy
>>> has been collected?  Is there any kind of workaround?
> 
> Depends on what sources PRNGD uses (I haven't looked), what the device is, what the application is... If the device has sensors you can read, you might be able to gather some entropy by reading noise from them (though this is somewhat fraught - you don't want to overestimate the amount of entropy, and both sensors and sensor APIs are often vulnerable to attack).
> 
> Sometimes applications ask users to generate some entropy by asking them to  bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it really depends on what your device and application are.
> 
> This topic is discussed at some length in the technical literature; see for example section 3 of RFC 4086.
> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From Michael.Wojcik at microfocus.com  Wed May 30 15:35:26 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Wed, 30 May 2018 15:35:26 +0000
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <0115EDFD-94F0-4114-A83A-24352C9B74F6@foocrypt.net>
References: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
 <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
 <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
 <0115EDFD-94F0-4114-A83A-24352C9B74F6@foocrypt.net>
Message-ID: <SN1PR18MB21120827DF1F9A5FD6A33264F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of FooCrypt
> Sent: Wednesday, May 30, 2018 10:46
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] PRNG is not seeded
>
> > On 30 May 2018, at 11:55 PM, Michael Wojcik
> <Michael.Wojcik at microfocus.com> wrote:
> >
> > Where would openssl rand be getting its entropy from, in this case? You
> have a circular dependency: openssl needs entropy, so it tries to get it from
> PRNGD; and you're asking openssl to put entropy into PRNGD.
> >
>
> Usage: rand [options] num

Spare me, please.

> RAND(1) describes the multiplicity of sources that can all be used together in
> some detail.

And why do you think this solves the problem?

>        The rand command outputs num pseudo-random bytes after seeding the
> random number generator once.

So all the entropy you can get from the output of "openssl rand" is whatever OpenSSL was able to gather when it seeded the PRNG. Which is exactly the problem Scott was trying to solve.

> Make some .rnd?s

YOU STILL HAVE TO FIND ENTROPY TO PUT IN THEM. All you're doing is pushing the problem around the plate.

>
>       dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024

Where [SOMEDEVICE] is your magical unicorn entropy device?

> Make an engine

I already mentioned the engine interface in my previous response. And if this is an option for Scott, it would be much better to use the engine in his application, rather than going through the rigamarole of running "openssl rand" to grab some entropy from it. The command-line utility is useful iff he can't change the application.

>       Microphones work wonders

No, they really don't. Look at the literature. (And, again, I mentioned sensors in my previous response.)

> and you can play with the sound, count,
> etc?.etc?.etc...

Cargo-cult entropy gathering. It may be fine under a given threat model, but we have no idea what Scott's is. As general advice it's poor.

--
Michael Wojcik
Distinguished Engineer, Micro Focus




From scott_n at xypro.com  Wed May 30 15:37:47 2018
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 30 May 2018 15:37:47 +0000
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
 <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
 <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <D358E5B1511A314F8160ADC6F37549870114193834@XYSVEX02.XYPRO-23.LOCAL>

>>> I?m using PRNGD to seed my random numbers (I?m on a system without
>>> /dev/random and /dev/urandom).   I occasionally get the dreaded ?PRNG is
>>> not seeded? error.
>>
>> I don?t know your OS or environment, have you tried the ?openssl rand?
>> functionality as a random source to seed your entropy issues ?
>
>Where would openssl rand be getting its entropy from, in this case? You have a circular dependency: openssl needs entropy, so it tries to get it from PRNGD; and you're asking openssl to put entropy into PRNGD.
>
>> perhaps rather than pseudo random, try a hardware device ?
>
>Now, this is a case where you might use openssl rand, in conjunction with engine, to get entropy from another source. That could be a useful hack if you can't easily change PRNGD or the application to read entropy from the device.
>
>For example, I think I successfully used openssl with the pkcs11 engine to get entropy from a NitroKey device a couple of years back, when I was playing around with cheap HSMs.
>
>Whether something like the NitroKey (which is an inexpensive USB-attached HSM in a thumbdrive form factor) would be useful in this case is something Scott would have to determine.
>
>If it is, it'd be cleaner if he could change the application to load the pkcs11 engine and use its RNG directly, or at least get entropy from it to seed OpenSSL's PRNG.
>
>>> I know this is caused by a lack of available entropy in the system; 
>>> but what can I do to address this?  Is it just a matter of waiting 
>>> until enough entropy has been collected?  Is there any kind of workaround?
>
>Depends on what sources PRNGD uses (I haven't looked), what the device is, what the application is... If the device has sensors you can read, you might be able to gather some entropy by reading noise from them (though this is somewhat fraught - you don't want to overestimate the amount of entropy, and both sensors and sensor APIs are often vulnerable to attack).
>
>Sometimes applications ask users to generate some entropy by asking them to  bang on the keyboard or wiggle the mouse, or that sort of thing. Again, it really depends on what your device and application are.
>
>This topic is discussed at some length in the technical literature; see for example section 3 of RFC 4086.
>

The platform in question is an HPE NonStop.



From openssl at foocrypt.net  Wed May 30 16:12:10 2018
From: openssl at foocrypt.net (FooCrypt)
Date: Thu, 31 May 2018 02:12:10 +1000
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <SN1PR18MB21120827DF1F9A5FD6A33264F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
References: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
 <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
 <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
 <0115EDFD-94F0-4114-A83A-24352C9B74F6@foocrypt.net>
 <SN1PR18MB21120827DF1F9A5FD6A33264F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
Message-ID: <8B4CF404-2AB7-46D2-AFB9-F02607AC79F2@foocrypt.net>


> On 31 May 2018, at 1:35 AM, Michael Wojcik <Michael.Wojcik at microfocus.com> wrote:
> 
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
>> Of FooCrypt
>> Sent: Wednesday, May 30, 2018 10:46
>> To: openssl-users at openssl.org
>> Subject: Re: [openssl-users] PRNG is not seeded
>> 
>>> On 30 May 2018, at 11:55 PM, Michael Wojcik
>> <Michael.Wojcik at microfocus.com> wrote:
>>> 
>>> Where would openssl rand be getting its entropy from, in this case? You
>> have a circular dependency: openssl needs entropy, so it tries to get it from
>> PRNGD; and you're asking openssl to put entropy into PRNGD.
>>> 
>> 
>> Usage: rand [options] num
> 
> Spare me, please.
> 
>> RAND(1) describes the multiplicity of sources that can all be used together in
>> some detail.
> 
> And why do you think this solves the problem?

Well its HP?s problem, not openssl?s

> 
>>       The rand command outputs num pseudo-random bytes after seeding the
>> random number generator once.
> 
> So all the entropy you can get from the output of "openssl rand" is whatever OpenSSL was able to gather when it seeded the PRNG. Which is exactly the problem Scott was trying to solve.
> 
>> Make some .rnd?s
> 
> YOU STILL HAVE TO FIND ENTROPY TO PUT IN THEM. All you're doing is pushing the problem around the plate.

generate them on another host

> 
>> 
>>      dd if=/dev/[SOMEDEVICE] of=~/.rnd bs=1 count=1024
> 
> Where [SOMEDEVICE] is your magical unicorn entropy device?

well its not /dev/random, its a HPE NonStop with no entropy that stops the application.


> 
>> Make an engine
> 
> I already mentioned the engine interface in my previous response. And if this is an option for Scott, it would be much better to use the engine in his application, rather than going through the rigamarole of running "openssl rand" to grab some entropy from it. The command-line utility is useful iff he can't change the application.

HPE NonStops don?t have DTrace

> 
>>      Microphones work wonders
> 
> No, they really don't. Look at the literature. (And, again, I mentioned sensors in my previous response.)
> 
>> and you can play with the sound, count,
>> etc?.etc?.etc...
> 
> Cargo-cult entropy gathering. It may be fine under a given threat model, but we have no idea what Scott's is. As general advice it's poor.

Probably financial sector, with PCI compliance and they can;t afford /dev/random or /dev/urandom


> 
> --
> Michael Wojcik
> Distinguished Engineer, Micro Focus
> 
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From levitte at openssl.org  Wed May 30 16:53:09 2018
From: levitte at openssl.org (Richard Levitte)
Date: Wed, 30 May 2018 18:53:09 +0200 (CEST)
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <D358E5B1511A314F8160ADC6F37549870114193834@XYSVEX02.XYPRO-23.LOCAL>
References: <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
 <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
 <D358E5B1511A314F8160ADC6F37549870114193834@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <20180530.185309.865195101276366828.levitte@openssl.org>

In message <D358E5B1511A314F8160ADC6F37549870114193834 at XYSVEX02.XYPRO-23.LOCAL> on Wed, 30 May 2018 15:37:47 +0000, Scott Neugroschl <scott_n at xypro.com> said:

scott_n> The platform in question is an HPE NonStop.

NonStop isn't the only platform with this sort of problem...  I'd
suggest asking in places dedicated to NonStop if they know of good
enough ways to gather enough entropy, such as comp.sys.tandem,
perhaps?

Either way, trying to use OpenSSL's PRNGD to seed OpenSSL's PRNGD is
an exercise in futility.

Cheers,
Richard

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

From Michal.Trojnara at stunnel.org  Wed May 30 16:54:06 2018
From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=)
Date: Wed, 30 May 2018 18:54:06 +0200
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
Message-ID: <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>

On 05/29/2018 01:48 AM, Viktor Dukhovni wrote:
> I am rather puzzled as to why you chose to eliminate
> not just fixed DH, but also the ephemeral finite-field
> DH key exchange.  What's wrong with the DHE ciphers?
Mostly precomputation attacks: https://weakdh.org/logjam.html
Those parameters are "ephemeral", but not really unique for each TLS
session.
They are also quite slow compared to their EC counterparts...

> I would have chosen:
>
> 	HIGH:!aNULL:!kDH:!kECDH:!MD5
>
> which excludes the *fixed* DH/ECDH ciphers and MD5
> (and thus also SSLv2).  This does not eliminate
> ephemeral finite-field DH, not sure why you're doing
> that...
Actually the only MD5 vulnerability is collisions.? This may be a threat
for some CAs that use predictable serial numbers, but there are no known
risk for HMACs as used in TLS cipher suites.

Also, excluding kECDH cipher suites sounds like a good idea indeed.

Best regards,
??? Mike


From openssl-users at dukhovni.org  Wed May 30 17:12:06 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 30 May 2018 13:12:06 -0400
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
Message-ID: <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>



> On May 30, 2018, at 12:54 PM, Micha? Trojnara <Michal.Trojnara at stunnel.org> wrote:
> 
>> I am rather puzzled as to why you chose to eliminate
>> not just fixed DH, but also the ephemeral finite-field
>> DH key exchange.  What's wrong with the DHE ciphers?
> 
> Mostly precomputation attacks: https://weakdh.org/logjam.html

Which is an issue with *weak* DH parameters, which are no longer
accepted by OpenSSL.  Ephemeral DH is in the majority of server
implementations actually ephemeral.  The group is fixed, but
the server private key is per session, or with old unpatched
code randomly chosen by each server.  It is not clear to me
that EECDH is fundamentally stronger.  Indeed it might prove
weak sooner to QC attacks if/when those become practical.

So I would disable only kDH, but not DHE.  Keep in mind that
some remote systems will not support EECDH, and by disabling
DHE, you get only kRSA, which is worse.  So I think that
'!DH' is unwise.

-- 
	Viktor.


From scott_n at xypro.com  Wed May 30 17:15:26 2018
From: scott_n at xypro.com (Scott Neugroschl)
Date: Wed, 30 May 2018 17:15:26 +0000
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <20180530.185309.865195101276366828.levitte@openssl.org>
References: <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
 <SN1PR18MB2112ABD27E7983F24D661AD2F96C0@SN1PR18MB2112.namprd18.prod.outlook.com>
 <D358E5B1511A314F8160ADC6F37549870114193834@XYSVEX02.XYPRO-23.LOCAL>
 <20180530.185309.865195101276366828.levitte@openssl.org>
Message-ID: <D358E5B1511A314F8160ADC6F37549870114193955@XYSVEX02.XYPRO-23.LOCAL>


> Either way, trying to use OpenSSL's PRNGD to seed OpenSSL's PRNGD is an exercise in futility.

Oh, I agree on that.  



From openssl at jordan.maileater.net  Wed May 30 20:06:58 2018
From: openssl at jordan.maileater.net (Jordan Brown)
Date: Wed, 30 May 2018 13:06:58 -0700
Subject: [openssl-users] Test SSL connection
In-Reply-To: <5B0E5DEF.7010002@mathemainzel.info>
References: <DM5PR04MB3753D78EB6AE007D2899E5F88E6C0@DM5PR04MB3753.namprd04.prod.outlook.com>
 <5B0E5DEF.7010002@mathemainzel.info>
Message-ID: <9f10523e-836e-2c4d-d727-63e4125b31c1@jordan.maileater.net>

On 5/30/2018 1:16 AM, Walter H. wrote:
> On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote:
>> [...]
>>
>> openssl s_client -connect 10.65.48.108:443
>>
>> [...]
> very probable, that the client doesn't have the root ca certificate of
> the ca certificate that signed server.pem
>
> you should have at least the following
>
> ca.pem? - the root ca
> server.pem - the server ssl/tls certificate

And also:? the certificate is unlikely to list an IP address, so it
should fail hostname verification.? You need to use a host name in your
client connection request, not an IP address.

(Pretty much, you don't ever want to use IP addresses in specifying TLS
connections.)

-- 
Jordan Brown, Oracle Solaris

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

From openssl-users at dukhovni.org  Wed May 30 21:08:16 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Wed, 30 May 2018 17:08:16 -0400
Subject: [openssl-users] Test SSL connection
In-Reply-To: <9f10523e-836e-2c4d-d727-63e4125b31c1@jordan.maileater.net>
References: <DM5PR04MB3753D78EB6AE007D2899E5F88E6C0@DM5PR04MB3753.namprd04.prod.outlook.com>
 <5B0E5DEF.7010002@mathemainzel.info>
 <9f10523e-836e-2c4d-d727-63e4125b31c1@jordan.maileater.net>
Message-ID: <74449AD9-77E7-4E80-97FD-EBF9BBE4FB11@dukhovni.org>



> On May 30, 2018, at 4:06 PM, Jordan Brown <openssl at jordan.maileater.net> wrote:
> 
> And also:  the certificate is unlikely to list an IP address, so it should fail hostname verification.  You need to use a host name in your client connection request, not an IP address.
> 
> (Pretty much, you don't ever want to use IP addresses in specifying TLS connections.)

True, but s_client does not do namechecks by default.  You'd have
to request that behaviour with the "-verify_hostname" option.  The
OP does not report doing that, so verification was likely limited
to just checking the trust chain.

A more complete invocation (with 1.1.0 or later) would be:

  openssl s_client \
	-connect $host:$port \
	-CApath $capath \
	-CAfile $cafile \
	-verify $depth \
	-servername $host \
	-verify_hostname $host \
        -verify_return_error

for suitable choices of $capath, $cafile, $depth, $host and $port
and in some cases additional desired options.

-- 
	Viktor.


From Michal.Trojnara at stunnel.org  Thu May 31 04:09:07 2018
From: Michal.Trojnara at stunnel.org (Michal Trojnara)
Date: Thu, 31 May 2018 06:09:07 +0200
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
Message-ID: <a2206781-16a2-0b54-9331-726df146b877@stunnel.org>

On 30.05.2018 19:12, Viktor Dukhovni wrote:

> So I would disable only kDH, but not DHE.  Keep in mind that
> some remote systems will not support EECDH, and by disabling
> DHE, you get only kRSA, which is worse.  So I think that
> '!DH' is unwise.
I respectfully disagree.? The only practical disadvantage of kRSA is
that it doesn't provide PFS.? Losing PFS is bad, but it's not a huge
price for ensuring secure key exchange.? Actually, there aren't that
many platforms nowadays that support kDHE and not kECDHE.

Best regards,
??? Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180531/1723364b/attachment.sig>

From openssl-users at dukhovni.org  Thu May 31 04:15:24 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 31 May 2018 00:15:24 -0400
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <a2206781-16a2-0b54-9331-726df146b877@stunnel.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
 <a2206781-16a2-0b54-9331-726df146b877@stunnel.org>
Message-ID: <B5485219-A44F-4A4A-9DC1-20541034161B@dukhovni.org>



> On May 31, 2018, at 12:09 AM, Michal Trojnara <Michal.Trojnara at stunnel.org> wrote:
> 
> I respectfully disagree.  The only practical disadvantage of kRSA is
> that it doesn't provide PFS.  Losing PFS is bad, but it's not a huge
> price for ensuring secure key exchange.

There's an assumption here that DHE key exchange is not secure,
while ECDHE is secure.  That assumption is wrong.  Only export
grade DHE was shown weak in logjam.  OpenSSL no longer accepts
weak DHE keys.  There are also weak ECDSA curves that old
implementations would accept, there nothing fundamentally
better (performance aside) about ECDHE vs. DHE.  Indeed
some trust DHE more because the keys are larger and perhaps
more resistant to QC, and the mathematics is better understood
(less bleeding edge than elliptic curves).

I expect there are still plenty of LTS RedHat systems that
ship without EC support, though yes anything reasonably
up to date, will have EC support.

Ultimately of course up to you and your users, I think I've
made my case as well as I could.  Good luck.

-- 
	Viktor.


From Michal.Trojnara at stunnel.org  Thu May 31 07:27:55 2018
From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=)
Date: Thu, 31 May 2018 09:27:55 +0200
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <B5485219-A44F-4A4A-9DC1-20541034161B@dukhovni.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
 <a2206781-16a2-0b54-9331-726df146b877@stunnel.org>
 <B5485219-A44F-4A4A-9DC1-20541034161B@dukhovni.org>
Message-ID: <25060c7a-6c38-9c10-f1e3-5888cbc5dc4a@stunnel.org>

On 05/31/2018 06:15 AM, Viktor Dukhovni wrote:
> I expect there are still plenty of LTS RedHat systems that
> ship without EC support, though yes anything reasonably
> up to date, will have EC support.
AFAIR EC cipher suites were introduced in OpenSSL 1.0.0, so those LTS
systems must be using OpenSSL 0.9.x.? In 2018 this is asking for
trouble, and a clear evidence that they don't care about security...
> Ultimately of course up to you and your users, I think I've
> made my case as well as I could.  Good luck.
Indeed.? Thank you.? I highly appreciate your input.? Defining an
acceptable security margin for algorithms is tough, especially with QC
predictions in mind...

Best regards,
??? Mike

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180531/1928c520/attachment.sig>

From openssl-users at dukhovni.org  Thu May 31 07:40:02 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 31 May 2018 03:40:02 -0400
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <25060c7a-6c38-9c10-f1e3-5888cbc5dc4a@stunnel.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
 <a2206781-16a2-0b54-9331-726df146b877@stunnel.org>
 <B5485219-A44F-4A4A-9DC1-20541034161B@dukhovni.org>
 <25060c7a-6c38-9c10-f1e3-5888cbc5dc4a@stunnel.org>
Message-ID: <BF7778C0-4066-491A-A35E-3BD4EAA6E783@dukhovni.org>



> On May 31, 2018, at 3:27 AM, Micha? Trojnara <Michal.Trojnara at stunnel.org> wrote:
> 
> AFAIR EC cipher suites were introduced in OpenSSL 1.0.0, so those LTS
> systems must be using OpenSSL 0.9.x. 

Actually, no.  For IP-related reasons, RedHat for a long time
disabled EC support in OpenSSL 1.0.x.  I expect some of those
systems are still deployed.

-- 
	Viktor.

From Mark.Shnaider at docusign.com  Thu May 31 07:49:52 2018
From: Mark.Shnaider at docusign.com (Mark Shnaider)
Date: Thu, 31 May 2018 07:49:52 +0000
Subject: [openssl-users] Test SSL connection
In-Reply-To: <5B0E5DEF.7010002@mathemainzel.info>
References: <DM5PR04MB3753D78EB6AE007D2899E5F88E6C0@DM5PR04MB3753.namprd04.prod.outlook.com>
 <5B0E5DEF.7010002@mathemainzel.info>
Message-ID: <DM5PR04MB3753EBBA5A55022E50B371F18E630@DM5PR04MB3753.namprd04.prod.outlook.com>

Hello Walter,
I did not found  file ca.pem (root certificate) for testing.

Thanks
Mark

From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Walter H.
Sent: Wednesday, May 30, 2018 11:17 AM
To: openssl-users at openssl.org
Subject: Re: [openssl-users] Test SSL connection

On 30.05.2018 08:45, Mark Shnaider via openssl-users wrote:

Hello,

I use  OpenSSL version is openssl-1.1.0h(Windows) and

I run following command from apps directory

openssl s_server -accept 443 -www

The server in this case use certificate "server.pem"

On client computer I run command

openssl s_client -connect 10.65.48.108:443

On client computer I  get error :

Verify return code: 21 (unable to verify the first certificate)

What is wrong?

Thanks for any help

Mark
very probable, that the client doesn't have the root ca certificate of the ca certificate that signed server.pem

you should have at least the following

ca.pem  - the root ca
server.pem - the server ssl/tls certificate

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

From chris.gray at kiffer.be  Thu May 31 08:07:32 2018
From: chris.gray at kiffer.be (chris.gray at kiffer.be)
Date: Thu, 31 May 2018 09:07:32 +0100
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
References: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
 <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
Message-ID: <8c6db9437f72645779b0221d0abdff30.squirrel@koningbalthazar.be>

I've also encountered this quite often, and I have a feeling that on
today's connected devices there may be a lot of entropy "in the air"
(quite literally) which is not being captured. Does any one know of 
research in this area?

> Hi Scott
>
> I don???t know your OS or environment, have you tried the ???openssl
> rand??? functionality as a random source to seed your entropy issues ?
>
> openssl rand 102400 > some named pipe file that you can call as your
> random source.
>
> perhaps rather than pseudo random, try a hardware device ?
>
>
>
>> On 30 May 2018, at 8:58 AM, Scott Neugroschl <scott_n at xypro.com> wrote:
>>
>> Hi,
>>
>> I???m using PRNGD to seed my random numbers (I???m on a system without
>> /dev/random and /dev/urandom).   I occasionally get the dreaded ???PRNG
>> is not seeded??? error.
>>
>> I know this is caused by a lack of available entropy in the system; but
>> what can I do to address this?  Is it just a matter of waiting until
>> enough entropy has been collected?  Is there any kind of workaround?
>>
>> Thanks
>>
>> ScottN
>>
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>



From openssl at foocrypt.net  Thu May 31 08:45:02 2018
From: openssl at foocrypt.net (FooCrypt)
Date: Thu, 31 May 2018 18:45:02 +1000
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <8c6db9437f72645779b0221d0abdff30.squirrel@koningbalthazar.be>
References: <D358E5B1511A314F8160ADC6F37549870114193542@XYSVEX02.XYPRO-23.LOCAL>
 <CE12C715-977D-4D44-A54C-B6C63DAEF988@foocrypt.net>
 <8c6db9437f72645779b0221d0abdff30.squirrel@koningbalthazar.be>
Message-ID: <EEBB3883-25B4-46B7-A025-D11D31B461F9@foocrypt.net>

Are you a Dr Who fan ?

Place a teaspoon of fine grade white sand onto the skin of a snare drum

Place an isolating isoscrope above the snare drum that can measure the fractional movements of the grains of sand based on the ambient noise.

Do something that moves the sand so you can measure the factorial movements based on different events.

There was a documentary on the ABC about it all a few years back, someone at ANU or somewhere else in Oz was woking on the research.


> On 31 May 2018, at 6:07 PM, chris.gray at kiffer.be wrote:
> 
> I've also encountered this quite often, and I have a feeling that on
> today's connected devices there may be a lot of entropy "in the air"
> (quite literally) which is not being captured. Does any one know of 
> research in this area?
> 
>> Hi Scott
>> 
>> I don???t know your OS or environment, have you tried the ???openssl
>> rand??? functionality as a random source to seed your entropy issues ?
>> 
>> openssl rand 102400 > some named pipe file that you can call as your
>> random source.
>> 
>> perhaps rather than pseudo random, try a hardware device ?
>> 
>> 
>> 
>>> On 30 May 2018, at 8:58 AM, Scott Neugroschl <scott_n at xypro.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I???m using PRNGD to seed my random numbers (I???m on a system without
>>> /dev/random and /dev/urandom).   I occasionally get the dreaded ???PRNG
>>> is not seeded??? error.
>>> 
>>> I know this is caused by a lack of available entropy in the system; but
>>> what can I do to address this?  Is it just a matter of waiting until
>>> enough entropy has been collected?  Is there any kind of workaround?
>>> 
>>> Thanks
>>> 
>>> ScottN
>>> 
>>> --
>>> openssl-users mailing list
>>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>> 
>> --
>> openssl-users mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>> 
> 
> 
> -- 
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


From Michael.Wojcik at microfocus.com  Thu May 31 12:09:47 2018
From: Michael.Wojcik at microfocus.com (Michael Wojcik)
Date: Thu, 31 May 2018 12:09:47 +0000
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <BF7778C0-4066-491A-A35E-3BD4EAA6E783@dukhovni.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
 <a2206781-16a2-0b54-9331-726df146b877@stunnel.org>
 <B5485219-A44F-4A4A-9DC1-20541034161B@dukhovni.org>
 <25060c7a-6c38-9c10-f1e3-5888cbc5dc4a@stunnel.org>
 <BF7778C0-4066-491A-A35E-3BD4EAA6E783@dukhovni.org>
Message-ID: <SN1PR18MB21124E86F6D7A22CBC935D7CF9630@SN1PR18MB2112.namprd18.prod.outlook.com>

> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Viktor Dukhovni
> Sent: Thursday, May 31, 2018 03:40
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] stunnel 5.46 released
>
>
> > On May 31, 2018, at 3:27 AM, Micha? Trojnara
> <Michal.Trojnara at stunnel.org> wrote:
> >
> > AFAIR EC cipher suites were introduced in OpenSSL 1.0.0, so those LTS
> > systems must be using OpenSSL 0.9.x.
>
> Actually, no.  For IP-related reasons, RedHat for a long time
> disabled EC support in OpenSSL 1.0.x.  I expect some of those
> systems are still deployed.

As do some other products that use OpenSSL. There's a great deal of FUD regarding ECC.

For the record, I'm with Viktor on this. WeakDH does not justify disabling finite-field DHE entirely; that's a misinterpretation of the WeakDH discovery. There's no advantage to having !DH in the default cipher string.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



From sampei02 at tiscali.it  Thu May 31 13:03:21 2018
From: sampei02 at tiscali.it (Sampei)
Date: Thu, 31 May 2018 15:03:21 +0200
Subject: [openssl-users] database openssl
In-Reply-To: <b7356d4f-4869-a57f-efc4-1023413ec42b@wisemo.com>
References: <a394da529f40241da81e8892c5dd6e23@tiscali.it>
 <1283ec38-fefc-a8ce-845d-b79b79952cdc@nikhef.nl>
 <b7356d4f-4869-a57f-efc4-1023413ec42b@wisemo.com>
Message-ID: <7b2d681035480e9af96f3e8bf7bbac1a@tiscali.it>

  

Oh, It's a good starter point. 
Openssl, installed in old server,
is 0.9.7e version. 
Openssl, installed in new server, is -0.9.8e verson.

In old server I searched .cnf files and I found several files which are
/usr/local/openssl-0.9.7e/xxx/yyyyy.cnf 
where  
xxx= is directory, 

yyyy = name of .cnf file 
I queried to
/var/cache/yum/updates-released/packages/openssl-0.9.7a-33.10.i686.rpm
in old server, I got:

/lib/libcrypto.so.0.9.7a
/lib/libssl.so.0.9.7a
/usr/bin/openssl
/usr/share/doc/openssl-0.9.7a
/usr/share/doc/openssl-0.9.7a/CHANGES
/usr/share/doc/openssl-0.9.7a/FAQ
/usr/share/doc/openssl-0.9.7a/INSTALL
/usr/share/doc/openssl-0.9.7a/LICENSE
/usr/share/doc/openssl-0.9.7a/NEWS
/usr/share/doc/openssl-0.9.7a/README
/usr/share/doc/openssl-0.9.7a/c-indentation.el
/usr/share/doc/openssl-0.9.7a/openssl.txt
/usr/share/doc/openssl-0.9.7a/openssl_button.gif
/usr/share/doc/openssl-0.9.7a/openssl_button.html
/usr/share/doc/openssl-0.9.7a/ssleay.txt
/usr/share/man/man1/asn1parse.1ssl.gz
/usr/share/man/man1/ca.1ssl.gz
/usr/share/man/man1/ciphers.1ssl.gz
/usr/share/man/man1/crl.1ssl.gz
/usr/share/man/man1/crl2pkcs7.1ssl.gz
/usr/share/man/man1/dgst.1ssl.gz
/usr/share/man/man1/dhparam.1ssl.gz
/usr/share/man/man1/dsa.1ssl.gz
/usr/share/man/man1/dsaparam.1ssl.gz
/usr/share/man/man1/enc.1ssl.gz
/usr/share/man/man1/gendsa.1ssl.gz
/usr/share/man/man1/genrsa.1ssl.gz
/usr/share/man/man1/md2.1ssl.gz
/usr/sh
are/man/man1/md4.1ssl.gz
/usr/share/man/man1/md5.1ssl.gz
/usr/share/man/man1/mdc2.1ssl.gz
/usr/share/man/man1/nseq.1ssl.gz
/usr/share/man/man1/ocsp.1ssl.gz
/usr/share/man/man1/openssl.1ssl.gz
/usr/share/man/man1/pkcs12.1ssl.gz
/usr/share/man/man1/pkcs7.1ssl.gz
/usr/share/man/man1/pkcs8.1ssl.gz
/usr/share/man/man1/req.1ssl.gz
/usr/share/man/man1/ripemd160.1ssl.gz
/usr/share/man/man1/rsa.1ssl.gz
/usr/share/man/man1/rsautl.1ssl.gz
/usr/share/man/man1/s_client.1ssl.gz
/usr/share/man/man1/s_server.1ssl.gz
/usr/share/man/man1/sess_id.1ssl.gz
/usr/share/man/man1/sha.1ssl.gz
/usr/share/man/man1/sha1.1ssl.gz
/usr/share/man/man1/smime.1ssl.gz
/usr/share/man/man1/speed.1ssl.gz
/usr/share/man/man1/spkac.1ssl.gz
/usr/share/man/man1/sslpasswd.1ssl.gz
/usr/share/man/man1/sslrand.1ssl.gz
/usr/share/man/man1/verify.1ssl.gz
/usr/share/man/man1/version.1ssl.gz
/usr/share/man/man1/x509.1ssl.gz
/usr/share/man/man5/config.5ssl.gz
/usr/share/man/man7/DES.7ssl.gz
/usr/share/man/man7/Modes.7ssl.gz
/usr/share
/man/man7/des_modes.7ssl.gz
/usr/share/man/man7/of.7ssl.gz
/usr/share/ssl
/usr/share/ssl/CA
/usr/share/ssl/CA/private
/usr/share/ssl/cert.pem
/usr/share/ssl/certs
/usr/share/ssl/certs/Makefile
/usr/share/ssl/certs/ca-bundle.crt
/usr/share/ssl/certs/make-dummy-cert
/usr/share/ssl/lib
/usr/share/ssl/misc
/usr/share/ssl/misc/CA
/usr/share/ssl/misc/c_hash
/usr/share/ssl/misc/c_info
/usr/share/ssl/misc/c_issuer
/usr/share/ssl/misc/c_name
/usr/share/ssl/openssl.cnf
/usr/share/ssl/private

I don't understand because rpm has no reference to
"/usr/local/openssl-0.9.7e/" path where there .cnf configuration files.


Il 29.05.2018 10:43 Jan Just Keijser ha scritto: 

> Hi,
> 
> On
29/05/18 09:47, Sampei wrote:
> 
>> I'm using Linux server to create
temporary CA and I know openssl maintains a text database of issued
certificates and their status. Now I need to migrate this server to
another one, so I ask myself how can I export this db. thanks
> 
> the
openssl CA "database" usually consists of two files. The location of
these files is specified in the openssl.cnf file. The 
> files are
>
serial - containing the last issued serial number
> index.txt -
containing the list of all issued, expired and revoked certificates.
>

> As I said, the location of these files is depending on how you set up
your temporary CA.
> 
> HTH,
> 
> JJK

Il 29.05.2018 13:12 Jakob Bohm ha
scritto: 

> On 29/05/2018 10:43, Jan Just Keijser wrote:
> 
>> Hi, On
29/05/18 09:47, Sampei wrote: 
>> 
>>> I'm using Linux server to create
temporary CA and I know openssl maintains a text database of issued
certificates and their status. Now I need to migrate this server to
another one, so I ask myself how can I export this db. thanks
>> the
openssl CA "database" usually consists of two files. The location of
these files is specified in the openssl.cnf file. The files are serial -
containing the last issued serial number index.txt - containing the list
of all issued, expired and revoked certificates. As I said, the location
of these files is depending on how you set up your temporary CA.
> 
>
Additionally, the openssl ca command stores the complete value of each
>
issued certificate in a subdirectory specified in openssl.cnf, this
>
may be needed/useful when importing to other CA software.
> 
> Also note
that unless a special setting is included (I forget where),
> the
openssl ca database will be in a different (older) format that
> only
remembers the most recently issued certificate for a given
> subject
distinguished name.
> 
> Enjoy
> 
> Jakob
> -- 
> Jakob Bohm, CIO,
Partner, WiseMo A/S. https://www.wisemo.com [1]
> Transformervej 29,
2860 S?borg, Denmark. Direct +45 31 13 16 10
> This public discussion
message is non-binding and may contain errors.
> WiseMo - Remote Service
Management for PCs, Phones and Embedded
> 
> -- openssl-users mailing
list To unsubscribe:
https://mta.openssl.org/mailman/listinfo/openssl-users [2]
 



Con Mobile Open 6 GB hai 6 Giga, 600 minuti e 300 SMS per il tuo smartphone a 9? al mese per sempre. Passa ora a Tiscali Mobile, il nostro mese ? vero! http://tisca.li/Open6GB0318

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

From tmraz at redhat.com  Thu May 31 16:37:18 2018
From: tmraz at redhat.com (Tomas Mraz)
Date: Thu, 31 May 2018 18:37:18 +0200
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
Message-ID: <1527784638.30157.38.camel@redhat.com>

On Wed, 2018-05-30 at 13:12 -0400, Viktor Dukhovni wrote:
> > On May 30, 2018, at 12:54 PM, Micha? Trojnara <Michal.Trojnara at stun
> > nel.org> wrote:
> > 
> > > I am rather puzzled as to why you chose to eliminate
> > > not just fixed DH, but also the ephemeral finite-field
> > > DH key exchange.  What's wrong with the DHE ciphers?
> > 
> > Mostly precomputation attacks: https://weakdh.org/logjam.html
> 
> Which is an issue with *weak* DH parameters, which are no longer
> accepted by OpenSSL.  Ephemeral DH is in the majority of server
> implementations actually ephemeral.  The group is fixed, but
> the server private key is per session, or with old unpatched
> code randomly chosen by each server.  It is not clear to me
> that EECDH is fundamentally stronger.  Indeed it might prove
> weak sooner to QC attacks if/when those become practical.

I would not say that weak DH parameters are fully rejected by OpenSSL.
The 1024 bit DH parameters could be in theory attacked by state
agencies by precomputation of the discrete logarithm table. And openssl
still accepts 1024 bit DH by default if I am not mistaken.

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


From sandeep.bvb at gmail.com  Thu May 31 17:23:38 2018
From: sandeep.bvb at gmail.com (Sandeep Deshpande)
Date: Thu, 31 May 2018 10:23:38 -0700
Subject: [openssl-users] Fwd: basic constraints check
In-Reply-To: <CAG1qr9DnSkCRO-Md5rh1gN2eAcEHPrnSHNSaTXqaY1-mVbd=dw@mail.gmail.com>
References: <CAG1qr9DnSkCRO-Md5rh1gN2eAcEHPrnSHNSaTXqaY1-mVbd=dw@mail.gmail.com>
Message-ID: <CAG1qr9AgSg2fxSAyMYvAxeorK0usNSNco3Pcogq9W7dwKHwdMg@mail.gmail.com>

Hi ,

We are using openssl 1.0.2j and have 3 level certificates like this.
root  CA --> intermediate 01 CA-->intermediate02 CA -->Server certificate.

We generated intermediate02 such that it has "basicConstraints" extension
and "keyUsage" missing. Now we used this intermediate 02 CA to sign server
certificate.

We have uploaded the CA certificates on the client side in the trust store.
When a connection is made using openssl s_client / curl, we see that
connection goes through successfully and the certificate chain is verified
successfully OK.

We expected the verification to fail as one of the certificate in the chain
has "basicConstraints" missing. But openssl allows it. Is this the right
behaviour ?

If we need to have this check in place how to go about it . ?


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

From jochen.bern at binect.de  Thu May 31 17:14:12 2018
From: jochen.bern at binect.de (Jochen Bern)
Date: Thu, 31 May 2018 19:14:12 +0200
Subject: [openssl-users] PRNG is not seeded
In-Reply-To: <mailman.5776.1527771821.2681.openssl-users@openssl.org>
References: <mailman.5776.1527771821.2681.openssl-users@openssl.org>
Message-ID: <2c8ab346-1279-28a3-bc09-49ef0ac025ce@binect.de>

On 05/31/2018 03:03 PM, openssl-users-request at openssl.org distributed:
> Date: Thu, 31 May 2018 18:45:02 +1000
> From: FooCrypt <openssl at foocrypt.net>
> 
> Place a teaspoon of fine grade white sand onto the skin of a snare drum

Macroscopic hardware TRNGs are a *tad* yesteryear

https://en.wikipedia.org/wiki/Lavarand

because observing *quantum* random events doesn't require large devices

https://en.wikipedia.org/wiki/Hardware_random_number_generator

(not to mention being IIUC harder to influence by an attacker so as to
make them lose randomness). Nonetheless, if you don't have the hardware
(builtin TPM?) and cannot easily connect one to the given platform (as I
suspect for the OP's architecture) ...

For general computing platforms, I've taken to installing (and, of
course, running and monitoring) haveged as a standard - on hosts *and*
VMs. It can run in an AIS-31 test mode if you want to check out the
entropy it collects.

https://wiki.archlinux.org/index.php/Haveged

>> On 31 May 2018, at 6:07 PM, chris.gray at kiffer.be wrote:
>> I've also encountered this quite often, and I have a feeling that on
>> today's connected devices there may be a lot of entropy "in the air"
>> (quite literally) which is not being captured. Does any one know of 
>> research in this area?

Not specifically for mobile phones or WiFi interfaces, if that's what
you're referring to with "in the air". However, squeezing available
entropy out of various less-than-predictable hardware and OS states is
what *all* non-hardware entropy gatherers ultimately do, from the Linux
kernel's /dev/random mechanisms to haveged to what-have-you.

Regards,
-- 
Jochen Bern
Systemingenieur

www.binect.de
www.facebook.de/binect

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

From openssl-users at dukhovni.org  Thu May 31 18:00:08 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 31 May 2018 14:00:08 -0400
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <1527784638.30157.38.camel@redhat.com>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
 <1527784638.30157.38.camel@redhat.com>
Message-ID: <B80647F6-04C7-4762-99CF-BB37B5C72E11@dukhovni.org>



> On May 31, 2018, at 12:37 PM, Tomas Mraz <tmraz at redhat.com> wrote:
> 
> I would not say that weak DH parameters are fully rejected by OpenSSL.
> The 1024 bit DH parameters could be in theory attacked by state
> agencies by precomputation of the discrete logarithm table.

That's speculative.  If the idea is to prefer kECDHE over kDHE,
OpenSSL already does that.  In practice ECDHE is negotiated
when available.  The issue at hand is whether kDHE is worse
than kRSA.  Which is more likely later key compromise or
a brute force attack on 1024-bit DHE likely costing 10's to
100's of millions of dollars per key...

> And openssl
> still accepts 1024 bit DH by default if I am not mistaken.

Yes, but unless you're another nation-state with secrets
worth attacking at all costs, it seems rather unlikely
that this is a concern.

-- 
	Viktor.


From rsalz at akamai.com  Thu May 31 18:08:38 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 31 May 2018 18:08:38 +0000
Subject: [openssl-users] Fwd: basic constraints check
In-Reply-To: <CAG1qr9AgSg2fxSAyMYvAxeorK0usNSNco3Pcogq9W7dwKHwdMg@mail.gmail.com>
References: <CAG1qr9DnSkCRO-Md5rh1gN2eAcEHPrnSHNSaTXqaY1-mVbd=dw@mail.gmail.com>
 <CAG1qr9AgSg2fxSAyMYvAxeorK0usNSNco3Pcogq9W7dwKHwdMg@mail.gmail.com>
Message-ID: <72EDAC8D-A635-4B68-8316-11883F020B49@akamai.com>

  *   We generated intermediate02 such that it has "basicConstraints" extension and "keyUsage" missing. Now we used this intermediate 02 CA to sign server certificate.

If those extensions, which are *optional,* are not present, then there is no limit on how the keys may be used, or how long the cert chain may be.  OpenSSL is doing the right thing.

If you want to add them, and you cannot upgrade, then read about the openssl config file syntax.  Good luck.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180531/694c3e55/attachment.html>

From uri at ll.mit.edu  Thu May 31 18:43:00 2018
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Thu, 31 May 2018 18:43:00 +0000
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <B80647F6-04C7-4762-99CF-BB37B5C72E11@dukhovni.org>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
 <1527784638.30157.38.camel@redhat.com>
 <B80647F6-04C7-4762-99CF-BB37B5C72E11@dukhovni.org>
Message-ID: <A3289E32-BD4F-45D2-8FAF-9E8EE4D5A43E@ll.mit.edu>

FWIW, I'm with Viktor in this argument. From cryptography point of view he's right. I suspect he's right from the practical point of view as well.

P.S. Those concerned that a nation-state would attack them, are advised to change the default config anyway.
--
Regards,
Uri Blumenthal

?On 5/31/18, 14:01, "openssl-users on behalf of Viktor Dukhovni" <openssl-users-bounces at openssl.org on behalf of openssl-users at dukhovni.org> wrote:

    
    
    > On May 31, 2018, at 12:37 PM, Tomas Mraz <tmraz at redhat.com> wrote:
    > 
    > I would not say that weak DH parameters are fully rejected by OpenSSL.
    > The 1024 bit DH parameters could be in theory attacked by state
    > agencies by precomputation of the discrete logarithm table.
    
    That's speculative.  If the idea is to prefer kECDHE over kDHE,
    OpenSSL already does that.  In practice ECDHE is negotiated
    when available.  The issue at hand is whether kDHE is worse
    than kRSA.  Which is more likely later key compromise or
    a brute force attack on 1024-bit DHE likely costing 10's to
    100's of millions of dollars per key...
    
    > And openssl
    > still accepts 1024 bit DH by default if I am not mistaken.
    
    Yes, but unless you're another nation-state with secrets
    worth attacking at all costs, it seems rather unlikely
    that this is a concern.
    
    -- 
    	Viktor.
    
    -- 
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180531/27c474af/attachment.bin>

From openssl-users at dukhovni.org  Thu May 31 19:43:31 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 31 May 2018 15:43:31 -0400
Subject: [openssl-users] stunnel 5.46 released
In-Reply-To: <A3289E32-BD4F-45D2-8FAF-9E8EE4D5A43E@ll.mit.edu>
References: <e97ac79e-5f17-0a75-5594-a86520c8dafc@stunnel.org>
 <1CE0D049-95F8-48CE-84DC-C6CC99259F44@dukhovni.org>
 <25a55c26-cfde-2eb2-94c9-f823f45122d6@stunnel.org>
 <4EDFFDE1-0873-4CBB-9065-BF56351719EC@dukhovni.org>
 <1527784638.30157.38.camel@redhat.com>
 <B80647F6-04C7-4762-99CF-BB37B5C72E11@dukhovni.org>
 <A3289E32-BD4F-45D2-8FAF-9E8EE4D5A43E@ll.mit.edu>
Message-ID: <D624CCCD-00D7-4684-A601-D8A0BF63E92E@dukhovni.org>



> On May 31, 2018, at 2:43 PM, Blumenthal, Uri - 0553 - MITLL <uri at ll.mit.edu> wrote:
> 
> FWIW, I'm with Viktor in this argument. From cryptography point of view he's right. I suspect he's right from the practical point of view as well.

This is not so much a matter of "right" or "wrong" as arguably
"sensibly pragmatic" vs. "counter-productively cautious", or is
it "negligently careless" vs. "duly conservative"?

So these are judgement calls, but:

  https://tools.ietf.org/html/rfc7525#section-4.2

does recommend both DHE and ECDHE, so I'm on solid
ground viz. the IETF.

-- 
	Viktor.


From sandeep.bvb at gmail.com  Thu May 31 22:08:13 2018
From: sandeep.bvb at gmail.com (Sandeep Deshpande)
Date: Fri, 1 Jun 2018 03:38:13 +0530
Subject: [openssl-users] Fwd: basic constraints check
In-Reply-To: <72EDAC8D-A635-4B68-8316-11883F020B49@akamai.com>
References: <CAG1qr9DnSkCRO-Md5rh1gN2eAcEHPrnSHNSaTXqaY1-mVbd=dw@mail.gmail.com>
 <CAG1qr9AgSg2fxSAyMYvAxeorK0usNSNco3Pcogq9W7dwKHwdMg@mail.gmail.com>
 <72EDAC8D-A635-4B68-8316-11883F020B49@akamai.com>
Message-ID: <CAG1qr9BbfHWqLTsVEgc60MK4VBRBAVtxQt2G3yQK7LaPwW_DSw@mail.gmail.com>

Hi Rich.. Thanks..
We want to add a check in our openssl library on client side to reject such
server certificate which are generated by the intermediate CA with missing
extensions like basic constraints..
How do we go about it?

I looked at the code. In crypto/x509v3/v3_purp.c I see that check_ca is
there. But it is getting called only for server certificate.


Thanks
Sandeep

On Thu, May 31, 2018, 11:39 PM Salz, Rich via openssl-users <
openssl-users at openssl.org> wrote:

>
>    - We generated intermediate02 such that it has "basicConstraints"
>    extension and "keyUsage" missing. Now we used this intermediate 02 CA to
>    sign server certificate.
>
>
>
> If those extensions, which are **optional,** are not present, then there
> is no limit on how the keys may be used, or how long the cert chain may
> be.  OpenSSL is doing the right thing.
>
>
>
> If you want to add them, and you cannot upgrade, then read about the
> openssl config file syntax.  Good luck.
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180601/d215d3c1/attachment-0001.html>

From openssl-users at dukhovni.org  Thu May 31 22:22:31 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 31 May 2018 18:22:31 -0400
Subject: [openssl-users] Fwd: basic constraints check
In-Reply-To: <CAG1qr9BbfHWqLTsVEgc60MK4VBRBAVtxQt2G3yQK7LaPwW_DSw@mail.gmail.com>
References: <CAG1qr9DnSkCRO-Md5rh1gN2eAcEHPrnSHNSaTXqaY1-mVbd=dw@mail.gmail.com>
 <CAG1qr9AgSg2fxSAyMYvAxeorK0usNSNco3Pcogq9W7dwKHwdMg@mail.gmail.com>
 <72EDAC8D-A635-4B68-8316-11883F020B49@akamai.com>
 <CAG1qr9BbfHWqLTsVEgc60MK4VBRBAVtxQt2G3yQK7LaPwW_DSw@mail.gmail.com>
Message-ID: <58C67B04-3BD9-4336-A5A2-BDCC213E9E6C@dukhovni.org>



> On May 31, 2018, at 6:08 PM, Sandeep Deshpande <sandeep.bvb at gmail.com> wrote:
> 
> Hi Rich.. Thanks..
> We want to add a check in our openssl library on client side to reject such server certificate which are generated by the intermediate CA with missing extensions like basic constraints..
> How do we go about it?
> 
> I looked at the code. In crypto/x509v3/v3_purp.c I see that check_ca is there. But it is getting called only for server certificate. 

Are you using OpenSSL 1.1.0 or OpenSSL 1.0.2?

-- 
	Viktor.


From rsalz at akamai.com  Thu May 31 22:22:43 2018
From: rsalz at akamai.com (Salz, Rich)
Date: Thu, 31 May 2018 22:22:43 +0000
Subject: [openssl-users] Fwd: basic constraints check
In-Reply-To: <CAG1qr9BbfHWqLTsVEgc60MK4VBRBAVtxQt2G3yQK7LaPwW_DSw@mail.gmail.com>
References: <CAG1qr9DnSkCRO-Md5rh1gN2eAcEHPrnSHNSaTXqaY1-mVbd=dw@mail.gmail.com>
 <CAG1qr9AgSg2fxSAyMYvAxeorK0usNSNco3Pcogq9W7dwKHwdMg@mail.gmail.com>
 <72EDAC8D-A635-4B68-8316-11883F020B49@akamai.com>
 <CAG1qr9BbfHWqLTsVEgc60MK4VBRBAVtxQt2G3yQK7LaPwW_DSw@mail.gmail.com>
Message-ID: <20C1F338-AC6B-4CE2-883C-CA1CD716A6FD@akamai.com>

I don?t recall the details of 1.0.2, sorry.  Maybe someone else on this list knows the best place to insert your checks.

From: Sandeep Deshpande <sandeep.bvb at gmail.com>
Date: Thursday, May 31, 2018 at 6:08 PM
To: Rich Salz <rsalz at akamai.com>, openssl-users <openssl-users at openssl.org>
Subject: Re: [openssl-users] Fwd: basic constraints check

Hi Rich.. Thanks..
We want to add a check in our openssl library on client side to reject such server certificate which are generated by the intermediate CA with missing extensions like basic constraints..
How do we go about it?

I looked at the code. In crypto/x509v3/v3_purp.c I see that check_ca is there. But it is getting called only for server certificate.


Thanks
Sandeep

On Thu, May 31, 2018, 11:39 PM Salz, Rich via openssl-users <openssl-users at openssl.org<mailto:openssl-users at openssl.org>> wrote:

  *   We generated intermediate02 such that it has "basicConstraints" extension and "keyUsage" missing. Now we used this intermediate 02 CA to sign server certificate.

If those extensions, which are *optional,* are not present, then there is no limit on how the keys may be used, or how long the cert chain may be.  OpenSSL is doing the right thing.

If you want to add them, and you cannot upgrade, then read about the openssl config file syntax.  Good luck.
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=DKOBwoCo7ectmyCA7_m3cOyRKCM9lxSO6nxCei8nOK4&s=RwnA-oRy8UC_wVuu40XbIthr0H-ML6HQhIGGl1uc3d4&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180531/cbece254/attachment.html>

From openssl-users at dukhovni.org  Thu May 31 22:38:26 2018
From: openssl-users at dukhovni.org (Viktor Dukhovni)
Date: Thu, 31 May 2018 18:38:26 -0400
Subject: [openssl-users] Fwd: basic constraints check
In-Reply-To: <CAG1qr9BbfHWqLTsVEgc60MK4VBRBAVtxQt2G3yQK7LaPwW_DSw@mail.gmail.com>
References: <CAG1qr9DnSkCRO-Md5rh1gN2eAcEHPrnSHNSaTXqaY1-mVbd=dw@mail.gmail.com>
 <CAG1qr9AgSg2fxSAyMYvAxeorK0usNSNco3Pcogq9W7dwKHwdMg@mail.gmail.com>
 <72EDAC8D-A635-4B68-8316-11883F020B49@akamai.com>
 <CAG1qr9BbfHWqLTsVEgc60MK4VBRBAVtxQt2G3yQK7LaPwW_DSw@mail.gmail.com>
Message-ID: <AF1A61D8-E2CB-42FC-A5D2-44EAAB5CDE83@dukhovni.org>



> On May 31, 2018, at 6:08 PM, Sandeep Deshpande <sandeep.bvb at gmail.com> wrote:
> 
> We want to add a check in our openssl library on client side to reject such server certificate which are generated by the intermediate CA with missing extensions like basic constraints..
> How do we go about it?
> 
> I looked at the code. In crypto/x509v3/v3_purp.c I see that check_ca is there. But it is getting called only for server certificate. 

In OpenSSL 1.0.2 CA certificates found in the trust store
are not checked.  This is fixed in 1.1.0.

You can always implement a verify callback to apply additional
constraints.

-- 
	Viktor.


From sandeep.bvb at gmail.com  Thu May 31 22:39:07 2018
From: sandeep.bvb at gmail.com (Sandeep Deshpande)
Date: Fri, 1 Jun 2018 04:09:07 +0530
Subject: [openssl-users] Fwd: basic constraints check
In-Reply-To: <58C67B04-3BD9-4336-A5A2-BDCC213E9E6C@dukhovni.org>
References: <CAG1qr9DnSkCRO-Md5rh1gN2eAcEHPrnSHNSaTXqaY1-mVbd=dw@mail.gmail.com>
 <CAG1qr9AgSg2fxSAyMYvAxeorK0usNSNco3Pcogq9W7dwKHwdMg@mail.gmail.com>
 <72EDAC8D-A635-4B68-8316-11883F020B49@akamai.com>
 <CAG1qr9BbfHWqLTsVEgc60MK4VBRBAVtxQt2G3yQK7LaPwW_DSw@mail.gmail.com>
 <58C67B04-3BD9-4336-A5A2-BDCC213E9E6C@dukhovni.org>
Message-ID: <CAG1qr9Dz5_mpp1qEp1CKU_tOVB6yGDg656_woP_vQSLybxitNQ@mail.gmail.com>

1.0.2j

On Fri, Jun 1, 2018, 3:52 AM Viktor Dukhovni <openssl-users at dukhovni.org>
wrote:

>
>
> > On May 31, 2018, at 6:08 PM, Sandeep Deshpande <sandeep.bvb at gmail.com>
> wrote:
> >
> > Hi Rich.. Thanks..
> > We want to add a check in our openssl library on client side to reject
> such server certificate which are generated by the intermediate CA with
> missing extensions like basic constraints..
> > How do we go about it?
> >
> > I looked at the code. In crypto/x509v3/v3_purp.c I see that check_ca is
> there. But it is getting called only for server certificate.
>
> Are you using OpenSSL 1.1.0 or OpenSSL 1.0.2?
>
> --
>         Viktor.
>
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180601/95742ab8/attachment.html>